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
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
Public beta of software for the hardware or the vMX?
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
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
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.
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.
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 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.
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?
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
@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.
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.
@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?
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?
@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
@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
Can we terminate the client to site VPN into the vMX just like what we do with the physical appliance?
@JohnS I believe client VPN is available on the vMX but have not confirmed if it works. The config is available in Dashboard though.
@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
@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.
It kinda works just no internet that is what im trying to get past today.
@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.
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.
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?
Getting the same issue here, deploying to North Europe.
Have raised with Support, account manager and our technical lead.
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 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.
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!
Check my post. This will help you.
https://community.meraki.com/t5/Security-SD-WAN/vMX100-Azure-Cloud/m-p/10121/highlight/true#M2490