Troubleshoot Check Point Traffic with fw monitor and cpview

Before you run this

fw monitor is Check Point's kernel packet-capture tool: it shows you a packet at four fixed points as the gateway inspects it, so you can tell where a flow is being dropped. cpview is a live, top-style performance dashboard for CPU, memory, connections, and throughput. Both are diagnostic and read-only — neither changes your policy or configuration.

Both run from expert mode, which is the root shell on Gaia, so you need the expert password. If you only have clish access you cannot run these until you type expert and authenticate.

That said, treat this with a gateway operator's caution:

fw monitor runs in the kernel and adds CPU load. On a busy gateway a wide, unfiltered capture can push utilisation up. Always filter to the host or flow you care about, and stop the capture (Ctrl+C) as soon as you have what you need. Run it during a maintenance window on a heavily loaded box.
Keep a separate console or out-of-band SSH session open. You are unlikely to lock yourself out with a capture, but if you go on to touch SecureXL (see below) you want a second way in.
Test your filter mentally first. Read the expression before you hit Enter — a too-broad filter dumps far more than you expect.
The one config-changing thing here is fwaccel off. Disabling SecureXL to make all traffic visible to fw monitor is a change that hurts performance and must be done in a window. Its undo is simply fwaccel on, and you should back up first: take a Gaia snapshot (System Management → Snapshot Management, or the add snapshot command in clish) before you touch anything, so you have a clean rollback.

Neither tool writes to your policy database, so there is nothing to roll back from the capture itself.

Assumptions

I'm writing for a Gaia R81.20 security gateway, single gateway (not VSX), working from expert mode. The fw monitor INSPECT expression syntax shown here has been stable across R80.x and R81.x. Menu paths for snapshots match the R81.20 Gaia portal. If you're on a much older version, the classic syntax still holds but some of the newer flags may not.

The four inspection points

fw monitor taps a packet at four positions relative to the firewall inspection module, and prints each one on its own line:

i — pre-inbound (packet just arrived, before the inbound policy)
I — post-inbound (survived inbound inspection)
o — pre-outbound (about to leave, before outbound policy)
O — post-outbound (survived outbound, on its way to the wire)

Lowercase means before the module, uppercase means after. This is the whole point of the tool: if you see a packet at i but never at I, it was dropped by inbound inspection. If you see i I o but no O, it died in the outbound path (often NAT or a routing/interface problem). Reading which of the four letters appear tells you where to look.

Capturing a specific flow

The mainstream, version-stable way is an INSPECT expression with -e. Note that accept here means "capture this packet into the monitor" — it is not a policy action and does not permit anything.

Capture everything to or from one host (replace 192.0.2.10 with your real address):

fw monitor -e "accept host(192.0.2.10);"

Narrow it to one direction of one conversation:

fw monitor -e "accept src=192.0.2.10 and dst=203.0.113.5;"

Filter on a port as well — here TCP 443 in either direction between two hosts:

fw monitor -e "accept (host(192.0.2.10) and host(203.0.113.5)) and port(443);"

192.0.2.10 and 203.0.113.5 are documentation-range placeholders; substitute your own client and server addresses.

Stop the capture with Ctrl+C.

There is also a newer simplified filter, -F, that takes a comma-separated 5-tuple (source, source port, destination, destination port, protocol) instead of an INSPECT expression. It's convenient, but the exact field order and its handling of direction have shifted between versions — confirm the format in the current fw monitor documentation before you rely on it, and use -e if you want something that reads the same on every box.

Limiting which points you see

If the four lines per packet are noisy, restrict the capture to specific points with -m. This shows only pre-inbound and post-inbound:

fw monitor -m iI -e "accept host(192.0.2.10);"

Run fw monitor -h to see the full, version-correct option list on your box rather than guessing flags.

Saving a capture for Wireshark

For anything you want to analyse properly, write it to a file with -o and open it off-box in Wireshark:

fw monitor -e "accept host(192.0.2.10);" -o /tmp/flow.cap

Let it run through the traffic you're chasing, stop with Ctrl+C, then copy /tmp/flow.cap off the gateway (SCP/WinSCP) and open it in Wireshark. The four inspection points come through as part of the frame data, so you can still see the i/I/o/O progression.

A note on SecureXL

This trips people up constantly: fw monitor sits at the firewall inspection points, so traffic that SecureXL has accelerated (offloaded) may not appear at every point — or at all. If you expect to see a flow and it's simply missing, check whether it's being accelerated:

fwaccel stat

You can disable acceleration to force everything through the slow path so fw monitor sees it:

fwaccel off      # this is a change — performance impact, window only
# ... run your capture ...
fwaccel on       # re-enable acceleration

Do this only in a maintenance window, and turn it back on the moment you're done. Newer fw monitor versions can capture accelerated traffic through additional capture points, so before you reach for fwaccel off, check the current fw monitor documentation for whether your version already shows the offloaded path.

Watching the gateway with cpview

While fw monitor tells you about one flow, cpview tells you how the whole box is doing. Launch it from expert mode:

cpview

Navigate the top menu bar with the left/right arrow keys, drill into a section with Enter / down arrow, and back out with the up arrow. You'll find Overview, CPU, Memory, Network, and connection statistics, all refreshing live. Press q to quit.

cpview also records historical statistics in the background, which you can browse rather than only watching the live view — the in-tool help and the Check Point SecureKnowledge article for cpview document the history keys for your version. I'd rather point you there than name a keystroke that may have moved.

Use the two together: when fw monitor shows a flow dropping at a certain point, cpview tells you whether the box is starved (a hot CPU core, exhausted connection table) or healthy.

Verify it worked

fw monitor: generate the traffic you're testing (a ping, curl, or the real application) and confirm packets for your host appear. Seeing all four points i I o O for a flow means it passed cleanly; a flow that stops at one letter shows you exactly where to investigate. An empty capture usually means your filter is wrong or the flow is accelerated — recheck the addresses and fwaccel stat.
cpview: you'll know it's working when the figures update every couple of seconds. Nothing to verify beyond that.

Undo / cleanup

There is nothing to undo for the captures themselves — both tools are read-only and stop when you press Ctrl+C or q. Delete any .cap files you no longer need from /tmp. The only action that needs reversing is disabling acceleration: run fwaccel on and confirm with fwaccel stat that SecureXL is enabled again. If you took a snapshot before starting, you can also revert to it from System Management → Snapshot Management in the Gaia portal, but for read-only troubleshooting you won't need to.

For exact, version-correct syntax and options, check the Check Point SecureKnowledge articles for fw monitor and cpview, and the Gaia Administration Guide for your release.