0000271: Windows Rekeying with NAT-T

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0000271

[Openswan] Pluto

minor

always

04-25-05 15:45

12-09-08 21:08

Reporter

paul

View Status

public

Assigned To

mcr

Priority

normal

Resolution

fixed

Status

closed

Product Version

Openswan 2.3.0

Summary

0000271: Windows Rekeying with NAT-T

Description

Von: Gerald Richter <richter@ecos.de>

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

Additional Information

Attached Files

pluto-natt.patch [^] (495 bytes) 04-25-05 15:45

Relationships

related to

0000294

closed

paul

NAT-T server behind NAT patch for 2.3.0

Notes
(0000501) paul 05-11-05 00:24	From: Norman Rasmussen <norman@rasmussen.org> Is this fixed in 2.3.1 or CVS? I'm currently testing with debian's 2.3.0-2 with Bernd's patch from the 24th of Feb 2005 users mailing list email. (it seems that the bottom half his patch got applied to 2.3.1) I've tried the natt patch supplied with this bug and it seems to make very little difference. (see http://www.darkskies.za.net/~norman/ipsec/ [^] and http://norman.rasmussen.org/79/ipsuccess-for-a-short-while/) [^] Having a look at my logs it seems that 1) Quick Mode fails, and then 2) after Main Mode succeeds, it quite happily deletes the new and old SA's instead of just the old SA. The bug report is guessing that pluto needs to be change to instead sending the ip address, it needs to send the FQDN with the peer name?

(0000693) ken 08-18-05 22:39	Should be resolved in recent 2.4.0dr builds.

(0000768) paul 08-27-05 02:05	put back to assigned, since the issue is closely related to a non-resolved issue

(0002094) paul 11-06-08 10:13	perhaps see also: http://support.microsoft.com/kb/957624 [^]

(0002129) paul 12-09-08 20:31	fixed a long long time ago

Issue History
Date Modified	Username	Field	Change
04-25-05 15:45	paul	New Issue
04-25-05 15:45	paul	File Added: pluto-natt.patch
04-25-05 16:00	paul	Status	new => assigned
04-25-05 16:00	paul	Assigned To	=> mcr
04-25-05 17:41	ibruell	Issue Monitored: ibruell
05-05-05 23:50	normanr	Issue Monitored: normanr
05-06-05 11:42	paul	Relationship added	related to 0000294
05-11-05 00:24	paul	Note Added: 0000501
08-18-05 22:39	ken	Status	assigned => resolved
08-18-05 22:39	ken	Fixed in Version	=> Openswan 2.4.0dr8
08-18-05 22:39	ken	Resolution	open => fixed
08-18-05 22:39	ken	Note Added: 0000693
08-27-05 02:05	paul	Note Added: 0000768
08-27-05 02:05	paul	Status	resolved => assigned
11-06-08 10:13	paul	Note Added: 0002094
12-09-08 20:31	paul	Status	assigned => resolved
12-09-08 20:31	paul	Note Added: 0002129
12-09-08 21:08	paul	Status	resolved => closed

Mantis 1.0.7[^]

75 total queries executed.
49 unique queries executed.