Configure RDP Proxy in NetScaler


The RDP Proxy functionality is provided as part of the Citrix Gateway and currently is available to all NetScaler Enterprise and Platinum customers.

The following RDP Proxy features provide access to a remote desktop farm or an RDSH session host server through Citrix Gateway:

  • Secure RDP traffic through CVPN or ICAProxy mode (without Full Tunnel).
  • Single sign-on (SSO) to RDP servers through Citrix Gateway. Also provides an option to disable SSO if needed).
  • Enforcement (SmartAccess) feature, where Citrix ADC administrators can disable certain RDP capabilities through Citrix Gateway configuration.
  • Single/Stateless(Dual)  Gateway solution for all needs (VPN/ICA/RDP/Citrix Endpoint Management).
  • Compatibility with native Windows MSTSC client for RDP without the need for any custom clients.
  • Use of existing Microsoft-provided RDP client on MACOSX, iOS, and Android.

Firewall Ports

RDP proxy requires port 3389 to be opened from the internet. You could also choose to use other port numbers if you don’t want to use the 3389 port. In a nutshell, just opening 443 port isn’t enough to get this to work.

Initial Configuration

Now to get started, we will need to enable RDP proxy feature if it isn’t turned ON. For that, navigate to SystemSettingsConfigure Advanced Features and ensure that RDP proxy is turned ON. if not, tick the box to Turn ON RDP proxy feature. You will need NetScaler Enterprise and above for this feature to work.

Create LDAP Profile and Policy

Create an LDAP profile for authentication. Navigate to NetScaler Gateway – Policies – Authentication – LDAP

Click on the Servers tab and click Add. Enter the required details such as AD server IP address, port details and a service account. For those who haven’t done this before, here is a helpful link from Citrix. It’s dead easy to set this up. https://docs.citrix.com/en-us/citrix-gateway/12-1/authentication-authorization/configure-ldap/ng-ldap-authen-configure-tsk.html If you have any questions, just pop it in the comments window and I will respond when I see them.

Now create the LDAP policy. Click on the Policies tab, click Add. Enter the entries as shown in the picture below. Ensure that the correct LDAP profile is selected.

Create the RDP Client Profile

Navigate to NetScaler Gateway – Policies – RDP Profiles and Connections – Client Profiles

Click Add

Give it a name such as RDProxy_Profile and leave the rest of the values default if you would like. I changed the RDP Cookie Validity from 60 sec to 120 seconds

Click OK

Create an RDP Server Profile

Create an RDP Server Profile. Click on the first tab that says Server Profile

Click Add and enter a name for the server profile. Enter the IP address (this is the IP address of the RDP Proxy Virtual Server that you will configure under the NetScaler Gateway). Enter the port number – You can choose to go with the default RDP port if you wish to or choose another one

Click OK

Create a Session Profile

Now, go to NetScaler Gateway – Policies – Session – Session Profiles. Click Add

Give the profile a Name

No changes under the Network Configuration tab. Leave everything as default there

Under Client Experience tab, change Clientless Access to ON and tick Single Sign-on to Web Applications and Credential Index to Primary. the last setting is turning ON Single Sign-on with Windows

Under the Security Tab, select Default Authorization to ALLOW and Secure Browse to ENABLED

Under Published Applications, set ICA PROXY to OFF

Under the Remote Desktop tab, pick the RDP Client profile that was created in the previous step

Click Create

Create a Session Policy

Now create a Session Policy that will be bound to the NetScaler Virtual Server. Remember that we haven’t created the virtual server yet.

Switch to Session Policies tab and click Add. Give the session policy a Name and pick the session profile that we just created in the previous step.

Create a Bookmark

Now create a Bookmark and this is what will appear to the users in the form of an application icon to click on.

Give a Name to the bookmark and enter the name of the string that you want to be displayed in the portal. Enter the Bookmark link in the format rdp://IPaddressOfTheBackendRDSServer

Click Create

Create the Gateway Virtual Server

Let’s create the Gateway Virtual server next. Navigate to NetScaler Gateway node, expand that and under Virtual Servers, click Add

Under Basic Settings, configure the below items

  • Name – RDPProxy_rdpproxy.fqdn.co.nz
  • IP Address type – IP Address
  • IP Address – X.X.X.X
  • Port – 443
  • Pick the RDP Server Profile – RDP Server Profile
  • Ensure that Enable Authentication, AppFlow Logging and State is turned ON
  • Disable ICA Only

Click OK

Attach a Server Certificate. The certificate can be a wild card cert or you could choose to get a named certificate that matches the external RDP proxy FQDN

Now bind the Primary authentication policy. We are going to use LDAP and hence I will use LDAP policy that we created in the steps above.

Under SSL Parameters, ensure that only TLS1.2 is turned ON for enhancing the security of client connections.

You can choose to go with the default SSL ciphers or modify the ciphers according to the company requirements.

Under Portal theme, I went with RfWebUI which I think is one of the cleanest UIs. You could choose to create a custom one and use that instead.

Under Published Applications, choose the URL Name and select RDP Link (this is the bookmark link that was created)

Under Policies, attach the Session Policy named RDP Session Policy

Click Create

Testing the Setup

Selecting the RfWebUI gives the below logon page and users could simply use their domain user name and password to log in. They don’t need to enter the domain name.

Upon login, you will be shown the Favorites page where you could add links for quick access. This is very similar to the subscriptions in Storefront.

Click on the Desktops tab and you will be able to see all the published Bookmarks there. I have one in there, you can choose to have any number of bookmarks.

Click on the RDP link to launch the application. It will first download the app.rdp file which could be used to launch the application. You will just need to give the users access to the servers locally by adding them to the Remote Desktop Users group or you could choose to do this via AD domain groups to manage it centrally.

Advertisements

How to verify that NetScaler COOKIEINSERT persistent sessions are working?


Ever had issues with your Storefront load balancing setup not working after painstakingly setting up NetScaler load balancing?

Now, let’s discuss a few reasons why cookie based persistence are better (in some scenarios) compared to Source-IP based persistence.

In some circumstances, using persistence based on source IP address can overload your servers. All requests to a single Web site or application are routed through the single gateway to the NetScaler appliance, even though they are then redirected to multiple locations. In multiple proxy environments, client requests frequently have different source IP addresses even when they are sent from the same client, resulting in rapid multiplication of persistence sessions where a single session should be created. This issue is called the “Mega Proxy problem.” You can use HTTP cookie-based persistence instead of Source IP-based persistence to prevent this from happening.

If all incoming traffic comes from behind a Network Address Translation (NAT) device or proxy, the traffic appears to the NetScaler appliance to come from a single source IP address. This prevents Source IP persistence from functioning properly. Where this is the case, you must select a different persistence type.

HTTP Cookie Persistence

When HTTP cookie persistence is configured, the NetScaler appliance sets a cookie in the HTTP headers of the initial client request. The cookie contains the IP address and port of the service selected by the load balancing algorithm. As with any HTTP connection, the client then includes that cookie with any subsequent requests.

When the NetScaler appliance detects the cookie, it forwards the request to the service IP and port in the cookie, maintaining persistence for the connection. You can use this type of persistence with virtual servers of type HTTP or HTTPS. This persistence type does not consume any appliance resources and therefore can accommodate an unlimited number of persistent clients.

Note: If the client’s Web browser is configured to refuse cookies, HTTP cookie-based persistence will not work. It might be advisable to configure a cookie check on the Web site, and warn clients that do not appear to be storing cookies properly that they will need to enable cookies for the Web site if they want to use it.

By default, the NetScaler appliance sets HTTP version 0 cookies for maximum compatibility with client browsers. (Only certain HTTP proxies understand version 1 cookies; most commonly used browsers do not.) You can configure the appliance to set HTTP version 1 cookies, for compliance with RFC2109. For HTTP version 0 cookies, the appliance inserts the cookie expiration date and time as an absolute Coordinated Universal Time (GMT). It calculates this value as the sum of the current GMT time on the appliance and the time-out value. For HTTP version 1 cookies, the appliance inserts a relative expiration time by setting the “Max-Age” attribute of the HTTP cookie. In this case, the client’s browser calculates the actual expiration time.

So some of the benefits of using cookie based persistence are

  • Easy to configure
  • Load balancer does all the work without involving the back end services (mostly a web server)
  • No connection table to maintain
  • Activity based – Time out is based on idle connection and not the total connection time
  • caters to most of the load balancing scenarios
  • if proxies are involved in the setup where source IPs are masked, this makes it an easy choice

Cons of Cookie based persistence

  • can throw off the load balancing where timeouts are set to 0 or when time outs are long lived
  • when Type 0 cookie is used, time of the cookie value is absolute(GMT time). When type 1 is used, relative time is used (local time)
  • hard to troubleshoot

Testing COOKIEINSERT persistence

Use Putty or some other SSH clients to login to the NetScaler.

sh lb vserver vservername

If you take a closer look at the snippet above, the letters in yellow shows that COOKIEINSERT persistence is turned ON with a time out value of 0 mins. This means that the cookies doesn’t have an expiry time set by the NetScaler appliance. The backup persistence is set to SourceIP with a time out value of 60mins. You can also see the cookie values at the bottom of the results staring with NSC_xxxxxxx

You will now need to get into Shell with an account that has permissions. To get to shell, type shell and hit enter

Now type the following

nsconmsg -i vservername -s ConLb=1 -d oldconmsg

In the snippet above, the highlighted text in yellow shows that persistence is set to Cookieinsert and the number of hits for each service. You will also get values such as response times, CPU and memory utilization.

VIP value shows the total number of hits to the vServer hits
Each service has a line starting with S (IP Address) and its status.
Hits (x, x/sec) shows the initial (method) hits to the service for a new connection.
P (x, x/sec) shows hits to the service that are served using a persistence cookie

Also, check the current persistent session via the commands below

sh persistentsessions
sh persistentsessions -summary

Storefront Load balancing using NetScaler


It’s been a while since I wrote on my blog so let’s get straight into the post without much mucking around. This time we will discuss how to go about setting up Storefront load balancing using NetScalers. This can be configured on a standalone NetScaler or a NetScaler pair in HA. The recommendation is obviously to get this setup on a HA NetScaler pair so that NetScaler outage wouldn’t result in Storefront also being unavailable.

My Storefront version is 3.11 and have a cluster with 2 Storefront servers. NetScaler version is 11.1 but the NS version shouldn’t matter much as the steps would be more or less the same for other NetScaler firmware versions – newer or older. (unless you are too far behind)

Pre-Requisites

To configure Storefront load balancing we need the following –

  • 2 or more Storefront servers
  • an IP address for the virtual server that hosts the LB configuration
  • SSL certificate that points to the intended load balanced URL of Storefront – the certificate can be a wild card or a named certificate

First Things First

Logon to your NetScaler and navigate to System — Settings — Configure Basic Features. Ensure that Load Balancing is selected, if not select it and click OK

1

NetScaler Configuration

Create Servers

Now, navigate to Traffic Management — Load Balancing — Servers. Click Add

2

Give the Storefront server a name and enter the IP address of the server. Ensure that “Enable after creating” is selected. Click Create

Add the second Storefront server following the above steps. If you have more than 2  servers, add all of them.

3

Create Monitors

New NetScaler version come with a built-in Storefront monitor so we are going to make use of it here. Go to Traffic Management –Load Balancing — Monitors and click Add

Here I am only going to create a single monitor to probe all my Storefront servers. You can choose to create multiple monitors depending upon the number of Storefront servers that you have. In my case, i will create just one.

Give a name to the monitor and select the type as STOREFRONT

5

Now select Special Parameters tab and provide the name of the Store that you have created in Storefront. Check the 2 entries – Storefront Account Service and Check Back End Services. 

4

Click on the Standard Parameters tab. Ensure that Secure is selected as below. Click Create

6

Create Service Groups

Go to Traffic Management –Load Balancing — Service Groups

Give a name to the service group and select the protocol as SSL. Check the entries below

  • State
  • Health Monitoring
  • AppFlow Logging (only if you have NetScaler MAS in your environment)

Click OK

7

Under Service Group Members, add the server entities that we created earlier. Once done, they will look like the below

8

Under Settings, type the Header as X-Forwarded-For

9

Under Monitors, bind the monitor that we created before

10

Under SSL Parameters, setup the settings as below

11

Under Ciphers, setup the ciphers based on your company security policy.

12

Once done, Service Group for Storefront should look like this

13

Now, it’s time to create the Virtual Server

Virtual Server

As mentioned in the pre-requisites section , we need an IP address for this. If the NetScalers are sitting in the DMZ, a DMZ IP address is required. In my case, NetScalers are hosted internally so i will use an internal unused IP address.

We will also need the SSL certificate here.

Go to Traffic Management –Load Balancing — Virtual Servers

Click Add

Give a Name to the virtual server and select the protocol as SSL

Specify the IP address under IP Address field and specify the port # as 443

14

Click More and specify the settings as below (note, that AppFlow logging only needs to be enabled if you have a NetScaler MAS setup or other monitoring solutions that could make use of AppFlow logs)

15

 

Under Services and Service Groups, click on Load Balancing Virtual Server ServiceGroup Binding

Click Add Binding and select the Service Group that you created in the previous step. Click OK

Once completed, the page should look like the below. Click Close and click Done

16

It’s time to attach the certificate. Go to Traffic Management — SSL — Manage Certificates / Keys / CSRs

17

 

Click on Upload button and upload your certificate file to NetScaler

Go to Traffic Management — SSL — Certificates — Server certificates

Under Certificate, click on Server Certificate and then Install

Give a certificate key-pair name and choose the certificate that was just uploaded in the previous step. Click Install

Now, go back to Traffic Management –Load Balancing — Virtual Servers

Select the Virtual server created for Storefront and click Edit. Under Certificates, select Server Certificate and then Click Add Binding

Under SSL Ciphers, select the ciphers that you would like to be in place. I am going with the default one. This is not the most secure for a production setup so go with something that’s secure enough for your organization.

Under SSL Parameters, configure the settings as below. Click OK

18

Under Method, Select LEASTRESPONSETIME for the Load Balancing Method. Configure a Backup LB Method, I choose LEAST CONNECTION

You can read more about the LB Methods here

19

Click OK

Under Persistence, select COOKIEINSERT for Persistence with a time-out value of 0. You can also read why I selected the timeout value of 0 here

Under Backup persistence, select SOURCEIP with a timeout of 60. Fill in the Netmask as in the picture

20

Click OK and then Done

We have now completed almost 90% of the config. There are a couple of things left so hold on tight.

The configuration so far will ensure that load balancing will be performed between the Storefront servers ( I know, i know I haven’t setup the DNS entries for the load balanced VIP)

If someone type in the http URL of LB Storefront in their browser, it will not go anywhere. It will show them the IIS page instead. So how do we ensure that the users are redirected to the correct Storefront page (https version) every single time? We will setup another virtual server on port 80 with a redirect URL configured.

Let’s do that now.

Under Traffic Management –Load Balancing — Virtual Servers, Click Add

Under Basic Settings, give the virtual server a Name and select protocol as HTTP

Specify the same IP address as for the Storefront LB VIP and provide 80 for the Port #

Click OK/Create

Under Persistence, select SOURCEIP with a timeout of 2 mins

21

Click OK

Under Protection, type in the correct HTTPS URL that you would want the users to be redirected to under Redirect URL field

22

Click OK. Then click Done

You will notice that the virtual server will be marked as down

23

DNS Changes

Now head over to the DNS server and open the DNS Console

Create an A record pointing to the Storefront LB name with the IP address configured on the vServer for LB configuration.

Storefront Changes

This is the last step, I promise. Head over to the Storefront servers and it’s time now to run some Powershell commands

Now, the monitors that we created earlier will be marked as Down if we didn’t perform this step prior to creating them on the NetScaler. That’s because the monitor created was based on HTTPS and by default, Storefront monitoring is done on HTTP

To change this to HTTPS. We need to configure the monitor service to use HTTPS instead. On all the StoreFront 3.0 servers perform the following steps.

Run PowerShell as an administrator.

Navigate to the Scripts (C:\Program Files\Citrix\Receiver StoreFront\Scripts) folder via the Powershell on the Storefront server,

Run ImportModules.ps1

24

Run the below command

 Get-DSServiceMonitorFeature

25

Now, type the below to setup the Storefront Monitor on HTTPS

Set-DSServiceMonitorFeature -ServiceURL https://localhost:443/StoreFrontMonitor

 

Repeat the above steps on all the Storefront servers.

Now, head back to the NetScaler and you can see that the monitor will be in GREEN and showing a status of UP

That’s all we need to do to setup Storefront load balancing using NetScalers.

 

 

 

 

Check the realtime performance/statistics of a NetScaler vServer


There are many a time you would want to look at the vServer performance due to many reasons – you are just too curious to see all the numbers, you have an issue with excessive resource utilization due to a particular vServer or you are seeing unusual amount of hits in Netscaler Insight Center graphs.

There are a couple of ways you could check it – via the NetScaler GUI and via the command line.

Via the GUI, its quite simple as all you need to do is to select the vServer and click on Statistics button to see the performance counters. the result will be as follows

vserver-counters1

Via the NetScaler GUI

Via the command line , it’s a bit more powerful as it gives the overall resource usage of the NetScaler appliance as well on top of all sorts of info at regular intervals. Here is what you need to do to check the realtime stats of a vServer

>shell
#nsconmsg -i vServername -s ConLb=2 -d oldconmsg

via-putty

via Putty / Command Line

 

The curious case of NetScaler access with error message ” The Connection to “Desktop” failed with status (Unknown client error 1110)”


I was pulled into to look at a problem for one of our customers with their Netscalers which stopped the user connections intermittently throwing a very “helpful” error message ” the connection to the desktop failed with status (unknown client error 1110).

The customer description was “it only started to happen a few weeks ago and these days it’s quite impossible to land a successful connection from the outside of our corporate network.”

I managed to get a couple of screenshots of error messages from the users and they appeared like below. When queried, the internal access via Storefront is working fine.

image001

Looking at the error message, there are a multitude of reasons why you would get that, and I am outlining the common areas to check in such cases.

  • Check if the Root certificates and intermediate certificates are available on the client devices. If frequently patched, the client will most probably have the latest and update Root CA’s from various public CAs. Check the IE’s / Other browsers’ certificate store to verify the Root and Intermediate CA SSL certs
  • If using non-IE browsers for connectivity, switch over to IE to see if it connects. IE is the safest bet when it comes to connectivity to Citrix environments.
  • Check for SSL ciphers attached to the NetScaler Gateway vServer. If high security ciphers are used, this issue may occur. Relax the cipher suites to see if that makes a difference. Again, if cipher suites are an issue, the problem will occur every single time when you connect and not sporadically.
  • Check the STAs on the NetScaler and ensure that it matches with the STAs configured on the  WI/Storefront. This is one of the most critical setting to check and probably the first one to check if the issue occurs only sporadically. There is a high possibility of an STA mismatch as it turned out to be in my case.
  • Check the FW from the NetScaler to the VDA – As the title says ensure that the Citrix ports to the VDA are open from the Netscaler