[Openswan Users] NAT-T problem

Peter Laczko peetie470 at gmail.com
Mon Aug 18 16:46:26 EDT 2008


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080818/b984ae66/attachment.html 


More information about the Users mailing list