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

    Firewall rules moving position

    Scheduled Pinned Locked Moved Firewalling
    11 Posts 4 Posters 5.6k 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.
    • R
      RandyN
      last edited by

      Hi all! It's been awhile. I tired to search this up but did not have much success so if there is a thread on this please point me to it.

      For one rule I want to allow Blizzard Entertainment traffic so I have an alias with about 74 CIDR's for their servers. I have the alias at the top of the rules and it all works but for some reason the rules that allow traffic get moved to the bottom of the rules list  and then Blizz traffic gets denied. Also a rule gets created on the WAN side to block the Blizzard alias traffic.

      I've tried re-arranging the order, clearing the firewall logs and re-booting. No luck the problem persists.

      Any suggestions?

      TIA,
      Randy

      Running Release 2.1
      squid3-dev
      squidGuard-devel
      pfblocker

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

        Do you mean that the alias list has it at the top, but the firewall rules do not? Rules do not automatically move or get created. That is usually intentional. Aliases are listed in alphabetical/numerical order, but order doesn't matter there.
        Do you have snort or dansguardian running?

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by

          I notice you use pfblocker - that will put its block rules at the top automagically. If you are using pfblocker to block big chunks of stuff, then those rules might be causing you pain. After you reboot, or some other reason for pfblocker to regenerate its rules, the pfblocker rules will head back to the top.
          You can get pfblocker to just generate aliases with all the blocked IPs, then you put rules in yourself to do the blocking, using the aliases, and put them wherever you need in the rule set.

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

          1 Reply Last reply Reply Quote 0
          • R
            RandyN
            last edited by

            pfblocker is running a list from iblocklist.com (as an alias). In this case it is the Level 1 list but this blocks Blizzard Entertainment. I created another alias (allowblizz) using the Blizzard Entertainment list from iblocklist.com (about 74 CIDRs in all).

            The Firewall–Rules page indicates rules are evaluated on a first -match basis so I put the allowblizz alias at the top of the rule list on the LAN tab (Source: LAN Subnet | Destination:pfblockerallowblizz)

            This works but the allow alias (allowblizz) keeps getting moved to the bottom of the rules list and then Blizzard gets blocked.

            @phil.davis:

            … You can get pfblocker to just generate aliases with all the blocked IPs, then you put rules in yourself to do the blocking, using the aliases, and put them wherever you need in the rule set.

            @phil.davis - If I understand you correctly I did that but the rule set changes order due to some kind of reset(?)

            @podilarius:

            Do you mean that the alias list has it at the top, but the firewall rules do not? Rules do not automatically move or get created. That is usually intentional. Aliases are listed in alphabetical/numerical order, but order doesn't matter there.
            Do you have snort or dansguardian running?

            @podilarius - it's just the order of the aliases under the Firewall Rules tab that changes. I set them up on a first-match basis but the order doesn't 'stick' and the pass rule moves to the bottom of the list after all the block rule.

            I recently setup squid3-dev (3.3.10) & squidGuard-dev (1.5_1 beta) this is on Release 2.1 because I am interested in ad blocking, cache proxy and clamav integration.

            I hope I made things a little clearer.

            Cheers,
            RandyN

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

              I'd hazard to say NOT making the allow list an alias will avoid this issue in the first place, since it's gonna stick to the top. Other than that, never seen your issue, when you make the lists an "alias only", then don't move anywhere in the ruleset, period. Maybe get rid of the proxies temporarily and see again.

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

                What Phil is saying that on reboot and pfblocker updates, the blocker rule gets moved to the top. Disable pfBlocker temporarily and see if your rules move around or not.

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

                  @podilarius:

                  What Phil is saying that on reboot and pfblocker updates, the blocker rule gets moved to the top.

                  Not with "alias only".

                  1 Reply Last reply Reply Quote 0
                  • P
                    phil.davis
                    last edited by

                    @doktornotor:

                    @podilarius:

                    What Phil is saying that on reboot and pfblocker updates, the blocker rule gets moved to the top.

                    Not with "alias only".
                    [/quote
                    Yes, what we are all trying to say is to set the list in pfBlocker to make only the alias (i.e. pfBlocker will not automagically add the rule).
                    Then go to Firewall->Rules and add a rule where you need it (down the list a bit) to block stuff from that pfBlocker-generated block-list alias.
                    Now pfBlocker will not mess with the rule - it has been told to just generate the alias, and that you the human are dealing with making and placing the rule you want.

                    As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                    If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                    1 Reply Last reply Reply Quote 0
                    • R
                      RandyN
                      last edited by

                      Ok…the light bulb has turned on!

                      List Action: Set this to "Alias only" and now the rules stick. Thank you!

                      Now does anyone have any ideas as to why I am not seeing a packet count increase in the pfblocker widget?

                      The # of CIDRs is displayed. Packets  is blank.  Status shows a green up arrow.

                      Thanks folks!
                      RandyN

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

                        @RandyN:

                        Now does anyone have any ideas as to why I am not seeing a packet count increase in the pfblocker widget?

                        Because there's no such feature implemented with "alias only". The code obviously has no idea about your rule description, so there's nothing to count.

                        1 Reply Last reply Reply Quote 0
                        • R
                          RandyN
                          last edited by

                          Well that was easy….thanks for the help, folks!

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