Recently, I was involved into a project where we had to deploy a Cisco Meraki vMX100 into Microsoft Azure cloud and build site-to-site and clients VPNs.
The setup process on Azure is relatively simple, however, I lost quite a lot of time on basic issues because the documentation provided by Cisco is not 100% accurate. Here are some tips and tricks to save you time.
Prerequisites and good to know
Here are some prerequisites and good points to know before starting with the Meraki vMX100 on Microsoft Azure cloud:
- You need a Meraki valid license to deploy the Meraki vMX100. You cannot test anything before entering the license. The vMX is not available into the Meraki dashboard before you enter a Meraki license. Moreover, to deploy the vMX into Azure, you need the Meraki authentication token available through the Meraki dashboard only when the vMX is existing.
- The Meraki vMX will work in one-armed concentrator mode only! No NAT mode available. The vMX can only play the role of VPN concentrator on Azure.
- You cannot use the Meraki vMX as a gateway into Azure.
- Full-tunnel site-to-site VPN mode is not possible. Your branch or remote offices need to make split-tunneling VPN: Internet traffic go to the branch/remote office local Internet access, and only Azure remote networks are routed through the VPN. This is the default on Meraki auto-VPN.
- Client VPN is supported on the vMX, but you must use split-tunneling to access to the Internet with a connected client. I give more details on this point in the last part of this post.
Meraki Dashboard Setup
To be able to install the vMX100 VM into Azure, you will need an authentication token from the Meraki dashboard. To generate it, you first need to create the vMX into the Meraki dashboard. So, let’s see this step in details first:
First, create an empty network on your Meraki Organization. Click on: Organization > Create Network
Enter a network name and choose “Security appliance” as network type. Then click on “Create network” without adding any device. Please note: you cannot use a “combined” network for Azure vMX, you must use a “Security appliance” network only.
At that point, you should have this message:
There are no Meraki devices in this network. If you add one we can help you configure it.
Alternatively, if you would like to add a vMX to your network, please add a vMX license to your org and visit this page again.
As you can see, you need to add a license for a vMX.
As soon as you did it, this message is different:
Then, click on “Add vMX” and you will see the vMX available into your network after a while.
Here, you need to click on “Generate authentication token” to generate the token for Azure custom-data field. The token is valid during 60 minutes, so you must add the vMX into Azure within this time. But don’t worry, if the token is expired, you can generate a new one without any problem.
At this point, you are ready to deploy the vMX into Azure.
Microsoft Azure VM Setup
Before starting, you must already have your Azure tenant up and running.
Then, you can follow the Meraki documentation here. There is nothing special here, except the following important points:
- You must create a dedicated subnet for the Meraki vMX. Create a smaller subnet inside your vnet supernet. For example, if your vnet is 10.100.0.0/16, you can create a 10.100.200.0/24 subnet for your Meraki vMX.
- You must also create a dedicated resources-group for the Meraki vMX and this resource-group must be empty.
- If you are a CSP, the Meraki vMX is currently not available on the Azure ressrouces. But, there is a workaround using an ARM template on the Meraki documentation here. I tested this with my colleagues and this solution is working at 100%. You can follow this part of the Meraki guide without problem.
Important note: When you create the vMX VM, Azure will create another resources-group, starting with the resources-group you created for the vMX, followed by random numbers. This resources-group is locked and you cannot unlock it. This is absolutely normal.
For example, at the end of the process, you may have one resources-group called “meraki-vmx”, this is the one you created. And another called “meraki-vmx01spkabu7gi5w5z”. Again, this is normal.
At this point, after a few minutes, you can go back to the Meraki dashboard and you should see your vMX up and running:
(Click on the image to enlarge)
Azure Route table
The Microsoft Azure routing is almost automatic: when you create a subnet, this subnet automatically has a gateway created on the lower IP address and, depending of your firewall rules, it must be able to access the other subnets without any other configuration.
With the vMX this is also true, the vMX you created received automatically a LAN IP and a default-gateway. You can see this information on the Meraki dashboard, under: Security Appliance > Appliance status > Uplink
Here, you see the public IP and under “WAN” you can see the WAN interface details:
- IP (DHCP) = The vMX LAN IP, for example: 10.100.200.12
- GATEWAY = The vMX Azure Gateway IP, for example: 10.100.200.1
(on this example, the subnet I created for the xMX was: 10.100.200.0/24).
As you can see, this is not the WAN but the LAN information. This is like this because we use the vMX in one-armed mode and on this mode the WAN physical interface (sometimes called Internet-1) is in use to connect the LAN. Like on a real MX appliance.
At this point, your Meraki vMX is up and running. You can now build a Meraki auto-VPN tunnel with your branches or remote offices. Then, the VPN tunnel will be up, yes, but the routing on the Azure cloud will not work.
As you can also read on the Meraki documentation, at this point the Azure routing is not done. This is correct, but the problem is, the information on how to add static route(s) on this documentation is not complete.
As you might read on the documentation, you must create a static route for each remote office into the Azure route table, pointing to the LAN IP address of your vMX. Like this, Azure know how to reach the subnet(s) of your remote branches and will route it to your vMX. Here is how to do this:
As written in the documentation, to create a route table, click on “new” and then “Route Table”.
Here, create a new route table with a name, subscription and assign it to the resources-group you created for your Meraki vMX. The resources-group you created for the vMX, not the one who was created automatically with random characters.
Into this table, add the subnet(s) of your branches and remote offices, use “Virtual appliance” as Next hop type, and specify the LAN IP address of the vMX as Next hop address. Here is an example:
Ignore the IP forwarding warning, the vMX take care of this.
Finally, and this is where the documentation is wrong: associate this network with the subnet(s) of your servers on the Azure cloud.
This “association” means where Azure apply this static route. So, you must associate it with the Azure subnet(s) of your servers, where your branch office(s) need to access. Not with the vMX subnet as written on the Meraki documentation.
For each association, this is the same: choose your “supernet” vnet on step 1, and choose the servers subnet on step 2.
Another important point: on the Meraki dashboard, on the vMX, you must specify the Azure subnet(s) reachable(s) through the VPN tunnel.
Do this into: Security appliance > Site-to-site VPN > VPN settings > Local networks. Like below:
Client-VPN on the vMX
I spent many time on this. Basically, the client-VPN tunnel to the vMX into Microsoft Azure is working, but you will not have access to the Internet through the tunnel. This is an Azure NAT limitation on the Azure gateway.
Hopefully, I had a very good support from the Meraki technical support on this problem. Everything was correctly configured, the access from the remote client to the Azure servers was working, but no Internet access.
After investigations, the answer of the Meraki Technical Support was this:
Full tunnel Client VPN to a vMX in Azure is currently not supported, since internet bound traffic coming through the full tunnel can not be forwarded to the internet.
Split tunneling for Client VPN allows traffic to go from the client VPN tunnel to remote subnets reachable via S2S VPN as well as other resources in the same shared Azure network (As long as the routing is setup correctly on the Azure side).
So, if your VPN clients needs to have Internet access, you must configure Split Tunneling, like explained here.
To make the routing part on Azure route table, this is the same setup as above for a site-to-site, but the route must be also applied (associated) to the vMX subnet. Not only to the server(s) subnet(s).
For the Client-VPN subnet configured on the vMX, I tried with a subnet part of the vnet supernet and I also tried with a RFC1918 subnet outside of the vnet supernet; both are working fine.
For example, if your vnet is 10.100.0.0/16, you can use 10.100.101.0/24 as client-VPN subnet. Or, if you prefer something totally outside your vnet, you can take another subnet like 192.168.27.0/24 for example. Just add the corresponding route into the Azure route table and that’s it.
Meraki vMX setup guide for Azure:
Meraki One-Armed VPN Concentrator deployment guide:
Configuring Split Tunnel Client VPN: