Deployment and Installation Center
Websense TRITON Enterprise v7.6.x

Go to the table of contents Go to the previous page Go to the next page Go to the index
Deploying Websense Content Gateway > Content Gateway deployment issues

A plan to deploy Websense Content Gateway as a proxy in your network involves more than physical site requirements like plant size, the power and cooling requirements for the hardware, available rack space, and network connectivity. You should also consider some of the following issues:
Websense Content Gateway is used in either an explicit or transparent proxy deployment. With an explicit proxy deployment, client software is configured to send a request for Internet content directly to Websense Content Gateway. In a transparent proxy deployment, a client request for Web content is intercepted (usually by a router) and sent to the proxy, and the client is unaware that it is communicating with a proxy.
A Websense Content Gateway deployment can scale from a single node to multiple nodes to form management cluster. With management clustering, all the nodes in a cluster share configuration information. A configuration change on one node is automatically made in all other nodes.
When SSL Manager is enabled to perform HTTPS content inspection, SLL configuration information can also be propagated around the cluster, however it uses a different mechanism that requires separate configuration.
See Clusters in Content Gateway Manager online Help for information about configuring proxy clusters.
When enabled, the IP spoofing feature directs the proxy to use the client IP address when establishing a connection to an origin server, rather than the proxy's IP address. With this option, a request appears to be from the client, not the proxy. IP spoofing is supported only in transparent proxy deployments. You should note that if IP spoofing is implemented, the client IP address is used for all HTTP and HTTPS requests in transparent proxy deployments.
Warning 
Deploying IP spoofing requires precise control of the routing paths on your network, overriding the normal routing process for traffic running on TCP port 80 and 443.
With IP spoofing enabled, traditional debugging tools such as traceroute and ping have limited utility.
You might want to implement this feature, for example, if an upstream network device is used to log HTTP/S traffic, perform authentication, or access controls based on the client IP address.
Authentication is the process of verifying a user via a username and password. User authentication may be configured on Websense Content Gateway. User identification is the process of identifying a user based on the client IP address. TRITON - Web Security offers a robust set of user identification agents.
Websense Content Gateway can be configured for transparent user authentication -- with Integrated Windows® Authentication (IWA) and Legacy NTLM -- in which case users are not prompted for credentials, or for prompted (or manual) authentication, in which case users are required to enter a username and password for network access.
Note 
Not all Web browsers support both transparent and prompted authentication modes. See Security in the Content Gateway Manager online Help for specific browser limitations.
In the manual authentication process, Content Gateway prompts a user for proxy login credentials when that user requests Internet content. After the user enters those credentials, the proxy sends them to a directory server, which validates the data. If the directory server accepts the user's credentials, the proxy delivers the requested content. Otherwise, the user's request is denied.
The issue of proxy authentication is important in a deployment in which multiple proxies are chained. Authentication by the proxy closest to the client is preferred, but may not be possible given a particular network's configuration. Other issues include whether Content Gateway is chained with a third-party proxy and which proxy is designated to perform authentication. See In a proxy chain for more information.
u
Legacy NTLM (Windows NT® LAN Manager, NTLMSSP)
Content Gateway supports both transparent and prompted authentication for Integrated Windows Authentication and Legacy NTLM. LDAP and RADIUS support prompted authentication.
Content Gateway also supports multiple realm authentication. Multiple realm authentication is for environments that have multiple domains that are essentially isolated for the purposes of user authentication by a lack of mutual inbound and outbound trust relationships. Therefore, users in these domains must be authenticated by a domain controller within their domain. Multiple realm authentication allows distinct authentication rules to be written for each domain, thereby supporting the ability to use multiple authentication methods (IWA, legacy NTLM, LDAP) at the same time.
See Security in the Content Gateway Manager online Help for detailed information about configuring all these proxy authentication options.
You can configure user identification in TRITON - Web Security rather than user authentication on the proxy. Methods of user identification include the use of Websense transparent identification (XID) agents like Logon Agent or DC Agent, which identify users transparently. Prompted authentication, which requires users to enter login credentials, can also be configured in TRITON - Web Security. See User Identification in the TRITON - Web Security Help for more information.
When you use Websense Content Gateway with SSL Manager enabled, HTTPS data can be decrypted, inspected for policy, and then re-encrypted as it travels from the client to the origin server and back. Enabling this feature also means that traffic from the server to the client can be inspected for Web 2.0 and uncategorized sites. The SSL feature includes a complete set of certificate-handling capabilities. See the Content Gateway Manager online Help for information on managing certificates.
u
Creation of trusted Certificate Authority (CA) certificates for each proxy to use for SSL traffic interception, and the installation of those certificates in each trusted root certificate store used by proxied applications and browsers on each client
u
In explicit proxy deployments, additional client configuration in the form of Proxy Auto-Configuration (PAC) files or Web Proxy Auto-Discovery (WPAD)
Note 
HTTPS content inspection can also affect system hardware resources like processing capacity and memory requirements.
When Content Gateway is configured to handle HTTPS traffic, category bypass settings can be used to specify categories of Web sites for which decryption and inspection are bypassed. You can also maintain a list of hostnames or IP addresses for which SSL decryption is not performed. See Scanning and SSL Bypass Options in TRITON - Web Security Help for more information.
Any Websense Content Gateway deployment must be able to handle Web site requests and applications that are not compatible with the proxy or that should bypass the proxy. For example, requests for data from some internal, trusted sites could be configured to bypass the proxy, for system performance reasons. In explicit proxy deployments, a PAC file can be used to list the traffic that is allowed to bypass proxy inspection. In transparent proxy deployments, the proxy must be installed in a way that allows static bypass. See the "Static bypass rules" section of Transparent Proxy Caching and ARM in Content Gateway Manager online Help.
The deployment should also be able to manage situations in which key fobs or tokens are used to access the network and for cases of highly coupled client/server Web applications. The type of proxy deployment determines how these situations are handled.


Go to the table of contents Go to the previous page Go to the next page Go to the index
Deploying Websense Content Gateway > Content Gateway deployment issues