vMX NAT Mode Use Cases and FAQ
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. Furthermore, the vMX is used only to route and NAT traffic for remote Meraki sites. 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 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.
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 192.168.128.1.
vMXs in NAT mode will not advertise subnets that are available on the public/private cloud. If an AutoVPN peer wants to access resources inside the public/private cloud, it must send all its traffic to the vMX, which will then NAT the traffic and send it across its WAN interface into the public/private cloud environment. This requires a full tunnel configuration on the AutoVPN peer communicating with the vMX.
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. To explain this in another way, traffic initiated from the cloud provider will be statefully dropped by vMX due to the stateful nature of the vMX operating in NAT mode.
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.
2. Routing Simplicity
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.
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.
FAQs
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.