Use of Websense Content Gateway in an explicit proxy deployment is an easy way to handle Web requests from users. This type of deployment is recommended for simple networks with a small number of users. Explicit proxy is also used effectively when proxy settings can be applied by group policy. It requires minimal network configuration, which can be an advantage for troubleshooting efforts.
For explicit proxy deployment, individual client browsers may be manually configured to send requests directly to the proxy. They may also be configured to download proxy configuration instructions from a Proxy Auto-Configuration (PAC) file. A group policy that points to a PAC file for configuration changes is a best practice for explicit proxy deployments. Another option is the use of Web Proxy Auto-Discovery (WPAD) to download configuration instructions from a WPAD server. See
Explicit Proxy Caching in
Content Gateway Manager online Help for a sample PAC file and more information about how to implement these options.
Exception handling instructions can also be included in the PAC file or WPAD instructions. For example, requests for trusted sites can be allowed to bypass the proxy.
Disadvantages of explicit proxy deployment include a user's ability to alter an individual client configuration and bypass the proxy. To counter this, you can configure the firewall to allow client traffic to proceed only through the proxy. Note that this type of firewall blocking may result in some applications not working properly.
You can also use a Group Policy Option (GPO) setting to prevent users from changing proxy settings. If you cannot enforce group policy settings on client machines, this type of configuration can be difficult to maintain for a large user base because of the lack of centralized management.
In a transparent proxy deployment, the user's client software (typically a browser) is unaware that it is communicating with a proxy. Users request Internet content as usual, without any special client configuration, and the proxy serves their requests. The Adaptive Redirection Module (ARM) component of Websense Content Gateway processes requests from a switch or router and redirects user requests to the proxy engine. The proxy establishes a connection with the origin server and returns requested content to the client. ARM readdresses returned content as if it came directly from the origin server. For more information, see
Transparent Proxy Caching and ARM in
Content Gateway Manager online Help.
Note that in a transparent proxy deployment, all Internet traffic from a client goes through the proxy (not just traffic from Web browsers), including:
Many of these programs are not developed with proxy compatibility in mind. For a successful transparent proxy deployment, the network must be configured to allow the proxy's static bypass feature to work. See the "Static bypass rules" section of
Transparent Proxy Caching and ARM in
Content Gateway Manager online Help.
This type of deployment requires the implementation of at least one other network device that is not required in the explicit proxy deployment. Added equipment presents compatibility issues, as all network devices must work together smoothly and efficiently. The overall system is often more complex and usually requires more network expertise to construct and maintain.
The use of a Layer 4 switch or WCCPv2-enabled router to redirect traffic in a transparent proxy deployment can provide redundancy and load distribution features for the network. These devices not only route traffic intelligently among all available servers, but can also detect whether a proxy is nonfunctional. In that case, the traffic is re-routed to other, available proxies.
Exception handling can be included in switch or router configuration. For example, requests for data from some internal, trusted sites can be allowed to bypass the proxy.
You can implement policy-based routing (PBR) for a transparent proxy deployment with the use of a Layer 4 switch, which can be configured to redirect a request to the proxy, as follows:
See Transparent Proxy Caching and ARM in
Content Gateway Manager online Help for more information about the use of a Layer 4 switch.
WCCP is a protocol used to route client request traffic to a specific proxy. A WCCP-enabled router can distribute client requests based on the proxy server's IP address, routing traffic to the proxy most likely to contain the requested information.
The router may use Generic Routing Encapsulation (GRE) to forward IP packets to the proxy. GRE is a tunneling protocol that allows point-to-point links between multiple traffic routing hops.
A router may also use Layer 2 (L2), which does not use GRE. Websense recommends the use of L2 if the router supports it. With L2 redirection, Content Gateway must be on the same subnet as the WCCP device (that is, Layer 2 adjacent).
A proxy and a router communicate via a set of WCCP "Here I am" and "I see you" messages. A proxy that does not send a "Here I am" message for 30 seconds is removed from service by the router, and client requests that would have been directed to that proxy are sent to another proxy.
|
|
|
|
|
|
|
Direct connection to proxy by browser to port 8080 (default)
|
Redirected to proxy by network device using GRE encapsulation or by rewriting the L2 destination MAC address to the proxy's address
|
Direct connection to parent proxy from child proxy
|
|
|
Exclude site, CIDR, etc., using browser configuration settings and PAC file settings.
|
|
Child/parent proxy configuration rules
|
|
|
Proxy challenge using 407 Proxy Authentication Required code
|
Challenge using server-based authentication scheme (client is not aware of proxy)
|
Proxies in a chain may share credential information, or a single proxy in the chain can perform authentication.
|
|
|
Proxy virtual IP pool shared across multiple proxies
|
WCCP pool with multiple proxies
|
Parent/child configuration points to proxy virtual IP addresses.
|
|
|
|
|
|
|
|
|
|
|
Deployment and Installation Center
