Addressed in this commit.

@Gertjan So why one tunnel and not the other, but running from the same Virtual IP out of the same WAN link?

@areckethennu Do I need a VIP configured? Is DNSBL deprecated? It's needed for DNSBL to work. The Virtual IP (VIP) allows pfBlockerNG to run a small local website that it can use as a replacement for all those other websites you don't want your devices to connect to. I don't understand why VIP isn't configured automatically with the upgrade. It is on some systems, but not on all. It isn't configured automatically for some systems because of the nature of how upgrades work on them. And on those systems it's only an issue between the old and new version of pfBlockerNG. Now that you've configured the VIP on pfSense, it won't be removed with future upgrades. I don't understand what I'm doing nor why I'm doing it or even if I should be doing it. Imagine you have the privilege of a home with a second floor. There's a master lightswitch on the bottom floor to control the stairs light, so when the bottom one is off you can't toggle the light from the upstairs switch. You want to avoid accidentally tripping one day due to not being able to turn the light on so you get an electrician to wire it up so you can control the light from each switch individually. Except in this case you're also the electrician. That's a very bad analogy of what and why you're doing it... ChatGPT could probably give you a better example .

@dalmirnogueira Windows Server by default uses root servers, unless you set up forwarding in its settings. Which, you can forward to pfSense. Note browsers may bypass local DNS using DoT/Doh, see https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html. If using an AD domain I suggest making a domain override in pfSense pointing to the AD DNS server. I find that helps if IPv6 is provided by pfSense, or something queries it. Or else you can set a DNS server in IPv6 settings.

@SteveITS said in Failed PF Blocker install due to PHP: pkg-static upgrade -fy pfSense-upgrade Thank you Steve, that upgrade solved my problem.

@SteveITS Ok, thank you for the info.

@colinstu https://redmine.pfsense.org/issues/16588

@Draco this is by design…see prior thread https://forum.netgate.com/post/1232883

@Bob.Dig Fair enough. The solution was to see on which feed the domain was blocked. Then the only thing I could do was disable that feed in its entirety, for Sucuri to no longer invalidate domains that other more renowned validators marked as clean and ok.

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