Reconstruct the exchange and defend your conclusion
For a typical TCP connection, look for client SYN, server SYN/ACK, and client ACK before application data. Sequence numbers track bytes and acknowledgements identify the next expected byte. Wireshark often presents relative sequence numbers to make them easier to read. A successful handshake supports transport connectivity at that moment; it does not prove that authentication, TLS negotiation, or the application succeeded. UDP has no equivalent transport handshake, so correlate requests and responses using application fields and timing.
Follow the dependencies in order. A client may obtain configuration through DHCP, resolve a local next hop through ARP, ask DNS for a service address, and then contact the service. Cached information means not every step appears in every capture. DNS response codes, ICMP errors, TCP resets, and application status codes answer different questions. A reset ends or rejects a connection; its presence alone does not identify the process or middlebox responsible.
Repeated SYNs with no visible SYN/ACK suggest an unanswered connection attempt at this capture point. They do not establish whether a firewall dropped the traffic, the server was unavailable, or the capture missed replies. Retransmissions can accompany loss or delay, while capture gaps and reordering can complicate their interpretation. A zero receive window indicates that the receiver is advertising no space for more data at that time. Compare timing and both directions before assigning a bottleneck.
Security analysis uses the same evidence discipline. Attempts to many ports, repeated periodic connections, or unexpectedly large outbound transfers may justify investigation, but can also have legitimate explanations. Establish a baseline, identify the owning process and asset, and correlate endpoint, DNS, proxy, or firewall records. Write down the observation, possible explanations, confidence, visibility limits, and the next check that could distinguish them.
Use the synthetic trace below as a paper lab. Times are seconds from capture start. No packet file is needed: the rows are deliberately simplified observations, not Wireshark output. The documentation addresses and portal.example name are illustrative. First identify the DNS query and answer, then pair the two TCP attempts with their destination, and finally locate the transport handshake and application response.