Re:VPN location claims don't match real traffic exits
by devilbunny on Sunday December 14, 2025 @07:05AM
(#46262483)
I have run into the firewall problems before. Even seen them that block authentication but -if already connected to the tailnet before joining the WiFi in question - will continue to pass data. OpenVPN would not connect and couldn’t handle the IP address switch.
At worst, I turn on phone hotspot, authenticate, then switch back to WiFi. A purely serendipitous discovery on my part, but a very welcome one.
Re:VPN location claims don't match real traffic exits
by lxgr on Sunday December 14, 2025 @07:17AM
(#46262537)
Interesting, maybe they block the orchestration servers of Tailscale, but not the actual data plane (which is almost always P2P, i.e., it usually does not involve Tailscale servers/IPs at all)?
Re:VPN location claims don't match real traffic exits
by devilbunny on Sunday December 14, 2025 @02:24PM
(#46265942)
I'm sure they do, but the question is, why did OpenVPN fail? It's pure P2P. I've got a dynamic DNS through afraid.org, and that resolves on that network, so it's not just DNS-level blocking. I effectively have a static IP anyway; there's no CGNAT going on, so I've discovered that I misconfigured my DDNS once or twice only when afraid.org emailed to tell me that I hadn't updated in X months.
While I still prefer running a plain Wireguard VPN if possible (i.e. when there's a publicly reachable UDP port), the really big advantage of Tailscale over other solutions is that it has great NAT traversal, so it's possible to run a routing node behind all kinds of nasty topologies (CG-NAT, double NAT, restrictive firewalls etc.)