Introduction
The Web Proxy feature is the main feature of the WSA that allows the appliance to filter HTTP traffic. While the Web Proxy can be enabled with minimal configuration, it is important to know how each of the settings can be configured and how they affect the operation of the Web Proxy.
Problem
The Web Proxy feature is the only feature that is required to be enabled in order to use the WSA to filter HTTP traffic. Due to the importance of the Web Proxy, it is vital that this feature is configured correctly. In this guide, I will cover how to configure the Web Proxy.
Solution
1) To enable the Web Proxy, access the WSA GUI and go to Security Services > Web Proxy.
2) Click on Enable, which will enable the Web Proxy and show an overview of the Web Proxy Settings.
3) At this point, the Web Proxy is functional. To further configure the Web Proxy, click on Edit Settings…, which will bring you to the Edit Web Proxy Settings page.
4) (Optional) Configure the remaining settings for the Web Proxy.
- HTTP Ports to Proxy
The ports listed here will determine what ports the WSA is listening on for HTTP traffic. The WSA will use the ports 3128 and 80 by default as the Web Proxy ports.
*Important* When using only one interface for the WSA, do not configure a port here that is in use elsewhere on the proxy. If using a different interface for data traffic than management traffic, it is possible to configure a port here that is used for a management service, but it is not recommended.
- Caching
Uncheck the box here to disable caching of HTTP content (enabled by default).
- Proxy Mode
This setting determines proxy mode of the WSA. It is recommended to keep the WSA in Transparent Mode as it can handle both transparent and explicit requests in this mode.
- IP Spoofing
This setting determines if IP Spoofing will be used. IP Spoofing will change the source IP address that is used when the WSA connects to the OCS from the WSA IP address to the Client IP address that made the request. This setting will require additional configuration not covered in this guide for WCCP if used with transparent requests. For Explicit requests, there must be a return route in place on the appropriate network device to send packets back to the WSA.
- Persistent Connection Timeout
A persistent connection is a socket that is kept open even after the HTTP request and HTTP response have been completed. Persistent connections must be negotiated when using HTTP/1.0. For HTTP/1.1, persistent connections are used by default without any additional headers. This setting determines how long the WSA should keep the socket open after traffic has stopped being sent. This setting is configured for 300 seconds for Client and Server side by default.
- In-Use Connection Timeout
This setting determines how long the WSA should keep a socket open when the transaction is still in progress and the Client or Server are waiting for a HTTP request or response. This setting is configured for 300 seconds by default for both Client and Server side connections.
- Simultaneous Persistent Connections
This setting determines the maximum number of persistent connections the WSA will maintain with servers (OCS) at any one time. This setting is configured for 2000 connections by default.
- Generate Headers
This setting determines what headers the WSA should include when sending HTTP requests or HTTP responses.
X-Forwarded-For – This HTTP header includes the IP address of the client making the request. This header is typically used when the WSA is sending traffic to some upstream device that can identify the IP address of the client instead of the IP address of the WSA. This header is disabled by default.
Request Side VIA – This HTTP header is sent when the WSA makes a HTTP request to the OCS and includes information about the WSA. By default, this information includes the following: HTTP version, hostname, port, product name, and version.
Response Side VIA – This HTTP header is sent when the WSA sends a HTTP response to a client that sent a HTTP request through the proxy. By default, this information includes the following: HTTP version, hostname, port, product name, and version.
- Use Received Headers
This setting when enabled allows the WSA to use the X-Forwarded-For headers it receives from a downstream device to identify the source IP address of a client instead of the IP address of the device that sent the request. Once enabled, you must enter the IP address of the trusted downstream device that is sending the HTTP requests with the X-Forwarded-For headers.
5) Submit and Commit the changes!
Now that the Web Proxy is configured, the WSA is able to filter HTTP traffic.
