[Openswan dev] KLIPS 2.4.0rc1 without NAT-T crashes on NAT-T conn

[Paul Wouters]

(submitted as http://bugs.xelerance.com/view.php?id=392)

After various reports about non-working L2TP tunnels with recent KLIPS, I
recreated a test L2TP server. I used the latest 2.6.11 based fedora kernel
(2.6.11-1.35_FC3) and KLIPS 2.4.0rc1 using PSK based IPsec/L2TP. I also
ran a test using NETKEY from 2.6.11-1.35_FC3.

ExecSUM: KLIPS without NAT-T patch to kernel crashed upon NAT-T connection.
          NETKEY worked fine, and I successfully had an L2TP connection up.

For the crashing log, I saw:

Aug 21 19:00:42 aivd pluto[23721]: packet from 209.222.54.61:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Aug 21 19:00:42 aivd pluto[23721]: packet from 209.222.54.61:500: ignoring Vendor ID payload [FRAGMENTATION]
Aug 21 19:00:42 aivd pluto[23721]: packet from 209.222.54.61:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
Aug 21 19:00:42 aivd pluto[23721]: packet from 209.222.54.61:500: ignoring Vendor ID payload [Vid-Initial-Contact]
Aug 21 19:00:42 aivd pluto[23721]: "west-l2tp-psk"[2] 209.222.54.61 #2: responding to Main Mode from unknown peer 209.222.54.61
Aug 21 19:00:42 aivd pluto[23721]: "west-l2tp-psk"[2] 209.222.54.61 #2: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Aug 21 19:00:42 aivd pluto[23721]: "west-l2tp-psk"[2] 209.222.54.61 #2: STATE_MAIN_R1: sent MR1, expecting MI2
Aug 21 19:00:43 aivd pluto[23721]: "west-l2tp-psk"[2] 209.222.54.61 #2: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
Aug 21 19:00:43 aivd pluto[23721]: "west-l2tp-psk"[2] 209.222.54.61 #2: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Aug 21 19:00:43 aivd pluto[23721]: "west-l2tp-psk"[2] 209.222.54.61 #2: STATE_MAIN_R2: sent MR2, expecting MI3
Aug 21 19:00:44 aivd pluto[23721]: "west-l2tp-psk"[2] 209.222.54.61 #2: Main mode peer ID is ID_FQDN: '@vaio'
Aug 21 19:00:44 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #2: deleting connection "west-l2tp-psk" instance with peer 209.222.54.61 {isakmp=#0/ipsec=#0}
Aug 21 19:00:44 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #2: I did not send a certificate because I do not have one.
Aug 21 19:00:44 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #2: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Aug 21 19:00:44 aivd pluto[23721]: | NAT-T: new mapping 209.222.54.61:500/4500)
Aug 21 19:00:44 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #2: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}
Aug 21 19:00:44 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #3: responding to Quick Mode {msgid:81cf0edb}
Aug 21 19:00:44 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #3: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Aug 21 19:00:44 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #3: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Aug 21 19:00:45 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #3: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Aug 21 19:00:45 aivd pluto[23721]: "west-l2tp-psk"[3] 209.222.54.61 #3: STATE_QUICK_R2: IPsec SA established {ESP=>0x06b76251 <0x5e49f38c xfrm=3DES_0-HMAC_MD5 NATD=209.222.54.61:4500 DPD=none}

==> /var/log/messages <==
Aug 21 19:00:44 aivd kernel: klips:pfkey_msg_parse: ext type 27(X-NAT-T-sport) unknown, ignoring.
Aug 21 19:00:44 aivd kernel: klips:pfkey_msg_parse: ext type 28(X-NAT-T-dport) unknown, ignoring.
Aug 21 19:00:44 aivd kernel: klips:pfkey_msg_parse: ext type 29(X-NAT-T-OA) unknown, ignoring.
Aug 21 19:00:44 aivd kernel: klips:pfkey_msg_parse: ext type 30(<NULL>) unknown, ignoring.
Aug 21 19:00:45 aivd kernel: klips:pfkey_msg_parse: ext type 27(X-NAT-T-sport) unknown, ignoring.
Aug 21 19:00:45 aivd kernel: klips:pfkey_msg_parse: ext type 28(X-NAT-T-dport) unknown, ignoring.
Aug 21 19:00:45 aivd kernel: klips:pfkey_msg_parse: ext type 29(X-NAT-T-OA) unknown, ignoring.
Aug 21 19:00:45 aivd kernel: klips:pfkey_msg_parse: ext type 30(<NULL>) unknown, ignoring.

The machine then locked up completely. Since the Fedora stock kernel had no NAT-T support for KLIPS,
the failure is understandable, but it should not lock up the machine. No kernel panic was logged.

Running the same version userland openswan with the NETKEY module for 2.6.11-1.35_FC3
resulted in a working L2TP connection.

Paul