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

[techturtle]

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

Inverting 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":

Without 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.

[Patrick M. Hausen]

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.

[techturtle]

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.

Since the logic cannot easily be changed

Can you (or someone else) elaborate, why not / what would need to be done?

[Patrick M. Hausen]

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.

[techturtle]

Thanks, no worries.

My case is IPset firewall alias with dnsmasq. A parent network alias nesting this ipset (amongst others) of course would be required to have its values immediately updated, after dnsmasq puts some ip into child ipset alias, in order to make whitelisting work properly. Your case might be slightly different - quick realtime updates of aliases vs. a bit more slow paced url table aliases. I am gonna re-test this current OPNsense version.

Regarding OP error: may some dev can comment and discuss here. Otherwise I am fine creating a separate issue on GitHub.

[techturtle]

Multiple sources/destinations become multiple rules under the hood - that's a bit different than I anticipated. Probably this is the cause, why implementation of negation gets complicated.

So back to nested aliases: Is there any info, how these are synced?
Given parent alias P and nested aliases C1, C2, I'd like to have P synced immediately in a blocking fashion, as soon as either C1 or C2 is changed. I.e. if a rule using P is to be consulted for a packet, application of this rule should wait till P has fully flushed / synced.

Is that possible?

[Patrick M. Hausen]

If you have an active connection which you intend to block the problem is possibly not that your alias are not updated in a timely fashion, but that you need to flush the firewall states.

An active TCP connection that once was permitted stays that way because of the stateful firewall, even if you change the rules.

Of course flushing the firewall states will disrupt all active connections which is exactly why it does not happen by default.