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.
- "Intro to OpenVPN, Page 1"
- "Intro to OpenVPN, Page 2"