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

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.

Jason Samuel

Jason Samuel is a visionary product leader and trusted advisor with a proven track record of shaping strategy and driving technology innovation. With extensive expertise in enterprise end-user computing, security, cloud, automation, and virtualization technologies, Jason has become a globally recognized authority in the IT industry. His career spans consulting for hundreds of Fortune 500 enterprises across diverse business sectors worldwide, delivering cutting-edge digital solutions from Citrix, Microsoft, VMware, Amazon, Google, and NVIDIA that seamlessly balance security with exceptional user experiences.

Jason’s leadership is amplified by his dedication to knowledge-sharing as an author, speaker, podcaster, and mentor within the global IT and technology community. Recognized with numerous prestigious awards, Jason’s contributions underscore his commitment to advancing technology and empowering organizations to achieve transformative results.  Follow him on LinkedIn.