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.