Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 04 Sep 2007 03:51:40 -0700
From:      Julian Elischer <>
To:        Vadim Goncharov <>
Cc:, Russell Fulton <>
Subject:   Re: getting state to work properly
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Vadim Goncharov wrote:
> 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:

also bear in mind the way that state is done..
it's not documented anywhere but when you do a 'keep-state', the rule that
does the keep-state is stored away, and when a "check state" is run,
it effectively JUMPS TO the rule that did the keep-state.

If the rule contains some action that is not terminal, then EXECUTION CONTINUES
at that point!!!

for example

"some rules"
skipto xxx [packet definition] keep state

xxx: more rules

the first packet will execute all of "some rules"
but subsequent packets from thise sessions will skip straight to 
the skipto.

All packets will do the test in the skipto rule, and subsequent rules.

> 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.


Want to link to this message? Use this URL: <>