Windows Server Summit 2024
Mar 26 2024 08:00 AM - Mar 28 2024 04:30 PM (PDT)
Microsoft Tech Community
LIVE
SOLVED

RDS connections are Not using HTTPS

MVP

I've built a VDI with 3 Windows server 2019 on Hyper-V on Windows 10 pro latest version. testing it on my local network, when clients connect to the RDS server, gateway manager shows the connections are based on HTTP and UDP only, no word about HTTPS.

i have my own enterprise CA and clients first connect through an SSTP VPN which is hosted in one of those servers and then use the internal DNS name of the RDS server to connect to it. the reason for the SSTP VPN is to first secure the connection and second to access the internal DNS servers.

without VPN the client can't use the internal DNS names of the servers.

I have an external domain name pointed to my VPN server which is globally resolvable and clients can easily connect to my VPN server first and then have access to the internal DNS server.

 

 

 

here is in default gateway manager

 

Annotation 2019-09-07 150955.png

 

i get this error when i try to turn of UDP:

 

Annotation 2019-09-07 151155.png

 

here is how the connection looks like when a client first connects to the SSTP VPN and then to the RDS host using RDP.

 

Annotation 2019-09-07 151017.png

 

Everything is set up correctly AFAIK, the certificates are ok, PKIVIEW is all ok, the connection is ok. i just don't know why i'm not seeing HTTPS connections in Gateway manager.

3 Replies

@HotCakeX 

 

Try adjusting the following

 

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core

and change the Key IsUdpEnabled  to 0  (instead of 1)

 

Give that a try. I know of a bug in Server 2019 where UDP could not be unchecked in the GUI so has to be done via the registry.

Now the UDP is gone and only the HTTP connection on port 3389 is shown in gateway monitoring. still no HTTPS
best response confirmed by HotCakeX (MVP)
Solution

Some updates,
I got an answer from a Microsoft expert and he said that

"With an RDP Gateway in the connection path it will end up RDP over HTTPS on port 443 and the Gateway will NAT that traffic back to 3389 to the endpoint on the LAN."

so that's probably why I'm seeing 3389 HTTP on the gateway monitoring because it only shows the endpoint and not what is happening before NAT.

I know it's possible to verify that by using tools such as Wireshark or Fiddler and i will do that later.

my RDGateway is on the same server as the rest of the VDI components, my VPN server is the only one behind DMZ, i haven't opened any ports manually in the firewalls. so i guess i'm gonna be fine.

 

 

Another option that can be used with success is Azure App Proxy and RDP Gateway to help secure this while not requiring a VPN with Pre Auth at the Azure AD level.

Details on that secure method of publishing RDP Gateway in the link below

  https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-integrate-with...

1 best response

Accepted Solutions
best response confirmed by HotCakeX (MVP)
Solution

Some updates,
I got an answer from a Microsoft expert and he said that

"With an RDP Gateway in the connection path it will end up RDP over HTTPS on port 443 and the Gateway will NAT that traffic back to 3389 to the endpoint on the LAN."

so that's probably why I'm seeing 3389 HTTP on the gateway monitoring because it only shows the endpoint and not what is happening before NAT.

I know it's possible to verify that by using tools such as Wireshark or Fiddler and i will do that later.

my RDGateway is on the same server as the rest of the VDI components, my VPN server is the only one behind DMZ, i haven't opened any ports manually in the firewalls. so i guess i'm gonna be fine.

 

 

Another option that can be used with success is Azure App Proxy and RDP Gateway to help secure this while not requiring a VPN with Pre Auth at the Azure AD level.

Details on that secure method of publishing RDP Gateway in the link below

  https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-integrate-with...

View solution in original post