Group policies on MS switches allow users to define sets of Access Control Entries that can be applied to devices in order to control what they can access on the network. MS Group Policy ACLs can be applied to clients directly connected to an MS switch on access switchports . This article provides the details of the MS switch platforms that support Group Policy ACLs and explains how Group Policy ACLs can be created and how they are applied to clients.
Please reach out Meraki Support to have the feature enabled in our Meraki Dashboard Organization.
Requirements, guidelines and limitations
- Hardware and software requirements: Group Policy ACLs for MS Switches are supported on the following platforms and firmware versions
MS Switch Family MS Switch Model Minimum Firmware Required MS200 series MS210 MS 14.5 MS225 MS 14.5 MS250 MS 14.5 MS300 series MS350 MS 14.5 MS355 MS 14.5 MS400 series MS410 MS 14.5 MS425 MS 14.5 MS450 MS 14.5
- Group Policy ACLs enable the application of the Layer 3 Firewall rules in a group policy on the MS switches within the network. The other configuration sections of the group policy will not apply to the MS switches, but will continue to be pushed to the devices in the network, such as the MX appliance and MR access-points, to which they are relevant.
- RADIUS authentication: Group Policy ACLs on MS are applied through client authentication Access Policies and, therefore, require a RADIUS server. Static assignment of a group to a client for Group Policy ACL application is not possible on MS switches.
- Access-Policy host-modes supported by Group Policy ACLs include single-host, multi-auth and multi-domain; Application of Group Policy ACL to a client authenticated by an access-policy using multi-host mode is not supported.
- Group Policy ACLs on MS cannot be applied to clients connecting on trunk ports.
- The recommended limits for Group Policy ACLs are :
- Maximum number of active Access Control Entries per switch at any time: 600 lines
- Maximum number of active groups per switch at any time : 20 groups
- Group Policy ACLs on MS switches are implemented as stateless access control entires.
- Group Policy ACL rules will take precedence over Switch ACL rules (configured from the Switch > ACL section) on and only on the switch where the client has been authenticated.
How it works
Group Policy ACL on MS switches are designed to work with RADIUS authentication, to allow access control lists to be dynamically applied to client traffic based on the role the RADIUS server associates with the client. The illustration below summarises the functional process.
Here is a more detailed look into the Group Policy ACL implementation shown in the illustration above.
- We start by classifying the client devices in the network into Groups and defining the Access Control List rules to allow or deny traffic from these groups to specific destinations. We then configure these groups and the rules associated with them on the Meraki Dashbaord from the Network Wide > Group Policies page (see Create a User Group and ACL rules for details on the configuration process).
Group Policy ACLs use the Filter-Id attribute in RADUIS authentication to identify the group a client device belongs to and so, next, we enable our access-policies to use Filter-Id as the criterion for classifying devices into groups. (see Configure Access Policy to use Filter-Id for details).
- The configuration changes made in step 1 are uploaded to each MS switch in that network on the next configuration sync. This ensure that all the MS switches in your network have the same understanding of who connects to our network and how their traffic should be regulated, thus, allowing these devices to move between RADIUS-authenticated switch-ports without the need for changes to any ACL related configuration on the Dashboard.
- Each switch maintains a copy of all the groups in the network along with their ACL rules. However, a group is considered active on a switch only if at least one authenticated client device in that group exists on that switch. Conversely, when the last client device belonging to a group active on a switch disconnects or de-authenticates, the group is marked inactive on that switch. The total number of groups active on a switch at any point in times should be within the limits stated in the Guidelines and Limitations section.
- As mentioned earlier, it is the RADIUS server which determines which group a client device belongs and it communicates this information to a switch using the Filter-Id attribute. Therefore, we also configure the RADIUS server to send back a case-sensitive Filter-Id value identical to the name of the group the device being authenticated belongs to.
- When a new device is detected on a switch-port configured with an access-policy, the switch initiates communication with this device to collect credential required to verify its identity with the RADIUS servers.
To be able to identify the group this new device belongs to, the access-policy applied on this switch-port should be enabled to use Filter-Id, as described in step 1.
- Switch checks with the RADIUS server to determine whether the client device should be given access to the network. If the RADIUS responds with an Access-Accept, validating the device's access to network, it must include the Filter-Id attribute in its response for Group Policy ACLs to work.
- On receiving the Access-Accept message from the RADIUS server, the switch binds the client device to the group with the name matching the Filter-Id value in the RADIUS response. If the group is current active on the switch, or if the number of groups active on the switch is less than the maximum supported value, the client device is allowed access to the network with its group's ACL applied to its traffic.
If the Filter-Id attribute is missing, the client is allowed access to the network with no Group ACLs applied. But if the Filter-Id value does not match a group name on the switch, or if the Filter-Id is matched against a group not currently active and the total number of active groups is already equal to the maximum supported value, the switch will successfully authenticate the client device and all traffic from it will be dropped.
Enabling MS Group Policy ACL in your network
The procedure for enabling Group Policy ACLs can be broken down into the following steps.
Create a User Group and ACL rules
- Navigate to Network-wide > Configure > Group policies
- Click Add a group to create a new policy.
- Provide a Name for the group policy. Generally, this will describe its purpose, or the users it will be applied to. Ex. "Guests", "Throttled users", "Executives", etc.
- Select Custom network firewall & shaping rules in the drop-down menu for the Layer 3 firewall option and click on Add a firewall rule to add an access-list entry.
- When done, click Save Changes.
Configure Access Policy to use Filter-Id
- On the Dashboard navigate to Configure > Access Policies.
- Select the access policy you want to modify or, to add a new policy, click on the link Add Access Policy in the main window, then select my RADIUS server from the drop-down menu for Authentication method.
- Enable RADIUS attribute specifying group policy name by selecting Filter-Id from the drop-down menu.
- Select the other options, as required. For details on configuring other options of the access policy refer to Creating an Access Policy on Dashboard
- Click Save changes