Content Gateway explicit and transparent proxy deployments
Applies to: | In this topic |
---|---|
|
|
- Explicit proxy deployment, where the user’s client software is configured to send requests directly to Content Gateway
- Transparent proxy deployment, where user requests are transparently redirected to a Content Gateway proxy, typically by a switch or router, on the way to their eventual destination
For more information about configuring explicit and transparent proxy options in Content Gateway, see the Explicit Proxy and Transparent Proxy and ARM topics in the Content Gateway Manager Help.
Explicit proxy deployment
Use of 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 when troubleshooting.
For explicit proxy deployment, individual client browsers may be manually configured to send HTTP, and optionally, HTTPS and FTP, 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 in the Content Gateway Manager Help for a sample PAC file and more information about how to implement these options. See also: PAC file best practices .
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.
Multiple proxies can provide for redundancy using Virtual Router Redundancy Protocol (VRRP). Using a single IP address, requests are sent to an alternate proxy in the event of failure. VRRP is not invoked until there is a failure with one of the proxies. See RFC 3768 for information on VRRP.
Configuring client browsers for explicit proxy
For explicit proxy deployments, you must configure each client browser to send Internet requests to Content Gateway, over the ports that Content Gateway uses for the associated protocol.
The default proxy port in Content Gateway for both HTTP and HTTPS traffic is 8080. The default port for FTP is 2121.
- In Internet Explorer, select .
- Select Use a proxy server for your LAN.
- Click Advanced.
- For HTTP, enter the Content Gateway IP address and specify port 8080.
- For Secure, enter the Content Gateway IP address and specify port 8080.
- Clear Use the same proxy server for all protocols.
- Click OK to close each screen in this dialog box.
- In Firefox, select Network tab. , and then select the
- Select Settings.
- Select Manual proxy configuration.
- For HTTP Proxy, enter the Content Gateway IP address and specify port 8080.
- For SSL Proxy, enter the Content Gateway IP address and specify port 8080.
- Click OK to close each screen in this dialog box.
Transparent proxy deployment
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 Content Gateway intercepts incoming packets and redirects them to the proxy. 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 and ARM in the Content Gateway Manager Help.
- Traffic tunneled over HTTP and HTTPS by remote desktop applications
- Instant messaging clients
- Software updaters for Windows and anti-virus applications
- Custom internal applications
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 and ARM in the Content Gateway Manager Help.
Because traffic management is centralized, users cannot easily bypass the proxy.
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.
Layer 4 switch
- Create an access control list (ACL) that identifies the web traffic that should be intercepted.
- Develop a route map to define how the intercepted web traffic should be modified for redirection.
- Apply a “redirect to proxy” policy to the switch interface.
See Transparent Proxy and ARM in the Content Gateway Manager 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. As a best practice, use 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.
The following illustration shows an example transparent proxy deployment.
Activity | Explicit Proxy Deployment | Transparent Proxy Deployment | Proxy Chain |
---|---|---|---|
Client HTTP request | 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 |
Exception management | Exclude site, CIDR, etc., using browser configuration settings and PAC file settings. | Static or dynamic bypass rules | Child/parent proxy configuration rules |
Proxy user authentication | 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. |
Redundancy | Proxy virtual IP pool shared across multiple proxies | WCCP pool with multiple proxies | Parent/child configuration points to proxy virtual IP addresses. |
Proxy management | Management clustering | Management clustering | Management clustering |
Load balancers | Supported | N/A | Supported |