@Antibiotic [image: 1728989194297-6d334907-5940-4713-8648-83a23ed2c3d7-image.png] was made for you ...

@smolka_J said in Custom Client Lists in pfBlockerNG: I'm waiting for pfSense's move to the Linux kernel that's coming down the road ... Im sorry, what ?

@mzeid said in Custom block list for specific subnet ?: pfblockerng block different lists for specific subnet While adding a new DNSBL feed here Firewal > lpfBlockerNG > DNSBL > DNSBL you can not select "use feeds only on interface LAN & LAN2" or "use feed only on interface LAN2 only", DNSBL feeds (filtering) apply to all interfaces. That is, this is valid when the "Python mode" is used. A feature request ? Btw : the above is 'very AFAIK, of course. For a school I would probably consider using a Pi-hole also As the DNSB Python filtering script is (I guess) aware of the requester IP, thus the network, thus the interface, it could be capable of 'per interface' filtering. In the past, before we were using pfBlockerng, and used handcrafted 'unbound' config rules, here : [image: 1728641354645-d451e5e1-6886-42ee-b577-9ea9f9d427c8-image.png] we were able to set up DNSBL files 'per interface' (per network). This meant that this one was our guide line. @mzeid said in Custom block list for specific subnet ?: bypassing one of the IP addresses That's the policy group setting : [image: 1728641081520-e41d7108-7cd8-424e-acd9-d3b82e996bd6-image.png] and from now on, this devices will bypass DNSBL filtering Btw : @mzeid said in Custom block list for specific subnet ?: teacher's computer I'm pretty sure the teacher doesn't mind he can't visit these sites neither ^^

@johnpoz I get back here tmrw ... it's late already in my timezone. Thanks so far! edit: currently sick since monday ... I'll get back here asap

Hi I have a similar problem. I have had PfSense for many years with no issues with PfblockerNG, recently I upgraded to latest version of PfBlockerNG 3.2.10. I lost full internet access for my single LAN. Turn off the pfblocker and reboot the firewall through GUI or console, Internet connectivity is back on. After trying to troubleshoot for a while, finally gave up and did a fresh install, problem is still the same. Another odd thing noticed in 3.2.10 version of pfblockerng is that the geoip to block and edit which countries to block, edit button was missing. Not sure if others have this issue or is this a bug in this release. Any ideas on what is causing the pfblockerng to break internet connectivity. I have a simple design: WAN interface, DHCP LAN interface, DHCP Class C addresses Pfsense current stable version 24.03 rel1 PfblockerNG 3.2.10 (currently not installed on a fresh install). Want to install and back with blocking ranges of IPs based on location/country I have another test PC that I can install the pfblockerng and test out the internet connectivity, hoping you can provide a tip to solve this issue.

@tman222 Yes, disabling the "States Removal" for the particular list(s) is what I did as a workaround. I looked for the code responsible when I made the post and recall pfblockerng is behaving as described in my first post. That is, if an IP address in a list is found in states, and "States Removal" is enabled, regardless of the "List Action", the state is removed. I retired my investigation since.

@SteveITS A little snooping (thanks for tip), I may have found the culprit. Now to see if I can fix it. The logs told me what was happening. CINS_army_v4,lb02.groups.io,Unknown,null,+ CINS_army_v4,lb02.groups.io,Unknown,null,- I unchecked/shut off the CINS_army feed and did a reload. That appears to have solved the issue. I'm just concerned why it was blocked recently. I don't stay up on some of this stuff, but even my work environment didn't block groups.io (and they block a lot).

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

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. [image: 1726870587973-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 [image: 1726872243946-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. [image: 1726872526016-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.

@SteveITS I tried both - Update and Reload. I'm just wondering that not all of the domains in my list where blocked. Edit: I tried again. The first time nothing happened. I tried again a reload for all and then: -1th webpage got an certificate error "net::ERR_CERT_AUTHORITY_INVALID" (the certificate had the pfSense details inside) -all other webpages are working^^ For me seems that this plugin/plugin is absolutely broken

@anubhav if you forward, you should not have dnssec enabled - where you forward is either going to do dnssec for you, like googledns or cloudflare, etc. or they won't like my 4.2.2.2 example enabling dnssec and forwarding is just going to lead to problems. And if your going to forward, if you want dnssec all the NS that you have listed to forward to should be doing it, or you can have different results depending on which actual NS got asked. Or if you don't want it - then all the NS you forward to shouldn't be doing it.

@michmoor There was a thread several months back…I think it boiled down to the update running (by schedule) on the secondary while the sync was still happening. But I don’t think there’s a way around that because the schedule setting is synced. We see it every couple months. I eventually set the pfB update to be a bit more frequent so it would fix itself.

there it is so as I expected that reboot is causing these 'Unknown' records to be added to the ip_cache database. When the system is starting up the filter starts blocking (as it should).. but the "lists" that pfB would be using are not available (I think this is primarily where tmpfs is memory based - I need to test this on a virtual using disk not ram disk someday - lol) so when the process goes to look it up of course they are Unknown. The problem is the "Unknown" entries are being written to the cache and then subsequent hits from the same IP lookup it up in the cache and find unknown. even if the underlying list might now be available, it will read the "unknown" from cache and use that. - That's the problem There is a better way, pondering, but for now the simple solution is don't cache "unknown" $stmt->execute(); becomes this if ($pfb_query[0] != 'Unknown') { $stmt->execute(); } Now the records won't be cached (still blocked and reported that way during the startup process) but as soon as the underlying data is correct the records start caching with IP address again. - Confirmed by doing... I'm ok with a couple of hundred block records saying unknown during the boot process, but then using the cached "unknown".. not so good. Now it occurs to me as well, that the ip_cache appears to only get flushed on a reboot, but the underlying lists used by pfBlocker could change. An IP that was listed and therefore blocked yesterday, may have been removed from a list and therefore should not be cached against the previous list. ie a) it is not on a list anymore (not blocked) and/or b) it is on a different list and should not be listed against the old one (or both) I'm thinking that when you see this 408 addresses added.337 addresses deleted. you don't need to worry about the "added" ones - they will cache if/when used. but the deleted ones (337 in this case) should be removed from the cache if they are there.. The quick solution here might be simply flush the entire cache and just let it start over, like on a reboot. I'm not seeing that it currently does either.(a seek and delete or a flush) If you reboot often the cache is flushed every time you do, but if you typically run for weeks (like here) the cache will become bloated with IPs that may or may not be what they currently are. The mechanism to remove stale ones and "update" existing one with fresher info doesn't seem to be there/work IMHO Pondering continues.. Still need to look at the reports but I don't believe they use the cache and likely shouldn't, you want to report on what happened at that time (from the record) not what happened from a stale or incorrect cache. etc etc Cheers