Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 28 subscribers
  • Views 655 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IP 192.168.99.76 port 7000 is this the APX?

Wayne Folta

I'm noticing a strange IP address on the network: 192.168.99.76. I can't find 192.168.99 anywhere in the SFOS.

But the mystery is even deeper because it appears that packets to this IP are being forwarded to the WAN. I think. But it's confusing...

I captured packets and this is one of those strange situations where I can't quite understand what's going on. There are always two TCP packets together:

1. Has the source IP of the AppleTV port 50183 and the destination is 192.168.99.76 port 7000. The IPv4 Checksum is always the same, though I can see slight changes in the body. The In interface is Port 1 (which connects to the APX), no Out interface is listed.

2. Has the source of the public IP of the WAN port (Port 2) and port 50183 and the destination is again 192.168.99.76 port 7000. The IPv4 Checksum is always the same, though I can see slight changes in the body. The In interface is Port 1 and the Out interface is Port 2.

The checksums of the two packets are different and their content looks different. (All 64 bytes total length.) Though as mentioned the Packet #1's all have the same checksum, and the Packet #2's all have the same checksum.

It feels like this is one packet caught at two points in time, going from the AppleTV wirelessly to the APX into Port 1 and out of Port 2 to the Internet.. (Except for the differing checksums.) But it's very confusing. And 192.168.99 is a private network so should not every go out Port 2 (WAN), right?

The second packer which has an Out Interface Port of 2 (WAN) also has a Firewall Rule of 4, which is the LAN/Any to WAN/Any rule. So I think it's not being dropped.



This thread was automatically locked due to age.
Parents
  • 0

    Is the apex registered on your XG or cm wireless? If you restart the app you should see it’s address appear in your dhcp list and logviewer.

    ian

  • 0 in reply to rfcat_vk

    Good idea. The APX is in the XGS' DHCP and the address is as expected a 192.168.1.X address. It is connected via ethernet to Port 1. (And Ports 1 and 4 are bridged together. There are three SSIDs on the APX, one of which has 192.168.1.X addresses and the other two are different but not 192.168.99.X.) There are four DHCP server entries, none of which have 192.168.99.X.

    Someone who knew what they're doing (I'm still learning) configured the XGS before I got it and the APX is registered/controlled on it. However, I did accidentally try to also register it on Sophos Central in my early days of poking around and that failed, but I'm wondering if it half-worked. (I've since rebooted the XGS and the APX multiple times as a part of maintenance and I'd assumed any weirdness would've worked itself out. The APX appears on the XGS and not in Sophos Central. Also, the APX Wireless Standard trial on Sophos Central has expired along with all the other trials you initially get signed up for.)

  • 0 in reply to Wayne Folta

    A quick answer, the APX will have a local address regardless XG or cm control. you can have you APX either on cm or XG, but not both.
    If you tracert to the offending address where does the report show it living?

Reply Children
  • 0 in reply to rfcat_vk

    Doing a trace route from the XGS I get nothing. From a laptop on the 192.168.1.X network, I get the first hop to the XGS then nothing.

    In my limited packet capture, the mystery address is always a destination. See the screenshot, below. Firewall use 4 is LAN/Any to WAN/Any.

  • +1 in reply to Wayne Folta

    You have to read the packet capture bot to top. 

    The first packet (second in your picture) is send from the Apple TV to the 192.168.99.76. 

    Expecting there is no .99.76 XG act as a router and send it to somebody, maybe knowing this address (Default Gateway aka WAN Interface). It gets masqueraded and send out to the WAN. 

    Port 7000 could be a streaming service, according to apple. https://support.apple.com/de-de/HT202944

    There seems to be people, having the same kind of observation: https://www.reddit.com/r/HomeKit/comments/bk1ee9/home_app_tries_to_communicate_with_random_ip_on/

  • 0 in reply to LuCar Toni

    Yes, it appears that the AppleTV sends a packet that the XGS says "Hey, not on my LANs, so I'll send it to my gateway." It could be SNAT'd, which might explain why the two packets -- if I showed the content -- differ in the bytes they contain. (Though they are the same length.)

    But isn't 192.168.99.X a private range which should not be routed? Or is that just the general description and in reality I need to make a Firewall rule that drops things bound to 192.168.X.Y where the IP isn't one of the ranges that I actually do use? (I assume that the ISP router drops it, but it seems like it would be best practice to not leak anything outside of my firewall if I can help it.)

    Your link is very helpful. The AppleTV happened to be streaming when I saw the packets, but the link talks about Homekit and the AppleTV will be the HomeKit hub, so it makes sense that it might be doing something HomeKit-related. Still reading the thread to figure out if it's one of my devices indirectly (maybe via Bluetooth) advertising an interface that's down and hence has an odd IP address, or if it's even picked up on a neighbor's HomeKit device (via Bluetooth) and is attempting to talk to it.

    If it's the latter, that's rubbing salt in the wound of Sophos not handling mDNS: my HomeKit devices on different networks can't talk to each other, but my HomeKit hub can detect a neighbor's HomeKit device?

  • 0 in reply to Wayne Folta

    Private Range will still be send to the ISP, because its the default gateway. The ISP will simply drop those packets. 

    PS: Helpful to know: Sophos XG Firewall is a business product. Consumer products are likely to be lazy to implement "auto discover" options, using Broadcast. Broadcast is not the best option, because it will not be forwarded. There are certain mechanism to fordward broadcast but thats another story. 
    Same for Multicast. Those protocols are likely to be difficult. 

  • 0 in reply to LuCar Toni

    It turns out that mDNS can work across subnets. See https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/NetServices/Articles/faq.html (point 3). From what I understand, since every printer, scanner, etc, has mDNS built-in it shows up in corporate networks as well. (And it's simply not surprising to run into a company that uses AppleTVs connected to big screens and projectors in conference rooms to share screens.)

    As I understand it, most consumer-ish routers that handle mDNS use a service to reflect broadcasts across subnets, which means it's broadcast everywhere. But if I understand Apple's paper, above, there is a better way to make it work on a broader scale.

    P.S. Seems like there should be a flag for each gateway in SFOS saying whether the gateway is to the outside world or not. If it is, all packets with private source or destination IPs should be dropped automatically. Or maybe the flag should be for Firewall rules. Why pass packets upstream that can't get anywhere, and why leak information to an external organization that could be compromised and being used to scout your organization out? I guess you could be clever with the current Firewall rule mechanism (with groups), but I would need to make groups that exhaustively define private IP ranges other than those I actually use -- including via gateways that are not to external networks.