Content Gateway deployment issues


	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.

For complete information, see IP Spoofing in 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. Forcepoint 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.

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.

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 rule-based authentication. Rule-based authentication uses an ordered list of rules to support multiple realm, multiple domain, and other authentication requirements. When a request is processed, the rule list is traversed top to bottom, and the first match is applied.

Authentication rules specify:

How to match a user.

By:

IP address

Inbound proxy port (explicit proxy only)

User-Agent value

A combination of the above

The domain or ordered list of domains to authenticate against.

With a list of domains, the first successful authentication is cached and used in subsequent authentications. If IP address caching is configured, the IP address is cached. If Cookie Mode is configured, the cookie (user) is cached.

Rule-based authentication is designed to meet several special requirements:

Multiple realm networks in which domains do not share trust relationships and therefore require that each domain's members be authenticated by a domain controller within their domain. In this environment rules are created that specify:

Members of the realm (untrusted domain) by IP address or proxy port

The realm (domain) they belong to

Authentication when domain membership is unknown: Some organizations do not always know what domain a user belongs to. For example, this can happen when organizations acquire new businesses and directory services are not mapped or consolidated. The unknown domain membership problem can be handled in rule-based authentication by creating a rule for IP address lists or ranges that specifies an ordered list of domains to attempt to authenticate against. The first successful authentication is remembered and used in later authentications. If authentication is not successful or the browser times out, no authentication is performed.

Authentication based on User-Agent value: One or more User-Agent values can be specified in an authentication rule. Often this is a list of browsers. When the User-Agent value matches a rule, authentication is performed against the specified domain or domains. If the User-Agent value doesn't match any rule and no rule matches based on other values, no authentication is performed (this is always true in rule-based authentication; if no rule matches, no authentication is performed).

See Content Gateway user authentication in Content Gateway Manager Help for detailed information.

Other methods of user identification

You can configure user identification in the Forcepoint Web Security module of the Forcepoint Security Manager rather than use user authentication on the proxy. Methods of user identification include both transparent identification via a transparent identification agent (such as Logon Agent or DC Agent) and manual (prompted) authentication. See the User Identification topic in the Forcepoint Web Security Administrator Help for more information.

HTTPS content inspection

When you use Content Gateway SSL support, HTTPS traffic is decrypted, inspected, and re-encrypted as it travels from the client to the origin server and back. Enabling this feature also means that HTTPS traffic from the server to the client can be inspected for uncategorized sites and sites with dynamic content. The SSL feature includes a complete set of certificate-handling capabilities. See Certificates in the Content Gateway Manager Help for more information.

When you run Content Gateway with Forcepoint DLP to inspect HTTPS traffic, you must enable SSL support. See Content Gateway Manager Help for a complete description of SSL support.

Deploying Content Gateway with SSL support 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, or Policy Based Routing.


	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 websites, individual websites, and clients for which decryption and inspection are bypassed. See SSL Decryption Bypass in Forcepoint Web Security Administrator Help.

Handling special cases

Any Content Gateway deployment must be able to handle web requests and web 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 Static bypass rules in Content Gateway Manager Help.

See, also: Websites that have difficulty transiting Content Gateway.