Palo Alto Destination NAT Not Working: How to Verify NAT and Security Policy

An external client connects to a public HTTPS address and times out. The destination NAT rule looks right, but the connection never reaches the web server. Trace one TCP connection through the original route lookup, NAT rule, translated route, and Security Policy. Then verify that the server sends its reply back through the firewall.

The example uses PAN-OS 11.1 CLI syntax and a classic virtual router named default. The external addresses are documentation examples. Substitute your own authorized test client, published address, server, zones, and routing instance.

Item	Example
External client	198.51.100.25
Published address	203.0.113.10:443
Real server	10.20.30.40:443
Client ingress zone	Untrust
Zone for the original destination lookup	Untrust in this topology
Zone for the translated destination lookup	DMZ

1. Confirm the connection reaches the firewall

Test from an external client. An internal client using the same public hostname may take a different path and require a separate hairpin NAT design. Record the attempt time and the destination IP the client actually used. In Monitor > Logs > Traffic, look for the same source, destination, and port on the firewall that should receive the flow.

A missing Traffic Log entry calls for an ingress check, since logging configuration and incomplete sessions can affect visibility. Use a narrow receive-stage capture if you need to confirm whether the SYN arrives. If it does not appear, check the upstream route to the published address. Where the upstream router treats the address as directly connected, verify ARP ownership or the expected proxy ARP behavior. For a routed public block, verify that the upstream next hop points toward the firewall.

Palo Alto Networks – Custom packet capture

2. Verify both destination route lookups

test routing fib-lookup ip 203.0.113.10 virtual-router default
test routing fib-lookup ip 10.20.30.40 virtual-router default

Map each returned interface to its security zone. The NAT rule’s destination zone comes from the route to the original destination IP. The Security Policy destination zone comes from the route to the translated destination IP. Both policy lookups use the original destination IP as the destination address.

Match field	NAT rule	Security Policy
Source zone	Untrust	Untrust
Destination zone	Untrust, based on the public IP lookup	DMZ, based on the real server lookup
Destination address	203.0.113.10	203.0.113.10

Use the interfaces and zones in your own topology. If the firewall uses advanced routing, check the equivalent lookup in the correct logical router.

Palo Alto Networks – Destination NAT example · PAN-OS CLI networking commands

3. Test NAT and Security Policy separately

Test the running configuration using the original connection tuple and the pre-NAT destination zone.

test nat-policy-match from Untrust to Untrust source 198.51.100.25 destination 203.0.113.10 destination-port 443 protocol 6

Check that the intended rule matches and that its translated address is 10.20.30.40. If a different rule wins, inspect rule order and the original packet criteria, including the destination interface if a rule specifies one. If your deployed rule uses port translation, compare the configured translated port with the server listener.

Next, use the post-NAT zone and keep the public IP in the destination field.

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

The example tests the ssl App-ID. Use the observed application where available and compare the result with the real session. A successful policy test confirms a match for the supplied values. A live connection still needs a working forwarding path, a responding server, and the expected application handling.

Palo Alto Networks – Test policy rules · PAN-OS 11.1 operational CLI hierarchy

4. Verify translation and follow the reply

While generating a fresh connection from the external client, query the session table using the public destination.

show session all filter source 198.51.100.25 destination 203.0.113.10 destination-port 443 protocol 6
show session id 12345

Replace 12345 with the matching session ID. Compare the original and translated flows, ingress and egress interfaces, rule, and packet counts in each direction. If needed, capture one attempt on the firewall and compare it with a capture on the server. Use the original tuple on the outside and the translated tuple on the server side.

Observation	Next check
External SYN reaches the firewall, but there is no expected translation	Verify the original tuple, pre-NAT zone, rule order, and running configuration.
The flow translates, but the security rule denies it	Check the post-NAT destination zone, original public destination object, App-ID, and service.
The translated SYN reaches the server, but the server sends no SYN-ACK	Check the listening port, host firewall, and service health.
The server sends a SYN-ACK, but it never returns to the firewall	Check the server or downstream gateway’s route back to the client.
The handshake completes, but HTTPS fails	Check TLS and application logs. Correlate the traffic log end reason with the same session.

Palo Alto Networks – Verify NAT with the session table

Worked example: A Security Policy uses the private IP

The NAT match test selects the expected rule and translates 203.0.113.10 to 10.20.30.40. The translated route leads to DMZ, but the Security Policy references the private address in its destination field. The security match test with the public IP falls through to a deny rule.

Update the intended Security Policy to match the public destination in this topology, while retaining DMZ as the destination zone and limiting access to the approved service and sources. Commit through your normal change process. Then repeat the two match tests and open a fresh HTTPS connection from the external client. Verify the translated destination, the matched Security Policy, packets in both directions, and the application response.

If the live session shows allow and the application still fails, continue with Palo Alto Firewall Is Allowing Traffic, but the Application Still Fails.