Understanding CSG

[What is CSG?] [Web Interface] [Secure Gateway] [Fire wall rules] [Copyright]

This is all newbie Information. No in depth Hardcore! Links inside may lead to more complex technical documentation.

What is CSG?

Citrix Secure Gateway is a single Point of Access for all these Metaframe Servers in your Company. Best of all: it is absolutely free. It first came with Citrix Metaframe XP and consists of 3 Components:

The Citrix Secure Gateway is a SSL Proxy. It is the Component that allows access. At the same time it knows very little about our internal infrastructure. In Fact, this is good news: Someone that does not know can't tell much. It may be run on a Linux or Windows Box
The Citrix secure Ticket Authority is a database that stores all information needed to grant access. Nowadays it is built into Citrix XML Service and does no longer use IIS!
The Web interface calculating the program neighbourhood. It is a collection of Java Code. It may run on a Windows or Linux Box

How does Web Access work?

I won't talk too much about Web interface. But we need to understand how it works. OK: Our user browses to that web interface and is required to enter his user name and password. He then pushes the Logon Button and they are carried (plain Text HTTP) to the server by a HTTP PUT command. We surely want to secure our credentials, so we'll have to use HTTPS (SSL)

The Java Objects now pass this information to the Citrix Server's XMP Port. Normally we use port 80 for this, but it is very much common to change this port elsewhere, mostly to 8080.

On our Metaframe Server, XML Service Checks these Logon Credentials (mostly asks a domain controller). It than checks what applications are available for that user and passes the list to our Web Interface Server.

Our Web Interface Server calculates what Program Neighbourhood will look like and sends it to our User.

Our user now clicks an application. This is sent to the Web Interface and passed to our Metaframe Server's XML Service. The Server now checks the least busy server to provide the user with that application and passes the IP address back to the Web Interface. Our Web Interface opens template.ica and merges all information into it and passes it to that User's Client PC (the name changes to launch.ica).

This is very much like clicking any object like a .ZIP file. On Client side launch.ica is opened using the locally installed Metaframe Client. That Client extracts our Metaframe Server's IP address from that launch.ica file and connects to it using good old ICA Protocol.

There are several Problems to overcome:

ICA Protocol is not real secure
Our Client will know just internal addresses. If we use NAT we won't be able to connect (you may want to look for altaddr in Citrix Knowledge Base)
Our Client Knows at least one address of an internal Server. In Fact this is not always desired.
We need to have that many IP Addresses on our Firewall as Metaframe Servers accessable from the Internet
Firewall departments don't like to open fancy Ports like 1494 (ICA)
We need to have open port 1494 on client side as well. However, opening it inside our Company may cost some bottles of beer or our last – already grey – hair, but it will be possible. We are definitely not able to speak to each and every Internet Coffee, Hotel and Airport all over the world, so this is an issue hardly to overcome.

Citrix Secure Gateway is a, let's say, the solution for all our problems!

The Secure Gateway Solution

What about using a proxy server? My Idea is a Proxy Server that may be accessable from outside and splits all traffic to inside so we need to have just one public address. Of course we want to use a real just secure Protocol. Let’s say SSL?

Damn. We conflict with our Web Server (we had to use SSL to protect our credentials, remember?). Ok. We have a proxy that already does some encryption/decryption. After decrypting SSL it would be quite easy to send HTTP to a web server, not to a Metaframe server, right? It is easy.

Last Problem: how to decide which Metaframe server to use. One more header within our newly created protocol? Not really ideal, remember, we did not want to expose that data... Right. A Database server!

So we got our components:

Our client connects to our Secure Gateway (CSG) using Port 443. Our Secure Gateway decrypts and sends that traffic to our web interface. Web interface does authentication (described above) and, after user’s mouse click, passes a launch.ica file back to our client (again using CSG as a proxy server). But there is a difference within that launch.ica file: there is no Citrix Metaframe Server’s IP address but our CSG’s address and, in addition, there is a randomise Number, the so called Ticket: The Web interface did store Metaframe Server’s IP into the STA (Secure Ticket Authority), a database now integrated into Citrix XML Service (elder versions are ISAPI applications for Internet Explorer).

Once Again, our Client PC launches his ICA Client to open that launch.ica file. ICA Clients are able to use SSL instead of ICA Protocoll and it now uses SSL to connect to CSG. Our Client side Firewall thinks of HTTPS and permits that traffic. On CSG Traffic is decrypted and our ticket Number (together with the name of our STA) are found. So CSG asks STA for the IP of our Metaframe Server and now acts as a proxy between Client and Server.

Where to put things too?

We should not put a Server that has access to the internet, into our LAN. Therefore we create a DMZ. We put our CSG Server there. We also put our Web server there. In Fact, we use the same machine for both functions. Makes things easier and cheaper. Metaframe Servers have to be on a secure place, so we put it into our LAN. STA is a part of Metaframe Servers and also a typical LAN Component. If we use Metaframe for UNIX we will have to set up an older version of STA, a ISAPI application on any IIS inside our LAN.

What Ports do we need to open on our Firewall for CSG?

Internet to DMZ

(Any Host to CSG): 443 (nothing else to open!!!!)

DMZ Traffic

CSG to Web server: 80

DMZ to LAN:

Web server to Metaframe servers: 80*
Web server to STA: 80**
CSG to STA: 80**
CSG to Metaframe Servers: 1494

* or that port you changed your XML Port too
** Presentation Server starting version 4 uses a built in STA inside XML Service, so you'll have to change this port if you change your XML Port!

LAN to DMZ:

Nothing to open here!!!

Internet to LAN

Nothing to open here!!!

LAN to Internet

Nothing to open here!!!

Citrix offers the possibility to secure all traffic that normally uses port 80 with SSL (443). This is not really needed and I'd suggest to start unsecured. There is a 2nd possibility: use IPSec instead. You may encrypt just inside your LAN and control the Content of Citrix XML Messages.

Copyright

This Page is part of www.norz.at. Feel free to read, enjoy my publications. Maybe you like what I do and like to provide feedback to me? If you hate Mail I am able to offer a 2nd way: Donate to 24510049205, BIC: BAWAATWW, IBAN: AT381400024510049205.

If you redistribute my documentation please include my Copyright!