First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

SYN issue, no 3-way handshake

  • retag add tags

Hello All,

This might be an easy one. Cannot get 3-way handshake completed: https://www.cloudshark.org/captures/3...

Any reasons?

Thx, Myky

myky's avatar
5
myky
asked 2018-10-20 20:03:13 +0000, updated 2018-10-20 20:21:46 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

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.

sindy's avatar
6.2k
sindy
answered 2018-10-20 21:21:55 +0000, updated 2018-10-20 21:22:25 +0000
edit flag offensive 0 remove flag delete link

Comments

Thanks. How did you figure out who sent RST packet? All packets have TTL of 64.

myky's avatar myky (2018-10-21 09:12:19 +0000) edit

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.

sindy's avatar sindy (2018-10-21 10:35:37 +0000) edit

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).

myky's avatar myky (2018-10-21 10:46:37 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer