In checkpoint we have three types of packet capture tools as following :

1. FW Monitor
2. TCP Dump
3. fw ctl zdebu

1. FW Monitor – Check Point’s FW Monitor is a powerful built-in tool for capturing network traffic at the packet level. The FW Monitor utility captures network packets at multiple capture points along the Firewall inspection chains. These captured packets can be inspected later using the Wire Shark.

• Anything related to policy installation or policy unloading on Security Gateway, will cause FW Monitor to exit.
• It is supported to run only a single instance of FW Monitor at any given time.
• Do not modify Check Point kernel tables used in the security policy while FW Monitor is running, otherwise unexpected behavior may result (including a system crash).
• Packets are defragmented as they leave the Security Gateway in both the inbound and outbound directions.
• If SecureXL is enabled on the Security Gateway, then FW Monitor and tcpdump will show only the non-accelerated packets (e.g., ‘TCP SYN’ will be shown, and ‘TCP ACK’ will not).

Important Note: Traffic captures can be misleading when working with SecureXL since both FW Monitor and Tcpdump do not always show ‘real’ packets that are going out to the network. This is related to the way the SecureXL kernel driver is attached to the network adapter itself. When using SecureXL to confirm whether packets are being handled correctly, either capture the traffic on the directly connected router / switch, or disable SecureXL.

In many deployment and support scenarios, capturing network packets is an essential functionality. The tcpdump / snoop utilities are normally used for this task. The FW Monitor utility provides an even better functionality, but omits many of the requirements and the risks associated with these tools:

• No Security Flaws

tcpdump / snoop are normally used with NICs in promiscuous mode. Unfortunately, promiscuous mode allows remote attacks against these tools. Check Point’s FW Monitor does not use promiscuous mode to capture packets. In addition, most firewalls’ operating systems are hardened. In most cases, this hardening includes the removal of tools like tcpdump / snoop, because of their security risks.

• Available on Firewall Installations

FW Monitor is a built-in tool that does not need a separate installation, or licensing.

• Multiple Capture Positions within the Firewall Kernel Module Chains

FW Monitor allows to capture packets at multiple capture positions within the Security Gateway kernel module chains, both for inbound and outbound packets. This enables to trace a packet through the different layers of the Security Gateway.

• Same Tool and Syntax on All Platforms

FW Monitor is available on all different platforms. tcpdump / snoop are often platform-dependent, or have specific “enhancements” on certain platforms. FW Monitor and all its related functionality and syntax are identical across all platforms.

Normally, Check Point kernel modules are used to perform several functions on packets, such as filtering, encryption and decryption, QoS, etc. FW Monitor adds its own modules to capture packets. FW Monitor can capture all packets that are seen and/or forwarded by the Security Gateway.

^(*) The traffic direction (inbound/outbound) relates to each specific packet, and not to the connection.

Disable SecureXL for capturing proper logs:

• If you have SecureXL enabled, it fast switches the packets and won’t show you all the detailed logs that you would like to see in your captures. You can disable SecureXL temporarily, if you want to inspect packets at that granularity (i.e ‘I’ and ‘o’). In my experience, disabling SecureXL hasn’t been a problem* and I haven’t seen any performance impact as such.

Right before the capture, turn off SecureXL on the gateway:

fwaccel off

Immediately after the capture, turn on SecureXL on the gateway:

fwaccel on

To turn on/off SecureXL on multiple VSXs at once:

fwaccel on -a fwaccel off -a

• Ensure that you re-enable after you are done capturing the logs.

Be aware that SecureXL does affect how the traffic passes through the firewall and only disable it if you are 100% sure of what you’re doing. Do it at your own risk, I do not take any responsibility for anything going wrong with this as it does affect the live traffic immediately.

Display all 8 inspection points (iIoO) for a complete two-way traffic on the console:

For specific flow:fw monitor -e ‘accept (src=10.1.1.1 and dst=20.2.2.2) or (src=20.2.2.2 and dst=10.1.1.1);’ -m iIoOORFor specific IP:fw monitor -e ‘accept (src=10.1.1.1 or dst=10.1.1.1);’ -m iIoO

Display 4 inspection points (iO) for a complete two-way traffic on the console:

fw monitor -e ‘accept (src=10.1.1.1 and dst=20.2.2.2) or (src=20.2.2.2 and dst=10.1.1.1);’ -m iO

• Note that we are only gripping iO, that means you are not looking for what is going on at the post-inbound (I) and pre-outbound (o) inspection points and just trying to get fewer output to see if it actually leaves the egress interface or not.

Saving fw monitor logs to a .pcap file to analyze in wire shark:

fw monitor -e ‘accept (src=10.1.1.1 and dst=20.2.2.2) or (src=20.2.2.2 and dst=10.1.1.1);’ -m iIoO -o wireshark.pcap

• By default, the capture file is saved to the /home/admin directory.
• Use WinSCP to access the Security Gateway and copy the file to your local drive to it in Wire shark.

Switches:

2. TCP Dump – TCPDUMP is a powerful tool for debugging on checkpoint, tcpdump feeds directly to the screen packets crossing an interface, if dumped to a file TCPDUMPS can be read by wire shark. you need to be in expert mode to invoke TCPDUMP.

Some Examples of  TCPDUMP I have used

tcpdump -w capture.pcap -i eth-s1p2c0 host 10.1.1.1 and host 20.2.2.2 tcpdump -nni any  –

host 10.1.1.1 -w capture.pcap tcpdump -nni any host 10.1.1.1 and host 20.2.2.2 -w capture.pcap

Capture your output in pcap format to open in wire shark

tcpdump -i eth1 src 10.1.1.1 and dst 20.1.1.1 – for specific source and destination

tcpdump -i mgmt host 192.168.1.1

Please refer below article for more TCP dump syntax.

TCP DUMP

What’s the difference between TCP Dump and FW Monitor ?

Tcpdump displays traffic coming or leaving to/from a firewall interface while FW monitor would also tell you how the packet is going through the firewall including routing and NAT decisions.

FW MONITOR

It captures traffic at 4 important points in the firewall namely i, I, o & O. You would see them in the capture in the same sequence.
i – Preinbound, just where the packet is received on the interface. If you see only this then the packet is dropped by address spoofing or the access rule.
I – Postinbound, where the packet has gone across the incoming interface. If you don’t see the next line in capture after this at ‘o’, you could infer that it’s a routing issue.
For both i & I the interface is the incoming, where the packet enters the firewall.
o – Preoutbound, the place where the packet is received at the exit interface within the firewall. If this is the point beyond which the capture is not seen, then you may need to check NAT.
O- Postoutbound, If you see this then make you are sure that the packet has left the firewall and the ACL, route and NAT all are working as expected.

FW Monitor -e “accept src=10.1.1.201 or dst=10.1.1.201;” -o monitor2.out

TCPDUMP.

It captures at position i & O of firewall monitor, and you can be sure the traffic has left the firewall. This is similar to the way captures work on a Cisco PIX/ASA.

So, which one you use ?

Consider you run tcpdump and see the incoming traffic but don’t see the traffic leaving the exit interface. You can guess it’s a routing or a NAT issue. But to make a sure shot without wasting time by looking in routes or the NAT rules you could run FW Monitor and know what the issue is.

3. fw ctl zdebu – fw ctl zdebug” is a power tool that is not exhausted from being used with “fw ctl zdebug drop”. There is not much to be found in Check Point KB or in the documentation. “fw ctl zdebug” is an R&D tool for testing software in development. Therefore, the insert should be used with care. It starts a debugging in the background until it is aborted with CTRL+C. On productive systems it can have a high performance impact. Furthermore, the debug buffer is not the largest.

What happens when you execute! It is a macro that executes the following commands:

fw ctl debug -buf 1024
fw ctl debug [The option behind “fw ctl zdebug”]
fw ctl kdebug -f
[Wait until CTRL+C is pressed]
fw ctl debug 0

Here are some good examples for debugging:

fw ctl zdebug + packet
fw ctl zdebug + packet | grep -B 1 TCP |grep -B 1 “(SYN)”      <<< change SYN-ACK,ACK,FIN,… and/or UDP,TCP…
fw ctl zdebug + all |grep -A 1 “Monitor” | grip “1.1.1.1”         <<< change IP address
fw ctl zdebug + all |grep -A 2 “Monitor”
fw ctl zdebug + sync
fw ctl zdebug + conn |grep “After  VM:” |grep “(SYN)”
fw ctl zdebug + xlate
fw ctl zdebug + monitorall                                                     <<< use with host IP “| grep 1.1.1.1” or network range “| grep 1.1.”
fw ctl zdebug + monitor                                                            <<< use with host IP “| grep 1.1.1.1” or network range “| grep 1.1.”
fw ctl zdebug + filter conn | grep -A 8 “rule 1”                          <<< change rule number – show connetions to rule xyz
fw ctl zdebug + filter monitor  | grep -A 8 “rule 2”                     <<< change rule number – show connetions to rule xyz

Attention, if you turn on debugging, this will affect the performance of the firewall.

Please find useful reference links

FW Monitor

Zdebug