Firewall Rules Interface Order
-
Does the order of interfaces matter in $config['filter']['rule']?
For instance does it matter if all the rules of an interface end up at the top or bottom of the saved config.?
Reason I ask is that if the order of interfaces does not matter it would be really easy to simplify the $_POST['order-store'] code in firewall_rules.php. Boil it down to just grab the rules posted for the selected interface, followed by all the rules of other interfaces from config.
-
In theory, no, in practice: maybe.
Try swapping the order around and observe the differences in /tmp/rules.debug, you'll see what I mean.
-
Yeah it will change the interfaces order. But does it matter? What determines the initial interface order to begin with?
Also observed that the order doesn't always seem to strictly follow what is in saved config. Don't know what to make of that either.
-
It should not make any difference, as long as the code that implements the floating rules keeps doing what it does now. Rules that specify an interface only apply to that interface, so do not match traffic arriving on another interface. Thus it does not matter in which order of interface the interface-based rules appear in the rule set.
So if it is convenient to code so that the rules for an interface are grouped together in the 'rule' array then I don't expect it to break anything.
But it will mean that the config diff after changing rule(s) might be a lot bigger than it is now, making it more difficult for a human to see the real change - if anybody cares.
-
It should not make any difference, as long as the code that implements the floating rules keeps doing what it does now.
+Interface groups
But it will mean that the config diff after changing rule(s) might be a lot bigger than it is now, making it more difficult for a human to see the real change - if anybody cares.
Plenty of people do care about that, not just with the built-in config history either. IIRC there are some out there who check the config into their preferred type of VCS/RCS/SCS repo.
-
Plenty of people do care about that, not just with the built-in config history either. IIRC there are some out there who check the config into their preferred type of VCS/RCS/SCS repo.
In that case you would need to do something like re-sorting into a fixed order on save - e.g. the "ordinary"rules by interface (wan, lan, opt1, opt2…) - so that the rule set in the config would have minimal diff after a change. Of course the first time after an upgrade there would be a bigger diff when the rules got first sorted like that.
-
An upgrade producing a large diff is expected, a simple rule change having a large diff would be a shock to some. Also makes rolling back simple changes with manual config edits a bit more confusing.
-
Looks like 2.2 went to pretty extensive lengths to preserve the order. So probably good idea to stay with that. Even though it probably doesn't make any functional difference, as Jim and Phil point out it probably wouldn't be as external processes friendly.
