Project VOLANS: Setting up VPN using Htun

:: Setting up VPN using Htun ::
HOME

Click Here for Comparison Chart for different VPN solutions

Recipe to set up VPN using Htun

Htun: HTun creates a VPN using HTTP-type request/response messages, sent through a web-proxy server. In order to understand basic HTTP/1.1 or HTTP/1.0 messages, I reffered to the book: HTTP Essentials: Protocols for Secure, Scaleable Web Sites, by Stephen A. Thomas.
The technical details for the HTun protocol can be obtained by reading the HTun: Providing IP Service Over an HTTP Proxy paper by the author of this VPN solution.
Htun requires the following things to be present. They are:
1. Tun/Tap driver: RedHat 8.0/9.0 kernels comes with support for Tun/Tap driver. Hence you don't need to do anything to enable kernel level support for it. If you do need to rebuild the kernel, take a look at the instructions mentioned here.
2. Proxy Server: Make sure that you have the proxy server up and running. I am using squid, which comes bundled with RH 9.0. I just had to add some commands to the access control list (ACL) in the squid configuration file (/etc/squid/squid.conf) to provide access to my network. Since i intend to configure squid on the machine spiff, I guess I will have to add the following lines to the ACCESS CONTROL section of /etc/squid/squid.conf, to allow access to certain machines. You may need to modify some rules for your environment.
```
--SNIP--
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
acl htun_ports port 8888 8889      #my Htund server listens on these ports.
http_access allow htun_ports

acl our_networks src 131.193.50.0/255.255.255.0 192.168.3.0/255.255.255.0
http_access allow our_networks
--SNIP--
```
  NOTE: You may have to restart squid, if htun does not seem to work. Use the following command for restarting:
```
#service squid restart
```

Now download the tarball and compile it using the instructions:

#>tar -xvzf htun-version.tar.gz
#>cd htun-version/src
#>make debug     (This will allow logging debug messages.. )
#>cp htund /usr/local/bin
#>cp ../doc/htund.conf /etc

I am asssuming that we are using the following setup with mia as the client, zidler as the server and spiff as the proxy server .

Configuration files are set up differently on the client and the server. They are illustrated below. All the parameters are almost self-explanatory. If in question refer to the README.

shashank@zidler:# cat /etc/htund.conf
options {
    daemonize no                    
    logfile /var/log/htund.log      
    tunfile /dev/net/tun
    debug yes
}               

server {
    iprange 192.168.254.0/24
    server_port 8888                     #both server_port and secondary_port must be specified.
    secondary_port 8889                  #Make sure u have given access to these ports in squid.
    max_clients 10
    redirect_host mia.ece.uic.edu
    redirect_port 80
    max_pending 40
    idle_disconnect 1800
    clidata_timeout 20
    min_nack_delay 150
    packet_count_threshold 10
    packet_max_interval 10
    max_response_delay 200
}
--------------------------------------------
shashank@mia:#> cat /etc/htund.conf
options {
    daemonize no
    logfile /var/log/htund.log
    tunfile /dev/net/tun
    debug yes
}               

client {
    do_routing no
    protocol 2
    proxy_ip 131.193.50.187          #Ip address of spiff
    proxy_port 3128                  #Default port for squid

# Only uncomment proxy_user and proxy_pass if you need to authenticate with
# the proxy. Having them set unnecessarily creates extra HTTP overhead.
#   proxy_user joeblow
#   proxy_pass SuperSecret123

    server_ip 131.193.50.184
    server_port 8888
    secondary_server_port 8889

    if_name eth0
    iprange 192.168.254.0/24

    connect_tries 2
    reconnect_tries 4
    reconnect_sleep_sec 30
    channel_2_idle_allow 30
    min_poll_interval_msec 200
    max_poll_interval 30
    poll_backoff_rate 3
    ack_wait 10
}

Start the server(first) and client(second) using the command:
```
#>htund -d
```

Check if the tunnel interface has come up.

[shashank@mia shashank]# ifconfig
--SNIP--
tun0      Link encap:Point-to-Point Protocol  
          inet addr:192.168.254.1  P-t-P:192.168.254.0  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:504 (504.0 b)  TX bytes:504 (504.0 b)

You will have to manually add routes to reach the other lan. For example, on zidler I use the command

shashank@zidler:# route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.254.1

Similarly on mia, I will use the command:

shashank@mia:# route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.254.0

Also check if the routes have been established properly using netstat -rn command and ping.
To kill htund, just use ps -A | grep htund, look at the process number and kill -9 processNumber.

Avg. overhead (No compression)
1. The below diagram traces the path taken by a packet as it travels over the HTTP tunnel created by Htun. We just concentrate up to the point where it is sent to the proxy server.
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 the overhead added by the Tun/Tap driver and the htun layer.
3. The TUN/TAP driver adds 4 Bytes (Flags(2) + Network protocol Type(2)). Will need to confirm this asumption.
4. The Htun daemon, wraps the packet with HTTP/1.0 headers and sends it to the proxy server. The HTTP/1.0 headers contain a large number of options, hence we did not try to get an exact detail of the header format.
  One thing that we noted however, was that the Htun daemon sends the HTTP/1.0 header and Content as seperate TCP messages, as show in the above figure. This largely increases the message size overhead.
5. No encryption/compression/MAC is currently used by Htun. Hence data is currently sent in the clear. I think that the author had meant to use the tunneling capability of the proxy server. However to use this, the Htun server will need to be upgraded to understand SSL3/TLS prtocol (or whatever security protocol that the proxy uses).
6. We conducted a series of experiments to calculate the overhead. The results can be accessed here. From our experiments we concluded that tunnels established by Htun, require an overhead of 261 Bytes.
7. The input data for this experiment was totally random, using ASCII values from decimal 32 to 125. 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.
Avg. overhead (Full compression)
1. Htund does not support any compression mechansim. Hence overhead with Full Compression is the same as overhead without compression, viz: 261 Bytes.
Inbuilt support for Routing:
1. Htund does not support any routing mechanism. The do_routing option should not be mistaken as support for routing. It merely manipulates your routing table to set the default gateway to the htun server. As a result all your packets will be automatically sent to the Htun server.
2. Thus the user has to take care of establishing routes to remote networks. This can be done in the following two ways:
  - Static routes can be set up, as we have done using the command:
```
route add -net network/netmask gw gateway-ip 
```
    Although this method is simple for small networks, it becomes exceedingly difficult to maintain such routes one your network reaches a decent size (> 5 nodes, say). Hence one should avoid using this method, unless you have a very small network.
  - Another way is to use a routing software that will set up/tear down the routes automatically. One such software to consider is Gnu Zebra with one of its components: OSPF. At the time of this writing, I could not find much documentation on how to configure zebra, and since I was not working with any complex network architectures, I preferred to use the first method. However, I do plan to include the steps to set up zebra in future.
Using Algorithm Plug-in's
1. The current version does not support encryption/compression/MAC. Hence there is no question of having algorithm plug-in's.
Scalability of the solution
1. The vpnd solution for forming VPN's is highly unscalable.
2. For e.g. If a company has 'N' different sites, then it would be necessary to have O(N^2) point-to-point PPP-over-SSH links and each site will have to maintain an entry in the routing table for (N-1) other sites. I think a full mesh will be necessary in this case, as the complexity of maintaining any other network infrastructure will be prohibitively high.