NetScaler eBook and work in progress and new project!

After being overwhelmed with requests (600+) and feedback (40+) on my previous project on NetScaler optimizing and tuning, both from guys in the community and Citrix themselves. I have decided to go ahead with the new project, which is basically creating a new “ebook” which focuses this time on the most requested feature… NetScaler gateway.

I have decided to split the new project into different segments of the book.

  • NetScaler Gateway
    • RDP Proxy
    • ICA Proxy
      • Best-pratices
      • Multi-domain scenarioes (single domain, multiple domains within same forest, multiple domains with trust, multiple domains no trust)
      • Deployment types (2 arm, 1 arm, double hop)
      • Optimal Gateway
      • Framehawk
      • Audio over DTLS
      • SSL VPN
      • Traffic profiles
      • Portal Customization
    • Bookmarks
    • Endpoint analysis and VPN
      • Pre-auth
      • OPSWAT
      • Smart Access
    • Unified Gateway
    • AAA
      • MFA
      • Kerberos auth
    • Troubleshooting
      • Policies
      • Connection
    • Security
      • SSL/TLS settings
      • PCI-DSS
    • AppFlow
      • HDX Insight

If there is anything that I have missed please leave me some feedback, and of course help is always appreciated, my goal is to start each part with an overview of the feature, what each option does and then create a to-do guide to configure each feature. For instance

AppFlow generates…..yada…yada, best-pratices include…yada…yada…yada

Then the to-do guide will go something like this.

To setup AppFlow go into System –> AppFlow… do step 1, 2 and 3.

Agree/Disagree?

My plan was also to integrate XenMobile and ShareFile components to the mix, but I will require assistance from someone else since those products are not my strong side.

Oh and based upon the feedback I have gathered so far on the first eBook, there will be an update to it as well, containing typoes, enchanced sections and some new stuff.

#netscaler-ebook, #netscaler-gateway, #tcp

Multitenant guide setup for Storefront and Netscaler with ICA-proxy

This is something I have been working on for quite some time… Fact it has been quite a pain in the ass to setup, but I think I finally managed to solve it properly. If anyone sees any issues or something that I haven’t adressed, please leave me a comment either below in the post or on twitter @msandbu
  One of the issues with trying to setup Netscaler and Storefront in a multi-tenant are in some cases the:

  • Amount of authentication policies needed to hit all the specific domains in a multi-tenant enviroment
  • Theme customization, this is by default set at a vServer level, which means that we need a vServer pr customer if we want customization
  • We could solve this with multiple Gateway vServers, but with Multiple vServers also means that we need many IP-addresses, which we might not have.
  • Multiple customer domains

Now it is possible to bypass Netscaler authentication, and setup the Gateway vServer just act as a ICA-proxy, so authentication happens at the Storefront but this setup does not work for Receiver. Since in a Netscaler Gateway setup, the Receiver needs to authenticate against the Gateway first.

NOTE: This might not be a supported configuration from Citrix, but it works and it requires a regular Netscaler for it to function (Not Gateway VPX)

So from an overview, how does it work?

  • We publish Storefront as a LB vServers behind the Netscaler (Meaning that Storefront is accessable from the external network)
  • We configure an Gateway vServer, which will handle the ICA traffic.
  • We use Responder, Rewrite policies to handle the redirect to the correct URLs.
  • We configure Optimal Gateway Routing with direct access on Storefront (Which basically means that all ICA traffic regardless of beacons will be redirected using a Gateway. This feature is not new, but with Storefront 3.1 tech preview this is available in the GUI. We also define that Gateways are being used for HDX routing only, all other auth will happen on Storefront.
  • We have one or multiple Storefront stores depending on the requirements for backend setup for instance if we have multiple isolated active directory, and we have defined password verification against DDCs instead of Active directory. This might vary from deployment to deployment but important to remember what are Store specific settings and what are Receiver for web specific settings.
  • We can have multiple Gateway vServers to handle communication, but customers still need one URL for storefront setup.

So if we look at the screenshot below, this is a test deployment I did. So when a user starts receiver for the first time and tries to configure his Receiver it will be communicating directly with the Storefront endpoint and configures properly. Depending on what kind of Store the user is accessing this might be done using DDC validation or using Active Directory. Same goes if using Receiver for web, the user connects and my typing his customer name is redirected to the customer website on Storefront. When the user tries to start an application or desktop session, the session will generate an ICA file contaning the Optimal Gateway setting (Which means that even thou in theory it is labeled as inside because of setup) the session will be routed using the Gateway.

image

So how to set this up?

  • First setup a load balanced vServer containing the Storefront servers, using HTTPS/443
  • Now I can’t address all configurations on the Storefront with stores and such so I gonna setup a generic Storefront setup where we have the Storefront in a untrusted domain using XML based auth against the DDC, and one simple store and where we have two customer URLs (kunde2.msandbu.org and kunde1.msandbu.org)

First of the base URL should not contain any customer specific reference so in case it should be just an indicator of the service, this is not something the enduser will see unless he for instance opens the receiver configuraiton file.

In my case its just sf.msandbu.org (Setup a wildcard cert on the Storefront server or we can use a SAN or SNI based cert) in my case I have a wildcard cert for the domain msandbu.org

image

Create a Storefront Store with internal access only, leave everything at default as of now. Create the Receiver for web sites needed for the end customers.

image
NOTE: I did some changes on the different websites to show how this works from the end-user experience

Note: We can alter what we want for each website, portal customization can be done under the c:\inetpub\wwwroot\citrix\(nameofwebsite) or using the Storefront GUI.

Next we define the Gateway that this store is going to use, this can be done by going into the Store settings –> Optimal HDX Routing

image

Specify HDX routing usage only and add the external FQDN of the Gateway. (And no the Storefront does not need to be able to communicate with the Gateway, since Auth is done completely at Storefront. After you have added the gateway, click for Direct Access and define which controllers should be used against the optimal gateway

image

So after this is setup, we need to add rewrite rules and URL transformation for each customer to their website on the Storefront.

Rewrite rules: these are pretty simple just replaces a URL prefix at the end

image

Then I have an expression that looks at the host name and specificies that the URL must be at the root to it continue

image

These policies needs to be added to the Storefront LB vServer. Next we also need to have URL transformation policies to define HTTP to HTTPS rules.

Simplest is to add a Netscaler URL transformation profile and add the different URLs

image

when creating the URL Transformation Profile, the simplest way is to use the HTTP.REQ.IS_VALID expression, since this policy is only being applied once to a storefront vServer, before the end users are being redirected to the HTTPS version

image

Setup a HTTP vServer Storefront on the same VIP as the SSL based vServer and add the transformation policy. This means that when a user logs inn to http://kunde2.msandbu.org (The HTTP vServer will respond and redirect the user to https://kunde2.msandbu.org and the rewrite will add the /Citrix/Website URL at the end.

After this is setup we can verify that Reciever for web is working

image

image

NOTE: (ill come back with how to make the URL much more pretty… )

Now that we can verify that this works we need to configure the Gateway which we described earlier. Go into Netscaler Gateway and setup a new vServer with a VIP which responds on the FQDN that we used in Storefront.

Now you need to define a ICA only vServer, with SSL certificate and STA server. No need for session policies. Now when we log into Storefront and try to start an ICA session we can see the following:

Address=;40;STA194872468;4618030C362634F074FC6FA386D7F7
AutologonAllowed=ON
BrowserProtocol=HTTPonTCP
CGPSecurityTicket=On
ClearPassword=A5C03D7BC85B05
ClientAudio=On
ConnectionBar=1
DesiredColor=8
DesiredHRES=4294967295
DesiredVRES=4294967295
DesktopRestartAllowed=1
Domain=\5487D51A0B09AEFE
DoNotUseDefaultCSL=On
FontSmoothingType=0
HTTPBrowserAddress=!
InitialProgram=#TS $S1-1
Launcher=WI
LaunchReference=33A65B1F22B5DD32998EC4B2DA9873
LocHttpBrowserAddress=!
LogonTicket=A5C03D7BC85B055487D51A0B09AEFE
LogonTicketType=CTXS1
LongCommandLine=
LPWD=43
NRWD=29
ProxyTimeout=30000
ProxyType=Auto
SecureChannelProtocol=Detect
SessionsharingKey=-gB14qmFkIrLKytSTzv+iLNLNGdG
SFRAllowed=Off
SSLCiphers=all
SSLEnable=On
SSLProxyHost=gw.msandbu.org:443

So we can see that the ICA files indicates that we are going using the Netscaler Gateway. Problem solved!

So what are we losing in this setup?

  • All auth happens on Storefront, so if we need to have two-factor that has to be integrated with Storefront directly.
  • We are using Netscaler Gateway only for routing purposes, which means that VPN goes away.

#multitenant, #netscaler-gateway, #storefront

Enabling Citrix Receiver audio over Netscaler Gateway with DTLS

Something caught my eye earlier today that I wasn’t aware of. With Citrix Reciever 4.2, Citrix introduced support for Audio over UDP with Netscaler Gateway. Now this is huge since ICA proxy has always been TCP but now it adds support for Audio over UDP which gives it a much better performance since it does’nt have the required overhead that TCP does.

So checking out Citrix edocs I didn’nt find much info. All I noticed was the information in the release notes of Citrix Receiver. Then out of the blue comes this blogpost –> http://discussions.citrix.com/topic/361759-udp-audio-through-netscaler-with-dtls/

Which basically states in order to setup audio over Netscaler Gateway using UDP (DTLS) we need to define Citirx Receiver Policies

image

Then we need to enable DTLS on the Netscaler Gateway (Which now is supported on the e-builds)

image

Then we are all set. You can use the HDX monitor insider a ICA-session to see that audio over UDP is enabled.

#netscaler-gateway

Netscaler Gateway and content switching

today is the day! Citrix annonced earlier today a new enhacement release for Netscaler Gateway which allows us to use Netscaler Gateway together with Content Switching.

This means that we can have a Gateway vServer together with content switching policy. So when we create a Netscaler gateway together with content switching we need to define content switching policies. For instance if we have the vServer gateway 10.0.0.1 and we have two content switching policies for the URLS /zm/ and /xm/ will point to a load balanced vServer. Others urls which are not being catched by a content switching policy will be redirected to the Gateway vServer.

So the content switching rules are checked first, before it goes on with session policies for the gateway vServer.

Now another thing that is cool with this release is that it supports SSO to RD solutions.

So this is the new screen when we create a new vServer.

image

We have the RDP info setup directly here. And we can also define CS policy bindings. So I can add a new content switching policy and add it to the vServer

image

And as I mentioned these rules will be evaluated before session policies.

But note that this is an enhacement build, and should/can be used for testing you can read more about the e versions here –> http://blogs.citrix.com/2013/03/29/citrix-access-gateway-demystifying-the-e-releases/

You can download the new build from citrix downloads here —> https://www.citrix.com/downloads/netscaler-adc/virtual-appliances/netscaler-vpx-release-105e.html

#content-switching, #netscaler-gateway

Netscaler TCP profile nstcp_default_xa_xd_profile

Netscaler has the ability to use something called TCP profiles, which allows “non-TCP” experts to customize the Netscaler based upon what application is being used or what kind of network is be used or devices that are accessing the service.

Now this might be the easiest performance tuning feature on the Netscaler.

The different profiles can be viewed under System –> Profiles –> TCP Profiles

image

Now by default when you create a service or virtual server it will automatically bind itself to the nstcp_default_profile so let’s take a look at it.

image

If we for instance setup a Netscaler Gateway solution for ICA access, we should use the nstcp_default_XA_XD_profile. Why you say? let’s take a look at it and compare the difference.

image

Not so much differences here. except a couple of things.

* Window Scaling
* Nagle’s algorithm
* Selective Ack (SACK)
* Maximum Packets per MSS
* Maximum Packts per Retransmission

Now all the differences here are within a key area. ICA is a “chatty” procotol, which might send out a lot of small packets. nstcp_xa_xd profile allows the Netscaler to send more packets inside a TCP segment. Window scaling and Selective Acknowledgement are also enabled for this profile for better experience over long pipes. Nagle’s algorithm increases the efficiency of a network application system by decreasing the number of packets that must be sent.

By choosing this profile for a NS gateway you gain a lower ICA RTT and less latency since packets will flow faster. And note you can attach a profile to a vServer by going into Advanced –> Profiles –> TCP profiles

#imagenya, #netscaler-gateway, #profiles

Tranferring ICA Proxy Sessions Between Devices

Short post!
So this is a new feature which popped up in the previous enhancement builds to Netscaler Gateway Enhancement Build 123.1100.e
It it also available in Netscaler VPX since it is the same build and everything.

The feature is ICA Proxy Session Migration which allow us to migrate sessions between users. For instance if a user has an active ICA connection from his computer and forgets to log out and then starts a new connection from his home laptop or iPad, Netscaler would then migrate the existing ICA session to that user.

This feature can be found under Netscaler Gateway vServer

image

So this only works if the vServer is set to basic mode, and will not function if the vServer is set in SmartAccess mode (even thou you do not get any error message if you do the switch.
You can of course do this switch in the CLI as well.

set vpn vserver x.x.x.x -icaProxySessionMigration ON

I can also mention that the 10.5 Netscaler beta is available from citrix to download http://bit.ly/1hTQxPV (This requires special access since this in a locked beta at the moment.

#ica-proxy, #netscaler-gateway

Allow users to choose between Access Gateway and XenApp connection

I some cases you want users to have the option to choose between a regular VPN connection when connecting to your solution or they just want to access their applications and desktops using receiver, of course you can create multiple session policies for users or based on something else but there is also another option which displayes the different options in the web GUI.

If you have a Netscaler Gateway vServer setup with a session policy we can do a change here, open the session policy and go into “request policy” and choose modify –>

NOTE: This requires Smart Access Mode and Smart Access requires the use of Universal licenses
image

Under Client Experience choose Advanced –>

image

Here you have a setting called “Client Choices”

image

When users now login they will be presented with this screen
Which allows them to choose between Network Access, XenApp or Clientless Access.
If I disallowed Clientless Access here it would not appear on the menu.

ill come back in detail later on how to setup Access Gateway for users with plugin or java client.

image
NOTE: If Netscaler is unable to communicate with the Storefront or WebInterface the XenApp choice will not appear.

And there are three options regarding clientless access.

  • On. Enables clientless access. If client choices are disabled and the Web Interface is not configured or disabled, users log on using clientless access.
  • Allow. Clientless access is not enabled by default. If client choices are disabled, and the Web Interface is not configured or disabled, users log on using the Access Gateway Plug-in. If endpoint analysis fails when users log on, users receive the choices page with clientless access available.
  • Off. Clientless access is turned off. When this setting is selected, users cannot log on using clientless access and the icon for clientless access does not appear on the choices page.

#access-gateway, #netscaler, #netscaler-gateway