Prove Check Point is working — first tool + proof field

1. Why “is it working?” is five questions

Operators collapse five failures into one sentence. The gateway never took tonight’s package. Policy dropped the 5-tuple. The kernel dropped it before a log row existed. You SSHed the STANDBY member. SmartConsole is pointed at the SMS while the gateways send logs to a dedicated Log Server. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught the five stamps (topology, installed policy, access rule, NAT, blade). Here you learn the five tools you actually open, in order, when someone asks you to prove Check Point is working.

Hero · five tiles, one ticket

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you ship Any-Any at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open the Access Control editor until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to SmartConsole. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the gateway (CLI). Side B proves the log row in SmartConsole / SmartView. Side C is the paste that closes the ticket. On a messy Sev-2, do them in this order until a field lights up.

Side A — CLI on the gateway

1. Name who is ACTIVE before you trust any other command

   Expert: cphaprob state. Clish: show cluster state. Official ClusterXL / CLI Reference: in High Availability (Active Up), only one member must be ACTIVE; the peer is STANDBY and does not forward. ACTIVE(!) still forwards but a Critical Device is in problem. Quote State and Cluster Mode. If you are on STANDBY, move. Do not debug an empty connections table on the wrong box.

2. Prove what this box installed

   On that ACTIVE member: fw stat. Official output headers are HOST, POLICY, DATE. R81 CLI Reference: name of the installed policy, date of the last policy installation, and the interfaces the policy protects ([>eth0] inbound, [<eth0] outbound). The same guide marks fw stat as kept for compatibility and points you at cpstat -f policy fw — quote Policy name and Install time from that flavor if your runbook prefers it. Either pair is the install proof. The SMS toast is not.

3. Read the log file on the box that generated it

   fw log -n -l -c drop (and -h <Origin> if you already know the object). Official fw log fields include Action, Origin, IfDir, InterfaceName, src, dst, proto, rule_name / rule_uid, layer_name. -n skips DNS (default, and faster). -c drop is the documented action filter; the command still always prints Control (ctl) lines. Alert: spoof is a documented alert type — that is topology, not a missing Accept.

4. If there is still no row, take a short zdebug

   sk167457 (R81.20, R82): fw ctl zdebug drop views drops on the Security Gateway. It is a live kernel debug — reproduce the 5-tuple, quote the drop reason (and Interface / TCP flags on that line), then stop it (Ctrl+C). Do not leave it running. Do not start here if Logs already named a Rule.

Side B — SmartConsole Logs (and SmartView)

1. Open the Logs tab, not the Access editor

   R81.20: left pane Logs & Monitor → Logs. R82: Logs & Events → Logs (or Queries). Official search: click Enter Search Query (Ctrl+F) in the query search bar. Time Period first — match the ticket’s UTC window.

2. Filter with documented fields

   Working with Logs (rule-log pane) lists Source, Destination, Blade, Action, Service, Port, Source Port, Rule, Origin, User. Searching the Logs (R82) documents the Action filter values: Accept (Access Control allowed), Drop (Access Control blocked, no notify), Reject (TCP RST to the source), Block (URL Filtering / Application Control), Prevent (DLP or Threat Prevention), Detect, Encrypt / Decrypt. Example query: action:Drop origin:CP-LAB-01 src:192.0.2.25.

3. Read Action, then Rule, then Origin

   Open the row. Quote Action, Rule (name and/or number / Rule UID), Origin (the gateway object). Add Interface / CLI InterfaceName and, for TCP, the flags you see on the details pane (a Reject officially notifies with TCP RST). If Origin is the STANDBY member, you asked the wrong box.

4. If the SMS Logs tab is empty, change store — not policy

   Understanding Logging: gateways send logs to the Management Server by default, or to a dedicated Log Server, or keep them local. To see logs from all Log Servers, connect SmartConsole to the Management Server and stay in the Logs tab. SmartView Web Application is the same real-time view in a browser: https://<Server IP>/smartview/ where Server IP is the SMS or the SmartEvent / Log Server that actually indexed the files. The Install Policy toast never wrote a log row.

Side C — what you paste to close the ticket

One paragraph. Named fields. UTC. No toast screenshot.

UTC window:     01:35–01:45
Member:         cphaprob State = ACTIVE on CP-LAB-01 (192.0.2.11)
Install:        fw stat POLICY=Standard DATE=16Aug2026 01:18:04
Log row:        Action=Drop  Rule=Cleanup  Origin=CP-LAB-01
                Interface=eth1  src=192.0.2.25 dst=198.51.100.80 proto=tcp
If no row:      fw ctl zdebug drop reason = <quoted kernel line>  (stopped)
Store:          SmartView on Log Server 203.0.113.20 — not the SMS toast
Next:           change-control on THAT rule / topology / member — or close as not-the-firewall

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only (RFC 5737 / 192.0.2.0/24).

Journey · one amber hop is the ticket

CEVD-01 — Prove the install (fw stat)

01:42 · P2. Change window ended at 01:18. SmartConsole showed Policy installed successfully. Finance still hits yesterday’s cleanup. L1 already drafted Any-Any.

First tool: SSH the ACTIVE member (prove that with cphaprob state if you are not sure), then fw stat.

If DATE is old: quote POLICY + DATE. The toast published a recipe. This box did not take it. Next is per-member install result / FWD — not a new Access rule.

If DATE matches 01:18: the package is live. Now you are allowed to open Logs for the 5-tuple. fw stat is not Action.

CEVD-02 — Prove the transaction (Logs)

02:05 · P2. Outlook-adjacent SaaS (lab dest 198.51.100.80) fails from 192.0.2.25 after last night’s cleanup tidy. Someone wants “another Accept for Any.”

First tool: Logs & Events → Logs (R82) or Logs & Monitor → Logs (R81.20). Query src:192.0.2.25 dst:198.51.100.80 in the last hour. CLI twin: fw log -n -l -c drop.

Proof field: Action = Drop, Rule = Cleanup (or the named rule that actually hit), Origin = CP-LAB-01. That name is the ticket. Change that one rule — or the object it missed — Publish, Install, then re-read the same three columns. If Action is Prevent, you are in Threat Prevention, not Access. If Action is Reject, the source got a TCP RST — quote that; do not call it “the app is down.”

CEVD-03 — Prove the silent drop (zdebug)

02:20 · P1. Same 5-tuple. Logs query is empty. The hit rule’s Track column is None, or Anti-Spoofing / an implied path never wrote a row the indexer sees. L1 wants Any-Any “so we get a log.”

First tool: on ACTIVE, fw ctl zdebug drop (sk167457). Reproduce once. Quote the drop reason. Stop the debug.

Proof field: the kernel reason — Address spoofing (topology; factory stamp 1), out-of-state TCP (flags on the line), SecureXL / chain drop, or the implied/rule path. Official Anti-Spoofing: a packet whose source does not belong behind that interface is blocked; configure it under Gateways & Servers → gateway → Network Management → interface Topology / Perform Anti-Spoofing based on interface topology. That is not a missing Accept at the top of Standard.

CEVD-04 — Prove the member (cphaprob)

02:40 · P2. Cluster object in SmartConsole looks fine. You SSHed 192.0.2.12 because it answered first. Connections look empty. Two apps “fail.” L1 wants cphastop.

First tool: cphaprob state / show cluster state.

Proof field: State. Lab: 192.0.2.11 ACTIVE 100% load, 192.0.2.12 STANDBY 0% load, Cluster Mode High Availability (Active Up). Official table: STANDBY waits for the Active member to fail before it forwards. Empty logs / empty fw tab -t connections on STANDBY are expected. Retest the 5-tuple on ACTIVE. DOWN means a Critical Device reports problem — that is a different ticket than “add a rule.”

CEVD-05 — Prove the store (SmartView / Log Server)

03:00 · P3. Helpdesk connected SmartConsole to the SMS, opened Logs, saw nothing, typed “Check Point is down.” The toast from 01:18 is still in the screenshot pack.

First tool: confirm where the gateway sends logs (Understanding Logging: Management Server, dedicated Log Server, or local). Then open https://203.0.113.20/smartview/ (lab Log Server) or stay in the SMS Logs tab only after you know that tab queries every Log Server.

Proof field: the same Action + Rule + Origin row, now visible on the server that indexed it. Official note: SmartView and SmartConsole Default Time Frames are not synchronized — do not export “last 15 minutes” from one and argue with “last 7 days” from the other.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• R81 CLI Reference Guide — fw stat (POLICY, DATE; compatibility note → cpstat -f policy fw)
• R81 CLI Reference Guide — cpstat (fw flavor policy; Policy name / Install time)
• CLI Reference Guide — fw log (Action, Origin, InterfaceName, IfDir, -c drop, -h <Origin>, Alert: spoof)
• R81 CLI Reference Guide — Viewing Cluster State (cphaprob state / show cluster state; State values)
• R81.20 ClusterXL Administration Guide — Viewing Cluster Interfaces
• sk167457 — How to use the fw ctl zdebug command to view drops on the Security Gateway (R81.20, R82)
• R81 Logging and Monitoring — Working with Logs (Logs & Monitor → Logs; Action, Rule, Origin filters)
• R81 Logging and Monitoring — Understanding Logging (Management Server vs dedicated Log Server vs local)
• R82 Logging and Monitoring — Logging and Monitoring Clients (Logs & Events; SmartView https://<Server IP>/smartview/)
• R82 Logging and Monitoring — Searching the Logs (Action values: Accept, Drop, Reject, Block, Prevent, Detect)
• R82 Logging and Monitoring — The Logs View (query bar, Time Period; SMS vs dedicated Log Server indexing note)
• R81 Security Management — Preventing IP Spoofing (Gateways & Servers → Network Management → Topology / Anti-Spoofing)
• sk125152 — Cluster member state-change event codes (referenced from Viewing Cluster State)

Related: Blog 1 · Check Point session factory · Logging & troubleshooting deep dive · ClusterXL deep dive · Troubleshooting command center · Check Point practice dashboard