TCP HANDSHAKE COMPLETE BUT RESET ARRIVES (Why it happens in real networks)

First we know one thing
Handshake means only Layer 4 session is ready
Application and security checks start only after handshake
So reset after handshake means path is OK but something inside the flow failed

Main reasons why RST comes after SYN SYN-ACK ACK

1) Application not listening
Handshake works because TCP replies
But the actual service (HTTP SSH DB etc) is not running Server immediately sends reset
Check with netstat and application logs

2) Firewall allowed handshake but blocked data
Handshake small packets easily pass
But when real data starts firewall does deep inspection If URL category or threat or App-ID blocks the flow Firewall sends reset Check traffic logs and threat logs

3) SSL TLS negotiation failure
Handshake finished
Now SSL client hello starts
If cipher mismatch or TLS version issue or wrong certificate Server sends reset
Check Wireshark for fatal alert and SSL logs on firewall

4) MTU MSS issue
Handshake packets are small so they pass
Application data is bigger
Tunnel supports smaller MTU and DF bit is 1
Packet cannot fragment
Router drops the packet and RST follows
This is very common in IPSec SD-WAN and cloud paths
Fix by MSS clamp

5) NAT or return path problem
Handshake may go through same path
But application packets take different path
Firewall sees asymmetric session and resets
Check NAT table and routing on both directions

6) Firewall session timeout
Sometimes application replies slowly
Firewall thinks session idle and expires it
Client or server sends reset

7) Endpoint security blocks traffic
Antivirus or EDR or SSL inspection agent may drop traffic
Reset seen after handshake
Check client logs and test by disabling agent

8) Server overload
Server accepts handshake
But cannot handle more sessions
Overloaded CPU memory or max connections reached
Server resets the flow

9) Asymmetric routing
Handshake lucky path
Next packets take different path
Firewall out of state and resets session
Check both direction trace

10) Application rejection
Application itself does not allow request
Invalid token
Wrong URL
403 or deny conditions
Server resets after handshake

Simple Troubleshooting Approach

1 See who sent the reset client or server
2 Check if SSL handshake starts or fails
3 Look for MTU errors fragmentation needed but DF set
4 Check firewall logs for reset-client or reset-server
5 Confirm service is actually listening
6 Check NAT and routing symmetry
7 Try curl from server side
8 Temporarily disable SSL decryption
9 Test path MTU using ping with DF
10 Check server health and resource usage