I like using dns2tcp, it's a lot easier to set up as it works on the transport layer (TCP), not the network layer (IP), and it seems a bit more reliable in my experience.
Second dns2tcp, although there's also Heyoka http://heyoka.sourceforge.net/, Netcross http://www.primianotucci.com/os/netcross-ip-over-dns-tunneli..., and a rather interesting presentation from Defcon a few years back that showed a more detailed and realistic scenario of using DNS tunneling to punch through a firewall and retrieve database records. I can't locate it right now, but I'll take a look if anyone's interested.
I've had some good experience with iodine in the past, it's been useful at airports and on trains to bypass captive portals.
It's extremely variable in performance, and can sometimes require a bit of tuning on the client side to work reliably; however, for the most part the auto-detection works well, and will upgrade to raw UDP on port 53 if it is possible.
The biggest downside with DNS tunneling is the high latency and low bandwidth - many "responsive" web apps feel like molasses, even long static pages take a surprisingly long time to download, and streaming video/audio becomes almost impossible. Of course it's better than no connectivity as a last-resort; SSH sessions are still quite usable and you can do basic things like email and forums.
Interesting idea. A few obstacles we'd need to overcome:
- Although SMS messages may be free/bundled for the mobile subscriber, they probably wouldn't be free for the other end (unless you set up the other end yourself, using another mobile device)
- The latency for SMS seems to be high (at least in places where I've lived: UK and China). I'm not sure about in the US. If latency is an issue then maybe somehow increasing the 'MTU', i.e. sending lots of SMS at the same time, would make the throughput OK.
On the other hand, maybe application-level gateways (email-to-SMS, web-to-SMS) would work better, albeit at the cost of flexibility.
How do these avoid captive portals? I thought the thing about captive portals was that they intercepted DNS queries: that's what caused you to get the portal when you typed in "google.com". (i.e., it resolves all DNS entries to the portal's IP until you authenticate) Is this not correct? (I can receive arbitrary DNS, not just send?)
Yes in the case of Bluecoat for example, which also is used to setup paywalls sometimes, you hijack all HTTP/HTTPS traffic and redirect it to the bluecoat server. So DNS goes through and when the portal is submit nothing is done to permit DNS traffic in any type of firewall.
Captive portals typically only capture A records, but custom servers like iodine will return results for any request type if the request starts with 'z'. As long as the captive portal supports unauthed recursing (which 99% of them do), you can still tunnel IP over DNS.
Almost all captive portals simply use MAC addresses for auth, so in practice it's much easier to spoof a host's MAC/IP and piggyback their authed session. IP over DNS is more useful for things like mobile providers where it's harder to spoof hardware identifiers, or networks that allow outbound DNS or have a DNS recursing resolver.
Somebody mentioned something about assuming networks that have deep packet inspection (really, it's almost always just application proxies on common ports) might not allow outbound DNS. Don't ever assume that the person who set up the network was smart, or that they didn't leave a hole for backwards compatibility with some legacy application. Almost all consumer-oriented networks have some hole you can use to get out to the internet.
HTTP hijacking is much more common than DNS. The reason for this is that hosts cache DNS results, so clients that just joined your network wouldn't get the redirect at all.
And yes, they probably should block excessive DNS traffic, but this is technically sophisticated to implement (now you're getting all stateful to determine what's excessive) and generally unnecessary.
It doesn't. You are correct. For any unencrypted WiFi but with a paywall / login page for actual usage - if the software is worth anything, DNS is hijacked and re-routed for unapproved clients.
I would think non-NXDOMAIN answers with very short TTLs (to avoid contaminating the negative lookup cache) ought to be harmless to all but the very sloppiest clients, no?
No. First, clients may be sloppy or may have alerts triggered if the IP doesn't fall into the right range. The latter has nothing to do with poor code quality. That's the problem with hijacking DNS, you've moved well beyond web browsers into all kinds of applications that are loaded with custom code that have completely undefined behavior from your perspective. For all you know, the DNS responses you've tweaked will make the user's software completely unusable until the whole thing is restarted.
Second, what do you do when the client is configured to require DNSSEC responses?
I have been running OpenVPN on UDP/53 for a few years now. I figure that any network operator sophisticated enough to do deep packet inspection to detect real DNS traffic is also sophisticated enough to block outbound UDP/53 traffic.
Nope. Public paywalled hotspots often have ip whitelists while you didn't pay. So they'll let everything trough that goes to THEIR dns. Openvpn on 53 won't help you here. Iodine will.
I don't know why they serve full dns to unpaid users. Maybe to avoid os dns cache issues.
I've used iodine a few times in the past while traveling. Works like a charm.
I see. You can use Iodine to tunnel through any arbitrary DNS server, even ones not under your control. I didn't appreciate that when I posted the above comment. Very neat.
They serve full DNS because then it's a single configuration to bother with - regular DNS. Until tools like this are factored for, there's no reason to do anything stateful with the DNS response. It'd just be extra work.
ICMP is often blocked nowadays even when HTTP is allowed, so I don't think IP over ICMP is very useful.
It is possible to filter Iodine requests given that they use NULL records, which are inexistent in the real world. Some other well-known tools use TXT, which is a bit more common. TUNS (http://www.loria.fr/~lnussbau/tuns.html) uses CNAME and respects the DNS standard, which should have near-100% success. It's quite a bit slower though.
Iodine is cool. If you plan on using it soon remember to set up your DNS records beforehand cause it might take a bit to propagate. I literally spent a whole airplane flight sending DNS requests to see if it propagated yet.
I've used it to get free internet at universities and hotels, slow but gets the job done. ICMP usually isn't filtered by those kinds of firewalls and I've yet to find a place that blocked it.
Nice project. I've been curious about internet (TCP, IP, whatever) over DNS for a while, but it always seems like a lot of work. Is there an X-over-DNS that's trivial to set up for Mac and phones? I'm aware that iodine works for those, it just looks .. complex.
I can imagine tunnelling your traffic through DNS to avoid a captive portal (i.e. actually paying for it) counts as circumventing a security measure, which is illegal in a lot of places including the country where I live in.
Cool.