[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Delete/disable certain ipfw rules?
 Date:  Thu, 19 Aug 2004 15:43:59 -0700 (PDT)
On Wed, 18 Aug 2004, Frederick Page wrote:
> Fred Wright wrote on Tue, Aug 17 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
> 
> >A little knowledge can be a dangerous thing. :-)
> 
> Indeed, that's why I asked about those rules ;-) Thank you very much
> for your valueable explanations.
> 
> 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.  While it's
almost certainly something that shouldn't be blocked, it also is unlikely
to have an operational impact other than making the pcb (and filter state
entry) hang around for longer than necessary.

> Again: this is WANTED traffic and it's even my own traffic from
> Azureus going out (sis0 is the internal LAN interface). And just a few
> seconds later the opposite:
> 
> 02:55:57.448415 ng0 @0:15 b 82.37.18.38,4643 -> 192.168.100.111,6111
>                             PR tcp len 20 88 -AFP IN

Same thing in the other direction, although it's not clear what's in those
88 bytes.  My guess is TCP options (including SACKs?) rather than real
data, since you only get simultaneous data and FIN with T/TCP, which
m0n0wall currently blocks (at least in its most common form).

> As I said: rule 15 only does harm here, absolutely no good at all.
> That's why I want it (along with rule 14) disabled/deleted, could you
> please tell me how?

In general, the only way to do this sort of thing is to modify
filter.inc.  But you have to be careful how what you do interacts with the
setup.  And removing that pair of rules would effectively disable stateful
filtering altogether.  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. :-)

Can you collect simultaneous packet traces from both sides of the m0n0wall
when this happens?  I only see that symptom sporadically here.

					Fred Wright