156-582 Sample Questions & Answers

'Phase 1 Retransmission' means one gateway is sending IKE negotiation packets but is not receiving any reply from its peer. This is almost always a fundamental connectivity or routing issue. The peer gateway is either not receiving the packets (due to routing, an intermediate firewall, or NAT issue) or its replies are not making it back. Mismatches in Encryption Domain or Phase 2 proposals occur after Phase 1 has successfully completed.

The cpd (Check Point Daemon) process is responsible for several critical tasks, most notably logging. It handles the transfer of logs from the Security Gateway to the Security Management Server or Log Server. High CPU utilization in cpd will directly impact the gateway's ability to send logs, leading to delays or log loss. Policy installation is handled by fwm on the management server and cpd on the gateway side, but logging is its primary and most resource-intensive function.

After attaching a new license or contract file via SmartUpdate, the information is updated on the Security Management Server but not automatically pushed to the gateways. A policy installation is required to synchronize the new contract and license information from the management server to the managed gateways. This action will update the gateway's local license files and resolve the 'Contract expired' status.

fw monitor -p all captures packets at all inspection points on all interfaces. This allows an administrator to filter for a specific session and observe the inbound and outbound interfaces. To diagnose asymmetric routing, one would look for the initial packet (e.g., SYN) going out one interface, but the return packet (e.g., SYN-ACK) never being seen inbound on any interface, confirming it took a different path. This is the most direct way to visualize the asymmetric flow. fw tab shows the state but not the path, cpview gives performance metrics, and tcpdump on a single interface wouldn't prove the asymmetry.

The fwm (Firewall Management) process on the Security Management Server is responsible for compiling the security policy and pushing it to the gateways. The log file for this process, $FWDIR/log/fwm.elg, contains the detailed, verbose output of the entire installation process, including verification, code generation, and transfer to the gateway. This is the primary log file to analyze for policy installation failures. fwd.elg is for general logging and SIC, while cpd.elg is for the Check Point Daemon on the gateway.

Even if SIC and network connectivity are correct, the gateway must be explicitly configured to send its logs to a specific Log Server or the management server. This is configured within the gateway's object properties under the 'Logs' tab in SmartConsole. If this is not set, or is pointing to the wrong destination, no logs will be sent. This is a common oversight during new gateway deployment.

The best practice is to be as specific as possible when creating exceptions. Allowing access only to the exact URL (https://www.example.com/login) needed for business purposes minimizes the attack surface. Whitelisting the entire domain (www.example.com) could inadvertently allow access to other, potentially malicious, parts of the site. Creating a broad 'allow all' rule is insecure. While submitting a categorization request is a good long-term solution, creating a specific exception provides an immediate fix.

The key symptom is that the data center gateway sees the traffic with the store's external IP, which means it was NAT'd, not encrypted. Check Point's logic dictates that if traffic matches a NAT rule before it matches the criteria for VPN encryption, it will be NAT'd. The issue is likely a broad NAT rule (e.g., Source: 'Store_Network', Destination: 'Any', Service: 'Any' -> NAT to 'Gateway_External_IP'). This rule is matching the POS traffic and translating it before the VPN logic can encrypt it. The solution is to create a 'No NAT' rule for traffic between the store network and the data center network, placed above the general internet access NAT rule.

The cpinfo command is the standard Check Point utility for gathering a wide range of configuration, log, and diagnostic information from a system. The output file generated by cpinfo is what Check Point support typically requests to begin troubleshooting a case.