Palo Alto Destination NAT and Port Forwarding with a Real-Life Web Server Example

Configuring destination NAT on a firewall can be confusing if you transition from other security platforms. Palo Alto Networks processes NAT and security policies using a distinct logic. A successful Palo Alto Destination NAT configuration requires you to understand how the architecture handles zone lookups and address evaluation during packet processing.

In this tutorial, you will learn how to publish an internal HTTPS web server to the internet using Destination NAT (DNAT) and Port Forwarding. We will cover the core architectural rules, step-by-step GUI and CLI steps, packet flow mechanics, verification commands, and real-world troubleshooting techniques.

Real-Life Scenario

Your enterprise operates an internal portal located in the DMZ network. The server hosts an application over secure HTTP (HTTPS) at the private IP address 192.168.20.10 listening on standard TCP port 443.

The business requirement dictates that remote clients and external partners must access this web server from the public internet. Your Internet Service Provider (ISP) assigned a public IP subnet to your WAN interface. You allocated the public documentation address 203.0.113.10 to represent this server on the internet.

To fulfill this requirement, you must create configuration policies on the firewall to perform two tasks:

• Translate incoming traffic addressed to 203.0.113.10 to the internal address 192.168.20.10.
• Allow the inbound HTTPS traffic through the security policy while maintaining strict access controls.

Lab Topology

The diagram below illustrates the physical and logical network path for inbound client connections. All network addresses, hostnames, and interface identifiers shown in this tutorial are LAB/EXAMPLE values and must be adapted to match your production environment.

[ Internet Client ]
  IP: 198.51.100.45
        |
        | (Inbound HTTPS Request to 203.0.113.10:443)
        v
+-------------------------------------------------------+
| Firewall Ingress: ethernet1/1                         |
| Zone: Untrust                                         |
|                                                       |
| PAN-OS Packet Processing Engine:                      |
|  1. NAT Policy Lookup   -> Translate IP to 192.168.20.10|
|  2. Security Evaluation -> Allow Untrust to DMZ       |
|                            Destination: 203.0.113.10  |
|                                                       |
| Firewall Egress: ethernet1/2                          |
| Zone: DMZ                                             |
+-------------------------------------------------------+
        |
        | (Translated Packet: 198.51.100.45 -> 192.168.20.10:443)
        v
[ Internal Web Server ]
  IP: 192.168.20.10

Example Addressing and Objects

Before configuring rules on the firewall, define standardized address and service objects. Using structured object names simplifies maintenance and auditing.

Prerequisites

Ensure the following network baseline exists before configuring Destination NAT:

• Zone definitions for Untrust and DMZ are active on the firewall.
• Interface ethernet1/1 is assigned to the Untrust zone with a public IP configuration or connection to the ISP layer.
• Interface ethernet1/2 is assigned to the DMZ zone with IP address 192.168.20.1/24 acting as the default gateway for the web server.
• A Virtual Router exists with a default route (0.0.0.0/0) pointing to the ISP upstream router.
• The web server at 192.168.20.10 has its local default gateway set to 192.168.20.1 and accepts connections on TCP port 443.

Step-by-Step GUI Configuration

Configuring Destination NAT requires creating Address Objects, a NAT Policy rule, and an accompanying Security Policy rule.

For the related outbound configuration, see the Palo Alto Source NAT guide and Palo Alto Security Policy guide.

Step 1: Create Address Objects

1. Navigate to Objects > Addresses.
2. Click Add at the bottom of the screen.
3. Name the first object H-Web-Server-Private, set Type to IP Netmask, and enter 192.168.20.10. Click OK.
4. Click Add again to create the public address object.
5. Name the object H-Web-Server-Public, set Type to IP Netmask, and enter 203.0.113.10. Click OK.

Step 2: Create the Destination NAT Rule

The NAT policy instructs the firewall to rewrite the packet destination address when an inbound connection hits the external interface.

1. Navigate to Policies > NAT.
2. Click Add to create a new NAT rule.
3. In the General tab, enter the rule name: Inbound-DMZ-Web-NAT.
4. In the Original Packet tab:
   • Source Zone: Click Add and select Untrust.
   • Destination Zone: Click Add and select Untrust. (Select the zone corresponding to the ingress interface where the public IP resides).
   • Destination Interface: Select ethernet1/1 (or leave as any).
   • Service: Select service-https or any.
   • Source Address: Select any.
   • Destination Address: Click Add and select H-Web-Server-Public.
5. In the Translated Packet tab:
   • Under Destination Address Translation, set Translation Type to Dynamic IP and Port or Static IP (select Static IP for 1-to-1 destination mapping).
   • Translated Address: Select H-Web-Server-Private.
   • Translated Port: Leave blank if the port remains 443. If you are forwarding a non-standard public port (for example, port 8443) to port 443, specify 443 here.
6. Click OK.

Step 3: Create the Inbound Security Policy Rule

In PAN-OS, NAT rules do not grant permission for traffic to flow. You must configure a security policy rule to explicit allow the packet. You must construct this security rule using specific address and zone combinations.

1. Navigate to Policies > Security.
2. Click Add to create a rule. Place it above any generic deny rules.
3. In the General tab, enter the name: Allow-Inbound-DMZ-Web.
4. In the Source tab, set Source Zone to Untrust and Source Address to any.
5. In the Destination tab:
   • Destination Zone: Select DMZ (This is the Post-NAT zone where the physical destination host resides).
   • Destination Address: Select H-Web-Server-Public (This is the Pre-NAT public address that the client originally targeted).
6. In the Application tab, add web-browsing and ssl.
7. In the Service/URL Category tab, select application-default.
8. In the Actions tab, ensure Action Setting is set to Allow. Enable Log at Session End.
9. Click OK.

CLI Configuration

You can execute the same configuration through the PAN-OS Command Line Interface (CLI). Access the firewall via SSH and enter configuration mode.

configure

Define the private and public address objects:

set address H-Web-Server-Private ip-netmask 192.168.20.10/32
set address H-Web-Server-Public ip-netmask 203.0.113.10/32

Configure the Destination NAT policy rule:

set rulebase nat rules Inbound-DMZ-Web-NAT from Untrust to Untrust source any destination H-Web-Server-Public service service-https destination-translation translated-address H-Web-Server-Private

Configure the matching Security Policy rule:

set rulebase security rules Allow-Inbound-DMZ-Web from Untrust to DMZ source any destination H-Web-Server-Public application [ ssl web-browsing ] service application-default action allow log-end yes

Review your changes before applying them:

show config diff

Commit the changes to the active configuration:

commit

CAUTION: Committing configurations updates the active rulebase. Ensure that your rule criteria do not accidentally match broader production traffic.

How the Traffic Flows

Understanding packet processing logic in PAN-OS prevents common design and troubleshooting errors. PAN-OS processes inbound Destination NAT through a predictable set of stages:

1. Ingress Processing: An IP packet arrives on interface ethernet1/1 (Zone: Untrust). Source IP: 198.51.100.45, Destination IP: 203.0.113.10, Destination Port: TCP 443.
2. NAT Policy Evaluation: The firewall performs a NAT rule lookup based on the original criteria:
   • Source Zone: Untrust
   • Destination Zone: Untrust (Zone associated with ingress interface)
   • Destination IP: 203.0.113.10

   The firewall matches Inbound-DMZ-Web-NAT. It notes the translated destination address (192.168.20.10).

3. Route Lookup (Post-NAT Destination): The firewall checks the Virtual Router table for the route to the translated destination (192.168.20.10). The routing table indicates that 192.168.20.10 is reachable via interface ethernet1/2 in the DMZ zone.
4. Security Policy Evaluation: The firewall evaluates security rules using a unique hybrid match:
   • Source Zone: Untrust (Original ingress zone)
   • Destination Zone: DMZ (Post-NAT zone determined by the route lookup)
   • Destination Address: 203.0.113.10 (Pre-NAT address requested by the client)

   The packet matches rule Allow-Inbound-DMZ-Web and access is granted.

5. Packet Rewriting and Egress: The firewall rewrites the IP packet header destination address to 192.168.20.10 and forwards the frame out interface ethernet1/2 toward the server.

Verification

Verify that your NAT and security policies match incoming traffic using operational CLI testing tools and session monitors.

1. Test NAT Rule Match

Run the test nat-policy command to verify that inbound traffic hits your NAT configuration:

test nat-policy ingress-interface ethernet1/1 source 198.51.100.45 destination 203.0.113.10 protocol 6 destination-port 443

The command output should display the matching rule name and the translation destination:

Inbound-DMZ-Web-NAT; Dynamic translation IP...
Result: 192.168.20.10:443

2. Test Security Policy Match

Run the test security-policy-match command using the Post-NAT Zone and Pre-NAT Destination IP:

test security-policy-match from Untrust to DMZ source 198.51.100.45 destination 203.0.113.10 protocol 6 destination-port 443 application ssl

Verify that the output confirms a match on rule Allow-Inbound-DMZ-Web with an action of allow.

3. Active Session Table Inspection

Initiate an HTTPS connection from an external client to 203.0.113.10. While the connection is active, query the active firewall sessions filtering by the internal server IP:

show session all filter destination 192.168.20.10

Identify the Session ID from the output list, then view session details:

show session id 12345

Confirm the session details output shows the double-sided flow structure:

c2s flow: 198.51.100.45[49152] -> 203.0.113.10[443] (Untrust)
s2c flow: 192.168.20.10[443] -> 198.51.100.45[49152] (DMZ)

Troubleshooting

When inbound connections to the translated server fail, systematically analyze symptoms using the operational workflow below.

Symptom 1: Traffic is Dropped by Default Deny Rule

• Evidence: Traffic logs show log entries for destination 203.0.113.10 hit the interzone-default or cleanup deny rule.
• Root Cause: The security policy configuration uses incorrect parameters. You likely configured the destination zone as Untrust instead of DMZ, or configured the destination IP as 192.168.20.10 instead of 203.0.113.10.
• Check: Verify the security policy parameters. Ensure the Destination Zone is set to DMZ (Post-NAT) and Destination Address is set to 203.0.113.10 (Pre-NAT).

Symptom 2: Connection Initiates but Fails with TCP SYN Timeout

• Evidence: Firewall session table shows state INIT or TCP SYN SENT, but the TCP handshake never completes.
• Root Cause: Routing failure on the return path or host-level packet blocking.
  1. The web server lacks a default gateway pointing back to the firewall’s DMZ interface (192.168.20.1).
  2. A host firewall on the server (for example, Windows Firewall or iptables) is dropping packets from external source subnets.
• Check: SSH to the web server and verify its default route. Ping 192.168.20.1 from the server. Check host firewall logs.

Symptom 3: NAT Rule Does Not Match

• Evidence: Run test nat-policy and the firewall responds with no rule matched or matches a general outbound rule.
• Root Cause: Destination Zone in the NAT rule is incorrectly configured.
• Check: In the NAT policy Original Packet tab, confirm that the Destination Zone is set to the zone of the receiving interface (Untrust), not the internal zone.

Common Mistakes

Avoid these frequent configuration errors when implementing destination NAT in PAN-OS:

• Using the Post-NAT IP in the Security Policy: Entering the internal address (192.168.20.10) in the security policy destination address field will cause the rule to fail. PAN-OS requires the **Pre-NAT IP** (203.0.113.10) in the security policy rule.
• Using the Pre-NAT Zone as the Security Destination Zone: Setting the security policy destination zone to Untrust causes access failure. The firewall evaluates security rules after determining the egress route, so the destination zone MUST be the **Post-NAT Zone** (DMZ).
• Forgetting Proxy ARP: If the public address 203.0.113.10 is in the same IP subnet as interface ethernet1/1 but not explicitly assigned to the interface itself, the upstream ISP router will issue ARP requests for 203.0.113.10. The firewall will not answer those ARP requests unless Proxy ARP is handled naturally by the NAT rule or configured on the interface.
• Over-restricting Application Identification (App-ID): Setting the security rule App-ID to strictly web-browsing on port 443 can cause initial SSL/TLS handshakes to drop before App-ID identifies the traffic. Include the ssl application in your security policy rule.

Production Considerations

When deploying Destination NAT in production enterprise networks, keep the following considerations in mind:

1. High Availability (HA) Synchronisation

In an Active/Passive HA pair, NAT rules and address objects sync automatically across devices. Ensure that upstream switches or ISP routers process ARP changes smoothly during a failover event.

2. Source NAT (SNAT) for Hairpinning

If internal hosts in your LAN zone need to access the DMZ server using its public IP address (203.0.113.10), you must implement a “Hairpin NAT” policy. This requires an additional Source NAT rule to translate internal source IPs to the internal firewall interface IP so return traffic routes symmetrically through the firewall.

3. Vulnerability Protection and Security Profiles

Public-facing web servers receive continuous automated attacks from the internet. Always attach Security Profiles to your inbound access rule, including:

• Antivirus Profile
• Vulnerability Protection Profile
• URL Filtering Profile
• WildFire Analysis Profile

Summary

Completing a successful Palo Alto Destination NAT configuration requires strictly following the PAN-OS rule architecture:

• NAT Policy: Source Zone = Untrust, Destination Zone = Untrust, Destination IP = Pre-NAT Public IP. Translated Destination = Post-NAT Private IP.
• Security Policy: Source Zone = Untrust, Destination Zone = Post-NAT Zone (DMZ), Destination IP = Pre-NAT Public IP.

By keeping this distinction clear—Pre-NAT IP with Post-NAT Zone for security rules—you can publish internal applications cleanly and securely without unexpected policy drops.