[solved] Group rules with overlapping sort priority

[OPNenthu]

After the upgrade from 26.1.9 -> 26.1.10 I am just now realizing an overlap in rule order between two interface groups when using the "All rules" filter in the new UI.  My "IG_OUT_WAN" group is interspersed with the "IG_OUT_VPN" group.  These are the only two affected.

Curiously, both groups are using the same "300002.xxx" sort order which should not happen, right?  I think the last digit in the priority group should be unique per interface/group if I'm not mistaken.

I will roll back to the snapshot for 26.1.9 and check the rule ordering there but that's as far back as I can go.  Was there a change in 26.1.10 that might affect this, or is it likely that this happened during my rule migration several releases ago and I never noticed?

I'm curious how this can happen.  Are there issues with cloning rules between groups that might cause the priority group number to carried over, perhaps?

[Monviech (Cedrik)]

The priority group number seems to be entirely decided by the number you put into the group itself when you create it.

Inside "Firewall - Groups" it has a sequence, and that influences the priority group.

EG all VPN groups will have 300010 because their Group Sequence is 10.

[OPNenthu]

Yep, you're right.  The groups are both set to sequence 2.  My mistake.

Thanks!

[Monviech (Cedrik)]

Don't worry, this one caught me offguard during coding so I explicitely commented it here:

https://github.com/opnsense/core/blob/b4fa4cd2e2f6743eaf49e0523b2303fd31c3ee59/src/opnsense/mvc/app/views/OPNsense/Firewall/filter_rule.volt#L87

[OPNenthu]

Since we're on the topic there's another quirk that I want to run by you.  When I set up my WG interfaces I cloned rules from WAN_VPN1 -> WAN_VPN2, and this is now reflected in the sequence of the rules.  You can clearly see where I created the first rule, cloned it, created the next two rules, cloned them, etc.

You cannot view this attachment.

I don't think this causes a problem in terms of firewalling because the traffic is anyway exclusive to each interface, but the mixed order of the interface rules is unsettling.

Since I don't manually manage sequence IDs and I typically let the system do it, I'm wondering if there's a possibility to clean up the automatic sequencing so that there are always cleanly separated ranges between interfaces?  Cloning seems problematic for overlaps.

[OPNenthu]

And just one more (sorry!)

I noticed that when you delete an interface from Interfaces->Assignments, any existing rules that were present for that interface get left hanging around in the config.  Next time you assign a new interface that automatically inherits the old device identifier (e.g. opt10) then it also silently inherits the old interface's rules.

Can there be an option (or better, a prompt) to delete interface rules when an interface is removed?

I don't mind adding feature requests for either of these if you think they might be reasonable.

[Monviech (Cedrik)]

For your first issue, this would need some sort of sequence number when interfaces are created, same as the groups already have. It's nothing that could be reasonably auto calculated because we cannot know what the user wants all the time.
You can see how that goes if you open a feature request for that on github.

For the second issue, this is also the case in the old rules view. Rules are not deleted when an interface vanishes, they stick around in the config. This is also a safety feature against accidental lockouts or deletions. Not sure if we should unravel this one.

Though /any/ config that references the interface sticks around.

If you ever deleted an entity inside a Sophos XG firewall before that recursively deleted everything that is dependant on it, you will like that we don't do this.

[OPNenthu]

For your first issue, this would need some sort of sequence number when interfaces are created, same as the groups already have. It's nothing that could be reasonably auto calculated because we cannot know what the user wants all the time.

Makes sense.  I get why you might not want to introduce sequence IDs at the interface level and it would interfere with the flexibility we now have to order individual interface rules liberally within the "400000.x" range.

I was thinking that it would be trivial to auto-rebalance the sequence numbers (the part after the decimal, not before) to avoid overlaps, but I didn't consider that some users/orgs might actually have overlapping rules on purpose.  I don't know why you would do that (performance optimization?) but as long as the system allows overlaps then my idea is not safe.

For the second issue, this is also the case in the old rules view. Rules are not deleted when an interface vanishes, they stick around in the config. This is also a safety feature against accidental lockouts or deletions. Not sure if we should unravel this one.

Understood; leaving this alone.  I think it's subjective anyway depending how you look at it.  My opinion is that stale interface configs that can be silently re-activated when a device ID is re-assigned is dangerous.  I can't be sure of what's happening with a newly created interface and I feel like I'm breaking my firewall by deleting & creating interfaces.  I guess it's not really a problem though if no one's complaining.