Hacker News Reader

Comment by digitallyfree | Hacker News Reader

Keep in mind that in the last couple years I've seen a lot of public Wifi (e.g. coffee shop, business guest network) blocking common dynamic dns domains like those from Afraid, Duckdns, etc. They also block most UDP and TCP ports unrelated to web browsing.

The only VPN connection I've seen that works everywhere is one on TCP 443, with a domain name that you control. Maybe have a UDP VPN instance on another port for performance but always have the TCP 443 instance avaliable as backup so you won't get blocked out. Personally I use OpenVPN on TCP 443 and have never had issues.

View on HN

Note that running VPNs over TCP has significant performance concerns (as you'd be running TCP within TCP) so it should only be used as a last-resort.

That's why you can run a second UDP instance on another port if you need that performance, and have the TCP one available as a fallback if that is blocked. Though to be honest the performance loss really depends on what you're doing on the VPN - if you need a low latency high bandwidth services, then UDP is the way to go. If you just use it for SSH, VDI, browsing, and file transfer I find the performance loss acceptable.

It really depends on packet loss. If you’re on a reliable connection with constant latency & bandwidth, TCP-in-TCP isn’t that bad.

However when you have high-packet-loss connections it becomes absolutely terrible.

If for some reason my Tailscale instance doesn't work at a cafe, last resort is a public cheap VPS where I have sshd listening on port 443 .. to ssh -D localhost:8888 VPS .. and then socks proxy my browser over localhost:8888

Do any OSs support DoH yet? Would solve that issue since cafe wifi wouldn’t be able to block individual domains.

for a chad in a cafe, maybe solved. but then again you could just connect to the address directly and forgoe doh.

dns blocking is mostly not a prohibiting factor, just an annoyance.

Reply on news.ycombinator.com