Check Point

Healthy and broken

What it checks, in order

1. The action on the connection log: accept, drop, or reject.
2. Which rule number and name matched.
3. Whether that was the intended permit, or a fallback deny or the cleanup rule.
4. If the intended permit is identity-based, whether the source address is mapped to an identity by Identity Awareness.
5. Which blade made the decision: the firewall access policy or a non-firewall blade.

Common causes and how to spot them

• Cause: The user was not identified by Identity Awareness.
  Spot it: The permit rule requires an access role, but Identity Awareness shows no identity for the source. The rule is skipped and the cleanup rule drops the traffic.
• Cause: Rule order or a missing permit rule.
  Spot it: The matched rule is a deny or the cleanup rule, not the rule the connection should use.
• Cause: Wrong service or port in the permit rule.
  Spot it: The permit rule exists, but its service definition does not match the actual connection.
• Cause: A non-firewall blade dropped the traffic.
  Spot it: The deciding blade in the log is not the firewall access policy (for example, Application Control or URL Filtering).

A drop on the cleanup rule with no identified user, next to a permit rule that requires an access role, points to an Identity Awareness gap, not a missing rule. The proposed solution is to get the user identified to the gateway so the existing permit rule can match. The engine never makes the change and proposes this for a person to perform.

An example investigation

pathwise > investigate "user blocked reaching payroll server, check point"

module        check point v1.0.0  ·  layer: rights
evidence      reading checkpoint/exports/policy-decision.json (file-drop door)

record 1      connection_log
              src 10.20.10.45  →  dst 10.50.4.20  tcp/443
              action drop  ·  matched rule 99 "Cleanup rule"
              blade Firewall  ·  gateway gw-hq-01  ·  policy Standard
              identity: no identity mapped for source

record 2      policy_rule  rule 23 "Finance to Payroll"
              source role  Finance-Group (access role required)
              destination  Payroll-Server (10.50.4.20)
              service      tcp/443
              action       accept

record 3      identity_status
              source 10.20.10.45
              identity     no identity mapped

analysis
  rule 23 accepts Finance-Group → Payroll-Server on tcp/443
  source 10.20.10.45 has no identity  →  rule 23 is skipped
  connection falls through to cleanup rule 99  →  drop
  this is an identity awareness gap, not a missing rule

finding       rule 23 would accept this connection. it requires the Finance-Group
              access role. identity awareness did not map 10.20.10.45 to any identity,
              so rule 23 was skipped and the cleanup rule dropped the traffic.
layer         rights  (confidence: high)
not verified  why the identity mapping is absent for this source

proposed solution (for a person to perform):
  get 10.20.10.45 identified to gateway gw-hq-01 via identity awareness.
  once the source maps to the Finance-Group role, rule 23 matches and accepts.

⚠ PathWise never makes the change. This step is yours.

What this module contains

checkpoint/
  module.yml        manifest: name, vendor, version, layer, covers, author
  knowledge.md      plain-language how-to troubleshoot Check Point rights
  connection.yml    API door (Management API v1.9), file drop as the fallback
  evidence.yml      field labels, for a later feature (not read yet)
  examples/
    sample-ticket.md
    exports/
      policy-decision.json  sample data: connection log + rule + identity status
  README.md

This module has two doors. Point it at your Management API and store the credential in Settings, and it reads through seven cards covering gateways, cluster state, the rulebase, objects, logs, admin profiles, and Identity Awareness lookups. Every card is a read against the Management API. There is no gateway CLI, no run-script, and no write of any kind. Without a credential it falls back to reading the policy decision you export and drop in the folder.

What we have not proven. The card catalog is tested against fixtures. Nobody has yet watched it run against a real Check Point estate. Until a tester does, treat the API door as built and unproven, and treat the file drop as the path we have actually exercised.