I've been testing a W10Pro Client VPN with the update against different MX firmware versions 14.xx/15.xx/16.xx and found that Client VPN is working against MX 14.56 on a Z1 even though it's not against newer releases on MX appliances, so @GiacomoS it might be worthwhile to review what changed on the Client VPN code from firmware MX 14.56 vs the newer ones that are not working.   Can someone else test Client VPN with update working against MX 14.xx to confirm?   I would expect a faster fix from MX firmware Dev/Support team vs waiting for Microsoft to release a hotfix that would have to be deployed or waiting it to be rolled in a future update. ... View more

@miki777 we recently had to setup the MX84 (with 14.40) and MX64 (with 14.40) to XG210 (with SFOS 17.5.8 MR-8). We were able to keep the tunnel working with the attached MX and XG IPsec policies and a bit of screen sharing to make sure VPN subnets/communities were set up correctly.   I don't know if it's still relevant for your case, but since I don't see a lot of info about Meraki with Sophos, I'll just leave this here.   MX84 custom IPsec   XG210 custom IPsec     ... View more

Same error... I checked some Orgs on different shards and initially thought issue is was at shard level, but on some shards I get mixed results at an Org level. Shards n131, n196: some orgs return client details, some return the error message Shards n63, n126, n149: all orgs checked returns error message Change management issue? Hope this is resolved quickly. ... View more

@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       ... View more

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 ... View more

@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 ... View more

@Granville my Azure AD tenant is in US ... View more

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

@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: ' ~ ! @ # $ % ^ & * ( ) = + _ [ ] { } \\\\ | ; : ' \\\" , < > / ?.\" '." ... View more

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.   ... View more

@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  ... View more

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. ... View more

@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 ... View more

 vMX100 Image location:   https://gallery.azure.com/artifact/20151001/cisco.meraki-vmxmeraki-vmx100.1.0.0/Artifacts   Deploying...  ... View more

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 ... View more

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 ... View more