When the vMX has been provisioned to Azure, and come online, it should pull an address on its LAN interface. Usually it will only be in VPN Concentrator mode. NAT mode should only be used in certain specific scenarios.
After pulling an address (usually .4 in your vmx subnet), you need to setup a routetable in Azure, to route back and forth between the vMX and other ressources in Azure.
The VPN settings shown in your first screenshot refer to those vnets you have configured in Azure. these are then announced into the AutoVPN topology, and thus known to your spokes/hubs across AutoVPN.
Assuming you used 172.16.0.0/12 at your spokes and 10.0.0.0/8 in Azure for whatever cloud servers, you'd usually enter 10.0.0.0/8 in the VPN settings on the vMX. Then this entire /8 will be announced to all your spoke sites that are using 172.16.0.0/12. In turn, the spokes will have 10.0.0.0/8 in their routetable showing the vMX as the next.hop for this subnet.
In Azure, you'd add 172.16.0.0/12 to the routetable with the vMX IP address as nexthop. In your case that would be 10.64.4.4. This is done for your servers in Azure to have a return route back to your spokes, via the vMX. The vMX will have 172.16.0.0/12 in its routetable, due to the spokes participating in AutoVPN.
When creating the Azure Routetable, make sure to attach it to your Meraki vMX Ressource Group. Also when deploying the vMX make sure you use the Standard SKU for Public IP addressing to the vMX.
LinkedIn :::
https://blog.rhbirkelund.dk/Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution
🙂All code examples are provided as is. Responsibility for Code execution lies solely your own.