Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Often we need to secure communication channels, not for remote workers, but for server-to-server communication. Backups, for example, come to mind. It may be fine to use SSH or stunnel to ship data securely, but when performance is required and encryption cannot slow down communication, something else is necessary. OpenVPN is easy to configure, but it may not be sufficient.
If data is critical enough to ship off-site in real time, chances are it’s valuable data, and should be encrypted for transit. Real-time data replication that databases often use, requires a fast enough network connection to avoid slowing down the local server. Disk block replication, i.e. DRBD, is even more sensitive to overhead when running synchronously to guarantee data integrity. Administrators will often configure a quick VPN connection for security, but then realize they’ve just compromised performance.
We will get into why OpenVPN is slower, but first, let’s consider alternatives for speeding up performance.
More Speed
Ideally, you won’t use any server-based encryption at all. And if you must use OpenVPN, hardware crypto accelerators can be used to offload encryption duties. New CPUs from Via also have Padlock, which is on-chip crypto acceleration. These processors are a bit limited to start with, but with a hardware crypto engine, you often get encryption “for free” with zero noticeable slowdown.
Better still, your router (or VPN device) can probably encrypt at line speed. Passing this work to the fancy router hardware means improved performance, but also less management hassle. There is no chance of a server operating system upgrade messing with that configuration, and no need to configure each server. You also push the duties of encryption and security to the network security administrators, who (should) have tons of experience with VPNs.
OpenVPN
OpenVPN, a user-friendly VPN client/server package available for *nix and Windows, uses OpenSSL for encryption. It is much easier to get working because the server and client configurations are simpler, and mussing with NAT and firewall settings is not usually necessary. Another part of its user friendliness is that multiple clients can connect to one port. No firewall rule changes to add another VPN client, and no need to change the configuration to add another port, either. OpenVPN, however, runs in user space.
Frequent context switches and memory copies means a user space VPN solution will seem much, much slower than kernel-based encryption. Even with hardware acceleration, more user-to-kernel copies still must occur. There is no getting around that fact, which is why IPSEC should be used when performance matters.
It must be said; all of these features that benefit OpenVPN seem a bit SOHO. OpenVPN wonderfully addresses the issue of road-warriors connecting to a VPN. This ease of use doesn’t mean you should attempt linking servers together with OpenVPN, but many people do.
IPSEC
IPSEC has a bad rap. It certainly is difficult to configure if you’re using the wrong tools–and the landscape is full of bad tools. The good news is that Windows, Linux, Solaris–everything–has IPSEC built in. There is no need to install anything, except maybe in the case of Windows, which has a particularly bad implementation. Most opt for Cisco’s software rather than the built-in Windows IPSEC implementation.
IPSEC is a standards-based IP SECurity extension. IPSEC requires key management and tunneling to make it a “VPN,” so the necessary glue to tie it all together is often many different applications. Having choice is great, but also why people–especially people who have tried FreeS/Wan–struggle to even make it work, let alone configure something secure, understandable, and extendable. The IPSEC specification and implementations are perfect examples of where systems administrators, protocol designers, and programmers butt heads.
That said, IPSEC is a standard, and therefore much more flexible and widely supported. Encryption is also done in the kernel (where the IP stack is), and therefore performs much better. Key management daemons do run in user space, but are only used to set up the tunnel and for infrequent key changes, not for the encryption of every packet.
Configuring IPSEC tunnels for every server to server connection may seem bothersome, but in fact this means it’s extremely flexible. You can logically understand packet processing order, in terms of firewall rules, and apply filters and bandwidth caps after decryption takes place. You can use the whole suite of tools used for other firewall or shaping tasks, and you are not limited to the capabilities of the OpenVPN software.
Choosing
Finally, there is performance. For road warriors and light site-to-site communication, OpenVPN may work fine. Applications sensitive to latency (like VoIP or synchronous replication), or those that require maximum use of bandwidth, will see a dramatic drop in performance: generally around 50 percent. Hardware crypto acceleration can improve that with OpenVPN, and IPSEC can do even better.
While configuring one-off server-to-server encrypted tunnels may not be a big hassle for small infrastructures, most enterprises shouldn’t want to mess with this at all. To be fair, some fairly large Linux environments may want just one link to a single remote server without any expected growth. A live hot-backup of a database, for example, may be the only remote connectivity needed.
Everyone else, though, needs to seriously reconsider stringing a tangled web of VPN tunnels all over the world if they are terminated on Linux servers. VPN tunnels are not easy to code into configuration management systems (each one is a one-off), and chances are good that a site-to-site VPN terminated on routing hardware makes much more sense. If you’re sending more than a single server’s worth of data, even the faster IPSEC VPN will not keep up. Encryption overhead will be noticed, unless you’re using purpose-built hardware.
There is still tremendous need for one-off VPNs, of course. Perhaps you need to connect one server to another company with whom you are partners. Or maybe that canonical single-server backup scenario rings home with you. We aren’t saying you should never do it, and coming up in a few weeks, we will show you how to configure IPSEC painlessly.
