A destination NAT rule can match while the application remains unreachable: translation and permission are separate decisions on a Palo Alto Networks firewall.[1] Before widening a Security rule, prove which address, zone and return path the failing connection actually uses.
This guide answers a specific troubleshooting question: why does Palo Alto destination NAT match, but the connection still fail? It includes a policy worksheet, a symptom-to-test matrix and an acceptance checklist you can reuse during a change. The example is hypothetical, uses symbolic objects rather than production addresses, and does not claim a firewall lab run.
The rule that prevents most DNAT policy mistakes
For NAT matching, use the original packet addresses and the destination zone associated with the pre-NAT route lookup.[1] For Security policy, use the original source and destination addresses, but the post-NAT zones.[1] A matching NAT rule does not itself authorize the connection.[1]
In a conventional internet-to-DMZ design, this means a NAT rule can be untrust → untrust, while the corresponding Security rule is untrust → dmz and still names the public destination address, not the private server address.[1][2] Do not memorize “untrust → untrust” independently of routing: it applies when the route lookup for the original public destination resolves to that zone.[1]
The worksheet below deliberately keeps the destination port unchanged. Port translation introduces another variable; validate service matching and application behavior on your actual PAN-OS release rather than extending an address-only mnemonic to every field.
Hypothetical design: publish one HTTPS service
Assume an external test client reaches a public service address through the firewall. The pre-NAT lookup resolves toward the external zone. The translated backend belongs to a routed DMZ, and its return route toward the client passes through this firewall. The intended service is TCP/443 end to end; no source translation is needed for this example.
Copyable policy worksheet
| Item | NAT rule | Security rule |
|---|---|---|
| Descriptive name | DNAT-PUBLISHED-HTTPS | ALLOW-PUBLISHED-HTTPS |
| Source zone | untrust | untrust |
| Destination zone | untrust, based on original route lookup | dmz, based on translated destination |
| Source address | Approved external test/client objects | Approved external test/client objects |
| Destination address | PUBLIC-SERVICE object | PUBLIC-SERVICE object, not BACKEND |
| Service | TCP/443 in this unchanged-port example | Explicit intended service; validate App-ID policy separately |
| Destination translation | BACKEND object; port unchanged | Not a Security-rule setting |
| Source translation | None for this routed-return example | Not a Security-rule setting |
| Permission | Translation only | Allow the intended application with required inspection |
The address/zone relationship in this worksheet follows Palo Alto Networks' documented policy matching model.[1] Object names and the rule design are original examples, not deployable configuration. Replace them with reviewed objects in your own environment; do not paste placeholder names into a production change.
Recommended implementation workflow: define the two address objects and service object; build the narrowly scoped NAT rule; create the corresponding Security rule; review existing rules above both; validate and commit through the normal change process. Preserve logging and inspection. Do not use an any-to-any allow rule as a shortcut for discovering the correct zone.
Diagnosis: separate configuration matching from packet delivery
1. Record one reproducible connection
Use a controlled external client and record its source address, destination address, protocol, destination port and a precise test time. Note any upstream translation that changes the address the firewall actually sees. If testing HTTPS, record the DNS answer and the hostname used for TLS as well.
Recommended test discipline: make a fresh connection for each comparison and avoid browser connection reuse when interpreting a change. Keep the test narrow enough that you can correlate it with a session or packet capture without guessing. Do not clear the entire firewall session table to make a single test easier.
2. Prove the selected NAT rule
PAN-OS provides NAT policy match testing under Device → Troubleshooting.[1] Use the observed original connection attributes and the appropriate zones, then record the rule returned. Treat that result as a policy-match test, not proof that a packet arrived or a backend answered.
NAT rules are evaluated top down, and processing stops at the first match.[1] A broad earlier rule can therefore prevent the intended destination translation from being selected.[1] Review no-NAT exceptions and general outbound rules as well as the rule you just added. Make a specific order change only after documenting which other flows could match it.
3. Prove the Security decision separately
Compare the original public destination object and the post-NAT destination zone with the intended Security rule.[1] In the hypothetical worksheet, a Security rule using BACKEND as its destination address is not equivalent to a rule using PUBLIC-SERVICE.[1]
Recommended evidence: the matched Security rule, action, application, original and translated addresses where exposed, byte counters in both directions and session-end information. If a log record is absent, check logging configuration and timing before concluding the packet never reached the device. A policy test and a traffic log answer different questions.
4. Trace the translated path and the reply
Inspect the route and neighbor resolution toward BACKEND, then check whether the backend receives the intended service connection. Verify the server listener, its local firewall and its route back to the observed client. These are diagnostic checks, not reasons to weaken the perimeter policy.
The firewall tracks NAT actions in session state and reverse-translates returning traffic for that session.[2] You do not need a separate reverse DNAT rule merely for replies to an established inbound connection.[2] A separately initiated outbound connection is a different policy-design question.
Use narrowly filtered captures only with authorization. Limit duration and volume, protect application payloads and remove capture files according to your operational policy. Capture observations should drive the next change; a timeout by itself does not identify which component dropped traffic.
Durable asset: NAT troubleshooting matrix
The following is an original diagnostic checklist, not a list of guaranteed root causes. Run the discriminating test before applying the suggested correction.
| Symptom | Next discriminating test | Correction to consider only after proof |
|---|---|---|
| Policy test selects the wrong NAT rule | Compare original tuple, zones and earlier matching rules | Narrow or reorder the specific overlapping rule |
| NAT test matches, but Security denies | Compare public destination object and final destination zone | Correct that Security rule, retaining least privilege |
| No correlated session or packet on ingress | Verify client DNS, upstream route and test timestamp | Repair reachability before editing translation |
| Packet leaves toward the wrong backend | Compare translated object and actual forwarding path | Correct the object or route after impact review |
| Backend sees the request but sends no reply | Inspect listener, server firewall and local logs | Repair the backend service or host policy |
| Backend replies but the firewall sees no return traffic | Trace the backend gateway and return route | Restore the intended symmetric return path |
| TCP connects but HTTPS fails | Check hostname, certificate, TLS alerts and inspection logs | Resolve the application/TLS issue rather than broadening NAT |
| External access works; internal access to public name fails | Compare internal client's ingress zone and backend return path | Design explicit U-turn NAT or reviewed split DNS |
| Only a newly added public address fails | Establish whether delivery is on-link ARP or routed | Correct the upstream route or address ownership model |
Public address delivery: proxy ARP is not a route
Palo Alto Networks documents proxy ARP when a NAT pool address lies in the same subnet as the relevant firewall interface.[1] When the NAT pool address is outside an interface subnet, the firewall does not provide that proxy ARP behavior; the upstream router needs a route that delivers the traffic appropriately.[1]
Before changing NAT, ask the provider or upstream-network owner whether the public service address is on-link or routed toward the firewall. Record the expected next hop. Avoid troubleshooting an absent route by repeatedly changing an otherwise correct Security rule.
Hairpin access: do not blindly copy the external rule
Palo Alto Networks describes a U-turn case in which the internal client and server share a network: without source translation, the server can reply directly to the client, bypassing the firewall.[2] In that scenario, source translation toward the firewall can keep the reply on the stateful path.[2]
Do not infer that every DNAT deployment requires SNAT. In this article's routed DMZ example, the return path is already through the firewall by design. For internal access, document whether preserving the original client address matters to application logging, and compare a dedicated U-turn policy with a split-DNS design before choosing.
Acceptance checklist for the change window
Use this as a sign-off template. Fill in actual results and evidence links; unchecked items are not successful tests.
- [ ] Approved external source reaches the intended application using its normal hostname.
- [ ] Observed original and translated destination match the worksheet.
- [ ] The intended NAT and Security rules are selected for a fresh test connection.
- [ ] Required application inspection and logging remain enabled.
- [ ] A disallowed source and an unintended service remain blocked, tested only from authorized systems.
- [ ] The backend response traverses the expected firewall path.
- [ ] Internal-client access is either deliberately supported and tested or explicitly out of scope.
- [ ] Neighboring published services still work after any rule-order change.
- [ ] Application owner verifies a real transaction, not just a TCP handshake.
- [ ] Rollback owner, saved configuration and stop conditions are recorded.
Suggested rollback triggers include an unintended exposure, loss of a previously working published service or inability to explain the selected rule. Revert the reviewed change through the normal workflow rather than adding a broad bypass rule. If high availability is in scope, schedule a separately approved failover test; do not turn an ordinary NAT fix into an unplanned resilience exercise.
Practical takeaways
First prove the packet and selected rule, then prove Security permission, then prove backend delivery and return traffic. The key PAN-OS distinction is original addresses for policy matching, with the translated destination zone for Security policy.[1] Keep an address/zone worksheet beside the change request so that a matching NAT rule is never mistaken for end-to-end application success.
For adjacent design work, browse the Data Center networking hub and the Start Here topic index.
Scope and sources: the linked vendor documentation supports the NAT fundamentals; the troubleshooting sequence, worksheet and acceptance criteria are original operational recommendations. Menu placement and detailed behavior should be checked against your installed PAN-OS release. No customer materials, production identifiers or vendor screenshots are reproduced.
Post a Comment