OpenVPN Is Too Slow? Time to Consider IPSEC - Page 2
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.
When he's not writing for Enterprise Networking Planet or riding his motorcycle, Charlie Schluting works as the VP of Strategic Alliances at the US Division of LINBIT, the creators of DRBD. He also operates OmniTraining.net, and recently finished Network Ninja, a must-read for every network engineer.