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?
Thanks. I would appreciate any information you could provide...
The external VPN server keeps trying to talk to me, so I certainly
assume it isn't getting the "port unreachable" in any way it
understands....
Thanks...
- Chris
