Date: Wed, 8 Jun 2016 00:31:03 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "Andrey V. Elsukov" <ae@freebsd.org> Cc: lev@freebsd.org, freebsd-ipfw@freebsd.org, Julian Elischer <julian@freebsd.org>, "Alexander V. Chernikov" <melifaro@freebsd.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? Message-ID: <20160607220136.R15883@sola.nimnet.asn.au> In-Reply-To: <5755F0D3.9060909@FreeBSD.org> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :) 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. 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?20160607220136.R15883>