A fairly new comparison of openswan and strongswan

Openswan vs strongSwan

From the beginning of my VPN project, I knew about strongSwan... but I stuck to Openswan because that’s what is covered in the Openswan book I bought and read.

After perusing the strongSwan website for a few minutes, one thing became apparent: the strongSwan project has superior documentation. The comparison isn’t even close; most of the Openswan documentation hasn’t been updated in years; it often refers to Openswan 3.0 - a branch on which development has stopped for at least 3 years, if its git repository is accurate.

Additionally, when I looked at features, a few trends emerged:

• Openswan moved in the direction of the networking industry

• • And as a result, supports aggressive mode (which the Openswan devs ask you not to use).
• • Openswan supports the legacy KLIPS IPsec kernel stack.

• strongSwan is interested in authentication and security:

• • No surprise, given its originator provided the x.509 patch.

• • • strongSwan has better support for authentication mechanisms in general
• • • Supports EAP methods, including EAP-RADIUS
• • • PKCS#11 smart cards

• strongSwan only supports KLIPS on 2.4 linux kernels; if you’re running 2.6, they use the in-kernel NETKEY IPsec stack.
• strongSwan also supports the new IKEv2 standard (and interoperates well with other IKEv2 implementations.

• • IKEv2 allows for automatic IP address assignment, DNS assignment, and routing.
• • IKEv2 is in its infancy in Openswan.

• strongSwan aupports Mobility and Multihomed IKEv2 (also known as MOBIKE)
• strongSwan supports additional ciphers, such as TwoFish, and elliptic curve crypto.
• strongSwan is modular (vs. Openswan’s monolithic nature)
• strongSwan also has IP address pools/assignment with IKEv1, which is not offered by Openswan.

With the data available to me, strongSwan looks like the clear winner. About the only thing I’ve heard about that Openswan does that strongSwan doesn’t are:

• KLIPS/MAST on 2.6 kernels

• • This allows (with a patched & recompiled kernel) some NAT mapping that doesn’t work well with the NETKEY stack. Cases where NAT clients have the same “internal” IP address as the server, or each other have problems with NETKEY currently.

• IKEv1 Aggressive mode: Which is something that even the Openswan developers suggest you avoid if at all possible.