We have some 2008 Windows servers that keep disconnecting RDP session attempts with a RESET before the connection is complete. We have taken a lot of Wireshark traces from different sources to several different machines. On most of the connections we see a SYN come in, the server responds with a SYN/ACK and then almost immediately follows that with a RESET.
Unfortunately for reasons we're still investigating - in some of our traces we're showing duplicate traffic coming in from the client. When we check directly on the client we never see duplicates, so it appears some path through our network is causing this.
Microsoft hasn't addressed all of the traces we've taken where there are no duplicates. Nor have they addressed the fact that our 2003 servers don't have this problem. These traces are being taken directly on the servers using Opnet so there's no chance of seeing dups due to an HA pair of switches (quite common) or some other flaw in our capture methodology.
What they've seized upon are some traces with the same SYN (as evidenced by source/dest IP & port, along with IP ID). They're stating that the server is sending RESETs because two identical SYNs are coming in while it's still in the process of negotiating its 3way handshake.
Is that right? It seems like TCP should ignore one of these and not send a RESET. My feeling is this is a red herring and an excuse they're using to explain an issue with their TCP stack in 2008 server.
Thanks in advance!
Unfortunately for reasons we're still investigating - in some of our traces we're showing duplicate traffic coming in from the client. When we check directly on the client we never see duplicates, so it appears some path through our network is causing this.
Microsoft hasn't addressed all of the traces we've taken where there are no duplicates. Nor have they addressed the fact that our 2003 servers don't have this problem. These traces are being taken directly on the servers using Opnet so there's no chance of seeing dups due to an HA pair of switches (quite common) or some other flaw in our capture methodology.
What they've seized upon are some traces with the same SYN (as evidenced by source/dest IP & port, along with IP ID). They're stating that the server is sending RESETs because two identical SYNs are coming in while it's still in the process of negotiating its 3way handshake.
Is that right? It seems like TCP should ignore one of these and not send a RESET. My feeling is this is a red herring and an excuse they're using to explain an issue with their TCP stack in 2008 server.
Thanks in advance!