[Openswan Users] L2TP/IPsec with NAT-passthrough - almost fixed ; -)

[Andreas Kemper]

Hi,

>  > Hmm, interesting parameter. Never seen/documented before. I guess it
>  > means "no carriage return send?"
>
> No, it means do not send Certificate Request. It can't be involved
> in the problem at hand, unless there is some MTU problem.
Yes, I got it in the meantime. But its definitely not the problem, since the 
IPsec-tunnel can be established without any problems either using PSK or 
certs.

>  > No, NAT-T definitely does not work with these passthrough routers. I
>  > tried it once with a "real" NAT-device (by means of "iptables" on a
>  > linux box), where it's been working properly.
>
> What do you mean with this? You used NAT-T with an old IP masquerading
> Linux box in place of the SMC, and it worked? If so, that would indicate
Yes, unfortunately passthrough can't be disabled as far as I know...

> a clear problem with IPsec passthrough mangling by the SMC.
Yes, but I don't wan't to setup an extra PC as linux router, while only being 
temporarily online with my notebook.
A suitable alternative might be using the Linksys WRT54g router.

> - What distribution are you using and what version? Are you using the
>    standard kernel, and if not, where did you get it?
I tried with 2.4.25 from kernel.org and OSW 1.0.3, but also with SuSE 9.1 
Kernel 2.6.5-xxx and OSW 2.2.0. The problem (UDP-checksum due to wrong IP) 
was always the same.

> - I am not sure if L2TP/IPsec (or Transport Mode in general) works
>    at all with IPsec passthrough. I never tested it because I do not
>    have access to a NAT device with IPsec passthrough anymore (I only
>    used it once with Sentinel in Tunnel Mode). Would NAT-T be an option
>    instead?
Hmm, I didn't try this in detail. But as I thought about this for some 
minutes, this actually seems to be the core of the problem.
I didn't configure any tunnel type in OSW and was wondering that 
DHCP-over-IPsec with Sentinel behaved different to Win-IPsec.
Hence if one is using tunnel and the other transport mode, it seems to be the 
reason, why the arriving UDP-packets have different source IPs, resulting in 
the checksum-problem for the L2TP-packets.

>  > Different to the DHCP-request, these do not contain the client's
>  > internal IP, but the external IP, as given from my DSL-provider. Even
>  > though this doesn't cause any serious routing problems in first place,
>  > these packets don't reach the gateway's L2TP-demon.
>
> ??? I don't quite understand.
Apart from the mismatching source-IP of the UDP-packets, the routing as being 
dynamically set-up by OSW doesn't fit. Namely OSW sets up IP-tables in any 
case (transport and tunnel mode) to the internal client IP. Hence if 
L2TP-packets arrive with the external (DSL-IP), the predefined routing 
doesn't fit.

>  > The problem is the mismatching
>  > UDP-checksum, which has been calculated at the client side with respect
>  > to the internal IP, but validated at the gateway according to the
>  > external (DSL-) IP.
>
> This is either normal, an artifact of Ethereal or indeed caused by the
> IPsec passthrough. Sorry about being vague, but again, IPsec passthrough
> is not my strong point...
See previous sections. The behaviour is correct, because checksum has been 
calculated with clients internal IP, but validated at the GW against the 
(improper) external IP.

To conclude this, the whole IPsec-L2TP stuff obviously doesn't work with 
NAT-passthrough, since it in general has problems with the transport mode. I 
guess I will look for sth. like the Linksys router, being able to use NAT-T 
properly.


Thx for your hint according to the different modes,
Andreas