Hi
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.
Hi
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?
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.
Hi
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.
It works as expected, but only for IPv4. IPv6 does not work.
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.
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
192.168.40.1 lladdr 26:f5:a2:2d:7c:c0 REACHABLE
192.168.40.2 lladdr b8:27:eb:fd:42:26 STALE
192.168.40.30 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 192.168.40.2
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
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.
