Tunneling your traffic for fun and profit

Zbyszek Sobiecki <kodz@slonce.com>

Some time ago, when I dropped managing network in company I worked for, and I lost control over it, I started wondering what is my new admin doing in his spare time. Is he sniffing my traffic? Or maybe he enjoys reading proxy logs? Few days later, during my morning coffee, digging through websites I checked daily, I got a message from squid. It said that resource I'm trying to see is forbidden because of my company's access policy. Bottom of the message looked like IT Staff Hall Of Fame, so I suspected rather their emotional problems than some management decision. I don't like to waste my time on political fights, so I've decided to setup a simple tunnel connection between my laptop and a host outside local network. I planned to transfer all my traffic through this connection except that related to my job - accessing local hosts, VPN sites, etc. I wanted to put all tunneled traffic into one encrypted, and possibly compressed channel. It would look like single, persistent connection to some remote host. And of course many work-related connections ;) Here goes the picture:

I've decided to use https port (443) on the remote side, because it wasn't filtered on my firewall. My experience says, that protocols like https, pop3s and many other, widely used ports with their encrypted (SSL enabled) versions are just passed out. It's probably because of difficulties in identifying suspicious traffic to cut off.

Software I always used for such tasks was vtun. It's configuration is quite simple. You'll find all needed options in example configuration file. You need to run two copies of it. First at the remote host, as a server and second on your workstation as client. It's possible to switch the peers - for example when your server is behind NAT, and you'd like him to initialize the connection. But it's rare. The only essential thing here is that you need a possibility to setup a TCP (or UDP) connection between these two hosts. It's doesn't really matter how. If you're lucky, you will simply find a port clearly passed from your workstation to the host, configure both sides of the connection (including packet forwarding and basic routing setup) and stop worrying about your privacy. My configuration follows.

Client file:

options {
  port 5000;		# Connect to this port.
  timeout 60;		# General timeout
  ppp		/usr/sbin/pppd;
  ifconfig	/sbin/ifconfig;
  route	/sbin/route;
}
Tunnel1 {
  pass  k0kom0rd4;	# Password
  persist keep;		# Persist mode 
  type tun;
  proto tcp;
  encr no;
  comp zlib:9;
  up {
	ifconfig "%% 10.100.1.2 10.100.1.1 mtu 1450";
  };
}

The syntax is quite clear here. I'm using this particular configuration through another encrypted tunnel (so encryption is turned off here) but the link is very slow and I need good compression with zlib. On analog dialup connection it gives my 4-5 times faster transfer of clear-text (all gzip-disabled websites, text files, mail transfer, etc). Local peer is 10.100.1.2, while remote side has address 10.100.1.1. It's useful to put there addresses into your /etc/hosts file. Session name is "Tunnel1". And corresponding remote side configuration:

options {
  port 5000;      # Listen on this port.
  syslog    daemon;
  ppp       /usr/sbin/pppd;
  ifconfig  /sbin/ifconfig;
  route  /sbin/route;
}

default {
  compress zlib:0;      # Compression is off by default
  speed 0;     # By default maximum speed, NO shaping
}

Tunnel1 {
  pass  k0kom0rd4; # Password
  stat  yes;
  type  tun;      # IP tunnel
  proto tcp;      # UDP protocol
  comp  zlib:0;   # LZO compression level 9
  encr  yes;      # Encryption
  keepalive yes;  # Keep connection alive

  up {
   ifconfig "%% 10.100.1.1 10.100.1.2 netmask 255.255.255.252 mtu 1450";
   route "add 10.100.1.2 10.100.1.1";
#  route "add 10.100.3.0/24 10.100.1.2";
  };
  down {
   ifconfig "%% down";
   ifconfig "%% delete";
  };
}

Now you can run vtund on your gateway host, to listen for incoming connection. Next, perform daily network setup of your workstation and check whether vtund port on remote side is accessible - just connect to specified port and wait for VTUN response. If it works - everything should go easily. Start your vtund client with proper parameters (including server address). Check out the syslog to make sure the connection was established. If so, ifconfig -a will tell you about a new tunnel interface. It's probably tunX (e.g. tun0) on your BSD system. It's name can differ, but basically it should contain both addresses in the description. Remote tunnel address should respond now (if no filtered somehow) and you should be able to connect to your gateway host through it.

As we want to access completely independent networks through our tunnel, we need to provide connectivity for them through the remote peer. It can be done in many ways. The easiest will be setting a NAT there. If you're using ipnat it'll take just one line:

map fxp0 10.100.0.0/16 -> 192.168.192.192/32

where fxp0 is default (outside) network interface of your peer, 10.100.0.0/16 - the network range for your tunnels, 192.168.192.192/32 - public address you'll be seen in the internet under. Of course your configuration can be much fancier. Don't forget to enable packet forwarding in sysctl (or simply gateway_enable="YES" in /etc/rc.conf)

Next, we have to route almost all your traffic through the new interface. On FreeBSD it goes like this:

> route add <remote_host_real_address> <local_default_gateway>
> route add default <remote_host_tunnel_address>

Remember, that we can't change the route to your remote internet host, because the tunnel would go down. Now all our "official" destinations not going through it:

> route add <official_network1> <local_default_gateway>
> route add <official_host1> <local_default_gateway>
> route add <official_host2> <local_default_gateway>
.. .. .. ..
.  .  .  .

It's nice to put all these commands in short shell script and use it from rc scripts, just to make sure that we didn't forget about anything and don't waste our time.

Maybe the whole thing looks quite complicated at first, but in daily usage it's not annoying and can give you a lot of profit.

Usage examples (excluding mistrusted local network issue):

If you're connected to very slow link (like dialup connection) and you need to download tons of mail - you just start one script, then your mail/news/web client and all data comes compressed to you. Really fast.

If your ISP's international (or any other) links are overloaded, but you're able to connect with your vtund host quite fast - you can use it's outside connections. It happens when your provider's BGP staff is drunk or missing ;) You just set your routing paths by yourself. Just in the higher layer.

You need static IP address. Whether your address is translated or not, it can be always constant. It's one of your peer's addresses or any other it can route. It has nothing to do with your actual physical location, however. So it's hard to tell whether you're at the office at the moment or somewhere else.

Your Internet connection is weak, but you're able to access some other network (like private WAN) with hosts able to forward your packets to the internet.

Once I worked for a company with fair VPN connection to it's other division, totally independent to very unstable Internet link. People often screamed "there's no Internet again!" and running all around behind my back, while I was still using google or IM's. Compressed and encrypted ;)

As I mentioned before, it doesn't matter how you will setup the TCP channel. Personally I don't like having any ports open on my gateway host except ssh. So I keep them closed or filtered on public interfaces - the vtund server runs on it's loopback. I'm setting a simple ssh tunnel to it, connecting to the "remote loopback" and listening on local 127.0.0.1 address. Then vtun client connects to localhost on my workstation and everything goes like this:

With SSH tunnels you can go through multiple hops before you reach the host running vtund. Sometimes, you might want to manually choose the way for your packets through different networks. It's good to tweak vtund.conf on both sides to tune encryption and compression methods and find right combination for your traffic profile.

Tunnels allow you to choose your own path. It's often safer and faster.