How-to: RD Gateway behind a NetScaler 11


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, http://bretty.me.uk), 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 wa.company.com and for the RD Gateway, gw.company.com. 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:

CS VIPs

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 wa.company.com, 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:

CS_POL_ns.iqbridge.ca: this policy checks if someone is trying to hit ns.iqbridge.ca and if that is the case, it uses the CS_ACT_ns.iqbridge.ca that is tied (as seen above) to the NetScaler Gateway VIP. Basically it will send people to that VIP.

CS_POL_wa.iqbridge.ca: this policy checks if someone is trying to hit the RD Web Access at wa.iqbridge.ca and if that is the case, it uses the CS_ACT_wa.iqbridge.ca 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.

CR

2,587 total views, 8 views today


Leave a comment

Your email address will not be published. Required fields are marked *

11 thoughts on “How-to: RD Gateway behind a NetScaler

  • Mathias Würsten

    is it possible to use netscaler as “RDP Proxy” and send users to rdweb after sucessfull authentication on AAA?

    it get a blank website:
    Error: Unable to display RD Web Access
    An unexpected error has occurred that is preventing this page from being displayed correctly.
    Viewing this page in Internet Explorer with the Enhanced Security Configuration enabled can cause such an error.

    a test-Website on the webserver and other websites (sharepoint) works fine, but RDWeb not working

    • Piotr Ostrowski

      as far as I am aware RDP proxy is not available within VPX, but you need to have a license. there is an excelent material on the YT how to configure the RDP Proxy on NS which seems to fulfill your needs.

      • crod Post author

        I think what he wants is to put the RDWeb page behind the NetScaler and authenticate at the NetScaler using AAA. That should work. Never tried though but would not mind doing it to see what happens.

        CR

  • Piotr Ostrowski

    Claudio,
    all what you have written here is clear, there is one missing point in my head at the moment…
    * I’m guessing that the external users reaches the RDWA which has inside it’s IIS parameters the TSDefaultGateway set as your LB DNS entry for the gateways, so it’s the RDGW which is wrapping the 3389 with SSL, and NS acts only as Content Switch with clever load balancer (health checks), right ?
    * I can imagine this is not covered in this scenario, but what in a situation if you like reach the point, where for your users inside the LAN you reach the RDWA and the traffic is not passing by the RDGW anymore, how to make this possible so external users and internal users in pure RDS 2012 deployment has call is seamless experience (I bare in mind the split horizon, GPO settings and all that stuff)
    + in short – external users always through RDGW and internal only through RDWA ?

    • Piotr Ostrowski

      once I wrote that, I’ve recollect that there is an option inside RDS to bypass the RDGW for the local addresses/connections.. seems this should do the trick..

      • crod Post author

        Exactly. That is how I do it. Internal users go to the internal DNS entry for the WA (same as the external by the way) but the setting for the deployment specifies not using the gateway for internal users. That works for me.

        CR

  • Daniel Gifford

    Hi there, great article BTW. Did you encounter problems with clients that have RDP v8.0 and 8.1? I currently have the same setup but clients with those RDP versions, cannot connect. It just gets stuck “Initiating remote connection”. I have searched for many hours but can’t find the reason. Would you happen to know? Thanks in advance!

  • jmpigeon

    hi, I try to do what you explane and that work until the publish application.
    When I try to start the application that tell me that remote desktop can not connect.
    I try nstrace to my netscaler a show quite a lot rst ack between my rdswa and subnet ip o my netscaler.
    do you have a idee.

    • crod Post author

      If you SSH to the NetScaler and telnet to the RDGW/RDWA/RDSHs, can you reach these with no issues on the correct ports? What about routing from these servers back to the NetScaler? Also the external name used for the RDGW/RDWA has to be available and pointing to the right external IP and then your firewall must NAT to the CS/Gateway.

      CR