I have a VPN.

I have it set up in a pretty standard way: when a machine joins the VPN it effectively becomes part of my LAN. But I don’t route everything via the VPN, that would be inefficient and would waste my bandwidth. I haven’t bothered with doing DNS over VPN, as I usually just use IP addresses anyway (one of the advantages of using a 10.x.x.x network), and when you do that you run into all kinds of complexities and problems (like how to resolve names on the lan you’re connected to)

But sometimes I’m somewhere where I don’t trust the owner of the network that I’m connected to: I don’t want to be spied on.

In these instances, it’s handy to be able to route everything out over the VPN connection.

But if you don’t stop to think for a minute and just try to add a default route which points to the VPN server, you’ll instantly lose your VPN connection and all internet access because there’s no longer any way to reach the VPN you’re trying to route through. Doh.

The solution is simple:

#!/bin/bash
#delete existing default route:
sudo route del default
#traffic to the VPN server goes out via your existing connection:
sudo route add <internet-ip.of.vpn.server> gw <your.existing.untrusted.gateway>
#...and everything else gets routed out via the VPN (assuming your VPN server is 172.16.0.1)
sudo route add default netmask 0.0.0.0 gw 172.16.0.1

OK, that takes care of routing. Next you need to send your DNS requests out via the VPN, or you’ll still be pretty easily monitorable – overlords will still know every domain you visit. To do that, edit /etc/resolv.conf and change the ‘nameserver’ line to point to the nameserver for your VPN and/or LAN:

#/etc/resolv.conf
nameserver 172.16.0.1

I recommend running your VPN on port 443. My reason is really simple: in oppressive environments, you can pretty much count on port 443 being open, since it’s used for https, and https is not something that a tyrannical sysadmin/policymaker can get away with blocking: it’s the backbone of e-commerce. In addition, https traffic is encrypted, as is VPN, so it’s less likely to be monitored by things like deep packet inspection, and any not-too-deep packet inspection is likely to come up with an outcome of ‘encrypted traffic, nothing unusual’ when looking at VPN traffic on port 443.

It should be noted that while this is unlikely to set off automated alarm bells, it will look somewhat unusual to any human observer who notices – your overlords will see a bunch of “https” traffic, but nothing else (not even DNS), which may in itself raise suspicions.

It should also be noted that you very likely just added a couple of hundred milliseconds to your latency and have now effectively limited your available bandwidth somewhat, depending on network conditions.

But I know from experience that the victorian government’s IT agency, Cenitex, is incapable of determining any difference between https traffic and VPN traffic going via port 443.

Though, of course, that doesn’t mean it’s impossible…

…In fact, that doesn’t even mean it’s difficult…

…but you should be reasonably safe from the spying eyes of your microsoft cerfitied sysadmin.