[Openswan dev] KLIPS: Source IP of the L2TP packet (1701) in NATed environment
david_mccullough at mcafee.com
Thu May 6 18:34:30 EDT 2010
Jivin hiren joshi lays it down ...
> This is related to L2TP in NATed environment (NAT_TRAVERSAL & TRANSPORT MODE).
> New KLIPS (openswan-2.6.24/linux/net/ipsec/ipsec_rcv.c::ipsec_rcv_cleanup
> at line#1618)
> overwrites source address with NATT-OA (and recalculates IP checksum).
> As a result, decrypted packet (from ipsecX device) appears with
> original IP of the L2TP client
> as its source IP. Ans so its reply packet is destined to the original
> IP of the L2TP client.
> However the eroute installed for the connection requires the NATed IP
> as packet's destination.
> x' (leftsubnet) --- x (left) === y (NATbox) --- z (L2TP client)
> eroute installed:
> x' --> y => y
> packet's source - destination:
> x' -> z
> The packet gets dropped as it gets injected into the tunnel.
> Old KLIPS (openswan-2.4.9/linux/net/ipsec/ipsec_rcv.c::ipsec_rcv_decap
> at line#868)
> was using NATT-OA only to fix udp/tcp checksum. It was modifying the
> source IP of the packet.
> I don't have configurations and logs with me right now.
> I don't know if I am the only one to observe this. I am running old
> (2.4.9) pluto with new (2.6.24) KLIPS.
> Request L2TP users to share their input on this.
If you can, I think the latest 2.6.26 (git) should have that fixed.
I can't remember whether it was kernel or user or a bit of both but IIRC
L2TP/klips/NAT is all fairly happy in the latest git code at the moment.
David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
More information about the Dev