Choosing a VPN-Type Program for Mathnet

James F. Carter, UCLA-Mathnet, 2003-09-26

Requirements

Users can connect from arbitrary off-campus locations to a VPN terminus (machine) in our DMZ. Presently, Harlech is the designated bastion host. We do not want to give users shell acounts on Harlech. (Direct connection to internal machines will be by ssh only.)
VPN connection should be allowed only for "authorized" people, which basically means anyone who has a valid Mathnet loginID.
Internal machines should provide services to VPN users beyond what they provide to the global internet (they're totally blocked), but maybe less than they provide to an actual internal machine. This is mainly a function of internal firewall rules.
VPN users should be able to route to off-campus sites and get NAT (network address translation) at the VPN terminus, so the connection appears to originate from a UCLA-Mathnet machine. This is for web access to licensed content protected by host-based authentication. (Example: AMS online journals.) Again, this is a function of firewall rules and routing.
The VPN connection should be encrypted.
Administratively, we aren't going to configure a tunnel individually for each user; it has to work on a generic basis.
There have to be clients for Linux, Windows, and preferably Mac. They have to work through NAT boxes.
Pre-assigned IP addresses are not feasible; the software must ensure that each tunnel has a unique remote IP address. Machines behind NAT boxes are typically assigned 192.168.1.1 or 192.168.1.100, depending on the brand of NAT box, and so the public IP of the client is likely to be non-unique; thus the tunnel's IP has to come from the VPN software, not be chosen by the client.
Most VPN products are intended for static routes between disjoint subnets, e.g. company sites in various cities. For our use the remote IPs are not predictable and the tunnels come and go randomly -- the "road warrior" scenario.

Candidate VPN Programs

Issue	FreeS/WAN	vtun	cipe	OpenVPN	PoPToP
Protocol	IPSec (ESP, AH)	Its own	Its own	TLS + its own	PPTP (GRE)
Encryption	Excellent	Weak (3)	Weak (3)	Excellent	See (7)
Authorization	X.509 (4)	SSH kludge	Static keys	X.509	Windows
(Pre-arranged keys also work for most programs)
Ad-hoc users	Yes	Kludge (1)	No	Yes (8)	Yes
Resists IP collisions	No	Kludge (1)	No	Yes (8)	Yes
Clients for:	L,W,M (2)	L,S	L,W	L,S,W,M-x	L,S,W (6)
(L=Linux, S=Solaris, W=Windows, M=Mac)
Works through NAT	Patch (4)	Yes	Yes	Yes	Yes
We used how long?	1 year	0.5 year	None	0.1 year	None
Blocked by BOL	Works	Works (ssh)	Prob. blocked	Asked for unblock	Probably works
Included with SuSE	Yes	Yes	Yes	Yes (8)	No
Links	Regular, Super	vtun	cipe	openvpn	poptop
Good features	Has been reliable	Reliable (with 1 user)	Net buzz	Rock solid, easy setup	Microsoft uses it
Bad features	Hard to set up. Diarrhea of the log files.	Requires kludge script. TCP meltdown (5). Shell accounts on bastion host.	No ad-hoc mode	None (8)	Microsoft uses it

For vtun, each user must be preassigned an IP address for the tunnel. A script has been written to dynamically assign these addresses when the connnection begins. But it's a kludge.
Any IPSec implementation should be able to talk to FreeS/WAN, and successful interoperation testing is extensive. It is said that Windows XP can do this natively. A kernel module is required, and I don't know if one is available for Solaris or Mac OS-X, nor whether it works with non-UNIX MAC OS's. There is a commercial IPSec client for Mac OS-X: VPN Tracker by Equinux.
Vtun uses a crypto algorithm (Blowfish) from the SSL library, but does not use the full-blown SSL to encrypt its channel. There has recently been discussion on the vtun mailing list about a weakness in how the initialization vector is chosen. (A similar problem led to the exploit against 802.11b WEP.) The same criticism is said to apply to cipe.
FreeS/WAN development is divided into two branches: "pure" FreeS/WAN (for which political goals are significant that require code that may be subject to USA export restrictions to be avoided), and "super" FreeS/WAN, which has patches for (among other things) X.509 key exchange and authentication, and NAT traversal. The NAT patch is present in SuSE Linux 8.2 but unfortunately there is a technical disagreement in the kernel community so that SuSE judges it imprudent to put the needed ESP-in-UDP patch in the stock kernel. You have to recompile the kernel yourself if you want it.
When tunnelling TCP in TCP, as with tunnelling vtun (or anything else) over a ssh forwarded port, when the load is high enough to make packets die in collisions, both TCP layers will retry, and the result will be a runaway overload, referred to as TCP meltdown. Special care is needed to resist this, which ssh is not designed for. Presumably kernel-level IP-in-IP tunnels can do better. See this link for more.
While PoPToP is for UNIX, Windows (95 and later) includes a native PPTP client, with which PoPToP interoperates. The HOWTO mentions a Mac client but you have to purchase it.
See this link for criticisms of security in Microsoft's implementation of PPTP. The issue is not weak encryption but weak authentication. Microsoft has put out a new, improved authentication protocol, which PoPToP interoperates with.
OpenVPN version 2.0beta$N has recently been released; we've installed N=5. In this version the server has a pool of IP addresses which it pushes to the clients. The client's local IP address is not used. The protocol is immune to NAT. The 1.x version requires each tunnel to be prearranged using the client's IP address. SuSE 9.1 includes OpenVPN-1.6, so we're distributing our own RPM of 2.0.

Additional Discussion

FreeS/WAN: IPSec is divided into the kernel support for AH and ESP protocols (with associated tunneling code), and the key (ISAKMP) daemon. The FreeS/WAN distribution provides the kernel modules and hacks. SuSE 8.2 (kernel 2.4.20) includes these (except see above about ESP-in-UDP). IPSec is now mainstream in the kernel as of 2.5. The ISAKMP daemon for FreeS/WAN is called "Pluto". People say that a competitor "Racoon" (sic) is just as good and is easier to set up. The FreeS/WAN developers would disagree.
vtun: While vtun has a number of users and partisans on its mailing list, its developer is in finished mode, and response to the security criticism mentioned above has not been swift. For us, the biggest problem with vtun is the likelihood of remote IP collisions, which it cannot handle natively. It was intended for use with prearranged connections.
cipe: It is often mentioned as being similar to vtun but better or more suited to real sysadmins. It is generally described in the context of prearranged connections.
OpenVPN: It is often mentioned in the context of you really ought to take a look at OpenVPN. They're right, we should, and will. It uses OpenSSL for TLS crypto on the control channel, a block-encrypted main channel via UDP, and TUN/TAP for tunnelling (mainstream in the kernel, originally written for vtun). No other kernel support is required. Performance quote: Pentium-2 266 MHz, TLS/Blowfish/SHA1, large precompressed files, data rate was 1.455 Mby/sec. It can do chroot, and/or not run as root, and can lock key info in memory. Version 1.x is intended for static point-to-point tunnels, and hence is designed so it has to be individually configured for each user. Version 2.0 includes the road warrior multi-user configuration that we need.
PoPToP: PPTP was developed by Microsoft and is present natively in Windows since Win98 (patches available for Win95). It apparently is in use by a lot of people. If more than one PPTP session have to traverse the same NAT box (not a common scenario), it needs special handling; Linux iptables includes a PPTP helper module. Microsoft provides their employees with a PPTP client which does more than the native one; it can use a smart card for authentication, and refuses to connect unless the machine is up to date on patches.

Conclusions

FreeS/WAN (Super): Super FreeS/WAN has a number of very positive features: Crypto is believable; a single configuration stanza can be used on the server for all user tunnels; the security association is automatically re-established if a laptop is suspended and reawakened; endpoint authentication is both effective and flexible. Recently Harlech's kernel was recompiled with the NAT traversal patch. And, supposedly it interoperates with Win2K and WinXP natively. A web interface to produce the X.509 certificates is (still...) in beta test. The only remaining flies in the ointment are, in the default configuration the remote host uses its public IP address (192.168.1.100) on the remote connection. The research was done to learn how to configure WinXP for IPSec, and it actually worked, but the procedure is so horrendous that it's not credible to expect a user to do it. For over a year Mathnet used FreeS/WAN exclusively as our VPN solution. But for the present, see the discussion of OpenVPN below.
vtun: Native vtun requires individual configuration of each client's tunnel. A script has been created to kludge up dynamic address assignment. While my experience with vtun is good, I'm afraid that it isn't robust enough for us to deploy in production.
cipe: Since it requires individual configuration of each client's tunnel, cipe has to be rejected.
OpenVPN: We were discouraged by version 1.x because each tunnel had to be configured individually, but we have found that v2.0beta5 is easy to set up for both generic clients and our server, and is totally reliable. The Windows client in particular is excellent. Mathnet has settled on OpenVPN as the VPN client that we will support with our users.
PoPToP: PoPToP appears to give solid cryptography and it used to be the only solution that can natively avoid IP address collision of the remote clients. (OpenVPN's new version also can do this.) However, authentication is done via PPP, specifically authenticating to a Windows domain controller (which Mathnet does have). Extensive auxiliary scripts are needed at the server end to make the connection work, e.g. filling in the ARP table manually. Thus, PoPToP unfortunately has to be rejected.