Introduction to NAT on Palo Alto Networks Firewalls

Network Address Translation (NAT) is a fundamental technique used in networking to modify IP address information in packet headers while they are in transit across a traffic routing device. Palo Alto Networks Next-Generation Firewalls (NGFWs) provide robust and flexible NAT capabilities, essential for scenarios like allowing internal users to access the internet (Source NAT), or permitting external users to access internal servers (Destination NAT).

Understanding NAT on a Palo Alto Networks firewall is crucial for network administrators and is a key topic covered in certifications like PCNSE (Palo Alto Networks Certified Network Security Engineer) and PCNSA (Palo Alto Networks Certified Network Security Administrator). Correct NAT configuration ensures proper traffic flow and is often a prerequisite for successful security policy enforcement.

Key NAT Concepts on Palo Alto Networks Firewalls

• NAT Rules: Configured policies that define criteria for matching traffic and the translation action to be applied. NAT rules are evaluated from top to bottom, similar to Security Policies.
• Source NAT (SNAT): Changes the source IP address of a packet. Commonly used to translate private internal IP addresses to a public IP address for internet access.
• Destination NAT (DNAT): Changes the destination IP address of a packet. Commonly used to translate a public IP address to a private internal server IP address.
• Bidirectional NAT: A single rule that performs both Source and Destination NAT. Often used for servers that initiate connections both internally and externally, or for U-turn NAT scenarios.
• NAT Types: Palo Alto Networks supports various NAT types including Dynamic IP, Dynamic IP and Port (DIPP/PAT), Static IP, and Static IP and Port.

Packet Flow and NAT

NAT happens early in the packet processing path. For the first packet of a new session:

1. Packet arrives on ingress interface.
2. Zone/Interface check.
3. Route lookup (using the packet's original destination IP).
4. NAT Rule Lookup (comparing original packet attributes against NAT rules). If a match is found, the NAT translation is determined.
5. Session is created. The session table stores both original and translated IP/port information.
6. NAT translation is applied (if required).
7. Policy lookup (using translated IP/port and potentially original source/destination zone depending on rule type and PAN-OS version).
8. Security Processing (App-ID, Content-ID, Threat Prevention, etc.).
9. Packet sent out egress interface.

This order is critical for troubleshooting. If NAT isn't happening as expected, it's often because the NAT rule wasn't matched *before* the session was created or the security policy was evaluated incorrectly due to incorrect NAT.

Simplified Packet Flow highlighting NAT rule lookup.

Checking NAT Hit Counters

Hit counters are invaluable for verifying if your NAT rules are being matched by traffic. A non-zero hit counter indicates that traffic corresponding to the rule's criteria has passed through the firewall and triggered that specific NAT rule. If a NAT rule isn't getting hits when you expect it to, it suggests a misconfiguration in the rule criteria (Source Zone, Destination Zone, Source Address, Destination Address, Service, etc.) or that traffic is being blocked by a security policy or routing issue before it hits the NAT evaluation point.

GUI Method

In the Palo Alto Networks GUI:

1. Navigate to Policies > NAT .
2. Locate the specific NAT rule you want to check.
3. Look at the Hits column for that rule.

You can sort the rules by the 'Hits' column to quickly see which rules are most active or identify rules with zero hits.

To reset NAT rule hit counters (useful after making changes to see fresh counts):

• Per Rule: In the GUI, right-click the rule and select Reset Hit Counter .
• Global: In the GUI, at the top right of the NAT rules list, click Reset All Hit Counters .

CLI Method

The primary command to view NAT rule hit counters in the CLI is:

This command displays a list of all configured NAT rules, including their rule index, name, and hit count. Example output snippet:

To reset NAT rule hit counters via CLI:

• Per Rule:
> clear nat rule hit-count rule-name <rule-name>
• Global:
> clear nat rule hit-count all

Interpreting Hit Counters

If your NAT rule is configured correctly based on the traffic you expect, but the hit counter is zero, consider the following:

• Is traffic actually reaching the firewall's ingress interface?
• Is the traffic hitting the firewall but being dropped by a Security Policy rule *before* NAT evaluation? (No, this is incorrect based on packet flow). NAT is evaluated *before* the security policy rule *match*. However, if the security policy lookup fails (e.g., due to incorrect zones after NAT), the session won't be permitted.
• Is the traffic hitting the firewall but being dropped by an implicitly denied NAT rule? (No, implicit NAT rules don't drop, they just don't NAT).
• Is there a routing issue? NAT uses the original destination IP for route lookup *before* applying DNAT. If the firewall can't route to the *original* destination, the packet may be dropped early.
• Are the criteria (Source Zone, Destination Zone, Source Address, Destination Address, Service) in the NAT rule an exact match for the traffic? Remember that the rule match uses the *original* packet information for Source/Destination Zone/Address/Service, and the *post-NAT* destination zone/address for policy lookup (primarily the destination zone after DNAT, if applicable).
• Are there other NAT rules above this one that are matching the traffic instead? NAT rule evaluation is top-down, first match wins.

NAT Troubleshooting Commands

Beyond checking hit counters, several CLI commands are essential for troubleshooting NAT issues on Palo Alto Networks firewalls. These commands help you understand how the firewall sees the traffic and how it's evaluating rules.

show session all

This is arguably the most important command for understanding active traffic and NAT. It shows details about current sessions, including original and translated IP/port information.

Replace placeholders with the actual IP addresses, port, and protocol of the traffic you are troubleshooting. Example output snippet:

Look for the `nat-rule` field to see which NAT rule the session matched. Examine the `source nat address`/`port` and `destination nat address`/`port` fields to see if the expected translation occurred.

test nat-policy-match

This command allows you to simulate traffic against your NAT rules to see which rule would be matched *before* the actual traffic arrives. This is extremely useful for verifying your NAT rule configuration without sending live traffic.

Example:

Output will show the first NAT rule that matches the simulated traffic attributes.

If this command shows 'No matching rule', then your NAT rule criteria are incorrect for the traffic flow you are testing.

show running nat-policy

Displays the currently active NAT policy configuration on the firewall, similar to viewing it in the GUI.

This is useful for quickly reviewing all NAT rules and their configurations via CLI.

show system state filter-xpath "nat"

Provides detailed NAT-related state information from the system. This is more advanced and might reveal internal NAT tables or counters not exposed in other commands.

Use this command with caution as the output can be extensive and may require Palo Alto Networks support guidance for full interpretation.

U-Turn NAT (Hairpinning)

Troubleshooting U-Turn NAT, where an internal host accesses another internal host using the destination host's public IP address, often involves ensuring both Source and Destination NAT occur. The traffic leaves and returns on the *same* firewall interface/zone (e.g., Untrust). Your NAT rule needs to match this specific flow (Source Zone = Untrust, Destination Zone = Untrust, Source Address = Internal Host's Translated SNAT address, Destination Address = Server's Public DNAT address) and apply DNAT *and* SNAT.

Simplified U-Turn NAT flow. Note traffic enters and exits the firewall on the same zone (Untrust in this example).

Debugging NAT with Packet Flow

When basic troubleshooting commands aren't sufficient, using packet flow debugging is necessary. This allows you to see how the firewall processes a specific packet step-by-step, including NAT evaluation and application.

The primary tool for this is the `debug flow` command.

Packet Flow Stages Relevant to NAT Debugging

The packet flow debugging output goes through many stages. Key stages for NAT are:

• flow_ipv4_decap / flow_ipv6_decap : Packet arrives.
• flow_lookup_policy_nat : This is where the NAT rule lookup occurs. You'll see checks against your NAT rules.
• flow_setup_session : Session is created. Original and translated addresses/ports are logged here.
• flow_apply_nat : The NAT translation is applied to the packet header.
• flow_lookup_policy_security : Security policy lookup occurs using the *translated* information.
• flow_fwd_final : Packet is forwarded out.

Steps for Debugging NAT

1. Set Debug Filters: Define filters to target only the specific traffic flow you are interested in. This is crucial!
> debug flow basic filter on > debug flow basic filter match source <src-ip> destination <dest-ip> protocol <protocol-number> destination-port <port>

Use IP addresses and the protocol number (e.g., 6 for TCP, 17 for UDP, 1 for ICMP). You can add source-port if needed but destination-port is often sufficient for initial NAT checks.

Gotcha! Protocol needs to be the number, not the name (e.g., 6 for TCP, not 'tcp'). Use show protocol if unsure.
2. Enable Debugging: Turn on basic flow debugging.
> debug flow basic on
3. Generate Traffic: Initiate the traffic flow from the source host.
4. View Debug Output: The output will be sent to the system logs (visible via less mp-log flow.log or `tail mp-log flow.log`) or directly to your console if you are using a session management tool. Look for the stages mentioned above.
> less mp-log flow.log
5. Disable Debugging: Immediately disable debugging filters and logging when you have captured the necessary traffic.
> debug flow basic filter off > debug flow basic off > clear log mp-log flow.log (Optional, to clear logs)

Interpreting Debug Flow Output for NAT

Look for lines containing `flow_lookup_policy_nat`. This will show which NAT rule is being considered and if a match is made.

Then look for `flow_setup_session` to see the determined translation:

If `flow_lookup_policy_nat` indicates 'no matching rule', review your NAT rule configuration and test it using `test nat-policy-match` first.

Sequence Diagram of Packet Flow including NAT on Palo Alto Networks Firewall.

Debug NAT States

While not a direct `debug flow` stage, understanding the states a NAT entry goes through can be helpful. A NAT entry in the session table has a state. It starts when a NAT rule is matched and a session created, is active during the session lifetime, and is eventually removed.

Simplified State Diagram for a NAT Session Entry.

NAT Troubleshooting Quiz

Test your knowledge of NAT on Palo Alto Networks firewalls with these questions, focusing on troubleshooting and PCNSE key points.