this post was submitted on 24 Jun 2024
8 points (90.0% liked)
networking
2805 readers
1 users here now
Community for discussing enterprise networks and the ensuing chaos that comes after inheriting or building one.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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
tcpdump
from 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/interfaces
and 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.