@Stonework4958 said in Issues with 25.11 latest patches and latest pfBlockerNG: being 1.1 million hosts Consider this : for every DNS request unbound receives from your network (pfSense, LANs), it has to parse these 1,1 million for a potential match. That's might no be a big deal if you have just a couple of LAN devices connected. Also : asking pfBLockerng to 'load, parse, sort, match, whitelist and handles stats' over a list with 1 million entries ... knowing that pfBlockerng is using world's worst data handling language ( also known as PHP **) can create unstable situations. I know, it's easy to 'click and select them all', but there will a a price to pay. My advise : give your pfSense (and thus yourself) a break ^^ ** PHP was meant to create web pages. Not massive data management. PHP is also very limited in its RAM usage, normally around 500 Mbytes on an average pfSense system, and your DNSBL file is more like 10 Million bytes or so (check it in the /var/unbound/ folder)

FWIW I've pushed a fix for this. We're planning on doing a point release for 25.11 and that will coincide with an updated pfBlockerNG package.

@tinfoilmatt Sorry for hijacking a bit but would you mind having a look at this post: https://forum.netgate.com/topic/199864/issues-with-python-mode-in-dns-resolver/2 - it does seems like it is blcokerNG script that is breaking the DNS resolver in the end but Im not programer or know python that well (just basic scripting) to analyze the script and what is it doing :/

@tinfoilmatt said in pfBlocker IP Event Timeline view annoyance: That's shocking. Unless using a RAM disk, you're going to fry your storage device with that number of daily writes. Nope, no RAM disk and also running Snort which I understand is not recommended with RAM disks. It's a 6100 MAX so: 128 GB M.2 NVMe storage if the specs haven't changed since introduction. I'll have to make some time to drastically pair-down what's being logged. Agree - Over-the-top logging isn't worth the risk of blowing out one's storage. Meantime I've changed IP Block (log) MAX lines back to 20,000 (default) and will review/disable logging rules & rule-sets wherever it makes sense, that where the issue lives. Also on my list is to take a serious look at offloading the logs to something like a Graylog or Splunk. I appreciate the cautionary advice.

@andersondeda said in pfblockerNG ASN bgpview trouble: I'm using pfSense 2.7.2. I'm using pfBlockerng 3.2.0_8. Hi, you should update your pfsense to 2.8.1 then your pfblockerNG will also update to 3.2.8. Reason? The package pfblockerNG switched for ASN from bgp to ipinfo. To utilize the free IPinfo ASN functionality, you must first register for a free IPinfo user account. PS. Here the api.bgpview.io is also not responding. I guess they have some trouble/maintenance ... PPS. If you can update (for whatever reason) you have to wait that bgp gets there problem/maintenance settled. Happy New Year, fireodo

@luckman212 Thanks a lot — I'd just come to the same conclusion! Everything's working fine now! :)

This is, generally speaking, how 'the cloud' works. Using a (paid) Entra SKU and Conditional Access policies, you can control which countries your tenant can be accessed from. But unless your organization is eligible for Microsoft 365 Government, you're not going to be able to control where your tenacy's resources are stored. (And even then I'm not so sure.)

@Mike_P Create the virtual IP on the "Loopback" interface, not the "LAN" interface, and then you should be able to assign it to pfBlockerNG's DNSBL webserver via the setup wizard. You should also update pfBlockerNG to the most recent version, 3.2.13_4.

Adding more info: I disabled DNSBL->Top 1M Whitelist and did a force reloaded. So far the error has not returned but I won't know until after it does another cron update. Still would like to know why this error is occurring, apparently due to the Top 1M Whitelist. The selection disabled is Cisco Umbrella.

@KOM No dynamic-alias nor feed-based IP filtering for you?

@marcosm Thank you. Updated and now it is working just fine.

I did a packet capture of several clients DHCP communications. This issue does not appear to be related to pfBlocker-NG, rather it seems to be related to Kea DHCP responding to DHCP request with a fully qualified domain name to the client request packet. Kea is adding a '.' at the end of that FQDN name in the response packet. Here's the relevant packet snippets: Windows client DHCP request: Option: (12) Host Name Length: 15 Host Name: DESKTOP-0MLM8MR Option: (81) Client Fully Qualified Domain Name Length: 18 Flags: 0x00 A-RR result: 0 PTR-RR result: 0 Client name: DESKTOP-0MLM8MR Kea DHCP ACK response: Option: (81) Client Fully Qualified Domain Name Length: 19 Flags: 0x08, Server DDNS A-RR result: 0 PTR-RR result: 0 ===> Client name: desktop-0mlm8mr. I will post this over to the DHCP/DNS forum.

@marcosm and @BBcan177 Updated to pfBlockerNG-devel 3.2.13_1 and the counts seem to be accurate now. Thank you.

@SteveITS It shows all the entries properly matching the alias table IP count. It's just the final line in the update log in pfblocker that shows a weird total table usage count as well as the pfblocker widget (both attached above) that are incorrect.

@mki Had similar issue. When force reloading DNSBL , process was stalling and erroring with CCT_BD. Ending up having to delete CCT_BD (https://cybercrime-tracker.net/all.php) and all is now well.

@Agneten Pro ? that and they dished the RTFM concept ? @Agneten said in DNSBL Python Mode GUI table missing on pfSense 2.8.1: ....your own (v)lans and assign different policies to them ... pfBlockerng doesn't (afaik) have the functionality to act differently upon LAN networks (aka interfaces) or LAN IPs. That is, it has the more or less 'all or nothing' Python "Group Policy". I hope to be wrong of course. My source : Here it is : 10 lines ... The thing is : unbound is set to listen to all interfaces - port 53, TCP and UDP, for DNS requests. "pfb_unbound.py" is nothing more as a plugin written for unbound. unbound sends the DNSC request to it's plugin, and the plugin can acts (in the main operate function) upon it. Basically, the 10 lines shown above do this : "if the requester IP is member of the policy list, accept the request and return back to unbound to handle it". If not, the comparing with DNSBL lists is done. I agree with the "preliminary" word here. The filtering could be done way more specific. Maybe in the future ?

edit : I found this post, created hours ago, not posted. So I finished it up and posted. Basically, what @SteveITS said above ^^ @cburbs said in PfBlocker and Paramount +: Like : when the device asks for host name to be resolved, like an add server, this host name will now be avaible ... for all your LAN devices, as it's now part of the resolver's cache. Ones a host name is white listed, it will be whitelist for all your LAN network devices. The "use the pfBlockng Python Group Policy" function (list with requesting IPs) will short circuit the DNSBL handling. Example : A device wants to resolve "horrible-add-server.com", so it sends a request to the upstream DNS, pfSense = unbound. Unbound will receive the requests, and checks its local cache if it wasn't already resolved = locally known. If it is, answer is returned straight away to the requesting LAN device. Take note : no DNS resolving was needed, a cache hit will return the answer direct. If the host name "horrible-add-server.com" isn't available locally, the resolve process kicks in. It's this process that first calls a local unbound plugin = our pfBlockerng script. The plugin interface doesn't use shell, PHP, LUA, or a binary, no, it uses Python. hence the name 'Python mode'. This Python script starts by checking if the requester is listed under "Python Group Policy", and if it is, "Ok" is returned right away : resolving starts and the answer is return to the requesting device. Take note : and the answer is placed in the local unbound cache. Now you understand that if a whitelisted "Python Group Policy" that will request "horrible-add-server.com" will make the resolved result avaible to all LAN networks. ... and this is why I wish a knew of a way to just do exclusions for a single device. I think there is. It's called "views". Go here : Services > DNS Resolver > General Settings and look at this page from top tho bottom. ( Have a look at the Advanced Settings page ) The good news is the bad news. Read this .... And now you know there are more possibilities - waaaay more possibilities. Probably most of the are accessible with this : [image: 1764832409373-d62cadd5-b3a4-4fa8-91c0-d67b73c498ee-image.png] Like the good old days : you have to create your own 'extended unbound config', and you'll need the manual. You'll discover that 'views' exist, so you can use these to have unbound work for differently on a network (LAN) level and even device level - never tested this myself though, but others did. Some examples are present here on this forum. So, you want special things 'just for you' : that's ok, but you have to go outside of what the pfSense (and pfBlockerng) GUI can do for you. A GUI can only offer a small percentage of all the available possibilities (of unbound).

I ended up slicking the whole pfblockerng config and started over from scratch. Took a few recommended defaults and added the Hegezi list. So far it seems to be back to normal and at least for one game (sudoku) that had an annoying amount of ads pop up it's clean again.