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

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.

@SteveITS Already did that by throwing My wheight Behind an existing ticket

https://redmine.pfsense.org/issues/14878

@NogBadTheBad

fair enough

@Orwi said in DNSBL not starting - lighttpd error:

These here?

Nope, the sections we're look for are at
Firewall > pfBlockerNG > DNSBL

Does someone kmow if a list is available?
I would like to import into pfblocker.
At my school students are using proxies and vpn to bypass firewall and i need to save my bandwith
Something like that?
https://github.com/TheSpeedX/PROXY-List/blob/master/http.txt

@jdeloach said in Shallalist: Failed to open stream: No such file or directory:

Since it's not updated anymore but still catches a lot bad actors, just turn off updates for that list and it will work just fine. I turned off updates for Shallalist a couple years ago but still use it and it causes no issues with the Cron app or anything else.

It's really as you said. As long as you control your account, your information will be well protected. Maybe this update will stay the same this time. Usually updates happen when they want to upgrade a feature.

It's running out of memory doing something in pfBlockerNG:

[03-Dec-2023 15:00:16 America/Barbados] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 122666480 bytes) in /usr/local/pkg/pfblockerng/pfblockerng.inc on line 3962

It may be some option in pfBlockerNG you need to adjust, but it might be something you can work around as well: You can increase the PHP memory limit on current releases using the option under System > Advanced, Miscellaneous tab. It's hitting an upper limit of around 128MB in your error.

@Jesper-1 said in Caching of NXDOMAIN:

When I compare that to the GUI-Top Reply DST IP it says 71% is NXDOMAIN

A break down of what answers were found for what is asked has little to do with that answer was actually resolved or from cache.

You could have 0 or 100% cache hits. That really wouldn't have anything to do with they all had answers or all were NX.

The info there like you provided direct from unbound, is the info you would want to look at to know how much was answered from cache by unbound, and how much was not.

How to interpret what pfblocker might be saying I am not sure - I don't use pfblocker to block any dns, I use it to create aliases that I use in my rules. Sorry. Unbound is the resolver - to know your cache hit or miss rate, you should look to the stats directly from unbound.

Keep mind any sort of stats on NX can be skewed, depending even in your settings to response. For example I block some stuff directly in unbound to respond with NX. Even if said thing might resolve to something, unbound returns NX.

I really appreciate all the help. Next week when I am at home I will dive into this again. In the meantime Pihole just the job.

@jrey said in pfblockerNG 3.2.0_7 new process?:

yup similar to what I was showing above but at the time, I had two of each.

So, since I don't mind break/fixing this non-production test machine,
I manually broke the link, and rebooted.

Thanks anyway that you are spending your time ...

think if should be version > "2.5" and NOT file exists) that being if the system is new and not running clog then link the file

Yes that is the logic behind. pfsense above 2.5 is not using clog anymore so tail is what has to be used ...

EDIT:

On a Lab machine, output of "ps ax | grep tail_pfb" (same pfsense version 2.7.1) with pfblockerNG 3.2.0_6 (before update):

11696 - S 0:00,00 sh -c ps ax | grep tail_pfb 2>&1 12025 - S 0:00,00 grep tail_pfb 27636 - S 0:00,01 /usr/bin/tail_pfb -n0 -F /var/log/filter.log

and after update to 3.2.0_7:

45276 - SC 0:00,01 /usr/bin/tail_pfb -n0 -F /var/log/filter.log 45907 - S 0:00,00 tail_pfb: system.fileargs (tail_pfb) 80307 - S 0:00,00 sh -c ps ax | grep tail_pfb 2>&1 80650 - S 0:00,00 grep tail_pfb

@cyberconsultants

Thanks heaps for the assistance, I'll try to implement that soon and let you know how it went :)