CliDeck
PlatformLog in
Workspace

FortiGate CLI Packet Capture: Use a Filter, a Count, and a Stop Condition

Runbooks
#fortigate#operational-evidence#runbooks#remote-operations#Runbooks
← Back to Blog

Short answer

For an approved FortiGate traffic check, start the CLI sniffer with a narrow interface and filter, a finite packet count, and a known stop method. Capture the terminal output before starting. A blank result is inconclusive until the interface, VDOM, traffic generation, filter, and hardware-offload path have been checked.

Scope and the question to answer

This runbook uses the FortiOS 7.6.3 CLI packet-sniffer workflow. Record the exact FortiGate model and installed build, and inspect the available command help before adapting it. Interface names, VDOM access, diagnostic permissions, and acceleration behavior vary across deployments.

Define one observation: for example, whether a permitted test connection from a known endpoint reaches the expected interface. Agree on the test owner, start time, duration, and allowed traffic before opening the capture.

This is an observation workflow. Enabling policy packet capture, changing ASIC offload, clearing sessions, and starting debug flow are separate operations with different effects. Do not add them to a basic sniffer task without a reviewed troubleshooting plan.

Prepare private logging and the correct context

Start session logging before running the sniffer. Record the device, build, VDOM, interface, synthetic test description, and collection time in the private task record. Packet headers expose network addresses and relationships even when payload bytes are not printed.

Use the VDOM that owns the traffic and an account authorized for the diagnostic operation. Confirm the interface name from the site's current inventory. Do not assume that every appliance calls its relevant interface port1.

Check syntax at the authorized CLI prompt:

diagnose sniffer packet ?

Keep a second management or console session available if the collection terminal becomes busy. Agree how to stop the capture before testing the command.

Use one bounded example

The following example uses a synthetic private endpoint and interface name. Replace them with the approved target:

diagnose sniffer packet port1 'host 192.168.10.20 and tcp port 443' 4 20 l

The arguments mean:

ArgumentPurpose
port1Selected observation interface
Quoted filterOnly the chosen host and TCP port
4Packet headers with interface names
20Stop after the packet count is reached
lAbsolute local timestamps

Verbosity 4 helps locate traffic without printing packet payload data. Keep the single quotes around the filter and use ordinary straight quote characters when pasting the command.

The count is a packet limit, not a wall-clock timer. If fewer than 20 packets match, the capture can keep waiting. Set an operator deadline as well, and press Ctrl+C to stop when that deadline arrives or the needed observation is complete.

Do not substitute count 0 into an unattended runbook: continuous output needs active supervision and a separate stopping plan. Avoid any and an unfiltered capture as the first response to an empty result; widening the scope can collect unrelated traffic without resolving the original question.

Read the observation carefully

Coordinate a fresh test connection during the capture window. Inspect direction, interface, timestamps, and the expected endpoint pair. Record whether the collection ended at its packet count or was stopped manually, and preserve the final prompt.

Seeing a packet at one interface does not prove a successful application transaction. Combine the capture with the endpoint's test result and other approved diagnostics. Account for address translation when deciding which address should be visible at the observation point.

Verification note: missing packets do not prove missing traffic

The normal CLI sniffer may not see packets handled entirely by an offload processor. A working accelerated session can therefore produce a misleadingly quiet CPU-side capture.

Before changing anything, review these possibilities:

  • The test did not run during the collection window.
  • The host, protocol, port, interface, or VDOM is wrong.
  • Address translation changed the address visible at this interface.
  • The relevant established flow is hardware-offloaded.

Do not disable offloading or clear sessions merely to produce visible lines. Those actions can affect processing load and existing connections. Use an approved model-specific plan, including the supported hardware-sniffer path where applicable, and define how normal operation will be verified afterward.

Close the task

Confirm that the capture stopped and the CLI prompt returned. Save the command, actual filter, start and end times, stop reason, observed header evidence, endpoint result, and unresolved visibility limits.

Keep originals private and sanitize excerpts before sharing. CliDeck Workspace can hold the transcript and command handoff record so the next engineer knows what was observed and what remains unknown.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides