Guest LAN client isolation possible?
-
What can I do on the Guest LAN interface I set up to isolate clients from one another?
I have figured out that this rule is ineffective:
because in-subnet communication does not reach the pfSense appliance and therefore its firewall.
-
@dominikhoffmann said in Guest LAN client isolation possible?:
What can I do on the Guest LAN interface I set up to isolate clients from one another?
I have figured out that this rule is ineffective:
because in-subnet communication does not reach the pfSense appliance and therefore its firewall.
You cannot do anything on your firewall about client to client talk within the same subnet/interface. That traffic never reaches your firewall - that’s how IP works, and has nothing to do with pfSense.
To isolate them from each other you need a switch/Accesspoint that supports either role-based networking or private-VLAN. That’s because isolation has to be done on layer 2 (on the network layer created by your switch/AP)
-
@dominikhoffmann Some APs will isolate that, for instance eero supports guest WiFi in eero's bridge mode, and when I tested it isolates the devices even while bridging them.
Another option is to use a separate interface on pfSense, use a second AP and put it on that interface. Then firewall rules do apply between interfaces. Is your "guest VLAN" not a separate interface?
(also that block rule has states so something is hitting it)
-
@steveits said in Guest LAN client isolation possible?:
(also that block rule has states so something is hitting it)
Could be something trying to talk to pfsense IP, or broadcast address - but blocks rules shouldn't ever have a "state" ;) So that is odd for sure. maybe he adjusted the rule from allow to block? And there were states from when it was allow?
-
@steveits: My guest LAN has a separate interface and a VLAN that is configured in the PoE switch and the UniFi OS console managing my APs.
-
@johnpoz: I do not know, how that might have happened.
-
@johnpoz said in Guest LAN client isolation possible?:
but blocks rules shouldn't ever have a "state" ;) So that is odd for sure. maybe he adjusted the rule from allow to block? And there were states from when it was allow?
Makes sense, with coffee. :) Open states would allow traffic to "bypass" the block rule.
@DominikHoffmann is that rule with both the source and destination as GUESTWIFIVLAN Net? That shouldn't make sense either. On a separate interface one would want rules something like:
allow from VLAN to "This Firewall" DNS
block from VLAN to "This Firewall" (blocks connecting to pfSense 443, etc. on any interface)
block from VLAN to LAN Net
allow from VLAN to any -
Late post but here's hoping for the best...
An option not discussed could be considered a hack, but it works surprisingly well.
Have the DHCP server hand out a /32 subnet mask to each device. This forces all traffic to the default GW offered by DHCP.
See this thread if you don't think it works (I didn't at first).
https://www.reddit.com/r/networking/comments/j37xy6/microsegmentation_intravlan_segmentation_dhcp/There's even a security startup based on this concept called Airgap (airgap.io).
Implementing this on pfsense, as it is today would be a hassle at best, but it would be awesome to have it as an option. Thoughts on how to submit a feature request?
Preemptive: Thoughts other than "it doesn't work because switches and L2" please. I thought the same thing, then I tried Airgap and it does work, even for IoT devices.
-
@Okijames: I like that idea, in principle. Of course, it could be overridden by the device by simply setting its subnet mask to /16 and poking around the other IP addresses in the subnet.
If a discussion ensued, I think, I could learn a lot. The whole Layer 1/Layer 2/Layer 3 thing is not entirely intuitive to me, yet.
-
@DominikHoffmann Not really because devices with a /32 mask won't accept L3 traffic from anything outside of their single IP "subnet", with the odd exception of the GW address. At most, your /16 device can send broadcast and multicast at L2.
-
The typical of the mill DD-WRT device has this option :
which is just perfect for 'public' networks : all connected devices - to this AP - can only talk to the gateway.
Be warned : things get trickier when you have more the one AP in the network. My AP's support ebtables - some sort of iptables like firewall, but for mac addresses.