Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    FW rules and VLAN's

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 4 Posters 2.7k 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.
    • C Offline
      cafcwest
      last edited by

      The pfSense box is setup with the WAN, LAN, a number of VLAN's, and virtual IP’s for the remainder of my static IP addresses.

      I like to be consistent in numbering the VLAN after the variable octet (in this case, the third octet).  As many switches do not allow much in the way of configuration on VLAN 1, I am abandoning it.  As such, I am using the following:

      WAN – public static IP
      LAN – 10.10.1.1
      VLAN10 – 10.10.10.1 (Internal Data)
      VLAN50 – 10.10.50.1 (Tenant)
      VLAN80 – 10.10.80.1 (Tenant)
      VLAN90 – 10.10.90.1 (Guest wireless)
      VLAN99 – 10.10.99.1 (management)

      LAN port is uplinked to a L2 switch, that port has trunking configured for all of my VLAN’s.

      Question 1: 
      As I have the LAN (which I am not really using), as well as all these VLAN’s on a single physical interface, should I just remove the LAN interface in pfSense all together?  Reason I ask this, because of the following thread(second post), it was mentioned not to mix untagged (which, would be anything on my LAN scope, which I’m not really using though) and my VLAN’s (which of course, are tagged).
      http://forum.pfsense.org/index.php?topic=34739.0

      Question 2:
      Firewall rules have been put into place between VLAN10 and VLAN99 and they work as expected.  These VLAN’s will either have statically addressed clients, or be served by an external DHCP source.
      VLAN50, 80, and 90 have been setup to be DHCP served by pfSense.  When I connect clients to the appropriately configured ports, they are served IP address.

      However, for ALL VLAN’s, not only do I not have access to the internet, I can’t even ping the gateway.  I have not messed with outbound NAT or anything like that, so I’m not sure why this behavior is occurring.  By design, would a new VLAN be completely sandboxed unless given firewall rules out?
      For example, I can put in a “any VLAN50 net –-> any” rule, and of course this fixes the issue, but that isn’t a fix – just a test.
      Trying to word my question properly;  If I do need to put firewall rules into place to allow access out to the internet, what is the appropriate destination type and/or address??  Or am I experiencing behavior outside of the expected?

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

        Question 1: LAN on the default interface is using VLAN 1, the default VLAN. You can choose to remove it if you like. I would assign it to a MGMT VLAN instead of removing LAN. Something like VLAN101.

        Question 2: Yes, only LAN has a rule to allow traffic to the internet by default. This is true for any new interface, be it VLAN or NIC. You are going to have to create a rule to allow traffic out. Remember that the default action is to block. So if there is no rule …......

        1 Reply Last reply Reply Quote 0
        • C Offline
          cafcwest
          last edited by

          Question 2: Yes, only LAN has a rule to allow traffic to the internet by default. This is true for any new interface, be it VLAN or NIC. You are going to have to create a rule to allow traffic out. Remember that the default action is to block. So if there is no rule …......

          So what is the appropriate destination that I'd specify in the rule to allow traffic to the internet?  WAN net?

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

            Usually is going to be something like OPT1 Net -> Any on any protocol and port. If you don't want opt2 to access opt1 or LAN, then create an alias like opt2inet that has the LAN and OPT1 subnets listed. then it would be allow opt1 net -> !opt2inet.

            1 Reply Last reply Reply Quote 0
            • C Offline
              cafcwest
              last edited by

              I thank you for your assistance, but setting up an alias really doesn't make sense to me honestly.

              At a high level, I understand the default action is to deny traffic unless a rule is specifically allowing it.  So each VLAN that should have access to another VLAN is configured with an appropriate rule.  VLAN's that should be segregated (no access to any other VLAN) of course do not have such a rule.  But the part I am missing is how I get these VLAN's out to the internet.  I would think that this'd just be "WAN" or something along those lines.  This is the root of my confusion.

              1 Reply Last reply Reply Quote 0
              • johnpozJ Offline
                johnpoz LAYER 8 Global Moderator
                last edited by

                It would be easiest to create a alias with all your vlan segments in it.. Then create a rule on your vlan you want to allow internet for any !vlanalias – so it will allow traffic as long as this traffic is not destined for any of your vlans.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 26.03 | Lab VMs 2.8.1, 26.03

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

                  Or if you don't want to write every vlan interface subnet on alias, just use 10.0.0.0/8.

                  With Aliases you can have much more like "nested" rules and subnets on rules

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