[Openswan Users] L2TP-IPsec with NAT-passthrough (UDP-checksum) problem

[Andreas Kemper]

Folks,

some months ago, I've set up the following configuration, which works almost
perfect:

Server:
* Kernel 2.4.25 with OpenS/WAN 1.0.3
* X.509 certs, alternatively PSKs
* DHCP-over-IPsec with dhcp-relay on the server
* IPtables using TCPMSS-option to adjust MSS (->MTU)
* Optionally providing NAT for OpenS/WAN clients

Client
* Wintendo 2k with Sentinel 1.4.1 and DHCP-over-IPsec
* DSL-connection with NAT-passthrough wireless router

Due to some minor bugs in Sentinel and in particular the problems with WinXP
SP2, I decided to set up L2TP-IPsec in parallel, according to Jaccos nice
docu (http://www.jacco2.dds.nl/networking/freeswan-l2tp.html). My settings
concerning the L2TP-tunnel are almost identical, while I just added
"rightsubnetwithin=0.0.0.0/0" to allow for IPsec-connection of NATted
clients.

Now basically the new set-up is running, as long as I don't connect via
NAT-passthrough over my router. Unfortunately there is no other option,
since also my neighbours are connected to the router and "passthrough" can't
be disabled, to allow for proper NAT-T.

Thus I looked a bit closer and thereby found that the l2tpd doesn't react at
all in case of NATted connections.
Different to the normal operation, two strange things can be found:

o Sniffing with Ethereal on ipsec0 during connection trials indicated
upd/l2tp-packets with source address of my DSL-line (external IP) and a
_mismatching_ UDP-checksum. Everything else, in particular L2TP-info, seems
to be correct.

o OpenS/WAN sets up a dynamic route to ipsec0 for the client's (internal)
NATted-IP.

The second point seems to be not critical or even ok, since at least for the
DHCP-tunnel it works almost in the same manner, except for the fact that
there "leftsubnet=0.0.0.0/0" is set to allow for DHCP-broadcasts.

Thus the obvious problem seems to be the corrupt checksum, which prevents
these packets from arriving at the l2tpd or at least being instantly
discarded there without further any logging information.

Now the question is, whether this problem can be fixed with a more recent
OpenS/WAN and/or kernel version or probably just some not yet documented
config tricks?

Any help appreciated.

Thx,
Andreas