Chapter 6: Network Address Translation (NAT)

Introduction to Network Address Translation (NAT)

Welcome to Chapter 6! So far, we’ve built a solid foundation, understanding the core architecture of Palo Alto Networks firewalls and how to craft powerful security policies. But what happens when the IP addresses on your internal network aren’t meant to be seen by the outside world? Or when you need external users to reach an internal server without knowing its private IP? That’s where Network Address Translation, or NAT, steps in.

NAT is a fundamental networking concept, especially crucial for firewalls. It allows a network device, like our Palo Alto firewall, to modify the source or destination IP addresses (and sometimes ports) of packets as they traverse the device. This capability is vital for both security and efficient use of IPv4 addresses.

In this chapter, we’ll demystify NAT, breaking down its types and how to configure them on your Palo Alto Networks firewall. We’ll build on our understanding of zones and security policies to see how NAT seamlessly integrates into the traffic flow. By the end, you’ll be able to confidently configure common NAT scenarios, enabling your internal users to access the internet and external users to securely reach your internal services.

Core Concepts of NAT

Let’s start by understanding what NAT is and why it’s so important in modern networks.

What is Network Address Translation (NAT)?

Imagine you’re at a large office building, and everyone inside has an internal phone extension. When someone inside calls an external number, the call goes through a central switchboard, which presents a single, public phone number to the outside world. When an external call comes in for a specific person, the switchboard operator knows which internal extension to connect it to.

In networking terms, NAT plays the role of that switchboard. It modifies the IP address information in the packet headers while the packets are in transit across a routing device, like our firewall.

Why Do We Need NAT?

NAT serves two primary purposes:

1. IPv4 Address Conservation: With the limited supply of public IPv4 addresses, NAT allows multiple devices on a private network to share a single public IP address when accessing the internet. This is the most common use case.
2. Security by Obscurity (to an extent): By hiding the internal network’s private IP addresses from the outside world, NAT adds a layer of protection. External attackers cannot directly target internal hosts because their private IPs are not publicly routable.

Types of NAT on Palo Alto Networks Firewalls

Palo Alto Networks firewalls support several types of NAT, each designed for specific scenarios. We’ll focus on the two most common: Source NAT and Destination NAT.

1. Source NAT (SNAT)

Source NAT changes the source IP address of a packet as it leaves the firewall. This is primarily used when internal devices (with private IP addresses) need to initiate connections to external networks (like the internet). The firewall translates the private source IP to a public IP address.

Common SNAT Scenarios:

• Dynamic IP and Port (Overload/PAT): This is the most common type. Multiple internal private IP addresses are translated to a single public IP address, differentiating connections by using different source port numbers. It’s like many people in an office sharing one public phone line, but the switchboard (firewall) keeps track of who initiated which call.
• Dynamic IP: Multiple internal private IP addresses are translated to a pool of public IP addresses. Each connection gets a unique public IP (and port).
• Static IP: A single internal private IP address is always translated to a specific public IP address. This is less common for SNAT but can be useful for specific services that always need to appear from the same public IP.

When to Use SNAT: When your internal network needs to reach the internet.

2. Destination NAT (DNAT)

Destination NAT changes the destination IP address of a packet as it enters the firewall. This is used when external devices need to initiate connections to internal servers (with private IP addresses). The firewall translates a public destination IP (often an external IP on the firewall itself) to a private internal IP.

Common DNAT Scenarios:

• Static NAT (Port Forwarding): A public IP address (and optionally a public port) is mapped to a specific internal private IP address (and internal port). This is essential for hosting services like web servers, mail servers, or VPN gateways that need to be accessible from the internet.

When to Use DNAT: When external networks need to reach services hosted on your internal network.

How NAT and Security Policies Interact

This is crucial: NAT rules are processed before security policy rules for incoming traffic, and after security policy rules for outgoing traffic.

• Incoming Traffic (e.g., from Internet to an internal server):
  1. Packet arrives at firewall.
  2. DNAT is applied (public destination IP translated to private destination IP).
  3. Security policy is evaluated based on the translated destination IP.
• Outgoing Traffic (e.g., from internal user to Internet):
  1. Packet arrives at firewall.
  2. Security policy is evaluated based on the original source IP.
  3. SNAT is applied (private source IP translated to public source IP).

Understanding this order is vital for correctly configuring both NAT and security policies. Security policies should always refer to the IP addresses after DNAT and before SNAT.

Visualizing NAT Flow

Let’s use a simple diagram to illustrate these concepts.

In this diagram, you can see how an internal PC’s private IP is translated to a public IP for internet access (SNAT), and how an external user’s request to a public IP is translated to an internal web server’s private IP (DNAT).

Step-by-Step Implementation: Configuring NAT on PAN-OS 11.1

Now, let’s get hands-on! We’ll configure both Source NAT and Destination NAT rules using the Palo Alto Networks firewall GUI (web interface). We’ll assume you’re running PAN-OS 11.1, the latest stable release as of December 2025. While specific UI elements might slightly shift in future versions, the core concepts and navigation paths remain largely consistent.

Scenario 1: Internal Users Accessing the Internet (Source NAT)

This is the most common NAT configuration. We want all devices in our internal Trust zone (e.g., 192.168.1.0/24) to be able to access the internet via the firewall’s public IP address on its Untrust interface.

1. Log in to the Web Interface: Open your web browser and navigate to the management IP address of your Palo Alto Networks firewall.

2. Navigate to NAT Policies:

   • In the left-hand navigation pane, click on Policies.
   • Then, select NAT from the submenu.

3. Add a New NAT Rule:

   • Click the Add button at the bottom of the NAT Policy Rule list.

4. Configure the General Tab:

   • Name: SNAT-Trust-to-Untrust (Descriptive name for the rule)
   • Description: Allows internal users to access the Internet using dynamic IP and Port.
   • NAT Type: Select IPv4
   • Enable: Ensure this checkbox is selected.

5. Configure the Original Packet Tab (What the firewall sees before NAT):

   • Source Zone: Select Trust (This is where your internal users are).
   • Destination Zone: Select Untrust (This is the zone connected to the Internet).
   • Destination Interface: Select the specific interface that connects to your ISP (e.g., ethernet1/1 if that’s your untrust interface). Why specify? It helps the firewall make more efficient routing decisions.
   • Service: any (We want to allow all services to the internet for now).
   • Source Address: Select any or a specific address object representing your internal network (e.g., 192.168.1.0/24). For simplicity, let’s use any if you haven’t defined a specific network object yet. Best practice: Use specific network objects for better control and readability.
   • Destination Address: any (Users can go anywhere on the internet).

6. Configure the Translated Packet Tab (What the firewall sends after NAT):

   • Translation Type: Select Dynamic IP and Port (This is PAT/Overload).
   • Address Type: Select Interface Address.
   • Interface: Choose your Untrust interface (e.g., ethernet1/1).
   • IP Address: Select ip (This tells the firewall to use the primary IP address configured on that interface).

   What does this mean? When a packet from the Trust zone destined for the Untrust zone leaves the firewall via ethernet1/1, its source IP address will be changed to the IP address of ethernet1/1, and its source port will be dynamically assigned.

7. Click OK.

8. Commit Your Changes:

   • In the upper right corner, click Commit.
   • Review the changes and click Commit again. This applies the configuration to the firewall.

Remember: After configuring the SNAT rule, you’ll also need a security policy rule that allows traffic from the Trust zone to the Untrust zone. This security policy should use the original (pre-NAT) source IP address.

Scenario 2: External Users Accessing an Internal Web Server (Destination NAT)

Now, let’s say you have a web server in your DMZ zone with a private IP address (e.g., 10.0.0.50), and you want external users to access it via a public IP address (e.g., 203.0.113.10).

1. Add a New NAT Rule:

   • Go back to Policies > NAT.
   • Click the Add button.

2. Configure the General Tab:

   • Name: DNAT-Webserver
   • Description: Allows external users to access the internal web server.
   • NAT Type: IPv4
   • Enable: Selected.

3. Configure the Original Packet Tab (What the firewall sees before NAT):

   • Source Zone: Select Untrust (This is where your external users are).
   • Destination Zone: Select Untrust (This is the zone the traffic enters).
   • Destination Interface: Select your Untrust interface (e.g., ethernet1/1).
   • Service: Create a new service object for HTTP/HTTPS or select web-browsing and ssl if they exist. For this example, let’s assume service-http (TCP/80) and service-https (TCP/443) objects exist. Best practice: Always use specific service objects instead of any for DNAT.
   • Source Address: any (External users can come from anywhere).
   • Destination Address: Create an address object for the public IP that external users will use to reach the web server (e.g., Public-Web-IP with value 203.0.113.10).

   What does this mean? When a packet from the Untrust zone destined for 203.0.113.10 on port 80 or 443 enters the firewall via ethernet1/1, it matches this rule.

4. Configure the Translated Packet Tab (What the firewall sends after NAT):

   • Translation Type: Select Static IP.
   • Destination Address Translation:
     • Translated Address: Create an address object for your internal web server’s private IP (e.g., Internal-Web-Server with value 10.0.0.50).
     • Translated Port: Leave as 0 if the port doesn’t change, or specify a different port if you want to perform port forwarding (e.g., public port 80 to internal port 8080). For a typical web server, leave as 0.

   What does this mean? The destination IP 203.0.113.10 will be changed to 10.0.0.50 (and the port will remain the same).

5. Click OK.

6. Commit Your Changes.

Remember: After configuring the DNAT rule, you MUST also configure a security policy rule that allows traffic from the Untrust zone to the DMZ zone. This security policy should use the translated (post-NAT) destination IP address (10.0.0.50) and the appropriate service (e.g., web-browsing, ssl).

Mini-Challenge: DNAT for a Secure Shell (SSH) Server

You have an internal SSH server in your DMZ zone at 10.0.0.20, and you want your administrators to be able to SSH into it from the internet using a public IP 203.0.113.20 on port 2222.

Your Task:

1. Create the necessary address objects for 10.0.0.20 (e.g., Internal-SSH-Server) and 203.0.113.20 (e.g., Public-SSH-IP).
2. Create a service object for TCP port 2222 (e.g., service-ssh-public).
3. Configure a Destination NAT rule on your Palo Alto Networks firewall to achieve this.
4. Describe the corresponding security policy rule you would need to implement.

Hint: Think carefully about the “Original Packet” destination address and service, and the “Translated Packet” destination address and port. Which port should change?

What to Observe/Learn:

• How to map a specific public IP and port to a different internal IP and port.
• The interaction between NAT rules and service objects.
• The importance of creating corresponding security policies based on the translated destination.

Common Pitfalls & Troubleshooting

NAT can be tricky, and misconfigurations are common. Here are a few pitfalls and tips for troubleshooting:

1. NAT Rule Order Matters: NAT rules are processed from top to bottom. If a packet matches an earlier, broader rule, it won’t be evaluated by later, more specific rules. Always place more specific NAT rules above more general ones. Use the ‘Move’ buttons in the NAT policy list to reorder.
2. Security Policy Mismatch: This is the most frequent issue!
   • For SNAT, the security policy should match the original (pre-NAT) source IP and zone.
   • For DNAT, the security policy should match the translated (post-NAT) destination IP and zone. Many people forget to use the internal IP for the destination in the security policy for DNAT.
3. Missing or Incorrect Zones/Interfaces: Double-check that your source and destination zones, and destination interfaces in the NAT rule, correctly reflect your network topology.
4. Service Object Errors: Ensure your service objects correctly define the ports and protocols needed for your traffic. Using any for DNAT is a security risk and often masks underlying service definition problems.
5. Troubleshooting Tools:
   • Traffic Logs: Check Monitor > Logs > Traffic. Look for (Deny) actions. If traffic is denied, examine the security policy that denied it to see if it’s due to an incorrect source/destination IP or service after NAT.
   • Session Browser: Go to Monitor > Session Browser and filter by source/destination IP. You can see the nat-src and nat-dst fields to verify if NAT is being applied correctly.
   • Packet Flow (CLI): For advanced troubleshooting, the test security-policy-match and test nat-policy-match commands in the CLI can simulate packet flow and show which policies are matched.
   • show session all filter (CLI): This command helps you see active sessions and their translated IP/port details.

Summary

Phew! You’ve just navigated the fascinating world of Network Address Translation on Palo Alto Networks firewalls.

Here are the key takeaways from this chapter:

• NAT is essential for IPv4 address conservation and adds a layer of security by hiding internal network topology.
• Source NAT (SNAT) changes the source IP of outgoing traffic, typically for internal users accessing the internet (often using Dynamic IP and Port).
• Destination NAT (DNAT) changes the destination IP of incoming traffic, typically for external users accessing internal servers (Static NAT/Port Forwarding).
• NAT Rule Order: Specific rules should be placed above general rules.
• Security Policy Interaction is Critical:
  • Security rules for SNAT use original source IPs.
  • Security rules for DNAT use translated destination IPs.
• Troubleshooting involves checking NAT rule order, security policy configuration, and using tools like traffic logs and the session browser.

You now have the power to control how your internal and external networks communicate at the IP address level. This is a massive step in securing and connecting your infrastructure!

In the next chapter, we’ll dive deeper into more advanced policy features, starting with App-ID, which allows the firewall to identify applications regardless of port or protocol. Get ready to unlock even more granular control!

References

• Palo Alto Networks Product Documentation: https://docs.paloaltonetworks.com/
• PAN-OS 11.1 Networking Admin Guide - NAT: https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-networking-admin/nat
• PAN-OS 11.1 Web Interface Help - Policies > NAT: https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-web-interface-help/policies/policies-nat
• NAT Policy Rules (PAN-OS 11.1): https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-networking-admin/nat/nat-policy-rules

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.