is something wrong with pfBlockerNG?
-
This has happened frequenty in the last 1 month - all of a sudden the domain name's in web browser does not resolve and get errror. When i "disable" pfBlockerNG everything is fine and dandy. It just happened again !
-
@netboy next time, try just restarting unbound/DNS
-
@SteveITS said in is something wrong with pfBlockerNG?:
next time, try just restarting unbound/DNS
I tried and this does not resolve the issue - IMHO pfBlockerNG is defintely broken - i have disabled it
-
@netboy said in is something wrong with pfBlockerNG?:
IMHO pfBlockerNG is defintely broken
Can confirm this is nonsensical.
-
@tinfoilmatt The proof: if i disable pfBlockerNG no issues this "clearly" confirms WITHOUT DOUBT it is broken
-
@netboy Well then it would seem that you've successfully resolved your root issue. Nice work.
-
@netboy Pfblockerng is a complicated system with lots of configuration options, and a combination of those CAN break things, however in most cases its not pfblocker but the user.
Having said that, have you checked for any errors? Does php crash?
Does the update process complete succesfully? -
@netblues My observations (logical) - pfBlockerNG was working perfectly fine "before" update pfsense to 25.07.1-RELEASE (arm64)- After the update i have made "zero" changes to pfBlockerNG - Based on this obervation, i logically conclude the update probably broke something that pfBlockerNG depended on? I maybe wrong but this is my cause and effect conclusions.Can others chime in? Do you have similar problems or observations?
-
@netboy Most probaly a configuration regression.
You really need to dig deeper.
From which pf version did you upgrade?
Have you tried removing and reinstalling pfblockerng?Looking to the moon for craters with naked eye doesn't show the one that the crashed spaceship created.
Use a telescope instead.
FWIW, I see quite a few pfblockerng instances on 25.07.1 running with no (apparent) issues τοο
-
Things you can test :
Leave pfBlockerng enabled, but :
Remove all IP lists.
De activate all DNSBL lists : you can do that by un checking :
Btw : You use the "Unbound Python mode", right ?
When DNS fails to work for your LAN devices, check 'manually' :
C:\Users\Gauche>nslookup google.com Serveur : pfSense.bhf.tld Address: 2a01:cb19:907:dead:beef:92ec:77ff:fe29:392c Réponse ne faisant pas autorité : Nom : google.com Addresses: 2001:4860:4802:32::78 216.239.38.120This tells me my LAN (windows) device was using the pfSense LAN IPv6 = 2a01:cb19:907:dead:beef:92ec:77ff:fe29:392c (for IPv4 this would be 192.168.1.1) - so I know that my device is using pfSense, the resolver, as it DNS source.
I got an answer, so I know the resolver did its work.If no answer, go console or SSH of pfSense and check there :
[25.07.1-RELEASE][root@pfSense.bhf.tld]/root: dig @127.0.0.1 google.com +short 216.239.38.120This shows me that @127.0.0.1 (pfSense localhost) answered, as the resolver listens on every LAN interface and also localhost.
This :[25.07.1-RELEASE][root@pfSense.bhf.tld]/root: dig @192.168.1.1 google.com +short 216.239.38.120as my pfSense uses the default 192.168.1.1/24 LAN IP.
If no answer : then the resolver isn't running, and that's 'not normal'. Starting it :

would resolve the issue right away.
Left to discover : why does your revolver (unbound) process dies ?edit :
Also logical : we all use the same 'code' :
( I'm using 25.07.1 on a 4100 )
'all' is probably a couple of hundred thousand pfBlockerng users using 2.8.1 or 25.07.1 and the latest pfBlockerng version.
The only thing that is different for all of us : our settings ...
This requalifies the problem from : "is something wrong with pfBlockerNG?" to a more mangeable "is something wrong with my pfBlockerNG?".
And as it is already known that we all use the same "pfBlockerNG", the issue reduces further to "What wrong with my (pfBlockerNG) settings?".
So : tell us all about your pfBlockerNG and DNS (!) settings, and we might be able to tell you what's wrong