Everything Have a Reason and I Need to Know that - RST Packet from Server - TCP Stack

Last week I faced a strange issue. Thou it was a good experience, lost my sleep for for a night at-least!! The problem was with TCP 3-way Handshake.. So I took a capture in server, I could see SYN packets coming from client, SYN ACK going back from server, and finally a "RST" from server.... Here I got screwed... Why "RST" from Server.. I thought of all conditions even if I don't know the exact working of TCP stack..

I looked into wireshark, could see TCP retransmission from SYN as well as SYN ACK. I decided to read some TCP stack stufff..

Next day I got call saying the issue is resolved, but HOW?? No one is interested in looking into that (F____rs) and I hate it most when putting things in a black HOLE.. One more day and I was so restless.. Needed a reason for "RST"

Finally yesterday I found the reason, could sleep well..

So reason is as follows

When ever a SYN or SYN ACK sent, there will a timer and first time it will set for 3 seconds.. after 3 sec if no response from peer, TCP will resend the packet and the timer will be set to 6 Seconds (Double)... after 6 sec if no response from peer, TCP will resend the packet and the timer will be set to 12 Seconds (Double)... even after this no response (after 21 Sec from the first packet); the server will send a "RST" packet, which is quiet normal...

The issue was in WAN, which never delivered SYN ACK to the other end.. (Some IPSC Crypto ACL problem)


Mistakes Which I did : I should have asked for the other end Capture toooo.. :)

Anyway I am happy to find a reason..

NB: I stick to my theory in practical way, will find a reason for each and everything and it will be audited.. Because I believe in RCA (Root Cause Analysis)