is something wrong with pfBlockerNG?

SteveITS

@netboy next time, try just restarting unbound/DNS

netboy

@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

tinfoilmatt

@netboy said in is something wrong with pfBlockerNG?:

IMHO pfBlockerNG is defintely broken

Can confirm this is nonsensical.

netboy

@tinfoilmatt The proof: if i disable pfBlockerNG no issues this "clearly" confirms WITHOUT DOUBT it is broken

tinfoilmatt

@netboy Well then it would seem that you've successfully resolved your root issue. Nice work.

netblues

@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?

netboy

@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?

netblues

@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 τοο

Gertjan

@netboy

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.120

This 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.120

This 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.120

as 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

netboy

@Gertjan said in is something wrong with pfBlockerNG?:

"is something wrong with my pfBlockerNG?".

First off, thanks for the detail reply.

After my post, I "changed" DNSBL -> DNSBL mode from "unbound python mode" to "unbound mode" and so far i have no issues.

I understand what you are saying & hinting "maybe something is wrong with my settings" - my response is this:

Everything was working before i upgraded the pfsense software to " 25.07.1-RELEASE (arm64)" -- Before the update my DNSBL Mode was set as "unbound python mode" and everything worked.

Here is my "inference" - something broke in pfBlockerNG after the upgrade and I cannot 100% point to what that setting (my) is?

I will observe for some days how this change in DNSBL mode works out and report the findings.

Gertjan

@netboy said in is something wrong with pfBlockerNG?:

arm64

That might be a factor.
I said that our code base is "bit-wise" identical - and we use the same processors.
Actually, that's wrong.
X86/amd64 isn't arm64 at all.

So, I'm not finger pointing, but I can't test the 'arm' version, as I'm using a 4100, a amd64 device.

I has a new unbound version installed yesterday. The previous version was 1.23.x - the new version is 1.24.1.
To get it : ssh or console, option 8, and then

pkg update
pkg upgrade

and again, not sure if this is valid for arm.

tinfoilmatt

@netboy said in is something wrong with pfBlockerNG?:

After my post, I "changed" DNSBL -> DNSBL mode from "unbound python mode" to "unbound mode" and so far i have no issues.

Terrible idea. Moving backwards in development history there.