From owner-freebsd-ipfw@freebsd.org Mon Jun 13 14:59:33 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 6A1B8AF1110 for ; Mon, 13 Jun 2016 14:59:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49B60212B; Mon, 13 Jun 2016 14:59:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-242-176.lns20.per4.internode.on.net [121.45.242.176]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u5DExOd5055447 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2016 07:59:27 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Ian Smith , "Andrey V. Elsukov" References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> Cc: lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" From: Julian Elischer Message-ID: <8fd8d2f7-72f9-4a0f-5123-d080450d3261@freebsd.org> Date: Mon, 13 Jun 2016 22:59:19 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160607220136.R15883@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 13 Jun 2016 14:59:33 -0000 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 >