ok, that's weird. No I'm using the standard pfBlockerNG 2.1.4_26 on pfSense 21.05.2-RELEASE. I'll try switching the list action and see if that makes any difference.
Your problem is that you are using an old unsupported version of pfBlockerNG. The maintainer of pfBlockerNG, @BBcan177, does not recommend the use of that old version. The -devel version has been in use for 2 to 3 years now and is very stable and the only version currently being updated.
Make sure that the box is checked to save your current settings and then uninstall your current version of pfBlockerNG 18.104.22.168 and then install the -devel version 3.1.0_1. This should take care of the issues you are seeing, if not, post back to the forum and someone will help you.
re: what triggers it, from the report certain orders of preg_match() calls can. It seems apparent that the pfSense GUI does not as everything I've seen is in regards to packages. Perhaps the feeds used (variable size) make a difference?
So far so good.
SG-3100 - 21.02p2 - Clean install
Actions taken in pfblockerNG
1 - Wizard
2 - Maxmind key set
3 - MaxMind Localized Language changed to Brazilian portuguese
Not using geoIP yet, planning to.
4 - Feeds
Noticed that only one DNSBL was in use, ADs_Basic, so I added the following:
5 - Changed DNSBL Mode to Unbound python mode
6 - Unchecked DNS Reply Logging because I don't need it
@viragomann Wenn die erste Antwort bzw. der erste Hop von Traceroute schon * * * zurückgegeben hatte, dann stimmte zu dem Zeitpunkt was mit dem Routing nicht wirklich. Wäre dann eher interessant gewesen, was beim traceroute blubb dann tatsächlich der volle Output war. Wäre es pfBNG gewesen, dann hätte die Auflösung von awsh.de schon 0.0.0.0 oder 127.1.1.7 ergeben und wäre ins "nichts" gelaufen. Wenn die aber sauber zur IP aufgelöst wurde und der Trace dann nicht ging, dann war das kein pfSense, sondern eine Routing/Proxmox Problem.
I'll query the ISP on what are they doing there. Doubt they'll talk... but that is a different story.
Just as a quick follow up: If you pay for your own public IP to get forwarded to you, they should have no trouble setting their UBNT POP the way you want. Otherwise what's the gain in paying for something you can't successfully use all the way you want? ;)
I'm having the same issue with pfBlocker and NAT rules. I have no issues adding white-list rules for my devices that are on a directly routed subnet. But trying to figure out how to handle an allow rule for an existing NAT rule is causing issues.
Amigos, a solução para o meu problema foi aumentar as entradas máximas da tabela do firewall no campo: System / Advanced / Firewall e NAT
Mudei o valor padrão de 400000 para 800000, mas o valor fica a critério de cada um de acordo a sua necessidade.
To begin, pfBlockerNG_devel 2.2.1_2 is awesome. Wow. Thanks.
Certain feeds are naughty. For example, adding RFC 1918 (Private Address Space), Multicast addresses, etc., etc., etc., is just BAD. Blocking possibly necessary system addresses, including multicast addresses, etc., is just NASTY. Adding a WhiteList is not going to fix this issue. These rule elements need to be culled from the list(s), and I mean permanently.
By chance are you using Firehol Level1? That feed contains bogons and should not be used for Outbound blocking. You can also enable "Suppression" which will remove local/loopback addresss.
A couple of feature suggestions for automatic rule insertion: use rule Separators to bind automatic rule insertion to specific places in the rules. (Indeed, one of my pet peeves is that automatic rules re-arrange Separator organization in seemingly random ways.). Another suggestion would be that automatic rule insertion should not re-arrange rule ordering AT ALL (after their initial placement). Subsequent rule updates should update rules IN PLACE. I like the possibility that Separators could be used to bind automatic rule insertion. But, disabling all automatic rule insertion needs to be an option for DNSBL.
Firewall rule separators will be very difficult to implement with pfBlockerNG and auto rules...