Configure Automatic and Manual NAT on a Check Point Firewall

Before you run this

This guide creates NAT rules on a Check Point gateway: Hide NAT (many internal hosts sharing one public address for outbound access) and Static NAT (a one-to-one map so a public address reaches an internal server). NAT rules rewrite the source or destination address of live traffic — get one wrong and you can break outbound Internet for a whole subnet or expose a server you didn't mean to.

Privileges: You need a SmartConsole login with write access to the policy, and the ability to Install Policy. The proxy-ARP step for Manual NAT needs expert-mode (root) shell on the gateway itself. Object and rule changes are made on the management server; they do nothing until you push policy to the gateway.
This changes production traffic flow. A published, installed NAT rule takes effect immediately on the next packet. Test on a lab management server / gateway or a non-production policy package first, and validate with a single test host before you touch the real subnets.
Keep an out-of-band way in. Have a separate console/SSH session to the gateway (and to the management server) open on an interface that your NAT change does not touch, so a bad rule can't lock you out of management while it's also cutting production traffic.
Back up before you change anything. On the management server take a Gaia snapshot or run the documented backup/migrate export procedure. Every Install Policy is also saved as a policy package revision, and object changes live in a session you can discard before publishing.
Do it in a maintenance window.
Rollback path: discard the session before you publish; after publishing, revert database changes from the management server's revision history; after installing, re-Install Policy from an earlier package revision. Restore the Gaia snapshot only as a last resort.

Read the whole procedure before you start. NAT rule order matters, and Manual NAT does not create proxy ARP for you the way Automatic NAT does — the last section exists specifically so you don't miss that.

Assumptions

Check Point R81.20, distributed setup: a Security Management Server and a separate Security Gateway, driven from SmartConsole R81.20.
Gaia OS on the gateway, with expert-mode access.
You already have Host / Network objects for the addresses involved, or will create them.
Menu paths and CLI move between versions. If you're on R80.40 or R81/R81.10 the concepts are identical but confirm exact wording against the Check Point Security Management Administration Guide for your version.

Step 1 — Check the global NAT settings

From the SmartConsole main menu (top-left), open Global Properties → NAT - Network Address Translation. Confirm the defaults are sane for your environment:

Automatic ARP configuration — leave enabled. This is what lets Automatic NAT answer ARP for translated addresses for you. It does not cover Manual NAT.
Translate destination on client side — the default that makes Automatic Static NAT work without extra routing.

Don't change these casually; they affect every NAT rule. If you're unsure what a checkbox does, look it up in the admin guide before touching it rather than guessing.

Step 2 — Automatic Hide NAT (outbound sharing)

This is the common "let this internal network reach the Internet behind the gateway's public IP" rule.

Open (or create) the Network object for your internal subnet, e.g. Net_Internal_10.0.10.0.
Go to the object's NAT pane.
Tick Add automatic address translation rules.
Translation method: Hide.
Choose Hide behind Gateway (translate to the gateway's outbound interface IP) — this is the standard choice. Hide behind IP Address is the alternative when you want a specific address instead.
Install on Gateway: leave All unless you specifically need to scope it.
Click OK, then Publish.

Check Point auto-generates the Hide rule in the NAT rule base and handles ARP automatically.

Step 3 — Automatic Static NAT (publish a server)

To map a public IP one-to-one onto an internal server:

Open the Host object for the server, e.g. Host_WebServer_10.0.10.20.
Go to the NAT pane and tick Add automatic address translation rules.
Translation method: Static.
Translate to IP Address: the public address, e.g. 203.0.113.20 (an obvious placeholder — use yours).
Install on Gateway: All.
OK → Publish.

With Automatic ARP configuration enabled (Step 1), the gateway will answer ARP for 203.0.113.20 on the relevant interface. You still need an Access Control rule that permits the inbound service to the server's real object — NAT translates, the firewall rule base allows.

Step 4 — Manual NAT (when the automatic rules aren't enough)

Use Manual NAT for translations Automatic NAT can't express: port-based (destination) translation, translating only for specific services, or mapping to addresses not tied to a single object.

In SmartConsole go to Security Policies → NAT (the NAT rule base for your policy package).
Add a rule and fill the Original and Translated columns with your objects and services. Automatic rules are generated into their own sections; place your manual rules deliberately, because the base is evaluated top-down and first match wins.
For a destination NAT (inbound server publishing with a different port), set the Original Destination to the public object and the Translated Destination to the internal server object, and the Translated Services to the internal port.
Publish.

The exact behaviour of each translated cell (static vs. hide, per-cell options) is documented with screenshots in the Security Management Administration Guide under NAT — follow it for the specific combination you need rather than guessing a cell setting.

Step 5 — Proxy ARP for Manual NAT (do not skip)

Manual NAT does not auto-configure proxy ARP. If your translated public address lives on a directly-connected interface subnet and isn't a routed-to address, the gateway won't answer ARP for it and inbound traffic will silently fail.

The standard fix is the local.arp file on the gateway, in expert mode:

# On the Security Gateway, as root (expert mode)
# Format per line:  <NAT_IP_address>  <MAC_of_the_gateway_interface_on_that_subnet>
vi $FWDIR/conf/local.arp

203.0.113.20   00:1c:7f:aa:bb:cc

Get the correct interface MAC from ip link show <interface>. After editing, the entries are applied on the next Install Policy. There is also a Global Properties option governing whether manual proxy-ARP is merged with the automatic configuration — confirm its exact wording and behaviour in the Check Point SecureKnowledge article on configuring proxy ARP for Manual NAT before relying on it. I'm not going to quote a menu string I can't verify for your build.

Step 6 — Install policy

Nothing above is live until you push it:

Menu → Install Policy (or the toolbar button), select your gateway, and install.

Watch for verification warnings. A NAT rule that overlaps or hides another triggers a warning at install time — read them, don't click through.

Verify

On the gateway, in expert mode:

fw ctl arp            # lists the proxy-ARP entries the gateway answers for
                      # (both automatic-NAT and your local.arp entries should appear)

fw tab -t fwx_alloc -f   # Hide-NAT port allocations, confirms outbound Hide NAT is active

For a live trace of what's being translated, use fw monitor (see the fw monitor documentation for the capture-point syntax) to watch a packet's address change across the inspection points.

Functional checks:

Hide NAT: from an internal test host, browse out / curl ifconfig.me and confirm you egress with the expected public address.
Static NAT: from outside, reach the published service on 203.0.113.20 and confirm it lands on the internal server (check the server's own logs for the connection).

Undo / roll back

Before publishing: in the session pane, Discard — the object/rule changes vanish.
After publishing, before install: revert the change from the management server's revision history.
After install: open Install Policy history and re-install an earlier policy package revision to restore the previous NAT behaviour on the gateway.
Remove a NAT rule cleanly: for Automatic NAT, untick Add automatic address translation rules on the object; for Manual NAT, delete the rule; then remove the matching local.arp line, Publish, and Install Policy.
Gaia snapshot restore is the heavy-handed last resort if the management database itself is in a bad state.

Confirm the rollback the same way you confirmed the change — fw ctl arp and a live traffic test — before you close the maintenance window.