Secure Gateway is secure reverse proxy server for SOCKS, HTTP or CGP traffic. CGP stands for
Citrix Gateway Protocol, a TCP tunneling protocol developed by Citrix and currently used only by
the Gateway Client for Secure Access Manager. A server will proxy unauthenticated
HTTP requests to one web server (referred to as the Logon Agent or Web Interface server), and will
proxy authenticated HTTP requests to a different server (usually MetaFrame Secure Access
Manager). Any ICA requests arriving at the Secure Gateway server must contain a secure ticket
granted by a Secure Ticket Authority (STA). Tickets are requested from the STA for authenticated
users or MetaFrame Secure Access Manager.
A convenient feature is that it allows to be hosted on the same
server. HTTPS traffic arriving at the gateway is decrypted and relayed to a web server running on the
same machine. This allows Web Interface and to share a single IP address and SSL
certificate.
Problem: Placing behind Reverse Proxy
Causes SSL Error 4
Combining Web Interface and Secure Gateway can create confusion if another reverse web proxy is
placed between the client and Secure Gateway. This scenario does not generally cause problems with
HTTPS traffic destined for it, but it cannot be used for ICA/SSL
traffic. When a combination Secure Gateway server is placed behind a reverse web
proxy, users are able to log into Web Interface and enumerate application icons (all HTTP
communications), but attempting to launch a published application results in SSL Error 4. This
happens because the ICA/SSL session is terminated by it, not the Secure
Gateway server
Here the it is viewed as a "man in the middle" compromising the
integrity of the ICA/SSL network stream. This causes the SSL handshake between the ICA Client and
to fail.
There following sections describe two possible solutions to this problem.
Solution One: Run it Parallel to the Reverse Web Proxy
Separate Web Interface and onto two machines. Place the server running Web
Interface behind the reverse web proxy and place the server parallel to the reverse
web proxy.

This scenario is still secure, and any security policies defined at the will still affect
all its users. In order to traverse the it, users must first satisfy the reverse
web proxy and log into Web Interface in order to obtain a ticket from the STA. Therefore any access
control rules defined at the will affect users wishing to gain entry through Secure
Gateway as well.
Solution Two: Use NAT instead of a Reverse Web Proxy
If the reverse proxy is configured to forward all traffic (not just HTTP traffic) to the combination
Web Interface server, then SSL is not terminated at the proxy and users are able to
connect through Secure Gateway. Different vendors refer to this deployment style in different ways.

This approach has the disadvantage that some control must be sacrificed regarding the type of traffic
that is permitted to traverse the proxy. Incoming traffic must be routed directly to the Secure
Gateway/Web Interface server without being decrypted, authenticated or inspected. From a security
standpoint, this is not much different from exposing the server directly to the
Internet. There is a logical SSL "tunnel" between the client and Secure Gateway.