Navigation

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

    Multiple objects in a single field - without aliases

    Firewalling
    3
    6
    1714
    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.
    • T
      triskelion last edited by

      Pre: I've searched for any previous mention of this, but it's a bit of a vague topic, also I'm not sure if this is on the radar or if I've completely overlooked this functionality.

      I'm using pfSense to enforce a zone based security model and have a rule base with close to 150 rules. What I would like is the functionality to have multiple objects in the source, destination and port fields on a number of rules.

      Now I know I can uses an alias to accomplish this, and I do use aliases extensively, though the situation arises where I need to, for example, remove specific access from one host alias to another host alias on a specific port.

      HR =
      172.16.12.1
      172.16.12.2
      172.16.12.3

      Eng =
      172.31.0.1
      172.31.0.2
      172.31.0.3

      Mgmt =
      22
      3389

      | SRC | DST | PRT |
      | HR | Eng | Mgmt |

      Say 172.16.12.3 in HR no longer needs this access, in this situation I can:

      • Remove the host from the HR alias which then denies it access on all other rules that alias is used in(10+).

      • Add a block rule above that rule specifically for this host

      • Create a new HR alias for that single rule not including that host.

      Are there any cleaner ways to do this? I ask because this requirement pops up quite regularly.

      Is there a technical limitation or complexity that makes it difficult to have multiple objects per field?

      1 Reply Last reply Reply Quote 0
      • M
        Metu69salemi last edited by

        You could use that one ip-address itself with blocking rule just before the allowing rule. or create alias HR-blocked and HR

        like this:
        HR-blocked: 172.16.12.3
        HR: 172.16.12.2, 172.16.12.3

        block: hr-blocked to eng
        allow: hr to eng
        allow: hr to internet or whatever

        1 Reply Last reply Reply Quote 0
        • T
          triskelion last edited by

          @Metu69salemi:

          You could use that one ip-address itself with blocking rule just before the allowing rule. or create alias HR-blocked and HR

          like this:
          HR-blocked: 172.16.12.3
          HR: 172.16.12.2, 172.16.12.3

          block: hr-blocked to eng
          allow: hr to eng
          allow: hr to internet or whatever

          @triskelion:

          • Remove the host from the HR alias which then denies it access on all other rules that alias is used in(10+).

          • Add a block rule above that rule specifically for this host

          • Create a new HR alias for that single rule not including that host.

          I was looking for a cleaner way, without having to add whole new rules, for example if I wanted to block multiple ports for that host, I'd need to create a new alias for those ports, or create x rules to cover each port.

          There are also other situations it would be useful to have multiple objects in a field.

          1 Reply Last reply Reply Quote 0
          • M
            Metu69salemi last edited by

            I understand you. but i don't know is it possible to do what you want

            1 Reply Last reply Reply Quote 0
            • GruensFroeschli
              GruensFroeschli last edited by

              You can use aliases in aliases with 2.0. Although i'm not sure that helps in this situation.
              What i would do is have an alias for each type of service you want to provide.
              Basically your approach 3 "Create a new HR alias for that single rule not including that host."
              But if you have 10 rules using a single alias, –> 10 aliases with each for a single rule.

              1 Reply Last reply Reply Quote 0
              • T
                triskelion last edited by

                @GruensFroeschli:

                You can use aliases in aliases with 2.0. Although i'm not sure that helps in this situation.
                What i would do is have an alias for each type of service you want to provide.
                Basically your approach 3 "Create a new HR alias for that single rule not including that host."
                But if you have 10 rules using a single alias, –> 10 aliases with each for a single rule.

                Thanks, I think the simplest way so far is just a block rule above, but any way it goes there are bound to be situations where if you heavily rely on groups, like I do, a simple exclusion becomes non-trivial.

                Also I leverage groups quite heavily, some nested 3-4 times. I've set up a policy framework where all zone flows are inherited the instant a subnet or host is added to a specific single groups.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post

                Products

                • Platform Overview
                • TNSR
                • pfSense
                • Appliances

                Services

                • Training
                • Professional Services

                Support

                • Subscription Plans
                • Contact Support
                • Product Lifecycle
                • Documentation

                News

                • Media Coverage
                • Press
                • Events

                Resources

                • Blog
                • FAQ
                • Find a Partner
                • Resource Library
                • Security Information

                Company

                • About Us
                • Careers
                • Partners
                • Contact Us
                • Legal
                Our Mission

                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                Subscribe to our Newsletter

                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                © 2021 Rubicon Communications, LLC | Privacy Policy