Palo Alto Source NAT Configuration with a Real-Life Internet Access Example

In enterprise firewall deployments, internal networks almost always use private RFC 1918 IPv4 addresses. Because public internet routers discard non-routable private addresses, outward-bound traffic requires source network address translation. Understanding Palo Alto Source NAT configuration is an essential skill for security engineers implementing outbound internet connectivity.

This tutorial provides a step-by-step guide to configuring, verifying, and troubleshooting Source NAT on a Palo Alto Networks firewall. You will learn how to configure Dynamic IP and Port (DIPP) translation to map an entire internal subnet to a single public IP address assigned to the firewall interface.

Real-Life Scenario

Acme Corp needs to provide outbound internet access for employee workstations located on an internal subnet. The company has a single static public IPv4 address assigned by its Internet Service Provider (ISP) to the external firewall interface.

The technical requirements are as follows:

• Translate internal clients on 192.168.10.0/24 to the firewall external public IP address when accessing the internet.
• Allow multiple internal hosts to share the single external public IP address simultaneously using port multiplexing.
• Ensure security policy rules correctly evaluate traffic matching the NAT policy.
• Log outbound sessions for auditing and troubleshooting purposes.

Lab Topology

The topology below illustrates the physical and logical flow of traffic from the internal client workstation, through the firewall, to the external ISP gateway and internet destination.

+------------------------------------+
| Internal Client (LAB/EXAMPLE)      |
| IP: 192.168.10.50/24               |
| Gateway: 192.168.10.1              |
+-----------------+------------------+
                  |
                  | Trust Zone
                  v
+-----------------+------------------+
| Palo Alto Networks Firewall        |
| Interface: ethernet1/2 (Trust)     |
|   IP: 192.168.10.1/24              |
|                                    |
| Interface: ethernet1/1 (Untrust)   |
|   IP: 203.0.113.2/24 (Public)      |
+-----------------+------------------+
                  |
                  | Untrust Zone
                  v
+-----------------+------------------+
| ISP Gateway Router                 |
| IP: 203.0.113.1/24                 |
+-----------------+------------------+
                  |
                  v
       Internet Destination
       IP: 198.51.100.20

Example Addressing and Objects

All network addresses, zone names, and object names used in this guide are laboratory examples. You must adapt these values to match your specific production deployment.

Prerequisites

Before configuring Source NAT, ensure the following foundational settings are operational on your firewall:

1. Layer 3 interfaces (ethernet1/1 and ethernet1/2) are configured with correct IP addresses and assigned to their respective zones (Untrust and Trust).
2. A Virtual Router is assigned to both interfaces.
3. A static default route (0.0.0.0/0) exists in the Virtual Router pointing to the ISP gateway IP (203.0.113.1).
4. An Address Object representing the internal subnet (192.168.10.0/24) is created.

Step-by-Step GUI Configuration

Follow these steps to complete the Palo Alto Source NAT configuration using the web interface.

Step 1: Create the Source Network Address Translation Rule

1. Log into the PAN-OS web interface.
2. Navigate to Policies > NAT.
3. Click Add at the bottom of the screen to create a new NAT rule.

Step 2: Configure the General Tab

1. In the Name field, enter a clear naming convention, such as snat-outbound-trust-to-untrust.
2. (Optional) Enter a brief description explaining the business purpose of the rule.
3. Set NAT Type to ipv4.

Step 3: Configure the Original Packet Tab

The Original Packet tab specifies the criteria for matching incoming traffic before any translation occurs.

1. Click the Original Packet tab.
2. Under Source Zone, click Add and select Trust.
3. Under Destination Zone, click Add and select Untrust.
4. Under Destination Interface, select ethernet1/1 (or leave as Any).
5. Under Service, keep the default setting of any.
6. Under Source Address, click Add and select net-192.168.10.0_24.
7. Under Destination Address, keep the default setting of any.

Step 4: Configure the Translated Packet Tab

The Translated Packet tab defines how the source or destination address is altered when the rule matches.

1. Click the Translated Packet tab.
2. In the Source Address Translation section, set Translation Type to Dynamic IP and Port.
3. Set Address Type to Interface Address.
4. In the Interface drop-down menu, select ethernet1/1.
5. In the IP Address drop-down menu, select 203.0.113.2/24.
6. Leave Destination Address Translation set to None.
7. Click OK to save the NAT rule rule configuration.

Step 5: Verify or Create Security Policy Rule

NAT policies only permit address translation; they do not allow traffic through the firewall. You must have a Security Policy rule allowing traffic from the Trust zone to the Untrust zone.

1. Navigate to Policies > Security.
2. Ensure a rule exists allowing traffic from Source Zone Trust to Destination Zone Untrust.
3. Confirm the Security Policy uses the pre-NAT (original) source IP address object (net-192.168.10.0_24) and destination IP address (any).

Step 6: Commit Configuration

1. Click Commit in the top right corner of the GUI.
2. Review the change summary and click Commit again.

CLI Configuration

For engineers who prefer the Command Line Interface (CLI), perform the following configuration steps from configuration mode. These exact PAN-OS CLI commands build the address object, NAT rule, and security policy.

# Enter configuration mode
configure

# Create the address object for the internal LAN segment
set address net-192.168.10.0_24 ip-netmask 192.168.10.0/24

# Create the Source NAT rule using Dynamic IP and Port (DIPP)
set rulebase nat rules snat-outbound-trust-to-untrust from Trust to Untrust source net-192.168.10.0_24 destination any service any dynamic-ip-and-port interface-address interface ethernet1/1 ip 203.0.113.2/24

# Create the Security Policy rule allowing outbound internet access
set rulebase security rules allow-outbound-internet from Trust to Untrust source net-192.168.10.0_24 destination any application any service application-default action allow

# Commit the changes to the active configuration
commit

How the Traffic Flows

Understanding PAN-OS packet processing flow is vital for proper policy design and operational troubleshooting. Palo Alto Networks firewalls evaluate security and NAT rules using specific logic.

1. Ingress Lookup and Route Lookup: An un-translated packet arrives on interface ethernet1/2 (Trust zone) with Source IP 192.168.10.50 and Destination IP 198.51.100.20. The firewall queries the Virtual Router routing table to determine the egress interface (ethernet1/1) and egress zone (Untrust).
2. NAT Policy Match: PAN-OS evaluates NAT rules top-to-bottom. It compares the packet’s original attributes against configured NAT rules. The match criteria are:
   • Source Zone: Trust
   • Destination Zone: Untrust (determined by the routing lookup in Step 1)
   • Original Source Address: 192.168.10.50 (matches object net-192.168.10.0_24)
   • Original Destination Address: 198.51.100.20
3. Security Policy Match: Firewall security policy lookup occurs. Crucially, the firewall evaluates security policies using:
   • Original (Pre-NAT) Source IP: 192.168.10.50
   • Original (Pre-NAT) Destination IP: 198.51.100.20
   • Post-Routing Destination Zone: Untrust
4. Translation Execution: Once the security rule allows the session, the firewall allocates a source translation binding. It rewrites the source IPv4 address from 192.168.10.50 to 203.0.113.2 and assigns a unique source port.
5. Egress Transmission: The firewall sends the modified packet out interface ethernet1/1 across the internet.
6. Return Traffic Processing: When the external host responds to 203.0.113.2, the firewall matches the incoming response against its active state table. It translates the destination address back to 192.168.10.50 and routes the frame back to the client host.

Verification

To verify that the Palo Alto Source NAT configuration is functioning correctly, perform active connectivity tests and inspect active session state entries.

1. Client-Side Test

From an internal workstation (192.168.10.50), initiate a web request or ping test to an internet server:

# Ping external test IP address
ping 198.51.100.20

2. Verify Session via CLI

Log into the firewall CLI and filter the active session table by internal source IP address:

show session all filter source 192.168.10.50

Example CLI Output:

ID       Application    State   Type Flag  Src[Sport]/Zone/Proto (Dst[Dport])
-------------------------------------------------------------------------------
12345    icmp           ACTIVE  FLOW       192.168.10.50[4096]/Trust/1 (198.51.100.20[0])
                                           198.51.100.20[0]/Untrust/1 (203.0.113.2[4096])

Inspect detailed session information using the session ID:

show session id 12345

Example Output highlighting Source NAT translation:

Session           : 12345
C2S flow:
        source          : 192.168.10.50 [Trust]
        dst             : 198.51.100.20
        proto           : 1
        sport           : 4096          dport           : 0
        state           : ACTIVE        type            : FLOW
        src user        : unknown
        proxy-id        : 0
S2C flow:
        source          : 198.51.100.20 [Untrust]
        dst             : 203.0.113.2
        proto           : 1
        sport           : 0             dport           : 4096
        state           : ACTIVE        type            : FLOW
        src user        : unknown
        proxy-id        : 0
NAT rule                : snat-outbound-trust-to-untrust(vsys1)
Source NAT              : dynamic-ip-and-port, ip address: 203.0.113.2

The output above confirms that Client-to-Server (C2S) traffic originates from 192.168.10.50, while Server-to-Client (S2C) return traffic is directed back to the translated address 203.0.113.2.

3. Verify Traffic Logs in GUI

1. In the firewall web interface, navigate to Monitor > Logs > Traffic.
2. Apply the query filter: ( src in 192.168.10.50 )
3. Verify the column NAT Source IP displays 203.0.113.2 while Source IP shows 192.168.10.50.

Troubleshooting

If outbound internet connectivity fails after completing the setup, work through these common symptoms and technical checks.

Symptom 1: Traffic is Dropped by Security Policy

• Likely Cause: A common misconception is configuring the post-NAT address in the Security Policy. Security policy matching uses pre-NAT IP addresses.
• Verification Check: Check the traffic logs under Monitor > Logs > Traffic. Look for log entries showing action drop or deny. Verify your security rule allows source 192.168.10.0/24, destination any, and destination zone Untrust.

Symptom 2: Traffic Matches Wrong NAT Rule

• Likely Cause: PAN-OS evaluates NAT policies in sequential order from top to bottom. A broader rule positioned higher in the list may match first.
• Verification Check: Check the rule order under Policies > NAT. Ensure specific NAT rules are placed above general overrides. Verify runtime rule execution with:

  test nat-policy-match source 192.168.10.50 destination 198.51.100.20 protocol 6 destination-port 80 dynamic-url no

Symptom 3: NAT Rule Fails to Match Due to Incorrect Destination Zone

• Likely Cause: The Destination Zone in a NAT rule must match the zone associated with the route egress interface for the original, un-translated destination IP address.
• Verification Check: Confirm routing to the destination IP points out interface ethernet1/1 (Untrust zone). Test route lookup:

  test routing fib-lookup ip 198.51.100.20 virtual-router default

Common Mistakes

• Configuring Post-NAT IP Addresses in Security Policy: Always use the original pre-NAT source address (192.168.10.0/24) in the security policy rule. PAN-OS matches security policies before performing source IP rewrite.
• Selecting the Wrong Destination Zone in NAT Rules: The destination zone in a NAT rule represents the destination zone of the egress interface determined by routing before translation occurs.
• Missing Reverse Route on Next-Hop Router: Ensure the ISP router or upstream gateway knows how to route traffic back to your public IP subnet range.
• Confusing Dynamic IP with Dynamic IP and Port: Selecting “Dynamic IP” (1-to-1 dynamic mapping without port translation) instead of “Dynamic IP and Port” (DIPP) will cause source pool exhaustion if you have more active clients than public addresses.

Production Considerations

When implementing outbound Source NAT in enterprise environments, account for these operational factors:

• DIPP Oversubscription Limits: A single IPv4 address supporting Dynamic IP and Port translation can handle approximately 64,000 concurrent source sessions per destination protocol/port. For high-density enterprise environments with thousands of users, use a public IP pool (e.g., a /28 subnet) in your NAT rule instead of a single interface address.
• High Availability Session Synchronization: In Active/Passive firewall clusters, session state and active NAT bindings sync automatically across HA links. Ensure NAT rules reference zone names rather than static physical interfaces when configuring multi-path HA environments.
• Logging at Session End: Ensure Log at Session End is enabled in your security rules to generate accurate session records showing translated IP addresses and port numbers for regulatory auditing and security incident investigations.

Summary

Configuring Source NAT on Palo Alto Networks firewalls translates private internal address spaces to routable public IP addresses for internet access. Key takeaways include:

• Use Dynamic IP and Port (DIPP) translation to map multiple internal client IPs to a single public interface address.
• PAN-OS evaluates Security Policies using **pre-NAT source and destination IP addresses**, but uses the **post-routing destination zone**.
• Always verify NAT functionality by combining CLI session checks (show session all filter...) with GUI traffic log analysis.