[Openswan Users] Dropping IPSec Connection

Paul Wouters paul at xelerance.com
Wed Mar 28 01:28:42 EDT 2007

On Tue, 27 Mar 2007, Muiz Motani wrote:

> On one of the routers, the VPN drops after a while. Sometimes the period between drops is a few hours and sometimes it is as
> much as 2 days. The only way to re-establish the VPN is to restart IPSec on the spoke router. I managed to capture barf
> output (which was difficult since this router is in production and the users have learned to just restart the router in order
> to restart IPSec when things don't work). I found it interesting that when the ipsec0 link fails, ipsec_tncfg shows that the
> MTU for the underlying physical interface (eth0) is 0, as well as the effective MTU! You will also note that I have tried to
> limit the MTU using overridemtu to 1400 since I originally suspected MTU issues.
> The interesting thing is that users are reporting that they can still access the internet through eth0 (e.g. they can still
> surf the web).
> I also noticed that when this happens, there is a large packet loss (> 20%) on the link between the routers.
> So, my question is does anybody know what is going on? Could this be caused by dropped packets in the network?
> Here is the extract from ipsec barf showing the tncfg output:
> + _________________________ proc/net/ipsec_tncfg
> +
> + cat /proc/net/ipsec_tncfg
> ipsec0 -> NULL mtu=1400(0) -> 0
> ipsec1 -> NULL mtu=0(0) -> 0
> ipsec2 -> NULL mtu=0(0) -> 0
> ipsec3 -> NULL mtu=0(0) -> 0

Is this over ppp? Perhaps this happens when the physical ppp device vanishes
(because the pppoe link went down and up). If that's the cause, the thing
you want to do is run:

 more /etc/ppp/ip-up.local

if [ -f /var/run/pluto.pid ]
        echo "ppp vanished while IPsec is running, fixing"
        echo "Detaching ipsec0 from previous ppp0 device"
        ipsec tncfg --detach --virtual ipsec0 > /dev/null 2> /dev/null
        echo "Attaching ipsec0 to new ppp0"
        ipsec tncfg --attach --virtual ipsec0 --physical ppp0

Note that this technically can cause a packet or two to "escape" in
cleartext, between the two tncfg ocmmands, though if it is unroutable
(eg private) ip space, then it should get dropped anyway.

Building and integrating Virtual Private Networks with Openswan:

More information about the Users mailing list