Building Tunnels with VTun
Arthur Donkers It has been a while since I wrote an article for Sys Admin. A lot of things have happened in that time -- business has been expanding, and Linux has definitely become mainstream. For my company, this meant that we grew out of our original office space and had to rent a new office to accommodate more people. And, since we did not want to drill holes in the (concrete) walls for the network cabling, we had to think of something else. Wireless LAN After some searching on the Internet, I ran into a wireless LAN system that operates at a frequency of 2.4 GHz. This system consists of two PCMCIA cards, plus two PCMCIA-to-ISA adapters, that you can add to your server or laptop computer. These cards emulate a “normal” Ethernet adapter and work both under Linux and Microsoft. After some initial testing, these cards were able to make a reliable connection between our two offices, with an acceptable throughput. However, using these cards causes a security problem. They communicate through the airwaves, free for anyone with a scanner (or a similar card) to pick up the signal and tune into the conversation. To solve this problem, a standard has been set that will encrypt the wireless communication, called WEP (Wireless Encryption Protocol). Different cards can join in by using the proper ESSID (a sort of shared secret that everyone must use to be able to communicate to each other). Being the paranoid people we are, we did not like this WEP thing, especially since even the 128-bit cards can be freely exported. So, we secured the communications ourselves. Besides, what's more fun than experimenting with new things under Linux? Tunneling Through After some Internet research, we decided to lay an encrypted IP tunnel on top of the wireless connection. This would secure communications between our offices, without sacrificing network functionality. So, first I will explain what IP tunneling is all about. Typically, on an IP network you communicate by directly addressing the party you want to talk to. So if, for instance, you wish to send an email to someone on the Internet, the following things happen:
• You compose a message. This scenario applies to many other services as well (http, telnet, ftp), in the same way. It is just like sending an envelope to someone, directly to their address. Directly addressing your counterpart is clean and simple; however, there are some problems related to this (some of which are resolved in IPv6, but that's a different article). Two of the main problems are: If you want to secure the communications, each protocol (server and client) must resolve that for themselves -- examples of these are SSH and SSL. Both of these added encryption and authentication functionality to the software for this. If you want to address a system you cannot reach directly, you have another problem. Suppose you are working at a client's site, and you want to read your company email. You must contact your internal mailserver, but this machine has been secured by using a firewall, so you cannot contact it. Both of these problems can be resolved with a tunnel. The best way to describe this is by saying that you put the envelope with the message into another envelope, addressed at the central mail dispatch of a company. This mail dispatch will pick up that envelope, open it, and send the original envelope on to the final destination. The same thing happens with an IP tunnel. Your original IP traffic is encrypted, including all header information, and stored as a data payload into another IP connection (the tunnel). This IP connection carries your data to the other side, where it is decrypted and sent to its original destination (based on the headers in the original message). Normally, this tunneling is done by the kernel itself, because it involves reassembling encrypted IP packets. Here's the process:
• The kernel receives an IP packet. Sending tunneling packets follows the same flow, in reverse order:
• The kernel receives an IP packet (mostly done on a special interface). The kernel is normally assisted by a daemon that will do the authentication and determine the encryption key used between the different parties. Tunneling the Linux Way: Getting and Building VTun For Linux, there are a number of tunneling packages available. If you visit freshmeat.net and search for tunnel, you get a list of different packages that build a tunnel one way or another. Especially for the 2.2.x (and 2.4.x) kernels, there are a number of tools available. There is a TAP device available, which allows you to manipulate raw IP packets in a user space program (e.g., a daemon or another program). After doing some research into the different packages, we chose VTun (virtual tunnel) because it is clean and simple and also works under OpenBSD and other UNIX implementations. You can find the home page of VTun at:
http://vtun.sourceforge.netThe VTun software (derived from VPPP by Maxim Krasnyansky) consists of two parts, the universal TUN/TAP driver and the VTun software itself. Both have excellent documentation on how to build and install the software. VTun does not quite follow the tunneling model described above. It uses its own daemon that will do the encryption and authentication. This daemon will use the Linux TUN/TAP devices to receive and send the IP traffic. The general idea, however, remains the same. If you follow these instructions, you should be able to build the software yourself. You may need to (possibly) recompile your kernel so it supports TUN and TAP. (TUN is a device for tunneling IP frames, and TAP is a device for tunneling Ethernet frames). You should install the TUN/TAP driver first (mind your kernel version), so you use the proper driver with Vtun. Both kernel options are shown below:
IP: tunneling (CONFIG_NET_IPIP) [M/n/y/?] ? CONFIG_NET_IPIP: Tunneling means encapsulating data of one protocol type within another protocol and sending it over a channel that understands the encapsulating protocol. This particular tunneling driver implements encapsulation of IP within IP, which sounds kind of pointless, but can be useful if you want to make your (or some other) machine appear on a different network than it physically is, or to use mobile-IP facilities (allowing laptops to seamlessly move between networks without changing their IP addresses; check out http://anchor.cs.binghamton.edu/~mobileip/LJ/index.html). Saying Y to this option will produce two modules ( = code which can be inserted in and removed from the running kernel whenever you want). Most people won't need this and can say N. Universal TUN/TAP device driver (CONFIG_TUN) [M/n/y/?] ? CONFIG_TUN: If you say Y here and create a character special files /dev/tun0 with major 90 and minor 0 and /dev/tap0 with major 90 and minor 128 using mknod (“man mknod”), you will be able to have a user space program read and write raw IP or Ethernet frames from/to that special file. tun0 and tap0 can be configured with ifconfig and route like any other network devices but they are not connected to any physical media; everything written by the user to /dev/tun0 and /dev/tap0 is treated by the kernel as if it had come in from a physical interface to the device tun0 or tap0; everything the kernel wants to send out over the device tun0 or tap0 can instead be read by the user from /dev/tun0 and /dev/tap0. Please read the file Documentation/networking/tun.txt for more information. This driver is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). The module will be called tun.o If you want to compile it as a module, say M here and read Documentation/modules.txt. If you don't know what to use this for, you don't need it.It is a good idea to build these as a loadable kernel module to avoid recompiling the whole kernel when you want to change the version of your TUN/TAP driver. You can even have the module autoload by adding it to the /etc/conf.modules file. After compiling the TUN/TAP driver, you can also compile the VTun software itself. You will end up with a vtund daemon program. After compiling all software, you should boot your new kernel. Configuring VTun Now that the easy part is done, you need to configure VTun. This is done through a number of simple steps. First, you need to load the tun module so you can create a tunneling Ethernet interface. You can simply insmod the module or have it autoloaded. This is how it looks on our machine:
[root@gw /root]# lsmod Module Size Used by tun 2396 1 hisax 135080 2 isdn 85024 2 [hisax] ray_cs 24572 1 ds 5740 1 [ray_cs] i82365 22640 1 pcmcia_core 39464 0 [ray_cs ds i82365]The tun module is the one from the TUN/TAP package. (Note that the ray_cs, ds, i82365, and pcmcia_core are used by the wireless LAN card and the rest are for our ISDN card). After you have loaded the tun module (and possibly others), you can configure the Ethernet interfaces and routing in the normal way. Depending on your network, you get something like this:
eth1 Link encap:Ethernet HWaddr 00:00:8F:48:84:5E
inet addr:192.168.1.2 Bcast:192.168.1.3 \
Mask:255.255.255.252
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6332560 errors:0 dropped:0 overruns:0 frame:20736
TX packets:5736741 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:3
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:219222 errors:0 dropped:0 overruns:0 frame:0
TX packets:219222 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
tun1 Link encap:Point-to-Point Protocol
inet addr:192.168.2.2 P-t-P:192.168.2.1 \
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1450 Metric:1
RX packets:5170215 errors:0 dropped:0 overruns:0 frame:0
TX packets:4211139 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
In our setup, eth1 is the wireless card and tun1 is the tunneling interface that communicates over this card. (The interface over which the tunneling software communicates depends on the routing and location of the VTun daemon on the other side. More on this later.)Combined with the routing below, this completes the basic networking setup.
[root@gw /root]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun1 192.168.1.0 0.0.0.0 255.255.255.252 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 tun1You now have a secure connection running over your wireless network. Running tcpdump on the different interfaces will show you that the data is really encrypted. By using ping, I will demonstrate this below (remember that ping fills its databuffer with a bytecounter incrementing in steps of 1). Running tcpdump on tun1, the input interface for traffic to be tunneled yields:
[root@gw /root]# ./tcpdump -i tun1 -lenx
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on tun1
08:02:23.869025 > 0:0:0:0:0:0 0:0:0:0:0:0 ip 98: 193.78.174.193 > \
193.78.174.34: icmp: echo request
4500 0054 7e50 0000 3f01 1dd8 c14e aec1
c14e ae22 0800 0601 703b 0000 7eaf 7239
9ad7 0b00 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
08:02:23.882594 < 0:0:0:0:0:0 0:0:0:0:0:1 ip 98: 193.78.174.34 > \
193.78.174.193: icmp: echo reply
4500 0054 a785 0000 fe01 35a2 c14e ae22
c14e aec1 0000 0e01 703b 0000 7eaf 7239
9ad7 0b00 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
08:02:24.860996 > 0:0:0:0:0:0 0:0:0:0:0:0 ip 98: 193.78.174.193 > \
193.78.174.34: icmp: echo request
4500 0054 7e56 0000 3f01 1dd2 c14e aec1
c14e ae22 0800 3f20 703b 0100 7faf 7239
5fb8 0b00 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
08:02:24.874011 < 0:0:0:0:0:0 0:0:0:0:0:1 ip 98: 193.78.174.34 > \
193.78.174.193: icmp: echo reply
4500 0054 a786 0000 fe01 35a1 c14e ae22
c14e aec1 0000 4720 703b 0100 7faf 7239
5fb8 0b00 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
As you can see from the data part of tcpdump (look at the echo-requests), the data is nicely incremented each byte. If you run tcpdump on eth1 (the wireless interface that carries the tunneled data), you will see this:
[root@gw /root]# ./tcpdump -i eth1 -lenx
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth1
08:03:29.856228 > 0:0:0:0:0:0 0:0:8f:48:84:5e arp 42: arp who-has \
192.168.1.1 tell 192.168.1.2 (0:0:8f:48:84:5e)
0001 0800 0604 0001 0000 8f48 845e c0a8
0102 0000 0000 0000 c0a8 0101
08:03:29.862493 < 0:0:8f:48:fd:f1 0:0:0:0:0:1 arp 64: arp reply \
192.168.1.1 is-at 0:0:8f:48:fd:f1 (0:0:8f:48:84:5e)
0001 0800 0604 0002 0000 8f48 fdf1 c0a8
0101 0000 8f48 845e c0a8 0102 b084 c14e
ae31 0000 0000 0000 c14e ae32 0000 f031
97a0
08:03:33.978459 > 0:0:0:0:0:0 0:0:8f:48:84:5e ip 140: \
192.168.1.2.socks > 192.168.1.1.vtun: udp 98
4500 007e 7f85 0000 4011 7796 c0a8 0102
c0a8 0101 0438 1388 006a b676 0060 5ec0
343d 6feb b64e 1c0f 5b14 66ab 2fb7 e783
9868 1773 fe8f a7bd 00d8 1e48 f246 f0fd
c6ce 1515 48c1 6a29 aefb 7faf d874 1c97
06fa 37f0 f7f2 300d b505 48f3 a9e3 8ec0
f671 1888 0ada 1f23 0f9d ca42 1ff1 6ad0
87ca 8283 75f4 71db 24bd cdcc d411
08:03:33.989318 < 0:0:8f:48:fd:f1 0:0:0:0:0:1 ip 144: \
192.168.1.1.vtun > 192.168.1.2.socks: udp 98
4500 007e 3ea4 0000 4011 b877 c0a8 0101
c0a8 0102 1388 0438 006a 9d96 0060 5ec0
343d 6feb b64e 4d95 f12c 4129 bc65 4ba1
132f 3e0e 6433 4703 be60 5beb d6c7 f0fd
c6ce 1515 48c1 6a29 aefb 7faf d874 1c97
06fa 37f0 f7f2 300d b505 48f3 a9e3 8ec0
f671 1888 0ada 1f23 0f9d ca42 1ff1 6ad0
87ca 8283 75f4 71db 24bd cdcc d411 fcc8
0918
08:03:34.973114 > 0:0:0:0:0:0 0:0:8f:48:84:5e ip 140: \
192.168.1.2.socks > 192.168.1.1.vtun: udp 98
4500 007e 7f89 0000 4011 7792 c0a8 0102
c0a8 0101 0438 1388 006a e34f 0060 5ec0
343d 6feb b64e 6ff7 f215 27ff 05f9 56a4
fd2f e44b 2297 c613 3ffe a08d eaaf 126e
1ae4 677d c2f4 aece 3bc6 5021 a826 1c97
06fa 37f0 f7f2 300d b505 48f3 a9e3 8ec0
f671 1888 0ada 1f23 0f9d ca42 1ff1 6ad0
87ca 8283 75f4 71db 24bd cdcc d411
All data will be gibberish, and you won't even recognize the ICMP protocol. You only see data between the IP addresses of the wireless interface. (The fact that one of them uses the socks port has nothing to do with the tunneling. The client daemon (which runs on 192.168.1.2) has used the first free port, which happened to be port 1080, the socks port. The VTun port is the service port of VTun when running in server mode.You now have a running encrypted tunnel. The last thing to know is how to configure the VTun daemon. Configuring vtund daemon For the tunnel to be established, you must run the daemon as a server on one machine and as a client on the other. The reason for this is mainly to have one daemon listening for connections from another one. If you would run vtund on a firewall, you would configure that daemon as a server. Clients who wish to make a connection run the daemon in client mode and make that connection when necessary. From the process listing, you can see whether the daemon runs in server [s] or client [c] mode:
ps ax 25677 ? S< 397:04 vtund[s]: wireless2 tun tun0 ps ax 7577 ? S< 261:28 vtund[c]: wireless2 tun tun1Both daemons use a configuration file; you can specify this file on the command line when starting the daemon. If not specified, it will look for the default /etc/vtund.conf. I have made a separate file for the client and server configuration. Thus, you can change the behavior of the daemon, simply by giving it a different configuration file. The file for the server looks like this (I changed the password for obvious reasons):
options {
port 5000; # Listen on this port.
# Path to various programs
ppp /usr/sbin/pppd;
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/ipchains;
}
# TUN config.
wireless2 {
pass SecretPassword; # Password
type tun; # IP tunnel
proto udp; # UDP protocol
comp lzo:9; # LZO compression level 9
encr yes; # Encryption
keepalive yes; # Keep connection alive
up {
# Connection is Up
ifconfig "%% 192.168.2.1 pointopoint 192.168.2.2 mtu 1450";
};
}
The general options apply to all configuration blocks in the file. You can have one server serve more than one client. Each client has its own configuration block, and the options part applies to all blocks.The port in the options block says on which port the daemon listens for new connections from clients. Once the connection is established, it will fork an active daemon that will communicate over that port with the connected client. The other items are locations of different programs used to configure interfaces and routing when a client connection is made. The wireless2 block is a block for a client that connects under the wireless2 name. It states the password (SecretPassword) that is also used by the client for authentication purposes. This password is never sent across the line, it is only used in a challenge-response mechanism. The “type” clause tells what kind of tunnel is established. Typically, you will use a “tun” type, since this is able to carry all types of IP traffic. You can also select “ether” to build an Ethernet tunnel (so you can use the tunnel as a kind of bridge), or “tty” to make a tunnel over a serial connection, or “pipe” to make a tunnel over a pipe. Typically, you would set this to “tun”. The “proto” clause tells vtund which protocol to use for communication to the other tunnel. Since UDP has the least overhead, you would usually choose “udp”. The vtund will make sure all data sent is also received. The “encr” and “comp” will tell vtund to encrypt and compress the traffic. You can unset these, but that will mean your tunnel is no longer secure. The “keepalive” clause will make sure the connection remains active if, for a longer period of time, you have no actual data traffic. The “up” clause will tell vtund what to do once the wireless2 client makes a connection to the daemon. You can specify all kinds of commands here, even IPchains statements to close down your firewall. The configuration file on the client side looks similar to the server:
options {
port 5000; # Connect to this port.
persist yes; # Persist mode
timeout 60; # General timeout
# Path to various programs
ppp /usr/sbin/pppd;
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/ipchains;
}
# TUN example. Host 'cobra'.
wireless2 {
pass SecretPassword; # Password
device tun1; # Device tun1
up {
# Connection is Up
# Assign IP addresses.
ifconfig "%% 192.168.2.2 pointopoint 192.168.2.1 mtu 1450";
};
}
You see that the password is included here as well; the other options are set by the serving daemon.Conclusion By using the VTun software, you can establish a tunnel over almost any network connection you have. And although it uses its own protocol for that, it is available in source and for a number of different platforms. Checking with tcpdump reveals that all tunneled traffic is not sent in the clear and protects from eavesdropping.
About the AuthorArthur Donkers graduated from the Delft University of Technology with a degree in Electrical Engineering and a major in Computer Architecture. Since then he has worked for a number of major software houses in the Netherlands. His primary field of interest is in datacommunications, especially the security aspects involved. He now is the founder and owner of Le Reseau, a company specializing in security-related issues for UNIX, OpenVMS and Windows NT, and the application of Linux in corporate environments. |