@jrey and @FCS001FCS - thank you both for your help. I believe I now have this resolved and part of the problem was my unfamiliarity with the ASN process in pfBlockerNG. It turns out that the post from @FCS001FCS was right on and the process does need to be bootstrapped somewhat with an ASN IPv4 list to download the files for the first time.

More Details:

If just enable ASN reporting (e.g. 1 hour cache and enter IPinfo token), save, and force an update, nothing happens, and no ASN files are initially downloaded. If I perform step 1, and then also create a new ASN IPv4 list, add an ASN to it under the Source field (as described above), save & enable that list and then force an update, the IPinfo ASN files are downloaded as part of the forced update and the ASN IPv4 list is populated. It turns out that I could see ASN information all along when creating a new ASN IPv4 list. I incorrectly formatted the text in the Source field the first time preventing the drop down list from showing. If I do not perform step 1 first, but still create the ASN IPv4 list and force an update as described in step 2, I will get an error during the update that I need to register for an IPinfo token and ASN IPv4 list will not be populated.

Long story short, after enabling the ASN reporting capability, to trigger the initial download of ASN files from IPinfo during a forced update, an IPv4 block list with one or more ASNs should be created as well. So in my view the initial download process is bootstrapped via the existence of an ASN IPv4 list.

A couple follow up questions:

Do the ASN files from IPInfo get updated on a regular basis now? Should ASN information also show up in the pfBlockerNG reports (e.g. permit, deny, unified logs)?

Thanks again for all your help, I really appreciate it.

@jrey said in pfBlockerNG-devel 3.2.0_18:

@tman222

so this maybe.

what is in your extras.log ? that is where the download is logged --

@jrey said in pfBlockerNG-devel 3.2.0_18:

regarding the change regarding the setting for ASN Reporting which must be enabled now.
The old feed would download even if the setting was disabled, the new ones won't even though ASN reporting means something else. Enable 1 hour

Thanks @jrey for the response. I'll continue the conversation regarding this issue in the other thread I posted.

@smolka_J No tweaking , i don't like that.

@johnpoz Thank you for the detailed and quick reply! I'm still looking at it to ensure I understand.
@ahking19 I did understand your message, and I created the firewall rules myself, as opposed to auto. Thank you.

@planedrop You can always (re)apply the one liner fix to the pfblockerng.php file under /usr/local/www/pfblockerng/ on the Master node. Haven't had any issues since.

@michmoor
Right thanks. I thought I had read somewhere that the functionality I wanted would be coming in a future release of pfblocker.
I have Pihole currently doing what I want but had wanted to simplify or consolidate the functionality in a single device.
Thanks for your feedback again.

@Beerman Some form of fix will be but may be in a different area or dependency package that pfBlockerNG uses. That line wasn't present in 3.2.0_8 and earlier versions of the pfblockerng.inc so I'm assuming something had changed in the magic database file(s) that's used to determine mime types. I have a similar error on feed PRI4_v4 - CCT_IP_v4 https://cybercrime-tracker.net/fuckerz.php that is coming up invalid Mime Type application/javascript, while the same feed is working fine on my CE VMs on pfBlockerNG 3.2.0_8. Tried adding a line with 'application/javascript' but that didn't do anything for it specifically

They had an earlier post about the upcoming changes as well which kinda explains it better:
https://blog.snort.org/2024/08/upcoming-changes-to-snortorg-sample-ip.html

My plus Offers me upgrade to 3.2.0.10 Is that safe? Or should I stay on 3.2.0.9

@michmoor said in pfblocker - speed up search:

I cant speak for @Gertjan but

just looking at the various screen captures provided the return expectation of @Gertjan is at least 500 results. That means on whatever search you are doing please return the most recent 500 that match. For alerts in particular if all (4) sections of the report have the same return value limit and you are searching you are telling each section to return 500 results. Could generate a lot of reading and then looking up related "stuff" to do that on top.

Screen Shot 2024-09-20 at 6.15.34 PM.png

if you are looking for DNSBL set that field to 50 to start, set the other 3 to 0
Screen Shot 2024-09-20 at 6.43.57 PM.png

for the alerts report Unified setting and DNS Reply setting will have no impact
this is how the 6 return value settings line up to the 3 reports.

Screen Shot 2024-09-20 at 6.46.14 PM.png

Sorry the IP Permit and IP Match both go to Alerts, made the green lines too wide and the overlapped. Honest there are 4 green lines there... 😊

Hi all,

since I deleted the files and de-installed watchdog no more errors occurred in the last 24 hours (which included a few cron jobs by pfblocker) so things seem to be fine again.

Oh, and yes, I have been running the python mode before (and still am) on DNSBL.

thanks again for helping.