[ previous ] [ next ] [ threads ]
 From:  Frederick Page <fpage at thebetteros dot oche dot de>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] wanted traffic blocked from in to out, why?
 Date:  Tue, 10 Aug 2004 22:44:12 +0200
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 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,6881 ->,4364
                          PR tcp len 20 40 -ARF IN 
21:11:39.185882 ng0 @0:15 b,6882 ->,4300
                          PR tcp len 20 40 -ARF IN 
20:51:32.044884 ng0 @0:15 b,6881 ->,4159
                          PR tcp len 20 40 -ARF IN 
20:51:15.717181 ng0 @0:15 b,6882 ->,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,1081 ->,6881
                           PR tcp len 20 112 -AP IN 
02:51:39.167502 sis0 @0:15 b,1104 ->,6881
                           PR tcp len 20 108 -AP IN 
02:51:38.161530 sis0 @0:15 b,1107 ->,6881
                           PR tcp len 20 108 -AP IN 
02:51:36.356875 sis0 @0:15 b,1102 ->,6969
                           PR tcp len 20 40 -AF IN 

sis0 is the INTERNAL interface and 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.


>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

>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

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