Granting safe, controlled access to your company network for road warriors, telecommuters, and branch offices isn't difficult when you use OpenVPN. OpenVPN is a great Secure Sockets Layer-based Virtual Private Network (SSL VPN) program that is free of cost, open source, easy to administer, and secure. OpenVPN is designed to be as universal as possible, so it runs on Linux, Solaris, Windows, Mac OS X, and several other platforms. It runs as a client or server from the same installation, so client setup is a breeze. There are no hassles with vendor compatibility or finding a decent client, as there are with other VPN products.
In this chapter, we're using OpenVPN 2.0.7. (Use the command
openvpn --version to see what yours
is.) Don't use anything older; it's free, and it's easy to install and
upgrade, so there's no point in using old mold. If you're not
experienced with Open-VPN, try out the recipes in order, or at least run
the first two recipes before you try anything else. These will help you
understand how OpenVPN works.
The subject of VPNs is muddled by misleading marketing and incorrect information about SSL VPN products, IPSec VPNs, what they can do, and what they actually do, so first let's discuss some basics.
To start out, let's define a VPN—it is an encrypted network-to-network virtual tunnel that connects trusted endpoints. Both the VPN server and client must authenticate to each other. It is a secure extension of your network that makes all the same services available to remote workers, such as telecommuters and road warriors, that local users have. Think of it as a secure Ethernet cable that extends your network through hostile territory. A VPN connects two networks, like branch offices, or lone remote users to the office.
SSL VPNs rely on SSL/TLS for security. Secure Sockets Layer (SSL) is the predecessor to Transport Layer Security (TLS). The terms are used interchangeably; the two are very similar. These are cryptographic protocols used to protect transmissions over untrusted networks. They aim to prevent eavesdropping, tampering, message forgery, and to provide authentication.
An alarming number of commercial SSL VPN products treat your network like a shopping web site: in other words, all clients are trusted. This works fine for online shopping, but can be disastrous for remote LAN access. These are not real VPNs, but application portals. What makes a VPN strong is trusted endpoints. You don't want your users logging in from arbitrary machines, and especially not from coffee shops or other public terminals. Sure, it's convenient not to have to install and configure client software and copy encryption keys. But, that is shortsighted—the last thing you need is users logging in from random PCs infected with keyloggers and spyware, and then being given a warm welcome into your LAN. Prevention is more convenient than cleaning up after a successful intrusion. Any SSL VPN product that promises "Easy clientless configuration!" should be viewed with a large dose of skepticism. A real VPN is not an SSL-enabled web browser with pretty icons. A real VPN doesn't need a web browser. Don't trust your security to prettified web browsers.
To further complicate the issue, some IPSec proponents claim that IPSec is superior and that SSL VPNs are not worthy. IPSec, especially in IPv4 networks, has a number of problems. It is complex and difficult to administer, which are not good traits for security products. It is tightly coupled to the kernel, which means a failure can bring down your whole system, or a flaw opens a root door to an intruder. If you really want to use an IPSec VPN, try OpenBSD. It comes with a great IPSec implementation that is easy to get up and running. Its one weakness is on the client side—you're on your own for hunting down IPSec clients.
As IPv6 is implemented, IPSec may become easier because it is integrated into IPv6, rather than bolted-on as it is for IPv4.
OpenVPN is, I think, the best VPN product available. OpenVPN creates a true VPN, an encrypted extension of your network that requires a mutual trust to be established between the server and the client. The first step to setting this up is creating your own Public Key Infrastructure (PKI), which means using OpenSSL to create your own Certificate Authority (CA), and server and client keys and certificates. Having your own CA simplifies certificate management considerably. The server doesn't need to know anything about the individual client certificates because the CA authenticates them. If a client is compromised, its certificate can be revoked from the server. OpenVPN comes with a batch of scripts that make managing your PKI easy.
OpenVPN's encryption process is complex. First, the SSL/TLS handshake authenticates both ends, then four different new keys are generated: Hashed Message Authentication Code (HMAC) send and receive keys, an encrypt/decrypt send key, and an encrypt/decrypt receive key. This is all delightfully complex, and happens in an eyeblink; the result is that any attacker is going to have a very hard time getting anywhere. To learn about this in detail, read Charlie Hosner's excellent paper, "OpenVPN and the SSL Revolution" (http://www.sans.org/reading_room/whitepapers/vpns/1459.php?portal=c7da694586dcdad815fd41098461e495).
Client configuration is the easiest of any VPN. OpenVPN runs as either client or server on Linux, Solaris, OpenBSD, Mac OS X, FreeBSD, NetBSD, and Windows 2000 and up, so you don't have to hunt for client software, or suffer the pain of testing poor-quality client software. Configuration files are pretty much the same on all platforms. Just remember that slashes lean in the wrong direction on Windows.
OpenVPN runs as a user-space daemon. It uses TAP/TUN drivers to manage network access. TAP/TUN drivers are standard on most operating systems; these provide a way for user-space applications to access network interfaces without needing root privileges. The TAP driver provides low-level kernel support for IP tunneling, and the TUN driver provides low-level kernel support for Ethernet tunneling. You'll see this on Linux and Unix systems as character devices named /dev/tapX and /dev/tunX. In ifconfig, they will appear as tunX and tapX. Use the TUN driver when your VPN tunnel is routed, and the TAP driver when it's bridged. You'll configure this in openvpn.conf.
In an ideal world, your remote users only log in from PCs that have been carefully screened by your ace security staff, and your users are wise and careful, and don't let other people use their computers. In the real world, it's messier, of course. But using OpenVPN is a strong security measure that prevents many ills.
OpenVPN is a standard package on most Linux-based firewall
distributions, such as Shorewall, IPCop, Pyramid, Open WRT, Bering
uClibc, and DD-WRT. On others, it's just a yum install openvpn or apt-get install openvpn away, and of course,
you may build it from sources if you prefer.