Don't rely on SmartViewTracker only - it may lie

Funny case of WYSIWYG misleading the uninitiated. The case involved a seemingly normally functioning firewall Checkpoint which after a client created rule to allow FTP from any to his server in DMZ (no Nat involved) refused to allow connections though. The client being quite experienced himself entered SmartViewTracker did filter on the rule (here rule 77) and saw nothing (of course Log was enabled on the rule) . OK, he thought, he canceled the filter and also started looking on the clean up rule that said Any -> Any = Drop (log enabled) and ... again saw no hits at all. And at this stage he approached us with request to check Linkproof leading to this firewall as " it doesnt pass traffic to my FTP server".
I did a usual thing - ssh -> fw monitor on FTP server IP and , hurra, saw me reaching FTP server IP but on input interface only - "Aha, dropped by a rule for sure" , then it took me another minute to prove it (to me and to the client) with this:

Here:
194.99.73.13 - FTP server in DMZ (IP sanitazed of course)
124.92.11.33 - my IP

[Expert@firewall2070]# fw ctl zdebug drop | grep 194.99.73.13

fw_log_drop: Packet proto=6 124.92.11.33:53408 -> 194.99.73.13:21 dropped by fwhold_expires Reason: held chain expired
fw_log_drop: Packet proto=6 124.92.11.33:53408 -> 194.99.73.13:21 dropped by
 fw_handle_first_packet Reason: Rulebase drop - rule 77

To remind - rule 77 was Any -> 194.99.73.13 (Service FTP) = Allow (log)

Why rule didn't work is another question - but reason was messed up rulebase that client did, when further down the rulebase was another rule to the same server partly overlapping this rule, the moment I disabled second rule all started to work.

So conclusion - don't rely on the SmartviewTracker only for debug , there can be too many reasons why it is not logging/showing logs as should.

Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.