Date: Mon, 13 Jun 2016 23:19:24 +0800 From: Julian Elischer <julian@freebsd.org> To: lev@FreeBSD.org, "Andrey V. Elsukov" <ae@FreeBSD.org>, freebsd-ipfw@freebsd.org Cc: "Alexander V. Chernikov" <melifaro@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? Message-ID: <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> In-Reply-To: <5759DB79.10205@FreeBSD.org> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/06/2016 5:11 AM, Lev Serebryakov wrote: > -----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. In writing complicated automatically generated firewalls, I've wanted the following capacities: 1/ one state table for one part of the flow and another for a different part... e.g. a different table for "inside" nat to "outside" nat.. also a different table for the inside interface to the outside interface.. just because you allow a flow at one interface doesn't mean you want it to be allowed through a different one. 2/ The ability to specifically add a flow's state rule to a table, without EVERY OTHER FLOW hitting a 'check-state' at that point. If I select s particular flow , then I do not want other flows affected. just that flow should be affected. 3/ the ability to select a completley different firewall for a differnent interface.. this can be simulated at the moment. but it'd be nice to be able to specify a entry pont into the table or a separate table per interface.. ipfw interface xn0 in enter 5000 or something. or maybe ipfw interface firewall 3 4/ the ability to have variables and set and test them. We ALMOST have that with tags . i] variables would hav eone of several scopes: a) a single transit.. you might set some flag at rule 40 and branch on it at rule 4000, but a separate packet would ahv ea different instance. b) per flow.. assigned at creation of the dynamic rule and avaliable at any time after a packet has been associated with that flow. c) global ii] branching on values is possible. there are others I've wanted (and forgotten) but that's the wish-list I have at the moment. >> 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?3d09497c-136c-e217-154c-ba00e6879c6f>