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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5759DB79.10205>