[Openswan Users] [Fwd: [strongSwan] Windows Rekeying with NAT-T]

[Paul Wouters]

On Mon, 25 Apr 2005, Ingo Brüll wrote:

> Gerald Richter postet to the strongswan mailinglist the following
> posting. I checked the source code from debian openswan 2.3.0-2 and saw
> that this patch was not included there. So i think this patch was not
> included in openswan, too. Could you check that, please ?

This patch has ben added to the patch queue. You can track process at:

http://bugs.xelerance.com/view.php?id=271

Paul

> -------- Original-Nachricht --------
> Betreff: [strongSwan] Windows Rekeying
> Datum: Sat, 23 Apr 2005 21:53:08 +0200
> Von: Gerald Richter <richter at ecos.de>
> Firma: ecos gmbh
> An: users at lists.strongswan.org
> Referenzen: <426A95A5.6070709 at rageofdivine.net>
> <426A9622.5090008 at strongsec.net>
>
> Hi,
>
> I still have issues with strongswan 2.4.1 and Windows ipsec/l2tp and
> rekeying&NAT-T.
>
> As long as there is no NAT involved it seems to work. As soon as the client
> behind a NAT gateway rekeying fails. Problems with ipsec sa rekeying can be
> solved (or worked around by the following patch (see at the end of the
> mail),
> which I already posted in November 04
> (http://lists.strongswan.org/pipermail/users/2004-November/000537.html),
> but
> it didn't made it into the release until now).
>
> The problem is that windows send an ID_FQDN and strongswan has to accept
> it. A
> similar workaround is already in the code for the initial connection setup,
> my patch make sure ID_FQDN is accepted during rekeying.
>
> With this patch it works until a ISAKMP rekeying, where it fails with the
> following messages:
>
> Apr 23 16:37:53 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: initiating Main Mode
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000002]
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: ignoring Vendor ID payload [FRAGMENTATION]
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: enabling possible NAT-traversal with method RFC 3947
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: NAT-Traversal: Only 0 NAT-D - Aborting NAT-Traversal negociation
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: Peer ID is ID_DER_ASN1_DN: 'DC=test, DC=testuml, OU=Benutzer,
> CN=bb53user'
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: issuer crl not found
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: ISAKMP SA established
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #34: initiating Quick Mode RSASIG+ENCRYPT {using isakmp#33}
> Apr 23 16:37:54 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: ignoring informational payload, type INVALID_ID_INFORMATION
> Apr 23 16:38:18 bb53 l2tpd[235]: check_control: control, cid = 0, Ns =
> 4, Nr =
> 471
> Apr 23 16:39:04 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #34: max number of retransmissions (2) reached STATE_QUICK_I1
> Apr 23 16:39:04 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #34: starting keying attempt 2 of an unlimited number
> Apr 23 16:39:04 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #35: initiating Quick Mode RSASIG+ENCRYPT to replace #34 {using isakmp#33}
> Apr 23 16:39:04 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: ignoring informational payload, type INVALID_ID_INFORMATION
>
> this repeats several times, and then
>
> Apr 23 16:49:33 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: cannot respond to IPsec SA request because no connection is known for
> 10.11.12.53:4500[DC=test, DC=testuml, OU=Ze
> Apr 23 16:49:33 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: sending encrypted notification INVALID_ID_INFORMATION to
> 10.11.12.1:4500
> Apr 23 16:49:34 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #43: max number of retransmissions (2) reached STATE_QUICK_I1
> Apr 23 16:49:34 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #43: starting keying attempt 11 of an unlimited number
> Apr 23 16:49:34 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #44: initiating Quick Mode RSASIG+ENCRYPT to replace #43 {using isakmp#33}
> Apr 23 16:49:34 bb53 pluto[11143]: "ipsec_test__bb53user"[1]
> 10.11.12.1:4500
> #33: ignoring informational payload, type INVALID_ID_INFORMATION
> Apr
>
> The invalid id information, is because strongswan sends the ip address,
> instead of the FQDN. Maybe the problem would be solved, if strongswan saves
> the FQDN it get from windows and uses it for rekeying as ID. At least this
> would suppress this error message
>
> Gerald
>
> --- programs/pluto/ipsec_doi.c.org      Mon Apr 18 08:11:10 2005
> +++ programs/pluto/ipsec_doi.c  Mon Apr 18 08:13:34 2005
> @@ -2714,6 +2714,13 @@
>     if (!decode_net_id(id, id_pbs, &net_temp, which))
>        return FALSE;
>
> +    /* Hack for MS 818043 NAT-T Update */
> +
> +    if (id -> isaiid_idtype == ID_FQDN)
> +       return TRUE ;
> +
> +    /* End Hack for MS 818043 NAT-T Update */
> +
>     if (!samesubnet(net, &net_temp)
>     || *protoid != id->isaiid_protoid || *port != id->isaiid_port)
>     {
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> http://lists.strongswan.org/mailman/listinfo/users
>
>
>