Check Point fw monitor Sees Nothing: the Capture Position Most People Skip

Check Point · Techclick CLI troubleshooting lab

You ran fw monitor and got zero packets. The user is still failing. Someone says the firewall is not in path.

This is a live-ticket style lesson from Techclick Infosec. You will isolate the fault with CLI first, then prove the fix with one clean packet or log.

What you will be able to do

• Name the first CLI command to run on Check Point for this ticket

• Separate the layer that is actually broken from the layer people blame

• Apply one scoped fix instead of a global disable

• Prove the ticket closed with a session, log, or counter

Quick answer

fw monitor has inspect points. If you filter on the NAT'd address at the wrong point, you capture silence on a busy box.

Why this ticket shows up

i (pre-inbound), I (post-inbound), o, O see different IPs because NAT happens in the middle. The wrong IP at the wrong point looks like 'no traffic'.

Symptoms operators actually see

• Empty fw monitor

• tcpdump on the same NIC sees the packet

• NAT is in play

• Filter used the inside IP on the outside point

CLI first — copy this block

Run these on the Check Point device or console named in the ticket. Do not skip the first show command — it tells you which later command matters.

fw monitor -e "accept host(10.1.1.20);"
fw monitor -e "accept (src=10.1.1.20 or dst=10.1.1.20);" -p all
fw ctl zdebug + drop | grep 10.1.1.20
tcpdump -nni eth0 host 10.1.1.20

How to read that output

tcpdump sees wire packets. fw monitor sees inspect points. If tcpdump has it and fw monitor does not, your filter IP is wrong for that point or SecureXL is accelerating past you.

Triage order

1. tcpdump first to prove the packet hits the NIC

2. fw monitor with both pre-NAT and post-NAT IPs

3. Check fw ctl zdebug drop

4. Disable SecureXL only for the test if needed

5. Restore acceleration

Classic traps

What you see	Real cause	Fix
Firewall not in path	Filter used the wrong IP	Use both IPs
Leave zdebug on	High CPU	Stop it
Disable SecureXL forever	It was a capture issue	Re-enable

Proof the ticket is closed

• fw monitor shows i/I/o/O

• Drop reason if any is identified

• SecureXL back on

Say this in an interview

Empty fw monitor is a filter or inspect-point mistake until tcpdump agrees the packet is absent.

---

Need the full vendor lab, mock interview, and production runbooks? Techclick trains Palo Alto, Zscaler, F5, FortiGate, Check Point, Cisco ISE, Azure and routing with live CLI — start at https://www.techclick.in/