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@GW77: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@GW77:0]# fw ctl zdebug drop | grep 192.168.21
;[fw4_0];fw_log_drop_ex: Packet proto=1 192.168.21.1:2048 -> 192.168.21.2:19709 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.