Firewall rules and aliases.

[MoonbeamFrame]

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

[MoonbeamFrame]

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.

[Bob.Dig]

Check your aliases in Firewall: Diagnostics: Aliases, what is actually in it. Maybe this gives a hint.

[MoonbeamFrame]

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.

[mokaz]

The 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

[MoonbeamFrame]

No, not at this time.

I also found that the 'fix' mentioned earlier did not persist after a reboot.

[mokaz]

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)

[MoonbeamFrame]

That was also my experience.

Do your changes persist after a reboot?