Skip to main content
Cisco Meraki Documentation

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 WAN appliance. The NAT Exceptions feature allows for WAN 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 WAN 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+ 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.

MX will not respond to incoming ISAKMP requests sent by its Peer when No-NAT is enabled. The tunnel can be established if it is initiated from the MX side.

We recommend using the WAN appliance in passthrough mode or terminate MPLS connections on the LAN side of the WAN 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

Screen Shot 2019-10-08 at 4.18.17 PM.png

 

 

 

 

 

 

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 WAN 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 WAN 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 WAN appliance Firewall will remain stateful for traffic initiated from inside the network (behind the WAN appliance). 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 Security & SD-WAN > Configure > Addressing & VLANs.

Below are configuration examples and expected behavior.


Configuration Example I - NAT disabled on Uplink 1
Screen Shot 2019-10-08 at 4.38.47 PM.png

 

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 WAN appliance through uplink 1/WAN 1 will not be NATed (LAN sourced traffic will maintain the 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 WAN appliance 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 (WAN appliance 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 & SD-WAN > 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 WAN appliance and identify where the traffic is being dropped