Use this page to configure Guardian's web proxy to suit your organizational needs.
Navigation: WEB PROXY > Web proxy > Settings.
|Enable||Selected by default, turns on Guardian's web proxy.|
|Disable||Turns off Guardian's web proxy.|
|Available proxy settings|
|Interface||The interface and address used for the automatic configuration script and the manual browser proxy settings.|
|Advanced »||Shows the additional settings for the web filter, logging, the cache, the Internet Cache Protocol and load balancing.|
|Web filter options|
|File upload policy||
Controls how Guardian handles file uploads.
|HTTP strict mode||This option determines the web proxy's behavior when processing HTTP/1xx response codes; specifically, response code 100 Continue. When HTTP strict mode is turned on, the web proxy does not forward responses with an Expect: 100 Continue header to the client. Although this is a HTTP protocol violation, some client applications have been found to not function correctly when such responses are forwarded. The default behavior is where HTTP strict mode is turned off. Therefore, the web proxy always forwards responses with Expect: 100 Continue headers to the clients.|
|Block advanced proxy bypass attempts||
Proxy avoidance services, such as UltraSurf, might be used to bypass the Smoothwall Filter. With this turned on (default behavior), such services are blocked when the initial connection is detected, and a 15-minute partial ban enforced for the user who made the attempt.
Whilst the bypass client is open and attempting reconnection, all traffic is blocked. If the client is closed, most traffic is allowed during the ban, but any domains that don't use Server Name Indication (SNI) to identify themselves remain blocked. This might result in some legitimate sites being blocked for the remainder of the ban, as without SNI, proxy bypass services are indistinguishable from legitimate traffic.
You can create a custom report to view the connection attempts. Make sure that the UltraSurf IPs reporting section (found under Guardian) is included.
|Resume interrupted NTLM connections||The Smoothwall Filter resumes interrupted NTLM connections caused by non-standard web browser behavior by default. If restrictive Active Directory account lockout policies are in place, turn off this parameter.|
|Resolve single component hostnames||The Smoothwall Filter makes no attempt to interpret single component host names not fully qualified by default. Turn off this parameter to stop from trying to interpret single component host names not fully qualified.|
|Server persistent connections||Indicates that the Smoothwall Filter allows server persistent connections by default. Turn off this option if you're experiencing 502 Bad gateway errors when accessing some websites.|
|Via headers||These are used to trace by default, for both the request and response, the proxies a connection has been made through. Guardian web filter adds its own entry into the Via header, and the header added by Squid. Some websites might attempt block users browsing through a proxy. Turn off this option to prevent the addition of headers by both Guardian web filter and Squid.|
|Honor incoming X-Forwarded-For||
Indicates that the Smoothwall Filter can take the client IP address from the X-Forwarded-For header, inserted by downstream proxy or load balancer. Using the IP address contained within the header clients can then be identified within the Smoothwall.
Note: Do not enable the Honor incoming X-Forwarded-For option if you've turned on Leak client IP with X-Forwarded-For headers with an upstream proxy, or with client IP address spoofing.
|Allow access to web servers on these additional ports||The Smoothwall Filter only allows requests to servers running on a certain subset of privileged ports by default, that is, ports lower than 1024, such as HTTP (80), HTTPS (443) and FTP (21). If you want access to servers running on non-standard ports, enter them here.|
|Proxy logging||We recommend that you turn off this option when Filter logging mode is turned on. This is because Guardian proxy logs are duplicated subsets of Guardian web filter logs. Turning off proxy logging can lead to improved performance by reducing system storage and processing demands.|
|Organization name||A meaningful name to identify Guardian in your organization. Organization names are also referenced in certain web reports.|
|Filter logging mode||
The logging mode.
|Client hostnames||Select whether to record host names of devices using Guardian. When turned on, you can generate web filter data incorporating host name information. It's important that DNS servers exist on the local network and are correctly configured with the reverse DNS of all devices if this option is selected, otherwise performance will suffer.|
|Client user-agents||Select whether to record the types of browsers used by users.|
|Advert blocks||Select whether to log information about advert blocking.|
|Local accesses||Select whether to log local accesses made through the web proxy to either localhost, or IP addresses 127.0.0.*. Typically, these accesses are logged. However, some configurations might cause clients to swamp the log files, in which case, you can turn off this logging.|
|Global cache size||The amount of disk space allocated to Guardian for caching web content. Web and FTP requests are cached. HTTPS requests and pages including username and password information aren't cached. The specified size must not exceed the amount of free disk space available. The cache size should be configured to an approximate size of around 40% of the system’s total storage capacity, up to a maximum of around 1.5 gigabytes. Larger cache sizes can be specified but might not be entirely beneficial and can adversely affect page access times. This occurs when the system spends more time managing the cache than it saves retrieving pages over a fast connection. For slower external connections such as dial-up, the cache can dramatically improve access to recently visited pages.|
|Max and min object size that can be stored in the cache||Enter the largest object size (Max object size) that is stored in the cache. Any object larger than the specified size is not cached. This prevents large downloads filling the cache. The default of 30720 kilobytes (30 MB) should be adjusted to suit the needs of your users. Enter the smallest object size (Min object size) that is stored in the cache. Any object smaller than the specified size is not cached. This can be useful for preventing large numbers of tiny objects filling the cache. The default is no minimum – this should be suitable for most purposes.|
|Max object size that can pass in and out of proxy||Enter the maximum amount of outbound data (Max outgoing size) that can be sent by a browser in any one request. This can be used to prevent large uploads or form submissions. The default no limit. Enter the maximum amount of inbound data (Max incoming size) that can be received by a browser in any one request. This limit's independent of whether the data is cached or not. This can be used to prevent excessive and disruptive download activity. The default is no limit.|
|Do not cache these domains||Used to specify domains that should be excluded from the web cache. You can use this to make sure that old content of frequently updated websites isn't cached. Enter domain names without the www prefix, one entry per line. To apply the option to any subdomains, enter a leading period, for example: .example.com|
|Internet Cache Protocol (ICP)|
|ICP server||Indicates that ICP compatible proxies can query Guardian's cache. ICP is a technique employed by proxies to determine if an unfulfilled local cache request can be fulfilled by another proxy’s cache. ICP proxies work together as cache peers to improve cache performance across a LAN. We recommend that you use ICP for LANs with multiple Guardian proxy servers; non- Smoothwall proxies must use port 801 for HTTP traffic.|
|ICP server IP addresses||The IP addresses of other ICP proxies on the LAN that Guardian should query. Use in conjunction with the ICP server option turned on to allow two-way cache sharing.|
|Direct Return Server Virtual IP||The virtual IP address assigned for communication to the Smoothwalls in the cluster. Not the actual IP address of the load balancer. You must make sure that this virtual IP address doesn't respond to ARP queries because ARP behavior is what sets this type of virtual IP address apart from a simple alias.|
Something not right? Send us feedback.