Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 04 Sep 2007 01:19:41 +0700
From:      "Vadim Goncharov" <vadimnuclight@tpu.ru>
To:        "Russell Fulton" <r.fulton@auckland.ac.nz>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: getting state to work properly
Message-ID:  <optx3bu3br4fjv08@nuclight.avtf.net>
In-Reply-To: <46D70145.3030708@auckland.ac.nz>
References:  <46D66176.9020300@auckland.ac.nz> <46D70145.3030708@auckland.ac.nz>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
31.08.07 @ 00:41 Russell Fulton wrote:

> Rule set appended -- anonymizing the rule set while keeping the sense
> would be a lot of work and I don't want to trim it down for fear of
> dropping something vital.  As this network is not exposed to the
> internet and the firewall's  primary purpose is traffic shaping not
> security I'll post it.
>
> Attached.

Some summary points:

1) localhost traffic should be unconditionally allowed at the start of  
firewall, state here is useless.
2) antispoofing can be more clearly done with antispoof and verrevpath  
keywords. Like:

ipfw add 100 pass all from any to any via lo0
ipfw add 110 deny all from any to any in recv $extiface not verrevpath
ipfw add 111 deny log all from any to any in recv $intiface not antispoof
ipfw add 112 check-state

3) Using "setup" option while protocol is "all" is unclear - it will match  
only tcp, while you possibly ment to keep-state on every protocol, not  
just tcp.
4) Consider using sysctl net.inet.ip.fw.one_pass - it controls whether  
traffic after getting out from pipe will continue go through ipfw ruleset.
5) Don't forget that ipfw has two passes, input and output, so if you are  
sending traffic from A to B into pipe without "in" or "out" options, speed  
will be half of that specified in a pipe.

-- 
WBR, Vadim Goncharov



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?optx3bu3br4fjv08>