Citrix Secure Gateway (CSG) is another great free component for Citrix customers that works in a MetaFrame Presentation Server (MPS) or MetaFrame Secure Access Manager (MSAM) environment. It allows thousands of users to access many MetaFrame servers from outside of the corporate network via a single IP address and single port while simultaneously handling the SSL or TLS encryption of the individual sessions. MetaFrame Access Suite 4.0, due out next year, will include a new version of CSG.

CSG is one of those great products that just “works.” Even when it’s playing a major role in a company, there’s not much you can see when it’s up and running which can make it hard to figure out if there’s anything that’s new. Well, let’s put it this way: Even though Secure Gateway 1.1 to 2.0 had big changes, most of the changes were under the hood. CSG 3.0 was also rewritten from the gound-up, and again most of the changes are under the hood.

So what big changes did Citrix make for CSG 3.0? First of all, they rebuilt it based on Apache. Citrix already uses Apache technology for their XTE Service which is responsible for the Session Reliability introduced in MPS 3. In the MPS 4 Technical Preview, the Secure Gateway Service is also named “Citrix XTE Server” and has still the Apache icon. Most likely Citrix used an early version of the XTE development kit to build the new Secure Gateway. Doing so provides two advantages for Citrix: They can share a development team for XTE/CSG and it will be easier to build the support for the Session Reliability through the Citrix Secure Gateway.

The Tech Preview showed a lot of things to indicate CSG’s support of Session Reliability, but the development on that part is not yet finished and therefore Session Reliability through CSG is not available in this beta version. (Besides, support for Session Reliability through the Gateway also needs development on the Web Interface and the ICA Client.)

The next big change in CSG 3.0 is the way CSG handles the client connections. Speaking in a simple way, with CSG 2.0 the ICA traffic is enveloped in SOCKS as the carrying protocol. Then, SOCKS is enveloped in SSL packages and finally send to the CSG where the procedure is reversed. Secure Gateway 3.0 now uses Citrix Common Gateway Protocol (CGP) that was introduced with the Session Reliability feature of MPS 3. This eliminates the use of SOCKS as the carrying protocol. Future ICA Clients (including the Advanced Gateway Client) will use CGP (although CSG 3.0 will continue to support SOCKS for backward compatibility with older clients). The advantage of the Citrix Common Gateway Protocol is the “built-in” Session Reliability capability and a lower bandwidth overhead as compared to SOCKS.

Have you ever wanted to use wildcards certificates for your Secure Gateway? If so, this feature is now supported with CSG 3.0. For example, if you host www.domain.com, an SSL Wildcard Certificate for *.domain.com would allow you to secure unlimited first-level subdomains.

A lot of people asked how to enable “relay mode” in Secure Gateway 2.0. The answer is that it’s not officially supported in 2.0. (Citrix claimed it broke a basic rule of security because it forwarded unauthenticated traffic.) Fortunately, relay mode is back in CSG 3.0!

When enabled, this mode will allow the gateway to accept connections without the need for a ticket from the Secure Ticket Authority (STA). This will also allow the full Program Neighborhood client to connect to the CSG without using a Citrix Web Interface or STA. (Of course from a security point of view, it’s not advisable to enable relay mode to get access from the Internet, but it might be a good solution for internal use.)

Secure Gateway 3.0 will support round-robin, load-balancing and failover of multiple Gateway servers. This is a great feature that will support highly available access solutions with MSA- or MetaFrame Presentation Server deployments. If one of or two secure proxy servers fail the Secure Gateway can still accept connections since it will route the traffic to another running secure proxy server.

Since CSG 3.0 is based on Apache, logging is already “build-in” (but has been extended for Secure Gateway.) All four log files (Access, SocksAccess, CgpAccess, Error) are available and can be automatically rotated. The access log is simply a web server log for the HTTP/S access. In addition to errors, the error log includes CSG notices (startup, shutdown) and warnings. The SocksAccess log is for the logging of clients accessing CSG with SOCKS (old clients). The last one, CgpAccess, is used for connections to the Secure Gateway using the new Citrix Common Gateway Protocol (new clients).

These logs made it easy for Citrix developers to build a report facility for Secure Gateway access. Taking it a step further, Citrix could import the logging into the Citrix summary database and put reports in the Access Suite Console (ASC) (Actually, full CSG ASC integration would be great. Maybe we’ll see this in version 4.0...?)

The Secure Gateway Management Console now has direct links to all other components: the configuration, diagnostic and the logon agent configuration. The Secure Gateway performance counter has now some additional entries like the CGP, SOCKS and SSL handshakes counters. (There are 22 more counters in the tech preview version.)

In the final version we’ll probably see links or integration to the new advanced logging feature. This will make the Management Console the central point for the Secure Gateway 3.0 and may be the first step for full MetaFrame Access Suite Console integration.

The SG Configuration now has an important new option: the deployment mode.

Both CSG 2.0 and 3.0 can work as a reverse proxy to support installations of the Web Interface and Secure Gateway on the same server using only one certificate. CSG 2.0 had some minor issues with this configuration, but these issues seem to have been solved in 3.0.

(The “Real IP” problem still exists in the tech preview and might also be in the final version. The “Real IP” problem is encountered when CSG and WI are installed on the same box with CSG working in reverse proxy mode. The problem is that IIS / WI will only detect the IP address of the server itself since all incoming the requests are funnelled through the CSG acting as the reverse proxy. If this is a problem in your environment, Sam Jacobs from IPM has written a Web Interface 3.0 modification, which is available here from my website.)

Previous versions of the Secure Ticket Authority (STA) had to be installed on an Internet Information Server (IIS) but only used an absolute minimum of server resources, even if the STA was creating 200 tickets per second. Most people wanted to choose a MetaFrame server to be their STA server, but there were issues with the STA and the Citrix XML Service sharing the same port. With MPS 4.0, the Citrix XML Service can act as the STA directly—no separate server is needed anymore.

Citrix Secure Gateway is a core component for MetaFrame Secure Access Manager. Therefore the new version of MSAM depends on the CSG functionalities to make new features possible (such as the support of “smart clients.”) The further development of the Secure Gateway is important for Citrix, since it will make MSAM more interesting for customers. I have to admit, I really have to dive into MSAM...