TCP Retransmission during TLS-Handshake
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:
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 10.2.4.147, while I tried to connect to 10.0.0.10 [A], which would redirect me to 10.0.1.10 [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, 10.2.4.147 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 10.2.4.147 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:
Any ideas?
EDIT3:
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(10.2.1.144)->Router(10.2.4.147)->A(10.0.0.10)->B(10.0.1.10), 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 asp.net 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 ...
