Organization-wide Group Policy Troubleshooting
Enforcement Targets
How do they work?
An Enforcement Target defines the "who" or "what" the policy applies to. Please note that rules are enforced by the MX, meaning the MX must be routing the traffic for the policy to take effect.
Enforcement Targets and Their Behavior
When you attach a ruleset, rules with “Any” as the source, the ruleset will use the Enforcement Target as the source.
VLAN
The policy applies to any packet within the specified VLAN(s).
SGT (Security Group Tag)
The policy applies to any packet carrying the specified SGT.
Note: A policy can only have one SGT as an Enforcement Target.
When both VLAN and SGT are selected
The policy will apply to any packet within the selected VLAN, and untagged packets will be tagged with the specified SGT.
Example
Suppose you configure a policy with enforcement target VLAN 10 for two different networks:
- Location 1: 10.10.1.0/24
- Location 2: 10.10.2.0/24
When I attach a ruleset, the rules that have an "Any" as the source, the Dashboard will automatically fill in the subnets. So if I have a rule like this:
| Rule | Action | Source | Destination |
|---|---|---|---|
| 1 | Deny | Any | 1.1.1.1/32 |
For Location 1, the MX will enforce the following:
| Rule | Action | Source | Destination |
|---|---|---|---|
| 1 | Deny | 10.10.1.0/24 | 1.1.1.1/32 |
For Location 2, the MX will enforce the following:
| Rule | Action | Source | Destination |
|---|---|---|---|
| 1 | Deny | 10.10.2.0/24 | 1.1.1.1/32 |
If we added another VLAN for Location 1 as an Enforcement Target, for example Location 1 - VLAN 11 (10.11.1.0/24), the Location 1 MX would enforce the following:
| Rule | Action | Source | Destination |
|---|---|---|---|
| 1 | Deny | 10.10.1.0/24 OR 10.11.1.0/25 | 1.1.1.1/32 |
Note: An Enforcement Target can belong to only one policy at a time.
If you attempt to select an Enforcement Target that is already attached to a different policy, a warning will appear.
Example: In the image below, we are adding an Enforcement Target to a policy named Workstation. When attempting to select Retail Store 3 - VLAN 2, an alert appears because this VLAN is already associated with the Guest Internet Access policy. Proceeding by clicking Save will remove the VLAN from the previous policy ("Guest Internet Access") and reassign it to the new Workstation policy.
Rules & Rulesets
Empty Rulesets
If a ruleset is empty when it is attached to a Policy, the ruleset will emit an allow any source to any destination rule. Please visit the User Guide for more information on configuring Rulesets
Rule Combinations
When configuring firewall rules in the Cisco Meraki MX, you can specify multiple types of destination criteria within a single rule, including:
- IP Address/Subnet (CIDR)
- Policy Objects & Groups (single IPs, IP ranges, or CIDR blocks)
- VLANs
- Internet & SaaS Resources (Layer 7 Applications)
- Ports and Protocols
- etc..
How Rule Matching Works
The MX firewall uses a logical combination of criteria to determine how traffic is matched:
- AND Logic (5-Tuple):
- Source AND Destination(s) AND port(s), AND protocol(s). All these fields must match for the rule to apply.
- OR Logic for Destination Types:
- IPs OR objects OR Application. The rule matches traffic to any of those destinations.
Example
Rule Configuration:
Matching Logic:
- Traffic from any source is evaluated (Remember: Rules apply to the Enforcement Target, so if my Policy is applied to VLAN 2, this rule would look at ANY source from VLAN 2)
- The rule will match traffic if the destination is any one of the following:
- IP address
1.1.1.1 - Any address within the
Employee Subnetgroup - Devices in VLAN
Retail Store 1 - appliance (1) - Traffic destined for Gmail (application-level match)
- IP address
- The traffic must also use TCP OR UDP protocol and be within the port range 1-65535.
- All criteria (source, destination, port, protocol) must be met (AND logic).
- Within each destination type (IPs, Groups, VLANs, Apps), traffic matches if it fits any of the listed options (OR logic).
Special Considerations
- Layer 7 Applications & Ports:
- If a rule combines Layer 7 applications (e.g., Gmail) and specific ports, both the application and the port must match for the rule to apply.
- For best results, it's better if the rule only contains Layer 7 application(s) without specifying port/protocol
- Multiple Protocols:
- Selecting multiple protocols will result in matching traffic for each protocol independently.
Understanding Layer 7 Rules in your Ruleset
When creating firewall rules with Organization-wide Group Policy, you are able to create rules with both IP and Layer 7 Applications. When you add Layer 7 rules, it is expected that a small number of packets may pass through the firewall before being classified. This will also apply subsequent firewall rules. This occurs because NBAR (Network-Based Application Recognition) requires several initial packets to accurately identify the application traffic. For classification purposes, up to 7 packets or a total of 2000 bytes may be allowed before enforcement begins. Please see the example below for details.
| Rule | Action | Source | Destination | Behavior |
|---|---|---|---|---|
| 1 | Deny | Any | 1.1.1.1/32 | Packets are dropped immediately; no classification needed. |
| 2 | Deny | Any | 2.2.2.2/32 | Packets are dropped immediately; no classification needed. |
| 3 | Deny | Any | Application X | Up to 7 packets or 2000 bytes may pass for classification before enforcement. |
| 4 | Deny | Any | 4.4.4.4/32 | Up to 7 packets or 2000 bytes may pass for classification before enforcement. |
What to Expect:
- IP-based rules (e.g., Rules 1 and 2): All packets matching the rule are denied instantly—no traffic is allowed.
- Layer 7 applications and subsequent rules (e.g., Rules 3 and 4): The MX may temporarily allow up to 7 packets or 2000 bytes to classify the application before denying further traffic.
This brief allowance is normal and necessary for accurate traffic identification. Once the application is recognized, enforcement of the Layer 7 rule is immediate, and no additional packets are permitted.
Firewall Logging Live Tool
To access the firewall logging live tool navigate to Security & SD-WAN > Appliance Status, from there, click on the Tools tab and look for Firewall Logging Live tool. In this case you will see my rules are blocking traffic going to a Google DNS server. My Organization-wide group policy is applied to VLAN 2 of my network. The Rule # column will show you the VLAN ID. Note, in the future this may change and this article will be updated.
Organization-wide Group Policy vs Network-wide Group Policy
- What is Organization-wide Group Policy?
- Organization-wide group policy is a new feature introduced with MX firmware version 26.1.2. This feature allows you to manage Layer 3 and Layer 7 firewall rules at an organization level. This features makes it easy to build a consistent Firewall policy at scale.
- What is Network-wide Group Policy?
- Network-wide group policy is an existing feature. It allows you to make custom configurations for all Meraki products to varying degrees. Each product allows specific settings and some products have overlap in supported feature set. This configuration only exists at the network level. There are various ways to apply group policy. For more information please visit this article.
- Can you use both types of Group Policy?
- You cannot use both an Organization-wide Group Policy (Security > Group Policy) and a Network-wide Group Policy (Network-wide > Group Policy) when applied to a VLAN or to assign an SGT.
-
- When a VLAN is configured with an Organization-wide Group Policy, the option to change the group policy is locked until the VLAN is removed from the Organization-wide Group Policy.
- Additionally, when an Org-wide Group Policy is applied to a VLAN, you are not able to manually assign an Adaptive Policy group (SGT).
The image below shows an example of what you will see an an Org-wide Group Policy is applied to a VLAN. This is the VLAN configuration view:
Adaptive Policy
SGT and Network-wide Group Policy
Within a Network-wide Group Policy (Network-wide > Group Policy) it's possible to assign an SGT. With the introduction of 26.1, the MX is able to map an SGT to the Group Policy and enforce on the configured rules. For Org-wide Group Policy, this means we can enforce Layer 3 or Layer 7 destinations based on the packets SGT.
Warning:
Before using Organization-wide Group Policy with an SGT as an Enforcement Target, ensure that your Network-wide Group Policies do not overlap with SGT assignments. Overlapping policies may result in indeterminate or unpredictable behavior.
Below is an example of Adaptive Policy settings which will conflict. On the left we have a group policy with the SGT 10 and firewall rules that allow any source to any destination. On the right we have org-wide policy with a very specific set of rules. If the network MX has both of these configured it's possible that it will result in either the Network-wide Group Policy OR the Org-wide Group Policy. Considering the nature for firewall rules, it's recommended to remove the overlapping configuration.
SGT as an Enforcement Target
When Security Group Tags (SGTs) are used as enforcement targets, the MX applies policy rules to any traffic tagged with the specified SGT. This allows for granular control over how network traffic is handled based on assigned SGT.
If an Enforcement Target is configured with both SGT and VLAN criteria, and traffic arrives at the MX without tags, the MX will automatically assign the selected SGT to that untagged traffic.
VLAN
If a VLAN is using an Organization-wide Group Policy, you will be unable to save the configuration if an Adaptive Policy Group is also applied to that VLAN.
