When we will see better client isolation

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

When we will see better client isolation

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
When we will see better client isolation
When we will see better client isolation
2023-10-26 21:35:31 - last edited 2023-10-27 06:54:01

Right now one area that the TP-Link AP's aren't strong in is client isolation - something that is pretty critical for hospitality environments.

 

As everybody knows the "guest network" setting is very deceptive and will only prevent layer 3 communication between devices on the same AP. To prevent layer 3 communication between devices across multiple AP's you need to create an EAP ACL rule to restrict access to other IP range(s).

 

There does not appear to be any way to configure proper L2 client isolation - if I run Fing on a network I should not be able to see the MAC addresses of any other devices. This is core functionality across every other brand of WiFi hardware.

 

When will TP-Link focus on these areas? The guest network setting should be fixed so that it does work properly and limit all L3 traffic on the same network, and that capability should also be extended to isolate all traffic at L2 level discovery level as well.

 

  1      
  1      
#1
Options
4 Reply
Re:When we will see better client isolation
2023-10-27 06:34:30

  @WiFiGuy01 

 

Yes, this is the current processing mechanism of omada devices, and I hope they can find an optimization method.

Just striving to develop myself while helping others.
  0  
  0  
#2
Options
Re:When we will see better client isolation
2023-11-17 16:22:25

I also think client isolation is a critical feature in hospitality.

  0  
  0  
#3
Options
Re:When we will see better client isolation
2023-11-17 17:00:25 - last edited 2023-11-17 17:00:47
I also miss the old "SSID isolation" feature.
 
My home network is mainly driven by a MikroTik switch. I have vlan 102 for guests. The switch has the following rule:
/interface ethernet switch rule add switch=switch1 ports=ether7,ether8,ether9 vlan-id=102 new-dst-ports=sfp-sfpplus1
Ether 7 is a wired network port in my guest room that has vlan 102 untagged. Ether 8+9 are trunk ports for my Omada EAPs, they have vlan 102 tagged and the EAP use it for the guest wifi ssid. The switch rule above forces any guest traffic to the uplink port (SFP+), there is no layer 2 switching between different guest ports on my switch.
When I have two guest clients on different switch ports (e.g. one wired and one wireless, or two wireless on different APs) then they cannot communicate, not even ARP, and no IPv6. But two guest clients on the same AP can see each other on layer 2 and via IPv6.
I can use EAP ACLs to block traffic within the same AP for the guest ssid, but this is very cumbersome. For IPv4 it is somewhat ok, but for IPv6 it is not. The beta firmware allows blocking IPv6, but my prefix is dynamic and I would have to change the ACL daily whenever my ISP decides to change the IPv6 prefix.
 
I understand that the old "SSID isolation" feature did not block traffic between different APs, but this is exactly what my switch rule above is for. Please bring back the "SSID isolation" feature and add a note in the GUI that it only blocks traffic between clients on the same AP.
 
Right now I have to disable IPv6 for guests, or create separate vlans + ssids for different guests (which wastes valueable airtime with beacons), or live with poor isolation. Everything sounds bad for soho-equipment that Omada should be.
  0  
  0  
#4
Options
Re:When we will see better client isolation
2023-11-19 04:51:05 - last edited 2023-11-19 04:54:24

Agreed.  Surprising to see this functionality lacking in an 'enterprise' product.

 

Prior to upgrading to the eap670, i ran vlans and different ssid's on a old asus rt-ac68u in ap mode.  Of course none of this functinoality was exposed in the gui. Instead vlans, ssid's and client (both wireless and wired) isolation was done via ebtables (layer 2) to completely insulate one wireless client from another.  It was a pain but doable - this on a device from 10+ years ago!

 

Edit: SSHing into the device reveals the ebtables binary is already present!

  0  
  0  
#5
Options