Client isolation

Not sure what you mean by "that option". The article mentions the following as recommended option, but they are other:

# bridge vlan del dev br0 vid 1 self
# echo 1 > /sys/class/net/br0/bridge/vlan_filtering

Yeah, I meant that option :slight_smile: the vlan_filtering setting isn't there to set on my Lede router.

Ah!

How about this one:

ebtables -A INPUT --logical-in br0 -j DROP

Also, see:

http://lists.infradead.org/pipermail/lede-dev/2017-February/005779.html

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.

Ah, good.

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 :slight_smile:

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 :slight_smile: Hopefully this is helpful information for other people as well!

3 Likes

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 !

1 Like

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 :slight_smile:

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 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.

...or on a bridge between each other.

The entire discussion was about adding netfilter functionality to bridges so that iptables could be used :slight_smile:

1 Like

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 ebtables and kmod-br-netfilter ?

@Mushoz

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.

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

Where the br-untrusted part is the name of the bridge where you want to enable isolation.

1 Like

Will go the ebtables way then.
Thank you very much for your time answering this.