Cisco Meraki MX Branch to Azure Virtual WAN Deployment Guide

Prerequisites

• Each branch MX must be on firmware 15.12 to take advantage of IKEv2. 
• This guide assumes the creation of Virtual WAN and the Virtual WAN hubs have previously been created in the Azure Portal. 

For steps on creating a Virtual WAN please reference: https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-site-to-site-portal#openvwan

For steps on creating a Virtual WAN Hub please reference:https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-site-to-site-portal#hub

• Owner access at the Resource Group level containing the Virtual WAN resource is required to delegate permissions to the automation script. 

 

 

Supported Use Cases

The design supports the use cases for in-region and inter-region Azure connectivity for branch (spoke) sites. In this scenario, a branch securely builds an IPSec tunnel to the Azure Virtual WAN VPN Gateway. Specifically, the branch will build a single tunnel to the Instance 0's IP address of the VPN Gateway. The toolkit will configure two tunnels with two different IPs (Each being Instance 0 and 1 for the VPN Gateway). However, only a single tunnel will be active at any given time. This is due to the fact that Cisco Meraki does not support Equal Cost Multipath and therefore cannot have 2 VPN tunnels to the same destination (private subnet). Below is a screenshot of the sample configuration that will be built once the branch has been tagged accordingly: 

The IPSec policies will be programmed to the following values:

ISP Failover

If a branch site experiences an ISP outage, the IPSec tunnel will be re-built utilizing the backup ISP automatically. Only one active tunnel can be configured per destination (In the example VNET 1 and 2). In other words, only a single tunnel is used on an uplink at any given time. When that uplink is detected as Down state, the appliance then builds the tunnel out its backup WAN interface.   

 

The events for detecting an uplink failover are:  

DNS test  

• Query the DNS servers (primary or secondary) configured on the Internet interface for the following hosts:  

• meraki.com  

• google.com  

• yahoo.com  

 

Internet test  

• Ping 8.8.8.8 every second.  

• Uses a round-robin technique to send an HTTP GET to https://google.com, https://yahoo.com, or https://meraki.com. An HTTP response of any kind will result in a success.  

 

ARP test   

• ARP for the default gateway and its own IP (to detect a conflict).    

Details on these tests are outlined in the following documentation:

 

Azure VPN Gateway Failover

In order to facilitate high availability for the VPN Gateways a combination of the VPN status API and Events API is used to detect gateway failover. The following endpoint is queried during the Azure Function: 

https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-vpn-stats

If the tunnel is detected as down for the site, we look at the events API to ensure that this wasn't taken down due to no interesting traffic on the tunnel:

https://developer.cisco.com/meraki/api-v1/#!get-network-events

By relying on the Meraki API + Azure function detecting a gateway failover in Azure may take up to several minutes to be detected. 

 

Deployment Steps

Obtain Cisco Meraki API Key and Org Name

The API Key and Org Name will be needed for the script to configure your Meraki device. 

To view your Organization name navigate to Organization > Configure > Settings and the following can be seen:

For access to the API, follow the steps below:

1. Navigate to Organization > Configure > API & Webhooks or go to the My profile page and generate an API key

2. Note: The API key is associated with a dashboard administrator account.   

 

 

Note: The toolkit also contains a firmware validation checker. One of the requirements for the solution is that the branch MX must be on firmware 15 or greater.  

 

Run the deployment script to create the Azure Function app: 

For automation, Azure Functions are used to run a Python script every 5 minutes to sync the configuration between the Cisco Meraki and Virtual WAN configurations.  An Azure Resource Manager (ARM) Template is used to help facilitate the deployment process and creation of the Azure Function, Storage Account, and Application Insights resources. 

 

Note: Each time a change is made to an IPSec Profile on the Meraki device, a renegotiation attempt is triggered for all non-Meraki VPN tunnels.  In environments with hundreds of tunnels, it may not be favorable to have this happen during business hours, so you can choose to enable a maintenance window for when the automation makes changes to the VPN profiles (the maintenance window feature will not disrupt failover detection capabilities or trigger renegotiations of all tunnels during a failover scenario).  If needed, you can specify a tag on any of the tunnels in scope of virtual wan with a value of vwan-apply-now, and the next sync will commit changes. 

 

 

1. To deploy the Azure Function, click on the deploy to Azure button below:
   
     Click the Deploy to Azure button. 

2. When logged in to the Azure Portal, fill out the required parameters and click Review + Create. 

1. Note: The Function App Name should not contain any special characters other than “-“.  The function app also needs to be unique globally within Azure, so please use a name that is unique to your organization. 

2. Tip: More information on each of the required parameters can be found by hovering over the  icon in the Azure Portal. 

3. Note:  For meraki_vpn_private_subnets variable, a placeholder value of 169.254.169.254 is visible when creating the function app. This field is entirely optional and is inteded for placing supernets that will be appended to the list of effective routes in the Meraki VPN Config. (More information can be found in the connecting to Secure Hub use case discussed below). If no additional custom subnets are needed for the Meraki branch sites, you can leave the placeholder value 169.254.169.254 as it will signal to the function to only put the effective routes in the Meraki config. 

   When all reachable subnets are not in the Azure effective routes table or you want the secure Hub to be an internet gateway for Meraki branch sites, you would input 0.0.0.0/0 with no quotes or 0.0.0.0/0, 192.168.0.0/16 for a default route and custom supernet. Note that these subnets will be appended to the effective routes in the vwan route table. So if you have 10.0.0.0/24 in an Azure VNET your Meraki private subnets would be 0.0.0.0/0, 192.168.0.0/16, 10.0.0.0/24.

4. Example Configuration 

 

3. Click Create on the Summary blade.  

 

 
 

Delegate access to the function app in the Azure Portal: 

Once the template has finished deploying, the Azure Function will not have any access to your Virtual WAN resources once provisioned.  To delegate access to Virtual WAN and a Storage Account used to store the Virtual WAN configuration files, please complete the following steps. 

 

1. Sign in to the Azure portal with your Azure account. 

2. Navigate to your Resource Group that contains your Virtual WAN and Storage Account resources. 

3. Select Access control (IAM), + Add, and select Add Role Assignment. 

4. Click the Assign access to dropdown and select Function App 

5. Specify the following: 

1. Role: Network Contributor 

2. Select: Cisco-Meraki-VWAN 

3. Select the service principal 

4. Click Save 

 

Cisco Meraki Workflow

Initially, there will be no tagged Meraki networks so the script will sleep and perform the same GET to obtain any networks with the relevant tag. In order to deploy a new branch, the user would navigate to Organization > Monitor > Overview and select the checkbox next to the network that you wish to connect. Below is a snippet of the Meraki dashboard Overview page:  

 

Once the network is tagged appropriately, connectivity is then automatically established. A customer gateway in the Azure Virtual WAN dashboard is created with a matching network name to that of the Meraki branch. Site1 will be named Site1 in both the Azure Virtual WAN and Meraki dashboards. Additionally, a site to site VPN will appear on the Security & SD-WAN > Configure > Site-to-site VPN page.  

 

In this example we have a site named branch 1 that has been provisioned and already connected to dashboard. Additionally, on the Security & SD-WAN > Monitor > Appliance Status page the firmware version can be verified as seen below: 

 

 

 

Post site provisioning

Once the device has been provisioned and connected to dashboard with the correct firmware, we are ready to connect. As described above, the next step is to appropriately tag the dashboard network that the user want to connect to Azure.  

 

Tag naming convention

In order for the function to properly detect new sites to be provisioned to Virtual WAN the following syntax must be applied:

• Tag template = vwan-(hub name)-unique identifier (number)
• Hub name example value = westus-vwan-hub
• Actual tag value = vwan-westus-vwan-hub-1

In order to scale the configuration, availability tags are placed on the Meraki VPN config. This ensures that the correct IPsec config is being distributed to the branch sites. Both the tunnel name and availability tag match what was configured by the user.  This can be seen by inspecting the same example that was displayed above. Each tag must be followed by a unique identifier to segment VPN configurations within the Meraki dashboard. 

 

Summary  

This document encompassed a step by step deployment guide along with a design guide for connecting your MX branch directly to Azure vWAN. Azure functions in conjunction with Meraki API is utilized to make a secure, automated, and scalable solution to meet any enterprise needs.

 

FAQ 

Q: Why do I see 1.2.3.4 as a WAN uplink? 

A: If you have two uplinks with the same public IP from the same WAN, you will receive 1.2.3.4 as a place holder address. Two site links with the same public IP address is not a valid VWAN configuration and the automation will check for this behavior, so 1.2.3.4 has been leveraged as a placeholder in the event additional checks have been disabled within the script. 

 

Q: How do I ensure the automation remains working if I generate a new Meraki API Key? 

A: You can navigate to the Azure Function in the Azure Portal and select Configuration under Settings.  Under Application settings, modify the value for the setting called meraki_api_key. 

 

Q: The automation doesn’t seem to be doing anything, how do I figure out what’s going on? 

A: The Azure Function will log many points of execution to help facilitate troubleshooting.  Navigate to your Function App, select Functions, choose Meraki-VWAN-Automation, and click Monitor.  On the Monitor blade, you can select any of the run dates and see the logging information as the code executes.  In many cases, a Type of Error will be logged at points where the script reaches out to make API calls. 

Note: Logs may take up to 5 minutes display after the script has executed. 

 

Q: How do I force the automation script to run on demand? 

A: Navigate to your Function App, select Functions, choose Meraki-VWAN-Automation, and click on Code + Test under Developer.  On the Code + Test blade, click the Test/Run button, and then click the Run button.  You should see HTTP response code 202 Accepted.  Once you see the response code, you can close out of the blade/navigate to another part of the Azure portal and the script will still continue to finish executing. 

Note: Logging can be found under the Monitor section, but please note it can take up to 5 minutes for logs to be displayed after execution. 

Note: If the maintenance window feature is enabled, you will need to apply a tag with a value called vwan-apply-now to any of the IPSec tunnels in scope of Virtual WAN.  This will ensure changes take effect. 

 

Q: How do I stop or pause the automation from running? 

A: Navigate to your Function App and click the Stop button and click Yes to confirm you are sure.  When you are ready to resume it, click Start where the Stop button was. 

 

Q: Are Azure US Government Cloud regions supported for this integration?

A: Azure US Government Cloud is not supported at this time due to requirements on Azure Functions – Linux Consumption Plans.  Once Linux Consumption Plans for Azure Functions are available, the integration can be updated to bring support for gov cloud.  An estimated availability time for Linux Consumption Plans for Azure Functions can be found here: https://azure.microsoft.com/en-us/global-infrastructure/services/?regions=usgov-non-regional,us-dod-central,us-dod-east,usgov-arizona,usgov-texas,usgov-virginia&products=functions

 

Online

Cases can be submitted directly within the dashboard. This option helps Support quickly locate your network and resolve issues more quickly.

To submit a case in the dashboard:

1. Log-in to the dashboard.
2. Navigate to "?" > Get help & cases > Pick a Tile to Contact Support > Submit a case.
3. Use the provided fields to explain the question or issue. Please include any relevant details.
4. Click Submit.

You will receive a confirmation email, and a Support Engineer will get back to you as soon as possible. You can update the case if needed by replying to that email, or visiting the  "?" > Get help & cases > Recent cases > View full case history page in the dashboard.

Phone 

Phone support is available for customers experiencing high impact issues where quick resolution is a top priority. 

When contacting Cisco Meraki Support via phone, please have your customer number and support passcode ready. These can both be found at the "?" > Get help & cases > Pick a Tile to Contact Support > Call support team  page.

The general Support number is +1 (415) 937-6671. A full list of region-specific phone numbers can be found in the dashboard under "?" > Get help & cases > Pick a Tile to Contact Support > Call support team > View regional phone numbers, or on the Meraki Support home page.

Contacting Support by phone with the support passcode ready is the most efficient way to resolve any network outage situations. This will ensure that any parties that may also need to get involved can be involved as early as possible. (escalations, account team etc)

 

 

References 

https://documentation.meraki.com/zGeneral_Administration/Organizations_and_Networks/Organization_Menu/Manage_Tags 

https://documentation.meraki.com/zGeneral_Administration/Support/Contacting_Support