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(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