[Openswan Users] L2TP/IPsec with NAT-passthrough - problem summary

[Andreas Kemper]

Hi,

as reported last month, I have some serious problems getting my Windows
(L2TP-) IPsec running, in case the client machine is behind a
NAT-passthrough router. Right now I'm really close to the problem, but
actually don't know how to solve this. Looking at the important pieces of my
"ipsec.conf" it looks like this:

>>>>>>>>>>>>>>

config setup
	interfaces=%defaultroute
	nat_traversal=no

conn %default
	left=%defaultroute
	right=%any
	pfs=no

conn l2tp
      leftprotoport=udp/l2f
      rightprotoport=udp/l2f
	rightsubnetwithin=0.0.0.0/0

conn dhcp
	leftprotoport=udp/bootps
	rightprotoport=udp/bootpc
	rightsubnetwithin=0.0.0.0/0
      leftsubnet=0.0.0.0/0

<...>

>>>>>>>>>>>>>>

Initially, I had a setup for Sentinel clients using DHCP-over-IPsec, which
didn't even cause any problem behind the NAT-router. While obtaining the
DHCP-IP, a tunnel and the according routing is established between the
internal (private) client IP and the DHCP-relay on the gateway. As DHCP uses
IP-broadcasting, the entry "leftsubnet=0.0.0.0/0" is required in this
section. Turning now to L2TP-Ipsec, establishment of the tunnel and routing
basically works in the same manner, which seems to be ok in first place. The
problem comes up, when after establishment of the IPsec-tunnel, the
L2TP-packets from the client are decrypted at the gateway. 
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. 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. Hence I'm wondering, why DHCP-packets and L2TP-packets have
different source addresses and if I can fix this issue on the gateway by
means of "eroute", "iptables" or similar?

Again, thanks for your hints and comments,
Andreas


BTW: For those who haven't read the previous threads:
- The problem occurs with OSW 1.0.3 / K 2.4, but also with OSW 2.2.0 and K
2.6
- It's independent of using PSKs or certs
- NAT-passthrough can't be disabled and conflicts with NAT-T
- I'm not looking for client-individual "hacks"
- It's not related to using WinXP SP2, even though this has been the
trigger...
- Restricting "rightsubnet(within)=" doesn't help
- My WLAN-router (SMC 2804WBR) is obviously not broken, since the same
problem appears with other passthrough-routers