Forgot to include mailing list in my reply. I'm sorry if you receive this email twice - first I sent it with wrong from address and it didn't seem to make it through.
Tri pivceta wrote: > > Suppose I have the IPFW ruleset like this: > > 100 count tcp from any to any in > > 110 allow tcp from any to any telnet in > > 199 deny tcp from any to any in > > 200 count udp from any to any in > > 210 allow udp from any to any domain in > > 299 deny tcp from any to any in > > 300 permit icmp from any to any > > > > When manipulating such a ruleset I don't want to touch rules 100, 200 > > and 300. I may want to allow another tcp port and later on remove it or > > whatever. It seems to me I can't do it with ipfilter. I understand > > You can, but not the way you expect in this case. IP Filter groups rules in > two groups, namely IN and OUT. The first rule in either group normally > takes "slot 1", and will be listed as "@1" for the respective group. The > keyword here is "normally" as there may be exceptions that I'm not > accounting for here. > > > ipfilter evaluates rules differently than IPFW (last match vs. first > > match wins operation) and that is has heads and groups and whatever. Yet > > it looks from the manpage it provides the similar functionality to IPFW > > regarding numbering rules and operating only on a given number rule. > > This is something specific to IP Filter. In IP Filter, the default > evaluation of rules is done in a really backward and bizzare way, where the > last rule may have precedence over the first rule on a basis of a "better > match" (and I use double quotes here loosely). This extremely > counter-intiuitive behavior is ON BY DEFAULT, supposedly "to give you a > choice", although it is completely senseless and illogical. I don't find it all that 'senseless and illogical' but it doesn't help me solve my issue with my users wanting something similar to IPFW. > However, there is a method to the madness, and namely, the way out is to use > the "quick" keyword in your rulesets. The "quick" keyword basically makes > IP Filter process rules in the IN and OUT groups in the order in which they > were written, meaning, if there is a match, no further rule parsing is done, > and the action specified is performed immediately. Effectively, the "quick" > keyword makes IP Filter behave procedurally like CheckPoint FW-1 or > CheckPoint NG. > > What this means is that by using the "quick" keyword in an intelligent way, > you can generate rulesets whereby rule numbering becomes irrelevant! If you > order your rules carefully with the above technique, you will get the EXACT > order and logic as in "ipf.conf" or "ipnat.conf", and any additional tweaks > can be made with the help of `ipfstat -ion`. > It's up to you to tweak them to get 'em right where you want 'em. It > effectively eliminates the need for rule numbering, and makes rule writing a > lot simpler. Thank you but I know all of that. I'm afraid you didn't really get what I was after. In IPFW (and I believe some Linux packet filtering package does it the same way) you don't supply the controlling program with list of rules (but you can do that). The original way (I believe) was to invoke the program once for each rule in the ruleset. The rule numbering by default is sparse, you can insert and delete the rules at any position in the list. The rule number you or the program assigns to the rule stays in kernel and you can rely on it. I don't want to flush all the rules and lose counters and state and whatnot just to modify some netmask or such. Thanks again anyway. Michal
