Introduction to OpenVPN

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

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

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).

Understanding Routing

OpenVPN, rather than glomming on to an existing network interface, uses
tunnel and TAP devices to route traffic to the remote server/client. This
means that understanding how computers route traffic is important when
creating an OpenVPN system. It also means that OpenVPN plays nicely with
almost any other network device on your system. Many Windows systems suffer
when a traditional VPN client is installed on them. The usual VPN client
worms its way into existing network devices where it ends up inevitably
causing problems. Since OpenVPN does not mess with any existing devices or
device drivers, it is very Windows-friendly.

The OpenVPN daemon simply waits for a packet to be routed on to its
interface (tunnel or TAP) by the system routing table. Any packets routed
to the OpenVPN interface, are then encrypted, and sent across the Internet
to the server. The server process then unpacks the packet, and sends it out
the OpenVPN interface into the server system. The server then checks its
routing tables to figure out where to send the now decrypted packet. This
routing of packets, rather than wrapping an existing network interface, is
easy to debug and understand if something were to actually go wrong.

One of Everything on the Server Side

OpenVPN does require one server process per user account on the server side.
This is because an OpenVPN process binds itself to a (configurable) port and
then services whichever client properly authenticates to it first. So, if
you are servicing fifty remote users, you will need fifty OpenVPN daemon
processes on the server side. Generally, this isn’t a problem as shell
scripts can be easily written to start and stop the VPN daemons without any
real hassle.

Each daemon process also requires a dedicated network port on the server.
So, if you use a firewall to protect your VPN server (a good idea), you’ll
have to poke a hole in the firewall for each daemon process. This can be
something of a hassle, but if that is the biggest hassle associated with
your VPN system, you’ll most likely gladly suffer it.

Ideas to Make Your Implementation Easier

When it comes to troubleshooting problems with a VPN connection, OpenVPN
offers plenty of detail to both admins and users. The amount of detail
dumped into the log file is configurable. However, even the default logging
level can produce seemingly excessive logging on the server side, so I
recommend dumping all OpenVPN logs into a dedicated log file. To do this,
you’ll probably need to edit /etc/syslog.conf if you run the server
processes on a Linux or *BSD system. If you don’t separate out the OpenVPN
log traffic, your general syslog file (/var/log/messages, in most cases)
will quickly be overrun by OpenVPN log messages with just a few OpenVPN
server processes running. Ramp that number up into the tens or hundreds of
processes, and signal will quickly get lost in the noise.

To enhance security, the OpenVPN server and client processes can also be run
as a generally non-privileged user. I recommend creating an openvpn
username and group on the server and client and telling the server and
client process to change user and group IDs while starting up. On a
properly configured server (and client), this prevents any remotely
exploitable holes that might be discovered in the OpenVPN daemon from
exposing vast numbers of files or processes to an attacker.

OpenVPN traffic crosses the Internet in UDP packets. This means that the
home router/firewall/WAP combos that many people have at home do not need
some sort of blackbox “Gee, I hope it works”, IPSEC pass-through feature to
pass UDP traffic. Also, ISP’s that try to force users into buying so-called
business-class service to use a VPN client may be bypassed by OpenVPN
client/server combinations.

If you decide to switch to OpenVPN, Windows users will appreciate it if you
create some simple batch files for them to start and stop the software.
One-line batch files containing directives like “net start openvpnservice”
and “net stop openvpnservice” will do the job nicely. This means users
don’t have to go digging around in their filesystem or control panels to
start the service.

Linux and *BSD users will most likely want a shell script to start the
OpenVPN service. In some cases, such a shell script can be dumped into
/etc/init.d/ to start the tunnel at startup (though I don’t recommend this
from a security point-of-view).

Considering OpenVPN yet?

For those seeking a fast, flexible, and (dare I say it?) almost fun to use
VPN system, it’s hard to beat OpenVPN. While the system has a few warts,
generally, it just works. For busy admins, and users who don’t care to
learn the ins-and-outs of networking, something that just works is a
pleasant revelation.

About the Author:
David Bogen is a freelance writer and technology consultant. He previously labored in the data mines of investment banks, streaming media startups, and software development corporations before striking out on his own.


  1. 2004-01-26 5:11 am
  2. 2004-01-26 5:12 am
  3. 2004-01-26 5:40 am
  4. 2004-01-26 6:25 am
  5. 2004-01-26 6:54 am
  6. 2004-01-26 7:22 am
  7. 2004-01-26 7:51 am
  8. 2004-01-26 7:51 am
  9. 2004-01-26 10:47 am
  10. 2004-01-26 10:49 am
  11. 2004-01-26 11:50 am
  12. 2004-01-26 11:55 am
  13. 2004-01-26 12:41 pm
  14. 2004-01-26 12:46 pm
  15. 2004-01-26 2:43 pm
  16. 2004-01-26 3:10 pm
  17. 2004-01-26 4:30 pm
  18. 2004-01-26 4:39 pm
  19. 2004-01-26 4:55 pm
  20. 2004-01-26 5:12 pm
  21. 2004-01-26 6:17 pm
  22. 2004-01-26 10:38 pm
  23. 2004-01-26 11:02 pm
  24. 2004-01-26 11:40 pm
  25. 2004-01-27 3:34 am
  26. 2004-01-27 8:30 am
  27. 2004-01-27 2:38 pm
  28. 2004-01-27 4:11 pm
  29. 2004-01-27 6:05 pm
  30. 2004-01-28 12:07 am
  31. 2004-01-28 1:07 pm
  32. 2004-02-04 11:21 pm