Shore Up
A postal sorting clerk at a gate, peeling the address label off a parcel and sticking a new one on before sending it through — the same parcel, a different address on the outside.
Security

Configure Automatic and Manual NAT on a Check Point Firewall

Ketan Aagja7 min read
No ratings yet

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.

  1. Open (or create) the Network object for your internal subnet, e.g. Net_Internal_10.0.10.0.
  2. Go to the object's NAT pane.
  3. Tick Add automatic address translation rules.
  4. Translation method: Hide.
  5. 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.
  6. Install on Gateway: leave All unless you specifically need to scope it.
  7. 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:

  1. Open the Host object for the server, e.g. Host_WebServer_10.0.10.20.
  2. Go to the NAT pane and tick Add automatic address translation rules.
  3. Translation method: Static.
  4. Translate to IP Address: the public address, e.g. 203.0.113.20 (an obvious placeholder — use yours).
  5. Install on Gateway: All.
  6. 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.

  1. In SmartConsole go to Security Policies → NAT (the NAT rule base for your policy package).
  2. 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.
  3. 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.
  4. 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.

Written by
Ketan Aagja

Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.

More about the author →

Was this article helpful?

Tap a star — no sign-in needed.

Be the first to rate this article.

Related guides

Security

Create and Install a Security Policy on a Check Point Gateway (R81.x)

This guide builds an Access Control policy in SmartConsole and installs it onto a Check Point Security Gateway. Building the policy touches only the management database; installing it is the moment that changes how the gateway forwards traffic. A policy that ends in the implicit cleanup drop, or one that removes the rule you rely on, can cut production traffic and lock you out of management in one push.

8 min read
Security

Upgrade a Check Point Gateway with CPUSE, Step by Step

CPUSE (the Gaia Deployment Agent) is Check Point's built-in tool for importing, verifying, and installing hotfixes and major-version upgrades on a Gaia gateway. In this guide I use it to take one gateway from one major version to the next. A major-version install reboots the box and replaces the running OS image — while it runs, that gateway passes no traffic and its management is offline. Treat it as a full outage, not a quick patch.

7 min read
Security

Troubleshoot Check Point Traffic with fw monitor and cpview

fw monitor is Check Point's kernel packet-capture tool: it shows you a packet at four fixed points as the gateway inspects it, so you can tell where a flow is being dropped. cpview is a live, top-style performance dashboard for CPU, memory, connections, and throughput. Both are diagnostic and read-only — neither changes your policy or configuration.

7 min read
Security

Configure ClusterXL High Availability on Check Point R81.20

This guide builds a ClusterXL High Availability (Active/Standby) pair from two Check Point gateways: two physical or virtual firewalls share one set of virtual IPs, and if the active member fails, the standby takes over the traffic and the connections. Its purpose is redundancy, not more throughput — HA mode passes traffic through one member at a time.

6 min read