[ previous ] [ next ] [ threads ]
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Filter blocking (small) Packets ?
 Date:  Sun, 1 Aug 2004 18:44:55 -0700 (PDT)
On Fri, 30 Jul 2004 eric at ericmagny dot com wrote:

> When I pick a look to my filter log, I can see a lot of these errors:
> Jul 30 16:19:25 router1 ipmon[75]: 16:19:25.174400 sis1 @0:18 b x.x.209.66,80 -
> > x.x.209.75,1579 PR tcp len 20 48 -AS IN
> Jul 30 16:19:25 router1 ipmon[75]: 16:19:25.174452 sis1 @0:18 b x.x.209.66,80 -
> > x.x.209.75,1577 PR tcp len 20 48 -AS IN

IPFilter is picky about sequence and ACK numbers, and unfortunately
doesn't include them in the log.  I haven't seen failures on SYN/ACK
packets before - is it possible the HTTP server in question is actually

> Jul 30 16:26:46 router1 ipmon[75]: 16:26:45.484354 sis1 @0:14 b 
> x.x.24.181,5554 -> x.x.71.229,4331 PR tcp len 20 40 -AR IN
> Jul 30 16:26:47 router1 ipmon[75]: 16:26:46.156576 sis1 @0:14 b 
> x.x.24.181,9898 -> x.x.71.229,4790 PR tcp len 20 40 -AR IN

These I have seen before, although not reproducibly.  I suspect another
IPFilter bug (there seem to be quite a number of them).  The good news is
that the presence of RST indicates that it's an "effectively dead"
connection anyway.

> Jul 30 16:28:39 router1 ipmon[75]: 16:28:38.775352 4x sis0 @0:18 b 
>,80 -> x.x.209.76,1100 PR tcp len 20 762 -A IN

I've also seen these, though as usual one can't tell from the log whether
the packet was really bad.

> I'm using now Monowall 1.1b15 (previously last release, I try beta to solve 
> this probs..)

That could fix *some* cases. :-)

The chronology of some *known* problems in IPFilter is:

m0n0wall	IPFilter	ACK check		ICMP checksum (NAT)
--------	--------	---------		-------------------
1.0		3.4.31		ignores wscale		OK
1.1b1-1.1b13	3.4.33		uses wrong wscale	broken
1.1b14-1.1b16	3.4.33+pat	uses wscale		broken

I've sent Manuel the fix for the ICMP checksum problem, so it will
probably be fixed in the next beta.  I haven't identified the cause of the
other troubles, other than in one case where the blocking was defintely

> Last thing, I'm using monowall as 'real' router.  No NAT.  On all 3 interface 

Then you probably aren't affected by the ICMP checksum problem. :-)

> there is a public IP add.    And when one error occurs in filter log, a web 
> page (or outlook freeze in retreiving mail) cannot be displayed in browser.

I've not seen that exact symptom, although I have seen it stop responding
in a case where it had probably gotten into a routing loop.  Is it really
*one* error in the log, or a flurry of them that are keeping it bogged
down with logging?

					Fred Wright