@dpsguard, you should leave »Guest Network« enabled if you want isolation of wireless clients against other wireless clients.

»Guest Network« is needed b/c it includes »Client Isolation«.

@dpsguard, can't second that. Client isolation is for clients connected to the same WLAN on the same EAP. Traffic between two clients in the same WLAN doesn't leave the EAP on the LAN side and won't go through the router.

Regarding firewall entries on the router: rules using IP addresses won't catch any non-IP traffic. IP rules are not enough to completely separate two networks. If you share the same network on two wireless networks you even have the same broadcast domain in both WLANs.

For a truly isolated guest network you need to use VLANs. See this HowTo for more information on how to set up a fully isolated guest network (Method 2). There is no difference between Omada Controller v3 and v4 in this respect.

@dpsguard, there are several situations which must be taken care of to isolate clients in a wired/wireless network:

1. Traffic from a client connected to SSID #1 to a client associated with the same SSID #1 of the same EAP (uses bridging in the WiFi chip, controlled by »Client Isolation« setting inside the WiFi chip),
2. trafic from a client connected to SSID #1 to a client associated with a second SSID #2 of the same EAP (uses bridging between radio interfaces radio0/wl0 and radio1/wl1 (»Client Isolation« should take care of this, too),
3. traffic from a client connected to a SSID of an EAP to a client connected to a SSID of another EAP (uses either switching or routing in the same LAN or between different LANs, controlled by ACLs in the switch or by firewall rules in the router),
4. traffic from a client connected to a SSID of any EAP to a client connected by wire to the LAN or the WAN if WAN is the local main network (routing, controlled by switch ACLs or firewall rules in the router).

Possible solution #1:

»Client Isolation« (and probably an additional ebtables rule for the internal bridge) in the EAP could achieve isolation in wireless networks (situations 1. and 2.). Switch ACLs or firewall rules covering L2 traffic could achieve isolations in the wired network (situations 3. and 4.). Pretty complex IMO, so see possible solution #2 below.

Now, the »Guest Network« setting of Omada Controller tries to achieve isolation by implicitely setting »Client Isolation« in the WiFi chip and by defining (invisible!) ACLs in the EAP blocking RFC1918 IPs. At best, this is kind of a »poor man's guest network«, which has no true isolation: non-IP traffic still can pass. I did proof this in the HowTo linked in my previous reply.

Possible solution #2:

IMO, the right way to achieve true isolation inside a guest netwok and between a guest network and the LAN is using a »Client Isolation« setting and VLANs. Client isolation covers bridging inside the EAP's radio and a VLAN covers the wired networks (LAN, GUEST) including the associated wireless networks (SSID for the LAN and SSID for the GUEST network) when using VLAN-mapped Multi-SSIDs.

Background info:

A »single click plug'n'play guest network« was demanded by home users in the past, b/c VLANs are not common in home networks. They finally got the »Guest Network« setting in Omada Contoller. Nothing wrong with this, but the the »Client Isolation« setting should have been retained IMO. Both settings could co-exist.

@dpsguard, please can I count your vote for the feature request to re-introduce the »Client Isolation« setting as an own setting in Omada Controller?

If so, @Fae, could you please add vote #22 for this feature request? Thanks to you both!