On Wed, 23 Jun 2004, Evan Talley wrote:

> Well, I upgraded to the latest beta version, and the problem remains. It

Oh, well.  I guess it's not the window-scale problem.

> looks to me like it's only blocking packets that contain either a -A or -AF,

Pretty much *every* TCP packet other than the initial SYN to open the
connection has the ACK bit, so its presence proves nothing.  However, you
can tell from the length whether it's a data-containing packet or
not.  The FIN is present when closing the connection is being
attempted.  You also had a few with RST, which happens when one side
thinks the connection is still open and the other doesn't, so the latter
says "go away" when presented with another packet for it.

> and only on port 80. It blocks both incoming packets and outgoing on port

I'm sure the bug has nothing to do with port 80 per se, but that's where
the traffic that happens to run afoul of the bug occurs.

> 80, but not all of them.... I don't know... it's weird. The rule that is
> causing the problem is this one:
> 
> @15 block in log quick proto tcp from any to any

As I posted before, that's where all TCP packets that aren't initial SYNs
and aren't passed by stateful filtering land.  In the absence of filter
bugs, it would only catch packets from attacks based on forged midstream
packets.  In practice, that particular sort of attack is rare, and the
majority of hits are due to filter bugs.

> Let me know if you need any more info, and maybe I can be more specific, or
> I can include a copy of my status page or something. Is this a bug? If so,
> where do I report it?

If you can reproduce it *and* get packet traces from both sides
(preferably with synchronized clocks), as well as the filter log and the
output of "ipfstat -sl" shortly after the failure, then I *might* be able
to figure something out.  Since m0n0wall itself can't capture packets, you
need to use other machines with access to the traffic to do so.

					Fred Wright