[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] wanted traffic blocked from in to out, why?
 Date:  Tue, 10 Aug 2004 15:18:40 -0700 (PDT)
On Tue, 10 Aug 2004, Manuel Kasper wrote:
> On 10.08.2004 03:04 +0200, Frederick Page wrote:
> 
> > Firmware is 1.1b17, ipfstat -nio (extract):
> > @14 skip 1 in proto tcp from any to any flags S/FSRA
> > @15 block in log quick proto tcp from any to any
> > 
> > Firewall-Log (extract):
> > 02:52:14.472848 sis0 @0:15 b 192.168.100.111,1081 ->
> > 24.99.173.2,6881                 PR tcp len 20 112 -AP IN 
> > 02:51:39.167502 sis0 @0:15 b 192.168.100.111,1104 ->
> > 24.37.142.208,6881                 PR tcp len 20 108 -AP IN 
> > 02:51:38.161530 sis0 @0:15 b 192.168.100.111,1107 ->
> > 200.49.84.236,6881                 PR tcp len 20 108 -AP IN 
> > 02:51:36.356875 sis0 @0:15 b 192.168.100.111,1102 ->
> > 65.96.213.245,6969                 PR tcp len 20 40 -AF IN 
> > 
> > This traffic is wanted (BitTorrent), sis0 is the LAN-interface, sis1
> > (aka. ng0 since I'm PPPoE user) the WAN interface, why are these
> > OUTGOING packets blocked? I trust my own machines ;-) Can I do
> > anything to pass the packets?
> 
> Those are packets that are deemed by ipfilter not to match any
> existing state table entry. That is, ipfilter thinks they do not

Or that matched but were deemed "inappropriate" by other criteria, such as
sequence and/or ACK numbers.

> conform to the expected flow of TCP packets of a TCP connection that
> was established earlier. One case where this happens is when you
> reboot your firewall (or clear the state table) while a machine on
> your LAN still has a TCP connection open. In that case, it's
> perfectly normal and expected behavior. Rule 14 and 15 are designed
> to not let any TCP packet other than one with the SYN flag set create
> a new state table entry. There used to be a problem with ipfilter's
> handling of TCP window scaling, which led to packets being blocked
> when they shouldn't have been, but thanks to Fred Wright's efforts,
> that one should be fixed.

True, but IPFilter has other bugs as well.  Unfortunately, the only case
so far where packet traces were available was a "borderline illegal but
harmless" case.

Personally, I think the only purpose of the filter should be to provide
security, not to punish people for communicating with mildly buggy TCP
implementations, but the IPFilter guys seem to think otherwise.

					Fred Wright