[Openswan Users] L2TP Data not Passed to Daemon (Possible NAT-T Problem?)
Isaac Aaron
e-tsik at q-bytes.com
Wed Nov 1 02:34:52 EST 2006
Thank you for the reply
MTU did not seem to work. Still the same result:
[root at fw root]# tcpdump -i ipsec0 -n
tcpdump: listening on ipsec0
18:46:18.694255 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() |...
18:46:19.674923 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() |...
18:46:21.700183 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() |...
18:46:24.017256 10.254.254.2.isakmp > 85.159.160.201.18495: isakmp: phase 1
? ident: [|sa] (DF)
18:46:25.646409 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() |...
18:46:33.644734 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() |...
18:46:35.017930 10.254.254.2.4500 > 85.159.160.201.18495: udp 1 (DF)
18:46:43.697096 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() |...
18:46:44.018481 10.254.254.2.isakmp > 85.159.160.201.18495: isakmp: phase 1
? ident: [|sa] (DF)
18:46:53.877125 10.254.254.2.4500 > 85.159.160.201.18495: udp 72 (DF)
18:46:54.438481 10.254.254.2.4500 > 85.159.160.201.18495: udp 88 (DF)
And on the external interface:
[root at fw root]# tcpdump -i eth1 'port 500 || port 4500 || proto 50' -n
tcpdump: listening on eth1
18:46:13.063059 85.159.160.201.19259 > 10.254.254.2.isakmp: isakmp: phase 1
I ident: [|sa]
18:46:13.759053 85.159.160.201.19259 > 10.254.254.2.isakmp: isakmp: phase 1
I ident: [|sa]
18:46:13.879978 10.254.254.2.isakmp > 85.159.160.201.19259: isakmp: phase 1
R ident: [|sa] (DF)
18:46:14.528805 85.159.160.201.19259 > 10.254.254.2.isakmp: isakmp: phase 1
I ident: [|ke]
18:46:14.852242 10.254.254.2.isakmp > 85.159.160.201.19259: isakmp: phase 1
R ident: [|sa] (DF)
18:46:15.499397 10.254.254.2.isakmp > 85.159.160.201.19259: isakmp: phase 1
R ident: [|ke] (DF)
18:46:15.807141 85.159.160.201.18495 > 10.254.254.2.4500: udp 72
18:46:15.861511 85.159.160.201.18495 > 10.254.254.2.4500: udp 72
18:46:16.426086 10.254.254.2.4500 > 85.159.160.201.18495: udp 72 (DF)
18:46:16.689624 10.254.254.2.4500 > 85.159.160.201.18495: udp 72 (DF)
18:46:16.901216 85.159.160.201.18495 > 10.254.254.2.4500: udp 304
18:46:17.727409 85.159.160.201.18495 > 10.254.254.2.4500: udp 304
18:46:18.458840 10.254.254.2.4500 > 85.159.160.201.18495: udp 168 (DF)
18:46:18.659469 85.159.160.201.18495 > 10.254.254.2.4500: udp 56
18:46:18.694255 85.159.160.201.18495 > 10.254.254.2.4500: udp 140
18:46:19.674923 85.159.160.201.18495 > 10.254.254.2.4500: udp 140
18:46:21.700183 85.159.160.201.18495 > 10.254.254.2.4500: udp 140
18:46:24.017279 10.254.254.2.isakmp > 85.159.160.201.18495: isakmp: phase 1
R ident: [|sa] (DF)
18:46:24.659764 85.159.160.201.18495 > 10.254.254.2.4500: udp 1
18:46:25.646409 85.159.160.201.18495 > 10.254.254.2.4500: udp 140
18:46:33.644734 85.159.160.201.18495 > 10.254.254.2.4500: udp 140
18:46:35.017947 10.254.254.2.4500 > 85.159.160.201.18495: udp 1 (DF)
18:46:43.697096 85.159.160.201.18495 > 10.254.254.2.4500: udp 140
18:46:44.018502 10.254.254.2.isakmp > 85.159.160.201.18495: isakmp: phase 1
R ident: [|sa] (DF)
18:46:44.683268 85.159.160.201.18495 > 10.254.254.2.4500: udp 1
18:46:53.668687 85.159.160.201.18495 > 10.254.254.2.4500: udp 72
18:46:53.696643 85.159.160.201.18495 > 10.254.254.2.4500: udp 88
18:46:53.877148 10.254.254.2.4500 > 85.159.160.201.18495: udp 72 (DF)
18:46:54.438499 10.254.254.2.4500 > 85.159.160.201.18495: udp 88 (DF)
Just for comparison, if I kill the l2tp daemon and connect from a real IP,
the sniffer shows icmp port unreachable messages:
[root at fw root]# tcpdump -i ipsec0 -n
tcpdump: listening on ipsec0
18:53:33.322759 85.159.165.42.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() |...
18:53:34.253772 85.159.165.42.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() |...
18:53:36.252778 85.159.165.42.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() |...
18:53:36.252887 10.254.254.2 > 85.159.165.42: icmp: 10.254.254.2 udp port
l2tp unreachable [tos 0xc0]
18:53:40.280155 85.159.165.42.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() |...
18:53:40.280246 10.254.254.2 > 85.159.165.42: icmp: 10.254.254.2 udp port
l2tp unreachable [tos 0xc0]
18:53:48.311990 85.159.165.42.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() |...
18:53:48.312069 10.254.254.2 > 85.159.165.42: icmp: 10.254.254.2 udp port
l2tp unreachable [tos 0xc0]
18:53:50.605183 10.254.254.2.4500 > 85.159.165.42.4500: udp 1 (DF)
18:53:58.321400 85.159.165.42.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() |...
18:53:58.321480 10.254.254.2 > 85.159.165.42: icmp: 10.254.254.2 udp port
l2tp unreachable [tos 0xc0]
18:54:08.504178 10.254.254.2.4500 > 85.159.165.42.4500: udp 72 (DF)
18:54:09.040009 10.254.254.2.4500 > 85.159.165.42.4500: udp 88 (DF)
Thanks,
Isaac Aaron
-----Original Message-----
From: Paul Wouters [mailto:paul at xelerance.com]
Sent: Monday, October 30, 2006 5:31 PM
To: Isaac Aaron
Cc: Users at openswan.org
Subject: Re: [Openswan Users] L2TP Data not Passed to Daemon (Possible NAT-T
Problem?)
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
.
.
Quality Bytes MailXpress Message:
Spam? Click the link below
http://10.0.0.3:16000/spam.php?spam=1&qid=00000000000233e7
.
.
.
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
.
More information about the Users
mailing list