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.
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
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.
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 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.
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.