Learn to build web apps and services, IoT apps, and mobile backends by covering the fundamentals of ASP.NET Core and exploring the core foundations for app libraries.
Can ping by IP and by Hostname, but cannot RDP
We have been working remote to another office computer for several weeks. However, yesterday we cannot connect to it. So we proceeded to verify the following:
What else can we check?
- Each of the PC IP ranges/segments - Ok
- System Ino >> Remote Settings >> Allow Remote Assistance... - Ok
- System Ino >> Remote Settings >> Allow Remote Connections... - Ok
- Comodo firewall permit each others access - Ok
- RDP port being used - Ok
- Ping IP address to/from each connected PC - Ok
- Ping Host name address to/from each connected PC - Ok
- ran "Ipconfig /flushdns", "Ipconfig /renew" - Ok
- Also ran (with restart) "netsh winsock reset" and "netsh winsock reset catalog" - Ok
What else can we check?
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
There's a registry value that I've been 'bitten' by, so to speak.
On the PC that you are trying to connect to, open registry editor and navigate to the following key:
HKLM\SYSTEM\CurrentControl
Change fDenyTSConnections from 1 to 0
After you make the change, reboot the PC and try using RDP to connect to it again.
On the PC that you are trying to connect to, open registry editor and navigate to the following key:
HKLM\SYSTEM\CurrentControl
Change fDenyTSConnections from 1 to 0
After you make the change, reboot the PC and try using RDP to connect to it again.
You might also want to run the following command using CMD to verify that the appropriate RDP port is in a LISTENING state:
netstat -a
netstat -a
Did fDenyTSConnections = 0, still no RDP access.
We use port '54661' in the PC to connect. Did run netstat -a and noticed the RDP port used was found in:
Yet didn't find it in the actual IP lines,
Could be something to look into? I mean, if I set the RDP portnumber to 54661, then there should be line like,
We use port '54661' in the PC to connect. Did run netstat -a and noticed the RDP port used was found in:
TCP [::]:54661 xPc-Accounting:0 LISTENING
TCP 0.0.0.0:54661 xPc-Accounting:0 LISTENING
UDP [::]:54661 *:*
UDP 0.0.0.0:54661 *:*
Yet didn't find it in the actual IP lines,
TCP 192.168.0.11:139
TCP 192.168.0.11:49708
etc.
Could be something to look into? I mean, if I set the RDP portnumber to 54661, then there should be line like,
TCP 192.168.0.11:54661
When I run this on the computer that need to connect to Host computer, I get:
When I run this at the host computer, I get:
What do u think is happening?
Connecting To 192.168.0.11:54661...Could not open connection to the host, on port 23: Connect failed
When I run this at the host computer, I get:
192.168.0.11:54661...:
What do u think is happening?
Hi,
My apologies - I mistyped. Please try this instead:
Space instead of the colon.
Thanks,
Alan.
My apologies - I mistyped. Please try this instead:
Telnet 192.168.0.11 54661
Space instead of the colon.
Thanks,
Alan.
When running on the computer that needs to connect to Host computer, I get:
Connecting To 192.168.0.11...Could not open connection to the host, on port 54661: Connect failed
When I run this at the actual host computer, it blanks out the cmd prompt and cannpt do anything else (seems to work or connect? - see below response)
Connecting To 192.168.0.11...Could not open connection to the host, on port 54661: Connect failed
When I run this at the actual host computer, it blanks out the cmd prompt and cannpt do anything else (seems to work or connect? - see below response)
Did noticed something, when doing Ping on the Host Computer using the PC-Name, I get a different IP, like the Host Computer has 2 IP. I made sure the Host Computer has in TCP/IPv4 the static value of '192.168.0.11'. Yet if I ping the actual '192.168.0.11' I also get a result.
Is this causing the problem?
Note 4 things that maybe can help in this problem:
Can any of these be the culprit?
Also not that I have been working connecting to the Host Computer previously prior this problem with the settings you see above. Some thing recently happened that cause this inaccessibility.
Lastly, will uninstall Comodo just to see if the problem is firewall.
Is this causing the problem?
Note 4 things that maybe can help in this problem:
- Both Host Computer and Remote Computer (computer that needs to connect to Host computer) have Hyper-V VM machines.
- Since both have Hyper-V installed, though not always being worked in, the IP is set in the Virtual Switch Manager that was created
- Both computer has installed Comodo Internet Security Premium 10
- The Host Computer has the RDP port available in Comodo Firewall
Can any of these be the culprit?
Also not that I have been working connecting to the Host Computer previously prior this problem with the settings you see above. Some thing recently happened that cause this inaccessibility.
Lastly, will uninstall Comodo just to see if the problem is firewall.
Update:
Note:
We can ping the host computer and we can even do a \\192.168.0.11\c$ and have access to the files on the host computer - the problem persist that it cannot use RDP on it.
- I uninstall Comodo completely on both Host Computer and Remote Computer.
- Remote Desktop worked excelently with no problem - hence, seems Comodo.
- Still, noticed that when doing Ping to the Host Computer using the PC-name, we get another IP than the one I manually set the IP to - can this be Hyper-V?.
- Afterward, I reinstalled Comodo on both Computers and back to the problem of no access using RDP.
Note:
We can ping the host computer and we can even do a \\192.168.0.11\c$ and have access to the files on the host computer - the problem persist that it cannot use RDP on it.
Just updated Comodo on both computers with the latest update, restarted and bang!!!! Works!!!
Don't understand.
Please shed some light EE....
Don't understand.
Please shed some light EE....
Don't really know if the actual uninstall/reinstall Comodo on both computers solved the problem, but will proceed to close the question. If you can share your opinion on possible cause, greatly appreciated.
Hi Rayluvs,
Glad to see you got this sorted. I can't say definitively why Comodo would cause that, but for what its worth, I would not let Comodo anywhere near any machine I was in charge off.
If I was looking at a new client, and they had Comodo installed, I would, at the very least, make it a firm condition that they remove all Comodo software and any other services from their entire network, including any certificates. If they baulked, I would walk away.
Do a search on Comodo and the issues with them.
Not sure how you will feel about that advice, but it is my considered opinion.
Alan.
Glad to see you got this sorted. I can't say definitively why Comodo would cause that, but for what its worth, I would not let Comodo anywhere near any machine I was in charge off.
If I was looking at a new client, and they had Comodo installed, I would, at the very least, make it a firm condition that they remove all Comodo software and any other services from their entire network, including any certificates. If they baulked, I would walk away.
Do a search on Comodo and the issues with them.
Not sure how you will feel about that advice, but it is my considered opinion.
Alan.
Opinion respected.
Been with Comodo many years, prior the initials Windows Firewall, Zonealarm, etc.; this of course, for small networks. We are not closed to try new product, ans reviews comes & go, we sometime consider them.
Thanx
Been with Comodo many years, prior the initials Windows Firewall, Zonealarm, etc.; this of course, for small networks. We are not closed to try new product, ans reviews comes & go, we sometime consider them.
Thanx
For me the shenanigans with certificates is beyond the pale - I think that if they did it now, Google and Firefox would just kill them off, same as they did to Symantec.
The whole PKI / Trusted Root Certificate system relies on us being able to trust the organisations that are given such status.
At the very best, Comodo were negligent in issuing certificates for places like Gmail (mail.google.com), Skype (login.skype.com), and Firefox Addons (addons.mozilla.org).
It just doesn't get any worse than that for me. I still can't understand why Google, Firefox, and Microsoft allowed Comodo to continue to live.
For my customers that require 'higher levels of security' we removed Comodo trusted root certificates. It can cause problems if a user needs to go to a site that uses them, but it now seems very rare that any high profile sites will use Comodo, so in reality it tends to stop people going to less salubrious sites anyway - probably no bad thing.
I don't recall it being raised by those clients for some time now, so perhaps Comodo has already been pushed down market at least, and will get squeezed out with LetsEncrypt taking over the bottom end with free DV certs.
Alan.
At the very best, Comodo were negligent in issuing certificates for places like Gmail (mail.google.com), Skype (login.skype.com), and Firefox Addons (addons.mozilla.org).
It just doesn't get any worse than that for me. I still can't understand why Google, Firefox, and Microsoft allowed Comodo to continue to live.
For my customers that require 'higher levels of security' we removed Comodo trusted root certificates. It can cause problems if a user needs to go to a site that uses them, but it now seems very rare that any high profile sites will use Comodo, so in reality it tends to stop people going to less salubrious sites anyway - probably no bad thing.
I don't recall it being raised by those clients for some time now, so perhaps Comodo has already been pushed down market at least, and will get squeezed out with LetsEncrypt taking over the bottom end with free DV certs.
Alan.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial