Create a Post
Showing results for 
Search instead for 
Did you mean: 

Tip of the Week - fw monitor

Arguably, the most popular tool to troubleshoot traffic crossing a Security Gateway is fw monitor. However, not all security engineers and administrators are familiar with the full potential of fw monitor.

The tool is extremely powerful, flexible and versatile.

To unleash its full potential, please look into the article of the week: What is FW Monitor? 

TO READ THE FULL POST it's simple and free

Hi Val



I have printed out on both side in A5 format, and then laminated those PDF that I have listed below.


Check Point CLI Reference Card – v2.1

Check Point fw monitor cheat sheet – 20180929


if I am in doubt I can alway take the document out for a reminder.


Just a nice a idea.





I like that


good work mate nicely done


Here are some more additions to R80.20 and "fw monitor". For details see here:

R80.x Performance Tuning and Debug Tips – fw monitor 

Whats new in R80.20:

  • With R80.20 it is no longer necessary to disable SecureXL.
  • The new fw monitor chain modules (SecureXL) do not run in the virtual machine (vm):

        SecureXL inbound (sxl_in)                 > Packet received in SecureXL from network

        SecureXL inbound CT (sxl_ct)           > Accelerated packets moved from inbound to outbound processing (post routing)

        SecureXL outbound (sxl_out)            > Accelerated packet starts outbound processing

        SecureXL deliver (sxl_deliver)          > SecureXL transmits accelerated packet

  • There are more new chain modules:

        vpn before offload (vpn_in)                  > FW inbound preparing the tunnel for offloading the packet (along with the connection)

        fw offload inbound (offload_in)            > FW inbound that perform the offload

        fw post VM inbound  (post_vm)            > Packet was not offloaded (slow path) - continue processing in FW inbound

  • New chain key 00000000 for SecureXL offloading
  • New fw monitor inspection points:
    • R80.10: e, E
    • R80.20: id, iD, iq, iQ, oq, oQ




Hi Kim,

You found more informations here: 




Hi Heiko,

Thanks a lot.

Great work. differently one I want to laminate and put near my desk when doing troubleshooting work.




Hi guys, 


I am little bit confused here. I thought that session generated from A(60325) to B(443) will always go pre-i > post-I > FW Kernel/L3 > pre-o > post-O and this is SYN packet. Then I guess the session is in session table and not processed by FW kernel. But because the reply needs to go back, I suppose we can see this with FW monitor also, but it will again look like B(443) to A(60325) pre-i > post-I > FW Kernel/L3 > pre-o > post-O (if accel is off).   

My confusion is based on the example bellow from one of the cheat sheet, where part two is clearly reply to part one. I would expect to see part two be same like part one only with o/O and then same 8 lines for traffic back as in part two but again with i/I and o/O. Can anyone one of you make this clear for me?

# fw monitor
monitor: getting filter (from command line)
monitor: compiling
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[fw_1]eth1:i[60]: -> (TCP) len=60 id=3017
TCP: 60386 -> 22 .S.... seq=1eaf882c ack=00000000
[fw_1]eth1:I[60]: -> (TCP) len=60 id=3017
TCP: 60386 -> 22 .S.... seq=1eaf882c ack=00000000

Part 2
[fw_1]eth1:o[60]: -> (TCP) len=60 id=1166
TCP: 22 -> 60386 .S..A. seq=bb543e77 ack=1eaf882d
[fw_1]eth1:O[60]: -> (TCP) len=60 id=1166
TCP: 22 -> 60386 .S..A. seq=bb543e77 ack=1eaf882d


>>My confusion is based on the example bellow from one of the cheat sheet

@ttyser , I cannot answer for a third party without details. It might be, something is omitted, or a specific filter is applied that hides NAT-ed part of the communication.