How-to: RD Gateway behind a NetScaler

Before jumping in on how to get this done, let’s take a step back and review what the problem is and why this makes sense.

The Issue

If you are cheap and like to run your labs (or parts of it) at home, that probably means you have a single IP address available and exposed to the outside world and either no way to get a second one or no money for it. Basically you are like me.

That poses a problem when you want to have in your lab everything you can throw at it and still make sure it is all accessible from the outside, over that single IP address. That may include things like a fully functional RDS environment (with RD Web Access, RD Gateway, etc), a XenApp/XenDesktop one and even VMware Horizon. Problem is as soon as one is up, you will have to point your firewall to the internal resource that is doing whatever role (i.e. RD Gateway) and now port 443 is gone. Sure you could then start doing other services on different ports but that creates a mess. Not only not everything allows you to use different ports but having to open several ports to the outside creates a problem. This is the problem in a nutshell.

The Solution

Well the solution is relatively simple and if I could do it (sure thing, with the help of Master of All NetScaler things and Citrix Technology Advocate, Dave Brett,, even a blind turtle can do it.

So what do you need? Here is your list:

  • NetScaler VPX. You can get the free version. It is limited bandwidth wise but hey, remember you are cheap and cheap people do not have more than 5Mbits down at home for sure. Also you will need a MyCitrix account.
  • One external IP address available (if you only have one, that is ok. After all this is the reason for this post).
  • Ports 443 and 3391 available (TCP 443, UDP 3391).
  • One Content Switch created on the NetScaler.
  • Policies and Actions that will tell the NetScaler where to send requests once it sees things like RD Web Access and RD Gateway traffic.
  • Couple internal IP addresses available.
  • The real FQDNs that people will use from the outside to reach whatever environment. For example, for the RD Web Access I normally use and for the RD Gateway, Also it does not matter if both roles are on the same server or not. I tested both cases and both work just fine and it is done the exact same way.
  • A wildcard certificate. Unless you want to spend more time managing certificates, I highly recommend you get a wildcard one. If you are really cheap, you can even issue your own certificates by setting up a CA on Windows Server (not part of this article). No matter what you decide to do, remember you need the certificate, Root CAs (if issuing your own certs), etc all on the NetScaler.

Doing it

Ok this is not a step-by-step post in any way. But will give you a very good idea/understanding on how to do it. If you have no idea what a NetScaler is, I highly recommend you take a look at my BriForum session ‘NetScaler for Dummies’. That will get you up and running and ready to create what you will need.

First thing you need, two Content Switch virtual servers (same IP is ok but on different ports). Mine are shown below:


This is where you will send your firewall to. Port 443 TCP and 3391 UDP will go to the internal IP address you used.

Next is to get three Load Balancing VIPs. One that will be the VIP to your backend RD Web Access servers (SSL) and the other two (same IP but two different ports) that will be the VIP to the RD Gateway servers. So basically in this example I am assuming you have two or more RD Web Access and two or more RD Gateways (for redundancy). You will end up  with something like this:

Load Balancing VIPs

Next you will need some Content Switch actions. This basically tells the NetScaler what to do when someone hits the Content Switch IP. Note that these are not the policies. The policies are the actual rules like ‘if anyone tries to reach, take action ACTION-WA.COMPANY.COM’. It seems odd to create actions first but once you understand the flow, you will see it makes a lot of sense.

So your actions will look like this (I have three, one to deal with the actual NetScaler Gateway – ICA Proxy, to my XenApp/XenDesktop environment and the other two, to deal with the RDS environment):

Content Switch Actions

If you open them you will see all they do is to send the connection to a VIP. The one for the XenApp/XenDesktop sends the connection to the NetScaler Gateway VIP. The other two, to the RD Gateway VIP you created above.

CS Action - ICA Proxy
CS Action – ICA Proxy
CS Action - RDWA
CS Action – RDWA
CS Action - RDGW
CS Action – RDGW

Next step is the policies. As I said, this is where the magic happens. Simple stuff as well. What you need is this:

Content Switch Policies
Content Switch Policies

Let’s take a look at the details of what is going on here: this policy checks if someone is trying to hit and if that is the case, it uses the that is tied (as seen above) to the NetScaler Gateway VIP. Basically it will send people to that VIP. this policy checks if someone is trying to hit the RD Web Access at and if that is the case, it uses the that is tied (as seen above) to the Load Balancing VIP for all your RD Web Access servers.

For the RD Gateway, things are a bit more complicated, due to what the RDP Client tries to do. That is why you need three policies. The idea is still the same. If the client attempts to reach anything that matches these three policies, they are sent to the Load Balancing VIP for all your RD Gateway servers.

The final step is to bind these policies to the Content Switch VIPs you created at the beginning. For the SSL traffic, as we need to check where the connection is going, we do need to bind these policies:

CS VIP SSL - Bindings
CS VIP SSL – Bindings

For the UDP one, there is no policy as all you want to do is to send all traffic to the Load Balancing VIP of the RD Gateway (UDP 3391):

CS VIP UDP - Bindings
CS VIP UDP – Bindings

That is it! Once you do this, you will be able to access your RDS environment from the outside through your RD Gateways, all load balanced. Not bad at all. And all this without losing the capability to reach your XenApp/XenDesktop through the same external IP address and port.

If you have any questions, just shout. As I said, this does work and works great.


9,456 total views, 2 views today