Network Topology

From Opendium Documentation
Jump to navigation Jump to search

Opendium systems are designed to operate as gateway devices, 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.

Opendium system's external connection

The Opendium system will usually be connected to your internet router, but 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.

It is possible to install a third party firewall between the Opendium system and the internet, but this is not recommended. There are a couple of reasons for this:

  1. Opendium systems include a very capable firewall, so there is little benefit in adding a second firewall.
  2. When trying to diagnose why certain applications aren't working, a second firewall complicates debugging since it is a second device, possibly managed by a different company, which could be interfering with those applications.

Opendium system's internal connection

If possible, the internal network connection to the Opendium system should be a tagged VLAN trunk, which will allow the Opendium system to act as a gateway for multiple internal VLANs. Even for schools that only have a single VLAN, using a tagged VLAN trunk for the connection to the Opendium system is a good idea since it allows the network to be expanded at a later date. 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.

Internal networks

Whilst it is possible to use a "flat" network topology, where all types of devices are mixed on a single VLAN, different types of device need to be handled differently and it is therefore preferable to split your network into multiple VLANs. For example, workstations which are connected to your Windows domain would usually use Kerberos single signon authentication to identify users, whereas Bring Your Own Device networks typically identify users through RADIUS accounting data. It is therefore best to keep these types of devices on separate VLANs so that the Opendium system can be set to use the most appropriate user identification mode.

We recommend that wifi networks which use either 802.1x (WPA-Enterprise) or captive portal authentication have a layer 2 connection to the Opendium system, rather than being routed by a layer 3 switch. The reason for this is that with a layer 2 connection, each client can be identified by its MAC address, whereas with the traffic routed via a layer 3 switch each client must be identified by its IP addresses.

For 802.1x, identifying clients by their IP addresses is less reliable because the Opendium system must wait for the wifi network to snoop on the network traffic and send a RADIUS accounting update containing Framed-IP-Address / Framed-IPv6-Address attributes before allowing access, and

  1. Some wifi systems do not have this capability, or in some cases send inaccurate data.
  2. Some wifi systems (notably Ubiquity UniFi) have a short delay between the client connecting to the network, and a RADIUS accounting update being sent to the Opendium system, which can result in clients receiving an "access denied" message when they first connect to the network.
  3. On IPv6 or dual-stacked networks, clients usually have multiple IP addresses, and very few wifi systems are capable of sending accounting updates containing Framed-IPv6-Address attributes for all of the client's addresses.
  4. Some wifi networks only send Framed-IP-Address data after the client has renewed its DHCP lease. The Opendium system will try to infer the IP addresses from previous sessions, but if the DHCP lease timeout is longer than 1 day or the client connects to multiple networks within the school, the Opendium system may not always be able to determine its IP addresses.

For the captive portal, identifying clients by their IP addresses is less reliable because on IPv6 or dual-stacked networks, clients usually have multiple IP addresses and the system will only know about the address that was used to log into the portal.