Citrix Secure Gateway - DABCC · Citrix Secure Gateway provides a gateway separate from the...

Administrator�s Guide

Citrix Secure GatewayVersion 1.0

Citrix Systems, Inc.

Copyright and Trademark Notice

Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Citrix Systems, Inc.

Copyright © 2001 Citrix Systems, Inc. All rights reserved.

Citrix, ICA (Independent Computing Architecture), and WinFrame are registered trademarks, and Citrix Solutions Network, MetaFrame, MetaFrame XP, NFuse, and Program Neighborhood are trademarks of Citrix Systems, Inc. in the United States and other countries.

RSA Encryption © 1996-1997 RSA Security Inc., All Rights Reserved.

Trademark Acknowledgements

Adobe, Acrobat, and PostScript are trademarks or registered trademarks of Adobe Systems Incorporated in the U.S. and/or other countries.

Microsoft, MS, MS-DOS, Windows, Windows NT, and Windows 2000 Server are registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and other countries.

Netscape and Netscape Navigator are registered trademarks of Netscape Communications Corp. in the U.S. and other countries.

All other trademarks and registered trademarks are the property of their owners.

Document Code csgwin.v10.ag.20011214

3

Contents

Chapter 1 Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9The Need for Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Introducing the Citrix Secure Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Secures ICA Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Strong Encryption (SSL V3.0 with 128-bit encryption) . . . . . . . . . . . . . . . . . . 12Certificate-based Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Single Point of Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Ease of Installation and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Scalable and Extensible Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Event and Audit Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Citrix Secure Gateway Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14How the Components Interact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Who Should Read this Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Citrix on the World Wide Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Reader Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapter 2 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21System Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Secure Gateway Service Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Secure Ticket Authority Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22NFuse Extensions Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23ICA Client Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Supported MetaFrame Versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Recommended System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25What to Do Next. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Citrix Secure Gateway Administrator�s Guide

Chapter 3 Security Concepts and Certificate Considerations . . . . . . . . . . . . . . . . . . 27SSL, Cryptography, and Digital Certificates 101 . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Secure Sockets Layer (SSL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Certificates and Certificate Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Certificates Required to Deploy Citrix Secure Gateway. . . . . . . . . . . . . . . . . . . . . 33Types Of Digital Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Certificates Required Between ICA Clients and a Secure Web Server . . . . . . 34Certificates Required Between ICA Clients and the Secure Gateway Server . 35Certificates Required for a Fully Secured Installation . . . . . . . . . . . . . . . . . . . 36

How Do I Get Certificates? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37If Your Organization is its own Certificate Authority. . . . . . . . . . . . . . . . . . . . 37If Your Organization is not its own Certificate Authority. . . . . . . . . . . . . . . . . 37

Obtaining a Root Certificate from a CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38What To Do Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapter 4 Installing Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Server Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Obtaining a Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Installing the Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Server Certificates: Tips and Cautions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Root Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Installing Root Certificates on the ICA Client Device . . . . . . . . . . . . . . . . . . . 44Installing Root Certificates on an NFuse Web Server. . . . . . . . . . . . . . . . . . . . 44

What To Do Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Contents 5

Chapter 5 Installing and Configuring Citrix Secure Gateway. . . . . . . . . . . . . . . . . . . 45Before You Begin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Compile the Following Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Installing Secure Gateway Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Accessing Context-sensitive Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Installing the Secure Ticket Authority (STA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Configuring the Secure Ticket Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Changing the STA�s Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Installing the Secure Gateway Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Configuring the Secure Gateway Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Starting the Secure Gateway Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Changing Secure Gateway Configuration Settings . . . . . . . . . . . . . . . . . . . . . . 56

Installing NFuse Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Configuring NFuse Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Changing Configuration Settings for NFuse Extensions. . . . . . . . . . . . . . . . . . 60Testing the Sample Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Testing the Citrix Secure Gateway Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Uninstalling Secure Gateway Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63What To Do Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 6 Advanced Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Errors and Error Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Citrix Secure Gateway Error Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Conventions For Log File Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Configuring Logging Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Accessing Performance Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Planning For High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Load Balancing A Secure Gateway Server Array. . . . . . . . . . . . . . . . . . . . . . . 74Using Multiple STAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Connection Keepalive Values on the Secure Gateway server . . . . . . . . . . . . . 76

Securing the Secure Gateway Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Deploy the Citrix Secure Gateway in the DMZ . . . . . . . . . . . . . . . . . . . . . . . . 78Restricting Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Follow Microsoft and Third Party Security Guidelines . . . . . . . . . . . . . . . . . . 79


Chapter 7 Troubleshooting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Compiling Secure Gateway Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Troubleshooting the Secure Gateway server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Checking the Error Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Checking Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Checking for Port Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Checking Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Checking Configuration Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Checking for Start-up Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Troubleshooting the Secure Ticket Authority (STA) . . . . . . . . . . . . . . . . . . . . . . . 88Checking the Error Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Checking Directory Access Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Ensuring the World Wide Web Publishing Service is Functional . . . . . . . . . . 89Ensuring STA System Files are Installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Checking Configuration Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Troubleshooting the NFuse Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Ensuring that the World Wide Web Publishing Service is Functional . . . . . . . 91Checking Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Ensuring that the NFuse Web site is Functional . . . . . . . . . . . . . . . . . . . . . . . . 92Checking Configuration Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Checking Configuration Values in Template.ica . . . . . . . . . . . . . . . . . . . . . . . 95

Troubleshooting the ICA Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Checking for High Encryption Pack on Client Device . . . . . . . . . . . . . . . . . . . 98Checking the ICA Client Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Checking the Root Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Checking Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101If You Are Still Unable to Resolve the Problem � . . . . . . . . . . . . . . . . . . . . 101

Contents 7

Appendix A Using Citrix Secure Gateway In Relay Mode . . . . . . . . . . . . . . . . . . . . 103Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Normal Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Relay Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Relay Mode Explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Why You Should Use Relay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106When You Should Not Use Relay Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106When You Should Use Relay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Before You Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Compile the Following Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Install Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Installing the Secure Gateway Service in Relay Mode . . . . . . . . . . . . . . . . . . . . . 109Configuring the Secure Gateway Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Start the Secure Gateway Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Changing Secure Gateway Configuration Settings . . . . . . . . . . . . . . . . . . . . . 114Modify the APPSRV.INI File on ICA Client Devices . . . . . . . . . . . . . . . . . . 115Using NFuse with Relay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Testing Relay Mode Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Appendix B Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Secure Gateway Service Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Status Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Fatal Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Service Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Informational Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Secure Ticket Authority Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Fatal Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Application Error Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Informational Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Appendix C Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

C H A P T E R 1

Welcome

Welcome to Citrix Secure Gateway, Version 1.0.

The Citrix Secure Gateway, also referred to as Secure Gateway, is designed to secure all Citrix Independent Computing Architecture (ICA®) traffic traveling across the Internet between MetaFrame servers and Secure Socket Layer (SSL)-enabled ICA Client workstations, making firewall traversal easier, providing heightened security with SSL encryption, simplifying deployment, and enabling tight integration with Citrix NFuse� application portal software.

The Secure Gateway is an enterprise wide solution that protects a customer�s investment in Citrix MetaFrame infrastructure and business applications. It is completely transparent to both application programs and network devices eliminating the need for any program modifications or equipment upgrades.

The Secure Gateway provides a single point of entry, and secures access to your Citrix server farm(s). The Secure Gateway consists of the following components:

Secure Gateway Service. A Windows service that runs on a Windows 2000 server.

Secure Ticket Authority (STA). An ISAPI DLL, that serves as a ticketing authority. The STA generates and validates �tickets� for access to MetaFrame resources.

NFuse Extensions. NFuse specific extensions that enable an NFuse Web server to support the Citrix Secure Gateway.


This chapter is an overview of the capabilities and components of the Secure Gateway. It includes the following topics:

� An overview of why security is necessary for remote access to Citrix servers

� A high-level description of the Secure Gateway

� A list of the features provided by the Secure Gateway

Important See the Readme.txt file in the root directory of the Citrix Secure Gateway distribution kit. This file contains important information that includes last-minute documentation updates and corrections.

The Need for SecurityProductivity of the workforce can be substantially increased by providing remote access to internal, corporate network resources. Employees, customers, and partners can access information, and corporate network resources from their homes, hotels, remote offices, Internet kiosks, and airport lounges.

Today, enterprises rely more and more on global networks, linking branch offices, telecommuters, road warriors, and partners. However, the high cost of maintaining and implementing private leased lines is often very prohibitive. Using cost-effective public networks − such as the Internet − is a compelling solution to this issue.

Any enterprise that relies on the Internet for connectivity must contend with security issues. Despite the enthusiasm for worldwide business communications, corporations must still be assured that they can protect confidential data from prying eyes as it travels through a global network. Citrix Secure Gateway allows enterprises using Citrix MetaFrame to securely transport ICA data over the Internet, using standards-based security technology.

Chapter 1 Welcome 11

Introducing the Citrix Secure GatewayThe Secure Gateway is a secure Internet gateway for ICA data travelling into and out of a MetaFrame enabled corporate environment over existing public networks, such as the Internet or, in some cases, through a corporate WAN. Whether the Secure Gateway is used for internal or remote access, this service transparently encrypts and authenticates all ICA connections to protect against eavesdropping and data tampering.

� The Secure Gateway safely and easily extends access to Citrix server farms over the Internet to remote workers and telecommuters in a simplified, cost effective and secure manner.

� The Secure Gateway leverages existing Citrix technologies, and security infrastructure to provide an ICA specific security layer to protect Citrix client-server communications on your network.

� The Secure Gateway works with Citrix NFuse to provide a single, secure, encrypted point of access through the Internet, to Citrix servers on internal corporate networks. This means office workers can access corporate information remotely, without compromising network security, from anywhere in the world, from any device, and at all times.

� The Secure Gateway can also operate in a corporate environment to secure internal data communications on a LAN or WAN.


Features and BenefitsCitrix Secure Gateway provides a gateway separate from the MetaFrame servers, and overcomes problems with firewall traversal by using a widely accepted port for ICA data. The Secure Gateway permits users authenticated by NFuse to access MetaFrame resources on the internal network, and provides a secure, encrypted tunnel for client-server communications. Citrix Secure Gateway has the following features:

Secures ICA TrafficCitrix Secure Gateway is specifically designed to secure ICA traffic in MetaFrame environments using SSL.

Strong Encryption (SSL V3.0 with 128-bit encryption)Citrix Secure Gateway delivers improved security by encrypting the user�s ICA sessions using SSL V3.0 with 128-bit encryption.

Certificate-based SecurityStandard PKI (Public Key Infrastructure) technology is used as a framework and trust infrastructure for authentication and authorization.

AuthenticationCitrix Secure Gateway provides authentication of users attempting to establish network connections to Citrix servers through an NFuse Web portal. The authentication process is further secured by implementing a secure NFuse Web server using HTTPS (HTTP over SSL). Use of third party security solutions, such as RSA SecurID or smart cards, can also be used in conjunction with NFuse, to further secure the enterprise network.

AuthorizationAuthorization takes place when the Secure Gateway confirms that the user has been authenticated by NFuse. The authorization process is entirely transparent to the user.

Single Point of EntryThe need to publish the address of every Citrix server is eliminated and certificate management on the server is simplified. This allows for a single point of encryption and access into the Citrix servers.


The Secure Gateway provides a gateway separate from the MetaFrame servers, and overcomes problems with firewall traversal by using a widely accepted port, typically 443, for ICA traffic through firewalls.

Ease of Installation and ManagementIntegrating the Citrix Secure Gateway into an existing Citrix server environment is relatively quick and simple, and requires minimal configuration, significantly reducing time and management costs.

Scalable and Extensible SolutionA single Secure Gateway server and Secure Ticket Authority deployment in a small corporate site can easily support 500 or more users. Medium to large sites catering to thousands of users can be supported using multiple load-balanced Secure Gateway servers. Citrix Secure Gateway components do not require any special hardware devices or network equipment upgrades.

Event and Audit Logging Critical and fatal system events are logged to the application section of the Windows event log. Also, a complete record of network connection attempts to the Secure Gateway can be retrieved from the audit log. This log file provides administrators with a record of systems events, and facilitates diagnosis of system problems.


Citrix Secure Gateway ComponentsIn order to secure traffic coming in over the Internet, the Secure Gateway is installed in the DMZ (demilitarized zone) as a security perimeter that protects MetaFrame resources and applications on the corporate Intranet. Citrix Secure Gateway involves the interaction of five network components:

� A Citrix MetaFrame server farm

� A Secure Gateway server

� A Citrix NFuse enabled Microsoft IIS 5.0 Web server

� A Secure Ticket Authority (STA) server

� A client device with an SSL-enabled ICA Client, Version 6.20 or higher, installed.


How the Components InteractA typical Secure Gateway configuration is shown below to illustrate how the various components interact to provide security.

The following communications take place between Citrix Secure Gateway components before a secure connection is established.

1. A remote user launches a Web browser and connects to an NFuse Web server on port 80 (HTTP), or port 443 (HTTPS).

The NFuse Web portal requires the user to authenticate using valid user credentials.

2. NFuse uses the user credentials to contact the Citrix XML Service, on port 80, running on a MetaFrame server and obtains a list of applications that the user is authorized to access.

NFuse populates the Web portal page with the list of published applications that the user is authorized to access. The communications so far are the normal sequence of events that occur when an NFuse Web server is deployed to provide ICA Client users with access to published applications.

3. When the user clicks on a link for a published application, NFuse sends the IP address for the requested MetaFrame server to the STA and requests a Secure Gateway ticket for the user. The STA saves the IP address and issues the requested Secure Gateway ticket to NFuse.


4. NFuse generates an ICA file, containing the ticket issued by the STA, and then sends it to the client browser. Note that the ICA file generated by NFuse only contains the IP address of the Secure Gateway server. The address of the MetaFrame server(s) that the ICA Client eventually connects to is never exposed.

5. The browser passes the ICA file to the ICA Client, which launches an SSL connection to the Secure Gateway server. Initial SSL handshaking is performed to establish the identity of the Secure Gateway server.

6. The Secure Gateway server accepts the ticket from the ICA Client and uses information contained in the Secure Gateway ticket to identify and contact the STA for ticket validation.

If the STA is able to validate the ticket, it returns the IP address of the MetaFrame server on which the requested application resides. If the ticket is invalid, or has expired, the STA informs the Secure Gateway server, and an error message is displayed on the ICA Client device.

7. On receipt of the IP address for the MetaFrame server, the Secure Gateway server establishes an ICA connection to the MetaFrame server. After the ICA connection is established, the Secure Gateway server monitors ICA data flowing through the connection, and encrypts and decrypts client-server communications.

Note Firewalls shown in illustrations throughout this document are optional, but are typically used by organizations to improve security.


Who Should Read this GuideThis Administrator�s Guide describes the Citrix Secure Gateway software. The intended audience for this guide is experienced network administrators who are responsible for maintaining network security. This guide is not intended for users of the network. This guide assumes knowledge of:

� System administration

� Networking and security technologies

� Microsoft Windows 2000 Server

� Microsoft IIS 5.0

� Internet protocols (IP, TCP, and so forth)

� Citrix MetaFrame XP for Windows Servers or later

� Citrix NFuse 1.51or later

� Citrix ICA Clients, Version 6.20 or later

Use this guide in conjunction with the:

� MetaFrame XP Administrator�s Guide

� NFuse Administrator�s Guide

� Citrix ICA Client Administrator�s Guides, Version 6.20 or later

Task For more Information see ...

Learn more about MetaFrame XP, NFuse, and ICA Clients

The Citrix Knowledgebase at http://knowledgebase.citrix.com/

Digital certificates and certificate installation �Security Concepts and Certificate Considerations� on page 27; and �Installing Certificates� on page 39

Installation of Citrix Secure Gateway components

�Installing and Configuring Citrix Secure Gateway� on page 45

Citrix Secure Gateway Performance Counters and Error Logs

�Advanced Concepts� on page 65

General recommendations about using network components such as load balancers, SSL accelerator cards, firewalls, and so on


Ensuring High Availability of Citrix Secure Gateway



For further information on topics discussed in this document, visithttp://www.citrix.com/.

Document Conventions Citrix documentation uses the following typographic conventions for menus, commands, keyboard keys, and items in the program interface:

Troubleshooting a Secure Gateway deployment

�Troubleshooting Information� on page 81

Installing and Using Citrix Secure Gateway in Relay Mode

�Using Citrix Secure Gateway In Relay Mode� on page 103

Getting more information on error messages �Error Messages� on page 119

Glossary of terms specific to Citrix Secure Gateway

�Glossary� on page 131

Task For more Information see ...

Convention Meaning

Boldface Commands, names of interface items such as text boxes and option buttons, and user input.

Italics Placeholders for information or parameters that you provide. For example, filename in a procedure means you type the actual name of a file. Italics also are used for new terms and the titles of books.

UPPERCASE Keyboard keys, such as CTRL for the Control key and F2 for the function key that is labeled F2.

Monospace Text displayed at a command prompt or in a text file.

%SystemRoot% The Windows system directory, which can be WTSRV, WINNT, WINDOWS, or other name specified when Windows is installed.

{ braces } A series of items, one of which is required in command statements. For example, { yes | no } means you must type yes or no. Do not type the braces themselves.

[ brackets ] Optional items in command statements. For example, [/ping] means that you can type /ping with the command. Do not type the brackets themselves.


Citrix on the World Wide WebThe Citrix Web site, at http://www.citrix.com/, offers a variety of information and services for Citrix customers and users. From the Citrix home page, you can access Citrix online Technical Support Services and other information designed to assist MetaFrame XP administrators, including the following:

� Citrix Product Documentation Library containing the latest documentation for all Citrix products (at http://www.citrix.com/support; select Product Documentation).

� Downloadable Citrix ICA Clients (at http://www.citrix.com/download).

� Program information on Citrix Preferred Support Services options.

� An FTP server containing the latest service packs, hotfixes, utilities, and product literature for download.

� An online Solution Knowledgebase containing an extensive collection of application notes, technical articles, troubleshooting tips, and white papers.

� Interactive online Solution Forums for discussion of technical issues with other users.

� Frequently Asked Questions pages with answers to common technical and troubleshooting questions.

� Information about programs and courseware for Citrix training and certifications.

� Contact information for Citrix headquarters, including worldwide, European, Asia Pacific, and Japan headquarters.

� The Citrix Developer Network (CDN) at http://www.citrix.com/cdn. This new, open enrollment membership program provides access to developer tool kits, technical information, and test programs for software and hardware vendors, system integrators, ICA licensees, and corporate IT developers who incorporate Citrix server-based computing solutions into their products.

| (vertical bar) A separator between items in braces or brackets in command statements. For example, { /hold | /release | /delete } means you type /hold or/release or /delete.

� (ellipsis) You can repeat the previous item or items in command statements. For example, /route:devicename[,�] means you can type additional devicenames separated by commas.

! Step-by-step procedural instructions.

Convention Meaning


Reader CommentsWe strive to provide accurate, clear, complete, and usable documentation for Citrix products. If you have any comments, corrections, or suggestions for improving our documentation, we want to hear from you.

You can send e-mail to the documentation author at [email protected]. Please include the product name and version number, and the title of the document in your message.

C H A P T E R 2

System Requirements

This chapter describes the pre-installation requirements for Citrix Secure Gateway and provides general guidelines for configuring the server hardware required for a Secure Gateway implementation.

This chapter contains the following topics:

� System Requirements, page 22

� Recommended System Configuration, page 25

� What to Do Next, page 26


System RequirementsFor optimal performance, plan the hardware and Internet connectivity of the Citrix Secure Gateway to meet the expected load. To use the Citrix Secure Gateway, you need to keep the following in mind:

Secure Gateway Service RequirementsThe Secure Gateway Service is a Windows service and must be installed on a Windows 2000 Server. Review the following requirements to ensure that your server environment meets the installation prerequisites.

Secure Ticket Authority RequirementsThe Secure Ticket Authority can be installed on a standalone PC running Windows 2000 Server. Review the following requirements to ensure that your server environment meets the installation prerequisites.

Server Hardware Server Software

Recommended minimum requirements for Windows 2000 Server. Refer to the Windows 2000 Server product documentation, or see the Microsoft Web site for more information.

Microsoft Windows 2000 Server with Service Pack 2 or later. The latest Service Pack is always recommended.

256MB of RAM

Additional 150MB of available hard disk space

Network Interface Card (NIC)




256MB of RAM Internet Information Services (IIS) 5.0, installed as default on Windows 2000 servers.

Additional 150MB of available hard disk space

Network Interface Card (NIC)

Chapter 2 System Requirements 23

NFuse Extensions RequirementsAt the time of this release, the current shipping version of Citrix NFuse is Version 1.6.

NFuse versions 1.51 and 1.6 do not feature built-in support for the Citrix Secure Gateway for Windows, Version 1.0. If you are using one of these versions of NFuse, you must install NFuse Extensions on your NFuse Web server to enable support for Citrix Secure Gateway.

Future versions of NFuse will natively support the Citrix Secure Gateway. For information on how to configure forthcoming releases of NFuse for use with the Citrix Secure Gateway, please refer to the NFuse Administrator�s Guide appropriate for your version of NFuse.

Important If your Web server is running a version of NFuse software released after NFuse 1.6, refer to the NFuse Administrator�s Guide to check the level of support for Citrix Secure Gateway. You may not need to install NFuse Extensions on your NFuse Web server.




Network Interface Card (NIC) IIS 5.0, installed as default on Windows 2000 server

NFuse versions 1.51 or 1.6 only.


ICA Client Requirements

Important Citrix ICA Clients, for 32-bit Windows, Java, Macintosh, and Linux platforms, Version 6.20 or later, are compatible with Citrix Secure Gateway. ICA Client software is available for download from the Citrix Download site,http://www.citrix.com/download.

Supported MetaFrame VersionsTo work with Citrix Secure Gateway, and NFuse by association, your MetaFrame servers must meet the following requirements:

Citrix Secure Gateway operates with these MetaFrame versions on all of their supported platforms. For a list of supported platforms, see the MetaFrame XP Administrator�s Guide.

Hardware Software

Consult your Citrix ICA Client, Version 6.20 or later, documentation.

SSL enabled Citrix ICA Client (Version 6.20 or later) software.

Network Interface Card (NIC) A Web browser. Consult the Citrix ICA Client, Version 6.20 or later, documentation appropriate for the OS you are using

Appropriate mechanism for installing root certificates. Consult the Citrix ICA Client, Version 6.20 or later, documentation appropriate for the OS you are using.


Consult your MetaFrame documentation. Windows NT Server 4.0, Terminal Server Edition with Service Pack 5 or later.−or−Windows 2000 Server Family

MetaFrame XP Application Server for Windows Version 1.0 or higher.−or−Citrix MetaFrame for UNIX Operating Systems Version 1.1

Chapter 2 System Requirements 25

Recommended System ConfigurationCitrix Secure Gateway does not require specialized hardware. Illustrated below is the recommended deployment scenario for Citrix Secure Gateway.

o

In this configuration, a Secure Gateway server and a secure NFuse Web server are installed in the DMZ. The Secure Ticket Authority (STA) is deployed behind an internal firewall on the Intranet.

The external firewall has port 443 open to allow SSL connections through to the NFuse server and the Secure Gateway server.

The internal firewall has port 1494 open, between specific IP addresses, to allow connections through to the MetaFrame server(s) from the Secure Gateway server. Port 80 is also open, between specific IP addresses, on the internal firewall to allow communications between the Secure Gateway, NFuse, the Citrix XML Service, and the STA.


What to Do NextNext, you must plan how you will deploy SSL to secure communications in your Citrix Secure Gateway environment, and obtain the appropriate digital certificates to do so. For information, see �Security Concepts and Certificate Considerations� on page 27.

C H A P T E R 3

Security Concepts and Certificate Considerations

This chapter provides conceptual information about the security technologies used in the Citrix Secure Gateway solution, helps you identify the number and type of certificates you will require, and helps you decide how and where to obtain them.


� SSL, Cryptography, and Digital Certificates 101, page 28

� Certificates Required to Deploy Citrix Secure Gateway, page 33

� How Do I Get Certificates?, page 37

� Obtaining a Root Certificate from a CA, page 38

� What To Do Next, page 38


SSL, Cryptography, and Digital Certificates 101This section is intended for users who are unfamiliar with SSL and the concepts of cryptography on which SSL is based. The section introduces the SSL protocol and provides an overview of cryptography and Public Key Infrastructure (PKI).

Secure Sockets Layer (SSL)The Citrix Secure Gateway uses the industry-standard SSL V3.0 protocol to establish secure connections between ICA Clients and the Secure Gateway server.

The SSL protocol allows sensitive data to be transmitted over an insecure network, like the Internet, by providing the following important security features:

� Authentication. A client can determine a server�s identity and be certain that the server is not an impostor. Optionally, a server can also authenticate the identity of the client requesting connections.

� Privacy. Data passed between the client and server is encrypted so that if a third party intercepts their messages, it will not be able to unscramble the data.

� Integrity. The recipient of encrypted data will know if a third party has corrupted or modified that data.

SSL comes in two strengths, 40-bit and 128-bit, that define the length of the session key generated by every encrypted data exchange. The longer the key, the more difficult it is to break the encryption code. Most browsers support 40-bit SSL sessions, and the latest browsers, including Internet Explorer and Netscape Communicator, enable users to encrypt transactions in 128- bit sessions − many orders of magnitude stronger than 40-bit sessions.

Relative to these strengths, using 128-bit SSL sessions is similar to sending or storing your data inside a high quality safe, compared to 40-bit which is similar to using a paper envelope to protect your data. In other words, 128-bits is considerably more secure than 40.

Important Citrix Secure Gateway supports 128-bit encryption only.

Chapter 3 Security Concepts and Certificate Considerations 29

CryptographySSL uses cryptography to secure communications. Cryptography provides the ability to encode messages to ensure confidentiality. Cryptography is also used to authenticate the identity of a message source and to ensure the integrity of its contents.

A message is sent using a secret code, called a cipher. The cipher scrambles the message so that it cannot be understood by anyone other than the sender and receiver. Only the receiver who has the secret code can decipher the original message, thus ensuring confidentiality.

Cryptography also allows the sender to include special information in the message that only the sender and receiver know. When the receiver sees this special information, they know that the message is authentic.

Cryptography also ensures that the contents of a message have not been altered. To do this, the sender includes a cryptographic operation called a hash function in the message. A hash function is a mathematical representation of the information, similar to the checksums found in communication protocols. When the data arrives at its destination, the receiver calculates the hash function. If the receiver�s hash function value is the same as the sender�s, then the integrity of the message is assured.

Types of CryptographyThere are two main types of cryptography:

� Secret key cryptography

� Public key cryptography

Secret key cryptography is also known as Symmetric Key Cryptography. With this type of cryptography, both the sender and the receiver know the same secret code, called the key. Messages are scrambled by the sender using the key, and unscrambled by the receiver using the same key.

This method works well if you are communicating with only a limited number of people, but it becomes impractical to exchange secret keys with large numbers of people. In addition, there is also the problem of how you communicate the secret key securely.

Public key cryptography, also called asymmetric encryption, uses a pair of keys for encryption and decryption. With public-key cryptography, keys work in pairs of matched public and private keys.


In cryptographic systems, the term key refers to a numerical value used by an algorithm to alter information, making that information secure and visible only to individuals who have the corresponding key to recover the information. The public key can be freely distributed without compromising the private key, which must be kept secret by its owner. Since these keys only work as a pair, an encrypted operation initiated with the public key can only be decrypted with the corresponding private key, and vice-versa. The following example illustrates how public key cryptography works:

1. Ann wants to communicate secretly with Bill. Ann encrypts her message using Bill�s public key (which Bill has made available to everyone) and Ann sends the scrambled message to Bill.

2. When Bill receives the message he uses his private key to unscramble the message so that the message can be read.

3. When Bill sends a reply to Ann, he scrambles the message using Ann�s public key.

4. When Ann receives Bill�s reply, she uses her private key to unscramble his message.

Public key cryptography has a major advantage over secret key cryptography�there is no need to communicate secret keys up front. Provided the private key is kept secret, confidential communication is possible using the public keys.

Combining Public Key and Secret Key Cryptography. The main disadvantage of public key cryptography is that the process of encrypting a message, using the very large keys common to PKI, can cause performance problems on all but the most powerful computer systems. For this reason, public key and secret key cryptography are often combined. The following example illustrates how this works:

1. Bill wants to communicate secretly with Ann, so he obtains Ann�s public key. He also generates random numbers that he will use just for this session, known as a session key.

2. Bill uses Ann�s public key to scramble the session key.

3. Bill sends the scrambled message and the scrambled session key to Ann.

4. Ann uses her private key to unscramble Bill�s message and extract the session key.

Once Bill and Ann have successfully exchanged the session key, they no longer need public key cryptography�communication can take place using just the session key. In other words, public key encryption is used to send the secret key then, once the secret key has been exchanged, communication takes place using secret key encryption.


This solution offers the advantages of both methods�it provides the speed of secret key encryption and the security of public key encryption.

Certificates and Certificate AuthoritiesBut wait a minute, how can Ann be sure that Bill is who he says he is, and not an impostor? When Ann distributes her public key, Bill needs some assurance that Ann is who she says she is.

The ISO X.509 protocol defines a mechanism called a certificate that contains a user�s public key that has been signed by a trusted entity called a Certificate Authority (CA).

Certificates contain information used to establish identities over a network, in a process called authentication. Like a driver�s licence, a passport or other forms of personal identification, certificates enable servers and clients to authenticate each other before establishing a secure connection.

Now when Ann receives a message from Bill, or vice-versa, the locally stored information about the CA that issued the certificate can be used to verify that it did indeed issue the certificate. This information is a copy of the CA�s own certificate and is referred to as a root certificate.

Certificates generally have a common format, usually based on ITU standards. The certificate contains information that includes the:

� Issuer�this is the organization that issues the certificates.

� Subject�the party that is identified by the certificate

� Period of validity�the certificate�s start date and expiration date.

� Public key�the subject�s public key used to encrypt data.

� Issuer's signature�the CA digitally signs the certificate to guarantee its authenticity.

A number of companies and organizations currently act as Certificate Authorities, including VeriSign, Baltimore, Entrust, and their affiliates.


Certificate Revocation ListsFrom time to time, CAs issue Certificate Revocation Lists (CRLs). CRLs contain information about certificates that can no longer be trusted�for example, because the private key has been compromised, or the certificate has expired and a new one is in use. Therefore, to trust a public key, you must also ensure that its certificate has not been revoked.

For example, suppose the user name associated with a key is �Ann Rigby, CIO, XYZ Corp.� If Ann were fired, her company would not want her to be able to sign messages with that key, and therefore the company would place the certificate on a CRL.


Certificates Required to Deploy Citrix Secure GatewayTypes Of Digital CertificatesIt is important to understand the sort of certificates you will need before you deploy the Citrix Secure Gateway. You must also determine the number and type of digital certificates required, and select a suitable source to obtain these from.

Obtaining a digital certificate can be an involved process, therefore it is important to accurately estimate how many digital certificates you will require up-front, and to allow enough time for the process of obtaining the certificates.

There are two main types of digital certificates used in a Citrix Secure Gateway deployment:

� Server certificate

This identifies a specific machine−for example, a Secure Gateway server. The type of digital certificate that is required by the Secure Gateway is called a Server Certificate.

� Root certificate

This identifies the CA that signed the server certificate. The root certificate belongs to the CA. The type of digital certificate required by an ICA Client is called a Root Certificate.

To establish an SSL connection you require a server certificate at one end of the connection and a root certificate of the CA that issued the server certificate, at the other end.

A server certificate must be installed on every Secure Gateway server and, if you are deploying a secure Web solution, on the NFuse Web server as well.

A root certificate must be installed on the ICA Client device. Typically, if the client device is using a 32-bit Windows Operating System (Windows 95, Windows 98, Windows NT, or Windows 2000) root certificates are automatically available for several public CAs. Root certificates also must be present on the Secure Gateway server, and on the secure NFuse Web server to enable validation of the respective server certificate(s).

Note For root certificate availability on client platforms other than 32-bit Windows, please refer to the ICA Client Administrator�s Guide appropriate to the client platform you are running.


Certificates Required Between ICA Clients and a Secure Web ServerA secure Web server is recommended as part of your Secure Gateway environment. If you are using NFuse, the security of the connection between the client and NFuse is dependant on the abilities and configuration of the NFuse Web Server and the client�s Web browser. The majority of Web browsers and Web servers support SSL, but configuration is required before the connection is secured. To do this, you require:

� A root certificate on the client, which can verify the signature of the CA on the server certificate. The root certificate is usually part of the Web browser itself, so there is no need to obtain and install a root certificate here.

� A server certificate on the NFuse Web server. A root certificate is also required to verify the signature of the CA on the server certificate. Windows 2000 ships with an exhaustive list of built-in trusted root authorities, and you might not need to install one if your server certificate is issued by one of these trusted root authorities. For further information about installing a server certificate, see your Web server documentation.

The illustration above shows the server and root certificates required to secure communications between client workstations and an NFuse Web server.


Certificates Required Between ICA Clients and the Secure Gateway ServerIn a Secure Gateway deployment, SSL is used to secure the connection between the ICA Clients and the Secure Gateway server. To establish a secure connection between the two, you will require:

� A root certificate on the client that can verify the signature of the CA on the server certificate. The root certificate is usually part of the Web browser itself, so there is no need to obtain and install a root certificate here.

� A server certificate on the Secure Gateway server

The illustration above shows the certificates required to secure communications between an ICA Client and a Secure Gateway server.


Certificates Required for a Fully Secured InstallationTo use SSL to fully secure all communications in your Secure Gateway installation, you must:

� Deploy an SSL-capable Web browser and SSL-capable Web server

� Use SSL to secure communications between the SSL-capable Web browser on the ICA Client device and the NFuse Web server

� Use SSL to secure communications between SSL-enabled ICA Clients and the Secure Gateway server

The illustration above shows the certificates required to secure communications at all the critical points in your Secure Gateway installation.


How Do I Get Certificates?Once you have identified the number and type of certificates required for your Secure Gateway deployment, you must decide where to obtain the certificates. Where you choose to obtain certificates will depend on a number of factors, including:

� Whether your organization is a Certificate Authority (CA). This is likely to be the case only in very large corporations.

� Whether your organization has already established a business relationship with a public CA.

� The fact that the Windows operating system includes support for many public Certificate Authorities.

� The cost of certificates, the reputation of a particular public CA, and so on.

If Your Organization is its own Certificate AuthorityIf your organization is running its own CA, you must determine whether it is appropriate to use your company�s certificates for the purpose of securing communications in your Secure Gateway installation. Citrix recommends that you contact your Corporate Security department to discuss this, and to get further instructions on how to obtain certificates.

If you are unsure if your organization is a Certificate Authority, contact your Corporate Security department.

If Your Organization is not its own Certificate AuthorityIf your organization is not running its own CA, you need to obtain your certificates from a public CA, such as VeriSign.

Obtaining a digital certificate from a public CA involves a verification process in which:

� Your organization provides corporate information so that the CA can verify that your organization is who it claims to be. This may involve other departments in your organization, such as Accounting, to provide Letters of Incorporation or similar legal documents.

� Individuals with the appropriate authority in your organization are required to sign legal agreements provided by the CA.

� The CA verifies your organization as a purchaser; therefore your Purchasing department is likely to be involved.

� You provide the CA with contact details of suitable individuals who they can call if there are queries.


Therefore, obtaining a digital certificate from a public CA can be an involved process.

Important Your server�s Fully Qualified Domain Name (FQDN) is encoded in the server certificate. If you require an additional certificate for another server, you will have to repeat the CA�s verification process. You cannot obtain a certificate for one server and use it on another. Therefore, it is important to decide at the start how many server certificates you require and to allow enough time for the process of obtaining these.

Obtaining a Root Certificate from a CASupport for most trusted root authorities is already built into the Windows operating system, and Internet Explorer. Therefore, there is no need to obtain and install root certificates on the client or on the NFuse Web server if you are using these CAs. However, if you decide to use a different CA, you will need to obtain and install the root certificates yourself.

CAs tend to assume that you already have the appropriate root certificates (this is because most Web browsers have root certificates built-in as standard) so you will need to specifically request the root certificate. Also, there are different types of root certificates−for example, VeriSign has approximately 12 root certificates that they use for different purposes−so ensure that you obtain the correct root certificate from the CA.

What To Do NextAfter you have planned the Citrix Secure Gateway deployment, and have obtained the appropriate digital certificates, you need to install the certificates. See �Installing Cer-tificates� on page 39 for more information.

C H A P T E R 4

Installing Certificates

This chapter discusses briefly the process used to obtain and install certificates required to use the Citrix Secure Gateway solution.


� Server Certificates, page 40

� Root Certificates, page 44



Server CertificatesYour organization�s security expert should have a procedure for obtaining server certificates. Instructions for generating server certificates using various Web server products are available from the Web sites of popular Certificate Authorities such as Verisign and others.

Important Several CAs offer Test Server Certificates for a limited trial period. It might be expedient to obtain a Test Certificate to test Citrix Secure Gateway before deploying it in a Production environment. If you do this, be aware that you will need to download matching Test Root Certificates that must be installed on each server component, and on each ICA Client device.

Obtaining a Server CertificateYou need to install a server certificate on the Secure Gateway machine. Optionally, if you are deploying a secure Web server you need to install a server certificate on the NFuse Web server as well. A description of the process involved in obtaining a certificate and installing it on the Secure Gateway server is provided below. Repeat the same process on the NFuse Web server, if required.

" Creating a Certificate Request

Create a Certificate Request using the IIS Certificate Wizard on the Secure Gateway server machine. To do this:

1. Click Start|Programs|Adminstrative Tools|Internet Services Manager

2. In the Internet Information Services console, right-click on the entry for Default Web Site, and select Properties.

3. Click the Directory Security tab in the Default Web Site Properties screen.

4. Click the Server Certificate button under Secure Communications.

5. The IIS Server Certificate Wizard is displayed. Click Next.

6. Select Create a new certificate, and click Next.

7. Select Prepare the request now, but send it later. Click Next.

8. In Name, type the name for the server certificate.

9. In Bit Length, enter the bit length to be used for the certificate's encryption strength, the greater the bit length, and the higher the security. It is recommended that you select 1024 or higher here. Click Next.

10. Enter details about your organization. Click Next.

11. Enter the FQDN of the Secure Gateway, and click Next.

Chapter 4 Installing Certificates 41

12. In Geographical Information, enter pertinent geographical information about your location. Click Next.

13. Save the certificate request as a text file, for example, c:\certreq.txt, to your hard drive. Click Finish to exit the wizard.

" Applying for a Server Certificate

To apply for a valid server certificate, follow the process specified by the public or private CA you are using. A server certificate will be issued to you in due course by email.

Installing the Server CertificateThe CA will mail your server certificate to you. The certificate might be a file, or a text block in the body of the email.

1. If the certificate is a text block in the body of the email, copy the text block and paste it into a text file in Notepad. Save as, filename.cer.

2. Locate the certificate file, for example, filename.cer, using Windows Explorer. Click Install to install it on your system.

-----BEGIN CERTIFICATE------MIICgDCCAioCEHUjY9Wu6IgLEnGwFh8GwswDQYJKoZIhvcNAQEEBQAwgakxFjAUBgNVBAoTDVZlcmlTaWduLCBJbmMxRzBFBgNVBAsTPnd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9UZXN0Q1BTIEluY29ycC4gQnkgUmVmLiBMaWFiLiBMVEQuMUYwRAYDVQQLEz1Gb3IgVmVyaVNpZ24gYXV0aG9yaXplZCB0ZXN0aW5nIG9ubHkuIE5vIGFzc3VyYW5jZXMgKEMpVlMxOTk3MB4XDTAxMDgxNjAwMDAwMFoXDTAxMDgzMDIzNTk1OVowgZgxCzAJBgNVBAYTAkFVMQwwCgYDVQQIEwNOU1cxEzARBgNVBAcUCk5vcnRoIFJ5ZGUxLDAqBgNVBAoUI0NpdHJpeCBTeXN0ZW1zIEFzaWEtUGFjaWZpYyBQdHkgTHRkMRQwEgYDVQQLFAtFbmdpbmVlcmluZzEiMCAGA1UEAxQZYXVzLWt0LXAyMTAuY2l0cml4LmNvbS5hdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA33IcbZU1Mht7esWsWYSI+6O1xdgNJgvP544MAlcrZRYMt8ZYORV220FMoZcszHf8k9r34IBMtv22qIuycBckIcabkyi5BZCM6Z7DBmv6E9veLhwOV405uVT1tFoKOKnSTDvUR00Ilbf69ovMgfAGzXPbv8XVzjWzt1TqCLEBmUCAwEAATANBgkqhkiG9w0BAQQFAANBAHu2Gc7jIqyoxcAqPjeSorqdiHouRB6d00GNTK8JsBxgb3RlHCf9mV62mOidvt9SKlZhuZ42kLdTFhRWlkIAVAk=

-----END CERTIFICATE-----


3. At this point if you don�t have a root certificate for the CA installed, a message stating, �This certificate cannot be verified,� is displayed. If this happens, obtain and install a root certificate from the same CA.

If you are using a server certificate issued by a trusted root authority, you do not need to install a root certificate because support for these CAs is built into the Windows operating system.

If you plan to use certificates from your own private CA, or from a untrusted CA ensure you obtain a root certificate as well. A single root certificate can be installed on any number of machines, including the ICA Clients, the NFuse server, and the Secure Gateway server.

Chapter 4 Installing Certificates 43

Server Certificates: Tips and CautionsThe following tips and cautions should be borne in mind when obtaining server certificates:

� Part of an initial request for a certificate involves generating a public/private keypair that is stored on your server. Since the public key from this keypair is encoded in your certificate, loss of the keypair on your server will render your certificate worthless. Care should be taken to backup your keypair data on another computer, a floppy disk, or perhaps both. The Microsoft IIS Key Manager has a special Export Key function that can be used to generate a backup file.

� Part of generating a keypair is specifying a password used to encrypt it. (This prevents someone with access to the keypair data from extracting the private key and using it to decrypt SSL traffic to and from your server.) Forgetting this password could also render your certificate worthless, so pains should be taken to remember it, perhaps writing it down in some hidden place, or sharing it with one or two other people in your department.


Root CertificatesA root certificate must be present on every ICA client device, Secure Gateway server and on the NFuse-enabled Web server, depending upon how you plan to deploy the Citrix Secure Gateway.

Installing Root Certificates on the ICA Client DeviceA root certificate is required on every SSL-enabled ICA client that accesses the Secure Gateway server. This means that when you roll out ICA Clients to your users, you need to bundle the root certificate along with the ICA Client files.

On 32-bit Windows systems, support for most trusted root authorities is built into the base operating system, and Internet Explorer, so there is no need to install root certificates on the client device for these CAs. However, if you choose a different CA, you will need to install the root certificates yourself.

Note For information about root certificate availability on ICA Client platforms other than 32-bit Windows, refer to the ICA Client Administrator�s Guide appropriate for the operating system you are using.

Installing Root Certificates on an NFuse Web ServerBy default, the Windows operating system ships with built-in support for an exhaustive list of root authorities. Therefore, if you have chosen to use one of these trusted authorities as your CA, you do not have to install root certificates on the NFuse Web server.

However, if you have chosen to use a private CA or a root authority other than those that ship with Windows, you must add the CA�s root certificate to the NFuse Web server − see the NFuse Administrator�s Guide for information about how to do this.

What To Do NextAfter you have installed the appropriate digital certificates, the next step is to install the Citrix Secure Gateway components and get it up and running. See �Installing and Configuring Citrix Secure Gateway� on page 45 for more information.

C H A P T E R 5

Installing and Configuring Citrix Secure Gateway

This chapter contains installation and configuration instructions for Citrix Secure Gateway software.


� Before You Begin, page 46

� Installing Secure Gateway Components, page 47

� Installing the Secure Ticket Authority (STA), page 49

� Installing the Secure Gateway Service, page 52

� Installing NFuse Extensions, page 57

� Testing the Citrix Secure Gateway Installation, page 61

� Uninstalling Secure Gateway Components, page 63



Before You BeginCitrix Secure Gateway consists of several components that need to be installed on separate servers. It is therefore important that you collate all the information required before you begin installation.

Compile the Following InformationCollate the following information before you install Citrix Secure Gateway.

You need to specify these values during the installation process. Note that the values in this listing are for illustration purposes only; replace them with the actual values for your environment.

The example network and port addresses shown above are used to demonstrate a sample Citrix Secure Gateway deployment in the following diagram.

No. Item Description Example

1. FQDN of the MetaFrame server running the Citrix XML Service

mfserver01.company.com

2. IP address of the MetaFrame server running the Citrix XML Service

10.42.1.19

3. FQDN of the Secure Gateway server csgwy.company.com

4. IP address of the Secure Gateway server 10.42.1.17

5. Listener port number, for SSL connections, on the Secure Gateway server

443

6. FQDN of the Secure Ticket Authority (STA) sta01.company.com

7. IP address of the STA 10.42.1.18

8. FQDN of the NFuse Web server nfuse01.company.com

9. IP address of the NFuse Web server 10.42.1.16

Chapter 5 Installing and Configuring Citrix Secure Gateway 47

Important Citrix recommends that you assign static IP addresses for the Secure Gateway server and the STA so that the components can always locate each other, even if one or the other has been rebooted.

Installing Secure Gateway ComponentsCitrix recommends that you install the Secure Gateway components in the following order:

1. Install the Secure Ticket Authority

The STA is an independent component, in that, you do not need to specify the location of the Secure Gateway Server or the NFuse server to complete configuration.

2. Install the Secure Gateway Service

You need to specify details and location of the STA while configuring the Secure Gateway Service.

3. Install NFuse Extensions

You will need to specify details of the STA as well as the Secure Gateway Service to complete configuration of the NFuse server.


Accessing Context-sensitive Help Installation of the software is wizard-driven, and each step in the install process is adequately described by the respective wizards. A software configuration utility is launched after each component is installed. Context-sensitive Help is available in the configuration utilities.

To view context-sensitive Help, click the in the title bar of the dialog box, and then click an item in the dialog box.


Installing the Secure Ticket Authority (STA)The STA is an ISAPI (Internet Server Application Program Interface) DLL that is loaded and called by Internet Information Services (IIS) when a request for a ticket is received from NFuse.

" To install the STA

1. The server you are using for STA installation should have IIS 5.0 installed, configured and running.

2. Copy the installer file for the STA, csg_sta.msi, to the local hard drive of this machine.

3. To install the STA, double-click the installer, csg_sta.msi. The installation program starts. You must complete the following tasks during installation:

� Accept the License Agreement.

� View information specific to the installation of the STA software.

� Specify a destination folder for the system files required for STA operation. The default installation directory for the STA is \inetpub\scripts\.

At this point, installation of the STA is complete.


Configuring the Secure Ticket AuthorityWhen installation of the software is complete, the Secure Ticket Authority Configuration utility is launched. You need to enter the following information to correctly configure the STA for use:

1. Select Typical or Advanced Configuration. Click Typical, to specify the minimum set of configuration values required to run the STA. Click Advanced, if you are an expert user, and would prefer to specify all the configuration values required for STA operation. Click Next.

2. Specify configuration values for the STA.

3. At this point, configuration of the STA is complete. In order to use the new configuration settings, the World Wide Web Publishing Service must be restarted. Clear the Restart World Wide Publishing Service check box if you prefer to restart the service manually.

4. Click Finish to exit the configuration utility.


Changing the STA�s Configuration SettingsYou can change the configuration settings entered during the install process at any time by running the Secure Ticket Authority Configuration utility.

" To run the configuration utility:

1. Click Start|Programs|Citrix|Citrix Secure Gateway|Secure Ticket Authority Configuration.

2. Make necessary changes, and click Finish to exit the utility.


Installing the Secure Gateway ServiceThe Secure Gateway Service has been implemented as a Windows 2000 service.

" To install the Secure Gateway Service

1. Stop the World Wide Publishing Service on the Windows 2000 server. The World Wide Publishing Service uses port 443 by default, and this causes a conflict with the Secure Gateway Service. Also ensure that port 443 on this server is not being used by any other Windows service.

2. Install root and server certificates. See �Installing Certificates� on page 39 for information on how to install certificates.

3. Copy the installer file, csg_gwy.msi, for the Secure Gateway Service to the local hard drive of this machine.

4. Double-click the installer file, csg_gwy.msi. The installation program starts. You must complete the following tasks during installation:

� Accept the License Agreement

� View information specific to the installation of the Secure Gateway Service.

At this point, files required to run the Secure Gateway Service are installed to the %systemroot%\system32\ctxsecgwy directory.


Configuring the Secure Gateway ServiceAfter you install the Secure Gateway Service, the Secure Gateway Service Configuration utility is launched. You need to enter the following information to correctly configure the Secure Gateway Service for use:

1. Select Typical or Advanced Configuration. Click Typical, to specify the minimum set of configuration values required to run the Secure Gateway Service. Click Advanced, if you are an expert user, and would prefer to specify all the configuration values required for Secure Gateway Service operation.

2. Select a server certificate to be used by the Secure Gateway Service.

The configuration wizard searches the system for installed server certificates, and presents a list for you to select from. Select the server certificate that you want the Secure Gateway Service to use.


3. Enter the FQDN (Fully Qualified Domain Name) or IP address of the STA you installed earlier. This address is used by the Secure Gateway Service to contact the STA for tickets.

4. Specify the interface, or IP address, and port number (typically 443) that the Secure Gateway will monitor for SSL connections. Click Next.


5. Specify values to configure connection parameters such as connection time-out, connection resume, and so on. Click Next.

6. Specify values to configure Secure Gateway logging operations. Click Next.

7. At this point, configuration of the Secure Gateway Service is complete. The server needs to be rebooted prior to running the service. Clear the Restart server check box if you would prefer to restart the server manually. Click Finish, to exit the utility.


Starting the Secure Gateway ServiceThe Secure Gateway Service is automatically started at boot up.

" To manually start, or stop the service

1. On the Secure Gateway server, log on as administrator.

2. On the desktop of the Secure Gateway server, right-click My Computer and select Manage.

3. Double-click Computer Management (Local).

4. Double-click Services and Applications, and then click Services. A list of all services registered for this computer is shown in the right hand pane.

5. Select Citrix Secure Gateway Service, and click Action|Start (or Action|Stop) to start (or stop) the Secure Gateway Service.

Changing Secure Gateway Configuration SettingsTo change configuration settings entered during the install process at any time, you need to run the Secure Gateway Service Configuration utility. It is recommended that you stop the Secure Gateway Service before you make changes to the configuration.

" To run the configuration utility

1. Click Start|Programs|Citrix|Citrix Secure Gateway| Secure Gateway Service Configuration.

2. Make necessary changes. Changes made do not take effect until the service is restarted. The program restarts the service automatically, however, if you would prefer to do this manually, clear the Start Secure Gateway Service check box. Click Finish to exit the utility.


Installing NFuse Extensions The next step is to install NFuse Extensions on your NFuse Web Server. NFuse Extensions is a software update to NFuse versions 1.51 and 1.6. This software update enables the NFuse Web server to support Citrix Secure Gateway. A sample Web site for use with Citrix Secure Gateway is created as a result of installing NFuse Extensions.

Important NFuse Extensions provides compatibility and support for the Citrix Secure Gateway software and is only for use with NFuse versions 1.51 and 1.6. Future versions of NFuse will natively support Citrix Secure Gateway and will not require the NFuse Extensions.

" To install NFuse Extensions

1. You should have NFuse 1.51 or 1.6 correctly configured and running on an IIS 5.0 Web server.

2. If you are implementing a secure NFuse Web server, you should have a server certificate installed on the machine. Refer to �Installing Certificates� on page 39 for instructions on how to do this.

3. Double-click the installer, csg_nfe.msi. The installation program starts. You must complete the following tasks during installation:

� Accept the license agreement

� View the Readme file.

� Specify a destination folder for the install. The default installation directory for the NFuse Extensions is \inetpub\wwwroot\csg.

� Click Finish to complete installation.


Configuring NFuse ExtensionsAfter you install NFuse Extensions, the NFuse Extensions Configuration utility is launched.

" To configure NFuse Extensions

1. Select Typical or Advanced Configuration. Click Typical, to specify the minimum set of configuration values required to enable NFuse to support Citrix Secure Gateway. Click Advanced, if you are an expert user, and would prefer to specify all the configuration values required. Click Next.

2. Enter the details, FQDN (Fully Qualified Domain Name) and STA identifier, of the server on which you installed the STA earlier. Click Next.

3. Enter the FQDN (Fully Qualified Domain Name), and SSL listener port of the server on which you installed the Secure Gateway Service. Click Next.


4. Enter the FQDN (Fully Qualified Domain Name) of the MetaFrame server running the Citrix XML Service which NFuse will contact for published applications.

5. At this point, configuration of NFuse Extensions is complete. The World Wide Web Publishing Service needs to be restarted to save configurations settings to disk. Clear the Restart the World Wide Web Publishing Service check box to do this manually.

No further configuration is required before using the NFuse Web server with Citrix Secure Gateway. Click Finish to exit the utility.


Changing Configuration Settings for NFuse ExtensionsTo change configuration settings entered during the install process at any time, run the NFuse Extensions Configuration utility. We recommend that you stop the World Wide Web Publishing Service (using the Windows 2000 Services console) before you make changes to the configuration.


1. Click Start|Programs|Citrix|Citrix Secure Gateway|NFuse Extensions Configuration.

2. Make necessary changes.

3. The program restarts the World Wide Publishing Service automatically, however, if you would prefer to do this manually, clear the Restart the World Wide Publishing Service check box. Click Finish to exit the utility.

Testing the Sample Web SiteWhen you install NFuse Extensions a sample Citrix Secure Gateway Web site is created (the default installation directory is \inetpub\wwwroot\csg\), on the NFuse Web server. This set of default Web pages enable you to test Secure Gateway functionality. You can customize this site as per your requirements.

To test this Web site, use a Web browser on the ICA Client device to openhttp://FQDN/csg/default.htm, where FQDN is the fully qualified domain name of your NFuse Web server.

Note This site is a sample Web site designed purely to help you test if Citrix Secure Gateway is functional. To customize this site to suit your environment, refer to the white paper entitled �Customizing NFuse For Citrix Secure Gateway.� This white paper is included in the Citrix Secure Gateway distribution kit and can be found in the directory to which you extracted the contents of setupcsg100en.exe. This paper can also be found in the Citrix Knowledgebase at http://knowledgebase.citrix.com/.


Testing the Citrix Secure Gateway InstallationOnce you�ve completed installation you need to test your Secure Gateway deployment to ensure that it is functioning correctly.

" To test the Secure Gateway installation

1. Use a Web browser on an ICA Client device to open the URL of your Secure Gateway Web site.


2. Log on using valid user credentials. The Web page is populated with a list of published applications that you are authorized to access.

3. Double-click on an application name to launch it.

After a brief interval, the application window is displayed on your screen.

4. Open the ICA Connection Center and check the entry for this published application.

Observe that the entry for the application you are running has the string �Remote, 128-bit SSL� appended, as shown above.

If you have trouble launching an ICA connection or connection fails, you need to revisit the installation procedure. For troubleshooting information see �Troubleshooting Information� on page 81.


Uninstalling Secure Gateway ComponentsTo uninstall Citrix Secure Gateway components use Add/Remove Programs available in the Windows Control Panel.

" To remove a Citrix Secure Gateway component

1. Open Add/Remove Programs in the Windows Control Panel.

2. Click Change or Remove Programs, then click the program you want to change or remove.

3. Click Change/Remove to uninstall the software.

What To Do NextOnce you have installed and tested a basic Secure Gateway installation, you can deploy it to your users in a Production environment. Corporate network environments tend to be complex, and if you are deploying Secure Gateway on a network that uses load balancers, SSL accelerator cards, firewalls, and so on, you should read �Advanced Concepts� on page 65 for general recommendations and compatibility guidelines for using Secure Gateway in such environments.

C H A P T E R 6

Advanced Concepts

This chapter describes error logs and performance objects, that are created by Citrix Secure Gateway components, and how they can be used to monitor and troubleshoot performance of the individual components. This chapter also provides general compatibility guidelines for deploying Citrix Secure Gateway in a complex environment containing typical network components such as load balancers, SSL accelerator cards, firewalls, and so on.


� Errors and Error Logs, page 66

� Performance Monitoring, page 68

� Planning For High Availability, page 73

� Securing the Secure Gateway Environment, page 78


Errors and Error LogsError logs are an invaluable troubleshooting tool; they record important system events such as low-memory conditions, or dropped ICA connections, and so on. System administrators can use the error log(s) to help determine what conditions caused the error and the context in which it occurred. By periodically viewing the event log, the administrator may be able to identify problems before they cause damage.

The Secure Gateway Service logs errors in two locations:

� In the Windows Application Log. The Windows application log contains events logged by applications or programs. The Secure Gateway Service logs fatal errors in the Windows application log. Use the Windows Event Viewer to examine fatal error messages logged by the Secure Gateway Service.

� In proprietary Error Logs. The Secure Gateway Service and the Secure Ticket Authority (STA) also generate proprietary error logs. These error logs contain details of fatal, critical, processing, and warning errors, as well as informational messages.

The amount of information logged is dependant on the log level specified during configuration.

Citrix Secure Gateway Error LogsLog files for the Secure Gateway Service and the STA are rolled over every day at midnight, or when certain criteria limits are reached. These criteria are:

� Date. A log file is rolled over at midnight each day.

� File Size. A log file can also be rolled over if it reaches the maximum file size limit. This means you could have multiple log files per day if the amount of information logged by the Secure Gateway components exceeds the maximum log file size setting.

� Number of Log Files. Log files are deleted if the number of log files exceeds the maximum specified. The default maximum is 7. It is therefore important that you backup your log files regularly.

Chapter 6 Advanced Concepts 67

Conventions For Log File Names To accommodate this roll over criteria, the Secure Gateway Service and STA log filenames follow a prescribed format.

� Secure Gateway Service CSGyyyymmdd-xxx.log

� Secure Ticket Authority STAyyyymmdd-xxx.log

where, the first three letters identify the Secure Gateway component, that is Secure Gateway Service (CSG), and Secure Ticket Authority (STA).The next six characters specify the date, in yyyy/mm/dd format. For example, 20011225 would mean it was the 25th of December, 2001The final three characters denote an index of files for that particular date, since it is possible to have more than a single log file per day. The maximum number of log files that can be created per day is 1000, that is, 000 to 999. If more than a 1000 log files are created in a day, then the index is wrapped around from 999 to 000. Existing log files ending with 000 will be over-written.

Configuring Logging ParametersYou can use the configuration utilities for the Secure Gateway Service and the STA at any time to configure logging parameters. For example:

" To configure logging parameters for the Secure Gateway Service

1. Click Start|Programs|Citrix|Citrix Secure Gateway| Secure Gateway Service Configuration.

2. In the Configuration utility screen displayed, click Advanced Configuration.

3. Click Next until you see the Configure Logging Parameters screen.

Context-sensitive Help on a control can be accessed by clicking the button and then clicking a control in the dialog.


Performance MonitoringYou can monitor performance of the Secure Gateway and the STA using the Performance console on Windows 2000 servers.

All work performed, by the Secure Gateway and STA components, generates performance data. Both of these components provide appropriate performance objects, and the Performance console on Windows 2000 servers can be used to generate performance graphs and logs to monitor these objects.

Monitoring system performance is an important part of maintaining and administering your Citrix Secure Gateway installation. Performance data can be used to:

� Understand the workload on the Secure Gateway or the STA, and the corresponding effect it has on the respective system�s resources

� Observe changes and trends in workloads and resource usage so you can plan for system sizing, and fail-over

� Test changes in configuration, or other tuning efforts by monitoring the results

� Diagnose problems and target components or processes for optimization

Citrix recommends that you regularly monitor performance of the Secure Gateway Service and the STA as part of your administrative routine.


Accessing Performance Objects" To access performance objects

1. Select Start|Programs|Administrative Tools|Performance.

2. In the tree view, select System Monitor.

3. Click the Add icon.

4. In the Add Counters dialog, click the Performance object drop down list, and select Citrix Secure Gateway (or select Citrix Secure Ticket Authority to view STA object counters).

5. Optional. In the Add Counters dialog box, click Explain for a description of the data provided by a particular counter associated with a performance object.


Performance Counters available for the Citrix Secure Gateway ObjectThe following Performance Counters are available for the Citrix Secure Gateway Object:

Performance Counter Description

Active Session Count The number of concurrent ICA connections being handled by this service.

Client Connections Accepted The number of successful client connections since the service started or restarted.

Client Connections Timed Out The number of client connections that timed out before initiating the connection handshake since the service started or restarted.

Client Connections Failed The number of client connections that failed handshake processing since the service started or restarted. A high connection failure rate may be due to a ticket timeout interval that is too short or the use of an invalid ticket to access the Secure Gateway server.

MetaFrame Connections Failed The number of failed connections to MetaFrame server(s). A high failure rate is indicative of network errors on the network between the MetaFrame server(s) and the Secure Gateway server.

MetaFrame Connections Successful The number of successful connections to MetaFrame server(s).

STA Data Requests Successful The number of successful Data Requests sent to the STA since the service started or restarted.

STA Data Requests Failed The number of failed Data Requests sent to the STA, since the service started or restarted. A high Data Request failure rate may be due to a ticket timeout interval that is too short or the use of an invalid ticket to access the Secure Gateway server.

Peak Client Connection Attempts/sec. The peak number of client connection attempts per second since the service started or restarted.

Peak STA Data Requests/sec. The peak number of Data Requests sent to the STA per second since the service started or restarted.

Peak Active Clients/sec. The peak number of active clients in any second since the service started or restarted.

Global Client(s) to Gateway packets The number of network packets sent from ICA client(s) to the Secure Gateway server.

Global Client(s) to Gateway bytes The number of data bytes sent from ICA client(s) to the Secure Gateway server.

Global Gateway to MetaFrame server bytes The number of bytes sent from the Secure Gateway server to the MetaFrame server.


Important Performance objects for the Secure Gateway Service and the STA are only available when the respective components are in use.

Global MetaFrame server to Gateway packets The number of packets sent from the MetaFrame server to the Secure Gateway server.

Global MetaFrame server to Gateway bytes The number of data bytes sent from MetaFrame server(s) to the Secure Gateway server.

Global connect time in msec. Specifies the time taken in milliseconds, from accepting a client connection request, to connecting to the MetaFrame server, for the last successful connection.

Longest connect time in msec. The longest time taken in milliseconds, from accepting a client connection request to connecting to the MetaFrame server, for a successful connection since the service was started or restarted. Excessive connection times are indicative of high peak or sustained loads. If the problem is due to a high sustained load, the number of connections to the Secure Gateway server can be limited by reducing the maximum connection limit.



Performance Counters available for the Secure Ticket Authority ObjectThe following Performance Counters are available for the Citrix Secure Ticket Authority Object:

Important The STA is an ISAPI DLL, and performance counters for the STA are initialized and available only after the STA has been started and used at least once.


STA Bad Data Request Count The total number of unsuccessful ticket validation and data retrieval requests during the lifetime of the STA.

STA Good Data Request Count The total number of successful ticket validation and data retrieval requests received during the lifetime of the STA.

STA Bad Ticket Request Count The total number of unsuccessful ticket generation requests received during the lifetime of the STA.

STA Good Ticket Request Count The total number of successful ticket generation requests received during the lifetime of the STA.

STA Peak Data Request Rate The maximum rate of data requests per second during the lifetime of the STA.

STA Peak Ticket Request Rate The maximum rate of ticket generation requests per second during the lifetime of the STA.

STA Peak All Request Rate The maximum rate of all monitored activities per second.

STA Ticket Timeout Count The total number of ticket time-outs that occurred during the lifetime of the STA.

STA Count of Active Tickets Total count of active tickets currently held in the STA.


Planning For High AvailabilityCitrix Secure Gateway can be configured to provide added redundancy to increase system availability by deploying multiple NFuse servers, Secure Gateway servers and STA servers. The illustration below depicts a sample scenario of such a deployment.

Deploying multiple NFuse servers, Secure Gateway servers and STA servers does not make the session fault tolerant, but provides an alternative server should a Secure Gateway component fail.

When the number of concurrent ICA sessions exceeds the capacity of a single NFuse server or Secure Gateway server, multiple NFuse servers or Secure Gateway servers will need to be deployed to support the load. There is no practical limit to the number of Secure Gateway servers or NFuse servers that can be deployed to service large MetaFrame farms.

In order to deploy more than one Secure Gateway server or NFuse server, a load balancer is required. The function of the load balancer is to distribute client sessions to one of a number of servers offering a service. This is normally done by implementing a �virtual address� on the load balancer for a particular service and maintaining a list of servers offering the service. When a client connects to a service, the load balancer uses one of a number of algorithms to select a server from the list and redirects the client to the selected server.


The algorithm can be as simple as a �round robin� where each client connect request is assigned to the next server in a circular list of servers, or a more elaborate algorithm based on machine load and response times. Intelligent load balancers can also detect the failure of a server through server polling and temporarily remove the failed server from their list of available servers and restore them to the list when they come back online.

The client response to a server failure depends on which server fails and at what point in the session the server fails.

The NFuse server is involved during user sign on, application launch, or application relaunch. Failure of the NFuse server requires the user to reconnect to the Web site and sign on again when they want to launch a new application or relaunch an existing application.

The Secure Ticketing Authority is involved in the launch or relaunch of an application. Failure of the Secure Ticketing Authority during application launch requires the user to return to the NFuse Web page to relaunch the application.

The Secure Gateway server is involved during application launch, and the time an application remains active. Failure of the Secure Gateway requires the user to return to the NFuse Web page and relaunch the application.

Load Balancing A Secure Gateway Server ArrayA load balancing solution managing an array of Secure Gateway servers can provide the following key benefits, including:

Scalability. Performance of a Secure Gateway implementation can be optimized by distributing its client requests across multiple servers within the array. As traffic increases, additional servers can be added to the array. The only restriction to the maximum number of Secure Gateway servers in such an array would be imposed by the load balancing solution being used.

High availability. Load balancing would provide high availability by automatically detecting the failure of a Secure Gateway server and redistributing client traffic among the remaining servers within ten seconds.

Load balancing a Secure Gateway server array should be accomplished using a virtual IP address that is dynamically mapped to one of the real IP addresses of the Secure Gateway servers. For instance, let�s say that you have three Secure Gateway servers with addresses 10.4.0.10, 10.4.0.11, and 10.4.0.12. Using a virtual IP address, such as 10.4.0.15, causes all your requests to be directed to the virtual IP address and then routed to one of the servers. The virtual IP address may be set up through software, such as Network Load Balancing (NLB), or hardware. If hardware is used in a production environment you should probably use two such devices to avoid a single point of failure.


Certificate RequirementsLoad balancing relies on the use of a VIP (Virtual IP) address. The VIP address is bound to an FQDN (Fully Qualified Domain Name) and all ICA Clients request connections from the VIP address rather than the individual Secure Gateway servers behind it. Basically, a single IP address, the VIP, acts as an entry point to your Secure Gateway servers, simplifying the way ICA Clients access published applications and services on MetaFrame servers.

If you are using a load balancing solution, all Secure Gateway servers can be accessed using a common FQDN, for example, csgwy.company.com.

In conclusion, you will need a single server certificate, issued to the FQDN (mapped to the Virtual IP) of the load balancing server, that must be installed on every Secure Gateway server in the server array that's being load-balanced.

Load-balancers and SSL Accelerator Cards...Load balancing solutions available in the market today may feature built-in SSL accelerator cards. If you are using such a solution to load-balance a Secure Gateway server array, disable the SSL acceleration for traffic directed at the Secure Gateway server. Consult the documentation that came with your load balancer for details on how to do this.

Presence of SSL accelerator cards in the network path before the Secure Gateway Service means the data arriving at the Secure Gateway server is decrypted data. This conflicts with a basic function of the Secure Gateway Service which is to decrypt SSL traffic before sending it on to the MetaFrame server(s). The Secure Gateway Service does not expect non-SSL traffic and drops the connection.


Using Multiple STAsDue to the small processing load involved in issuing a ticket and returning ticket details, a single STA is capable of supporting a very large number of users. Two STA servers can be configured for redundancy purposes. If more than one NFuse server is used, the servers can be configured with a different STA entry at the head of each server�s configured list of STAs to distribute the ticketing load across the available STAs.

Warning Do not attempt to load balance STA servers. Tickets are issued and verified by the same STA for a particular connection request. The nature of load balancing does not guarantee that the same STA is contacted for issuing as well as verifying a ticket.

Connection Keepalive Values on the Secure Gateway serverCitrix Secure Gateway establishes connections over the Internet between ICA Clients and MetaFrame servers. When a client connection drops off without being properly logged off, the Secure Gateway Service continues to keep the connection to the MetaFrame server open. Accumulation of these �ghost� connections eventually affects performance of the Secure Gateway server.

The Secure Gateway Service uses TCP/IP Keepalives, which are registry settings in Windows, to detect and close broken connections between the Secure Gateway server and the ICA Client(s). TCP/IP Keepalive settings, which configure the Secure Gateway Service to terminate ICA connections after a period of 7,200,000 milliseconds or 2 hours, are added to the Windows registry during installation of the Secure Gateway Service. This is the period of time TCP/IP waits before an attempt is made to verify if an idle connection is still connected.

If no response is received, TCP/IP retries the verification process after the interval specified by KeepAliveInterval and for a maximum number of times specified by TcpMaxDataRetransmissions. The default value for KeepAliveInterval is 1 second, and the default value for TcpMaxDataRetransmissions is 5.

You might need to modify Keepalive parameters or disable them depending on your network environment. KeepAliveInterval, KeepAliveTime, and TcpMaxDataRetransmissions parameters, are stored in the Windows registry −HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\


Consult the Microsoft Knowledgebase article, Q120642 − TCP/IP & NBT Configuration Parameters for Windows, for information about making changes to these parameters. Under normal circumstances it should not be necessary to change these settings.

Keepalive Values on MetaFrame serversIf you have enabled TCP/IP Keepalive parameters on your MetaFrame server, Citrix recommends that you modify values of the Keepalive parameters on the Secure Gateway server to match the values on the MetaFrame server.

This is required because in an environment containing Secure Gateway, ICA connections are routed through the Secure Gateway server. TCP/IP KeepAlive messages from the MetaFrame server to the ICA Client are intercepted and responded to by the Secure Gateway server. Similarly TCP/IP Keepalive from the Secure Gateway server are sent only to the ICA Client; the Secure Gateway server does not transmit Keepalives to the MetaFrame server or to the Secure Ticket Authority. Setting the Keepalive values on the Secure Gateway server to match the values set on MetaFrame ensures that MetaFrame is aware of the client connection state and can either disconnect or logoff the connection in a timely manner.

See the Citrix Knowledgebase Article CTX708444 − How to Configure TCP and ICA KeepAlive Values So TCP/IP Users Go to Disconnected State for more information on the use of ICA and TCP/IP Keepalives on MetaFrame servers.


Securing the Secure Gateway EnvironmentThe Citrix Secure Gateway is an application specific proxy, and as such is relatively secure. It is not a firewall and should not be used as such. Citrix highly recommends that you use a firewall to protect Citrix Secure Gateway and other corporate resources from unauthorized access from the Internet, as well as unauthorized access from internal users.

Deploy the Citrix Secure Gateway in the DMZYou should place Citrix Secure Gateway in the demilitarized zone (DMZ) between two firewalls for maximum protection. In addition, physically secure the DMZ to prevent access to the firewalls and servers within the DMZ. A breach of your DMZ servers should, at worst, create an annoyance in the form of downtime while you recover from the security breach.

Warning Citrix recommends that you configure your firewalls to restrict access to specific ports only. If, instead, you configure your firewalls to allow access to ports other than those used by SSL, ICA, and the Citrix XML Service, you may allow users to gain access to unauthorized ports on the server.

.

Restricting CiphersuitesThe process of establishing a secure connection involves negotiating the ciphersuite that is used during communications. A ciphersuite defines the encryption type that�s used−it defines the cipher algorithm and its parameters, such as the size of the keys.

Negotiation of the ciphersuite involves the ICA Client informing the Secure Gateway which ciphersuites it is capable of handling, and the Secure Gateway informing the client which ciphersuite will be used during communication.

Citrix Secure Gateway supports two main categories of ciphersuite: COM (commercial) and GOV (government). The ALL option includes both the commercial and government suites.

The COM ciphersuites are:� SSL_RSA_WITH_RC4_128_MD5 or {0x00,0x04}

� SSL_RSA_WITH_RC4_128_SHA or {0x00,0x05}

The GOV ciphersuite is:� SSL_RSA_WITH_3DES_EDE_CBC_SHA or {0x00,0x0A}

Some organizations, including US government organizations, require the use of government-approved cryptography to protect �sensitive but unclassified data�.


Changing the Assigned CiphersuiteCitrix Secure Gateway uses a registry key, HKLM\SYSTEM\CurrentControlSet\Services\CtxSecGwy\Global\CipherStrength, to store the value indicating which ciphersuite is used.

" To modify this registry key

1. Click Start, click Run, and then type regedit.

2. Locate the registry entry below. You may have to add this key if it�s not found.

HKLM\SYSTEM\CurrentControlSet\Services\CtxSecGwy\Global\CipherStrength=ALL

3. To restrict the ciphersuite, change the value to GOV or COM, as required.

Follow Microsoft and Third Party Security GuidelinesTo further secure Citrix Secure Gateway, the Secure Gateway server should be locked down by removing or disabling all unnecessary accounts and services on the machine.

Citrix recommends that you refer to Microsoft guidelines and other third party publications for securing Windows 2000 servers.

Note Microsoft has recently released a tool that makes it simple to secure an IIS Web server. The tool, known as the IIS Lockdown Tool, allows Web server administrators to quickly configure the Web server for maximum security. For more information see the Microsoft Web site.

C H A P T E R 7

Troubleshooting Information

Citrix Secure Gateway consists of three separate software components, which, if configured incorrectly, could cause connection errors or failures.

The procedures outlined in this section should be sufficient to troubleshoot a majority of potential problems that could occur.


� Assumptions, page 82

� Compiling Secure Gateway Information, page 82

� Troubleshooting the Secure Gateway server, page 83

� Troubleshooting the Secure Ticket Authority (STA), page 88

� Troubleshooting the NFuse Web server, page 91

� Troubleshooting the ICA Client, page 98


AssumptionsAll of the Citrix Secure Gateway components should already be installed as described in �Installing and Configuring Citrix Secure Gateway� on page 45.

Note Issues concerning firewall traversal, Domain Name Service (DNS), and Network Address Translation (NAT) are beyond the scope of this document.This chapter assumes that you have correctly configured NAT and packet filtering on your network.

Compiling Secure Gateway InformationBefore you begin troubleshooting, obtain details of the Citrix Secure Gateway deployment as shown below. Note that the example values in this listing are for illustration purposes and are used throughout the outlined troubleshooting process described. Replace these values with the specifics of your environment.


1. FQDN of the MetaFrame server running the Citrix XML Service mfserver01.company.com

2. IP address of the MetaFrame server running the Citrix XML Service

10.42.1.19




443

6. FQDN of the Secure Ticket Authority (STA) sta01.company.com

7. IP address of the STA 10.42.1.18

8. FQDN of the NFuse Web server nfuse01.company.com

9. IP address of the NFuse Web server 10.42.1.16

10. Path for the Citrix Secure Gateway Web site on the NFuse Web server

http://nfuse01.company.com/csg/default.htm

Chapter 7 Troubleshooting Information 83

Troubleshooting the Secure Gateway serverTo ensure that the Secure Gateway server is functioning correctly, do the following:

� Check the error log for the Secure Gateway Service

� Check that you installed appropriate certificates, that the certificates are still valid, and were issued by a trusted source

� Ensure that there is no port conflict on the Secure Gateway server

� Ping the STA from the Secure Gateway server to verify its IP address and FQDN

� Start the Secure Gateway Service and check the error log

Checking the Error LogsThe error log for the Secure Gateway Service, located in%systemroot%\system32\ctxsecgwy\ctxsecgwy.log, contains details of fatal, critical, processing, and warning errors, as well as informational messages. The level of information logged is dependant on the log level specified during configuration.

Fatal or critical errors are also logged in the Windows Application Log. The application log contains events logged by applications or programs. Use the Windows Event Viewer to examine error and information messages logged by the Secure Gateway Service. The information available in the error log (s) may help you identify the problem quickly.

Checking CertificatesCheck that the certificates installed have been issued by a trusted source, are still valid and have been issued for the correct machine.

" To check your certificates

1. Log on as administrator, to the Windows 2000 server that is running the Secure Gateway Service.

2. Click Start|Run. In the Run dialog, type mmc to run the Microsoft Management Console (MMC).


3. In the MMC, select Console|Add/Remove Snap-in

4. In the Add/Remove Snap-in dialog box, click the Standalone tab.

5. In the Standalone tab, click Add.

6. In the Add Standalone Snap-in screen, select Certificates, and click Add.

7. In the Certificates Snap-in dialog, select Computer Account. Click Next.

8. In the Select Computer dialog box, select Local Computer (the computer that this console is running on). Click Finish.

9. Click Close, click OK. Note that a new branch has been added to Console root in the MMC.

10. Double-click Certificates (Local Computer).

11. Double-click the Personal folder, and then click Certificates.


12. Examine the certificate that was issued and is installed on your Secure Gateway server.

13. If you don't see a certificate for your server, then revisit the certificate installation process. See �Installing Certificates� on page 39.

14. Double-click the certificate.

� Check that the value in the Issued To field, matches the FQDN of this machine (refer to the network addresses and port list you compiled previously). Record details of the Issued To field for use in further troubleshooting.

� Also ensure that it hasn�t expired. If the certificate has expired you will need to apply for certificate renewal. Contact your Corporate Security department for help with this.

15. Close the MMC.


Checking for Port ConflictsYou need to stop the Secure Gateway Service to check for port conflicts.

" To check for port conflicts



3. Double-click Services and Applications, and then click Services. A list of all services registered for this computer appears in the right hand pane.

4. Select Secure Gateway Service, and click Action|Stop to stop the service.

5. Next, select World Wide Web Publishing Service and click Action|Stop to stop the service.

6. Open a command prompt window, and type the following command:

netstat -a -nA list of active TCP/IP connections appears. You should see no entry representing the port you wish the Secure Gateway server to be listening on (typically 443).If you do see an entry for port 443, it is possible that another application is running on that port. You will need to resolve this conflict.

Checking Network ConnectivityTo check that you have network connectivity on the Secure Gateway server, ping the machines that the Secure Gateway server connects to:

" To ping the STA

1. At the command prompt, use the FQDN of the STA to ping the machine it was installed on. For example, type:

ping sta01.company.com2. Ensure that the IP address resolved matches the one you recorded previously.

" To ping the Citrix XML Service in the MetaFrame server farm

1. At the command prompt, ping the MetaFrame server running the Citrix XML Service using its FQDN.

ping mfserver01.company.com2. Ensure that the IP address resolved matches the one you recorded previously.


Checking Configuration ValuesCheck that you've configured the Secure Gateway Service correctly.

" To check current configuration values

1. Log on as administrator, to the Windows 2000 server that is running the Secure Gateway Service.

2. Click Start|Programs|Citrix|Secure Gateway Service Configuration.

3. Check that the configuration values specified are correct.

Note You must restart the Secure Gateway Service, if you made changes to the configuration settings.

Checking for Start-up Errors1. On the desktop of the Secure Gateway server, right-click My Computer and

select Manage.



4. Select Citrix Secure Gateway Service, and start the service. If an error is returned, record the error message.

5. Open a command prompt window, and type:

netstat -a -nYou should see an entry representing the port you configured the Secure Gateway to listen on (typically 443).

6. Check the application log file,%systemroot%\system32\ctxsecgwy\ctxsecgwy.log, to ensure that the service did not report any errors.


Troubleshooting the Secure Ticket Authority (STA)To ensure that the STA is functioning correctly, do the following:

� Check the STA�s Error Log

� Check access privileges to the STA�s logging directory

� Ensure that the World Wide Publishing Service has been started and is functional

� Ensure STA system files are installed

� Check values in the STA�s configuration file

Checking the Error LogThe STA�s configuration file, inetpub\scripts\ctxsta.log, contains details of fatal, critical, processing, and warning events, as well as informational messages. The level of information logged is dependant on the log level specified in the STA�s configuration file. The information available in the error logs may help you identify the problem quickly. See �Error Messages� on page 119 for a listing of error messages.

Checking Directory Access PrivilegesMicrosoft guidelines for securing Web servers recommends removing access privileges to the \inetpub\wwwroot\scripts\ directory.

The STA is an ISAPI DLL that�s loaded and called by IIS. If you�ve removed access rights to the directory in which the STA system files reside, typically inetpub\wwwroot\scripts\, then IIS can�t load and execute the STA. As a result of insufficient access privileges, the STA will be unable to read its configuration file, and/or write to its log file.

Ensure that the directory, typically \inetpub\wwwroot\scripts\, to which you installed the STA has sufficient read and execute permissions in IIS.


Ensuring the World Wide Web Publishing Service is Functional

" To check that the World Wide Web Publishing Service is functional

1. Log on as administrator to the Windows 2000 server running the STA.

2. On the server desktop, right-click My Computer and select Manage.



5. Ensure that the World Wide Web Publishing Service has been started and is running.

6. Next, open a command prompt window, and type:

netstat -a -nYou should see an entry representing port 80, which is the listener port for IIS.

Ensuring STA System Files are InstalledEnsure that the following files are present on your system:

� \inetpub\scripts\ctxsta.dll

� \inetpub\scripts\ctxxmlss.txt

� \inetpub\scripts\ctxsta.config

� \inetpub\scripts\ctxsta.log

� %systemroot%\system32\ctxsecgwytaperf.dll

If any of the above files are missing, reinstall the STA software.


Checking Configuration ValuesCheck that you configured the STA correctly. To check current configuration values, stop the World Wide Web Publishing Service and then run the Secure Ticket Authority Configuration utility.

" To stop the World Wide Web Publishing Service

1. Log on as administrator, to the Windows 2000 server on which the STA is running.




5. Right-click on World Wide Web Publishing Service, and select Stop.

" To run the STA Configuration utility

1. Log on as administrator, to the Windows 2000 server running the STA.

2. Click Start|Programs|Citrix|Secure Ticket Authority Configuration.

3. Check that configuration values specified are correct.

Note You must restart the World Wide Web Publishing Service if you made changes to the configuration settings.

" To restart the World Wide Web Publishing Service

1. Log on as administrator, to the Windows 2000 server running the STA.




5. Right-click on World Wide Web Publishing Service, and select Start.


netstat -a -nYou should see an entry representing port 80, which is the port IIS is listening on.


Troubleshooting the NFuse Web serverTo ensure that the NFuse Web server is functioning correctly, do the following:

� Ensure that the World Wide Publishing Service has been started and is functional

� Check network connectivity

� Ensure the sample Citrix Secure Gateway Web site is functional

� Check values specified in configuration files

Ensuring that the World Wide Web Publishing Service is Functional

" To ensure that the World Wide Web Publishing Service is functional

1. Log on as administrator, to the Windows 2000 server on which the NFuse Web server is running




5. Ensure that the World Wide Web Publishing Service has been started and is running.


netstat -a -nYou should see an entry representing port 80, which is the port IIS is listening on.


Checking Network ConnectivityTo check that you have network connectivity on the server running NFuse, ping the machines that NFuse communicates with.

" To ping the STA

1. At the command prompt, ping the STA using its FQDN

ping sta01.company.com2. Ensure that the IP address resolved, matches the one you recorded previously.

" To ping the Citrix XML Service in the MetaFrame Server farm

1. At the command prompt, ping the MetaFrame server running the Citrix XML Service using its FQDN.

ping mfserver01.company.com2. Ensure that the IP address resolved, matches the one you recorded previously.

Ensuring that the NFuse Web site is Functional" To check that the sample Citrix Secure Gateway Web site is functional

1. Use a Web browser on a client device to connect to the Citrix Secure Gateway Web site on the NFuse Web server.

2. Log on to ensure that your published applications are enumerated and presented correctly.

If this does not occur, then revisit your NFuse and MetaFrame software installations. Refer to your NFuse and MetaFrame documentation for more information. It is unlikely that Citrix Secure Gateway has caused this to happen.


Checking Configuration ValuesInstallation of NFuse Extensions creates a sample Web site on your NFuse Web server. Check that the configuration settings for the sample Web site are correct for your environment.

" To check current configuration values

1. Log on as administrator, to the NFuse Web server.

2. Click Start|Programs|Citrix|Citrix Secure Gateway|NFuse Extensions Configuration.

3. Check that configuration values specified are correct. Alternatively, you can manually edit the configuration settings for the sample Web site.

However, before you edit the configuration files, stop the World Wide Publishing Service.

" To stop the World Wide Web Publishing Service

1. Log on as administrator, to the NFuse Web server.




5. Right-click on World Wide Web Publishing Service, and select Stop.

Checking Configuration Values for the sample Web site" To check that configuration values are correct

1. Edit the configuration file NFuse uses for the sample Web site, inetpub\wwwroot\csg\csg_conf.inc, using Notepad. A sample listing of the configuration file is shown below. Note that the values in this listing are for illustration purposes only. Please take particular note of the parameters in bold text.

2. Close, and save (if you made changes) the configuration file.


<%

' Citrix Secure Gateway Version 1.0' csg_conf.inc ' Citrix Secure Gateway NFuse Web site configuration file' Modify the parameters in this file to reflect the settings of your' Citrix Secure Gateway' Specify the FQDN or IP address of your MetaFrame master browser' machine. Ensure that the value you give is surrounded with quotes' as shown in the following example:

strCitrixServer = �mfserver01.company.com�

' Specify XML service port number for the above Citrix MetaFrame' server.

numCitrixServerPort = 80

' DO NOT MODIFY the following line

Dim rg_strSTAURL(7)

' Specify the STAs in your system.' IMPORTANT: numSTACount defines the number of active STAs in your' system.The maximum value is 7. The value of numSTACount is 1 (ONE)' less than the actual number of active STA, for example, if you' have 2 (two) active STAs, numSTAcount should be set to 1 (one).

Const numSTAcount = 0

' Specify the Secure Gateway Ticket Authority URLs below.' Ensure that the values you give are surrounded with quotes as shown' in the following example:

rg_strSTAURL(0) = �http://your_ticket_authority.yourdomain.com/scripts/CtxSta.dll�

rg_strSTAURL(1) = �http://your_ticket_authority_02.yourdomain.com/scripts/CtxSta.dll�







' The hostnames entered above should be the same as the FQDN recorded ' previously, with the ticket authority dll path and name appended,' e.g., /scripts/CtxSta.dll

' Port number can be specified if required, for example:' http://your_ticket_authority_01.yourdomain.com:80

%>


Checking Configuration Values in Template.icaThe template.ica file is used by NFuse to dynamically generate ICA files in response to ICA client requests for published applications. The template.ica file needs to contain the location of the Secure Gateway server on the network, in the SSLProxyHost field, so ICA client devices can establish connections to it.

" To check values in Template.ica

1. To do this, edit the \inetpub\wwwroot\csg\template.ica file using Notepad.

2. A sample listing of the template.ica file is shown below. Note that the values in this listing are for illustration purposes only. Take particular note of the parameters in bold text.

3. Close, and save (if you made changes) the configuration file.

; template.ica for the Citrix Secure Gateway, Version 1.0 Web site

; Copyright 2001 Citrix Systems, Inc. All rights reserved.

;

<[NFuse_setSessionField NFuse_ContentType=application/x-ica]>

<[NFuse_setSessionField NFuse_WindowType=seamless]>

[WFClient]

Version=2

ClientName=[NFuse_ClientName]

BrowserRetry=1

BrowserTimeout=20000

HttpBrowserAddress=!

TransportReconnectEnabled=Off

[ApplicationServers]

[NFuse_AppName]=

[[NFuse_AppName]]

Address=[NFuse_IPV4Address]

; When using alternate address for firewall traversal purposes,

; replace the �NFuse_IPV4Address� tag above with

; �NFuse_IPV4AddressAlternate�

<continued on page 96>


<continued from page 95>InitialProgram=#[NFuse_AppName]

DesiredColor=[NFuse_WindowColors]

TransportDriver=TCP/IP

WinStationDriver=ICA 3.0

AutologonAllowed=ON

; Specify the Citrix Secure Gateway Fully Qualified Domain Name; (FQDN) and port number here, the FQDN MUST match the exact name; used in the server certificate. e.g., csgwy.company.com:443

SSLProxyHost=csgwy.company.com:443

SSLEnable=On

SSLNoCACerts=0

SSLCiphers=ALL

BrowserProtocol=HTTPonTCP

[NFuse_Ticket]

<[NFuse_IFSESSIONFIELD sessionfield=�NFUSE_SOUNDTYPE�value=�basic�]>

ClientAudio=On

<[/NFuse_IFSESSIONFIELD]>

[NFuse_IcaWindow]

[NFuse_IcaEncryption]

SessionsharingKey=[NFuse_SessionSharingKey]

[EncRC5-0]

DriverNameWin16=pdc0w.dll

DriverNameWin32=pdc0n.dll

[EncRC5-40]



[EncRC5-56]



[EncRC5-128]



[Compress]

DriverNameWin16=pdcompw.dll

DriverNameWin32=pdcompn.dll


Restarting the World Wide Web Publishing Service" To restart the World Wide Web Publishing Service.

1. Log on as administrator, to the Windows 2000 server on which the STA is running




5. Right-click World Wide Web Publishing Service, and select Start.


netstat -a -n

You should see an entry representing port 80, (or port 443 in the case of a secure Web server), which is the port IIS is listening on.


Troubleshooting the ICA ClientThe procedure that follows focuses on troubleshooting the ICA Win32 Client, but the same concepts apply to the 6.20 or later versions of ICA Clients for Linux, Macintosh, and Java.

To ensure that the ICA Win32 Client is functioning correctly, do the following:

� Ensure that Windows supports 128-bit encryption on the ICA Win32 Client device

� Ensure that you are running Version 6.20 of the ICA Win32 Client.

� Check that the appropriate root certificate is installed, that the certificate is still valid, and has been issued by a trusted source.

� Check network connectivity

Checking for High Encryption Pack on Client DeviceThe ICA Win32 Client leverages 128-bit encryption capability available from the underlying 32-bit Windows operating system (Windows 95, Windows 98, Windows Me, Windows NT, or Windows 2000).

To enable 128-bit encryption you must install the High Encryption Pack on the client device. See �System Requirements� on page 22 for ICA Client device requirements.


" To check whether 128-bit encryption is supported on the client device

1. Open Internet Explorer, and click Help|About Internet Explorer in the Internet Explorer window. The following screen appears.

Note in the figure above that the Cipher Strength is 128-bit.If the cipher strength reported is less than 128-bit, click Update Information to read about software updates available from Microsoft Corp.


Checking the ICA Client VersionThe Citrix Secure Gateway is only compatible with ICA Client Versions 6.20, or later. If you are running an older version of the client software, you must upgrade to the latest version available.

" To check the version number of the ICA Win32 Client

1. Click Start|Programs|Citrix ICA Client|Citrix Program Neighborhood

2. In the Program Neighborhood window, click Help|About Program Neighborhood. The client version number is displayed at the top of the splash screen.

If your client version number is not 6.20 or later, then upgrade your ICA Client software.

Note The latest versions of Citrix ICA Clients are available for download from the Citrix Download site, http://www.citrix.com/download.

Checking the Root CertificateWhen attempting to launch a published application, if the client reports that it is attempting to connect to a server that it does not trust, ensure that you have the correct root certificate authority installed. Refer to the ICA Client Administrator�s Guide for information about installing certificates on the client operating system you are using.


Checking Network ConnectivityTo check that you have network connectivity on the client device, ping the machines that the ICA Client communicates with.

" To ping the NFuse Web Server

1. At the command prompt, ping the NFuse Web server using its FQDN

ping nfuse01.company.com

2. Check that the IP address resolved, matches the one you recorded previously (assuming no NAT is performed by an intermediate firewall).

" To ping the Secure Gateway Server

1. At the command prompt, ping the Secure Gateway server using its FQDN

ping csgwy.company.com

2. Check that the IP address resolved, matches the one you recorded previously (assuming no NAT is performed by an intermediate firewall).

If You Are Still Unable to Resolve the Problem �If you are still experiencing problems with your Citrix Secure Gateway deployment, please email [email protected] with details, and if possible screen captures of any error messages displayed by the system.

A P P E N D I X A

Using Citrix Secure Gateway In Relay Mode

This appendix gives you an understanding of Relay Mode operation of Citrix Secure Gateway, and also gives you instructions on how to install and configure the Secure Gateway in Relay Mode.

This appendix contains the following topics:

� Modes of Operation, page 104

� Relay Mode Explained, page 104

� Before You Install, page 107

� Installing the Secure Gateway Service in Relay Mode, page 109

� Testing Relay Mode Operation, page 116


Modes of OperationYou can use Citrix Secure Gateway in either Normal Mode or Relay Mode.

Normal ModeThe recommended mode of operation for Citrix Secure Gateway is Normal Mode. In Normal mode, the Secure Gateway server functions as an SSL gateway with authentication and authorization support provided by a secure NFuse Web server and a Secure Ticket Authority (STA). This is the native mode of operation, provides strong security, and is the recommended mode of operation.

Relay ModeYou can also use Citrix Secure Gateway in Relay Mode. The biggest difference in this mode is the absence of ticketing support provided by the STA. This mode of operation was implemented to provide more flexibility in the way the Secure Gateway is used.

In Relay mode, an ICA Client connects to a MetaFrame server or farm through the Secure Gateway server, which acts as a proxy. User authentication is performed by the MetaFrame server or farm.

In this mode, the Secure Gateway server functions as a SOCKS proxy, and supports ICA Client attempts to locate the Citrix XML Service, ICA browsing, and ICA connections through to a MetaFrame server.

Note The Citrix Secure Gateway, operating in Relay mode, can also be deployed in a Citrix server environment that uses NFuse.

Relay Mode ExplainedCitrix Secure Gateway uses a TCP port, typically port 443, to listen for SSL-secured connections. When it receives an ICA connection request, it verifies whether the requested server address exists in its Access Control List (ACL).

If the address exists, the Secure Gateway server lets the connection through. The MetaFrame server prompts the ICA Client for user credentials, typically NT domain credentials. Once authenticated, the ICA connection is established and ICA data begins to flow to and from the client and the server.

Once the connection is established, the Secure Gateway decrypts SSL data from the client before sending the data down to the MetaFrame server, and encrypts data from the MetaFrame server before forwarding it to the ICA Client.

Appendix A Using Citrix Secure Gateway In Relay Mode 105

The figure below illustrates the communications that take place between the ICA Client, the Secure Gateway Service, and a MetaFrame server farm.

� A remote user launches an ICA connection to the Secure Gateway server on port 443.

� The Secure Gateway server checks that the requested server address exists in its ACL. If it does, then the connection is let through.

� The MetaFrame server prompts the user to login using domain credentials. Once authenticated, the ICA connection is established and the published application or application list is made available to the user.

� The Secure Gateway server monitors data flowing through the connection, and encrypts and decrypts client-server communications.


Why You Should Use Relay ModeRelay mode is designed to provide flexibility in the way Citrix Secure Gateway is used. It is a simpler solution, and requires less hardware resources. The benefits of this mode of operation are:

� Compatibility with ICA Client deployments that do not include NFuse support. Relay mode can typically be used in secure corporate environments such as Intranets, LANs, and WANs

� Fully secures data, but provides relatively weaker authentication

� Enables use of Program Neighborhood to browse for applications, provided you make the changes outlined in �Modify the APPSRV.INI File on ICA Client Devices� on page 115

When You Should Not Use Relay ModeRelay Mode is not the recommended mode in which to use Citrix Secure Gateway. In this mode, Citrix Secure Gateway is essentially an SSL tunnel through your firewall. IP addresses of your servers are visible from the ICA Client. Be aware, that you are opening up a well-known port on your firewall, and of the associated risks in doing so.

When You Should Use Relay ModeCitrix Secure Gateway should only be used in Relay Mode when:

� You want to use Secure Gateway but do not want to use the ticketing support available through the STA.

� You want to use Secure Gateway but are not using NFuse, and do not intend to.

� You want to use Secure Gateway to secure your corporate Intranet, LAN, or WAN; and if your ICA Clients are connecting from a secure perimeter.


Before You InstallCompile the Following InformationCollate the following information before you begin installation of Citrix Secure Gateway in Relay Mode.

You will need to specify these values during the installation process. Note that the values in this listing are for illustration purposes only; replace them with specifics of your environment. The network and port addresses shown above are used to demonstrate a sample Secure Gateway deployment in the diagram below.


1. FQDN of the MetaFrame server running the Citrix XML Service.

mfserver01.company.com

2. IP addresses, or IP address ranges, and port numbers of MetaFrame server(s) that Secure Gateway Service is allowed to access. This list should also include separate entries for the MetaFrame servers running the Citrix XML Service used for HTTP browsing. Port number(s) used by MetaFrame servers for ICA traffic is typically 1494, and for the Citrix XML Service it is typically 80.

10.1.1.11−10.1.1.255:149410.1.1.11:8010.1.40.11−10.1.40.255:1494




443


Install CertificatesYou need a server certificate on the Secure Gateway server and a root certificate on the ICA Client device. See �Certificates Required Between ICA Clients and the Secure Gateway Server� on page 35 for conceptual information on the certificates required. Also see, �Installing Certificates� on page 39 for instructions on creating certificate requests and installing a server certificate on the Secure Gateway server.


Installing the Secure Gateway Service in Relay ModeRelay mode installation is a hidden option available in the Secure Gateway Service installer.

" To install the Secure Gateway Service

1. Disable the World Wide Publishing Service on the Windows 2000 server. IIS listens on port 443 by default, and this causes a conflict with the Secure Gateway Service. Also, ensure that port 443 on this server is not being used by any other Windows service.

2. Install root and server certificates. See �Installing Certificates� on page 22 for information on how to install certificates.

3. Copy the installer file, csg_gwy.msi, for the Secure Gateway Service to the local hard drive of this machine.

4. Open a command window and type:

msiexec /I csg_gwy.msi RELAYMODE=1

5. The installation program starts. You must complete the following tasks during installation:

� Accept the License Agreement

� View information specific to the installation of the Secure Gateway Service.

At this point, files required to run the Secure Gateway Service are installed to the %systemRoot%\system32\ctxsecgwy directory.


Configuring the Secure Gateway ServiceAfter you install the Secure Gateway Service, the Secure Gateway Service Configuration utility is launched. You need to enter the following information to correctly configure the Secure Gateway Service for use:

1. Select Typical or Advanced Configuration. Click Typical, to specify the minimum set of configuration values required to run the Secure Gateway Service. Click Advanced, if you are an expert user, and would prefer to specify all the configuration values required for Secure Gateway Service operation. Click Next.

2. Select a server certificate to be used by the Secure Gateway Service. The configuration wizard searches the system for installed server certificates, and presents a list for you to select from. Select the server certificate that you installed for use with the Secure Gateway Service. Click Next.


3. Define the Access Control List (ACL) containing the list of MetaFrame servers that the Secure Gateway Service is allowed to access. You may enter a range of IP addresses and ports, to include IP addresses of all MetaFrame servers in a given range. The listener port for ICA traffic is typically 1494.

Click Add to enter an IP address range and port. The Enter IP address range dialog appears.

If you are specifying a single IP address leave the End address field blank. Click OK. Click Next.

Important You must also define the IP address and port of any MetaFrame server on which the Citrix XML Service is running. The port listener for the Citrix XML Service is usually, port 80.


4. Enter the IP address and port of the interface, or NIC, that the Secure Gateway Service must monitor for incoming connection requests. The default value of 0.0.0.0:443 is used, if no specific IP address and port number are specified. Click Add to specify a new IP address and port. Click Next.

Important You must specify a port that the Secure Gateway Service will monitor for SSL traffic.

5. Specify values to configure connection parameters such as connection timeout, connection resume, and so on. Click Next.


6. Specify values to configure Secure Gateway logging operations. Click Next.

7. At this point, configuration of the Secure Gateway Service in relay mode is complete.

The server must be rebooted prior to starting the service. Clear the Restart Server check box if you would prefer to reboot the server manually. Click Finish to exit the utility.

Important If MetaFrame XP FR1 is being used in your environment, ensure that Citrix SSL Relay, if available on your MetaFrame servers, is either not installed or is disabled. You cannot use the Citrix Secure Gateway in an environment containing Citrix SSL Relay.


Start the Secure Gateway ServiceThe Secure Gateway Service is automatically started at boot up.

" To manually start or stop the Secure Gateway Service

1. On the Secure Gateway server, log on as administrator.




5. Select Secure Gateway Service, and click Action|Start (or Action|Stop) to start (or stop) the Secure Gateway Service.

Changing Secure Gateway Configuration SettingsTo change configuration settings entered during the install process at any time, run the Secure Gateway Service Configuration utility. We recommend that you stop the Secure Gateway Service before you make changes to the configuration.


1. Click Start|Programs|Citrix|Citrix Secure Gateway|Secure Gateway Service Configuration.

2. Make necessary changes. Changes made do not take effect until the service is restarted. The program restarts the server automatically, however, if you would prefer to do this manually, clear the Start Secure Gateway Service check box. Click Finish to exit the utility.


Modify the APPSRV.INI File on ICA Client DevicesModify the APPSRV.INI file on each client device so that ICA connections are always directed to the Secure Gateway server.

Modify the file %HOMEPATH%\Application Data\ICAClient\appsrv.ini for each user who uses the client device. The following parameters must be added or modified as shown below:

These modifications force the ICA Client to use SSL.

Important Note that these settings are enforced for all new custom connections and application sets that you deploy. Existing application sets and custom connection definitions need to be modified individually.

[WFClient]; Forces the ICA Client to use SSLSSLEnable=On

; This entry forces the ICA Client to connect to the FQDN and SSL port of the Secure Gateway server.SSLProxyHost=csgwy.company.com:443

; This field should either specify the address of the master ICA Browser to contact, or should be left empty.HttpBrowserAddress=


Using NFuse with Relay Mode" To use NFuse with Citrix Secure Gateway in Relay Mode

1. Modify the template.ica file located in \inetpub\wwwroot\csg\ on the NFuse Web server to include the following parameters:

2. Test your Relay mode installation as described in �Testing Relay Mode Operation� on page 116.

Testing Relay Mode OperationOnce you have completed installation, test your Secure Gateway deployment to ensure that it is functioning correctly.

" To test Relay mode operation

1. Ensure you have configured all your application sets and custom ICA connections to use SSL. Refer to the ICA Client Administrator�s Guide for instructions on how to do this.

2. Double-click an ICA connection to launch it. If you have not entered your user credentials for this application set or custom ICA connection, a login dialog box appears. Enter a valid user name, domain, and password. After a brief interval, the application window is displayed.

[WFClient]; Forces the ICA Client to use SSLSSLEnable=On

; This entry forces the ICA Client to connect to the FQDN and SSL port of the Secure Gateway server.SSLProxyHost=csgwy.company.com:443

; This field should either specify the address of the master ICA Browser to contact, or should be left empty.HttpBrowserAddress=


3. Open the ICA Connection Center and check the entry for the published application you have open.

You should see the string �\\Remote, 128-bit SSL� appended to the application names as shown above. Also, if you click on Properties in the ICA Connection Center screen, the status message shown below appears. Note that the encryption level field displays the string �Basic. 128-bit SSL in use.�

If you have trouble launching an ICA connection or connection fails, you need to revisit the installation procedure.

A P P E N D I X B

Error Messages

This appendix describes the system, error, warning, and informational messages that are recorded in log files for the Secure Gateway Service and the Secure Ticket Authority.

This appendix contains the following sections:

� Secure Gateway Service Messages, page 120

� Secure Ticket Authority Messages, page 126


Secure Gateway Service MessagesStatus MessagesThis section contains system messages that are logged when a normal operational event, such as starting or stopping the service occurs.

Error Number Error Message Description

CSG0001 Citrix Secure Gateway Service starting mode. The Secure Gateway Service was started in normal or relay mode. Mode is replaced by the system with either �Normal Mode� or �Relay Mode� to indicate the mode of operation.

CSG0002 Citrix Secure Gateway Service stopped. The service has been stopped.

CSG0003 Citrix Secure Gateway Service paused. The service was paused through the Windows Service Control Manager.

CSG0004 Citrix Secure Gateway Service continued. The service was resumed, after having been paused, through the Windows Service Control Manager.

CSG0005 Citrix Secure Gateway Service paused as active connections exceeded limit of maxconn.

The service was paused because the number of active connections has exceeded the maximum limit. maxconn is replaced by the current value of Maximum Connections.

CSG0006 Citrix Secure Gateway Service continued as active connections below threshold of connresume.

The service was resumed after having been paused as a result of error condition CSG0005; connresume is replaced by the value specified in Connection ResumeThe service is resumed because the number of active connections has dropped to the current value specified in Connection Resume.

CSG0007 Log file index reset to 000 (from 999). 1000 log files were generated in a 24-hr. period. The Secure Gateway service will now reuse the oldest log file, CSGyyyymmdd-000.log.

CSG0008 Application generated error code error number: �error string�.

This is a general purpose error that is used to report an application error received from the operating system.

Appendix B Error Messages 121

Fatal Error MessagesFatal error messages are logged as a result of operational failure that prevents the the Secure Gateway Service from starting.


CSG0101 Unable to initialize system. The service was unable to start because of an operational failure such as allocation of memory, starting worker threads, and so on.

CSG0102 Unable to read configuration from registry key value.

The service was unable to find its configuration in the registry and hence was not started. The key value is replaced with the missing registry key.

CSG0103 Invalid or missing configuration in registry key label for key value.

The service encountered an invalid or missing configuration value in the registry, and therefore could not start. key label and key value are replaced by the missing entries

CSG0104 Unable to bind to interface IP address:port. The service was unable to bind to the interface because the IP address:port specified is in use.

CSG0105 Unable to listen to interface, IP address. The service was unable to listen on the interface, IP address, specified because it is in use.

CSG0106 Insufficient memory to initialize system. The service was unable to start because there is insufficient memory available.

CSG0107 Invalid configuration entry for configuration value.

The service encountered an invalid configuration value in the registry, and therefore could not start.

CSG0108 Missing entry in configuration for configuration parameter.

The service encountered a missing configuration value in the registry, and therefore could not start.

CSG0109 Unable to access local computer name. The service could not resolve its local computer name, and therefore could not start.

CSG0110 Unable to open local certificate store. The service could not open the local certificate store to retrieve certificates.

CSG0111 Unable to find certificate for FQDN specified. The service could not find a certificate in its local certificate store for the specified FQDN.


CSG0112 Unable to acquire certificate credentials. The service was unable to initialize SChannel on Windows.

CSG0113 Unable to access log file directory, path. The service was unable to access the specified directory path where the application log file is to be written.

CSG0114 Unable to open log file, filename. The service was unable to write to the application log file, filename.



Service Error MessagesThese error messages are logged as a result of partial failure of the service.


CSG0201 Unable to initialize performance counters. The service was unable to access memory for performance counters. Performance counter data is not updated.

CSG0202 Insufficient memory to establish connection for client IP address.

The service is running low on memory and was unable to allocate sufficient memory to initialize an ICA connection for this client IP address. Increase system memory, or close unnecessary applications and services.

CSG0203 Error accepting connection from client IP address. Connection dropped.

The service was unable to complete the connection request from client IP address due to a TCP/IP error, an operating system error, and so on. Try stopping and restarting the service and/or reboot your machine.

CSG0204 Error removing oldest log file, file name. The service was unable to delete the oldest log file, specified by file name. The service attempts to delete the oldest log file when the number of log files reaches the maximum limit. This error could occur if the file is in use or its file attributes were changed.


Warning MessagesThese messages are logged as a result of events caused by corrupted data requests or data packets received, ticket time-outs, and so on.


CSG0301 Error parsing ticket from client IP address. A malformed ticket was received from this client IP address, and the service rejected it.

CSG0302 Error formatting STA request for client IP address. The service could not format a ticket validation request to the STA because of insufficient or bad information in the ticket from this client IP address.

CSG0303 Unable to send request to STA ID for client IP address.

The service could not communicate with the STA ID mentioned in the ticket from this client IP address.

CSG0304 Error receiving STA response for client IP address.

The service did not receive a response to ticket validation request, for this client IP address, from the STA.

CSG0305 Error invalid STA response for client IP address. The STA could not resolve the ticket validation request from the service for this client IP address. This could occur if the ticket timed out.

CSG0306 Unable to connect to server IP address 1 for client IP address 2.

The service could not connect to the MetaFrame server, at IP address 1, for this client, at IP address 2.

CSG0307 Unknown STA ID in request from client IP address.

The service does not recognize the STA ID passed in the ticket from this client IP address.

CSG0308 Connection from client IP address timed out. The service has timed out the connection from this client IP address, because the connection is taking longer than the configured time to establish. Possible causes are latency in the connection to the STA and the MetaFrame server.

CSG0309 Connection from client IP address failed SSL handshake.

The SSL handshake between this client IP address and the service failed. Possible causes could be that the server certificate was not accepted by the client, encryption level mismatch, or network errors that prevented the client from completing the handshake before the connection time-out limit.

CSG0310 Connection from client IP address failed SSL decryption.

The service refused the connection from this client IP address, due to bad SSL data.

CSG0311 Connection to server IP address not allowed. The service was unable to connect to the requested MetaFrame server IP address, because it is not permitted through the ACL in the registry. This only occurs in Relay mode.


Informational MessagesThese messages are logged as a result of client connection events.

Error Number Error Messages Description

CSG0401 Accepted connection from client IP address. The connection from this client IP address was accepted by the service

CSG0402 Client IP address sent ticket Ticket. This client IP address sent the service a Ticket. (Ticket is replaced by the full value of the ticket).

CSG0403 Request STA ID to resolve ticket Ticket. The service asked STA ID to resolve this Ticket.

CSG0404 Successful connection to server IP address 1 for client IP address 2.

Established a connection to the MetaFrame server at IP address 1, from the client at IP address 2.

CSG0405 Closed connection from client IP address 1 to server IP address 2.

Closed the connection between the client at IP address 1 to the MetaFrame server at IP address 2.


Secure Ticket Authority MessagesFatal Error MessagesThe following messages are logged when a fatal error occurs. In all these cases, the STA cannot be started and ticketing will fail. The best way to correct such problems is to reinstall the STA software.

Error Number Error Messages Description

CSG1001 Unable to read config file The configuration file is missing, or cannot be found.

CSG1002 Unable to initialize Random Generator The Random Generator is corrupted. The random generator is used to generate random number sequences that are used to encrypt tickets. If this component is not found or is malfunctioning, ticketing fails.

CSG1003 Unable to access XML translation file CtxXmlss.txt The CtxXmlss.txt file is the XML translation file used by the STA to translate input to Unicode.

CSG1004 Insufficient memory to initialize system The system is unable to allocate memory required for the application. This could be because the system is running low on memory. Close some applications before trying again.

CSG1005 Missing entry in config file for configuration parameter

Configuration parameter is not defined in the STA configuration file.


Application Error MessagesThe following messages are logged as a result of the STA experiencing operational problems. The system was started, but certain operations, such as generating performance data, fail.


CSG1101 Unable to initialize performance counters The service was unable to access memory for performance counters. Performance counter data is not updated.

CSG1102 No Ticket Store in memory Memory was not initialized at startup.

CSG1103 Unable to delete old log file The STA was unable to delete the oldest log file. The system attempts to delete the oldest log file when the number of log files reaches the maximum limit. This error could occur if the file is in use or its file attributes were changed.

CSG1104 Unable to access log directory The system is unable to access the directory specified for logging system messages. This could be because the directory doesn�t exist, or there are insufficient access privileges.


Warning MessagesThese messages are logged as a result of events caused by corrupted data requests or data packets received, ticket time-outs, and so on. In general, these errors are likely to occur when the data request originates from an unknown source.


CSG1201 Request Data - Parsing failed, bad XML Data request packet contains bad XML data and could not be parsed.

CSG1202 Request Data - No ticket or wrong ticket version in XML.

The request is not in the right format for the STA to resolve the ticket to its associated data. The request is rejected.

CSG1203 Request Data - Ticket not found. The ticket requested was not found. This could occur if the ticket timed out.

CSG1204 Request Ticket - Parsing failed, bad XML. The ticket request failed because the STA encountered unknown XML data. The ticket could not be parsed.

CSG1205 Request Ticket - No data or wrong type in XML. Data request packet received contains no data, or bad XML data. Ticketing failed.

CSG1206 Request Ticket - No memory to save data. The system is low on memory and could not save ticket request.

CSG1207 Request Ticket - Maximum reached, data NOT saved.

The maximum active ticket limit was reached. Ticketing failed. Increase the maximum ticket limit or reduce the ticket lifetime.

CSG1208 Request Ticket - Failed, data NOT saved. A system error occurred when trying to save this ticket.

CSG1209 Unused tickets still in IMDB at unload. The STA application was terminated abruptly. Unused tickets are still present in the In-Memory Database (IMDB)


Informational MessagesThese are information messages are logged as a result of normal STA operations.


CSG1301 CtxSTA.dll Loaded The STA was started.

CSG1302 CtxSTA.dll Unloaded The STA was unloaded (stopped).

CSG1303 Ticket Timed Out This ticket has reached the maximum ticket lifetime and has now expired.

CSG1304 Request Data - Successful This ticket data request was successful.

CSG1305 Request Ticket - Successful This ticket request was successful.

CSG1306 Log file index reset to 000 (from 999) 1000 log files were generated in a 24-hr. period. The STA will now reuse the oldest log file, STAyyyymmdd-000.log.

A P P E N D I X C

Glossary

This appendix provides a glossary of terms and acronyms used throughout the Citrix Secure Gateway documentation.

Access Control List (ACL) In the context of the Secure Gateway Service (Relay Mode only), an Access Control List (ACL) is a mechanism that restricts access to resources. The ACL is a data structure containing the IP addresses and ports of MetaFrame servers on the network that the Secure Gateway server has access to.

authentication The process of identifying an individual, usually based on a username and password. In security systems, authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual.

authorization The process of granting or denying access to a network resource. Most computer security systems are based on a two-step process. The first stage is authentication, which ensures that a user is who he or she claims to be. The second stage is authorization, which allows the user access to various resources based on the user's identity.

certificate An attachment to electronic data used for security purposes. The most common use of a digital certificate is to verify that a user sending the data is who he or she claims to be, and to provide the receiver with the means to encode a reply.

ciphersuites An encryption/decryption algorithm. When establishing an SSL connection, the client and server determine a common set of supported ciphersuites and then use the most secure one to encrypt the communications. These algorithms have differing advantages in terms of speed, encryption strength, exportability, and so on.


Citrix Secure Gateway A software solution which provides a secure encrypted channel for ICA traffic over the Internet, using SSL (Secure Sockets Layer) between ICA Clients and the Secure Gateway. Citrix Secure Gateway provides a single point of encryption and access into MetaFrame server farms. Citrix Secure Gateway consists of three software components, namely, the Secure Gateway Service, the Secure Ticket Authority and NFuse Extensions.

Citrix XML Service A Windows NT service that provides an HTTP interface to the ICA Browser. It uses TCP packets instead of UDP, which allows connections to work across most firewalls. The default port for the Citrix XML Service is 80.

ICA Independent Computing Architecture. The architecture that Citrix uses to separate an application�s logic from its user interface. With ICA, only the keystrokes, mouse clicks, and screen updates pass between the client and server on the network, while 100% of the application�s logic executes on the server.

ICA Client Citrix software that enables users to connect to Citrix servers from a variety of client devices.

ICA connection 1. The logical port used by an ICA Client to connect to, and start a session on, a Citrix server. An ICA connection is associated with a network connection (such as TCP/IP, IPX, SPX, or NetBIOS) or a serial connection (modems or direct cables). 2. The active link established between an ICA Client and a Citrix server.

ICA file (.ica) A text file (with the extension .ica) containing information about a published application. ICA files are written in Windows .ini file format and organize published application information in a standard way that ICA Clients can interpret. When an ICA Client receives an ICA file, it initializes a session running the specified application on the Citrix server specified in the file.

ICA protocol The protocol that ICA Clients use to format user input (keystrokes, mouse clicks, and so forth) and address it to Citrix servers for processing. Citrix servers use it to format application output (display, audio, and so forth) and return it to the client device.

ICA session A lasting connection between an ICA Client and a Citrix server, identified by a specific user ID and ICA connection. It consists of the status of the connection, the server resources allocated to the user for the duration of the session, and any applications executing during the session. An ICA session normally terminates when the ICA Client user logs off the Citrix server.

MetaFrame® This term, the product name for a family of server-based computing solutions, is a Citrix registered trademark.

NFuseTM A Citrix product, NFuse is an Internet portal technology that provides the ability to integrate and publish interactive applications into any standard Web browser. A three-tiered solution, it includes a Citrix server, a Web server, and a client device with a Web browser. This name is a Citrix trademark.

Appendix C Glossary 133

NFuse Extensions This is a Citrix Secure Gateway specific component that must be installed on a NFuse 1.51 or 1.6 Web server to provide Secure Gateway compatibility. Future versions of NFuse will natively support Citrix Secure Gateway, and this component may not be required.

Program NeighborhoodTM The user interface for the ICA Win32 and ICA Java Clients, which lets users view the published applications they are authorized to use in the server farm. Program Neighborhood contains application sets and custom ICA connections.

published application An application installed on a Citrix server or server farm that is configured for multiuser access from ICA Clients. With Load Manager, you can manage the load for published applications among servers in the server farm. With Program Neighborhood and NFuse, you can push a published application to your users� client desktops.

Relay Mode Mode of use of the Citrix Secure Gateway solution in which the STA is not used. This means that the Secure Gateway Service functions without ticketing support. This is a less secure mode in which the Secure Gateway Service functions as a proxy server and provides a single point of contact to a MetaFrame farm. This allows ICA Clients to use HTTP browsing or ICA files, to establish connections to a MetaFrame server farm.

Secure Gateway Service A Citrix Secure Gateway component that functions as an SSL gateway between ICA Clients and a MetaFrame farm. The Secure Gateway Service runs as a service on a Windows 2000 server.

Secure Ticket Authority (STA) The STA is a ticketing mechanism that issues �tickets� for ICA connections. These tickets form the basis of authentication and authorization for ICA connections to a MetaFrame server.

server farm A group of Citrix servers managed as a single entity (or �system image�), with some form of physical connection between the member servers and an IMA-based data store, thus providing centralized administration and horizontal scalability.

session ID A unique identifier for a specific ICA session on a specific Citrix server.

135

Index

.ica 132

AAccess Control List 104, 111, 131ACL. See Access Control Listauthentication 31, 131authorization 131

Bbenefits of SSL 28

CCAs. See certificate authoritycertificate authority 31certificate request 40

how to 40Certificate Revocation List 32certificates 131

how to get them 37certificates required

fully secured installation 36cipher 29ciphersuites 131

COM 78GOV 78modifying Windows registry settings 79registry keys 79restricting usage 78

Citrix 73Citrix Documentation Library 19Citrix Secure Gateway. See Secure GatewayCitrix SSL Relay 113Citrix Web site 19Citrix XML Service 132COM 78connection keepalive settings 76Contacting Support 101context-sensitive Help 48CRL. See Certificate Revocation Listcryptography 29

Ddemilitarized zone. See DMZdigital certificate

types 33digital certificates 39

format 31DMZ 78

Eerror logs 66

configuring 67error messages 119

FFAQ 19fault tolerance 73FQDN 38Frequently Asked Questions 19

GGOV 78

Hhash function 29high availability 73

planning 73

IICA

clients 132connection 132file 132protocol 132session 132sessions 132

ICA Clientsdownloading 19

ICA connectionsdefined 132


IISsecuring 79

IIS Lockdown tool 79installation

Citrix Secure Gateway 45relay mode 109Secure Gateway Service 52sequence 47server certificates 40STA 49

ISAPI 49ISO X.509 31

Kkeepalive settings 76

Lload balancing

benefits 74certificates required 73Secure Gateway array 74SSL accelerator cards 75

load-balancingcertificate requirements 75certificates required 75

log filesnaming convention 67rollover criteria 66

logging parameters 67

MMetaFrame

keepalive settings 77

monitoring performance 68

NNFuse 132NFuse Extensions 9, 133normal mode 104

Pperformance monitoring

objects 69why it is useful 68

pre-installation taskscompile information 46

Program Neighborhood 133published application 133

Rrecommendations for secure environments 78redundancy 73relay mode 104, 133

benefits 106certificates 108changing configuration settings 114compiling information 107configuration 109configuring for use 110explained 104how it works 105how to use NFuse 109ICA Client modifications 109install certificates 108installation 109installation command 109pre-installation tasks 107starting the service 113testing 109what is it 104

root certificate 31, 33, 44installation on ICA Client 44installation on NFuse 44

Index 137

SSecure Gateway

accessing performance data 69advanced concepts 65best practices 78connection keepalive settings 76context-sensitive Help 48deployment scenario 47executive summary 9fatal error messages 121glossary of terms 131high availability 73information messages 125installation 45load balanced cluster 74load-balancing 73load-balancing an array 74modes of operation 104monitoring performance 68performance counters 70performance monitoring 68performance objects 69pre-installation tasks 45proprietary error logs 66relay mode 103, 133scaling 73status messages 120warning messages 124

Secure Gateway Service 133changing configuration 56configuration 53error messages 119event logging 66installation 52modes of operation 104performance counters 70starting 56

Secure Ticket Authority. See STAsecuring Web servers 79security concepts 27server certificate 33

applying for one 41creating a certificate request 40how to install 41tips 43verification 42

server farm 133server farms

defined 133

session ID 133Solution Knowledgebase 19SSL 28

128-bit 28strength 28

STA 133application errors 127changing configuration settings 51configuration 50ensuring high availability 76fatal error messages 126information messages 129installation 49performance counters 72planning for high availability 76using multiple STA servers 76warning messages 128warnings 128

Ttest server certificates 40troubleshooting ICA Client

check network connectivity 101Client version 100High Encryption 98

troubleshooting NFusecheck configuration 93check network connectivity 92check sample Web site 92check values in template.ica 95instructions 91

troubleshooting the ICA Clientinstructions 98

troubleshooting the Secure Gatewaycheck certificates 83check configuration 87check error logs 83check network connectivity 86start-up errors 87

troubleshooting the STAcheck configuration 90check error logs 88check system files 89directory access problems 88instructions 88

types of cryptography 29


WWindows registry

keepalive parameters 76

Citrix Secure Gateway - DABCC · Citrix Secure Gateway provides a gateway separate from the...

Documents

Transcript of Citrix Secure Gateway - DABCC · Citrix Secure Gateway provides a gateway separate from the...