TCP SYN Retransmission and No SYN-ACK PCAP Analysis: Firewall, Routing, Server Down, or Asymmetric Path?

When a TCP connection never opens, the packet trace often starts with repeated SYN packets. The client sends SYN, waits, sends another SYN, waits longer, and eventually gives up. Users search for "TCP SYN retransmission pcap", "no SYN ACK", "SYN_SENT troubleshooting", "connection timeout Wireshark", and "firewall dropping SYN" because the application only says "connection timed out."

Repeated SYN without SYN-ACK is a reachability problem at or before TCP session establishment. It is not an HTTP error, not TLS failure, not a database query problem, and not a certificate issue. The server application may never see the connection.

PCAP Surgery is useful because these traces are simple but attribution depends on capture point, direction, routing, firewall policy, and whether any response appears.

Healthy TCP handshake

A normal TCP connection starts with:

Client -> Server: SYN
Server -> Client: SYN-ACK
Client -> Server: ACK

If SYN-ACK never arrives at the client, the handshake does not complete.

SYN retransmission pattern

When the client does not receive SYN-ACK, it retransmits SYN:

0.000 Client -> Server SYN
1.000 Client -> Server SYN retransmission
3.000 Client -> Server SYN retransmission
7.000 Client -> Server SYN retransmission

The exact timing depends on operating system and configuration. The pattern means the client still has no valid response.

Possible causes

Common causes include:

• Server is down.
• Server port is filtered by firewall.
• Destination IP is wrong.
• Route to server is missing.
• Return route from server is missing.
• Security group blocks ingress.
• Local host firewall blocks outbound or inbound response.
• Load balancer listener is absent.
• Network ACL drops SYN or SYN-ACK.
• Asymmetric routing sends reply through another path.
• Capture point misses the response.

The trace alone must be interpreted with where it was captured.

SYN with RST is different

If the server sends RST, the port is reachable but closed or actively rejected:

Client -> Server SYN
Server -> Client RST,ACK

That is not the same as no SYN-ACK. A reset is explicit. No response suggests drop, route failure, or no host response.

Capture point matters

Client-side capture showing SYN leaving and no SYN-ACK returning proves the client did not receive a response. It does not prove whether the SYN reached the server.

Server-side capture can answer:

• Did the server receive the SYN?
• Did the server send SYN-ACK?
• Did the SYN-ACK leave the server?

If server sees SYN and sends SYN-ACK but client never receives it, the return path is suspect. If server never sees SYN, the forward path is suspect.

Asymmetric routing

Asymmetric routing can make one capture misleading. A middle capture may see SYN but not SYN-ACK because the reply takes another path. That does not necessarily mean the reply is missing.

For hard cases, use captures at both endpoints or at known routing boundaries.

Firewall and security groups

Many firewalls silently drop SYN packets. Cloud security groups and network ACLs may do the same. The application sees timeout because no reset is sent.

If the same destination responds on port 22 but not 443, inspect port-specific policy. If ICMP ping works but TCP SYN does not, do not conclude that the TCP service is reachable.

Checklist

Use this workflow:

1. Identify client, server, and port.
2. Capture at client and look for SYN retransmissions.
3. Check whether any SYN-ACK or RST returns.
4. Capture at server if possible.
5. Determine whether SYN reaches server.
6. Determine whether server sends SYN-ACK.
7. Check firewall, security group, ACL, and local host firewall.
8. Check forward and return routes.
9. Consider asymmetric routing.
10. Preserve SYN timing when sharing the trace.

Final diagnosis

TCP SYN retransmission with no SYN-ACK means the connection failed before application protocol negotiation. The likely causes are server down, filtered port, firewall drop, missing route, missing return path, asymmetric routing, or capture-point limitation.

PCAP Surgery helps reduce the trace to the handshake evidence that proves where the connection attempt stopped.