PFBlockerNG stops working (RESOLVED)

  • I am noticing that after about 10 to 12 hours the rules that were created by pfblockerNG diasappear from the respective interfaces. Despite the hourly Cron updates nothing gets applied to the interfaces. If I click "Force Update" the aliases get created and the rules are applied but after 10-12 hours the rules disappear and the aliases diassappear.

    Anyone notices this behaviour.


  • Banned


    Anyone notices this behaviour.


  • Been running pfBlockerNG for a long time, and have never seen anything like this.

    Have you looked at the pfBlockerNG logs?

  • I think this is related to this issue with NANOBSD. We usually have a schedulded reboot of our system nightly and it appears the aliastabled get wiped at the next cron after the reboot. So say we reboot at 2:30. Then when the system comes up at 2:32 the aliastables are created. But at when the cron runs at 03:00 then the log entry states that :

    ls: pfB_*.txt: No such file or directory
    Archiving Aliastable Folder

    I think this error is related to this:

    If this was meant to be fixed in version 1:06 I can tell you its NOT. Since the aliastables are not getting recreated at the next CRON. IN fact if click the "Force Cron" button, nothing gets created. But if I cclick the "Force Update" button, thats when the aliastables get created.


  • Moderator

    Hi Sammy,

    I believe that all Package Maintainers love to hear when things don't work on NANOBSD!  :)

    The process for NanoBSD is as follows:

    1. Download Alias/Lists. Files are created in /var/db/pfblockerng/deny (or other sub folders as required).
    2. Aliastables are created in /var/db/aliastables
    3. An archive of the Aliastables is made and saved in  /usr/pbi/pfblockerng-<arch>/etc/aliastables.tar.bz2
          Each time Cron/Update runs, if there are any changes to the files, a new archive file is created.
    4. At reboot an earlyshellcmd is run that un-compresses this archive and restores it to /var/db/aliastables. This is completed prior to pfSense Loading the Aliastables and Rules.

    However, the /var/db/pfblockerng folder and sub-folders are not restored. These will be created at the next Cron event or a manual "Force Update" process. The archive only contains the aliastables to reduce the size of the Archive to only the critical "/var/db/aliastables" folder and files because Nano systems typically do not have large amounts of non-volatile storage space.

    Steps to confirm -

    • Please verify that the archive file is created before reboot and that it contains the Aliastables.
    • Reboot and confirm that the archive file is extracted. You will see this in a Bootup window (from a Monitor)
    • view the contents of the folder /var/db/aliastables.</arch>

  • Moderator

    Another possibility is that you have pfBlockerNG set to Update and then you are invoking the Reboot of the Box before the Update process has completed?

  • Here is the step by step. It actually shows the problem from start to finish.

    Basically the cron is not working is not "re-creating" the file structure as its supposed to. So while the alistables survive the reboot the get destroyed at cron. But if you do a "manual" "force reboot" things work again.

    Please see the steps and screenshots attached.

  • Moderator

    Instead of using "Force Cron" after the reboot. Please use "Force Update" and see if that makes a difference. I don't use Nano but the two users who replied in this thread both use the Nano version with pfBNG without issues.

    I would also suggest you read the pfBlockerNG thread about Blocking the world and reverse that approach to Allow a few Countries instead.

  • Yes as shown in  Img 6, "Force Update" works. The only things is how do I automate that ?? I am willing to change the crontab file so that I do no an hourly force update. Since the reboot happens late at night we are not on site to log in and do a manual "Force Update". For robustness sakes there should be a way to automate this step.

  • Banned

    It works just fine automated for me (on multiple nanobsd boxes). I'd suggest to uncheck the Keep Settings box, remove the package and start from scratch.


    I would also suggest you read the pfBlockerNG thread about Blocking the world and reverse that approach to Allow a few Countries instead.

    Yeah, indeed…

  • Moderator

    The particular situation here is unique as most users have other Lists along with Country Blocking.

    So I see the issue now with "Force Cron". I will write an update and send it to you to test before I release it.

  • Thanks BBCAN … I will await your response.


  • BBCan is a ROCK STAR !!!

    Emailed me the patch and it works now like a charm. So I'm sure he/she will be sending the code upstream to be included in the next update of the package.

    The affected version was 1.06

    Thanks again for an amazing package and amazing support !!!

  • @sammybernard:

    BBCan is a ROCK STAR !!!

    Yes, he certainly is.

  • Banned

    We cant arque with that ;)

  • Yep ROCKIN'

    Scratching around trying to figure out why no rules were being created, no logs showing any complaints, configuring everything and looking for things that might hint of what could be broken. Then found this thread… pressed Reload and for the first time after hours of having pfBng enabled, it runs:

    UPDATE PROCESS START [ 04/03/15 23:55:19 ]

    All the rules werre written and appended to my interface rule-sets.

    Sweet! Thanks to all of you for these posts and of course bbcan177… who it seems may have nailed this for 1.07/8.

    Not a moment too soon (mine worked just before midnight)!

  • Moderator

    Hi unEsxi,

    Your situation is not related to the issue in this thread. You need to use "Force Update" to apply changes. There is a big red disclaimer above the "Save" button.

    Thanks for the overall positive Feedback!

Log in to reply