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 Proxy page and importing it into the domain's Trusted Root Certification Authorities.
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 Proxy page, 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 no proxy is configured through Group Policy, and that clients are set to autodiscover the proxy settings.
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.