Packet Capture as a Decision Procedure¶

Packet capture cuts a fault in half: it answers whether traffic left the device and whether anything came back. That answer eliminates most candidate causes in one step, which is why it belongs early in an investigation. This page is a method, not a tcpdump syntax reference — for the wider command set see Diagnostic Commands, Common Issues and Port Mirroring (SPAN).

The Core Question¶

Capture on the interface the traffic should be leaving through, filter tightly to the far-end address, and read the direction of each packet. There are three possible observations, and they lead to three completely different investigations.

Observation	Meaning	Where to look next
Nothing leaves	The local device is not sending at all — a routing decision sent it elsewhere, the process bound to the wrong interface or source address, a local rule dropped it, or the application never attempted the connection	Local configuration: routing table, interface binding, outbound rules, the application itself
Outbound only, no replies	Packets are being emitted but nothing answers — the path or the far end is discarding them	Upstream device, the provider, the far-end service, or a protocol/parameter mismatch causing a silent discard
Both directions	The network path works in both directions — the fault is above the network layer	Authentication, certificates and crypto negotiation, application logic

Two rules make the reading reliable:

Capture on the egress interface, not the internal one. Traffic can be present on a LAN interface and never reach the WAN because of a routing or NAT decision in between.
Filter to the far-end address and, where known, the port. Anything broader and the genuinely interesting packets are buried.

"Outbound Only" Is Not Proof of a Block¶

The most common misreading is treating "packets go out, nothing comes back" as evidence that something upstream is blocking traffic. It is not.

A server that receives a packet it cannot validate may discard it silently — no reply, no error, and frequently no log entry at the far end either. Seen from the sending side, that is indistinguishable from a firewall dropping the packet in transit. The capture looks identical in both cases.

This behaviour is deliberate in a broad class of protocols. Anything that authenticates its very first packet — many VPN and tunnelling protocols work this way — will discard a packet whose authentication or key material does not match, so that the service does not answer scanners or reveal that it is listening. A wrong pre-shared key, a mismatched authentication mode, or a client configured for one variant of a protocol while the server expects another all produce the same symptom: outbound packets and total silence. See OpenVPN Client Troubleshooting for a worked example.

So "outbound only" narrows the fault to path or far end. It does not distinguish between them. That takes a second test.

Discriminating: Change One Variable¶

Having established that traffic leaves and nothing returns, isolate the cause by altering exactly one thing per test and re-reading the capture.

A different port on the same host. If one port answers and another does not, the host is reachable and the problem is service-specific.
A different host, same port and protocol. If a second destination answers, the path and the local configuration are fine and the original far end is the problem.
A different protocol to the same host. This is the sharpest test. If a TCP connection to a host completes while UDP to that same host stays silent, the host is reachable, the route works and nothing generic is filtering the flow — the fault is protocol- or service-specific, not a path block.
A different source interface or gateway, where more than one exists, separates a provider-side block from a local one.

Changing two variables at once eliminates nothing.

Where the Capture Sits Relative to the Rule Set¶

The capture point is not symmetric, and the asymmetry changes how the result is read. Netgate documents a capture as the first thing to see a packet arriving on an interface and the last thing to see a packet leaving it: inbound traffic is captured before firewall rules, NAT and other processing; outbound traffic is captured after all of that has run.

Inbound — a packet appears in the capture even when a rule is about to discard it. That separates two cases which look identical from the client and share no fix:
- "Never arrived" — nothing in the capture. The problem is upstream of this device: routing, VLAN tagging, the switch path, or the sender.
- "Arrived and was dropped" — present in the capture, absent from the state table, usually present in the block log. The problem is this device's rule set.
Outbound — a packet blocked on the way out never reaches the capture at all. "Nothing leaves" on an egress capture therefore includes a local rule or floating rule among its causes, alongside routing and source binding. Check the block log before concluding the traffic was never generated — see Firewall Rules & Aliases.

See Stateful Firewalls and State Tables for what happens to an inbound packet after it clears the capture point.

Running a Capture in pfSense¶

Diagnostics → Packet Capture runs tcpdump against a chosen interface and returns the result in the browser. The settings that matter for this method:

Interface — the egress interface being tested; assigned VLAN interfaces are selectable in their own right
Protocol and Port — narrow the output to the flow under test
Host address — the far-end address, or a CIDR subnet; multiple space-separated values are accepted
Packet Count — packets to collect before the capture stops automatically
Packet Length — bytes captured per packet; the default truncates payload, which is sufficient for a direction check but not for payload analysis
Promiscuous Mode — includes traffic not addressed to the appliance's own MAC address

The form has been restructured between releases — recent versions separate the filter criteria from the capture settings and add VLAN-tag and MAC-address criteria — so confirm the labels on screen rather than following a documented layout. Vendor documentation lags the shipping GUI.

Keep the filter tight. An unfiltered capture on a busy interface is unreadable within seconds. Start with host plus protocol, then add the port once the flow is visible. View renders the result at a selectable level of detail and Download retrieves the capture file for a full protocol analyser elsewhere.

The same capture can be taken from a shell. tcpdump needs the operating-system device name rather than the friendly interface name — Interfaces → Assignments shows the mapping, and a VLAN subinterface takes the form igc1.20. From a shell on the pfSense appliance (SSH, or the console menu's shell option):

tcpdump -ni igc1 -c 100 host 203.0.113.10 and udp

-n suppresses name resolution so the output does not stall on DNS; -c stops the capture after a set number of packets. Without -c the command runs until interrupted, which makes it a poor fit for Diagnostics → Command Prompt, where the page returns output only once the command exits.

Cisco switches vary. Classic IOS access switches have no on-box capture for transit traffic; some IOS-XE platforms provide Embedded Packet Capture (monitor capture, from privileged EXEC), but availability and buffer limits are platform-specific and worth confirming against the platform's own command reference. Where it is absent, mirror the port and capture on the attached host — see Port Mirroring (SPAN).

Complementary Checks¶

A capture says whether packets moved. Two other checks say why, and are most useful run alongside it.

A port test confirms something is listening at the far end. From a Linux/macOS shell, nc -vz <host> <port> for TCP. From Cisco IOS privileged EXEC, telnet <host> <port> opens a raw TCP connection for the same purpose, without Telnet being enabled as a management protocol on the local device. A UDP port test cannot distinguish "open" from "silently discarding" — see TCP vs UDP & Common Ports.
The service's own log, read against the same time window as the capture. The log records the reason for a rejection — a validation failure, an unsupported parameter, an expired credential — where the capture records only that a packet arrived or did not. Where logs are centralised, see Syslog.

Reading the Firewall Log¶

Under Status → System Logs → Firewall, blocked packets are logged by default and passed traffic only where a rule is explicitly set to log. Two consequences follow:

No log entry at all usually means the traffic never reached the firewall — the "nothing in the capture" case above.
A block entry proves the packet arrived, so the investigation moves to which rule matched and why.

A WAN interface carries routine inbound noise that is logged as blocked without being an attack:

Log entry	Explanation
Multicast group queries from the upstream router's address	Normal IGMP/MLD querier behaviour on the provider segment
Router advertisements and neighbour discovery traffic	Standard IPv6 operation on a shared segment
Late TCP replies blocked shortly after a session ends	The reply arrived after its state entry expired, so no state matched it
Broadcast and link-local traffic from neighbouring subscribers	Normal on a shared access network

Unsolicited inbound connection attempts to common ports are constant background scanning on any public address, and a default-deny rule set blocks them as designed. Investigate changes in volume and pattern, not the presence of entries.

Where This Fits¶

Use capture to decide the direction of an investigation, then switch tools:

Nothing leaves → local configuration, routing and interface state — Diagnostic Commands
Outbound only → change one variable, then examine the far-end service and its log
Both directions, but slow or lossy → the fault is throughput or latency, not reachability — Performance Troubleshooting
Both directions, and clean → stop looking at the network — Common Issues