Configure Address Translation and NAT Exemption on Check Point

This covers the three NAT jobs you actually do on a Check Point gateway: outbound Hide NAT so an internal network reaches the internet behind one address, a Static NAT one-to-one mapping for a published server, and a NAT exemption (no-NAT) rule so site-to-site VPN traffic is not translated. The exemption is the one people get wrong, and the one that quietly breaks a VPN.

I'm writing for Check Point R81.20, a Security Management Server and a gateway managed from SmartConsole on a Windows admin workstation, gateway OS Gaia. On R81.10 the menus are nearly identical; older R77 GUI names differ.

Before you run this

NAT on Check Point is configured in SmartConsole, not in a shell. The "script" is object properties plus NAT-policy rules, then an Install Policy. There is no bash/PowerShell here — the CLI steps below are for verification and proxy-ARP only, run in Gaia expert mode (root) on the gateway.

• Privileges: a SmartConsole administrator with read/write on the policy, able to publish and install policy. Proxy-ARP and verification commands need expert mode (root) on the gateway.
• This changes forwarding behaviour. A wrong NAT or exemption rule can black-hole production traffic or stop a VPN from establishing. Installing policy is live the moment it lands.
• Test first. Build and prove this in a lab or on a test gateway, or scope it to one test host, before you touch production. Read each rule before you install.
• Keep an out-of-band path open. Have a serial console or a separate SSH session to the gateway that does not depend on the rule you're changing, so a bad NAT can't lock you out of management.
• Back up before you change anything: take a Gaia snapshot on the gateway, and note that each Install Policy creates a database revision you can roll back to.
• Do it in a maintenance window.
• Rollback paths (named): discard the SmartConsole session if you haven't published; revert to the previous policy revision and reinstall if you have; revert the Gaia snapshot as the last resort. Covered at the end.

Take the snapshot in Gaia clish first:

add snapshot before_nat_change

(Confirm snapshot/revert syntax for your build in the Gaia Administration Guide — revert is done from Snapshot Management or the boot menu.)

1. Outbound Hide NAT for an internal network

Hide NAT translates a whole network to a single routable address — the classic "all internal hosts reach the internet behind the gateway" case. The cleanest way is automatic NAT on the network object.

1. In SmartConsole, open Objects and edit (or create) the network object for your internal subnet, e.g. Net_10.0.0.0_24.
2. Go to the NAT tab.
3. Tick Add Automatic Address Translation rules.
4. Set Translation method to Hide.
5. Choose Hide behind the gateway (hides behind the gateway's outbound interface address — the usual choice) or Hide behind IP Address and enter a specific address you own.
6. Set Install on Gateway to your gateway (or All).
7. OK, then Publish.

Check Point generates the automatic NAT rule and, for automatic NAT, handles the ARP for the hide address itself when Automatic ARP configuration is enabled in Global Properties → NAT. Leave that enabled.

2. Static NAT for a published server

Static NAT is a bidirectional one-to-one mapping — an internal server reachable from outside on a dedicated public address.

1. Edit the host object for the server, e.g. Web_Server_10.0.0.20.
2. NAT tab → Add Automatic Address Translation rules.
3. Translation method: Static.
4. Translate to IP Address: the public address, e.g. 203.0.113.20.
5. Install on Gateway: your gateway. OK, Publish.

For the gateway to answer ARP for 203.0.113.20 on its external interface, automatic ARP (above) must be on. You still need an access rule permitting the inbound service — NAT does not open the firewall, it only rewrites addresses.

3. NAT exemption (no-NAT) for VPN traffic

This is the important one. Hide NAT would otherwise rewrite internal source addresses before they hit the VPN, so the remote peer never matches its encryption domain and the tunnel's interesting traffic fails. You fix it with a manual NAT rule that translates nothing, placed above the automatic Hide NAT rules.

In SmartConsole, go to Security Policies → NAT.

1. Add a rule at (or near) the top of the manual section.
2. Original Source: your internal network object, Net_10.0.0.0_24.
3. Original Destination: the remote VPN network object, Remote_Net_192.0.2.0_24.
4. Original Service: Any.
5. Translated Source: Original.
6. Translated Destination: Original.
7. Translated Service: Original.

Setting all three Translated columns to Original means "match this traffic and do not translate it." Order matters: this rule must sit above the automatic Hide NAT rule for the same source, because Check Point applies the first matching NAT rule. Automatic rules land below manual ones by default, which is what you want here, but confirm the ordering after you publish.

Manual NAT does not auto-configure ARP. For a no-NAT rule that's fine (no new address is introduced). If you ever build a manual Static NAT, you must add proxy ARP yourself — the standard place is $FWDIR/conf/local.arp on the gateway, one line per <NAT-IP> <gateway-MAC>, with Global Properties → NAT → Merge manual proxy ARP configuration enabled. Check the exact file format and the global-property wording in the Check Point SecureKnowledge article on configuring Proxy ARP for Manual NAT before you rely on it.

4. Install the policy

Publish your session first, then Install Policy onto the gateway. Review the preview before confirming — this is the moment it goes live.

Verify it worked

Generate traffic, then check the Logs & Monitor view in SmartConsole. Add the XlateSrc, XlateDst, XlateSPort, XlateDPort columns to a log entry:

• Hide NAT: XlateSrc shows the hide address, with a translated source port.
• Static NAT inbound: XlateDst shows the internal server address.
• VPN-exempt traffic: no Xlate columns populated — original addresses preserved.

On the gateway in expert mode, confirm proxy ARP and watch packets:

fw ctl arp            # proxy-ARP entries the gateway answers for (NAT addresses)

# Live packet view, pre/post NAT (i=pre-in, o=post-out). Ctrl-C to stop.
fw monitor -e "accept host(203.0.113.20);"

For Hide NAT port allocations you can inspect the allocation table:

fw tab -t fwx_alloc -f    # hide-NAT source-port allocations, formatted

If fw ctl arp is missing an address you expect to see answered, your ARP/proxy-ARP config is the thing to fix — not the NAT rule.

Undo / roll back

• Haven't published yet: in SmartConsole, Discard the session. Nothing reached the gateway.
• Published but want the rules gone: untick the NAT checkbox on the object / delete the manual NAT rule, Publish, Install Policy.
• Already installed and traffic broke: open the gateway's policy installation history / Manage policies and revisions, select the previous revision, and Install it. This restores the exact policy that was running before your change.
• Last resort: revert the Gaia snapshot you took (before_nat_change) via Snapshot Management — this reboots the gateway back to its pre-change state.

Confirm the rollback the same way you verified the change: watch the SmartConsole logs and fw ctl arp until traffic and the VPN behave as they did before.