Firewall rules with multiple selected hosts and source inversion not working

[Vexz]

Since OPNsense 25.1 supports the selection of multiple hosts for firewall rules, I thought it would be a good idea to get rid of my nested aliases, but it's currently not working correctly.

Setup to reproduce:
I have a firewall rule with a nested alias as source and activated the checkbox for source inversion. I use this rule to route all traffic of all hosts through a specific gateway with that firewall, except for the hosts in that nested alias for the source (hence the inversion). With the nested alias everything works as intended, but when I instead multi-select the hosts in the nested alias (instead of the nested alias, which should have the same effect, right?) it does not work. Then even the traffic of the selected hosts in the source of the firewall rule is routed through that gateway. To me it looks like it's a bug, but maybe I'm just misinterpreting the multi-selection?

[senser]

Well, when you select multiple targets for a pass rule then there are multiple rules created in the background, one for each target (or source in your case). When you invert the meaning for the target (or source) you basically get an allow all ruleset. Because the second rule passes traffic that the first one did not allow.

I also think that this is an issue.

To not break current rulesets the only solution that I can see is to reflect the fact that there are multiple rules created in the background in the UI (you can have a look at /tmp/rules.debug). Like showing those rules indented and slightly greyed out below the rule. That way you get a hint why it does not work as you may have intended.

I think it is better to keep using aliases for this usecase, as you end up with only one rule.. which results in better lookup performance.

I am not sure if this is a bug. It is certainly not working as you and I expected. But changing the behavior now (like using an automatically created alias) would potentially break existing rulesets... even though that would probably ,,fix" what this feature intends to do, but currently does not? I don't know.

[senser]

Maybe @franco or another developer can chime in on this. Seems like we have some air for improvement here. :)