GUI live capture — when to use the web interface and when to drop to the shell

OPNsense ships a graphical live capture tool accessible from the web UI. It runs tcpdump on the firewall and streams the output into the browser. The operator who knows what it can and cannot do uses it for quick “is the packet on the wire” checks and drops to the shell for sustained or precise work.

This lesson covers the GUI live capture, its pcap file output, and the discipline of choosing between GUI and shell.

The GUI live capture page

The GUI capture lives under Interfaces → Diagnostics → Live Capture (in older versions, Utilities → Live Capture). The page presents a form: interface selection, BPF filter expression, count or duration, and a Start button. Below the form, the captured packets stream as the firewall prints them.

The page:

• Runs tcpdump on the firewall with the selected interface and BPF filter.
• Streams the lines back to the browser over an AJAX poll or websocket (depending on the OPNsense version).
• Optionally writes the capture to a pcap file that can be downloaded at the end.

The operator types the filter in the same syntax tcpdump uses. A filter of host 192.0.2.50 and port 443 produces only frames matching that tuple.

$ pfSsh.php playback svc stop dumpcapservice

Stopped dumpcap service.

What the GUI capture does well

The GUI capture is good for:

• Quick “is the packet arriving” checks. Type a filter, click Start, watch a few packets, Stop. No file management, no rotation.
• Demonstrating traffic to a non-operator. The operator can show a colleague what is on the wire without handing over a pcap.
• Capturing from a remote desktop where the operator does not have shell access. The web UI is sometimes the only available interface.
• Capturing on systems where SSH is locked down. SSH access to the firewall is often restricted to a small set of source IPs; the web UI is broader.

What the GUI capture does poorly

The GUI capture is poor for:

• Long-running captures. The browser connection times out; the operator has to keep the page open; the streamed output fills the browser memory.
• High-volume captures. Streaming every line to the browser consumes CPU on both ends and can drop packets.
• Precise analysis. The browser displays plain tcpdump output; the operator cannot easily filter the stream, follow a TCP flow, or apply a display filter.
• Capturing to a pcap on the firewall for later download. The GUI does this — but the operator should be aware that the file is on /root (or wherever OPNsense stores it) and download it before the firewall rotates or deletes it.

Downloading the pcap

When the GUI capture writes to a file, the operator can download it from the page or from the firewall directly. The path is typically under /var/lib/pfsense/ or /usr/local/, depending on the OPNsense version. The file name is the one chosen in the form (or auto-generated).

The operator can pull the file via SCP, SFTP, or the GUI’s download button. The pcap can then be opened in Wireshark for offline analysis.

The discipline is to pull the pcap while the capture is fresh — long-running captures on the firewall can fill the disk. The operator should download the file, then delete it from the firewall to free space.

When to drop to the shell

The operator drops to the shell when:

• The capture needs to run longer than a few minutes.
• The capture volume is too high to stream.
• The filter needs BPF features the GUI does not expose (e.g. byte offsets, complex boolean expressions).
• The operator needs to rotate files (-G, -W) for sustained capture.
• The GUI capture is unresponsive or hangs.
• The operator needs to capture on a non-standard interface (a bridge member, a tunnel, a loopback alias).

$ tcpdump -ni igb0 -w /root/sustained.pcap -G 60 -W 1440 'host 192.0.2.50 or host 192.0.2.51'

tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
600 packets captured
600 packets received by filter
0 packets dropped by kernel

Reading GUI output

The GUI capture displays the same text tcpdump would. The operator reads it as described in the previous lesson: timestamp, link layer (only with -e), network layer, length, IP and transport endpoints, protocol-specific details.

The trap is that the GUI may not show all flags the operator expects. The default output verbosity is tcpdump’s default; the operator cannot easily pass -v or -e from the GUI. When the operator needs verbosity, the shell is the right tool.

The combined workflow

A typical troubleshooting session uses both:

1. GUI capture to localise the question. “Is the packet arriving on the WAN at all?” Capture on WAN with a permissive filter, watch for ten seconds.
2. Shell capture to collect evidence. Stop the GUI capture, start a shell capture with a precise filter to a pcap file. Run for the duration needed.
3. Download the pcap and analyse in Wireshark. Apply display filters, follow TCP streams, export the relevant slice.
4. Cross-reference with firewall logs and PF state. Confirm what PF decided about the captured packets.

The operator who treats the GUI capture as a debugging tool rather than a data collection tool misuses it; the operator who uses the GUI capture as a quick check and the shell capture as the source of evidence uses it correctly.

Summary

• The GUI live capture is a tcpdump wrapper with a streaming web UI; it is convenient for quick checks.
• The GUI capture is poor for long-running or high-volume captures; the shell is the right tool for those.
• Captures from the GUI can be saved as pcap files and downloaded; the operator should treat the pcap as the durable artifact.
• The GUI capture shows what was on the wire — not what PF decided. Cross-check with firewall logs and PF state.
• A typical session: GUI to localise, shell to capture, Wireshark to analyse.