SYN issue, no 3-way handshake
Hello All,
This might be an easy one. Cannot get 3-way handshake completed: https://www.cloudshark.org/captures/3...
Any reasons?
Thx, Myky
Hello All,
This might be an easy one. Cannot get 3-way handshake completed: https://www.cloudshark.org/captures/3...
Any reasons?
Thx, Myky
Wireshark shows you exactly what has happened but rarely why it has happened. Here a firewall somewhere close to the server (because the RST has come for each SYN but the RST for the first SYN has come as late as after the second SYN was sent) may be responsible for rejecting the connection, or the server application itself (e.g. if the apache server's configuration only permits connections from some addresses/subnets).
So the next capture point should be the server, to see whether the SYN has arrived there or not.
TTL is independent between directions (the IP layer knows nothing about the TCP layer's notion of request and response). But I admit I haven't studied deeply the capture, so I've missed that the first two packets have the same timestamp (which is weird itself), while the two RST packets have different ones. You haven't stated how and where you have captured, so it may be a merge of captures from different capture points.
But the essence remains, the RST may come from the actual recipient of the SYN as well as from some firewall between the sender (client) and recipient (server). If you can capture at the server, you should be able to distinguish between these two cases.
Thanks, @sindy. The issue is no longer present and it was resolved on its own. The tcpdump was taken from my Teltonika (3G router). It seats between the client and AWS UniFi controller. I always thought that TTL value is a good indication in order to understand who initiates RST (or if packet actually was routed before or if RST is spoofed by the upstream firewall/router).
Asked: 2018-10-20 20:03:13 +0000
Seen: 341 times
Last updated: Oct 20 '18