vMX Setup Guide for Microsoft Azure

One-Armed Concentrator 

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, any traffic coming over auto-VPN or client VPN to the vMX will be NATed to the vMX's IP as it egresses the vMX. Other capabilities of the NAT mode including DHCP, HA or multiple ports (LAN and WAN) are not supported.  In this mode the vMX is still a one-armed appliance with one network interface. Please look at vMX NAT Mode Use Cases and FAQ for more information.

Split Tunnel 

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.

Full Tunnel  

In full-tunnel mode, all traffic that the branch or remote office does not have another route to is sent to a VPN hub.

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.

Resource group 

A resource group is a container within Microsoft Azure's infrastructure where resources such as virtual machines are stored.

Azure-Managed Applications

Managed applications within Azure serve as the network used to manage and support the Cisco Meraki vMX.

Additional Information 

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.

Project Details

• 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 or select an existing resource group

Instance Details

• 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 

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.”

Deployment Details

• Configure virtual networks

  • Virtual network: Choose an existing virtual network from the list.

  • Subnet: Choose the SD-WAN subnet mentioned above in which the vMX will be deployed; if needed, refer to the article for more information about subnets in Azure. The subnet chosen here must be different from the subnet where resources you plan to access and route through the vMX are deployed.

• VM size: Choose the VM size based on the vMX SKU you want to deploy using vMX comparison datasheet . For best performance, the new instance type of "Standard F4s_v2" should be used to deploy the vMX.  

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.

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

• Instance Details

  • 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:

Finally, associate the Route Table with the subnet where the resources are deployed (NOT the SD-WAN subnet where the vMX is deployed). Click on "Subnets" and then "Associate.  Choose the virtual network and then choose the production subnet(s) where your applications are deployed 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.