Wireless client isolation - how does it work, and can it be bypassed?
The implementation that I've seen of this is done by fiddling with the MAC forwarding table on the access point. Since the access point simply acts as a network bridge, it is fairly well suited to this kind of task. At the switching layer it is already collecting all of the heard (sometimes called learned) MACs and which interface it can be found on.
The logic looks kind of like this:
- Access Point receives a packet over the wireless interface
- Bridging subsystem examines packet for destination MAC
- If destination MAC is in the learned switching table for wireless interface -> DROP
- Otherwise forward packet via wired interface
Because of the way network bridges work I see this being fairly difficult to trick the access point into forwarding a packet to a client in spite of the isolation. Your best bet would be to attempt to talk directly to the other client, as if you were operating with an ad-hoc network.
Wireless client isolation, how it works and how it's bypassed:
When you establish a wireless (wpa/wpa2-aes/tkip) connection to your access point (AP/router) 2 keys are created, a unique key for unicast traffic and a shared key for broadcast traffic which is shared with every pc that connects, known as the GTK.
When you send data to the AP it's encrypted with your unicast key. The AP then decrypts this and uses the broadcast GTK to send the data to the next system on the wireless network.
When you enable client isolation on the AP it stops using the GTK to send data. Because everyone establishes a unique unicast key to send data with you will no longer be able to see eachothers data.
Bypassing this takes a little more effort and understanding. Know that ARP traffic still gets broadcasted across the network using the GTK so that DHCP can maintain clients.
If the ARP table is poisoned with a broadcast MAC on the clients entry you will force the clients system to use the bradcast GTK when sending data. If the clients system is fooled into using the GTK to send data it can now be seen and you will bypass the client isolation.
Thus, if you set your local static ARP entry using the clients ip with a bradcast mac your local system will think its sending broadcast traffic when talking to that client and use the GTK allowing the client to see your traffic.
It will take about two minutes for DHCP to fix a poisoned ARP entry so you will have to write a program that streams poisoned/fake ARPs to maintain visability.
I acknowledge that some advanced APs have arp control and layer 2 isolation where advanced tactics are needed but we're not talking about those guys were talking about your SOHO.
Cheers.