Connect with us

Hi, what are you looking for?

Citrix NetScaler

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:


so in this box, I would type:

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:


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:

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 “” 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 ( 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 “”. 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:

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:

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

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:

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:

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:


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:


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.



  1. Daniel Ruiz

    April 11, 2012 at 6:43 AM

    Excellent guide!

    One question: If you use double factor authentication of the Reciever Site do you still need to set up Radius as primary and LDAP as secondary for the iPad to successfully enumerate the apps?

    Thank you

  2. Dan Dudas

    May 3, 2012 at 8:36 AM

    One (possible) correction: I am using session reliability for Android and iOS connections through Receiver and they work fine. Did Citrix say somewhere that they wouldn’t?

    And to answer Daniel’s comment above, yes you still need Radius as primary and LDAP as secondary in your vserver settings. Silly, I know.

  3. liam

    June 11, 2012 at 8:45 AM

    I have this setup similarly, but the problem is if the person goes to the website ( lets say) with a browser they log in and get the right desktop (we call it the General Desktop).
    If they use ICA client on Iphone/Ipad they get the other desktops we are using on the campus and the General Desktop does not show up.
    How do I setup so the ICA clients get the right desktop?

    Thanks for any help.

  4. Stephan

    November 13, 2012 at 4:44 PM

    Hi Jason,
    Great article!
    Is it possible to use the Netscaler with using the URL of the WI instead of the URL of the vserver? I would like to use the WI for all internal users and add a “gateway direct” for IP that id coming through the DMZ. If I call the WI through the DMZ WI acts in Gateway Direct mode, all others act in Direct mode. With CSG you can chose “users type in the URL of the WI” function and this works excellent. With the Netscaler I didn’t have success with this functionality. Any ideas ?

    Thanks a lot again for this wonderful blog post


  5. Jason Samuel

    November 20, 2012 at 2:09 PM


    Yes it is possible. Read through my guide after the “***UPDATE***” section toward the bottom.

  6. Jason Samuel

    November 20, 2012 at 2:15 PM

    @Dan Dudas

    Yes, under their Receiver documentation and just from previous experience:

    “Session reliability is not supported in this release. [#0276347] ”

    newer clients may have the ability though. To verify, enable it and then do a packet capture to see if there is communication on port 2598 or not.

  7. Oren

    November 22, 2012 at 3:51 PM

    Mobile receivers – Check
    Web clients – Check
    PNAgent/Receiver enterprise – not so much.

    Any idea on how to make that one work?
    It seems that the desktop receiver cannot pass the NetScaler authentication phase to get to the config.xml.

    I can make it work by turning off authentication on the NS and passing that task to the web interface server but then I lose the Smart Access functionality. This means we cannot apply policies from our XenApp farm to these sessions based on Access Gateway filters.


  8. Nicolas

    November 29, 2012 at 1:22 AM


    Do you know if the solution work with a citrix farm with Xenapp 4.6 ?

    Thank for this sharing 🙂

  9. shinatipt

    January 21, 2013 at 4:06 AM

    In the Virtual Servers > and hit Add. Give it a name, IP address
    So i want to know what does the IP address input it?

  10. Bahaa

    February 18, 2013 at 7:09 AM

    Greate Article, organized, detailed, cases, screenshots, concept, i don’t want to say to thank for that greate effort.

    but i have a question: i have deployed XenDesktop behind 3rd party hardware firewall without NetScaler, but i want to access the VMs from the internet, i have configured the NAT rule on the firewall:
    Public IP —-> WI Private IP

    can i do this without deploying NetScaler or i have to do it?
    i see posts talk about a command “altaddr” but i couldn’t apply, do u have any info about it?

    Thank you again.

  11. Dean

    March 18, 2013 at 5:29 PM

    Excellent overview, We are trying to stand up a Storefront 1.2 implementation, but the netscaler is obviously smarter than I am! Do you have a similar discussion where you have put together an environment that is accessible from internal as well as external clients using SF 1.2 and XA 6.5? Thanks!

  12. Jason Samuel

    March 19, 2013 at 4:19 PM


    Thanks Dean. I am working on a StoreFront 1.2 article right now. Should have it up soon hopefully.

  13. Pingback: How To Configure Access to iPad/Mobile Devices to Citrix Applications | Diary Of A Citrix Administrator...

  14. Alex Jones

    June 12, 2013 at 9:05 PM

    NetScaler, Access Gateway, Web Interface, StoreFront and Receiver can be customized to match your site / Company brand and theme or as your requirement. Please visit to for live demos and submit the quote for your requirement.

  15. Jamie T

    July 9, 2013 at 7:21 PM

    Great article. I do have one question. I have Xenapp and Xendesktop servers behind a netscaler. Currently I have one ZDC and one DDC as my STAs but I don’t think this is working properly. Is there a way to verify STA is setup and working properly? Should only Xenapp servers be STAs?

  16. bozorgi

    September 23, 2013 at 5:21 AM

    Great article. I do have one question. I have Xenapp and my firewall is mikrotik router RB-2011AH
    i try to set NAT on firewall
    when i connect in local there is no problem
    but when i want to connect from internet ican just access to my app but didnot run
    please help me

  17. Forrest B

    November 18, 2013 at 10:59 PM

    Thanks. We have a Netscaler 10.1 in front of a XenApp 6.5 farm. When we open apps on the iPad the app switching option on the right end of the drop down menu always shows zero and we cannot switch between apps. The Citrix demo site works as expected and the list of open apps shows in the app switch option. Also, on the home page, apps that are already open have a dot under them on iPad. For us there is no dot when we open an app. What have we not setup correctly or completely that the Citrix demo site has? Thanks Jason.

  18. Red

    July 14, 2014 at 11:52 PM

    Hi..for me its almost close to impossible to set up access for mobile devices. Everytime I try to login after creating the profiles I get a “Could not log on. Try again error”. My environment uses a NetScaler 10 with Web Interface 5.4 and I use it with XenApp 6.5 on Android devices. I also have two-factor authentication and I used this ( to configure it as I thought it was an issue with Receiver and RADIUS but still no luck. It’s really a painful process as I found many configuration guides but with different polices configured etc. I also removed RADIUS as secondary authentication and I used only LDAP but…no luck.

  19. ichayan

    April 21, 2016 at 10:34 AM

    I am trying to configure RSA SecureID two factor authentication. When people visit the website they require a passcode, but when they connect via citrix receiver app on ipad android tablet and macbook they never get prompted for a passcode and they can access published apps without two factor authentication. Please could you point me to the right direction?

Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like

Citrix Workspace

You can use FIDO2 hardware security keys plugged into your physical desktop over the Citrix HDX remoting protocol for use with virtualized Windows Desktop...


Today I would like to go over proper URL redirection when using SSL but first I would like to preface this by describing what...

Exchange 2003

A useful Exchange 2003 guide I wrote for a friend’s blog originally but I am posting it here on mine now for your viewing...


In a worst case scenario and all your web servers have failed, what do you do? You could have a standby group of servers... began in 2008 as a way for me to give back to the IT community. This website features the latest news and how-to's on enterprise mobility, security, virtualization, cloud architecture, and other technologies I work with. This website has evolved over time to become a go-to reference hub for these technologies. It receives hundreds of thousands of unique visitors from all over the world each month. More details on the About Me page.
Copyright © 2008-2023