Yeah, I meant that option the vlan_filtering setting isn't there to set on my Lede router.
How about this one:
ebtables -A INPUT --logical-in br0 -j DROP
But it is unclear what was done with the Vlan Filtering option after this thread.
It was proposed again less than 2 weeks ago: http://lists.infradead.org/pipermail/lede-dev/2018-April/011715.html
So hopefully this will make it to Lede officially. Ebtables is quite slow/inefficient from what I can see.
It is said that ebtables is slow, but I don't know what this means in practice. Maybe < 100 mbit/sec it is perfectly fine on a home router.
I managed to get it working via iptables
Install the following package: kmod-br-netfilter
Which will add netfilter support for bridges. And then set:
echo 1 > /sys/class/net/br-guestlan/bridge/nf_call_iptables
Optional for ipv6 support: echo 1 > /sys/class/net/br-guestlan/bridge/nf_call_ip6tables
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!
Wonderful! All that remains to do is to add a Luci checkbox to allow enabling/disabling. Default should be "On", in my view.
Great to know that it's meeting your goals!
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)
You may be right. In any case, a wrapper in Luci for that stuff (+ WiFi client isolation) would be wonderful !
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
This setting only applies if there are 2 routers in the same firewall zone, unless you are referring to the Forward TO and FROM rules, instead.
I just changed my untrusted zone's
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.
...or on a bridge between each other.
The entire discussion was about adding netfilter functionality to bridges so that iptables could be used
Understood...I actually have a DD-WRT in storage, if I have a chance, I'll see if I can discover how they isolate.
I'm sure they don't make bridges for each device.
Also, these rules can be placed in UCI.
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.
so.. did anybody encounter/measure a performance difference between
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 (?) :
Should I delete the 3 lines already inserted in my
/etc/sysctl.conf file? I guess not.
I will also have to install the
PS: I am on 19.07 version of OpenWRT.
Thanks in advance for your help.
Not that I know.
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
br-untrusted part is the name of the bridge where you want to enable isolation.
Will go the
ebtables way then.
Thank you very much for your time answering this.
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) :
ebtables -I FORWARD --logical-in br-guest --logical-out br-guest -j DROP ebtables -I FORWARD --logical-in br-guest -d 01:23:45:67:89:01 -j ACCEPT ebtables -I FORWARD --logical-in br-guest -s 01:23:45:67:89:01 -j ACCEPT ebtables -I FORWARD --logical-in br-guest -d Broadcast -j ACCEPT
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.
If someone has a better solution I am all ears