Skip to main content
Cisco Meraki Documentation

vMX NAT Mode Use Cases and FAQ

The document outlines various use cases and frequently asked questions regarding vMX NAT mode, including its deployment scenarios, limitations, and configurations for virtual MX appliances in NAT mode on the Meraki platform.
The document outlines various use cases and frequently asked questions regarding vMX NAT mode, including its deployment scenarios, limitations, and configurations for virtual MX appliances in NAT mode on the Meraki platform.

NAT Mode on the vMX Overview

NAT Mode vMX will simplify cloud deployments. It allows customers to NAT traffic coming over auto-VPN or client VPN to the vMX IP as it egresses the vMX so that it can reach resources inside their public or private cloud environments without needing to setup and maintain individual routes for branch sites. Other capabilities of the NAT mode including DHCP, HA or multiple ports (LAN and WAN) are not supported on the vMX at this time.  In this mode the vMX is still a one-armed appliance with one network interface.

All new vMXs deployed post October, 31, 2022 will be deployed in Routed/NAT Mode by default, existing vMX deployments will not be effectedIf 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. 

Dashboard UI Addressing and VLANs device set to Routed mode


Dashboard UI Addressing and VLANs device set to use Single LAN

Do not modify the subnets section under Security & SD-WAN > Configure > Addressing & VLANs by adding or removing subnets as this will break the routing behavior of a vMX in NAT mode.

The vMX may not reply to ICMP requests destined to its LAN IP. In the image above the LAN IP is

vMXs in NAT mode will not advertise subnets that are available on the public/private cloud, so spoke MXs will have to send all their traffic to the vMX, which will then NAT the traffic and send it across its WAN interface into the public/private cloud environment. 

As vMXs in NAT mode function as stateful firewalls, any traffic that is initiated from the cloud environment will be dropped due to the lack of a corresponding flow initiated from the other end, be it Auto-VPN or Client VPN. 

Spokes will have to full tunnel all their traffic to a vMX in NAT mode, if they want to access resources inside the public/private cloud.

If users behind remote sites participating in AutoVPN want to reach certain subnets (split tunnel) on the public/private cloud environment, then the vMX will have to be set to passthrough mode. This is so that users can advertise those specific subnets, by configuring them under Security & SD-WAN > Configure > Site-to-Site VPN page of the vMX.

Common Use Cases

1. Scaling Client VPN using Public Cloud vMX

The vMX supports Client VPN, which allows remote clients to securely connect to their cloud environment and other resources at remote sites participating in AutoVPN. However, if the vMX is deployed in Passthrough mode, you would need to either do a split tunnel or use an additional third party NAT device for Internet-Bound traffic. 

With NAT Mode vMX, any traffic from the client devices will get NATed to the vMX WAN IP and you will not have to be concerned with managing an additional solution for securing Internet-bound traffic for Client VPN devices as the same upstream internet gateway can be used to exit out to the internet.  

Diagram of how client traffic traverses through to Internet-bound and remote resources in infrastructure with a vMX in place


For Public Cloud vMXs participating in IPSec and/or AutoVPN, customers have to configure individual routes destined for subnets at the other end of the VPN tunnel. These routes are necessary and act as return routes for any inbound traffic attempting to reach Public Cloud resources over VPN. When many physical branches with multiple subnets participate in AutoVPN, updating the cloud routing tables with the respective return routes becomes challenging.

With NAT Mode vMX we don't need to maintain individual routes for the branch sites on the cloud as the VPN traffic get's NATed to the vMX's WAN IP. NAT vMX tremendously decreases the amount of configuration and management required for Public Cloud subnets to have return routes over VPN.

Internet-bound / remote resources   Diagram shows example vMX branches with NAT mode showing that VPN traffic will be NATed to the vMX IP

The above diagram illustrates the simplicity of routing on the cloud environments. 

  • Branches are advertising Subnet A, Subnet B and Subnet C
  • Without NAT mode, each branch route/subnet has to be programmed on the VPC/vNET routing table with the next hop as the vMX

  • With NAT mode, the VPN traffic will be NATed to the vMX IP and since the VPC/vNET is aware of the vMX IP as the local subnet no need to program each individual branch route/subnet. 


How to enable NAT mode vMX?

NAT mode is enabled by default on the vMXs deployed after October 31st, 2022. However, if you want to enable NAT mode on an existing vMX instance, you can change the settings from the Security & SD-WAN > Configure > Addressing & VLANs page. 

How to check if NAT mode is enabled for vMX?

Go to Security & SD-WAN > Configure > Addressing & VLANs and make sure that the vMX is set to "Routed" mode.

Does the vMX support multiple LAN/WAN interface in NAT mode?

No, the vMX is a single interface instance.

How to configure spokes for NAT mode vMX?

Enable site-to-site VPN for the spokes and set the NAT mode vMX as the Hub. Next, make sure to select enable full-tunnel to the vMX by selecting IPv4 default route to true under the hub settings. 

What is the advantage of running vMX in NAT mode?

You don’t have to set return path routing inside the VPC/vNET with NAT mode vMX since the VPC/vNET will see all traffic coming from the vMX which it already knows how to route back to.

How to setup routing for NAT mode vMX on the cloud? 

Once, the vMX is deployed in NAT mode all traffic coming over the VPN will be NAT'ed to it's WAN IP, so there is no need to setup a return path for the VPN traffic. Meaning, that no additional routes needs to be setup for the auto-vpn routes in the VPC. In most cases, the default VPC routes should suffice. 

  • Was this article helpful?