@Home-User That is WAD (works as designed).. If you try to send a https request to some block page, yeah your browser is going to complain.. It tried to go to say www.somethingblocked.com, and it gets sent to the VIP ip of pfblocker serving up a page saying this is blocked, this cert is not for www.somethingblocked.com - so yeah your browser going to complain. See the part of the error where it says "the name on the cert does not match" https://forum.netgate.com/post/873559

@jrey thank you for the reply. It think I may have fixed the issue, I am using a ram disk and it was completely full. I have fixed this by encreasing the size and so far no issues. Thank you

@planedrop So at least that's setup right in the config yup that was a long shot that something was corrupt and not showing the correct value. Sure thing. @jrey said in Unified Log Growing Infinitely (24 gigabytes and counting): ls -l /var/log/pfblockerng/unified.log; ls -l /var/unbound/var/log/pfblockerng/unified.log you could try ^ and see if the files are exactly the same. Actually so could I -- I'll just break it on my test box and see what happens. I've actually went a little further on the logging of the logs being trimmed T(Target) B(efore) A(After) and at least now I have confirmation that logs are being trimmed. Also discovered another annoyance (to me) -- there is no reason at all to go through the steps of making a temp, moving it back etc for a file that only has say 6 or 1 line in it. So I might change that some day as well. UPDATE PROCESS ENDED [ 01/8/24 14:31:00 ] Log trimmed(2): '/var/log/pfblockerng/pfblockerng.log' Lines: T:10000 B:11110 A:10000 Log trimmed(2): '/var/log/pfblockerng/error.log' Lines: T:10000 B:6 A:6 Log trimmed(2): '/var/log/pfblockerng/ip_block.log' Lines: T:20000 B:20878 A:20000 Log trimmed(2): '/var/log/pfblockerng/ip_permit.log' Lines: T:20000 B:20031 A:20000 Log trimmed(1): '/var/unbound/var/log/pfblockerng/dnsbl.log' Lines: T:20000 B:20388 A:20000 Log trimmed(2): '/var/log/pfblockerng/dnsbl_parsed_error.log' Lines: T:10000 B:1 A:1 Log trimmed(1): '/var/unbound/var/log/pfblockerng/dns_reply.log' Lines: T:20000 B:24884 A:20000 Log trimmed(1): '/var/unbound/var/log/pfblockerng/unified.log' Lines: T:20000 B:26126 A:20000 (I liked the logging change enough to patch my production box - let that spin for a while)

@korgua Just as a proof of concept that the 3.2.0_7 package would run on 2.7.0 I spun fresh 2.7.0 instance installed 3.2.0_7 pfBlocker [image: 1704571000873-screen-shot-2024-01-06-at-2.52.23-pm-resized.png] [image: 1704571010252-screen-shot-2024-01-06-at-2.52.59-pm.png] DNS Resolver [image: 1704571032733-screen-shot-2024-01-06-at-2.53.37-pm.png] DNSBL [image: 1704571049079-screen-shot-2024-01-06-at-2.54.36-pm.png] The script is there, total 6146 -rw-r--r-- 1 root unbound 176 Jan 6 19:46 access_lists.conf drwxr-xr-x 2 unbound unbound 2 Jun 28 2023 conf.d dr-xr-xr-x 7 root wheel 512 Jan 6 19:49 dev -rw-r--r-- 1 root unbound 0 Jan 6 19:46 dhcpleases_entries.conf -rw-r--r-- 1 root unbound 3408 Jan 6 19:46 dnsbl_cert.pem -rw-r--r-- 1 root unbound 0 Jan 6 19:46 domainoverrides.conf -rw-r--r-- 1 root unbound 388 Jan 6 19:46 host_entries.conf drwxr-xr-x 4 root wheel 68 Jun 28 2023 lib -rw-r--r-- 1 root unbound 1271 Jan 6 19:49 pfb_dnsbl_lighty.conf -rw-r--r-- 1 root unbound 8429809 Jan 6 19:49 pfb_py_data.txt -rw-r--r-- 1 unbound unbound 8192 Jan 6 19:49 pfb_py_dnsbl.sqlite -rw-r--r-- 1 root unbound 1687428 Jan 6 19:46 pfb_py_hsts.txt -rw-r--r-- 1 unbound unbound 12288 Jan 6 19:58 pfb_py_resolver.sqlite -rw-r--r-- 1 root unbound 1043 Jan 6 19:49 pfb_py_whitelist.txt -r-xr-xr-x 1 root unbound 5534 Jan 6 19:46 pfb_unbound_include.inc -rw-r--r-- 1 root unbound 358 Jan 6 19:49 pfb_unbound.ini -r-xr-xr-x 1 root unbound 68158 Jan 6 19:46 pfb_unbound.py -rw-r--r-- 1 root unbound 300 Jan 6 07:29 remotecontrol.conf -rw-r--r-- 1 unbound unbound 83 Jan 6 19:46 root.key -rw------- 1 unbound unbound 2455 Jan 6 07:29 unbound_control.key -rw-r----- 1 unbound unbound 1411 Jan 6 07:29 unbound_control.pem -rw------- 1 unbound unbound 2455 Jan 6 07:29 unbound_server.key -rw-r----- 1 unbound unbound 1549 Jan 6 07:29 unbound_server.pem -rw-r--r-- 1 unbound unbound 1996 Jan 6 19:49 unbound.conf drwxr-xr-x 3 root unbound 3 Jan 6 19:49 usr drwxr-xr-x 3 root unbound 3 Jan 6 19:49 var Confirmed the DNSBL is blocking [image: 1704571949542-screen-shot-2024-01-06-at-3.11.55-pm.png] And the system is running with no issues -- but the recommendation that 2.7.2 is available still stands.

@Popolou I think i figured it out. In my click -> click -> next in setting up the config so that I can run tests, I inadvertently overlooked a setting that needed to be changed. Running more tests, but the limited testing shows logging happening. Thank you so much for that assistance.

The Alias native is working! Thank you very much!

@mzaknoen Looking to block malicious sites on the network generally the issue regardless of what you are trying to do will be based on the list effectiveness installed pfBlockerNG DNSBL, did not install the "devel" version There is currently no difference and the "non - devel" version is the way to go for most users. Looking into setting up category filtering, when checking the "adult" section, I am prompted with the memory warning. Memory warning specifically saying? What list specifically ? Guessing UT1 -> Adult ? that is something like 4.5 million "domains" with a file size of 122mb but well less than 8gb RAM That said the list is also full of bloat. is there a way for me to download that list of IP's on a computer and copy is over to my Pfsense device to avoid RAM usage of downloading that big file. yes, but downloading and using ram based on what was downloaded are different things. Any alternative options for blocking specific categories? yes, everything from education of users to block everything and move to allow certain sites only and anything in between. there is a balance and that will be different for every use case. consider the following sample from the UT1 adult list as I suspect that is what you are running into problems with. Ask yourself, do I have a need for anything on blogspot.com? Yes, write it down (you will want to whitelist that website(s) if you do) No, nice, just continue UT1 - Adult domains (raw file) 4,511,799 122mb remove all blogspot lines (raw file) is now 891,692 domains and 18mb add 1 line containing blogspot.com to the TLD list ( a quick DNS scan to others for example blogspot.hr are all cname or redirects to the .com) Okay, i have not even tried to load the list, it is not a list I would ever consider using. There are other ways with far less impact. However, for the purpose of this example I added only blogspot.com to a TLD for testing. I grabbed one of the URLs from the list (bad me) then over to a browser. Don't try this at home kids [image: 1703796094425-screen-shot-2023-12-28-at-3.40.32-pm.png] immediately gets the redirect [image: 1703796186256-screen-shot-2023-12-28-at-3.42.44-pm.png] and in the log we see the original request getting the cname reply and the website being blocked by the 1 line added to the TLD [image: 1703796340087-screen-shot-2023-12-28-at-3.44.57-pm-resized.png] A second scan of the original domain list, shows that many of the names don't even resolve, so those are just old and could also be removed. Size of list does not equate to "effectiveness" of the list -- also applies to any/all of the available lists. If the math is correct I've removed 3,620,107 lines from the file, and effectively have the same blocking with the addition of 1 line. Of course I'm not going to try every single one, although it would be easy enough to script a test. This is where the user education can come into play, why on earth would you be going to a website like zxaswdserdwokgkmbjnhntbftherhbfokmlplfnvhrfdx.(some TLD) certainly not by typing that address in. Often it is better, to determine what needs to be blocked specifically by reviewing logs. Do I use lists, certainly do. But certainly no need to hit the finishing nail with a sledge hammer. Memory is pretty flat lined here - holding at [image: 1703798930261-screen-shot-2023-12-28-at-4.28.09-pm.png]

@jrey Thank you

It seems after restarting pfsense a couple of times, the issue seems to have been resolved. I will monitor it for some time and will update here.

I see. Thanks for the info. I already solve it via PFblockerNG IPv4 and adjust it to firewall rules.

@jrey Thanks a lot for your input! That helps a lot as for example I had not seen the smetrics.cadenaser.com before. It did not appear in pfsense nor the browser dev tools. At the moment I allowed only pagead2.googlesyndication.com and with this, it takes 2-3 seconds more to start the streaming but I got this without any Ads. I will test some days, but if it does not work I will try whitelisting only your URLs. Much appreciated! Happy holidays and new year!

@jrey Thanks. I do confirm that I deleted the log entries for the error and when the cron job for the feeds ran again (0315, once daily) no further errors appeared. With your explanation I now understand what I am seeing and how to resolve it.

@Mission-Ghost In the current system if each of the lists are disabled there is no concern about pruning logs it will still happen the change I am testing, based completely on the one setting that cron is set to disabled - there is no concern about pruning logs it will still happen. The only change being made is that setting the cron job to disabled, will do exactly as the setting implies, which is not run the lists. CRON PROCESS START [ v3.2.0_7 ] [ 12/16/23 14:12:54 ] List processing disabled by cron setting 'Disabled' No Updates required. CRON PROCESS ENDED UPDATE PROCESS ENDED

@Understudy Of course, as long as you understand that the part of the config we are discussing in the other thread is on systems already updated and different than the DNSBL lists. on the other hand since it has been agreed over there that the update has likely already been run not once but twice. the menu should already be fixed. There is something else going on, and we are waiting for the OPs to respond. It's good that updating from 2.7.0 to 2.7.2 appears to have resolved your issue. Likely just means that something else was out of step with the version of pfB you had running on 2.7.0 and what it is now. you should be on _7 of pfBlocker now, not that there is a huge difference between it and _6. Thanks for the feedback.

I'm facing the same issue when attempting to perform outbound block for a set of ASNs and a custom source. See: https://redmine.pfsense.org/issues/14523

@Lockie said in DNS Log/Notification (Telegram): As what I'd like to ask is when a domain is access, could a notification be triggered. Perhaps a log of it on pfSense or even better a notification via telegram or similar. What pfBlockerng shows on the screen (GUI) is made for you, at the moment when you access the page that shows the stats. You've noticed, it took some time to generate the page. I'll show you the source. Open the console, or better : SSH. Option 8 : and type tail -f /var/unbound/var/log/pfblockerng/dns_reply.log and just look at it. If you have just one or two devices on your LAN, then there will be moments without anything logged at all. But wait : if one of these devices is a Windows PC : do the thing that you normally shouldn't do : Open Microsoft Edge. And enjoy the spectacle. On my pfSense, I can't even read the lines on the screen as they scroll by to fast. Note : Don't use the console access for this if its serial. 115200 Bits/sec won't make it. I'm pretty sure you see it coming now : you want to send the content of this file over Telegram ? Or something else ? You will get banned from them in no time. Checkout this one : [image: 1702631952481-cb0cfdb8-712b-4f5b-b288-ef2c2c3858da-image.png] Out of the box, it can't send the "/var/unbound/var/log/pfblockerng/dns_reply.log" file. If interested, I could show you the line to add, so it can send you the "/var/unbound/var/log/pfblockerng/dns_reply.log" file by mail. Btw : careful, this file can get pretty big. Email, these days, doesn't accepet 'any' size anymore. And as it gets very big (also called : huge), you can't really look at it anymore, and you'll be needing 'tools' to have it analyzed.

@Gertjan said in PHP error report on opening pfBlockerNG page in GUI: pfSense-pkg-pfBlockerNG-3.2.0_7. Not a bad question, but also the way the packages work now on the new structures - also the only choice. At 2 points in the cycle we have agreed the package was updated (Step 2 and again at Step 3) "../pkg_edit.... menu" shouldn't exist. But it does! Other packages still use it!! I have one such package installed.. and thus was able to recreate the exact observation. That is not the issue. Again there is no disagreement from me that the menu option is wrong in the config, and yes we see the effect of the issue because of it. Running this directly - may tell us more https://your_pfsense_ip/pfblockerng/pfblockerng_general.php Yes if a reboot post upgrade has not been completed, OR if the op has not simply logged out, closed the browser and then logged back in the current running dashboard might be using the old menu. Two possible items here. 1st the system then didn't update at the step 2 (reload of config), and 2nd the OP either hasn't rebooted or logged out since the update (fair question) a post upgrade reboot is always recommended, HOWEVER depending on the hardware you should not do that for at least 15 minutes. I always wait an hour (for no good reason, just the way it works out here). Even with that longer delay, I have never noticed a problem with accessing the menu before completing that post update reboot. For all we know, the OP has done something else at this point and it is working or not.