Turns out it is the semicolon causing the issue.
In this post, BBcan177 says there is no parser for the semicolon.

@jeffvogelsang
Well, on PFBLOCKERNG/DNSBL page, there is the TOP 1M WHITELIST. You can choose the Cisco or Alexa list and then choose how many down the list from the top you want to whitelist. Then choose what is to be included in TLD whitelist. I see it as a safety net to catch popular domains that could end up as a false positive in the blacklists. I set mine to the top 2k.

A real pre-packaged 'whitelist' like the blacklists would be very hard to maintain and would obviously need to be very large to really be useful. Consider that for it to have value, you would have to decide what to do with sites that are not on the whitelist. Do you block them? If you don't then what is the point of the whitelist? Thinking someone can figure out, for all the blacklists out there, what the false positives are and then making a whitelist for them and keeping it up to date would be about as daunting. Think about the maintenance involved, ouch.

I rarely have issues where I have to add anything to the whitelist anymore, my list is about 45 domains and some TLD exclusions that have been added over the last couple of years. If I test out a a list and see a large amount of false positives I dump it and use something else.

@maba
Thank you. Makes sense. Just found the button to clear out the counters and reset them!

Screen Shot 2020-05-01 at 7.06.00 PM.png

ok i figure it out ...
for some obscure reason , the line

server:include: /var/unbound/pfb_dnsbl.*conf

in dnsresolver was append at the end of my custom options ... it need to be at the top before them...

The update of pfblocker have broken that.

Hope it stay as it is.

edit: and a better solution : my options just miss one line ...

My "options" begin with:

local-zone: "x.X.X.X.X.X.ip6.arpa" typetransparent

i had to add "server:" just before "local-zone" ... so no more crash , "server:include..." can be at the bottom or at top ... it's working. ;)

So maybe the bug, one more time, was between the chair and the keyboard ;)))

@Jobee Please wait for package update: https://redmine.pfsense.org/issues/9874#note-8

@manuelgop Did you apply the changes after reordering the rules? They apply in order, though as I said pfBlocker might reorder them.

You mean a IPv4 List you created is now not working?

I'm having the same problem with a brand new setup + List.

Cant create it, when it tries to update it gives me custom error list!

Thanks all.

I just came here to check if there was an eta on 2.2 being not marked as development - I normally just look in the package manager for updates.

@NollipfSense said in When will pfBlockerNG 2.2 be stable:

@zjgn said in When will pfBlockerNG 2.2 be stable:

pfBlockerNG-devel 2.2.5_30

Has been stable getting close to 2yrs now.

So is the 2.1 branch no longer recommended?

@IsaacFL said in pfBlocker, blocking the wrong countries:

@bmeeks maybe someone who is using pfblocker more than I, could verify if that is really the case.

This is a /10 owned by Microsoft in Ireland so a pretty big error in the data base.

I know it was pointed out that the orig file was not in numerical order, but at least the csv file I downloaded from Maxmind, was in numerical order so I expected the country extraction would also have resulted in something also in numerical order.

But i didn’t spend much time on it so could have been something I did wrong.

Sorry, but I don't use pfBlocker. I was just responding to the general issue of GeoIP inaccuracies. This effects things other than just pfBlocker.

My personal opinion is that GeoIP is slowly losing its utility due to these errors.

@gabacho4 said in lighttpd taking > 30% cpu:

Turning off the pfblockerng service does

Leave it on. With the default settings. With no feeds what so ever.
Now you have the same config as I have, and the same as the author has. he wouldn't release it if it would explode the usage of certain( lighttpd ) processes.
All will be fine - guaranteed.

Now, add your feeds - your config, step .... by ... step...... and test a lot.
As soon as you see strange things, like lighttpd going haywire, undo that step - reboot, drink cofee, take a break, and test that step ones more.
Still a no go ?
Detail your step on the forum : you'll be having something that can be reproduced. That's worth a lot !
If you find something : do not forget to detail your entire setup without omitting anything.

Btw : You could even disable lighttpd, as it only servers a 1 by 1 pixel in most times (I guess, never tried it).

@gabacho4 said in lighttpd taking > 30% cpu:

Is there really only a couple of us having this issue?

Just you ;)
tazmo resolved the issue by putting things in place. A reboot is rarely needed, but it never hurts.