Chris Ross wrote:
I have a NetBSD 4.0_BETA2, which is running ipfilter 4.1.23. ipf -V
reports:
ipf: IP Filter: v4.1.23 (396)
Kernel: IP Filter: v4.1.23
I am trying to debug some problems I'm having with a Windows machine
running the Contivity VPN client on an internal network, and when
things go bad (ie, no traffic is being received from the VPN any
longer), we disconnect things. After this, the VPN server keeps
trying to contact the client on port 4500/udp, as you'd expect. The
client then generates a "ICMP port unreachable" error, and it seems
that the NAT'ing of ipfilter knows how to remap that to send that back
to the server.
However, I think it's getting the checksum wrong. If I watch the
internal network, which has the windows client on it, I see:
18:45:57.843588 IP (tos 0x20, ttl 105, id 52030, offset 0, flags
[none], length: 96) vpnsvr2a.xxx.com.4500 > 172.31.83.24.1071: [no
cksum] UDP, length: 68
18:45:57.844839 IP (tos 0x0, ttl 128, id 12807, offset 0, flags
[none], length: 124) 172.31.83.24 > vpnsvr2a.xxx.com: icmp 104:
172.31.83.24 udp port 1071 unreachable for IP (tos 0x20, ttl 105, id
52030, offset 0, flags [none], length: 96) vpnsvr2a.xxx.com.4500 >
172.31.83.24.1071: [no cksum] UDP, length: 68
But, if for those same packets, I look at my external network
interface, which is on the *outside* of the NAT'ing action, I see:
18:45:57.843492 IP (tos 0x20, ttl 106, id 52030, offset 0, flags
[none], length: 96) vpnsvr2a.xxx.com.4500 >
c-69-244-mm-nn.hsd1.md.comcast.net.38037: [no cksum] UDP, length: 68
18:45:57.844936 IP (tos 0x0, ttl 127, id 12807, offset 0, flags
[none], length: 124) c-69-244-mm-nn.hsd1.md.comcast.net >
vpnsvr2a.xxx.com: icmp 104: c-69-244-mm-nn.hsd1.md.comcast.net udp
port 38037 unreachable (wrong icmp cksum 738f (->52c2)!) for IP (tos
0x20, ttl 105, id 52030, offset 0, flags [none], length: 96)
vpnsvr2a.xxx.com.4500 > c-69-244-mm-nn.hsd1.md.comcast.net.38037: [no
cksum] UDP, length: 68
It looks like it's converting the "port unreachable" to send it
back, but tcpdump is complaining that the icmp cksum is wrong for the
packet that the NAT'ing software has generated. Is this a real bug in
that code, or is something going wrong somewhere and I'm just
misinterpreting the output of tcpdump?
I don't believe you are but I'm really surprised that you're
seeing this. What I would like is if you can do the following:
1) email me (privately) the output from tcpdump with some additional
command line options "-xX -s 1536" so I can manually verify what
is happening with the packets - the same 4 packets from above
should be enough;
2) let me know the names of the interfaces the packet is received
and transmitted on;
3) goto the following URL and fill in a bug report:
http://sourceforge.net/tracker/?func=add&group_id=169098&atid=849053
Thanks,
Darren
