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.

This, of course, caused some (minor) changes to my /etc/ipsec.conf file, but all things told, it wasn’t too jarring a change.

/etc/ipsec.conf:
config setup
crlcheckinterval="600"
cachecrls=yes
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24,%v4:!192.168.2.0/24,%v4:!192.168.3.0/24,%v4:!192.168.4.0/24
interfaces=%defaultroute

conn %default
keyingtries=1
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyexchange=ikev1
compress=yes
left=%defaultroute.
right=%any
dpddelay=30
dpdtimeout=120
dpdaction=clear
pfs=yes

conn rw-local-nat
rightsubnet=vhost:%no,%priv
also=rw-local

conn rw-local
# Supposedly rekey can be no, because the client will ask for it...
rekey=no
leftsubnet=192.168.1.0/24
rightsourceip=%hostpool
also=rw

conn rw-l2tp-nat
rightsubnet=vhost:%no,%priv
also=rw-l2tp

conn rw-l2tp
keyexchange=ikev1
leftprotoport=17/1701
rightprotoport=17/%any
pfs=no
also=rw

conn rw
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
leftcert=pilotCert.pem
leftid=@pilot.pariahzero.net
rightid="C=US, ST=Utah, O=Troy Telford Family, OU=Home, CN=*, E=*"
rightca=%same
auto=add

# for iPhone VPN... mainly as a test...
conn rw-l2tp-psk-nat
rightsubnet=vhost:%no,%priv
also=rw-l2tp-psk

conn rw-l2tp-psk
keyexchange=ikev1
type=transport
authby=secret
leftprotoport=17/1701
rightprotoport=17/%any
pfs=no
auto=add

There is a new file, /etc/strongswan.conf:
charon {
plugins {
sql {
loglevel = -1
database = sqlite:///etc.ipsec.d/ipsec.db
}
}
}

pluto {
}

libstrongswan {
}

libhydra {
plugins {
attr-sql {
database = sqlite:///etc/ipsec.d/ipsec.db
}
}
}

pool {
load = sqlite
}

And, lastly, there’s the configuration of the IP address pools (for both IKEv1 and IKEv2):

1. Grab the SQL database for IP pools.
2. Import it into the SQL DB of your choice (I chose SQLite, as it’s easy and doesn’t connect to anything external...)
3. $ cat IPsec.sql | sqlite3 /etc/ipsec.d/ipsec.db
4. Generate the IP Address pools: ipsec pool --name hostpool --start 192.168.4.2 --end 192.168.4.63 --timeout 30

And, that should cover it.

Tags: Computing, Linux