Micheal Patterson wrote:
----- Original Message -----
From: "Norm Vilmer" <[EMAIL PROTECTED]>
To: "Micheal Patterson" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 11:47 AM
Subject: Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
----- Original Message -----
From: "Norm Vilmer" <[EMAIL PROTECTED]>
To: "Micheal Patterson" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
