[Openswan Users] Dropping IPSec Connection

[Muiz Motani]

> 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
> #!/bin/sh
> 
> if [ -f /var/run/pluto.pid ]
> then
>         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
> fi
> 
> 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.

Thinking a little more about this, I realized that I could run a script which would detach and 
reattach my ipsec0 if my VPN went down. The only way I can think of to determine from the 
router if the tunnel has gone down is to run a cron job every couple of minutes to monitor 
the tncfg. If the MTU for the underlying physical interface goes to 0 then I can just detach 
and reattach ipsec0. Does this sound reasonable, or can you think of another method to 
detect if the tunnel has failed? I currently find out that the tunnel has failed by running a 
cron job on a system in the subnet behind the spoke router which pings a system in the 
subnet behind the hub router, but this does not help me on the spoke router itself.

The above method is really a kludge, though. I would still like to find out if the tunnel would 
fail the way I described if there was packet loss in the path. A more elegant solution than the 
one I describe would be most welcome.

Muiz Motani
muiz (a) askaritech. dot com