A number of general permissions can be set for each group in the Permisions & Limits subsection of the Web Proxy module. These settings will also be inherited by all the descendent groups, unless explicitly overridden. If you need to override the inherited settings, untick the Inherit box of the setting and adjust it as appropriate.
If the filtering is simply being used to prevent trusted users from accidentally stumbling across inappropriate content, it can be useful to allow those users to override a block if they are sure that the website they are visiting is ok. When a user is blocked, if they are in a group with this setting ticked they will be given the option to temporarily override the block and continue to the website.
Users who are in a group that has this option ticked will not be restricted by any web filtering or bandwidth limits at all, irrespective of any other settings.
By intercepting HTTPS traffic, the filter to decrypt, analyse and log encrypted traffic. This option allows you to find a balance between safety and intrusiveness:
- Active interception - Traffic may be fully decrypted. The filter will be able to examine the whole URI and content in order to categorise the request. Logs will contain full data, including the whole URI, content type, etc. Client devices need to have your unique Opendium interception certificate installed.
- Passive inspection - The SSL handshake may be decoded but traffic will not be decrypted. The filtering capabilities will be reduced - only the host name part of the URI will be used for categorisation and no content can be examined. The logs will only contain the host name part of the URI. Client devices do not need the Opendium certificate installed.
- Disabled - No examination of the encrypted traffic is done. The filtering capabilities will be extremely limited as the only information available to the filter is the host name part of the URI for non-transparently proxied traffic. Logs will contain the host name part of the URI if it is available, or just the IP address of the web server.
Note that by default, banking websites are excluded from active interception. We recommend that active interception is enabled for students. It is often convenient to use passive inspection for guest devices.
Different types of device require different techniques in order to unobtrusively associate the web requests with specific users. This option allows you to pick a suitable profile. The Automatic setting provides a reasonable default that works reasonably well in most situations, but setting a more specific profile to each part of your network helps provide the best compatibility with the devices.
- Automatic [NOT RECOMMENDED] - this is an "all round" mode that works in most situations. However, it has a number of problems, so it is preferable to divide your network up so that a more appropriate setting can be used for networks of each type of device. A combination of HTTP proxy authentication, captive portal authentication, WISPr and RADIUS accounting will be used.
- Automatic 2 [NOT RECOMMENDED] - similar to Automatic mode, except that traffic through the transparent proxy will not be authenticated. This mode is not recommended.
- Workstation - for networks of workstations which accept logins from several non-concurrent users. A combination of HTTP proxy authentication and RADIUS accounting will be used. Devices must be configured to use the proxy. Transparently proxied requests will be denied until after an authenticated proxy request has been made.
- Single user devices - for networks of devices whereby each device is only used by a single user. For example, wifi networks of personal devices such as phones, tablets, etc. A combination of captive portal authentication, WISPr and RADIUS accounting will be used. It is recommended that you also configure your wifi controller to send RADIUS accounting data to Web Gateway / UTM.
- Multiuser servers - for networks of servers whereby each server is expected to be used by multiple concurrent users. HTTP proxy authentication will be used exclusively. When HTTP proxy authentication is not possible, users will not be identified.
- Disabled - users are not identified.
The amount a user downloads over the web can be restricted by enabling this setting. Once a user has exceeded the limit, their web requests will be blocked.
This works on a "Leaky Bucket" model: If, for example, a user is allowed to download 500MB per hour, they start with 500MB left in their quota. If they then use 400MB of that over a half hour period, at the end of that time they will have 350MB of their quota left (100MB of the original 500MB, plus the 250MB extra they accumulated over that half hour based on the 500MB/hour limit). As such, a user can actually use up to 1000MB in a single hour, but when averaged over a longer period the limit tends towards the configured 500MB per hour.