checkpoint troubleshooting

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”

Example.

(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 ”10.10.10.10, 0, 0, 0, 0”

For more 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(8.8.8.8);”
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_1] Mgmt:i[66]: 192.168.11.197 -> 8.8.8.8 (UDP) len=66 id=10534
UDP: 57317 -> 53
[vs_0][fw_1] Mgmt:I[66]: 192.168.11.197 -> 8.8.8.8 (UDP) len=66 id=10534
UDP: 57317 -> 53
[vs_0][fw_1] eth1:o[66]: 192.168.11.197 -> 8.8.8.8 (UDP) len=66 id=10534
UDP: 57317 -> 53
[vs_0][fw_1] eth1:O[66]: 192.168.11.197 -> 8.8.8.8 (UDP) len=66 id=10534
UDP: 57317 -> 53
[vs_0][fw_0] Mgmt:i[62]: 192.168.11.196 -> 8.8.8.8 (UDP) len=62 id=47650
UDP: 58094 -> 53
[vs_0][fw_0] Mgmt:i[65]: 192.168.11.196 -> 8.8.8.8 (UDP) len=65 id=0
UDP: 55619 -> 53

---

You can also use source or / and destination

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

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