From owner-freebsd-questions@FreeBSD.ORG Fri Sep 17 18:39:29 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76D8816A4CE for ; Fri, 17 Sep 2004 18:39:29 +0000 (GMT) Received: from advmail.lsn.net (advmail.lsn.net [66.90.138.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3211943D41 for ; Fri, 17 Sep 2004 18:39:29 +0000 (GMT) (envelope-from norm@etherealconsulting.com) Received: from etherealconsulting.com (24-155-40-125.ip.grandenetworks.net [24.155.40.125]) by advmail.lsn.net (8.12.8/8.12.4) with ESMTP id i8HIdR0A008777; Fri, 17 Sep 2004 13:39:30 -0500 Message-ID: <414B2F5B.4090702@etherealconsulting.com> Date: Fri, 17 Sep 2004 13:39:23 -0500 From: Norm Vilmer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Micheal Patterson References: <414A6E9C.4060708@etherealconsulting.com><020b01c49c76$e3d1ada0$0201a8c0@dredster> <414AF79C.4030809@etherealconsulting.com> <06af01c49cc5$b0b615b0$4df24243@tsgincorporated.com> <414B02FD.6020703@etherealconsulting.com> <06fd01c49ccd$36e91450$4df24243@tsgincorporated.com> <414B150C.6090608@etherealconsulting.com> <07af01c49cdd$e9910f80$4df24243@tsgincorporated.com> In-Reply-To: <07af01c49cdd$e9910f80$4df24243@tsgincorporated.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.6; VAE 6.27.0.11; VDF 6.27.0.66 cc: freebsd-questions@freebsd.org Subject: Re: Too many dynamic rules, sorry X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 18:39:29 -0000 Micheal Patterson wrote: > > ----- Original Message ----- > From: "Norm Vilmer" > To: "Micheal Patterson" > Cc: > Sent: Friday, September 17, 2004 11:47 AM > Subject: Re: Too many dynamic rules, sorry > > > >>Micheal Patterson wrote: >> >>>----- Original Message ----- >>>From: "Norm Vilmer" >>>To: "Micheal Patterson" >>>Cc: >>>Sent: Friday, September 17, 2004 10:30 AM >>>Subject: Re: Too many dynamic rules, sorry >>> >>> >>> >>> >>>>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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@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