Pfblocker firewall rules move around???



  • I hope this is not a question that is too dumb or has alredy been answered but it's driving me nuts….

    pfBlocker block rules keep moving before some accept rules.
    I believe this happens once a day.

    Am I doing something wrong, misunderstand rules????


  • Moderator

    I believe that is normal.

    When you make any changes to the rules, the logs can mismatch the Rule Names. All new rules should be ok after you make any changes.

    I think this will be fixed in the next version.



  • There is a Cron job that runs "/usr/local/www/pfblocker.php cron" every hour. That looks for lists and stuff to update. After something is updated it does syn_package_pfblocker("cron"). That code rebuilds the pfBlocker rules in the various interface rule sets.
    pfBlocker is a "blocker" - it puts its rules ate the top, right after any "automatic" pfSense rules (like after the anti-lockout rule) and before ordinary user rules. e.g. if you tell pfBlocker to block "Africa", then that means block Africa, no exceptions.
    I don't think pfBlocker has any way to tell it to keep its rules at a certain point in the list, after some pass rules that you would like to apply, before pfBlocker blocks "the rest of Africa…".


  • Banned

    @phil.davis:

    I don't think pfBlocker has any way to tell it to keep its rules at a certain point in the list, after some pass rules that you would like to apply, before pfBlocker blocks "the rest of Africa…".

    Actually, when you select an "Alias only" for the list, you can add/move those rules where you want and they stick.



  • Yep, what doktornotor says  :D


  • Moderator

    If you add a new "Alias" to "Firewall:Rules", the Firewall logs will go out of sync with the Rule Name.

    Editing an existing "Alias" or editing an existing "Rule" will not cause the Firewall log to go out of sync.

    Thats on my boxes anyways.



  • Resurrecting this thread, had the same question.

    I ended up working around the issue by creating a floating rule and checking the "quick" option so it takes precedence over my regular WAN rules. This way my OpenVPN allow rule takes precedence over pfBlockerNG block rules, so I don't have to worry about my VPN accidentally getting blocked by any of my third-party lists.



  • @Crispix:

    Resurrecting this thread, had the same question.

    I ended up working around the issue by creating a floating rule and checking the "quick" option so it takes precedence over my regular WAN rules. This way my OpenVPN allow rule takes precedence over pfBlockerNG block rules, so I don't have to worry about my VPN accidentally getting blocked by any of my third-party lists.

    No need for a workaround; a solution exists (see doktornotor's post above).

    To give more detail, on List Action, I have all mine set to "Alias Deny."