A new Access Control rule is visible in SmartConsole and the install task reports success. The same application still fails, and the gateway log names another rule. Work backward from the test connection to the gateway, installed package, and rule layer. That gives you a specific correction before you reinstall policy.
This guide uses Check Point Quantum Security Management and Gaia R81.20. It covers Access Control changes, including deployments to a ClusterXL pair.
1. Record one new connection
Generate a new connection from the affected client. Record the timestamp and time zone, source and destination IPs, protocol, and destination port. Open the corresponding entry in Logs & Monitor. In the detailed view, note the origin gateway, action, matching rule and layer where shown, and any translated addresses relevant to the test.
If the browser reused an existing TCP connection, repeat with a fresh client connection. A log for a previous attempt or a different destination IP can point you to the wrong rule.
2. Confirm the change reached the intended gateway
In SmartConsole, verify the change was published, then check the result for the specific gateway or cluster under the Install Policy task. Compare the package and policy type with the change you intended to deploy. For an Access Control change, review the Access Control installation result.
On the gateway, check its local identity and installed firewall policy:
hostname
cpstat -f policy fwCompare the policy name and installation time with the SmartConsole task. If you manage a ClusterXL pair, check both members directly and record their roles before comparing results:
cphaprob stat
cpstat -f policy fwIn SmartConsole, Security Policies > Access Tools > Installation History lets you select the target gateway and inspect the installed revision and its changes. Use it when a recent timestamp matches expectations but you still need to establish whether your exact edit was included.
Check Point R81.20 – Policy Installation History · Check Point R81.20 – CLI Reference
3. Compare the logged match with the intended rule
Open the matching rule and its policy layer. Compare the observed source, destination, service, and gateway with the intended rule. If the rule is inside an inline layer, check the parent rule first. Traffic must match that parent before the gateway evaluates the inline rules. Check whether a broader earlier rule in the relevant layer handled the connection.
| Finding | What to verify |
|---|---|
| Gateway reports an older policy timestamp | Confirm the install result for that target and inspect the exact task error if installation failed. |
| Logs come from a different gateway | Verify the client path and which gateway handles the test flow. |
| Expected revision is installed but another rule matches | Check rule order, layer, object membership, service, and applicable identity conditions. |
| No matching log appears | Check the time range, log origin, Track setting, and whether the test traffic reached the gateway. |
| Expected rule logs Accept, but the application fails | Follow the live connection and return path. Check related inspection logs if the session reaches the gateway in both directions. |
Worked example: An earlier drop rule matches the connection
An engineer adds an exception for TCP/443 from a branch subnet to an internal application. The active gateway reports the expected package and install timestamp. The live log shows the connection matching an earlier drop rule in the same layer. The new exception sits below it.
Confirm that the source subnet, destination object, and service match the approved access change. Put the scoped exception in the intended order through the change process. Publish and install it on the correct target. Then start a fresh TCP connection, confirm the new log matches the exception, and verify an application response. Use an approved negative test from outside the allowed source scope to verify that the broader restriction still applies.
Record the gateway, package, revision, install time, rule name, and final test result in the change ticket. Those fields let the next engineer distinguish a deployment issue from a rule match or forwarding issue.