What ports need to be open for Remote Desktop Gateway?

All good now, thank you gents!

0

· · ·

Jalapeno

OP

Biotech Nov 2, 2016 at 04:02 UTC

Stonebridge IT is an IT service provider.

m@x wrote:

I assume your problem is the /v parameter looking at the external address. Change it to internal FQDN of your all-in-one RDS box and post results.

When you are launching the published app you are connecting to the gateway over 443 and asking it to connect you to remote.site.com. The RD Gateway checks DNS and if the public IP is returned, then it tries to connect to itself over the WAN interface. Therefore 3389 needs to be open.

If the above suggestion worked you gotta leave the v/ parameter pointing to the internal FQDN or, if you don't want to expose the internal FQDN make sure your internal DNS returns local ip of the gateway when remote.site.com is queried inside the network.

HTH

Well said. Marking as it a Best Answer - hope that the contributors agree.

0

· · ·

Mace

OP

Da_Schmoo

This person is a verified professional.

Verify your account to enable IT peers to see that you are a professional.

Microsoft Remote Desktop Services expert

50 Best Answers

207 Helpful Votes

M@x is correct - you want /v: to point to the internal FQDN and your external public URL defined in the RD Gateway settings.

Personally, I skip the command line switches. What I do is create an .rdp file with "Computer Name" defined as the internal FQDN. RDGateway in the "advanced" tab defined for the public URL/IP Address, save it and distribute it to the users. I have a generic .rdp I give them to access the RDS Server for a Session Host connection and a second .rdp if they are allowed to access their office PC remotely. Some are, some aren't.

Now that I think about it, I don't even know if there is a command line switch to defined the RDGateway and if not, that makes using /v: moot.

0

· · ·

Tabasco

OP

m@x Nov 2, 2016 at 06:05 UTC

Biotech wrote:

m@x wrote:

I assume your problem is the /v parameter looking at the external address. Change it to internal FQDN of your all-in-one RDS box and post results.

When you are launching the published app you are connecting to the gateway over 443 and asking it to connect you to remote.site.com. The RD Gateway checks DNS and if the public IP is returned, then it tries to connect to itself over the WAN interface. Therefore 3389 needs to be open.

If the above suggestion worked you gotta leave the v/ parameter pointing to the internal FQDN or, if you don't want to expose the internal FQDN make sure your internal DNS returns local ip of the gateway when remote.site.com is queried inside the network.

HTH

Thanks m@x, just saw your post.

Well said. Marking as it a Best Answer - hope that the contributors agree.

Thanks Biotech!

If you want users to RDP into the RDS server only then technically you don't even need to publish the Remote Desktop Connection pointing to /v remote.site.com.

Not that it maters in your single Session Host deployment, but using your approach will skip the Connection Broker part. The connection will be as follows: extuser >> 443 >> Gateway portion >> 3389 >> Session Host (same box). Similar connections happen when external users remote into their corporate computers from outside via the gateway.

If the goal is to allow users to remote into the session host (part of RDS deployment, the server where you deploy and publish user software) then the remote connection was designed to be like this:

extuser >> 443 >> gateway >> connection broker >> session host.

In your case kipping the connection broker won't have any impact because you have a single session host in the collection (farm). If you were to have 2 or more session hosts for high availability, balancing and fault tolerance then the connection broker would play a role of the balancer between SH1, SH2 etc.

In any case, to avoid manually publishing mstsc /v [....] you can remove it and just switch your collection mode from RemoteApp (publishing apps) into the Remote Desktop.

The Remote Desktop icon will automatically show up in the RemoteApp portal. It will be pointing to the Connection Broker as the destination, but that's what you want. The connection broker will know to relay the connection to session host. Since it's all in one box everything happens inside your RDS server.

1

· · ·

Tabasco

OP

m@x Nov 2, 2016 at 06:10 UTC

And if you decide to try it, keep in mind that the Gateway Manager needs to have the connection broker listed in the RAP. Again, in your case it's the same box, so I am sure the server is already in there.

But if you were to have the Session Host and the Connection Broker on different boxes, then you'd need to have both listed in the RAP on the Gateway.

0

· · ·

Tabasco

OP

m@x Nov 2, 2016 at 06:26 UTC

On the second thought your RemoteApp approach still uses the Connection Broker but you run mstsc on the session host to connect to the session host. Basically the server remotes into itself =). I don't know if that makes sense, but if you were to publish calculator then the extuser would run the calculator via gateway > connection broker > session host (running the calc app). So since you published mstsc you are running the app on the session host and then you use it to connect into the session host (itself) =).

But I guess this is the only option if you want to publish other apps. If you put the collection into the Remote Desktop mode, then it will provide full RDP to the session host only. You won't be able to publish apps inside that collection.

I hope I didn't confuse you =)

0

· · ·

Jalapeno

OP

Biotech Nov 2, 2016 at 18:39 UTC

Stonebridge IT is an IT service provider.

Not at all, thanks for the additional follow up and adding value to the thread.

- As far as RAP - right, since it is all-in-one then single server entry was enough. Default policy on deployment was failing and pointed to group "Domain\Domain Computers" so it had to be adjusted. Again, most likely due to DNS translation of the server name when being access from outside and matching (remote.site.com) RD Gateway name was used.

- RemoteApps collection was an idea where Remote Desktop and Apps would be additional nice options (probably will not be used), we really just wanted a secure RDS without having to leave the port 3389 wide open.

- The "/v:server.dom.local" parameter was there as you are right - it won't matter since it would be connecting to itself. For better or worse it triggered us to test manually making .rdp files and hitting it via WAN...which then surfaced the DNS issues that were skipped during deployment.

- Just need to get a valid SSL cert to eliminate lag/validity check during login.

Thank you!

2

· · ·

Tabasco

OP

m@x Nov 2, 2016 at 19:38 UTC

Here's some additional info you might find useful:

When you create RDP files manually, the connection broker is excluded from the connection chain. With this approach you specify the destination computer (rds.domain.local) and the gateway (remote.site.com).

This approach is identical to connecting to another user desktop via gateway (destination: pc01.domain.local, gateway: remote.site.com)

What may go wrong:

In 2012R2 RDS you can assign trusted SSL certificates to the WebApp, Gateway and Connection Broker. You can't assign them to Session Hosts. Therefore, when the user will try to mstsc into internal FQDN of the RDS a cert warning will pop up:

1) user connects to the gateway: remote.site.com:443

2) the gateway provides the trusted SSL cert to the user and validates its servername remote.site.com

3) user requests connection to the destination PC by internal FQDN: rds.domain.local

4) gateway connects it, the destination PC provides its remote desktop cert rds.domain.local (different from gateway SSL cert becausue this time the session host component is engaged, using different cert).

5) user cannot validate the self-signed cert because anything.domain.local is not in its trusted list. Still, they can ignore the warning.

0

· · ·

Tabasco

OP

m@x Nov 2, 2016 at 19:47 UTC

The next logical step would be to give the session host a trusted cert, and the problem is solved, right? Well, there are 2 problems:

Problem 1. You can't assign an SSL cert to a session host just like you do for the gateway and connection broker in the RDS Deployment Properties. You could do it in Server 2008, but Server 2012R2 RDS has been completely re-built with a different concept in mind, where extusers wouldn't care what's behind the connection broker. They are supposed to RDP to the connection broker and all they need is validation of the gateway and validation of the connection broker. Connection broker decides what session host to pick which is absolutely transparent for extusers.

Problem 2. There is a trick to assign a trusted cert to the session host, but then you need the destination PC name to match the name on the SSL cert. Meaning that you need to mstsc into remote.site.com via remote.site.com bringing you to square 1 (mstsc /v remote.site.com)

If you are interested I can suggest a way to eliminate SSL problems down the road.

0

· · ·

Jalapeno

OP

Biotech Nov 2, 2016 at 20:18 UTC

Stonebridge IT is an IT service provider.

Sure, I am all ears - send PM if you feel that discussion is going OT. As I said before I am rusty, my last deployment was on 08 (its nice to have engineers standing by) but if I remember correctly we were able to add two entries "rds.domain.local" and "remote.site.com" into a single cert. This would be a hosted server so no 'internal' users, this time difference would be we are planing on using a wildcart cert.

Not sure if it is worth the effort (and pain of renewals) since even self published certs can be imported/trusted and the client could care less for the little 'ssl validation badge' if they are not hitting https://.../RDweb. Though their machines could potentially get compromised, and DNS spoofed then redirected to a fake RDS to harvest logins even if they are using .RDP file...perhaps my tinfoil hat needs to be put away.

0

· · ·

Tabasco

OP

m@x Nov 2, 2016 at 22:18 UTC

Ok, I'll write in here, maybe someone else finds it useful.

we were able to add two entries "rds.domain.local" and "remote.site.com" into a single cert.

If you purchase a wildcard for *.site.com then your additional subject alternate names must be subdomains of site.com, for example you can add rds.ad.site.com but not rds.site.local.

In this case yes, it is possible to establish RDP via the gateway directly into the remote server. This is equal to connect to any other workstation via gateway. Connection broker and Session Host components aren't engaged.

2012R2 RDS concept the way I see it:

The core of the RDS deployment is the connection broker (RDCB). Everything else spins around it. You can completely remove or add gateways (RDGW) and session hosts (RDSH) without decommissioning your deployment. You can't do it with the RDCB.

On one side of RDCB there is a pool of session hosts, grouped into Collections (collection = farm). On the other side of RDCB there is the gateway server, allowing and securing connections from the outside, and the Web Access server (RDWA) that provides IIS web portal with the list of published applications.

When you publish an app, you do it on the collection level. The RDWA is simply providing a web interface for users to download the RDP file for the RemoteApp. The rest of the configuration is inside the RDP file.

So when you have a RDCB and 6 session hosts (RDSH1-6) you can technically do this:

Create Collection1 and make RDSH1,2 members of it. Then Collection2 with RDSH3-4 members. One session host can't be a member of 2 collections. Those are 2 different farm entities.

When you publish an app, you publish it on the collection level, not session hosts. If you publish Calculator to Collection1, then the RDCB will ensure that the app exists on all members of that collection (RDSH1 and 2) and then publish it.

When the user logs into the portal (RDWA) and downloads the calculator app, it's a simple RDP file that contains the following configuration:

Gateway: remote.site.com

Remote computer: remote.site.com (as the connection broker, not session host)

Collection name: Collection1

Application name: calc.exe

That's it. No session hosts mentioned. When the extuser launches the RDP file, it will initiate conversation with the connection broker. The connection broker will see your request, check the loads on RDSH1 and RDSH2, pick one, and have it launch the calculator remoteapp for your remote use. This approach make perfect sense - it allows you to add (ore remove) new session hosts to the collection without altering user RDP files. Their single point of contact is the connection broker.

From the extuser perspective it needs to validate 3 things:

- the identity of the gateway (*site.com)

- the identity of the broker (*.site.com)

- the identity of the Calculator software publisher > this is not your SSL cert. This is the publisher thumbprint (separate topic)

1

· · ·

Tabasco

OP

m@x Nov 2, 2016 at 22:35 UTC

Now the next thing worth mentioning is the 2 modes of a collection: RemoteApp and Remote Desktop.

Any collection you create can operate in one of the two modes. If you want both, full RDP and publish remote apps, then you need to create 2 separate designated collections. Each collection requires at least one session host. So you will need a minimum of 2 RDSH to create 2 collections - one for full desktop RDP and one for RemoteApps.

The collection mode does not exist as a setting that you can change. It changes automatically for you. When you don't have any RemoteApps published inside the collection it is set in the Remote Desktop mode and provides Full RDP to your server farm/collection. As soon as you start publishing anything it will switch to RemoteApp mode.

Out of curiosity, go ahead and unpublish your mstsc so there are no applications published. Then make sure your collection resources has changed to "Remote Desktop" (in the screenshot I posetd yesterday).

Then log into the Web App portal and you will see the RDP conneciton file there. This one is different that yours though.

I suggest you deploy this file to all users and you will have the result you wanted.

What this file does differently:

Instead of RDP-in directly into the server name rds.ad.site.com via gateway remote.site.com it does the following:

1. connects to the connection broker side via the gateway telling it the name of the collection (Collection2 for example)

2. The broker sees that the collection is in Remote Desktop mode, no apps published, so then the full RDP is used.

3. The broker looks up the list of session hosts that are members of Collection2, checks which one is more available and connects you to that one.

From the extuser perspective - no session host names involved. In fact, if you look at the blue RDP stripe at the top, there will be the name of the connection broker, not session host (you won't notice - they're all in one box in your case).

Benefits? Scalability transparent for users. You just deploy another session host, with similar software and add it to the collection, boom, you got load balancing without even changing that RDP file that your users have downloaded 3 years ago.

Hope this helps =)

P.S. Oh, and when you use the Remote Desktop mode, you won't be warned about the unknown software publisher - since you're not using the RemoteApp.

Good luck!

1

· · ·

Jalapeno

OP

Biotech Nov 2, 2016 at 23:44 UTC

Stonebridge IT is an IT service provider.

Then I assume your AD domain is a subdomain of site.com, something like ad.site.com?If you purchase a wildcard for *.site.com then your additional subject alternate names must be subdomains of site.com, for example you can add rds.ad.site.com but not rds.site.local.

3. The broker looks up the list of session hosts that are members of Collection2, checks which one is more available and connects you to that one.

From the extuser perspective - no session host names involved. In fact, if you look at the blue RDP stripe at the top, there will be the name of the connection broker, not session host (you won't notice - they're all in one box in your case).

Benefits? Scalability transparent for users. You just deploy another session host, with similar software and add it to the collection, boom, you got load balancing without even changing that RDP file that your users have downloaded 3 years ago.

Thanks for the great write ups, very kind of you to share!

All the best.

0

This topic has been locked by an administrator and is no longer open for commenting.

To continue this discussion, please ask a new question.