JasonSamuel.com

I’ve covered Access Gateway quite a bit in the past and these two articles on my blog are a good primer for what I’m about to cover:

1. How to setup your Citrix Netscaler (Access Gateway) and Web Interface for iPads and mobile devices that use Citrix Receiver

2. Quick way to brand Access Gateway and Web Interface 5.4 with company logo and colors

Now let’s throw a new scenario into the mix. You want to allow users from another domain access to resources through your Access Gateway and Web Interface. Here is what you need to do to accomplish this.

SETTING UP A DROPDOWN BOX TO PASS THE DOMAIN
On your Access Gateway, if you followed my “branding guide” article above you will have noticed on the themes available from the Citrix blogs there are 2 versions, one normal and one with a dropdown. If you chose Horizon to customize like I did, make sure to download Horizon2.gz which has the code for the dropdown already in it. You just need to add your domains in the code. This is found in these two files:

\Horizon2\ns_gui\vpn\index.html

\Horizon2\ns_gui\vpn\tmindex.html

If you have your own theme and just want to add the code, Citrix has an excellent CTX article here covering it:

How to Add a Drop-down Menu with Domain Names on the Logon Page for Access Gateway Enterprise Edition:
http://support.citrix.com/article/CTX118657

What’s happening here is that a dropdown box is created with pre-populated domain names that you specify in your code. The user selects the proper domain when logging in and then this domain name is inserted into the header and passed to the Netscaler Access Gateway vserver where the authentication policy examines it. Based on the name the Netscaler sees in the header, it forwards the request on to the correct authentication server. This works great with LDAP authentication servers. I have not tested it with TACACS or RADIUS yet.

SETTING UP ACTIVE DIRECTORY LDAP AUTHENTICATION
Now it’s time to setup your Active Directory authentication for each of your domains.

1. Download LDAP Browser 4.5 for free here: http://www.ldapbrowser.com/download.htm

2. Go to your Netscaler under System > Authentication > Servers tab and create a new LDAP server. Use port 636 for secure LDAP instead of 389. Use LDAP Browser to get the Base DN and Administrator Bind DN. I prefer to use the app so I don’t fat finger the distinguished name and spend an hour trying to figure out that I missed a comma. Using LDAP Browser is much quicker and less error prone. The Base DN can be your entire AD domain or you can lock it down to an OU. The Administrator Bind DN is the actual account name that is used to enumerate AD. So CN = the user name, OU= the OU it’s in, etc. Add the password for this service account.

Make sure to select “SSL” for security type near the bottom. Click the blue “Retrieve attributes” link and it should talk to AD. Then the drop down boxes in Other Settings will not be greyed out anymore. Set the following:

Server Logon Name Attribute = samAccountName
Group Attribute = memberOf
Sub Attribute Name = CN
SSO Name Attribute = UserPrincipalName

So everything should look like this so far:

3. Now expand the Netsted Group Extraction arrow near the bottom. You need to enable it and set the same Group Name Identifier as you did for Server Logon Name Atrribute. In this case samAccountName. Then press OK to create the server:

4. Now it’s time to create the policy and bind it to the server. Hit the tab for Policies and create a new policy. Choose the server you just created. For the Expression, you will want:

REQ.HTTP.HEADER Cookie CONTAINS domain1

where domain1 is the name of your first domain.

5. Now do steps 2 through 4 again but for your second domain, domain2.

6. Almost done. What we’ve done so far is create two authentication servers and two authentication policies. These two policies are good for web browser users (IE, Firefox, Chrome, Safari, etc.) but mobile devices using the Citrix Receiver native app like iPhones, iPads, Android phones, Android tablets, etc. will not work just yet. This is because they cannot pass cookie values. Nor do they pass the domain during authentication against the Access Gateway (a traffic capture can confirm it only passes user ID and password). You need to create a different set of authentication policies for these. So you will create one for each domain. You will bind to the same authentication server as the other policies but you’ll want to add the word “mobile” or something descriptive to the end of the policy name so you know what it is for. The expression should be:

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver

7. Now do the same for your other domain, domain2.

8. Now go to your Access Gateway vserver and add all 4 policies you created. Take a look at my example screenshot closely and the priority order.

Here is the logic behind this policy order:

100 – Domain1 user logs in via web browser and uses drop down/passes cookie for domain1 so authenticates against domain 1 DC.

110 – Domain2 logins via web browser and uses drop down/passes cookie for domain2 so authenticates against domain 2 DC

120 – Domain1 user logins via iPad so first two policies are automatically false since the native Citrix Receiver app can’t pass a cookie. Authentication policy is looking for CitrixReceiver in the header so it will try to authenticate against domain 1 DC. It will be successful and the user will see his apps.

130 – Domain2 user logins via iPad. The first two are false for the same reason as 120. The expression from policy 120 is true so the user will actually authenticate and fail against domain 1 DC. Then it moves on to the 130 policy and authenticates against the domain 2 DC. It will be successful and the user will see his apps. Note, if a user has the same account name on both domains, it will cause a rejected login attempt on domain 1 which depending on your Active Directory account lockout policy can eventually lead to an account lockout. Just be mindful of this and adjust your policy accordingly if you need to.

MODIFYING YOUR SESSION POLICIES
9. Now on to the session policies. If you followed my guide on How to setup your Citrix Netscaler (Access Gateway) and Web Interface for iPads and mobile devices that use Citrix Receiver you should have 2 policies. One for regular traffic and one for mobile/Citrix Receiver traffic. Should look something like this:

Go ahead and click on the blue profile link for the CitrixReceiver policy first.

10. Under the Published Applications tab, clear the Single Sign-on Domain, you don’t need it anymore. SSO is being handled by the authentication server now. Specifically the SSO Name Attribute setting for each server which you set as UserPrincipalName. So it is automatically passing the UPN formatted user credentials to the Web Interface as the same time the user is successfully authenticating against the Access Gateway using the SAM account name. Pretty cool right? Now do the same for your other policy that controls regular web traffic.

11. An extra step for your mobile traffic policy. Under the Client Experience tab, you can set the Clientless Access to Allow and the Plug-in Type to Java but it’s not necessary. It will still work but since it’s mobile traffic only, this won’t hurt.

SETTING UP ACTIVE DIRECTORY AUTHENTICATION GROUPS
12. Now let’s move on to setting up your authentication groups. Let’s say each domain has a security group that gives users access via the Access Gateway. Again, there are 2 well documented methods for group extraction:

How to Configure a NetScaler Appliance for Active Directory Group Extraction for LDAP:
http://support.citrix.com/article/CTX111079

How to Configure a NetScaler Appliance for Active Directory Group Extraction for LDAP Using the Groups Allowed To Login Feature:
http://support.citrix.com/article/CTX125797

I prefer the first method. It’s basically just one step in one place (the authentication server object) and goes into effect at the authentication level. No fooling around trying to control it via a session policy. So go back to your 2 authentication servers you created before and take a look at the Search Filter field. It should be blank at the moment.

13. Go to LDAP Browser and get the DN for for the security group you want to give access to for your first domain.

14. Go back to the Search Filter field and type memberOf= followed by the DN (distinguished name) for the security group. So it should look something like this:

That easy. Make sure to do it for the authentication server for domain 2 as well. Go ahead and test your login scenarios and everything should work perfectly.

ADDING REDUNDANCY FOR YOUR AUTHENTICATION SERVERS
I only covered how to add a single authentication profile (domain controller) for each of the 4 policies on the vserver. Most companies are going to have multiple DCs. There is no way to add multiple DCs per authentication policy. The solution is to create a Load Balanced vserver with all your DCs behind it per domain and then add the IP of the vserver to an authentication server that is bound to the authentication policy. So in the example I’ve been showing you, I would have to create 2 load balanced vservers since I am working with 2 domains.

15. Go to Load Balancing > Servers > and add all your servers here:

16. You guys know I prefer to create service groups vs. services and the reasons why if you’ve read my previous Netscaler articles so go to the Service Groups section and add a new services group. Select SSL_TCP for the protocol.

Specify the server based members and make sure to set the port to 636. You can weight the servers here if you want to. Under the Monitors tab, go ahead and add a ping monitor or whichever monitor you prefer. Do this for each group of your authentication servers. You might want to group them by city, datacenters, production vs. DR, or whatever makes sense in your environment.

17. Now create a load balanced virtual server for your first domain. Select SSL_TCP for the protocol, port 636, and give it an IP address. Under the Service Groups tabs, add the groups you need. Keep in mind you won’t be able to see the SSL_TCP service group you created until you set the vserver protocol to SSL_TCP. Under the Methods and Persistence tab, you can get creative if you like or just leave it the default Least Connection. It really depends on your environment and where you prefer traffic to go. Under the SSL Settings tab, bind the cert you use for your Access Gateway vserver. Do all of this for your other domain as well. Both load balanced vservers should be in the UP state at this point.

18. Now go to System > Authentication > Server tab and left click on one of the DCs. Then at the bottom click Add, this will copy all of the settings on the DC you had highlighted and allow you to create a new one based off of it. So you don’t have to put all your DNs and stuff in again. Just give it a unique name and for the IP, type in the IP of LB vserver you just created for that domain:

Now do the same for the other domain.

19. Now go to the Policies tab and edit each of your 4 policies. You can simply change the server in the drop down to the new one you created for each of your 4 policies and you’re done. All authentication traffic is now going through your load balanced vservers. Keep in mind that before, LDAP traffic was going from your NSIP to each DC. When you use LB vservers, traffic is going from the SNIP to each DC. So make sure you have your firewall ports open from the correct source IPs or you won’t be able to authenticate. Retest all your scenarios and everything should continue to work just as before.

TROUBLESHOOTING LOGINS
Once you’ve set everything up you might encounter issues and need to troubleshoot. There are a few ways to troubleshoot logins. I’ve covered this before here:

How to troubleshoot RADIUS or TACACS authentication issues on a Netscaler/Access Gateway

20. First you can troubleshoot the authentication layer but capturing of all authentication happening on the device. Open Putty and connect via SSH to your Netscaler. Enter the shell by typing

shell

and pressing enter. Then type:

cat /tmp/aaad.debug

and the cursor will go to the next screen and wait. Open up your web browser and attempt to login to the Access Gateway. Immediately you will see the request happen in your SSH window. You’ll see exactly what is happening line by line like this. You’ll even see the nested group extraction taking place:

The last line will show the accept or reject:

When you’re done, press Ctrl+Z to exit.

21. The next layer to troubleshoot is all the polices. All of them, authentication, session, etc. You want to see everything a user hits when he logs in. So type the following:

nsconmsg -s disptime=1 -d current -g pol_hits

and login to the Access Gateway again using a web browser. Immediately in your Putty window you’ll see what all policies were hit:

This will help troubleshoot your policy flow. We’ve built a lot of intelligence into the cascading authentication and session policies and based on the user’s device and domain, it will vary what all they hit. This is an excellent way to test each of those scenarios.

22. The last step is getting down to the packet layer and analyzing the traffic using Wireshark. I’ve covered this in my previous post but go to System > Diagnostics > Start New Trace and set the packet size to 0. Then press Start.

Login to your Access Gateway via web browser, stop the capture, and download it to your desktop. You will also want to WinSCP into the Netscaler and grab the SSL RSA key for the SSL cert you are using on your Access Gateway site so you can decode the SSL traffic. Then double click on the .cap packet capture file and it will open in Wireshark. Go to Edit > Preferences > Protocols > SSL > and click Edit in the RSA Keys field:

In the SSL Decrypt Window, hit New in the bottom right side and this window will popup. Type in the IP address of the Access Gateway vserver, port 443, protocol http, the exact path on your hard drive to the SSL RSA key file, and leave the password blank. Then press OK to add it:

Press okay and get back to your capture. Now in the Filter field, just type the following:

frame contains youruserID

because we want to find all the instances of your user ID being passed. You should be able to find your user ID and password in plain text. Follow the TCP stream if you need to to find out exactly what is happening.

Hope this helps. Please leave a comment if this post helped you or if you have any questions and I’ll try my best to help.

A lot of companies use RADIUS or TACACS authentication on a Netscaler for use with Access Gateway (AGEE) which is pretty secure. Sometimes you might have users that complain they can’t login via the Access Gateway. There are a few things you can do to troubleshoot authentication issues. I’m going to run through some screenshots from a NS 9.3 device because that’s what I have in front of me at the moment but the same troubleshooting methods can apply to NS 10.x.

Capturing AAA authentication traffic in real-time
1. SSH into the Netscaler, login with your admin credentials, then enter shell by typing:

shell

2. Now you want to capture the authentication in real time and see exactly what the error looks like. This is handled by the AAA (Authentication, Authorization, and Auditing) on the Netscaler. So type the following:

cat /tmp/aaad.debug

A successful authentication against the Access Gateway would look like this. The user is named User1:

usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[614]: 
process_kernel_socket call to authenticate
user :User1, vsid :414
Tue Feb  5 09:53:53 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[138]: 
start_radius_auth attempting to auth User1 @ xxx.xxx.xxx.xxx
Tue Feb  5 09:53:53 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[741]:
 process_radius radius accepts : User1
Tue Feb  5 09:53:53 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[743]:
 process_radius extracted group string :(null)
Tue Feb  5 09:53:53 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[1466]: 
send_accept sending accept to kernel for : User1

and an unsuccessful authentication would look like this. The user is named User2:

Tue Feb  5 09:50:11 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[614]: 
process_kernel_socket call to authenticate
user :User2, vsid :414
Tue Feb  5 09:50:11 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[138]:
 start_radius_auth attempting to auth User2 @ xxx.xxx.xxx.xxx
Tue Feb  5 09:50:11 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[788]:
 process_radius radius rejects : User2
Tue Feb  5 09:50:11 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[138]:
 start_radius_auth attempting to auth User2 @ xxx.xxx.xxx.xxx
Tue Feb  5 09:50:14 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[731]:
 process_radius retransmit radius packet
Tue Feb  5 09:50:17 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[731]:
 process_radius retransmit radius packet
Tue Feb  5 09:50:20 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[778]: 
process_radius rad_continue_send_request:No valid RADIUS responses received
Tue Feb  5 09:50:20 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[785]:
 process_radius unknown return value from rad_continue_send_request :-1
Tue Feb  5 09:50:20 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[788]:
 process_radius radius rejects : User2
Tue Feb  5 09:50:20 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[1562]:
 send_reject sending reject to kernel for : User2
Tue Feb  5 09:50:23 2013
lwagent.c[1107]: main EV_DEBUG: handle time out

you can see very clearly that the authentication server has denied access. This points to an issue on the authentication server. To stop the capture, just hit Ctrl + Z.

Viewing the ns.log using Syslog Viewer
1. You can look at all the failed logins in the ns.log. In the Netscaler admin console/GUI, go to System > Auditing and click the “Syslog messages” button:

2. Select the AAA module and then double click each ns.log file. You will immediately see all the “LOGIN_FAILED” event types as you go through each ns.log (these are the logs stored at /var/log on the Netscaler). Pay attention to the message, it will tell you why the authentication attempt failed. As you can see in this example, the authentication server is the problem and is denying access:

Running a Trace
1. Lastly you can run a network capture/trace when users are experiencing the issue. You can do this via the console/GUI easily by going to System > Diagnostics and clicking on “Start new trace”:

2. Set the packet size to 0 and hit Start:

3. Stop the trace once you feel you have enough traffic captured:

4. Download the nstrace .cap file and you can open it in Wireshark for further analysis:

Hope this helps some of you. Let me know if you have any other methods of troubleshooting authentication issues you would like to share. LDAP troubleshooting is easier since the Netscaler can give you a lot more detail as to what is failing. RADIUS and TACACS is a little trickier since you have something in the middle to troubleshoot but the steps above should give you enough to tell you if the problem resides on the Netscaler or on the authentication server.

If you have a need to quickly brand your Netscaler Access Gateway and Web Interface 5.4 with your company colors and logo, it’s pretty easy and can be done in less than 30 minutes if you are under a deadline. It’s easy in StoreFront too, just don’t have one in front of me right now to write about. This is quick and dirty, you can do more work to match them up exactly but I just wanted to knock this out in 30 minutes.

NETSCALER ACCESS GATEWAY
Just download one of these available themes Jeff Sani posted:

http://blogs.citrix.com/2011/04/11/horizon-theme-for-citrix-netscaler/
http://blogs.citrix.com/2012/06/19/symphony-theme-for-citrix-netscaler/
http://blogs.citrix.com/2012/04/19/green-bubble-theme-for-citrix-netscaler/

I chose the Horizon theme because it matches WI 5.4 the closest. Here’s what you need to do to implement it. I did this on a Netscaler running NS 9.3 but 10.x will work too:

1. Download the Horizon.txt script and rename it to Horizon1.sh like Jeff says. Then download Horizon1.gz.
2. Now use WinSCP to copy both to your primary Netscaler to /var/vpn/themes
3. Putty/SSH into the primary Netscaler, enter shell, and navigate to /var/vpn/themes
4. Type:

sh Horizon1.sh

This script by Andre Perry does all the stuff Jeff says in the posts above. Very nice Andre! At this point you have deployed the theme. Now to customize for your company.

5. Just change 3 files on the Netscaler:

/var/vpn/themes/Horizon1/ns_gui/vpn/images/Background.png – your company colors in the background. I usually use 2 colors here. Just play with the height of the colors in Photoshop to adjust and make them line up with the login box the way you want.

logo.jpg – Create it from scratch and drop it in /var/vpn/themes/Horizon1/ns_gui/vpn/images/

index.html – change the following:

<table cellspacing="0" cellpadding="0" class="logonBoxWidth">
<tr><td colspan="3" class='headertop'><span class='headerLabel'>NetScaler Access Gateway</span><span class='headertm'><sup>TM</sup></span></td></tr>

TO

  <td>
          <img src="/vpn/images/logo.jpg">
      </td>
<table cellspacing="0" cellpadding="0" class="logonBoxWidth">

6. Now make sure to copy all 3 of these files to the flash (where everything is currently running from) here:

/netscaler/ns_gui/vpn/images/Background.png
/netscaler/ns_gui/vpn/images/logo.jpg
/netscaler/ns_gui/vpn/index.html

7. Refresh the Access Gateway page and your changes should appear there. Sometimes you may need to clear your cache. I use FireFox which is pretty good about it and I didn’t have to clear anything. If you need to adjust anything, go ahead and do so now. Just remember, after a reboot of your Netscaler anything you put in Flash at the paths in step 6 above will revert. Stuff gets copied over from the /var folder in step 5 above. So make sure you put your files there as well to prevent this.

8. Now login to your secondary Netscaler and perform all the same steps. None of this stuff gets synched between devices.

Here is how my final product looks:

WEB INTERFACE
Andrew Morgan has an excellent post here that goes pretty in depth:

http://andrewmorgan.ie/2011/08/30/decrapifying-the-citrix-web-interface-5-4/

I needed something quick so I just modified 4 things under c:\inetpub\wwwroot\Citrix\XenApp\media:

1. CitrixXenApp.png and CitrixXenApp.gif – I changed this to my company logo
2. HorizonBgTop.png – I went with solid white in Photoshop with this one
3. HorizonBgBottom.png – I went with solid blue in Photoshop with this one
4. HeaderGradient.png – Did a gradient in Photoshop using two of my company’s colors. This appears once you login along the top.

This located under c:\inetpub\wwwroot\Citrix\XenApp\app_data\include:
5. fullStyle.inc – I changed this to rip out that ugly HDX logo:

.horizonPage #hdxLogo {
display: none;
}

and this to give me a solid white background along the bottom:

.horizonPage {
    background: #ffffff url("../media/HorizonBgBottom.png") repeat-x left 325px;
}

And this under c:\Program Files (x86)\Citrix\Web Interface\5.4.0\languages:
6. accessplatform_strings.properties – I customized the text in this. While playing with it I noticed it does support HTML just fine so I did this:

HorizonTagline=Your Windows 7 desktop and company apps on demand - from any PC, Mac, smartphone or tablet.<br><font size="2">FOR SUPPORT: Help Desk at xxx-xxx-xxxx, Option 1 (toll free: xxx-xxx-xxxx) or xxxxxxx@xxxxx.com.</f>

Done, upload all your files and you have a pretty nice simple company branded Web Interface. You should change the “loggedoff” images that are greyed over to match when you get some time or you’ll see the default images there greyed over instead.

Here is how my final product looks:

So you want to give iPads, iPhones, Android phones and other mobile devices and tablets that have Citrix Receiver access to your enterprise infrastructure securely. This can be done pretty easily using a Netscaler and the Access Gateway (aka CAG/Citrix Access Gateway, AGEE/Access Gateway Enterprise Edition) which is an SSL VPN among other things. First you need to prep your Citrix Web Interfaces.

In this example, I want users sitting inside the building with their iPads connected to the corporate WiFi direct access to XenApp and XenDesktop. I want anyone external to have to come in through the Access Gateway to get access. So I need to make sure I have 2 Services sites on my web interface:

The default site is PNAgent (which is a reference to the old legacy Program Neighborhood). This services site is setup for Direct access and will service all my internal iPads and other devices that need it. The second site is the one I created manually called “AccessGateway”. This one is setup as Gateway Direct mode. This is the site that will be handling traffic from the CAG (Citrix Access Gateway):

When you are setting up the site, just add the farms as you would any other site. Nothing is different. In my case, I am using port 8080 as the XML Service port:

Under Secure Access, hit Next:

Here you need to type in the FQDN that your iPads and other devices are all pointed to. You need to type in the actual name, not the IP. So in my example, I want my users to hit this URL in Citrix Receiver:

http:\\receiver.company.com

so in this box, I would type:

receiver.company.com

This is presented to your iPad and other devices through the Web Interface in the form of an ICA file later so it needs to be the same. Also make sure to disable Session Reliability. Session Reliability is not supported on iPad and other devices using Citrix Receiver. So this means all ICA traffic will be on port 1494, not 2598. So keep that in mind when opening up firewall ports:

The last page is to add the STAs (Secure Ticket Authorities). You DO NOT need to add an STA from every farm you are connecting to. Just 2-3 STAs for redundancies sake is enough. It won’t be a whole lot of traffic. All it will be used for is to pull the ticket hash value when a client hits the web interface and then later to validate that ticket. In my case, I am using port 8080 for the XML Service port so that needs to reflect here in my STA URLs. You may be using port 80 so you would not to enter the port. In my example, it is:

http://servername:8080/scripts/ctxsta.dll

The ctxsta.dll is an ISAPI extension for IIS that will take the ticket request, process it, and send back the generated ticket. When a user hits the Access Gateway and comes in through the web interface, the web interface will send this request to the STA. Once the web interface gets the ticket (a random 32 character hash value) from the STA, it builds the ICA file to present back to the client and this value will be included. Then validation occurs just before the actual ICA session is launched and the STA needs to validate the ticket.

So now that the web interface config is complete, it’s time to configure the Netscaler. Go to the Access Gateway section and expand the Policies section. Then click Session and click the Profiles tab at the top. We are going to create a session profile first. I will call the profile “CitrixReceiver_Profile”:

I don’t really needs to change anything in this profile except on the last tab, Published Applications. Under Web Interface Address, I type in the URL to the web interface “Access Gateway” site I had create in the steps above earlier on the web interface. But I need to make sure I point directly at the config.xml file which has all the configuration information in it for the Access Gateway to read. So in my case, the URL is:

http://receiver.company.com/Citrix/AccessGateway/config.xml

Hit OK, and click the Policies tab. Create a new session policy to filter out traffic and only allow Citrix Receiver traffic. I will call my policy “CitrixReceiver_Policy”:

The actual policy will look like this, notice how it looks at the TCP User-Agent header for “CitrixReceiver”. For any other traffic, like a web browser for example, it will drop the packet. Don’t forget to choose the “CitrixReceiver_Profile” you created so that it knows to pass Citrix Receiver traffic to your new “AccessGateway” services site:

Hit OK and you are done setting up policies. Now go to Authentication under Policies and setup your Active Directory authentication. For better security, I recommend RADIUS. You will need to setup the policy and the back end server here:

Then go to your SSL certs and make you have a valid 3rd party SSL cert for your “http://receiver.company.com” website. Traffic will be SSL encrypted and Citrix Receiver does not support self signed certs. Make sure your intermediate and root certs are there and everything is linked properly. Otherwsie your SSL chain will be broken which will lead to issues:

Now that we have all the pieces in place, it’s finally time to configure our Access Gateway virtual server. So go to Access Gateway > Virtual Servers > and hit Add. Give it a name, IP address, leave it on port 443, leave the protocol as SSL, and add your SSL cert over to the column in the right. It should look something like this. And yes, Down State Flush is unchecked meaning if the vserver goes down, TCP sockets will remain active and won’t immediately be disconnected. You don’t have to uncheck it though:

Now click the Authentication tab, and add your Authentication Policy:

Now click on Policies and add your Citrix Receiver policy. By default, the priority will be 0 which is actually last. Doesn’t matter if you only have 1 policy but if you add more, you might forget to change it then. So just set it as 10 for now:

Now lastly, you need to add your STAs under the Published Applications tab. The same exact STAs you specified in your web interface several steps above. Again, I am using port 8080 for my XML Service so I have specified it here after each server name. Once you are done, press OK and then immediately open the virtual server again, go to the Published Applications tab, and you will see the green arrow and the word “UP” next to each STA. You will also see it has pulled the identifier down:

And now you’re done with the config! Don’t forget to open up firewall ports. In the DMZ, you will need 443 to come through and hit the Access Gateway URL (receiver.company.com in my case). From the Netscaler SNIP (subnet IP), not the Access Gateway virtual server IP, you need the XML Service port (8080 in my case but 80 if you left it default) open to all the STA servers you specified. You also need ICA (port 1494) open to all your XenApp application servers or XenDesktop VMs open from the SNIP as well. Lastly, you need to open up port 80 from the Netscaler SNIP to your web interface for HTTP traffic. Just remember, the SNIP is the one communicating to your internal servers, not the Access Gateway VIP so don’t get confused when adding your firewall rules. The only exception would be authentication (LDAP, RADIUS, etc.). This traffic comes from the NSIP (Netscaler management IP), not the SNIP or MIP. So take this into consideration when opening your ports.

Now to test! Open up Receiver in your iPad and type the URL, in my case “receiver.company.com”. Set your credentials and connect. If you did everything right, it should enumerate all the apps on all the farms you had specified on your “AccessGateway” services site. Click an app and it should launch just fine.

You can do an nstrace (packet capture) on the Netscaler itself to verify and also as a troubleshooting step if something isn’t working as expected. Pull the capture file over and use Wireshark to read and filter it. Remember above when you were setting up your services site and had the type the FQDN name and I mentioned this is important because it is passed back to the iPad in the ICA file? Well here it is, the red arrow is where it appears under “SSLProxyHost”:

And don’t forget to apply your CAG licenses. You might have only licensed the appliance itself and said to yourself you would apply the CAG licenses later…yes I’m guilty of this. By default you can only have 5 simultaneous CAG users so don’t forget to apply the license before releasing to production. You need to also make a decision of SmartAccess/CCU/Universal licenses vs basic licenses. If using basic licenses, you can set it up for up to 10,000 concurrent users, here is a great KB from Citrix on how to do this:

http://support.citrix.com/article/CTX125567

Also don’t forget to set the global user limit on number of sessions through the Access Gateway. It should match up to the number of licenses + 5 you get for free with the appliance. By default the Maximum Number of Users setting is 5. This is found under Access Gateway > Global Settings > Change authentication settings. You can also limit this per Access Gateway vserver if you wish:

And what if nothing works after going through all these steps? Well it can be any number of reasons. Citrix has an excellent troubleshooting PDF available here called “Citrix Receiver for Mobile Devices Troubleshooting Guide” with plenty of screenshots. It is extremely helpful:

http://support.citrix.com/article/CTX125533

Try flipping through it and if you can’t figure it out, post here and I can see if I can help.

***UPDATE***
You might also want to allow regular clients (IE, Chrome, Firefox, etc.) running Windows 7, OS X, etc. access through the Access Gateway to your Web Interface via SSL. Something a lot of companies do. For that just create another Access Gateway site but under “XenApp Web Sites”:

Make sure you set the authentication service URL to whatever your AG URL is, so following the same example:

https://receiver.company.com/CitrixAuthService/AuthService.asmx

The Secure Access method must be Gateway direct mode just like you did for the Services Access Gateway site above.

The FQDN should be the AG URL your users are hitting externally so:

receiver.company.com

Go ahead and enable session reliability since it is supported on workstations. So keep in mind ICA traffic will be on port 2598 when opening firewall ports.

Now add your STAs in the same order as before:

On your Netscaler under Access Gateway > Policies > Session, you will need to create a policy for non-mobile devices. The Web Interface address is the internal URL of your web interface you want client’s to passthrough to. You can also put your domain in the Single Sign-on Domain box so it passes through the credentials:

Default Authorization Action I set to DENY usually:

Under the Client Experience tab, I allow Single Sign-on to Web Applications:

Now under the Policies tab, you need to create your session policy and bind it to the profile you just created:

My expression will be:

REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver

And now finally under the Access Gateway, make sure both policies are in it. I set the mobile device policy first, then everything else. Doesn’t really matter though what order you have it:

One last bit of info. If you want to only allow mobile devices with Citrix Receiver installed and have regular browser traffic (IE, Chrome, Firefox, etc.) redirected somewhere else, it’s pretty easy to do. For your port 80 traffic, you need to create a load balanced virtual server on the same IP as your Access Gateway virtual server. The effective state will be down since you will not add any services or service groups to it. Under the Advanced tab, set a Redirect URL to the site you want to redirect your PC browser users to.

Now for port 443 traffic, the Access Gateway virtual server will be servicing that traffic. Unfortunately Access Gateway vservers do not support Responder policies. The quick way of getting around this is creating a Responder policy and binding it globally instead. In my case, I created the following Responder policy to redirect any traffic that is not detected to be from Citrix Receiver:

HTTP.REQ.HEADER("User-Agent").SET_TEXT_MODE(IGNORECASE).REGEX_MATCH(re/CitrixReceiver/).NOT

and if it can’t figure out the User Agent, it will drop the packet per the Undefined Result action:

For the action, I set it to redirect to the URL I want browser users to end up on:

And then you can bind it globally:

Now all my Citrix Receiver SSL traffic will hit the Access Gateway vserver and regular browser based SSL traffic will be redirected to the URL I specified. What’s cool about this is that as you test it, the hit count should increase on the policy. Just be careful binding a policy like this globally since it will impact every vserver on your Netscaler. It works fine in my scenario because this particular appliance is dedicated for Access Gateway connections only.

Masking the web server software in your http header/http server banner (server header obfuscation) is an important layer of security you might want to implement since it can be accomplished so easily on a Netscaler. It’s a layer of security you can add to prevent someone from telling what kind of web server you are running, though it is still quite possible to figure out depending on your environment and application so don’t rely on it too much. The thought is an attacker scans for certain versions of a web server that have known vulnerabilities and begins running attacks for that specific web server software to see if those vulnerabilities have been patched or not. They can do this programmatically so changing the header to say something else is a layer of security that can prevent them from easily figuring out what your web environment infrastructure is like.

You will notice that Chase.com uses “JPMC1.0″:

Amazon.com uses just “Server”:

Google.com uses “gws”:

This can be done very easily using rewrite policies on the Netscaler. Catherine Hampton wrote a great article over at the Ctirix Developer Network on how to do this:

http://community.citrix.com/display/ns/Using+Rewrite+to+Improve+Web+Server+Security

And if you want to read more about web server fingerprinting, check Net-square’s website and their httprint tool:

http://net-square.com/httprint/

Saumil Shah at Net-square wrote an excellent and very thorough article on HTTP fingerprinting here:

http://net-square.com/httprint/httprint_paper.html

Today I would like to go over proper URL redirection when using SSL but first I would like to preface this by describing what proper URL redirection is. Anytime you inherit, consult for, or build an environment out from scratch, you must always verify every vector a user may use to get to your website. You must plan accordingly to intercept and redirect the user transparently when they manage to get to URLs that you don’t want them to use. They should never be prompted for an action (such as “click here” to continue) or receive a warning/error message if at all possible.

A 301 redirect is in my opinion to best way to steer a user to where they need to go. A 301 tells the browser/search engine spider that the redirect is permanent. In the case of spiders, a 301 will tell it only the destination URL should be indexed. A 301 redirect works fine over regular HTTP connections and all web servers and load balancers are capable of performing them. Alternatively, you can also use a 302 redirect but this tells spiders the redirect is temporary. Not very good for SEO purposes if your organization is concerned about that.

The problem occurs when you try to do a 301 or 302 redirect to an SSL URL (HTTPS URL) but the SSL certificate for that URL does not match the domain. It will throw a warning message saying the connection is untrusted or that there is a problem with the website’s security certificate in the user’s browser. Most users will come across on an HTTP connection such as http://www.domain.com and if needed, the network/web engineer would setup a web server or load balancer policy to perform the 301 redirect to https://www.domain.com. The certificate in this case is valid for “www.domain.com” and will not throw an error. But what if the user somehow manages to go directly https://domain.com over an SSL connection? It would throw an error unless the certificate is valid for “domain.com” which is most cases it is not. Even if you had a wildcard certificate for “*.domain.com”, it would not prevent you from getting a warning because this specifies any subdomain is valid, but does not cover just the domain by itself. Your user will always get a warning message. You may think you could write a policy on your load balancer to do the redirect but that will not work. The reason is a TCP connection has to be established first and during the SSL handshake before the connection is fully established is when the user gets the warning. The policy will never run as a result until after the user accepts the warning message and the SSL handshake is completed.

There are a couple of ways to get around this. The cleanest way of doing it is using a Subject Alternate Name (SAN) SSL certificate. A SAN cert allows you to specify exactly what domains you would like the certificate to be valid for. The price on SAN certs is much higher than a standard certificate or even a wildcard certificate and they are only available from a handful of certificate authorities at this time. They require a lot more validation typically and the validation term is usually a bit lower than a standard certificate.

Let’s compare a SAN SSL certificate vs. a Wildcard SSL certificate. A single SAN cert would cover me for the following if I wanted it to:

domain.com
www.domain.com
www.myotherdomain.com

while a single Wilcard SSL cert would only be able to do the following:

*.domain.com

It is possible to combine both so you could get a SAN + Wildcard SSL certificate that will cover all of the above. To my knowledge, the only certificate authority that currently offers them is DigiCert. They have a pretty nice write up about their cert here:

http://www.digicert.com/ssl-support/wildcard-san-names.htm

I once asked a VeriSign managed PKI rep why they don’t offer wildcard + SAN like DigiCert and he went on for 5 minutes about ICAAN policy. Why one cert authority can issue while another won’t, I am guessing it likely has to do with acquisition costs for them. You have to remember, VeriSign is still trying to convince people to buy SGC SSL certs (for legacy browsers) at a premium price when in my opinion, SGC has been obsolete for years now and any web/network engineer that knows about SSL encryption has anything below 128 bit locked down anyhow. But I guess if people will buy it, they will sell it. Either there just hasn’t been enough demand or their costs are too high for wildcard + SAN certs. Not trying to pick on VeriSign, just making an observation. I still purchase certs from them regularly (non-SGC of course). Most every large organization does, but sometimes the wildcard + SAN might be the best solution for you. I know some CDN providers like Akamai sometimes have a need for them and purchase through DigiCert.

Getting back on subject, a second way of getting around this is purchasing two standard SSL certifcates and putting them on different IPs. One will do a 301 redirect to an another. So you would have to purchase an SSL cert for domain.com AND www.domain.com.

Let’s look at some real world examples to better understand this. I am going to compare Chase, Bank of America, Citrix, and Amazon.com to show the different types of solutions for this problem.

Chase.com
Chase uses SAN certs from VeriSign. Again, SAN certs are a very pricey approach but the easiest. Your configuration on your load balancer and servers is minimal since one SSL cert will take care of everything. This will result is less overhead on your load balancers as well which is a big plus when you serve up millions of connections.

Go to https://chase.com, it will immediately do a 301 redirect to https://www.chase.com. Here is a screenshot showing the 301 redirect to https://www.chase.com and the certificate which shows the 4 Subject Alt Names Chase’s cert is valid for:

As you can see, the certificate is valid for www.chase.com, chase.com, www.yourchasefreed.com, and yourchasefreedom.com. You will also notice that the cert is only valid for a 1 yr period. Typically CAs will try and limit you to a max of 2 years on SAN SSL certs and EV SSL certs but it is always best practice to keep them to 1 year just in case your cert keys were compromised. A SAN cert can have many domains leaving you very exposed, so it is a good idea to change it every year for this reason.

Bankofamerica.com
Bank of America uses standard SSL certs from VeriSign. Cheaper but a little extra configuration involved on the load balancer. Let’s take a look at what happens when you visit https://bankofamerica.com:

You will be 301 redirected to https://www.bankofamerica.com just as you were with Chase. But this time using a standard SSL cert with one CN name as you saw above. You can verify this by pinging bankofamerica.com which resolves to 171.159.100.173 and typing just the IP into the browser over SSL as https://171.159.100.173. This will give you an SSL error before the 301 redirect gets a chance to run and you can view the cert:

So just to be clear, typing https://bankofamerica.com will use the above cert which is valid, will complete the connection, run a policy that will do a 301 redirect to https://www.bankofamerica.com, cert for https://www.bankofamerica.com is validated, then the connection is completed and the page is served up. A perfectly good way around the problem using standard SSL certs as opposed to SAN SSL certs.

Citrix.com
Citrix is another example of using the standard SSL certificate redirect method much like Bank of America. But they do not leverage the 301 redirect at all. Instead they use a 302 temporary redirect pointed directly to their index page. The 302 is likely done for SEO purposes so the “www.citrix.com” domain is indexed in search results and not the “www.citrix.com/lang/English/home.asp” destination page. In this case, a Netscaler with either a responder policy or content switching policy will send you to https://www.citrix.com or https://citrix.com which both display the same content. They are on different VIPs with different SSL certs. One is a standard cert while the other a wildcard. They could have used two standard certs if they wanted to as well of course but in this case, they may use the wildcard for other subdomains, GSLB, etc. and the standard cert is meant to solely capture those users typing in an incorrect URL:

Amazon.com
Woops! The world’s largest online retailer does not seem to be redirecting customers that arrive on an irregular URL over SSL properly. If you go to https://amazon.com, it will give you a “This Connection is Untrusted” error. It’s not the end of the world but still, a user should never see a message like this.

In IE for example, it will say “There is a problem with this website’s security certificate”. Again, not the end of the world. But in Chrome, the error will have a bright red background and say “This is probably not the site you are looking for!
You attempted to reach amazon.com, but instead you actually reached a server identifying itself as www.amazon.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of amazon.com. You should not proceed.”

Yikes! Do you really want your users to see a message like this?

Interesting to note however, going to https://www.amazon.com does a 301 redirect to http://www.amazon.com. Obviously Amazon wants the customer to use HTTP rather than SSL on their homepage. Much less overheard on their load balancers plus they don’t have a login box directly on their home page so no need for SSL to begin with. This is thought out well but I am puzzled as to why they don’t do anything about https://amazon.com. As you saw with Chase, Bank of America, and Citrix, the different solutions are very easy to implement.

I hope this article has been helpful. Please post a reply if you have a different solution to the problem that I did not cover. I would love to hear your insights.

Citrix is now offering Netscaler VPX Express licenses with throughput increased from 1 Mbps to 5 Mbps! This will help tremendously in test lab environments for a lot of people. Most of my important test environments where I need some extra bandwidth were on VPX 10 or VPX 200 licenses already but now with a 5 Mbps throughput VPX Express for free, it gives me a little more wiggle room before I need to shell out the cash for these licenses.

That’s not all! Now those of us that are existing Netscaler customers are entitled to VPX Developer edition licenses with Platinum edition features! This makes testing features like integrated caching for example easier without having to pay for a license first. Sadly you are limited to 1 Mbps but it should be more than enough to test low bandwidth apps against Platinum features. You can always get a 90 eval though which has a 1 Gbps limited if you really need the extra bandwidth for testing.

Good move on Citrix’s part! This how how you corner the application delivery market and then stay on top. Give it away for free and let people see how powerful the Netscaler platform is first hand.

Read more about the changes on the Citrix Community blog here.

In a worst case scenario and all your web servers have failed, what do you do? You could have a standby group of servers or CDN on or off premise to pick up the load or at least display a maintenance page but this is worst case scenario. A catastrophic failure and ALL your servers are down due to a code issue, server configuration issue, database issue, virtual infrastructure failure, SAN failure, maintenance being performed on all servers at once (I hope not on purpose), virus outbreak, or whatever else kind of horrible scenario you can think of. You get traffic all the way up to the Netscaler appliance but since your vserver is down, the user’s browser will timeout as if your company fell off the face of the earth. This is very unprofessional for any organization. Users timing out or seeing a “page could not be displayed” error is unacceptable.

So the solution is to have the Netscaler display a maintenance page with the code hosted on itself somehow. I tried several different methods including content filtering and responder policies using HTML. Originally I even thought I could leverage integrated caching to serve up cached pages and static content like images. I settled only using a responder policy initially which worked. Citrix even has a very nice knowledge center article (CTX117337: How to Configure a Maintenance Web Page by using the Responder Feature of the NetScaler Appliance) which is located here:

http://support.citrix.com/article/CTX117337

In a nutshell, what the author of the article wrote is basically more or less the same conclusion I reached as well. I just did it via GUI and that is what I will show you below. But I was not happy with the result. Keep reading and you will see why. FYI, I did all the screenshots below on an NS 9.1 appliance but it is the same procedure on NS 9.2 or any other version.

1. I am going to assume you have servers, services/service groups, and a vserver already that is UP and running. I will call them the following in this example:

vserver – lb_vsver_mywebsite
service group – svcgrp_myservicegroup
server – svr_mywebserver

Excuse the redactions in my screenshots please, I had some other configurations on this test appliance and I don’t want to confuse you with it:

vserver:

service group:

server:

2. Now create a backup vserver for your existing live vserver. In this example, I have called it “lb_vsvr_bkup_mywebsite”. But instead of giving it an IP, just uncheck directly addressable. This will cause the IP area to become greyed out:

backup vserver:

When you click Create, it will show up as running on the IP 0.0.0.0 like below:

3. Now you need to create a service that is always UP and bind it to this backup vserver so that it will always remain UP. Just go under Load Balancing > Services, and click Add. Then create a service called “svc_maintpage” but for the Server, type in the localhost IP of 127.0.0.1, add a ping monitor, and press create.

4. Now go back to your backup vserver and bind this new service to it. Immediately after clicking OK, the backup vserver should go into an UP state. You might need to refresh your window if it doesn’t.

5. Now double click on your live vserver and under the Advanced tab, choose “lb_vsvr_bkup_mywebsite” for the Backup Virtual Server option and press OK:

6. Now under Responder > Action, click Add to create a new action. This is where you get to put some HTML and CSS. It must be very basic, all parenthesis have to be removed when using CSS in the HTML body or it will give you can error, and the whole policy must be under 255 characters total. I will name mine “action_mywebsite_maint_page” and here is an example of my policy I will use with it:

"HTTP/1.0 200 OK" +"\r\n\r\n" + "<html>
<style type=text/css>
<!--
.mywebsitefont {
  font-size: 24px;
}
-->
</style>
<body class=mywebsitefont>Sorry, our website is currently not available. 
Please try again later.</body></html>" + "\r\n"

7. Now under Responder > Policy, click Add to create a new policy that will call on the action you just created. In this example, all we need is for the HTTP request to be valid and we will display the maintenance page. I will name it “resp_policy_mywebsite_down” in this example. Choose the action you just made in the Action drop down and for the expression, just put:

HTTP.REQ.IS_VALID

8. Now go back to the Load Balancing folder and double click your backup vserver and bind the responder policy to it like below:

9. Now to test. Open up your website in a browser and it should display as normal right now. Now login to your webservers and turn off your websites. Immediately your live vserver should say DOWN for the State but the Effective State should remain UP. This is because all traffic is being forwarded to your backup vserver you specified earlier which is set to always be up:

Refresh your browser and you should now see the maintenance page you created like below:

As you can see, a simple HTML page like above is not very professional. We need more HTML/CSS than 255 characters to work with and we need images working to make it look professional. At least it is better than a page timeout though!

Now with a content filtering policy, you don’t have to worry about a character limit. You can get away with putting HTML/CSS in a content filter policy. But again, where do the images come from?

I decided to call Citrix and see if they have run into a request like this. They had not. Now off the bat both techs I spoke to said what I was trying to do is not supported by Citrix. A Netscaler is not designed to do this. But luckily the second tech Brian at Citrix Support was just as enthusiastic about getting something to work as I am and wasn’t going to give up easily so we went over a few scenarios. The Netscaler does have an Apache web server on board, that is how the admin GUI is display to you. It is also how the Access Gateway portal is displayed to the end user. We needed to figure out a way to leverage the Apache web server on board the Netscaler to host our images, HTML, CSS, etc. The initial thought was to overwrite the Access Gateway portal and create a responder policy that would do a redirect to an Access Gateway vserver you create. The negatives here are that you are limited to SSL traffic only, have to worry about having a valid cert, you can’t bind all the policies you might need to it like you can a load balanced VIP, etc. I didn’t feel that comfortable destroying functionality to gain other functionality either.

In the end, the solution was easy and did not require overwriting the Access Gateway portal. We can host our HTML, CSS, and images on the Netscaler itself and point Apache at it. Brian did a quick proof of concept in his lab. Then I improved on it a bit. Here is the end result which I am sure a lot of you will find pretty handy in your organizations. Steps 1 through 5 are the same as above. Then from there, begin these steps:

1. First we need to get our HTML, CSS, and images on the Netscaler. WinSCP into your Netscaler and go to “/netscaler/ns_gui”. The folders you see called admin_ui, vpn, etc. are what host the Netscaler Admin GUI and Access Gateway respectively. So you have the option of putting something in the root of this folder or even create a separate folder here if you want. In my case, I decided to put a “maintenance.htm” in the root and also create a folder called “static” that will host most static content like CSS and images.

2. Now under Responder > Action, click Add to create a new action. Very important, make sure to change the type from Response to Redirect. The action should be the following (with parenthesis included):

"http://www.mywebsite.com/maintenance.htm"

3. Now under Responder > Policy, click Add to create a new policy that will call on the action you just created.. Your responder policy will need to allow the maintenance page, plus CSS, .gifs, and .jpgs you might use. So the policy I will use is:

!HTTP.REQ.URL.CONTAINS("maintenance.htm") && !HTTP.REQ.URL.CONTAINS(".gif") && !HTTP.REQ.URL.CONTAINS(".jpg") && !HTTP.REQ.URL.CONTAINS(".css")

4. Now go back to the Load Balancing folder and double click your backup vserver and bind this new responder policy to it like I did below:

Now if you disable your service groups and check your maintenance page again, you can see how the website displays the full page with nice HTML, CSS, and images. In this example, I borrowed the Sears.com maintenance page. Notice how showing your company logo keeps your branding intact even on a maintenance page which is the correct way to handle a website issue. Tell your users you are aware of the problem and offer alternatives in the meantime (static links along the bottom to other servers that are up and offering content in this example). You don’t have to go that far but it’s always nice to let your user base know you haven’t disappeared and your infrastructure is solid. This is very professional and above all, automated!

The only problem here is that when your website is back up, users will still be refreshing on this maintenance.htm page. They will get a 404 error. So you have four options. I usually prefer number 4 personally but it all depends on your needs:

1. Change your maintenance.htm page to say index.htm or whatever page is the default page of the root of your website so when they refresh once the vserver is back up, they will get the live page. You will need to WinSCP into your Netscaler again and change the maintenance.htm file name as well as change it in your Responder Action. The issue here is if let’s say you are using .NET, you can’t call it index.aspx because Apache on the Netscaler can’t parse it.

2. Just create a link on the page that says “Click Here to Try Again” which is pointed at the correct index page. This assumes the end user will actually click the link instead of hitting refresh. You can’t be 100% sure they will do this.

3. Create a maintenance.htm page on your servers and then set IIS, Apache, or whatever web server you use to do a 301 redirect to your live index page. You can leverage the Netscaler to do the redirect too of course.

4. My preferred method. Create a new responder policy saying any maintenance.htm should automatically redirect to index.aspx and bind it only to your real vserver. That way anyone that requests that page when your servers are up will always be redirected to your index page. In this example, I will call my live site’s index page index.asp and call the action policy “action_mywebsite_index_redirect”. I will also make it redirect to SSL in this example because there is a login box on the index.asp page and I want to keep it secure using https:

I will call the responder policy “resp_policy_index_redirect” and for the expression, tell it to redirect any requests to “/maintenance.htm”:

HTTP.REQ.URL.CONTAINS("/maintenance.htm")

Now bind this to your live vserver:

Now you can test it by disabling and enabling your servers or service groups. It should transition automatically between your maintenance page and the live index page.

One thing I would like to point out. On any of your Responder Policies or Actions, you can always view the hit counter to see if the policy or action is being invoked. This might help you when you are setting this up initially and something goes wrong and you want to see if the policy or action is being hit:

So there it is. Your Netscaler is now an emergency web server that automatically puts up a professional looking maintenance page in a worst case scenario when every backend web server you have is down. A big thank you to Brian at Citrix for the help! If anyone can think of any improvements to this process or has any trouble with it, please reply I would love to hear about your experience.

I get asked this question a lot. How do you tell what license you have applied to a Netscaler VPX appliance? The next question is what edition VPX do I have: Standard, Enterprise, or Platinum? Most people expect either one of these very important pieces of info would be displayed right along the top header where the IP and hostname are or at least under the main System window under the Hardware Information section but it is not. You can figure out what version you have by looking at the features of the appliance and looking at the current throughput to deduce the license and edition but that is not very practical. There are 3 ways you can see the current license applied easily without having to play detective:

1. Click Licenses under the System folder and the last item in the first column is “Model ID”. For physical devices, it will show the model number like 7500, 9500, 15000, 17500 etc. But for VPX appliances, it will say 1 for the the free VPX Express appliance (denoting the 1 Mbps limit) and 10, 200, 1000, or 3000 for the pay for licenses. If you just upgraded from the free version to a pay for version, you can verify it was applied here at a glance easily.

2. WinSCP down the license file from the appliance and open it in Notepad or any text editor. Make sure wordwrap is off. The third line of the license file will tell you the version. For example, something like this:

#CITRIXTERM FEATURE 1.0 CNS_V200_SERVER EN Citrix NetScaler VPX 200|Server

This means the license I have is for a VPX 200. If you take a look at the very first line and scroll to the right some, you can see the edition level info under INCREMENT on physical appliances:

CNS_SPE_SERVER

The SPE part means I have a Platinum Edition license. Standard Edition would be CNS_SSE_SERVER and Enterprise Edition would be CNS_SEE_SERVER.

On a VPX virtual appliance, it will never say this. Instead it will say something like:

CNS_V200_SERVER

which tells you it is a VPX 200, but you have no way of telling the edition. The only thing you can do to figure out what edition it is by looking at the features available to you and comparing to the the VPX feature matrix here or move on to option 3 below.

3. Login to MyCitrix.com and look at the license file there under Manage Assets. It will tell you which version you have. But when you have 50-60 Netscalers you might be responsible for, this becomes a bit tedious to wade through. You could also call Citrix Support and give them your license number and they can tell you what edition your license is but then you have to play the waiting game on the phone with them. Easier to just login to MyCitrix.com and go through your licenses.

Hope this helps. Please do post a reply if you have an easier way of identifying your VPX license edition level at a glance.

I recently received a request to catch all requests on HTTP and redirect the user to the exact same URL that was requested but over SSL (HTTPS) instead. You can do this using a Responder Policy.

Basically the action to redirect over SSL will be:

"HTTP/1.1 301 Moved Permanently\r\n" + "Location: https://" + HTTP.REQ.HOSTNAME + HTTP.REQ.URL.PATH + "\r\n"

Make sure to Bypass the Safety check or it will give you an Input Expression is unsafe error. Don’t worry, this is just a warning message. The Netscaler tries to resolve URLs to make sure they respond when you write an expression. In this case we are telling it to catch any URL. So since it can’t validate something general like this, it throws the expression error. Make sure to bypass the safety check to get around this.

The responder policy that calls the action by looking for non-SSL connections should be:

!CLIENT.SSL.IS_SSL

You will notice I specified a 301 redirect in my action because I want to make sure any search engine spiders index my site URL as “https://www.mywebsite.com” and not as “http://www.mywebsite.com” for SEO purposes.

You may or may not want to bind the policy globally. I only apply responder policies to vservers that need them just to be cautious.