Windows 2012 R2 Terminal Services Remote Desktop connection internal error

The client is running Windows Server 2012 R2 Standard with Terminal Services, and they’re having a problem where Remote Desktop Connection is getting an error.

Network components involved

Microsoft Windows Server 2012 R2 Standard
Terminal Services
Windows 10 Thin Client
Windows 7 Client
Remote Desktop Connection
Sophos UTM 9 Firewall
Network Address Translation (NAT)

Remote Desktop Connection error

This is the error message:

Remote Desktop Connection
An internal error has occurred.

I wasn’t able to connect from my OSX laptop using Microsoft Remote Desktop v8.x for Mac, but after upgrading I could connect using Microsoft Remote Desktop 10.x no problem.  I also installed an RDP client on my iPhone and it too connected.  However, when testing from a Windows 7 VM  or remotely from the client’s office using a Windows 10 Thin client, it would look like it’s connecting the server, show certificate warning and then fail during the login process.  I could see on the server the remote IP when using netstat on the correct port number coming through the Sophos firewall.

The Window 2012 R2 server is located in a data center behind a Sophos UTM 9 firewall, and the firewall is running NAT from public IP address to the private subnet. It’s also set up with port forwarding enabled for RDP.  The customer is running RDP not on 3389, but a higher port number.

Everything was working okay until one-day OSX, iOS, and even Android can connect but none of the Windows clients.

We also saw during the debugging process that the Windows Server certificate for Terminal Services regenerated a few days earlier, after going down that rabbit hole and still not fixing the issue, that ultimately didn’t end up being the actual problem.

Resolution

Mainly what happened is the Sophos Intrusion Detection was allowing the IP to connect but then blocking the user’s Terminal Services connection during the negotiation process.

After adding a rule into the Sophos to pass all traffic on the custom RDP port Windows, clients were now allowed to connect to the server once again.