vMX and Azure VNET peering

[chrisan99]

I have deployed a vMX into MS Azure. Following the deployment guide, the vMX sits in its own Resource Group, in a dedicated VNET and Subnet.

The vMX is configured to be a VPN Hub.

Within the Dashboard, the vMX looks healthy.

I have a test branch acting as a spoke, which has an AutoVPN tunnel formed to the vMX.

Within Azure, I have a separate server Resource Group, VNET, Subnet with a VM. I want the spoke site to be able to connect to this VM.

In the vMX, I have defined this server subnet under the "VPN settings" "Local networks".

Now for the problem - the vMX VNET and server VNET are not peered, and I'm unable to peer them due to the following error:

"Failed to add virtual network peering 'vMX-to-Server' to subscription ... The client <my-email-address> with object id <abc-123> has permission to perform action .... write on RG-vMX; however the access is denied because of the deny assignment created by the managed application"

Essentially, the Azure RG I created acts as a container for the vMX and it's objects (including the VNET). This RG is very restrictive and doesn't allow me to setup peering to existing VNETs within Azure.

I have a support case open with Meraki, but I believe they're struggling to understand the problem.

MS Azure support have confirmed the permissions are due to the managed application (the vMX).

Does anyone have any pointers to assist with the VNET peering setup?

Thanks

Chris

[PhilipDAth · Accepted solution]

The community forum filters out a lot of swear words.  I was thinking of using more creative words but CarolineS might not be happy with me.

Here is the secret.  When deploying the VMX in Azure you can select an existing virtual network and subnet.

Note that the VMX itself must go into its only read only resource group.

I would select the existing subnet wherever your servers are located.  If you are super keen you can create a new subnet in your existing resource group.

Just don't let the VMX create the subnet in its own resource group.

This is stated in the deployment guide (search for "Choose an existing Virtual Network") but it should probably be in big bold lettering.

https://documentation.meraki.com/MX/Installation_Guides/vMX100_Setup_Guide_for_Microsoft_Azure

This really does deserve some swearing.

[PhilipDAth]

And to answer your next question, you have to delete the managed application to delete the resource group tp delete the VMX so you can re-deploy it.

[Uberseehandel]

@PhilipDAth 

Purely out of philological interest and completeness - were you wanting to say "pokokohua, iti uri"? ;-[]

[PhilipDAth]

At least that involves some cooking.

[chrisan99]

Thank you for this! Once again, Cisco documentation is woefully lacking in detail and the end-users become the beta testers for their products and documentation. The community has fixed this issue, not Meraki support.

I'm re-deploying now. Many thanks for your help.

[Pugmiester]

I've just run up against the same issue deploying a vMX. The process never made sense beforehand (I'm in no way any sort of Azure expert) so I just presumed it was my physical world thinking but I don't recall having any options at all to select a subnet/vnet outside the vMX's new resource group.

In theory, peering the VNET's should be trivial but I'm hitting a permissions error that we can't make sense of so I've bounced it back to our Meraki sales contact to see if they can help unravel what's happening.

[PhilipDAth]

> I don't recall having any options at all to select a subnet/vnet outside the vMX's new resource group.

It's under one of those "Advanced" boxes.  You can't see it just sitting on the screen.  I know.  A real pain.

[Pugmiester]

We're up and running but not without having to tear down the initial installation and start from scratch. That was rather convoluted as well but eventually I managed to unpick it and remove all of the newly created resource groups and the vMX.

I had to create a new dedicated subnet in our primary resource group and VNET to be able to attach the vMX LAN interface to which then made it available on the list when building the new vMX. The other subnet I was trying to connect to initially, has been configured as the Azure gateway subnet which seems to exclude it from the selection list.

Yeah, I don't know anywhere near enough about Azure to fully understand how all the widgets hang together. It seems overly complicated coming from a physical hardware world but I think it makes enough sense to me now to be able to reproduce this in production when we need to.

[fcarrelli]

I ran into the same issue. Did you have to remove everything? Can I leave the local Meraki network and appliance intact and just remove the vMX appliance in Azure? Then create a new token and start over?  Thanks...

[Pugmiester]

It was the Azure side of things that I managed to get confused so just removing the vMX and redeploying worked for me.

[fcarrelli]

Thanks again.

[MattPainter701]

Phillip,

Can you elaborate more on the vnet requirements?

[PhilipDAth]

You need a VNET that is part of an existing reosurce group.  You don't want to let the VMX deployment create its own VNET because it will place it in its own resource group.

[MattPainter701]

I've tried using an existing VNET with a new subnet, yet it gives an error on deployment. 

networkInterfaces/NWT-vMXNic was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.

Yet they are all in the same region....

[MattPainter701]

I've tried using an existing VNET with a new subnet, yet it gives an error on deployment. 

networkInterfaces/NWT-MXNic was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.

Yet they are all in the same region....

[MRyan]

I have created and torn down the vMX 3 times now as I run into one problem or another, initially I tried to use a VNET that was already existing in another resource group (all resource groups are in the same region), and that VNET had nothing associated with it but only 3 subnets defined within it, I got an error message every time I tried to create this, so I had to let the vMX create it's own VNET within it's resource group, but now there are such draconian "deny" controls that it is basically useless as you can't create any route paths on the VNET in the Meraki Resource group.  SO here we go for round 4 of deploying the vMX100, this time I will create a new VNET in an empty Resource Group and then pre-create a /30 subnet within that VNET range for the vMX to use and see if I can then setup a VNET peer from that /30 to other subnets within the same VNET.

[fcarrelli]

Save yourself some time and contact Meraki Support. At least for my issue, I had to get Meraki to remove the Azure Meraki virtual appliance from Azure. Evidently it caches some settings in Azure and does not fully go away. I deleted that app several times from Azure before giving up and getting Meraki Support to intervene. Once they cleared it in Azure, it all worked perfectly.

[MRyan]

I deleted everything in Azure and started from scratch, the only thing I predefined was a VNET and subnet in an empty resource group.. This time I was able to have the vMX100 created successfully and have even created a Win10VM in Azure on the same internal VNET/subnet, however I'm having routing issues between the Azure vMX100 and the MX-450 in our data center, yet other remote facilities that enable the Azure vMX100 as another Hub can access the networks behind it.

[Brandon_Fox_CSG]

tl;dr

1. Create new Resource Group (eg vMX-RG)
2. Create Virtual Network in that RG (eg vMXvnet - 10.0.0.0/16)
3. Create subnet in that vnet (eg vMXsubnet - 10.0.0.0/24)
4. Create Meraki Network Security Appliance from market place
5. Assign vMXsubnet as network

After that's completed

1. Create a resource (server) subnet in vnet (default - 10.0.10.0/24)
2. Put resources in that subnet
3. Create a route table and make all remote subnets next hop to the security appliance
4. Configure Meraki as a spoke in AutoVPN or use as a Client VPN concentrator

Hopefully this helps someone.

PS, you can peer disparate vnets and route resource traffic that way if you want.

[JayHylander]

This works if you don't already have a VNet with hosts on it.  If you have a VNet with hosts on it you need to create peerings between the VNet(s) with your hosts and the VNet with your vMX.  This creates routes between the subnets of one VNet and the subnets in the other VNet.  Then you can apply the route table with your VPN peer networks to the subnets where the hosts are.  

[Brandon_Fox_CSG]

Absolutely correct. I vaguely mentioned that at the end of my post, but you've made it a little more clear. You can always peer the vnets together if you have to create a separate one. 

[freemti]

[freemti]

this is just a template showing all the fields, I am still unclear which pieces go where and which RSGs/vnets/subnets should be created already.

[Brandon_Fox_CSG]

Hey @freemti ,

Are you looking for someone to assist you with Azure, or the concept of setting up the vMX?

In general, you'll want to have a vnet created already with a subnet for the vMX. When you deploy the Azure Marketplace package, it will do the rest. You just need to assign the vMX to that vnet's subnet.

Hopefully this helps.

PS. I'm not sure what an RSG is, but if you're referring to an NSG, you don't need to worry about that for a vMX. If you're referring to a route table, you'll need to create that as well. 

[Mohit_Chauhan]

Few clarifcations on your point Phil,

1. are you suggesting we can use the same existing subnet where servers are hosted so when when the vMX comes up online, it will pick up one of the ip range from the same pool? In my case, I have only one /24 subnet available in the server vnet beside the server subnet. However, I am planing to use that for the VPN users, will this be OK?

2. The other alternative was, can I use /25 as the subnet for the vMX. So far when I have tried its giving me "conflict error" on Azure in building up the VM for this vMX. I have logged a case with Azure on that and waiting for the feedback.

Thanks in advance.

Mo