Messages

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.

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.

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.

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.

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.

he ISP should hand out more than 1 IP

Good luck with that, in most scenarios.

You'll find open sense UI superior to that of pFS. I believe you can migrate your config but do not hold me to it. Some XML transform may be involved. I'll let more knowledgeable members correct me on this.

- ISP connection is 750Mbps down and 100Mbps up.

Sounds like cable. If your modem is Intel Puma 6 chipset (some say even 7 is affected), then its UDP throughput sucks ballz. Block QUICK (UDP port 443) from the LAN and see if it improves things.

I solved all of that plus more, by blocking UDP port 443. Then browsers fall back onto TCP HTTP, and they also are no longer able to circumvent many of protections in place against backdooring, dialing home, etc.

So it is from the router. Swap it for anything else that is not based on FreeBSD and compare. If the packet loss persists, then kick your provider in the ribs.

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.

3. Had a technician install a splitter between the street and the cable modem, as the signal was "coming in too hot".

Your scenario is different from the OPs. You are on cable, they are on Ethernet.
The OP should ping from the open sense server, not from the LAN, to eliminate the FreeBSD+FW quirks.
If there is any variance in ping results between the LAN and the open sense, then it is within the router. Otherwise it is between the GW interface and the provider's infrastructure.
A good test would have been to use an alternative router and to ping from it, then compare. Temporarily use any non-FreeBSD router distro.

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!

Yes, it's in 25.1.8 (June 12, 2025) and 25.4.2 (August 6, 2025), respectively.


Cheers,
Franco

Great news!
Maybe eventually we will catch up, but it will be a project, not something that I can simply flip a switch on.

Not using the same name for testing.
Were the results cached, the response time would have been lower than the quickest, 3d server, but it is always equal to it.