Note that the timing is not synchronized between client and server
Any help would be appreciated
Added capture files here:
Note that there are several successful handshakes and ensuing traffic, but at some point something breaks as described above.
This question is marked “community wiki”.
asked 28 May ‘13, 14:53
edited 29 May ‘13, 18:25
The same issued was discussed in a Oracle Forum thread
"The Solaris response, with just ACK instead of the typical SYN ACK, is good according to RFC 793. The FW obviously doesn't agree to this behaviour and RST's the connection towards both ends.
Note that the correct (= expected) SYN ACK from the server is sent out delayed. So it might be the http server is having problems acctepting the new connection in a timely manner causing an unexpected ACK to flow out before the SYN_ACK.
answered 29 May '13, 23:29
Looks like Load balancer is not translating server ip address to virtual ip address when replying back to client. Assuming 22.214.171.124 is the client,if you check ACK-RST packet which is 136 is having SIP:126.96.36.199 and DIP:192.168.140.26(In normal case the DIP should be Load balancer IP a.k.a VIP which is 188.8.131.52).ACK-RST is generated because somehow client didn't liked the previous packet it got and it failed to process it.One case is, It opened connection to LB ip but it got a response directly from server instead of LB ip. Is asymmetric flow triggered(Forward traffic hits LB-A and Reverse hit LB-B and LB-B instead of translation do a plain routing which will break the session)
"Then the client received a ACK (and not a SYN ACK as expected) from the server, which the server sent in replay to a SYN" I didn't get this part.
Why syn-ack is not expected?
SYN/SYN-ACK and ACK are must and should for any TCP Based communication right?How come client will send an ACK with out seeing SYN-ACK from server?
Better to wait for some expert analysis here. I am sure you will get.
answered 28 May '13, 15:08
edited 28 May '13, 15:45
It looks as if the server ignores the first SYN packet and then answers with ACK (Frame #134).
Possible Reason: Asymmetric routing. You see only one half of the communication and the other half is router through a different interface/path. This usually happens in cluster environments (Firewalls, Loadbalancers, etc.), hence the different IP addresses. They are either NATed (Firewall) or balanced (Loadbalancer).
If the capture was taken on the server itself, then there must be two interfaces in the server (possibly with an IP address in the same subnet) and the OS does send the replies to the same interface where the requests came into the system. You don't see the SNY-ACK for the SYN in Frame #132, as it may have taken a route you did not monitor.
The strange thing here is Frame #134, which should not exist in this conversation at all, as it is an ACK from the server to the client.
If the capture was taken on a TAP or switch, there is most certainly a cluster tool involved. You see the requests coming from one cluster node and you don't see the answers as they are sent to the second cluster node. The second node possibly drops those packets, and that's why you don't see the SYN-ACK at the client.
Suggestion: Check your environment for misconfigured clustered devices (Firewalls, Loadbalancers) and/or a misconfigured server with dual interfaces (possibly in the same subnet - some versions of windows do allow that!).
answered 28 May '13, 23:35
Kurt Knochner ♦
edited 28 May '13, 23:45