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

By Charlie Schluting | Posted Oct 21, 2009
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn


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.

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, and recently finished Network Ninja, a must-read for every network engineer.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter