Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jun 2016 00:49:35 +1000 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Julian Elischer <julian@freebsd.org>
Cc:        "Andrey V. Elsukov" <ae@freebsd.org>, lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" <melifaro@freebsd.org>
Subject:   Re: IPFW: more "orthogonal? state operations, push into 11?
Message-ID:  <20160616003432.A15883@sola.nimnet.asn.au>
In-Reply-To: <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org>
References:  <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Jun 2016 22:59:19 +0800, Julian Elischer wrote:
 > 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.   :-)

Ok, but you're regularly referring to multiple state _tables_, but I 
think that what is proposed is one table with name added to protocol, 
addresses and ports as a parameter rather than as distinct tables?

Is that right, Andrey?  As I said, I'm not looking at the code now.

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

I don't think so.  That was just a suggestion in place of generic 'name' 
but the more I read your following message, which I'll respond to next, 
the more I think you've made a good case for 'flowname', which Andrey 
has used in latest review in ipfw(8).  Onwards ..

cheers, Ian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160616003432.A15883>