Guest network not secure!

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
12

Guest network not secure!

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Re:Re:Guest isolation not secure!
2019-08-20 10:05:15

Hello all,

 

Guest network = Access Control + SSID Isolation. That is to say, when we enable guest network for the SSID, we cannot communicate with each other and we cannot access private subnets. So we cannot ping other clients successfully. 

However, this feature will not block ARP/DNS/DHCP packets, because the clients need these packets to access the internet. 

When we use some APPs like Fing, we will see other devices in the lan subnet, like the router, the AP. But it is normal because these APPs are based on ARP protocal, they can can other devices. But please don't worry that these clients are visible but they cann't be accessed. So they are secure.

  0  
  0  
#12
Options
Re: Guest isolation not secure!
2019-08-20 16:47:42 - last edited 2019-08-20 18:10:17

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.

 

 

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  1  
  1  
#13
Options
Re:Re: Guest isolation not secure!
2019-08-21 01:34:43

Hi @R1D2 ,

 

Thank you for your test. 

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). 

 

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? 

  0  
  0  
#15
Options
Re: Guest isolation not secure!
2019-08-21 12:22:00 - last edited 2019-08-26 14:28:18

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.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  2  
  2  
#16
Options
Re:Guest isolation not secure!
2019-08-21 18:45:18 - last edited 2019-08-22 08:11:27

Hi All,

 

I have tested further and concluded it is very unsafe to use the guest function in a public area!


I configured a DHCP server on a device which I connected to guest SSID wifi. 

The device has a valid IP address to access the internet on the guest wifi.
The device will NAT all traffic going thru it.  
It will serve (DHCP) IP address in the range of 100.64.0.0/10, telling the clients to router traffic through him.
Those address are common on 4G networks, so nobody will notice that it's strange. 

 

My laptop and phone got an IP address from the rogue DHCP server.
All there traffic is going through the device. So it can alter your traffic, or simple register what you and your guests are doing. 
Also the LAN is effected and will get its traffic rerouted if doing a DHCP request.


Here you can see what is happening.

  

This is really bad. It’s very easy to setup. The problem with two DHCP servers on the network is easily solved by the attacker to make sure the scope is full of the trusted dhcp server.

 

I really recommend TP-LINK that they follow my advice about the mac filter post #6 in this thread.

 

How can you work around this issue?
One AP with One guest SSID in a dedicated VLAN for that AP only will have no problem. All else is a problem.

Activated DHCP Snooping on your switch and use a single band for each AP. This will not solve all the problems but will help a lot.
 

Cheers,
Meetriks

  1  
  1  
#17
Options