You can make these options survive a reboot by setting these in sysctl.
Now packets traveling from one VLAN to another VLAN through the bridge interface are subject to iptables rules, and hence using a reject rule on the default forward chain will effectively isolate the clients Hopefully this is helpful information for other people as well!
Perhaps "wrapping it up" as an optional "package" for those that desire the functionality might be a better course of action.
I'd argue against it being "default" for a few reasons:
Adds a requirement for new modules and would increase the size of the LuCI install; many are already challenged by flash-size constraints (for many, every kB "counts")
Potentially increases memory consumption; a challenge for memory-constrained devices
Increases CPU consumption
"Upgrade" considerations; would unexpectedly "break" existing configurations that aren't expecting client-to-client isolation (one example is home-automation devices that expect that a cell-phone app can directly communicate with devices, including broadcast discovery)
The LAN zone has the default forward chain set to accept, so even with this enabled clients are still able to reach each other. This modification simply applies netfilter/iptables rules on traffic through the bridge. It still needs a firewall rule to actually isolate the clients. I do agree with the rest of your points.
A nice LuCi wrapper would be very welcome as an optional thing. I don't have time for this now, but this could be something I will look into in the future. But others are also free to pick this up
I just changed my untrusted zone's forward from reject to accept, and clients were instantly able to reach each other again. Changing it back to reject, and they weren't able to reach each other anymore.
I am making VLANs for each device. All associated with the same bridge, same subnet, same DHCP server, but isolated via iptables via above configuration. So I am not making a bridge for each device. Just one bridge.
I know this topic is old, but your post seems to be the best response to this problem in all forums, and I have a couple of questions regarding this.
First, is there now a luci package to get packets from a certain bridge to be subject to iptables rules?
Secondly, how can I add a sysctl rule for only one bridge? In my /etc/sysctl.conf file I already have :
# disable bridge firewalling by default
net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
The new rule for my guest network should be (?) : net.bridge.bridge-nf-call-iptables.guest=1
Should I delete the 3 lines already inserted in my /etc/sysctl.conf file? I guess not.
I will also have to install the kmod-br-netfilter package.
Not sure either. When I played around back in those days I simply changed those rules all to 1. But as you might imagine this means that all bridges are subject to iptables processing. While this isn't a problem, since you can simply accept all these packets, I found a VERY large performance hit on all traffic that had to go through the bridge.
The way I solved it, was to install the ebtables package which allows you to create firewall at the layer 2 level, one level above IP traffic. In order to get isolation on a bridge, I would simply add the following custom rule in Luci's Firewall's custom rule page:
ebtables -A FORWARD --logical-in br-untrusted -j DROP
Where the br-untrusted part is the name of the bridge where you want to enable isolation.
I ended up using the following. I have one router (router mode with guest AP) and another router (access point mode with guest AP) in my house. I want to disable any guest inter-bridge communication (on the same device and inter-device - don't forget to also use the isolate 1 in your wireless config to enable AP isolation for the guest iface).
On router, because we want only inter-bridge communications to be blocked (we want WAN communication to be accepted for guests) we use the following command : ebtables -I FORWARD --logical-in br-guest --logical-out br-guest -j DROP
If you only have one router and no APs you are good to go.
On AP, because we want to allow DHCP and Layer2 communications to router (which is the DHCP/DNS server) but block any other inter-bridge communication we use the following commands (where 01:23:45:67:89:01 is the router's MAC address on br-guest bridge) :
You have to accept Broadcast because DHCP relies on it to find the DHCP server (which is router in our case). Other broadcast traffic shouldn't work as the reply to the broadcast is normally a unicast and that traffic will be accepted only if the source is the router.
I tested it and it seems to work as intended.
You will also have to install the ebtables package for this to work.