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
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
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).
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
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
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
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.
Openvpn is very good vpn solution:
– easy multiplatforms, no differences in conf like with ipsec
– very easy configuration files (about 6 to 10 short lines)
– support for win, macosx, linux, solaris, *bsd
– very good options for debugging
– and a good community (mailing-lists & co)
on the security aspect, there was once an article on slashdot on the poor security of cipe, vtun and some others. on the opposite, openvpn was granted as a very secure solution.
Does openVPN Support IPX traffic?
Is it usable for WAN gaming?
OpenVPN can operate in TAP mode, which is a virtual ethernet connection. Anything that will run across ethernet will run over openvpn (although I don’t think its the most efficient way). I have my VPN handing out ips via dhcp.
so, yes it will do IPX.
What kind of client does it comes with or support?
same than server: so nearly anything than support tun/tap device:
win, macosx, *bsd, solaris, …
sorry, I mean can I use like [ Cisco VPN client, CheckPoint Secure Remote, or Lucent VPN client] connect to OPENVPN server.
Or dose the OpenVPN provide its own client? if so, does it run on Win32?
Anonymous: yes, it provides its own client for all OSes. I’ve tested it under Win32 and it works like a charm (both as a NT service or as a standalone application). I never had problems with it.
We are using OpenVPN with a Linux server and some Linux laptops connected through WLAN for many month without hassle. Easy and no problems so far.
I’ve been looking for a VPN solution that’s based on other methods than key authentication. Does anyone know of VPN servers that is PAM based? It would be nice to intergrate this with the LDAP user database(and such).
So do I understand correctly that a server requires multiple listening ports if it wants more users to connect? How does the client software know which port to use if the first handful are already in use?
Its biggest plus compared to bare-bones l2tp server is that it encrypts traffic. Everything else is pretty much the same as an l2tp tunnel.
The port no is predefined per tunnel. So 5001 is set on the server and the client for that tunnel.
I have to say that I’ve used ipsec with cisco, watchguard and FreeSwan but in the 3 months I been using OpenvVPN I nearly replaced everything with it where possible. As of ver 1.5 the quality of this software is truely fantastic. I cannot recomend it enough.
“The port no is predefined per tunnel. So 5001 is set on the server and the client for that tunnel.”
Do you have to do this manually? If you do this seems like it would be a nightmare to administer more than a few clients.
Also I was wondering about the speed of SSL encryption vs. hardware based IPSEC.
> Also I was wondering about the speed of SSL encryption vs. hardware based IPSEC.
Aren’t there also hw ssl impls?
>”The port no is predefined per tunnel. So 5001 is set on >the server and the client for that tunnel.”
>Do you have to do this manually? If you do this seems >like it would be a nightmare to administer more than a >few clients.
>Also I was wondering about the speed of SSL encryption >vs. hardware based IPSEC.
Yes it’s manual but it takes 2 mins to create a tunnel. I’ve written my own scripts which cuts it down to a few seconds, but once you have good configs then you can use them as templates for the other tunnels. One template per os is fine.
The first patches are coming thru for multiple tunnels to a single port but dont expect anything in the mainline too soon.
I dont know anything about hardware acceleration but there’s quite a few comments on the openvpn mailing list.
Yup, this is a really good product, all the more so for being multi-platform.
Which should soon count one more, when I get vtun working with my tuntap driver for BeOS BONE (it currently compiles but fails in select() after connecting), I should jump on that one.
I understand and use other VPN solutions (IPSEC and PPTP), but this seems at first glance to be just like creating a tunnel with SSH.. Am I missing the boat here?
AFAIK ssh only tunnels *ports*, that is, it can tunnel your local port 80 (http), 6000 (X11), …, but you need to specify each of them.
Here we want to tunnel the whole path from one box to another.
@ Gabriel Ebner
Yes. See for example “Cryptographic Hardware Support” (OpenBSD’s support, not OpenVPN’s support) at http://www.openbsd.org/crypto.html for a list.
@ Chris Hamant
IPsec / VPN -> Transport layer.
SSL / SSH -> Application layer.
The difference or preference depends on what you want.
Imagine you work at a company and there’s 2 offices. 1 in Great Britain, the main office. One in Germany, a small one. Now, a new software package got released which has to be moved to Germany over the internet in a secure way.
FTP to 10.0.200.1 which is then encrypted over the internet by VPN/IPsec. It goes a bit slower than over LAN but otherwise it is transparent.
Otherwise the internet address has to run FTP over SSL [the horror] or SSH.
VPN / IPsec also gets rid of NAT.
Those are a few practical differences…
A few years ago there was a brilliant article in C’T about VPN.
The article says that I have to open a firewall port for every user. In an Enterprise environment, this is simply unacceptable. I can’t go opening 500 or 1,000 ports for VPN users. Other VPN solutions run over ONE port. The firewall port issue alone is enough to discount OpenVPN as a solution. Is the port information correct, or am I misunderstanding?
>The article says that I have to open a firewall port for >every user. In an Enterprise environment, this is simply >unacceptable. I can’t go opening 500 or 1,000 ports for >VPN users. Other VPN solutions run over ONE port. The >firewall port issue alone is enough to discount OpenVPN >as a solution. Is the port information correct, or am I >misunderstanding?
It’s messy yes, but not unacceptable. good scripting can manage the ports. It’s no more insecure, the last 999 ports have the same security as the 1st 1.
If you are in an Enterprise environment then chances are this will not be your solution because it is not backed by a bluechip support company. If this is not a problem then you could write a decent management script(s) in a day. One day is nothing for 500-1000 tunnels.
I don’t see any reason why anyone should bother with OpenVPN.
For permanent connections or certificate based solutions, IPSEC is the way to go. Seeing how it is now part of the 2.6 Linux kernel, and has been in FreeBSD and Solaris for years, there is no reason why you should go with anything else. It is available everywhere and requires no additional installations. Also, it is simply unbeatable in security.
For VPN solutions requiring user entered authentication, PPTP is probably the best choice. Great security and almost all Unix OS support interopperability with it (they can act as both server and client). L2TP is also a great solution, providing the best of both worlds (certificate and user entered authentication) and IPSEC for security. However, it is currently proprietary to Microsoft so I would stay away from it until we get Linux clients and servers.
I don’t see any reason why anyone should bother with OpenVPN. For permanent connections or certificate based solutions, IPSEC is the way to go.
Have you tried to deal with IPSec through NAT? It’s doable, but if you’re a small company that cannot buy a commercial IPSec solution (one that comes with Windows clients that can tunnel IPSec through UDP), it won’t work.
I played with FreeS/WAN and Win2K IPSec and it’s a nightmare if you must open a VPN link through NAT (you must be able to do that if you want to give your road warriors enough flexibility).
OpenVPN deals with that issue gracefully.
I know the issue is not the protocol itself, but a lack of a free Win2K client that can tunnel IPSec through NAT, but whatever the cause, if it doesn’t work, then you must search for something else.
slash: As Florin said, IPSec isn’t easy. Having commercial solutions – Watchguard, Checkpoint, Cisco makes the pain easier, but having both protocol types as well as port types (IPSec) makes NAT hard. ALGs are often required in NAT deployments to keep it all working nicely.
PPTP is similar in that you need a TCP port and another protocol to be supported in your NAT gateway.
As I said earlier, L2TP is great that it’s only one port and protocol type to support. This is pretty much L2TP but with encryption.
Also the more complicated with your security you get, the harder it is to support. Suddenly you have you get a self-signed CA for your organisation if you don’t want a commercial variety. How do you distribute the PKIs and revocation servers for IPSec? You’ll have to face all these questions, and more.
This looks very promising. I’ve been having a headache about setting a vpn network up for a while, and this looks like just the ticket. I bought that fvs318 netgear router and it only really has good support with router to router vpn networking. Otherwise you have to pay hundred plus bucks for an exceptionally confusing client program that doesn’t seem to work half the time with the windows version you are using.
I will say one thing about the fvs318, it is very easy to configure if it is a router to router connection, and does the best job of a vpn router setup that I have ever seen outside of the CISCO relm.
I have worked with FreesWan Linux and Win2k roadwarriors over NAT and it works like a charm. I guess you need to combine the Freeswan Nat support and IPtables firewall rules
(i prefer using shorewall to get the job done).
Configuring many ports for OPen VPN is a nightmare.
I moved all VPN type functions to SSH. One port, no management. Clients can be pre-configured to tunnel the needed ports, so no configuration by the client needed. Very secure. All the applications we needed (file transfer, email, intranet web access, remote GUI application execution, etc.) can be transferred over SSH tunnels. Wide availability of clients (even Java implementations, loadable via web browser). Available for every platform and architecture, and cross-platform compatible. As an ad-hoc solution, no resources are consumed when the connection is not in use. Works easily with NAT (port forward) and firewalls. Support one client or 10,000 makes no different (size the server for concurrent use).
Ok, can someone explain me what this program is for? I dont know what VPN is, i already have a router with a firewall
Let’s say that you have a private local area network (LAN) at your house and your friend has a private LAN at his house and you want to connect your LAN and your friend’s LAN together as though it was one big LAN. A VPN solution will enable you to do it. You can also limit what your friend sees in your LAN and vice-versa. I hope that this helps.
How does OpenVPN compare to IPSec when it comes to re-establish a broken tunnel (say 1 of the boxes loses connection to Net for 1/2 hour).
Compare to PPTP, IPSec is fantastic as you dont’t to worry
about re-establishing the link. IPSec does it automatically, unlike PPTP. Does OPenVPN automatically re-establish the link?
And how to long does it take to establish it?
muito bom realmente