Hendrik Lüth

While I have been in the US during the last days, I’ve had the pleasure to meet Robert Boardman and Rowell Dionicio. We had a really nice discussion about WiFi and happened to stumble over the topic of client isolation and the problems is can cause to usability. Robert suggested to turn the discussion into a blog article, so this one’s on you, Robert!

In general client isolation means that you set an option in your AP or WiFi-controller and thus prohibit all communication between all clients in the SSID. It’s a quite common feature and nearly every WiFi-AP supports it – from the basic 15€home-router up to the enterprise-grade hardware. You could compare it to an ACL that prohibits any traffic, except between a client and its default gateway, but in a layer 2 manner. In some solutions it’s just one checkbox in the UI, but for example in the HPE MSM760 controllers you must write a filter to apply on that SSID you want client isolation in.

Client isolation turned out to be a huge advantage back in the days were WiFi used to be unsecure and inefficient. By prohibiting the communication between the clients, you reduce the amount of multicast and broadcast e.g. caused by mDNS or AirPlay. But is it still a thing? In times of micro segmentation, mDNS-proxys and dynamic multicast optimization there are other things you can possibly use to make your network more efficient. But even if we decide to use client isolation there is a type of deployment where it would cause more harm than advantage: single SSID deployments.

Back then, when I worked at the university, there were seven SSIDs in the air. We reduced that to four. Yes, it’s not single SSID, but let’s imagine a deployment where you are single SSID and I’ll spare you with the political details on why we had to run four. Anyway, we ran into the same problem as a single SSID deployment.We had to serve 25.000 students and 10.000 employees, so we ran a total of four VLANs with a /19 IPv4 and a /64 IPv6 each. This is not even one device per possible user, but as some students are lazy or don’t have classes at the same time and the lease-time is 30 minutes, this works quite well.

We had those VLANs splited over the two main campuses and used one as a guest and the other one as an internal VLAN. On top we had a slowly growing total of 110 institute-VLANs connected to the WiFi-Controllers. Every sub-unit of the university has its own VLAN(s). The span over their building(s) and the subnets are routed on three core-routers. As we attached the WiFi-Controllers directly to the Core, we can offer wireless access to those local VLANs from anywhere on the campus, so e.g. a professor can access his institutes internal fileserver during a lecture, even though he’s not in his office.

The problem you now have is that you can’t turn on client isolation, as it can only be enabled on a per-SSID basis. You can either have that massive broad- & multicast load or you break communication in the institute-VLANs. There is no other option than keeping client isolation disabled, but I managed to workaround that. At first, I enabled a bunch of features that would convert most of the multi- & broadcast to unicast. As this only works for Aruba and not for the old HPE MSM hardware that’s still in use, so this is not applied everywhere. But there are only 250 of 2100 APs left, so this problem will solve itself over time.

Disabling the 1-11Mbit/s data rates is also another way of optimizing the multicast and broadcast. WiFi works like a hub – it is believed that all connected devices and all not yet connected devices should be able to receive a transmission, so the AP settles for the lowest data rate he knows. With legacy configuration that would mean 1Mbit/s. By disabling the 802.11b data rates you can speed the multi- and broadcast up to 12Mbit/s. This is highly recommended in high density areas.

The second part of the workaround is widely referred to as micro segmentation. It is the plan to create user-roles with rules that prohibit Layer 3 traffic between the clients of a subnet. This is not hard to do but you always must keep that up to date, if some of the IP-Ranges change. On top of this there is a thing Aruba calls “Airgroup”, which basically is a mDNS proxy that reduces the load of multicast in the overall network and can control with which devices another device can talk. This means, that you can create a private segment for each user, in which he can use AirPlay, his printer and so on.

In general, I would like to see vendors to implement something like “role-based client isolation” which would make it a lot easier to create such an environment as described above. Another thing could be an option to make that user-based, so all devices that a user owns can still talk to each other. Overall all current options are still not perfect, but what is? In my opinion this is a good way to implement single SSID deployments.