Client Configuration

Opendium Web Gateway and UTM provide a traditional non-transparent authenticated HTTP proxy and a transparent proxy. The non-transparent proxy service provides support for HTTP, HTTPS, FTP and Gopher and is the primary means for clients to contact these services, whilst the transparent proxy will intercept any other HTTP or HTTPS traffic.

Proxy settings

The transparent proxy service cannot provide the full functionality of the non-transparent proxy service, so where possible clients should be configured to use the traditional non-transparent proxy service. In particular, the following situations cannot be supported by the transparent proxy:

  • Non-SSL/TLS communication to TCP port 443. Unless HTTPS inspection is disabled entirely, the transparent proxy will always perform a passive HTTPS inspection step on traffic to port 443, and this will fail if the traffic is not standard SSL or TLS.
  • Kerberos single signon authentication
  • NTLM authentication
  • Basic authentication
  • Authenticated access from multiuser servers (e.g. remote desktop servers)

Whilst we recommend explicitly setting the proxy wherever possible, this isn't always feasible. For example, it is desirable to connect guest devices to the network without manually setting the proxy. In these cases, it is usually fine to rely entirely on the transparent proxy, but be aware of the limitations listed above.

Authentication

The proxy server supports the following methods of client authentication:

  • Kerberos - automatic single sign-on, requires no interaction from the user. The workstation must be a member of the Windows domain and configured to use the non-transparent proxy.
  • RADIUS accounting - automatic single sign-on, requires no interaction from the user. The user details must be supplied by Network Access Controllers within your network, such as your wifi controller.
  • NTLM - pops up a box at the start of a web browsing session. The user name entered must include the Windows domain name in the format "DOMAIN\user". Most clients offer a save password option so that the user doesn't have to enter their credentials every time. The device must be configured to use the non-transparent proxy.
  • Basic - pops up a box at the start of a web browsing session, or on some clients can be manually configured. The user name entered can be a plain user name, or can optionally include a windows domain (which will be ignored). Most clients offer a save password option so that the user doesn't have to enter their credentials every time. The device must be configured to use the non-transparent proxy.
  • WISPr - displays the captive portal on the first use, requires no interaction from the user thereafter. The user name entered must be a plain user name (no Windows domain).
  • Captive Portal - displays at the start of a web browsing session. The user name can be a plain user name (no domain), "DOMAIN\user" or "user@domain" (e.g. an email address). The domain, if any, will be ignored.

The authentication methods that clients are expected to use are determined by the user identification profile. We highly recommend that your wifi controller is configured to send RADIUS accounting data to the system and that your user identification profiles are set appropriately on each network, rather than left on Automatic.

Certificates

By default, the system performs active HTTPS interception where necessary and client devices are therefore usually required to have your unique Opendium interception certificate installed. A link to the certificate can be found on the captive portal and on the Web Proxy configuration page. You may want to include a link to the certificate in a convenient location on your Intranet or print the QR code to download it on any literature.

It is not always feasible to install a certificate on every device. For example, it is desirable to connect guest devices to the network without installing the certificate. In those cases, you can set the HTTPS interception mode to Passive, but be aware that this will greatly reduce the filtering and auditing capabilities of the system and is therefore not usually a suitable configuration for student devices.

Remember that since the both unencrypted and encrypted network traffic may be examined by the system, you should ensure the users all agree to a usage policy that indicates that their network traffic may be monitored.

Configuration Instructions for Specific Clients

We have provided several pages, listed below, giving guides to the configuration of several common client devices.