This post has already been read 31718 times!
I was recently looking at Microsoft RDS on Server 2016 TP5 as an alternative to running full blown XenDesktop and wanted to take it for a spin in my lab.
This was OK in principle but I also did not want to shut down my XenDesktop estate and start to change firewall rules to get remote access to my RDS Apps and Desktops. So, with this in mind I started to look at the options around Unified Gateway and presenting out my RDS deployment via that.
I was having a few issues getting everything running as it should within RDS (I like to have no single points of failure) and he was kind enough to give me a preview of his new book coming out – RDS 2012 R2 Complete. I have to say that it is brilliant – I went from knowing a little about RDS 2012 R2 to having a full blown, highly available, Azure hosted RDS platform within days. If you are not following him already on twitter then click his name above, follow him and grab a copy of the book when it comes out.
Please note in this post I WILL NOT be describing any RDS configuration as Claudio does that in his book and is far better qualified to do so! If you want to know that part then reach out to him and buy yourself a copy.
So, onto my issue. I only have 1 external IP Address and limited compute at home, therefore I needed to use Microsoft Azure and NetScaler Unified Gateway to get this all off the ground and accessible from anywhere.
First, my RDS Deployment is all hosted in Azure using the ARM method. All of these servers can be routed to from my internal network and vice versa. If you want to know how to expand your lab into Microsoft Azure then read my previous post here:
Below is what I have installed to run my RDS environment.
Essentially I have 2 FQDN’s that I am going to be using
- remote.bretty.me.uk – This is for RDS Gateway and Web Access
- enroll.bretty.me.uk – This is for the RDS Connection Brokers
I know that enroll is not the best URL but I don’t have a wildcard certificate just a SAN one so that was my best option with what I have.
So, ALL the Certificates on my RDS deployment are externally minted certs and I have added dns zones ONLY for my 2 FQDN’s enroll and remote. The reason for this is that I run bretty.me.uk as my external site and do not have split brain DNS, it also needs to be accessable from my internal network so adding bretty.me.uk as a zone was not an option for me.
Once again Claudio’s book does a great job of explaining why to use external FQDN’s for Gateway, Web and Brokering services within RDS so I will not go into it here.
Onto the NetScaler Part.
I have the Web and Gateway parts of RDS running on the same servers and Connection Brokering running on another pair of servers.
RDS Gateway and Web Service Load Balancers
TCP 443 vServer
Set up a SSL vServer load balancing the 2 Gateway/Web Servers running on port 443. You can make this non-addressable but as I want to access this internally and externally I want to give it a valid address on my LAN.
Bind your external certificate to the vServer
and set the persistence to Source IP with your required time out
Finally create a rewrite policy to redirect the user to /RDWeb if you are hosting Web Access on this server. This is not required but will prevent the user having to remember to add the /RDWeb when typing in the URL
Click OK to create the vServer
UDP 3391 vServer
Create another Load Balanced vServer on the SAME IP as the previous vServer but use UDP port 3391 as the service.
Load balance the same 2 gateway servers and leave the rest as default
Point Internal DNS Name to Load Balancer IP Address
Add a BLANK A record to the new dns zone you created earlier (in my case remote.bretty.me.uk) this will direct internal traffic to the load balancer internally and external traffic will hit your firewall
RDS Connection Broker Load Balancers
TCP 443 vServer
Create a new vServer on port 443 load balancing the 2 RDS Connection Brokers you have. Give it a valid internal IP as you will also want to access this both internally and externally
Again – make sure you add your external certificate to this and set any persistence options you require
TCP 3389 vServer
Create another Load Balancer on the SAME IP as the Connection Brokers but this time use TCP port 3389 to take in and load balance RDP traffic passed from the gateway servers
Just ensure that you select both connection brokers to load balance and you can leave the remaining settings as default
Point Internal DNS Name to Load Balancer IP Address
Add a BLANK A record to the new dns zone you created earlier (in my case enroll.bretty.me.uk) this will direct internal traffic to the load balancer internally and external traffic will hit your firewall
External Access – note it is the same IP Address as remote.bretty.me.uk
Putting it all together
So, you now have load balancers for the Gateway and Web Servers on TCP port 443 and UDP port 3391 as well as Load Balancers for the Connection Brokers on TCP port 443 and TCP Port 3389
Internally (As you added new zones) it should all work perfectly now.
Integrate it with Unified Gateway
At home I have Citrix Unified Gateway running and therefore have a Content Switch and NetScaler Gateway in place and running. I have a firewall rule to direct all incoming SSL traffic to my Unified Gateway (Content Switch) running on IP Address 192.168.0.105. With that in mind I need to handle the UDP 3391 traffic. I have set up another rule to direct all UDP 3391 traffic to the SAME IP Address
Now that the firewall rules are in place we need to sort out the content switching.
What we are after is:
- All remote.bretty.me.uk TCP traffic on port 443 to be redirected to our SSL vServer for Gateway and Web
- All remote.bretty.me.uk UDP traffic on port 3391 to be redirected to our UDP vServer
- All enroll.bretty.me.uk TCP traffic on port 443 to be redirected to our SSL vServer for Brokering
To achieve this we will need 2 Content Switches one on TCP port 443 and one on UDP port 3391 both on the same IP Address
Fortunately the NetScaler Unified Gateway is running so that takes care of the TCP 443 Content Switch so all we need to create is a new UDP Content Switch and set the default vServer to be our UDP 3391 Load Balanced vServer. This means all UDP traffic inbound to our firewall will hit this Content Switch and therefore (as no policies are defined) be passed onto our default vServer
So that takes care of the inbound UDP Traffic, what about the TCP 443 traffic.
To deal with this we can create 2 new Content Switching policies and actions to deal with remote and enroll and redirect them to their respective vServers.
Create 2 new Content Switching actions and set them to direct traffic to the relevant vServers (remote or enroll)
Next create 2 new Content Switching Policies and bind them to the relevant action. Be sure to set the expression to equal the external dns name that you will be entering into the browser or that you have changed the brokering services in RDS to (again – see Claudio’s book for this)
The Final Step is to bind this to your Unified Gateway Content Switch running on port 443
At this point assuming your certificates are good you should be ready to test.
so, first i am going to ping my Unified Gateway and RDS gateway to show they are on the same IP Address
Now lets log into Unified Gateway to make sure it all still works OK
and finally lets log into our RDS gateway
Click on Command Prompt to run
Done, As you can see its running from my RDS Session Host in Azure on the 10.0.2.0/24 subnet (internal is 192.168.0.0/24) and I can ping internal resources on my network at home.
Hopefully this helps some of you out that have asked me about this.
Once again I would like to thank Claudio for giving me the opportunity to really get under the hood with RDS and how it works. If you want to understand RDS on 2012 R2 and really get to grips with how it all works then you should but his book when he releases it, I know I will be!