Do I need Citrix Secure Gateway if I have Unified Access Gateway?

Overview:

I recently had a customer ask if they could move the Citrix Secure Gateway functionality to UAG.  Their goal is to simplify infrastructure and minimize risk.

What is Citrix Secure Gateway (CSGW)?

CSGW is Citrix’s solution for publishing XenApp (ICA) to the internet wrapping all the traffic in HTTPS.  CSGW is offered as a standalone component or is included as a feature in their NetScaler solution.

From a protocol perspective with the correct configuration, it allows clients to initiate an authentication request (via HTTPS) get a session ticket and wrap all ICA traffic in the same HTTPS traffic.  It depends on Citrix’s Web Interface, Secure Ticket Authority and XML services for a complete solution.  The diagram below shows the full architecture:

Can UAG perform the same function?

Yes and no. 

Out of the box, UAG includes the ability to publish Citrix Web Interface and does not require Citrix Secure Gateway.  This is because while UAG does wrap all communications via HTTPS, it does it via a dynamic SSLVPN tunnel and the Citrix application (Citirx XenApp plugin) is unaware of the tunnel and just initiates a “direct” connection using TCP port 1494 or 2598.  This direct connection is routed through the SSLVPN tunnel and connects directly to the XenApp Server.

With this approach, UAG can perform the same function, but in a different manner.  This also only works on Windows, Mac and Linux machines.

The down side is that this only works on Windows, Mac and Linux.  Citrix offers clients for many platforms, like iPad, Android and the like.  The only supported method for wrapping ICA communications in HTTPS for those clients is to use CSGW.

Ok, can I put Citrix Secure Gateway behind UAG?

Yes and no.

CSGW performs 2 major tasks, it serves up Citrix Web Interface (HTML content) and it encapsulates ICA traffic in HTTPS (Citrix secret sauce).  You can place the Web Interface behind UAG, but the encapsulation feature does not work behind UAG.  UAG and TMG fail when they try to interpret the ICA encapsulated in HTTPS traffic.

If you have a requirement to have all web servers behind UAG, you could place the Web Interface behind UAG and keep the ICA encapsulated in HTTPS function on a different server.  This would give you SSO to the Web Interface and allow the ICA encapsulated in HTTPS traffic to work.  The following diagram shows this:

To fully understand this interaction, the following sequence diagram illustrates the component interaction:

Notice after step 9, when the user clicks the application, based on configuration of the Citrix Web Interface Secure Access Settings, the Citrix Plugin Client initiates a connection to the Citrix Secure Gateway and not the UAG server.  This works great for a passive client, where the initial login (step 1) was via a web browser.  This sequence diagram is not followed for an active client, where the login is initiated from the Citrix Plug in Client.  For Active clients, they initiate the communication directly to the Citrix Secure Gateway.

Now, imagine if the Citrix Secure Gateway was installed on the UAG server and listening on a different port or IP address.

How do I make the changes where the Citrix Plug in Client communicates with the CSGW?

Open the Citrix Web Interface and modify the Secure Access Settings, as shown below:

[

](resources/7142.image010.png)

Summary:

You can move some of the functionality to UAG, but not the most important.  You will have to run CSGW, to get ICA to HTTPS encapsulation for non-Windows / MAC / Linux devices.

Author:

Kevin Saye - Security Technical Specialist, Microsoft