:)  I thought I fixed that… Dok mentioned it to me like over a year ago ... Will get that fixed in the next version...

Once I re-enable it I will report back as to whether or not the service restarts under those conditions. So I got around to enabling DNSBL, and I think I have it working.  ;D  The DNSBL service does indeed remain running now after a CRON or forced update. I did have to add a rule to pass traffic to the DNSBL VIP as you instructed… THANK YOU for that. I do have a question: what should I see in my browser if I navigate to the VIP? All I see is a blank page, but the title bar tells me it is resolved... is that normal? See attached. I would like you to take a look at a sample of the top of my firewall rules (I am a default block guy), and tell me if you see any issues. I wan't sure about my NAT redirect for DNS (as I asked above), so I left it. I also have one VLAN interface where I have the NAT redirect pointing to opendns (my kid's clients), and that seems to still work as well. I am very happy with the adblocking that I see now, and I will be adding to the DNSBL lists as you discussed here: https://forum.pfsense.org/index.php?topic=102470.msg573159#msg573159 Please review the attached sample rule set and let me know if you see any problems with the DNS redirect or otherwise. Thank you so much for your work on this package, and for your help! -Bill [image: 1x1.JPG] [image: 1x1.JPG_thumb] [image: Rules2.JPG] [image: Rules2.JPG_thumb]

I should mention that my VPN is setup as TUN, but all client traffic is forced through the tunnel. Hopefully this will help

Thanks.  That would seem the sensible way to go, particularly as someone has very kindly already done a pull request for it. I couldn't see an option for the RAM disk backup/restore in pfBlockerNG itself, so I'm assuming it's always enabled.  If you have the time, I could see a benefit to implementing the DNSBL backup too if only because it seems anomalous to have some of the settings backed up but not all. Thanks for developing pfBlockerNG by the way - it really is a useful and well-used package for pfSense.

I was trying to see what the process running would be pfBlockerNG that would be seen by top. The process that is running is php. Here is the real. I believe process /usr/local/bin/php -f /usr/local/pkg/pfblockerng/pfblockerng.inc dnsbl. Top would show php as the process. last pid: 18593;  load averages:  0.00,  0.01,  0.00                                                                                up 0+23:14:21  07:14:39 73 processes:  1 running, 72 sleeping CPU:  0.0% user,  0.0% nice,  0.2% system,  0.4% interrupt, 99.4% idle Mem: 104M Active, 383M Inact, 405M Wired, 256K Cache, 407M Buf, 2949M Free Swap: 8192M Total, 8192M Free   PID USERNAME  THR PRI NICE  SIZE    RES STATE  C  TIME    WCPU COMMAND 45366 squid      1  20    0  267M  167M kqread  0  0:14  0.00% squid 42679 unbound    2  20    0 55112K 28476K kqread  1  0:06  0.00% unbound 67172 root        1  52  20 17000K  2392K wait    1  0:05  0.00% sh 54987 squid      1  20    0 37752K  4084K select  1  0:03  0.00% pinger 37883 root        1  20    0  220M 33036K nanslp  0  0:03  0.00% php I was just curious why I could not see a process running. Now I know why. All I know about php that it is one of the scripting languages. Thanks for the information. If I have problems in the future I am able to dig deeper into the problem.

Oh look there it is! Apparently is for DNSBL with a big DO NOT EDIT. Thanks for pointing me to that, any ideas what to do from here or should I take the query into the PFBlocker post?  

@dougc420: OK a clever friend of mine found the solution. When I setup PFB it auto created rules. The list action was set to "Deny" by change that to "Alias Deny" and deleting and recreating the rules manually. This fixed the sorting order issue where the rules would move in priority. I also see the logic doktornotor shared. Rather thank blocking 4,225,000,000 port combinations and 3,706,452,992 public IP addresses causing much computational overhead. It is better rather to make selective entries to PFB specific openings and let pfSense do that inherently and not globally blocking everything using PFB because pf already does all that. Thank you everyone for your help I really appreciate your support. Now I do not have an absurd WTF setup.    (: +1, this solved it for me as well. My issue was I wanted to block the same IP's on LAN and WAN, but I needed the order to be different on the interfaces as I needed passthrough rules on the LAN, which obviously didn't work. Only drawback I seem to be getting due to this approach is that Alerts in the pfblockerNG now is empty so it is challenging to know which block list actually initiated a block. edit Duh, forgot to mark "log this".

Nice, thanks ! Think I'll hold off adding any more packages until after the 2.3 upgrade, but will keep pfBlockerNG in situ.

Ah yes thats a reverse address ofcourse duh why didn't i see that ;) I did a grep ":127" /var/db/pfblockerng/original/* result several ipv6 addresses: /var/db/pfblockerng/original/pfB_Europe_v6.orig:2001:67c:127c::/48 /var/db/pfblockerng/original/pfB_Europe_v6.orig:2001:67c:1278::/48 /var/db/pfblockerng/original/pfB_Europe_v6.orig:2001:67c:1274::/48 /var/db/pfblockerng/original/pfB_Europe_v6.orig:2a00:1278::/32 /var/db/pfblockerng/original/pfB_Europe_v6.orig:2001:67c:1270::/48 /var/db/pfblockerng/original/pfB_NAmerica_v6.orig:2001:1270::/32 /var/db/pfblockerng/original/pfB_NAmerica_v6.orig:2001:1278::/32 /var/db/pfblockerng/original/pfB_SAmerica_v6.orig:2804:1270::/32 /var/db/pfblockerng/original/pfB_SAmerica_v6.orig:2804:1274::/32 /var/db/pfblockerng/original/pfB_SAmerica_v6.orig:2804:1278::/32 /var/db/pfblockerng/original/pfB_SAmerica_v6.orig:2804:127c::/32 /var/db/pfblockerng/original/pfB_Top_v6.orig:2001:67c:1270::/48 /var/db/pfblockerng/original/pfB_Top_v6.orig:2001:67c:1274::/48 /var/db/pfblockerng/original/pfB_Top_v6.orig:2a00:1278::/32 /var/db/pfblockerng/original/pfB_Top_v6.orig:2804:1270::/32 /var/db/pfblockerng/original/pfB_Top_v6.orig:2804:1274::/32 /var/db/pfblockerng/original/pfB_Top_v6.orig:2804:1278::/32 /var/db/pfblockerng/original/pfB_Top_v6.orig:2804:127c::/32 /var/db/pfblockerng/original/pfB_Top_v6.orig:2001:67c:1278::/48 /var/db/pfblockerng/original/pfB_Top_v6.orig:2001:1270::/32 /var/db/pfblockerng/original/pfB_Top_v6.orig:2001:1278::/32 Don't think they are the problem. I have many more lists besides this "http://list.iblocklist.com/?list=bt_ads&fileformat=p2p&archiveformat=gz" I deleted them all the way you explained and run a force-update and a force-reload and disabled the suppression option but still filling up my system log with "kernel: pfr_update_stats: assertion failed".

In regards to what your explaining, there should be no difference in how the package is working in pfSense 2.2.6 or 2.3. If you wanted to start fresh with the package… goto the pfBlockerNG: General Tab, and unclick "Enable pfBlockerNG" and "Keep Settings"… then hit "Save"…  This will remove the database and files but leave the configuration intact... Re-click both checkboxes and "Save"…. Follow that with a "Force Update". You can then review the pfblockerng.log in the Update Tab window. Depending on how you defined the pfBlockerNG Cron task, its typically defined to run "Every hour". You can goto the "Update Tab" tab, and click the "View" button before the Cron task is scheduled to run, and you will see in Realtime what is occurring… If there are specifics, copy/paste those into this thread, or send me a PM and I can help guide you further...

@BBcan177: BTW… I'm the dev of the package and the last time I looked... I do this all for FREE and on my own time... What have you done... And from those of us who do listen… whom you have helped...  Thank you SO MUCH! I won't say its perfect (and I don't think you would either), but with a little tweaking here and there, random updates to block or allow lists, it works damn well.  I'm amazed at the numbers that build in the dash widget. Similar thanks go out to Bill for Snort too! Rick

@BBcan177: Before you run "Force Update", delete the two files: /var/db/pfblockerng/permit/pfB_google_ipv4    (Change permit and filename as required) /var/db/pfblockerng/permit/pfB_google_ipv6 The error persisted. But I found where the bug is. My list Header/Label was "Google IPv4" (with space). When I force update, it generates the "/var/db/pfblockerng/permit/Google IPv4.txt" file and I get the message: ... ===[  IPv4 Process  ]================================================= [ Google IPv4 ] Downloading update  .. completed ..   Empty file, Adding '1.1.1.1' to avoid download failure. ... I changed the Header/Label to "Google_IPv4" (space -> underscore) and now it is working as expected.

Can you PM me the contents of those two files (If there still is an error)… I can't do much without seeing the file contents when there is an error message...

In this case I wasn't concerned about the sigma list because I thought you meant by being unreliable it generated false positives, not corruption. We proved it wasn't the IPs in the list that were the problem, so I dismissed sigmalist as the problem. I didn't expect corruption to join the party. I guess it's good you discovered it because this could potentially happen with any other list, not just sigma. That was very good sleuthing! When I extracted the file on windows the smallest network in the list was a /10. Can I add a bug/feature report somewhere to add corruption checking on compressed lists? The country file is in the alias native so I can customize the order. see image i sent you. I''m assuming this is okay. EDIT: What about the sigma block showing up as a goodCountries alias in the log? Is this resolved because of the corruption or is this caused because of the way I'm using aliases? (or is there a 3rd option?) EDIT2: I couldn't stand that /3 got by me so I re-added them to pfSense and you're right. (should I be surprised I got a different result on windows?) . Wish I sorted by network size to begin with! EDIT3: Dug in some more to see whats up with the Alerts tab. I'm not sure how this works but based on how slow the page loads, I'm guessing that the block list information isn't stored in a logfile but instead the blocked IP is matched to a list dynamically so depending on how that works, I'm guessing a corrupt list could cause the log to malfunction. It seems to be working fine as of now. I looked through a few pages and looks like I would expect. https://s3.amazonaws.com/uploads.hipchat.com/9809/24877/2tOJuorc3rqUbcv/upload.png

I'm sorry to make you not happy. I'm here just want a fix, not a workaround: Is 192.168.1.100 a part of LAN net?  YES Is my firewall rule defined wrong:  Allowing OPT access all interfaces except LAN?  NO Should 192.168.1.100 be blocked by the rule:  YES, BUT its not blocking anymore. Again, I'm sorry made you feel so angry.  but thats the issue I'm having.  The rule was working perfectly until I installed your package, so of course, I need to ask you about this first,  if you think its not your package issue, then I will ask pfSense teams.

Nothing strange there. Would you mind posting a screenshot of the pfBlockerNG dashboard widget. Edit: I forgot that you posted the widget before. I don't see any issues with what your posting. Have you tried a reboot or a filter reload?  You are also on pfSense  v2.04, maybe update to 2.2.6?

Go to pfBlockerNG \ DNSBL then scroll down to the very bottom and add www.googleadservices.com then save, switch to the Update tab and force a reload.

When you install the package, it downloads the latest MaxMind GeoIP files. Those are updated the first Tuesday of each month. You will need to download those files as required. In the General tab, click the checkbox to disable the cron download of the MaxMind files. MaxMind files are saved in:  /usr/pbi/pfblockerng-amd64/share/GeoIP    (amd64 or i386) (You will need to extract these files into that folder) http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz http://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip Followed by executing these two commands to convert the MaxMind files for pfBNG: php /usr/local/www/pfblockerng/pfblockerng.php gc php /usr/local/www/pfblockerng/pfblockerng.php uc In the IPv4/v6/DNSBL Feeds tabs, you can enter a local address in the "Source Fields". Hope that gets you started!