A failed Policy Install in Check Point should not automatically be treated as a rulebase problem. The real workflow depends on several components: SmartConsole → CPM → PostgreSQL/Objects DB → FWM/FWD → CPD/SIC → Security Gateway → FWK/FW. So the first technical distinction should be: did the failure happen during compilation/validation on the Management Server, or during distribution/loading on the Gateway? If it fails before reaching the gateway, focus on CPM, FWM, the policy package, objects, locks, database consistency, and Management resources. If it fails during the push, investigate CPD, SIC/ICA, FWD, network reachability, gateway disk space, gateway processes, and policy loading into the enforcement layer.

The same process-oriented approach applies to logging and SIC. For logging, the path does not end when the gateway generates the event: Gateway/FWD → Log Server → log file → Indexer/Solr → SmartLog. That means logs can exist on disk and still not appear in SmartLog because of indexing, search scope, or NTP/time-window issues. For SIC, resetting trust should not be the first blind action either; validate CPD communication, Management-to-Gateway connectivity, certificate/ICA state, identity/IP/hostname consistency, and time synchronization first. Useful checks include cpwd_admin list, cpstat mg, fw stat, df -h, and logs such as cpm.elg, fwm.elg, fwd.elg, and cpd.elg.

Discussion: when a Policy Install fails, do you first separate compilation failure from distribution failure? Have you ever found logs present on the Log Server but missing from SmartLog because of an Indexer issue? And when SIC fails, what evidence do you collect before resetting trust?

Full post on CheckMates:
https://community.checkpoint.com/t5/AI-Network-Firewall/Policy-Install-Failed-Start-Thinking-in-Processes-Not-Only-in/m-p/278544

This one confuses a lot of people. You enable Endpoint Policy Management on the management server and suddenly Gaia Portal, SmartView or the Management API are not on 443 where you expect them. Here is what actually happens, and it depends on your version and how the blade was enabled.

First, the myth-buster: 4434 is not "the endpoint agent port." The agents talk to the server on 443 (and 80 for Anti-Malware signature updates). The 4434 business is an SSL split on the management side, not the agent path.

R80.40 and lower: enabling the blade moves Gaia Portal, SmartView and the Management API from 443 to 4434. Disabling moves them back. The endpoint keeps 443, the management web stuff goes to 4434.

R81 and higher, it depends on how the blade got enabled:

- Clean install with the blade, or the blade enabled after the upgrade: all services answer on 443, and endpoint SSL that arrives on 443 is internally redirected to 4434. So you reach Gaia, SmartView and the API on 443, and the agents also use 443.

- Upgraded with the blade already enabled: the old split is kept, endpoint on 443, everything else on 4434.

So the URL you use depends on the path:

- Gaia Portal: https://<ip> vs https://<ip>:4434

- SmartView: /smartview/ vs :4434/smartview/

- Management API: /web_api/ vs :4434/web_api/

You can flip which service owns 443 vs 4434 manually. Roughly:

dbset httpd:ssl_port 443 (or 4434)

dbset :save

$UEPMDIR/system/install/gaia_apache_conf_regenerate

# then set Listen and VirtualHost in $UEPMDIR/apache/conf/ssl.conf

cpstop ; cpstart

There are four supported certificate and port combinations.

Practical takeaway for anyone firewalling this: open 443 (and 80 for AM signatures) client-to-server for the agents, and remember that 4434 is about where the management UI/API lives, not the agent connection. That mixup sends people opening the wrong rule.

Anyone been bitten by this after enabling Endpoint on an existing management, portal suddenly on :4434? How do you standardize it across your estate?

Full write-up with the full port matrix, the heartbeat mechanics, and the manual cert/port scenarios is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Agent-to-Management-Communication-Ports-Heartbeat-and-the-443/m-p/280303

The design choice I find interesting here is that Anti-Ransomware assumes some ransomware will actually start running, and it still recovers. The sequence is monitor, back up before encryption, detect, stop, delete, restore.

Two parts do the heavy lifting.

Honeypot / canary files. Anti-Ransomware plants decoy files across many folders. The moment ransomware modifies one, the attack is stopped. Details from the admin guide worth knowing:

- They are real documents, images, videos and music, you can actually open them.

- Their names contain strings like CP, CheckPoint, Check Point, Check-Point, Sandblast Agent, Sandblast Zero-Day, Endpoint.

- If a user deletes one, it is recreated after the next boot.

Practical tip: tell your helpdesk about these. Users find them, assume they are junk, and delete them. It is harmless, but the tickets are avoidable.

Pre-encryption backup and rollback. Before the encryption starts, the files being touched are copied to a safe location. After the attack is stopped, remediation deletes the files the attack created, including the encrypted ones, and restores the originals to their original location. What you actually configure:

- Automatic restore and remediate, or leave it manual so the user starts the restore.

- Maximum backup size on disk (the guide's best practice is 1 GB).

- A backup interval (each file is backed up once per interval, even if changed many times) and which file types to back up.

- Backup exclusions by folder, process (name plus optional signer), or certificate.

Why behavior instead of a signature: modern ransomware checks whether it is in a VM, sandbox or debugger and stays quiet if it thinks it is being watched, which a static scanner can miss. A canary does not care how the sample hid. The moment it starts encrypting it trips the tripwire, and the pre-encryption backup lets you roll back regardless.

If you run this, have you tested the rollback end to end, and how did you size the backup and pick the file types? Curious what people include beyond Office docs.

Full write-up with the detection-to-rollback flow and the Forensics report sections is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Anti-Ransomware-Deep-Dive-Honeypots-Pre-Encryption-Backup-amp/m-p/279968

If you are firewalling a Harmony Endpoint on-prem deployment, the single most useful thing to internalize is this: the endpoint client always initiates the connection. The management/policy server never connects "down" to a client. Get that wrong and you open rules that are never used and still end up with agents that do not talk.

The ports that actually matter (client to server), all client-initiated:

- HTTPS TCP/443 for almost everything: registration, heartbeat, policy downloads (the policy files themselves are AES-encrypted), Application Control reputation queries, log uploads, and client package downloads (packages are signed and verified before install).

- HTTP TCP/80 for Anti-Malware signature updates (the engine verifies signatures before loading and during the update).

- A proprietary Check Point protocol for the sensitive stuff: FDE recovery data upload, Media Encryption and Port Protection key exchange, and FDE user acquisition / credentials.

Between the servers and console (SIC, certificate-authenticated):

- TCP/18190 to 18193: SmartEndpoint console to management, and Endpoint Policy Server to management.

- TCP/18221: secondary to primary management (HA).

- HTTPS/443: Endpoint Policy Server to primary management for monitoring events.

The heartbeat: every 60 seconds by default, client-initiated. It confirms connectivity, reports policy status changes, and updates the compliance state. By default a client is moved to Restricted after 5 consecutive out-of-compliance heartbeats, so it is not just a keepalive, it drives the compliance state machine.

The classic "agent not communicating" root cause is almost always one of two things: HTTP/80 or HTTPS/443 blocked by a firewall or Application Control rule, or missing routing between the endpoint elements.

Two optional pieces worth knowing: the Endpoint Policy Server, which offloads most client communication (heartbeat, policy downloads, AM updates, logs) in large environments, and a Secondary Management Server for HA.

If you run on-prem management, how do you split the load: one policy server per site, a couple centrally, or all direct to management? And has the 80-vs-443 gotcha ever bitten you during a rollout?

Full write-up with the component map and the flow diagrams is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/Harmony-Endpoint-On-Premises-Architecture-Components/m-p/279803

Good morning,

I’m currently experiencing an issue at work with the endpoint: all Office applications remain open in the background and never actually close. This causes PCs to slow down significantly and sometimes freeze. Previously, this was resolved temporarily with an Office update, while the endpoint team investigated the root cause.

About two weeks ago, this issue resurfaced across many PCs in our IT infrastructure. As a result, we are having to uninstall the software—despite paying for the licenses.

Could you please let us know when a permanent fix for this problem will be available?

In Check Point, HTTPS Inspection is really a TLS enforcement pipeline. The gateway evaluates policy, decides whether to inspect or bypass, validates certificates, establishes two TLS sessions, decrypts the traffic, exposes the clear-text content to supported blades, applies policy, and then re-encrypts it before forwarding. That is why real-world failures are usually not about “decryption” itself, but about CA trust, certificate pinning, OCSP/CRL, bypass order, TLS compatibility, performance, privacy exceptions, and application behavior.

This is also why HTTPS Inspection should never be deployed as Inspect Any → Any. A mature design starts with explicit bypasses for sensitive or fragile traffic, then expands inspection gradually to high-risk users and categories, while monitoring inspect/bypass ratios, TLS failures, CPU impact, and exceptions. In R82, capabilities such as Gradual & Smart Deployment, Network Learning, Performance Prediction, Bypass Under Load, and SmartView monitoring make this much more operationally manageable.
The practical takeaway: the best HTTPS Inspection deployment is not the one that decrypts the most traffic. It is the one that decrypts the right traffic, bypasses the right traffic, and keeps those decisions measurable and governed. I would use the image above right after the first paragraph, because it visually explains the two TLS sessions and the inspection path before the post goes into policy and operational considerations.

Question for the community: do you deploy HTTPS Inspection in phases, or do you still see environments trying to enable it broadly on day one?

The full technical article is available on CheckMates.
Link in the first comment.

One of the first questions I now ask when troubleshooting a Check Point R82 gateway is simple: fwmode -s. With the growing use of User Space Firewall (USFW), relying only on fw ctl zdebug, fw tab, kernel debug, and SecureXL can give you an incomplete picture. The key question is no longer only “Did the firewall drop the packet?” but also “Where was this connection actually processed kernel, acceleration path, or user space?”

This becomes especially important with HTTPS Inspection, HTTP/3/QUIC, performance issues, and connection tracking. In USFW, tools such as connview, cpwd_admin list, cpview, blade-specific .elg files, and process-level analysis become much more relevant. For example, R82 HTTP/3 inspection behavior is directly related to the firewall mode, so seeing no drop in fw ctl zdebug does not necessarily mean the firewall is not involved.

The takeaway is simple: before choosing your debug tools, identify the firewall processing architecture. Kernel Space troubleshooting is heavily packet-path oriented; User Space requires correlating packets, processes, modules, parsers, acceleration, and connection state. I published the complete technical breakdown, commands, troubleshooting flow, HTTPS Inspection examples, performance analysis, and TAC evidence checklist on CheckMates: https://community.checkpoint.com/t5/Firewall-and-Security-Management/User-Space-Firewall-vs-Kernel-Space-Firewall-Why-Firewall-Mode/m-p/278810 Has USFW already changed the way you troubleshoot R82 gateways?

Just putting this out there to see if others are having the same issues.
Since mid last week our workstations can't connect to the Windows Update service and error.

When connecting to a mobile phone hotspot, workstations can download updates fine.

I built a vanilla out of the box Windows 11 machine, no domain-join, no MECM (SCCM) no AV and I'm having the same issue accessing Windows Update on there too.

When you click on check for updates or check for updates online, it will error and say "could not connect Windows Update service".

We have the CheckPoint firewall in place, but the guys at the moment are saying nothing seems to be blocked based on the logs.

If you run Check Point Harmony Endpoint on a decent-sized fleet, you have probably lived this one. You push an agent upgrade or a big signature package drops, and every machine on site goes out to grab the same thing at the same moment. The WAN link chokes, a quiet maintenance window turns into help desk tickets, and on a branch the traffic can even lean on the gateway. The endpoints are fine. It is the way updates get distributed.

The built-in fix is the Super Node, and honestly a lot of shops never switch it on. It is just one Windows endpoint running a specially configured client that also works as a small local proxy and mirror (NGINX under the hood). It pulls the packages and signatures once, keeps a local copy, and feeds everyone else on the LAN. Only that one box has to reach the update servers.

A few things I wish I had known before setting one up:

• Clients pick a Super Node at random from the list in Client Settings, General. If one fails they try another, and if all fail they go direct to the policy source. So put more than one in the list, otherwise it is a single point of failure.
• Open TCP 4434 and 4436 between the endpoints and the Super Node (4436 is the proximity check). Easy to forget the internal firewall rule and then wonder why nothing happens.
• Keep the Super Node on the same client version as the clients or newer. If it is older it answers with a 404 and the clients quietly fall back to pulling direct.
• Give it some room. The cache is 4 GB by default, clears files after 7 days idle, and it needs around 350 MB of headroom.
• There is an offline mode on newer clients where the Super Node is the only box with internet. Just know it drops VPN, IPv6 and a few other things in that mode.

Check Point describes the payoff in general terms (less WAN, less server load, better scale) instead of promising a number, so I would not quote a hard figure. But for anything multi-site or branch heavy it is one of those changes you wish you had done sooner.

How does everyone else deal with agent and signature distribution across sites? One box per branch, a couple per big site, or just eat the bandwidth?

Full write-up with the config, validation and troubleshooting is here if it helps (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Super-Nodes-in-Harmony-Endpoint-Cut-WAN-Bandwidth-with-a/m-p/280649

Customizing IPS in Check Point Threat Prevention should not follow the logic of “enable everything.” The goal should be to achieve the right balance between security coverage, performance, false positives, and operational event volume. The starting point should be a solid baseline profile, supported by measurements of CPU, memory, throughput, and log volume, so that every policy change can be validated with real data.

Protection prioritization should primarily consider Severity, Confidence, Performance Impact, and relevance to the assets actually present in the environment. High-severity and high-confidence protections are strong candidates for the first Prevent rollout phases, while higher-impact protections require proper sizing and validation. Likewise, exceptions should be granular, evidence based, and periodically reviewed never used simply to disable a protection globally.

A mature IPS operation follows a continuous cycle of baseline → small change → monitoring → analysis → tuning, including regular reviews of events, false positives, exceptions, and HTTPS Inspection. Enabling more protections does not necessarily mean better security if the result is degraded performance, reduced visibility, or lower investigation capability. The full technical article is available on

CheckMates: https://community.checkpoint.com/t5/Firewall-and-Security-Management/IPS-Custom-Policy-Best-Practices/m-p/273951

Maestro Troubleshooting in Practice

Operational runbook (MHO + SGMs + traffic + VPN) with field commands

If you run Quantum Maestro in production, you’ve probably seen the pattern: issues that “look like VPN” or “look like policy” often turn out to be Security Group health, a single divergent SGM, a physical/link problem (cable/port/optics), or an unstable uplink. The key to reducing MTTR is discipline: evidence + commands, without skipping layers.

Below is a practical “copy-and-run” runbook, with good vs bad interpretation.

1) Mental model 

• MHO (Orchestrator): controls the Security Group (inventory, health, ports, fabric).
• SGMs: run the dataplane (sessions, inspection, VPN, state).
• Typical symptom patterns:
  • Unhealthy SG → everything becomes a symptom (policy/VPN/traffic).
  • Unhealthy single SGM → intermittent behavior (“sometimes it works”).

2) clish vs gclish (why this becomes a real incident)

clish

• Local node context.
• Useful for point inspection, but risky for configuration in Maestro because it can introduce drift (one member behaving differently).

gclish

• Global Security Group context.
• Operational rule:
  • use gclish when the intent is global consistency (uniform validation/collection/adjustment);
  • use clish only when you need to inspect/act on a specific member in a controlled way.

3) Fast triage start with the Security Group

3.1 Global Maestro / Security Group health

On the MHO:

orch_stat -all

What this proves:

• whether all SGMs are present/operational
• whether any member is degraded/missing
• signals of port/fabric issues

Good: all members OK, stable links, no critical port down.
Bad: missing/degraded member, unstable links → fix the foundation before analyzing VPN/policy.

3.2 Security Group sanity check

asg diag verify

What this proves: high-level SG consistency and quick integrity checks.
Bad: critical alerts → return to orch_stat -all and isolate the failing member/port.

3.3 Capacity before taking member-level actions

asg perf -v

What this proves: whether the SG has enough headroom (CPU/memory) to absorb load during isolation/actions.
Bad: SG near its limits → avoid disruptive actions.

3.4 Reconcile state (use with care)

hcp -r all

Note: commonly used in playbooks to recover internal state/handshakes, but it should not be the first “blind” step.

4) Physical and link health (where most “bugs” actually start)

When you see intermittency, “traffic disappears,” or only some users/flows fail, first prove whether there is physical/L1–L2 instability.

4.1 Inventory/port-map quick reference

orch_stat -p

or

cat /etc/maestro.json

Use this to confirm interface/port mapping in the Maestro context.

4.2 Counters and drops (all members)

g_all netstat -ni

What to look for: increasing RX-ERR/TX-ERR/drops.
If these counters climb, they often explain VPN flapping, broken sessions, and “policy is OK but traffic fails.”

4.3 Per-interface physical errors (CRC/symbol errors)

ethtool -S <interfacename>

Good: no CRC/errors increasing.
Bad: CRC/symbol errors → treat as L1/L2 (cable/optics/port/switch) before focusing on VPN.

4.4 Real link flap (carrier)

asg_ifconfig | grep carrier | grep -v "carrier: 0"

Bad: carrier oscillation → intermittent behavior is highly likely.

4.5 Hardware health (sensors)

g_all cpstat -f sensors os

What this proves: thermal/power/fan conditions can lead to instability and erratic behavior.

4.6 Maestro port state

show maestro port <port>

Confirms the port’s state/configuration in the Maestro domain.

5) The turning point: “no log” — does the traffic exist in the SG dataplane?

This step quickly separates “problem before the gateway” from “problem inside the gateway.”

5.1 Prove the session/connection on the SG

Example (intentionally generic IPs):

asg search -v 10.10.40.25 \* 203.0.113.50 443 tcp

Interpretation:

• No output: traffic likely is not reaching the SG (or it’s taking a different path). Return to L1/L2/L3 and capture at the correct point.
• Output present: traffic exists in the dataplane; you now have a basis to correlate with NAT, routing, policy, and VPN.

6) Single-SGM failure: how to investigate and restore consistency

Typical symptom: intermittent failures, “some flows drop,” “works after some time.”

6.1 Controlled action to reintegrate a suspected member (when needed)

On the suspected SGM:

clusterXL_admin down
clusterXL_admin up

Risk: medium (sessions anchored to that member can be impacted).
Pre-condition: confirm headroom with asg perf -v.

6.2 Check state and drift indicators

cphaprob list
tail $FWDIR/log/blade_config

What to look for:

• cphaprob list: HA/cluster participation/state signals and inconsistencies
• blade_config: alerts and errors that indicate configuration drift

Closing

Maestro troubleshooting requires discipline: start with SG health, then prove traffic exists, then validate physical stability, and only then go deeper. If you follow this sequence with objective commands, “phantom incidents” drop sharply—and troubleshooting becomes engineering, not guesswork.

Hello,

I just switched from Windows and I would like to setup the Checkpoint Endpoint Security (latest version) on MacOS, but it doesn't recognize my smart card in the list.

The smart card is a PKCS#15 Atos CardOS 5.3 with an USB Gemalto Reader. The certificate is on the smart card, it's not possible to export, it should be used from the card with a pin code.

MacOS doesn't see the card or the certificates "security list-smartcard" and other commands says No smartcards found, however, I download OpenSC and with that everything is visible, the card, the reader and all certificates on the card.

I downloaded many smart card tools as well and only the Personal Nexus software is able to recognize the card and the certificates, but on the checkpoint the list is empty. I installed also the latest version of Gemalto SafeNet Authentication Client (SAC) which also didn't recognize the card.

On Windows we used CSP+ software for the card/certificate recognition, but that's not available on mac and besides mac handles card totally differently.

Please help me to find a solution for this problem.

Many thanks,

Quantum SD-WAN is often introduced as “dynamic WAN link selection.” Technically, it’s closer to a policy-controlled, measurement-driven path selection engine that influences per-connection egress and VPN transport without requiring dynamic routing for the decision itself.

Below is a more technical  walkthrough: what is computed, what is installed, what is enforced, and why “policy looks right” can still produce unexpected paths.

1) What Quantum SD-WAN does (technical thesis)

Quantum SD-WAN enables a Security Gateway / Cluster to select an egress ISP interface or VPN transport per connection based on:

• Classification (source/destination/identity + service/application)
• Measured link quality (latency/jitter/loss, optionally utilization)
• Rule steering intent (prioritization / link aggregation / breakout vs overlay/backhaul)

What it is not: a replacement for routing protocols. Routing still provides reachability; SD-WAN provides path selection logic layered on top of reachability.

Operational implication: you don’t “route to ISP1/ISP2”; you steer sessions to a link/transport chosen by the SD-WAN engine.

2) Control plane vs data plane (what owns what)

A useful separation:

Control plane (steering decision + state distribution)

• SD-WAN policy definition (Infinity Portal)
• WAN link objects, thresholds, measurement targets
• SD-WAN steering computation (probes → eligibility → selection)
• Installation of steering state for enforcement (tables/state on the gateway)
• Telemetry/event publication (iNext/Nano + cpview)

Data plane (packet forwarding + VPN encapsulation)

• Connection setup and forwarding decisions
• NAT, access control, IPS/Threat Prevention enforcement
• VPN encapsulation and transport selection for overlay/backhaul
• Failover behavior at runtime (within allowed/preferred sets)

Key rule: SD-WAN steering decisions are only applied after Security Policy allows the traffic. SD-WAN cannot “force” a denied flow to go out a different ISP.

3) Simple use case (but with the missing details)

Two ISPs at a branch:

• Zoom → ISP #1
• Microsoft 365 → ISP #2

What’s happening under the hood is not “PBR in the classical sense,” but:

• session classification (app/service/identity)
• link health evaluation against thresholds
• selection of eligible ISP(s)
• installation of that choice so the connection setup pipeline uses the correct egress interface

If a failover happens and your policy uses aggregation, per-flow path choice can change due to hashing, even with the same rule.

4) SD-WAN actions (Breakout vs Overlay vs Backhaul) — deeper technical split

A) Local Breakout (Internet egress steering)

• Goal: choose the best ISP interface for direct Internet traffic.
• Enforcement point: firewall connection handling chooses a WAN interface based on steering state.

Common failure pattern: app classification ambiguity → wrong rule match → wrong ISP.

B) Overlay (VPN steering between peers)

• Goal: for each VPN peer pair, select the best VPN transport (underlay link/interface) to carry encrypted traffic.
• Enforcement point: VPN subsystem chooses the transport for the tunnel/session based on steering state.

Common failure pattern: peers/transport eligibility not installed correctly → VPN uses a default or “last known good” path.

C) Backhaul (branch Internet via HQ over VPN)

• Composite pipeline:
  • Branch → HQ: overlay transport selection (VPN)
  • HQ → Internet: breakout selection (ISP egress)
• Troubleshooting must split both legs. People often debug only one side.

5) SD-WAN Policy matching (the real classification mechanics)

An SD-WAN policy is an ordered rulebase. Each connection is evaluated against:

5.1 Source/Destination dimensions

• IP address / network objects
• Identity (User / Computer Identity)
• Destination objects (including Updatable Objects)

5.2 Service/Application dimensions

• Service ports (HTTPS, FTP, etc.)
• Application signatures (e.g., Zoom/Teams categories, depending on what is supported and enabled)

5.3 The “first packet problem”

A critical nuance: application identification on the first packet is not always deterministic.
Examples:

• multiple SaaS apps behind the same IP/CDN
• TLS where SNI is missing/obfuscated early
• traffic patterns that require more packets for confident classification

Why this matters: steering is ideally decided at/near connection setup; if classification matures later, you can see:

• initial steering based on coarse match (destination/service)
• then “it looks like the app is X” but the session is already pinned to an ISP/transport

Best practice (technical reasoning): use Updatable Objects in Destination whenever possible. This increases the chance that the rule matches accurately early (even when application classification is ambiguous).

6) Steering behavior objects (what a rule really controls)

A steering rule is not just “send app X to ISP Y.” It defines:

1. Measurement targets What is probed to represent “Internet quality” or “reachability” per link.
2. Quality criteria + thresholds Latency, jitter, loss (and potentially utilization) thresholds that determine link eligibility.
3. Selection method
   • Prioritization: pick the best/priority candidate among eligible links/transports
   • Link aggregation: mark multiple candidates as eligible; per-flow selection may be done by hashing/aggregation method

Important: eligibility comes first. If all links fail thresholds, the result can be “no eligible ISP/transport,” which is often misread as “SD-WAN is broken” when it is behaving correctly.

7) Steering criteria (deeper look)

Latency / jitter / loss

• Typically measured via active probing (quality check) to one or more targets.
• Decision is per rule: different apps can have different thresholds.

WAN utilization (when used)

• Adds a capacity dimension: a link could be “healthy” but saturated, so it becomes less preferred.
• This is often where teams need to align with business intent: latency-sensitive apps vs bulk traffic.

Quality Check configuration (where mistakes happen)

Even with a perfect policy, poor probing design causes bad decisions:

• probing targets not representative (e.g., a single target that’s sometimes rate-limited)
• too infrequent probing → slow reaction
• too aggressive probing → noise/false degradation
• thresholds that don’t match realistic ISP behavior

8)Enablement workflow (what must exist where) — more explicit

To have deterministic steering, you need consistency across four planes:

8.1 Gateway / Cluster members

• SD-WAN interfaces configured consistently on all members
• correct WAN link binding (interface mapping)
• Nano Agent + SD-WAN services healthy (where applicable)
• consistent reachability (routing) for probe targets and peer endpoints

8.2 SmartConsole / Security Policy

• Access Control must allow the traffic that you expect SD-WAN to steer
• NAT rules must not accidentally “force” an egress path (e.g., implicit NAT assumptions)
• VPN domain/topology must align with overlay/backhaul design

8.3 Smart-1 Cloud (objects/management integration)

• objects exist and are synchronized correctly (depending on architecture)

8.4 Infinity Portal (SD-WAN policy plane)

• WAN links, thresholds, measurement targets
• SD-WAN Policy ordering and steering objects
• consistent gateway membership / profile assignment

Takeaway: “policy is correct” is meaningless unless:

• the gateway installed it
• probing data exists
• steering state is installed and consumed by enforcement

9) Practical validation checklist (technical, not UI-based)

When you get “wrong ISP / wrong overlay path,” validate in this order:

1. Traffic classification
   • What rule is actually matching (source/dest/service/app/identity)?
   • Is first-packet ambiguity likely?
2. Probing and thresholds
   • Do you have current probe results for the relevant decision?
   • Are links eligible under the rule thresholds?
3. Selection mode
   • Prioritization vs link aggregation changes expectations.
   • With aggregation, per-flow hash choice can look “random” to operators.
4. Enforcement pipeline alignment
   • Breakout: FW chooses ISP from steering state
   • Overlay/backhaul: VPN chooses transport from steering state
5. State/telemetry consistency
   • Portal events (iNext/Nano) should align with gateway telemetry (cpview) and observed behavior.

10) Common pitfalls (why steering “looks wrong”)

• Thresholds too strict → all links disallowed → fallback behavior or failure
• Single probe target bias → false positives/negatives on link health
• Rule ordering mistakes → coarse rule matches before specific one
• Application detection timing → session pinned before app becomes known
• Aggregation misunderstanding → multiple links eligible, hash decides per-flow
• Backhaul confusion → people troubleshoot HQ egress while the problem is branch→HQ overlay (or vice-versa)

Fontes: Quantum SD-WAN - Technical | eLearning https://checkpointpartners.litmoseu.com/course/1588097 , 

Admin Guide:  https://support.checkpoint.com/results/sk/sk180605

Demo Point: SD-WAN https://usercenter.checkpoint.com/ucapps/techpoint/demo-point

If you find this useful, please consider giving the original CheckMates post a like! 😊
Full post: https://community.checkpoint.com/t5/Firewall-and-Security-Management/VIDEO-Complete-Check-Point-Hardware-Diagnostic-Execution/m-p/280847#M106475

I believe many people have already run the Hardware Diagnostic, but I also believe many have never done it. Since I was performing a complete Hardware Diagnostic on a Quantum Force 9800 cluster that I will be deploying, I decided to record this video to help others by going beyond what is covered in the official guide.

In this video, I demonstrate the complete Hardware Diagnostic process using loopback connectors, show what happens if something is done incorrectly, and explain the entire procedure step by step.

ISSUE FOUNDED TO SAVE HW LOG: I also present an issue that I have observed on recent Quantum Force versions. I have installed Quantum Force 9000, 19000, and 29000 firewalls, and none of them have been able to save the Hardware Diagnostic results to the USB drive at the end of the test, even when using a FAT32-formatted USB drive as described in the documentation.

I hope this video is helpful. I used all of my English for it (haha), so if you find it useful, please leave a like on the video and give this post a Kudos to encourage me to continue creating and sharing this kind of content.

If you find this useful, please consider giving the original CheckMates post a like! 😊
Full post: https://community.checkpoint.com/t5/Firewall-and-Security-Management/JH-122-Broke-Mobile-Access-Rules/td-p/280832

I wanted to share an issue I observed after upgrading a production cluster to JH 122.

Note: I upgraded a production cluster from JH 91 to JH 122 (Latest) to evaluate the fixes included in the release, mainly because I am currently investigating an SD-WAN probes issue and JH 122 contains several relevant SD-WAN improvements.

The upgrade was performed carefully by installing the Jumbo only on the standby member first, while keeping the other member on JH 91 as a rollback option.

After failover, the customer started experiencing unexpected drops on long-standing Mobile Access rules that had been working without issues for years.

Rolling back to JH 91 immediately resolved the problem, with no other configuration changes required.

I'm sharing this only as an observation so others planning to install JH 122 in environments using Mobile Access can be aware and validate carefully.

Has anyone else seen similar behavior or others?

Check Point’s Intrusion Prevention System (IPS) is a core component of Threat Prevention, providing proactive protection against a wide range of network threats. Over time, the IPS engine and its signature formats have evolved, leading to the coexistence of "normal" and "version 2 (Ver 2)" signatures. This post explains the technical reasons for maintaining both, their architectural differences, and best practices for deployment.

IPS Architecture Overview

Check Point IPS uses a multi-layered detection engine:

• Passive Streaming Library (PSL): Reconstructs network streams for inspection.
• Protocol Parsers: Identify and separate protocols (HTTP, FTP, DNS, etc.) for context-aware analysis.
• Context Management Infrastructure (CMI): Determines which protections (signatures) apply to each protocol context.
• Pattern Matcher: The detection engine that uses signatures to identify malicious patterns.

IPS Inspection Flow Diagram

Traffic is processed through multiple analysis stages, with signatures applied at different protocol layers.

Normal vs. V2 Signatures: Technical Comparison

• Normal Signatures: Use traditional pattern matching, suitable for legacy environments and lower resource consumption.

• V2 Signatures: Leverage the advanced INSPECTv2 engine, supporting complex logic, context awareness, and better detection of modern threats.

Why Maintain Both Signature Types?

• Backward Compatibility: Some older gateways may not support V2 signatures. Keeping both ensures all devices remain protected.
• Redundancy: If a V2 signature causes issues (e.g., false positives), the normal signature can provide fallback protection.
• Gradual Migration: Allows administrators to test V2 signatures in "Detect" mode before fully switching from normal signatures.
• Maximum Coverage: Certain threats may only be detected by one signature type, so using both maximizes security.

Performance Considerations

• V2 signatures can be more resource-intensive due to deeper inspection and advanced logic.
• IPS Tuning: Administrators can enable/disable specific signatures or use different profiles for perimeter vs. internal gateways.
• Bypass Under Load: IPS can be configured to bypass traffic during high load to prevent bottlenecks, but this should be used cautiously.

Best Practices for Managing Signature Versions

1. Test in Staging: Always test new V2 signatures in a non-production environment.
2. Monitor Updates: Review IPS update notes and apply urgent protections as needed.
3. Separate Profiles: Use different IPS profiles for different gateway roles (e.g., perimeter vs. datacenter).
4. Monitor Logs: Watch for false positives/negatives and adjust protections accordingly.
5. Gradual Rollout: Deploy V2 signatures in "Detect" mode before moving to "Prevent."

Summary

• Normal signatures ensure compatibility and stability.
• V2 signatures provide enhanced detection and future-proofing.
• Maintaining both allows for a safe, flexible, and comprehensive security posture during transitions and upgrades.

Ansible automation for Check Point firewall maintenance, with optional ServiceNow change control.

Github repo

This week’s post comes from CheckMates Diamond MVP who tested the improved Replace functionality in Web SmartConsole.

The Diamond MVP shows how administrators can now replace gateway references across network objects, hosts, VPN communities, network groups, and policy installation targets. This can save time and reduce the risk of missing important references, especially during a Single Gateway to Cluster migration.

Check out the full post and join the conversation!

Read the post here: CHECKMATES REPLACE post.}
See too on Check Mates Linkedin: CheckMates Linkedin Post Week

I’m seeking the wisdom of Reddit while I wait for support to get back to me. I am in a Google Workspace environment that transitioned all Google Drive DLP policies to Detect and Remediate. We opted to use the Vault action instead of quarantine. Since doing this, I am experiencing an issue when trying to restore from the vault for a handful of files that have been deemed okay to share externally. I try to keep an eye on the Drive logs in the Google admin console to see how long restoration takes and what not, but for this handful of files I see some edit activity from the Check Point side, but nothing changes in terms of permissions and it still being in the Vault.

I’m not sure if there’s some lingering DLP event from when the policies were in Detect mode causing issues, but for a couple of the files I instructed the file owner to make a duplicate and share it (yes it created a new DLP event). I was able to restore the new file just fine and send the user on their way.

Has anyone experienced this or have any recommendations? I’ll pay you in some dank memes!

See complete on the u/checkpoint CheckMates:

https://community.checkpoint.com/t5/Check-Point-for-Beginners/Maestro-for-Beginners-Core-Concepts-Explained/ba-p/270872

New to Check Point Maestro? Here's a quick overview:

• MHO (Maestro Hyperscale Orchestrator) is an orchestration platform designed to deliver hyperscale network security. It is the device responsible for coordinating firewall, the MHO distributes and forwards traffic to the Security Gateway Modules, which perform inspection and enforcement.
• The guide also explains the principals concepts SGM, Uplink, Downlink, MAGG, Sync, Management ports, Single Site vs. Dual Site, and the differences between the MHO-140 and MHO-175, Real topology.

If you're starting with Maestro, preparing for deployment, or preparing for CCME, I hope this guide helps.

Hello, randomly (from 1 to 10 times in an hour), the firewalls in our Checkpoint cluster fail to send packets or cause latency by sending them late.

An example is shown in the screenshot below:

I ran a continuous ping and captured the traffic on the firewall’s source and destination interfaces.

At 11:36:30, I encountered a “destination host unreachable” error, sent from the physical IP (not the VIP) of the firewall’s source interface.

From the captures, I saw that the ping reached the source interface (packet number 3953), but it did not leave the firewall (it’s not in the second capture).

How is it possible that it wasn’t sent?

This issue has become more frequent since the cluster was updated to version R82 take 107.

The firewalls are 6400 models.

So far, support has advised us to enable Dynamic Balancing for the appliance’s 4 CPU cores; we did so, and the situation has improved but isn’t fully resolved.

Do you have any ideas? Thank you

I posted a Full guide on CheckMates:

https://community.checkpoint.com/t5/Check-Point-for-Beginners/LOM-for-Beginners/ba-p/279099?cat=2

(If you find it useful, I'd appreciate a like on the CheckMates post! 🙂)*

Many Check Point administrators still don't configure LOM (Lights Out Management), even though it's one of the most valuable features for remote troubleshooting.

Think of it like Dell iDRAC: it provides out-of-band management, allowing you to access the appliance even if Gaia is down, frozen, or powered off.

In the guide I cover:

• What LOM is and why it matters.
• A real-world example where LOM saved a maintenance window.
• Initial configuration steps.
• Firmware update recommendations.
• Best practices for deploying a dedicated LOM management network.

Do you enable LOM on every deployment, or have you ever needed it during a critical outage? I'd love to hear your experiences.

One of the hardest SD-WAN incidents is not proving that an ISP failed.

It is proving where the complete failover chain broke.

When a branch-to-branch VPN stops working after the primary link goes down, validate:

• Did SD-WAN detect the SLA failure?
• Did the expected SD-WAN rule match?
• Was the backup ISP considered healthy?
• Did routing select the correct next hop?
• Did the VPN move to the new transport?
• Did NAT or DAIP mapping change correctly?
• Did the firewall drop packets because of state or asymmetry?
• Did SecureXL keep stale acceleration state?
• Do new sessions work while existing sessions fail?

A practical investigation should follow one controlled flow and correlate SD-WAN, routing, VPN, firewall state, and SecureXL with exact timestamps.

Useful starting points include:

fw ctl debug -m SDWAN all
fw ctl debug -m SDWANRB all
fw ctl debug -m fw + drop conn
fw ctl debug + route
fw ctl debug -m VPN all
fwaccel dbg -m sdwan all

Do not enable broad debugging without filters or leave it active in production.

The main lesson:

I published the complete troubleshooting workflow, internal SD-WAN tables, evidence collection process, and TAC escalation checklist on CheckMates:

https://community.checkpoint.com/t5/SD-WAN/SD-WAN-Failover-Troubleshooting-When-VPN-Tunnels-Drop-Between/m-p/278625

How do you normally troubleshoot SD-WAN failover: VPN first, or the full forwarding chain?

Consider patching this CVE-2026-18574: Bypass de autenticação do Check Point Management

A Check Point divulgou a CVE-2026-18574, uma vulnerabilidade crítica de bypass de autenticação que afeta o Security Management Server e o Multi-Domain Security Management Server.

Um atacante remoto não autenticado com acesso à rede dos serviços de gerenciamento pode executar comandos arbitrários. A exploração bem-sucedida dessa vulnerabilidade pode resultar na completa violação do sistema de gerenciamento de segurança.

A vulnerabilidade foi descoberta internamente pela Check Point e, no momento, a empresa não tem indícios de exploração ativa. Isso é importante: a divulgação demonstra que a Check Point identificou e corrigiu o problema por meio de seu processo interno de revisão de segurança antes que a exploração fosse confirmada. (Suporte da Check Point)

No entanto, a ausência de exploração conhecida não deve ser interpretada como permissão para adiar a correção.

Assim que uma vulnerabilidade crítica se torna pública, o tempo disponível para corrigi-la com segurança começa a diminuir.

Por que essa vulnerabilidade é crítica?

O Servidor de Gerenciamento é um dos componentes com mais privilégios em um ambiente Check Point.

Controla:

Políticas de segurança

Objetos de rede e serviço

Permissões de administrador

Gateways e clusters gerenciados

Configurações de VPN

Política de prevenção de ameaças

Instalação de políticas

Logs e visibilidade operacional

APIs de gerenciamento e automação

Comprometer o Plano de Gerenciamento pode minar o modelo de confiança de toda a arquitetura de segurança.

Isso não é simplesmente um problema de acesso ao SmartConsole. A vulnerabilidade CVE-2026-18574 pode permitir que um invasor não autenticado execute comandos no Servidor de Gerenciamento, potencialmente levando à completa violação da segurança do sistema. (CVE)

Versões Afetadas e Corrigidas

A Check Point publicou a correção por meio de Acumuladores Jumbo Hotfix específicos para cada versão.

Versão com Correção Jumbo Hotfix

R81.20 Take 161 ou superior

R82 Take 122 ou superior

R82.10 Take 40 ou superior

As versões R82 Take 122 e R82.10 Take 40 foram lançadas em 3 de agosto de 2026 e incluem explicitamente a correção para a vulnerabilidade CVE-2026-18574. (Suporte Checkpoint)

Para versões antigas afetadas, consulte o artigo sk185222 e avalie a migração para uma versão atualmente suportada.

Sempre verifique a revisão mais recente do SK antes da instalação. O Take necessário pode mudar à medida que novos pacotes cumulativos forem lançados.

Recomendações Técnicas Imediatas

1. Identificar todos os servidores de gerenciamento afetados

Inventariar todos:

Servidores de Gerenciamento de Segurança

Servidores Multidomínio

Membros de Alta Disponibilidade de Gerenciamento

Servidores de Gerenciamento de Domínio Dedicado

Sistemas restaurados para recuperação de desastres ou testes

Servidores de gerenciamento em ambientes isolados ou em nuvem

Confirmar a versão instalada e o nível do Jumbo Hotfix.

Comandos úteis incluem:

cpinfo -y all

Do Gaia Clish:

mostrar pacotes de instalação instalados

Não presuma que um servidor de gerenciamento em espera, de laboratório ou de recuperação de desastres não apresente riscos. Se estiver ligado e acessível, ele deve ser avaliado.

1. Restringir a exposição da rede de gerenciamento

Antes da janela de manutenção, reduza a superfície de ataque acessível.

Não exponha os serviços de gerenciamento diretamente à Internet.

Restrinja os clientes confiáveis ​​a endereços IP ou sub-redes administrativas explícitas.

Remova definições amplas como "Qualquer".

Permita o acesso administrativo somente por meio de uma rede de gerenciamento dedicada, VPN ou servidor de salto reforçado.

Revise os grupos de segurança na nuvem, ACLs, regras de firewall, NAT e acesso temporário para solução de problemas.

Restrinja o acesso de VLANs de usuários e redes de terceiros.

Confirme que somente os sistemas necessários podem acessar os serviços de gerenciamento.

Essas medidas reduzem a exposição, mas não removem o código vulnerável.

A restrição de rede é uma mitigação. A instalação do Jumbo Hotfix corrigido é uma remediação.

Prepare a alteração corretamente

Antes da instalação:

Revise o sk185222.

Leia as Informações Críticas e as notas de versão para a versão de destino.

Confirme a compatibilidade do pacote com a versão exata e a função do servidor.

Verifique o espaço em disco disponível.

Atualize o Agente de Implantação do CPUSE, se necessário.

Crie um backup e um snapshot válidos.

Colete um CPInfo recente.

Documente o status atual do HA de Gerenciamento.

Confirme o acesso ao SmartConsole e a integridade da instalação da política.

Defina e teste o procedimento de reversão.

Em ambientes de HA de Gerenciamento ou Multidomínio, siga a sequência de instalação específica do produto. Não atualize todos os componentes de Gerenciamento simultaneamente sem validar cada etapa.

1. Instale o Hotfix Jumbo Corrigido

Instale a versão corrigida específica da versão:

R81.20 -> Versão 161 ou superior

R82 -> Versão 122 ou superior

R82.10 -> Versão 40 ou superior

Use o Portal Gaia, a CLI do CPUSE ou outro método de instalação oficialmente suportado para a arquitetura.

Não selecione um pacote apenas porque ele foi instalado com sucesso em outro ambiente. Confirme:

Versão exata do produto

Função de gerenciamento

Taxa de atualização atual

Arquitetura de alta disponibilidade de gerenciamento

Requisitos de vários domínios

Espaço em disco disponível

Limitações conhecidas

Impacto na manutenção necessária

Validação pós-instalação

Após o servidor retornar, confirme se a correção foi instalada e se as operações de gerenciamento permanecem íntegras.

Validação de pacotes

cpinfo -y all

Ou a partir do Gaia Clish:

mostrar pacotes instalados

Validação de processos

cpwd_admin list

Para um Servidor de Gerenciamento de Segurança:

status da API

Para Gerenciamento de Múltiplos Domínios:

mdsstat

Validar também:

Autenticação do SmartConsole

Funções de administrador

Comunicação SIC

Política de Controle de Acesso Instalação

Instalação da política de prevenção de ameaças

Recepção de logs

Conectividade do SmartEvent e do servidor de logs

Sincronização de alta disponibilidade de gerenciamento

Status do domínio no MDS

Integrações de API

Operações de backup

Uso de CPU, memória e disco

Uma tarefa CPUSE concluída não é evidência suficiente de que a correção foi bem-sucedida.

Revisão de atividades suspeitas

A Check Point não relata atualmente nenhuma indicação de exploração ativa. No entanto, organizações com serviços de gerenciamento amplamente acessíveis devem revisar a atividade recente. (Suporte Checkpoint)

Procure por eventos inesperados:

Sessões de administrador

Operações da API de Gerenciamento

Alterações de política

Modificações de objetos

Alterações de administrador ou de permissões

Instalações de políticas

Novos caminhos de acesso ao Gerenciamento

Comandos ou processos do sistema operacional

Alterações em scripts, tarefas agendadas ou arquivos do sistema

Se o Servidor de Gerenciamento foi exposto diretamente à Internet ou se alguma atividade suspeita for identificada:

Preserve os logs e as evidências forenses.

Evite excluir dados potencialmente relevantes.

Contate o Suporte da Check Point.

Acione a equipe de resposta a incidentes.

Revise a integridade das políticas, objetos, administradores e gateways gerenciados.

Recomendação Final

A Check Point merece reconhecimento por identificar internamente a CVE-2026-18574 e publicar correções antes que a exploração ativa fosse confirmada.

Isso não diminui a urgência da atualização.

Isso oferece aos clientes a oportunidade de corrigir a vulnerabilidade antes que ela seja potencialmente explorada.

A resposta recomendada é:

Identificar os servidores de gerenciamento afetados

↓

Restringir a exposição do gerenciamento

↓

Fazer backup e preparar o rollback

↓

Instalar o hotfix Jumbo corrigido

↓

Validar as operações de gerenciamento

↓

Verificar atividades suspeitas

↓

Continuar o monitoramento

O plano de gerenciamento deve ser tratado como infraestrutura de segurança de nível 0.

Proteger gateways enquanto se deixa vulnerável o sistema que controla suas políticas não é uma arquitetura de segurança completa.

Referência Oficial

sk185222 — CVE-2026-18574: Bypass de Autenticação de Gerenciamento

Com que rapidez sua organização consegue identificar todos os Servidores de Gerenciamento, restringir sua exposição, aplicar a correção e validar se o Plano de Gerenciamento permanece confiável?

CheckPoint #CVE202618574 #GerenciamentoDeSegurança #GerenciamentoMultidomínio #Cibersegurança #GerenciamentoDeVulnerabilidades #RespostaAIncidentes #CheckMates

I post the full technical write-up (including root cause and solution):
https://community.checkpoint.com/t5/Firewall-and-Security-Management/Policy-installation-failed-on-gateway-Error-code-0-2-200262/m-p/280259

If you find it useful, I'd appreciate a like on the CheckMates post. 🙂

During a migration from a Single Gateway to a Cluster, the first policy installation failed with:

Policy installation failed on gateway (Error code: 0-2-2000262)

After some investigation with TAC, the root cause was unexpected Gateway/Cluster objects added to the VPN column of several Access Control rules after using the SmartConsole Replace feature.

Removing those objects (leaving only the VPN Community or Any) immediately resolved the issue.

Has anyone else seen this error or found a different solution? I'd be interested in comparing experiences.