Issue on isolating clients in wired guest network

madmat17 · November 19, 2024, 8:57am

Hi all,

I'm struggling to isolate clients from each other on a wired guest network.
Any help would be appreciated. So far I couldn't find any layer 3 based solution online; going down to layer 2 using ebtables might be the ultimo ratio if not possible otherwise - but not the most appreciated way to go.

I'm running OpenWRT 23.05 on an AVM Fritz!Box 7530 with network segmentation. Internal switch configuration is DSA based.

3 VLANs are set up:
VLAN 5: trusted network (192.168.5.0/24)
VLAN 3: guest network (10.0.3.0/24)
VLAN 10: WAN (192.168.1.0/24) - connection between my OpenWRT router and the internet gateway
.

The following should be accomplished:

Clients in VLAN 3 must not communicate with each other, but should be able to access the internet - isolation not working right now
Clients in VLAN 3 must not be able to access the router (blocked with respective input rule) - is working
Clients in VLAN 5 are suppposed to see devices in VLAN 3 and should be able to access the internet - is working
.

The router is having 4 physical LAN ports, whereas the ports are configured as follows:

LAN1: Trunk port for all 3 VLANs - connected to a VLAN capable 16-port switch (switch is connected to internet gateway and is providing connection for clients for VLAN 3 and VLAN 5)
LAN2: Local (untagged) port for VLAN 5
LAN3: Local (untagged) port for VLAN 3
LAN4: Trunk port for VLAN 3 and VLAN 5 - connected to a VLAN capable 8-port switch
.

The network is working in general; only the isolation of the clients from each other within the guest network (VLAN 3 - 10.0.3.0/24) is not working as expected.
.

/etc/config/network:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdc7:fb8f:43ea::/48'

config interface 'lan'
	option device 'br-lan.5'
	option proto 'static'
	option ipaddr '192.168.5.1'
	option netmask '255.255.255.0'
	option delegate '0'

config interface 'wan'
	option proto 'static'
	option device 'br-lan.10'
	option ipaddr '192.168.1.222'
	option netmask '255.255.255.0'
	option gateway '192.168.1.1'
	list dns '195.202.128.3'
	list dns '195.202.138.3'
	list dns '62.40.128.3'

config interface 'wan6'
	option proto 'dhcpv6'
	option device 'br-lan.10'
	option reqaddress 'try'
	option reqprefix 'auto'
	option auto '0'
	option disabled '1'

config interface 'lan_guest'
	option proto 'static'
	option device 'br-lan.3'
	option ipaddr '10.0.3.1'
	option netmask '255.255.255.0'
	option delegate '0'

config device
	option type 'bridge'
	option name 'br-lan'
	option igmp_snooping '1'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan1:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '3'
	list ports 'lan1:t'
	list ports 'lan3'
	list ports 'lan4:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '5'
	list ports 'lan1:t'
	list ports 'lan2'
	list ports 'lan4:t'

# MTU setting for WAN port - might be dismissed
config device
	option name 'br-lan.10'
	option type '8021q'
	option ifname 'br-lan'
	option vid '10'
	option mtu '1496'

.
/etc/config/firewall

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
	option flow_offloading '1'
	option flow_offloading_hw '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'
	option masq '1'

config zone
	option name 'wan'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'
	option network 'wan wan6'
	option input 'REJECT'
	option forward 'REJECT'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow OCPP Traffic from EV charger'
	option src 'wan'
	list src_mac 'xx:xx:xx:xx:xx:xx'
	list src_ip '192.168.1.123'
	option src_port '8887'
	option dest '*'
	option dest_port '8887'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option name 'Allow-mDNS_LAN'
	list proto 'udp'
	option src 'lan'
	option src_port '5353'
	list dest_ip '224.0.0.251'
	option dest_port '5353'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-mDNS_LAN_CoAP'	
	list proto 'udp'
	option src 'lan'
	option src_port '5683'
	list dest_ip '224.0.1.187'
	option dest_port '5683'
	option target 'ACCEPT'
	
	option family 'ipv4'

config rule
	option name 'Allow-IP-webcam-UDP'
	list proto 'udp'
	option src 'lan_guest'
	list src_ip '10.0.3.229'
	option dest 'wan'
	option target 'ACCEPT'

config rule
	option name 'Allow-MQTT-across-nets'
	list proto 'tcp'
	option src 'lan_guest'
	option dest 'lan'
	option target 'ACCEPT'
	option family 'ipv4'
	option dest_port '1882 1883 8883'
	list dest_ip '192.168.5.124'
	list dest_ip '192.168.5.100'

config rule
	option name 'Block-Guest-from-Guest'
	option src 'lan_guest'
	option dest 'lan_guest'
	option target 'DROP'
	list dest_ip '10.0.3.0/24'	# rule didn't work with/without specified IP range
	list proto 'all'
	list src_ip '10.0.3.0/24'	# rule didn't work with/without specified IP range

config rule
	option name 'Allow-Guest-DNS-Lookup'
	option src 'lan_guest'
	option dest_port '53'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'

config zone
	option name 'lan_guest'
	option network 'lan_guest'
	option output 'ACCEPT'
	option input 'REJECT'
	option forward 'REJECT'
	option log '1'

config forwarding
	option src 'lan_guest'
	option dest 'wan'

config rule
	option name 'Allow-Guest-DHCP-Request'
	list proto 'udp'
	option src 'lan_guest'
	option dest_port '67-68'
	option target 'ACCEPT'


config rule
	option name 'Allow-mDNS_guest'
	list proto 'udp'
	option src_port '5353'
	list dest_ip '224.0.0.251'
	option dest_port '5353'
	option target 'ACCEPT'
	option src 'lan_guest'
	option family 'ipv4'

config rule
	option name 'Allow-mDNS_guest_CoAP'
	list proto 'udp'
	option src 'lan_guest'
	option src_port '5683'
	option dest_port '5683'
	option target 'ACCEPT'
	list dest_ip '224.0.1.187'
	option family 'ipv4'

config rule
	option name 'Block-Guest-from-Gateway'
	option src 'lan_guest'
	option dest '*'
	option target 'DROP'
	option family 'ipv4'
	list proto 'all'
	list dest_ip '192.168.1.0/24'

config forwarding
	option src 'lan'
	option dest 'lan_guest'

config redirect
	option name 'OCPP - forward port 8887'
	option dest 'lan'
	option target 'DNAT'
	option src 'wan'
	option src_dport '8887'
	option dest_ip '192.168.5.100'
	option dest_port '8887'

Thanks a million in advance,
Mat

lleachii · November 19, 2024, 9:28am

Correct, since it's the same subnet/VLAN, the traffic never traverses the firewall plane, hence no way to block.

Placing them on separate VLANs might be an option too, particularly if you needed to divide your network anyway. Is there a unique use case for us to consider - given you want them on the same VLAN, yet "isolated"?

madmat17 · November 19, 2024, 11:07am

@lleachii thanks for the swift response and hints!
The point is that I want to reduce the potential attack surface for internal attacks (e.g. if one of the guest devices is compromised). Having even more subnets to further segment my guest network in different zones isn't the way I want to go.
Frankly: I haven't been aware that traffic from within one subnet is not traversing the firewall at all - but quite obvious that the routing is done on layer 2 within 1 subnet. Thus I do see 2 options:

Forcing all traffic to traverse the firewall (by implementing an ARP proxy for the respective interface)
Having a more detailed look at ebtables for filtering the traffic.

I'll update the post once I have had the chance to run some tests.

Cheers,
Mat

NPeca75 · November 19, 2024, 12:18pm

Buy a real managed switch (200 eur ++), run separate cables for each device for Vlan3, config ports on switch to disable L2 communication between ports

madmat17 · November 20, 2024, 5:01am

Well, thanks and nice idea! However, there wouldn't be any switches flying around in my setup at all if I could have wired up everything directly. That's the point of having a switch, I guess (at least in my case).
Furthermore, not all devices are on ethernet. Some are wired, some are wireless.

Generally speaking:
ebtables doesn't seem to be the right choice with fw4 and nftables being in place as of OpenWRT 22.03.
From what I read nftables should be capable of filtering at layer 2 and thus manage intra-subnet traffic. What I'm not sure about is how I could ensure that traffic in a DSA setup between VLAN ports is being handled by fw4/nftables at all.

lleachii · November 20, 2024, 5:56am

?

This is important information.

Given the title of this thread ("isolating clients in wired guest network") can you clarify these statements so we can better assist you?
Can you verify that all the clients you're attempting to isolate are Ethernet-based and where/how they're connected?

It almost seems from my understanding - that some devices are wireless, or connected downstream of the OpenWrt device?

Interesting.

madmat17 · November 20, 2024, 7:18am

Certainly. I tried to mock a schematic layout.
The wiring between different floors and rooms cannot be changed (neither the routing of the cables, nor the amount of cables).

Some of the clients are wired, some are connected wireless; wireless connected clients attach to the network via different APs.
That's why the WiFi client isolation (which is only working within the same WiFi band of the same WiFi device) won't solve the problem.
The wired ones are going via ethernet due to throughput as well as reliability reasons.

The whole setup looks as follows:

Edit: I just realized that I didn't add the info that also some VLAN 5 clients are connected wirelessly to all of the 3 routers as well - but that's out of scope here anyways (as the VLAN 5 is working as expected and no client isolation is needed there)

lleachii · November 20, 2024, 7:35am

Ummmm...

Which OpenWrt device are you expecting to perform isolation?
Also explain how/what/where/which devices should be isolated from which/what
Basically - provide more detail regarding the following:

We need to know exactly where all devices are located (physically - including what AP the WiFi devices is connected to, if applicable)

(FYI, you have a switch/es in the middle of your network - i.e. that manages Layer 2 connections/isolation - or lack thereof, etc. So since you want to "isolate" albeit within VLAN, we need to know all details. Or...you could just properly VLAN these devices too. )

Perhaps, this is making the Best Practice of VLANing for isolation - become more apparent as the standard solution to your issue
"Zone" (firewall) and "VLAN" (networking) are different terms, and I'm not sure which you meant in the context of OpenWrt

lleachii · November 20, 2024, 7:58am

Also, you provided a config, I assume it's the FritzBox (and that you want that device to do the isolation?)...but which device is that - router 1, 2 or 3?

I assume Router 1 (since you mention DSA)?

I only ask because there're switches in the middle (i.e. that mange Layer 2).

madmat17 · November 20, 2024, 8:13am

I was assuming that the Router 1 (which is the main device hosting the DHCP server and the firewall) should be taking care of the isolation.

All clients (no matter if connected via ethernet or wirelessly, no matter via which router) within the VLAN 3 should be isolated from each other.

Clients in VLAN 3 are connected as follows:

Ground Floor - wireless: Connected via the AP provided by Router 1
Ground Floor - wired: Connected via untagged VLAN 3 ports of the 8-port switch which is hooked up via a trunk port to Router 1 (port 4 of Router 1, port 1 of the switch)
Basement - wireless: Connected via the AP provided by Router 2, which is connected via a trunk port to the 16-port switch (port 2 of Router 2, port 4 of the switch)
Basement - wired: Connected via untagged VLAN 3 ports of the 16-port switch which is hooked up via a trunk port to Router 1 (port 1 of Router 1, port 1 of the switch)
First Floor - wireless: Connected via the AP provided by Router 3, which is connected via trunk port to the 16-port switch (port 1 of Router 3, port 3 of the switch)

What do you mean by "properly VLAN these devices"? I would like to avoid setting up an own VLAN for each client.

Each VLAN is having its own firewall zone.

VLAN 10 is in the firewall zone wan
VLAN 3 is in the firewall zone lan_guest
VLAN 5 is in the firewall zone lan

My thinking was that the firewall / nftables rules applied to VLAN 3 should then be defined in the context of the zone lan_guest.

You are totally right. Router 1 is the main router, the Fritz!Box, which is on DSA already.

lleachii · November 20, 2024, 8:18am

Correct. And everything you described looks good. Except...

This is not possible. The Router 1 OpenWrt device does not manage the Layer 2 MAC tables/filtering/etc. of:

Ground Floor Switch
Basement Switch

So it's impossible that (in general) any device on your VLAN 3 could be isolated in another location in your home by Router 1. Save VLANing more.

psherman · November 20, 2024, 8:20am

That is simply not possible. Traffic between any two devices that exist on the same L2 network will be switched, not routed. This means that it will not even reach router 1 since the switches define the path between any 2 wired devices. But even if it did reach the router, the firewall only filters traffic that is routed (L3), not switched.

Therefore, the only viable solution for your isolation request is either lots of VLANs or replacing all the switches with higher end managed switch that have port isolation features.

madmat17 · November 20, 2024, 8:32am

Thanks for your swift support on that matter! This is highly appreciated!
To be frank: I totally missed that the switches are not actually routing. But makes perfect sense.

I assume that there's also no chance to force all traffic on that subnet being routed via the standard gateway 10.0.3.1 (rather than being switched) of that - e.g. via NAT-ing or manually defined routes?
I'm well aware that I would sacrifice bandwidth and probably performance when doing so - but that could be a workaround until I had a chance to wrap my head around how/which enterprise grade switch I could use for a clean setup.

psherman · November 20, 2024, 8:35am

No, not possible. L2 networks are switched. You can’t change that - the OSI model defines it very clearly.

lleachii · November 20, 2024, 8:35am

Inter-network traffic is already sent to your gateway (I assume 10.0.3.1 is Router 1). But...in order to reach the gateway IP (L3) you need to switch the traffic via L2 to reach it. You're describing Layer 2.

This requires another Gateway IP...on another VLAN.

That part.

If it helps:

Layer 1 - Ethernet or Wireless Ethernet (physically)
Layer 2 - MAC Addresses/Switches
Layer 3 - IP Addresses/Routers

appelsin · November 21, 2024, 12:50am

Although some switches do have an extra feature called "port isolation" or "private vlan".

Forces all traffic on flagged ports through the uplink port (eg. to OpenWrt) instead of doing the normal layer2 things.

https://en.wikipedia.org/wiki/Private_VLAN

lleachii · November 21, 2024, 2:03am

Perhaps, but since this is a design consideration of the switches, I'm not sure now that would assist you with OpenWrt.

BTW - this was already mentioned to you:

Buying more advanced managed switches could also solve your issue.

I didnt understand what you meant by this part. It's merely an isolation config feature of more advanced switches that we already suggested. Same Layer 2.

appelsin · November 21, 2024, 3:12am

I didnt understand what you meant by this part.

Just trying to gloss over irrelevant technical details by calling it "things".

But ok, will try to explain better.

"normal mode" = switch ASIC does a CAM table lookup with key being destination-MAC and VLAN-id, then streams buffered datagram out relevant port(s).

"private vlan mode" = same, but if the ingress port has "isolated=true" the lookup key gets the added condition "isolated==false" to filter away some CAM entries.

The latter to prevent intra-VLAN traffic between relevant ports. Just ends up being an extra key in the CAM table lookup in addition to vlan and dst-mac.

In any case, my point was really just that the feature @madmat17 is looking for (wired clients on the same VLAN blocked from talking to each other) is typically called "port isolation" or "private vlan" in the feature description when buying a network switch.

(Looking at the drawing in comment #7, the wired vlan3 clients are all connected to hardware network switches.)

@madmat17's existing switches may even already support it. For example, the 10-year old switch I'm currently connected to seems to have it:

root@OpenWrt:~# grep "" /sys/class/net/lan1/brport/*
/sys/class/net/lan1/brport/bpdu_filter:0
/sys/class/net/lan1/brport/bpdu_guard:0
/sys/class/net/lan1/brport/broadcast_flood:1
/sys/class/net/lan1/brport/change_ack:0
/sys/class/net/lan1/brport/config_pending:0
/sys/class/net/lan1/brport/forward_delay_timer:0
/sys/class/net/lan1/brport/group_fwd_mask:0x0
/sys/class/net/lan1/brport/hairpin_mode:0
/sys/class/net/lan1/brport/hold_timer:0
/sys/class/net/lan1/brport/isolated:0        <-------- here
/sys/class/net/lan1/brport/learning:1
/sys/class/net/lan1/brport/message_age_timer:0
/sys/class/net/lan1/brport/multicast_fast_leave:0
/sys/class/net/lan1/brport/multicast_flood:1
/sys/class/net/lan1/brport/multicast_router:1
/sys/class/net/lan1/brport/multicast_to_unicast:0
/sys/class/net/lan1/brport/neigh_suppress:0
/sys/class/net/lan1/brport/proxyarp:0
/sys/class/net/lan1/brport/proxyarp_wifi:0
/sys/class/net/lan1/brport/root_block:0
/sys/class/net/lan1/brport/unicast_flood:1

(Often configurable via switch web GUI; using CLI to demonstrate here just because that particular switch is running OpenWRT. Under OpenWRT, wifi-isolation is available via LUCI, but port-isolation is currently CLI only.)

The only problem I can foresee with using port-isolation is that on hardware switches the setting may be per-port and not per-configured-vlan-on-port. In which case, trunked ports with both vlan 3 and vlan 5 would need to be untrunked.

Buying more advanced managed switches could also solve your issue.

Hmm, looking at the drawing again, the switches are already configured with VLANs and trunking, so I imagine that they are in fact managed switches already.

lleachii · November 21, 2024, 3:36am

I thought you were the OP when I replied, my apologies.
Yes, I understand the OP already has mangaed switches. It seems you may have overlooked the [original] premise of the thread (i.e. the OP wanted to make configurations in Router 1).
It seems clear now that a managed switch with the correct features will definitely solve the OP's issue.

appelsin · November 21, 2024, 3:39am

Ah, my bad. Sorry!