TCP RST and Connection Reset PCAP Analysis: Who Closed the Connection and Why

Connection reset by peer is a common error in HTTP clients, databases, TLS tools, proxies, and custom TCP applications. Users search for "TCP RST pcap analysis", "connection reset by peer Wireshark", "RST after SYN", "TLS connection reset", and "firewall TCP reset" because they need to know who ended the connection and whether the reset came from the application, operating system, firewall, load balancer, or server.

A TCP RST is explicit. It says "abort this connection." The hard part is attribution.

PCAP Surgery is useful because reset investigations need a clean, focused trace with direction, timestamps, sequence numbers, and enough packets before the reset.

Common reset patterns

RST can happen:

• Immediately after SYN.
• After SYN-ACK.
• After ClientHello.
• After HTTP request.
• During idle timeout.
• After invalid protocol data.
• When an application closes a socket with unread data.
• When a firewall rejects a policy.
• When a load balancer has no healthy backend.
• When a server process crashes or refuses state.

The timing tells you where to look.

Who sent the RST

First identify source IP, source port, destination IP, and destination port of the reset packet. If the server IP sends RST, the server side or something impersonating that side ended it. If the client IP sends RST, the client side ended it. If TTL, MAC, or path behavior suggests a middlebox, the reset may be injected.

Do not rely only on application wording. "Reset by peer" may be reported by the side that received the RST.

Reset after SYN

RST after SYN often means the port is closed or policy rejects the connection. If SYN receives RST immediately, the application never reached TLS or HTTP.

Look for:

• SYN -> RST,ACK
• No ServerHello
• No application data
• Consistent behavior across attempts

This is not a certificate failure or HTTP error; it is a TCP reachability/service state failure.

Reset during TLS

RST after ClientHello can be caused by wrong port, unsupported TLS, SNI mismatch, middlebox policy, or server rejection. Preserve DNS and ClientHello metadata so you can see hostname, ALPN, TLS versions, and timing.

If the reset arrives after a TLS alert, the alert is more informative than the reset. If there is no alert, the reset may be lower-level or policy-driven.

Reset after request

RST after HTTP request, database query, or protocol command often means the application understood enough to reject or crash on the request. It can also mean a proxy closed because upstream was unavailable.

Correlate:

• Last application bytes sent.
• Server response or lack of response.
• Idle time before reset.
• Backend/load-balancer logs.
• Whether reset happens only for certain request sizes.

Checklist

Use this workflow:

1. Identify the first RST in the conversation.
2. Identify who sent it.
3. Inspect what happened immediately before it.
4. Check whether TCP handshake completed.
5. Check whether TLS began or completed.
6. Check whether application data was sent.
7. Check for idle timeout timing.
8. Compare TTL/MAC/path clues for middlebox injection.
9. Preserve DNS, TCP, TLS, and application bytes around the reset.
10. Use server/load-balancer logs to confirm attribution.

Final diagnosis

TCP RST is a connection abort, but the reason depends on timing and sender. A pcap can distinguish closed port, firewall reject, TLS rejection, application close, idle timeout, load balancer failure, and middlebox reset.

PCAP Surgery helps preserve the packet sequence that answers the most important question: who reset the connection, and what happened just before it?