Meraki Umbrella SDWAN Connector Deployment Guide

Use Case 

• Inspect all internet-bound traffic at scale from a single cloud-delivered platform.

• Managing and monitoring both network devices and their security policies from simple cloud-based solutions.

• Network administrators want to manage the entire set of security policies for all SD-WAN branches using a single pane of glass.

• Organizations want to exclude guest traffic or high bandwidth application traffic from cloud security services.

• Organizations want to utilize a unified cloud-based security solution without incurring additional costs from interconnecting it to their existing Meraki network solution.

Requirements

Umbrella

• the Umbrella SIG Essentials package is required. Please visit Umbrella for more package information.

Meraki

• Branch MXs must be on MX 14.00+ firmware versions 
• Meraki Umbrella SDWAN Connectors must be on MX 15.37+ firmware versions
• MV cameras and other Meraki devices that do not use FIPs Device-to-Cloud connectivity(TCP-443) must have their dashboard management traffic excluded from SIG tunnels, or they may experience issues with dashboard configuration updates. 

Umbrella dashboard

1. Create Umbrella Management API Keys on the Umbrella dashboard

In the Umbrella dashboard, navigate to Admin > API Keys > Click Legacy Keys, and then expand a legacy Umbrella API key.

Click Generate Token.

Meraki dashboard

1. Enable Cloud On-Ramp
   In the Meraki dashboard, navigate to Organization > Configure > Cloud On-Ramp
   
   
    
2. Add API keys from the Umbrella dashboard to the Meraki dashboard
   
   On the Configuration tab, click Connect to Cisco Umbrella
   

   Input both the management API key and secret and continue the process by clicking the Yes, continue button

   
   
   Click on Deploy, to begin the process of deploying the Connector
   
    

   Kindly note that 

   1. If you have already had a MR-ADV integration, you won't be able to enable Meraki Umbrella SD-WAN Connector. A new Meraki Org is needed.
   2. If you have already linked your Meraki Org to an Umbrella SIG Org, you will need to use that Umbrella Org and won't be able to link your Meraki Org to a different Umbrella SIG Org.
   3. Meraki Umbrella SD-WAN Connector is available with the MR and MX DNS integrations.

   For any problem illustrated above, please reach out to your SE for assistance.

3. Choose the Data Center (DC) location pair where the Connectors will be deployed
   Input a name for the Connector network and choose the DC locations. This will create 2 networks, with a connector in each located at the chosen locations. For example, If you choose US west coast, the networks will be created on the Meraki dashboard and the two connectors will be hosted at both the Los Angeles and Palo Alto DCs. The name of the new networks created in the Meraki Dashboard will follow the format:

   Network 1

   <Network Name>-<Region specific DC-1> 

   Network 2

   <Network Name>-<Region specific DC-2> 

   
   
   Next, choose a Network Region (associated DC pair) to which your branch sites will connect in order to access SIG. Click Yes, continue to execute the deployment. The location of the Disaster Recovery (DR) Data Center is highlighted once a DC pair is chosen
   
    
4. Verify the Meraki Umbrella SDWAN connectors are deployed

   Navigate to the deployment tab, Organization > Configure > Cloud On-Ramp > Deployments to access the newly deployed connectors. A correctly deployed SD-WAN connector will display a status of "deployed" for both of the connectors.  The following status messages infer:

   Created:

   The UMB-SIG network was created in the Meraki dashboard and a UMB-SIG connector added to it
   
   Deployed:

   The Meraki Umbrella SDWAN connector was instantiated inside the Umbrella cloud and it should check-in on the Meraki dashboard within 5-10 minutes after the deployment is complete.

   Tunneled:

   A network tunnel was created in your linked Umbrella dashboard under Deployments > Network Tunnels

   
   

   Once fully deployed, the Connectors will be pre-configured as:
   
   1. A Hub, Select one of the Connector networks and navigate to the Site-to-site VPN page, Security & SD-WAN > Configure > Site-to-site VPN
   

   2. BGP enabled with a peer IP: 169.254.0.9 and ASN:36692 Umbrella. NOTE: Sigraki 1.0 does not support changing the default BGP VPN AS from 64512 to another value.
   
   

   There will be no option to change Site-to-site VPN configs for Meraki Umbrella-SIG connector networks. These connectors are pre-configured and the Auto VPN default route to Umbrella SIG is advertised to all spokes connected to these Umbrella-SIG connector hubs. Please make sure not to have an overlapping default route for any of the NMVPN tunnels, this can disrupt the overall Umbrella SIG routing. 

   Due to the default Meraki Auto-VPN design, all VPN hubs in an organization will automatically tunnel to all other hubs in an organization. This behaviour changes for the Meraki Umbrella SDWAN Connector solution, when the connector hubs are deployed, all other hubs in the organization will not automatically tunnel to SIG and all hub traffic will not be defaulted to Umbrella. The Meraki Umbrella SDWAN Connector network hubs will not automatically tunnel to other hubs in the organization. 

5. Connect your branch MX to the Connectors on the Site-to-Site VPN page

The branch MX needs to be configured as a Spoke on the Site-to-site VPN page, Security & SD-WAN > Configure > Site-to-site VPN, and the deployed connectors need to be configured as Hubs.

Deleting a Meraki SDWAN Umbrella connector

BGP Routes

We can confirm that our tunnel to SIG and associated routing is successfully established by looking at the UMB-SIG and branch MX routing table.

In the UMB-SIG device navigate to Security & SD-WAN > Monitor > Route table (click on view new version in the upper right if not already on the new version of the route table).

In the route table you should now see a 0.0.0.0/0 eBGP default route to our Umbrella BGP peer (next hop should be a 169.254.0.9 IP) and it should be in a green/healthy state.

On the Branch MX we can also check the same route table and ensure this default route has propagated to the spokes via iBGP (the next hop will show up as a 6.X.X.X IP.  This is expected).

UMB-SIG Devices Online

The first thing to check post-deployment is to ensure both of the UMB-SIG devices created are online and checking in to the dashboard.  As part of the above deployment you will notice two new networks created in your Meraki organization.  These networks will be in the following format (based on the input provided above)

<Deployment name>-<Region specific DC Name > 

<Deployment name>-<Region specific DC Name > 

Navigate to the Security & SD-WAN > Monitor > Appliance status page to confirm both devices are online and healthy.

Umbrella Tunnel Endpoints Created

Next, we can confirm that a network tunnel was created in our Umbrella dashboard.  Within the Umbrella dashboard navigate to Deployments > Core Identities > Network Tunnels.

Here you will find two new tunnels created, one with the serial number of the primary UMB-SIG device and the other with the serial number of the secondary UMB-SIG device.  Once the tunnel has been fully established it will show here as active with a green checkmark.

DNS Policies

A DNS policy provides DNS-layer visibility, security, and enforcement with the ability to selectively proxy risky domains for added security. You can have more than one DNS policy and your identities can be added to any number of policies. However, Umbrella applies the first matching policy to your identity and immediately stops evaluating policies.

If no matching policy is found, Umbrella applies the DNS default policy. Because of the way Umbrella evaluates identities against policies, it's important that you configure policies correctly for each of your organization's identities. An error in configuration may result in unintended results: identities being left unprotected to various threats or users accessing destinations you may want blocked. Plan and design your policies before you build them. For some helpful suggestions, see Best Practices for DNS Policies.

Firewall Policies

Umbrella’s cloud-delivered firewall (CDFW) provides visibility and control for internet traffic across all branch offices. With Umbrella’s cloud-delivered firewall, all activity is logged and unwanted traffic blocked using IP, port, and protocol rules. 

The Umbrella cloud-delivered firewall (CDFW) expects an RFC 1918 IP address as the source IP address for outbound packets. If you use routable IP addresses on your internal network, you must contact Umbrella Support and provide the range of IP addresses that you use. Without this information, Umbrella cannot determine the IP address and may drop packets. For information about address allocation and private networks, see RFC 1918.

Web Policies

Umbrella's Web policy is the heart of its cloud-based Secure Internet Gateway (SIG) platform, providing URL-layer visibility, security, and enforcement to your organization's web traffic. There is only one Web policy, which is made up of rulesets and rules that set various security, permission, and access controls for your identities.

While the Web policy does include a default ruleset that is applied to all identities and which you can configure, to best take advantage of the various features offered by Umbrella's cloud-based SIG, add your own organization-centric rulesets and rules. Indeed, you can add multiple rulesets and rules so that your various identities can be granted different permissions within the Web policy.

Data Loss Prevention Policies

The Data Loss Prevention policy monitors content classified as personally identifiable or sensitive information. When necessary, content is blocked from an upload or a post. There is only one data loss prevention policy. Rules are added to the policy to define what traffic to monitor (identities and destinations), the data classifications that require monitoring, and whether content should be blocked or only monitored.

Prerequisites

HTTPS Inspection must be enabled either on the Web Default Policy, or at least one web policy ruleset where the same identity is configured in a DLP rule. For example, if the identity "Network A" is configured for a DLP rule, it must also be configured for a web policy ruleset where HTTPS is enabled. For more information see Configure a Ruleset > 2. Ruleset Settings > G. HTTPS Inspection.

 Please visit Umbrella's documentation for a comprehensive guide to Umbrella SIG features.

DNS Policy Consideration

The extension of SD-WAN to Umbrella will default all traffic that is not routed to other sites in the Auto-VPN topology with more specific routes to the connector in Umbrella.  This include all DNS traffic. 

When you establish tunnels to the Cisco Umbrella head end to use the cloud-delivered firewall, DNS traffic should be bypassed to ensure that DNS Layer Enforcement is not impacted.

When DNS traffic gets routed in tunnels, the traffic will go through all services in the service chain in the cloud-delivered firewall, undergo Network Address Translation (NAT), and then go to the Umbrella Resolvers with the cloud-delivered firewall's public IP address. In that situation, Umbrella Resolvers will not be able to apply DNS-based policies as the source IP will not match your organization.

To ensure that DNS Layer security is not impacted by the cloud-delivered firewall, traffic for destination port 53 to IP address 208.67.222.222 and 208.67.220.220 should be bypassed.

If your organization is currently leveraging or plans to implement Umbrella DNS policies that are using Meraki Networks by Public IP address as Identities in these policies,  one of the following 3 actions will need to be taken:

1.     Umbrella API integration for DNS policies in Meraki Dashboard

If your organization has not yet implemented DNS protection for your Meraki sites, another option is to configure the API integration for Umbrella DNS policies in the Meraki Dashboard.  This method will use network devices as the identity to apply policy to as opposed to using the public IP address from the Meraki Site.  Given the nature of how this integration works, it also prevents users from circumventing Umbrella DNS policies by changing their DNS resolver configuration on their end user system. 

Details on how to perform this integration and the configuration options for it are available at these two links:

https://learn-umbrella.cisco.com/solution-briefs/meraki-mx-and-cisco-umbrella-integration-offers-simple-flexible-deployment

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Manually_Integrating_Cisco_Umbrella_with_Meraki_Networks

2.     Configure L3 VPN exclusion for the Umbrella Resolver IP addresses in Meraki Dashboard

• Navigate to Security & SD-WAN > Configure > Site-to-site VPN
• If the site is configured as a Spoke ensure that the two Umbrella SIG Connectors are configured as Hubs and that they do not have the Default route option checked.
• If the site is configured as a Hub ensure that the two Umbrella SIG Connectors are configured as Exit Hubs.
• Navigate to Security & SD-WAN > Configure > SD-WAN & traffic shaping
• Scroll down to Local Internet breakout > VPN exclusion rules and click Add +
• Under Customer expressions, Select protocol UDP.
• For the Destination, input the Umbrella resolver IP address 208.67.222.222/32 and port 53, click add expression
• Repeat for IP address 208.67.220.220

Proxy Debug

To validate traffic is flowing through Umbrella SIG you can use the following Umbrella test site:

http://policy-debug.checkumbrella.com/

The external IP field below shows you the public IP where your traffic egresses to the internet and the page offers a link to the Umbrella dashboard and policies that are acting on your traffic.

Traffic Test

To validate traffic being sent to over the auto-vpn tunnel to SIG vs traffic not being sent over the tunnel we can connect to a network on a VLAN that is participating in the VPN and one that is not to observe the difference.

For this test we used the below configuration where the Default VLAN1 is not participating in VPN and the SIG VLAN 10 is participating. This configuration can be viewed under Security & SD-WAN > Configure > Site-to-site VPN.

Using a Wireless capable MX68CW two SSIDs were created. One on VLAN 1 and the other on VLAN 10.

When a device connects to the SSID SIG1, it receives an IP on VLAN10.

When the device accesses the Internet, the traffic will have a NAT address from Umbrella (an IP in the 146.112.0.0/16 subnet means it is exiting Umbrella).

When a device connects to the SSID DIA, it receives an IP on VLAN1.

When the device accesses the Internet, the traffic will have a NAT address from the MX Internet Interface.