rdc could not connect

[Chris]

I am sure this has been asked a million times, but I have checked on Google
and couldn't find the proper solution that fixes my problem.

I have a laptop that is running Windows XP Pro SP2. It has been working
fine since SP2 was installed. However, all of a sudden, I can no longer
use Remote Desktop to connect to my servers.

I have tried connecting to Windows 2000 Server and Windows Server 2003
without success. The error I get is:

The client could not connect to the remote computer
Remote connections might not be enabled or the computer might be too busy
to accept new connections. It is also possible that network problems are
preventing your connection.
Please try connecting again later. If the problem continues to occur,
contact your administrator.


I have no problems connecting with a few different computers and all
servers are listening on port 3389.

I have the remote desktop web connection set up on a different box running
IIS, and I get a similar message that I can't connect using this particular
computer when trying it within Internet Explorer.

I have even try telnetting to port 3389 of some of the servers and it just
says "Could not open connection to the host, on port 3389: Connect
failed." It's not a DNS problems as it can look up the names of the
servers fine and it's assigned by DHCP anyway.

I checked with netstat -an during the attempt of connection and it does say
"10.10.34.x:3389 SYN_SENT", rather than "Established".

So, is there anything else I can try to resolve this? I hope someone can
help me.

Thank you.

 

[Bill Sanderson]

Good one!

Hope the collective "we" are up to this one.

Sounds like you know that the target hosts are properly configured and
functional 'cause others can talk to them.

And your machine is properly configured and functional 'cause you can talk
to OTHER machines.

And it isn't something esoteric with RDC, 'cause RDWC gives the same
behavior (not too surprising, really.)

So I tend to agree with the portion of the error message that reads:

"It is also possible that network problems are preventing your connection."

So far, just analysis, now I'm reaching a depth limit. You've got DNS,
apparently. You can't do a telnet test, and the netstat -an result is
unusual, apparently. I expect that you've tested using IP addresses as well
as dns names?

What can you tell us about the network?

 

[Chris]

Good one!

Hope the collective "we" are up to this one.

Sounds like you know that the target hosts are properly configured and
functional 'cause others can talk to them.

And your machine is properly configured and functional 'cause you can
talk to OTHER machines.

And it isn't something esoteric with RDC, 'cause RDWC gives the same
behavior (not too surprising, really.)

So I tend to agree with the portion of the error message that reads:

"It is also possible that network problems are preventing your
connection."

So far, just analysis, now I'm reaching a depth limit. You've got
DNS, apparently. You can't do a telnet test, and the netstat -an
result is unusual, apparently. I expect that you've tested using IP
addresses as well as dns names?

What can you tell us about the network?

Everything is closed behind the "corporate firewall". The problematic
machine is just accessing servers in the same subnet. Nothing is leaving
the firewall. Our subnet is 10.10.34.0, with netmask 255.255.255.0. We
used to have four domain controllers, now down to three... one W2k and
two Win Server 2003. The W2k DC is the Global Catalog server and it's
not doing much other than file sharing. One "active directory
integrated" DNS server (WinServ 2003) and two secondary DNS servers. Two
WINS servers on the WinServ 2003 and also two DHCP servers for the
subnet, but of course, divided into two different ranges when providing
addresses to DHCP clients. There are about twenty machines which have
DHCP reservations on both servers.

And yes, I have tried using IP addresses as well as host names when
trying to connect with the Remote Desktop Client, but with same results.

I attempted to reinstall the client, but of course, it doesn't let me
since the RD Client is a built-in component of Windows XP.

I am really stumped. Is there any way I can replace DLLs and/or EXEs
that the RD client use? It's a machine-wide problem because when I
logged in using a different domain user name, it gives me the same
errors.

Thanks...

Chris

 

[Robin Walker]

I am really stumped. Is there any way I can replace DLLs and/or EXEs
that the RD client use? It's a machine-wide problem because when I
logged in using a different domain user name, it gives me the same
errors.

You don't want to replace the RD client: it seems to be working fine. That
fact that you got the SYN_SENT status shows that it is attempting to create
the connection, but the Windows network stack is not receiving a reply from
the remote RDC server. Your problem is a network one, or a firewall one,
not the RDC client.

 

[Chris]

You don't want to replace the RD client: it seems to be working fine.
That fact that you got the SYN_SENT status shows that it is attempting
to create the connection, but the Windows network stack is not
receiving a reply from the remote RDC server. Your problem is a
network one, or a firewall one, not the RDC client.

We used a packet sniffer to sniff what's being sent when telnetting to
port 3389 or connecting to the different terminal servers.

It turns out that the packets were being encrypted as UDP 500 packets. I
couldn't find any reason why it was doing that and there was no VPN
clients running at the time. We even stopped the VPN Client service.

So, a few of my colleagues agreed that we should just re-format the
stupid laptop and start over. They said the last person who used this
could have put some stuff on it for his home network.

I guess the smart thing to do is to always clean the laptop before
handing it to someone else. Oh well...

Thanks to all who gave me suggestions.

Chris.

 

[Robin Walker]

It turns out that the packets were being encrypted as UDP 500
packets. I couldn't find any reason why it was doing that and there
was no VPN clients running at the time. We even stopped the VPN
Client service.

UDP 500 is IPSec (Secure IP) key exchange. The actual data would be carried
on a different protocol all together, but it never got as far as setting
that up. It looks like someone had configured an IPSec security policy for
IP traffic which happened to match what you were trying to do, so it
automatically turned on IPSec for the RDP connection.

 

[Bill Sanderson]

I've seen some strange issues with leftovers from previous installs of
proprietary VPN software.

There may be an easier fix, but I suspect the method you mention is going to
do the job most expeditiously!

Thanks--that's a really nasty one, and I'm very glad to have heard the
outcome.