Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfBlockerNG rules is going downwards in the firewall rule everyday

    Scheduled Pinned Locked Moved pfBlockerNG
    45 Posts 11 Posters 14.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • I
      igoldstein
      last edited by

      that seems to be working on our server that had the issue

      did you do any other changes to the package, other then the ordering issue ?

      should i be aware of any other issues ?

      finally, id love if you can add support for FQDN in a list, and have a "resolver" resolve the FQDN every x amount of time, and the resolved IP should be whitelisted or blacklisted, based on the rules of the list

      ?

      1 Reply Last reply Reply Quote 0
      • BBcan177B
        BBcan177 Moderator
        last edited by

        @igoldstein:

        that seems to be working on our server that had the issue

        did you do any other changes to the package, other then the ordering issue ?

        should i be aware of any other issues ?

        finally, id love if you can add support for FQDN in a list, and have a "resolver" resolve the FQDN every x amount of time, and the resolved IP should be whitelisted or blacklisted, based on the rules of the list

        ?

        Thanks for the feedback…  This fix will be in v2.0 which is just around the corner... v2.0 will have DNSBL domain name blocking via Unbound Resolver. It also allows conversion of an AS number into its respective IP Addresses.

        Could always add another beta tester should you be interested to test it out? Send me a PM....

        Thanks!

        "Experience is something you don't get until just after you need it."

        Website: http://pfBlockerNG.com
        Twitter: @BBcan177  #pfBlockerNG
        Reddit: https://www.reddit.com/r/pfBlockerNG/new/

        1 Reply Last reply Reply Quote 0
        • D
          dsmithson
          last edited by

          BBcan177,

          We have been testing the patch on one instance of pfsense in our environment.  igoldstein added a new BLOCK rule to the access list on that instance.  For some reason, now that rule gets moved down during 'update'.  We think it might be because it's not a pfB rule, so pfB allow rules get ordered in front of it.  See screenshot.  The second rule, blocking access to port 22 is the one that we now have to move up nightly.

          Is there an ordering option that will keep all block rules at the top even if they are not pfB rules?  Perhaps we are doing something wrong here.  Please advise.  Thank you.

          Capture.PNG
          Capture.PNG_thumb

          1 Reply Last reply Reply Quote 0
          • BBcan177B
            BBcan177 Moderator
            last edited by

            dsmithson,

            Create that other Block rule in pfBNG, and you can set those required settings in Adv. Inbound Options…

            "Experience is something you don't get until just after you need it."

            Website: http://pfBlockerNG.com
            Twitter: @BBcan177  #pfBlockerNG
            Reddit: https://www.reddit.com/r/pfBlockerNG/new/

            1 Reply Last reply Reply Quote 0
            • I
              igoldstein
              last edited by

              BBcan177,

              the problem is, the SAME list is also used to ALLOW traffic,  its a WHITELIST

              but i also use the same list in my rule to block for port 22, but there im saying if it does NOT match the IP's from this list, then it should block it

              here take a look at the screen shot of the rule

              Capture.PNG
              Capture.PNG_thumb

              1 Reply Last reply Reply Quote 0
              • BBcan177B
                BBcan177 Moderator
                last edited by

                @igoldstein:

                the problem is, the SAME list is also used to ALLOW traffic,  its a WHITELIST

                but i also use the same list in my rule to block for port 22, but there im saying if it does NOT match the IP's from this list, then it should block it

                Not enough information in this one screenshot to help you :)

                "Experience is something you don't get until just after you need it."

                Website: http://pfBlockerNG.com
                Twitter: @BBcan177  #pfBlockerNG
                Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                1 Reply Last reply Reply Quote 0
                • P
                  pf3000
                  last edited by

                  I had this problem of rule being moved down. Just uncheck "Floating Rules" in pfBlockerNG's main settings page. In other words, don't use floating rules. I hope it works for you, as it did for me.

                  For me, everytime cron or reload happens, my custom pfBNG rule would move from somewhere on top where I saved it, to the very bottom, in the floating rules tab. To narrow it down, it only happens to custom deny/reject pfBNG rules, and not custom pass/match pfBNG rules. My rule order is default setting.

                  I'm sure BBcan177 will have a workaround in a future version.

                  1 Reply Last reply Reply Quote 0
                  • BBcan177B
                    BBcan177 Moderator
                    last edited by

                    Hi pf3000… igoldstein's setup is too complicated to auto sort the rules in pfBNG. I recommended that he use "Alias type rules" for his setup as that will allow for a more fine-grain configuration.

                    I did however, test the following change with another user... Would you be able to fetch this file and see if that resolves your Floating Rule issue?

                    Thanks!

                    cp /usr/local/pkg/pfblockerng/pfblockerng.inc /usr/local/pkg/pfblockerng/pfblockerng.inc.bk
                    

                    Fetch the new file and execute a 'Force Update' cmd:

                    fetch -o /usr/local/pkg/pfblockerng/pfblockerng.inc "https://gist.githubusercontent.com/BBcan177/cf6af30af46fedd37d07/raw/ab64d4682b28dd5fdf3f84877b28fe1feeef14f5/pfblockerng.inc"
                    

                    Anyone else able to test that would also help…

                    "Experience is something you don't get until just after you need it."

                    Website: http://pfBlockerNG.com
                    Twitter: @BBcan177  #pfBlockerNG
                    Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                    1 Reply Last reply Reply Quote 0
                    • D
                      doug.claxton
                      last edited by

                      Hello
                      I have been dealing with this issue for some time now.
                      Two firewalls with default install and settings with different behavior.

                      I have some simply allow rules above the pfBNG rules to allow my remote travelers working from random countries around the world to be able to hit the exchange OWA https site on 443.
                      I would like to have those rules on top permanently and not re-sort the order every time CRON runs.
                      Please see attached file "Rules order before Cron" I would like all the rules to stay static in that order and not resort.

                      I am not sure but I am assuming by reading all of the above posts that I need to manage this "options" please see attached image properly to get that desired affect.
                      However I have a second firewall that DOES NOT behave like this with the same settings so I am confused please help before I go mad.

                      My desired affect would be this.
                      Have a list of rules that are static and do not move and I manually manage them, and the pfBNG does its auto update thing.

                      Thank you in advance I have been waiting for some one to have the same symptoms as I do.

                      ![Rules order before Cron.JPG](/public/imported_attachments/1/Rules order before Cron.JPG)
                      ![Rules order before Cron.JPG_thumb](/public/imported_attachments/1/Rules order before Cron.JPG_thumb)
                      Options.JPG
                      Options.JPG_thumb

                      1 Reply Last reply Reply Quote 0
                      • W
                        wcrowder
                        last edited by

                        @dougc420:

                        Hello
                        I have been dealing with this issue for some time now.
                        Two firewalls with default install and settings with different behavior.

                        I have some simply allow rules above the pfBNG rules to allow my remote travelers working from random countries around the world to be able to hit the exchange OWA https site on 443.

                        I have the same thing, use the option:

                        | pfSense Pass/Match | pfB_Pass/Match | pfB_Block/Reject |

                        Works for me, but I'm using 2.0, should work on the last version also.

                        1 Reply Last reply Reply Quote 0
                        • D
                          doug.claxton
                          last edited by

                          Wonderful I will test that in my LAB first thank you for that.

                          What is your setting for the "floating rules" enabled or disabled?

                          1 Reply Last reply Reply Quote 0
                          • W
                            wcrowder
                            last edited by

                            @dougc420:

                            Wonderful I will test that in my LAB first thank you for that.

                            What is your setting for the "floating rules" enabled or disabled?

                            Should work the same for both, I run floating. I have tested on both in the past. If I remember correctly, BBCan177 fixed this weeks ago, I do not know if it was updated in the 1.x series, it has been awhile since I used it. I believe it was added in an earlier pull to the 1.x branch, I can't say for sure.  :)

                            https://forum.pfsense.org/index.php?topic=99987.msg562116#msg562116

                            1 Reply Last reply Reply Quote 0
                            • D
                              doug.claxton
                              last edited by

                              Thank you again for your support.
                              I wish this was an easy fix really i do.
                              However after Cron ran the same results. I will attach screen shots.
                              The rules resort and my priority is changed blocking my traveler from port 443

                              ![Rules order before Cron.JPG](/public/imported_attachments/1/Rules order before Cron.JPG)
                              ![Rules order before Cron.JPG_thumb](/public/imported_attachments/1/Rules order before Cron.JPG_thumb)
                              ![Rules order after Cron.JPG](/public/imported_attachments/1/Rules order after Cron.JPG)
                              ![Rules order after Cron.JPG_thumb](/public/imported_attachments/1/Rules order after Cron.JPG_thumb)
                              ![Options before recommeded change.JPG](/public/imported_attachments/1/Options before recommeded change.JPG)
                              ![Options before recommeded change.JPG_thumb](/public/imported_attachments/1/Options before recommeded change.JPG_thumb)
                              ![Options after recommended change.JPG](/public/imported_attachments/1/Options after recommended change.JPG)
                              ![Options after recommended change.JPG_thumb](/public/imported_attachments/1/Options after recommended change.JPG_thumb)

                              1 Reply Last reply Reply Quote 0
                              • D
                                doktornotor Banned
                                last edited by

                                @dougc420:

                                I wish this was an easy fix really i do.

                                It would be extremely easy to do if you designed things in a SANE way. Why the HECK are you blocking the ENTIRE WORLD via pfBNG?! Allow what you need, the rest is blocked by default. Been said like zillion times. Here we go again. Hundreds of thousands of CIDRs in firewall rules, totally useless. Absurd. Please, get some basic understanding of default deny before deploying similar WTF setups.

                                1 Reply Last reply Reply Quote 0
                                • D
                                  doug.claxton
                                  last edited by

                                  I actually do have the country's unblocked that I require and have taken the time to work out our desired flow of traffic. I do wish to globally block all traffic in the world to our exchange on port 25 and ONLY allow it to talk to our hosted mail providers. It is peace of mind to know that I do not need to worry about that.

                                  This is a preferred configuration for us however we would like to be able to manage our rules accordingly and not have to log in every day and re sort them.

                                  The odd thing is that the behavior on a like firewall is different. Firewall two with the same config the rules stay but on this firewall the rules resort after Crond.
                                  What am I missing here?

                                  1 Reply Last reply Reply Quote 0
                                  • BBcan177B
                                    BBcan177 Moderator
                                    last edited by

                                    Hi Doug,

                                    The "Rule Order" that you selected ordered the rules as per the Order you selected. I think you want to use the second option as the manual pass rules that you created are 'pfSense Pass' rules not 'pfBNG pass' rules.

                                    Please see the following links for what Dok has mentioned:
                                    https://forum.pfsense.org/index.php?topic=86212.msg548324#msg548324
                                    https://forum.pfsense.org/index.php?topic=86212.msg553921#msg553921
                                    https://forum.pfsense.org/index.php?topic=102071.0

                                    "Experience is something you don't get until just after you need it."

                                    Website: http://pfBlockerNG.com
                                    Twitter: @BBcan177  #pfBlockerNG
                                    Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                                    1 Reply Last reply Reply Quote 0
                                    • D
                                      doug.claxton
                                      last edited by

                                      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 Reply Last reply Reply Quote 0
                                      • F
                                        fredrikpf
                                        last edited by

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

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.