Reading Packet Captures: A Security Engineer's Method

By Taylor Thomas · 2026-08-31

The difference between an engineer who gets answers from packet captures and one who drowns in them is not tool mastery. It is that the first arrives with a question. A capture is the closest thing the network offers to ground truth, and even ground truth in bulk is noise. It is a recording, not a guarantee: capture engines drop packets under load, timestamps and ordering reflect the capture path rather than perfect wire truth, and host-side NIC offload can record coalesced, oversized segments that never crossed the wire in that form — all of which matters whenever you treat absence as evidence. The method below is how experienced engineers make it speak.

Start With a Question, Not a Capture

Every useful capture session begins as a hypothesis: this client cannot reach this service, and I believe the traffic dies at the firewall. The hypothesis dictates everything that follows — where to capture, what to filter, and what evidence would settle it. Filter to the single conversation that tests the hypothesis: one client, one server, one port, one attempt. Read that conversation end to end before widening. An unfiltered capture scrolled in hope is how afternoons disappear; a five-packet filtered exchange read carefully is how problems resolve. Flow telemetry has its place — NetFlow answers “who talks to whom,” within what its exporter observed; the capture is for what happened inside one conversation.

Read the Handshake First

For TCP traffic, the three-way handshake is the highest-value read in the file. A clean SYN, SYN-ACK, ACK shows a handshake completed with something — usually the server, but possibly an in-path proxy or firewall completing it on the server’s behalf. It narrows the investigation without closing it: in-path security devices can still drop or reset the flow after establishment, once enough data packets have arrived for an application or URL verdict. Repeated SYNs with no SYN-ACK at your capture point mean the SYN or its reply is being lost, blocked, or ignored — or the reply is returning by an asymmetric path your capture does not see. An immediate RST in response to the SYN is a different fact entirely — something actively refused, whether a closed port on the server or a device in the path that rejects rather than drops. Silence and refusal implicate different suspects, and the handshake tells you which investigation you are in. A RST is also not proof the server sent it — devices in the path can inject resets — exactly the ambiguity paired captures resolve.

What Encryption Leaves Visible

When the flow under investigation is TLS, the question is what a capture still shows without decryption. For TLS over TCP captured outside any lower-layer encrypted tunnel, the TCP layer stays readable: handshakes, resets, retransmissions, timing, sizes. In TLS 1.3, the initial ClientHello is normally readable — including the SNI extension naming the requested server. With Encrypted Client Hello, an outer ClientHello stays visible and may carry a public cover name, while the true server name travels encrypted inside. The server certificate, which an initial certificate-authenticated TLS 1.2 handshake sent in plaintext, is encrypted in TLS 1.3 when one is sent. In practice that is often enough: you can see the exchange begin, where it stops, and which side sent the last observable record — though past the ServerHello, TLS 1.3 encrypts the handshake messages themselves, so the exact failing stage is generally not identifiable without decryption. A connection that dies immediately after the ClientHello is consistent with a device objecting to what the handshake revealed — a hypothesis to corroborate against paired captures or device logs, since loss, version or cipher incompatibility, and plain server failure can end a flow at the same stage. A readable TLS alert names a TLS-layer error more precisely than a reset — but alerts are readable only before record protection is active, as with an alert answering the ClientHello; once it is, they travel encrypted, and many failures show up as silence rather than an alert at all.

Place Captures to Turn Absence Into Evidence

A single capture shows what its capture engine recorded at one point; localizing a drop takes two. Capture on both sides of the suspect device and the logic approaches arithmetic: a packet that appears on the ingress capture and never on egress died inside that box — once you have confirmed the packet was meant to be forwarded, that you captured the right egress path, and that filters or capture loss did not hide it. The pattern is a staple on Cisco Secure Firewall, where on-box capture shows what arrived and left, and Packet Tracer complements it by simulating a synthetic packet through the supported datapath phases — routing, NAT, access control — to show which policy would act on it; it cannot reproduce every stateful or application-layer verdict a live flow receives, which is why it pairs with captures of what live traffic actually did. NAT changes what you are matching on — the inside and outside captures may carry different addresses for the same conversation, an order-of-operations detail covered in our FTD NAT guide. The SNCF 300-710 blueprint puts the tools squarely in scope: objective 3.3 covers troubleshooting Firewall Threat Defense using tools, naming packet capture procedures and Packet Tracer among them, and the SNCF course drills the paired-capture method on real topologies until it is reflex.

Frequently Asked Questions