Thanks Malwina,   I want this to work with certificates issues by an internal CA.    Will this work well with device certificates, or can I put user certificates in a different store? What's the best practice/does it work well?   Many thanks, ... View more

Thanks Fady,   I've had to revert to the VPN concentrator mode, and I'm trying the static solution, though the Azure resources cannot ping the branch sites, and vice-versa:   -The Azure Server subnet is correctly advertised to the branch site.  -Pings from the branch site can be seen on packet capture to cross the VPN, and leave the VMX, but do not come back to the VMX -The VMX can ping the servers, and the servers can ping the VMX -There is a route table attached to the server subnet which includes the VMX subnet and the branch subnet -There is an entry in the server subnet's NSG allowing traffic from the branch site -Essentially the same settings as when the routing worked when the VMX was in routed mode   You've mentioned that there needs to be a route table attached to the VMX subnet to point to the server subnet if they are in separate VNETS - they are in separate VNETS, but there is VNET peering, and the VMX can ping the servers without a route table.   I've added a route table, but this doesn't make a difference - Can you confirm what the next hop should be in the route table?   Thanks,    ... View more

I had restarted the branch MX to ensure that the tunnel was re-established and still working with the setup, which it was (unless you mean restart the VMX?)   My understanding of what was happening was the static route on the VMX does not go active, and is ignored in VMX routing lookups, and all VMX traffic (except traffic to  branch sites) is sent out the default route. I have now actually set the static route to be inactive if the next hop IP is unavailable, which it always will be, as the IP I've used for next hop is not assigned to anything. So the static route is always inactive, but always advertises the Azure subnets to branch sites.   Ultimately, the solution is not supported, and this is not the desired behaviour, so I can't deploy it.   It's just very strange that the default deployment for a VMX is routed mode; a mode which means that as part of my SD WAN solution, instead of just extending SD WAN to Azure, I now have to full-tunnel all of my branch traffic to Azure (for no good reason, and for it to be subject to Azure's egress charges???)   Regardless of the mode of vMX, I don't think it is expected to communicate from the Azure subnet to the Internet via vMX. This might be the case, but who knows, as the documentation (that I've seen) doesn't explicitly say that it can't/shouldn't be doing this. I'm not sure why it couldn't act as a firewall between the internet and Azure - it is a firewall.   ... View more

After some further investigation, and calls to Meraki support, this looks like it might be the correct way to configure this, however, I have got it configured the way I want it (not force tunnel), and it seems to be working. I'll explain:   -I don't want to setup full-tunnel and send all my traffic to Azure. This is just supposed to be an extension of the SD WAN. (It wasn't clear to me initially that the requirements were to set this up in full tunnel. I've only seen this in an FAQ section - seems it would have been important to mention this in the setup docs)   -I want to use routed mode so that the VMX is the firewall between Azure resources, and the internet.   -I have managed to set this up as split tunnel, by creating a static route to the subnets in Azure that I want my branch sites to reach. I've pointed this static route to the IP on the VMX's default (192.168.128.0) LAN subnet...I've noticed that the static route doesn't go active, so it's almost useless, *except* it allows me to advertise that route over the SD WAN. So now branch sites have that route, know to route to the VMX, and then the VMXs default routing behaviour knows how to get to the subnet (I'm not sure what wasn't working previously, as it was the same principle, though I wasn't using the default LAN subnet)   My concerns deploying the solution are:   -Since this is not explicitly the expected behaviour, then some patch in future may break the whole solution -My understanding of how my workaround is working is not correct, and the solution breaks   Seems crazy that they've changed the default mode to routed mode, with minimal documentation, and with the expectation that everyone is going to full-tunnel all their branch traffic to the cloud? ... View more

Thanks, I didn't know templates were this limited. Hopefully it's possible to add specific L3 rules at each site in future, while using templates. For any updates to the "template configuration", looks like we're in the position where each firewall is going to have to be manually updated with the same rule, because many sites need specific rules. ... View more

The article I referenced references a further article "Concentrator Modes": https://documentation.meraki.com/MX/Networks_and_Routing/MX_Addressing_and_VLANs   This says: Routed Mode This is the default selection. Choose this option if you want to use the MX appliance as a layer 7 firewall to isolate and protect LAN traffic from the Internet (WAN)"     So that makes me think that the vMX is deployed in "Routed/NAT Mode Concentrator by default" and routed mode makes use of the appliance as a layer 7 firewall   ... View more

Referencing this Meraki vMX setup guide for Azure https://documentation.meraki.com/MX/MX_Installation_Guides/vMX_Setup_Guide_for_Microsoft_Azure ..it says that:   "All new vMXens deployed post October, 31, 2022 will be deployed in Routed/NAT Mode Concentrator by default, existing vMX deployments will not be effected. If you wish to use the vMX in passthrough mode, please change the deployment settings to Passthrough or VPN Concentrator mode from the Security& SD-WAN > Configure > Addressing & VLANs page. "   So this suggests that we can use the vMX as a gateway to Azure. Is this incorrect?   ... View more