Packet Capture with tcpdump: Filters, Placement, and What Encryption Leaves

Packet capture is the ground truth of network troubleshooting. When the logs disagree and the vendors blame each other, the packets settle it. The skill is not running the tool — it is capturing the right traffic in the right place and knowing what you can still learn when the payload is encrypted.

Filters are the whole technique

An unfiltered capture on a busy interface produces gigabytes of traffic you will never read. Berkeley Packet Filter expressions applied at capture time keep the file small and the analysis possible.

The vocabulary is compact. Filter by host to capture traffic to or from an address, by net for a range, by port for a service, by protocol for tcp, udp or icmp, and by direction with src or dst. Combine with and, or and not.

Two distinctions matter. Capture filters are applied by the kernel before packets reach the tool, which is efficient and irreversible — what you filtered out is gone. Display filters in an analysis tool operate on an already-captured file, which is reversible and requires having captured it. The practical approach is a capture filter broad enough not to miss context, narrowed with display filters afterwards.

Capture the full packet rather than truncating, unless storage forces otherwise. A capture missing the payload cannot answer the question you have not thought of yet.

Where to capture

Placement determines what you see, and getting it wrong wastes the exercise.

On a switched network, a host's interface sees only its own traffic plus broadcast and multicast. To capture someone else's, you need a SPAN or mirror port configured on the switch, or a network TAP inserted in the link.

The difference is worth knowing. A SPAN port is configured in software, costs nothing extra, and drops packets under load because mirroring competes with forwarding — so it is fine for troubleshooting and unreliable for evidence. A TAP is a physical device in the path, passes every packet including errors, and is what you use when completeness matters.

Capture at both ends when investigating a path problem. Comparing what one side sent with what the other received identifies exactly where packets are lost or altered, which no single capture can do.

What you see when traffic is encrypted

Most traffic is encrypted, and the common conclusion — that capture is therefore useless — is wrong.

The TLS handshake is in the clear. The Server Name Indication field names the host being requested, the certificate is visible, and the negotiated versions and cipher suites are visible. That tells you which site was contacted and whether the cryptography is acceptable, without any content.

Timing, volume and direction remain. A connection at a consistent interval with small consistent payloads is beaconing. A large upload to an unfamiliar destination is exfiltration. Neither requires decryption — and that is the same metadata that flow collectors work from, at higher resolution.

DNS is frequently still visible, which resolves names for everything else in the capture — unless encrypted DNS is in use, as under DNS over HTTPS, which removes one of the most useful sources in a capture.

Decryption is possible where you hold the server's key and the session did not use forward secrecy, or where the client exports session keys. With modern cipher suites the first no longer works, which is why inspection happens at a proxy instead — the arrangement under TLS proxies.

What packets settle that logs cannot

Whether a packet arrived at all, which separates a network problem from an application problem immediately. Retransmissions and duplicate acknowledgements, which indicate loss. TCP window behaviour, which distinguishes a slow application from a constrained network. Malformed frames and the interface errors discussed under CRC and frame check sequence errors. Fragmentation and path MTU problems, which produce the classic symptom of small requests working and large ones hanging.

And the two-capture comparison, which is the only way to prove that a middlebox altered or dropped traffic.

Legal and practical limits

A capture contains other people's communications. Depending on jurisdiction, capturing traffic you are not party to may require authorization, notice to employees, or both, and the resulting file is personal data with retention obligations.

Handle it accordingly: capture the minimum needed, store it access-controlled, delete it when the investigation ends, and remember that a capture from a period before TLS was universal may contain credentials in plaintext.

Where the capture is evidence, hash the file on creation and preserve the original, analysing a copy — the handling described under order of volatility.

Exam angles

Know packet capture as recording frames from an interface, with BPF capture filters applied by the kernel and display filters applied afterwards. Know that a switched network requires a SPAN/mirror port or a TAP to see other hosts' traffic, and that SPAN drops under load while a TAP does not. Recognize that SNI, certificates, timing and volume remain visible in encrypted traffic, and that captures contain personal data with legal and retention implications.