Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jun 2016 00:11:21 +0300
From:      Lev Serebryakov <lev@FreeBSD.org>
To:        "Andrey V. Elsukov" <ae@FreeBSD.org>, freebsd-ipfw@freebsd.org
Cc:        "Alexander V. Chernikov" <melifaro@FreeBSD.org>,  Julian Elischer <julian@freebsd.org>
Subject:   Re: IPFW: more "orthogonal? state operations, push into 11?
Message-ID:  <5759DB79.10205@FreeBSD.org>
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
-----BEGIN PGP SIGNED MESSAGE-----
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,
really.

> 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: 
> https://reviews.freebsd.org/D6674
 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJXWdt4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePQ+kP/jTUZQ/W2srUhiRCkTzDsGpy
dbODp6utMjQGwtZKgPRVN4+0KuchgJInA6odB/34WKfgW5THpevLkh5do8QGvm+5
/8DcYZOYwCk45TRkjhctBH6u2t0v3TPvjd1pPkknmhd3qE9Zzkk2fi+0iUWBavMH
LvLJ+afUlmw8l95Om8g4Per3C7TEWmxXews3k+vg1xgrTtPn6m1Vcwspp7gHe2Zo
OIGTzDl0S95SUofQuQX3vD7gPqm6YTnRVhtHrb36saVpP2HCv6e+7vOkyfiTV4nd
Mchu3T6e9zJ2cmWBRIE9d/wB18LRVjWE+pvosTf6EEIkRJnUUnCZF19EJj8BS+9X
7+zbPnVeUSo17YdxSTcDXL0cBuzRIsz50V2Q6bFgl313PB9u97a4FeLdNmqEZfnN
jEgeonc8loN6Fw/Mgjdn2wjmAhZaWU+zCpozzDPcjevkl9NIVVkMys4iZUUCdRkG
yGQtU18X3hHwrbM4uJs7K9JLJj1HHEgpT9mnZ3qxCQ1YKEWZ0plgPvXoFWOiYYIB
Ecz19D/kLBad3gVZ0X9NZwqA2XM23UmfMiKqd0ZcoOPiMY1WY35PQWOocOhiCIW4
mhcEwp9ZR2mV7OZEO1ObLiK1Jo/q0xNn2eV9UgSrYJGSjOSLPj+9rC2zOjBbO1EO
o1H+cNxLn5zMM4sybo9X
=WZgr
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?5759DB79.10205>