Hi Meraki Community,
For those who haven’t had the chance to test the new routed-mode vMX in release 19.1 with Advanced Security in Azure, I wanted to share the results of my Proof of Concept (PoC).
Until now, the vMX in Azure has been able to serve as a VPN concentrator providing client VPN termination and serving as an entry-point into Azure from the Meraki AutoVPN and vice-versa. This feature set of the vMX can be most closely compared to the Azure-native Virtual Network Gateway offering.
An often asked question is whether the vMX can provide Advanced Security features to secure traffic flows within Azure as well as from Azure workloads to the internet. While the answer to this in the past has been “no”, with the release of MX firmware 19.1, this is now a possibility.
PoC Scope
The goal of this PoC was to validate the vMX operating as a firewall in Azure to protect cloud workloads. Specifically, the vMX needs to inspect flows from vNET-homed resources to/from the Internet (North<->South) and inter-vNet/inter-VM (East<->West). Additionally, Advanced Security features are tested.
PoC Topology
- vMX in Hub vNet (10.0.0.0/16): The vMX is deployed in the Hub vNet.
- vNet Peerings: The Hub vNet is peered with Spoke1 (10.1.0.0/16) and Spoke2 (10.2.0.0/16) vNets.
- Azure Route Server: Located in the Hub vNet, it peers with the vMX LAN interface IP using eBGP.
- Route Tables: Spoke1 and Spoke2 have route tables with a User Defined Route (UDR) for 0.0.0.0/0 pointing to the vMX LAN interface IP.
PoC Findings
- Marketplace Deployment: The Cisco Meraki vMX deployment now includes an option to “Enable and configure LAN interface,” which attaches a second vNIC to the VM to act as the LAN/inside interface. This is not yet reflected in the Meraki Docs.
- Permissions: The vMX managed application now allows querying effective routes and security rules on the vMX vNICs, which was previously restricted by policy. This change also applies to new one-armed vMX deployments.
- Content Filtering: This feature works as expected.
- Inter-vNET/Inter-VM Traffic: Traffic transiting the vMX LAN interface does not have NAT applied, as expected. The Layer 3 outbound firewall on the vMX can block/allow TCP/UDP traffic.
- Internet-Bound Traffic: Traffic from Spoke1 and Spoke2 VMs to the Internet is NAT overloaded to the vMX WAN interface public IP as expected.
- Port Forwarding Rules: The vMX successfully forwards ports on the WAN interface public IP to VMs in Spoke1 and Spoke2.
- Layer 7 Firewall: This feature appears to work as expected, although not all L7 applications were tested.
- IDS/IPS: This feature is available, although I was not able to generate any traffic to test the feature.
- WAN Interface Limitation: The vMX WAN interface can only have a single IP configuration, limiting it to a single public IP address.
PoC Findings (Issues)
- Layer 3 Outbound Firewall: The vMX firewall cannot block ICMP traffic between VMs in vNets protected by the vMX. The firewall log in live tools shows the flow accepted by the L7 firewall but no L3 rule is matching. Blocking ICMP from the VM to the Internet works as expected. Blocking TCP and UDP works as expected.
- BGP Prefixes in L3 Rules: vNET prefixes learned via eBGP peering from the Azure Route Server cannot be referenced in Layer 3 outbound rules due to an error: “There were errors in saving this configuration: the IP address range 10.2.0.0/16 does not apply to any configured local or VPN subnets in the source field of the 1st firewall rule.” As a workaround, static routes for vNET prefixes must be added to configure them as source or destination prefixes in the rule. This somewhat defeats the purpose of running eBGP with the Route Server.
- Layer 7 Geo IP Blocking: This feature is unavailable.
- Advanced Malware Protection (AMP): This feature is missing.
- Traffic Interruption: Making firewall changes on the vMX briefly interrupts traffic passing through the vMX.
I have reported these issues to Meraki support, and I hope some fixes will be implemented soon.
Final Thoughts
The vMX as a firewall in Azure provides the expected functionality and meets the goals set out in the PoC scope. However, native Azure Firewall or other third-party Network Virtual Appliances (NVAs) currently offer more flexibility and features. Additionally, the vMX is not a supported security partner for Secure Azure Virtual WAN.
Depending on the Azure network architecture, requirements, and budget, the vMX as a firewall could be a suitable choice.
If you have any questions or if your observations differ from my own, let me know!
