Hallo Fred,

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
 
>>Rule 15 is my main-concern, just while we are talking:
>>02:55:48.645748 sis0 @0:15 b 192.168.100.111,6111 -> 82.37.18.38,4643
>>                             PR tcp len 20 40 -AF IN

>This is a FIN packet involved in closing the connection.

Ouch, although it was right in front of me, I missed it ;-)

>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.

>>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.

>>That's why I want it (along with rule 14) disabled/deleted, could
>>you please tell me how?

Well I should have thought more before this mail :-/ I logged all
events to a Linux-client and had time to evaluate some more. As said
before: Rule 15 does also block junk and the price of disabling it
seems much too high.

>In general, the only way to do this sort of thing is to modify
>filter.inc.

This is valueable info, but I better not mess with a carefully planned
setup, as you correctly mentioned before, I could easily do more harm
than good.

>And removing that pair of rules would effectively disable stateful
>filtering altogether. 

Exactly. And that's something I definately do not want ;-)

>An interesting suggestion coming from someone who only a few days ago
>was taking issue with my claim that the stateful filter is being
>overly strict with respect to sequence numbers. :-)

It's one thing talking about standards, but another, if it actually
happens to me ;-) No seriously, I really should have thought better
about the whole issue and done my analysis more thoroughly before
increasing the noise-ratio on this list :-/

I'm truely sorry for my previous post and gladly admit that I was
wrong. Thank you very much for answering anyway, although I appeared
to be just another troll/smurf.

>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 :-/

Kind regards from Aachen (Germany)

Frederick