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

Hallo Manuel,

Manuel Kasper schrieb am 10. August 2004:

I'm updating the logs and firewall-rules, because I'm also
experiencing blocked inbound traffic, which is wanted, everything
blocked by rule #15:

ipfstat -nio:
@13 block in log quick on ng0 from 192.168.0.0/16 to any
@14 skip 1 in proto tcp from any to any flags S/FSRA
@15 block in log quick proto tcp from any to any
@16 block in log quick on sis0 from any to any head 100

Incoming blocked (but wanted) packets:
21:11:54.262991 ng0 @0:15 b 69.196.217.174,6881 -> 192.168.100.111,4364
                          PR tcp len 20 40 -ARF IN 
21:11:39.185882 ng0 @0:15 b 62.14.126.220,6882 -> 192.168.100.111,4300
                          PR tcp len 20 40 -ARF IN 
20:51:32.044884 ng0 @0:15 b 69.196.217.174,6881 -> 192.168.100.111,4159
                          PR tcp len 20 40 -ARF IN 
20:51:15.717181 ng0 @0:15 b 62.14.126.220,6882 -> 192.168.100.111,4093
                          PR tcp len 20 40 -ARF IN 

>Those are packets that are deemed by ipfilter not to match any
>existing state table entry.

Okay, I did not find those IP-numbers in the state-tables, so blocking
is absolutely correct. But why is OUTGOING traffic blocked as well?

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 

sis0 is the INTERNAL interface and 192.168.100.111 is an internal
machine trying to reach the outside world. Should rules 14-16 better
be "from <wan>" instead of "from any"?

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

I am aware of that, if I choose to reboot the Soekris or clear the
state-tables, I also reset the (Windows) machines just in case.

>In that case, it's perfectly normal and expected behavior.

Certainly.

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

I see your point, especially for the external interface. m0n0wall
follows the (IMHO proper) concept of a largely trusted intranet,
I'm just wondering, why denying some "ACK PUSH" or "ACK FIN" from the
inside going out?

I have to admit, that the software which causes these packets may not
be standard-complying or buggy (it's latest Azureus 2.1.0.4).

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

Please don't get me wrong: I very much appreciate yours and Fred's
work and m0n0wall in general. I'm just confused why rule #15
explicitly blocks ANY interface, instead of only the "bad" WAN
interface.

Or should I send a bugreport to the Azureus developers, are the before
mentioned (blocked) outgoing packets non-standard?

Thanks for the answer and kind regards

Frederick