I did set up a testbed using a spare device (TL-WDR4300) running OpenWRT Linux configured as a router. It also runs a DHCP server, Linux firewall and our own Wireless Captive Portal software. Omada portals are not used here, controller is just for management of the EAPs.

 

IMO a guest network implemented with Multi-SSID should always be isolated by using VLANs. I personally don't care for requirements to deploy a common broadcast domain over two or more SSIDs, that's not used in business-class setups.

 

So this is my testbed setup:

 

 

 

I used different names for the WDR4300 WLANs and the Omada WLANs to test and compare client isolation.

 

My MacBook is connected wirelessly to the private network (VID 16) on the WDR4300. My Nexus 7 and my Neffos N1 are used to test both guest WLANs (the WDR4300 »public« and the Omada »free« WLANs). The WDR4300 is connected to the LAN which has plenty of other devices effectively isolated by the Linux firewall. Fing is running on the Nexus.

 

WDR4300 running Linux has WiFi client isolation for its own public WLAN enabled, Omada Controller has »guest network« enabled on the EAP's guest WLAN.

 

First test with Omada WLANs with fing reveals the devices in the same network (»Private WiFi«), no matter whether they are in different frequency bands or in the same band:

 

 

 

Second test with client isolation on the WDR4300 running OpenWRT Linux does not reveal any devices (except itself and the router) in fing while scanning the guest network »myname (public)«:

 

 

 

Seems to me that client isolation does not really isolate clients in Omada Controller. Client isolation in OpenWRT Linux works as expected.

 

Regarding the guest network function introduced recently in Omada Controller: IMO it is a very bad idea to implement a guest network the way Omada Controller does:

 

• ACLs are not as powerful as a full-fledged firewall
• ACLs/firewalls do not belong to APs nor to an AP controller (except maybe in system concepts where the controller routes all traffic itself)

 

I know that in the past home users, who were overburdened with VLAN setups, did complain again and again to convince TP-Link to add an easy way for creating a guest WLAN in Omada Controller. It seems to me that TP-Link added this because of those complaints. That's ok and no problem so far.

 

However, it isn't nonetheless that easy at all to deploy a guest WLAN if you use different subnets or VLAN-based Multi-SSIDs and need certain devices to be accessible for guest users (such as an OC200 or a third party/external Captive Portal located in a subnet with private IPs or behind the router's firewall):

 

If you adopt EAPs and enable »Guest Network« before adding execptions using ACLs you exclude the EAPs from the controller and the Captive Portal. To get the EAPs connected to the controller again, you either have to re-configure the switch temporarily or reset EAPs to factory settings, forget them and adopt them again.

 

But there is also another problem with this concept of »Guest Network« setting fiddling around with ACLs: forrest, remember that I observed that »Allow ACLs« are not working in combination with invisible ACLs set by the »Guest Network« setting? I noticed this while setting up a guest WLAN for a customer, but couldn't reproduce back then b/c I was in a hurry and already had to deliver the system to the customer. Now, with the testbed above, I can reproduce it again:

 

Turning on »Guest Network« in the above testbed and using an »Allow« ACL for access to the Captive Portal running on WDR4300 in the same guest subnet or OC200 in a different subnet does not work.

 

This does not allow to contact the Captive Portal running on the WDR4300 and OC200 in another VLAN. ACLs set by »Guest Network« seems to have preceedence over »Allow« rules.

 

The following (traditional) blocking ACL allows access to the gateway by excluding its IP from blocking, even if »Guest Network« is enabled:

 

 

This allows to access the gateway and the OC200 in another VLAN.

 

However, as @Meetriks noted correctly, isolating guests effectively needs to allow blocking their devices not only by IP, but also by MAC address or by protocol even if a common broadcast domain is used over different SSIDs. A firewall allows this.

 

What's more, firewalls usually have a default policy and the best default policy for public hotspots is to deny everything except certain IPs/MACs or protocols explicitely defined, not the other way around.

 

 

So, to summarize:

 

Please give us the old »Client Isolation« setting back!

 

You can still offer a »Guest Network« setting for home users if you think it's worth it, but please don't remove pure client isolation setting just to combine it with invisible ACLs blocking private networks. We want to block traffic to private IPs in our firewall on the router, which allows much more fine-grained control than ACLs ever will achieve.

 

Also, a working client isolation for public hotspots is an absolute need for commercial hotspots (compare Linux' client isolation above with Omada Controller's client isolation).

 

Combining WiFi client isolation with L3 ACLs denying access to private IPs and then removing old client isolation setting excludes the requirements of professional users setting up business-class hotspots.

 

 

I will keep the testbed running for some days in case you want me to provide further informations.

 

 

 

forrest wrote

You want the SSID Isolation not Guest Network. But we have a test, when we enable SSID Isolation only, we can still see other clients in the LAN network because of the ARP packets. So SSID Isolation cannot block other visible clients (We can still see them). 

 

Hello forrest,

 

thanks for your reply.

 

I think there is some confusion about visible devices in the LAN. We have 3 networks in our Omada hotspot installations, each in a separate firewall zone:

• Network/zone LAN: the customer's own corporate network (e.g. VLAN 2 with subnet IP 192.168.1.0/24),
• network/zone PRIVATE: our private network for management, OC200 or Omada SW controller located in this network (e.g. VLAN 16 with subnet IP 192.168.16.0/24),
• network/zone PUBLIC: public hotspot network for guests (e.g. VLAN 11 with subnet IP 192.168.11.0/24).

 

Router's firewall default policy is to reject forwarding any traffic for all zones. The firewall allows input/output to/from the router for PRIVATE and PUBLIC zones, blocks input from LAN, allows output to LAN. Only exceptions are DNS, DHCP, HTTP/HTTPS redirection to Captive Portal on the router (or the OC200), layer3-based EAP discovery for OC200 using DHCP option 138 etc.

 

It rejects all other forwarding traffic including inter-zone ARP traffic, thus:

 

• Devices in zone LAN are not visible for zone PUBLIC.
• Devices in zone PRIVATE are not visible for zone PUBLIC (except HTTP/HTTPS on a OC200 in PRIVATE zone if one uses OC200 portals).
• Devices in LAN are visible for zone PRIVATE (PRIVATE is just an extension of LAN through a separate WiFi network, second SSID).
• Devices in PUBLIC zone are not visible to other users in PUBLIC zone in WDR4300 WLANs running Linux.
• But devices in zone PUBLIC are visible to other users in zone PUBLIC in EAP WLANs.

 

This is the first point in my posting in reply to Meetriks' observation of devices in his LAN being visible to guest users. It's probably his setup allowing to see devices in the LAN zone.

 

 

Why was »Guest Network« causing a problem for us when being introduced in v3.1.13?

 

Our firewall on the router denies access to all RFC1918 IPs already, except for the router itself (input/output to Captive Portal) and for OC200 HTTP/HTTPS for only three customers still using an OC200 portal at the moment.

 

Blocking of RFC1918 IPs with certain exceptions was suddenly messed up by introduction of the »Guest Network« setting. This customer uses Omada controllers not managed by us, updated the OC software, enabled »Guest Network« and caused breakdown of 5 hotspots out of 11 with hundreds of users for a whole day until we found out what the cause was.

 

Please don't get me wrong. I'm not saying the new »Guest Network« settings is bad, I'm saying the way it was introduced (by removing the client isolation setting and combining it with invisible ACLs) was no good decision in my opinion.

 

Why didn't R&D just keep the old checkbox for client isolation setting in addition to introduction of a guest network setting which just enables client isolation beside fiddling with ACLs? Why are those ACLs not visible in the ACL settings, so one could notice the change?

 

Just adding a »Guest Network« setting without removing the »Client Isolation« setting would have helped to avoid much confusion on installations doing RFC1918 blocking for themself with (intentional) exceptions of certain private IPs.

 

That's the second point in my posting in reply to your information that client isolation has now been moved to guest network setting.

 

 

If you have other ways that can block the visible devices via the client isolation, please tell us. 

 

By the way, you mention the "Also, a working client isolation for public hotspots is an absolute need for commercial hotspots (compare Linux' client isolation above with Omada Controller's client isolation)."  What's the meaning of it? 

 

That's the third point in my post: I noticed that on TL-WDR4300 running Linux the client isolation setting prevents clients being visible in the same WiFi network.

 

Maybe you can tell me whether client isolation in WDR4300 has to be implemented in the WiFi driver (software) or is implemented in the WiFi chip itself (hardware function on the chip enabled by a register setting)? And how about Omada EAPs? Is client isolation implemented in the software driver or in the chip itself? If it is handled in software, I would say it could be implemented in the driver for this chip, right? Or am I missing something here?

 

 

Why should clients not see which devices are connected to the guest network?

 

Because zero-day exploits can introduce potential attack vectors if some vendor of a client device messes up handling of certain protocols which need to be allowed (DNS, DHCP, ARP etc.) for such devices in the guest network. Because setup of a secure environment is complex enough to justify not showing IPs of other devices to the users in a guest network.

 

 

Hope you can understand that such changes can cause problems in existing setups as has happened with the guest network setting or as it is expected to happen when migrating old software controller setups to an OC200 setup. In fact, this is the reason why I still manage dozens of older customer installations with Omada Controller v2.7.0, few newer customers with v3.2.1 SW controller and latest customers with OC200. All three installation types need different setups b/c of changes in the controller.

 

Thanks anyway for your attendance. I hope you can convince R&D to consider backward compatibility in new versions of Omada Controller when adding new features.