{"id":10,"date":"2008-01-04T10:34:26","date_gmt":"2008-01-04T01:34:26","guid":{"rendered":"http:\/\/www.jhouseconsulting.com\/index.php\/jhouseconsulting\/2008\/01\/04\/failover-cag-design-limitation\/"},"modified":"2008-01-04T23:55:25","modified_gmt":"2008-01-04T14:55:25","slug":"failover-cag-design-limitation","status":"publish","type":"post","link":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/2008\/01\/04\/failover-cag-design-limitation-10","title":{"rendered":"Failover CAG Design Limitation"},"content":{"rendered":"<p><a href=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-content\/uploads\/2008\/01\/cagredundancy3.PNG\" title=\"cagredundancy3.PNG\"><\/a>The Citrix Access Gateway Advanced Edition (CAG integrated\u00a0into an\u00a0AAC 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.<\/p>\n<p>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.<\/p>\n<p>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. <strong>Clientless<\/strong> connections.<!--more--><\/p>\n<p><strong>Issue 1:<\/strong> 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.<\/p>\n<p>\u00a0<a href=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-content\/uploads\/2008\/01\/cagredundancy1.PNG\" title=\"cagredundancy1.PNG\"><img decoding=\"async\" src=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-content\/uploads\/2008\/01\/cagredundancy1.PNG\" alt=\"cagredundancy1.PNG\" \/><\/a><\/p>\n<p>In other words, if we have a second CAG with the FQDN of <strong>remote2.mydomain.com<\/strong>, we can still login to the Logon Points, but we won\u2019t be able to launch any Presentation Server applications via the Web Interface integration. The field in the screenshot above only accepts one FQDN.<\/p>\n<p>So you\u00a0think that it would be\u00a0nice 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&#8230;hold that thought for a minute, as I believe it does. I&#8217;ll explain this further shortly.<\/p>\n<p><strong>Issue 2:<\/strong> 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.<\/p>\n<ul>\n<li>Workapce Control &#8211; reconnects users to disconnected sessions.<\/li>\n<li>File Type Associations &#8211; 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.<\/li>\n<\/ul>\n<p>The FQDN we are referring to here is highlighted in the screenshot below.<\/p>\n<p>\u00a0<a href=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-content\/uploads\/2008\/01\/cagredundancy2.PNG\" title=\"cagredundancy2.PNG\"><img decoding=\"async\" src=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-content\/uploads\/2008\/01\/cagredundancy2.PNG\" alt=\"cagredundancy2.PNG\" \/><\/a><\/p>\n<p>The farm association with a single Web Interface is highlighted in the screenshot below.<\/p>\n<p>\u00a0<a href=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-content\/uploads\/2008\/01\/cagredundancy3.PNG\" title=\"cagredundancy3.PNG\"><img decoding=\"async\" src=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-content\/uploads\/2008\/01\/cagredundancy3.PNG\" alt=\"cagredundancy3.PNG\" \/><\/a><\/p>\n<p><a href=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-content\/uploads\/2008\/01\/cagredundancy3.PNG\" title=\"cagredundancy3.PNG\"><\/a>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 (<a href=\"https:\/\/remote.mydomain.com\/\">https:\/\/remote.mydomain.com<\/a>). Therefore, to connect to the new Logon Point users will need to use the full URL. Something like <a href=\"https:\/\/remote2.mydomain.com\/CitrixLogonPoint\/Failover\">https:\/\/remote2.mydomain.com\/CitrixLogonPoint\/Failover<\/a>, where Failover is the name of the Logon Point and remote2 is the 2nd CAG. It starts to get messy.<\/p>\n<p>Regardless of this, both points raised in issue 2 will then fail to work since they are related to the AAC Farm configuration itself.<\/p>\n<p>So should the Primary CAG fail, you would need to manually make two changes to enable <strong>Clientless<\/strong> connections to connect and launch applications:<\/p>\n<ul>\n<li>Change the AAC Farm config to point to a different CAG FQDN<\/li>\n<li>Change the Web Interface AAC site to point to a different CAG FQDN, but must be the same as the AAC Farm config.<\/li>\n<\/ul>\n<p>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.<\/p>\n<p>So this proves that using multiple CAGs for <strong>Clientless<\/strong> access cannot be achieved without a hardware load balancer, or does it?<\/p>\n<p>Well let me end by telling you that I have found a simple solution to this problem by using a wildcard certificate. ie <strong>*.mydomain.com<\/strong>. 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\u2019s 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.<\/p>\n<p>So now we can use the following URLs, which represent two different CAGs:<br \/>\n<a href=\"https:\/\/remote.mydomain.com\/\">https:\/\/remote.mydomain.com<\/a><br \/>\n<a href=\"https:\/\/remote2.mydomain.com\/\">https:\/\/remote2.mydomain.com<\/a><\/p>\n<p>Both these URLs will work 100% correctly for <strong>Clientless<\/strong> access. The &#8220;hostname&#8221; 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.<\/p>\n<p>This is working nicely for a customer who so far has deployed 3 CAGs into their AAC Farm.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Citrix Access Gateway Advanced Edition (CAG integrated\u00a0into an\u00a0AAC 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 &#8230; <a title=\"Failover CAG Design Limitation\" class=\"read-more\" href=\"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/2008\/01\/04\/failover-cag-design-limitation-10\" aria-label=\"Read more about Failover CAG Design Limitation\">Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[9],"tags":[10,11,12],"class_list":["post-10","post","type-post","status-publish","format-standard","hentry","category-citrix-access-gateway","tag-cag","tag-failover","tag-wildcard"],"aioseo_notices":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/posts\/10","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/comments?post=10"}],"version-history":[{"count":0,"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/posts\/10\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/media?parent=10"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/categories?post=10"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jhouseconsulting.com\/jhouseconsulting\/wp-json\/wp\/v2\/tags?post=10"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}