This is huge for Meraki. We have been waiting for this feature for years. While some might scoff at this as it has been available for years with other vendors and platforms. Meraki has been able to develop this feature and package it into a super easy-to-configure and super easy-to-use feature set across most of the Meraki MS switching portfolio. Let’s check it out!
Let’s start with what is a group policy and why we should care. Meraki Group Policies are basically L3 – L7 sets of rules that can be applied to devices in several ways. On MS switches this will allow users to define sets of Access Control Entries at L3 and L4 that can be applied to devices in order to control what they can access on the network. MS Group Policy ACLs can be applied directly to client devices connected to an MS switch on access switch ports. What makes this so important is that in the past we could only apply these policies to wireless devices via MR access points and MX security appliances.
First, what does this look like in the Meraki Dashboard interface?
Go to Network-wide -> Configure -> Group polices. Here we can define the policies that can be applied to all types of network devices. These devices can be connected to wireless networks, VLAN’s on MX security appliances, and now individual switch ports.
Second, let’s look at what is inside one of these group policies. From an MS switching perspective we are mainly interested in the L3/L4 information contained within the Layer 3 Firewall configuration. This allows us to define what specific devices connected to a port will and will not be able to get to. In the below example you see that I have created an L3 Firewall Rule that will Deny ICMP traffic fro Any to a destination of 1.1.1.1/32.
Once the Group Policy is in place we will need to either create an MS Switching Access Policy or modify an existing one and ensure that the Access Policy will allow the Group Policy to be referenced and applied. To do this go to Switch -> Access Policies.
Above you will notice the new section where you can specify the Radius attribute: Filter-id from the drop-down box. Once this is set the switches in this network will acknowledge and apply a matching Group Policy based on the Filter-id passed back to the switch from a Radius Server. Please note: the Filter-id and Group Policy name must match exactly. If not, this may cause traffic disruption for any matching devices connected to ports where the Access Policy has been applied.
Now let’s explore how we can apply this Filter-id automatically via Radius using Cisco ISE?
Basically we need to modify the Authorization Profile which is used as the result of an Authorization Policy. When logged into ISE go to Policy -> Policy Elements -> Results -> Authorization Profiles. In the below example all I had before was an Access Type = Access_Accept. I added the Filter-ID and matched it to the Group Policy name I had created in the Meraki Dashboard. Caution: I have provided the below screenshot for a reason. There are a couple of ways to configure the Filter-ID. First, is under Common Tasks. Here you can check the ACL (Filter-ID) box and enter the name of the GP-ACL. The problem is that it appends the “.in” to the name. This will not match unless I go back into the Meraki Dashboard and change my Group Policy to include a “.in” at the end of the name. Second, this can be configured under the Advanced Attributes Settings. After selecting Radius and Filter ID you can enter the name of the Group Policy. Once you have that set, click Save.
Yeah, it is that easy! The only thing left to do is a test with client device. You can also verify within ISE by going to Operations -> Live Logs.
In the above screen shots I was able to check the Authentication Detail Report and found that user1 was successful in authentication and the authorization result passed the Filter-ID: GP-ACL-Testing back to the Meraki switch. Success!
Please contact your Meraki Sales team to discuss firmware requirements and to have this added to your lab environments. Since it is not GA yet I would not recommend running this in production.