[Openswan Users] NAT-T problem

[Toby Chamberlain]

Hi Peter,

I had a similar problem to this... it was because the l2tp daemon was 
sending packets from the internal IP not the public one.  tcpdump showed 
unencrypted packets from 1024->1701 instead of the expected 1701->1701 (the 
packets were being NATted on the way out). If you have similar symptoms you 
might be able to fix it by forcing your l2tpd to use a specific IP. I don't 
know how to do this in OpenL2TP, but with xl2tpd it's with the "listen-addr" 
config entry.

Toby


--------------------------------------------------
From: "Peter Laczko" <peetie470 at gmail.com>
Sent: Tuesday, August 19, 2008 6:46 AM
To: <users at openswan.org>
Subject: [Openswan Users] NAT-T problem

> Hi,
>
> If any of you have a working Openswan road warrior setup with the client
> behind a NAT and the server NOT behind a NAT, please help.
>
> The IPSec connection seems to come up fine, and packets client-->server
> arrive OK, however, response from the server (the L2TP server) does not 
> get
> encrypted and gets transmitted in plaintext.
>
> I ran an "ip xfrm policy" which says:
>
> # ip xfrm policy
> src 192.168.2.20/32 dst 89.a.b.c/32 proto udp
>        dir in priority 2080 ptype main
>        tmpl src 0.0.0.0 dst 0.0.0.0
>                proto esp reqid 16417 mode transport
> src 89.a.b.c/32 dst 192.168.2.20/32 proto udp
>        dir out priority 2080 ptype main
>        tmpl src 0.0.0.0 dst 0.0.0.0
>                proto esp reqid 16417 mode transport
>
> (89.a.b.c is the server's public IP address, 192.168.2.20 is the client's
> private IP address.)
>
> Is this normal? I mean, the private address in the rules.
>
> I tried to rule out any L2TP server issues and stopped the server. Then I
> wrote a script that sends an UDP packet to the given IP and port address,
> and tried to "emulate" L2TP server response with it (by sending UDP 
> packets
> from port 1701 to port 1701 on the client).
>
> - When sending to 89.d.e.f, the client's public address, the packet 
> arrives
> unencrypted, just as if it was the L2TP server's response (OpenL2TP
> actually)
> - When sending to 192.168.2.20, the send() call on the socket never 
> returns
> and the script hangs. It returns only when IPsec SA is torn down. When
> running "ip xfrm monitor", the following entry gets into the log right 
> after
> running the script:
>
> acquire proto esp
>  sel src 89.a.b.c/32 dst 192.168.2.20/32 proto udp sport 1701 dport 1701
>  policy src 89.a.b.c/32 dst 192.168.2.20/32 proto udp
>        dir out priority 2080 ptype main
>        tmpl src 0.0.0.0 dst 0.0.0.0
>                proto esp reqid 16425 mode transport
>
> and that's it, nothing goes out, and the script hangs.
>
> Please help me, I'm stuck. If it helps, I'll post whatever logs necessary, 
> I
> just didn't want to start with a multi-thousand line mail.
>
> Thank you so much,
> Peter
>



> _______________________________________________
> 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
>