On 9/14/14 20:47, Willem Jan Withagen wrote:
On 14-9-2014 13:44, Ian Smith wrote:
On Sun, 14 Sep 2014 12:36:43 +0200, Willem Jan Withagen wrote:
> On 13-9-2014 21:51, Freddie Cash wrote:
> > You can replicate it using 3 rules, loaded into two sets:
> >
> > ipfw set disable 1
> > ipfw add allow ip from any to any
> > ipfw add 65524 allow ip from any to any
> > ipfw add allow ip from any to any
> > ipfw set swap 1 0
> >
> > Run that two or 3 times. Every rule will be numbered 65534 after the 2nd
or
> > 3rd run.
>
> >
> > I expected it to be numbered 10, 65524, 65534 after every run.
> >
> > However, after reading the man page a few more times and thinking about it
> > a little more, it makes sense that the numbering is global across all
sets,
> > as you can have multiple sets enabled simultaneously.
> >
> > It just doesn't mesh with my desire to use auto numbering. I'm in the
midst
> > of manually numbering all my rules now. :)
> This is easily circumvented by making shure that the first rule is
>
> ipfw add 10 .....
> like:
> ipfw add count ip4 from any to any via vlan126
> (vlan126 is my outside connection)
> And then you are home free.
>
> I actually use this to also separate diffent types of block by injecting:
> ipfw add <blocknumber> count ip from any to any
>
> like:
> 03000 713812041 425643462848 count ip from any to any
> 03010 0 0 deny ip6 from fc00::/7 to any via vlan126
>
> And the 3000 block contains all antispoofing and likes.
I'd almost replied along the same lines - also tending to number first
rules in a block and then add unnumbered rules until other sections -
before realising that once Freddie had added his rule 65524, maybe in
another set, it's game over; every unnumbered rule added after that is
going to be >= 65524 and <= 65534.
And even as you have it above, if you rerun your script again without
flushing the entire ruleset, apart from specifically numbered rule/s,
everything will get readded after the highest rule previously used.
Alexander said:
> I think we can consider implementing sysctl which permits per-set
> auto-numbering.
Perhaps rather than a separate high water mark per set that would be
reset on set N flush - which I think is what Alexander means? - if one
could set something like maybe 'net.inet.ip.fw.autoinc_last' which would
default, as now, to the highest rule added so far, but could be reset to
something else before adding more auto_inc rules? Might get tricky, and
of course it has to not break older rule scripts - some VERY old :)
Could very well be.
I was for the same reason going to implement Freddy's strategy and swap
sets... So could be that I'd run into the same problem in near future.
It is hard to imagine that people would depend on the fact that the last
rule used would survive a set swap, and actually build on it.
Being able to actual set the last number used, aka the next number to be
assigned, would be equivalent to my trick using
'ipfw add <num> count....'
to preset a certain startingpoint.
It could even be made into either a flag on ipfw like
-k keep the last index for future increment
or an ipfw instruction
ipfw setautoincr <num>
And that would not interfere with old scripts.
tinkering it through sysctl would be possible too, but I'd prefer things
like this integrated in the command-interface.
--WjW
I think the per-set auto-numbering is a good idea.
But we are there is because of the "set", the "set" in IPFW is a trouble
maker.
I stared to learn the IPFW in Apr this year, and I was disappoint on
some features, and the "set" is one of them.
I created a fix patch about it but not relevant to this topic.
Regards,
Bill Yuan
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
