7.8 cpinfo and Common Issues

cpinfo and Common Troubleshooting Scenarios

cpinfo is the single command Check Point Support asks for first. It collects system information, configuration, and a sanitized set of logs from a gateway or Management Server into one compressed file that TAC can analyze with DiagnosticsView (sk125092). On R82 the relevant SK is sk92739 for collecting cpinfo and sk125092 for analyzing it. Knowing when to collect cpinfo, what it contains, what it does not contain, and how it fits in the broader troubleshooting workflow is a CCSA staple.

cpinfo Basics

cpinfo                       # full cpinfo from a gateway
cpinfo -l                    # limited output (build/version info only)
cpinfo -h                    # hardware info (replaces asg_collect_vsx_logs on Scalable Platforms)

When opening a support case you collect a full cpinfo plus (per the R82 pre-upgrade checklist) a snapshot, a system backup, and the migrate export. cpinfo is not encrypted; it contains configuration and log snippets, so handle it as confidential and transfer it via secure channels. cpinfo is a snapshot of state at collection time — it does not include live debugging output, so for intermittent issues you may need to run fw ctl zdebug or fw monitor while the problem is occurring and attach those outputs separately.

SIC Failures

Secure Internal Communication (SIC) is the certificate-based mutual auth between the Management Server and gateways. Without it you cannot install policy or send logs. SIC errors are logged in $CPDIR/log/sic_info.elg on both sides.

SIC status values:

Troubleshooting sequence (official R82 order):

1. Verify IP connectivity between Gateway and Management Server.
2. Confirm the same one-time activation key was used on both sides.
3. If Management is behind a gateway, ensure rules and Anti-Spoofing allow the connection.
4. Ensure the Management Server's name and IP are in the gateway's /etc/hosts.
5. If Management is behind static NAT, add the public IP to the remote gateway's /etc/hosts (must resolve to hostname).
6. Verify date and time — clock skew can make certificates not-yet-valid.
7. Re-establish trust.

To reset trust: run cpconfig on the gateway → Secure Internal Communication → enter a new activation key; then in SmartConsole enter the same one-time password and click Initialize. Useful CLI on the gateway: cp_conf sic state (current state), cp_conf sic init (reset key), cp_conf sic cert_pull <MGMT_IP> <GW_NAME> (for DAIP gateways).

Policy Install Errors

A policy install failure breaks down into two phases:

• Compilation failure — fails before reaching the gateway; investigate CPM, FWM, the policy package, the objects database, validation, and management performance. Logs: $FWDIR/log/cpm.elg, $FWDIR/log/fwm.elg.
• Distribution failure — fails while pushing to the gateway; investigate CPD, SIC, CPCA/ICA, FWD, network reachability, gateway disk space, gateway processes, and policy load. Logs: $FWDIR/log/fwd.elg, $CPDIR/log/cpd.elg, $CPDIR/log/sic_info.elg.

Process health first: cpwd_admin list shows whether key Check Point processes are alive and monitored. On a gateway, fw stat / fw stat -l shows the policy currently loaded. df -h and free -m — a full disk or exhausted memory breaks many "Check Point" symptoms that look like SIC or policy issues. A disk-full /var is one of the most common causes of policy install failure because the gateway cannot write the new policy files.

To unload policy for emergency access without installing a new one, fw unloadlocal on the gateway disables the current policy (no filtering). Use only for break-glass troubleshooting because the gateway becomes a router.

A real-world example: SIC error 325 ("SIC General Failure") on R82.10 cross-AZ cluster installs. SIC trust initialized fine, but Install Policy always failed. Root cause was a certificate date-validation bug (sk184766); resolution was to apply JHF Take 464 or higher. The lesson: when SIC is up but every install fails with a SIC error, suspect certificate/time-related bugs and check the JHF level before resetting trust.

Common Issues — Quick Triage

The CCSA Mindset

Don't react to the error string. Identify which process in the chain failed: SmartConsole → CPM → PostgreSQL/objects DB → FWM/FWD → CPD → CPCA/ICA → gateway → FWK/FW. The fix follows from where the chain broke, not from the wording of the error. Collect cpinfo as evidence early, check process health and system resources next, and only then start resetting trust or restarting services.