On Tue, 22 Jun 2004, Evan Talley wrote:
> 
> Heh, yeah I forgot all about status.php. Duh. Well, I'm kind of new to this
> I suppose. Anyways, going off of that I think it is this rule that is
> causing me some troubles:
> 
> @15 block in log quick proto tcp from any to any

Well, not exactly.  See below.

> Here is some of the log:
> 
> Jun 22 14:10:03 m0n0wall ipmon[57]: 14:10:02.505270 ng0 @0:15 b
> 65.61.220.204,80 -> 69.29.133.211,7478 PR tcp len 20 40 -AF IN
> Jun 22 14:10:06 m0n0wall ipmon[57]: 14:10:06.087642 ng0 @0:15 b
> 66.28.242.50,80 -> 192.168.0.2,3621 PR tcp len 20 1420 -A IN
> Jun 22 14:10:15 m0n0wall ipmon[57]: 14:10:14.495634 ng0 @0:15 b
> 65.61.220.204,80 -> 69.29.133.211,7478 PR tcp len 20 40 -AF IN
> Jun 22 14:10:38 m0n0wall ipmon[57]: 14:10:38.512460 ng0 @0:15 b
> 65.61.220.204,80 -> 69.29.133.211,7478 PR tcp len 20 40 -AF IN
> Jun 22 14:11:27 m0n0wall ipmon[57]: 14:11:26.511299 ng0 @0:15 b
> 65.61.220.204,80 -> 69.29.133.211,7478 PR tcp len 20 40 -AF IN
> Jun 22 14:11:55 m0n0wall ipmon[57]: 14:11:54.954259 ng0 @0:15 b
> 208.255.43.151,80 -> 192.168.0.10,2748 PR tcp len 20 43 -AR IN
> Jun 22 14:11:55 m0n0wall ipmon[57]: 14:11:54.954559 ng0 @0:15 b
> 208.255.43.151,80 -> 192.168.0.10,2749 PR tcp len 20 43 -AR IN
> Jun 22 14:12:47 m0n0wall ipmon[57]: 14:12:47.798236 ng0 @0:15 b
> 209.66.118.161,80 -> 192.168.0.17,1765 PR tcp len 20 421 -AP IN
> 
> This is a problem not only because it's flooding my logs, but my downloads
> time out half the time as well. Very annoying. I tried making a rule to
> allow port 80 to pass through, but it didn't have any affect. Any ideas?

First of all, the stateful filtering check happens before the rule check,
so only packets that don't get passed by stateful filtering are subject to
the rules.  This is why the block rule above doesn't *really* block
almost all TCP traffic (unless the stateful filter screws up).

Secondly, rules defined in the WebGUI only apply to initial SYN packets,
so there's nothing you can do at that level to get around this sort of
problem.

The symptom sounds a lot like the window-scale bug, but most of your log
entries have FIN, RST, or data, making them unlikely candidates for that
particular bug.  But you may have missed the relevant cases due to their
looking similar to the irrelevant ones.  Or you may be getting burned by a
bug that hasn't been fixed yet.

On Wed, 23 Jun 2004, Evan Talley wrote:

> It also happens when I download onto a computer outside the network from my
> web server on the network:
> Jun 22 20:59:41 m0n0wall ipmon[57]: 20:59:41.283439 7x rl0 @0:15 b
> 192.168.0.2,80 -> 165.95.7.5,9533 PR tcp len 20 1420 -A IN
> Jun 22 20:59:49 m0n0wall ipmon[57]: 20:59:49.080704 7x rl0 @0:15 b
> 192.168.0.2,80 -> 165.95.7.5,9533 PR tcp len 20 1420 -A IN
> Jun 22 21:00:05 m0n0wall ipmon[57]: 21:00:05.346655 7x rl0 @0:15 b
> 192.168.0.2,80 -> 165.95.7.5,9533 PR tcp len 20 1420 -A IN
> Jun 22 21:00:13 m0n0wall ipmon[57]: 21:00:13.078911 7x rl0 @0:15 b
> 192.168.0.2,80 -> 165.95.7.5,9533 PR tcp len 20 1420 -A IN
> Jun 22 21:00:30 m0n0wall ipmon[57]: 21:00:29.256202 7x rl0 @0:15 b
> 192.168.0.2,80 -> 165.95.7.5,9533 PR tcp len 20 1420 -A IN

These are all data packets, which is a symptom I've also seen but one not
likely to be related to the window-scale bug (at least not the known
window-scale bug :-)).

> One more thing I guess I should mention is it doesn't seem to block ALL the
> traffic. I mean, I can still get web pages and I can still download from my
> webserver from remote locations. If I try to download a large file from a
> web server though it eventually times out. There is probably a really common
> solution that I'm just overlooking, or I might just have something set up
> wrong. I admit my n00bness :-(. Help? Thanks.

That sounds a lot like the symptoms of the known window-scale bug.  For
that one to strike, you need:

1) Window scaling in use.  In m0n0wall 1.0 (with Ipfilter 3.4.31), *any*
use of window scaling was sufficient.  For 1.1beta versions < 14 (with
Ipfilter 3.4.33), you'd need to have a larger window scale in the data
flow direction (i.e. server->client for "fetches") than in the opposite
direction.  Note that window scaling is never used unless the receiving
side has a receive socket buffer larger than 65535.

2) A certain pattern of packet loss.  Some patterns would cause ACKs to
get blocked only temporarily, and thus reduce performance without causing
hangs.  Other patterns would cause permanent hangs of the
connection.  It's theoretically possible, but highly unlikely in practice, 
for the bug to have an effect without packet loss.  Note that packet loss
is almost always present, since it's usually the only way that TCP gets
feedback about congestion.

On Wed, 23 Jun 2004, Evan Talley wrote:
> 
> Ok, I'll give it a shot. I'm running it off of a cd+floppy right now, but
> when I upgrade I'm going to put it on the hard drive. I was wondering if
> after I did that I could somehow load the config into it. I have the
> config.xml backed up. I just don't know how to merge the two, or if you even
> can. Do different versions read/write the config.xml file differently?
> Thanks.

Sometimes, but the newer firmware always knows how to read the older
config.  Just beware that it may rewrite it in a way that won't be
acceptable if you roll back.

> From: Manuel Kasper [mailto:mk at neon1 dot net] 
> Sent: Wednesday, June 23, 2004 1:08 AM
> 
> On 23.06.2004 00:14 -0500, Evan Talley wrote:
> 
> > One more thing I guess I should mention is it doesn't seem to block
> > ALL the traffic. I mean, I can still get web pages and I can still
> > download from my webserver from remote locations. If I try to
> > download a large file from a web server though it eventually times
> > out. There is probably a really common solution that I'm just
> 
> If you aren't already running 1.1b14, give it a try - it's got a fix
> for what appears to be a bug in ipfilter's window scaling handling.

It's certainly worth a try, although *most* of the log entries posted look
like they're caused by a different bug(s).  Then again, those cases may
not be causing the user-visible hangs.  Here, installing the fix stopped
the hangs, but didn't get rid of the other packet blocks that I might not
have noticed if the hangs hadn't made me look at the logs more closely.
:-)

					Fred Wright