VPN location claims don't match real traffic exits

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.

[ Parent | on HN ]

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)?

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:VPN location claims don't match real traffic exits by lxgr on Monday December 15, 2025 @06:53AM (#46273298)

Were you using the semi-well-known port (1194)? Otherwise, maybe it's just more fingerprint-able, or whatever DPI the firewall uses hasn't caught up to Wireguard yet?

[ Parent | on HN ]