Network Address Translation (NAT) in Palo Alto Networks

Network Address Translation (NAT) in Palo Alto Networks firewalls allows for the translation of IP addresses and ports, facilitating communication between networks with differing addressing schemes. NAT policies are crucial for scenarios such as internet access, server publishing, and overlapping networks.

     Understanding NAT concepts and how they are implemented on the Palo Alto Networks firewall is fundamental for the PCNSE/PCNSA exams. Pay close attention to NAT types and the packet processing flow.
    

Types of NAT

Palo Alto Networks firewalls support several types of NAT, each serving specific purposes:

Source NAT (SNAT): Translates the source IP address of outbound traffic, commonly used to allow internal users to access external networks. This is typically applied to traffic originating from a trusted (internal) zone going to an untrusted (external) zone.
Destination NAT (DNAT): Translates the destination IP address of inbound traffic, typically used for publishing internal servers to external clients. This is commonly used for traffic originating from an untrusted (external) zone going to a trusted (internal) zone.
Static NAT: Provides a one-to-one mapping between internal and external IP addresses, maintaining consistent address translation. This is often used for server publishing where the external IP must always map to the same internal IP. Can be Source or Destination NAT.
Dynamic NAT: Maps internal IP addresses to a pool of external addresses, allowing multiple internal hosts to share a limited number of external IPs. The specific external IP used can vary per session.
Dynamic IP and Port (PAT): Also known as Port Address Translation, it allows multiple internal hosts to share a single external IP address by differentiating sessions using unique source port numbers. This is the most common form of SNAT for internet access.
No NAT: Specifies traffic that should not undergo any NAT. This is useful for internal communications where translation is unnecessary or for traffic destined for specific networks where the original IP addresses must be preserved.

     Know the difference between Static, Dynamic, and DIPP/PAT NAT, and their primary use cases (internet access vs. server publishing).
    

Dynamic NAT Pool vs. Interface IP: Port Exhaustion and DIPP Oversubscription

When configuring Dynamic NAT, particularly PAT/DIPP, administrators typically choose between two methods for the translated address:

Dynamic NAT Pool:

This approach involves defining a pool of public IP addresses that the firewall can use for translating internal (private) IP addresses.
Each internal host session is mapped to an available public IP address from the pool, using a unique port number on that IP.
This method provides greater scalability and flexibility, especially for environments with a large number of internal hosts requiring external access, as more public IPs mean more available source IP/port combinations.

Interface IP:

Alternatively, the firewall can use the IP address assigned to its egress interface for NAT translations.
This method is simpler to configure but may lead to port exhaustion more quickly.
All translations share a single public IP address, limiting the number of concurrent sessions to the number of available source ports (max ~64,000 per destination IP/port tuple).

Port Exhaustion

When multiple internal hosts are translated to a single public IP address (as is typical with the Interface IP method or a small DIPP pool), each unique internal source IP and port combination must be mapped to a unique public source IP and port combination for a given destination IP and port. Since there are only 65,536 TCP/UDP ports available per IP address, high-volume environments translating many internal hosts to a single public IP may exhaust available ports, leading to dropped connections for new sessions.

Dynamic IP and Port (DIPP) NAT Oversubscription

To mitigate port exhaustion, Palo Alto Networks firewalls support Dynamic IP and Port (DIPP) NAT oversubscription. This feature allows the reuse of the same translated IP address and port pair multiple times (e.g., 2x, 4x, or 8x) in concurrent sessions.

The oversubscription is based on the assumption that the full 5-tuple (source IP, source port, destination IP, destination port, protocol) will likely be unique, even if the translated source IP and port are reused. For example, an internal host connecting to Google (8.8.8.8:53) and another connecting to Cloudflare (1.1.1.1:53) can potentially use the same translated source IP and port if oversubscription is enabled.

Oversubscription rates vary by firewall model and can be adjusted (1x, 2x, 4x, or 8x).
A higher oversubscription rate increases the number of potential concurrent sessions using a single translated IP/port pair, increasing scalability with fewer public IPs.
For example, with a theoretical base limit of 64,000 sessions per translated IP, an 8x oversubscription could potentially handle 512,000 sessions.
While enabling oversubscription increases potential session capacity, it also consumes more memory resources on the firewall. Administrators should adjust the rate to balance between scalability needs and firewall resource utilization.

     Port exhaustion is a common problem addressed by DIPP oversubscription. Understand what oversubscription does and why it's necessary in high-volume NAT environments using limited public IPs.
    

For more detailed information, refer to the official documentation on Dynamic IP and Port NAT Oversubscription.

Understanding the 256 Translated IP Addresses Limit per NAT Rule

In Palo Alto Networks firewalls, each NAT (Network Address Translation) rule can reference up to 256 unique translated IP addresses. This means that when configuring a single NAT rule (e.g., for a DIPP pool), you can specify a maximum of 256 public IP addresses for translating internal (private) IP addresses.

Practical Example:

Suppose your organization has been allocated a block of public IP addresses ranging from 203.0.113.1 to 203.0.113.254 (a /24 subnet, excluding network and broadcast). This range contains 254 usable IP addresses.

If you want to use this entire /24 range for a Dynamic NAT pool in a single NAT rule, you can do so because 254 is within the 256 IP address limit per rule.

However, if you had a larger block, like a /23 (510 usable IPs), you could not put all 510 addresses into a single NAT rule's pool. You would need to split them into at least two NAT rules, each referencing a subset of the addresses.

     Attempting to configure a single NAT rule with a translated address pool containing more than 256 IP addresses will prevent the configuration commit from succeeding. The firewall might suggest reducing the oversubscription ratio *if* oversubscription combined with the number of IPs exceeds *total* session capacity, but the fundamental 256 IPs *per rule* is a hard limit for the pool definition itself.
    

Best Practices for Managing the 256 IP Limit:

Ensure that no single NAT rule references more than 256 translated IP addresses in its Source or Destination Translation configuration.
If you need to use more than 256 translated IP addresses in a pool (e.g., for large-scale outbound DIPP), consider creating multiple NAT rules, each handling a subset of the IP address pool. These rules would likely have the same 'Original Packet' criteria but different 'Translated Packet' pools. Rule order might matter if pools overlap, but typically pools are disjoint.
Monitor the total number of translated IP addresses used across all NAT rules and compare it against the firewall model's overall capacity for translated addresses (which is much higher than 256). Excessive total translated addresses can also cause commit failures.

For more detailed information, refer to the official documentation on Dynamic IP and Port NAT Oversubscription (as this limit is often discussed in that context).

IPv6 NAT Support

While the long-term goal of IPv6 is often end-to-end connectivity without NAT, there are still scenarios where NAT-like functions are needed for IPv6, particularly during migration or interworking with IPv4.

NAT64: Enables communication between IPv6-only clients and IPv4-only servers. The firewall translates the IPv6 address of the client into an IPv4 address and maps the requested IPv4 destination address. This requires a specific IPv6 prefix for the NAT64 service.
NPTv6 (Network Prefix Translation for IPv6): Translates one IPv6 prefix to another, maintaining the host portion of the address (the lower 64 bits in typical /64 assignments). This is a stateless, one-to-one translation of prefixes. Useful for scenarios like multi-homing where an organization wants to use a stable internal IPv6 prefix but appear to use different provider-assigned prefixes when connecting to different ISPs. It preserves the client's original port numbers.

     Understand the purpose of NAT64 (IPv6 to IPv4) and NPTv6 (IPv6 prefix to IPv6 prefix). NPTv6 is often preferred over NAT66 (IPv6 to IPv6 translation that changes ports) as it maintains better end-to-end transparency.
    

Understanding No NAT Policies

A "No NAT" policy rule explicitly tells the Palo Alto Networks firewall not to perform any IP or port translation on traffic matching its criteria. While most NAT rules are about performing a translation, "No NAT" is about preventing it.

Purpose of No NAT

The primary purpose is to ensure that the original source and/or destination IP addresses and ports are preserved for specific traffic flows. This is essential when translation is unnecessary, undesirable, or would interfere with the correct functioning of applications or routing.

Configuration

Configuring a "No NAT" rule is similar to configuring other NAT rules. You define the matching criteria in the 'Original Packet' tab (Source/Destination Zone, Source/Destination Address, Service). In the 'Translated Packet' tab, you simply select "No NAT" as the translation type.

Like all NAT rules, "No NAT" rules are processed from top to bottom. If traffic matches a "No NAT" rule, no further NAT rules below it will be evaluated for that traffic flow.

Scenarios Where No NAT is Useful

Scenario 1: Internal Network Traffic Between Different Zones

If you have multiple internal zones (e.g., Trust, Servers, DMZ) and traffic between hosts in these zones should use their actual private IP addresses without translation, a "No NAT" rule is appropriate. While many internal flows won't hit outbound NAT rules anyway, explicitly defining "No NAT" for specific internal zone combinations ensures clarity and prevents accidental translation if rules are reordered or zones change.

Example: Traffic from the Trust zone (10.1.1.0/24) to the Servers zone (10.1.10.0/24).

Original Packet: Source Zone: Trust, Destination Zone: Servers, Source Address: 10.1.1.0/24, Destination Address: 10.1.10.0/24, Service: any
Translated Packet: Translation Type: No NAT

Scenario 2: Traffic to/from Specific Subnets on a VPN Tunnel

When you have a VPN tunnel connecting two sites, traffic intended to go over the tunnel typically should not be Source NAT'd to the firewall's public IP. The remote side of the tunnel expects the original internal source IPs from your site. Similarly, traffic from the remote site through the tunnel should not be Destination NAT'd unexpectedly.

While policy-based VPNs and routing often direct this traffic correctly before NAT is considered, an explicit "No NAT" rule matching the source/destination zones and subnets involved in the tunnel traffic can act as an important safeguard to ensure these specific internal-to-internal flows are never translated.

Example: Traffic from your internal zone (Trust: 10.1.1.0/24) to a remote site's internal zone (VPN-Remote: 10.2.2.0/24) over an IPsec tunnel.

Original Packet: Source Zone: Trust, Destination Zone: VPN-Remote, Source Address: 10.1.1.0/24, Destination Address: 10.2.2.0/24, Service: any
Translated Packet: Translation Type: No NAT

Scenario 3: Traffic Exempted for Troubleshooting or Specific Applications

Occasionally, you might need to bypass NAT for specific hosts or services for troubleshooting purposes or because an application is incompatible with NAT (though this is less common now). A temporary "No NAT" rule placed high in the NAT policy list for that specific traffic can achieve this.

Example: Temporarily disable NAT for a specific internal host (10.1.1.50) communicating with an external server (203.0.113.100).

Original Packet: Source Zone: Trust, Destination Zone: Untrust, Source Address: 10.1.1.50, Destination Address: 203.0.113.100, Service: any
Translated Packet: Translation Type: No NAT

      Be cautious with broad "No NAT" rules to Untrust, as this could expose private IPs directly to the internet if routing permits. Always combine "No NAT" with appropriate security policies.
     

Interaction with Security Policies

Traffic matching a "No NAT" rule proceeds to the security policy check with its original source and destination IP addresses and ports, using the post-NAT zones (which are the destination zone defined in the NAT rule). Ensure your security policies permit this traffic using the original addresses and the correct destination zone.

     "No NAT" rules are critical for preserving original IPs in specific scenarios, most commonly internal-to-internal traffic or VPN traffic. Remember that traffic matching "No NAT" still undergoes policy lookup based on post-NAT zones but original IPs.
    

NAT Policy Configuration

NAT policies are configured under Policies > NAT in the firewall's web interface. Each NAT rule is defined by two main parts:

Original Packet: This tab defines the criteria that the incoming packet must match for the NAT rule to be considered. This includes Source Zone, Destination Zone, Source Address, Destination Address, and Service.
Translated Packet: This tab specifies the type of NAT to apply (Source NAT, Destination NAT, Static NAT, Dynamic NAT, No NAT) and the translated address(es) and/or port(s) to be used if a translation occurs.

     NAT rules are processed from top to bottom, and the first rule that the traffic matches is applied. More specific rules should be placed higher in the list than more general rules to ensure they are evaluated first.
    

Packet Processing Flow (Simplified)

Understanding the order in which the Palo Alto Networks firewall processes traffic is fundamental to correctly configuring NAT and security policies. A simplified flow is as follows:

Ingress: Packet arrives on an interface.
Forwarding Lookup (Route): The firewall determines the egress interface and zone based on the packet's destination IP address and the routing table.
NAT Policy Evaluation: The firewall evaluates NAT policies from top to bottom. It matches the packet based on the original source and destination zones and addresses, and the pre-NAT service.
- If a matching rule is found, the firewall determines what the translated IP/port would be, but the *actual translation* doesn't happen yet.
- This step also determines the post-NAT zone (the destination zone defined in the NAT rule).
Security Policy Evaluation: The firewall evaluates security policies from top to bottom. It matches traffic based on:
- Original source and destination IP addresses.
- Post-NAT zones (the ingress zone and the destination zone determined by the NAT lookup).
- The application is identified here (App-ID).
- User information is identified here (User-ID).
If no security policy permits the traffic based on these criteria, the session is denied.
Egress: If the security policy permits the traffic, the firewall forwards the packet out the egress interface (determined by the initial route lookup).
- If a matching NAT rule was found in step 3, the firewall performs the actual translation of the source and/or destination IP addresses and ports as the packet leaves the firewall.

     This packet flow is critical for exam success. The key takeaway is that Security Policies evaluate traffic using the
     
      original
     
     IP addresses but the
     
      post-NAT
     
     zones. The actual NAT translation happens on
     
      egress
     
     .

Mermaid Sequence Diagram: Packet Flow with NAT

Simplified packet processing flow showing NAT and Security Policy interaction.

Interaction with Security Policies

As highlighted in the packet flow, the interaction between NAT and Security policies is a frequent area of confusion and misconfiguration. Correctly understanding this interaction is vital.

Security policies control whether traffic is permitted or denied through the firewall. They perform matching based on several criteria, crucially including Source Zone, Destination Zone, Source Address, and Destination Address.

When a NAT rule is matched for a packet, it influences the security policy lookup in a specific way:

The Security policy uses the Original (pre-NAT) Source and Destination IP Addresses.
The Security policy uses the Post-NAT Zones. The source zone is the ingress zone, and the destination zone is the zone specified in the matching NAT rule's Destination Zone field.
The Security policy uses the identified Application (App-ID) and potentially User-ID.

Example Configuration Consideration:

Suppose you have a NAT rule translating internal users (Trust zone, 192.168.1.0/24) going to the internet (Untrust zone) to the firewall's Untrust interface IP.

NAT Rule: Source Zone: Trust, Destination Zone: Untrust, Source Address: 192.168.1.0/24, Destination Address: any, Service: any -> Source Translation: Dynamic IP and Port, Address Type: Interface Address, Interface: ethernet1/1 (Untrust).
Packet Flow Check: A packet from 192.168.1.10 to 8.8.8.8 arrives on a Trust interface. Route lookup points to the Untrust interface. NAT policy matches the rule. Post-NAT Zones become Trust (Source) -> Untrust (Destination). Translation determined: 192.168.1.10 -> 203.0.113.1 (Untrust IF IP).
Security Policy Match Required: The Security policy must permit traffic with Source Zone: Trust, Destination Zone: Untrust, Source Address: 192.168.1.0/24, Destination Address: any, Application: dns (if connecting to 8.8.8.8:53). Note the Security policy uses the *original* source IP (192.168.1.0/24), not the translated one.

     This is one of the most frequently tested concepts: Security policies match on ORIGINAL IPs and POST-NAT zones. Get this wrong, and traffic will be denied even if NAT is correctly configured.
    

Best Practices for NAT Configuration

Implementing NAT effectively and securely on Palo Alto Networks firewalls involves following recommended practices:

Order Matters: Place more specific NAT rules higher in the policy list than general rules. This is particularly important for "No NAT" rules or specific static NATs which must be processed before a broad Dynamic NAT rule.
Use Address Objects: Define IP addresses and subnets as Address Objects. This makes NAT rules easier to read, manage, and update. Group related objects for complex rules.
Audit Regularly: Review your NAT rules periodically to ensure they are still necessary and correctly configured. Remove unused or redundant rules.
Monitor and Troubleshoot: Use the firewall's monitoring tools (Traffic logs, Session browser, NAT counters) to verify NAT translations are occurring as expected and to troubleshoot connectivity issues. Packet Capture can also show pre- and post-NAT packets.
Purposeful NAT: Only apply NAT where necessary. Internal traffic between zones often does not require NAT ("No NAT").
IPv6 Considerations: For IPv6 deployments requiring translation, prefer NPTv6 over other forms of IPv6 NAT (like stateful NAT66) where possible, as it offers better end-to-end address transparency for the host portion.
Documentation: Clearly document your NAT policies, including the logic and scenarios they address.

Quiz: Test Your NAT Knowledge

This quiz covers key concepts about NAT on Palo Alto Networks firewalls discussed in this article.

1. Which type of NAT is typically used to publish an internal web server to the internet?

Source NAT (SNAT) Destination NAT (DNAT) Dynamic IP and Port (PAT) No NAT

Correct Answer: Destination NAT (DNAT)
DNAT translates the destination address of inbound traffic, directing external requests for a public IP to an internal server's private IP.

2. Which type of NAT is most commonly used to allow multiple internal users to access the internet using a shared public IP address?

Destination NAT (DNAT) Static NAT Source NAT (SNAT), specifically PAT/DIPP No NAT

Correct Answer: Source NAT (SNAT), specifically PAT/DIPP
SNAT translates the source address of outbound traffic. PAT/DIPP is a form of Dynamic SNAT that uses port numbers to allow many internal hosts to share one public IP.

3. According to the Palo Alto Networks packet flow, when does the actual NAT translation (changing the IP/port in the packet header) occur?

Immediately upon packet ingress After the Security policy allows the session When the packet exits the firewall (egress) It happens logically, but the packet header isn't changed

Correct Answer: When the packet exits the firewall (egress)
NAT translation is applied to the packet header just before it is sent out the egress interface.

4. When the Palo Alto Networks firewall evaluates a Security policy for traffic that has matched a NAT rule, which zone is used for the destination zone match?

The original destination zone (pre-NAT) The post-NAT destination zone (defined in the NAT rule) The source zone of the packet The 'any' zone is automatically used

Correct Answer: The post-NAT destination zone (defined in the NAT rule)
Security policies match on original IP addresses but post-NAT zones. This is a key concept.

5. When the Palo Alto Networks firewall evaluates a Security policy for traffic that has matched a NAT rule, which IP addresses are used for the source and destination address match?

The translated (post-NAT) IP addresses The original (pre-NAT) IP addresses Source is original, Destination is translated Destination is original, Source is translated

Correct Answer: The original (pre-NAT) IP addresses
Security policies consistently use the original source and destination IP addresses for matching criteria, alongside the post-NAT zones.

6. How are NAT policies processed on a Palo Alto Networks firewall?

From bottom to top, applying the last match In a random order From top to bottom, applying the first match In alphabetical order by rule name

Correct Answer: From top to bottom, applying the first match
Both NAT and Security policies are processed sequentially from the top of the list down. The first rule that traffic matches will be applied.

7. What issue does DIPP NAT Oversubscription primarily help to mitigate?

High network latency Excessive CPU utilization Port exhaustion when using a limited number of translated IP addresses High memory usage

Correct Answer: Port exhaustion when using a limited number of translated IP addresses
By allowing the reuse of translated IP/port pairs, oversubscription increases the number of concurrent sessions possible with a single public IP or a small pool, reducing the chance of port exhaustion.

8. In which scenario would you most likely use a "No NAT" rule?

Internal users accessing the internet Publishing an internal web server to the internet Traffic between two internal networks traversing a VPN tunnel via the firewall Guest Wi-Fi users accessing internal resources

Correct Answer: Traffic between two internal networks traversing a VPN tunnel via the firewall
Traffic over a VPN typically needs to retain original source/destination IPs so that hosts on the remote network see the actual internal addresses from your site.

9. What does NPTv6 primarily translate?

An IPv6 address to an IPv4 address Only the port number of an IPv6 packet One IPv6 prefix to another IPv6 prefix An IPv4 address to an IPv6 address

Correct Answer: One IPv6 prefix to another IPv6 prefix
NPTv6 is a stateless translation of the network portion (prefix) of an IPv6 address, typically used for multi-homing while preserving the host portion.

10. Which IPv6 NAT technology allows IPv6-only clients to communicate with IPv4-only servers?

NPTv6 NAT66 NAT46 NAT64

Correct Answer: NAT64
NAT64 specifically handles the translation between IPv6 client addresses and IPv4 server addresses.

11. Which Dynamic NAT method is simpler to configure but more prone to port exhaustion when translating many internal hosts?

Dynamic NAT Pool Interface IP Static NAT No NAT

Correct Answer: Interface IP
Using the Interface IP is quick but translates all sessions to a single IP, increasing the likelihood of port exhaustion compared to using a pool of addresses.

12. What is the primary benefit of enabling DIPP NAT Oversubscription?

Makes NAT traffic faster Increases the potential number of concurrent sessions per translated IP Simplifies NAT policy configuration Reduces firewall CPU load

Correct Answer: Increases the potential number of concurrent sessions per translated IP
By reusing translated IP/port pairs for different destination tuples, oversubscription multiplies the effective session capacity of a single translated IP.

13. Port Address Translation (PAT) is also known as:

DNAT DIPP (Dynamic IP and Port) Static NAT NPTv6

Correct Answer: DIPP (Dynamic IP and Port)
On Palo Alto Networks firewalls, PAT is referred to as Dynamic IP and Port (DIPP) NAT when configured with a single translated IP.

14. What is the maximum number of translated IP addresses that can be configured in a single Dynamic NAT pool within one NAT rule on Palo Alto Networks firewalls?

64 128 256 Unlimited, firewall capacity is the only limit

Correct Answer: 256
A single NAT rule can reference a pool of up to 256 translated IP addresses. To use more, you need multiple NAT rules.

15. If traffic matches a "No NAT" rule, what happens next in the packet processing flow?

The traffic is immediately dropped. A second route lookup is performed. The traffic proceeds to the Security Policy evaluation using original IPs and post-NAT zones. A default NAT rule is applied instead.

Correct Answer: The traffic proceeds to the Security Policy evaluation using original IPs and post-NAT zones.
"No NAT" simply bypasses the translation step. The packet continues through the flow, hitting the Security policy check using its original addresses and the destination zone specified in the "No NAT" rule.

16. Which is the correct order of processing steps for a packet traversing a Palo Alto Networks firewall with NAT configured?

Security Policy -> NAT Policy -> Route Lookup -> Egress Route Lookup -> Security Policy -> NAT Policy -> Egress NAT Policy -> Security Policy -> Route Lookup -> Egress Route Lookup -> NAT Policy -> Security Policy -> Egress (Apply NAT)

Correct Answer: Route Lookup -> NAT Policy -> Security Policy -> Egress (Apply NAT)
The simplified flow is Ingress -> Route -> NAT Lookup -> Security Policy (Match original IPs, post-NAT zones) -> Egress (Apply NAT).

17. DIPP Oversubscription relies on the assumption that what will likely remain unique even if the translated source IP and port are reused?

The original source IP address The full 5-tuple (Source IP, Source Port, Destination IP, Destination Port, Protocol) Only the protocol (TCP/UDP) The application identified by App-ID

Correct Answer: The full 5-tuple (Source IP, Source Port, Destination IP, Destination Port, Protocol)
Oversubscription works because while the translated source IP/port might be the same for two sessions, the destination IP/port/protocol is usually different, making the complete 5-tuple unique.

18. Which is a recommended best practice for managing NAT policies?

Randomize rule order daily for security Use the broadest possible rules to minimize complexity Never delete old rules, just disable them Regularly audit rules and remove unused entries

Correct Answer: Regularly audit rules and remove unused entries
Auditing helps keep the policy clean, reduces confusion, and prevents unintended translations. Rule order is critical and should be specific-to-general, not random. Address objects simplify management.

19. Using Address Objects for defining IPs and subnets in NAT rules primarily helps with:

Increasing NAT translation speed Simplifying management and improving readability of rules Enhancing threat prevention capabilities Reducing firewall resource utilization

Correct Answer: Simplifying management and improving readability of rules
Using named objects instead of raw IPs makes policies much easier to understand, update, and audit.

20. A common use case for a "No NAT" rule is for traffic flowing:

From an internal zone to an external (Untrust) zone for internet access From an external zone to an internal zone for server publishing Between two different internal zones where translation is not needed From an internal zone to another internal zone *without* traversing a VPN tunnel

Correct Answer: Between two different internal zones where translation is not needed
Unless there are overlapping IP ranges, traffic between internal zones typically does not require NAT and is often explicitly configured with "No NAT" for clarity and to ensure original IPs are preserved within the trusted network segments. (Traffic over a VPN to another internal network is also a strong "No NAT" case, but the prompt specifies just "internal zones").