Installation Requirements

In order for your Opendium system to integrate into your network, there some basic configuration of your existing systems needs to be carried out. The Opendium installation engineer will ensure that the necessary configuration is done at installation time, but it is documented here for your reference.

Network topology

The Opendium system is designed to operate as a gateway device, situated between your network and the internet. Usually one of the Opendium system's network interfaces will be connected to your internet router and another interface connected to your internal networks. If your internet connection is delivered as a PPPoE connection (e.g. ADSL, vDSL/FTTC, FTTP), the Opendium system can terminate the PPP link, eliminating the need for the router.

If possible, the internal network connection should be a tagged VLAN trunk, which will allow the Opendium system to act as a gateway for multiple internal VLANs. We recommend that most wifi VLANs have a layer 2 connection to the Opendium system, rather than being routed by a layer 3 switch.

For larger sites, we may recommend that the Opendium system is connected to the internal network using an LACP trunk, which utilises multiple network links for improved redundancy and speed.

See the Network Topology knowledgebase article for more comprehensive information.

Internet connectivity

Opendium systems must be connected to an internet connection which provides a static IP address.

The Opendium system has an integrated firewall, and we do not recommend installing it behind a third party firewall since this adds unnecessary complexity. However, if it is installed behind another firewall, at least TCP ports 22 (SSH) and 80 (HTTP) must be forwarded to the Opendium system.

• TCP port 22 is used by Opendium engineers to access your system in order to provide technical support.
• TCP port 80 is used to automatically renew encryption certificates.

External DNS records

The following DNS records must be added to your external DNS zone:

opendium	A	<external IPv4 address>
opendium	AAAA	<external IPv6 address>

The addresses for these records are your Opendium system's external IP addresses. If your internet provider only supports the legacy IPv4 protocol, omit the AAAA record.

These records are required for:

• Offsite backups of the system's configuration.
• Monitoring of the system's health.
• Access by Opendium engineers in order to provide technical support.
• Automatic renewal of encryption certificates.

Depending on your wifi system, Opendium engineers may also recommend configuring the following DNS record:

wifi

CNAME

opendium

This may be required for automatic renewal of encryption certificates used by the RADIUS authentication server.

Internal DNS configuration

The following DNS records must be added to your internal DNS zone:

opendium	A	<internal IPv4 address>
opendium	AAAA	<internal IPv6 address>
proxy	A	<internal IPv4 address>
proxy	AAAA	<internal IPv6 address>
wpad	A	<internal IPv4 address>
wpad	AAAA	<internal IPv6 address>
certcheck	A	<internal IPv4 address>
certcheck	AAAA	<internal IPv6 address>

The addresses for these records are your Opendium system's primary internal IP addresses. If your network does not have IPv6, omit the AAAA records.

Although it is tempting to use CNAME records rather than A / AAAA records, this should not be done as unfortunately CNAMEs break some functionality, such as Kerberos single sign-on authentication.

If your internal DNS records are hosted by your Windows Domain Controllers, their global query block list must be disabled in order to allow the wpad record to be resolved. This must be done on all of the domain controllers, not just the primary one, using the following command:

dnscmd /config /enableglobalqueryblocklist 0

Your internal DNS servers should be configured to always forward DNS requests to the Opendium system. On Windows systems, this can be done by adding forwarders into the DNS server properties in DNS Manager. Ensure the "Use root hints if no forwarders are available" check box is not ticked. This must be done on all of your internal DNS servers.

Time synchronisation

Many services require clocks to be properly synchronised. In particular, Kerberos single sign-on authentication if very sensitive to clock drift and will not work if clocks have drifted by more than 5 minutes. The Opendium system provides an NTP service and your domain controllers should all be configured to synchronise against the Opendium's NTP service.

Trust relationship

If the Opendium system is being installed into a Windows network, it requires a trust relationship with the domain. The Opendium installation engineer will configure the trust relationship, which will require a temporary domain administrator account. Once the trust relationship has been established, the temporary administrator account can be removed.

User synchronisation

If the Opendium system is being installed into a Windows network, it must synchonise its internal user directory with Active Directory. This requires a user to be created within Active Directory for that purpose. This user should not be an administrator.

The synchronisation user's DN and password are configured on the Opendium system in the User Sync Configuration page, together with the IP address of the domain controller and the domain's base DN. By default all of the users under the base DN are synchronised, but more specific OUs can be added here to be synchronised instead.

Appropriate group mappings must also be configured in the User Sync Configuration page, to ensure that users are mapped into appropriate Opendium groups, based on their Active Directory security groups.

DHCP

The following DHCP option must be added to all DHCP scopes:

Name	WPAD
Data type	String
Array	Unticked
Code	252
Description	http://wpad.<internal domain>/wpad.dat

Replace <internal domain> with your internal domain.

This is because whilst the Opendium system can filter web traffic which is not sent via its web proxy server, there are certain capabilities that can only be provided by the proxy. It is therefore always best to use the proxy server where possible. It is possible to manually configure devices to use the proxy, but that can cause a number of problems, especially in situations where devices may be moved onto other networks, such as laptops which may be taken home. We therefore recommend using automatic configuration, which requires this DHCP option.

Inspection certificate

In order for the Opendium system to be able to decrypt HTTPS traffic, devices on your network must have the appropriate certificate installed.

For devices connected to your Windows domain, this should be done through Group Policy by downloading the certificate from the Web tab and importing it into the domain's Trusted Root Certification Authorities. Please see Microsoft Windows Configuration.

The certificate will need to be installed manually onto stand-alone devices. There are a number of ways to make this easier, such as using the QR code which is displayed on the Web tab, or using the Splash Page.

This certificate is unique to your Opendium system, and is separate from any certificate that is required to connect to your wifi network.

Proxy

We recommend using automatic proxy discovery. If the Opendium system is being installed into a Windows network, ensure that Group Policy configures no proxy servers, and has "Automatically discover proxy settings" ticked.

However, if it is necessary to manually configure the proxy, the settings used should be:

Proxy address	proxy.<internal domain>
Port	3128
Use the same proxy server for all protocols	Ticked

You must use the address shown above, rather than the proxy's IP address, otherwise Kerberos Single Sign-on authentication will not work.

Wifi

If you have any wifi networks which use WPA2-Enterprise / 802.1x authentication, they must be added to the RADIUS Clients page and configured to send RADIUS accounting data to the Opendium system.

The Opendium system also provides a RADIUS authentication service, so it may be desirable to configure the wifi networks to use the Opendium system for authentication.

We recommend setting up a completely unfiltered wifi network, to be only used for temporary testing and device onboarding. Since such a network is a potential risk, ensure that the password is kept secure, and consider restricting it only to certain parts of the school, such as the ICT office.

Data protection policy

Since the Opendium system automatically examines network traffic, including encrypted traffic, you should ensure the users all agree to a usage policy that indicates that their network traffic may be monitored. Under data protection law, there are a number of requirements that must be met, which are discussed in our blog article on the subject.

You are the data controller for the data which are collected directly by the Opendium system. Reports of miscategorised websites are passed directly to Opendium staff and Opendium is considered the data controller of those reports. Data for which we are considered the data controller are governed by our Data Protection Policy.

Some filtering suppliers put an onus on the school to ensure that the supplier's engineers are not given access to any personal data. With such a restriction, we do not believe that it would be possible to offer the level of support, and would inevitably lead to schools committing routine data protection breaches by giving access to the supplier's engineers. Instead, the contract between the school and Opendium includes a data processing agreement, and we are therefore considered data processors of the data which are collected by the Opendium system.