[Solved] Help needed on isolating LAN clients from each other

I'm struggling with isolating LAN client from each other and need some help. I try to reorganize my DMZ so that the computer inside the DMZ do not have access to each other besides the ports I open in the firewall.

In the DMZ I have 3 servers

  • one pi running pihole and I need to open port 53 for this from all my internal network and the other computers in DMZ
  • one pi running my Nextcloud and I only want to give access to 80 and 443
  • one pi running a mail server so I want to open 25 only

I have each of the servers in a seprate VLAN (one per device) and bridged those in one interface named 'dmz'. I have a zone 'dmz' for this interface and I have a set up:

  • I can access to everything in the DMZ from my LAN by the zone rules so I can access ssh, etc from my notebook to manage the devices.
  • I have traffic rules for each of the pis with the ports to be open and by the pi's ip as destination address

So access to the pis from outside the DMZ works as wanted (only accessable by the ports opened in the OpenWrt firewall).
But the pis inside the DMZ have no limit in accessing each other as they are all in one bridge, even though they have seperate VLANs which means, the traffic between the servers is going through the bride, they are nnot connected on the switch.

I now want to isolate the servers from each other as I want to set up another two servers in DMZ.

Setting the 'forward' rule on the DMZ zone to 'REJECT' prevents any traffic from other zones to this zone but is not isolating the servers from each other.
I found this: https://openwrt.org/docs/guide-user/firewall/fw3_configurations/bridge and I see that kmod-br-netfilter is not installed. So this seems to be the way to go ...

But I also have another network with a bridge for my media systems (nas, tvheadend, Kodi client) and I don't want to isolate those clients from each other.

So how can I isolate the devives in one bridge but not the devices in another bride? The settings for br-netfilter seems to apply for all bridges.
Any help welcome.


The isolation part is optional and described in the extras.
You need to change the forward policy for a specific firewall zone.

thanks for the reply. I saw that. The problem I see is: The reject on the zone does by default reject the forwarded traffic to the zone (form other zones). For exceptions a traffic rule is needed. This worked well so far.
I have three zones with bridges where the forward is set to reject. At the moment in the zones the devives on the bridged networks can see each other and this is stil wanted for two of the zones but not for the DMZ.
If I enable the kmod-br-netfilter it is blocking the forward between the devives in a bridge for ALL bridges. Or did I miss something?

1 Like

No, it just makes possible to process bridged traffic with firewall.
Firewall rules do not apply for bridged traffic within the bridge by default.

1 Like

Ok, I see
The forward rule on a zone defines default handling for forward between the interfaces of the zone. So for my three zones with bridges this has never been relevant as those zones only cover one interface each (a bridged interface, but a single interface for the zone). So when with kmod-br-netfilter the forward rules also applies to the interface within the bridge, I can set the forward on the other zones to accept. That should solve my problem.
I'll try it that way and hopefully the traffic rules for the servers still apply even between the bridged interface and only all the rest is blocked.

1 Like

If you want them isolated and you have created the vlans per device, why did you bridge them? That alone would be enough to achieve your goal.

1 Like

The goal is to separate the servers from each other, that's why I have them separated by vlans. I bridged them as I didntt want to define one interface per vlan and to create different subnets each fro a single server. I found no way to assign multiple vlans to an interface without briding (not allowed in luci, didn't test with uci).
Separate vlans is to ensure they don't talk to each other via one of the switches. :wink:

1 Like

Thank you.
Easier as expected. Need to learn not think the complicated way in the first direction ..

1 Like

I need to reopen this issue.

It works as expected, but only for IPv4. IPv6 does not work. :frowning:

All traffic between the devices is rejected by default, for IPv4 and IPv6. If I define traffic rules and allow traffic forwarded to certain ports of a device, it works for IPv4. So IPv4 obviously is routed (also shown in the firewall ui).

As the current three decives are Raspberry Pis with Buster and those use DHCPCD5 for network configration this might be a routing problem. Seems as if I need to dig further. Raspberry Pis with openmediavault use networkd instead and have a correct routing entries. The dhcpcd5 seems to drop a number of the route advertisments.

Digging deeeeeper I found the following:

The routing subsystem will decide the destination of the packet. However, unlike IPv4, there is no reverse-path filtering.
For IPv6, reverse-path filtering needs to be implemented with Netfilter, using the rpfilter match.

I'll give it a try

Analyze the firewall configuration:

uci show firewall

Make sure your rules and zones do not limit the protocol family to IPv4 only.


thanks for the reply. For me it seems to be sort of routing problem. The devices are Raspberry Pis and those have kinda broken routing table. Just suggetsing thats the problem.

Access to the devives from outside the bridge zone (dmz) works.

What I see is:

pi@pi-nc1:~ $ ip neigh show dev eth0 lladdr 26:f5:a2:2d:7c:c0 REACHABLE lladdr b8:27:eb:fd:42:26 STALE lladdr b8:27:eb:22:20:47 STALE
fd42:0:0:40::2  FAILED
fe80::ba27:ebff:fefd:4226 lladdr b8:27:eb:fd:42:26 STALE
2xxx:xxx:xxx:40::2  FAILED
fe80::24f5:a2ff:fe2d:7cc0 lladdr 26:f5:a2:2d:7c:c0 router REACHABLE

pi@pi-nc1:~ $ host pi-hole
pi-hole.xxx.xx has address
pi-hole.xxx.xx has IPv6 address 2xxx:xxx:xxx:40::2
pi-hole.xxx.xx has IPv6 address fd42:0:0:40::2

looking on my routing it is (raspberry pi with raspbian os and dhcpcd 5):

pi@pi-nc1:~ $ ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2xxx:xxx:xxx:40::/64 dev eth0 proto ra metric 202 mtu 1500 pref medium
fd42:0:0:40::/64 dev eth0 proto ra metric 202 mtu 1500 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::24f5:a2ff:fe2d:7cc0 dev eth0 proto ra metric 202 mtu 1500 pref medium

and this is the routing table of a raspberry pi with openmediavault and systemd-networkd:

pi@pi-omv:~ $ ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2xxx:xxx:xxx:41::/64 dev eth0 proto ra metric 100 expires 3073sec pref medium
2xxx:xxx:xxx::/48 via fe80::24f5:a2ff:fe2d:7cc0 dev eth0 proto ra metric 1024 expires 1574sec pref medium
fd42:0:0:41::/64 dev eth0 proto ra metric 100 pref medium
fd42::/56 via fe80::24f5:a2ff:fe2d:7cc0 dev eth0 proto ra metric 1024 expires 1574sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::24f5:a2ff:fe2d:7cc0 dev eth0 proto ra metric 100 expires 1574sec mtu 1500 pref medium

This one has a correct /56 route for the ULA.

Doing a traceroute from pi-nc1 to pi-hole gives:

pi@pi-nc1:~ $ traceroute
traceroute to (, 30 hops max, 60 byte packets
 1  OpenWrt.xxx.xx (  0.301 ms  0.243 ms  0.192 ms
pi@pi-nc1:~ $ traceroute fd42:0:0:40::2
traceroute to fd42:0:0:40::2 (fd42:0:0:40::2), 30 hops max, 80 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *

I think my best option is to switch to systemd-networkd or network-manager for the pis. Or is there a way to manually add a route, just for testing?

1 Like

Rules are ok, I'm sure. Also working from devices outside the dmz.

1 Like

IPv6 heavily relies on the ICMPv6.
Make sure to extend the existing rules for all zones:


And here we are. That's it.

Thank you very much.

While neighbour discovery inside a zone (and bridge) always worked and there was no need for having it between zones, with the isolated bridge I needed to open neighbour discovery between zones (forward). It now works. :slight_smile:


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.