Ask Your Question
0

SYN issue, no 3-way handshake

asked 2018-10-20 20:03:13 +0000

myky gravatar image

updated 2018-10-20 20:21:46 +0000

Hello All,

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

Any reasons?

Thx, Myky

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-10-20 21:21:55 +0000

sindy gravatar image

updated 2018-10-20 21:22:25 +0000

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.

edit flag offensive delete link more

Comments

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

myky gravatar imagemyky ( 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 gravatar imagesindy ( 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 gravatar imagemyky ( 2018-10-21 10:46:37 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-10-20 20:03:13 +0000

Seen: 365 times

Last updated: Oct 20 '18