"Inverting destinations is only allowed for single targets" rule error

Started by techturtle, May 29, 2026, 04:10:57 PM

Previous topic - Next topic
Setting multiple aliases as "Destination" and ticking "Invert destination" within a firewall rule declaration currently triggers error:

QuoteInverting destinations is only allowed for single targets to avoid mis-interpretations

I am a bit buffled, what is meant by "mis-interpretations" - isn't this the application of De Morgan's laws?

Let's say, two firewall aliases A and B exist, each with couple of IPs. Then setting A and B in "Destination" creates the union of those two aliases A ∨ B ("match, if destination is in any of those aliases"). Additionally enabling "Invert destination" should lead to ¬ ( A ∨ B ) = ¬ A ∧ ¬ B ("match, if destination neither is in A nor in B").

I am not asking from a theoretical or academical standpoint, but would really like to express:
  • If destination does not match any of the hosts in those aliases, block connection => block rule.
  • Fail fast => quick/first match rule is to be used.
  • Keep firewall rules strict.

Especially with regards to point 3, if splitting up into
  • a pass rule for A ∨ B
  • followed by blocking rule for non-matching hosts
, then anything with destination in either A or B is immediately allowed. But according to principle of least privilege, it would be better to preserve the possibility to block traffic for other reasons by subsequent rules. Current rule logic cannot express this pattern AFAIK.

I definitely agree, these logic expressions sometimes can get confusing. So it might be worth to add a help message for "Invert destination":
QuoteWithout inversion, the union of destinations is matched = "match if any destination A OR B matches".
With inversion, selected destinations A and B are processed as follows: ¬ ( A ∨ B ) = ¬ A ∧ ¬ B = "match, if destination neither is in A nor in B"

Btw: https://forum.opnsense.org/index.php?topic=51467.msg263889#msg263889 is a bit similar, at least error message. But my issue does not have to do anything with migration. Above error already appeared with the old firewall rules format.

Happy to read any feedback.

Source or destination invert used to be allowed for multiple entries, but lead to undesired effects confusion because the underlying logic created "not this OR not that" which essentially applied to anything.

Since the logic cannot easily be changed, the check and error message was created and the solution for your requirement is to create a group alias and use that with invert.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Thanks for the answer - you mean Network group alias, right?

Group alias seems to only support other Network and host aliases - though I also need to nest External and URL Table. In the past I had some timing issues, where values of child aliases (ipsets; external type alias) weren't quickly enough populated to parent alias. Apparently group alias is only  guaranteed to be eventually consistent with all child aliases, not immediately, as all values are copied over and not referenced. Or has this synchronization been improved in recent versions? Otherwise unfortunately that's not a viable solution for me.

Quote from: Patrick M. Hausen on May 29, 2026, 04:59:05 PMSince the logic cannot easily be changed
Can you (or someone else) elaborate, why not / what would need to be done?

I have network group aliases with multiple URL tables exactly for the purpose of source invert to express "not in any of these block lists".

As for the underlying logic - I'm not a core developer, sorry.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)