Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jun 2016 00:11:21 +0300
From:      Lev Serebryakov <>
To:        "Andrey V. Elsukov" <>,
Cc:        "Alexander V. Chernikov" <>,  Julian Elischer <>
Subject:   Re: IPFW: more "orthogonal? state operations, push into 11?
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Hash: SHA512

On 07.06.2016 00:53, Andrey V. Elsukov wrote:

> 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.
  It is was initial driver for this patch, yes, but, please, read
subject (? is mistype, of course, it is closing ").

  Current set of primitives, dealing with state, is terribly wrong,
IMHO. "keep-state" which trigger (any!) state check alone is awuful,
and complete "keep-state / check-state" pair is ugly hack. It is like
CISC vs RISC, actually.

  New primitives are ORTHOGONAL. Each one solves one and only one
well-defined task, state creation, state checking and command
execution are well-separated. IMHO, "keep-state" in it current form
should be killed with fire. Yes, I understand about backward
compatibility and POLA, so I don't propose to really remove it, but,
IMHO, new set is much, much better.

> 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."
  It is only very rudimentary example to show the point of new
primitives. All meaningful examples require big and complex rulesets,

> 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.
  For what?! Logically it is one flow. NAT is kludge itself, of
course, but, IMHO, logically it doesn't create new flow, or
connection, whatever your name it. It hacks existing one.

> Due to limits of implementation this looks impossible to solve. But
> proposed patch with deferred action looks too hackish to me.
  IMHO, it untangles current very sad situation.

> With the following patch you will be able create two different
> states, I think, and solve your task with NAT and dynamic rules: 
 Named states are great and very useful by themselves, but how this
solve problem, that "keep-state" implies "check-state" rule, for example

 I seen a thousand posts, messages and how-tos about stateful IPFW and
all of them suffer from this "keep-state is check-state" problem,
really, when you try to structure your firewall in "ingress / egress"
per-interface sections and not one small ruleset for one interface.

- -- 
// Lev Serebryakov AKA Black Lion
Version: GnuPG v2.0.22 (MingW32)


Want to link to this message? Use this URL: <>