Product Documentation

Troubleshooting the Secure Gateway

Sep 15, 2015

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 correct computer.

For more troubleshooting information, see the Citrix support Web site at for technical support options.

To check your certificates

  1. Log on as an administrator to the server running the Secure Gateway.
  2. Open the Secure Gateway Configuration Wizard.
  3. Select the products you want to secure and then click OK.
  4. On the Secure Gateway configuration level screen, select Advanced.
  5. In the Select server certificate dialog box, select the certificate the Secure Gateway is configured to use and click View.
  6. Check that the value in the Issued To field matches the FQDN of this server.
  7. When you view the certificate, ensure that it contains a key icon and the caption “You have private key that corresponds to this certificate” at the bottom of the General tab. The lack of an associated private key can result in the CSG0188 error.
  8. Ensure the certificate is not expired. If it is expired, you need to apply for certificate renewal. Contact the appropriate resources in your company for assistance with certificate renewal.

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 audit trail.

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 Are Idle

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 session inactivity.

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 Gateway.

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip \Parameters\TcpWindowSize

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 2

Windows XP Service Pack 2 prevents connections to all IP addresses that are in the loopback address range except for If the Gateway Client is using a loopback address other than, 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 site at

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 attempts fails

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:

  1. Run the Secure Gateway parallel to the reverse Web proxy
  2. Use a network address translator (NAT) in place of the reverse Web proxy

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 Gateway.

Use a Network Address Translator Instead of a Reverse Web Proxy

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.

Shows use of a network address translator instead of a reverse Web proxy

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.