[Openswan Users] L2TP Data not Passed to Daemon (Possible NAT-T Problem?)

[Paul Wouters]

On Sun, 29 Oct 2006, Isaac Aaron wrote:

Perhaps this is a packet size issue. Try setting the external ethX interface
on your l2tp server to an mtu of 1472 and see if that helps?

Paul

> I have this very strange issue setting up L2TP/IPSEC connections with
> Windows XP SP2 when both the client and the server are behind NAT. While the
> setup works fine with clients not behind NAT, when a NAT'ed client connects,
> it completes the IPSEC negotiation successfully, but then the L2TP daemon
> does not "see" the transmitted L2TP packets.
> As mentioned, the same setup (same configuration, with the same L2TP daemon)
> does work with directly connected clients.
> "AssumeUDPEncapsulationContextOnSendRule" seems to have no effect here.
>
> tcpdump on ipsec0 does show the L2TP negotiation packets, but nothing seems
> to pick it up.
>
> Tcpdump:
> [root at fw root]# tcpdump -i ipsec0 -n
> tcpdump: listening on ipsec0
> 20:05:47.215210 85.159.160.201.l2tp > 10.254.254.2.l2tp:
> l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
> *BEARER_CAP() |...
> 20:05:48.148692 85.159.160.201.l2tp > 10.254.254.2.l2tp:
> l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
> *BEARER_CAP() |...
> 20:05:50.175890 85.159.160.201.l2tp > 10.254.254.2.l2tp:
> l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
> *BEARER_CAP() |...
> 20:05:50.487821 10.254.254.2.isakmp > 85.159.160.201.30510: isakmp: phase 1
> ? ident: [|sa] (DF)
> 20:05:54.175366 85.159.160.201.l2tp > 10.254.254.2.l2tp:
> l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
> *BEARER_CAP() |...
> 20:06:02.150956 85.159.160.201.l2tp > 10.254.254.2.l2tp:
> l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
> *BEARER_CAP() |...
> 20:06:03.488620 10.254.254.2.4500 > 85.159.160.201.30510:  udp 1 (DF)
> 20:06:10.489026 10.254.254.2.isakmp > 85.159.160.201.30510: isakmp: phase 1
> ? ident: [|sa] (DF)
> 20:06:12.147735 85.159.160.201.l2tp > 10.254.254.2.l2tp:
> l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
> *BEARER_CAP() |...
> 20:06:22.351028 10.254.254.2.4500 > 85.159.160.201.30510:  udp 72 (DF)
> 20:06:22.870241 10.254.254.2.4500 > 85.159.160.201.30510:  udp 88 (DF)
>
> Any ideas?
> Thanks,
> Isaac Aaron
>
> Relevant logs/files:
>
> /etc/ipsec.conf
> Please note that only l2tp_2 is relevant. The others are just attempts
> please disregard them. I did not delete them because they show up in the
> attached log and thought someone might ask.
>
> version 2.0
> config setup
>   klipsdebug=none
>   plutodebug="control parsing"
>   nat_traversal=yes
>   virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
>
> conn block
>     auto=ignore
>
> conn private
>     auto=ignore
>
> conn private-or-clear
>     auto=ignore
>
> conn clear-or-private
>     auto=ignore
>
> conn clear
>     auto=ignore
>
> conn packetdefault
>     auto=ignore
>
> conn l2tp_1
>     left=192.168.16.254
>     right=%any
>     pfs=no
>     leftprotoport=17/1701
>     rightprotoport=17/1701
>     authby=secret
>     auth=esp
>     esp=3des-md5-96
>     auto=add
>     keyingtries=3
>
> conn l2tp_2
>         type=transport
>     left=10.254.254.2
>     leftnexthop=10.254.254.1
>     right=%any
>     pfs=no
>     leftprotoport=17/1701
>     rightprotoport=17/1701
>   # uncommenting this on has no effect
>   #     rightsubnet=vhost:%no,%priv
>     authby=secret
>     auth=esp
>     esp=3des-md5-2048
>     auto=add
>     rekey=no
>     keyingtries=3
>
> conn l2tp_3
>     left=10.254.253.2
>     right=%any
>     pfs=no
>     leftprotoport=17/1701
>     rightprotoport=17/1701
>     authby=secret
>     auth=esp
>     esp=3des-md5-96
>     auto=add
>     keyingtries=3
>
> conn l2tp_4
>     left=192.168.252.44
>     right=%any
>     pfs=no
>     leftprotoport=17/1701
>     rightprotoport=17/1701
>     authby=secret
>     auth=esp
>     esp=3des-md5-96
>     auto=add
>     keyingtries=3
>
>
> .
> .
> DISCLAIMER: This mail message was scanned for malicious content by Quality Bytes Mail Security when leaving the gateway of Quality Bytes
> http://qb.q-bytes.com/qbms/?c=qb
> .
>

-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155