TCP: SYN request receives SYN response instead of SYN-ACK

1
votes

From packet capture file(pcap), observing the following during the TCP Handshake

Client sends SYN request to Server, Server responds with SYN packet instead of SYN+ACK, Client responds with Out of Order packet message, Server terminates the TCP handshake with RST packet

This occurs randomly and not always. TCP connections do get established but sometimes connection establishment fails with above observed pattern.

The client is hosted in AWS, while the server is a CDN network

1
amazon-web-servicestcp
I would show the trace to the operator of the CDN network. – David Schwartz
Do you see any other TCP or IP flags set? – Thomas L.
Sorry I do not see any other TCP flags set – anonexpr

1 Answers

0
votes

If a socket is on TIME_WAIT and new syn is appended the kernel will check to see if the SEQ number of the SYN is greater than or less than the last SEQ received for this the socket being used.

you can review this post/answer: https://serverfault.com/questions/297134/server-not-sending-a-syn-ack-packet-in-response-to-a-syn-packet

Typically if a SYN is Sent and another SYN is recieved without an ACK it is generally just a loss of the ACK over the line (especially in your case). this is prevalent whenever your route from A(client) to B(Server) is short AND your packets path from server to client is especially long and traverses over a network that may not be able to guarantee reliable packet travel over the substantially greater distance. IF you are losing your ACK over the line you will tend to find a RST message from the client, essentally asking the server to start again.

The other possibility is a request of some kind. typically where the client will push a PSH, ACK signal with a len: xx where x is a number of the requested length. the server will typically respond with an ACK telling the client that it recieved its request and the server is processing (this ACK is typically empty.) it will then push a PSH, ACK - len: xx packet to the client to let the client know it has accepted its request and this packet will have information in it.

Monitoring this information (non-maliciously) with wireshark will typically help spread some light on your situation, just be sure to learn (if you don't already know) how to filter your packets, otherwise you will have a lot of information to dig through (typically).

I would also attempt to send a packet to the server in question that you can trace to see if its being directed off of the beaten path. If your packets are jumping through loops to make its destination it is extremely likely that its doing the same thing on the way back. if you'd like you can try using tcpdump(linux) or tracert(windows).

Hope this helps!