Check Point is a session factory. SMS toast ≠ gateway.

1. Why the toast is a trap

The ticket says “the firewall is blocking SaaS.” The screenshot is SmartConsole with a green toast. L1 SSHes the first cluster IP that answers, sees a Gaia login, and adds an Any-Any “just to test.” Twenty minutes later the same drop is still there — or worse, the cleanup rule is now theater.

Check Point is a session factory. A connection is minted only after independent stamps. The toast is check two, and only if you asked the enforcement point. Helpdesk treats SmartConsole as the whole product. That is the lie this lesson kills.

Hero · who talks to whom

2. Mental model — five stamps

Memorize the order before you open SmartConsole. Each stamp has its own menu and its own false “green.” ClusterXL is not a sixth stamp on the packet — it is which box you ask. Get that wrong and every later stamp is theater.

Pre-train the hard words before the runbook. Security Management Server (SMS) is the design plane: objects, layers, Publish, Install. Security Gateway is the data plane: interfaces, anti-spoof, connections table, NAT, blades. SmartConsole is the GUI that talks to the SMS — it is not the box that forwarded the SYN. SIC (Secure Internal Communication) must be Communicating before you trust Get Interfaces. Publish session writes your edits to the SMS database; unpublished work is not on any gateway. Install Policy pushes a package to selected targets. Access Control and Threat Prevention are separate policies you can install independently. Path: SmartConsole left pane Security Policies versus expert mode on the gateway fw stat / cphaprob state.

Vocabulary you will use on the wire

3. Decision flow on the gateway

Draw this on a whiteboard before you touch a rule. The browser never goes “through SmartConsole.” The SYN lands on an interface. Anti-spoof runs first — official wording: NAT is performed after Anti-Spoofing checks, which are performed only on the source IP. Then the installed Access Control policy. Then NAT. Then Threat Prevention. ClusterXL only decides which member owns the VIP.

Path · stamps then allow or drop

4. How to choose the stamp

Use the symptom, not the user’s theory. “The firewall is down” is never a stamp.

5. Side A / B / C runbook

Goal: a new lab VLAN 192.0.2.0/24 is on eth1, anti-spoof allows it, Access Control accepts Finance-SaaS tcp/443, NAT hides behind the lab egress, Threat Prevention stays Prevent on the shared profile, and the gateway proves the install. Lab values only. Nothing here is a customer tenant.

Side A — SmartConsole (topology + rule of record)

Primary source: R81 Quantum Security Management Administration Guide — Manually Updating the Gateway Topology and Preventing IP Spoofing. If the VLAN is missing from the gateway object, every Accept you write is theater. Anti-spoofing runs before the ordered Rule Base.

1. Open the gateway object

   Connect SmartConsole to the lab SMS. Left pane Gateways & Servers. Double-click the cluster object (dummy: CP-LAB-CL-01) or the member you will install. Confirm SIC is Communicating before you trust Get Interfaces. Official: if SmartConsole fails to retrieve topology, check General Properties and that the gateway, SMS, and SmartConsole can communicate.

2. Refresh topology — do not guess the map

   Network Management. Official: click Get Interfaces and choose Get Interfaces With Topology or Get Interfaces Without Topology. With Topology, a warning asks if you want to overwrite existing Topology and Anti-Spoofing settings — read that warning. Click Yes only if you intend to replace the map. The Get Topology Results window opens. Click Accept. Then select eth1 → Edit.

3. Set Leads To and Anti-Spoofing from Topology Settings

   Official interface path: navigation tree General → Topology section → Modify. Topology Settings opens. Under Leads To choose This Network (Internal) (or Internet External / Interface leads to DMZ). For internal, pick how addresses are defined:

   • Not Defined — all IPs behind this interface are considered internal.
   • Network defined by the interface IP and Net Mask — only the directly connected network.
   • Network defined by routes — Dynamic Anti-Spoofing; the gateway recalculates from routes without another Get Interfaces.
   • Specific — a Network, Host, Address Range, or Network Group. Put 192.0.2.0/24 here if it is not the connected mask.

   Select Perform Anti-Spoofing based on interface topology. Action = Prevent (drop spoofed packets) unless you are in a documented learn window, then Detect + Spoof Tracking Log. Optional: Don't check packets from for a scoped exception object. Click OK twice. Repeat for every interface — official: configure Anti-Spoofing on all interfaces, including internal.

4. Write the access rule under the right layer

   Security Policies → Access Control → Policy. Add a scoped rule using documented columns: Source = Finance_Net, Destination = SaaS_Finance, VPN = Any (or the community you intend), Services & Applications = HTTPS, Action = Accept, Track = Log, Install On = Policy Targets / the cluster. Keep it above cleanup. Do not insert Any-Any “to test.” Hits is a counter, not proof the user’s SYN completed.

5. Check NAT and Threat Prevention — do not skip them

   Security Policies → NAT. Official methods: Hide behind gateway, Hide behind IP address, or Static. Hide: connections start from internal computers; the gateway does not allow unsolicited external access to those internals. Static: external traffic can reach the translated resource. Automatic rules come from the object NAT page; Manual rules you place. Enforcement is sequential by the No. column. Install Access Control after NAT edits.

   Security Policies → Threat Prevention. Confirm the profile applied to this gateway is the one the SOC thinks is live. Accept in Access Control still sends the flow through IPS / Anti-Bot / Anti-Virus / Threat Emulation / Threat Extraction if those blades are on. Official: you can install Threat Prevention separately from Access Control to reduce impact.

Side B — Publish, then Install Policy on the cluster

Primary source: R81 — Installing the Access Control Policy and R81.20 — Installing the Threat Prevention Policy. The toast is not fw stat.

1. Publish the session

   Official first step: Global Toolbar → Menu → Publish session. Unpublished edits are not on any gateway. If verification fails on zone or topology objects, fix that before you force install.

2. Verify Access Control (optional but cheap)

   Official: Menu → Verify Access Control Policy → select the package → Verify. Alternate: Security Policies → Access Control → Actions → Verify Access Policy.

3. Install Policy on the right target

   Menu → Install Policy. The Install Policy window lists Security Gateways. If more than one package exists, pick it from the Policy drop-down. Select Access Control. Select Threat Prevention if TP changed. Select CP-LAB-CL-01 (the cluster), not a single member unless that is the design. Official cluster note: if you choose the cluster-safe mode, the SMS makes sure it can install on all members before it begins; if one member cannot take the package, install fails for all of them.

4. Choose Install Mode on purpose

   Official two modes:

   • Install on each selected gateway independently — one failure does not stop the others. For clusters, the extra checkbox For Gateway Clusters, if installation on a cluster member fails, do not install on that cluster is the safe default.
   • Install on all selected gateways, if it fails do not install on gateways of the same version — all-or-nothing for that version.

   Click Install. Watch the per-member result. One member can fail while a glance at the desktop still looks cheerful.

5. Name ClusterXL mode before you celebrate

   Lab is High Availability (Active Up). Official: in HA only one member is ACTIVE (100% load) and the others are STANDBY (0% load). STANDBY does not forward. Load Sharing (Multicast or Unicast) means every healthy member is ACTIVE. Do not fail over in production to “test the rule” without a change window.

Side C — prove on the ACTIVE member

Primary sources: R81 CLI — fw stat, cpstat, Viewing Cluster State. On the practice dashboard use allowlisted commands. Do not invent show checkpoint user ram@. Do not run unfiltered fw ctl zdebug drop on production.

gaia-lab> show cluster state
# Expert twin:
# cphaprob state

Cluster Mode:   High Availability (Active Up)

ID Unique Address  Assigned Load   State
1 (local)  192.0.2.11  100%   ACTIVE
2          192.0.2.12    0%   STANDBY

gaia-lab> fw stat
HOST     POLICY     DATE
localhost Standard   12Aug2026 22:10:11 : [>eth0] [<eth0] [>eth1] [<eth1]

# Official R81 replacement (same question):
gaia-lab> cpstat -f policy fw
Policy name: Standard
Install time: Wed Aug 12 22:10:11 2026

gaia-lab> fw log -n -c drop | tail
10:42:19 drop  192.0.2.25 -> 198.51.100.80 proto tcp 443
  rule: 0  interface: eth0  reason: Address spoofing
  src: 192.0.2.25  dst: 198.51.100.80

Live UI twin: Logs & Monitor. Filter the user 5-tuple and the install window. Copy action, rule, interface, reason / blade, and the origin gateway into the ticket. That is the close. If origin is the STANDBY member, you asked the wrong box. Field-by-field log reading lives on the evidence desk — this factory only needs you to name the stamp the log points at.

6. Runtime path after install

After Side A/B are live, a browser request is not “SmartConsole looks up Accept and opens SaaS.” It is a short factory line on the ACTIVE member.

Proof · quote the gateway, not the toast

1. Packet arrives on an interface the gateway knows. Map it with Network Management — not with a guess. Lab interfaces are dummy eth0 / eth1 / eth2 / Sync.
2. Anti-spoofing: is this source allowed on this ingress? Official: source IP only, based on topology. No → drop rule 0, reason Address spoofing. Stop. Your new Accept never ran.
3. Access Control evaluates the installed package (fw stat name + date) in order. First match wins. Cleanup denies. No match you expected → quote the hit rule. Do not invent a new Any.
4. NAT applies (Hide / Static / no-NAT). Official Hide: many-to-one using ports 600–1023 and 10,000–60,000, up to 50,000 concurrent translations; connections start from inside. Hide pool full or missing return path → Accept in the log, still no SYN-ACK.
5. Blades inspect if enabled: IPS, Anti-Bot, Anti-Virus, Threat Emulation, Threat Extraction, HTTPS Inspection. Prevent is a designed drop after Accept. Threat Prevention is a dedicated policy you can install without re-pushing Access Control.
6. Connection lands in the connections table. fw tab -t connections -s (limit / peak / used). Table full vs one drop are different incidents.

SecureXL / CoreXL sit under this path. A “fast path” miss is not an excuse to skip the drop reason. Mention acceleration only after you have the 5-tuple and the rule or blade name. fw ctl zdebug drop is a live scalpel — tight filter, short window, lab first. In class we use the dummy fw log -n -c drop | tail.

Three production tickets (same factory, different first stamp)

Scenario 1 — New VLAN dropped as spoofing

Flow: Switch adds 192.0.2.0/24 on the LAN → users source 192.0.2.25 → packet hits eth0/eth1 → topology still lists only 10.10.0.0/16 → drop rule 0 Address spoofing → never reaches the Accept you wrote. Official Anti-Spoofing example is the same shape: a packet with an internal source arriving on the external interface is blocked because the source is spoofed.

gaia-lab> fw log -n -c drop | tail
10:42:19 drop  192.0.2.25 -> 198.51.100.80 proto tcp 443
  rule: 0  interface: eth0  reason: Address spoofing
  src: 192.0.2.25  dst: 198.51.100.80

Trap: Any-Any at the top. Anti-spoofing already dropped the packet. The new rule never sees it. NAT cannot save it — official order is anti-spoof first.

Close: Gateways & Servers → Network Management → Get Interfaces / Topology → Modify. Put 192.0.2.0/24 behind the real ingress. Prevent + Log. Publish. Install Access Control. Quote a new log without rule 0. Weak interview: “I added an allow.” Strong: “Rule 0 Address spoofing is topology. I fixed Leads To, then fw stat.”

Scenario 2 — Cluster green, you are on standby

Flow: Failover drill or VIP moved → ClusterXL still High Availability (Active Up) green → you SSH 192.0.2.12 → connections look empty → two apps “fail” on the member that is not forwarding. Official: STANDBY waits for ACTIVE to fail; it does not forward packets. Assigned Load 0% is the tell.

gaia-lab> cphaprob state
Cluster Mode:   High Availability (Active Up)
ID Unique Address  Assigned Load   State
1 (local)  192.0.2.11  100%   ACTIVE
2          192.0.2.12    0%   STANDBY

If you ran fw tab -t connections -s on STANDBY, used can be near empty even while ACTIVE is busy. Official states you will also meet: ACTIVE(!) (problem, but still forwarding because it is the only member), DOWN (a Critical Device reports problem), READY, INIT. Do not treat ACTIVE(!) as healthy HA.

Trap: “Cluster is down.” Or forcing a failover without a window. Or adding Any-Any because the STANDBY has no logs for the user.

Close: Name who is ACTIVE. Retest the same HTTPS flow on that member. Quote cpstat -f policy fw on that member. Weak: “ClusterXL is broken.” Strong: “STANDBY does not forward. I moved to 192.0.2.11.”

Scenario 3 — SMS says installed, gateway disagrees

Flow: Change window. SmartConsole toast. Users still hit yesterday’s cleanup. One member in the group never took the package. Official Install Policy: you can install independently, or all-or-nothing; a cluster-safe mode fails the whole cluster if one member cannot take the package. A glance at the toast is not that per-member result.

gaia-lab> fw stat
HOST     POLICY     DATE
localhost Standard   12Aug2026 22:10:11

gaia-lab> cpstat -f policy fw
Policy name: Standard
Install time: Wed Aug 12 22:10:11 2026

gaia-lab> cpwd_admin list
APP        PID    STAT  START
FWM        1204   E     12Aug
FWD        1210   E     12Aug
CPD        1188   E     12Aug

Policy name + install time is the first Check Point evidence sentence. If FWD is not E, install can stick. Knowledge: fw stat is the gateway’s view, not the SMS view. Official R81: prefer cpstat -f policy fw; fw stat remains the interview line because every L2 still types it.

Trap: Close the change from the toast. Or reboot both members “to pick up policy.”

Close: Quote gateway install time on each member. Reinstall on the member that lagged, or fix FWD. Weak: “SMS said success.” Strong: “Member 2 still shows yesterday. I reinstalled Access Control on the cluster.”

Bonus — Accept, then the blade or the hide pool

Flow: Access rule Accept, Track Log. User still fails. Either Threat Prevention Prevents a protection, or Hide NAT ran out of ports so the SYN never gets a SYN-ACK. Official Hide: 50,000 concurrent translations; ports from two ranges. Official TP: IPS / Anti-Bot / Anti-Virus / Threat Emulation / Threat Extraction live in a dedicated policy.

Trap: “They have an Accept, so the firewall cannot be the cause.” Accept is permission to inspect and to translate — not a promise of delivery.

Close: Name the blade and protection, or the NAT rule and pool. Do not add a second Accept. Weak: “Disable IPS.” Strong: “Quote the protection, owner, and a scoped exception — or Detect in a window.”

7. Traps, proof, interview close

Related: Check Point evidence desk · ClusterXL deep dive · NAT deep dive · Policy layers · Threat Prevention · Check Point hub

Sources

• R81 Quantum Security Management — Manually Updating the Gateway Topology — Gateways & Servers → Network Management → Get Interfaces With / Without Topology; then Install the Access Control Policy
• R81 Quantum Security Management — Preventing IP Spoofing — General → Topology → Modify; Leads To; Perform Anti-Spoofing based on interface topology; Prevent / Detect; Spoof Tracking Log; configure every interface
• R81 Quantum Security Management — NAT and Anti-Spoofing — NAT is performed after Anti-Spoofing; anti-spoof checks source IP only
• R81 Quantum Security Management — Installing the Access Control Policy — Menu → Publish session → Verify → Install Policy; Access Control checkbox; two Install Modes; cluster-safe failure behavior
• R81.20 Security Management — Installing the Threat Prevention Policy — IPS / Anti-Bot / Anti-Virus / Threat Emulation / Threat Extraction; install TP separately
• R81 Quantum Security Management — Configuring the NAT Policy — Automatic vs Manual; Hide behind gateway / Hide behind IP / Static; sequential No. column; Hide port ranges and 50,000 translations
• R81 Quantum Security Management — The Columns of the Access Control Rule Base — No, Hits, Name, Source, Destination, VPN, Services & Applications, Action (Accept / Drop / Reject), Track (None / Log / Accounting), Install On
• R81 CLI — fw stat — policy name, last install date, protected interfaces; official note to use cpstat -f policy fw
• R81 CLI — cpstat — cpstat -f policy fw Policy name and Install time
• R81 CLI — Viewing Cluster State — cphaprob state / show cluster state; HA Active Up vs Load Sharing; ACTIVE / STANDBY / DOWN / ACTIVE(!)
• sk21181 — Address spoofing drop log — official SK for anti-spoof drop messages
• R81 Logging and Monitoring Administration Guide — Logs & Monitor tracking options

Related: Check Point evidence desk · Check Point practice dashboard · Run dummy lab · ClusterXL deep dive · NAT deep dive · Logging & troubleshooting · Policy layers · Threat Prevention