7.7 fw monitor, fw ctl zdebug, and cpview

Packet Capture and Debug Tools

When a connection is being dropped and you cannot tell from the log why, Check Point provides three layered tools: fw monitor for packet capture at inspection points, fw ctl zdebug for kernel-level drop reasons, and cpview for a real-time performance and drop-statistics overview. CCSA questions test which tool to start with in each scenario and the key syntax of each.

fw monitor

fw monitor captures packets at the Chain Modules — the inspection points inside the firewall VM. Unlike tcpdump (which captures only at the interface), fw monitor can show a packet at multiple points in the inspection chain, which is what lets you tell whether a packet was dropped before or after NAT, before or after VPN encryption, and so on.

The four core inspection-point masks:

Plus e (pre-VPN encrypt) and E (post-VPN encrypt) for VPN troubleshooting. A packet seen at i but not I was dropped by the inbound inspection; seen at I but not o was dropped between inbound and outbound; seen at o but not O was dropped by outbound inspection or after.

Common examples:

fw monitor -e "accept;" -o /var/log/fw_mon.cap
fw monitor -e "host(192.168.1.1), accept;" -o /var/log/fw_mon.cap
fw monitor -e "port(80), accept;" -o /var/log/fw_mon.cap
fw monitor -F "0,0,8.8.8.8,0,0" -o /var/log/fw_mon.cap   # accelerated + non-accelerated
fw monitor -T -e "accept;" -o /var/log/fw_mon.cap         # with timestamps

-e takes an INSPECT filter and captures non-accelerated traffic. -F (capital) captures both accelerated and non-accelerated traffic using a simple srcPort,srcIP,dstPort,dstIP,proto filter. -o writes to a binary file you can read back with Wireshark (after converting with fw monitor -o or using the capinf/cppcap tools). Only one fw monitor instance can run at a time. Stop with Ctrl+C or fw monitor -U from another shell.

fw ctl zdebug

fw ctl zdebug is a wrapper around fw ctl debug that simplifies running kernel debugs. The flagship use case is dropped packets with reasons:

fw ctl zdebug + drop                          # all drops with reasons
fw ctl zdebug + drop | grep 192.168.1.1       # drops for a specific IP
fw ctl zdebug + packet                         # packet path
fw ctl zdebug + conn                           # connection table
fw ctl zdebug + xlate                          # NAT table
fw ctl zdebug + sync                           # ClusterXL state sync

Under the hood it runs fw ctl debug -buf 1024, enables your flags, runs fw ctl kdebug -f, waits for Ctrl+C, then runs fw ctl debug 0. The 1024 KB buffer is small — for production-volume debugging use the full fw ctl debug commands with a larger buffer. After Ctrl+C you may need to run fw ctl debug 0 manually to fully reset the debug state. Leaving debug on after you finish is one of the most common performance degradation causes — always reset.

Important caveat: fw ctl zdebug + drop and fw monitor -F share the same SecureXL/sim debug filter settings. If you run both at the same time the -F capture can become unfiltered. If you must run both, start zdebug first, then fw monitor -F, and stop fw monitor -F first.

cpview

cpview is a real-time performance and drop-statistics monitor. It shows CPU, memory, network interfaces, connection counters, and — most importantly for troubleshooting — the drop statistics occurring on the gateway, broken down by reason code. Best practice is to start with cpview for a quick look at where packets are being dropped, then drill down with fw ctl zdebug + drop for the per-packet reason, then use fw monitor to confirm the exact inspection point. cpview is non-invasive and safe to leave running during a troubleshooting session.

Related Tools

When SecureXL Acceleration Matters

SecureXL-accelerated connections are offloaded to a fast path that bypasses the FW VM, so fw monitor with -e will not see them. To capture accelerated traffic you either use -F, disable SecureXL temporarily with fwaccel off (then back on with fwaccel on), or look at the SecureXL drop counters in cpview. Disabling SecureXL in production impacts performance — only do it briefly during a debug window.

Exam Traps

• Start with cpview for drop statistics, then fw ctl zdebug + drop for reasons, then fw monitor for the inspection point. Picking the wrong starting tool is a common wrong-answer pattern.
• Only one fw monitor instance at a time.
• fw ctl zdebug + drop shows drop reasons; fw monitor shows packet positions — they answer different questions.
• Running fw monitor -F and fw ctl zdebug + drop together can break the filter; stop fw monitor -F first.
• Forgetting to reset debug (fw ctl debug 0) is a common cause of unexplained gateway slowdowns after a debug session.