Remote desktop problem
07 October 2011, 03:59 PM
#1
Remote desktop problem
Guys
Windows 7 64 bit
Remote desktop was working(inide last weekl, and has recently stopped for only one particular site.
I've tried updates etc, but nothing so far.
So, I can remote desktop to other sites, but not this particular one.
Its not their problem, because if I remote desktop to a server and then out to the site all is well.
Any ideas?
Windows 7 64 bit
Remote desktop was working(inide last weekl, and has recently stopped for only one particular site.
I've tried updates etc, but nothing so far.
So, I can remote desktop to other sites, but not this particular one.
Its not their problem, because if I remote desktop to a server and then out to the site all is well.
Any ideas?
08 October 2011, 05:26 PM
#4
I used to be able to RDC to the site from my laptop, but now I can't
I have to do a double hop via another machine at my site.
So that means everything their side is OK
But my RDC is also OK as I get get to other sites, just not this particular one
08 October 2011, 05:34 PM
#5
Is the problem that you can't connect at all, or that the remote machine won't let you login once you reach it, or that you can't see anything on the screen, or what exactly? Have you taken a packet-capture or looked at any logs on the remote machine?
Also worth thinking about if you'd rather not spend too long figuring out the root cause of the problem is to setup RealVNC on the remote machine, and remote into it that way. You'd need to be careful you don't leave the thing wide open for anyone to get into, obviously.
Also worth thinking about if you'd rather not spend too long figuring out the root cause of the problem is to setup RealVNC on the remote machine, and remote into it that way. You'd need to be careful you don't leave the thing wide open for anyone to get into, obviously.
08 October 2011, 05:51 PM
#6
Scooby Regular
Join Date: Nov 2000
Posts: 1,227
Likes: 0
Received 0 Likes
on
0 Posts
1. Has anything changed with the remote machine?
2. Are you the only one who has access to it, are you sure no-one has been tampering with it?
3. Is your traffic getting to the machine? Can you ping it (or anything else), or is it just an RDC related issue? If you cant get a route to it, then its a routing issue, check IP conflicts, blocked IPs in software/hardware etc. If you can ping it then its an RDC/port issue, check blocked ports in software/hardware etc.
4. Are you able to ping your machine from the machine with a problem?
5. Have you tried rebooting routers/firewalls/machines? it quite often solves problems that are unexplainable (gremlins).
6. Do you have any active security/ip filtering software/hardware in the network or on the machines or your machine. Popup's that warn of connections people weren't expecting are easily clicked if they dont know that they are doing (if someone else has access to the machine).
Just a few things to look in to.
J
2. Are you the only one who has access to it, are you sure no-one has been tampering with it?
3. Is your traffic getting to the machine? Can you ping it (or anything else), or is it just an RDC related issue? If you cant get a route to it, then its a routing issue, check IP conflicts, blocked IPs in software/hardware etc. If you can ping it then its an RDC/port issue, check blocked ports in software/hardware etc.
4. Are you able to ping your machine from the machine with a problem?
5. Have you tried rebooting routers/firewalls/machines? it quite often solves problems that are unexplainable (gremlins).
6. Do you have any active security/ip filtering software/hardware in the network or on the machines or your machine. Popup's that warn of connections people weren't expecting are easily clicked if they dont know that they are doing (if someone else has access to the machine).
Just a few things to look in to.
J
08 October 2011, 08:13 PM
#7
Scooby Regular
iTrader: (1)
Join Date: Aug 2010
Location: W Yorkshire
Posts: 521
Likes: 0
Received 0 Likes
on
0 Posts
So you can RDP to other computers and the destination can receive connections if you double hop via another computer on your site.
That suggests that there isn't a problem with the RDP on your local computer or Terminal Services on the remote server. Also you must have a rule in place at the remote site for your public IP to connect using port 3389 because you can access it via another computer on your site.
That leave two possibilities. Either for some reason your computer doesn't know the route to the destination. Trace route the destination and ensure it is hitting your local gateway to rule that out.
The other thing is going to be your local site firewall. This won't apply if your site is your home and only has a home router. I'm thinking corporate networking. Your firewall need to have a rule in place which allows your local computer IP address to go to the destination public IP address using port 3389. Usual cause of this sort of thing happening is because a firewall is rebooted and the running config wasn't saved to the startup config so the new rules will be removed.
That's a quick answer based on the information provided. It's the sort of stuff I do at a corporate level daily.
That suggests that there isn't a problem with the RDP on your local computer or Terminal Services on the remote server. Also you must have a rule in place at the remote site for your public IP to connect using port 3389 because you can access it via another computer on your site.
That leave two possibilities. Either for some reason your computer doesn't know the route to the destination. Trace route the destination and ensure it is hitting your local gateway to rule that out.
The other thing is going to be your local site firewall. This won't apply if your site is your home and only has a home router. I'm thinking corporate networking. Your firewall need to have a rule in place which allows your local computer IP address to go to the destination public IP address using port 3389. Usual cause of this sort of thing happening is because a firewall is rebooted and the running config wasn't saved to the startup config so the new rules will be removed.
That's a quick answer based on the information provided. It's the sort of stuff I do at a corporate level daily.
Last edited by chris84; 08 October 2011 at 08:14 PM.
Trending Topics
08 October 2011, 08:22 PM
#8
Scooby Regular
iTrader: (1)
Join Date: Aug 2010
Location: W Yorkshire
Posts: 521
Likes: 0
Received 0 Likes
on
0 Posts
Is the problem that you can't connect at all, or that the remote machine won't let you login once you reach it, or that you can't see anything on the screen, or what exactly? Have you taken a packet-capture or looked at any logs on the remote machine?
Also worth thinking about if you'd rather not spend too long figuring out the root cause of the problem is to setup RealVNC on the remote machine, and remote into it that way. You'd need to be careful you don't leave the thing wide open for anyone to get into, obviously.
Also worth thinking about if you'd rather not spend too long figuring out the root cause of the problem is to setup RealVNC on the remote machine, and remote into it that way. You'd need to be careful you don't leave the thing wide open for anyone to get into, obviously.
RDP uses an encryption protocol so it's much safer.
Most corporate networks use VPN encrypted access into the site so all your traffic can be sent more securely in the same way as sending it through an ssh tunnel.
also another one people sometimes forget. FTP isn't encrypted either so as an alternative use SFTP
08 October 2011, 11:14 PM
#9
While VNC is a good tool in the real world it's not enough. VNC traffic isn't encrypted so any information you type to a remote device will be sent in plain text and could be intercepted. The way to avoid that happening is to create an ssh tunnel between you and your destination so that your VNC traffic can be sent through the tunnel, that way you're protected.
RDP uses an encryption protocol so it's much safer.
Most corporate networks use VPN encrypted access into the site so all your traffic can be sent more securely in the same way as sending it through an ssh tunnel.
also another one people sometimes forget. FTP isn't encrypted either so as an alternative use SFTP
RDP uses an encryption protocol so it's much safer.
Most corporate networks use VPN encrypted access into the site so all your traffic can be sent more securely in the same way as sending it through an ssh tunnel.
also another one people sometimes forget. FTP isn't encrypted either so as an alternative use SFTP
08 October 2011, 11:32 PM
#10
Scooby Regular
iTrader: (1)
Join Date: Aug 2010
Location: W Yorkshire
Posts: 521
Likes: 0
Received 0 Likes
on
0 Posts
i like to put random insights into posts as well. even if it only educates one person and saves their identity as a worst case scenario then it's worth it.
10 October 2011, 10:25 AM
#11
So you can RDP to other computers and the destination can receive connections if you double hop via another computer on your site.
That suggests that there isn't a problem with the RDP on your local computer or Terminal Services on the remote server. Also you must have a rule in place at the remote site for your public IP to connect using port 3389 because you can access it via another computer on your site.
That leave two possibilities. Either for some reason your computer doesn't know the route to the destination. Trace route the destination and ensure it is hitting your local gateway to rule that out.
The other thing is going to be your local site firewall. This won't apply if your site is your home and only has a home router. I'm thinking corporate networking. Your firewall need to have a rule in place which allows your local computer IP address to go to the destination public IP address using port 3389. Usual cause of this sort of thing happening is because a firewall is rebooted and the running config wasn't saved to the startup config so the new rules will be removed.
That's a quick answer based on the information provided. It's the sort of stuff I do at a corporate level daily.
That suggests that there isn't a problem with the RDP on your local computer or Terminal Services on the remote server. Also you must have a rule in place at the remote site for your public IP to connect using port 3389 because you can access it via another computer on your site.
That leave two possibilities. Either for some reason your computer doesn't know the route to the destination. Trace route the destination and ensure it is hitting your local gateway to rule that out.
The other thing is going to be your local site firewall. This won't apply if your site is your home and only has a home router. I'm thinking corporate networking. Your firewall need to have a rule in place which allows your local computer IP address to go to the destination public IP address using port 3389. Usual cause of this sort of thing happening is because a firewall is rebooted and the running config wasn't saved to the startup config so the new rules will be removed.
That's a quick answer based on the information provided. It's the sort of stuff I do at a corporate level daily.
Thanks so far Chris - most helpfull
OK, it is a work network.
Right - problem is now very odd indeed.
I had to connect to this site from home at the weekend and it worked!
Back in office now and it no longer works unless I double hop via another machine in the office?
Last edited by urban; 10 October 2011 at 10:28 AM.
Thread
Thread Starter
Forum
Replies
Last Post
Mattybr5@MB Developments
Full Cars Breaking For Spares
28
28 December 2015 11:07 PM
Mattybr5@MB Developments
Full Cars Breaking For Spares
12
18 November 2015 07:03 AM
