Project VOLANS: Setting up VPN using tinc

:: Setting up VPN using Tinc ::
HOME

Click Here for Comparison Chart for different VPN solutions

Recipe to set up VPN using Tinc

Tinc might compete to be the best solution for a VPN. I wanted a solution that will have inbuilt routing mechanism, and tinc is the only one, that fits it. The configuration and installion was a bit difficult, but it was a time well spent. It will be fun to explore more on the routing part of tinc.
Here I will try to describe two different ways to use tinc.
1. The conventional way of having a seperate subnet (I use 192.168.254.0/24 for most of my VPN's) for VPN server/client and adding appropriate routes to the routing table at both the client and server. I have been using this method for all my previous configuration.Apparently tinc does not require (and does not WANT) allocation of this seperate subnet. Of course you could have the tunnel endpoints on the same seperate subnet, but this requires some tricky route manipulation, to reach the other end. I have tried using this, but repeatedly failed. I will show how this can be done, once i suceed.
2. The second method is a better one. Here each end of the vpn tunnel belongs to the subnet that it is trying to reach (Hence you don't need a seperate subnet like above). Thus the two endpoints lie in different subnets. This leads to a very scalable solution. I will explain this method here.
Before starting, download the tarball and compile it. I had a problem using the latest version (1.08pre8) on ReHat 9.0. Hence I used the CVS version (branch CABAL). Instructions for checkingout the CVS version can be found here, repeated for tcsh below:
```
#>setenv CVSROOT :pserver:[email protected]:/home/CVS 
#>cvs login
#>cvs checkout -r CABAL tinc
```
After downloading I followed the normal ./configure;make; make install commands.
NOTE: Tinc will be installed in the directory relative to /usr/local
I am asssuming that we are using the following setup with mia as the client and zidler as the server .
The first thing that one needs to do is select a name for the VPN that you are going to form. In this example, I will use the name testVPN.
Assuming your base directory is /usr/local/etc/tinc, quickly make a directory testVPN in /usr/local/etc/tinc on all participating nodes (viz: mia and zidler). Use the following command:
```
# mkdir /usr/local/etc/tinc/testVPN
```

The next thing that you need to do is make a configuration file tinc.conf in /usr/local/etc/tinc/testVPN. This configuration file is a bit different on different nodes and is produced below (PLease read the comments in the file below:

shashank@zidler# cat /usr/local/etc/tinc/testVPN/tinc.conf 
# Tinc hostname. Required. Change appropriately at each host.
Name = zidler

# The internet host to connect with.
#ConnectTo = mia

Device = /dev/net/tun                 #Device name.. Leave as is.
Interface = vpn                       #Virtual Interface name. Give any suitable name. 
Mode = router                         #use Router mode

PrivateKeyFile = /usr/local/etc/tinc/testVPN/rsa_key.priv 
-------------------------------------------------------------------
[shashank@mia# cat /usr/local/etc/tinc/testVPN/tinc.conf 
Name = mia
ConnectTo = zidler

Device = /dev/net/tun
Interface = vpn
Mode = router
PrivateKeyFile = /usr/local/etc/tinc/testVPN/rsa_key.priv

NOTE: The only options that are different are Name and ConnectTo. The Name option specifies the name of the tinc host, while the ConnectTo option tells the tinc host which other tinc host to connect to. If the ConnectTo option is left commented, then the tinc daemon will act like a server, ONLY listening to incoming connections. Multiple ConnectTo options can be provided on seperate lines. For more information use the online manual.

Now make a directory /usr/local/etc/tinc/tincVPN/hosts on all participarting nodes to place the host configuration file, which is different than the tinc.conf mentioned above. For example use the command:
```
# mkdir /usr/local/etc/tinc/testVPN/hosts
```
The host configuration file must be given the same name as the Name option in tinc.conf.
However before delving into the host configuration file, we will first generate public/private keys on all participating nodes for ease. Use the following command:
```
# tincd -n testVPN -K
shashank@zidler# tincd -n testVPN -K
Generating 1024 bits keys:
.++++++ p
.......++++++ q
Done.
Please enter a file to save public RSA key to [/usr/local/etc/tinc/testVPN/hosts/zidler]: 
Please enter a file to save private RSA key to [/usr/local/etc/tinc/testVPN/rsa_key.priv]: 
```
NOTE: The key generation process, creates a partially filled host configuration file /usr/local/etc/tinc/testVPN/hosts/zidler (on zidler). This file contains the public key genrated by the key generation tool. This is why we follow this step first.

Now edit the freshly created host configuration file in the above step and add the following at the top:

shashank@zidler:/usr/local/etc/tinc/testVPN/hosts# cat zidler
Address = 131.193.50.184  #IP address of the tinc host.

#Cipher = blowfish        #Cipher to be used. (none for no cipher)
Cipher = none

#Compression = 9          #Compression level to be used. (0 for no compresion)
Compression = 0

#Digest = sha1            #HMAC to be used (none for no HMAC)
Digest = none

#IndirectData = no        
Subnet = 192.168.2.0/24   #Subnet that this host is connected to.
--SNIP--
-------------------------------------------------------------------------------
shashank@mia:/usr/local/etc/tinc/testVPN/hosts# cat mia
Address = 131.193.50.165

#Cipher = blowfish
Cipher = none

#Compression = 9
Compression = 0

#Digest = sha1
Digest = none

#IndirectData = no
Subnet = 192.168.0.0/24
--SNIP--

Now exchange the host configuration file of all all particpating nodes. Use the following commands for our two nodes:

shashank@zidler# scp /usr/local/etc/tinc/testVPN/hosts/zidler root@mia:/usr/local/etc/tinc/testVPN/hosts
--------------------------------------------------------------------------------------------------------
shashank@mia# scp /usr/local/etc/tinc/testVPN/hosts/mia root@zidler:/usr/local/etc/tinc/testVPN/hosts

Two scripts tinc-up and tinc-down also need to be placed in /usr/local/etc/tinc/testVPN/ directory of all participating hosts, which will be executed to manipulate the virtual interface during startup and shutdown of the tinc daemon. Both the scripts have been show below.

shashank@zidler:# cat /usr/local/etc/tinc/testVPN/tinc-up
#!/bin/sh

# Set hardware ethernet address, needed on Linux when in router mode
ifconfig $INTERFACE hw ether fe:fd:0:0:0:0

# Give it the right ip and netmask. Remember, the subnet of the
# tap device must be larger than that of the individual Subnets
# as defined in the host configuration file!
ifconfig $INTERFACE 192.168.2.2 netmask 255.255.255.0

# Disable ARP, needed on Linux when in router mode
ifconfig $INTERFACE -arp

#Add a route to the other network
route add -net 192.168.0.0 netmask 255.255.255.0 dev $INTERFACE

NOTE: DO not change the hardware address of the virtual interface. Let it remain to fe:fd:0:0:0:0. tinc refuses to work, if it is changed. Also the option -arp is required to be specified.

shashank@zidler:# cat /usr/local/etc/tinc/testVPN/tinc-down
#!/bin/sh
# This file closes down the tap device.
#Delete the route
route del -net 192.168.0.0 netmask 255.255.255.0 dev $INTERFACE

ifconfig $INTERFACE down

Similarly proceed on mia to create all the above with appropriate options. Below I have listed all such files on mia.

-------------------------------------------------------------------------------
shashank@mia# cat /usr/local/etc/tinc/testVPN/tinc-up
#!/bin/sh
ifconfig $INTERFACE hw ether fe:fd:0:0:0:0
ifconfig $INTERFACE 192.168.0.2 netmask 255.255.255.0
ifconfig $INTERFACE -arp

#Add a route to the other network
route add -net 192.168.2.0 netmask 255.255.255.0 dev $INTERFACE
-------------------------------------------------------------------------------
shashank@mia# cat /usr/local/etc/tinc/testVPN/tinc-down
#!/bin/sh
#Add a route to the other network
route add -net 192.168.2.0 netmask 255.255.255.0 dev $INTERFACE

ifconfig $INTERFACE down
[shashank@mia mia]#

Now start the tincd on both zidler and mia (no matter what is started first, but i prefer to start zidler).

shashank@zidler# tincd -n testVPN --debug=5 -D
-----------------------------------------------------------------------
shashank@mia# tincd -n testVPN --debug=5 -D

Use ifconfig to see the virtual interface:

shashank@zidler# ifconfig 
--SNIP--
vpn       Link encap:Ethernet  HWaddr FE:FD:00:00:00:00  
          inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:196 (196.0 b)  TX bytes:196 (196.0 b)
-----------------------------------------------------------------------
[shashank@mia mia]# ifconfig
--SNIP--
vpn       Link encap:Ethernet  HWaddr FE:FD:00:00:00:00  
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:196 (196.0 b)  TX bytes:196 (196.0 b)

Also check if the routes have been established properly using netstat -rn command and ping.
To kill tinc, just use killall tincd.
Now begins the experimentation.

Avg. overhead (No compression)
1. The below diagram traces the path taken by a packet as it travels over the tinc created data tunnel.
2. The TCP/IP/Ethernet layers adds known amount of header/trailer which are trivial to find out. Hence, I will not explain them here. I will concentrate only on overhead added by tincd.
3. NOTE: While calculating the overhead added by vtun, we had said that the TUN/TAP driver adds ZERO bytes of overhead. However in that case, the TUN/TAP driver was configured as a point-to-point device, while in this case, it is configured as an ethernet device and hence adds 14 bytes of overhead.
4. From the online manual (Technical Information) page, one can find out that tincd uses the following packet format.
```
4-byte            sequence number
n1-byte           payload; 
n2-byte           random padding; to make [sequence number + payload] a multiple of 
                  block_size used by the cipher. (min = 1 byte, max = BLK_SIZE bytes) 
MACLength-byte    MAC (message authentication code); e.g. SHA1 (20 Bytes), MD5 (16 Bytes). The MAC is 
                  limited in size by the MACLength parameter in a host configuration file. 
```
5. A suitable cipher and HMAC can be selected by specify the appropriate Cipher and Digest options in host configuration file. Let us assume that we are using the cipher bf-cbc (Blowfish-CBC mode) and the MAC sha1. Also we have disabled compression by seting the Compression option to 0.
6. Supose that the tincd gets a 142 Byte packet as the input. The following method enables one to find out how much overhead is added by tincd.
  1. Add sequence number (4) to input data size (142) to give 146 Bytes.
  2. Find out what block size is used by the cipher used. Since we are using blowfish, the block size is 8.
  3. Calculate 146 % 8 = 2. Hence in order to make the packet an even multiple of 8, you will have to add either 6 bytes (to make it 152). All the padding bytes are set to 0x06. Hence there is no need for the padding length.
  4. Now add the MAC. By defualt tincd adds the first MACLength bytes (=4, default). However this can be changed in the configuration file.
  5. Thus we have a total packet size of 156 Bytes, which agress with out experimental results.
  6. Thus we conclude that the tincd adds a minimum of (4(sequence number) + 1(padding) + 0(MACLength = 0) = 5 bytes) and maximum of (4(sequence number) + 8(padding) + 20(MACLenght = 20) = 32 bytes).
7. We conducted a series of experiments. The input data for this experiment was totally random. An example of such data is shown below:
```
seq_no: 0
Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3;                             
"Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/
U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4q                   
```
  This data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
8. Results for the experiment can be viewed here. Thus the total average overhead acumulated by using the tincd is 97 bytes (with no compression).
Avg. overhead (Full compression)
1. I enabled full compression by seting Compression option to 9 in all the host configuration files. Also we were using the cipher bf-cbc (Blowfish-CBC mode) and the MAC sha1 with MACLength set to 4 bytes.
2. The input data for this experiment was totally random. An example of such data is shown below:
```
seq_no: 0 
Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3;
"Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/
U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4q
```
  This data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
3. Results for the experiment can be viewed here. Thus the total average overhead acumulated by using the tincd is 39 bytes (with full compression).
4. Using compressionm, it is not possible to estimate the amount of overhead, as the amount of compression really depends on the entropy in the data. It is entirely possible for the data on the wire to be lesser in size to the input data. For e.g. when we used an input data of size 1200 bytes (each having a value "S"), we found that the packet size on the wire was just 130 Bytes.
Inbuilt support for Routing:
1. tinc is the probably the ONLY protocol that has inbuilt-support for routing. Hence there is no need to use the route commands after the link is up.
Using Algorithm Plug-in's
1. Tinc relies on the SSL implementation installted at your site. Hence the available number of ciphers is limited to those provided by the SSL implementation. We are using the openssl implementation of SSL, which has support for a wide vairety of cipher/MAC algorithms.
2. Proprietary algorithms can be used with tinc, if they can be somehow incorporated in to the OpenSSL implementation.
3. tinc support both zlib and lzo. Using propritary compression algorithms will require source code hacking.
Scalability of the solution
1. Highly Scalable.