[Openswan Users] Dropping IPSec Connection
muiz at askaritech.com
Wed Mar 28 14:45:12 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.
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 (a) askaritech. dot com
More information about the Users