Client 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

Ah, I understand. What would be the cleanest solution to achieve full client isolation? Setting up 3 different interfaces, with their own subset and DHCP server doesn't seem very efficient.

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!

2 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 ?