I would like to revisit this feature request, which was discussed previously here:
[link to previous discussion]
The original discussion took place over a year ago, and as far as I can tell there have been no updates or changes regarding this functionality since then.
It would be highly beneficial to support separate ACL (Access Control List) policies for the Primary, Guest, and IoT networks.
Currently, ACL whitelist mode is applied globally. As a result, any device that is not on the whitelist is unable to connect not only to the primary network, but also to the Guest network. This significantly reduces the usefulness of the Guest network, since guests must be manually whitelisted before they can access the network.
Ideally, each network should have its own ACL policy. For example:
-
Primary network: Whitelist enabled
-
Guest network: Open access or blacklist mode
-
IoT network: Separate whitelist or custom policy
This would allow administrators to maintain strict access control on their primary LAN while still providing convenient Guest and IoT network access.
Another usability improvement would be to allow non-whitelisted devices to associate with the Wi-Fi network while blocking their traffic until they are approved. At a minimum, newly connected devices should appear in the client list and be clearly marked as blocked or pending authorization. Currently, devices that are not on the whitelist never appear in the controller, which makes onboarding and approving new devices unnecessarily difficult.
These enhancements would improve both security and usability, particularly in environments with a large number of IoT devices and occasional guest access requirements.
Hi
We have introduced firewall-based ACL rules in v4.9, which may be helpful for your use case.
For details, please refer to:
Partially.
The new firewall-based "ACL" feature introduced in v4.9 is useful, but it addresses a different problem.
What is currently labeled as "ACL" in the firewall section is effectively a set of firewall rules that control traffic flow between networks and devices. Traditional Access Control on the Clients page serves a different purpose: it controls whether a device is allowed to connect to the network at all, based on its MAC address. I would also expect this mechanism to apply to both wireless and wired clients.
I also think the current terminology may cause some confusion. Referring to firewall rules as "ACL" in the UI makes it difficult to distinguish between network access control (allowing or denying devices from joining the network) and traffic filtering (controlling what connected devices can communicate with). While ACLs and firewall rules are related concepts, they serve different functions in this context, and clearer naming would help users better understand which feature addresses which use case.
The issue raised in this feature request is specifically about connection-level access control. At the moment, MAC-based whitelist mode is applied globally across all networks. This means that if whitelist mode is enabled to protect the primary LAN, guest devices must also be manually approved before they can even connect to the Guest SSID, which defeats much of the purpose of having a guest network.
A more flexible approach would be to allow separate access control policies per network, for example:
- Primary network: MAC whitelist enabled
- Guest network: Open access with client isolation
- IoT network: Separate whitelist or custom policy
Firewall rules can then be used as an additional layer to restrict communication between those networks.
Without per-network access control policies, the current whitelist feature becomes difficult to use in environments where strict LAN access control is required while still allowing convenient guest and IoT device onboarding.
Hi
Thank you for the additional clarification and your suggestion.
We will discuss it further with the product team.