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

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

Users unable to change passwords via Netscaler or Access Gateway when “User must change password at next logon” is checked


EnvironmentNetScaler 10.1, Citrix Storefront 2.5, XenDesktop 7.5, LDAP Authentication

Issue – AD user accounts with the attribute “User must change password at next logon” are unable to change their passwords at the NetScaler /Access gateway page. However, users do have the ability to change the passwords by selecting “change password” from the drop down menu on the Netscaler page

Resolution – The issue was the Active Directory /LDAP Authentication profile that I created which had the Security Type set to PlainText. Changing it to TLS resolved the issue for me.

Capture

How to Configure ICA Proxy for XenApp & XenDesktop for Citrix Receiver for iPhone, iPod, iPad – Deployment Guide


I came across this super informative document from Citrix detailing the setup of Citrix access on iPads and other iOS devices. The document has been written for the older version of Netscaler and XenDesktop versions but i would think there isnt much changes in terms of configuration so is worth a look.

Solution Requirements

  • Windows Desktops delivered to iPhone, iPod or iPad
  • Windows Applications delivered to iPhone, iPod, iPad
  • ICA Proxy for Citrix Receiver iPhone, iPod & iPad
  • ICA Proxy for XenApp & XenDesktop
  • ICA Proxy for NetScaler Access Gateway Enterprise Edition – AGEE

Prerequisites

  • Citrix NetScaler L4/7 Application Switch, version 9.1 build 101.5+ running Access Gateway (Quantity x 2 for High Availability)
  • Citrix XenApp Server 5.0+ or XenDesktop 4.0+
  • Microsoft Server with Active Directory
  • iPhone Configuration Utility
  • iPhone OS 3.0+, iPad OS
  • Citrix Receiver for iPhone v2.1+

The document can be downloaded  here citrix_agee_icaproxyxaxdreceiver.pdf