Skip to main content
Cisco Meraki Documentation

Manually Integrating Cisco Umbrella with Meraki Networks

Overview 

Integrating the Meraki dashboard and Umbrella DNS allows clients connected behind Meraki security appliances or access points to have their DNS traffic filtered through Cisco's Umbrella DNS service. 

This integration allows administrators to apply and modify DNS-based filtering rules to multiple groups of clients on their network by assigning a filtering policy to a specific Meraki group policy or SSID. Once assigned, all DNS requests from clients included under that policy will be automatically redirected to Cisco's Umbrella DNS service where it will be checked against the appropriate policy configured for the network device in the Umbrella dashboard

Note: This feature was designed to handle standard UDP-based DNS lookups and does not currently support extended TCP-based DNS lookups on the MX Platform

umbrella_overview_dual_box2_scaled.png

Firmware Requirements

  • MX Platform requires MX firmware version 15.10+.
  • MR Platform requires MR firmware version 26.1+.

Licensing Requirements

  • MX Platform
    • This feature is available for an MX with Advanced Security license
    • Z3 with an Enterprise license (as Z3 does not support Advanced Security license).
  • MR Platform
    • Manual Integration: Enterprise License
    • Automatic Integration: Advanced licenses

Configuring Umbrella DNS Integration

Warning: This integration is mutually exclusive with Automatic Umbrella integration on MR, which requires MR Advanced licenses. If you wish to use the manual MX or MR Umbrella integration in your Meraki organization, please follow the steps below before claiming any MR Advanced or MR Upgrade licenses in your organization or adding the organization to your Enterprise Agreement.

Linking the Meraki and Umbrella Dashboards 

Integrating Umbrella DNS with a Meraki network is a simple process that requires only a few steps. For Umbrella filtering policies to be applied successfully, the Meraki and Umbrella dashboards must first be linked via the Umbrella network devices API key. Once the dashboards have been linked, the Umbrella policies can be properly assigned to the appropriate Meraki SSID or group policy.

Generate the Umbrella API Key 

Before linking the two dashboards, the Umbrella API key and associated secret must first be created on the Umbrella dashboard. This can be done by selecting Admin > API Keys > Legacy Keys > Umbrella Network Devices > Generate Token

If there is no existing key available for the Umbrella Network Devices, select the blue and white plus sign (+) labeled Create at the top-right of the page (see image below). Umbrella Network Devices should be selected by default. If not, select it and click Create. Once the key has been generated, copy both the key and the secret so they can be entered on the Meraki dashboard. Be sure to save the secret in a safe location, as it will only ever be shown once.

If the Umbrella Network Devices API key and secret have already been generated, use the existing information.

WARNING: The Umbrella dashboard will only display the API secret when it is first generated, make sure that you've saved both the key and secret before closing the page.

Umbrella API Creation - New - Edit.png

Apply the Umbrella API Key to a Meraki Network 

Once the Umbrella API key and secret have been generated, they need to be added to the Meraki dashboard to properly link the Meraki network and the Umbrella dashboard:

  • Go to the Network-wide > Configure > General page
  • Scroll down to the bottom of the page and click New credentials under the Cisco Umbrella account header
  • Paste the Umbrella API key and secret in the appropriate fields and click Save Changes

Once this information has been saved, the Meraki and Umbrella dashboards should now be properly linked, allowing Umbrella policies to be applied to Meraki SSIDs or group policies within the current Meraki network. 

NOTE: Umbrella integration is linked on a per-network basis to the Meraki dashboard, so the Umbrella API key and secret must be entered on every Meraki network that requires Umbrella integration. Additionally, the Umbrella network devices API can be linked on a template parent network so that children networks bound to the template can easily leverage the same policies. Meraki networks that are cloned will also retain the API key for easy linking. 

Meraki API Entry.png

Unlinking a Meraki Network and Cisco Umbrella

Once the Meraki and Umbrella dashboards have been linked successfully the currently linked API Key will be displayed at the bottom of the Network-wide > Configure > General page. There is also a checkbox to delete the link between the selected Meraki network and the Umbrella dashboard.

To unlink a Meraki network from Umbrella, check the Delete linked account box and select Save Changes on the Meraki dashboard. Deleting this link between accounts will clear any objects in the Umbrella dashboard that were sourced from this network in addition to any Umbrella policies applied to SSIDs or group policies in the network.

Meraki API Delete.png

Linking and Applying an Umbrella Policy

Linking an SSID or group policy to an Umbrella policy is straightforward once the dashboards have been linked. When a Meraki SSID or group policy is linked to Umbrella, a unique device ID is generated for that Meraki object. An Umbrella policy is then linked to that device ID on the Umbrella dashboard. This device ID is included in any DNS traffic sent to Umbrella and used to specify which Umbrella policy that traffic should be checked against.

NOTE: These Meraki objects can be viewed on the Umbrella dashboard by going to Deployments > Core Identities  > Network Devices. Umbrella Network Devices are automatically created when linking a Meraki SSID or group policy and use the following naming format: <SSID/Group_Policy_name>__<Network name>_-_wireless 

Linking a Meraki Group Policy to an Umbrella Policy (MX & MR)

Create the Group Policy 

Before linking an Umbrella policy to a Meraki group policy, the group policy must first exist in the Meraki dashboard. Group policies can be created by going to Network-wide > Configure > Group policies. Ensure the group policy is set to use Custom network firewall & shaping rules. For more guidance on creating group policies on the Meraki dashboard, check out our more detailed documentation.

NOTE: Before attempting to link the group policy with Umbrella, ensure that the group policy is completely saved on the Meraki dashboard first. 

Link the Meraki Group Policy with Umbrella

From the Network-wide > Configure > Group policies page, select the group policy that should be linked, then select the Link Umbrella policies button located under the layer 7 firewall rules. The Meraki dashboard will then automatically create the appropriate network device on the Umbrella dashboard and apply the default policy to the group policy.

NOTE: Group policies must be set to use Custom network firewall & shaping rules to link an Umbrella policy.

WARNING: If creating a new group policy then the policy must first be saved before it can be linked to Umbrella.

Pre Link Policy to Group Policy.png

Apply an Umbrella Policy to the Group Policy

When first linking a group policy to Umbrella, the default policy is automatically applied. To apply a different Umbrella policy to the Meraki group policy, select the appropriate Umbrella policy from the drop-down menu on the group policy details page, then select Save at the bottom of the page.

If the Umbrella policy does not yet exist, it must first be created from the Umbrella dashboard:

  • Navigate to Policies > Management > All Policies on the Cisco Umbrella dashboard
  • Click Add in the top-right corner and follow through with the necessary policy creation steps

Once the Umbrella policy has been created, it can be applied to the appropriate Meraki group policy from the Meraki dashboard.

Post Link Policy to Group Policy.png

NOTE: The order that policies are listed in Umbrella is important. This can be viewed by logging into the Umbrella dashboard and navigating to Policies > Policy list. When a Meraki group policy is initially linked it will inherit the default Umbrella policy, which will be the last policy in Umbrella's ordered list. This shows in the Meraki dashboard as Default Policy (indirectly applied) because the default Umbrella policy was not specifically selected from the Meraki dashboard. If, for example, an admin were to assign a different policy to a network device (read: Meraki group policy or SSID) in the Umbrella dashboard, that change would be reflected in the Meraki dashboard, however, the policy would still show as indirectly applied because it was not applied from the Meraki dashboard.

Once a policy is assigned to a network device (SSID/group policy) in the Umbrella dashboard, any policies below the one selected for the network device will not be checked against. The policy list in Umbrella is read in a top-down order and once a match is found for the device ID, no other policies will be evaluated. More information can be found in Cisco Umbrella's Policy Precedence documentation. 

Applying the Group Policy to Clients

Apply the Group Policy to Specific Clients (MX & MR) 

To apply the Umbrella filtering policy to specific end clients, assign the Meraki group policy to the client from the Meraki dashboard. Group policies can be applied to clients in various ways, including utilizing an Active Directory integration, or by manually assigning a policy from the Network-wide > Monitor > Clients page. Filter the client list down to the intended client, select the checkbox to the left for that client, then use the Policy drop-down menu to apply the appropriate group policy containing the Umbrella policy to the client.

Refer to our group policy documentation for a more detailed overview of applying a group policy to a specific client.

Apply the Group Policy to a Subnet (MX Only)

When MX Umbrella integration is available, an Umbrella-enabled Meraki group policy can be applied to a subnet of clients. In this configuration, any traffic that passes through the MX with a source IP contained within that subnet will be subject to Umbrella filtering for the Umbrella policy selected in the relevant Meraki group policy.

To apply a group policy to a subnet of clients:

  • Go to Security & SD-WAN > Configure > Addressing & VLANs
  • Select the appropriate subnet from the Subnets list
  • In the accompanying dialog box, use the group policy drop-down menu to select the appropriate group policy and associated Umbrella Policy to apply
  • Select Update, then Save to apply the changes

Refer to our group policy documentation for more detailed information.

Note: If Walled Garden is used in your MX configuration, please be sure to add an Umbrella DNS domain exclusion for the required domain(s). This can be configured by navigating to Security & SD-WAN > Configure > Threat protection.

Linking an SSID to an Umbrella Policy (MR Only)

Create the SSID

Before linking an Umbrella policy to a Meraki SSID, the SSID must first exist in the Meraki dashboard. SSIDs can be enabled by going to Wireless > Configure > SSIDs. For more guidance in creating and configuring an SSID on the Meraki dashboard, refer to the documentation on enabling SSIDs and client IP assignment modes for SSIDs.

NOTE: Ensure that the SSID is completely saved in the Meraki dashboard before attempting to link an SSID with Umbrella.

Link the SSID to Umbrella 

Linking an SSID to Umbrella is done from the Wireless > Configure > Firewall & traffic shaping page, under the Block Applications and Content Categories header for the appropriate SSID. Select Link Umbrella Policies on the appropriate SSID and the Meraki dashboard will automatically create the appropriate network device on the Umbrella dashboard and apply the default policy to the SSID. 

Umbrella integration with MR is currently supported for all client addressing types found under the Access Control page.

Link Policy to SSID.png 

Apply an Umbrella Policy to the SSID

After linking an SSID to Umbrella, the default policy is automatically applied. To apply a different Umbrella policy, select the appropriate Umbrella policy from the drop-down menu on the Firewall & traffic shaping page, then select Save at the bottom of the page.

If the Umbrella policy does not yet exist, it must first be created from the Umbrella dashboard. This can be done by navigating to Policies > Management > All Policies on the Cisco Umbrella dashboard, then clicking Add in the top-right corner and follow through with the necessary policy creation steps. Once the policy has been created it can be applied to the appropriate Meraki SSID from the Meraki dashboard.

Post Linking SSID.png

NOTE: The order that policies are listed in Umbrella is important. This can be viewed by logging into the Umbrella dashboard and navigating to Policies > Policy list. When a Meraki SSID is initially linked, it will inherit the default Umbrella Policy, which will be the last policy in Umbrella's ordered list. This shows in the Meraki dashboard as Default Policy (indirectly applied) because the default Umbrella policy was not specifically selected from the Meraki dashboard. If, for example, an admin were to assign a different policy to a network device (read: Meraki group policy or SSID) in the Umbrella dashboard, that change would be reflected in the Meraki dashboard, however the policy would still show as indirectly applied because it was not applied from the Meraki dashboard. 

Once a policy is assigned to a network device (SSID/group policy) in the Umbrella dashboard, any policies below the one selected for the network device will not be checked against. The policy list in Umbrella is read in a top-down order and once a match is found for the device ID, no other policies will be evaluated. More information can be found in Cisco Umbrella's Policy Precedence documentation. 

Removing an Umbrella Policy from an SSID or a Group Policy

To remove an Umbrella policy from an SSID or group policy, navigate to the Wireless > Configure > Firewall & traffic shaping page for SSIDs or the Network-wide > Group policies > Group policy details page for the appropriate group policy. Under the currently applied Umbrella policy, click Disconnect from Cisco Umbrella followed by Yes in the confirmation pop-up. 

WARNING: Disconnecting an SSID or group policy from Umbrella will delete the associated object from the Umbrella dashboard and unlink any policies applied to that SSID or group policy in the Meraki dashboard. 

Remove Policy - New.png

DNS Traffic Flow

This section of the article describes the expected traffic flow of DNS traffic from clients after an SSID or group policy has been successfully linked to an Umbrella filtering policy.

 

traffic_flow_MR-and-MX.png

 

  1. Client sends a DNS query.
  2. Meraki intercepts the DNS query and attaches an identifier to identify which Umbrella policy this request should be checked against.
  3. Meraki then encrypts the DNS query using DNSCrypt, source NAT's the packet to the MR management IP, and redirects it to the appropriate Umbrella endpoint.
  4. After arriving at the Umbrella endpoint, the DNS query is decrypted and checked against the appropriate Umbrella policy (based on the attached identifier) to determine if it should be allowed or not.
  5. If the request is allowed, Umbrella will return an encrypted DNS response with the appropriate IP.
  6. If the request should be blocked, Umbrella will return an encrypted DNS response pointing to the Umbrella block page.
  7. The client is sent the requested web page based on applied policy.

NOTE: DNSCrypt Compatibility

Access points that do not support 802.11ac, such as the MR18, will still be able to utilize Umbrella DNS services but do not support the use of DNSCrypt when communicating back to the Umbrella servers. All access points that are capable of 802.11ac or newer fully support the use of DNSCrypt with Umbrella DNS.

NOTE: HTTPS Blocking

Just like Meraki's content filtering, blocked requests for HTTPS content will not load the Umbrella blocked page correctly. Instead, users will be presented with a generic "Webpage is not available" error. 

 NOTE: Cisco Umbrella has two potential endpoints that Meraki will send DNS traffic to: 208.67.222.222/32 and 208.67.220.220/32. Make sure that bi-directional UDP 443 to both of these addresses is allowed on any upstream devices. 

 NOTE:  Expected Routing Behavior when Default Route is over VPN (Auto VPN or Non-Meraki)

When an MX has Umbrella protection enabled and a VPN (Auto VPN or Non-Meraki VPN) default route, it forwards the DNS requests rewritten by Umbrella over the VPN default route even though the subnet via which the request was generated doesn't participate in VPN. 

DNS Exclusion 

When an SSID is configured in Bridge Mode, the option to configure DNS Exclusion will be available under the policy selection drop-down menu. This allows administrators to specify domains that should be excluded from Umbrella filtering. DNS requests for excluded domains will not be redirected to Umbrella and will instead be forwarded to the DNS server specified by the client. This is extremely useful for preventing DNS requests for local resources from being redirected to Umbrella and instead allowing them to reach internal DNS servers to resolve correctly.

NOTE: MRs automatically add the .local and in-addr.arpa domains to be excluded from Umbrella redirection by default. This is not the case for MXs Umbrella DNS exclusions. 

NOTE: DNS exclusion is only available for SSIDs configured in Bridge Mode.

 For DNS exclusion on the Advance security licensed MX, you can specify one or more domain names (one per row) to be excluded from being routed to Cisco Umbrella by going to Security & SD-WAN > Configure > Threat protection, and scroll down to Umbrella protection section. 

NOTE: DNS exclusion is not available for configuration on group policies that are linked to Umbrella policies. The domain exclusions for group policies will adhere to the configuration of the SSID. For example, if the employee SSID is excluding meraki.com from Umbrella lookups, and a client with an assigned group policy linked to a different Umbrella policy connects, then meraki.com will still be excluded from DNS lookups sourced from that client.

MX supported DNS exclusion per network. The configuration is only visabled once Umbrella protection is enabled. 

Screenshot 2023-09-29 at 1.01.41 PM.png

Best Practices

  • Enable the DNS integration on both MX and MR platforms for the broadest protection

  • TCP DNS is not supported on the MX at the time of this writing. 

  • Under normal circumstances, TCP DNS requests account for ~.02% of DNS requests. If TCP DNS is a concern steps to secure this type of traffic the following steps can be taken.

  • Add an L3 Firewall Rule (Security & SD-WAN > Configure > Firewall) which blocks TCP port 53

  • Add a Content Filtering Rule (Security & SD-WAN > Configure > Content Filtering) to block DoH/DoT Traffic. This category is intended to identify and block encrypted TCP DNS traffic which will force the client back to unencrypted lookups and continued security coverage.

  • Update to Chrome 113 on Windows clients. 

    • A bug that impacted Windows clients caused frequent DNS queries over TCP. This has been fixed in Chrome 113 (released 5/2)

For DNS Policy best practices please see this Umbrella article.

Troubleshooting 

General Troubleshooting Steps

  • Ensure that the Umbrella and Meraki dashboards are properly linked via API from Network-wide > Configure > General (Section 2.1)
  • Ensure that the SSID/group policy has been linked to Umbrella in the Meraki dashboard and has an Umbrella policy applied from either Network-wide > Configure > Group polices or Wireless >  Configure > Firewall & traffic shaping respectively (section 3.1 & 3.2)
  • Ensure that the appropriate identity exists under Deployments > Core Identities  > Network Devices on the Umbrella dashboard (section 3)
  • Ensure that the correct policy is assigned to the correct network device in the Umbrella dashboard from Policies > Policy List
  • Ensure that bi-directional UDP 443 traffic is allowed to the Umbrella endpoints - 208.67.222.222/32 and 208.67.220.220/32 (section 4)