Choosing a VPN-Type Program for Mathnet

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

1. 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.
   
2. 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.
   
3. 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.
   
4. 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.
   
5. 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 href="http://sites.inka.de/sites/bigred/devel/tcp-tcp.html">this link
   for more.
   
6. 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.
   
7. 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.
   
8. 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.

--
map{ map{tr|10|# |;print} split//,sprintf"%.8b\n",$_}
unpack'C*',unpack'u*',"5`#8<3'X`'#8^-@`<-CPP`#8V/C8`"