From owner-freebsd-ipfw@freebsd.org Wed Jun 15 15:03:34 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99363A44FAC for ; Wed, 15 Jun 2016 15:03:34 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11D4617C1; Wed, 15 Jun 2016 15:03:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u5FEnZOw004724; Thu, 16 Jun 2016 00:49:35 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 16 Jun 2016 00:49:35 +1000 (EST) From: Ian Smith To: Julian Elischer cc: "Andrey V. Elsukov" , lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" Subject: Re: IPFW: more "orthogonal? state operations, push into 11? In-Reply-To: <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org> Message-ID: <20160616003432.A15883@sola.nimnet.asn.au> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:03:34 -0000 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