Check Point provided us many ways to debug issues. Some are easier, some are harder.
The first thing to do when you have dropped traffic is to see whether the packets are being dropped by the firewall or not. The first impulse is to look at SmartView Tracker's logs and that's ok, unless of course you have some Security Rules without log enabled on them. But there has always been available this command that gives us real time insight of what is being dropped at the KERNEL level! What can be better ? You may use it in cases when fw monitor or SmartView Tracker logs do not give conclusive results. Or, you can use it as the first command as I do - this saves time loading all the logs or decluttering fw monitor output. The command, run in the expert mode, is fw ctl zdebug drop :
[Expert@smartcenterr77:0]# fw ctl zdebug drop
Defaulting all kernel debugging options
Initialized kernel debugging buffer to size 1023K
Updated kernel's debug variable for module fw
Kernel debugging buffer size: 1023KB
Module: kiss
Enabled Kernel debugging options: None

Module: kissflow
Enabled Kernel debugging options: error warning
Messaging threshold set to type=Info freq=Common

Module: fw
Enabled Kernel debugging options: drop
Messaging threshold set to type=Info freq=Common
;[fw4_0];FW-1: Initializing debugging buffer to size 1023K;
;[fw4_0];Setting the flags for debug module fw: drop;
On loaded firewall it is advisable to limit output to the terminal for decluttering using grep:
[Expert@smartcenterr77:0]# fw ctl zdebug drop  | grep 192.168.21
;[fw4_0];fw_log_drop_ex: Packet proto=1 -> dropped by fw_handle_first_packet Reason: Rulebase drop - rule 1;
Here you can clearly see that ICMP is being dropped on Security Rule 1 (which blocks all ICMP). The tool becomes even more interesting when a firewall drops some packets NOT on rules, but say on IP Options set field.