DNS tunneling over captive portals for free Wi-Fi

Secure WiFi isn’t just about passwords. It’s about understanding every protocol, every port, every potential bypass.

RasterSec provides comprehensive WiFi and network security audits: captive portal testing, wireless encryption analysis, segmentation validation, and real-world attack simulations.

Have you noticed how many WiFi access points in Turkey require ID or phone numbers? The Turkish Internet Law (Law No. 5651) makes every public Wi-Fi spot (airports, coffee shops, hotels) a mandatory surveillance point. The law requires these places to keep detailed logs of your internet activity, linked to your ID, for up to two years.

Apart from the privacy nightmare, it is simply backwards to extort travelers and tourists like this. Luckily, there is often a way to bypass these captive portals without supplying PII and it’s through DNS.

Businesses and municipalities invest into proprietary solutions like the one above whose whole selling point is that they run tcpdump and save the output in a centralized repository. Oh gee, I wonder what would happen if they got hacked… Sometimes these solutions allow traffic to other DNS servers such as Cloudflare. In this instance, only traffic to the default DNS server distributed via DHCP was permitted.

[siren@susasus ~]$ dig TXT rastersec.com +short @4.4.4.4
;; communications error to 4.4.4.4#53: connection refused
;; communications error to 4.4.4.4#53: connection refused
;; communications error to 4.4.4.4#53: connection refused

; <<>> DiG 9.20.13 <<>> TXT rastersec.com +short @4.4.4.4
;; global options: +cmd
;; no servers could be reached
[siren@susasus ~]$ dig TXT rastersec.com +short @1.1.1.1
;; communications error to 1.1.1.1#53: connection refused
;; communications error to 1.1.1.1#53: connection refused
;; communications error to 1.1.1.1#53: connection refused

; <<>> DiG 9.20.13 <<>> TXT rastersec.com +short @1.1.1.1
;; global options: +cmd
;; no servers could be reached
[siren@susasus ~]$ dig TXT rastersec.com +short
"google-site-verification=Gn1oiQHbDuYQ-lcSqDDrZlrcxKfW1VJ89QK1ZPKDkVU"
"v=spf1 mx -all"
[siren@susasus ~]$

Set up a DNS tunneling server (Iodine)

Before your travels, set up Iodine and save any credentials you need to connect to it. The steps may look like this if you’re on a RedHat Linux variant:

#!/bin/sh
dnf group install 'Development Tools' -y
dnf install net-tools -y
git clone https://github.com/yarrick/iodine.git
cd iodine
git checkout tags/v0.8.0
make -j
make install
mkdir -p /usr/local/lib/systemd/system
install doc/iodine-server.service /usr/local/lib/systemd/system/iodine-server.service
sed -i 's/syslog/journal/' /usr/local/lib/systemd/system/iodine-server.service
sed -i 's/\/bin\//\/sbin\//' /usr/local/lib/systemd/system/iodine-server.service
install doc/iodine-server.socket /usr/local/lib/systemd/system/iodine-server.socket
systemctl daemon-reload
cat > /etc/sysconfig/iodine-server << EOF
OPTIONS='-P password 10.6.0.1 your.domain.tld'
EOF
systemctl enable --now iodine-server.socket

Find an AP and connect for free

You can connect to the Iodine server and access SSH on the same server, which has unlimited internet. Although it is barely usable due to low speeds. Still, this can help you in an emergency situtation where you need to look up something or shoot a message.

The latency might be a problem, try Mosh. You can go one step forward and deploy a VPN/proxy on the server. So you can route all of your traffic through it over Iodine. Or simply create a good old SOCKS5 proxy by using the ssh -D (dynamic tunnel) option. I recommend choosing no encryption (HTTP proxy) or light encryption (SOCKS) if you go with the VPN/proxy route as Iodine can be slow and it has some limitations.