IPFW rule sets and automatic rule numbering

[bycn82]

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