[Openswan Users] ignored or precessed delete SA message ?

[albert agusti]

Hello all, 

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.
kernel 2.6 and openswan 2.2.0 on both sides behind DSL routers doing
NAT.

Stable status form the Responder side :

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
000 "vpn-sc-sants":   ike_life: 3600s; ipsec_life: 48800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 0
000 "vpn-sc-sants":   policy: RSASIG+ENCRYPT+TUNNEL+PFS; prio: 16,26;
interface: eth0;
000 "vpn-sc-sants":   newest ISAKMP SA: #191; newest IPsec SA: #187;
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
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,
000 "vpn-sc-sants":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536
000 "vpn-sc-sants":   ESP algorithms wanted: 3_000-1, 3_000-2,
flags=-strict
000 "vpn-sc-sants":   ESP algorithms loaded: 3_000-1, 3_000-2,
flags=-strict
000 "vpn-sc-sants":   ESP algorithm newest: 3DES_0-HMAC_MD5;
pfsgroup=<Phase1>
000
000 #190: "vpn-sc-sants" STATE_MAIN_R3 (sent MR3, ISAKMP SA
established); EVENT_SA_REPLACE in 191s
000 #187: "vpn-sc-sants" STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 36802s; newest IPSEC; eroute owner
000 #187: "vpn-sc-sants" esp.5af32f74 at 217.125.26.237
esp.9c47c92e at 192.168.3.2 tun.0 at B.B.B.B tun.0 at 192.168.3.2
000 #191: "vpn-sc-sants" STATE_MAIN_R3 (sent MR3, ISAKMP SA
established); EVENT_SA_REPLACE in 3148s;  newest ISAKMP

When remote (Initiator) side does /etc/init.d/ipsec stop, Responder log
messages are:

Dec  8 13:25:27 fwstacoloma pluto[24576]: "vpn-sc-sants" #191: received
Delete SA(0x5af32f74) payload: deleting IPSEC State #187
Dec  8 13:25:27 fwstacoloma pluto[24576]: "vpn-sc-sants" #191: received
and ignored informational message
Dec  8 13:25:27 fwstacoloma pluto[24576]: "vpn-sc-sants" #190: received
Delete SA payload: deleting ISAKMP State #190
Dec  8 13:25:27 fwstacoloma pluto[24576]: packet from B.B.B.B:10516:
received and ignored informational message
Dec  8 13:25:27 fwstacoloma pluto[24576]: "vpn-sc-sants" #191: received
Delete SA payload: deleting ISAKMP State #191
Dec  8 13:25:27 fwstacoloma pluto[24576]: packet from B.B.B.B:10516:
received and ignored informational message

At this point, no SA's shown in Responder (all seems clean) and 
prospective erouted; eroute owner: #0 is on the connection table.

If ipsec start issued on remote end, log in Responder shows:
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]
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
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]
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

Retransmission of Main mode occur forever and tunnel does not come up. 

ipsec auto --delete <conn>
ipsec auto --add <conn>

or ipsec stop/start on the Responder pemits again the tunnel negotiation


Thanks in advance
Albert Asgutí
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20041208/69872947/attachment.htm