Navigation

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

    Permit from VLAN subnet to WAN only

    Firewalling
    7
    10
    3741
    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.
    • S
      sammy2ooo last edited by

      I have created a new VLAN interface. Now I would like to (exclusively) allow traffic coming from this subnet to the WAN and not to any other subnets like WLAN or LAN.

      Does this require a "reject" rule on each interface? I was expecting a rule like "permit any traffic coming from iface VLAN_IFACE to WAN_IFACE"

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

        I have the same issue but I have six VLANs rather than one. I need to allow outbound internet from one of these VLANs for WAN only on ports 80 and 443. (i.e. no access to the other VLANs). The only way I can make it work is to use an any on the Destination which means that I need 12 rules to stop this one VLAN from accessing all the others.

        Is there any way of defining a destination as an interface rather than a network address range or is there a way that I can combine multiple Destination nets into one blocking rule.

        If needs be I am happy to edit the XML config file directly if necessary rather than use the GUI.

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

          @sammy2ooo:

          Does this require a "reject" rule on each interface? I was expecting a rule like "permit any traffic coming from iface VLAN_IFACE to WAN_IFACE"

          A reject rule on each interface doesn't help because traffic is ONLY filtered when it enters the firewall (e.g. the incoming interface).
          Since WAN is defined as anything but local LANs you cannot easily define the allowed range. The denied range is way easier, then allow the rest. Rules are always processed from top to bottom. The first rule that fits will be executed and the following ones are ignored.

          With this in mind do the following:
          Goto  Firewall|Aliases  and create an alias holding all local subnets.

          Now go to  Firewall|Rules  and select the VLAN interface in question (or one after another).
          Add a rule to permit traffic to this subnet (to be able to get DHCP, DNS etc. from your pfSense. Not sure if this is really needed but doesn't hurt).
          Add a rule below this one and block or reject traffic to the alias of all subnets you created earlier.
          Add a third rule below this one to allow traffic to the rest (e.g. WAN for internet etc.)

          You can copy those rules to other interfaces (or VLANs) by hitting the "+" sign next to the rule and change the interface accordingly.
          That's it.

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

            Thanks Chris, that is a great suggestion. I've also setup an Alias for the port set (80 and 443) which has enabled me to reduce these 12 rules down to 2 which makes it manageable in the longer term.

            1 Reply Last reply Reply Quote 0
            • G
              GroundX last edited by

              I've created an alias for all RFC1918 addresses. Comes in VERY handy in some situations (BYOD and Guest net for example :) )

              1 Reply Last reply Reply Quote 0
              • S
                stickybit last edited by

                @jahonix:

                @sammy2ooo:

                Does this require a "reject" rule on each interface? I was expecting a rule like "permit any traffic coming from iface VLAN_IFACE to WAN_IFACE"

                A reject rule on each interface doesn't help because traffic is ONLY filtered when it enters the firewall (e.g. the incoming interface).
                Since WAN is defined as anything but local LANs you cannot easily define the allowed range. The denied range is way easier, then allow the rest. Rules are always processed from top to bottom. The first rule that fits will be executed and the following ones are ignored.

                With this in mind do the following:
                Goto  Firewall|Aliases  and create an alias holding all local subnets.

                Now go to  Firewall|Rules  and select the VLAN interface in question (or one after another).
                Add a rule to permit traffic to this subnet (to be able to get DHCP, DNS etc. from your pfSense. Not sure if this is really needed but doesn't hurt).
                Add a rule below this one and block or reject traffic to the alias of all subnets you created earlier.
                Add a third rule below this one to allow traffic to the rest (e.g. WAN for internet etc.)

                You can copy those rules to other interfaces (or VLANs) by hitting the "+" sign next to the rule and change the interface accordingly.
                That's it.

                Hello,

                Is this still the way it goes?
                Or is it possible to add only one permit rule with source net vlan to destination net wan?

                Regards

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

                  Sorry to drudge this up again.  Jahonix's solution worked great for me, but like stickybit i'm curious if this is still the best way to accomplish this?

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

                    @stickybit:

                    permit rule with source net vlan to destination net wan?

                    There is no destination net "WAN" describing the "rest of the internet".
                    It would point to your WAN interface's public IP to which you surely do not want to connect to.

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

                      @diablo266:

                      if this is still the best way to accomplish this?

                      Yes as far as the rule set is concerned.
                      No for multiple interfaces. Use "Floating rules" for this now. https://doc.pfsense.org/index.php/What_are_Floating_Rules

                      1 Reply Last reply Reply Quote 0
                      • Derelict
                        Derelict LAYER 8 Netgate last edited by

                        Don't forget to block connections to This Firewall too.  Else they can get at your webgui on the WAN address (if it's not RFC1918)

                        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