The Citrix Access Gateway Advanced Edition (CAG integrated into an AAC Farm) presents us with a design limitation that customers must understand so that the expectation of the level of redundancy built into the solution can be met.
Having multiple CAGs in place for failover only provides you with an automated and seamless failover mechanism for Secure Access Client (SSL-VPN) connections. This is as per design of the CAGs.
There are several limitations and issues that customers must be made aware of if using the failover CAG for access to File Resources, Web Resources, Web-Based Email, and Presentation Server Applications via Web Interface. i.e. Clientless connections.
Issue 1: The Web Interface can only be configured to communicate with the FQDN of one CAG. Therefore, launching apps via Web Interface when using a different CAG will fail. The FQDN we are referring to here is highlighted in the screenshot below.
In other words, if we have a second CAG with the FQDN of remote2.mydomain.com, we can still login to the Logon Points, but we won’t be able to launch any Presentation Server applications via the Web Interface integration. The field in the screenshot above only accepts one FQDN.
So you think that it would be nice if Citrix had of written some further intelligence into the software so that the AAC passes session information to the Web Interface server so that it knows which CAG the traffic came from, and works on some sort of session persistence for each individual session. Hmmm…hold that thought for a minute, as I believe it does. I’ll explain this further shortly.
Issue 2: The integration of the Presentation Server farm into the AAC Farm configuration only allows one FQDN as well, and the association with one Web Interface server. This particular configuration at the Farm level controls Workspace Control and File Type Associations, amongst other things.
- Workapce Control – reconnects users to disconnected sessions.
- File Type Associations – You can select a file from a File Resource, a Web Resource, or Web-Based Email, and launch it with its associated Presentation Server application.
The FQDN we are referring to here is highlighted in the screenshot below.
The farm association with a single Web Interface is highlighted in the screenshot below.
Issue 1 can be overcome by creating separate Logon Points and Web Interface instances for the failover CAGs. The Web Interface instances can be filtered based on the Logon Point. However, only one Logon Point can use the default URL (https://remote.mydomain.com). Therefore, to connect to the new Logon Point users will need to use the full URL. Something like https://remote2.mydomain.com/CitrixLogonPoint/Failover, where Failover is the name of the Logon Point and remote2 is the 2nd CAG. It starts to get messy.
Regardless of this, both points raised in issue 2 will then fail to work since they are related to the AAC Farm configuration itself.
So should the Primary CAG fail, you would need to manually make two changes to enable Clientless connections to connect and launch applications:
- Change the AAC Farm config to point to a different CAG FQDN
- Change the Web Interface AAC site to point to a different CAG FQDN, but must be the same as the AAC Farm config.
The only real solution for a fully automated failover deployment is to use a Hardware Load Balancer device, such as the Citrix Netscaler, as it allows for all CAGs to be addressed using the same FQDN, as well as using the same certificate.
So this proves that using multiple CAGs for Clientless access cannot be achieved without a hardware load balancer, or does it?
Well let me end by telling you that I have found a simple solution to this problem by using a wildcard certificate. ie *.mydomain.com. A wildcard cert is more expensive than a standard web cert, but if it provides you with a level of redundancy without needing a hardware load balancer device, then it’s worth every extra dollar you pay. Obviously this solution does not offer all the features that a hardware load balancer will offer, such as a single URL access and GSLB (Global Server Load Balancing), but it does allow the users to connect to a different URL and continue working without the need for anyone in the IT Department to make any back-end changes.
So now we can use the following URLs, which represent two different CAGs:
https://remote.mydomain.com
https://remote2.mydomain.com
Both these URLs will work 100% correctly for Clientless access. The “hostname” in the FQDN we use in the configuration screenshots above are irrelevant. Despite what Citrix tells me, it seems to use the FQDN of the certificate and not the CAG.
This is working nicely for a customer who so far has deployed 3 CAGs into their AAC Farm.
Jeremy Saunders
Latest posts by Jeremy Saunders (see all)
- Best Practice for the Active Setup StubPath value - September 25, 2023
- User Profile Migration Strategy and PowerShell Script with a User Interface - August 28, 2023
- Cold Starting and/or Hydrating Your Applications To Improve Their Startup Times - June 27, 2023