For anyone managing Check Point in production, installing a Jumbo Hotfix should not be treated as a simple “upload → install → reboot” task.

I published a practical guide on CheckMates covering Jumbo Hotfix installation on standalone Security Gateways and ClusterXL HA environments, including the upgrade workflow, member preparation, validation steps, and key precautions to reduce operational risk during the maintenance window.

In HA environments in particular, the upgrade sequence and the checks performed before and after the installation are critical to preserving availability and avoiding unexpected behavior during failover.

If you work with Check Point administration or troubleshooting, this is worth saving as a reference for your next maintenance window.

Full article on CheckMates:

Jumbo Hotfix Installation on a Single Firewall or HA Cluster

https://community.checkpoint.com/t5/AI-Network-Firewall/Jumbo-Hotfix-Installation-on-an-single-firewall-or-HA-Cluster/m-p/280409

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.

https://preview.redd.it/0ynbsf70l4jh1.png?width=745&format=png&auto=webp&s=d8dbd8a0ac7247fff589941ef3a7ef01de302ccf

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.

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

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?

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.

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)

 

https://preview.redd.it/fbcqqdzmzxhh1.png?width=666&format=png&auto=webp&s=e7612945bec3b086276200585be111ad9b217434

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

 

https://preview.redd.it/1k2jhe6pzxhh1.png?width=575&format=png&auto=webp&s=804f5df36c6d19197803a1342b9bc2846a1f6515

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

 

https://preview.redd.it/03eqzkawzxhh1.png?width=620&format=png&auto=webp&s=61452bb034b61ce7291adbbf7b47e282010050c2

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

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

https://preview.redd.it/qer1xda2mqhh1.png?width=596&format=png&auto=webp&s=fc3f56380e6c7114e9149afebe929f8fce3fa694

 

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

 

 

Normal vs. V2 Signatures: Technical Comparison

Feature	Normal Signature	V2 Signature (INSPECTv2)
Detection Engine	Classic Pattern Matcher	INSPECTv2 (advanced engine)
Coverage	Known threats	New threats, evasive techniques, improved accuracy
Performance	Lower resource usage	May require more CPU/memory, but optimized for accuracy
Compatibility	Legacy gateways	Modern gateways (R80+)
Update Frequency	Less frequent	Updated regularly

• 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.