FW monitor – the new way.

The other day i was performing troubleshooting on a firewall, and wanted to make a capture using fw monitor.

As i normally do, i performed the commands mentioned in sk30583 with the ”-e” flag, but the other day i got an error.

Then i remembered… going forward from R80.x they made some new commands.

I don´t really know when or why this only impacts some of the R80 systems, (and i have not spend time researching this topic) but my guess is that it is dependant on the patchlevel of the system.

Anyway – the new commands can also be found at checkpoint Sk30583.

Go to chapter 8 ”Capture Examples of “-F” flag”


(Remove the brackets from the command)

fw monitor -F ”{src IP}, {src port}, {dst IP}, {dst port}, {protocol number}”:

Example captureing ssl trafic on port 443.

fw monitor -F ”0, 0, 0, 443, 0”

Example capturing traffic from source ip

fw monitor -F ”, 0, 0, 0, 0”

For more fw monitor

R81 is out in Early Availability

It looks like Checkpoints R81 is comming soon. It is now available in the Public Early Availability program.

This means that if you have a Checkpoint subscription, you can now participate in EA, and download the EA release.

And there is a lot of changes, but here is a few…

  • Custom intelligence feeds can now be managed through SmartConsole. Add, delete or modify feeds fetched by the Security Gateways as well as import files in a CSV or STIX 1.x formats.
  • Out of the box policy profiles based on business and IT security needs.
  • Azure Active Directory support in Identity Awareness – Use Azure AD users and groups for authentication and authorization using Identity Awareness Access Role picker.
  • Hit count for NAT rules.
  • Cross-Domain Management Server Search lets you search for objects across multiple Domain Management Server databases.

And much more…

The Checkmates forum have the improvements listed.


Troubleshooting with fw monitor

This is probably the command i use the most when troubleshooting traffic issues.
The reason is that we can follow packets flow through the kernel / firewall engine, and see if it leaves the interface.
There are 4 inspection points when a package passes through a Security Gateway. (See the picture)
You need to be in expert mode to use the “fw monitor” command.

[Expert@GW1:0]# fw monitor -e “accept host(;”
monitor: getting filter (from command line)
monitor: compiling
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_1] Mgmt:i[66]: -> (UDP) len=66 id=10534
UDP: 57317 -> 53
[vs_0][fw_1] Mgmt:I[66]: -> (UDP) len=66 id=10534
UDP: 57317 -> 53
[vs_0][fw_1] eth1:o[66]: -> (UDP) len=66 id=10534
UDP: 57317 -> 53
[vs_0][fw_1] eth1:O[66]: -> (UDP) len=66 id=10534
UDP: 57317 -> 53
[vs_0][fw_0] Mgmt:i[62]: -> (UDP) len=62 id=47650
UDP: 58094 -> 53
[vs_0][fw_0] Mgmt:i[65]: -> (UDP) len=65 id=0
UDP: 55619 -> 53

You can also use source or / and destination

[Expert@GW1:0]# fw monitor -e “accept src= and dst=;”

So how does this help me prove that the firewall is not the problem ???
Lets take a look at how the packet is passing through the firewal virtual machine.

The shown interfaces are just examples for simplification, just as the return traffic would be the opposite regarding to the iIoO flow.

So if you see all 4 types “i I o O” its safe to say that the package have left your firewall.

Using the new fw monitor