Just verified this on 2 boxes each after a fresh re-flash back to pf 22.05 after changing repos on the updates tab corrupted my conf files and then led to persistent certificate errors at boot, going back to restore configurations I ran into this on each, and in IPv6 whitelists as well. Config.xml restoration went smoothly and re-installed the packages after fine also. Previously saved IP whitelists I created in 21.05 that I haven't edited since show the correct configuration settings when I inspect them inside pfblocker and verified are still working at the auto generated firewall rules in creates. Verified still present in pfblockerng-devel 3.1.0_9, I can no longer edit nor can I create any IPv4/IPv6 whitelist with the available "permit inbound" or "permit both" options as they previously used to function. "Alias permit" does work though with manually configuring a new firewall filter for the alias. Just located this after posting about it too:

BBcan177BBcan177 MODERATOR 12 days ago
@bob-dig @cjbujold

See the patch here and report back pls.

From the Shell or pfSense GUI > Diagnostics > Command Prompt > Execute Shell Command, run this command to download the patch.

curl -o /usr/local/www/pfblockerng/pfblockerng_category_edit.php "https://gist.githubusercontent.com/BBcan177/1a33c42d0a61f3ddd9c2f1b1d514ed83/raw"
"Experience is something you don't get until just after you need it."

@nogbadthebad that is odd nslookup behavior..

oh tip on windows, you could try adding . as the search suffix.. since it won't let you use nothing.. this seems to quiet it down.. Atlease from respect of nslookup debug.

@gertjan

I didnt have to disable all or reinstall pfBlockerNG.

The only thing I did was increase the Firewall Maximum Table Entries to 600000

located at System / Advanced / Firewall & NAT

from previous value of 400000

Maybe I bought some more time?

@yquirion I was surprised as well and was hoping it did not change my configuration which it did not. I was not aware about querying the database so I learned a very nice thing from you as well.

@gpinzone

?
Have a look at a DNS packet unbound receives on the pfSense LAN port. Yep, that will be an Ethernet packet. As filter criteria, set up port 53, and use the IP of your device.
As soon as you have one, inspect it. This is technology of the years 60 and 70, last century, so quiet simple.

You will find out quickly there is a source IP, destination IP, source port, destination port, and a 'word' with 16 or so bits that tells what kind of packet it is (like UDP - the packet number etc) and a time stamp.
There is no information that tells unbound "what program" made or send this packet ***
So, unbound on pfSense can not know that the packet creating program was a 'browser' (or a mail client, or command line tool, or a file server, or a mail server, or whatever program) that wants to communication over the Internet.

With some very nifty comparing you could speculate what OS made the packet. Programs exist to do this kind of detecting. Unbound can't do that.

What you can do : tell your browser to do its own DNS, so addresses itself direcly to, for example, 8.8.8.8 or a "canary" solution.

@bbcan177 Hey thanks for your efforts, any luck with the patch specific to saving port alias for Geo IP as well.

@meelek Thanks for the report. This will be fixed in the next version. Problem was that it was validating for Domain name which failed to validate just TLDs.

@serbus said in Error when creating whitelist:

A quick, untested, use at your own risk code hack that could possibly get this working on 3.1.0_9 would be to change line 443 in
/usr/local/www/pfblockerngpfblockerng_category_edit.php

This would just bypass the validation completely for other variables also. But it will temporarily fix the issue. This will be fixed in the next version. I posted a patch in another thread.

@bbcan177 Thank you!

@serbus said in GeoIP Showing Unk:

Thanks for the report. The problem is that $file_dwn_esc should be $file_download. Will get this fixed in the next version.

exec("/usr/bin/tar -xzf {$file_dwn_esc} --strip=1 -C {$pfb['geoipshare']} >/dev/null 2>&1");

Or don't make them auto. Just create them once and then I can drag them around like I want. Probably the same work on your end though.

@noplan Many thanks. Removing those files (dated 1969) and restarting the Unbound service worked for me

You can temporarily disable DNSBL blocking by:

Going to Firewall-->pfBlockerNG-->DNSBL
and unticking "Enable DNSBL"

Going to Firewall--> pfBlockerNG-->Update
and running (forcing) an update.

Going to Status-->DNS Resolver and clicking the "restart service" icon.

Now try to reach your previously blocked web site again.
If you can now reach it, then DNSBL is the culprit.

To turn DNSBL back on, tick "Enable DNSBL",
and do steps 2 and 3 again.

@steveits said in Pfblocker not blocking outbound connections:

@tbr281 Is the DNS server on your devices set to use pfSense? If they are, empty the DNS cache...on Windows, "ipconfig /flushdns".

Note many browsers use DNS over HTTPS (DoH) to bypass local DNS, so that may also need to be blocked or disabled. pfBlockerNG-devel has a setting for that on the DNSBL SafeSearch page, though I had some trouble getting that to work and ended up using the DoH_IP feed.

That worked thank you!!

@bbcan177 said in pfBlockerNG-devel v3.1.0_7 / v3.1.0_14:

I was waiting for someone to post what error they were seeing and I didn't get any helpful details. So I think that bit of info that you now provided helps diagnose the issue. I will post a fix for testing once I have it ready.

I'm a bit confused as to the current status of things... The current version I see available is 3.1.0_9. Does it have a known bug related to DNS getting sometimes broken? Thanks.

@wifi75 Did you wait for it to reinstall all packages after you reinstalled pfSense? There's a banner that pops up telling you not to do anything until it's done.
But no worries, just reinstall the package from package manager, you won't lose it's config.