Your Linux Data Center Experts

I haven't written about OpenVPN here before, but those of you who know us know that we're big fans of OpenVPN. There are several reasons for this: It doesn't require any kernel patches, it uses well-established crypto (OpenSSL), it can be configured to use either UDP (for performance and lack of melt-down) or TCP (if UDP is blocked). IPSEC might be another option, but it doesn't have the flexibility to run over TCP if it's GRE packets are blocked, and while it's better now, historically it's been quite painful to set up. Admittedly, it's been years since I've even tried.

OpenVPN just works, and it works very well. It's available for any platform that has OpenSSL, and the TUN/TAP driver. This means Linux, Windows and MacOS all work just great, among others. Read on for more reasons why I like OpenVPN.

In the past we've used various VPN software. Some used questionable crypto, or at least not well reviewed crypto. OpenVPN uses OpenSSL, which is probably the most widely used set of crypto routines available. Others I have used either required kernel modules or custom-built kernels.

We are currently using an OpenVPN configuration based on the version 1 code. Back then, you had to use one port for every connection. Version 2 implemented a server mode where a single server port could deal with many different clients, authenticated by SSL certificate. The down side of our current setup is that we have to have one OpenVPN daemon running for every client. It also makes it difficult to switch between TCP and UDP.

OpenVPN does include the ability to run over both TCP and UDP. This is nice because TCP tends to work over more firewalls without special configuration. However, the drawback is that TCP doesn't work very well for tunneling TCP traffic. There are a few pretty serious problems with tunneling TCP over TCP. In short, both the tunnel and the end applications will do packet retransmission, which eventually can lead to a “meltdown”.

Another problem with TCP is that if you lose a packet, all packets sent after it are blocked until that one successfully goes through. If you have many streams of data going on, this means that nothing moves until the logjam is cleared. Also, real-time applications like VoIP can deal much better with a single dropped packet every second, but can't deal with these sorts of retransmissions. If you're sending a file, you don't want it to drop any packets. For VoIP, you can deal with a lossy channel.

UDP corrects this, but some firewalls block UDP for various reasons. UDP is not connection-oriented, so firewalls have to be more clever in how they handle allowing UDP streams. It's extremely nice to have the choice though. Running OpenVPN on a well-used port like HTTP or SSH or DNS may allow it your VPN to get through where it otherwise would be blocked.

Another thing I use in OpenVPN is the “redirect gateway” option. It has recently implemented a “def1” option in which the daemon, once it has connected, adds routes for and to go over the VPN. In this way, it can direct all your traffic except that going to the VPN server over the VPN, without removing the default route. Removing the default route is problematic, because if you later restart OpenVPN it can lose the default route. We set up our default route to go over the VPN so that we don't have to worry about connecting from an insecure network or over a compromised WiFi. Anywhere we are, our traffic is secured over the VPN.

There are also many scripts you can set up to run before, during, and after the VPN connections are established. We run UUCP to hand off e-mail to and from our laptops. UUCP works extremely well with inconsistently connected machines like laptops, and also with low bandwidth connections. It can pick up in the middle of sending a very large message, which is great over slow wireless or dial-up connections.

While you are connected, UUCP will make a connection whenever a new message comes in, meaning that it provides immediate delivery of new messages. However, when you re-connect, you want to make sure that any current connection attempts are killed, and a new UUCP session is started. The variety of OpenVPN “up” scripts allow for this to be done quite easily. I just “pkill” any existing UUCP connections, and then start a new one. Any queued mail immediately comes in once the VPN connection is established.

With the TUN/TAP driver, you have the ability to select between a point-to-point (routed) connection and a bridged connection. This can allow you to implement “mobile IP”, where you have a consistent IP address no matter where you go. I use this for my home network, so that no matter where I go I get the same IP address in my home LAN and can easily run backups over the network whether I'm at home or at the coffee shop.

There is a “ping” and “restart” set of options allowing you to ensure the connection remains up, and trigger a restart if it fails for any reason. Whether it's because your local dynamic IP address has changed, you have moved to another network, had to redial, whatever. We are using OpenVPN in a number of situations where the VPN just needs to be up, no matter what.

Those are a few of the things I love about OpenVPN. If you're considering a VPN, look at OpenVPN. We've been using it for several years now and are extremely happy with it.

comments powered by Disqus

Join our other satisfied clients. Contact us today.