OpenVPN Is Too Slow? Time to Consider IPSEC - Page 2

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.