On Wed, Nov 16, 2005 at 07:52:11PM +0100, Sebastiaan van Erk wrote:
> Ok, a friend of mine fixed the problem.
>
> Seems FreeBSD GRE (netgraph) does not cope well with fragmented packets.
In my case the datagrams are not fragmented. There seems to
be a problem with the checksums in ICMP error messages. It
seems unlikely that this would be a problem in the netgraph
module, but it is distinctly possible.
> Adding mssclamp 60 to the nat redirect rules fixed the problem for me.
> I will write to the FreeBSD lists about this.
Whoa! An MSS of 60! That may be over doing it a little.
Although this is admitting defeat and going with a broken
kludge, I will give it a try. It should work. It'd be nice
to fix the bug tho'.
To answer some of these earlier questions:
> Nicolas Saurbier wrote:
> >Hi,
> >
> >are you using Checksum Offloading?
No.
> >What does your ifconfig-output look like?
The Internet-facing interface,
$ ifconfig ep0
ep0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::220:afff:fe17:a3e9%ep0 prefixlen 64 scopeid 0x3
inet 24.6.184.207 netmask 0xfffff800 broadcast 255.255.255.255
ether 00:20:af:17:a3:e9
media: Ethernet 10baseT/UTP
The netgrap interface is boring at the moment since no clients
are attached,
$ ifconfig ng0
ng0: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::290:27ff:fe13:2540%ng0 prefixlen 64 scopeid 0x6
The inet configuration and mtu are changed by the mpd process
when the client connects. But it looks like a pretty stanard
P-to-P interface when configured by mpd.
> >>-----Original Message-----
> >>From: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED] On Behalf Of
> >>Sebastiaan van Erk
> >>Sent: Wednesday, November 16, 2005 4:13 PM
> >>To: [email protected]
> >>Subject: Re: Bad ICMP Checksums, NAT, MPD
> >>
> >>I'm running FreeBSD 6.0 with IPFilter 4.1.8 with MPD as well.
> >>I'm having
> >>similar problems (intermittent connection timeouts), especially to
> >>www.google.com. If I use a web proxy (squid) to a colocated server I
> >>have on the internet (thus also via mpd) then all connection
> >>problems go
> >>away. The connection timeouts occur from the FreeBSD machine itself
> >>(lynx to www.google.com; this does get NATed as it's from my
> >>internal IP
> >>10.0.0.2 to www.google.com over the netgraph interface ng0), or any
> >>other hosts (windows, linux, etc) on my internal network.
> >>
> >>Greetings,
> >>Sebastiaan
> >>
> >>Crist J. Clark wrote:
> >>
> >>>I have IPFilter 4.1.8 running on FreeBSD 4.11-RELEASE-p13.
> >>>I was running with the base version of IPFilter, but upgraded
> >>>hoping it would make this problem go away. Obviously, it did
> >>>not.
> >>>
> >>>The IPFilter host is a firewall with three interfaces. One is
> >>>to the Internet, one to my internal wired network, and finally,
> >>>one to my home wireless net. The Internet connection does NAT
> >>>for the internal networks which are RFC1918 addresses. I do run
> >>>WEP on the wireless LAN, but since WEP is hopelessly broken,
> >>>WLAN hosts run a VPN on top of that. The problem I am having is
> >>>with a Windows host that communicates with the IPFilter firewall
> >>>through PPTP using MPD. Now, this all works fine for a Win2k
> >>>host, but a WinXP host is having intermittent problems.
> >>>
> >>>The WinXP host, for some reason, negotiates a smaller MRU. No
> >>>big deal, that shouldn't affect things, but it does. The problem
> >>>is that other hosts send packets that are too big for the pipe
> >>>(the WinXP doesn't seem to negotiate the right MSS with them, but
> >>>that shouldn't actually break things). The firewall generates
> >>>Fragmentation Needed But DF Set ICMP errors, but they are getting
> >>>sent out with bad ICMP checksums. The host at the other end drops
> >>>them, never decreases MTU, so the connections time out.
> >>>
> >>>The problem is definately somewhere on the firewall machine. My
> >>>best guess is that these are getting munged by NAT when they go
> >>>out of the interface to the remote host on the Internet. Anyone
> >>>seen this before or have a way to debug this to see where things
> >>>are getting messed up? I had a look at the IPFilter NAT code that
> >>>messes with the various checksums and got dizzy.
> >>>
> >>>Here's what it looks like. Also note that the IP checksum in
> >>>the encapsulated bit of the offending packet is also wrong
> >>>in the ICMP message:
> >>>
> >>>21:20:59.554327 63.146.70.20.80 > 24.6.184.207.1352: . [tcp
> >>
> >>sum ok] 143:1503(1360) ack 476 win 17205 (DF) (ttl 115, id
> >>56691, len 1400)
> >>
> >>>0x0000 4500 0578 dd73 4000 7306 ce90 3f92 4614
> >>
> >>[EMAIL PROTECTED]
> >>
> >>>0x0010 1806 b8cf 0050 0548 ff35 dda6 ec1a ff6a
> >>
> >>.....P.H.5.....j
> >>
> >>>0x0020 5010 4335 135f 0000 0d0a 3c21 444f 4354
> >>
> >>P.C5._....<!DOCT
> >>
> >>>0x0030 5950 4520 4854 4d4c 2050 5542 4c49 4320
> >>
> >>YPE.HTML.PUBLIC.
> >>
> >>>21:20:59.555051 24.6.184.207 > 63.146.70.20: icmp:
> >>
> >>24.6.184.207 unreachable - need to frag (mtu 1396) (wrong
> >>icmp csum) for 63.146.70.20.80 > 24.6.184.207.1352: [|tcp]
> >>(DF) (ttl 115, id 56691, len 1400, bad cksum 3f65!) (DF) (ttl
> >>64, id 2447, len 56)
> >>
> >>>0x0000 4500 0038 098f 4000 4001 daba 1806 b8cf
> >>
> >>[EMAIL PROTECTED]@.......
> >>
> >>>0x0010 3f92 4614 0304 a43f 0000 0574 4500 0578
> >>
> >>?.F....?...tE..x
> >>
> >>>0x0020 dd73 4000 7306 3f65 3f92 4614 1806 b8cf
> >>
> >>[EMAIL PROTECTED]
> >>
> >>>0x0030 0050 0548 ff35 dda6 .P.H.5..
> >>>
> >>
> >>
> >>
> >
> >
--
Crist J. Clark | [EMAIL PROTECTED]
