Date: Mon, 13 Jun 2016 22:59:19 +0800 From: Julian Elischer <julian@freebsd.org> To: Ian Smith <smithi@nimnet.asn.au>, "Andrey V. Elsukov" <ae@freebsd.org> Cc: 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: <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org> In-Reply-To: <20160607220136.R15883@sola.nimnet.asn.au> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8fd8d2f7-72f9-4a0f-5123-d080450d3261>