[Openswan Users] remote disconnection causes local issues

[Richard Green]

I have a Debian Linux 5.0 box running OpenSwan system, with two VPN
connections. One is to an OpenBSD box running ISAKMPD, and the other
connection is to another Linux box running a port of ISAKMPD. This mix isn't
my choice, but I don't think it's relevant to the issue, which is as
follows:

When either of the remote ISAKMPD boxes drop the connection to the box
running OpenSwan (a re-boot, for instance), after a few seconds...

Initializing XFRM netlink socket

...appears in the kernel log of the box running OpenSwan, and after that
point it is no longer possible to log in to that box running OpenSwan,
either via a ssh connection or via the console, and some services
become unavailable. No log additional errors are logged relating to the
problems with the other affected services.

If there was an existing terminal session to the OpenSwan box (obviously not
over one of the VPN links), that remains usable, and the I can recover by
killing (needs KILL, TERM is not enough) all pluto processes, the starting
ipsec connections again (on Debain, that's /etc/init.d/ipsec restart). If
there is not a terminal left open the only way I have found to regain access
is to reboot the system running OpenSwan.

Now I would expect it should be possible for the remote side of an IPSEC
connection to drop it's connection in any way - gracefully or not - without
impacting the ability to log in to the local system (no services critical to
authentication etc are accessed through the IPSec links).

Well I guess when the connection drops, OpenSwan responds by trying to do
something, and it must hang at this stage. For various reasons I'm having to
work on a live and critical system, so I'm looking to find out a bit more
with minimum disruption.

To start with, has anyone experience similar?

Also what debug options can you suggest for starters which won't cause havoc
on a live system which might be relevent to an issue such as this?

Here's my config (OpenSwan system is on the 'right'):

# basic configuration
config setup
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 private"
        # eg: plutodebug="control parsing"
        #
        # ONLY enable plutodebug=all or klipsdebug=all if you are a
developer !!
        #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        nat_traversal=no
        # virtual_private=%v4:
10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
        #
        # enable this if you see "failed to find any available worker"
        nhelpers=0
        forwardcontrol=yes

# Add connections here
conn IPsec-birdsville-atlanta1
        pfs=no
        left=xxx.xxx.xxx.197
        leftsubnet=192.168.4.0/24
        leftnexthop=%defaultroute
        right=yyy.yyy.yyy.254
        rightsourceip=192.168.123.7
        rightsubnet=192.168.123.7/32
        rightnexthop=%defaultroute
        auto=start
        authby=secret
        keylife=1200s
        ikelifetime=3600s


conn IPsec-bourke-atlanta2
        left=www.www.www.2
        leftsubnet=192.168.234.5/32
        leftnexthop=%defaultroute
        right=yyy.yyy.yyy.254
        rightsourceip=192.168.234.7
        rightsubnet=192.168.234.7/32
        rightnexthop=%defaultroute
        auto=start
        authby=secret
        keylife=1200s
        ikelifetime=3600s
# sample VPN connections, see /etc/ipsec.d/examples/


#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20100607/33d210f0/attachment.html