Re: RDP stopped working

[Digil (Google Cloud Platform Support)]

This seems like an issue with Remote Desktop Service. I have found a discussion thread here for a similar issue. You can also check this help center article on setting up Remote Desktop on Mac as well. I hope it helps.

Additionally, have you tried to access the machine using a different RDP service(for example Chrome RDP)?    

PS: As this is a public discussion thread, sharing sensitive information like 'Project ID' is not recommended. 

[Peter Hornyack]

Please see our Troubleshooting RDP page for further suggestions.

[Kevin Black]

Look I have the same problem, have read all of the support issues and have read the article you pointed to. That isn't the issue. 

We had RDT working fine on our GCI (Windows Server 2012 R2) for a couple of years. The server reboot and no RDT (also Apache DS will not start, but that's another issue).

I have done the firewall thing and my macOS RDT client has been working for a couple of years NOT now.

Trying to talent to the RDT port, nothing. Doing a port scan shows MYSQL, SMTP and 8080 (our app) open. There is NO 3389 for RDT.

After a reset stop restart and a couple more stop start I got into a second external IP address. I had a look at the services and all seemed OK. Got out and tried to get back in again and got the Please Wait for a couple of hours. Killed that and tried to get back in nothing. Did a stop start and no port 3389 open.

Again several attempts to start stop the instance and the port was visible. Tried to RDT in and got the place wait.

So we have gone from something that just worked for a couple of years and now cannot get in or if we do, then once out we cannot get in again. I've search the net for the last couple of days and not. 

At the risk of sound a bit touchy, please don't ask me to setup the firewall rules, check the account and password etc, these are all OK. The problem is that the port (3389) is NOT being opened.

This from the port scanner:

Starting Nmap 7.70 ( https://nmap.org ) at 2018-08-14 16:14 AUS Eastern Standard Time

Nmap scan report for 128.201.155.104.bc.googleusercontent.com (104.155.201.128)

Host is up (0.17s latency).

Not shown: 97 filtered ports

PORT     STATE SERVICE  NOTE NO PORT 3389 for RDT

25/tcp   open  smtp

3306/tcp open  mysql

8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 29.62 seconds

Any suggestions greatly welcome.

[Kevin Black]

Sorry you probably wanted the project instance etc:

Project ID:  orex-administration

Instance:  orex-admin-instance

[Peter Cort Larsen]

Found it, Google chnaged the IP address

On Monday, August 13, 2018 at 4:32:01 PM UTC+2, Peter Cort Larsen wrote:

Hi again

Some info:

Your Project ID: intranet-test-212118

2. Instance name: ontranetvm

3. Error that you receive when trying to RDP or telnet.

"We couldn't connect to the remote PC. Make sure the PC is turned on and connected to the network, and that remote access is enabled.

Error code: 0x204"

4. How are you trying to RDP (ChromeRDP, Windows RDP etc)?

I am using "Microsoft Remote Desktop 10" on Mac

On Monday, August 13, 2018 at 4:30:00 PM UTC+2, Peter Cort Larsen wrote:

Hi,

I have just finished creating a new VM instance on Google cloud (Windows server 2016).

Yesterday eveing i could connect from my Mac, but today i get this error:

"We couldn't connect to the remote PC. Make sure the PC is turned on and connected to the network, and that remote access is enabled.

Error code: 0x204"

I can ping the IP address

I have no idea how to fix this, can anyone help?

[Fady (Google Cloud Platform)]

@Peter, I am glad to hear that you found the root cause of the issue. An ephemeral (dynamic) IP address may get reassigned when instances shutdown or reboot. As such, and to avoid this situation in the future, you may consider reserving a static IP.

@Kevin, if it is a port issue, it could either be the Google Compute Engine firewall, or your (internal) Windows instance firewall.

As such, If the “default-allow-rdp” rule does not exist in GCE firewall rules, create a new one allowing port 3389 (or any other port that you are using) per this document. Furthermore, if it is your Windows instance firewall, you may open the port, but assuming you are not able to RDP, you may use this method suggested in this thread, or you may have to disable the firewall through a startup script (attach and reboot) per the suggestions at this old thread. I hope this helps.

[Kevin Black]

@Fady

As such, If the “default-allow-rdp” rule does not exist in GCE firewall rules, create a new one allowing port 3389 (or any other port that you are using) per this document.  

Nope, that exists. 

Furthermore, if it is your Windows instance firewall, you may open the port, but assuming you are not able to RDP, you may use this method suggested in this thread, or you may have to disable the firewall through a startup script (attach and reboot) per the suggestions at this old thread. I hope this helps.

I'm using bothe RDT on macOS and RDT on a Windows 10 VM. As per my email and the enclosed port scan data, the RDT port is physically not open on the Server. It does not seem to be any issue with the Apple or Windows clients running RDT. And, again as I note, I have been able to RDT in and then I reboot the server and I cannot. It seems to be on the server side completely NOT on the client side. I am not sure about startup scrips, rapidly getting to my level of competence, but I will have a look and report back. This was all working fine for a couple of years until there was a server reboot (not by us) and it came back with these RDT problems.

Again, in a nutshell the problem is: Port 3389 is NOT being opened on the server. 

[Kevin Black]

@Fady,

Furthermore, if it is your Windows instance firewall, you may open the port, but assuming you are not able to RDP, you may use this method suggested in this thread, or you may have to disable the firewall through a startup script (attach and reboot) per the suggestions at this old thread. I hope this helps.

I must eat humble pie (a bit), but see later - initially worked, but now fails. 

That indeed did work initially (disable firewall). Which isn't a healthy option, but hey. So it appears that the startup Firewall options (in the GCI Console) are NOT working in that port tcp:3389 is just not happening. After a port scan now (BUT See my later port scan):

PORT     STATE SERVICE

25/tcp   open  smtp

3306/tcp open  mysql

3389/tcp open  ms-wbt-server 

I now get out of RDT and try to get back in using the macOS client and I get the please wait image (forever) as in Please Wait......:

So I now cannot get back in because the system will not let me get past whatever it's now doing with the please wait (this was the issue I had previously when I could occasionally get in, a subsequent attempt would result in the please wait screen).

After a reboot (and with the custom metadata still in place) I cannot RDT in (now the error is the same as before 0x204) I do a port scan and port tcp:3389 is no longer there:

PORT     STATE SERVICE

25/tcp     open  smtp

3306/tcp open  mysql

8080/tcp open  http-proxy

OK, so reboot again and now I can login again (gets past the please wait.....). So this is very frustrating, totally repeatable. I login with RDT and I logout and then cannot get back in. Now back in and I am not getting past the please wait....

On a windows system RDT shows this:

AnAuthentication error has occurred

The function request is not supported

Remote Computer: IP ADDRESS

This could be due to CredSSP encryption oracle remediation. 

for more information, see https://go.microsoft.com/fwlink/?linkid=866660

I look at the article and there is an assumption that you can actually get into the system to do a pile of other stuff.

Further stop/start and ms-wbt-server no longer running and the port is obviously closed again. This is like a lottery, only in a lottery at least someone eventually wins.

So, any ideas what I should be trying next, this is now a big deal for us.....

[Fady (Google Cloud Platform)]

Hello Kevin,

Following up on my comment, I meant the firewall of the Windows server hosted on Google Compute Engine, and not your local machine, but I assume you figured it out per your last message. Furthermore, and while the instance is already behind the Compute Engine firewall,  disabling Windows firewall should be temporarily until you fix the root cause of the issue. Another way to troubleshoot is using the serial console per this guide.

Reading your last message, and per this superuser discussion you may either have an un-patched server or RDP client. I am not sure if the port gets blocked because of the CredSSP error, but it seems the connection will be dropped because of “different expectations on the establishment of a secure RDP session”. I also found this third party article that explains “CredSSP encryption oracle remediation” error and suggests a fix (patch both client and server) and workarounds.

As this is a technical issue, and related to OS configuration within the instance itself, and not a general question about Compute Engine or VPC firewall, and for further help, I’d recommend posting your question at serverfault.com which we closely monitor when tagged with [google-compute-engine], and where you have access to a larger community of enthusiasts and experts to share ideas with and get support from.

[Kevin Black]

Hi Fady,

I’d recommend posting your question at serverfault.com which we closely monitor when tagged with [google-compute-engine], and where you have access to a larger community of enthusiasts and experts to share ideas with and get support from.

Will do, and thanks for your help today, it's appreciated.

Kevin