Ask Your Question

TCP Retransmission during TLS-Handshake

asked 2017-11-20 16:09:11 +0000

KwirkMiyagi gravatar image

updated 2017-12-08 10:42:49 +0000

I am having a serious delay during the TCP handshake in our LAN. I have no explanation why this may occur, it leads to a load time of ~20 seconds in total. If you have any hints or explanations, I'd be really thankful. I am not able to upload the wireshark capture, unfortunately because I didn't earn enough points. But you find a screenshot at the following url: image description

EDIT: Yes, the initial handshake worked well and in time (see update screenshot). I try to clarify our configuration with its components: When I open the URL to the specified port, the wireshark log shows the destination IP, while I tried to connect to [A], which would redirect me to [B] (OAuth mechanism). Each server runs a IIS server with a wildcard certificate being installed, the intermediate certificate is stored in the microsoft local store (mmc).

Note: The phenomenon of the tcp retransmissions occurs on each client I tried (as well as multiple browsers).

So, seems to be a network device in our LAN (I haven't installed the certificate on that device, I don't even know which server (+firewall?) that is in our LAN).

Is it possible that the server verifies the certificate chain in the internet/LAN? Why don't I see the server [A] or [B] in the wireshark log?

What else can I do/analyse?

EDIT2: I finally got access to our router/firewall configuration (RouterOS Winbox of Mikrotik router). I checked firewall settings, loaded certificates, but I can't find any setting that could give some hint about the reason for the delay. I found a SIP setting, which I also tried to deactivate, but with no success.

I attached some screenshots of the settings:

Firewall Service List Certificates IP Settings Connections

Any ideas?


Due to omuffat's great analysis I was motivated to get the wireshark log on router-site going. Below you find the complete cycle Client(>Router(>A(>B(, which hopefully gives some more clarification about the reason for the lost ACK packet. @omuffat: As far as I see, your assumption was right, it never reaches the endpoint. My questions:

  • Why does the communication succeeds nonetheless (after ~20 seconds)? Is the ACK optional?
  • Might it have to do with the redirect to B or is the correct TCP handshake independent of the application?
  • Might any IIS webserver setting be the cause of the problem? On system [A] an mvc application is running while on [B] an application runs. They are loaded on demand on the first access (in IIS), while I did already installed the initialization module, etc..
  • Might OAuth cause the delay? I activated logging which showed that process was done before redirect in 1-2 seconds, and I was calling consumer.Channel.Send(response) [DotNetOpenAuth.Messaging] on system A ...
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2017-12-01 14:17:04 +0000

The initial TCP handshake didn't take place correctly. Frame 2336 (ACK to SYN/ACK) is lost in the network, since there is a retransmission of SYN/ACK in frame 3530 (9 seconds later !). Firewall rules should not be the problem since the transaction eventually finish.

It could be caused by congested network or overloaded system (router/firewall, server) since the rest of transaction takes place normally and is less than 1 seconds (Frame 5996 to 6077).

You should understand how you get that IP Address (DNS, HTTP Redirect, ...) in the capture, since it is not the expected server. You should make a capture on that server ( when the symptoms occur. Do you have the same symptoms when you get the expected server(s) ?

edit flag offensive delete link more


Thanks for the great hint, I did some more analysis (see EDIT3 above). I really hope that we will get rid of this delay together.

KwirkMiyagi gravatar imageKwirkMiyagi ( 2017-12-06 09:29:03 +0000 )edit

answered 2017-11-20 16:26:42 +0000

Jaap gravatar image

So the initial TCP handshake takes place normally (why didn't you include that?), the TCP connection is then handed over to some TLS entity. Obviously the TLS entity isn't available until after 15 seconds from when the TCP socket has been opened, hence the retransmissions. So you should be looking at that TLS handler. All assuming there's no intervening network equipment, eg. load balancers, firewalls, etc. So with this little information there's little to tell, really.

edit flag offensive delete link more


Thanks for your reply and explanation. I edited my post and attached some screenshots of the server configuration, firewall rules, etc. I hope it is helpful for further analysis, I am stuck.

KwirkMiyagi gravatar imageKwirkMiyagi ( 2017-11-30 11:02:45 +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


Asked: 2017-11-20 16:09:11 +0000

Seen: 11,523 times

Last updated: Dec 08 '17