ExamFinch.com My Study

Study guide

3.3 Static NAT (One-to-One)

Practice this exam

CCSA R82 — Check Point Certified Security Administrator Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Architecture

1.1 CCSA R82 Exam Facts 1.2 Standalone vs Distributed Deployment 1.3 Gaia OS, clish and expert Mode 1.4 The SmartConsole Suite 1.5 Secure Internal Communication and the ICA

2 Chapter 2: Security Policy & Access Control

2.1 Policy Packages 2.2 Access Control Policy Overview 2.3 Ordered Layers and First-Match Evaluation 2.4 Inline Layers and Nested Rule Matching 2.5 Access Rules: Fields, Actions, and Track Options 2.6 Implied Rules and Global Properties 2.7 Stealth and Cleanup Rules: Placement and Best Practice 2.8 Hit Count and Policy Install Workflow

3 Chapter 3: Network Address Translation (NAT)

3.1 NAT Overview in Check Point 3.2 Hide NAT (Many-to-One) 3.3 Static NAT (One-to-One) 3.4 Automatic vs Manual NAT and Proxy ARP

4 Chapter 4: Identity Awareness

4.1 Identity Awareness Overview 4.2 Active Directory Query 4.3 Identity Collector 4.4 Identity Agent 4.5 Captive Portal and Access Roles

5 Chapter 5: Threat Prevention

5.1 Threat Prevention Overview 5.2 Application Control 5.3 URL Filtering 5.4 Intrusion Prevention System (IPS) 5.5 Anti-Bot and Anti-Virus 5.6 Threat Emulation and Threat Extraction 5.7 TP Profiles, Best Practice, and Ordered Layers for TP 5.8 HTTPS Inspection

6 Chapter 6: ClusterXL — High Availability, Load Sharing, and Failover

6.1 ClusterXL Overview: Why Clustering, HA vs Load Sharing 6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up 6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution 6.4 Cluster Control Protocol (CCP) and State Synchronization 6.5 Failover, Cluster States, and Troubleshooting with cphaprob

7 Chapter 7: VPN, Logs, and Troubleshooting

7.1 Site-to-Site IPsec VPN 7.2 Remote Access VPN 7.3 Encryption Domains and VPN Communities 7.4 Mobile Access Blade 7.5 Logs, Monitor, and SmartEvent 7.6 Backups, Snapshots, and Migrate Export 7.7 fw monitor, fw ctl zdebug, and cpview 7.8 cpinfo and Common Issues

3.3 Static NAT (One-to-One)

Key Takeaways Explain This Topic AI

Static NAT maps one internal host to one public IP address, bidirectionally translating source and destination

It is used to publish internal servers (web, mail, DNS) so external clients can initiate inbound connections

Because the public IP must be reachable on the gateway's external segment, the gateway must answer ARP for that IP — proxy ARP

Static NAT preserves ports (no port translation); each public IP maps to exactly one internal host

  • Access Control is still required and is evaluated on the original, pre-NAT addresses
  • Last updated: July 2026

What Static NAT Does

Static NAT is one-to-one address translation. One internal host is mapped to one public IP address, and the translation is bidirectional: when the internal host initiates outbound, its source is rewritten to the public IP; when an external host initiates inbound to the public IP, the destination is rewritten to the internal host. Unlike Hide NAT, ports are not translated — the same port number appears on both sides.

This makes Static NAT the correct choice whenever an internal host must be reachable from the Internet — a published web server, mail server, DNS server, or any service where external clients initiate the connection.

A Typical Static NAT Rule

A Manual Static NAT rule for publishing an internal web server at 10.1.1.100 behind public IP 203.0.113.50 looks like this:

Original Source Original Destination Original Service Translated Source Translated Destination Translated Service

Any 203.0.113.50 HTTP Original 10.1.1.100 Original

When an Internet client connects to 203.0.113.50:80, the gateway rewrites the destination to 10.1.1.100:80 and forwards it inside. The internal server replies from 10.1.1.100; the gateway rewrites the source back to 203.0.113.50 so the client sees a consistent endpoint.

For traffic the server itself originates (for example, fetching OS updates), a second rule — or the same rule with broader columns — rewrites the source from 10.1.1.100 to 203.0.113.50 so the server's outbound traffic also appears from its public IP. When you enable Automatic Static NAT on the server object, Check Point generates both directions for you.

Why Proxy ARP Matters

Here is the part CCSA questions repeatedly test. The public IP 203.0.113.50 is not assigned to any interface — it is a "virtual" address that the gateway translates to the internal server. But the upstream router, on the same external subnet as the gateway, must be able to deliver packets addressed to 203.0.113.50. Routers use ARP to find the MAC address for a destination IP on the local subnet. Without an ARP response, the router cannot build the Ethernet frame, and the packet never reaches the gateway.

The gateway therefore must answer ARP requests for 203.0.113.50 as if that IP belonged to it. This is proxy ARP — the gateway responds to ARP on behalf of another IP. There are two ways to make it happen on R82:

Automatic , via Automatic NAT: when you enable Automatic Static NAT in the host object's NAT tab, the gateway adds the proxy ARP entry automatically at policy install (and removes it when the rule is removed).

Manual , via Gaia: when you write a Manual Static NAT rule, you must add the proxy ARP entry yourself using clish ( add arp proxy ipv4-address 203.0.113.50 interface eth1 mac-address auto ) or the Gaia Portal. The Security Management Server does not auto-generate ARP for Manual rules.

Without proxy ARP, the symptom is deterministic: external clients time out, and a packet capture on the gateway's external interface shows the inbound packets never arriving. The router simply has no MAC to address them to.

A Common Trap: Anti-Spoofing

Check Point gateways run anti-spoofing on each interface, validating that the source of an inbound packet matches the network topology defined on that interface. When you add Static NAT, the gateway now expects to see traffic on its external interface whose destination is a public IP that is not on any interface. The topology rules must be consistent — the public IP must be treated as "behind" the gateway. With Automatic NAT this is handled; with Manual NAT, you may need to verify anti-spoofing does not drop the translated return traffic on the internal interface.

Static NAT vs Hide NAT Side by Side

  • Property Hide NAT Static NAT
  • Mapping Many-to-one One-to-one
  • Port translation Yes (source port remapped) No
  • Inbound initiation Not supported Supported
  • Use case Outbound client Internet access Publishing internal servers
  • Proxy ARP needed No (uses gateway's own IP) Yes (for the public IP)
  • Public IPs consumed One for many hosts One per published host
  • When to Choose Static NAT

Static NAT is correct when:

An internal host must accept inbound connections from the Internet.

The organization has enough public IP space to dedicate one per published server.

The server must be reachable at a stable, well-known public IP (DNS, certificates, partner firewalls allowlisting that IP).

Two-way traffic must appear to originate from the public IP (some applications embed the source address in the protocol or in logs).

A Worked Example

A company owns the public subnet 203.0.113.0/28 and uses 203.0.113.50 for the web server and 203.0.113.51 for the mail server. Both servers physically live at 10.1.1.100 and 10.1.1.101 on an internal segment. The administrator creates two host objects, enables Automatic Static NAT on each (mapping 203.0.113.50 to 10.1.1.100 and 203.0.113.51 to 10.1.1.101), and installs the policy. The gateway now answers ARP for both public IPs on its external interface, rewrites inbound destinations to the internal addresses, rewrites outbound sources from the internal addresses to the public addresses, and Access Control rules still govern which services each server is allowed to receive or initiate.