Named states in ipfw (and old rulesets)
Ian Smith
smithi at nimnet.asn.au
Mon Aug 15 06:11:44 UTC 2016
On Mon, 15 Aug 2016 02:20:19 +0300, Lev Serebryakov wrote:
> > Please, change this to some prefix to state name (:name, @name or something
> > like this) or to "state-action(name)" format. It will be much better: less
> > error-prone and will work without ugly warnings on old rulesets.
I like the idea of something like :name, @name or perhaps =name ? as a
distinct state name identifier. (name) seems like overkill, especially
since it requires escaping on the command line as \(name\), and while of
course such escaping is required now to identify table names, we don't
need anything that might tend to confuse table names with state names.
> Or, maybe, state names should be pre-declared (except "default"), as
> table's ones does. Like
>
> ipfw flow create my-name
> ipfw add allow ip from an to any keep-state my-name
I really hope that's not necessary; the assumption of 'default' name for
existing rulesets is good, and requiring pre-declaration of state names
- except default - would be less .. orthogonal :) and not necessary.
One thing I wondered about earlier but didn't ask is that the order of
options is generally not relevant, so for example the commonly used:
ipfw add skipto $somewhere tcp from $a to $b setup keep-state
would currently be equally valid as:
ipfw add skipto $somewhere tcp from $a to $b keep-state setup
with possibly other options following?
And while 'setup' should be recognised as an existing keyword, not a
state name - as will '//' when that's fixed I guess? - still I wondered
whether the keyword 'setup' would get "pushed back" for later parsing?
> This will be somewhat bullet-proof!
I think existing rulesets working out of the box is vital too; the last
thing needed on managed remote boxes is firewall breakage on upgrading.
cheers, Ian
More information about the freebsd-ipfw
mailing list