Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Remote Desktop Connection getting dropped 1

Status
Not open for further replies.

jfoxx75

IS-IT--Management
Oct 8, 2007
8
0
0
US
We have a network set up with an Cisco ASA Router. We also have a Cisco 3560 switch. I am trying to remote desktop into another desktop on the network and the network connection is getting dropped. I have checked the log on the ASA and it is not getting dropped there. I think it may have something to do with the switch. Any Ideas.
 
If you are on the same network as the workstation then the ASA isn't even in the loop.
 
When you say the connection is getting dropped-does that mean you can login and then it is dropped? or that it never comes up?
After the connection is dropped, can you still ping the remote machine?
 
When I bring up the rdp client and put in the IP of the machine I want to remote desktop into, It acts as if its trying to connect. The desktop pops up but the logon prompt never appears and then I get an error saying that the connection has been lost.
 
Are you RDC'ing from XP to XP? Does it work the other way around? Are they in different VLANs?

Burt
 
Its XP to XP on the same VLAN
 
You've probably already done this:
Check that RDP is allowed on the remote machine. You can do this by opening a remote registry session and go to this key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnections and set it to 0 (ie disabled which means that you can RDP in).
Also, does the firewall on the remote host allow connections?
Can you ping it?
Can you also ping by both IP and hostname? (ie is it a DNS issue?)
 
I think it is the switch that is the problem. I can remote into both Desktops from my office on a different network.
 
You say the login prompt never appears, is the background of the RDP session all black or coloured?

If its all black check the MTU size. This is common on WAN links but shouldn't happen on the LAN.
 
Perhaps fast user switching is enabled on these machines. You didn't mention if they are on a domain but it does cause those symptoms.
 
Do an extended ping with the df bit set to off. This will verify the MTU that needs to be set.

Burt
 
The background is colored as if it is going to connect, but the login prompt never appears.
 
This could be a MTU and/or ICMP filtering issue with the Don't Fragment bit being set. I have seen similar behaviour before where the RDP session starts but then hangs. It could be along the path there is a device with a smaller MTU and since the DF bit it is set it can't fragment the packets. Normally this router would send ICMP unreachables back to the client to force it to use smaller packets. If these aren't being sent or are being blocked somewhere the client or the server doesn't get to know it needs to send smaller packets.
You could try using ping and sending increasingly larger packets to see if it is this:
Code:
Z:\>ping

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
            [-r count] [-s count] [[-j host-list] | [-k host-list]]
            [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name

Options:
    -t             Ping the specified host until stopped.
                   To see statistics and continue - type Control-Break;
                   To stop - type Control-C.
    -a             Resolve addresses to hostnames.
    -n count       Number of echo requests to send.
    -l size        Send buffer size.
    -f             Set Don't Fragment flag in packet (IPv4-only).
    -i TTL         Time To Live.
    -v TOS         Type Of Service (IPv4-only).
    -r count       Record route for count hops (IPv4-only).
    -s count       Timestamp for count hops (IPv4-only).
    -j host-list   Loose source route along host-list (IPv4-only).
    -k host-list   Strict source route along host-list (IPv4-only).
    -w timeout     Timeout in milliseconds to wait for each reply.
    -R             Trace round-trip path (IPv6-only).
    -S srcaddr     Source address to use (IPv6-only).
    -4             Force using IPv4.
    -6             Force using IPv6.


Z:\>ping -f -l 1520 10.10.10.10


Pinging 10.10.10.10 with 1520 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 10.10.10.10:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

You should see the response above sent from the router that can't send packets that big. Start at 1400 and then increase, if it stops and you get just timeouts then that's your problem. The resolution is to change the MTU on the end devices or find out where the ICMP messages are being blocked or not sent out and fix it.

HTH

Andy
 
Thanks,
That did the trick. I changed the MTU settings on both of the computers and now can RDP between the two.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top