Go to the table of contents Go to the previous page Go to the next page
Content Gateway Deployment > Special Content Gateway deployment scenarios
An explicit proxy deployment for high availability can benefit from the use of virtual IP failover. IP addresses may be assigned dynamically in a proxy cluster, so that one proxy can assume traffic-handling capabilities when another proxy fails. Websense Content Gateway maintains a pool of virtual IP addresses that it distributes across the nodes of a cluster. If Content Gateway detects a hard node failure (such as a power supply or CPU failure), it reassigns IP addresses of the failed node to the operational nodes.
Websense Content Gateway can be deployed in a network that contains multiple proxy machines, including one or more third-party proxies. A proxy chain deployment can involve different scenarios, depending on where Content Gateway is located in relation to the client. The proxy that is closest to the client is called the downstream proxy. Other proxies are upstream.
See Chaining Content Gateway with other proxies for specific instructions on using Blue Coat® ProxySG® or Microsoft® Forefront® Threat Management Gateway as the downstream proxy.
The X-Forwarded-For HTTP header is the de facto standard for identifying the originating IP address of a client connecting through an HTTP proxy. Some proxies do not utilize the X-Forwarded-For header.
Set the Read authentication from child proxy option on the Content Gateway Configure page (Configure > My Proxy > Basic > Authentication). This option allows Content Gateway to read the X-Forwarded-For and X-Authenticated-User HTTP headers. The downstream third-party proxy passes the client IP address via the X-Forwarded-For header and the user domain and username in the X-Authenticated-User header.
See Hierarchical Caching in Content Gateway Manager Help.
Routing SSL traffic in a proxy chain involves the same parent proxy configuration settings used with other proxy-chained traffic. You identify the ports on which HTTPS requests should be decrypted and policy applied when SSL is enabled in the Protocols  > HTTP > HTTPS Ports option in the Configure tab. Parent proxy rules established in parent.config for HTTPS traffic (destination port 443) determine the next proxy in the chain for that traffic.
Enable the Configure tab Content Routing > Hierarchies > HTTPS Requests Bypass Parent option to disable SSL traffic chaining when all other traffic is chained.
If you want to exclude SSL traffic from the parent proxy and tunnel the traffic directly to the origin server, enable the Tunnel Requests Bypass Parent option in the Configure tab Content Routing > Hierarchies. This option can be used for any tunneled traffic.

Go to the table of contents Go to the previous page Go to the next page
Content Gateway Deployment > Special Content Gateway deployment scenarios