After you have configured NAT and packet filtering on your network, use
the Secure Gateway Diagnostics tool to confirm that the Secure Gateway is
configured correctly and that it is able to resolve addresses and communicate
with servers located in the DMZ and the secure network. Troubleshooting
information concerning firewall traversal, Domain Name Service (DNS), and
Network Address Translation (NAT) are beyond the scope of this document.
Run the Secure Gateway Diagnostics tool on the server running the Secure
Gateway and examine the results reported. The report contains configuration
values for the Secure Gateway and results of connection attempts to components
and services in the DMZ and secure network that the Secure Gateway uses.
For instructions about using the Secure Gateway Diagnostics tool, see
Generating the Secure Gateway Diagnostics Report.
Careful review of the Secure Gateway event log can help you identify the
sources of system problems. For example, if log warnings show that the Secure
Gateway failed because it could not locate the specified certificate, you can
conclude that the certificate is missing or installed in the incorrect
certificate store. In general, information in the event log helps you trace a
record of activity leading up to the event of failure.
If you receive an error: The Secure Gateway Fails with a CSG0188 Error,
the error implies that SChannel could not validate certificate credentials of
the server certificate used by the Secure Gateway. Ensure that the certificate
installed was issued by a trusted source, is still valid, and is issued for the
For more troubleshooting information, see the Citrix support Web site at
technical support options.
Client Connections Launched from IP Addresses in the Logging
Exclusions List Fail
For security reasons, IP addresses configured in the logging
exclusions list are not allowed to establish connections to the Secure Gateway.
This measure blocks connections to the Secure Gateway that do not leave an
The logging exclusions list is designed to help keep the system log
free of redundant data. Configure the IP address of load balancing devices in
the Logging Exclusions list. Configuring an exclusions list enables the Secure
Gateway to ignore polling activity from such devices and keeps the log free of
this type of data.
Load Balancers Do Not Report Active Client Sessions if Connections
Some load balancers stop reporting active client connections flowing
through them if the connections are idle for a while because of the way in
which certain load balancers treat idle connections.
Connections that are idle for a certain amount of time stop being
represented as active connections in the load balancer’s reporting tools even
though the connections are still valid.
Resolve this issue by modifying the keep–alive settings in the Windows
registry on the server(s) running the Secure Gateway.
If you load balance an array of servers running the Secure Gateway,
decrease the keep–alive values to force packets to be sent after a period of
Performance Issues with Transferring Files Between a User Device
and a Citrix XenApp Server
Users may experience performance issues with data transfer using
client drive mapping on high bandwidth, high latency connections.
As a workaround, you can optimize throughput by increasing the value
of TcpWindowSize in the Windows registry of your server running the Secure
Caution: Using the Registry Editor incorrectly can cause
serious problems that may require you to reinstall your operating system.
Citrix cannot guarantee resolution of problems resulting from the incorrect use
of Registry Editor. Use Registry Editor at your own risk.
To modify this setting, edit the following Windows Registry key:
Citrix recommends setting the value of TCPWindowSize to 0xFFFF(64K).
Be aware that this change incurs higher system memory usage. Citrix
recommends increasing physical system memory on the server running the Secure
Gateway to suit the typical usage profile of the network.
Gateway Client Connections Fail When Using Windows XP Service Pack
Windows XP Service Pack 2 prevents connections to all IP addresses
that are in the loopback address range except for 127.0.0.1. If the Gateway
Client is using a loopback address other than 127.0.0.1, the connection to the
Secure Gateway fails.
Microsoft provides a patch to fix this issue. For more information,
refer to the Microsoft Knowledgebase Article “Programs that connect to IP
addresses that in the loopback address range may not work as you expect in
Windows XP Service Pack 2 (884020)” available from the Microsoft Support Web
Failed Client Connections to the Secure Gateway Result in
Duplicate Entries in the Secure Gateway Log
You may find duplicate entries for client connection attempts in the
Secure Gateway application and performance logs. Duplicate entries can occur in
the following situations:
- SSL protocol mismatch between the user device and the server
running the Secure Gateway
- Client automatically attempts to reconnect if the first connection
The log entries are actually a record of client behavior. In these
cases, the client attempts to reconnect if it fails the first time.
Placing the Secure Gateway Behind a Reverse Web Proxy Causes an
SSL Error 4
If the Web Interface and the Secure Gateway are on the same server, it
can create confusion if a reverse Web proxy is placed between the client and
the Secure Gateway. Clients can communicate with the enterprise network using
HTTPS but traffic for ICA/SSL is refused. When a combination of the Web
Interface and the Secure Gateway is placed behind a reverse Web proxy server,
users can log on using the Web Interface and enumerate application icons, which
is all HTTP communications. When users launch a published application, they
receive an SSL Error 4 because the ICA/SSL session is terminated by the reverse
Web proxy, not by the Secure Gateway.
This graphic shows the incorrect placement of the Secure Gateway and
Web Interface behind a reverse Web proxy.
The Secure Gateway views the reverse Web proxy as a “man in the
middle” that compromises the integrity of the ICA/SSL network stream. This
causes the SSL handshake between the client and the Secure Gateway to fail.
There are two possible solutions to correct this problem:
- Run the Secure Gateway parallel to the reverse Web proxy
- Use a network address translator (NAT) in place of the reverse Web
Run the Secure Gateway Parallel to the Reverse Web Proxy
The Secure Gateway and the Web Interface are installed on two separate
servers. The server running the Web Interface is behind the reverse Web proxy.
The Secure Gateway is parallel to the reverse Web proxy.
This graphic shows the correct placement of the Secure Gateway, which
is parallel to the reverse Web proxy.
Placing the Secure Gateway parallel to the reverse Web proxy provides
a secure solution. Security policies that are defined on the reverse Web proxy
continue to affect all Secure Gateway users. To cross the Secure Gateway, users
must first satisfy the reverse Web proxy and log on to the Web Interface to get
a ticket from the STA. Any access control rules that are defined on the reverse
Web proxy affects users who are also trying to gain entry through the Secure
Use a Network Address Translator Instead of a Reverse Web
If the reverse Web proxy is configured to forward all network traffic
(not just HTTP traffic) to the combination Secure Gateway and Web Interface,
the SSL connection is not terminated at the proxy and users can connect through
the Secure Gateway. The following figure is an example of how different vendors
refer to this type of deployment.
This graphic shows the use of a network address translator instead of
a reverse Web proxy.
This approach has the disadvantage that some control must be
sacrificed regarding the type of traffic that is permitted to cross the proxy.
Incoming traffic must be routed directly to the Secure Gateway and the Web
Interface without being decrypted, authenticated, or inspected. From a security
standpoint, this is not much different from exposing the Secure Gateway server
directly to the Internet. There is a logical SSL tunnel between the client and
the Secure Gateway.