Friday, February 15, 2013 4:05 PM
I have a Speedtouch router at home with several PCs connected. I want to be able to access one of those machines from my office. I changed the router to forward port 3389 to the local (static) IP address of the relevant home PC. I also set the PC to allow remote desktop connections both locally and publically. I determined the external IP address of my router using whatismyip.com.
I am unable to connect from the office. Both office and home PCs are running Windows 7 Ultimate. It still fails if I switch the firewall off on the home PC.
I can connect via logmein in a browser. I can also connect using another local PC (also Windows 7 Ultimate) at home.
I've tried using PortQry from the office and it resolves the IP to a name but declares port as 'FILTERED'
If I do a net stat -a -o on the home PC, it appears to show port 3389 as listening.
Is there a chance there is something I need to change on the office PC to make this happen?
I am tearing my hair out. Any help would be appreciated, thank you.
Friday, February 15, 2013 4:15 PM
Is your internet provider blocking port 3389? Some providers block a lot of ports they consider dangerous.
You can try if you can Telnet to port 3389 from the office to be sure this is not blocked somewhere in the connection to your home
This is the instruction from http://support.microsoft.com/?kbid=187628&wa=wsignin1.0 :
Telnet tserv 3389
where "tserv" is the host name or IP number for your Terminal Server.
If telnet is successful, you simply receive the telnet screen and a cursor. On the Terminal Server, Terminal Server Administration will show a blue computer icon with no other information. The Telnet connection will also consume an idle session.
The Terminal Server should disconnect the connection after a few minutes. Or, you can disconnect using Telnet.
This test tells you that you can connect over the port.
If Telnet reports that you cannot connect, there are several possible reasons:
If you can connect by replacing "tserv" with the Terminal Server's IP address but not the host name, you may have a DNS or WINS resolution problem.
- If you can connect when "tserv" is the host name, but cannot connect when "tserv" is the computer name, then you may have a NetBIOS name resolution issue with WINS or an LMHOSTS file.
- If you cannot connect when "tserv" is the IP address, the host name, or the computer name, then it is likely that port 3389 is blocked somewhere in your WAN.
Danny van Dam, Citrix CCIA/CCEE Microsoft MCSE Server Infrastructure/MCSE Desktop Infrastructure/MCSA Server 2008, Cisco CCNA, VMware VCP 3/4/5 http://www.citrix-guru.com http://www.rds-support.eu
- Proposed As Answer by Danny van Dam Saturday, February 16, 2013 7:59 AM
Friday, February 15, 2013 4:29 PM
Thanks Danny.I assume that you are talking about my home ISP with regard to blocking port 3389? I guess I may be able to check that.
Telnet does not work with the IP address. Would you regard this result as being consistent with an ISP block?
Friday, February 15, 2013 5:28 PM
"I've tried using PortQry from the office and it resolves the IP to a name but declares port as 'FILTERED'"
Sounds like either your office firewall is blocking this port, or like Danny says: your ISP is blocking this port (either work or home, or both).
Friday, February 15, 2013 6:32 PM
OK I will explore with the office IT people when I'm back there. Thank you.
Saturday, February 16, 2013 9:56 AMI've checked with my home ISP and they are not blocking the port. I also tried connecting using mobile broadband from my laptop (as an alternative to using PC at office) and that failed, so, unless both the mobile broadband provider and my office are both blocking the port, perhaps the problem lies elsewhere.
Thursday, February 21, 2013 9:28 PM
It is possible that your mobile broadband blocks 3389 as well. This is a well known port for RDP and some ISPs block it for security reasons.
Your best bet is to do a port scan to see if 3389 is reachable.
If your ISP is adamant that they do not block 3389, go to a friend's house who is also on the same ISP and try connecting/port scan from there.
- Edited by Guy Techie Thursday, February 21, 2013 9:33 PM