This document is a walk-through for setting up a virtual MX appliance (vMX) in the Azure Marketplace. After completing the steps outlined in this document, you will have a virtual MX appliance running in the Azure Cloud that serves as an Auto VPN termination point for your physical MX devices.
Before deploying a vMX, it is important to understand several key concepts.
All MXs can be configured in either NAT or VPN concentrator mode. There are important considerations for both modes. If needed, refer to the article on concentrator modes for more detailed information.
In this mode, the MX is configured with a single Ethernet connection to the upstream network. All traffic will be sent and received on this interface. This is the only supported configuration for MX appliances serving as VPN termination points into Azure Cloud.
NAT Mode Concentrator
In this mode, the MX is configured with a single Ethernet connection to the upstream network and one Ethernet connection to the downstream network. VPN traffic is received and sent on the WAN interfaces connecting the MX to the upstream network and the decrypted, unencapsulated traffic is sent and received on the LAN interface that connects the MX to the downstream network.
Note: A limited NAT mode capability can be enabled on the vMX in which traffic from the spokes will be NATed to the vMX's IP as it egresses the vMX in to your datacenter. Other capabilities of the NAT mode including DHCP, HA or multiple ports (LAN and WAN) are not supported. In each mode the vMX is still a one-armed appliance with one network interface
If you wish to change the concentrator mode after the vMX deployment, you must restart the instance for the changes to be applied. Please choose the desired concentrator mode before the vMX deployment.
There are several options available for the structure of the VPN deployment.
In this configuration, branches will only send traffic across the VPN if it is destined for a specific subnet that is being advertised by another MX in the same dashboard organization. The remaining traffic will be checked against other available routes, such as static LAN and third-party VPN routes, and if not matched will be NATed and sent out the branch MX unencrypted.
In full-tunnel mode, all traffic that the branch or remote office does not have another route to is sent to a VPN hub.
Note: This is not supported for vMX VPN concentrators operating within Azure.
Azure Cloud Terminology
This document will make reference to several key Azure-specific terms and concepts.
Azure Virtual Network
A virtual network is where a block of associated IP addresses, DNS settings, security policies, and route tables can be configured and managed.
Azure Resource Manager (ARM) and Azure Classic
Azure has different types of virtual network environments, which represent two different methods of deploying and managing Azure virtual environments. The vMX uses managed applications, which is a Microsoft platform, and is not compatible with Azure 'classic' deployments.
A resource group is a container within Microsoft Azure's infrastructure where resources such as virtual machines are stored.
Managed applications within Azure serve as the network used to manage and support the Cisco Meraki vMX.
During the setup of your vMX instance, or over the course of working within Azure, you may encounter additional terminology which is not defined in this document. To find out more about these terms, and for additional details on the terms listed above, please see the Microsoft Azure glossary.
Meraki Dashboard Configuration
Begin by creating a new Security Appliance network in your organization. This guide will walk you through creating a new network in the Meraki dashboard.
1. Adding license(s) to the Meraki dashboard
The Meraki Dashboard will require a vMX license to be added before you are able to continue. If you do not have access to a vMX license, please reach out to your Meraki reseller or sales rep.
Create a "Security appliance" network type:
Once you have created the "Security appliance" network and added the appropriate license, you will be able to deploy a new vMX to your network by clicking on the 'Add vMX' button:
Before generating the token, please verify the firmware is running MX 15.37+, otherwise the upgrade will not occur.
2. Generate the authentication token
After you add the new vMX to your network, navigate to Security Appliance > Appliance status and select “Generate authentication token” to generate the token for the Azure "Meraki Authentication Token" data field.
3. Copy the newly generated token and save it.
The newly generated token will be used in the Basics -> Instance details section when creating a new Azure-managed application.
The authentication token must be entered into the Azure instance within one hour of generating it, otherwise a new token must be generated.
This section walks you through configuring the necessary requirements within Azure and adding a vMX instance to your Azure virtual network. For more details on setting up an Azure virtual network and other components, please refer to Microsoft Azure Documentation.
Before You Begin
You must have the following before you begin:
An Azure virtual network and virtual subnet on a resource group separate from the resource group you will be creating to host the vMX.
Your virtual network must be in a separate resource group from the one hosting your vMX. If you assign the vMX to a resource group that already contains a virtual network/virtual subnet, you will not be able to deploy the vMX.
This section walks you through configuring the necessary requirements within Microsoft Azure, and adding a vMX instance to your resource group. For more details on setting up a resource group and other components, please refer to Azure's documentation.
Accessing the Offer
Access to the VM offer. A screenshot of the Marketplace list of Cisco Meraki vMX in Azure is included below:
The same vMX offer is also available via Cloud Solution Providers (CSP) program on Azure.
From the Marketplace listing, click on "Create."
After creating, you will be prompted to configure basic settings for the managed app.
Subscription: Choose the subscription that you want to be billed for from the drop-down menu
Resource group: Create a new resource group with any name
VM name: Choose a name for your Cisco Meraki vMX VM; it can be any name
Meraki authentication token: Paste the token previously generated on the Meraki dashboard
Region: Select the region where the vMX will be deployed
Zone: Select the appropriate Availability Zone (AZ) for the region selected above
Not all regions on Azure support Availability Zones (AZ). Select “NONE” for zones that don’t support AZs. If a zone is selected for a region that does not support AZs, the deployment will fail.
Managed Application Details
Application name: Choose a name for your Cisco vMX managed application
Managed resource group: Name for the managed resource group, which will hold all the resources that are required by the vMX managed application
After completing the basic settings configuration, go to the next step, “Deployment Details.”
Configure virtual networks
Virtual network: Choose an existing virtual network from the list; minimum allowed prefix size for the virtual network is /24 and max is /8
Subnet: Choose the subnet in which the vMX will be deployed; if needed, refer to the article for more information about subnets in Azure.
VM size: Choose the VM size based on the vMX SKU you want to deploy. For best performance, the new instance type of "Standard F4s_v2" should be used to deploy the vMX-S and vMX-M SKUs.
vMX-L is currently not supported on Azure.
Next, review the deployment details and licensing information and hit "Create."
After you click on "Create," the deployment will begin.
It may be several minutes before the deployment completes and the instance launches.
Once the vMX is online, a route table needs to be created including the Auto VPN subnets so that the Azure resources know how to access the Meraki subnets over Auto VPN.
Additional Azure Route Table Configuration
To create a route table, click on "New" and then "Route Table."
Next, define the “Basics” for the new route table resource.
Route Table Basics
Subscription: Choose the subscription that you want to be billed for from the drop-down menu
Resource group: Choose an existing or a new resource group where your instances are present or will be deployed
Region: Select the region where the route table will be deployed
Name: Name for the route table instance; can be anything
Propagate gateway routes: Default is "Yes;" select "no" to prevent the propagation of on-premises routes to the network interfaces in associated subnets
Once the Route Table has been created, add the VPN routes pointing to the vMX as the next hop, including the client VPN subnet where applicable:
Please ignore the IP forwarding warning, it has already been enabled in the managed application template by default.
Finally, associate the Route Table with the subnet where the vMX was deployed. Click on "Subnets" and then "Associate."
Choose the virtual network where the vMX was deployed, then choose the subnet used to deploy the vMX and click "OK."
Once the subnet has been associated, enable site-to-site VPN on dashboard.
On the site-to-site VPN page, add each subnet in your resource group that should be accessible to remote Auto VPN peers to the list of "Local Network(s)." For more information on configuring Auto VPN, please refer to the site-to-site VPN settings documentation.
The most common problem when deploying a vMX is getting it provisioned and online in the Meraki dashboard in the first place. New troubleshooting/diagnosis messages have been added to the vMX console screen so you can identify what went wrong during the provisioning process.
When the vMX boots it will execute the following steps during its initial provisioning process:
- Obtain user data (vMX auth token)
- Authenticate with the dashboard (using auth token)
- Connect to dashboard
Obtain User Data and Authenticate to Dashboard
Once a vMX has successfully connected to a network, it will then attempt to obtain its user data (vMX auth token). There are different user-data mechanisms in each platform that the vMX currently runs on to provide the token to the vMX. In AWS, Azure, GCP, and Alicloud there are user-data fields in the VM configuration where this can be provided.
vMX auth tokens have a lifetime of only one hour for security purposes. If you see the following message on your vMX console it means the token you provided is no longer valid.
If the token provided is incorrect in any way the "invalid token" message is displayed on the console.
Unable to Reach Meraki Dashboard
If the vMX is unable to reach the dashboard on TCP port 7734, the initial provisioning phase will fail and an "Unable to reach Meraki Dashboard" message will be displayed on the console (check the firewall information page for a list of all the firewall rules needed for the Cisco Meraki cloud communication). Please refer to this document on the correct ports/IPs that need to be opened for Meraki dashboard communication.
No "Add vMX" Button
When navigating to Security & SD-WAN > Appliance Status, if there is no "Add vMX" button, please ensure the following two conditions are met:
- You have available vMX licenses in your license pool.
- You have created a "Security appliance" network type.
Please note that Meraki support does not troubleshoot Azure Cloud-specific firewall rules and deployments.