1- Switching the vMX to Routed mode does not automatically change spoke site traffic to full-tunnel. The tunnel behavior (full vs. split) is determined by the Site-to-Site VPN configuration on each spoke MX. If the spokes are configured for split-tunnel, internet-bound traffic will continue to exit locally at the spoke.
If you want Azure services to route outbound traffic through the vMX, Routed mode allows you to define default routes (0.0.0.0/0) on the vMX, which can be advertised to spokes if desired. This could make the vMX act as an internet exit hub, but only if the spokes are configured to use it as such.
2- In Routed mode, NAT is performed on the WAN interface. The MX will NAT outbound traffic from LAN subnets to the WAN IP when no specific route exists for the destination. This is typical behavior for internet-bound traffic.
3- Yes, spoke clients can still communicate with Azure servers, but there are some considerations:
- Auto VPN routes between spokes and the vMX will still function normally.
NAT on the vMX could affect return traffic if Azure services are expecting traffic from the original source IP but receive it from the vMX’s NATed IP instead.
If Azure services are sensitive to source IPs (e.g., for firewall rules or logging), you may need to adjust those configurations to account for NAT behavior.
To avoid issues, ensure static routes and firewall rules are correctly configured and consider using private IPs and bypass NAT where possible for internal Azure communication.
MX Routing Behavior - Cisco Meraki Documentation
VPN Concentrator Deployment Guide - Cisco Meraki Documentation
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.
Please, if this post was useful, leave your kudos and mark it as solved.
