26.7.1: Network(s) alias using IP range no longer matches after upgrade

[ProximusAl]

I upgraded from OPNsense 26.1 to 26.7.1 (in-place upgrade, followed by updating the bootloaders).

After the upgrade, outbound traffic continued to work normally, but all unsolicited inbound traffic stopped working.

After troubleshooting, I traced the issue to two WAN firewall rules (one IPv4 and one IPv6) that used a custom Network(s) alias as the destination.

The alias was of type Network(s) and contained an IP address range in the format:

a.b.c.d - w.x.y.z

These rules had worked correctly prior to the upgrade.

Symptoms:

* Inbound packets reached the WAN interface.
* The packets never reached the LAN interface.
* pflog0 showed the packets hitting the default block rule instead of the WAN pass rule.
* Packet captures confirmed the traffic reached the WAN interface but was never forwarded.

The interface configuration was correct, and the built-in interface network object contained the expected IPv4 subnet and IPv6 prefix.

The fix was simply to change the firewall rule destination from the custom alias to the built-in  network object. As soon as I did this, both IPv4 and IPv6 immediately started working again.

Has there been a change in 26.7 regarding Network(s) aliases containing IP address ranges (a.b.c.d - w.x.y.z) when used as firewall rule destinations? This worked correctly before the upgrade, but afterwards the alias no longer matched traffic, whereas the built-in interface network object worked immediately.

Is this an intentional behavioural change or a regression?

I should add, this router is not using NAT and purely routes public IP addresses

[pfry]

Similar issue: Firewall rules and aliases.

Likely inconvenient on a running firewall, but: I'd check "Firewall: Diagnostics: Aliases" to make sure the member elements appear as you expect. Also, check the "Statistics" box in the alias definitions to look for rule matches (pass rules only). I'd also look at "Firewall: Diagnostics: Statistics" -> "rules" to make sure the rules are defined as you would expect.

Could be a bad rule expansion - the diagnostic view may be enlightening.

[trdeal]

After upgrading to 26.7.1 a rule which allows internal DNS servers (defined as an Alias with IPv4 and IPv6 addresses) to perform UDP/TCP dns queries was ignored, however a later rule which used the invert of the DNS Servers Alias group which stopped non-DNS servers from making DNS queries blocked the DNS servers from performing DNS queries. Other rules using Aliases (with hosts identified) also did not work correctly.