Configure Source and Destination NAT on a Palo Alto Firewall

Before you run this

This guide creates two NAT policies on a Palo Alto firewall: a source NAT rule so hosts on your inside zone reach the internet behind the firewall's public interface address (hide-NAT / PAT), and a destination NAT rule that forwards an inbound public IP and port to an internal server (a port forward). Both change how traffic is translated and, paired with the security rules they require, change what traffic is allowed. A wrong NAT or a missing/overbroad security rule can expose an internal host or break outbound connectivity for a whole zone.

You do not use sudo here. You need an administrator account on the firewall with rights to edit the NAT and Security rulebases and to commit — a superuser role, or a custom device-admin role that includes commit. Work in the web GUI over HTTPS (the normal path for PAN-OS); the CLI equivalents are shown for reference.

Treat this as a production change:

Keep an out-of-band path open. Have a console cable or a management connection that does not depend on the data-plane rules you are editing, so a mistake in a NAT or security rule can't lock you out of management and cut production traffic at the same time.
Back up first. In the GUI go to Device → Setup → Operations and use Save named configuration snapshot (and Export named configuration snapshot to pull a copy off-box) before you touch anything.
Do it in a maintenance window, and test against a lab firewall or a VM (PAN-OS runs as a VM-Series appliance) or a single test flow before you touch the live rulebase.
Rollback path: PAN-OS keeps your changes in a candidate config until you Commit. Before committing you can Config → Revert Changes to drop uncommitted edits. After a bad commit, restore the snapshot you saved with Device → Setup → Operations → Load named configuration snapshot, then Commit. There is no automatic timed rollback, so the saved snapshot is your safety net — take it.

Nothing here is irreversible if you saved that snapshot first. Once you commit a rule, though, it is live immediately.

What I assume

PAN-OS 11.x, single firewall (not Panorama-managed; if it is, you make these edits in the relevant Device Group and push).
A trust zone on the inside and an untrust zone facing the internet.
The internet-facing interface is ethernet1/1, holding your public IP.
Your inside network is 192.0.2.0/24 (replace with your real inside subnet).
The internal server you want to publish is 10.0.0.10 (replace with yours).
Menu names and CLI keywords below are PAN-OS 11; earlier and later trains differ, so confirm against your version if a label doesn't match.

Replace every example, zone name, interface, and IP with your own values.

The one thing that trips people up

On a Palo Alto, the NAT policy is evaluated to determine the post-NAT zone, but the Security policy is written against the original (pre-NAT) destination address with the post-NAT zone. For a port forward that means the security rule's destination is the public IP, and its destination zone is the zone where the internal server lives. Get this backwards and the session is created but the security policy drops it. More on that below.

Source NAT — outbound hide-NAT

This lets inside hosts reach the internet using ethernet1/1's address.

Policies → NAT → Add.
General tab: name it something like Outbound-Hide-NAT.
Original Packet tab:
- Source Zone: trust
- Destination Zone: untrust
- Destination Interface: ethernet1/1 (or leave any)
- Source Address: 192.0.2.0/24 (your inside subnet, or any)
- Destination Address / Service: any
Translated Packet tab, under Source Address Translation:
- Translation Type: Dynamic IP And Port
- Address Type: Interface Address
- Interface: ethernet1/1
- IP Address: pick the interface's public IP (or leave to use the interface address).
OK.

The CLI equivalent:

set rulebase nat rules Outbound-Hide-NAT from trust to untrust source 192.0.2.0/24 destination any service any
set rulebase nat rules Outbound-Hide-NAT source-translation dynamic-ip-and-port interface-address interface ethernet1/1

You still need a Security rule allowing trust → untrust for the traffic you want out. Source NAT here uses the real, pre-NAT source and the destination zone, so that rule is the ordinary outbound one — no special addressing trick.

Destination NAT — inbound port forward

Say you publish HTTPS on public IP 203.0.113.10 to internal server 10.0.0.10.

Policies → NAT → Add.
General: name it Inbound-Web.
Original Packet:
- Source Zone: untrust
- Destination Zone: untrust — this is the zone the public IP currently belongs to (pre-translation), which is untrust, not the server's zone.
- Destination Interface: ethernet1/1
- Source Address: any
- Destination Address: 203.0.113.10 (your public IP; use an Address object)
- Service: service-https (or the specific service/port you're forwarding)
Translated Packet: under Destination Address Translation:
- Translation Type: Static IP (this is the standard 1:1 mapping; Dynamic IP exists for a pool of servers but Static is the mainstream choice)
- Translated Address: 10.0.0.10
- Translated Port: 443 only if you're remapping the port; leave blank to keep the original.
OK.

CLI equivalent:

set rulebase nat rules Inbound-Web from untrust to untrust source any destination 203.0.113.10 service service-https
set rulebase nat rules Inbound-Web destination-translation translated-address 10.0.0.10

Add translated-port 443 to that second line only if you are remapping the port.

The matching security rule (read carefully)

Now the part that catches everyone:

Policies → Security → Add, name it Allow-Inbound-Web.
Source Zone: untrust, Source Address: any (or your allowed sources).
Destination Zone: the zone where 10.0.0.10 actually lives — e.g. dmz or trust. This is the post-NAT zone.
Destination Address: 203.0.113.10 — the original public IP, not the internal address.
Application: web-browsing / ssl (or any while testing, then tighten), Service: application-default or the specific service.
Action: Allow. OK.

Destination zone = server's zone, destination address = public IP. Hold that pattern.

Commit

Nothing is live until you commit.

Review pending changes: Config → Preview Changes (top right) or run a Config Audit under Device → Setup → Operations.
Click Commit → Commit and wait for it to finish.

CLI: commit from configuration mode after set commands.

Verify it worked

Test the policy logic without generating live traffic first, from the CLI operational mode:

test nat-policy-match from untrust to untrust source 198.51.100.5 destination 203.0.113.10 destination-port 443 protocol 6

That returns which NAT rule matches and the translated address — confirm it names Inbound-Web and translates to 10.0.0.10. Do the same for outbound:

test nat-policy-match from trust to untrust source 192.0.2.50 destination 8.8.8.8 destination-port 443 protocol 6

Then generate real traffic and check live sessions:

show session all filter destination 10.0.0.10

You should see the session with source/destination NAT applied. In the GUI, Monitor → Traffic shows the NAT rule name and the translated source/destination columns per session, and Monitor → Session Browser shows active flows. If NAT matches but traffic still fails, the security rule addressing (public IP as destination, server's zone) is the first thing to recheck.

Undo / roll back

Uncommitted: Config → Revert Changes discards the candidate edits.
Single rule: Policies → NAT (or Security), select the rule, Delete (or use the Disable action to leave it in place but inactive), then Commit. CLI: delete rulebase nat rules Inbound-Web then commit.
Bad commit: Device → Setup → Operations → Load named configuration snapshot, choose the snapshot you saved in Before you run this, then Commit.

For the exact behaviour and any option labels that shifted between trains, check the PAN-OS Administrator's Guide section on NAT (source and destination NAT examples) and the PAN-OS CLI Quick Start / reference on Palo Alto's official documentation site rather than guessing a keyword.