<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
Hello all, <BR>
<BR>
Some mails above I spoke of a problem that arises when one of the openswan gateways that hold an IPsec tunnel restarts (lets say Initiator). From this point, the tunnel is only recovered if manual restart of IPsec process is done on the Responder, or manual (ipsec auto --delete <conn> and ipsec auto --add <conn>) is launched. I'm totally lost about the reason of this behaviour (suspecting some relation with NAT-T) but obviously it kills any serious production deployment. Here I paste you what is shown in Responder end when Initiator restarts. Does it seems to you the expected information ? Please, any feedback will be appreciated.<BR>
kernel 2.6 and openswan 2.2.0 on both sides behind DSL routers doing NAT.<BR>
<BR>
Stable status form the Responder side :<BR>
<BR>
000 "vpn-sc-sants": 10.10.0.0/16===192.168.3.2:4500[@santacoloma.serialnet.net]---192.168.3.1...B.B.B.B:10516[@sants.serialnet.net]===192.168.1.64/26; erouted; eroute owner: #187<BR>
000 "vpn-sc-sants": ike_life: 3600s; ipsec_life: 48800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0<BR>
000 "vpn-sc-sants": policy: RSASIG+ENCRYPT+TUNNEL+PFS; prio: 16,26; interface: eth0;<BR>
000 "vpn-sc-sants": newest ISAKMP SA: #191; newest IPsec SA: #187;<BR>
000 "vpn-sc-sants": IKE algorithms wanted: 5_000-1-5, 5_000-1-2, 5_000-2-5, 5_000-2-2, flags=-strict<BR>
000 "vpn-sc-sants": IKE algorithms found: 5_192-1_128-5, 5_192-1_128-2, 5_192-2_160-5, 5_192-2_160-2,<BR>
000 "vpn-sc-sants": IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536<BR>
000 "vpn-sc-sants": ESP algorithms wanted: 3_000-1, 3_000-2, flags=-strict<BR>
000 "vpn-sc-sants": ESP algorithms loaded: 3_000-1, 3_000-2, flags=-strict<BR>
000 "vpn-sc-sants": ESP algorithm newest: 3DES_0-HMAC_MD5; pfsgroup=<Phase1><BR>
000<BR>
000 #190: "vpn-sc-sants" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 191s<BR>
000 #187: "vpn-sc-sants" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 36802s; newest IPSEC; eroute owner<BR>
000 #187: "vpn-sc-sants" esp.5af32f74@217.125.26.237 esp.9c47c92e@192.168.3.2 <A HREF="mailto:tun.0@B.B.B.B"><U>tun.0@B.B.B.B</U></A> <A HREF="mailto:tun.0@192.168.3.2"><U>tun.0@192.168.3.2</U></A><BR>
000 #191: "vpn-sc-sants" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3148s; newest ISAKMP<BR>
<BR>
When remote (Initiator) side does /etc/init.d/ipsec stop, Responder log messages are:<BR>
<BR>
Dec 8 13:25:27 fwstacoloma pluto[24576]: "vpn-sc-sants" #191: received Delete SA(0x5af32f74) payload: deleting IPSEC State #187<BR>
Dec 8 13:25:27 fwstacoloma pluto[24576]: "vpn-sc-sants" #191: received and ignored informational message<BR>
Dec 8 13:25:27 fwstacoloma pluto[24576]: "vpn-sc-sants" #190: received Delete SA payload: deleting ISAKMP State #190<BR>
Dec 8 13:25:27 fwstacoloma pluto[24576]: packet from B.B.B.B:10516: received and ignored informational message<BR>
Dec 8 13:25:27 fwstacoloma pluto[24576]: "vpn-sc-sants" #191: received Delete SA payload: deleting ISAKMP State #191<BR>
Dec 8 13:25:27 fwstacoloma pluto[24576]: packet from B.B.B.B:10516: received and ignored informational message<BR>
<BR>
At this point, no SA's shown in Responder (all seems clean) and prospective erouted; eroute owner: #0 is on the connection table.<BR>
<BR>
If ipsec start issued on remote end, log in Responder shows:<BR>
Dec 8 13:28:27 fwstacoloma pluto[24576]: packet from B.B.B.B:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]<BR>
Dec 8 13:28:27 fwstacoloma pluto[24576]: packet from B.B.B.B:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 108<BR>
Dec 8 13:28:27 fwstacoloma pluto[24576]: packet from B.B.B.B:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]<BR>
Dec 8 13:28:27 fwstacoloma pluto[24576]: packet from B.B.B.B:500: initial Main Mode message received on 192.168.3.2:500 but no connection has been authorized<BR>
<BR>
Retransmission of Main mode occur forever and tunnel does not come up. <BR>
<BR>
ipsec auto --delete <conn><BR>
ipsec auto --add <conn><BR>
<BR>
or ipsec stop/start on the Responder pemits again the tunnel negotiation<BR>
<BR>
<BR>
Thanks in advance<BR>
Albert Asgutí
</BODY>
</HTML>