:: Comparison Chart of different VPN solutions ::
HOME

Click Here for Comparison Chart for different VPN solutions


Comparison Chart of Different VPN solutions


PPP over SSH PPP over SSL(Stunnel) Ipsec Cipe PPTP vTun vTun + PPP openvpn Amrita VPN VPN daemon Tinc Htun LinVPN Yavipin l2tpd
Source Code (HTML) - - - X X, Y X X X X X X X X X X
Recipes for creating VPN's X X X X X X X X X X X X X X X
Popularity (Court. freshmeat.net, How Popularity is Calculated?) - - 0.23% 2.71% 3.71% 2.68% 2.68% 6.86% 1.55% 1.92% 2.26% 1.85% 1.9% 0.58% 0.4%
How Tunneling is Acheived? PPP + Pseudo Terminal (PTY). PPP + Pseudo Terminal (PTY). .. <--> IP <--> ipsec <--> Slave PTY <--> Master Pty <--> IP (modified IP stack) <--> .. cipecb PPP + Pseudo Terminal (PTY). Universal Tun/Tap driver. PPP + Pseudo Terminal (PTY). Universal Tun/Tap driver. Universal Tun/Tap driver. SLIP + Pseudo Terminal (PTY). Universal Tun/Tap driver. Universal Tun/Tap driver. PPP + Pseudo Terminal (PTY). Universal Tun/Tap driver. PPP + Pseudo Terminal (PTY).
Security Protocol Suite Used SSH (v.2) SSL (v.3) IPsec Proprietary MS CHAP + MPPE (Proprietary) Proprietary Proprietary SSL SSL (v.3) Proprietary Proprietary None SSL Proprietary None
PPP over SSH PPP over SSL(Stunnel) Ipsec Cipe PPTP vTun vTun + PPP openvpn Amrita VPN VPN daemon Tinc Htun LinVPN Yavipin l2tpd
Authentication Method RSA, password + X.509 Certificates + RSA, Shared Secret + Shared secret + MS Chap v2 Secret password Secret password Shared Secret, X.509 Certificates + X.509 certifcates Shared Secret RSA UserName, Password X.509 Certificates Password CHAP +
Cipher (to provide confidentiality) Blowfish-cbc + 3DES-cbc + Cannot specify blowfish + MPPE (Microsoft Proprietary) blowfish blowfish blowfish + Cannot Specify blowfish (Prop. Impl.) blowfish NONE Cannot Specify BF-SBC, DES-CBC(default) NONE
HMAC (to provide data-integrity) md5 + sha + Cannot Specify NONE NONE NONE NONE md5 + Cannot Specify MD5 + Sha NONE Cannot Specify MD5-96 NONE
Compression none, gzip NA Available NONE NONE zlib, lzo zlib, lzo lzo NONE Available, but buggy. zlib, lzo NONE NONE zlib NONE
Compression Level (default value) 6 NA NA NA NA zlib:1 zlib:1 NA NA NA 0:No-Comp, 1-9: zlib, 10-11 lzo NA NA NA NONE
PPP over SSH PPP over SSL(Stunnel) Ipsec Cipe PPTP vTun vTun + PPP openvpn Amrita VPN VPN daemon Tinc Htun LinVPN Yavipin l2tpd
Support for QoS negotiations.
Inbuilt recovery mechanism
Recovery during peer crashes
Recovery during Physical link Failures
Overhead/packet assuming No compression (Bytes) 150 (X) 180 (X) 98 (X) 87 (X) 78, 82 (X) 101 (X) 115 (X) 111 (X) 155 (X) 120 (X) 97 (X) 261 (X) 125 (X) 97 (X) 80 (X)
Avg. Overhead/packet assuming full compression (Bytes) 70 (X) 65 (X) 38 (X) 87 (X) -17.5, 79 (X) 9B (X) 17 (X 111 (X) (NA) 120 (X) 39 (X) 261 (X) 27 (X) 36 (X) -15 (X)
PPP over SSH PPP over SSL(Stunnel) Ipsec Cipe PPTP vTun vTun + PPP openvpn Amrita VPN VPN daemon Tinc Htun LinVPN Yavipin l2tpd
TCP Bandwith (Mbps) 6.87 6.83 6.71 6.97 6.95 6.76 7.19 6.02 6.04 6.32 3.6 3.57 6.87 6.15 8.825
RTT(ms) 4.6 2.26 1.08 9.6 1.12 0.93 1.306 2.124 1.9 8.12 1.98 77.32 0.55 4.38 0.61
Jitter(ms) 0.219 0.084 0.29 2.55 0.75 0.44 0.34 0.11 0.49 3.42 1.14 14/92 0.01 0.193 0.016
Inbuilt Support for Routing (Y/N) N N N N N N N N N N Y N N N X
Tunneling Technique Used IP-in-IP IP-in-IP IP-in-IP IP-in-IP IP-in-IP IP-in-IP IP-in-IP IP-in-IP IP-in-IP IP-in-IP IP-in-HTTP IP-in-IP IP-in-IP IP-in-IP IP-in-IP
PPP over SSH PPP over SSL(Stunnel) Ipsec Cipe PPTP vTun vTun + PPP openvpn Amrita VPN VPN daemon Tinc Htun LinVPN Yavipin l2tpd
Cipher algorithms plug-ins? X X - X X X X X X X X N/A X X N/A
Message Digest Algorithms plugins? X X - X X X X X X X X N/A X X N/A
Compression algorithms plugins? X X - X X X X X X X X N/A X X N/A
Scalability Highly unscalable (X) Highly unscalable (X) - ? ? X X X (X) (X) (X) (X) (X) (?) (?)
OpenSource (Y/N) Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
PPP over SSH PPP over SSL(Stunnel) Ipsec Cipe PPTP vTun vTun + PPP openvpn Amrita VPN VPN daemon Tinc Htun LinVPN Yavipin l2tpd
Internet Standard (Y/N) Y N Y N Y N N N N N N N N N Y
Linked back to my Site - - - - X - - X X - - X - - -
# of tunnels that need to be manually set up between N nodes. N(N-1)/2 N(N-1)/2 N(N-1)/2 Simplest is start network, with poptop server at the center node, and pptp client on the leaves. Hence (N-1) tunnels will need to be configured. Somehow the center node will have to be maintain routing table to route to all other nodes. Simplest is star network. Simplest is Star network N(N-1)/2 N(N-1)/2 N(N-1)/2 Best

Click Here for Comparison Chart for different VPN solutions

Recipes for creating VPN's: These describe elementary steps to create VPN's using the respective method on RedHat linux.

Cipher Algorithms (or Message Digest or Compression Algos.) plugins: Some companies may prefer to have their proprietary cipher, message digest or compression algorithm for use in their VPN's. How easy (or difficult) will it be to add such algorithm plugins into the VPN solution?

How did I measure bandwidth, RTT and Jitter: In order to measure BW, RTT and Jitter, I made use of common tools like iperf and ping. I developed the client.pl and server.pl scripts to execute these tests in batch mode. Please modify these scripts for proper use. [Actual Results]

How Tunneling is Acheived?: Understanding this question is perhaps ths key to understandinging the basic working of a VPN. In order to encapsulate an IP packet in another IP packet, there should be some way in which we can get hold of the IP packet that is sent by an application down the IP protocol stack. Once this is achieved, we can do any number of manuipulations to this IP packet (like encryption, compression, etc.) before sending it again down the IP protocol stack to another destination. In the current Linux VPN solutions this is mainly achived using the following method(s):
  1. PPP(or SLIP ) + Pseudo-Terminal (PTY): In this method, we have to manipulate the routing tables such that the application sends IP packets through a PPP (or SLIP) interface. The PPP program can then use a Pseudo Terminal (PTY) instead of an actual serial line. The Pseudo-Terminal has two parts: a master (/dev/ptys*) and a corresponding slave (/dev/ttys*). Anything written to the master appears at the slave and vice-versa. PPP communicates with the master in the normal way it communicates with any serial device. However, we, as an application, have to use appropriate functions to communicate with the slave PTY and get hold of PPP frames for further processing. (I don't know the correct functions to use to communicate with Slave PTY, at this time)
  2. Using special Device Driver's: Special device drivers like Universal Tun/Tap driver are now available. They eliminate the use of PTY's altogether. We still need to manipulate the routing tables, such that the application sends IP packtes through this device (tun0, say). The speciality of such drivers is that they are designed similar to ethernet drivers. Hence IP layer can transparently write packets to these drivers, in the same way it would write packets to ethernet drivers. However the difference here is that we, as an application, can set these drivers to deliver such packets to us. Thus any packet sent to this device gets delivered to us, and any packet sent by us to these drivers gets deliverd to the IP layer, thus simulating a packet arrival. Other similar drivers are ciped which works on similar principals. (I don't know how to use Tun/Tap driver, at this time. But, I think, it should be simple to use.)











Comments and corrections are appreciated and can be sent to papers@mia.ece.uic.edu. Click here for ©opyright information.