Just been looking at an issue where I had lost NFS access across a site-to-site Wireguard VPN.
I found that a permit rule that was using an alias that contained aliases ( Alias_NW1, Alias_NW2 ) was not allowing traffic to pass.
While a separate rules for Alias_NW1 and Alias_NW2 worked as they should.
This looks to be a change of behavior from prior to 26-7
I'm seeing some more examples of this which are also inconsistent across firewalls.
After the upgrade to 26.7.1 some inbound traffic started to be blocked on one firewall.
The alias at the root of the problem is structured:
+----- Alias_NW1 subnet
|
Alias-+----- Alias_NW2 subnet
|
+----- Alias_NW3 + NW4 subnets
The cause was the alias covering NW3 & NW4. Removing either one of them resolved the problem.
The inconsistency is that I use the same rule, that stopped passing traffic, on numerous other firewalls.
Most notably there are two identical Protectli firewalls where the rule passes on one and not the other.
Check your aliases in Firewall: Diagnostics: Aliases, what is actually in it. Maybe this gives a hint.
Thanks. I had already done that.
I'm wondering if this is caused by an extra space in the alias entry.
I have since tried removing and replacing the alias in question. Which now passes data.
But it is not obvious if it was the update to the alias or the process of editing that resolved this.
Quote from: MoonbeamFrame on July 22, 2026, 01:19:38 PMThe alias at the root of the problem is structured:
+----- Alias_NW1 subnet
|
Alias-+----- Alias_NW2 subnet
|
+----- Alias_NW3 + NW4 subnets
Hi,
Funny, I'm seeing roughly the same here; had to add a any/any/all/all rule for traffic to pass.
The used alias looks like this:
+----- Alias_SITE1 (10.x.x.x/16)
|
ALL-LAN-+----- Alias_SITE2 (10.x.x.x/16)
|
+----- Alias_SITE3 (10.x.x.x/16)
|
+----- + 3 other SITES aliases (site4,5,6)
Have you found a decent solution and better something to do before the update/upgrade? I had updated my local FW where I stand and could workaround the issue but remotely that may be more problematic..
Thank you
No, not at this time.
I also found that the 'fix' mentioned earlier did not persist after a reboot.
Hum very bizarre, I now created the exact same alias with a different name and suddenly, within the firewall / diagnostics / aliases, the new alias as well as the former alias are now all populated with the correct subnets. Which wasn't the case on the original alias before (was empty within the diagnostics)
That was also my experience.
Do your changes persist after a reboot?
Quote from: MoonbeamFrame on July 27, 2026, 10:24:06 AMDo your changes persist after a reboot?
No, it doesn't -- that's a bit of an annoying situation TBH...
According to quick testing's here is seems to be underscores chars within the source aliases (here named NET_XYZ/NET_ABC etc..) of types : Network(s).
Renaming them without underscores seems to populate the network group alias (of type : Network group) within the diagnostics..
Testing a reboot right now, will update.
----
Edit: nope did not survive the reboot, Network group alias is empty again post reboot -- clearly a bug
As a workaround, I migrated my Network group(s) aliases to Network(s) aliases before any further 26.1 to 26.7 migrations / upgraded all the remaining firewalls with no issues / will still monitor that situation as it tend not to put me at trust and I haven't checked inbound connections using aliases yet.
Hope this helps
Tried renaming all my aliases removing the underscore character but this made no difference the aliases still would not work.
I think I might have an alias issue with policy based routing. have you found a fix to this?
Is there no testbed, no automatic quality check ?
Is it only the user feedback that found such issues of general nonfunctionality ?
Is it possible to expand the automatic machine driven testing before release ?