vMX100 Azure Cloud

[bholmes12]

Is there a time frame on getting vMX100 available in the Azure cloud? 

[BHC_RESORTS]

---

@bholmes12 wrote:

Is there a time frame on getting vMX100 available in the Azure cloud? 

---

Sooner than you'd think....

[Brandon_Fox_CSG]

I got word it was released... but i can't find it in the marketplace....where can i find this unicorn?

[BHC_RESORTS]

---

@Brandon_Fox_CSG wrote:

I got word it was released... but i can't find it in the marketplace....where can i find this unicorn?

---

It hasn't been released yet. Soon.

[Brandon_Fox_CSG]

Oh... my rep told me it was... ah well.

[jvdp]

- Expanding Meraki vMX100: now available for Microsoft Azure, extending Meraki Auto-VPN and SD-WAN functionality to the public cloud

This was in an email for a webinar  I got today.

Do I assume this is released now or next week along with the webinar announcements?

Will it be available to test in MSDN subscriptions?

[MRCUR]

Official launch is coming in October: https://meraki.cisco.com/products/appliances/vmx100

[Brandon_Fox_CSG]

I like how the they changed the wording to include Azure but the link still takes you to AWS... sneaky...

[KarbonX1]

It's in beta now. I'm running it, but the S2S functionality isn't fully working yet so I can't truly test it until the MX team gets the fix done in Azure. They are a managed appliance, so you can't do anything to them except deploy as is.

[Brandon_Fox_CSG]

Well, hopefully they fix the S2S because that's the whole reason I need this. 

[KarbonX1]

Yeah, I'm working with the engineering team to get the IP forwarding issue worked out.

[KarbonX1]

As an update for anyone wondering, we got the IP forwarding issue figured out and I am using the vMX successfully for the last few weeks now. Works just as expected.

[MJPAGAN]

May I ask what size VM that you are running it on? I haven't been able to get an answer when I've asked Meraki reps.

[KarbonX1]

Standard D2 v2 (2 vcpus, 7 GB memory)

Its a managed virtual appliance, so there is no control over the sizing or any config at all. So there is some planning that has to go into deployment such as:

- You cannot change DNS settings on NIC config, so has to use whatever vnet is set to.

- Cannot shutdown from within azure

- Can only delete entire resource group if you have to redelploy

I am sure there was more, but those are what I can remember at the moment.

[HaloTech]

Waiting for this as well!

[Shanec]

Still no sign on the azure marketplace. or has a more solid date than october.

[apilbeam]

The official line is "mid to late October"

[Shanec]

Meraki are good at not giving firm dates!

[AnythingHosted]

It's getting fairly close to the end of October and still no sign on Azure Marketplace 

[BBagley]

I got tired of not seeing this in the Marketplace, so, just for the heck of it, I pulled up powershell and started looking for it.  Using EastUS as the location, I see the offer and VMimage are there, but the versioning makes me think what's there are the beta ones (0.0.1 and 0.0.2)

Get-AzureRmVMImage -Location $loc -PublisherName "cisco" -Offer "cisco-meraki-vmx100" -Skus "vmx100"

[BklynITGuy]

Hi there,

Was anyone able to deploy this in the EastUS Region successfully? We're having issues trying to deploy it, it continues to fail. Within new vnet, or existing, within new resource group, or existing, etc... We were able to search and see the VMX in the marketplace. It shows up as Cisco Meraki vMX100 (Staged)

Would deploying via PowerShell make a difference? Thanks in advance

Error:

{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details.

Please see https://aka.ms/arm-debug for usage details.","details":[{"code":"BadRequest","message":"{\r\n  \"error\": {\r\n    \"code\": \"InvalidResourceReference\",\r\n    \"message\": \"Resource /subscriptions/d364e0bc-1d6a-4e8d-87fc-de2382680e4b/resourceGroups/lohvmxldfp6wjz6ubkg/providers/Microsoft.Network/virtualNetworks/LXX_Main/subnets/LXX_Production referenced by resource /subscriptions/d364e0bc-1d6a-4e8d-87fc-de2382680e4b/resourceGroups/lohvmxldfp6wjz6ubkg/providers/Microsoft.Network/networkInterfaces/lxxvmxNic was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.\",\r\n    \"details\": []\r\n  }\r\n}"}]}

[MRCUR]

@BklynITGuy I don't actually see it listed. I'd suggest trying it again next week though, perhaps sometime after Tuesday. 

[BklynITGuy]

Thanks @MRCUR. We apparently are still using a beta, initially it was only available in the West Central region. We got an email from a Meraki Rep that it was available world wide on the 24th, with instructions on how to deploy it.

Just confusion I guess, the hope was once we got that email, we'd be able to move forward. Below is the email we got on Tuesday:

As you already know, we started the vMX beta program in West Central US only. I am happy to announce that vMX is now available worldwide.

Please follow the steps in the setup guide to deploy vMX and let me know if you have any questions.

Thank you for all your help during the beta program!

[MRCUR]

@BklynITGuy That's not a public setup guide... 

[BklynITGuy]

It's not public in that you can't search for it yet on their site, but they definitely sent to those who participated in the beta. So the guide itself will probably be public Monday or whenever. It just seemed odd that I'd get that email and still encounter issues that we're having.

[techmoc]

Following link name on draft for the official and where AWS guide is published... denied!

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

Late October is turning into November

[MRCUR]

---

@techmoc wrote:
Late October is turning into November

---

Tuesday is still October... 

[Reinout]

That is true, however I meaned that I hoped the pricing would be comparable with the vgateway in azure. Meraki sales rep told the price would be the same as on aws. Maybe the price of the vmx is comparable with the ms vgateway (vpngw1) but now we also need to pay the extra vm in azure, so pricing is higher. Maybe my ignorance but I expected the appliance came including a vm os. The vmx probably has more options, but we only use it to configure multiple s2s and a bounce of p2s VPN, like we could do in the VPN sku vpngw1 of Ms.

[MRCUR]

@Reinout I'm a bit confused by your post. The vMX license is one price - it doesn't matter if you run it on AWS or Azure. But the costs to running on AWS or Azure are of course different as they aren't set by Meraki. Meraki is just setting the type of VM hardware you need to supply for the vMX as it's a managed appliance on each service. 

[MJPAGAN]

FWIW, I just checked the Azure marketplace for the vMX100 and it's still not available. It's officially not late for it's October release but it's really cutting it close...

-Mike

[CiscoKid78]

I just tried today October 31, 2017 and still not available on Azure Marketplace.  This to me sounds like end of October is out and no word on a push into November 2017 timeframe.  This sounds like something is missing or wrong with the beta program to have delayed a release as advertised in multiple announcements to include Cisco and Microsoft announcements.  Maybe there's not enough feedback or active participation within the beta user community or maybe Cisco Meraki could use more Azure user community to have a more complete QA process before launch.  Count me in here as I am not trolling just to ask if/when is the vMX100 ready but I am ready to help with validation on my Azure subscriptions and Meraki Networks.

[techmoc]

Just checked and Official Setup Guide is Live https://documentation.meraki.com/MX-Z/Installation_Guides/vMX100_Setup_Guide_for_Microsoft_Azure

Also checked Azure Marketplace and image is available, although the link on the guide still points incorrectly to the preview image

[CiscoKid78]

Wow, literally within in seconds of my posting and it's now available on the Azure Marketplace.  Thanks, this is confirmation of +1 for it's AVAILABLE!!!

[MRCUR]

Man you guys must be really excited for this launch. I was going to say it's only early afternoon at Meraki's HQ. They must've finished up lunch and clicked the right buttons to make it live. 

[techmoc]

 vMX100 Image location:

https://gallery.azure.com/artifact/20151001/cisco.meraki-vmxmeraki-vmx100.1.0.0/Artifacts

Deploying... 

[Brandon_Fox_CSG]

Where is everyone getting their authorization keys from?

All i see is: 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.

[AnythingHosted]

I can't seem to add to an existing resource group. 

I was hoping to add to an existing subnet where I have existing virtual machines. 

Does it need to be added to new RG?

[KarbonX1]

Needs a new resource group or one without any resources in it. Also, needs to be deployed in a subnet that is different than the VMs due to the way IP forwarding works so that all data passes through a layer 3 boundary and can be routed properly using the route table.

[KarbonX1]

Brandon_Fox, you need the license to add the vMX. Then you can get the Auth keys.

[techmoc]

@Brandon_Fox_CSG you need to claim an order for a vMX license/trial on the Org first. After you can add the new device to the new networks and generate the auth token for Azure/AWS.

I am testing with a 14 day trial at the moment

I got it up an running on the following:

- MPN IUR Azure Sub (setup guide says it cant be deployed on trial or Azure CSP sub yet)

- D2v3 VM on USWest2

- S2S Spoke to one of my existing MX hubs

- Status and routes updated correctly on MX and vMX

- Ping running and responding each way

I am currently adding VM to do additional tests and also will test adding routes to created route table to existing subnets in Azure

[KarbonX1]

**FYI to everyone**

Do not upgrade the vMX to any 12.x or 13.x firmware. Apparently it is actually running a 14.x firmware, and so the upgrade will kill it. I had to redeploy mine to resolve.

[techmoc]

Thanks for the info! I have the vMX running on 12.26 after deployment. Only have the option to upgrade to 13.xx and higher if I enable the Beta Firmware option on the network.

[Uberseehandel]

Doesn't appear to be in Europe/UK, yet.
Probably best to leave it until the new year to settle down before doing any production trialling.

[MRCUR]

@KarbonX1 Definitely submit a case about that. It shouldn't actually try to run the lower firmware than is required, even if you configure it on the network. It should just say it's up to date on the version you configure but continue running its minimum version silently. 

[techmoc]

---

@techmoc wrote:

@Brandon_Fox_CSG you need to claim an order for a vMX license/trial on the Org first. After you can add the new device to the new networks and generate the auth token for Azure/AWS.

I am testing with a 14 day trial at the moment

I got it up an running on the following:

- MPN IUR Azure Sub (setup guide says it cant be deployed on trial or Azure CSP sub yet)

- D2v3 VM on USWest2

- S2S Spoke to one of my existing MX hubs

- Status and routes updated correctly on MX and vMX

- Ping running and responding each way

I am currently adding VM to do additional tests and also will test adding routes to created route table to existing subnets in Azure

---

Update:

- added new resource group/vnet/subnet

- added new Win VM to run on new subnet

- added route to route table for vnet

- added subnet to S2S config on vMX

- added peerings and corresponding features to both vnets 

- RDP/ping running correctly to/from a VM behind a local MX Spoke to a VM running on new vnet/subnet thru MX-vMX tunnel

Looks good 

[4zap]

I am facing the same problem.... i was too late to participate in the beta but since yesterday the xMX100 is visible in the Azure Marketplace. I could claim my license in the meraki dashboard but wasnt able to deploy the vMX100 in Azure. It tells that my subscription is not able to deploy it, on the other side it tells me that it is not available for my region. 😞 no glue what the real issue is. I created a ticket in Azure... i need this vMX in WestEU and Asia East and cant deploy it at this locations, it does not make any sense to deploy it in West. Hope i get a solution from MS today!

[Granville]

For the error "subscription not able to depoy"

There is a note at the bottom of the guide stating that we cannot use trial or CSP accounts to deploy. I assume you have one of these?

I don't get that error and am deploying using PAYG.

I planned on using CSP.

[4zap]

We have an EA agreement, no CSP, no trial.... still waiting for an reply from MS....

[Granville]

That would suggest that it doesn't work with trial, CSP or EA?

ultimately we are hoping to use EA.

Would be really interested to hear back from you on this if that's ok...

[4zap]

@Granville: We are on it right now with the MS Azure Support Team, i ll keep you informed if we found a solution today... maybe Monday...

[MJPAGAN]

I really hope it starts working with CSP because we're setting up all new customers and migrating existing PAYG customers to CSP to simplify billing.

Thanks to everyone who's sharing their experiences.

[4zap]

It seems it is related that Meraki rolled out this vMX not in WestEurope. Thats where i need to place the vMX. I created a support ticket in the dashboard and hope that we get it solved.

[techmoc]

Since I was able to use one of our IUR subscriptions (an older Action Pack IUR offer for Microsoft Partners), I tested deployment on West Europe and it was successful.

I think it definitely has to do with the comment on the setup guide regarding the subscription type.

We are also moving our subs to CSP... so will eventually need this issue solved.

[Granville]

Oh Wow, thanks for letting us know. I'm sitting here assuming its not my subscription type. Ill check West Europe just in case..., but otherwise it might be my PAYG sub type. I'm not sure there is another type immediately available for me.

[techmoc]

@Granville just rechecked the guide for any updates... it only states at the end to not choose a Trial or CSP subscription type and a couple of lines below to not use specific characters on the template

"The following characters are not being used in the template: ' ~ ! @ # $ % ^ & * ( ) = + _ [ ] { } \\\\ | ; : ' \\\" , < > / ?.\" '."

[Granville]

I just tried west Europe and I get the same error "The publisher does not offer this product in the billing region....". So if you are able to deploy there Techmoc it must be something to do with my account setup rather the a VMX100 being limited to my area?

[techmoc]

As a double check... Public IP is from region name "europewest" according to most recent Azure IP list XML

[HaloTech]

I can't deploy it anywhere, on any subscription even pay as you go.

Anyone had any luck?

Seems like I'm going to be asking for my money back since this is needless if I can't deploy it.

[Granville]

Hey Techmoc, Which billing region is your Azure tenant? will that be GB?

anyone managed to get past this issue yet?

[4zap]

@Granville I dont get a notification that the issue is fixed but this morning i was able to deploy a vMX100 in Azure WestEU with my EA subscription! I am connected with my meraki network now.... i need to configure the subnets today and then i will see if it is working as expected. But for the first approach it looks good!

[Granville]

Hi 4zap, We tried around an hour ago and it deployed ok. I also just has a message from Meraki to say engineering made an update last night.

So we are up and running...

[4zap]

Nice, it seems they made some improvements last night. I have hustle to assign subnets... we are working with some classic networks... the ressource group that is created while installing the vMX VM in Azure is write protected and i cant remove the lock to make any changes in the subnet assignment. I tried to peer both (classic and ressource based networks) but i always get the error that the vMX RG is locked..... 😞

[techmoc]

@4zapsince it is deployed as a managed application, the deployment generated resource group is basically locked by design. I did test creating subnets in another RG and added them using vnet peering option. I only tested ARM vnet and was able to get it working as needed. I'll see if I can incorporate a classic vnet and let you know

[Granville]

We will have these challenges to start testing very soon. Thanks for your feedback. Have clicked the Kudos button hope you win some socks...

[techmoc]

Thanks @Granville, I did a simple test regarding integration of a classic vnet to the VPN community.

Peering between vnet and classsic vnet works and I am able to ping devices on classic vnet from the vMX ping tool, the difference is on the ip route since resource doesnt support classic vnet. As mentioned on the VNET peering docs, peering between vnets with different deployment types and even subs is supported and works but to route traffic you need to add azure gateway resources between the vnets to be able to route traffic to/from the vnet/subnet where the vMX is deployed and the classic vnet/subnet. Check Create a virtual network peering - different deployment models, same subscription

During my tests I can see the most important thing is to have the resource groups and vnets/subnets created before and make sure only vMX resources are deployed on the vMX and Managed App resource groups to avoid getting other resources locked that you may need to modify later.

Cuauhtemoc

[Uberseehandel]

It appears that there are capacity issues with Azure's UK West and UK South regions.

[techmoc]

@Granville my Azure AD tenant is in US

[IngramLeedy]

Does the license you buy from Meraki include the VM or is the VM an additional cost. From what I can tell the VM is about $85/month. Any clarification would be helpful. THanks!

[MRCUR]

@IngramLeedy Azure or AWS charges are not included in the vMX license. There is no hardware cost to the vMX from Meraki since you need to pay Microsoft or Amazon to run the appliance. You're just paying Meraki for the software license. 

[AbhilashRN]

I can confirm from the Azure side, you will have to pay for the compute power, in this case, the Virtual Machine on which you deploy the Meraki image. The overall cost per month depends on the Tier of the Azure VM, Disk Size, number of cores,  Disk Type (Managed or Unmanaged) and if you would like Azure support services for any issues with the VM instance itself. 

Please use the following link to calculate the costs for your virtual machine - https://azure.microsoft.com/en-us/pricing/calculator/#virtual-machines1

- Opting for the Azure Support plan, Azure teams will assist you with any issues with the NIC, underlying network infrastructure, migration to a different network for example. 

- Please note that the Meraki documentation recommends an Azure VM of minimum size Standard D2_V2, you can also find the detailed documentation of Azure VM sizes and types at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes

- Detailed documentation on the managed disk feature for Azure IaaS VMs can be found at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/faq-for-disks

[AbhilashRN]

@IngramLeedy

[Reinout]

No luck in West-europe...

Oops!

Could not create the marketplace item

This marketplace item is not available.

... And all we wanted is to build a route based (dynamic) VPN with the MX84... Since this could be done (Meraki does not support that), we waiting for the vMX100 to bypass the limitations of a policy based (static) VPN in azure... a bit disappointed  

[CiscoKid78]

BklynITGuy, I have been working extensively with this particular issue with a client and have formulated two possible paths for them to try. The first is to use the AzureRM PowerShell commands to review VMImage repository for their EastUS region for the availability for their subscription ID access and what they can see publicly. I tried the same AzureRM PowerShell commands with my subscription and although I can see 2 templates they fail to deploy because my Azure subscription hasn't been authorized for the beta program that can only be authorized by a Cisco Meraki representative. The other option I have formulated for the client was to use a Template that I have written and imported on my Azure subscription but again...it fails because I am not authorized to participate in the beta program as per Cisco Meraki.

The sad thing is after developing these two possible avenues for this client I am not longer able to get a hold of them to try either of these two approaches. We have tried just about everything for this client to even procure a few MX64 appliances and ask for a trial vMX100 to simulate this clients environment. We went as far as even trying to work different channels to see if we could be late participants to the beta for Cisco Meraki and Azure and they said unfortunately it was closed due to the release date being so close. Anyway, I think your best bet being you do have access to the beta program from Cisco Meraki is to try the AzureRM PowerShell method if you haven't already resolved the issue by other means.

[JuanK]

I am having exactly the same issue. i have re-deployed this multiple times and i cannot associate the subnet to the vmx100, called support and azure and both are finger-pointing each other.

[BklynITGuy]

Curious how long the appliances has taken some of you guys to deploy successfully? I have a deployment running now and it's at about 33 minutes... I don't see any errors on the Azure side, it just seems to be taking long.

[BklynITGuy]

Welp, never mind.  After about 40 mins, got the following:

{ "status": "Failed", "error": { "code": "ApplianceDeploymentFailed", "message": "The operation to create appliance failed. Please check operations of deployment 'e66f5b3b08274953a0be4cd24e589cc6' under resource group '/subscriptions/xxxxxx-1d6a-4e8d-87fc-de2382680e4b/resourceGroups/XXXX-VMXicr32w4ebkd6k'." } }

[BklynITGuy]

Ok, so not sure if anyone else has experienced this or figured it out.. Brand new RG/Vnet, etc...

Problem I have now is when I try to associate the vvnet/subnet to the route table, I get an error that it failed to save subnet due to the resource being locked.  , I  cant  figure out if i'm missing something

[4zap]

The lock is the problem, you cant make any changes in the RG.  I run into the same issue. I talked to the Azure Team and the Meraki Support. Meraki told me that there may be an issue with the lock and they notify me when the problem is solved. Seems the vMX isn't ready yet, lets wait till monday.

[BklynITGuy]

Yea last I checked with Meraki, this was by design to have that lock. But it makes it impossible to go through their remaining steps. I haven't tried via powershell, i wonder if that'd make any difference

[PRISMI]

Hi ,

Today i have deployed on azure trial of vmx100. I have create all the static vpn. 
the problem now is that i can't stop, restart the VM. I recive error with resource locked.
i can't change Managed resource group too.

error is :

The scope '/subscriptions/dc63112c-4031-43f4-a43b-3cc6cbb74795/resourcegroups/MerakiRGoupfteqm5i5vgjp2' cannot perform write operation because following scope(s) are locked: '/subscriptions/dc63112c-4031-43f4-a43b-3cc6cbb74795/resourceGroups/MerakiRGoupfteqm5i5vgjp2'. Please remove the lock and try again. (Code: ScopeLocked)

[CiscoKid78]

I think it's pretty much unanimous that the problems described here with other Azure subscribers trying to deploy the vMX100 that there is indeed an issue with the lock on the named Azure Resource Group.  The result of this deployment cause a "Shadow" Resource Group where the VM for the vMX100 lives.  My suspicion is that even though PowerShell one would run into this probably unless we can isolate just the VMImage deployment via PowerShell.  Deploying the vMX100 from the MarketPlace does so as an application where it's deployment tasks places a lock on the Resource Group almost immediately.  I'll try to create a PowerShell VMImage deployment task now that I have the some time and that the vMX100 is now out of the Beta phase.  I'll report back.

What is so secret about the vMX100 deployment versus the Cisco CSR1000V that requires a lock on the Resource Group?  Cisco felt it necessary to empower Azure subscribers by offering the flexibility to manipulate the Resource Group associated with the CSR1000V.  Why the 180 degree change dealing with this particular vMX100 appliance?  Cisco?

[PRISMI]

Thanks a lot for all the informations.

🙂

[techmoc]

@CiscoKid78 

In my case I did mention regarding the resource lock the following on a previous post:

"have the resource groups and vnets/subnets created before and make sure only vMX resources are deployed on the vMX and Managed App resource groups to avoid getting other resources locked that you may need to modify later"

The Setup Guide also warns. What it doesn't say is that only deployment resources should be added automatically to the created RG to avoid the resource lock. If all vnets, subnets, route table, etc are added to a separate RG they can be modified and associated without a problem.

I think the lock by design is more of a managed application practice on the Azure side

[BklynITGuy]

So when I created the resource group, vnet, and subnet first, I try to add that VMX appliance to the resource group and it says the following:

That RG has the vnet/subnet already. Am I going in the wrong order on this?

[BklynITGuy]

So I was able to get it deployed, it was a bit unorthodox, but it worked.

-I assigned the VMX to the new (empty) RG

-Then on another tab, I created the vnet/subnet and assigned them to that RG

-Then went back to the VMX creation page and used the newly created vnet/subnet

It deployed successfully. Now Meraki support said you should be able to create this in an existing vnet, however I was unsuccessful in doing so. So I created peerings between the 2 vnets. I tested a VM and confirm it could ping the VMX from a different vnet.

Still having some issues pinging from Azure to our on-prem site, but I think that could be resolved once we look into the routings a bit more.

[HaloTech]

I totally just gave up on it, since I was testing it out as a proof of concept for another project. After 2 days of head desking I asked for RMA.

[4zap]

Nice! Will try it this way...after i tried it 2 times to redeploy in different ways i gave up today, but with this info i will try again.

[4zap]

failed again. Did not get it running. Need to connect it to a classic created network ressource. From the vMX RG i cant peer this network because of the lock (that i can not remove or change). And the classic network has no option for peering, only ARM RG networks does provide the peering option. I need to setup different DNS Servers in the vMX network, but i run always in the lock. This i anoying. Any changes i need to do are restricted by the lock. when i try to remove the lock i get the message that this is a child lock, i need to delock the parent ressource group, but in the parent RG is no lock visible...... i give up till the support tells me that they had fixed it.

[Andreas]

I have the same issues, installing the vmx into our test subscription. With a prepared vnet and subnet, all fine. If i want to create a route and attach this to the meraki subnet.. no chance. It says it cant added to the resource group, because it is write protected. 

Looks like a beta test... 

[4zap]

Still stuck at the same point once again. Locked ressource, it tells me that a child lock is set. When i try to delock the parent there is no lock visible. While i deployed the vMX in Azure the deployment creates a "shadow" - ressource group where all the deployments are included (network card, network, VM, disks ....) This shadow RG is locked by design as far as i figured out.

I talked to a Meraki Support Engineer today, he will provide me a solution till monday. I let you know if i will be able to solve it and if so  i will post the workaround here next week.

[4zap]

Ok, it runs well now. What we did:

- create a virtual network (ARM) in your default network ressource group where you need it -> give the network a unique name

- deploy a vMX100 in Azure, when you get asked at step2 to define a virtual network there is already a proposal for a new virtual network visible ->(new)vmx-net. Dont use this. choose the virtual network which you had created before with the unique name. finish all the steps from the deployment -> setup a routing table as in the documentation described. Thats it! It is running, After i assigned my subnets i was able to ping the vMX from any tenant and from any office (we have a full meshed meraki network onprem with site2site Meraki VPN).

Additional to this deployment i was able to peer classic virtual network ressources to the new virtual network. From the old ressources i am now able to ping the vMX and any Meraki in any country.

Good Luck!

[AbhilashRN]

My findings: 

Unfortunately you will not be able to remove the locks on the Resource Group created by default while deploying the vMX100 Appliance on the Azure VM. We have observed several similar issues raised and this by vMX10 is getting the Resource Group locked.

So below is the best practice work around – to avoid any other resources being locked.

Scenario: If you have a VNET: VNET1 in a Resource Group: RG1 in the location: US East (Example) where you would like to deploy the vMX100 appliance.

• Step 1: Create an empty Resource Group: RG2 in the US East (Same as where your VNET is) location.
• Step 2: While deploying the vMX100 using the documentation at https://documentation.meraki.com/MX-Z/Installation_Guides/vMX100_Setup_Guide_for_Microsoft_Azure while configuring the basic settings (Step 1), instead of creating a new Resource Group use the existing RG option to select RG2
• Step 3: As the RG2 resource group is in the same location you be able to select VNET1 virtual network/subnet to deploy the vMX100 on the VM1 in VNET1.
• Step 4: Once you complete the rest of the deployment you will also find that from RG2 there will be a new RG2XXXXXXXX resource group created, which is being done by the vMX100 image itself. And this RG2XXXXXXXX is being locked.
• Step 5: Following the above steps you will only have vMX100 VM on the locked Resource Group: RG2XXXXXXXX and therefore you still be able to make changes to the VNET1.
• This work around will isolate the locked Resource Group: RG2XXXXXXXX to contain only one resource the vMX100.
• After deploying the vMX100 VM, please create the route table as per the https://documentation.meraki.com/MX-Z/Installation_Guides/vMX100_Setup_Guide_for_Microsoft_Azure in the RG2 resource group only.

Note: Resource Group is only a logical container to put all the related resources in to one container, to make it easier to manage. So the extra resource group will not create any additional charges.

[MRCUR]

@AbhilashRN  Thanks for the excellent directions. These worked perfectly for me and now I have a vMX in its own RG that isn't locked. 

Forgive my unfamiliarity with Azure - but did you create a subnet dedicated to the vMX WAN port and then have another subnet used for the inside (what's supposed to be tunneled out the vMX)? 

Also, anyone figure out a way to set a static IP on the vMX WAN (not sure this really matters)? 

[Speightz]

Did anyone figure out how to set static IP? I also cannot set static IP address which I require as I want to terminate 3rd party VPNs into Azure also... due to the lock. 

I tried to delete the lock with powershell but it wouldn't let me. I dont like the Resource Group it creates and was trying to move the resources to a tidy RG.

Feels very Beta TBH. Its a shame it doesn't have NAT mode either.

[MRCUR]

@Speightz You definitely can't change the public IP to be static because of the lock. But as long as you don't de-provision the vMX, the IP won't ever change so it shouldn't be an issue to set up the S2S VPN's. 

[LucPaquet]

Because of the lock problem with my 2 vMX, I was not able to stop 2 VMs in Azure. I open a case with Meraki support and here their response. I did it and it worked fine. 

"When the appliance is created and you create a new Resource group it also creates another read only resource group. This is what is locked and caused a lot of the issues as I create the network during setup it became read only effecting the rest of our Azure setup. If you need to delete the appliance and start again you need to do the following:
1) Bring up all the resource groups in the Azure portal.
2) open the resource group that you created in the guide above.
3) In this resource group you will see a managed application which is a large bunch of letters and numbers. This is also the name of the lock that is in the read only resource group. If you delete this managed application it will also delete the read only resource group and the locks allowing you to start again."

[bholmes12]

@AbhilashRN@MRCUR

I seem to have run into this same issue.

I want to make sure that i am understanding this correctly. I have a couple questions.

1. Before I start the vMX deployment i need to create a RG and a Vnet?

2. Your step 3 ) At this point select that Vnet. What about the subnet? Does that also need to be pre-created or can that be done during the deployment? Or do i just leave that as default?

3. If i want to have the vmX in a /24, but I also want several other /24's available for VM's how do I accomplish that?

Very new to Azure, any help would be greatly appreciated.

[MRCUR]

@bholmes12 I'll try to answer these as best I can from memory:

1) Before you deploy the vMX, you should have two resource groups. One of them should be for your servers, the other should only be for the vMX. You should also create the VNet you want the vMX to be in ahead of time and place this in the first resource group - NOT the RG that's only for the vMX. 

2) Pick the VNet that is in the first RG. This will be the VNet that the vMX gets an IP from. I use a dedicated subnet in the VNet just for the vMX. 

3) Add multiple subnets to the VNet. As an example, I use the 192.168.0.0/16 address space for my VNet. This is set on the "Address space" page under the VNet. Under the "Subnets" page, I then have multiple /24's defined (within the 192.168.X.X space). One of these I call vMX-Net and it is the /24 I use for the vMX and nothing else. 

One other thing - when you create the route table for the vMX, you should create this in the RG that is only for the vMX. Don't create the route table in the RG you use for other servers. After you've deployed the vMX, don't add anything else to the vMX RG. 

[Christian87]

Hello together,

i have a problem to make changes at the vnet configuration. The problem is that the meraki managed application locked the thr resource group at azure. In this case a want remove the lock from the resource group but i get a error message that this change is not possible. 

Have anybody some ideas to solve my problem to remove the locked on the resource group. I want to move the resource to another resource group and recreating the lock.

Thanks for your help.

Best regards 

Christian

[MRCUR]

@Christian87 See my post here: https://community.meraki.com/t5/Security-SD-WAN/vMX100-Azure-Cloud/m-p/12205/highlight/true#M2969

You cannot remove the lock on the resource group the vMX is deployed in. Because of this, you need to place the vnet in another RG. Nothing should be in the RG with the vMX as it will be locked during the deployment. You'll need to redeploy the vMX to correct this. 

[Jerome_T]

Hi Chrsitian,

I just wrote a blog post on my experiences with the vMX on Azure: https://aboutnetworks.net/deploy-a-cisco-meraki-vmx-into-azure/

The lock is normal on this resource-group. You don't need to touch this resource-group.

For the static route into Azure route table, you should associate your server(s) subnet(s), not the vMX subnet as specified into the Meraki documentation.

I hope this helps.

Best Rgds,

Jerome

[Dudleydogg]

This article is few months back have you had any different Luck with the Client VPN in Azure?

My vMX is on the same subnet as my Virtual Machines infrastructure in Azure which I see you suggested a separate Subnet but did not state if that was a fix for the Client VPN issue not passing traffic.  I was told per Meraki that this should work and I do not need to split Tunnel.

Which I could get a straight Answer from Azure or Meraki.

Thanks

[Dudleydogg]

For to Mention this !!!
Public Betas Available
IKEv2
Includes support for Route-based VPN's
So then Bye Bye vMX going back to the old way i did VPN.

[MJPAGAN]

Public beta of software for the hardware or the vMX?

[Dudleydogg]

For hardware device meaning you won’t need a vMX for Azure can use route based IKE_v2 vpn from Azure to on Prem MX devices then use Azure Radius Auth for Client VPN. I complained about that lacking feature 

[Dudleydogg]

For hardware device meaning you won’t need a vMX for Azure can use route based IKEv2 vpn from Azure to on Prem MX devices then use Azure Radius Auth for Client VPN. I complained about that lacking feature 

[MJPAGAN]

I've been waiting for IKEv2 and route based VPN capabilities. Do you happen to have a link for that public preview or any articles referencing it. I haven't seen anything yet.

[Dudleydogg]

It was the Meraki quarterly webinar, I did not attend but someone forwarded me the information because they knew how livid I was over Meraki not supporting IKEv2 forcing me to buy a vMX license just to make it all work. Now I am going back to route Based, and will enable Client VPN in Azure using Radius going to test all that tonight.

[MJPAGAN]

Cool. I found a tread in the Community forums so I've opened a case so I hope I can get access soon to test it out also. I have a number of customers who could use this. Thanks for sharing.

https://community.meraki.com/t5/Security-SD-WAN/IKEv2-support-on-MX-devices/td-p/37709

[Dudleydogg]

I think if you just to to Organization and under Firmware settings set your MX to Beta then schedule an upgrade.
You can always roll back. If that's not the case and you did have to open a Meraki support case let me know.
Tap my Kudos button don't have any of those yet LOL.

[MattPainter]

I got the beta update 15.13. Now I need to find some setup directions for route based VPNs. I hope to try it out this weekend.

[Dudleydogg]

Route based is the Default in Azure Just click on your Dashboard and search for "Virtual Network Gateways"  click ADD Choose your subscription, name the gateway, make sure you choose correct region and put the gateway in same resource group as your Vnet (keep it easy).  SKU can be standard or VpnGw1 << is better than you can modify later.

under Virtual Network choose the Vnet you want to put the VPN on.

Create new public IP and wait for like 20 minutes it takes a bit.

you will have to create a Root Certificate and User Certificates for IKE SSTP this one is tricky to manage if you want a cert for each user. 

There are guides out there but its not difficult to setup.

I configured mine for Radius Authentication.

FYI policy based is the IKE_v1 we dont want that !!!

[LucPaquet]

Same problem here. Ping is working fine between the MX and the vMX but cannot goes further.
"Still having some issues pinging from Azure to our on-prem site, but I think that could be resolved once we look into the routings a bit more."
Have you solve that one?

[MRCUR]

@LucPaquet Did you set up the route table per the documentation? I have a vMX deployed and have no issues pinging from on-prem to the servers in Azure. 

[4zap]

From where do you ping? From VM in a classic resource model there are problems with the routing because you have no gateway traffic if you peered it with the new resource network. From a new ARM model deployed VM and an routing table in the vMX resource group i can ping any machine in our subnets. The routing table must contain all subnets outside this azure location with the vMX as gateway. does your routing table contains alls subnets and the vMX as gateway? Did you setup all local network scopes in the meraki dashboard for this meraki network location?

[LucPaquet]

Hi

Ping that are ok

- MX (192.168.1.1) <--> vMX (10.1.1.4)

- Mac (192.168.1.22) <--> MX (192.168.1.1)

- vMX(10.1.1.4) <--> VMwin2016(10.1.1.5)

Ping that are not OK

- MX <--> VMwin2016

- vMX <--> Mac

- Mac <--> VMwin2016

The GTW for PC is the MX and for the PC2 is the vMX. Both MX and vMX are in a DMZ with natting. 

I'm new to Azure, what you mean by ARM? How to check what I used?

Thanks

[MRCUR]

@LucPaquet Hmm, the vMX shouldn't be set as the gateway for any of your Azure VM's. You need to create a route table in the VNET where your VM's reside that has your vMX as the next hop. That way Azure will take care of the routing. Make sure you update the vMX routes in Dashboard too. 

ARM is Azure Resource Manager and is the "new" way of managing resources inside of Azure (everything goes into resource groups). If you've recently set everything up, you're most likely using ARM as it's been around for a bit now. 

[JohnS]

Any idea when the vMX100 will be available in Azure CSP? We have customers use Meraki appliance at HQ and Branch offices, the servers are in Azure CSP. now they cannot connect all locations together. 

Meraki does not support IKEv2, vMX100 is the only solution to get all locations connected, however, vMX100 does not work in CSP, we have been stuck for months now.

Help Please. 

[4zap]

In this case i would open a support case in the meraki dashboard and ask a support technican.

[MRCUR]

---

@JohnS wrote:

Any idea when the vMX100 will be available in Azure CSP? We have customers use Meraki appliance at HQ and Branch offices, the servers are in Azure CSP. now they cannot connect all locations together. 

Meraki does not support IKEv2, vMX100 is the only solution to get all locations connected, however, vMX100 does not work in CSP, we have been stuck for months now.

Help Please. 

---

@MerakiDave Can you check if there is a FR for the vMX to support CSP billing in Azure? 

[LucPaquet]

I restarted my proof of concept Site to site VPN (MX and vMX) in Azure.
I'm lost. Here my setup:

2 Windows 10 VM in Azure, both in the same vNet as the vMX, one in the same subnet, 
Windows 10 - 1 : 10.0.0.x and a public IP
Windows 10 - 2 : 10.0.2.x and a public IP
vMX : 10.0.0.4
Azure Route table 1 - 10.0.0.0/24 next hop : 10.0.0.4
Azure Route table 2 - 10.0.2.0/24 next hop : 10.0.0.4
MX - 192.168.1.1

MX and vMX can ping each other.
That's the only thing the vMX can ping. Both Windows 10 are not able to ping each other. 
Windows Firewalls are turned OFF on both Windows 10 and Azure NSG is open to any-any for inbound and outbound.

Route tables in the MX and vMX network are perfect.

So, why the vMX and the 2 Windows 10 cannot see each other?

[MRCUR]

@LucPaquet Two things: 

1) I'm not sure it's supported to have the vMX in the same VNET as VM's. I would recommend creating a VNET just for the vMX to sit inside. The vMX should get an IP from this VNET and this VNET should NOT have a route table attached to it. 

2) See attached screenshot of the local networks configured on the "Site-to-site VPN" page. Make sure you have the VNET your VM's are in configured at a minimum. I also have the VNET I use for the vMX only so I can ping it from on-prem for monitoring. vMX Local Networks

[LucPaquet]

@MRCUR - I'll do that tonight

Question: Do I have to peer the 2 vNET in Azure or the vMX will do the job?

Thanks

[JohnS]

Can we terminate the client to site VPN into the vMX just like what we do with the physical appliance?

[MRCUR]

@JohnS I believe client VPN is available on the vMX but have not confirmed if it works. The config is available in Dashboard though. 

[LucPaquet]

@MRCUR I did a new vNET-subnet and put a Win10 there.... and still no way to ping between the VM and the vMX.

If you're up for the challenge to resolve my issue....

https://drive.google.com/drive/folders/1qhdXhyeHAr68ZenRvfj_-2Ot90Io4ajc?usp=sharing

You will find there a lot of stuff. 

You could reach me with : luc.paquet@gmail.com

Thanks

[MRCUR]

@LucPaquet I think your route table in Azure is the issue. It looks like you're using 192.168.1/2/3.X/24 on-prem, correct? 

You need routes in the Azure route table for those subnets so the VM's in Azure know to route traffic to those subnets via the vMX. Your on-prem MX already has a route to the vMX 192.168.4.0/24 subnet. 

Take a look at the screenshot of my route table in Azure. 192.168.161.4 is my vMX in Azure while the other subnets are all used on-prem. The 192.168.162.0/24 subnet is what the VM's in Azure use. 

[LucPaquet]

@MRCUR big thanks. I'll try that right now.

[Dudleydogg]

It kinda works just no internet that is what im trying to get past today.

[MRCUR]

@LucPaquet No need to do any VNET peering. Just make sure you have the route table set up on the VNET for VM's to point to the vMX IP. You don't need any route tables on the VNET the vMX is in. 

[Dudleydogg]

A completely Different Virtual Network or just a Different Subnet in the same Virtual Network?

other wise you would have to peer the 2 Vnets to hit Azure VM?

Your suggestion caught my attention because my vMX is in the same Vnet as the azure VM's and I have access to all everything works except.

users on the VPN have no  internet access while on the VPN.

I had to do split tunnel and set metric on VPN interface.

[Manabu]

I envy you all...

I have been participating the beta program since the beginning of October. However, I have not succeeded to deploy the vMX100 on Azure yet.

During the deployment, Azure console says "The publisher does not offer this product in the billing region of your subscription. Please choose another subscription.", and it failed.

Is there any person who has encountered the same problem?

[Granville]

Getting the same issue here, deploying to North Europe.

Have raised with Support, account manager and our technical lead.

[MRCUR]

For those who have deployed the vMX in Azure, is the "Historical data" working for you on the Uplink page? I have the default destination of 8.8.8.8 configured on the Traffic Shaping page along with an additional IP. I can see the traffic through a pcap, but am not seeing anything reflected in Dashboard.

[MRCUR]

---

@MRCUR wrote:

For those who have deployed the vMX in Azure, is the "Historical data" working for you on the Uplink page? I have the default destination of 8.8.8.8 configured on the Traffic Shaping page along with an additional IP. I can see the traffic through a pcap, but am not seeing anything reflected in Dashboard.

---

This is corrected in firmware 14.19. 

[Speightz]

Update from my testing so far. My vMX100 has been down for about 3 weeks while I bounce between Azure support and Meraki support.

The issue was I ran out of credit and the vMX was de-allocated after de-allocation I cannot start the VM again due to you guessed it the "lock" 

Azure support say they cannot remove the lock cause it is placed by Cisco in the logs. 

Cisco Meraki support say they didn't put the lock there...

Can anyone else de-allocate their vMX100 and can start it again?

I think RMA for me is best option at this stage the lock has to go!

[LucPaquet]

Check my post. This will help you.

https://community.meraki.com/t5/Security-SD-WAN/vMX100-Azure-Cloud/m-p/10121/highlight/true#M2490