IPFW: more "orthogonal? state operations, push into 11?
I still hope to see https://reviews.freebsd.org/D1776 committed before 11-RELEASE. It seems to me, that I does everything what was requested by reviewers. Please? -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On Mon, Jun 6, 2016, at 14:41, Lev Serebryakov wrote: > > I still hope to see https://reviews.freebsd.org/D1776 committed before > 11-RELEASE. > > It seems to me, that I does everything what was requested by reviewers. > > Please? > I agree, this looks very useful -- Mark Felder f...@feld.me ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 06.06.16 22:41, Lev Serebryakov wrote: > > I still hope to see https://reviews.freebsd.org/D1776 committed before > 11-RELEASE. > > It seems to me, that I does everything what was requested by reviewers. Hi Lev, 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. 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." 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. Due to limits of implementation this looks impossible to solve. But proposed patch with deferred action looks too hackish to me. 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 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 07.06.16 09:31, wishmaster wrote: >> 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 > > Will there be the patch in the 11-RELEASE? Hi, there are three patches for ipfw, that I want to commit: https://reviews.freebsd.org/D6420 https://reviews.freebsd.org/D6434 https://reviews.freebsd.org/D6674 But we are in code slush and there aren't any positive review yet. So, I guess they will be committed only after 11.0 would be branched. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote:
> On 06.06.16 22:41, Lev Serebryakov wrote:
> >
> > I still hope to see https://reviews.freebsd.org/D1776 committed before
> > 11-RELEASE.
> >
> > It seems to me, that I does everything what was requested by reviewers.
>
> Hi Lev,
>
> 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.
>
> 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."
>
> 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. Due to limits of implementation this
> looks impossible to solve. But proposed patch with deferred action looks
> too hackish to me.
>
> 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
If your patch does what Lev wanted to achieve with (I thought too many)
new dynamic rule actions, then I think your simpler solution is better,
not least because it's far easier to understand for non-Julians :)
Looking from a useability and documentation perspective only - I won't
even be looking at this code - I have a few thoughts:
Thus far, keep-state and limit seem to be interchangeable options; limit
rules will need to work the same with respect to named dynamic flows; do
I assume that you've just started with only keep-state for testing?
I think flow names should be specified as an _optional_ parameter, thus:
check-state [name]
keep-state [name]
limit {src-addr | src-port | dst-addr | dst-port} N [name]
where name (maybe flowname, for easier comprehension by man readers?) is
optional, assigned as 'default' whenever omitted - as well as being for
backwards ruleset compatibility, which then only needs mentioning once,
and maybe also put another way in the STATEFUL FIREWALL section.
So a few of the existing example rules with no name could stand, while
others (see below) append names of OUTBOUND and INBOUND or whatever.
As is, you have
740 .It Cm check-state Op Ar name | Cm any | Cm default
which in other contexts would mean you have to supply one of 'name' or
'any' or 'default' when you don't have to provide one, 'default' being
assigned otherwise. Otherwise I think this is fairly well described.
Will 'ipfw -[e]d list|show' show the flow names? or the indices?
As I pestered Lev about last year, we still need a small example ruleset
section that actually deals with potentially problematic stateful issues
with NAT - which I still don't fully understand - beyond descriptions in
the abstract case; ie an actual working dual- or multi-flow example.
I know these are "just doc" issues of little importance while testing
working code, and I haven't supplied any patches, so are just FWIW ..
cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 07/06/16 10:00, Andrey V. Elsukov wrote: On 07.06.16 09:31, wishmaster wrote: 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 Will there be the patch in the 11-RELEASE? Hi, there are three patches for ipfw, that I want to commit: https://reviews.freebsd.org/D6420 https://reviews.freebsd.org/D6434 https://reviews.freebsd.org/D6674 But we are in code slush and there aren't any positive review yet. So, I guess they will be committed only after 11.0 would be branched. To bad. Those all look very useful and and together would enable me to use my FreeBSD jail hosts for all packet filtering instead of running the traffic through a OpenBSD bhyve guest on each jail host. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
It is more and more complex here! On 8 June 2016 at 17:28, Jan Bramkamp wrote: > On 07/06/16 10:00, Andrey V. Elsukov wrote: > >> On 07.06.16 09:31, wishmaster wrote: >> >>> 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 >>> >>> Will there be the patch in the 11-RELEASE? >>> >> >> Hi, >> >> there are three patches for ipfw, that I want to commit: >> https://reviews.freebsd.org/D6420 >> https://reviews.freebsd.org/D6434 >> https://reviews.freebsd.org/D6674 >> >> But we are in code slush and there aren't any positive review yet. So, I >> guess they will be committed only after 11.0 would be branched. >> > > To bad. Those all look very useful and and together would enable me to use > my FreeBSD jail hosts for all packet filtering instead of running the > traffic through a OpenBSD bhyve guest on each jail host. > > ___ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" > ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 07.06.16 17:31, Ian Smith wrote:
> If your patch does what Lev wanted to achieve with (I thought too many)
> new dynamic rule actions, then I think your simpler solution is better,
> not least because it's far easier to understand for non-Julians :)
>
> Looking from a useability and documentation perspective only - I won't
> even be looking at this code - I have a few thoughts:
>
> Thus far, keep-state and limit seem to be interchangeable options; limit
> rules will need to work the same with respect to named dynamic flows; do
> I assume that you've just started with only keep-state for testing?
We don't use limit rules at all, so it wasn't implemented. I think it
will not so hard to implement.
> I think flow names should be specified as an _optional_ parameter, thus:
>
> check-state [name]
>
> keep-state [name]
>
> limit {src-addr | src-port | dst-addr | dst-port} N [name]
>
> where name (maybe flowname, for easier comprehension by man readers?) is
> optional, assigned as 'default' whenever omitted - as well as being for
> backwards ruleset compatibility, which then only needs mentioning once,
> and maybe also put another way in the STATEFUL FIREWALL section.
>
> So a few of the existing example rules with no name could stand, while
> others (see below) append names of OUTBOUND and INBOUND or whatever.
>
> As is, you have
>
> 740 .It Cm check-state Op Ar name | Cm any | Cm default
>
> which in other contexts would mean you have to supply one of 'name' or
> 'any' or 'default' when you don't have to provide one, 'default' being
> assigned otherwise. Otherwise I think this is fairly well described.
>
> Will 'ipfw -[e]d list|show' show the flow names? or the indices?
It will show the flow name at the end of line.
> As I pestered Lev about last year, we still need a small example ruleset
> section that actually deals with potentially problematic stateful issues
> with NAT - which I still don't fully understand - beyond descriptions in
> the abstract case; ie an actual working dual- or multi-flow example.
>
> I know these are "just doc" issues of little importance while testing
> working code, and I haven't supplied any patches, so are just FWIW ..
Will try to implement support for limit rules and update man. Thanks.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
In my opinion,
keep-state == "if this kind of packet come again, we are going to perform
the current action"
check-state == "did we met this kind of packet before? Yes! then perform
that action"
so in DragonflyBSD, below commands are implemented to manipulate the
"states"
ipfw3 state show [rulenum]
ipfw3 state add rule rulenum proto src:port dst:port [state-options]
ipfw3 state delete rulenum
On 8 June 2016 at 18:36, Andrey V. Elsukov wrote:
> On 07.06.16 17:31, Ian Smith wrote:
> > If your patch does what Lev wanted to achieve with (I thought too many)
> > new dynamic rule actions, then I think your simpler solution is better,
> > not least because it's far easier to understand for non-Julians :)
> >
> > Looking from a useability and documentation perspective only - I won't
> > even be looking at this code - I have a few thoughts:
> >
> > Thus far, keep-state and limit seem to be interchangeable options; limit
> > rules will need to work the same with respect to named dynamic flows; do
> > I assume that you've just started with only keep-state for testing?
>
> We don't use limit rules at all, so it wasn't implemented. I think it
> will not so hard to implement.
>
> > I think flow names should be specified as an _optional_ parameter, thus:
> >
> > check-state [name]
> >
> > keep-state [name]
> >
> > limit {src-addr | src-port | dst-addr | dst-port} N [name]
> >
> > where name (maybe flowname, for easier comprehension by man readers?) is
> > optional, assigned as 'default' whenever omitted - as well as being for
> > backwards ruleset compatibility, which then only needs mentioning once,
> > and maybe also put another way in the STATEFUL FIREWALL section.
> >
> > So a few of the existing example rules with no name could stand, while
> > others (see below) append names of OUTBOUND and INBOUND or whatever.
> >
> > As is, you have
> >
> > 740 .It Cm check-state Op Ar name | Cm any | Cm default
> >
> > which in other contexts would mean you have to supply one of 'name' or
> > 'any' or 'default' when you don't have to provide one, 'default' being
> > assigned otherwise. Otherwise I think this is fairly well described.
> >
> > Will 'ipfw -[e]d list|show' show the flow names? or the indices?
>
> It will show the flow name at the end of line.
>
> > As I pestered Lev about last year, we still need a small example ruleset
> > section that actually deals with potentially problematic stateful issues
> > with NAT - which I still don't fully understand - beyond descriptions in
> > the abstract case; ie an actual working dual- or multi-flow example.
> >
> > I know these are "just doc" issues of little importance while testing
> > working code, and I haven't supplied any patches, so are just FWIW ..
>
> Will try to implement support for limit rules and update man. Thanks.
>
> --
> WBR, Andrey V. Elsukov
>
>
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 7/06/2016 3:41 AM, Lev Serebryakov wrote: I still hope to see https://reviews.freebsd.org/D1776 committed before 11-RELEASE. It seems to me, that I does everything what was requested by reviewers. Please? I think I gave a blessing a long time ago.. you are blocked by melifaro I forget who he is in email or I'd send him one asking for some action. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
-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) iQJ8BAEBCgBmBQJXWdt4XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w 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- ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 10.06.16 00:11, Lev Serebryakov wrote: >> 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. Your patch does exactly what I said - it creates state for untranslated flow when you call record-state with deferred action. Then after translation this flow has new addresses and ports, so ipfw_install_or_update_state() will create new state, old state will not updated (don't know for what purpose you have renamed it). Then when check-state/probe-state will be checked, both states can be updated by lookup_dyn_rule_locked() depending from flow that triggers this opcode. So, you introduced new implicit behavior while thinking that resolve old wrong behavior. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10.06.2016 11:07, Andrey V. Elsukov wrote: >>> 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. > > Your patch does exactly what I said - it creates state for > untranslated flow when you call record-state with deferred action. > Then after translation this flow has new addresses and ports, so > ipfw_install_or_update_state() will create new state, old state > will not updated (don't know for what purpose you have renamed > it). Why will ipfw_install_or_update_state() be called after translation with my patch and example? I'm using my patch more than year, and I don't have any problems with splitting of states or expiration of "right" ones, and I've checked dynamic states very carefully first several days after patch was complete (and I had problems with rules expiration in very first, unpublished, version of my patch). > Then when check-state/probe-state will be checked, both states can > be updated by lookup_dyn_rule_locked() depending from flow that > triggers this opcode. So, you introduced new implicit behavior > while thinking that resolve old wrong behavior. Sorry, I lost you here. Why untranslated flow will trigger check opcode? It will be mistake in ruleset, for sure! - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJXW9yaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePIKEP/jPPXByu7ufxZhoK7LJ7SY4Q VEmbrQ+FXvtwkQEHCLVeAPYjOkELVhyM+Z+mJijx4cnYibvmzS1Eh1pPYvsanios x3iec4rz86wli53rhxh19hzWRzmKAXHiw3xd+eIjvlgnIx+TTresn1fNeudVPpwU /iGlehzwAxaZXctjsQkwqJolZLtb8iy98OHE0W/Maj0sjJNj+4b6Cn52oi5Z70V4 DlJ5SbKpUr7NHRCLidA5YxLDQ2MHJimBHh/zoSisU7DmsvrQiJ8ETF5A6b9QFQNV WmKlrd3N+biXF2kXpq9fjTRet0BMhfLgkZk+l/GaY6vJ8C5k0cQuh1GD5ZbJ23D3 mgdE41LFX/m7iXpdc0DoKW8nF8yVJsgYvxnaIKN+i7VVKBp4MUIhsdF66k7KUewB /IHH3kPMdIBleQgfO92QLomCTyD0s31MqclPq3bm+AfI94ZuJonN2YSzgkO1HwXF 0xCsR9C/PxM7AYtiF9QEuaUOr/gVPZQUJlvUcJ2Lh2r9vsEB35qGkAuPTAZwufI7 nzeFNKiSJxv/PL3YmL1qHEQNHqdvt8OdaJ+IZacNl7PfnGsQ76P3O9BTj6QWGAAS 1uxW1qZGp2hcAbv1J5ctNOG9OFNLP7mnVTMIIoX9Ze8FITibJDo5pLfIMJuJv4cy F6G6phqgAAckRcOm3ab3 =fjEL -END PGP SIGNATURE- ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 7/06/2016 4:00 PM, Andrey V. Elsukov wrote: On 07.06.16 09:31, wishmaster wrote: 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 Will there be the patch in the 11-RELEASE? Hi, there are three patches for ipfw, that I want to commit: https://reviews.freebsd.org/D6420 https://reviews.freebsd.org/D6434 https://reviews.freebsd.org/D6674 But we are in code slush and there aren't any positive review yet. So, I guess they will be committed only after 11.0 would be branched. 6674 would be good to have.. I;ve given it a +1 The feature I want from Lev's change is the ability to store a state entry without the implicit check-state. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 7/06/2016 10:31 PM, Ian Smith wrote:
On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote:
> On 06.06.16 22:41, Lev Serebryakov wrote:
> >
> > I still hope to see https://reviews.freebsd.org/D1776 committed before
> > 11-RELEASE.
> >
> > It seems to me, that I does everything what was requested by reviewers.
>
> Hi Lev,
>
> 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.
>
> 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."
>
> 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. Due to limits of implementation this
> looks impossible to solve. But proposed patch with deferred action looks
> too hackish to me.
>
> 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
If your patch does what Lev wanted to achieve with (I thought too many)
new dynamic rule actions, then I think your simpler solution is better,
not least because it's far easier to understand for non-Julians :)
actually I want only subset..
what I want is a "set-state" that is the same as keep-state, but does
not have
the implicit check-state before it. (if it has a collision with an
existing rule it overrides it)
I also want he named state tables. :-)
Looking from a useability and documentation perspective only - I won't
even be looking at this code - I have a few thoughts:
Thus far, keep-state and limit seem to be interchangeable options; limit
rules will need to work the same with respect to named dynamic flows; do
I assume that you've just started with only keep-state for testing?
I think flow names should be specified as an _optional_ parameter, thus:
check-state [name]
keep-state [name]
limit {src-addr | src-port | dst-addr | dst-port} N [name]
where name (maybe flowname, for easier comprehension by man readers?) is
optional, assigned as 'default' whenever omitted - as well as being for
backwards ruleset compatibility, which then only needs mentioning once,
and maybe also put another way in the STATEFUL FIREWALL section.
I think flowname is a bad name.. it's a state table name.
So a few of the existing example rules with no name could stand, while
others (see below) append names of OUTBOUND and INBOUND or whatever.
As is, you have
740 .It Cm check-state Op Ar name | Cm any | Cm default
which in other contexts would mean you have to supply one of 'name' or
'any' or 'default' when you don't have to provide one, 'default' being
assigned otherwise. Otherwise I think this is fairly well described.
Will 'ipfw -[e]d list|show' show the flow names? or the indices?
As I pestered Lev about last year, we still need a small example ruleset
section that actually deals with potentially problematic stateful issues
with NAT - which I still don't fully understand - beyond descriptions in
the abstract case; ie an actual working dual- or multi-flow example.
I know these are "just doc" issues of little importance while testing
working code, and I haven't supplied any patches, so are just FWIW ..
cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
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) iQJ8BAEBCgBmBQJXWdt4XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w 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/q0xNn
Re: IPFW: more "orthogonal? state operations, push into 11?
On Mon, 13 Jun 2016 22:59:19 +0800, Julian Elischer wrote:
> On 7/06/2016 10:31 PM, Ian Smith wrote:
> > On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote:
> > > On 06.06.16 22:41, Lev Serebryakov wrote:
> > > >
> > > > I still hope to see https://reviews.freebsd.org/D1776 committed
> > before
> > > > 11-RELEASE.
> > > >
> > > > It seems to me, that I does everything what was requested by
> > reviewers.
> > >
> > > Hi Lev,
> > >
> > > 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.
> > >
> > > 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."
> > >
> > > 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. Due to limits of implementation this
> > > looks impossible to solve. But proposed patch with deferred action
> > looks
> > > too hackish to me.
> > >
> > > 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
> >
> > If your patch does what Lev wanted to achieve with (I thought too many)
> > new dynamic rule actions, then I think your simpler solution is better,
> > not least because it's far easier to understand for non-Julians :)
>
> actually I want only subset..
> what I want is a "set-state" that is the same as keep-state, but does not
> have
> the implicit check-state before it. (if it has a collision with an existing
> rule it overrides it)
> I also want he named state tables. :-)
Ok, but you're regularly referring to multiple state _tables_, but I
think that what is proposed is one table with name added to protocol,
addresses and ports as a parameter rather than as distinct tables?
Is that right, Andrey? As I said, I'm not looking at the code now.
> > Looking from a useability and documentation perspective only - I won't
> > even be looking at this code - I have a few thoughts:
> >
> > Thus far, keep-state and limit seem to be interchangeable options; limit
> > rules will need to work the same with respect to named dynamic flows; do
> > I assume that you've just started with only keep-state for testing?
> >
> > I think flow names should be specified as an _optional_ parameter, thus:
> >
> > check-state [name]
> >
> > keep-state [name]
> >
> > limit {src-addr | src-port | dst-addr | dst-port} N [name]
> >
> > where name (maybe flowname, for easier comprehension by man readers?) is
> > optional, assigned as 'default' whenever omitted - as well as being for
> > backwards ruleset compatibility, which then only needs mentioning once,
> > and maybe also put another way in the STATEFUL FIREWALL section.
> I think flowname is a bad name.. it's a state table name.
I don't think so. That was just a suggestion in place of generic 'name'
but the more I read your following message, which I'll respond to next,
the more I think you've made a good case for 'flowname', which Andrey
has used in latest review in ipfw(8). Onwards ..
cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote: > 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. Lev, is there any chance you and Andrey can work together here? At the moment we seem to have two 'competing' models. Can they be melded at all? Or can you live with adding new opcodes on top of Andrey's named states? (Feel free to tell me that this is none of my business ..) > 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.. Isn't one table with distinct flow-or-whatever names for matching not sufficient for this purpose? Wouldn't that also be faster than having to consult multiple distinct tables? In the end those are details the user doesn't need to know about .. but ze does need to comprehend the terms conveying the ideas. > 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. Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside', 'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to distinguish multiple flows? Why doesn't 'flowname' sound right to describe what you call 'flows'? > 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. Isn't that the case with Andrey's code at the moment, if you specify a name on that keep-state rule, only that - erm - flow would be checked and not other flows (including 'default' where added by unnamed rules)? Can I assume that if this is the first keep-state|limit for one flowname then an implicit check-state would check that flow only, finding none? Similarly, if I'm grokking this at all right, then only a check-state (or another keep-state or limit encountered) with that same name will match existing states having that same name? Issue 2/ solved or not? I hope you can see my concern that this be easily described in ipfw(8) so people without high level of expertise can easily see how it works. I'll have some more suggestions re description along the way, but after seeing clear agreement that the proposed model/s cover the usage cases described (somewhat), and where not, what more needs doing to make it acceptable as a next step, if not entirely ideal for every case .. To that end, I'll leave wishes 3/ and 4/ well alone .. as usual, FWIW cheers, Ian > 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. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebs
Re: IPFW: more "orthogonal? state operations, push into 11?
On 15.06.16 17:49, Ian Smith wrote: > Ok, but you're regularly referring to multiple state _tables_, but I > think that what is proposed is one table with name added to protocol, > addresses and ports as a parameter rather than as distinct tables? > > Is that right, Andrey? As I said, I'm not looking at the code now. Internally it is implemented as one unsigned integer in addition to addresses and ports in flow structure. So, in general, there is still one hash table. > > I think flowname is a bad name.. it's a state table name. > > I don't think so. That was just a suggestion in place of generic 'name' > but the more I read your following message, which I'll respond to next, > the more I think you've made a good case for 'flowname', which Andrey > has used in latest review in ipfw(8). Onwards .. I updated the patch in https://reviews.freebsd.org/D6674 Also I reworked Lev's patch on top of my patch and made it simpler: https://reviews.freebsd.org/D1776#143557 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 16/06/2016 12:11 AM, Ian Smith wrote: On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote: > 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. Lev, is there any chance you and Andrey can work together here? At the moment we seem to have two 'competing' models. Can they be melded at all? Or can you live with adding new opcodes on top of Andrey's named states? (Feel free to tell me that this is none of my business ..) yes, please.. > 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.. Isn't one table with distinct flow-or-whatever names for matching not sufficient for this purpose? Wouldn't that also be faster than having to consult multiple distinct tables? if you name table entries then you effectively have different tables, but yes I was mistaken in how it was being done. I had assumed a separate table In the end those are details the user doesn't need to know about .. but ze does need to comprehend the terms conveying the ideas. > 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. Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside', 'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to distinguish multiple flows? Why doesn't 'flowname' sound right to describe what you call 'flows'? multiple flows can end up in the same table/name a flow to me is some set of packets that relate to each other in source, destination and sequence. you could almost say that each pair of sockets defines a flow. Others probably have different definitions.. One could even say that in the context of ipfw, any set of packets that can be discriminated by a set of rules can be a flow. > 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. Isn't that the case with Andrey's code at the moment, if you specify a name on that keep-state rule, only that - erm - flow would be checked and not other flows (including 'default' where added by unnamed rules)? no. but it is the case with Lev's patch (and Andrey's matching effort) Can I assume that if this is the first keep-state|limit for one flowname then an implicit check-state would check that flow only, finding none? I don't know. currently the selector part of the rule doesn't distinguish who does a check-state. I'm guessing he finds the label and uses it but I don't know. Similarly, if I'm grokking this at all right, then only a check-state (or another keep-state or limit encountered) with that same name will match existing states having that same name? Issue 2/ solved or not? Issue 2 is mostly solved for many cases. I hope you can see my concern that this be easily described in ipfw(8) so people without high level of expertise can easily see how it works. I'll have some more suggestions re description along the way, but after seeing clear agreement that the proposed model/s cover the usage cases described (somewhat), and where not, what more needs doing to make it acceptable as a next step, if not entirely ideal for every case .. To that end, I'll leave wishes 3/ and 4/ well alone .. as usual, FWIW cheers, Ian > 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 int
Re: IPFW: more "orthogonal? state operations, push into 11?
Do we have any movement on these improvements? even similar functionality by different names is ok. 1/ ability to use keep-state without an implicit check-state. <--- most important for me. (store-state)? 2/ ability to keep-state without actually doing it < less important for me. 3/ multiple state tables? this was discussed and I thought I saw patches but I haven't seen it going in, <-- super luxurious On 20/06/2016 9:59 PM, Julian Elischer wrote: On 16/06/2016 12:11 AM, Ian Smith wrote: On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote: > 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. Lev, is there any chance you and Andrey can work together here? At the moment we seem to have two 'competing' models. Can they be melded at all? Or can you live with adding new opcodes on top of Andrey's named states? (Feel free to tell me that this is none of my business ..) yes, please.. > 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.. Isn't one table with distinct flow-or-whatever names for matching not sufficient for this purpose? Wouldn't that also be faster than having to consult multiple distinct tables? if you name table entries then you effectively have different tables, but yes I was mistaken in how it was being done. I had assumed a separate table In the end those are details the user doesn't need to know about .. but ze does need to comprehend the terms conveying the ideas. > 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. Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside', 'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to distinguish multiple flows? Why doesn't 'flowname' sound right to describe what you call 'flows'? multiple flows can end up in the same table/name a flow to me is some set of packets that relate to each other in source, destination and sequence. you could almost say that each pair of sockets defines a flow. Others probably have different definitions.. One could even say that in the context of ipfw, any set of packets that can be discriminated by a set of rules can be a flow. > 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. Isn't that the case with Andrey's code at the moment, if you specify a name on that keep-state rule, only that - erm - flow would be checked and not other flows (including 'default' where added by unnamed rules)? no. but it is the case with Lev's patch (and Andrey's matching effort) Can I assume that if this is the first keep-state|limit for one flowname then an implicit check-state would check that flow only, finding none? I don't know. currently the selector part of the rule doesn't distinguish who does a check-state. I'm guessing he finds the label and uses it but I don't know. Similarly, if I'm grokking this at all right, then only a check-state (or another keep-state or limit encountered) with that same name will match existing states having that same name? Issue 2/ solved or not? Issue 2 is mostly solved for many cases. I hope you can see my concern that this be easily described in ipfw(8) so people without high level of expertise can easily see how it works. I'll have some more suggestions re description along the way, but after seeing clear agreement tha
Re: IPFW: more "orthogonal? state operations, push into 11?
On 02.08.2016 09:47, Julian Elischer wrote: I don't have rights to commit my changes, and looks like I can not persuade others that my changes are Ok as-is, with all changes, made on requests from reviewers. Personally, I think, that (1) + (2) is orthogonal to (3) and it should be different change sets, reviews, etc. And, yes, (3) is great feature by itself. > Do we have any movement on these improvements? > even similar functionality by different names is ok. > > 1/ ability to use keep-state without an implicit check-state. <--- most > important for me. (store-state)? > 2/ ability to keep-state without actually doing it < less important > for me. > 3/ multiple state tables? this was discussed and I thought I saw patches > but I haven't seen it going in, <-- super luxurious -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 02.08.16 09:47, Julian Elischer wrote: > Do we have any movement on these improvements? > even similar functionality by different names is ok. > > 1/ ability to use keep-state without an implicit check-state. <--- most > important for me. (store-state)? > 2/ ability to keep-state without actually doing it < less important > for me. So, if there are nobody against, I plan to commit this part in a several days. > 3/ multiple state tables? this was discussed and I thought I saw patches > but I haven't seen it going in, <-- super luxurious AFAIR, this was a part of "per-interface firewall" patch from eri@ and I think it is mostly outdated now, because in head/ we did very complex changes in ipfw. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 03.08.2016 21:03, Andrey V. Elsukov wrote: >> 1/ ability to use keep-state without an implicit check-state. <--- most >> important for me. (store-state)? >> 2/ ability to keep-state without actually doing it < less important >> for me. > So, if there are nobody against, I plan to commit this part in a several > days. Which implementation? Just curious, I could live with any, really. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 03.08.16 22:07, Lev Serebryakov wrote: > On 03.08.2016 21:03, Andrey V. Elsukov wrote: > >>> 1/ ability to use keep-state without an implicit check-state. <--- most >>> important for me. (store-state)? >>> 2/ ability to keep-state without actually doing it < less important >>> for me. >> So, if there are nobody against, I plan to commit this part in a several >> days. > Which implementation? Just curious, I could live with any, really. This one https://people.freebsd.org/~ae/ipfw.diff but with separate opcodes, I have come to the opinion, that this will be more readable. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 03.08.2016 22:08, Andrey V. Elsukov wrote: 1/ ability to use keep-state without an implicit check-state. <--- most important for me. (store-state)? 2/ ability to keep-state without actually doing it < less important for me. >>> So, if there are nobody against, I plan to commit this part in a several >>> days. >> Which implementation? Just curious, I could live with any, really. > > This one > https://people.freebsd.org/~ae/ipfw.diff > > but with separate opcodes, I have come to the opinion, that this will > be more readable. How will it differ from my implementation, with separate opcode? -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 4/08/2016 12:44 AM, Lev Serebryakov wrote: On 02.08.2016 09:47, Julian Elischer wrote: I don't have rights to commit my changes, and looks like I can not persuade others that my changes are Ok as-is, with all changes, made on requests from reviewers. Personally, I think, that (1) + (2) is orthogonal to (3) and it should be different change sets, reviews, etc. And, yes, (3) is great feature by itself. I think 1 on its own would have good chance.. I'd probably commit it myself :-) save-state as a new keyword, that doesn't do a check-state. 2 is more esoteric. and sort of orthogonal to 1. Do we have any movement on these improvements? even similar functionality by different names is ok. 1/ ability to use keep-state without an implicit check-state. <--- most important for me. (store-state)? 2/ ability to keep-state without actually doing it < less important for me. 3/ multiple state tables? this was discussed and I thought I saw patches but I haven't seen it going in, <-- super luxurious just noticed this IS in... ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 4/08/2016 3:08 AM, Andrey V. Elsukov wrote: On 03.08.16 22:07, Lev Serebryakov wrote: On 03.08.2016 21:03, Andrey V. Elsukov wrote: 1/ ability to use keep-state without an implicit check-state. <--- most important for me. (store-state)? 2/ ability to keep-state without actually doing it < less important for me. So, if there are nobody against, I plan to commit this part in a several days. Which implementation? Just curious, I could live with any, really. This one https://people.freebsd.org/~ae/ipfw.diff but with separate opcodes, I have come to the opinion, that this will be more readable. so, reading it. it appears that teh record-state saves a rule as a target but doesn't actually perform the rule, right? that needs to be made more clear in the man page you say " Instead, the firewall creates a dynamic rule and the search continues with the next rule." so it's a combination of #1 and #2 in my list. I think I originally thought of having just #1. A combination is less useful for me as you need to do: 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
So while thinking about states etc, it occured to me, what does THIS do on subsequent packets in the session? 10 skipto tablearg tcp from table(3) to me keep-state On 4/08/2016 11:42 AM, Julian Elischer wrote: On 4/08/2016 3:08 AM, Andrey V. Elsukov wrote: On 03.08.16 22:07, Lev Serebryakov wrote: On 03.08.2016 21:03, Andrey V. Elsukov wrote: 1/ ability to use keep-state without an implicit check-state. <--- most important for me. (store-state)? 2/ ability to keep-state without actually doing it < less important for me. So, if there are nobody against, I plan to commit this part in a several days. Which implementation? Just curious, I could live with any, really. This one https://people.freebsd.org/~ae/ipfw.diff but with separate opcodes, I have come to the opinion, that this will be more readable. so, reading it. it appears that teh record-state saves a rule as a target but doesn't actually perform the rule, right? that needs to be made more clear in the man page you say " Instead, the firewall creates a dynamic rule and the search continues with the next rule." so it's a combination of #1 and #2 in my list. I think I originally thought of having just #1. A combination is less useful for me as you need to do: 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
Hello Julian, Thursday, August 4, 2016, 6:42:45 AM, you wrote: > A combination is less useful for me as you need to do: I'm against this too, as I really love orthogonality, as everybody know already, and your example is good example why. > 20 skipto 400 tcp from table(2) to me setup record-state > 21 skipto 400 tcp from table(2) to me setup > to make the entire session do the same thing. Sometimes it could be 20 skipto 400 tcp from table(2) to me setup record-state 21 check-state But only sometimes. -- Best regards, Levmailto:l...@freebsd.org pgpgq3uD3IS2C.pgp Description: PGP signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 04.08.16 06:42, Julian Elischer wrote: > so it's a combination of #1 and #2 in my list. I think I originally > thought of having just #1. > > A combination is less useful for me as you need to do: > > 20 skipto 400 tcp from table(2) to me setup record-state > 21 skipto 400 tcp from table(2) to me setup > to make the entire session do the same thing. So, in your example what wrong with just using keep-state? "record-state without immediate action" == "keep-state without implicit check-state" needed to solve issues with NAT or something similar, that was described by Lev. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 04.08.16 06:58, Julian Elischer wrote: > o while thinking about states etc, it occured to me, what does THIS do > on subsequent packets in the session? > > > 10 skipto tablearg tcp from table(3) to me keep-state I think it will not work like you expected when you have created this rule :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPFW: more "orthogonal? state operations, push into 11?
On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: On 04.08.16 06:42, Julian Elischer wrote: so it's a combination of #1 and #2 in my list. I think I originally thought of having just #1. A combination is less useful for me as you need to do: 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. So, in your example what wrong with just using keep-state? "record-state without immediate action" == "keep-state without implicit check-state" needed to solve issues with NAT or something similar, that was described by Lev. because keep-state is a check-state for ALL packets going past, regardless of whether they match the pattern. at least that's what I have observed. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 4/08/2016 6:27 PM, Lev Serebryakov wrote: Hello Julian, Thursday, August 4, 2016, 6:42:45 AM, you wrote: A combination is less useful for me as you need to do: I'm against this too, as I really love orthogonality, as everybody know already, and your example is good example why. 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. Sometimes it could be 20 skipto 400 tcp from table(2) to me setup record-state 21 check-state But only sometimes. exactly.. I don't want OTHER packets coming past here to hit a check-state yet.. I still have unfinished business with them. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 4/08/2016 7:20 PM, Andrey V. Elsukov wrote: On 04.08.16 06:58, Julian Elischer wrote: o while thinking about states etc, it occured to me, what does THIS do on subsequent packets in the session? 10 skipto tablearg tcp from table(3) to me keep-state I think it will not work like you expected when you have created this rule :) yes that's what I was thinking.. I'm guessing that the table is not evaluated due to the dynamic match and thus the skipto fails, either doing nothing, or dropping the packet (not sure which) ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 04/08/16 18:12, Julian Elischer wrote: On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: On 04.08.16 06:42, Julian Elischer wrote: so it's a combination of #1 and #2 in my list. I think I originally thought of having just #1. A combination is less useful for me as you need to do: 20 skipto 400 tcp from table(2) to me setup record-state 21 skipto 400 tcp from table(2) to me setup to make the entire session do the same thing. So, in your example what wrong with just using keep-state? "record-state without immediate action" == "keep-state without implicit check-state" needed to solve issues with NAT or something similar, that was described by Lev. because keep-state is a check-state for ALL packets going past, regardless of whether they match the pattern. at least that's what I have observed. According to the documentation and my experience it is. As a workaround i use skipto $stateful + record-state. That way each stateful match continues processing at $stateful. Whilte it works it's hard to understand when combined with in-kernel NAT, because you end up with asymmetric paths through the ruleset for incoming and outgoing packets. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote: > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > > On 04.08.16 06:42, Julian Elischer wrote: > > > so it's a combination of #1 and #2 in my list. I think I originally > > > thought of having just #1. > > > > > > A combination is less useful for me as you need to do: > > > > > > 20 skipto 400 tcp from table(2) to me setup record-state > > > 21 skipto 400 tcp from table(2) to me setup > > > to make the entire session do the same thing. > > So, in your example what wrong with just using keep-state? > > "record-state without immediate action" == "keep-state without implicit > > check-state" needed to solve issues with NAT or something similar, that > > was described by Lev. > > > because keep-state is a check-state for ALL packets going past, regardless of > whether they match the pattern. > > at least that's what I have observed. Except now(?) with named states/flows/whatever, isn't it the case that check-state [flowname] only affects packets with same state/flowname? So you can clearly separate, say, packets on different interfaces, packets coming or going on any interface, and such? If I'm understanding that right - quite possibly not! - then only those packets will match, and others with other names (including 'default') won't match states with that name. I'm not sure I'm expressing this at all well, because I'm only just starting to get any sort of grip, but I'm liking the idea and wondering if it's sufficient for starters. To me, orthogonality implies the least number of commands/instructions that will accomplish the desired functionality. First, let's find out what can and cannot be accomplished with named states/flows .. I'm yet to understand what record-state-without-action can accomplish apart from that .. it could work only for the first packet I suppose, since once state is established, further packets will match and follow state, no? Again, I find concrete examples - like the use of valtype skipto,fib mentioned above - really helpful, essential really, for bears of such little brain as I .. cheers, Ian ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 5/08/2016 2:14 AM, Ian Smith wrote: On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote: > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > > On 04.08.16 06:42, Julian Elischer wrote: > > > so it's a combination of #1 and #2 in my list. I think I originally > > > thought of having just #1. > > > > > > A combination is less useful for me as you need to do: > > > > > > 20 skipto 400 tcp from table(2) to me setup record-state > > > 21 skipto 400 tcp from table(2) to me setup > > > to make the entire session do the same thing. > > So, in your example what wrong with just using keep-state? > > "record-state without immediate action" == "keep-state without implicit > > check-state" needed to solve issues with NAT or something similar, that > > was described by Lev. > > > because keep-state is a check-state for ALL packets going past, regardless of > whether they match the pattern. > > at least that's what I have observed. Except now(?) with named states/flows/whatever, isn't it the case that check-state [flowname] only affects packets with same state/flowname? So you can clearly separate, say, packets on different interfaces, packets coming or going on any interface, and such? If I'm understanding that right - quite possibly not! - then only those packets will match, and others with other names (including 'default') won't match states with that name. I'm not sure I'm expressing this at all well, because I'm only just starting to get any sort of grip, but I'm liking the idea and wondering if it's sufficient for starters. we not quite.. Only the given state table will be looked at, but all packets will still be matched with it. To me, orthogonality implies the least number of commands/instructions that will accomplish the desired functionality. First, let's find out what can and cannot be accomplished with named states/flows .. I'm yet to understand what record-state-without-action can accomplish apart from that .. it could work only for the first packet I suppose, since once state is established, further packets will match and follow state, no? Again, I find concrete examples - like the use of valtype skipto,fib mentioned above - really helpful, essential really, for bears of such little brain as I .. ok, so sometimes I like to do some processing on a packet (e.g. divert it somewhere for munging) after I've set up a state for it. so I don't want to necessarily Act on the state immediately. but the packet may get changed in the munging, so I need to set the state before hand., or I can't match it. here's a real example that I couldn't do because I couldn't store a state without actually doing it. I wanted all packets from a process on the local machine (identified because it has a unique group, used for just this purpose) to be forwarded to a particular other machine for "vetting', however the machine I am doing this has outgoing NAT using a modified natd that also does some added "stuff". After the NAT I can no longer recognise the packets that came from that process as they moved out of the kernel to userland and back, yet I still need these ackets to go through the natd. So I need to identify them first, before the nat in order to set a state entry for them. Since they are local packets NAT will not have changed their addresses, so AFTER the NAT I could have done the associated check-state which triggers the stored action (forwarding to another location). I ended up having to do this via an ugly use of skiptos where packets I wanted to forward, were identified early and then sent to a duplicate set of rules which also did the divert, but then did the forward. I think there were about 25 rules duplicated. Having said that, "store without do" is the least important of the features. Store (do or not) without a prior checkstate is more important to me. state name are a wonderful addition that I have yet to use in all my scripts I just haven't had time yet. cheers, Ian ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW: more "orthogonal? state operations, push into 11?
On 05/08/16 06:36, Julian Elischer wrote: I ended up having to do this via an ugly use of skiptos where packets I wanted to forward, were identified early and then sent to a duplicate set of rules which also did the divert, but then did the forward. I think there were about 25 rules duplicated. You could deduplicate this with a call/return pair but good luck ever debugging it if something goes wrong because the call/return stack is tied to the mbuf "allowing" you to call during igress and return during egress for maximal confusion. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re[2]: IPFW: more "orthogonal? state operations, push into 11?
Hi, > 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 Will there be the patch in the 11-RELEASE? -- Vitaliy ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
