On Fri, 20 Aug 2004, Frederick Page wrote:
> Fred Wright schrieb am 19. August 2004:
> 
> >>>>1395 @14 skip 1 in proto tcp from any to any flags S/FSRA
> >>>>  79 @15 block in log quick proto tcp from any to any
> >>>>1040 @16 block in log quick on sis0 from any to any head 100
[...]
> >it also is unlikely to have an operational impact
> 
> You are of course right, I experienced a lot of trouble with
> transfers lately and blamed blocked packets from rule 15 for these
> troubles. This was obviously premature, since the transfers are fine
> today and I've changed nothing in my setup.

It could still be the same bug.  The window-scale bug hit quite
frequently, but only a small percentage of cases met the other conditions
for hanging the connection.

> >>As I said: rule 15 only does harm here
> 
> I was wrong here too :-( Rule 15 did indeed block some wanted traffic,
> but it also blocks junk that I definately do NOT want.

Well, removing 14 and 15 doesn't eliminate *filtering*, it just eliminates
*stateful* filtering.  So you'd still be protected from the usual crap
like infected Windows machines banging on ports 135, 445, etc.  But I'm
not really recommending doing that.

> >Can you collect simultaneous packet traces from both sides of the
> >m0n0wall when this happens?  I only see that symptom sporadically
> >here.
> 
> Meanwhile it's also sporadically here. As I said before: I had some
> troubles here (cause unknown, but gone now) and quite a pile-up of
> blocked packets and slow transfer-rates. I simply did not analyze
> enough and blamed rule 15 prematurely :-/

Traces of blocked legitimate packets might be informative even in cases
without visible symptoms.  But it's not that simple to set up.

					Fred Wright