Windows 2016 remote desktop collection not accessible externally
Hello! We're moving from 2008R2 to 2016 for RDS and we'd like to open it to a test group to iron out any issues before switching. Our '08R2 farm is still operational and working. We've created a 2016 RDSH collection with 1 RDCB, 1 RDGW and 3 RDSH servers. The 3 RDSH servers are in a collection called rdfarm.
The issue: We can successfully connect to the collection internally by using the RDP shortcut downloaded from RWA however, it does not work outside our office. When attempting to connect from a home PC, it shows the correct FQDN but then an error is returned that remote desktop can't connect to the remote computer due to remote access is not enabled, the remote comuter is turned off or the remote computer is not available on the network.
A couple of notes about our deployment:
1) The GW & RWA services are on the same machine.
2) We will not be using RWA for our users, just RDP for connecting externally.
3) Our internal domain is .local, so we have split DNS. We have a forward zone for both rdfarm.domain.com (A record for the IP of rdcb1) and rdgw1.domain.com (A record for the IP or rdgw1).
4) We're using a wildcard cert from GoDaddy and it's trusted on both the GW & CB. It's been installed on all 3 RDSH servers as well.
5) The collection name has been set in the registry of the CB.
6) The firewall rule is this
rdfarm.domain.com:443->rdc
Things we've checked:
1) Port scan shows that port 443 is open and accessible from the IP and FQDN for the collection externally.
2) A packet capture shows traffic is coming in through our firewall to rdcb1.
Any suggestions on what we could check to see why the RDP connection is unsuccessful?
The issue: We can successfully connect to the collection internally by using the RDP shortcut downloaded from RWA however, it does not work outside our office. When attempting to connect from a home PC, it shows the correct FQDN but then an error is returned that remote desktop can't connect to the remote computer due to remote access is not enabled, the remote comuter is turned off or the remote computer is not available on the network.
A couple of notes about our deployment:
1) The GW & RWA services are on the same machine.
2) We will not be using RWA for our users, just RDP for connecting externally.
3) Our internal domain is .local, so we have split DNS. We have a forward zone for both rdfarm.domain.com (A record for the IP of rdcb1) and rdgw1.domain.com (A record for the IP or rdgw1).
4) We're using a wildcard cert from GoDaddy and it's trusted on both the GW & CB. It's been installed on all 3 RDSH servers as well.
5) The collection name has been set in the registry of the CB.
6) The firewall rule is this
rdfarm.domain.com:443->rdc
Things we've checked:
1) Port scan shows that port 443 is open and accessible from the IP and FQDN for the collection externally.
2) A packet capture shows traffic is coming in through our firewall to rdcb1.
Any suggestions on what we could check to see why the RDP connection is unsuccessful?
Last Comment
ASKER
The RDWA generated shortcut is being used.
Your firewall rule is wrong as well. Pointing 443 to the CB does nothing. You are trying to bypass the GW, which defeats the purpose of the GW. And the CB doesn't listen on 443.
And step/point 5 simply doesn't make sense to me. In a properly set up environment, you don't set anything manually in the registry. The RDCB does intelligent load balancing and will redirect to individual machines as needed. Setting the farm name in the registry just doesn't make sense.
ASKER
Thank you for your input. Before responding to your points, I'm going to go back over the several different documents we followed for setting this up.
ASKER
Regarding step 5, we found in the documentation that the registry setting was only needed if you were doing SQL HA load balancing with your connections brokers. We've removed that but we're pretty sure it wouldn't affect our ability to connect externally.
We're still looking for where it was documented to point to the CB vs the GW. We thought that was strange too since our original '08R2 farm points to the GW.
We're still looking for where it was documented to point to the CB vs the GW. We thought that was strange too since our original '08R2 farm points to the GW.
ASKER
After making the recommended changes pointing to the GW instead, we now get this if we attempt to connect internally or externally with the RDP shortcut from RWA after entering our login credentials:
The user account is a member of the group specified in the CAP/RAP policies. There is a corrected forward zone in DNS for the FQDN (rdfarm.domain.com) that includes an A record pointing to the internal IP of the GW (10.10.40.13).
The firewall record is now: rdfarm.domain.com:any->rdg
The user account is a member of the group specified in the CAP/RAP policies. There is a corrected forward zone in DNS for the FQDN (rdfarm.domain.com) that includes an A record pointing to the internal IP of the GW (10.10.40.13).
The firewall record is now: rdfarm.domain.com:any->rdg
Those three possibilities are pretty accurate.
1) Could be a policy issue with the CAP/RAP policies (I always recommend keeping defaults first, then customizing *AFTER* you have the platform working. Right now you have no way of verifying if this *EVER* worked.)
2) See #1. Policies can be created in a way that specifically exclude machines that have trust issues (SSL related often)
3) Could be testing with a server out of date on patches. Or a client out of date on patches. In particular, there are the Oracle remediation patches from March that need to properly match.
1) Could be a policy issue with the CAP/RAP policies (I always recommend keeping defaults first, then customizing *AFTER* you have the platform working. Right now you have no way of verifying if this *EVER* worked.)
2) See #1. Policies can be created in a way that specifically exclude machines that have trust issues (SSL related often)
3) Could be testing with a server out of date on patches. Or a client out of date on patches. In particular, there are the Oracle remediation patches from March that need to properly match.
And just to clear this up, even internal connections start out using the Gateway. There is a checkbox to bypass the gateway for internal connections, but that still needs to establish the connection (via the gateway) to determine if the redirect is internal or external. So this is purely a gateway/client configuration issue and yes that does impact internal connections.
ASKER
Thank you very much for your responses. I'm going to respectfully disagree with it being a CAP/RAP policy issue because I didn't state that I changed the CAP/RAP policies, I was just clarifying the membership of the user we are testing with just to be thorough and it was working internally prior to the changes I listed. For further clarification, the only change that was originally made in each policy during the initial setup was to the user groups and that was from Domain users to RDSLicensedUsers, which is the group we use to manage user access in our current RDS farm.
Bypassing the gateway for internal addresses is not checked.
All servers in this farm are current on Windows updates. There is no other software installed on any of them besides Notepad++. The test PC, which is a Windows 10 Pro machine, is current on updates as well.
Bypassing the gateway for internal addresses is not checked.
All servers in this farm are current on Windows updates. There is no other software installed on any of them besides Notepad++. The test PC, which is a Windows 10 Pro machine, is current on updates as well.
" I'm going to respectfully disagree with it being a CAP/RAP policy"
Agree. Disagree. Whatever. I didn't say it *was* a problem. Given the error you posted, I said it was a *POSSIBILITY.*
" I didn't state that I changed the CAP/RAP policies, "
" the only change that was originally made in each policy "
Right. So you made changes. You may or may not have made them or reverted them properly. And you clearly followed bad guidance earlier.
In short, this is a forum. I can look at what was posted and make some LIMITED guesses and advice. You have a few choices:
1) Take the advice as given and try to figure it out.
2) Hire a consultant who can actually LOOK at these things instead of guess.
3) Do your own thing and take pot-shots at volunteers helping.
If this is a new setup not yet in production, I might advice to hit the self-destruct button then start over without registry entries, changed policies, or bad documentation that has you forwarding ports to the RDCB. Find the official docs and follow them for a clean trusted install.
Other than that, I believe I've hit the edge of what can be recommended over a forum given there are clearly multiple misconfigured items and a resistance to consider the possibilities of the cause. Maybe another expert will chime in. But I have nothing currently left to offer.
Agree. Disagree. Whatever. I didn't say it *was* a problem. Given the error you posted, I said it was a *POSSIBILITY.*
" I didn't state that I changed the CAP/RAP policies, "
" the only change that was originally made in each policy "
Right. So you made changes. You may or may not have made them or reverted them properly. And you clearly followed bad guidance earlier.
In short, this is a forum. I can look at what was posted and make some LIMITED guesses and advice. You have a few choices:
1) Take the advice as given and try to figure it out.
2) Hire a consultant who can actually LOOK at these things instead of guess.
3) Do your own thing and take pot-shots at volunteers helping.
If this is a new setup not yet in production, I might advice to hit the self-destruct button then start over without registry entries, changed policies, or bad documentation that has you forwarding ports to the RDCB. Find the official docs and follow them for a clean trusted install.
Other than that, I believe I've hit the edge of what can be recommended over a forum given there are clearly multiple misconfigured items and a resistance to consider the possibilities of the cause. Maybe another expert will chime in. But I have nothing currently left to offer.
ASKER
Thank you for your time, we'll see if someone else can provide suggestions.
ASKER
Since this has not become an actual production environment yet and it was noted that we possibly followed some incorrect documentation, we rebuilt the farm from scratch following only these 2 documents:
https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-deploy-infrastructure
http://www.jschweg.com/2016/12/properly-configuring-ssl-certificates-for-remote-desktop-services/
After doing this, we cannot access it internally. Here is the current error:
Updated notes about our deployment:
rdgw - remote desktop gateway
rdcb - remote desktop connection broker
1) We are testing with the RDP shortcut downloaded from RDWA.
2) No CAP/RAP policies have been modified.
3) The GW & RWA services are on the same machine.
4) We will not be using RWA for our users, just RDP for connecting externally.
5) Our internal domain is .local, so we have split DNS. We have a forward zone for both rdfarm.domain.com (A record for the IP of rdgw) and rdcb.domain.com (A record for the IP of rdcb).
6) We're using a wildcard cert from GoDaddy and it's trusted on both the GW & CB. It's been installed on all 3 RDSH servers as well.
7) We have a public DNS A record for rdfarm.domain.com.
8) The firewall rule is this
rdfarm.domain.com:443->rdg
Any input on what to look at would be appreciated.
https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-deploy-infrastructure
http://www.jschweg.com/2016/12/properly-configuring-ssl-certificates-for-remote-desktop-services/
After doing this, we cannot access it internally. Here is the current error:
Updated notes about our deployment:
rdgw - remote desktop gateway
rdcb - remote desktop connection broker
1) We are testing with the RDP shortcut downloaded from RDWA.
2) No CAP/RAP policies have been modified.
3) The GW & RWA services are on the same machine.
4) We will not be using RWA for our users, just RDP for connecting externally.
5) Our internal domain is .local, so we have split DNS. We have a forward zone for both rdfarm.domain.com (A record for the IP of rdgw) and rdcb.domain.com (A record for the IP of rdcb).
6) We're using a wildcard cert from GoDaddy and it's trusted on both the GW & CB. It's been installed on all 3 RDSH servers as well.
7) We have a public DNS A record for rdfarm.domain.com.
8) The firewall rule is this
rdfarm.domain.com:443->rdg
Any input on what to look at would be appreciated.
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Windows 10
Windows 10 is a personal computer operating system featuring the "universal application architecture" (UAP); apps can be designed to run across multiple devices with nearly identical code, including PCs, tablets, smartphones, embedded systems, Xbox One, Surface Hub and HoloLens. Windows 10 also includes a virtual desktop system, a window and desktop management feature called Task View, the Microsoft Edge web browser, support for fingerprint and face recognition login, voice-based search (Cortana), new security features for enterprise environments, and DirectX 12 and WDDM 2.0 to improve the operating system's graphics capabilities for games.
20K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
The RDP files that RDWA generates include a collection name in the file. This property CANNOT be manually entered in the GUI.