[Openswan Users] NAT-Traversal not working with Openswan 2.6.20

[Paul Wouters]

On Wed, 4 Mar 2009, Danny Woodruffe wrote:

> Hello, I cannot get NAT-Traversal working with Openswan, but the
> configuration works well when there is no natting involved.
>
> I'm using XP SP3 and openswan-2.6.20 running on Centos-5.2
>
> 1. The AssumeUDPEncapsulationContextOnSendRule value on the XP client is
> set to 2.
> 2. The client internal IP is 192.168.2.111
> 3. The natted IP is 84.201.183.1
> 4. The server IP is  84.201.191.137

> conn west-l2tp-psk
>    left=84.201.191.137
>    leftnexthop=84.201.191.129
>    leftprotoport=17/1701
>    rightprotoport=17/%any
>    rightsubnet=vhost:,%priv,%no

There is a typo there that might matter. The first comma is bogus.
If that does not fix it, please try using rightprotoport=17/0 or 17/1701.

>    right=%any
>    auto=add
>    authby=secret

NAT and PSK do not work well together. Try using X.509 certs instead.
The ID you are using now is based on the IP, which is NATTED.

Paul

>
>
>
>
>
> 6. Here is the eror message:
>
> Mar  4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:
> ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
> Mar  4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:
> ignoring Vendor ID payload [FRAGMENTATION]
> Mar  4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:
> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set
> to=106
> Mar  4 10:49:01 s10-mail pluto[11001]: packet from 84.201.183.1:500:
> ignoring Vendor ID payload [Vid-Initial-Contact]
> Mar  4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: responding to Main Mode from unknown peer 84.201.183.1
> Mar  4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Mar  4 10:49:01 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: STATE_MAIN_R1: sent MR1, expecting MI2
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer
> is NATed
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: STATE_MAIN_R2: sent MR2, expecting MI3
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: Main mode peer ID is ID_FQDN: '@lixxus-35e4ff1a'
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[11] 84.201.183.1
> #6: switched from "west-l2tp-psk" to "west-l2tp-psk"
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: deleting connection "west-l2tp-psk" instance with peer 84.201.183.1
> {isakmp=#0/ipsec=#0}
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: new NAT mapping for #6, was 84.201.183.1:500, now 84.201.183.1:4500
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
> group=modp2048}
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar  4 10:49:02 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar  4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar  4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar  4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar  4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar  4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar  4 10:49:04 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar  4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar  4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar  4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar  4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar  4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar  4 10:49:08 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar  4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: peer client type is FQDN
> Mar  4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: Applying workaround for MS-818043 NAT-T bug
> Mar  4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: IDci was FQDN: T\311\277\211, using NAT_OA=192.168.2.111/32 as IDci
> Mar  4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: the peer proposed: 84.201.191.137/32:17/1701 ->
> 192.168.2.111/32:17/0
> Mar  4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: cannot respond to IPsec SA request because no connection is known
> for
> 84.201.191.137<84.201.191.137>[+S=C]:17/1701...84.201.183.1[@lixxus-35e4
> ff1a,+S=C]:17/%any===192.168.2.111/32
> Mar  4 10:49:16 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: sending encrypted notification INVALID_ID_INFORMATION to
> 84.201.183.1:4500
> Mar  4 10:49:30 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1
> #6: received Delete SA payload: deleting ISAKMP State #6
> Mar  4 10:49:30 s10-mail pluto[11001]: "west-l2tp-psk"[12] 84.201.183.1:
> deleting connection "west-l2tp-psk" instance with peer 84.201.183.1
> {isakmp=#0/ipsec=#0}
> Mar  4 10:49:30 s10-mail pluto[11001]: packet from 84.201.183.1:4500:
> received and ignored informational message
>
>
> Any advice would be greatly appreciated.
>
> Thanks
>
> Danny
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>