Messages

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.

+1

At the very least use readable timestamps for which alphabetical and chronological order is identical like YYYY-MM-dd-hh:mm:ss or similar.

I had to disable the plugin too. Many files with meaningless names.

To me, lock to the previous version as Franco says can't be a long term solution, so I had to stop using it.

Ok... thank you

I've closed the request.

I have opened a feature request to have an option that allows the user to opt for the previous behavior.

The problem with backing up the conf/backup directory is that when using nginx plugin, it uses the configuration to maintain the list of banned IPs, and this changes the config many times per day generating a huge amount of files.

I don't need to backup every of theses configs. So having the chance to use the original method would be useful in my case.

No packet is passed back to the firewall to match another rule on the same interface afterwards.

Does it mean that it doesn't matter the selection of pass, reject or block on the "divert-to" rule?

I have a (maybe dumb) question:

When using "divert-to" the matched packet is sent to Suricata to be inspected. After that, Suricata is responsible for the evaluation of the packet and not pf anymore.

Who is in charged of rejecting, blocking or passing the packet?

I can imagine that Suricata responds to pf with a verdict and is pf who blocks or pass the packet.