OSNews

For many systems administrators, choosing and managing a VPN system is often quite a headache. Inflexible clients, servers, and protocols often prevent VPN's from being smoothly integrated into an already functioning network. The fact that many VPN clients are installed on users' home computers, well out of the reach of the systems administration team, often means that troubleshooting and upgrading VPN systems is time consuming and a struggle for both admins and users.

At the same time, the modern workplace continuously becomes more and more geographically dispersed. The "work from anywhere" idea continues to worm its way into the minds of more and more employees and managers. The forty hour work week, to many folks, sounds more and more like a pleasant vacation. Leaving "work at the office" is something more likely to be heard in a television drama from by-gone years than it is to be uttered in the modern workplace. VPN systems are a large part of what enables such "work anywhere, anytime" philosophies to come to life, and for many businesses, operating without a VPN evokes memories of office life in the days of mimeograph hegemony.

Like many computer users and systems administrators, I had used a variety of VPN solutions over the years. Time and time again, I had been let down by various VPN solutions both commercial and free. Last year, however, I finally found a VPN solution that was easy to use, administer, and debug, as well as fast, flexible, and free. The client and server both run on numerous platforms, including (but not limited to) FreeBSD, Linux, MacOS X, and Windows. OpenVPN was simply a delight to use and administer.

Installing OpenVPN on Windows, Linux, and *BSD

One of the biggest selling points to OpenVPN is its multi-platform support. The OpenVPN web site offers a self-installing .exe file for Windows users, and source code for everyone else.

Windows users simply fire up the installer, click a few buttons, restart their system, and they're done.

Linux and *BSD users have a few more steps to follow, but even novice users should have no problem getting the software installed. OpenSSL is not technically required to get OpenVPN working, but if you plan on encrypting your traffic in any sort of meaningful way, plan on having OpenSSL installed somewhere on your system. However, since most modern operating systems ship with OpenSSL these days, getting OpenSSL installed is a no-op for most folks.

You'll also need the LZO real-time compression library installed on your system. If your system already has LZO installed, you can jump right in to the deep end and compile OpenVPN. If you need to compile and install LZO, the usual "./configure; make; make install" tango seems to work well for most folks.

Once you have OpenSSL and LZO compiled and installed on your system, you're read to take a crack at the OpenVPN source code with your development tool chain. Again, the "./configure; make; make install" shimmy, shimmy, shake will compile and install OpenVPN without much hassle.

Once the software is installed on both the client and server systems, the next hurdle to be jumped is writing the configuration file. There are examples on the OpenVPN web site that will get most everyone 90% of the way to a functioning OpenVPN client-server system with just a copy-and-paste.

Choosing Between Certificates and (Hopefully) Secret Keys

There are two options available to control user authentication against the OpenVPN server processes.

The first is simply to generate a key file using the command "openvpn --genkey --secret ". This will generate a key that must then be distributed to both the client and the server processes. While this is easy, it also has a large inherent security problem. If the key is compromised, the attacker can decrypt all the past, present, and future traffic encrypted with the now compromised key. Beyond the obvious exposure of information that should be secret, key theft could expose both the client and the server to man-in-the-middle attacks. Another downside to using this method is that, because of the limited information present in the authentication credentials supplied by the client, many of enhanced user authentication controls are simply not available to the server.

Using a certificate authority (CA) of some kind to generate certificates is the second method available to control user authentication. This method is more complicated to setup and manage than using secret keys, but ultimately more flexible. The HOWTO documentation on the OpenVPN website offers step-by-step instructions on how to create and use a private, self-signed CA. If you find yourself deploying a number of OpenVPN clients (say, more than fifteen) using shell scripts to manage the CA-generated files will make your life easier.

Why should you use a CA and certificates, instead of secret keys? The first reason is that a certificate can be revoked by a CA. The OpenVPN server processes can then check a certificate revocation list (CRL) when presented with a user's certificate. If the certificate is on the list, the client is denied access. Also, through the use of external scripts, information within the user certificate itself can be checked again to ensure that the user trying to connect to a particular daemon is who they say they are. Finally, the keys used to encrypt the connection between the client and the server are rotated periodically when using certificates. This means that if someone were to obtain a certificate, they could not decrypt past or future traffic. They could only decrypt traffic between client and server until the keys were again rotated (which is done hourly).

1. "Intro to OpenVPN, Page 1"
2. "Intro to OpenVPN, Page 2"