Virtual Private Networks Made Easy
Virtual Private Networks (VPNs) are a way to establish a secure network over an insecure channel. When most people talk about VPNs they refer to the IPSec protocol. However, IPSec is painfully difficult to setup, especially when it comes to connecting products of different vendors. Security guru Bruce Schneier questioned the security of the protocol back in 1998, and not much has happened since regarding these weaknesses.
OpenVPN is not another IPsec implementation, it implements its own protocol, which means that both communication endpoints have to run it. However, OpenVPN is available on several platforms, so this shouldn't be a big issue. For a VPN, there are two modes of operation available: bridging and tunneling. Bridging means that the local networks of both endpoints are put together to form a bigger virtual network. While this is generally harder to setup, it enables non-routable protocols that rely on broadcasts to work across the VPN. Tunneling means to have additional IP addresses for the endpoints, similar to a PPP connection with an ISP.
No matter which mode you are using the whole configuration resides in a surprisingly short config file. OpenVPN supports connections authenticated and encrypted with pre-shared static keys or a TLS-based client-server architecture. The latter requires to setup a certificate authority (CA), but the documentation will guide you gently through these steps. (If you ever built a CA using OpenSSL, you probably know why Mark Shuttleworth earned billions with Thawte.) Both authentication modes are implemented via the OpenSSL library.
OpenVPN uses only a single port, therefore it is extremely firewall-friendly. Using UDP here is favorable as running TCP over TCP is generally a bad idea. NAT traversal doesn't even have to be configured, the protocol is designed in such a way that it simply doesn't need to care about NAT. For an additional layer of security another HMAC authentication can be put on top of the TLS authentication which means that only packets of (more or less) trusted clients will enter the TLS part of the code. This is a good idea, as the TLS handshake is much more complicated than a simple signature verification and thus more prone to security holes.
If a connection with a client has been established, specific actions can be performed on the server depending on the identity of the user. For example, this makes it possible to dynamically adjust firewall rules. Specific networks can be added to the routing table of the client or the client can even be commanded to transfer all network traffic over the VPN.
Unfortunately, OpenVPN clients are a bit too generous when accepting configuration options from a server. It is possible to transmit environment variables to client-side shell scripts. There are some filters in place to prevent obvious nonsense, however they don't catch the good old LD_PRELOAD trick. All we need is to put a file onto the client under a known location (e.g. by returning a specially crafted document upon web access) and we have a remote root exploit. But since the attack may only come from authenticated servers, this threat is greatly reduced.
The only real problem with OpenVPN is that there are hardly any appliances that support it. There are a few great hacks for some, but getting support for them is quite difficult. However, as the usage of OpenVPN will increase (and it surely will), this drawback will go away.
So if you have any possibility to use OpenVPN instead of IPsec: do it. You won't regret it.