Basically, I’m running Tailscale on most of my devices and using subnet routing on a Raspberry Pi for non-Tailscale devices.
My problem is that while using an exit node streaming video from cameras in the iOS/macos Home apps is entirely too slow. I can see from App Privacy Report that it attempts to connect to my home network’s WAN address, so I’ve set up subnet routing to bring in any traffic to any of ISP’s networks through the Raspberry Pi at home (this also makes it possible to use said ISP’s streaming app on Apple TV as if I were at home).
I know that Home doesn’t connect to the cameras locally at all, because I can tear down all the Tailscale stuff and not see any traffic between the client and the camera on the LAN.
Has anyone have a clue how to go about configuring this? Thanks in advance!
This is a shot in the dark, but you could do IPv6 for your internal networking, with the global unique IP addresses, it might help tailscale just route locally instead
I’m considering updating the post because I realize how vague it was. Let’s see if I can explain it quick on mobile:
I figured out that by enabling SNAT on the Tailscale subnet router then sniff traffic, I can see an HTTP pairing handshake between the two which succeeds.
Later when it switches to UDP port 5200 is when I start to see a response from the camera saying “destination port unreachable.”
If I
tcpdumpfrom the subnet router’s LAN interface (eth0), I do see the packets being rewritten (SNAT) correctly, but I still see the camera responding to the subnet router with “destination port unreachable.” That lines up with Wireshark running on macOS except obviously I see the packet coming from the camera’s LAN IP address going to the destination Tailscale IP address.What baffles me is if I completely shut down Tailscale then everything succeeds, I see UDP traffic flowing from the camera to the client without issue.
It makes me wonder if something is blocking UDP within the Tailscale software itself as I can’t seem to find any anti-UDP rules in the firewall.
Good thinking. If it works without tail scale, it’s probably a tail scale configuration issue.
I’m crossing my fingers that during the handshake they aren’t passing which IP address they’re sending/receiving from. I can’t really see inside the data from Wireshark, but my fear is the camera is saying “I’m 192.168.x.x” and the Mac is saying “I’m 100.x.x.x” because from the camera’s point of view, it would be receiving from “192.168.x.y” (the subnet router).
Since the feature is called HomeKit Secure Video I get the feeling they might be securing it by doing something like that.
This is why I’m recommending IPv6. If you have global unique addresses for all your devices, including on your local network, it makes tail scales job much easier
I’m really big on IPv6 adoption but you’re probably right — I have no clue which subnet to advertise on Tailscale for IPv6. Also, the subnet router happens to be the only device I can’t seem to get IPv6 to work on (Alpine Linux). Each time I’ve tried I ruined my
/etc/networking/interfacesand had to plug the hard drive into another machine to undo my changes.For what it’s worth, I believe Tailscale on the Apple TV blocks IPv6. In fact, if you activate Tailscale on your HomeKit Hub, it has the side effect of all thread devices no longer responding until you disconnect from Tailscale and reboot the Apple TV. It’s a major pain in the ass for my small HomeKit / Thread setup.
Here’s the corresponding bug report on GitHub.
I’ve actually had Tailscale disabled on it for some time now because my ISP’s (a cable operator) TV app knows via some tvOS API that a VPN is running and effectively shuts down.
My solution is to remove the Tailscale app completely, then when traveling put it behind a travel router (this works fantastically).
I’ll have to look into resolving my issue again soon; I just haven’t had time to follow up on this.