Unable to access

When you RDP by IP address, what error message do you get ?

FYI

Check on both computers that Network Discovery is turned ON (Advanced Network Sharing) and that Allow Remote Connections is turned ON (System Properties).

Make sure firewalls are not in the way.

Thanks. Is there any other way to remotely access that machine, other than using Remote desktop or Team-viewer, without further setting up any other tool on that remote machine?

You can use Team View or you can put Radmin Remote Control server on the machine to be accessed and Radmin Viewer on the machine viewing. I use RDP and Radmin both.

https://www.radmin.com/

Many thanks John.

I sent you a message and need a help from you!

Could you please help? Thanks.

If available. Next time, I really would not disturb you like this.

try using TELNET 133.255.219.14 3389 to determine if the RDP port is actually open or not.

FYI, i tried to PING the same host from here but the request was timeout.

It is 113.255.219.14

Sorry to that I cannot set up "telnet" within my machine now.

just scanned the port 3389 of the above host, it was not open.

I send you a message and can you please help me by that? Thanks a lot.

Port 80 and 443 are open on the host running Microsoft Windows 7|Vista|2008 (93%).

> 80/tcp  open  http?
> 443/tcp open  skype2  Skype

FYI

Starting Nmap 6.00 ( http://nmap.org ) at 2016-05-09 08:03 EEST
NSE: Loaded 17 scripts for scanning.
Initiating SYN Stealth Scan at 08:03
Scanning 113.255.219.14 [100 ports]
Discovered open port 443/tcp on 113.255.219.14
Discovered open port 80/tcp on 113.255.219.14
Completed SYN Stealth Scan at 08:03, 2.79s elapsed (100 total ports)
Initiating Service scan at 08:03
Scanning 2 services on 113.255.219.14
Service scan Timing: About 50.00% done; ETC: 08:07 (0:01:45 remaining)
Completed Service scan at 08:05, 105.65s elapsed (2 services on 1 host)
Initiating OS detection (try #1) against 113.255.219.14
Retrying OS detection (try #2) against 113.255.219.14
Initiating Traceroute at 08:05
Completed Traceroute at 08:05, 0.26s elapsed
NSE: Script scanning 113.255.219.14.
Initiating NSE at 08:05
Completed NSE at 08:05, 0.88s elapsed

[+] Nmap scan report for 113.255.219.14
Host is up (0.22s latency).
Not shown: 98 filtered ports

PORT    STATE SERVICE VERSION
80/tcp  open  http?
443/tcp open  skype2  Skype

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port80-TCP:V=6.00%I=7%D=5/9%Time=57301A43%P=x86_64-unknown-linux-gnu%r(
SF:GetRequest,1A,"HTTP/1\.0\x20404\x20Not\x20Found\r\n\r\n")%r(HTTPOptions
SF:,42,"9\xe6\xdd\x95/\x94\x99\xc8\x15\xb4\x97\x1e\xeb\x11\xe4fo\x82\xf9\x
SF:11\]%\xf6o\xe3}\x1d=\x049\x04\x95i\xba2\x93\xfeO/\x08\xbf<\x8f\xc3\x9d\
SF:xcc\x80\x97n\x87\x8c\x8dZ\x83X\xe9\x06\?\xe4\x05r\xbb0\xe1\x9e\xf7")%r(
SF:RTSPRequest,52,"\x087\xcc\xb6\x96\xe4U\xf6\xe8\xd2\x13\xc4F\xccK\xf93\x
SF:cf\x8c\xe1\xec\xd7\x97~\x8f\x930\x0fN\r\x89\xf2\xe3\0\x91\xe6\"-f\x10\x
SF:98\xe0\x9c\x04%\x82J\x99;\xb0a\x1ew\xbc\xfd\ns\x88Y\xb6/\x14u\"\xab`QN\
SF:xe7l\xed:\xe38I\xe6\x9f\xc4eR\x1b\x10")%r(FourOhFourRequest,1A,"HTTP/1\
SF:.0\x20404\x20Not\x20Found\r\n\r\n")%r(RPCCheck,55,"\xb7\xb2\xd1\xb2\xdc
SF:\x9e1z\x82\x1f\xd7\x9f\xfe\x8a\xbf\xba\x8ef\xc2\xfci\x8dA>\*\)\xb3`CR;\
SF:x8c10w0\xa9~O,,0rX\xa8\xf0\xbc\xe5\xae\xc7\xcc\xcd\x9a\xc3\x98\)F\x7f\$
SF:E\xb2\xfbp!\xde7\|\xbd\xca3H\x19v\xef\xd45\xe2k\x20\x11\x0e\xa7,\xad\xf
SF:a")%r(DNSVersionBindReq,4F,"\x16\xcc\\\x93-\xdd\xb0\xd6\x90\xaa`\xb1\x0
SF:8p\*\xb8E\xc5\xc1W;\x82\xa6}\xd0L\xb5\xe7\x94\]\xfd7\xed\x13\xde\xe7\x1
SF:cS2\xcd\xf5\x18aF\xc0\]A\xb3\x91\x8e'\xac-z#x\x89&\xdf\x04\xa5\x92\[P\x
SF:81\xbe\x97\\\x1d\xaa\x93\(yVO\xb4\x95\xc2\xcb")%r(DNSStatusRequest,37,"
SF:cz\xcd\xb3\xa8\xba\xc9w\x03jX\xcf\xba\x1c5\xda\^\xaeI\xd6\xdb\x20n<\xfb
SF:\xaf\xf9\x99\x83\xb8&\xf4G\xff\xe2\xc5&\xb3\xb5\xac\x05v\xee\xaa\xe3\$\
SF:x01\xccc\xb8\xc9f\x1fD\xe5")%r(SSLSessionReq,58,"H\xba\x9f\x93\"K\x1fWd
SF:\xca\xa7\xf6\xd2\xb5\xa8&\x0ee\t`\xd8\xbf\xc9hQs\xf9s#\x03\x9f\xef\x84q
SF:\xdf\x9b\x8c\xbb\x13\xf6\xed1\xc9\xd9\xb5\xb7\x1bn\xfbp!\xde7\|\xbd\xca
SF:3H\x19v\xef\xd45\xe2k\x20\x11\x0e\xa7,\xad\xfa\xa3\xf8\t\xa6_\x84%\x12\
SF:xbf'\x15\xd2y\x88\"\x19")%r(Kerberos,6C,"\xb8\xd1\xb3n<\x95O\x83\x1dq\x
SF:b9\x14\xbc\xc5\x94Q\^\[\x9f%\xcbI\xc0\xa1\xe9\xe9\x91p\x1dl\xc1\xe14@\x
SF:83\xc8\|\x94P\xc5\xb3`X\xce\x93\x0e\xff\xdb\xa6_\x84%\x12\xdb\xd0\x01>\
SF:x17\xdc\x9d\*\x13\xa8\xf9\xd6\xcf4\x15BK\x80\xf1n\x87\x8c\x8dZ\x83X\xe9
SF:\x06\?\xe4\x05r\xbb0\xe1\x9e\xf7<}\x8a\xf3\x08\xd96\xaf\x94\xf5\xbdC\x1
SF:a\xb8\x15Y\xcb\x8e")%r(SMBProgNeg,6E,"\xa0\xad~5\xc7\xa4S\x98\x07\x9ez\
SF:x1bM\"\xf3\xd4\"\0\xb3\t\x88\xa8\x9a\x938\xabY\x9e\x97~IM\xf4\0,\x1c9L\
SF:xf7w\xffV\x9d\xaf%\"s\x1bu\"\xab`QN\xe7l\xed:\xe38I\xe6\x9f\xc4eR\x1b\x
SF:10A~W\x1c\xddjS\xe89\x16\x0ftU\x82\x8b\xc01\xae\xc7\xcc\xcd\x9a\xc3\x98
SF:\)F\x7f\$E\xb2\xfbp!\xde7\|\xbd\xca3H\x19v");

Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 7|Vista|2008 (93%), FreeBSD 6.X (86%)
OS CPE: cpe:/o:microsoft:windows_7::professional cpe:/o:microsoft:windows_vista::- cpe:/o:microsoft:windows_vista::sp1 cpe:/o:microsoft:windows_server_2008::sp1 cpe:/o:freebsd:freebsd:6.2

Aggressive OS guesses: Microsoft Windows 7 Professional (93%), Microsoft Windows Vista SP0 or SP1, Windows Server 2008 SP1, or Windows 7 (93%), Microsoft Windows Vista SP2 or Windows Server 2008 (93%), Microsoft Windows Server 2008 R2 (90%), Microsoft Windows Server 2008 SP1 (90%), Microsoft Windows Vista SP0 - SP1 (87%), Microsoft Windows Vista Home Premium SP1, Windows 7, or Windows Server 2008 (86%), FreeBSD 6.2-RELEASE (86%), Microsoft Windows Server 2008 Beta 3 (85%), Microsoft Windows Server 2008 SP2 (85%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 4.682 days (since Wed May  4 15:44:04 2016)
Network Distance: 15 hops
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: Incremental


TRACEROUTE (using port 443/tcp)
HOP RTT       ADDRESS
1   0.48 ms   router1-lon.linode.com (212.111.33.229)
2   1.18 ms   212.111.33.233
3   1.01 ms   85.90.238.69
4   0.76 ms   1-0-peer12-01.lon2.telecity.net (85.90.226.206)
5   0.87 ms   ae-1.r23.londen03.uk.bb.gin.ntt.net (195.66.236.138)
6   1.22 ms   ae-0.r22.londen03.uk.bb.gin.ntt.net (129.250.4.85)
7   186.38 ms ae-6.r21.sngpsi05.sg.bb.gin.ntt.net (129.250.7.65)
8   190.66 ms ae-11.r20.sngpsi05.sg.bb.gin.ntt.net (129.250.7.22)
9   215.58 ms ae-7.r22.tkokhk01.hk.bb.gin.ntt.net (129.250.6.47)
10  220.41 ms ae-6.r01.tkokhk01.hk.bb.gin.ntt.net (129.250.6.233)
11  220.24 ms 203.131.243.122
12  223.90 ms 218.189.98.2
13  240.04 ms 10.28.21.6
14  219.57 ms 10.30.18.234
15  225.21 ms 113.255.219.14

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 116.08 seconds
           Raw packets sent: 322 (19.448KB) | Rcvd: 84 (7.198KB)

Select allOpen in new window

Bing,
I've further replied to you by message.

Hi There,

The stated IP address could be scanned using the below tool:

https://pentest-tools.com/network-vulnerability-scanning/tcp-port-scanner-online-nmap

The output indicates that port 3389 i.e. RDP port has been filtered by the remote end.
The ping goes through since the ICMP might have been allowed.

Kindly share the output generated by the above URL to the remote end to confirm if they have allowed your public IP on their firewall.

Most probably the http/https ports belong to the Internet gateway at that site, which is responsible for forwarding the RDP port to the correct machine. If so, you've got the chance to log into the router and check its settings.
If http/https is forwarded to a host, there is nothing you can do but to get yourself or someone else on site.
The NMAP scan results can mean both of above, sadly.

Ian,
What to adjust regarding 3389, as I had no problem on one other machine, which is also connecting to the same router and it was also using the public IP allocated from the same router?

Hi,

Kindly perform the below steps.

i)
Within the same LAN, using the same credentials, you are able to take a remote connection to the destination machine from one workstation whereas it does not work from the other?
Have you verified from a few more test machines?

ii)
Verify whatismyipaddress.com output on the affected machine is similar to the machines from which things are working fine.
There could be a possibility that a PBR(policy based route) on the network device might be routing the affected machines traffic via some other ISP.

I see from the IP address in the screenshot of your first post that you're probably based in Hong Kong so if RDP access to the machine is possible from the LAN where it resides but not from anywhere outside of the private network, then this would suggest that either changes have been made to that LAN's router or firewall that you don't know about, or that the blocking of such traffic might be happening at the ISP level due to a change in their policy for reasons unknown.

But I really get no problem to access one other machine remotely, which is also connecting to the same router of that ISP, from somewhere else.

Hi Hua,

Unable to understand the below,


But I really get no problem to access one other machine remotely, which is also connecting to the same router of that ISP, from somewhere else.

Well' if you can access another host inside your LAN from a remote location, that suggests something amiss with the one that you can't access.

Has anything been changed in the problem machine's configuration, or has the RDP service stopped running on it for some reason?

Many thanks all. I did no change to the computer and its router.

John,

Where is Network discovery option?

Network discovery settings are in Control Panel, Network and Sharing Center.

I turn on Network discovery but the problem still persists.

Are the two computers on the same LAN or remote from each other.

Try a different computer on the same network subnet

Yes, the two computers are being allocated with the similar IP like

113.255...

Previously, everything was also fine to this problematic PC. What to adjust to ensure no problem?

Try a different computer.

Sorry, I want to be able to access this problematic PC, by remote desktop. What to adjust?

The IP is being allocated by ISP. I do not which option of the hardware is producing the problem.

Hi Hua,

Kindly update on the queries raised in the threads  41584423 and 41584781 so that we could have a clear picture out here.

Hi,
I have one Desktop, to which I could use Remote desktop to access it more than one week before, but now I cannot (this is only issue I have). While it is having the IP allocated by ISP. Now it is with IP

113.255.213.162

Hi HuaMin,

The issue roght now is that you are unable to RDP to the server 113.255.213.162 which initially had the IP 113.255.219.14.

Are you able to RDP to this server from any other machine in your LAN?
Have you chacked with remote end team for any changes done?

I could not access it by RDP using whatever machine and I did no change to it.

What to check within the desktop, to see what is affecting RDP?

Hi HuaMin,

i)
First check if the server is behind a firewall.
If yes, please ask your firewall team if they have restricted RDP access on it.
ii)
Do you manage the server?
share the output of netstat -ano | findstr 3389.
also turn off the windows firewall on the server.

If I turn off Firewall, I can then connect to it by RDP. How to know which Inbound/Outbound firewall rule is leading to the error?

Here is what I get

Hi,

Kindly confirm if you have turned off the firewall at the server level.
The output pasted above I believe is from the server destination.It indicates that the server is listening on port 3389 i.e. RDP port.

Yes, I turned it off.

But why can't connect to it by RDP, if I turn on the firewall?

It sounds as though the public IP address through which you remotely access the server in question is dynamically assigned; if so this isn't going to help remote access. If you obtain a static public IP address for the server site then at least you will always be able to find the server!

Regarding the RDP access problem, is there an explicit rule in the firewall allowing access to the server on port 3389? If there isn't, make one, and just to be sure that it will work as expected, configure it so that the rule applies to both inbound and outbound traffic.

Sorry, the machine is Windows 10 and I did currently do no change on it. Which firewall rule could be leading to the problem?

If the RDP target computer is Windows 10, does it have any third-party internet security software installed, such as Symantec or McAfee? If so, it is the firewalls of these products that you will have to configure, as they normally disable the native Windows one in order to run their own without conflicts.

Hi,

The external port scan (nmap) indicates that 3389 port is opened.

@Perarduaadastra: Need your expertise out here since the Mr. Hua states that the server is accessible when the local firewall is disabled.

@Hua: I would recommend you to consult with your firewall team since I remember that the previous IP that had been alloted to server failed the port scan for port 3389 from external tools.
TCP_Port_Scan_with_Nmap--1-.pdf

Ian,
Many thanks and appreciated a lot!

Every day, there would be IP allocated to the server, from ISP.

While the previous IP would be of no use!

I believe should be something to do at the local firewall/access privilege level

What to adjust, to firewall rule?

Sorry, I want to be able to access this problematic PC, by remote desktop. What to adjust?

I understand, but if the problem machine is on the same LAN subnet as the accessing machine (you said it was), then try local access or a different machine to determine the problem by a process of elimination.

Can you confirm that the RDP target computer is the Windows 10 machine you referred to earlier, or that we're dealing with a Windows server? If it's the latter case, knowing which one would be helpful.

Can you also confirm that no third-party firewalls are running on the target computer?

If a third-party firewall is indeed running, then check to see if the Windows firewall is disabled - not just turned off. I've encountered situations in which the Windows firewall still blocked traffic even though it was actually turned off.