Today I had to install another Bubba3 server together with an VPN service. Having the need of allowing Windows systems to logon with its native client (via VPN transport mode) my choice went to Openswan. After learning that the automatic detection of the KLIPS and/or NETKEY stack is broken in the case of road warriors with NAT enabled, I added the line
config setup # ... protostack netkey
in the /etc/ipsec.conf file (please note that this may be necessary, even though KLIPS may not be available and autodetection of the stack falls back to NETKEY support). That worked out during my first tests. However, soon after I got the problem that the kernel oops’ed with an error message like
kernel: Internal error: Oops: 5 [#1] kernel: Process mv_crypto (pid: 563, stack limit = 0xdfb80270) kernel: Stack: (0xdfb81ef4 to 0xdfb82000)
I was very pleased to find the discussion thread “[Solved] Oops on mv_crypto” by Gordon in the Excito Forum which also provides you with a good solution: Switch to the KLIPS stack. For doing so, you first have to ensure that the /etc/ipsec.conf reads as follows
config setup # ... protostack klips
but you also need to make sure that the corresponding KLIPS module is available with your kernel. We know this game already from my blog post “Strongswan on the Excito Bubba3 Server” and similiarly to what I have provided there for the NETKEY stack, I have created a Debian package for download at my Debian repository available at http://debian.schmoigl-online.de/repos (for details how to add the debian repository to your bubba configuration see the post mentioned before). Installing the package with apt is as easy as:
apt-get install bubba3-openswan-module-klips
Please note that you have to make sure that your box is restarted, if you encountered the kernel Oops mentioned above. Otherwise restarting ipsec could lead to the effect that the system still thinks that the NETKEY stack shall be used although you have stated otherwise in your /etc/ipsec.conf. After a reboot of the kernel this should be gone.