Messages

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.

The button is the checkbox beside the filename

We are anxious =)

So, the renew process will have to run more regularly but the TXT record will be reused so there will not be the need to create a DNS record on each renewal.

Ok, just take into account that if you are using an alias in your "NAS allow" firewall rule and that alias takes its IP from DNS, that could be the problem because switching to Dnsmasq could make the alias table to not populate anymore with the NAS IP.
That's what I wanted to make sure.