<br>Hi list,<br><br>We encountered a bug in openswan 2.4.7 running on debian kernel 2.6.8 with Klips stack that crashes our entire production platform tunnels !!<br><br>After investigations, this is due to a new connection we have just declared that seems perfectly normal compared to our hundred others. When this connections goes up, pluto end with a "Segmentation fault", then pluto is endless restarted and faulting every 30 seconds making all other tunnels unusable !
<br><br><br>Here are the pluto logs :<br><br>Mar 2 13:08:44 ipsec-platform pluto[21291]: "faulty_tunnel" #76: responding to Main Mode<br>Mar 2 13:08:44 ipsec-platform pluto[21291]: "faulty_tunnel" #76: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
<br>Mar 2 13:08:44 ipsec-platform pluto[21291]: "faulty_tunnel" #76: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM<br>Mar 2 13:08:44 ipsec-platform pluto[21291]: "faulty_tunnel" #76: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
<br>Mar 2 13:08:44 ipsec-platform pluto[21291]: "faulty_tunnel" #76: STATE_MAIN_R1: sent MR1, expecting MI2<br>Mar 2 13:08:47 ipsec-platform pluto[21291]: "faulty_tunnel" #76: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
<br>Mar 2 13:08:47 ipsec-platform pluto[21291]: "faulty_tunnel" #76: STATE_MAIN_R2: sent MR2, expecting MI3<br>Mar 2 13:08:53 ipsec-platform pluto[21291]: "faulty_tunnel" #76: Main mode peer ID is ID_IPV4_ADDR: '
222.126.XXX.YYY'<br>Mar 2 13:08:53 ipsec-platform pluto[21291]: "faulty_tunnel" #76: I did not send a certificate because I do not have one.<br>Mar 2 13:08:53 ipsec-platform pluto[21291]: "faulty_tunnel" #76: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
<br>Mar 2 13:08:53 ipsec-platform pluto[21291]: "faulty_tunnel" #76: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cip her=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}<br>Mar 2 13:08:53 ipsec-platform pluto[21291]: "faulty_tunnel" #76: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
<br>Mar 2 13:08:57 ipsec-platform pluto[21291]: "faulty_tunnel" #77: we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION<br>Mar 2 13:08:57 ipsec-platform pluto[21291]: "faulty_tunnel" #77: sending encrypted notification NO_PROPOSAL_CHOSEN to
222.126.XXX.YYY:500<br>Mar 2 13:09:08 ipsec-platform ipsec__plutorun: Restarting Pluto subsystem...<br><br><br>And in the syslog :<br><br>Mar 2 13:08:57 ipsec-platform ipsec__plutorun: /usr/local/lib/ipsec/_plutorun: line 1: 21291 Segmentation fault /usr/local/libexec/ipsec/pluto -
<br>-nofork --secretsfile /etc/ipsec.secrets --ipsecdir /etc/ipsec.d --debug-none --use-auto --uniqueids --nat_traversal --nhelpers 0<br>Mar 2 13:08:57 ipsec-platform ipsec__plutorun: !pluto failure!: exited with error status 139 (signal 11)
<br>Mar 2 13:08:57 ipsec-platform ipsec__plutorun: restarting IPsec after pause...<br>Mar 2 13:09:07 ipsec-platform kernel: IPSEC EVENT: KLIPS device ipsec0 shut down.<br>Mar 2 13:09:07 ipsec-platform ipsec_setup: ...Openswan IPsec stopped
<br>Mar 2 13:09:07 ipsec-platform ipsec_setup: Stopping Openswan IPsec...<br>Mar 2 13:09:07 ipsec-platform ipsec_setup: Removing orphaned /var/run/pluto/pluto.pid:<br>Mar 2 13:09:08 ipsec-platform ipsec_setup: KLIPS debug `none'
<br>Mar 2 13:09:08 ipsec-platform ipsec_setup: KLIPS ipsec0 on eth0:1 89.234.ZZZ.AAA/255.255.255.240 broadcast 89.234.ZZZ.EEE<br>Mar 2 13:09:08 ipsec-platform ipsec_setup: ...Openswan IPsec started<br>Mar 2 13:09:08 ipsec-platform ipsec_setup: Restarting Openswan IPsec
2.4.7...<br>Mar 2 13:09:08 ipsec-platform ipsec__plutorun: ipsec_auto: fatal error in "common": connection has no "right" parameter specified<br>Mar 2 13:09:17 ipsec-platform kernel: ipsec0: no IPv6 routers present
<br>Mar 2 13:09:36 ipsec-platform ipsec__plutorun: /usr/local/lib/ipsec/_plutorun: line 1: 10404 Segmentation fault /usr/local/libexec/ipsec/pluto -<br>-nofork --secretsfile /etc/ipsec.secrets --ipsecdir /etc/ipsec.d --debug-none --use-auto --uniqueids --nat_traversal --nhelpers 0
<br>Mar 2 13:09:36 ipsec-platform ipsec__plutorun: !pluto failure!: exited with error status 139 (signal 11)<br>Mar 2 13:09:36 ipsec-platform ipsec__plutorun: restarting IPsec after pause...<br><br>[And so on...]<br><br>
The line "we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION" appears in the auth-log everytime the crash occurs and only at the crash time, so I suspect it should be linked.<br><br><br>Here is the config file for this connection :
<br><br>version 2.0 <br>config setup<br> nat_traversal=yes<br> nhelpers=0<br> interfaces="ipsec0=eth0:1"<br> klipsdebug=none<br> plutodebug=none<br><br>conn faulty_tunnel<br> also=common
<br> ike=3des-sha-modp1024<br> ikelifetime=28800s<br> esp=3des-sha1<br> keylife=3600s<br> pfs=yes<br> right=222.126.XXX.XXX<br> rightsubnet=222.126.XXX.YYY/32<br><br>conn common
<br> authby=secret<br> type=tunnel<br> auto=add<br> dpddelay=30<br> dpdtimeout=10<br> # dpdaction=restart<br> dpdaction=hold<br> compress=yes<br> left=89.234.ZZZ.AAA
<br> leftsubnet=89.234.ZZZ.BBB/32<br> leftsourceip=89.234.ZZZ.CCC<br> leftnexthop=89.234.ZZZ.DDD<br><br><br>As our partner also use openswan and it seems that the bug need the 2 end part to be set up to appear, we will try to get their exact configuration file also.
<br><br><br>I saw an archive mail from Matthias Haas on Jan 15 in the dev list that seem to found the same bug and suggest this patch :<br><br>--- openswan-2.4.7/programs/pluto/demux.c Fri Jan 12 11:35:21 2007<br>+++ openswan-2.4.7-debug
/programs/pluto/demux.c Fri Jan 12 12:16:07 2007<br>@@ -2411,7 +2411,7 @@<br> * we can only be in calculating state if state is ignore,<br> * or suspended.<br> */<br>- passert(result == STF_IGNORE || result == STF_SUSPEND ||
<br>st->st_calculating==FALSE);<br>+ passert(result == STF_INLINE || result == STF_IGNORE || result ==<br>STF_SUSPEND || st->st_calculating==FALSE);<br><br><br>The good news is that the problem is perfectly reproduceable, but we would not do so before we moved the tunnel with our partner to a staging platform to perform more test and investigations, not to impact all our production, which could be done next week.
<br><br>Do you, developpers, need special further test from us, and do you think we could apply this patch on our production server?<br><br><br>Thanks,<br>Jean-Michel Bonnefond.<br><br>