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.
- 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
- 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)
- 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
- VLAN Tagging:
- 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)
- 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
- If the SSID uses NAT mode, then a policy will only be applied if a splash page is configured to do so
- 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.
- 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
- 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
- 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)
- 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)
- 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
- 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.
- 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
- 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
- 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
- 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
- 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.
- 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)
