[Openswan Users] XL2TPD/Double NAT issue
vogt at spamcop.net
Fri Oct 12 07:56:54 EDT 2007
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
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) 220.127.116.11.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
>> 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?
More information about the Users