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:

  • 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?
rayluvsAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Timothy McCartneySYS ADMINISTR I INFRASCommented:
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\CurrentControlSet\Control\Terminal Server
Change fDenyTSConnections from 1 to 0

After you make the change, reboot the PC and try using RDP to connect to it again.
0
Timothy McCartneySYS ADMINISTR I INFRASCommented:
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
0
rayluvsAuthor Commented:
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:

  TCP    [::]:54661             xPc-Accounting:0      LISTENING
  TCP    0.0.0.0:54661          xPc-Accounting:0      LISTENING
  UDP    [::]:54661             *:*                    
  UDP    0.0.0.0:54661          *:*         

Open in new window

         

Yet didn't find it in the actual IP lines,
TCP    192.168.0.11:139 
TCP    192.168.0.11:49708
etc.

Open in new window


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

Open in new window

0
Become a Certified Penetration Testing Engineer

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

AlanConsultantCommented:
Hi,

Can you telnet from the guest to the remote host?

Telnet 192.168.0.11:54661

Open in new window



Alan.
0
rayluvsAuthor Commented:
When I run this on the computer that need to connect to Host computer, I get:
Connecting To 192.168.0.11:54661...Could not open connection to the host, on port 23: Connect failed

Open in new window


When I run this at the host computer, I get:
192.168.0.11:54661...:

Open in new window


What do u think is happening?
0
AlanConsultantCommented:
Hi,

My apologies - I mistyped.  Please try this instead:

Telnet 192.168.0.11 54661

Open in new window


Space instead of the colon.


Thanks,

Alan.
0
rayluvsAuthor Commented:
Oh ok.... will try tomorrow.
0
rayluvsAuthor Commented:
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)
cmdtelnet
0
rayluvsAuthor Commented:
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:
  • 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.
0
rayluvsAuthor Commented:
Update:

  • 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.
0
rayluvsAuthor Commented:
Just updated Comodo on both computers with  the latest update, restarted and bang!!!! Works!!!

Don't understand.

Please shed some light EE....
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
rayluvsAuthor Commented:
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.
0
rayluvsAuthor Commented:
Chose our entry since it solved our problem.
0
AlanConsultantCommented:
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.
0
rayluvsAuthor Commented:
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
0
AlanConsultantCommented:
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.
0
rayluvsAuthor Commented:
Curious, why “... with certificates is beyond the pale ”; why?
0
AlanConsultantCommented:
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.
0
rayluvsAuthor Commented:
Understood.

Thank you.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Remote Access

From novice to tech pro — start learning today.