NAT Exceptions/No NAT on MX Security Appliances
Overview
In some circumstances, network administrators may have topologies that require network traffic to egress the WAN interface while maintaining its private source IP address. While it is recommended to rewrite all internal source addresses to protect the internal network, some use cases require internal traffic to maintain the same internal source IP. A typical use case is a layer 3 MPLS VPNs terminating on a WAN uplink of the MX security appliance. The NAT Exceptions feature allows for MX security appliances to fulfill these use cases.
Feature
NAT Exceptions (AKA No NAT) offers the ability to configure NAT exemptions on some or all configured VLANs. This exempts the source IP address of a packet received on LAN of the MX security appliance from being rewritten as it transverses the WAN uplink.
NAT Exceptions is currently a beta feature that requires more improvement. We do not recommend beta features for production environments, however, if your deployment requires the use of this feature, we recommend testing in a lab environment first. Please feel free to email nonat@meraki.net for suggestions and feedback.
UPDATE FOR MX16 AND NEWER FIRMWARE:
In order to accommodate AnyConnect Client VPN on MX appliances, changes in firmware were required that prevent the concurrent use of Client VPN - either via AnyConnect or IPsec) - and No NAT. There are no current expectations on when concurrent functionality of these features will be restored.
We recommend using the MX in passthrough mode or terminate MPLS connections on the LAN side of the security appliance whenever possible.
Use Cases
Direct Internet Access with MPLS failover
|
|
Problem: Client needs to access MPLS network with original source IP. Solution: This problem can be solved with NAT Exceptions enabled on WAN2. Traffic is NATed on the Internet link and not NATed over MPLS link. |
MPLS-only branches
|
|
Problem: Only MPLS at branch with Internet access at Data Center. Clients needs to access MPLS network with original source IP. Solution: This problem can be solved with NAT Exceptions enabled on the WAN interface. Traffic will not be NATed on the WAN. The MX security appliance needs to be online via MPLS for cloud management. |
Publicly routable LAN subnets and DMZs
|
|
Problem: Ability to configure publicly routable DMZ subnet. Solution: With NAT Exceptions enabled on the DMZ VLAN, public routable subnets can be used in the DMZ. Public routable subnet is not NATed, MPLS is not NATed while traffic over Internet link is NATed. |
Caution
As this feature is still in early development, please read this section carefully before having this feature enabled.
Inbound Firewall
When NAT Exceptions is enabled, the inbound firewall on the MX security appliance will be enabled as well. The inbound firewall will be used to police traffic sourced from outside the network e.g. Inbound connections for NATs, port forwards or subnets on the WAN side trying to access subnets on the LAN. You will risk unauthorized access to your network if you do not configure the Inbound firewall correctly.
The MX Firewall will remain stateful for traffic initiated from inside the network (behind the MX). Only traffic initiated from outside the network (on the WAN side) will be affected by the inbound firewall.
What you need to do:
Apply a Deny Any Any rule on the inbound Firewall. This can be done by navigating to the Security & SD-WAN > Configure > Firewall to block external access to Firewall and internal networks. Permit inbound connections as needed. Please note that a Deny Any Any rule will not take the Security Appliance offline or affect cloud management traffic.
1:1/ 1:Many NATs, Port forwards, Firewall Services
The inbound firewall overrides the “allowed inbound connections” field for NATs, port forwards, and firewall host services, etc.
What you need to do:
Use inbound firewall to accommodate allowed inbound connections for NATs, port forwards and firewall services on the inbound firewall on the Security & SD-WAN > Configure > Firewall page.
Prerequisites
I. This feature requires MX 15.4 firmware or higher
Ii. This feature can only be enabled by Meraki Support. Please contact Meraki Support to have this feature enabled.
Configuration
To configure NAT Exceptions, once enabled, navigate to dashboard > Security & SD-WAN > Configure > Addressing and VLANs.
Below are configuration examples and expected behavior.
Configuration Example I - NAT disabled on Uplink 1
Override NAT per VLAN option is only available when VLANs are enabled and NAT Exceptions is disabled on either Uplink. As seen in the image above and below.
Expected behavior
All traffic flowing out the MX through uplink 1/WAN 1 will not be NATed (LAN sourced traffic will maintain source IP address). While all traffic flowing out via uplink 2/WAN2 will be NATed.
Configuration Example II - NAT disabled on Uplink 1 and Uplink 2, with VLAN 100 set to override NAT Exceptions
Expected behavior
Traffic from VLAN 100 will be NATed on both uplinks, Traffic from VLAN 200 will not be NATed on both uplinks.
Troubleshooting
The easiest way to verify NAT Exceptions is working will be to: generate traffic from the LAN of the security appliance and use the packet capture tool available on dashboard to sniff traffic on the uplink that has NAT Exceptions enabled. Observe source IP of the traffic flowing through the uplink. If traffic is still being NATed, verify your configuration and ensure the security appliance's configuration is up to date.
Duplicate subnets
Please ensure you do not have duplicate subnets on the LAN and WAN. This usually occurs when the MX is sitting behind a NAT device, ISP modem, etc. This can cause NAT Exceptions to not function as expected.
Unidirectional traffic flow outbound:
If you have unidirectional traffic flow,
i. Ensure you have a return route pointing to the right next hop (MX uplink IP, Virtual IP if you have one configured).
ii. Ensure that you are permitting the right subnets on your inbound firewall
iii. Take simultaneous packet captures on the LAN and WAN of the MX security appliance and identify where the traffic is being dropped
Unidirectional traffic flow inbound:
i. Ensure you are permitting the right traffic on the outbound firewall (security appliance > configure > firewall)
ii. Ensure the device on the LAN is reachable (ping, check ARP with live tools on dashboard, ensure device is on the right VLAN)
iii. Take simultaneous packet captures on the LAN and WAN of the MX security appliance and identify where the traffic is being dropped