TCP SYN, SYN ACK followed by RST

asked 2019-11-14 20:32:39 +0000

Hi, I need help figuring out why the client responds with a RST in this case. Packet capture can be accessed at this link:

I have confirmed that it is indeed the client sending a RST. Packet capture on the client end shows that it is sending the RST. It doesn't look like a firewall or some middleman is involved.

Any help will be appreciated. Thank you!

edit retag flag offensive close merge delete


The capture above was done at the server? Can you upload a capture from the client end?
Have you looked at the SYN-ACK when it reached the client?

bubbasnmp gravatar imagebubbasnmp ( 2019-11-14 21:31:30 +0000 )edit

Is the client a load-balancer doing health-checks?

SYN-bit gravatar imageSYN-bit ( 2019-11-14 22:28:44 +0000 )edit

A capture from the client end can be found here:

I have looked at the SYN-ACK. Apart from a source destination mismatch between the SYN and SYN-ACK packet, I did not find anything interesting.

smbnoob gravatar imagesmbnoob ( 2019-11-18 19:36:35 +0000 )edit

@SYN-bit No the client is an smb client.

smbnoob gravatar imagesmbnoob ( 2019-11-18 19:49:42 +0000 )edit

Something in the middle is changing the TCP MSS from 1460 down to 1380 when it reaches the server.
The server responds with a MSS of 1380 which arrives at the client as 1380.

The MAC address difference looks like the client is sending to a VRRP address and the responses are coming back from a HP MAC address (for one of the interfaces on the default gateway?).

I'm not sure if or which of the above two would be enough for the client to send the RST.

bubbasnmp gravatar imagebubbasnmp ( 2019-11-18 22:47:05 +0000 )edit

Different MSS values are normal, so are different MAC-addresses when a First-Hop-Redundancy-Protocol is used.

From these singled out packets, it is not possible to determine the cause of the RST. But I think it is either one of the following:

  • A health check by some process. This is what is called a half-open health check, as the connection is not in ESTABLISHED phase when it is already reset

  • Mutliple connections are opened (for instance also to port 445) and this one is closed because the other connection succeeded and had precedence.

SYN-bit gravatar imageSYN-bit ( 2019-11-18 23:07:06 +0000 )edit

I was just about to ask what the capture criteria was :-) Is it only for port 139?
Old link here on ports 139 and 445:
Can access on Wayback Machine:
"Starting with Windows 2000, the operating system will prefer to use port 445 for SMB instead of port 139. In this process, the client node will send two TCP Syn packets, one with a destination port of 445 and one with a destination port of 139."

bubbasnmp gravatar imagebubbasnmp ( 2019-11-18 23:11:46 +0000 )edit

I agree, the reason for closing is somehow application/socket related. and so far I was not sure about the reason. But the port probing assumption makes absolute sense to me. Great spot @SYN-bit

Christian_R gravatar imageChristian_R ( 2019-11-19 07:03:53 +0000 )edit

Yes, The SYN ACK what it was there is not belongs to the client for which it's requested. But even why the client is sent RST is the question even there is no socket connection is being established.

ramu2987 gravatar imageramu2987 ( 2020-02-12 10:08:46 +0000 )edit