Network type alias rule blocks a pass subnet

[Jyling]

I have a network type alias. It includes subnet xyz.172.0.0/14.
All of my rules are Apply immediately.
This alias is used in an Allow rule whose destination is the destination server IP and port.
This alias is also used in a Block rule whose destination is invert of the destination server IP, any port. It sits right after the former.
Yet the connection is blocked by the latter rule when a source IP is xyz.175.196.230, i.e. from that subnet, according to the IP calculator:

Address:   xyz.172.0.0
Netmask:   255.252.0.0 = 14
HostMin:   xyz.172.0.1
HostMax:   xyz.175.255.254

It should pass. Why does it not?

Crap! It's even worse! Just checked the server logs. The IP address passes for several hours, then is blocked for 30 min, and then it passes again. So the issue is intermittent. This is bad!

[viragomann]

I have a network type alias. It includes subnet xyz.172.0.0/14.
Yet the connection is blocked by the latter rule when a source IP is xyz.175.196.230

This IP does not belong to the subent above.

[pfry]

I'd check those blocks in the live log, particularly using the "i" on the right. Protocol or protocol-related attributes such as TCP flags can be tough to spot offhand - it's easy to get locked into the address/port pair.

[Jyling]

This IP does not belong to the subent above.

How did you establish that?
I did that by punching it into https://jodies.de/ipcalc and getting the posted result.
Now that you claim they are wrong, I double-checked that in https://www.calculator.net/ip-subnet-calculator.html and got the same result.
Do you find any fault with their calculators?

I'd check those blocks in the live log

That's where I saw the issue.

[viragomann]

How

No, my fault. I didn't read the xyz as the first octet.

[Jyling]

The plot thickens.

I have a Network type alias that includes a subnet. I have a rule that allows that alias to a LAN IP/port.
Further down there is a rule that blocks everything to that port, so as to only allow only that which passes the above rule.
Yet in the live log I can see the latter blocking the connection from an IP address that belongs to the alias of the former.
This means that the firewall is broken and is unable to function correctly with the network type aliases as source.

[Jyling]

I verified the above observations by separating the subnet in question to its own Allow subnet rule and placed it before the original Allow rule. Now the connection is allowed. Alias type rules have a problem.

[pfry]

What do the kids say these days? "Pics or it didn't happen"?

In this case, most diagnostic would be logs from "Firewall: Log Files: Plain View" with the definitions of the rule(s) in question (capture of "Firewall: Rules: [interface]" may be sufficient). Unfortunately the quickest way I can see to correlate logs to rules is via the "Firewall: Log Files: Live View" -> "i" ("Detailed rule info") for the rule in question, as it gives the "rulenr" value (assuming the additional correlation of a unique Description/label). Log reference. Naturally the "Detailed rule info" for the particular event would suffice in place of the log, but that may be inconvenient to capture.

Someone else here may have a better method.

[pfry]

"Firewall: Diagnostics: Statistics" -> "rules" -> "filter rules" (expand) also gives the "rulenr", UUID, and definition.

[Jyling]

What do the kids say these days? "Pics or it didn't happen"?

I don't recommend calling me a liar. Think again, better this time.

The separation of the subnet into its own pass rule is proof good enough for me.

[Jyling]

This is a truly bizarre behavior:

Aug 30 10:42:37   abc.def.198.14:5176   1.2.3.4:5222   tcp   Allow XMPP   
Aug 30 10:41:50   abc.def.198.14:5167   1.2.3.4:5222   tcp   Allow XMPP   
Aug 30 10:41:48   abc.def.198.14:14722   1.2.3.4:5222   tcp   Block XMPP   
Aug 30 10:41:39   abc.def.198.14:14722   1.2.3.4:5222   tcp   Block XMPP   
Aug 30 10:41:34   abc.def.198.14:14722   1.2.3.4:5222   tcp   Block XMPP   

The same connection is intermittently moving between the allow and block rules. I can no longer refer to this piece of software as a firewall.
I never experienced anything of the sort for as long as the subnets remained on their own rules, so aliases are clearly the root cause of this rubbish and have to be avoided like plague.

[Jyling]

Over the past few days, I established that firewall rules work or do not work intermittently and randomly. I can no longer trust open sense's firewall and will be migrating off of it, for 1st time in my 30+ year career in IT.
We realized that our org was not receiving many emails due to SMTP connections being blocked by lower rules despite higher rules that were supposed to allow them, for 1st time in my 30+ year career in IT.
This is not firewall. This is rubbish.

[Patrick M. Hausen]

You have not yet provided any evidence so far.