Go to the table of contents Go to the previous page Go to the next page
Content Gateway Deployment > Content Gateway deployment issues
Content Gateway deployment issues
Deployment and Installation Center | Forcepoint Web Security
 
Planning to deploy Content Gateway as a proxy in your network should include physical requirements, such as:
*
*
*
*
Also consider:
*
Content Gateway system requirements (hardware and operating system)
*
*
*
*
Internet connectivity
It is recommended that the Content Gateway host machine have Internet connectivity before starting the installation procedure. The software will install without Internet connectivity, but analytic database updates cannot be performed until Internet connectivity is available.
Security of the Content Gateway machine
Consider the following security issues prior to installing Content Gateway:
Physical security
Physical access to the system can be a security risk. Unauthorized users could gain access to the file system, and under more extreme circumstances, examine traffic passing through Content Gateway. It is strongly recommended that the Content Gateway server be locked in an IT closet and that a BIOS password be enabled.
Root permissions
Ensure that root permissions are restricted to a select few persons. This important restriction helps preclude unauthorized access to the Content Gateway file system.
Ports
For a list of default Content Gateway ports, see the ports spreadsheet for on-premises Web protection solutions. These ports must be open to support the full set of Forcepoint Web Security features.
 
Note 
Restrict inbound traffic to as few other ports as possible on the Content Gateway server. In addition, if your subscription does not include certain features, you can restrict inbound traffic to the unneeded ports. For example, if your subscription does not include Forcepoint DLP or the Forcepoint Web Security DLP module, you may choose to restrict inbound traffic to those ports related to Forcepoint DLP.
IPTables Firewall
If your server is running the Linux IPTables firewall, you must configure the rules in a way that enables Content Gateway to operate effectively. See the IPTables for Content Gateway article in the Technical Library.
Proxy deployment options
Content Gateway is used in either explicit or transparent proxy deployments.
With an explicit proxy deployment, client software, typically a web browser, is configured to send requests for Internet content directly to Content Gateway.
In a transparent proxy deployment, client requests for Internet content are 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 Content Gateway deployment can scale from a single node to multiple nodes to form a management cluster. With management clustering, all nodes in the cluster share configuration information. A configuration change on one node is automatically propagated all other nodes. Transparent proxy deployments with WCCP can disable cluster synchronization of WCCP configuration settings.
See Clusters in the Content Gateway Manager Help for information about configuring Content Gateway clusters.
IP spoofing
By default, when communicating with origin servers Content Gateway proxies client requests substituting its own IP address. This is standard forward proxy operation.
With both transparent and explicit proxy deployments, Content Gateway also supports IP spoofing.
IP spoofing configures the proxy to use either of the following:
*
*
IP spoofing is sometimes used to support upstream activities that require the client IP address or a specific IP address. It also results in origin servers seeing the client or specified IP address instead of the proxy IP address (although the proxy IP address can be a specified IP address).
IP spoofing:
*
*
*
*
 
Warning 
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 authenticationwith 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:
*
*
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 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:
1.
By:
*
*
*
*
2.
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:
*
*
*
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:
*
*
*
 
Note 
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.

Go to the table of contents Go to the previous page Go to the next page
Content Gateway Deployment > Content Gateway deployment issues
Copyright 2023 Forcepoint. All rights reserved.