Firewall not blocking entire range in aliases?

[meyergru]

P.S.: Some people like to exclude blocking aliases by using their negation in the allowed source of the NAT rules. My previous preferred way was blocking in the old "floating" rules, but maybe you have to do it differently now.

[Mpegger]

I think that may be because of the transition from the old to the new rules, which is not yet finished. With the old rules, this was more apparent, as I tried to explain. However, I do not know for sure and at this point, I do not bother to pursue this, because there is still work underway: For example, the firewall rules are "new", but the NAT rules are still "old" - and frankly, I do not know the exact implications, which is why I suggested to look at what is actually being made of it in /tmp/rules.debug.

Yes, I see that now. I disabled the Auto Firewall Rule option in the Destination Nat rule and set it to Manual instead. The Destination NAT rule was setup using both the WAN+LAN interface in my network, so that I could use the external FQDN to contact the NTP server, even from within my local LAN network. When I tried to recreate the Firewall rule the same way the NAT Auto rule was, it was created as a Floating Rule (because it was using the WAN+LAN interfaces in a single rule), which moves it the top of the all the manual Firewall rules I have in place, and there is no way to move it further down in the list because it is a Floating rule. This to me means that Floating rules would come before all manual single interface rules (in my case the blocking rules I have setup), which would explain how those IPs that should be blocked make it through. They hit a floating rule first, before hitting the non-floating block rule.

I'm going to instead recreate the rule as 2 seperate rules, one for the WAN and one for the LAN, as this would allow me to set the order of the rule and should still allow internal and external access to the NTP server external FQDN.

My guess is that even though the NAT Auto generated firewall rule is at the bottom of the list, because it is setup for both interfaces, it's considered a Floating Rule and will be parsed before the manual rules, even though it shows at the bottom of the list of firewall rules. I'll need to go through my other rules as I have similar rules setup for other services.

And your insight on creating blocking rules as floating rules makes sense if floating rules always come first before non-floating rules.

[meyergru]

And your insight on creating blocking rules as floating rules makes sense if floating rules always come first before non-floating rules.

When the new rules scheme was first discussed, this was my main gripe about it, because with the old rules, you could create floating rules purely for precedence reasons. Now, with the new rules, the role of a rule switches with the number of interfaces it applies to (and it can never be floating with just one interface like "WAN only").

We'll see how this plays out when everything is migrated.