Why is there a dependency on external IP address?

i just spent an entertaining 2 days debugging why the DVR functionality against the appleTV client was unstable.

it turns out, that having added a split source route so that traffic from the appleTV goes around my VPN (for the sake of netflix), the appleTV can not see the DVR backend, which is running on another computer in the house.

removing the split route or changing the appleTV IP address allows the client to see the DVR with no problem. it seems that the client and server have some dependency on the external IP. this seems strange given that one can connect remotely to the DVR backend over http.

why does the client and/or the server even care what my external IP address is?

rob

Not really sure what you mean. The DVR advertises over Bonjour, and the clients use the Bonjour advertised host name to connect to the DVR. There is no other requirement.

that is exactly what i would expect, but there seems to be some kind of dependence on the external IP address that the appleTV presents vs. the server machine.

the sum total of whatā€™s programmed into my router is to create a new routing table, add a default route to that table which points out the cablemodem interface directly, and a rule saying traffic from the appleTVā€™s ip address should be looked up in the new table. if i delete the rule, the appleTV sees the DVR server and can play recordings. if i add the rule back, the appleTV can not stream a recording from the server.

itā€™s bizarre and the only thing that i could think of is that both ends are talking to one of your servers.

rob

the good news is that initially i thought my problem was a failing server machine, so i am replacing the disk and upgrading it to sierra. if you remember i was way downrev - 10.9.

rob

If the DVR receives a request from an internal IP, it lets it through. If itā€™s not in a known internal subnet, it will error out as it wants public internet access to be authenticated. Maybe thatā€™s related?

hmm. i donā€™t know. everything is on the same subnet here, so lan-lan communication should just work. thereā€™s no vlans or anything like that. when the source route is in place all other functions of the appleTV seem to work fine - streaming ESPN, itunes, etc.

i guess what i can do is set up the IP address of one of my laptops to hit the same route table and see if the http DVR interface works any differently. it really should not matter though as anything on the local subnet should not involve the router.

will the auth issue show up in the logs? its as though the appleTV is simply not able to connect to the backend as far as i can tell.

is there a more verbose logging level available?

rob

No but you can try hitting /status and see if you get json back. the response will be an HTML login page instead of json.

ok. i did try my experiment and did not have any problem with the http interface. and now of course when i install/delete my rule everything is still working on the Apple TV. no idea whatā€™s happeningā€¦

before i happened upon that (likely bogus) connection with the router, i was convinced that the appleTV was failing. i do have another one courtesy of the nice people at DTVNow, so i might try replacing it. itā€™s ridiculous, this would be the 3rd appleTV across 2 generations that has failed. and itā€™s not like i have the atv in a cabinet or anything.

rob

@pfile: Is your VPN configured for split tunneling, or is it configured for full vpn.

If not split tunneling, some VPNs will force ALL traffic, including traffic meant for the local LAN to other machines on the same subnet to instead go across the VPN link instead of ā€œlocallyā€.

the vpn is running on the router; the default route for the router points out the vpn. the source route for the appletv amounts to a split route.

i understand what you are saying but it really only applies to a vpn setup where each machine on the lan is running a vpn client. over here the machines on the lan are not running any vpn client and have no idea that the routerā€™s default route is thru a tunnel.

well, i do have some more info on thisā€¦ it would appear at first glance that the source route rule i installed is blindly forwarding all packets with the ip address of the Apple TV to the wan port. it remains a mystery why the router is even seeing these packets on its lan port, since the switches between the Apple TV and the router should have learned the mac addresses and not be broadcasting the packets to the segment of the lan that the router is actually on.

but that makes me wonder if this has something to do with all the MDNS traffic involved with the Apple TV and service advertisement, etc. because presumably some of those are IP broadcast packets which i assume must also be ethernet broadcast packets, or at least multicast packetsā€¦

its not clear to me why this would hose things up as nothing should be responding to those packets that get routed. it could be that as part of the multicast stuff that maybe the Apple TV or the server thinks that the mac address of the server or appleTV is actually the mac address of the router, thus hosing things. there is a very ā€œrace conditionā€ feel to whatā€™s happening; the client can spend a long time looking for the server and never find it. sometimes it eventually finds the server and then all is well for a long while.

bottom line though is this is probably a misconfiguration of the router on my partā€¦ i really only want the source route rule to take effect post-routing, and not pre-routing.

rob

ok, well just to close this outā€¦ i did a lot of tcpdump with the router rules in and out, and the only thing that i could really observe is that the communication between the appleTV and the server became very flaky when the source route rule was installed on the router. the client would query the server for status, dvr, etc. all the way up to ā€œjobsā€ and then there would be a lot of repeated tcp acks (from the server) for the same packet as though there was some issue at L2 between the two machines. i donā€™t think this was related to discovery since the Apple TV was talking to the server just fine, until it couldnā€™t.

the fix seems to have been to use an iptables rule that marks only packets with the appleTV source IP and a destination IP not on the subnet, then creating a rule that routes those marked packets to the ISP wan interface. one gotcha is that rp_filter needed to be set to 2 on the tunnel and wan interfaces with this method; with the ā€˜blindā€™ source route rule it was not necessary for some reason.

with this rule i donā€™t see any of the lan traffic being mistakenly routed to the wan, and channels starts up and runs fine. and of course netflix works OK too. so problem solved, but i wish i understood exactly what was going wrong in the first placeā€¦

1 Like