SSID isolation option removed/missing from OC200
SSID isolation option removed/missing from OC200
Just discovered the option to isolate an SSID does not exist in the OC200. Was this an oversight or intentional?
This is a critical feature in my network.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi,
We have replaced the SSID isolation with guest network in Controller 3.1.4. For the guest network function, there are two functions:
1) SSID Isolation. The wireless clients connected to the SSID cannot communicate with eath other.
2) To block clients from accessing private IP subnet. All the clients connected to the SSID cannot access the private subnet.
So if you want to use the SSID Isolation, you can enable the guest network function.
- Copy Link
- Report Inappropriate Content
Glad to know the feature is still there.
"Guest Network" is not as clear as "SSID Isolation" since "Guest Network" is a term consumer WiFi routers use to create a separate SSID for the guest network. The name of the "Guest Network" is ususally "ssid_guest".
In my case SSID Isolation is used to isolate SSIDs that service specific sub-groups of users. I can live with the new label as long as the functionality behind it does not change.
Thanks.
- Copy Link
- Report Inappropriate Content
I request that separation of client isolation and guest mode be made!!!!
We assign dhcp addresses via mac to our internal users and they NEED to be able to traverse our internal subnets that are all using private address spaces. Visitors get assigned dynamic addresses and lan access is handled by the firewall, which by definition is it's job.
This seems like such a tiny tweak as there are no new features, just a separation of them.
Thanks
- Copy Link
- Report Inappropriate Content
Thank you for your feedback, we want to know more details about your network demand so that we can evaluate this feature.
If possible, tell us more details. Thank you.
- Copy Link
- Report Inappropriate Content
mymlact wrote
I request that separation of client isolation and guest mode be made!!!!
We assign dhcp addresses via mac to our internal users and they NEED to be able to traverse our internal subnets that are all using private address spaces. Visitors get assigned dynamic addresses and lan access is handled by the firewall, which by definition is it's job.
This seems like such a tiny tweak as there are no new features, just a separation of them.
Thanks
@forrest Yes, this is exactly what I want too!
I have a network assigned to a VLAN and want to block communication between clients on that VLAN, while still allowing access to other networks. The other access is controlled by my firewall.
- Copy Link
- Report Inappropriate Content
Dear forrest,
since mymlact didn't reply so far, I'll chime in because we have a similar network setup.
The guest network setting installs an (invisible) ACL which denies access to any private IP.
In our hotspot systems we use VLANs and separated networks for guests and for employees of, say, a hotel.
Access policies are:
- Guests should be denied access between wireless clients in the same subnet. That's what Client Isolation does.
- Guests should be denied access to other subnets, e.g. to the employee's subnet. This is what our gateway's firewall manages.
- Guest need access to our Wireless Captive Portal running on our gateway which as a multi-homed host has an interface in the guest VLAN.
- Employees should be denied access between wireless clients, too. That's what Client Isolation does.
- Employees should be allowed to access stationary devices (e.g. accounting systems) in the same subnet. That's what our firewall manages.
- Hotel manager using a stationary device in the same subnet needs access to all employees tablets. That's what our firewall manages.
- OC200 runs in the mgmt VLAN which is used to be the network all EAPs and switches are located. Our firewall usually denies access to this mgmt VLAN.
- If Omada portals are used, guests need access to OC200. That's what our firewall allows if requested by the customer.
Now, setting Guest Network to isolate clients prevents access to private IPs. This interferes with access policies 3., 5., 6. and 8.
When Omada controller did change the »Client Isolation« setting into »Guest Network«, some of our customers using Omada software controller on their own systems complained about their hotspot not working anymore. It did cost me 4 hours until I found out what had happened and even more time to find an acceptable solution to work around this limitation.
Obviously, the work-around is to set an »Allow« ACL for OC200, right?
Oops. What the Omada Controller User's Guide doesn't tell you is the side effect of creating an explicit »Allow« rule:
It will only allow access to the networks listed in this ACL. Thus, clients do not have access to the Internt anymore!
Ok, so we do it in the way it was done in previous controller versions. You can use the following »Block« rule to block access to private networks and allow access to a specific device by excluding it from blocking. This works in all versions of Omada Controller from V2.x to V3.x:
Now, in my opinion it's cumbersome to add such ACLs for all subnets/VLANs in use.
What's more, the blocking done in »Guest Network« setting becomes obsolete with such an ACL.
Thus, my feature request:
- Keep the »Guest Network« setting for home users who want an »one-click plug-n-play« button to create a guest network.
This setting can enable client isolation and install ACLs in the same way it does already.
- Re-introduce a separate setting »Client Isolation« for professional users.
This setting should just enable client isolation between wireless clients and nothing more.
Pro users hate such »smart« features doing things under the hood and taking over control of things like access policies.
Both settings can co-exist. You don't even have to add any code for this, just a setting in the web UI.
Thanks very much for your consideration.
- Copy Link
- Report Inappropriate Content
R1D2 wrote
You have to create a »Block« ACL explicitely and list the subnets to which access should be allowed as »Excluded subnets«:
Ah! This works perfect for me! Although I didn't follow it exactly.
Rule Name: Client Isolation Rule Mode: Block Subnets: 10.0.50.0/24 (My Guest VLAN is 50 and this is the same network they get assigned to) Exclude Subnets: <blank>
I then assigned it to my guest wifi SSID which is assigned to VLAN 50 and I was good to go! Now communication between hosts on the same VLAN is blocked, and traffic to other hosts on the network (Different VLANs) are handled by the router. Excellent.
Edit: I spoke too soon. A lot of traffic on the VLAN is being properly blocked. For example I can no longer access my printers management web page, but some is not. I have two macs on the same AP/SSID, and they are able to connect to web and ssh services across eachother. I'm baffed as to why that is.
- Copy Link
- Report Inappropriate Content
rockin wrote
I have two macs on the same AP/SSID, and they are able to connect to web and ssh services across eachother. I'm baffed as to why that is.
Did you enable »Guest Network«? If so, wireless clients should be isolated (you cannot exclude specific wireless clients from this isolation).
- Copy Link
- Report Inappropriate Content
R1D2 wrote
Did you enable »Guest Network«? If so, wireless clients should be isolated (you cannot exclude specific wireless clients from this isolation).
Yeah so I tried it both ways.
With Guest Network off (what I did above), I can set an ACL to block the same subnet as the network but it appears to only block isolate clients on the same band and allows traffic for clients connected on the same AP. The printer was connected at 2.4Ghz, which is why I think communication was blocked, and the two macs were on the same AP at 5Ghz, which is why I think they were still able to communicate despite the ACL.
With Guest Network enabled, your solution worked to properly isolate clients. I set a Block rule and excluded the network the DNS server is on, which allowed the firewall the properly filter the traffic. As unintuitive as it is, it worked. If TP-Link doesn't change this behavior, they should probably update their FAQ on How to set Access Control to create guest SSID FAQ for the new method.
My "guest" network is just an "untrusted" network, which is why the printer is there but I have rules to allow the trusted network to acces it for printing. I think the solution is for me to move the printer to the trusted network, enable the Guest Network setting for the untrusted network, and follow your solution to allow access from the untrusted network to other internal networks.
The Block > Exception requirement is pretty unintuitive, and I don't like that it creates invisible ACL's to do it. The interface and set up is already very simple compared to other solutions I've used (Looking at you, Aruba Controller), so I would appreciate if the interface allowed you to see and edit these rules manually if necessary.
Also, one thing to be aware of is that changing the ACL rule doesn't take effect immediately. If I change the ACL in Wireless Control, I had to go to Wireless Settings > SSID (Edit) and click Apply without changing anything else for it to take effect on the network.
- Copy Link
- Report Inappropriate Content
rockin wrote
Yeah so I tried it both ways.
With Guest Network off (what I did above), I can set an ACL to block the same subnet as the network but it appears to only block isolate clients on the same band and allows traffic for clients connected on the same AP.
There is only one way to use this work-around: you need to check »Guest Network« and define an »Exclude Subnet« in a »BLOCK« ACL at the same time.
Client isolation is a setting in the WiFi chip. It will isolate all clients from each other in the same frequency band (that means when WiFi frames don't leave the radio's interface). It will not isolate clients in another frequency band (b/c that involves forwarding of frames between two bridged radio interfaces).
Guest network turns on client isolation and also blocks all private IPs. This blocks IP traffic (and only IP traffic!) from clients in one band to clients in another band, as well as to clients in the wired network.
To allow traffic from wireless clients to selected wired devices you would block any private IP addresss (just that there is an entry to be able to set the exclude setting) and exclude the appropriate IP(s) for the device(s) which should not get blocked (e.g. your printer). This ACL applies to both, wired devices and devices across frequency bands. But it does not apply to devices in the same frequency band for the reason explained above. The latter also applies to a single »Client Isolation« setting.
If you set a rule to exclude a whole subnet from blocking (e.g. by blocking 192.168.0.0/16, but excluding 192.168.1.0/24) you allow traffic from any device in the 192.168.1.0 network to any other device in the same subnet if traffic involves bridging or forwarding, but clients in the same wireless band (e.g. 2.4 GHz) are still isolated from each other.
Also, one thing to be aware of is that changing the ACL rule doesn't take effect immediately. If I change the ACL in Wireless Control, I had to go to Wireless Settings > SSID (Edit) and click Apply without changing anything else for it to take effect on the network.
Can't second that. If changing an ACL, it will take effect few seconds later after it has been transferred to and configured by the EAP.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 9456
Replies: 12