[Openswan Users] impossible ISAKMP rekey using NAT-T ?

[Andreas Steffen]

Hi,

I have fixed this bug in strongswan-2.2.2 with the attached patch.

 From the strongswan-2.2.2 ChangeLog:

- Fixed a bug occuring with NAT-Traversal enabled when the responder
   suddenly turns initiator and the initiator cannot find a matching
   connection because of the floated IKE port 4500.

Regards

Andreas

Paul Wouters wrote:
> On Mon, 25 Oct 2004, albert agusti wrote:
> 
>> I'm trying to deploy a VPN ipsec between two nated host (for the moment
>> testing only gw-gw traffic). Both behind same DSL routers not doing
>> nothing like ipsec passthrough that could affect and both runing kernel
>> 2.6 and openswan 2.2.0. When I rise the tunnel all goes fine, ruted and
>> secured.
>>
>> The problem arises when timer for ISAKMP key reaches the limit. On both
>> logs at the ends, lines like those appear:
>>
>> pluto[4172]: packet from R.R.R.R:10075: received Vendor ID payload
>> [draft-ietf-ipsec-nat-t-ike-03]
>> pluto[4172]: packet from R.R.R.R:10075: received Vendor ID payload
>> [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 108
>> pluto[4172]: packet from R.R.R.R:10075: received Vendor ID payload
>> [draft-ietf-ipsec-nat-t-ike-00]
>> pluto[4172]: packet from R.R.R.R:10075: initial Main Mode message
>> received on 192.168.3.2:4500 but no connection has been authorized
>>
>> Key IS NEVER RENEGOTIATED!!, at the end the end SA expires, and some
>> time latter (at ipsec_life), tunnel goes down
> 
> 
> This is the third report of this in the last week, so I think we have
> a bug here. This email was the only one which actually contained some
> logfiles so we can better understand what is going on. I've filed it
> in the bug tracker, and hopefully we'll have this fixed soon.
> 
> Paul
> 
>> If I try the same but DISABLING NAT-T, and for my surprise all goes fine
>> and ISAKMP rekey can do it's job !!! Tunnel is not functional because I
>> need UDP encapsulation, but the rest is going OK. The question is: did I
>> miss something important ? the first sensation is that NAT-T is not
>> doing his job right. Message is displayed in pluto talking about mapping
>> between 500/4500, but the erros seems to be that it does not recognize
>> the peer :-(
>>
>> My config at both ends is very simple. Something like this (with obious
>> changes):
>>
>> conn albert
>>        left=%defaultroute
>>        leftid=@smaug.serialnet.net
>>        leftsubnet=192.168.3.11/32
>>        leftrsasigkey=0sA......
>>        right=R.R.R.R
>>        rightid=@glaurung.serialnet.net
>>        rightsubnet=192.168.1.10/32
>>        rightrsasigkey=0sAQOd......
>>
>> I've tested avoiding the use of %defaultroute and use the IP local
>> adresses, I've tested to define %myid an config setup, but nothing
>> changes.
>> Anybody knows what's going on?
>>
>> Thanks in advance
>> Albert Agustí

=======================================================================
Andreas Steffen                   e-mail: andreas.steffen at strongsec.com
strongSec GmbH                    home:   http://www.strongsec.com
Alter Zürichweg 20                phone:  +41 1 730 80 64
CH-8952 Schlieren (Switzerland)   fax:    +41 1 730 80 65
==========================================[strong internet security]===
-------------- next part --------------
--- strongswan-2.2.1/programs/pluto/ipsec_doi.c	Fri Sep 17 23:42:38 2004
+++ strongswan-2.2.2/programs/pluto/ipsec_doi.c	Sun Oct  3 21:12:27 2004
@@ -2963,10 +2963,18 @@
     struct payload_digest *const sa_pd = md->chain[ISAKMP_NEXT_SA];
     struct state *st;
     struct connection *c = find_host_connection(&md->iface->addr, pluto_port
-	, &md->sender, md->sender_port);
+				, &md->sender, md->sender_port);
     pb_stream r_sa_pbs;
 
     int vids_to_send = 0;
+    
+#ifdef NAT_TRAVERSAL
+    if (c == NULL && md->iface->ike_float)
+    {
+	c = find_host_connection(&md->iface->addr, NAT_T_IKE_FLOAT_PORT
+		, &md->sender, md->sender_port);
+    }
+#endif
     
     if (c == NULL)
     {