Okay, I'm at a complete loss...
-
I'm trying to set my system at home (XP64) up to allow remote connections. Here's my setup: - DSL with static IPs - Router configured as DHCP server, and IP's are assigned according to MAC address (so the same computer always gets the same internal IP) - NAT is turned on, assigning specific external IPs to associated LAN boxes The things I've done: - Remote Connection is configured to use a specific port (I changed the registry to set this port value, and I've verified after a reboot that the desired port is still specified). - Router firewall is configured to forward all TCP/IP traffic on the specified port to the desired LAN box. - Allow remote connections is turned on. - The desired user accounts have been added to the list of accounts that are allowed to remote in. When I try to connect from work (using Vista64, and typing the IP:port), I get the message: This computer can't connect to the remote computer If I try the same thing on one of my computers at home (a XP-32 laptop), it works fine (and yes, it's going out of the router and back in because it has a different IP address). The systems folks here at work say they're not blocking any outbound traffic, so that leads me to believe that I have a configuration problem somewhere. What have I missed?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001On your port forwarding rule in the firewall see if there is a SNAT (Source NAT) option and make sure its enabled. I had a similar issue this week when setting up a new subset behind a new router, the ports where all forwarded correctly but I was unable to establish a connection. It turns out the router i was using was passing the data to the backend machine running RDP but then when it was replying the gateway was sending the data from its own IP address and, of course, the client didn't know where the data was coming from. Source NAT will make the data appear to come from the IP of the backend machine and not the gateway and solve this issue (or at least did for me).
Richard Green
-
As Zoltan suggested try
telnet computer-ip-address remote-desktop-portin command prompt at your office, just to see if you can establish TCP connection with home PC at specified port. You don't need telnet server, all you need is something thatlistenson that port and you already have Remote Desktop enabled. If you can establish connection you'll get blank screen, otherwise telnet client will display error :)Well, it gave an error. But it also gave an error on port 80 for my web server, which I know for a fact works fine.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I'm trying to set my system at home (XP64) up to allow remote connections. Here's my setup: - DSL with static IPs - Router configured as DHCP server, and IP's are assigned according to MAC address (so the same computer always gets the same internal IP) - NAT is turned on, assigning specific external IPs to associated LAN boxes The things I've done: - Remote Connection is configured to use a specific port (I changed the registry to set this port value, and I've verified after a reboot that the desired port is still specified). - Router firewall is configured to forward all TCP/IP traffic on the specified port to the desired LAN box. - Allow remote connections is turned on. - The desired user accounts have been added to the list of accounts that are allowed to remote in. When I try to connect from work (using Vista64, and typing the IP:port), I get the message: This computer can't connect to the remote computer If I try the same thing on one of my computers at home (a XP-32 laptop), it works fine (and yes, it's going out of the router and back in because it has a different IP address). The systems folks here at work say they're not blocking any outbound traffic, so that leads me to believe that I have a configuration problem somewhere. What have I missed?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001I think the best advice was to try it from another network like a wifi hotspot etc. "System folks at work" generally can't tell their elbow from their asshole and there's a very good chance one or both isp's *are* blocking certain ports. What you need to do is enable as many services on your home box as possible so you can try them all, i.e. a web server, telnet, mail, etc then try it from another network.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
Well, it gave an error. But it also gave an error on port 80 for my web server, which I know for a fact works fine.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Are you sure the syntax is correct? Don't use
:to split host and port. For example:telnet 192.168.0.1 80
-
Are you sure the syntax is correct? Don't use
:to split host and port. For example:telnet 192.168.0.1 80
yes, that's the way i did it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I think the best advice was to try it from another network like a wifi hotspot etc. "System folks at work" generally can't tell their elbow from their asshole and there's a very good chance one or both isp's *are* blocking certain ports. What you need to do is enable as many services on your home box as possible so you can try them all, i.e. a web server, telnet, mail, etc then try it from another network.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
John C wrote:
there's a very good chance one or both isp's *are* blocking certain ports
Well, I can RDC from home (the same machine I'm trying to connect to from here) to this machine, and other people here can RDC from here to their home machines, as well as RDC from their home machines too their boxes here at work (at least one is using UVerse, and at least one is using Time Warner). I seriously doubt that any ports are being blocked anywhere. I have a web server running on another machine at home, and I can connect to that just fine (through a browser).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I'm trying to set my system at home (XP64) up to allow remote connections. Here's my setup: - DSL with static IPs - Router configured as DHCP server, and IP's are assigned according to MAC address (so the same computer always gets the same internal IP) - NAT is turned on, assigning specific external IPs to associated LAN boxes The things I've done: - Remote Connection is configured to use a specific port (I changed the registry to set this port value, and I've verified after a reboot that the desired port is still specified). - Router firewall is configured to forward all TCP/IP traffic on the specified port to the desired LAN box. - Allow remote connections is turned on. - The desired user accounts have been added to the list of accounts that are allowed to remote in. When I try to connect from work (using Vista64, and typing the IP:port), I get the message: This computer can't connect to the remote computer If I try the same thing on one of my computers at home (a XP-32 laptop), it works fine (and yes, it's going out of the router and back in because it has a different IP address). The systems folks here at work say they're not blocking any outbound traffic, so that leads me to believe that I have a configuration problem somewhere. What have I missed?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001It sounds like most of the others have covered the basics. If you can connect on your internal LAN, you know that the computer is setup correctly. If there were a software firewall on the machine causing problems, it would show up here as well unless you have it somehow configured to allow open access from other LAN computers but I don't know of any Firewall software with an option like that. If you can't connect from an external connection, then it has to be your router or ISP. You can't test this easily from another computer on your LAN since almost any router will short-circut the connection and bypass it's own rules when going to any local machine unless you have specificly configured it not to. Can you VPN into work or some other location? If so, then VPN out of your router, and then use the remote computer to Remote Desktop back in (easiest way to test). Another option would be to use a wireless connection to your neighbor's unsecured network (everyone has at least one neighbor like this right?) to test comming into your network. If you still can't get it to work, now its time to try from a "known good" connection. Find someone who uses outgoing Remote desktop from thier network successfully. Configure your computer to use the same port they do and remote destop from them to you. If it works, then your network guys at work lied to you.
-
It sounds like most of the others have covered the basics. If you can connect on your internal LAN, you know that the computer is setup correctly. If there were a software firewall on the machine causing problems, it would show up here as well unless you have it somehow configured to allow open access from other LAN computers but I don't know of any Firewall software with an option like that. If you can't connect from an external connection, then it has to be your router or ISP. You can't test this easily from another computer on your LAN since almost any router will short-circut the connection and bypass it's own rules when going to any local machine unless you have specificly configured it not to. Can you VPN into work or some other location? If so, then VPN out of your router, and then use the remote computer to Remote Desktop back in (easiest way to test). Another option would be to use a wireless connection to your neighbor's unsecured network (everyone has at least one neighbor like this right?) to test comming into your network. If you still can't get it to work, now its time to try from a "known good" connection. Find someone who uses outgoing Remote desktop from thier network successfully. Configure your computer to use the same port they do and remote destop from them to you. If it works, then your network guys at work lied to you.
I had one of the guys that *can* RDC out connect to his box at home and then try to connect to my home box, and it wouldn't work for him either. The only difference we could see is that he's using the standard RDC port (3389), and I'm not.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I'm trying to set my system at home (XP64) up to allow remote connections. Here's my setup: - DSL with static IPs - Router configured as DHCP server, and IP's are assigned according to MAC address (so the same computer always gets the same internal IP) - NAT is turned on, assigning specific external IPs to associated LAN boxes The things I've done: - Remote Connection is configured to use a specific port (I changed the registry to set this port value, and I've verified after a reboot that the desired port is still specified). - Router firewall is configured to forward all TCP/IP traffic on the specified port to the desired LAN box. - Allow remote connections is turned on. - The desired user accounts have been added to the list of accounts that are allowed to remote in. When I try to connect from work (using Vista64, and typing the IP:port), I get the message: This computer can't connect to the remote computer If I try the same thing on one of my computers at home (a XP-32 laptop), it works fine (and yes, it's going out of the router and back in because it has a different IP address). The systems folks here at work say they're not blocking any outbound traffic, so that leads me to believe that I have a configuration problem somewhere. What have I missed?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001I couldn't get my to work either. I just use TeamViewer since it is free for personal use.
I didn't get any requirements for the signature
-
I ran into this configuring my own system. I bet your firewall is blocking the port. At least on my systems (XPSP3 32 bit) the pre defined Remote Desktop exception is hardwired to port 3389 so if you change the port you need to create a new exception. Try this (I'm assuming windows firewall). Make sure exceptions are enabled. On the exceptions tab, add a new port, specifying the port you assigned to remote access. Select TCP and make sure the scope allows 'Any computer (including those on the internet)'. [Edit] Shoulda read all the responses - if you're not running a software firewall then the above advice will resemble a one legged man in a bum kicking contest [/Edit]
Rob Manderson My bloghttp://robmanderson.blogspot.com[^]
Rob Manderson wrote:
[Edit] Shoulda read all the responses - if you're not running a software firewall then the above advice will resemble a one legged man in a bum kicking contest [/Edit]
:laugh:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
Ray Cassick wrote:
The only reason I am asking is because the router knows its own external IP address so there is a chance that it is optimising the connection request from another internal device on the same subnet as the destination of the port forwarding and just looping the two together internally making you think that the router is allowing the traffic out and then back in.
I suppose that could be happening, but I'm not sure how to find out if that's the case...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001The only way I know of would be to actually use a public IP connection to come in rather than your work (that is behind a firewall) or your home (that is also behind your NAT router), and see if you have better luck. The only other thing I could think of is to see if you could stuff something on the WAN link of your router and sniff to see if the outbound traffic is actually going out and then coming back in form your ISPs gateway. If your NAT router has logging perhaps you could look at them to see if the connection (the one that works) in is even being see as an inbound connection form the WAN side or the LAN side of the router and then see if your reporting even shows the inbound connection (the one that fails) at all. Are you using a cheap-o NAT router or an actual integrated services type router? The only reason I am asking is that more expensive routers may offer the ability to run a sniffer on the WAN link and to look at the TCP traffic within the router itself. Just some ideas... Hope they help.
-
I had one of the guys that *can* RDC out connect to his box at home and then try to connect to my home box, and it wouldn't work for him either. The only difference we could see is that he's using the standard RDC port (3389), and I'm not.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001So configure yours to use 3389 and see if it works. At least that way you KNOW that it is a problem with some hardware along the line blocking the port you are using. Along those lines. What port are you using? Hopefully it isn't one that is used for some other common service or well known virus.
-
I'm trying to set my system at home (XP64) up to allow remote connections. Here's my setup: - DSL with static IPs - Router configured as DHCP server, and IP's are assigned according to MAC address (so the same computer always gets the same internal IP) - NAT is turned on, assigning specific external IPs to associated LAN boxes The things I've done: - Remote Connection is configured to use a specific port (I changed the registry to set this port value, and I've verified after a reboot that the desired port is still specified). - Router firewall is configured to forward all TCP/IP traffic on the specified port to the desired LAN box. - Allow remote connections is turned on. - The desired user accounts have been added to the list of accounts that are allowed to remote in. When I try to connect from work (using Vista64, and typing the IP:port), I get the message: This computer can't connect to the remote computer If I try the same thing on one of my computers at home (a XP-32 laptop), it works fine (and yes, it's going out of the router and back in because it has a different IP address). The systems folks here at work say they're not blocking any outbound traffic, so that leads me to believe that I have a configuration problem somewhere. What have I missed?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Did you "NAT" the port you are using for remote desktop in the DSL box? E.g. ext.req. IP:PORT -> your DSL box -> your PC The DSL box needs to know how to route the PORT to an internal IP address. Usually the DSL boxes have internal NAT tables. You need to have access to change the DSL box configs.
-
Did you "NAT" the port you are using for remote desktop in the DSL box? E.g. ext.req. IP:PORT -> your DSL box -> your PC The DSL box needs to know how to route the PORT to an internal IP address. Usually the DSL boxes have internal NAT tables. You need to have access to change the DSL box configs.
If by "dsl box", you mean the dsl modem, it's in bridge mode and is simply passing everything through to the internal router.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
If by "dsl box", you mean the dsl modem, it's in bridge mode and is simply passing everything through to the internal router.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Makes no difference. You still need to "NAT" the port in the router to an internal IP address, otherwise this will not work. p.s. I have done this before :)
