Hacker News Reader

Comment by tgtweak | Hacker News Reader

The amount of public WiFi's (including in-flight ones) I've bypassed by running a vpn server on udp port 53 is honestly insane. Sadly, this is becoming less commonplace many captive portals don't allow any egress at all aside from the captive portal's IP - but alas - still impressive how many are susceptible. It also bypasses traffic shaping (speed limiting) on most networks that are publicly accessible even if they do require some kind of authorization to enable external accessibility.

Highly recommend softether as they give you juicy Azure relay capability for free which is allowed in more "whitelist only" networks than your own vps server.

Haven't gone so far as to enable iodine for actual two-way dns communication through a third party DNS resolver, but that would probably work in more cases than this, albeit slower.

View on HN

The networks where you can pay through the captive portal have to temporarily allow all traffic to load their payment widget and provide 3D-Secure (they don't know the domain your bank uses for that, so they have to allow all). Those can generally be bypassed by initiating the payment flow over and over again.

Some implementations of 3d secure load in an iframe, and the containing app waits for a postMessage from inside the iFrame to confirm that 3d secure has completed successfully

If you can load your own content into the iframe, and can figure out what the containing page web app is expecting, you can send window.parent.postMessage() and bypass 3dsecure

I had 8 IPs in a hetzner server years ago. One IP had an iptables rule to accept openvpn on any port.

My openvpn config was a long list of commonly accepted ports on either tcp or udp.

Startup would take a while but the number of times it worked was amazing.

Yea, I run wireguard & OpenVPN on port53 (different VPS) just in case it works. Unfortunately my experience with the "pay to use" WiFi so far has been they validate that port 53 is valid DNS traffic, and often don't allow arbitrary resolvers (e.g. `dig example.com @1.1.1.1` will not work)

You can use iodine and do a delegation from a real domain: It encodes packets in subdomains of your domain (and decodes them with a special DNS server). It is not fast.

I like to use SNI with e.g. pagead2.googlesyndication.com and www.googletagmanager.com because a lot of captive portals put ads on them, and I it on a google cloud instance since they own the IP.

Those are great domains for this kinda thing! Thanks for the idea

I've gotten this to work, but it's just so slow that it's not worth it.

There are also airline wifi these days that allow "free messaging" i.e. WhatsApp and Facebook Messenger traffic only.

If one could create a TCP-over-WhatsApp VPN that would be fantastic.

I think that's essentially what my HTTPS proxy does; except rather than actually being over WhatsApp (i.e. using WA messages or w/ever), the SNI tricks their authorization into thinking I'm using WA, while I am connecting to my proxy.

No, yours would immediately break if they whitelist IPs. This one is pretty much officially sanctioned WhatsApp traffic.

Ah right, if they also impose IP restrictions this would not work

TCP would be too wasteful - Whatsapp already has retransmissions/etc. You'd want to proxy at a higher layer such as HTTP and just relay HTTP messages (or ideally QUIC traffic so that you take advantage of header reuse/compression, etc - but somehow disable retransmissions since you're already on a reliable link).

I think this is a premature optimisation.

I'd rather have a straightforward TCP-over-WhatsApp proxy than some hacky thing that only works for HTTP, has to peek inside your TLS sessions, etc.

You’d get banned from WhatsApp pretty fast doing that.

Even for genuine WhatsApp traffic the speed is limited so severely that loading a video or image someone sent you is nearly impossible.

Airline-dependent but I have been able to browse HN over the "messaging" plan. Sometimes its just a data rate restriction, so HN works fine.

I don’t remember the exact verbiage, but one of the airlines hints that it’s the bandwidth-heavy “websites” (domains) they’re liable to be blocking.

Nothing like asking some data center far below to generate AI art from 30,000 feet.

Reply on news.ycombinator.com