IPFW: more "orthogonal? state operations, push into 11?

[Julian Elischer]

On 7/06/2016 10:31 PM, Ian Smith wrote:
> On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote:
>   > On 06.06.16 22:41, Lev Serebryakov wrote:
>   > >
>   > >  I still hope to see https://reviews.freebsd.org/D1776 committed before
>   > > 11-RELEASE.
>   > >
>   > >  It seems to me, that I does everything what was requested by reviewers.
>   >
>   > Hi Lev,
>   >
>   > looking at provided description and examples, seems the main task you
>   > want to solve is problem with NAT. But from my point of view, you are
>   > trying to solve it in a easy way wrongly using existing methods.
>   >
>   > As you described in patch to ipfw(8) "Problem is, you need to create
>   > dynamic rule before NAT and check it after NAT actions (or vice versa)
>   > to have consistent addresses and ports."
>   >
>   > In terms of ipfw(4) a state is represented by ipfw_flow_id structure.
>   > To solve your task you just needs two states - one for not translated
>   > flow and second - for translated. Due to limits of implementation this
>   > looks impossible to solve. But proposed patch with deferred action looks
>   > too hackish to me.
>   >
>   > With the following patch you will be able create two different states, I
>   > think, and solve your task with NAT and dynamic rules:
>   >   https://reviews.freebsd.org/D6674
>
> If your patch does what Lev wanted to achieve with (I thought too many)
> new dynamic rule actions, then I think your simpler solution is better,
> not least because it's far easier to understand for non-Julians :)

actually I want only  subset..
what I want is a "set-state"  that is the same as keep-state, but does 
not have
the implicit check-state before it. (if it has a collision with an 
existing rule it overrides it)
I also want he named state tables.   :-)

>
> Looking from a useability and documentation perspective only - I won't
> even be looking at this code - I have a few thoughts:
>
> Thus far, keep-state and limit seem to be interchangeable options; limit
> rules will need to work the same with respect to named dynamic flows; do
> I assume that you've just started with only keep-state for testing?
>
> I think flow names should be specified as an _optional_ parameter, thus:
>
>      check-state [name]
>
>      keep-state [name]
>
>      limit {src-addr | src-port | dst-addr | dst-port} N [name]
>
> where name (maybe flowname, for easier comprehension by man readers?) is
> optional, assigned as 'default' whenever omitted - as well as being for
> backwards ruleset compatibility, which then only needs mentioning once,
> and maybe also put another way in the STATEFUL FIREWALL section.

I think flowname  is a bad name..  it's a state table name.

>
> So a few of the existing example rules with no name could stand, while
> others (see below) append names of OUTBOUND and INBOUND or whatever.
>
> As is, you have
>
> 740		.It Cm check-state Op Ar name | Cm any | Cm default
>
> which in other contexts would mean you have to supply one of 'name' or
> 'any' or 'default' when you don't have to provide one, 'default' being
> assigned otherwise.  Otherwise I think this is fairly well described.
>
> Will 'ipfw -[e]d list|show' show the flow names? or the indices?
>
> As I pestered Lev about last year, we still need a small example ruleset
> section that actually deals with potentially problematic stateful issues
> with NAT - which I still don't fully understand - beyond descriptions in
> the abstract case; ie an actual working dual- or multi-flow example.
>
> I know these are "just doc" issues of little importance while testing
> working code, and I haven't supplied any patches, so are just FWIW ..
>
> cheers, Ian
>