Do multiple Group Policies stack ??

[AaronKennedy]

I have an SSID that is set up with an Active directory splash page. When a user connects to that wireless network and is prompted for credentials, a group policy will be applied based on their AD group membership. This works exactly as expected.

However, some devices within a particular group require different settings, so after the user has connected that device and signed on through the splash page, I go to the client page in Dashboard and manually apply a different group policy. This policy also works as expected.

But... elements from the original group policy that was assigned based on AD group membership seem to still be in effect (especially appended URL blacklists and DNS/IP based layer-3 firewall rules). It is as if the policy that was applied manually in the Dashboard is simply being applied ON TOP of the policy that was assigned during sign-in to the wireless network.

Is this the expected behavior? Do manually applied policies stack on top of automatically applied policies, or should a manually applied policy completely override any policy that was assigned automatically based on AD group membership (or VLAN membership)?

[PhilipDAth]

I don't know the answer for sure.

Many of the items in the group policy allow you to override or replace.  I would say if you use those they should take precedence in the most recently applied policy.  If you are not using one of these two options then I would expect any previously applied policy option to still be in effect.

[AaronKennedy]

OK... here is a scenario with using different group policies

• Group Policy #1 has 'append' set for Blocked URL patterns and the list contains roblox.com. As long as Policy #1 is being applied to a device, then roblox.com will be blocked on that device.
• I then apply Group Policy #2 to the device. Policy #2 has 'Use network default' set for Blocked URL patterns. However, because Policy #2 does not specifically overwrite any existing blocked URL patterns, roblox.com is still blocked because Policy #1 had previously appended it to the blocked URL list.
• But if I apply Group Policy #3 to the device and this third policy says to 'override' the Blocked URL patterns with youtube.com, I should find that roblox.com now works on that device, but youtube.com no longer works.

This would be consistent with the behavior I have witnessed.

But let me change the order of things a bit.

• A device has Group Policy #1 applied to it and roblox.com is blocked as a result
• I then apply the 'normal' template to the device.
• Finally I apply Group Policy #2 to the device. Now roblox.com should work on the device because the intervening application of the 'normal' template wiped out any customization that had been applied by Group Policy #1.

I will have to attempt this and see if the resulting behavior is actually as I have described.

[Seshu]

Hello @AaronKennedy 

Thank you for the detailed description. There are certain things that you need to make sure when Group Policies are concerned - 

1. If you are applying a specific dashboard Group Policy in a combined network and not a Custom value in the client details page, then MX and MR in that network will apply the Policy and process the traffic at both the levels. 

2. If a Splash based policy is applied by the MR, then it would be only on the MR and similarly if the MX is applying Splash based policy, it's only on the MX. 

3. There may be multiple policies applied at each level (MX/MR) for a single client. These will each be with different priorities. So, the highest priority will be the only one taking affect at any given time for a client on an MX or MR. For example, blacklisting has the highest priority, whitelisting comes after that, dashboard level specific group policy comes next, AD comes after that... and so on. The network default will have the least priority.  

So, to answer your question whether or not there will be multiple policies taking affect for a client, the don't. At each level (MX or MR), only 1 policy will be active and packets are processed based on it. However, it is possible that some traffic is blocked by MX and some by MR due to the policy types that are being applied by Splash AD Integration and dashboard selection. 

I would recommend opening a support case if you have an active client that is displaying this behavior. Our team can definitely confirm where what is getting blocked.

Let me know if you have any questions.

Regards,

Meraki Team

[AaronKennedy]

Thanks for the suggestion to open a support case.  If I ever need to tunnel down and find out where different things are happening, I will be sure to do so.

It never occurred to me that different devices (MX vs. MR) could be applying different policies. I just assumed the MR was a 'dumb' WAP and all group policy was applied by the MX at the MX. But I understand why you would want to apply rules at the AP instead of having the traffic traverse the internal network first. It just makes sense.

However, right now I am just trying to teach myself the ins and outs of group policy. The policies I have created in my production network are working just fine, but the method I have devised for applying them involves a lot of monitoring and manual changes. I am looking for a way to make the process more automatic and 'hands-free', so I am experimenting with things like...

• AD integrated splash page to set different policies for different clients
• Using the RADIUS splash page and the filter-id attribute to push different clients into different policies
• Setting VLAN-based policies on the MX
• Manually assigning custom policies using the client page in Dashboard (this is what I want to avoid)

At the moment, I am just exploring and trying to understand the behaviors I am seeing. If I understand why something happens the way it does, then I am closer to my goal of knowing how to set things up the way I want.

[AaronKennedy]

I spent a week testing group policies in multiple scenarios and learned this about policy priority (sorry for the length)...

SSID Rules

These are the first rules to be applied to traffic, and therefore have the lowest priority. There are a limited number of globally applied elements that will be effective if set at this level.

1. Layer 3:  These rules are restricted to IP addresses (in CIDR format) with port targeting. Best used for controlling access to the local network, but can be used to block IP addresses on the internet as well.

         THESE RULES CANNOT BE OVERRIDDEN BY HIGHER PRIORITY GROUP POLICIES

1. Layer 7:  These rules can be used to block (Meraki’s) layer 7 categories, but can also block specific URLs, public IP addresses (in CIDR blocks), or individual TCP/UDP ports.

         THESE RULES WILL BE IGNORED IF A POLICY IS ASSIGNED MANUALLY (even if that policy has no layer 7 rules)

1. Bandwidth:  These rules can be used to set global bandwidth limits for the entire SSID and individual bandwidth limits for clients.

       THE *SSID* BANDWIDTH LIMIT CANNOT BE CHANGED BY HIGHER PRIORITY POLICIES

       THE *DEVICE* BANDWIDTH LIMIT CAN BE LOWERED BY HIGHER PRIORITY POLICIES

1. VLAN Tagging: 
   1. If the SSID tags the device with a VLAN managed by a device downstream of the MX, then no policy will be applied (only ‘network default’ settings and the rules listed above)
   2. If the SSID tags the device with a VLAN that is managed by the MX but there is NO group policy assigned to that VLAN, then only ‘network default’ settings will be applied
   3. If the SSID uses NAT mode, then a policy will only be applied if a splash page is configured to do so
   4. If the SSID tags the device with a VLAN that is managed by the MX AND there is a group policy assigned to that VLAN, then the VLAN policy will be assigned to the device and it will have higher priority than any policy assigned by a splash page

Splash Page Group Policy (using Active Directory)

These policies have the second lowest priority. They can override some of the SSID rules, and they can override ‘network default’ content filtering that has been set on the MX.

1. Bandwidth:  Lower bandwidth device limits set here will supersede a higher limit set in the SSID rules, but a higher device bandwidth cannot be set.

        THESE DEVICE BANDWIDTH RULES CAN BE LOWERED BY HIGHER PRIORITY POLICIES

1. Layer 3:  These rules can be set to block specific URL patterns, IP addresses (in CIDR format), and even all traffic to specific ports.

         A “DENY” RULE WILL REMAIN ACTIVE AND CANNOT BE OVERRIDDEN BY HIGHER PRIORITY POLICIES

1. Layer 7:  These rules can be used to block (Meraki’s) layer 7 categories, but can also block specific URLs, public IP addresses (in CIDR format), or individual TCP/UDP ports.

        THESE RULES WILL BE IGNORED IF A POLICY IS ASSIGNED MANUALLY (even if that policy has no layer 7 rules)

1. Traffic Shaping:  Layer 7 traffic shaping rules set by this policy will only be applied if this is the highest priority policy that has been assigned to a device.

        THESE RULES WILL BE IGNORED IF A POLICY IS ASSIGNED MANUALLY (even if that policy has no traffic shaping rules)

1. Security Appliance:  Rules set here will be effective and can be used to customize or even override the ‘network default’ content filtering set on the MX.

         THESE RULES CAN ONLY BE SUPERSEDED BY A POLICY APPLIED MANUALLY TO DEVICES IN AN MX-MANAGED VLAN

1. VLAN Tagging:  VLAN tagging in this policy will NOT override any settings that were made at the SSID level

        THIS SETTING HAS NO EFFECT IF A SPLASH PAGE ASSIGNS THE POLICY

VLAN Group Policy

If a group policy is assigned to a VLAN on the MX and a device is in that VLAN, then then the VLAN-specific policy will be given a higher priority than a policy assigned as a result of splash page authentication. However, it will function in exactly the same manner as a group policy assigned by a splash page. Only a manually assigned group policy will be given a higher priority.

Manually Applied Group Policy

This is the highest priority policy that can be assigned. Even if this policy tags a device with an MX-managed VLAN that has been given its own group policy, the manually assigned policy will still have the highest priority.

1. Bandwidth:  A limit set here will supersede ANY limit set elsewhere (up to the maximum device bandwidth defined in the SSID rules)

        THIS RULE CANNOT BE SUPERSEDED

1. Layer 3:  These rules are effective and enforced. Any rule set here will be enforced unless a Layer 3 DENY rule from any other policy overrides it.

       A “DENY” RULE WILL ALWAYS SUPERSEDE AN "ALLOW" RULE FROM A LOWER PRIORITY POLICY

1. Layer 7:  These rules can be used to block (one of Meraki’s) layer 7 categories, but can also block specific URLs, public IP addresses (in CIDR format), or individual TCP/UDP ports.

       ANY RULES APPLIED HERE WILL BE APPLIED

1. Traffic Shaping:  These rules will be applied, but the upper bandwidth limit is capped at the lowest applied bandwidth restriction that is currently in place.

        THESE RULES WILL BE APPLIED TO MATCHING TRAFFIC

1. VLAN Tagging: 
   • If a manually assigned policy tags a device with a VLAN that is configured as a subnet on the MX AND the VLAN uses the same group policy, then all features of the group policy will function.
   • If the manually assigned policy tags the device with a VLAN managed by a device that is downstream from the MX, then all features of the policy will function ECXEPT the ‘Security Appliance’ settings.    
2. Security Appliance:  Depends on whether or not the device is in a VLAN managed by the MX.

        THESE RULES ARE ENFORCED IF THE DEVICE IS IN AN MX-MANAGED VLAN

        THESE RULES ARE NOT ENFORCED IF THE DEVICE IS IN A DOWNSTREAM-MANAGED VLAN

Splash Page Group Policy (using RADIUS)

Meraki documentation indicates that splash-based RADIUS authentication will honor the filter-id attribute and apply a group policy to devices during authentication. Unfortunately, I cannot get it to work... but I can confirm that it does work if RADIUS is authenticating via 802.1X. (but that method is not feasible in my environment, so it was not extensively tested)

[GIdenJoe]

Group policies calling other group policies could be a nice feature.

Say you want to authorize a user on your network and give a filter-id, but some of the rules only apply timebased.
It would be handy to call child policies that have different timeranges or additive blocking or allowing rules.

[AaronKennedy]

This is not a scenario that I tested, as I could only get the filter-id attribute to pass a group policy to a device if it authenticated using 802.1X. The majority of devices in my network are BYOD, so 802.1X authentication is not a viable option.

However, if you are using NPS on a Windows server to handle RADIUS authentication, you should be able to set time-based restrictions there and have customized network policies in NPS for passing different group policies depending on day of week and time of day.

[CptnCrnch]

---

@AaronKennedy wrote:

However, if you are using NPS on a Windows server to handle RADIUS authentication, you should be able to set time-based restrictions there and have customized network policies in NPS for passing different group policies depending on day of week and time of day.

---

Not only with NPS, but every other decent (in almost every case more decent) RADIUS server available 😋