Palo Alto NAT Miss: test nat-policy-match When Return Traffic Dies

Palo Alto · Techclick CLI troubleshooting lab

Outbound web works. Inbound published app answers SYN then goes silent. Security policy is allow.

This is a live-ticket style lesson from Techclick Infosec. You will isolate the fault with CLI first, then prove the fix with one clean packet or log.

What you will be able to do

• Name the first CLI command to run on Palo Alto for this ticket

• Separate the layer that is actually broken from the layer people blame

• Apply one scoped fix instead of a global disable

• Prove the ticket closed with a session, log, or counter

Quick answer

Run test nat-policy-match for both directions. If destination NAT is missing or source NAT is hiding the server, the return packet never finds the original session.

Why this ticket shows up

NAT and security policy are separate lookups. A perfect security rule still fails when destination NAT points at the wrong server or when source NAT changes the return path.

Symptoms operators actually see

• SYN arrives, no SYN-ACK at the client

• Server sees the packet with a wrong destination IP

• Session ends as aged-out or discard

• Works from inside the same subnet

CLI first — copy this block

Run these on the Palo Alto device or console named in the ticket. Do not skip the first show command — it tells you which later command matters.

test nat-policy-match from untrust to trust source 198.51.100.20 destination 203.0.113.50 destination-port 443 protocol 6
show session all filter destination 203.0.113.50 destination-port 443
show running nat-policy
show counter global filter packet-filter yes delta yes

How to read that output

The NAT test must show the real inside server IP as Translated Destination. If it shows the public IP unchanged, destination NAT did not hit. Check that the untrust interface is in the NAT rule's destination interface/zone.

Triage order

1. Capture one inbound 5-tuple from the ISP or untrust interface.

2. Run test nat-policy-match with that 5-tuple.

3. Confirm the translated destination is the real server.

4. On the server, confirm it receives the packet and replies to the original client or to the firewall, depending on NAT type.

5. Fix the NAT rule order — first match wins, just like security policy.

Classic traps

What you see	Real cause	Fix
Security rule is allow	NAT rule never matched	Test NAT separately
U-turn needed	Client and server both on trust	Add a hairpin / u-turn NAT
Port 443 open	NAT still on 80	Service object mismatch

Proof the ticket is closed

• NAT test shows the inside IP

• Session bidirectional counters increment

• External curl gets 200

Say this in an interview

I split NAT and security. If NAT is wrong, a perfect allow rule still looks like a black hole.

---

Need the full vendor lab, mock interview, and production runbooks? Techclick trains Palo Alto, Zscaler, F5, FortiGate, Check Point, Cisco ISE, Azure and routing with live CLI — start at https://www.techclick.in/