In this topic, I will talk about the NAT process and how to troubleshoot it if it is not working on ASA.
When you troubleshoot NAT configurations, it is important to understand how the NAT configuration on the ASA is used to build the NAT policy table
Below is the most common problem faced while working in NAT rules :
- The NAT configuration rules are out of order. For example, a manual NAT rule is placed at the top of the NAT table, which causes more specific rules placed farther down the NAT table to never be hit.
- The network objects used in the NAT configuration are too broad, which causes traffic to inadvertently match these NAT rules, and miss more specific NAT rules.
How the ASA Configuration is Used to Build the NAT Policy Table
All packets processed by the ASA are evaluated against the NAT table.
The three sections of the ASA NAT table are:
| Section 1 | Manual NAT policies These are processed in the order in which they appear in the configuration. |
| Section 2 | Auto NAT policies These are processed based on the NAT type (static or dynamic) and the prefix (subnet mask) length in the object. |
| Section 3 | After-auto manual NAT policies These are processed in the order in which they appear in the configuration. |
This example shows how the ASA’s NAT configuration with two rules (one Manual NAT statement and one Auto NAT configuration) are represented in the NAT table:
How to Troubleshoot NAT Problems
- Use the Packet Tracer Utility
- View the Output of the Show Nat Command
Use the Packet Tracer Utility
In the example below, a sample TCP packet that enters the inside interface and is destined to a host on the Internet is given. The packet tracer utility shows that the packet matches a dynamic NAT rule and is translated to the outside IP address of 172.16.123.4:
ASA# packet-tracer input inside tcp 10.10.10.123 12345 209.165.200.123 80
…(output omitted)…
Phase: 2
Type: NAT
Subtype:
Result: ALLOW
Config:
object network 10.10.10.0-net
nat (inside,outside) dynamic interface
Additional Information:
Dynamic translate 10.10.10.123/12345 to 172.16.123.4/12345
…(output omitted)…
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
Packet Tracer -ASDM
Choose the NAT rule and click Packet Trace in order to activate the packet tracer from the Cisco Adaptive Security Device Manager (ASDM). This uses the IP addresses specified in the NAT rule as the inputs for the packet tracer tool:
View the Output of the Show Nat Command
The output of the show nat detail command can be used in order to view the NAT policy table. Specifically, the translate_hits and untranslate_hits counters can be used in order to determine which NAT entries are used on the ASA.
NAT Problem Troubleshooting
Use packet tracer in order to confirm that a sample packet matches the proper NAT configuration rule on the ASA. Use the show nat detail command in order to understand which NAT policy rules are hit. If a connection matches a different NAT configuration than expected, troubleshoot with these questions:
- Is there a different NAT rule that takes precedence over the NAT rule you intended the traffic to hit?
- Is there a different NAT rule with object definitions that are too broad (the subnet mask is too short, such as 255.0.0.0) which causes this traffic to match the wrong rule?
- Are the manual NAT policies out-of-order, which causes the packet to match the wrong rule?
- Is your NAT rule incorrectly configured, which causes the rule to not match your traffic?
Common Problems with NAT Configurations
Problem 1: Traffic fails due to NAT Reverse Path Failure (RPF) Error: Asymmetric NAT rules matched for forward and reverse flows
The NAT RPF check ensures that a connection that is translated by the ASA in the forward direction, such as the TCP synchronize (SYN), is translated by the same NAT rule in the reverse direction, such as the TCP SYN/acknowledge (ACK).
Problem 2: Manual NAT Rules are out-of-order, which causes incorrect packet matches
The manual NAT rules are processed based on their appearance in the configuration. If a very broad NAT rule is listed first in the configuration, it might override another, more specific rule farther down in the NAT table. Use packet tracer in order to verify which NAT rule your traffic hits; it might be necessary to rearrange the manual NAT entries to a different order.
Problem 3: A NAT rule is too broad and matches some traffic inadvertently.
NAT rules are created that use objects that are too broad. If these rules are placed near the top of the NAT table (at the top of Section 1, for example), they might match more traffic than intended and cause NAT rules farther down the table to never be hit.
Problem 4: A NAT rule diverts traffic to an incorrect interface
NAT rules can take precedence over the routing table when they determine which interface a packet will egress the ASA. If an inbound packet matches a translated IP address in a NAT statement, the NAT rule is used in order to determine the egress interface.
Problem 5: A NAT rule causes the ASA to Proxy Address Resolution Protocol (ARP) for traffic on the mapped interface
The ASA Proxy ARPs for the global IP address range in a NAT statement on the global interface. This Proxy ARP functionality can be disabled on a per-NAT rule basis if you add the no-proxy-arp keyword to the NAT statement.
This problem is also seen when the global address subnet is inadvertently created to be much larger than it was intended to be.