[Swan] Frequent Crashing with libreswan 3.10/pluto

[Paul Wouters]

On Tue, 7 Oct 2014, Reuben Farrelly wrote:

> I've recently set up an IPSec VPN between a VPS I run and a Cisco IOS router. 
> This seems to function just fine (initiates and passes traffic as designed) 
> however I'm seeing frequent crashes on the libreswan end, which is causing 
> disruptions in connectivity.  The frequency of the crashing is usually 1-2 
> times per day.
>
> The Cisco end is an 800 series router running 15.4(3)M which acts as a spoke, 
> initiating connections.  The VPS end is acting as a hub and is a Gentoo 
> x86_64 VM running on Linode, who use Xen.  I am using the kernel they supply 
> as part of the VPS, which is currently 3.15.4.  I am running with 
> libreswan-3.10 and nss-3.17.1 from Gentoo portage.
>
> The IPSec connection uses IKEv2 and runs in tunnel mode, and I have separate 
> /32s on each end of the link and only encrypt data between the two endpoints.
>
> The libreswan config I have is:
>
> conn reub.net
>        type=tunnel
>        left=106.187.48.126
>        leftid=@lightning.reub.net
>        leftsubnet=192.168.6.1/32
>        leftsourceip=192.168.6.1
>        right=%any
>        rightid=@router-2.reub.net
>        rightsubnet=192.168.6.2/32
>        authby=secret
>        ikev2=insist
>        ike=aes256-sha1;modp1536
>        esp=aes128-sha1;modp1536
>        mtu=1438
>        dpddelay=15
>        dpdtimeout=45
>        dpdaction=restart
>        auto=add

Can you try adding ikelifetime=15m and salifetime=30m ? It seems like
the cisco is giving a message we don't like.


> Frequently the libreswan end seems to just die.  Pluto crashes out entirely 
> and the VPN goes down.
>
> At the time of this the following is logged in the kernel log:
>
> Oct  6 14:52:06 lightning kernel: pluto[23223]: segfault at 58 ip 
> 00007f8f85f0c8d0 sp 00007fffb30275b8 error 4 in 
> libnss3.so[7f8f85ebc000+11f000]
>
> And in the auth.log the lines preceding this are:
>
> Oct  6 14:50:12 lightning pluto[23223]: | V2 microcode entry (R2: process 
> INFORMATIONAL) has unspecified timeout_event

It would be useful to have the full debug log for that with more
history.

Paul