Messages

@franco, I was at 26.1.10 and noted this behavior. The first part of the update were fine and I could see all the packages update progress.
When it reached the point to update kernel and base packages it stuck a while until it showed kernel download complete, and then stuck again until base download complete.
After that, the update continued as normal, with kernel and base installation and reboot.

It was the kernel and base download that I couldn't see the progress, so depending on the download speed one could think that the update stopped.

I think the problem is that the kernel is downloading but you can't see the progress.

It happened to me and I waited until it started to download the base package and it didn't either showed the download progress until it finished and the the update finished normally with the reboot

Hi, your situation reminds me a problem I had with pfSense a long time ago. Of course the speeds were slower at that time.
The solution was, if I can remember well, to set a fixed speed at the WAN interface. I set 100M full-duplex and the problem was solved.
For some reason the auto negotiation was not working as expected.

May be this due to a temporary file lock during log rotate and is not a problem at all.

Hi, I'm having a may be not important issue. Some nights at 12 AM, nginx is throwing these 2 errors on its log:

Code Select Expand

2026-05-19T00:00:00-03:00 Emergency nginx 2026/05/19 00:00:00 [emerg] 88258#100283: open() "/var/log/nginx/permanentban.access.log" failed (13: Permission denied)
2026-05-19T00:00:00-03:00 Emergency nginx 2026/05/19 00:00:00 [emerg] 88258#100283: open() "/var/log/nginx/tls_handshake.log" failed (13: Permission denied)
2026-05-18T00:00:00-03:00 Emergency nginx 2026/05/18 00:00:00 [emerg] 88258#100283: open() "/var/log/nginx/permanentban.access.log" failed (13: Permission denied)
2026-05-18T00:00:00-03:00 Emergency nginx 2026/05/18 00:00:00 [emerg] 88258#100283: open() "/var/log/nginx/tls_handshake.log" failed (13: Permission denied)

May be this is not important, as I can see that the service is working as expected, but...

In my case, when I select the "All rules" filter, the number of rules are right in both indicators, the little circle on the filter selector and the number below the grid.

The problem is in the rest of the numbers of the interface filters. All little circles shows different numbers than the real value. The counter below de grid always shows the right value.

One extra problem I've found is that when I select the "Floating" filter, it shows nothing in the grid but I have eight floating rules as correctly indicated in the number below the grid. Fortunately I can see these eight rules using the "All rules" filter.

EDIT:
I see that I misunderstood the way filtering works. The numbers are correct because what I see in the grid includes the floating rule where the selected interface is selected. So the only problem I still find is that the Floating filter is showing an empty grid.

Check your rule set for rules that do not specify the protocol explicitly as TCP, UDP or ICMP but use "any" instead. These are susceptible to a DoS attack. You might want to replace "*" with "TCP/UDP" if applicable.

Thank you Patrick for pointing this out

That said, I did open a feature request ticket to expose 'harden-below-nxdomain'.

Thank you. In any case, the next time my Internet connection fails I will test this custom option to see if it also solves my issue.

Hi LemurTech.
I've read your solution, and I wonder if this could be the solution for other problems that I've found people are having https://github.com/opnsense/core/issues/9736
Given that you have researched this in detail, may be it worth to open a ticket at github for asking the developers to add the intended options that had solved this problem.
May be these options were not needed before, but the new Unbound-Dnsmasq schema proposed by the developers can lead to the need for some additional options like the ones you have mentioned.

In my case, I had the problem of Unbound not forwarding queries to Dnsmasq when my Inet connection was down. It's not the exact same symptom but the problem looks the same at the end.

Ok, thank you for your time and work. The new gui is really impressive.

Just set the sequence to 0 on the WAN rule and it should be before all other WAN rules

By the way, sequence 0 is not allowed on the gui. The input error is "Sequence shall be between 1 and 999999."

This doesn't seem right.  Interface rules have priority group 400000, not 300000.  Are you sure you have an interface rule with 300000?  That violates the docs and could be a bug.

You are right, it was a typo, sorry. It is 400000.000001.

It gets processed in the way you see it sorted in the GUI.

Just set the sequence to 0 on the WAN rule and it should be before all other WAN rules?

I know that floating rules should not be needed for my general blacklist case but if the rules are processed in the sorted order on the GUI, I can see the floating rules first, then the group rules and finally the interface rules. And inside each group the rules are ordered by the sequence number, that is only the second part of the sort order. So that is my confusion.

So, to get the functionality of the general backlist as I had before with the floating rule. Do I need to modify the interface rule to make it a floating one, e.g. enabling a second interface on the rule? could be a loopback?

Or may be there is a more elegant way of achieving it?

Just to be sure, I have a floating rule with sort order 200000.0000011, then a group rule 300000.0000021 and finally an interface rule 300000.000001. Does it mean that the interface rule will be processed before the floating and the group rules?

I have to make sure that the interface rule is processed first because is a general blacklist.

In the old rule system I had the blacklist declared as a floating rule with only the WAN interface selected.

I'm using 127.0.0.1 as redirection address.

I also created an issue: https://github.com/opnsense/plugins/issues/5181

Thank you meyergru.