[Openswan dev] Re: [PATCH] Openswan and OS X with NAT-T

[Paul Wouters]

On Mon, 26 Sep 2005, Michael Richardson wrote:

>  No, that's not the case at all.
>  That's what vendor IDs are for --- to work around bugs in your old code.

Peter's patch was backported to v2_4_X and I managed to successfully setup
an L2TP connection on MacOSX Tiger from behind NAT. It showed:

Sep 27 06:38:49 aivd pluto[22301]: packet from 209.222.54.61:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
Sep 27 06:38:49 aivd pluto[22301]: "west-l2tp-psk"[1] 209.222.54.61 #1: responding to Main Mode from unknown peer 209.222.54.61
Sep 27 06:38:49 aivd pluto[22301]: "west-l2tp-psk"[1] 209.222.54.61 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Sep 27 06:38:49 aivd pluto[22301]: "west-l2tp-psk"[1] 209.222.54.61 #1: STATE_MAIN_R1: sent MR1, expecting MI2
Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[1] 209.222.54.61 #1: ignoring Vendor ID payload [KAME/racoon]
Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[1] 209.222.54.61 #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[1] 209.222.54.61 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[1] 209.222.54.61 #1: STATE_MAIN_R2: sent MR2, expecting MI3
Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[1] 209.222.54.61 #1: Main mode peer ID is ID_IPV4_ADDR: '192.168.1.100'Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #1: deleting connection "west-l2tp-psk" instance with peer 209.222.54.61 {isakmp=#0/ipsec=#0}
Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #1: I did not send a certificate because I do not have one.
Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Sep 27 06:38:50 aivd pluto[22301]: | NAT-T: new mapping 209.222.54.61:500/4500)
Sep 27 06:38:50 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
Sep 27 06:38:51 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #2: responding to Quick Mode {msgid:f501fb46}
Sep 27 06:38:51 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Sep 27 06:38:51 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Sep 27 06:38:51 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Sep 27 06:38:51 aivd pluto[22301]: "west-l2tp-psk"[2] 209.222.54.61 #2: STATE_QUICK_R2: IPsec SA established {ESP=>0x020aea13 <0xa87f3c57 xfrm=AES_128-HMAC_SHA1 NATD=209.222.54.61:4500 DPD=none}

The strange thing is the line that says:

  	NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed

First, we are not really using RFC 3947 but the "apple bug" version
of it.  And second, both ends are not NAT'ed, only my MacOSX was
NAT'ed. aivd.xelerance.com, the other end, is on public IP. Is this the
expected behaviour from the patch? After all, it does work. But I find
the messages a bit confusing.

Thanks to Peter and Michael for picking this up!

Paul