How to See a Network Flow Through the CLI in a Checkpoint Firewall

IT team reviewing firewall CLI output on dual monitors while troubleshooting Checkpoint network traffic flow

Notice: This blog post was originally published on Indeni before its acquisition by BlueCat.

The content reflects the expertise and perspectives of the Indeni team at the time of writing. While some references may be outdated, the insights remain valuable. For the latest updates and solutions, explore the rest of our blog

If you want to check the traffic flowing through a Checkpoint firewall without using the SmartView Tracker, you can use “fw monitor” command.

I will show you how to use fw monitor the way I use it for my troubleshooting process.

Take into consideration the following:
1. If you have a cluster, this command will show traffic flowing through the active firewall.
a. To check active status issue: cphaprob state
2. If you have SecureXL enabled, some commands may not show everything.
a. To disable SecureXL: fwaccel off
b. To enable SecureXL: fwaccel on

Traffic to/from a Host

You can check the traffic that a host is receiving or sending with the following command:

fw monitor -e “accept host(x.x.x.x);”

Example

CP-Firewall> fw monitor -e "accept host(192.168.1.86);"
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_6] eth3:i[71]: 173.16.25.44 -> 192.168.1.86 (TCP) len=71 id=0
TCP: 43637 -> 443 F..PA. seq=4a5c5909 ack=df3170c0
[vs_0][fw_6] eth3:I[71]: 173.16.25.44 -> 192.168.1.86 (TCP) len=71 id=0
TCP: 43637 -> 443 F..PA. seq=4a5c5909 ack=df3170c0
[vs_0][fw_6] eth1:o[41]: 173.16.25.44 -> 192.168.1.86 (TCP) len=41 id=0
TCP: 43637 -> 443 F...A. seq=4a5c5927 ack=df3170c0
[vs_0][fw_6] eth1:O[41]: 173.16.25.44 -> 192.168.1.86 (TCP) len=41 id=0
TCP: 43637 -> 443 F...A. seq=4a5c5927 ack=df3170c0
monitor: caught sig 2
monitor: unloading
CP-Firewall>

In this example, you can see the ingress interface (eth3) and the egress interface (eth1). Also, you can see the 4 capture points (iIoO):

pre-inbound i (lowercase i)
post-inbound I (uppercase i)
pre-outbound o (lowercase o)
post-outbound O (uppercase o)

You can also use set the capture points:

CP-Firewall> fw monitor -e "accept host(192.168.1.86);" -m iO
 Compiled OK.
 monitor: loading
 monitor: monitoring (control-C to stop)
 [vs_0][fw_6] eth3:i[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
 TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
 [vs_0][fw_6] eth1:O[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
 TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000

Traffic to/from a Network

You can check the traffic to a network with the following command. You can use 32 as netmask and would work like a host as well.

fw monitor -e "accept net(x.x.x.x,yy); "

Example (network 192.168.1.64/26)

CP-Firewall> fw monitor -e "accept net(192.168.1.64,26); "
 Compiled OK.
 monitor: loading
 monitor: monitoring (control-C to stop)
 [vs_0][fw_11] eth2:i[44]: 172.16.10.149 -> 192.168.1.89 (TCP) len=44 id=36544
 TCP: 7480 -> 443 .S.... seq=25d68d6c ack=00000000
 [vs_0][fw_11] eth2:I[44]: 172.16.10.149 -> 192.168.1.89 (TCP) len=44 id=36544
 TCP: 7480 -> 443 .S.... seq=25d68d6c ack=00000000
 [vs_0][fw_11] eth1:o[44]: 172.16.10.149 -> 192.168.1.89 (TCP) len=44 id=36544
 TCP: 7480 -> 443 .S.... seq=25d68d6c ack=00000000
 [vs_0][fw_11] eth1:O[44]: 172.16.10.149 -> 192.168.1.89 (TCP) len=44 id=36544
 TCP: 7480 -> 443 .S.... seq=25d68d6c ack=00000000

 

To see a one-way network flow:

You can check the traffic to a source and destination in one direction:

fw monitor -e “accept (src=x.x.x.x and dst=x.x.x.x); “

Example (from 173.16.25.44 to 192.168.2.134)

CP-Firewall> fw monitor -e "accept (src=173.16.25.44 and dst=192.168.2.134); "
 monitorfilter:
 Compiled OK.
 monitor: loading
 monitor: monitoring (control-C to stop)
 [vs_0][fw_0] eth3:i[64]: 173.16.25.44 -> 192.168.2.134 (TCP) len=64 id=0
 TCP: 31668 -> 443 .S.... seq=334241eb ack=00000000
 [vs_0][fw_0] eth3:i[64]: 173.16.25.44 -> 192.168.2.134 (TCP) len=64 id=0
 TCP: 10589 -> 443 .S.... seq=96f7c1ab ack=00000000
 [vs_0][fw_0] eth3:i[64]: 173.16.25.44 -> 192.168.2.134 (TCP) len=64 id=0
 TCP: 59589 -> 443 .S.... seq=b00da993 ack=00000000
 [vs_0][fw_0] eth3:i[64]: 173.16.25.44 -> 192.168.2.134 (TCP) len=64 id=0
 TCP: 24452 -> 443 .S.... seq=b7eab2df ack=00000000
 [vs_0][fw_0] eth3:i[71]: 173.16.25.44 -> 192.168.2.134 (TCP) len=71 id=0
 TCP: 24452 -> 443 F..PA. seq=b7eac473 ack=aaeba7f0
 [vs_0][fw_0] eth3:i[71]: 173.16.25.44 -> 192.168.2.134 (TCP) len=71 id=0
 TCP: 31668 -> 443 F..PA. seq=33425c0a ack=39f1e2fa
 [vs_0][fw_0] eth3:i[71]: 173.16.25.44 -> 192.168.2.134 (TCP) len=71 id=0
 TCP: 59589 -> 443 F..PA. seq=b00db2f8 ack=5c949cea
 [vs_0][fw_0] eth3:i[71]: 173.16.25.44 -> 192.168.2.134 (TCP) len=71 id=0
 TCP: 10589 -> 443 F..PA. seq=96f7c6d9 ack=9c027709
 monitor: caught sig 2
 monitor: unloading
 CP-Firewall>

 

To see a 2-way network flow:

You can check the traffic to a source and destination in both directions:

fw monitor -e "accept (src=x.x.x.x and dst=x.x.x.x) or (src=x.x.x.x and dst=x.x.x.x);"

Example (from/to 172.16.125.81 to 192.168.1.84)

CP-Firewall> fw monitor -e "accept (src=172.16.125.81 and dst=192.168.1.84) or (src=192.168.1.84 and dst=172.16.125.81);"
 monitorfilter:
 Compiled OK.
 monitor: loading
 monitor: monitoring (control-C to stop)
 [vs_0][fw_17] bond1.102:i[84]: 192.168.1.84 -> 172.16.125.81 (ICMP) len=84 id=52498
 ICMP: type=8 code=0 echo request id=22608 seq=1
 [vs_0][fw_17] bond1.102:I[84]: 192.168.1.84 -> 172.16.125.81 (ICMP) len=84 id=52498
 ICMP: type=8 code=0 echo request id=22608 seq=1
 [vs_0][fw_17] bond1.101:o[84]: 192.168.1.84 -> 172.16.125.81 (ICMP) len=84 id=52498
 ICMP: type=8 code=0 echo request id=22608 seq=1
 [vs_0][fw_17] bond1.101:O[84]: 192.168.1.84 -> 172.16.125.81 (ICMP) len=84 id=52498
 ICMP: type=8 code=0 echo request id=22608 seq=1
 [vs_0][fw_4] bond1.101:i[84]: 172.16.125.81 -> 192.168.1.84 (ICMP) len=84 id=24621
 ICMP: type=8 code=0 echo request id=13742 seq=30840
 [vs_0][fw_4] bond1.101:I[84]: 172.16.125.81 -> 192.168.1.84 (ICMP) len=84 id=24621
 ICMP: type=8 code=0 echo request id=13742 seq=30840
 [vs_0][fw_4] bond1.102:o[84]: 172.16.125.81 -> 192.168.1.84 (ICMP) len=84 id=24621
 ICMP: type=8 code=0 echo request id=13742 seq=30840
 [vs_0][fw_4] bond1.102:O[84]: 172.16.125.81 -> 192.168.1.84 (ICMP) len=84 id=24621
 monitor: caught sig 2
 monitor: unloading
 CP-Firewall>

As you can see, this is a very helpful and flexible command, you can combine the OR and AND operators as you need and capture the information into a .pcap file and analyze it later with Wireshark.

Thank you to Juan Ochoa for his work on this article.

Key Takeaways
  • Use the Check Point “fw monitor” command as an alternative to SmartView Tracker for inspecting traffic through the firewall.
  • On clusters, “fw monitor” only shows traffic on the active member, which can be identified using the “cphaprob state” command.
  • SecureXL may hide some traffic from “fw monitor” captures, so it may need to be disabled with “fwaccel off” (and re-enabled with “fwaccel on”) during troubleshooting.
  • Host-specific traffic can be captured with filters such as fw monitor -e "accept host(x.x.x.x);" to see all traffic to and from a single IP.
  • Network or flow-based captures can be created using logical expressions like source/destination filters and netmasks (e.g., /32 for host, /26 for subnet) combined with AND/OR operators.
  • The four “fw monitor” capture points (i, I, o, O) allow analysis of packets at pre-inbound, post-inbound, pre-outbound, and post-outbound stages, and results can be exported to .pcap files for Wireshark analysis.

We have hundreds of automation elements to prevent problems from occurring in your environment. Check out our top picks for Check Point firewalls automation


Published in:

Related content

Three armored figures walking toward a futuristic Las Vegas skyline with pyramids, glowing orb, and "Welcome to Fabulous Las

Your journey to intelligent NetOps begins at Cisco Live

Visit BlueCat’s booth or book a meeting now to learn more about how our solutions can help you build a network that supports constant change.

Read more
Stacked colorful wooden directional arrows on a post by a calm seaside with distant hills and blue sky

Replace BIND and ISC with Micetro DNS/DHCP Server (MDDS)

Tired of patching and manually configuring BIND DNS and ISC DHCP? Discover how Micetro MDDS appliances can replace them for modern DDI.

Read more
Row of orange industrial robotic arms positioned along an automated conveyor belt in a factory setting

Automate it all in Integrity with REST v2 API-first DDI management

Discover API-first DDI with Integrity X by using REST v2 to automate DNS, DHCP, and IPAM for scalable, secure network operations.

Read more
Three colleagues at monitors collaborating, overlaid with network, analytics, cloud, and gear icons.

Agentic AI adoption in network observability propels NetOps teams

Network observability is crucial for today’s networks and even more capable with agentic AI, according to new Omdia and BlueCat research.

Read more

⏳ Cisco Live is almost here. Put BlueCat on your agenda for smarter, more secure networks.