Check Point Technology Expert

• Troubleshooting -- Load references/diagnostics.md for CLI commands, cpstat, fw commands, SecureXL, cluster diagnostics
• Policy design -- Apply layered policy model, rule base structure, inline layers, Security Profile Groups
• Architecture -- Load references/architecture.md for SmartConsole, MDS, ClusterXL, Maestro, Infinity, ThreatCloud AI
• Administration -- Follow session-based commit model (edit, publish, install policy)
• Automation -- Apply mgmt_cli, Web API, Terraform, or Ansible guidance

Core Architecture: Software Blades on Gaia OS

Check Point runs all security functions as Software Blades on Gaia OS (64-bit Linux-derived):

• Gaia OS: Unified operating system for all Quantum gateways and management servers. WebUI (Gaia Portal) for OS-level config, CLI (expert mode bash, clish for structured commands).
• Software Blades: Modular security functions activated per gateway -- Firewall, IPS, Application Control, URL Filtering, Anti-Virus, Anti-Bot, Threat Emulation, Threat Extraction, HTTPS Inspection, VPN, Identity Awareness.
• Management architecture: Security Management Server (SMS) manages one or more gateways. SmartConsole connects to SMS. Policy is authored on SMS, compiled, and installed to gateways.

Session-Based Commit Model

Check Point uses a session-based editing model in SmartConsole:

• Session creation: Each admin works in an isolated session. Changes are visible only to that admin until published.
• Publish: Commits session changes to the management database. Creates a revision snapshot.
• Install Policy: Pushes compiled policy from SMS to target gateways. Must be done after publish for changes to take effect on gateways.
• Discard: Abandons unpublished changes in the current session.
• Concurrent editing: Multiple admins can edit simultaneously in separate sessions. Conflicts detected at publish time.
• Revision control: Every publish creates a versioned snapshot. Roll back to any prior version.

Workflow: Edit -> Publish -> Install Policy. Never skip publish before install.

mgmt_cli equivalent:

mgmt_cli login -> (make changes) -> mgmt_cli publish -> mgmt_cli install-policy -> mgmt_cli logout

Security Policy Architecture

Layered Policy Model (R80+)

Check Point uses ordered layers for policy evaluation:

1. Access Control Layer -- Network/application firewall rules. 5-tuple + application + URL filtering. Ordered, first-match within a layer.
2. Threat Prevention Layer -- IPS, Anti-Virus, Anti-Bot, Threat Emulation, Threat Extraction. Profile-based (Optimized, Strict, or custom). Applied after Access Control permits traffic.
3. HTTPS Inspection Layer -- SSL/TLS interception policy. Inbound (server protection) and outbound (user inspection). Must be enabled for Threat Prevention to inspect encrypted traffic.

Inline Layers

• A rule in an Access Control layer can reference an inline layer -- a nested sub-policy evaluated only when the parent rule matches.
• Use cases: per-department web filtering, per-application micro-policies.
• Inline layers have their own ordered rules; evaluation returns to parent layer after inline layer completes.

Rule Base Best Practices

1. Most-specific rules at top
2. Use updatable objects for geo-blocking (IP feed-based, auto-updated by Check Point)
3. Use time objects for scheduled rules
4. Implicit cleanup rule at bottom (deny all, log)
5. Object tagging for large rule bases (10,000+ rules)
6. Use Security Profile Groups rather than individual blade profiles per rule

Multi-Domain Shared Policy

In MDS environments, Global Policy wraps domain-specific rules:

• Global pre-rules -- Evaluated before domain rules (corporate mandatory policy)
• Domain rules -- Domain-specific rules managed by domain admins
• Global post-rules -- Evaluated after domain rules (corporate catch-all)

NAT Architecture

• Hide NAT (Many-to-One) -- Source NAT; auto-configured per network object or manual rule. Most common for outbound internet.
• Static NAT (One-to-One) -- Bidirectional; supports port translation. Proxy ARP auto-configured for local subnets.
• NAT Rule Base -- Manual NAT rules evaluated before automatic NAT. Separate tab in SmartConsole.
• Rule evaluation: Manual rules (top-down, first-match) -> Automatic rules (object-defined NAT, evaluated by specificity).
• IPv6 NAT64/NAT66 supported in R82.

VPN

IPsec Site-to-Site

• IKEv1/IKEv2; pre-shared key or certificate authentication
• Policy-based (domain-based encryption rules) and route-based (VTI) modes
• VPN Communities -- Star and meshed topologies for hub-and-spoke
• MEP (Multiple Entry Points) -- Route-based failover across redundant gateways

Remote Access

• Endpoint Security VPN (full client), Check Point Mobile (SSL VPN), L2TP/IPsec
• MFA via RADIUS/LDAP/SAML
• Managed from SmartConsole or Infinity Portal

Post-Quantum VPN (R82)

• Hybrid Kyber (ML-KEM / CRYSTALS-Kyber) + classical IKE key exchange
• Backward compatible -- non-PQC peers negotiate classical only
• Protects against harvest-now-decrypt-later quantum threats

High Availability: ClusterXL

Key Concepts

• Cluster Control Protocol (CCP) -- Proprietary heartbeat; monitor via cphaprob stat
• State Synchronization -- Connection table, NAT table, VPN tunnels synced via dedicated sync interface
• VRRP/VMAC -- Virtual MAC prevents ARP flooding on failover
• Graceful failover -- clusterXL_admin down triggers planned failover
• Multi-Version Cluster (MVC) -- Rolling upgrades between minor versions without downtime
• Configurable sync exclusions -- Exclude non-critical protocols (DNS, HTTP) from state sync for performance

HA Best Practices

• Dedicated physical links for CCP/sync -- never share with production
• Test failover regularly: clusterXL_admin down on active, verify traffic moves, restore with clusterXL_admin up
• Monitor via cphaprob stat, cphaprob -a if, fw hastat
• Upgrade passive first, verify, fail over, then upgrade former active

Maestro Hyperscale

Maestro enables elastic horizontal scaling for data center and carrier-grade deployments:

• Maestro Hyperscale Orchestrator (MHO) -- Dedicated appliance (MHO-140, MHO-175) connecting gateways via high-speed backplane
• Security Group -- Logical unit of multiple physical gateways managed as one entity in SmartConsole (Single Management Object)
• Scale -- 2 to 52 gateways per group; add members without downtime
• Throughput -- Multi-Terabit/second combined threat prevention with 26000-series members
• Dual Orchestrator HA -- Two MHOs for resilience with automatic failover
• Dynamic Balancing -- Session affinity with dynamic rebalancing; handles asymmetric routing

ThreatCloud AI

Real-time threat intelligence network powering all security blades:

• Aggregates data from 150,000+ networks and millions of endpoint sensors
• 30+ AI/ML engines covering malware, phishing, zero-day, campaign correlation
• Feeds ThreatEmulation (sandboxing), ThreatExtraction (CDR), Anti-Bot, AV, IPS, URL Filtering
• ThreatExtraction delivers clean files immediately while sandbox runs asynchronously (zero-latency CDR)
• Custom IoC feeds importable via SmartConsole or API

Automation

mgmt_cli (Local CLI)

mgmt_cli login                              # Returns session-id
mgmt_cli show hosts                          # List host objects
mgmt_cli add host name "web01" ip-address "10.1.1.100"
mgmt_cli set access-rule layer "Network" uid "..." action "Drop"
mgmt_cli publish                             # Commit pending changes
mgmt_cli install-policy policy-package "Standard" targets "gw01"
mgmt_cli logout

Web API (REST / HTTPS)

• Endpoint: https://<mgmt-ip>/web_api/<command>
• Auth: POST /web_api/login returns {"sid": "..."} used in X-chkp-sid header
• Full CRUD for all policy objects, rules, NAT, VPN, users
• Batching and async task execution supported
• Swagger/OpenAPI at https://<mgmt-ip>/api/swagger.json

Terraform

• Provider: CheckPointSW/checkpoint (Terraform Registry)
• Manages gateways, clusters, policy packages, layers, rules, NAT, VPN, objects

Ansible

• Collection: check_point.mgmt (Ansible Galaxy)
• Modules mirror mgmt_cli: cp_mgmt_host, cp_mgmt_access_rule, cp_mgmt_publish, cp_mgmt_install_policy
• Idempotent; supports check mode

Common Pitfalls

1. Forgetting to publish before install-policy -- Changes exist only in the admin's session until published. Install-policy pushes the last published revision, not unpublished edits.

2. Not using inline layers for complex rule bases -- Flat rule bases with 5,000+ rules become unmanageable. Inline layers provide modular sub-policies.

3. SecureXL acceleration disabled or bypassed -- Check fwaccel stat. Many features (HTTPS inspection, certain NAT configurations) prevent acceleration. Verify accelerated vs. medium/slow path distribution.

4. Upgrading both cluster members simultaneously -- Always upgrade passive first, verify with cphaprob stat, fail over, then upgrade the other.

5. Ignoring Threat Prevention profile mode -- "Optimized" profile balances performance/security; "Strict" catches more but may impact throughput. Choose based on environment.

6. Manual NAT shadowing automatic NAT -- Manual rules are evaluated first. An overly broad manual rule will prevent automatic object-level NAT from matching.

7. Not testing VPN with vpn tu -- The VPN tunnel utility (vpn tu) is essential for debugging IKE/IPsec issues.

8. MDS global policy conflicts -- Global pre-rules override domain rules. Ensure global policy doesn't inadvertently block domain-specific requirements.

Version Agents

For version-specific expertise, delegate to:

• r82/SKILL.md -- R82 / R82.10: AI Copilot, Post-Quantum VPN, unified SASE policy, enhanced HTTPS inspection, IoT/OT discovery

Reference Files

Load these when you need deep knowledge:

• references/architecture.md -- SmartConsole, MDS, policy layers, ClusterXL, Maestro, Infinity, ThreatCloud AI. Read for "how does X work" questions.
• references/diagnostics.md -- cpstat, fw, fwaccel, SecureXL, cluster commands, mgmt_cli, Web API. Read when troubleshooting.