[Openswan dev] KLIPS: Source IP of the L2TP packet (1701) in NATed environment

[David McCullough]

Jivin hiren joshi lays it down ...
> Hello,
> 
> 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.
> 
> Network:
> 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.

Cheers,
Davidm

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org