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.

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

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.

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

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

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

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

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

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

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

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

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

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.

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

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

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.

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.

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

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

Under Client Experience choose Advanced –>

Here you have a setting called “Client Choices”

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.

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

Setup Netscaler for XenDesktop 7 and AppController 2.8

This is going to be a long one
Always wanted to document this myself but never had the time, so I figured why not knock two birds with one stone and blog it as well since many are probably wondering about the same thing.

This is a typical deployment for many right? You have your internal XA/XD which are tied to a StoreFront web server and for remote access you have Netscaler Gateway/AG

And depending on the setup you might have a Netscaler in DMZ behind a NAT firewall, or directly connected to the internet from the DMZ or you might have a double hop network where you have multiple DMZ sones and firewalls.

So how to tie them together ?
First I suggest you read my previous post regarding XenDesktop 7 with StoreFront and Appcontroller deployment.
https://msandbu.wordpress.com/2013/06/26/xendesktop-7-setup-and-appcontroller-setup/

Lets head over to our Netscaler deployment. We can start by cheching our network connection.

We have different types of networking within the NS, we have VIP( Virtual IP) which are typically tied to load balanced service. We have SNIP (Subnet IP) which are used to initiate a connection to the back-end servers (XenDesktop Servers, Storefront etc) and you have a NSIP (Netscaler IP which is used for management)

So for a user the connection will look like this.

User –> VIP –> SNIP –> XenDesktop (Servers)

Typical deployment is that you have a netscaler with two interfaces, one in to the DMZ and one into the backend servers. (In my case I have all interfaces connected to the same subnet.

Next we can add authentication.
Go into Netscaler Gateway –> Policies –> Authentication –> LDAP –> Add

For named expression I choose General and True and choose Add.
((What does this do ? specifies that IF the traffic is going trough the NS appliance then this policy should be applied)

Then give it a name and choose new server and enter the information to the AD server. After you have entered the info “Press Retrieve Attributes”
Remember that this command uses the IP address of the server you are using the browser on.

If you are having trouble with authentication fire up console to the Netscaler Appliance type in shell then cd /tmp then type the command cat aaad.debug
This will display in real time information regarding the authentication tries.

After that is done, add a DNS server.

Now lets add a certificate (for this purpose I have a Enterprise Root CA on Windows Server 2012 which I used to create a web server certificate which contained the host name of the access gateway) nsgw.msandbu.local in my case and I choose to export it as a PFX file including the private key (You will need the private key!!) In production you should use a third party CA to isse a certificate to you.

You can upload the PFX file under Traffic Management –> SSL –> Manage Certificates –> then you can upload the PFX.

After this is done open Netscaler console and extract the certificate and the key from the PFX.
This can be done by running openssl from the Netscaler Console

openssl.exe pkcs12 -in publicAndprivate.pfx -nocerts -out privateKey.pem (Extract keys)
openssl.exe pkcs12 -in publicAndprivate.pfx -clcerts -nokeys -out publicCert.pem (Extract Certs)

After that is done you can install the certificate

Next we create a virtual server under Netscaler Gateway and assosiate it with an IP-address.
Since we just want ICA-proxy and no VPN (Smart Access solution) we can choose Basic Mode.
Under Protocol choose SSL (After this is done the service will go down unless you have a valid ceritificate installed)

If you go into the Authentication Tab (mark the Enable Authentication)
and under Primary Authentication Policiess choose insert policy. (By default the one we created earlier will appear)

Now if you wish to have two-factor authentication you can add another Primary authentication policy.

After this is done head over to policies. We need to add a Session Policy, here as well we use ns_true as an expression. Give it a name and press create New Request Profile.

Here we enter the information about the backend storefront servers. (NOTE I already have one stored there this is because I have created this earlier

Now there are a couple of options here we need to define.
First under Published Applications.

1: We have to define ICA-proxy, this will tunnel ICA traffic via port 443 back to the user.
2: Web Interface address this has to be Storefront web address.
3: Single sign-on domain should be your local AD domain. (Don’t enter anything here in case you have multiple domains)

Next is under Client Experience –>
Define Single Sign-ON to web applications using Primary Credentials, this allows the Netscaler gateway to authenticate to the Storefront site.

We have to define at the NS should use SSO to the storefront web adress using the Primary authentication mechanism which is AD in my case.

Last but not least, Security so we can allow users to actually enter.

You should also enable TCP profile for this virtual server set to nstcp_default_xa_xd_profile (This profile works best for internal usage and high bandwidth networks)

Then we also have to add STA (Of the XD controllers in my case) Go back to Published Applications.

Click Add and enter the URL of the XD controller. After you save and refresh the page it will show up like mine did now.

Remember to save the config!
After that is done we have head over to Storefront

Now there are a couple of things we need to fix there. First we need to add an authentication option from Netscaler.

This will allow the Storefront to authenticate users coming from  Netscaler. (To pass the credentials forward)

Next we have to go to Stores –> Enable Remote Access –> Choose Add netscaler appliance –>

Here enter the info regarding your netscaler.
SNIP here is the one that you entered inn earlier on the Netscaler, StoreFront uses this to validate that any incoming connections comes from a trusted host.
The CallBack URL is the Internal IP-address of the Netscaler.

Then you setup it as a NO VPN Tunnel and choose the Gateway appliance to use.
You also have to add the STA’s here as well.

And last but not least, Beacons.
Beacons are used to identify if the end-user comes from an internal or external connection.
For instance you can put an external beacon for a public accessable website and internal for a website that is ONLY available for internal users.

This is what decides if the ICA-file the end-user receives is going to be used via ICA-proxy or a plain ICA-connection straight to the server.

In this case since it’s a demo enviroment all are on the same network. But I could remove the nsgw as an external beacon. And just have www.citrix.com and another external site.

Now since the AppController connected to the Storefront service we don’t need to anything else inorder to view Apps deployed from AppController.

NOTE: There is a couple of things if you are doing to deploy for instnace WorX apps from appcontroller and going to use mVPN solution to iOS and Andriod.

You will need to enable a couple of things here.
* Split-tunneling
* Clientless Access URL Encoding = Clear

You also need to enable Secure Browsing

After this is done, we can open up our virtual IP URL.
In my case it is https://nsgw.msandbu.local

Login with my username and password and start a desktop connection (For the purpose of this demonstration I have also added a weblink from AppController that points to yammer.com

If you open resource monitor you can see that traffic is tunneled in port 443

And if we open resource monitor on the desktop I just launched I can see that the servers speaks via the session reliability port to the SNIP ip (Which is 60.114)

#appcontroller, #netscaler, #netscaler-gateway, #storefront, #xendesktop, #xenmobile