Proof of Concept: Routed Mode vMX in Azure on MX 19.1 with Advanced Security!

ShaunB93
Here to help

Proof of Concept: Routed Mode vMX in Azure on MX 19.1 with Advanced Security!

 

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

  1. 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.
  2. 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.
  3. Content Filtering: This feature works as expected.
  4. 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.
  5. Internet-Bound Traffic: Traffic from Spoke1 and Spoke2 VMs to the Internet is NAT overloaded to the vMX WAN interface public IP as expected.
  6. Port Forwarding Rules: The vMX successfully forwards ports on the WAN interface public IP to VMs in Spoke1 and Spoke2.
  7. Layer 7 Firewall: This feature appears to work as expected, although not all L7 applications were tested.
  8. IDS/IPS: This feature is available, although I was not able to generate any traffic to test the feature.
  9. 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)

  1. 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.
  2. 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.
  3. Layer 7 Geo IP Blocking: This feature is unavailable.
  4. Advanced Malware Protection (AMP): This feature is missing.
  5. 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!

14 Replies 14
PhilipDAth
Kind of a big deal
Kind of a big deal

That was a lot of work!  Great report.

JPAWELCHAK
Getting noticed

Very exciting and great job. Thank you!

CHARTER
Forward, Together
annmarie24us
Meraki Employee
Meraki Employee

Yes, this can now serve as a point of reference. Thank you for provide such great information

Callum1
Comes here often

Hi Shaun,

On the "Azure Route Server: Located in the Hub vNet, it peers with the vMX LAN interface IP using eBGP."

i just wanted to check that you used the LAN NIC IP addresses on the azure route server peering and on the Meraki BGP peering did you select the LAN interface from the drop down or did you use the WAN interface from the drop down?


I'm trying to utilize routed mode with a route server for an azure firewall deployment, however the only way i'm getting BGP routes to be learned/advertised is by using the WAN NIC IP Address on the azure route server peering.

ShaunB93
Here to help

Hi Callum, yes, all BGP is done to/from the MX LAN IP

lovethecloud
Here to help

Hi Shaun - Great POC.....I'm wondering if Azure Route Server is a requirement, or you could accomplish the same with UDR for smaller setups? Also, what do you mean by "Traffic Interruption" when making changes to vMX? What kind of changes can cause that? Thanks in advance!

ShaunB93
Here to help

You can definitely use UDR's, I just wanted to use Route Server in this case

In regards to interruption, I noticed that when making firewall changes on the MX that traffic from a VM behind the vMX would lose connectivity for a brief period 

lovethecloud
Here to help

Hey ShaunB93,
I'm trying to deploy the Meraki vMX in routed mode, but I'm running into issues installing version 19.1 from the Azure Marketplace. Could you share how you went about deploying it or if there’s a specific workaround you used?

Thanks in advance!

jimg3
Here to help

@lovethecloud you deploy the vMX with the additional interface then upgrade to the 19.x firmware train after it is installed. stable release candidate is 19.1.7.2


lovethecloud
Here to help

I think that's what I tried but I got an interface error:

"error": { "code": "InvalidResourceReference", "message": "Resource /subscriptions/c3417xxx/resourceGroups/TEST-Meraki-vMX/providers/Microsoft.Network/virtualNetworks/TEST_vMX_vnet/subnets/lan-subnet referenced by resource /subscriptions/c3417exxxxc/resourceGroups/mrg-cisco-meraki-vmx-20250422171814/providers/Microsoft.Network/networkInterfaces/TEST-AZ-FWLanInterface was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.", "details": [] } }

lovethecloud
Here to help

Ok, got it working. I had to create the LAN subnet before Meraki deployment, not during deployment. Same goes for the WAN subnet.

Thanks! 

lovethecloud
Here to help

Another issue we found: 

Please NOTE
if the vMX will be doing 1:1 NAT port forwarding then the server subnet cannot be a part of Secure Connect. When you enable a subnet to traverse the tunnel via Secure Connect then this breaks any 1:1 NAT port forwarding rule configured in the Meraki Dasbhoard as that traffic is not sent out the local WAN anymore but over the AutoVPN tunnel to Secure Connect. So in order to do this you would need whatever server/devices that need the port forwarding to be disable from VPN participation.

jimmyt234
A model citizen

That is just a thing with Secure Connect on any MX, not just vMXs!

lovethecloud
Here to help

That's right. Thanks for clarifying

Get notified when there are additional replies to this discussion.