Re: ICMP checksum error through NAT ?

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...98&atid=849053

Thanks,
Darren