[Openswan Users] XL2TPD/Double NAT issue

[Gerald Vogt]

Paul Wouters wrote:
>> with tcpdump whether the full packet comes through or only a part of it.
>> The initial l2tp packet does arrive on ipsec0. But so far I did not
>> check the sizes of what is sent out and what is received...
> 
> Though that's a useful check to do, but remember the fragment might never
> reach your machine.

O.K. I have checked the packet dumps. The first packet has a total 
length of 131. It gets through completely. I now doubt very much that it 
is a mtu issue with a packet size like that. The client only sends this 
one packet repeatingly and the server side receives the packet on the 
ipsec0 interface.

However, with more verbosity and a snaplen of 1600 tcpdump shows 
something else, too:

20:50:02.888409 IP (tos 0x0, ttl  62, id 3484, offset 0, flags [none], 
proto: UDP (17), length: 88) 1.0.0.2.49166 > 192.168.4.2.l2f: [bad udp 
cksum 563c!]  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) 
*FRAMING_CAP(AS) *HOST_NAME() *ASSND_TUN_ID(1) *RECV_WIN_SIZE(4)

The packet has a bad checksum. This only happens when the client is 
behind the NAT router as well. When the client is not behind the NAT 
router the checksums are O.K. Is this the problem why xl2tpd cannot read 
the packet?

>> I guess, as I had major issues getting NET_KEY working in that kernel
>> that made me give up on that and use KLIPS instead this issue could just
>> as well be some other kind of kernel issue.
> 
> Yes, that would be the recommened solution. Though the nat-t patch is
> still a pain to apply to the kernel....

What is the recommended solution? Getting NET_KEY running?

Gerald