Help getting RDS Web over 443 instead of 3389?

R.O.S.S.I · 7 Mar 2013 at 12:07

Hi all, having a bit of a problem at the moment with our RDS Remote Web Access and getting it to work with some other organizations firewalls/proxies etc.

Just a bit of background, the RDS server is setup and running fine, the certificate is installed correctly and users can access the web gateway via https://remote.ourdomain.co.uk/, they can log in and they can run either a published App or click Remote Desktop to load straight into a desktop. All of this works fine.

We have some members of staff who have been seconded out to work in other partner organizations and I am coming against a problem whereby our remote access isn't being allowed through their proxies/firewall/whatever because when it makes a connection back to our server it does so on port 3389 directly, which is a big no-no. Now i'm under the understanding that the SSL port 443 is a port which will allow the traffic through but i'm a bit stumped at the moment in how to get the traffic routing over that so that it can traverse any firewalls and proxies it comes to without any problems.

I'm not the greatest with all this RD Web remote access stuff so i'm not entirely sure if ive missed off a simple option, or if the way I have configured it is prohibiting it from being sent out over 443.

I have 2 rules set up on our Draytek. One is to forward port 3389 on one WAN IP (the one that is pointing to our web access page) to 3389 on the RDS server (if I don't have this setup when a user clicks on the remote desktop link they can't get in, it just thros up an error when trying to connect).
And another is port forwarding of 443 from the same WAN IP to the same RDS server (if I dont have this setup users can't access our https://remote.ourdomain.co.uk/ )
I'm not sure if these play any part in all of this.

I have no idea if this is the correct way to do things but that's how I got it all to work in the first instance and upon looking at a packet tracer I can see that when it does connect it connects on 3389.

Is anyone able to offer any advice/guidance on how I might get it so that all the data is sent over 443 instead of 3389?

marc2003 · 7 Mar 2013 at 13:29

i don't think you can simply change ports to something that's commonly in use and expect to get through. if they're stopping RDP, they're probably blocking the whole protocol, not just the port. it would be inept of them to block 3389 and allow it out on another port.

you should ask the network admins their end before spending any more time on this.

ecksmen · 7 Mar 2013 at 13:32

Do you have remote desktop gateway installed? It sounds like you are just using the webaccess to give a nicer interface to users providing them each with essentially an RDP shortcut (ie Via TCP 3389). It doesn't seem like you are tunnelling 3389 over SSL via the remote desktop gateway feature.

EDIT

To give a bit more understanding

RDGW is exposed to the internet on TCP 443 only (so needs the cert installing on). You specific criteria on here on who can connect to what (CAP / NAP). Users connect to this address (ie rdp.yourdomain.co.uk) as the connect anywhere feature on MSTSC.exe. When they connect they'll hit the RDGW on 443, which will then tunnell 3389 via 443. You do not need 33389 open at all (other than from the RDGW to the target machine).

R.O.S.S.I · 7 Mar 2013 at 14:27

I think I may have sussed it and it was to do with the gateway role not being set up correctly.

Going to do a bit more testing from home with packet tracer etc first but did some tests from work on a laptop with a dongle and it looked like it was going over port 443 now instead of 3289!

Hellsmk2 · 7 Mar 2013 at 22:24

ecksmen said:
Do you have remote desktop gateway installed? It sounds like you are just using the webaccess to give a nicer interface to users providing them each with essentially an RDP shortcut (ie Via TCP 3389). It doesn't seem like you are tunnelling 3389 over SSL via the remote desktop gateway feature.

EDIT

To give a bit more understanding

RDGW is exposed to the internet on TCP 443 only (so needs the cert installing on). You specific criteria on here on who can connect to what (CAP / NAP). Users connect to this address (ie rdp.yourdomain.co.uk) as the connect anywhere feature on MSTSC.exe. When they connect they'll hit the RDGW on 443, which will then tunnell 3389 via 443. You do not need 33389 open at all (other than from the RDGW to the target machine).

This.

You really don't want 3389 exposed to the internet. Asking for trouble.

R.O.S.S.I · 8 Mar 2013 at 08:32

Yeh I gathered its not the greatest thing to have open on your router!

Just doing some final testing but hopefully got it sorted! One last stumbling block i've come across is getting this to work on XP? It's working fine on Windows 7, but XP doesn't seem to be playing ball when trying to load up a remote desktop.

Is there any particular config I need to check?

ecksmen · 9 Mar 2013 at 09:19

You need to use the RDP client version 7 for xp. http://support.microsoft.com/kb/969084

R.O.S.S.I · 9 Mar 2013 at 14:52

Yeh think that is the issue, just waiting for them to get back to me on whether it has worked or not - its either that or need to enable CredSSP.

pjansell · 9 Mar 2013 at 23:10

SSO over TS Web/RDWeb requires both RDP 7.x and CredSSP in order to function properly.

Similiarly as the guys have said block 3389 on your perimeter appliance, and make sure all your users are routing through your TS Gateway.

When we set this up originally, most of our problems related to trust issues and certificates, in particular the TS Gateway certificate was from a Public CA, where as the remote app host server was on a different internal box, with a different name.

In retrospect we should have gone with a wildcard cert, but as money was tight we generated our own cert for the internal box, signed the remote apps with that, and pushed it out to our clients over AD/GP.

Setting the 'private' option as the default selection on the login page for RDWeb to circumvent the cert warnings/and store passwords etc, was too much of a liability for us - but we got there in the end. Funny thing is we've just moved everyone over to citrix about a month ago, which we've found to be infinitely better than RDS for the purposes intended.

R.O.S.S.I · 11 Mar 2013 at 14:29

pjansell said:
SSO over TS Web/RDWeb requires both RDP 7.x and CredSSP in order to function properly.

Similiarly as the guys have said block 3389 on your perimeter appliance, and make sure all your users are routing through your TS Gateway.

When we set this up originally, most of our problems related to trust issues and certificates, in particular the TS Gateway certificate was from a Public CA, where as the remote app host server was on a different internal box, with a different name.

In retrospect we should have gone with a wildcard cert, but as money was tight we generated our own cert for the internal box, signed the remote apps with that, and pushed it out to our clients over AD/GP.

Setting the 'private' option as the default selection on the login page for RDWeb to circumvent the cert warnings/and store passwords etc, was too much of a liability for us - but we got there in the end. Funny thing is we've just moved everyone over to citrix about a month ago, which we've found to be infinitely better than RDS for the purposes intended.

We had a very old Citrix essentials install on a 2003 box which was't the greatest. As we were upgrading all our servers to 2008R2 I took it as an opportunity to bin the old 2003 server and set up RDS.

It works perfectly for what we need and as I had absolutely no experience of Citrix and its configuration etc it made sense to go with RDS (not to mention the cost of Citrix).