Revision history [back]

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:

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?

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?

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?

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 which leads to a call on system B (which took about 8 seconds), and this happens twice in the initialization process. Might the delay have to do with the missing ACK?

While doing the wireshark streaming on router-site, I came across some conspicuity: The router permanently sends data to my client (see screenshot [IDLE]), might that be an explanation for your congestion assumption? What more information do you need?

Additional Info:
On localhost the delay only occurs on the first application call (because it gets compiled in IIS), on the second try, it is fast (even after Cache clear). But over the network, the delay described occurs again and again (each time!).

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 which leads to a call on system B (which took about 8 seconds), and this happens twice in the initialization process. Might the delay have to do with the missing ACK?

While doing the wireshark streaming on router-site, I came across some conspicuity: The router permanently sends data to my client (see screenshot [IDLE]), might that be an explanation for your congestion assumption? What more information do you need?

Additional Info:
On localhost the delay only occurs on the first application call (because it gets compiled in IIS), on the second try, it is fast (even after Cache clear). But over the network, the delay described occurs again and again (each time!).

Router: System A: System B: IDLE: