Content Gateway deployment issues

Deployment and Installation Center | Web Security Solutions | Version 7.7.x

Applies to:

In this topic

Web Security Gateway and Gateway Anywhere, v7.7.x

Proxy deployment options

User authentication

HTTPS content inspection

Handling special cases

Planning to deploy Websense Content Gateway as a proxy in your network should include physical requirements, such as:

data center location and space

power and cooling requirements for hardware

required rack space

connectivity to existing or extended network topology

Also consider:

Content Gateway system requirements (hardware and operating system)

Advantages and disadvantages of proxy network configuration options

User authentication and identification options

How to configure and use HTTPS content inspection

A plan for handling special proxy/client issues

Proxy deployment options

Websense Content Gateway is used in either an explicit or transparent proxy deployment.

With an explicit proxy deployment, client software, typically a Web browser, is configured to send a request for Internet content directly to Content Gateway.

In a transparent proxy deployment, a client request for Web content is intercepted (usually by a router) and sent to the proxy. The client is unaware that it is communicating with a proxy.

Both options have advantages and disadvantages. See Content Gateway explicit and transparent proxy deployments for more information.

Management clustering

A Websense Content Gateway deployment can scale from a single node to multiple nodes to form a management cluster. With management clustering, all the nodes in the cluster share configuration information. A configuration change on one node is automatically propagated all other nodes.

When SSL Manager is enabled to perform HTTPS content inspection, SSL 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 Help for information about configuring Content Gateway clusters.

IP spoofing

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 in transparent proxy deployments only. 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 ports 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.

For information about how to enable IP spoofing, see Transparent Proxy Caching and ARM in the Content Gateway Manager Help.

User authentication

User authentication is the process of verifying a user via a username and password. Several types of user authentication are supported by 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.

Content Gateway user authentication

Content Gateway can be configured for transparent user authentication -- with Integrated Windows® Authentication (IWA) or Legacy NTLM -- in which users are not prompted for credentials. Alternatively, Content Gateway can be configured for prompted (or manual) authentication, in which users are required to enter a username and password to obtain network access.


	Note Not all Web browsers support both transparent and prompted authentication modes. See the v7.7 Websense Content Gateway Release Notes 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 that 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 user 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.

Websense Content Gateway supports the following user authentication methods:

Integrated Windows Authentication (with Kerberos)

Legacy NTLM (Windows NT® LAN Manager, NTLMSSP)

LDAP (Lightweight Directory Access Protocol)

RADIUS (Remote Authentication Dial-In User Service)

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 Help for detailed information about configuring these proxy user authentication options.

TRITON - Web Security user identification

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

HTTPS content inspection

When you use Content Gateway with HTTPS (SSL Manager) enabled, HTTPS data can be decrypted, inspected, 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.

Deploying Content Gateway with SSL Manager enabled may require the following modifications to your system:

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

In explicit proxy deployments, additional client configuration in the form of Proxy Auto-Configuration (PAC) files or Web Proxy Auto-Discovery (WPAD)

In transparent proxy deployments, integration with WCCP v2-enabled network devices


	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, you can specify categories of Web sites, individual Web sites, and clients for which decryption and inspection are always bypassed. See SSL Decryption Bypass in TRITON - Web Security Help for more information.

Handling special cases

Any 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 Help.

See, also: Web sites that have difficulty transiting Content Gateway.