Hack 47. Securely Connect Two Networks

Connect two networks together using vtun and a single SSH connection.

vtun is a user space tunnel server, allowing entire networks to be tunneled to each other using the tun universal tunnel kernel driver. Using an encrypted tunnel such as vtun allows roaming wireless clients to secure all of their IP traffic using strong encryption. It currently runs under Linux, BSD, and Mac OS X. These examples assume that you are using Linux.

The procedure described in this hack will allow a host with a private IP address (10.42.4.6) to bring up a new tunnel interface with an externally-routed IP address (208.201.239.33) that works as if the private network weren't even there. You'll do this by bringing up the tunnel, dropping the default route, then adding a new default route via the other end of the tunnel.

To begin, here is the (pre-tunneled) configuration of the network:

	root@client :~# ifconfig eth2 
	
	eth2 Link encap:Ethernet HWaddr 00:02:2D:2A:27:EA
	inet addr:10.42.3.2 Bcast:10.42.3.63 Mask:255.255.255.192
	[snip]
	root@client :~# route 

	Kernel IP routing table
 
	Destination Gateway Genmask Flags Metric Ref Use Iface
	10.42.3.0 * 255.255.255.192 U 0 0 0 eth2
	loopback * 255.0.0.0 U 0 0 0 lo
	default 10.42.3.1 0.0.0.0 UG 0 0 0 eth2

As you can see, the local network is 10.42.3.0/26, the IP is 10.42.3.2, and the default gateway is 10.42.3.1. This gateway provides network address translation (NAT) to the Internet. Here's what the path looks like to yahoo.com:

	root@client :~# traceroute -n yahoo.com 
	traceroute to yahoo.com (64.58.79.230), 30 hops max, 40 byte packets 
	1 10.42.3.1 2.848 ms 2.304 ms 2.915 ms 
	2 209.204.179.1 16.654 ms 16.052 ms 19.224 ms 
	3 208.201.224.194 20.112 ms 20.863 ms 18.238 ms 
	4 208.201.224.5 213.466 ms 338.259 ms 357.7 ms 
	5 206.24.221.217 20.743 ms 23.504 ms 24.192 ms
	6 206.24.210.62 22.379 ms 30.948 ms 54.475 ms
	7 206.24.226.104 94.263 ms 94.192 ms 91.825 ms
	8 206.24.238.61 97.107 ms 91.005 ms 91.133 ms
	9 206.24.238.26 95.443 ms 98.846 ms 100.055 ms
	10 216.109.66.7 92.133 ms 97.419 ms 94.22 ms 
	11 216.33.98.19 99.491 ms 94.661 ms 100.002 ms
	12 216.35.210.126 97.945 ms 93.608 ms 95.347 ms
	13 64.58.77.41 98.607 ms 99.588 ms 97.816 ms

 

3.9.1. vtun Setup

This example will connect to a tunnel server on the Internet at 208.201.239. 5. It has two spare live IP addresses (208.201.239.32 and 208.201.239.33) to be used for tunneling. I'll refer to that machine as the server and our local machine as the client.

Now, let's get the tunnel running. To begin, load the tun driver on both machines:

	# modprobe tun

It is worth noting that the tun driver will sometimes fail if the kernel version on the server and client don't match. For best results, use a recent kernel, and the same version (e.g., 2.6.11) on both machines.

On the server machine, save this file to /usr/local/etc/vtund.conf:

	options {
	port 5000;
	ifconfig /sbin/ifconfig;
	route /sbin/route;
	syslog auth;
	}

	default {
	compress no;
	speed 0;
	}

	home {
	type tun;
	proto tcp;
	stat yes;
	keepalive yes;
	
	pass sHHH; # Password is REQUIRED.

	up {
	ifconfig "%% 208.201.239.32 pointopoint 208.201.239.33";

	program /sbin/arp "-Ds 208.201.239.33 %% pub";
	program /sbin/arp "-Ds 208.201.239.33 eth0 pub";

	route "add -net 10.42.0.0/16 gw 208.201.239.33";
	};

	down {
	program /sbin/arp "-d 208.201.239.33 -i %%";
	program /sbin/arp "-d 208.201.239.33 -i eth0";

	route "del -net 10.42.0.0/16 gw 208.201.239.33";
	};
	}

Then launch the vtund server:

	root@server :~# vtund -s 

Now you'll need a vtund.conf file for the client side. Save this file as /usr/local/etc/vtund.conf on the client side:

	options {
	port 5000;
	ifconfig /sbin/ifconfig;
	route /sbin/route;
	}

	default {
	compress no;
	speed 0;
	}

	home {
	type tun;
	proto tcp;
	keepalive yes;
	
	pass sHHH; # Password is REQUIRED.
	
	up {
	ifconfig "%% 208.201.239.33 pointopoint 208.201.239.32 arp";

	route "add 208.201.239.5 gw 10.42.3.1";
	route "del default";
	route "add default gw 208.201.239.32";

	};

	down {
	route "del default";
	route "del 208.201.239.5 gw 10.42.3.1";
	route "add default gw 10.42.3.1";
	};
	}

Finally, run this command on the client:

	root@client :~# vtund -p home server 

Presto! You now not only have a tunnel between client and server, but also have added a new default route via the other end of the tunnel. Take a look at what happens when we traceroute to yahoo.com with the tunnel in place:

	root@client :~# traceroute -n yahoo.com 
	
	traceroute to yahoo.com (64.58.79.230), 30 hops max, 40 byte packets 
	1 208.201.239.32 24.368 ms 28.019 ms 19.114 ms
	2 208.201.239.1 21.677 ms 22.644 ms 23.489 ms
	3 208.201.224.194 20.41 ms 22.997 ms 23.788 ms
	4 208.201.224.5 26.496 ms 23.8 ms 25.752 ms 
	5 206.24.221.217 26.174 ms 28.077 ms 26.344 ms 
	6 206.24.210.62 26.484 ms 27.851 ms 25.015 ms 
	7 206.24.226.103 104.22 ms 114.278 ms 108.575 ms 
	8 206.24.238.57 99.978 ms 99.028 ms 100.976 ms 
	9 206.24.238.26 103.749 ms 101.416 ms 101.09 ms
	10 216.109.66.132 102.426 ms 104.222 ms 98.675 ms
	11 216.33.98.19 99.985 ms 99.618 ms 103.827 ms
	12 216.35.210.126 104.075 ms 103.247 ms 106.398 ms
	13 64.58.77.41 107.219 ms 106.285 ms 101.169 ms

This means that any server processes running on client are now fully available to the Internet, at IP address 208.201.239.33. This has happened all without making a single change (e.g., port forwarding) on the gateway 10.42.3.1.

Here's what the new tunnel interface looks like on the client:

	root@client :~# ifconfig tun0 

	tun0 Link encap:Point-to-Point Protocol
	inet addr:208.201.239.33 P-t-P:208.201.239.32 Mask:255.255.255.255
	UP POINTOPOINT RUNNING MULTICAST MTU:1500 Metric:1
	RX packets:39 errors:0 dropped:0 overruns:0 frame:0
	TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
	collisions:0 txqueuelen:10
	RX bytes:2220 (2.1 Kb) TX bytes:1560 (1.5 Kb)

And here's the updated routing table (note that we still need to keep a host route to the tunnel server's IP address via our old default gateway; otherwise, the tunnel traffic couldn't get out):

	root@client :~# route 

	Kernel IP routing table
	Destination Gateway Genmask Flags Metric Ref Use Iface
	208.201.239.5 10.42.3.1 255.255.255.255 UGH 0 0 0 eth2
	208.201.239.32 * 255.255.255.255 UH 0 0 0 tun0
	10.42.3.0 * 255.255.255.192 U 0 0 0 eth2
	10.42.4.0 * 255.255.255.192 U 0 0 0 eth0
	loopback * 255.0.0.0 U 0 0 0 lo
	default 208.201.239.32 0.0.0.0 UG 0 0 0 tun0

To bring down the tunnel, simply kill the vtund process on client. This restores all network settings back to their original state.

3.9.2. vtun with SSH

This method works fine, if you trust vtun to use strong encryption and to be free from remote exploits. Personally, I don't think you can be too paranoid when it comes to machines directly connected to the Internet. To use vtun over SSH (and therefore rely on the strong authentication and encryption that SSH provides), simply forward port 5000 on client to the same port on server. Give this a try:

	root@client :~# ssh -f -N -c blowfish -C -L5000:localhost:5000  server 
	root@client :~# vtund -p home localhost 

In order to discourage connections to vtund on port 5000 of the server, add an iptables rule to drop connections from the outside world:

	root@server :~# iptables -A INPUT -t filter -i eth0 -p tcp --dport 5000 -j  
	DROP 

This allows local connections to get through (since they use loopback) and therefore requires an SSH tunnel to server before accepting a connection.

As you can see, this can be an extremely handy tool to have around. In addition to giving live IP addresses to machines behind a NAT, you can effectively connect any two networks together if you can obtain a single SSH connection between them (originating from either direction).

3.9.3. Tips and Tricks

While that should be enough information to get vtund up and running on your system, here are a couple of additional points to keep in mind.

• The session name (home in the preceding example) must match on the client and the server sides, or you'll get an ambiguous "server disconnected" message.
• The same goes for the password field in the vtund.conf file on both sides. It must be present and match on both sides, or the connection won't work.
• If you're having trouble connecting, make sure you're using the same kernel version on both sides, and that the server is up and running (try telnet server 5000 from the client side to verify that the server is happy).
• Try the direct method first, then get SSH working once you are happy with your vtund.conf settings.

If you're still having trouble, check /etc/syslog.conf to see where your auth facility messages are going, and watch that log on both the client and server when trying to connect. It can be tricky getting vtun running the first time, but once it is properly configured, it works like a charm.

If your head is swimming from this vtund.conf configuration, or if you're feeling lazy and don't want to figure out what to change when setting up your own client's vtund.conf file, take a look at the automatic vtund.conf generator [Hack #48].