Re: wanted traffic blocked from in to out, why?

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

- Manuel