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

    Block LAN to Guest SSID

    Scheduled Pinned Locked Moved Wireless
    5 Posts 4 Posters 2.1k 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.
    • F
      FTX
      last edited by

      Hello!

      I was wondering if is possible to block Guest's SSID access to LAN not to Internet using VLANs in this kind of configuration?

      or should I use separates LAN interfaces to separate the traffic?

      In VLANs situation we can decrease number of Access Points from 2 to 1.

      What is your opinion?  :o

      1 Reply Last reply Reply Quote 0
      • M
        Mr. Jingles
        last edited by

        Nice picture  ;D

        I think in order to phave pfSense block any traffic between LAN/VLAN you will need to setup VLAN's in pfSense first. Then you can set up a rule for VLANGUESTS to go out to the internet, yet block it accessing LAN.

        I have VLAN's on 1 NIC, I do recall the wise men in here said each VLAN on it's own interface is most secure, but I don't have more NICs.

        6 and a half billion people know that they are stupid, agressive, lower life forms.

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

          Is your switch layer 3 or layer 2?

          If layer 2, then you must already have tagged VLAN interfaces on pfSense from the switch right?

          Yes, it's possible.

          Doesn't matter if it's on a separate interface or a VLAN tagged interface.  You'd do something like this:

          alias local_subnets
          VLAN1 CIDR
          VLAN2 CIDR
          VLAN3 CIDR
          VLAN4 CIDR
          GUEST CIDR

          Then on the interface for the guest VLAN:
          reject ip any source GUEST network dest local_subnets any
          reject ip any source GUEST network dest WAN address any
          reject ip any source GUEST network dest WAN2 address any
          pass ip any source GUEST network dest any any

          Above all those reject rules you would pass specific things like pinging the GUEST address, DNS, etc.

          Chattanooga, Tennessee, USA
          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
          Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

            I think most people get into VLAN security issues when they continue to used the native VLAN (untagged traffic on a VLAN trunk (tagged) port.)  I would not continue using VLAN1.  I would do something like VLAN101, VLAN102, VLAN103, VLAN104, and use em0_vlan101, em0_vlan102, em0_vlan103, em0_vlan104, leaving em0 unassigned.  Then, in the switch, if you can't outright disable the native vlan on your trunk port (have it simply discard untagged traffic it receives), set it to an unused VLAN.

            I will usually use tagged pfSense interfaces and a tagged switchport even if the interface has only one VLAN on it.  That way adding VLANs in the future is pretty much hitless.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • ?
              Guest
              last edited by

              From me on top please enable WiFi client isolation for the VLANs where the both WLANs are in.
              So no one can snoop on the neighbors WiFi device.

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