Plug as L2TP/IPSEC VPN server

[FrankL]

My intention is to get already available software for Debian 6 (Squeeze) to accept L2TP/IPsec connection from clients that using the build-in VPN client in Windows (although I don't see a reason why it wouldn't work with Android/OSX/iOS too), while optimally making use of the Marvell Kirkwood platform. This means the highest speed possible with the limited resources available on the ARM CPU as well as using the hardware crypto capabilities of the Kirkwood platform (CESA) to accelerate IPsec and possibly other layers of the connection.

For this project, an IPsec protocol implementation, IPsec IKE daemon, L2TP daemon and PPP daemon are needed. For this I have done research and tried several of the available options, and come to the following 'best yet' list:

NETKEY as IPsec protocol stack implementation
Netkey is the native IPsec implementation of the Linux 2.6 kernel and up, and uses the kernel's Async Crypto API and for which a driver is included in the mainstream Linux kernel that can use the Marvell CESA. Netkey is supported by all current IKE daemons and therefore allows for the biggest flexibility in choice of that component.

As an alternative, the KLIPS implementation has been ported to kernel 2.6.x by the Openswan developers (Xelerance Corporation). KLIPS only works with the Openswan IKE, and requires the Cryptodev API to get usermode hardware crypto acceleration. For this, an implementation of Cryptodev needs to be installed, such as OCF with a native CESA driver or the cryptosoft driver to convert calls to the kernel's Async Crypto API. When using OCF with native CESA driver, you'll probably lose acceleration by the Async Cryptosoft driver in the kernel as I assume they can't be active at the same time. For example dm-crypt uses the Async Crypto API for acceleration.

Openswan as IKE daemon
Openswan and strongSwan both seem to be actively developed, contrary to Racoon which is a port of the userland tools of the KAME FreeBSD and NetBSD utilities and which development seems to have slowed to a crawl. Openswan also supports the KLIPS ipsec stack on the 2.6.x kernel, so it has more flexibility than strongSwan does. However, strongSwan has support for more crypto algorithms than openswan and a better IKEv2 implementation which makes is more future proof (i.e. with use with Windows 7, etc.).

openl2tp as L2TP daemon
The only current projects seem to be xl2tpd and openl2tp. xl2tpd runs in usermode and is much (MUCH) slower than openl2tp, which uses a kernel module to speed up (or avoid slowing down) L2TP traffic.

pppd as ppp daemon
pppd, hosted by the samba project seems to be the only ppp daemon and works fine for that purpose.

Al right, with these options and choices, you'd think setting up would be a breeze. Unfortunately I ran into many problems which I haven't been able to resolve up to now.
current state of the project
- openl2tp and openswan don't play nice together in the IPsec initiation phase. Connection initiation is difficult, as openswan receives l2tp traffic from the initiating Windows clients often before it has finished setting up the outgoing SAD. This lead to leakage of encrypted data as openl2tp responses get send outside of the IPsec tunnel. The bugreport for this has been filed at the end of 2010, but no resolution available for openswan as of yet. Note that Racoon also suffers from the same issue, and an old bugreport on the strongSwan mailinglist seems to imply the same holds true for strongSwan. A workaround for this problem with NETKEY is to (ab)use a plugin for openl2tp to automatically set up the IPsec SAD using racoon (setkey ipsec-tools).
- openl2tp and openswan don't play nice together in the IPsec rekey phase when using netkey. Connections get dropped when the client rekeys the IPsec connection, which MS Windows does after transferring ~170-200MB of initial data over the ipsec connection and ~100 of successive data after that. When using the KLIPS stack this does not happen, so this could be an issue in the kernel (netkey) too.
- hardware accelerated NETKEY stack in the 2.6.32 and 2.6.36 kernel is not usable or unstable for ipsec. In 2.6.32 (Debian kernel) this manifests itself in the inability to set up L2TP/IPsec connections when using CESA with netkey. In the 2.6.36 kernel connections can be set up, but if for example EAP-TLS is used for PPP authentication, system instability results.

The path towards a working solution
- accept the far slower l2tp implementation provided by xl2tpd. On ARM (tested with two different platforms), xl2tpd is such a bottleneck that hardware accelerated cryptographic ciphers don't even improve the throughput of L2TP/IPsec. For me, this is a non-option.
- bug fixes in openswan/netkey for interoperability with openl2tpd in L2TP/IPsec. Already have been waiting 9+ months for this to happen. Theoretically a fix of either problem may results in a working solution. If the connection initiation bug is fixed, KLIPS + OCF w/cryptosoft may provide a working accelerated solution. If the ipsec rekey bug is fixed, the plugin for openl2tp (using setkey in racoon/ipsec-tools package) can provide a workaround for the connection initiation bug.
- try strongSwan to see if said bugs exist, file bugreports and hope for fixes from them

- If the solution uses NETKEY: test kernel 3.x for improvements in CESA driver for Async Cryptosoft API (there seem to be changes on the code in the 3.0.0 kernel version)
- If the solution uses KLIPS: test OCF with native CESA driver, or cryptosoft driver. Possibly try alternative linux cryptodev implementations

[FrankL]

Update:

- openl2tp and openswan don't play nice together in the IPsec rekey phase when using netkey. Connections get dropped when the client rekeys the IPsec connection, which MS Windows does after transferring ~170-200MB of initial data over the ipsec connection and ~100 of successive data after that. When using the KLIPS stack this does not happen, so this could be an issue in the kernel (netkey) too.

Fixed with a commit to the 3.2-rc5 linux kernel

I'm trying to get this commit into Debian stable kernel.

[sfzhi]

Openswan as IKE daemon
Openswan and strongSwan both seem to be actively developed, contrary to Racoon which is a port of the userland tools of the KAME FreeBSD and NetBSD utilities and which development seems to have slowed to a crawl.

current state of the project
- openl2tp and openswan don't play nice together...

Openl2tp and ipsec-tools (racoon) play together very nicely. I've been using them for quite a while with built-in Windows VPN client and no problems whatsoever (although not on the plug and not with hardware acceleration). By the way, ipsec-tools-0.8 was released just a few months ago, and judging by the activity in the mailing list, they have been working hard to make it happen. (Before choosing ipsec-tools I tried a couple of *swan-s and found them to be too much of bloatware. I'm not sure it's such a good thing that they are being actively developed further).

[sfzhi]

Forgot to mention one important thing. If you want NAT-T in transport mode (which you do, to be able to connect to the VPN from behind NAT), you would need ipsec-tools-0.8 (0.7.3 does not support it).

[FrankL]

Openswan as IKE daemon
Openswan and strongSwan both seem to be actively developed, contrary to Racoon which is a port of the userland tools of the KAME FreeBSD and NetBSD utilities and which development seems to have slowed to a crawl.

current state of the project
- openl2tp and openswan don't play nice together...

Openl2tp and ipsec-tools (racoon) play together very nicely. I've been using them for quite a while with built-in Windows VPN client and no problems whatsoever (although not on the plug and not with hardware acceleration). By the way, ipsec-tools-0.8 was released just a few months ago, and judging by the activity in the mailing list, they have been working hard to make it happen. (Before choosing ipsec-tools I tried a couple of *swan-s and found them to be too much of bloatware. I'm not sure it's such a good thing that they are being actively developed further).

I'm quite indifferent to the IKE daemon used. I've tried all (Openswan, strongSwan and racoon), and all work for my purposes (since the rekey fix, which is unrelated to the IKE daemon used).

However: there have only been 6 commits in the entire year 2011 to the Racoon codebase, questions on their mailinglists remain unanswered, both their bug database and their mailinglists are completely littered with spam. I doubt there's much life in racoon after the 0.8.0 release....

Openswan creates a load of processes on startup. strongSwan seems cleaner, apparently has better IKEv2 support and is more modular in buildup (you can chose to only run the IKEv1 or IKEv2 daemon). They also claim to focus more on interoperability with as many other implementations as possible.

Right now I'd say strongSwan is the best choice.

[FrankL]

oh and since I can't edit the original post, let me give an update on general things:

the 'connection initiation problem on relatively slow hardware' occurs regardless of the IKE daemon used. At this point, my uneducated guess is that the IPSEC RFCs define resultant behaviour. Probably openl2tp needs to take this into account and add a workaround for it that doesn't require external dependencies like ipsec-tools.

The rekey issues is fixed with the kernel commit I mentioned, and make all IKE daemons viable options. At this point I prefer strongSwan because of the reasons in my previous post.

I'm waiting for a 3.0 kernel release to hit the Debian Squeeze backports repository, so I can do some serious hardware acceleration testing on the Marvell Kirkwood platform. Without acceleration, I get around 3-4 MBps (= 25-34 Mbps) throughput with openswan+openl2tp on my 1200MHz Marvell Kirkwood.

The other option would be manually building OCF-linux for Debian Squeeze, trying both the cryptosoft and native CESA driver with the KLIPS IPSEC stack and openswan. However, this is quite a bit of additional work (OCF-linux is not available in Debian repositories) and using the native CESA driver in OCF-linux will exclude other applications from using the mv_cesa kernel driver (e.g. dm-crypt) for acceleration. It might still be a very interesting project, as to compare the CESA driver implementations differences between the kernel and OCF-linux...