- In order to keep everything isolated, I created a new user/group (amvpn/amvpn) on mia and zidler. Instructions for creating users using command line options can be found here I have also set up passwordless login using SSHv2. PLease refer to this document for the HowTo.
- Amrita VPN is very easy to configure and install. It is basically a wrapper for sending packets over an SSL(Ver. 3.0) connection.
- Amrita VPN supports public key encryption using client & server certificates (SSLv3). It comes with a useful README(or HOWTO) file that explains everything in great detail (especially the method of generating certificates and keys etc.). I have used a bit different approach here (I haven't used amvpn-keytool) and hence this document will only supplement the given documentation.
- Download the necessary rpm's from http://sourceforge.net/projects/amvpn. I decided to go for the source rpm's and rebuild them for my system using the command rpmbuild --rebuild amvpn-version.src.rpm. This command will build the necessary rpm for your system, and u can install it using the command rpm -ivh /usr/src/redhat/RPMS/i386/amvpn-version.i386.rpm
- Assuming that you have a running installation, lets use the following setup with mia
as the client and zidler as the server .
- It is better to set up your own CA (Certificate Authority) that will grant and sign certificates. However this is not entirely necessary, and this step can be omitted. You might alternately use the amvpn-keytool. All further steps will assume the existence of a CA. Instructions to create your very own CA, that can sign and approve user requested certifcates can be found here. Make sure that you copy the CA's very own certificate to a known directory.I have kept all such certificates in $HOME/certificates.
- The amvpn user (amvpn) that creates a VPN must request a certificate and get it signed by the CA. PLease remember that the private key must not be protected by a password . Instructions for users to create such keys can be found in Step 8, 9, 10 of this document.
- When the user generates a request for the certificate he also generates a private key. At the client(mia) i have named this private key as $HOME/certificates/amvpn_mia_key.pem. When the CA signs the certificate and sends it bck to the user (amvpn_mia_cert.cert,say), place it in $HOME/certificates/amvpn_mia_cert.cert.
- Similarly repeat the same step for zidler (the server).
- I have used the following configuration files at the server/client.
amvpn@zidler:~> cat /home/amvpn/amvpn.conf #For more options take a look at /etc.amvpn.conf. tunnel-ip 192.168.254.201 #Ip-Address that we want to allocate to out side of the tunnel. #server-ip 131.193.50.184 #Required ONLY AT THE CLIENT.Comment out at SERVER route-ip 192.168.254.0 #Route to peer. route-mask 255.255.255.0 #Netamsk route-ip 192.168.0.0 #Route to remote Network (Private N/W behind Mia) route-mask 255.255.255.0 #Netmask run-as-user amvpn #Run as used amvpn private-key-file /home/amvpn/certificates/amvpn_zidler_key.pem #Location of Private key file. cert-file /home/amvpn/certificates/amvpn_zidler_cert.cert #Location of certificate file signed by CA. ca-cert-path /home/amvpn/certificates/cacert.cer #Location of CA certificate. #reconnect-delay 30 #reconnect delay in seconds - default 30 #reconnect-attempts 3 #reconnect attempts - default 3 -------------------------------------------------------------------------------------------- amvpn@mia:~> cat /home/amvpn/amvpn.conf #For more options take a look at /etc.amvpn.conf. tunnel-ip 192.168.254.200 server-ip 131.193.50.184 route-ip 192.168.254.0 route-mask 255.255.255.0 route-ip 192.168.2.0 route-mask 255.255.255.0 run-as-user amvpn private-key-file /home/amvpn/certificates/amvpn_mia_key.pem cert-file /home/amvpn/certificates/amvpn_mia_cert.cert ca-cert-path /home/amvpn/certificates/cacert.cer #reconnect delay in seconds - default 30 #reconnect-delay 30
- Start amvpn at the Server and then at the client using the following command:
amvpn@zidler:/home/amvpn# amvpn -c /home/amvpn/amvpn.conf -l verbose Amrita Virtual Private Network Software (AmritaVPN) v0.95 Amrita Innovative Technology Foundation Labs, Amrita Institutions, India. Configuration option: tunnel-if, not set. Using the default value: tun0. Configuration option: port, not set. Using the default value: 7171. Configuration option: proxy-port, not set. Using the default value: 3128 --SNIP-- ---------------------------------------------------------------------- [amvpn@mia amvpn]# amvpn -c /home/amvpn/amvpn.conf -l verbose Amrita Virtual Private Network Software (AmritaVPN) v0.95 --SNIP--
- After a couple of messages a tunnel will be established. Use ifconfig to see the tunnel device.
papers@mia:> ifconfig --SNIP-- tun0 Link encap:Point-to-Point Protocol inet addr:192.168.254.200 P-t-P:192.168.254.200 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)I don't know why it shows the same IP address for both "inet addr" and "P-t-P:". Need to check if this is correct. - Use netstat -rn and ping to verify that the routing is indeed set up properly.
- The tunnel can be discontinued by killing the amvpn process.
- NOW BEGINS THE EXPERIMENTATION
- The below diagram traces the path taken by a packet as it travels over the SSL3 tunnel created by Amrita VPN.
- Each layer of protocol adds some bytes of overhead. This is illustrated in the above diagram. Since Amrita VPN just acts like a wrapper program to send packets over an SSL connection, no overhead is introduced by the AmritaVPN program itself. However the underlying SSL layer, does add some headers (and trailers as discussed in SSL record Layer packet format document.
- I have put up a small ssl-timeline document about SSL handshake procedure, along with introduction to using ssldump, which is very useful to capture SSL sessions. This note gives the reader a gentle introduction to how SSL clients and server's actually negotiate.
- NOTE: The above diagram shows that the AmritaVPN layer produces two packets, a short packet of 29 bytes is generated with the normal packet of 152 bytes, for an input of length 128 bytes. I have found this behaviour even for other wrappers like Stunnel. However, at this point, I am not yet sure as to why the shorter packet is generated and what it contains.
- Amrita VPN does not provide mechanism to acheive compression. Also no option is provided which can allow a user to select a cipher suite. The cipher suite IN USE, can be only be found out by taking the SSLdump of the session.
- We conducted a series of experiments with random packet sizes and measured the packet length on the wire. The experimental results can be accessed here. From the results one can coonclude that Amrita VPN solution adds an average of 155 bytes of overhead to the data.
- AmritaVPN does not support any compression mechanisms.
- AmritaVPN uses the cryptographic functions provided by your SSL implementation. Hence, if one needs to add
his own plugin-algorithm, one has to look for plug-in support in the SSL implementation that he is using.
Currentlty, I am using OpenSSL implementation of SSL, which AFAIK does not yet support any plugin algorithms to be used. However there is always the option of patching the source code itself with new algorithms and recompilation.
- The PPP-over-SSL solution for forming VPN's is highly unscalable.( This might not be true)
- 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.