Re: IPFW: more "orthogonal? state operations, push into 11?

[Julian Elischer]

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?

[Bill Yuan]

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?

[Andrey V. Elsukov]

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?

[Bill Yuan]

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?

[Jan Bramkamp]

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"