<br><div>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:</div>
<div><br></div><div>When either of the remote ISAKMPD boxes drop the connection to the box running OpenSwan (a re-boot, for instance), after a few seconds...</div><div><br></div><div>Initializing XFRM netlink socket</div>
<div><br></div><div>...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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>To start with, has anyone experience similar? </div><div><br></div><div>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?</div>
<div><br></div><div>Here's my config (OpenSwan system is on the 'right'):</div><div><br></div><div><div># basic configuration</div><div>config setup</div><div> # plutodebug / klipsdebug = "all", "none" or a combation from below:</div>
<div> # "raw crypt parsing emitting control klips pfkey natt x509 private"</div><div> # eg: plutodebug="control parsing"</div><div> #</div><div> # ONLY enable plutodebug=all or klipsdebug=all if you are a developer !!</div>
<div> #</div><div> # NAT-TRAVERSAL support, see README.NAT-Traversal</div><div> nat_traversal=no</div><div> # virtual_private=%v4:<a href="http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12">10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12</a></div>
<div> #</div><div> # enable this if you see "failed to find any available worker"</div><div> nhelpers=0</div><div> forwardcontrol=yes</div><div><br></div><div># Add connections here</div>
<div>conn IPsec-birdsville-atlanta1</div><div> pfs=no</div><div> left=xxx.xxx.xxx.197</div><div> leftsubnet=<a href="http://192.168.4.0/24">192.168.4.0/24</a></div><div> leftnexthop=%defaultroute</div>
<div> right=yyy.yyy.yyy.254</div><div> rightsourceip=192.168.123.7</div><div> rightsubnet=<a href="http://192.168.123.7/32">192.168.123.7/32</a></div><div> rightnexthop=%defaultroute</div><div>
auto=start</div><div> authby=secret</div><div> keylife=1200s</div><div> ikelifetime=3600s</div><div> </div><div><br></div><div>conn IPsec-bourke-atlanta2</div><div> left=www.www.www.2</div>
<div> leftsubnet=<a href="http://192.168.234.5/32">192.168.234.5/32</a></div><div> leftnexthop=%defaultroute</div><div> right=yyy.yyy.yyy.254</div><div> rightsourceip=192.168.234.7</div><div> rightsubnet=<a href="http://192.168.234.7/32">192.168.234.7/32</a></div>
<div> rightnexthop=%defaultroute</div><div> auto=start</div><div> authby=secret</div><div> keylife=1200s</div><div> ikelifetime=3600s</div><div># sample VPN connections, see /etc/ipsec.d/examples/</div>
<div><br></div><div><br></div><div>#Disable Opportunistic Encryption</div><div>include /etc/ipsec.d/examples/no_oe.conf</div></div><div><br></div><meta http-equiv="content-type" content="text/html; charset=utf-8">