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-----
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
