Too many dynamic rules, sorry

[Norm Vilmer]

Micheal Patterson wrote:
> 
> ----- Original Message ----- 
> From: "Norm Vilmer" <norm at etherealconsulting.com>
> To: "Micheal Patterson" <micheal at tsgincorporated.com>
> Cc: <freebsd-questions at freebsd.org>
> Sent: Friday, September 17, 2004 11:47 AM
> Subject: Re: Too many dynamic rules, sorry
> 
> 
> 
>>Micheal Patterson wrote:
>>
>>>----- Original Message ----- 
>>>From: "Norm Vilmer" <norm at etherealconsulting.com>
>>>To: "Micheal Patterson" <micheal at tsgincorporated.com>
>>>Cc: <freebsd-questions at freebsd.org>
>>>Sent: Friday, September 17, 2004 10:30 AM
>>>Subject: Re: Too many dynamic rules, sorry
>>>
>>>
>>><snip>
>>>
>>>>I do have a check-state rule
>>>>
>>>>add 00200 check-state
>>>>
>>>>Norm Vilmer
>>>
>>>
>>>Ok. Then right above the check-state entry, place an
>>>
>>>allow ip from 123.123.123/24 to 123.123.123./24
>>>
>>>Replace the ip's with the appropriate network/metric for your lan and
> 
> that
> 
>>>will allow lan traffic to go to itself unhindered by any stateful
> 
> checks.
> 
>>>--
>>>
>>>Micheal Patterson
>>>TSG Network Administration
>>>405-917-0600
>>>
>>>
>>>
>>
>>would this be the same?
>>
>>add 00200 allow all from any to any via ${iif} keep-state
>>add 00210 check-state
>>
>>
> 
> 
> The goal is to not use dynamic rules for your local lan, only the traffic
> from the lan to the net. Otherwise, you're wasting dynamic state table space
> for rules that aren't necessary.
> 
> A very basic stateful ruleset:
> 
> ipfw add 100 allow ip from 1.1.1.0/24 to 1.1.1.0/24
> ipfw add 500 check-state
> ipfw add 600 allow ip from 1.1.1.0/24 to any keep-state
> ipfw add 65000 deny log ip from any to any
> 
> That type of ruleset, will allow local traffic without using state table,
> and the entry at 1000 will catch everything else outbound and use state
> tables for it.  If it's not originating from your network, and there's no
> state entry, it's blocked by 65000.
> 
> --
> 
> Micheal Patterson
> TSG Network Administration
> 405-917-0600
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 
I tried your suggestion and got the same results and I think I
understand why. If I have this right, it's putting keep-state on
a rule that cause dynamic rules to be created. Well, I have
removed all the keep-state's except for the one you specified.

I launched the nmap attack against my public ip, however, the
machine I launched it from is on the same network segment as the
firewalls internal interface. So the traffic is going out the firewall
then coming back in. If I am correct, this is a major Doh! on my part.
Of course the net.inet.ip.fw.dyn_count is climbing, the

ipfw add 600 allow ip from 1.1.1.0/24 to any keep-state

rule is the culprit due to the outbound traffic.

So I really need to nmap my firewall from another location
to complete my test.

Hmmm, does this mean that I can mess up my firewall by running
nmap on a machine inside my firewall. It appears so.

Do you know what the maximum value for net.inet.ip.fw.dyn_max is?
I thought I read 8192....

Norm Vilmer