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:

1. Guests should be denied access between wireless clients in the same subnet. That's what Client Isolation does.
2. Guests should be denied access to other subnets, e.g. to the employee's subnet. This is what our gateway's firewall manages.
3. 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.
4. Employees should be denied access between wireless clients, too. That's what Client Isolation does.
5. Employees should be allowed to access stationary devices (e.g. accounting systems) in the same subnet. That's what our firewall manages.
6. Hotel manager using a stationary device in the same subnet needs access to all employees tablets. That's what our firewall manages.
7. 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.
8. 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.

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

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.