Channels app "at home" recent server list

[enigma]

I have a channels server in my apartment in City A.
I live in an apartment in City B with multiple Apple TVs and iOS devices with the Channels app.
I travel a lot (hotels) with an Apple TV and iOS devices with the Channels app.

When I used to live full-time in City A I connected the Channels app on all of my devices "At Home" directly to the local network (lets say 172.10.11.x) since we were all on the same LAN. When my life became mobile, I set up Tailscale integration and so far it has worked flawlessly!!

Each device (Apple TV, iPad, iPhone, etc) has Tailscale up and running and when I first opened the Channels app I selected "At Home" and entered the Tailscale address of the server. Again all is working well.

I have been experimenting with a pfSense firewall and have noticed that when I open a Channels app on any of my devices here in City B (on the Tailscale network) the firewall goes crazy with hundreds of connection attempts to the old "at home" LAN address (172.10.11.x). The 172 network is in the IANA "private" network range and should NOT have connection attempts to it across the open internet (hence its being blocked by the firewall).

I suspect that since all my devices used to connect to the server on the local LAN that even though they are now connecting via Tailscale, the Channels app is still trying to contact the LAN address server as well.

Is there any way to delete old "At Home" server addresses from the Channels app (either server side or in the app itself)?

[eric]

@enigma

I have been experimenting with a pfSense firewall and have noticed that when I open a Channels app on any of my devices here in City B (on the Tailscale network) the firewall goes crazy with hundreds of connection attempts to the old "at home" LAN address (172.10.11.x).

Yes, when on WiFi, the client will attempt to connect to the last local address it had.

I don't know why a firewall would be configured to complain about this sort of situation.

@enigma

The 172 network is in the IANA "private" network range and should NOT have connection attempts to it across the open internet (hence its being blocked by the firewall).

The router is the "default route", so anything that isn't routable by the client will be sent to the router. The correct behavior of the router would be to silently drop any RFC1918 destinations and move on. There's nothing bad going on here and everything is acting as designed.

@enigma

I suspect that since all my devices used to connect to the server on the local LAN that even though they are now connecting via Tailscale, the Channels app is still trying to contact the LAN address server as well.

When we connect to a DVR, we ask the DVR for all of the available IPs and attempt to connect to all of them to see if one of them gives us a better (more direct) route.

@enigma

Is there any way to delete old "At Home" server addresses from the Channels app (either server side or in the app itself)?

There is not a way to delete old At Home addresses at this time.

[johnluber]

I had entered a feature request abut a month ago to give us the option to manage IP addresses as part of the client settings on the server. It'd really be helpful to be able to cleanup addresses that are no longer valid and be able to set which one(s) are especially to better help non-technical users, like my wife, who travels to visit family.

[enigma]

@eric

Yes, when on WiFi, the client will attempt to connect to the last local address it had.

At home in City B, the Apple TVs are all WIRED connections. Not sure if that makes a difference.

@eric

I don't know why a firewall would be configured to complain about this sort of situation.

Please don't laugh at me... for security and research purposes I generally block & log ALL outgoing traffic and allow only necessary outbound connections on a case-by-case basis. It's a PITA, but it eliminates a lot of unnecessary bandwidth and chatter as well as security leaks.

@eric

The router is the "default route", so anything that isn't routable by the client will be sent to the router. The correct behavior of the router would be to silently drop any RFC1918 destinations and move on. There's nothing bad going on here and everything is acting as designed.
When we connect to a DVR, we ask the DVR for all of the available IPs and attempt to connect to all of them to see if one of them gives us a better (more direct) route.

I agree that there is nothing bad going on, but it does add unnecessary chatter as router bandwith & processing effort. Imagine if every device in our homes was passing to our routers hundreds of unnecessary requests per second for external private networks that have to be blocked/dropped/rejected.

@eric

There is not a way to delete old At Home addresses at this time.

Unfortunate. How might one submit a request for such a feature?

[eric]

@enigma

Please don't laugh at me... for security and research purposes I generally block & log ALL outgoing traffic and allow only necessary outbound connections on a case-by-case basis. It's a PITA, but it eliminates a lot of unnecessary bandwidth and chatter as well as security leaks.

That's fine, but you get what you ask for in regards to logging...

@enigma

I agree that there is nothing bad going on, but it does add unnecessary chatter as router bandwith & processing effort. Imagine if every device in our homes was passing to our routers hundreds of unnecessary requests per second for external private networks that have to be blocked/dropped/rejected.

The impact of a few extra SYN requests that the router drops is not going to be relevant to even the slowest routers. It's just a routing table lookup or firewall table lookup, which is incredibly efficient. The resources that it takes to log are somewhere between 100x and 10000x more than it took to drop the packet.

If you just passed the SYN along, your upstream router would likely drop it itself, which would also be just fine.

Whether a connection is "useful" or "unnecessary chatter" comes down to perspective. We aren't making any requests that we don't have a reason to make — we do it to provide the best, most seamless experience we can in the widest range of scenarios.

@enigma

How might one submit a request for such a feature?

It's on our radar but we don't have any timeline for when it could be addressed.

[enigma]

Okay. Thanks for the information.

[slampman]

@enigma

it does add unnecessary chatter as router bandwith & processing effort. Imagine if every device in our homes was passing to our routers hundreds of unnecessary requests per second for external private networks that have to be blocked/dropped/rejected.

Unless you are running pfsense from a 5 1/4in floppy on a 1987 computer, you are fine. Pfsense can handle this and 1,000,000,000,000 times more.