Why does one of my LAN servers frequently require 21 seconds to connect?

Question

Using a mix of Windows 7 and Windows 10 clients, one of my LAN servers tends to take 21 seconds to establish a connection. This LAN server is running Windows Server 2012-R2 and hosting TFS 2015 on IIS port 8080. Playing with Fiddler reveals that the connection is spending 21 seconds establishing a TCP connection.

Using wireshark, I see the following conversation. It is ordered by time.

Time  0 : IPV6 - TCP 49371 → 8080 [SYN] Seq=0 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1  
Time  3 : IPV6 - TCP 49371 → 8080 [SYN] Seq=0 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1
Time  9 : IPV6 - TCP 49371 → 8080 [SYN] Seq=0 Win=8192 Len=0 MSS=1440 SACK_PERM=1
Time 21 : IPV4 - TCP 49372 → 8080 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256
                SACK_PERM=1
Time 21 : IPV4 - TCP 8080 → 49372 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256
                SACK_PERM=1
Time 21 : IPV4 - TCP    49372 → 8080 [ACK] Seq=1 Ack=1  Win=65536 Len=0
Time 21+: IPV4 - HTTP chatter
                 (at this point the connection has been established successfully)

This seems to match the firewalled port diagram on http://www.codeproject.com/Articles/363088/TCP-and-Port-Filtering-Firewalls-with-WinSock (i.e., 3 second timeout, 6 second timeout, 12 second timeout). However, turning on Windows firewall logging on client and server does not show dropped packets.

This seems to be server-specific; I can connect to other servers (on the LAN and outside) without this issue. If I explicitly specify an IPV4 or IPV6 ip address, the connection is established successfully (and the wireshark logs show only IPV4 or IPV6 traffic in this scenario).

Please note that everything described above is suspect, as this problem is highly resistant to diagnosis:
1. If two requests are made within the same application, the second request responds quickly (unless the requests are far enough apart?).
2. Sometimes tweaking a setting on the server (or maybe even on the client?) will temporarily eliminate the problem (until the client is rebooted?).

Edit: Below is what a Wireshark trace looks like when the server starts working:

Time 0 : IPV6 - 60459 → 8080 [SYN] Seq=0 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1
Time 0 : IPV6 - 8080 → 60459 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 
                SACK_PERM=1
Time 0 : IPV6 - 60459 → 8080 [ACK] Seq=1 Ack=1 Win=66048 Len=0
Time 0+: IPV6 - HTTP Chatter
                (at this point the connection has been established successfully)

Question: How can I modify the server to avoid this 21 second connection delay?

Answer 1

The intended configuration for the IPV4 connection properties was for the machine to have a pair of hard-coded IPV4 DNS server, each of which was a Domain controller. However, the actual configuration was that one of the two hard-coded DNS servers was a domain controller and the other was an ex-domain controller, the latter of which was running Server2003 and lacked ipv6 support. I will note that the previous server was similarly misconfigured, but the previous server was a Server2003 machine and lacked IPV6 support.

Since updating this setting about 2 days ago, the TCP issue has not occurred. While the previous setting was obviously wrong, I am not confident that the IPV4 misconfiguration is the specific cause of the TCP/IP failure. I've been investigating this issue for about a month, with the problem has been intermittently vanishing and reappearing the whole time.