This article describes how to achieve wireless clients isolation:
.
.
Q: Is it possible to isolate any client (Wireless AND Wired) from each other ?
1 Like
Yes this is possible but not so easy as for wireless...
Do you want isolate only wireless clients from lan or also every lan client?
The situation is as such:
I have some wired devices (TV, Raspberry) and some wireless ones (Laptops, Mobiles etc.)
I never access one device from another device - all they need is Internet Access.
My understanding is that the default firewall rules allow for all devices to communicate between each other.
That is a bit problematic, as:
a) If one device would become infected by a virus or other nuisance, it may spread throughout the network. Configuring firewalls on each and every device is cumbersome and error prone.
b) Once in a while I have guests. They should not be able to access other devices on the network (I know, I could set up a Guest network for that case, but this is also not so straightforward).
So it seems to me that LEDE is missing a simple option "Isolate all clients on this network", or similar. And in fact, that for improved security, this option should be enabled in the default installation.
Complete isolation on a wired network typically requires one switch port and cable per device. Ethernet frames over the wire aren't encrypted the way 802.11 packets are. Enterprise-grade switches manage port access and authorization with 802.1X or the like.
Between hardware limitations in the switches and the general pain to manage, it's hard for me to imagine it being popular.
On the other hand, I've been keeping each brand of IoT device on its own SSID and VLAN for years now, each with their own DNS and firewall rules.
Yes, obviously we are speaking about isolation of each switch port, rather than each device (apologies for my shortcut).
Typical home routers will have 2-8 such switch ports.
So is it possible to ensure that they are isolated from each other ?
Yes, putting each port on its own VLAN isolates them in the switch. Its easiest if each has its own subnet assigned.
From there they can be trunked to another switch (with VLAN tagging), services supplied by the OpenWRT box, and/or routed.
- VLAN-to-VLAN is generally a "forward" operation
- VLAN-to-Internet is generally a "forward" operation
- VLAN-to-service is generally an "input" or "output" operation
- VLAN-to-wireless is generally a bridge operation within the OpenWRT box
- VLAN to trunk generally is handled by the switch itself and doesn't "touch" the OpenWRT interfaces
DHCP, usually DNS, and often NTP are "required" for each isolated network.
dnsmasq is not a sophisticated server, so you'll likely need one instance running with its own config for each VLAN's subnet. When I ran DNS on OpenWRT, I personally found unbound easier to configure. Today, I'd also use a single instance of kea for DHCP (again, ease of configuration for multiple subnets), but I don't know that there is a package for it yet.
NTP is less troublesome as time is time is time, so, unless you've got some wacky things going on, the same server can provide NTP to all the subnets.
1 Like
be aware that each ssid eats about 1% of available airtime (on its channel) so this will exceberate the crowded spectrum problem.
setting option isolate on your guest/iot wifi will probably be sufficient.
in addition to the vlan/subnet isolation on wired, a one-way software bridge with
ebtables -A FORWARD --logical-in br-guest1 -j DROP
will allow for the use of the same subnet and isolate the bridge members from each other.
1 Like
Re-using a single SSID makes it challenging in multiple ways, as, at least with PSK2 authentication, you end up giving out the only password to everything and you can't restrict the DHCP address issued without knowing the MAC address (or other client parameters) in advance. Address restriction does some to limit rogue activity, probably most of it, but is far from robust against more sophisticated actors.
Yes, "beacon pollution" can be significant, especially if you haven't disabled legacy rates and "forced" 802.11n as your minimal supported standard (at least force 802.11g).
You can see what rates your attached devices are using in the LuCI interface (or through iw dev <dev> station dump). From the rates used, you can generally determine if they are using 802.11n. ("Inactive" links may show a very slow rate in one or both directions.)
One well-written resource on this is
1 Like
Thanks.
That requires the creation of a guest network (not foreseen in the default distro) and does not take care of the issue I mentioned with regards to protecting devices against viruses etc. by default.
I was hoping for an option attached to the firewall zone for example (ie "Isolate clients in this zone"). But maybe that is not technically doable.
Shouldn't setting the Forward option in the untrusted zone to "reject" do exactly this? Also set "input" to "reject" so virus infected devices within that zone also cannot access the router. Make sure you create a rule for DHCP and DNS. Keep "output" to "accept".
That's hard to specify generically. As specific examples from my home:
- TP-Link switches
- Allow port 9999 TCP from my host that manages them
- Provide DHCP and NTP; for DNS, return local NTP server for known set of NTP servers it tries, NXDOMAIN for any other queries
- Block everything else (they "phone home" no matter how you set them)
- Lutron SmartBridge PRO
- Allow telnet from my host that manages it
- Allow outbound connections to encrypted MQTT broker "somewhere in the cloud"
- Provide DHCP, DNS, and access to remote NTP
- Pi-esque controllers
- Allow encrypted MQTT connection to my local broker
- Allow ssh access over my management VLAN
- Allow outbound HTTP-S connections (for software updates)
- Allow syslog over TLS to my log server
- Provide DHCP, DNS, NTP
- Microcontrollers
- Allow encrypted MQTT connections to my local broker
- Provide DHCP, restricted DNS, broadcast NTP
While an "isolate fully" button might cover some use cases, what do you do when you manage the device through your phone, and does its app communicate directly, or through some kind of remote service. If the latter, what is that service and what has to be let through and in what direction?
I agree that an easy way to set up an isolated guest network through LuCI would be appreciated by many.
Communications between ports on the switch is not subject to firewall rules I believe, so that wouldn't be sufficient. You need to go through the length and complexities of creating VLANs to achieve full isolation of all LAN clients.
If I take my TV and my phone for example, I do not have the possibility to configure a firewall on them. It is possible to do, but not straightforward, on the software I run on my raspberry.
So an option that would take care of all the nitty gritty on the router would really be helpful.
Maybe a security-oriented custom build could take care of that ?
How about using ebtables ?
1 Like
i think you could tag each switchport with a different vlan and then bridge those vlan's together again in software ...
and use ebtables ...
1 Like
It isn't as hard as you make it out to be. Just put each and every port on it's own VLAN (tagged on CPU & untagged on one port per VLAN) and bridge them all together. Put the bridge in the untrusted firewall zone with "reject" on the forward rules and you should be done 
1 Like
Actually, I would like to get back to this. Is the above thing I mentioned correct? Because I need a similar setup, and did the above thing as described. However, my clients within my untrusted zone are still able to reach each other despite the forward rule being set to "reject".
tcpdump on the router shows that the packets successfully hit the router CPU, and aren't just forwarded through the switch. However, the firewall does not reject said packets. Any firewall gurus around that know why these packets are being forwarded regardless? Is it even possible to reject forwards on a bridge interface? Or do I need to setup 3 different networks with their own subnet (cumbersome!) in order to achieve full client isolation?
Found this good article about bridge isolation:
Unfortunately, that option does not exist on the bridge interface configured on the Lede router. Additionally, while this would work if the option was present, I still do not understand why the forward reject rule is not triggering for me on the firewall.
That rule rejects forwarding between interfaces within the same firewall zone; it does not apply to the clients on the same interface. A bridge that nterface is a single interface.
1 Like