Date: Wed, 4 Feb 2015 23:34:12 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-ipfw@freebsd.org, lev@freebsd.org Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny Message-ID: <20150204231922.X38620@sola.nimnet.asn.au> In-Reply-To: <54D1FE72.1020508@freebsd.org> References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Feb 2015 19:121:46 +0000, Julian Elischer wrote: > On 2/4/15 5:22 PM, Lev Serebryakov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 04.02.2015 08:13, Julian Elischer wrote: > > > > > yes I think "keep-state" should be deprecated and replaced or > > > supplemented by 'save_state' that does NOT do an implicit > > > 'check-state'.. I don't know whose idea that was but it's just > > > wrong. (if the state exists, maybe just replace it..) > > Update, not replace :) > > See my Version-3 patch for "record-state" :) > I meant a function that acts like 'keep-state' except it does not do a > 'check-state'. > Im suggesting adding yet-another command. a 'fixed' keep-state. > > I sort of know why they did it.. so that if the state for that > session already exists, the original state rule is used and not the > new rule. but ..it fires on other packets as well as the one you are > working with. I don't get this .. we're always working on just one packet at any time, either inbound or outbound (to kernel), so how can check_state (or the check also on keep-state) apply to any other packets than that one? I've seen examples that run keep-state on the same packet both before and after NAT, ie state on both the internal and external addresses, which is even more confusing and surely inefficient too. I'm not sure that everyone realises that it's the first check-state or keep-state rule _encountered_ - ie not skipped around - that matters. A good, definitive tutorial on how to best handle stateful, NAT'd rules would be useful, because there are a few different theories in the wild. Personally I only run stateful on a few types of session, and then always using the internal addresses, but that's just one of the ways .. but doing _everything_ statefully seems to be the Holy Grail to some. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150204231922.X38620>