Consider a small network with OPNsense acting as an Internet router/firewall, and two LANs. The two LANs serve different tenants, hence communication from LAN 1 to LAN 2 or vice versa is blocked.
DHCP is to be provided by Kea, which is part of OPNsense since version 24.1. For LAN 2, OPNsense is to be the only DHCP server; on LAN 1, DHCP servers are OPNsense and a local server on LAN 1, preferably in a loadbalancing configuration or with the local server being the default server.
This is quite similar to the hub and spoke setup described in the Kea Administrator’s Reference Manual, chapter 16.12.19, except:
- The branch servers are on separate networks which can communicate with the central server but not between each other.
- Only one of the branches has its own server, the other always uses the central server.
- The central server is running OPNsense, and Kea is configured through the OPNsense GUI.
To configure Kea manually on the central server, as I understand, one would do the following:
$.Dhcp4.hooks-libraries[[email protected] == "/usr/lib/kea/hooks/libdhcp_ha.so"].parameters.high_availabilitywould have one child (corresponding to an HA relationship) for each branch/LAN,- Each relationship would have a different
this-server-nameand a different list of peers inparameters.high-availability.peers - Each of these peers would have a globally unique name (the local server uses a different name for each HA relationship in which it participates)
- Each subnet in
$.Dhcp4.subnets4would have anuser-context.ha-server-nameattribute, which can be any server name in the list of peers, tying the subnet and its address pools to a particular HA relationship.
However, the OPNsense GUI (in Services > Kea DHCP > Kea DHCPv4) seems to be limited to just one single HA relationship:
- Settings has a check box to enable HA, and one single text box for the local server name. There doesn’t seem to be any way for the same server to be known by multiple names.
- When adding a subnet in Subnets, there doesn’t seem to be a way to set
user-contextorha-server-name. - The HA Peers tab appears to be just a flat list; I don’t see any way to group it into multiple relationships.
Does the OPNsense GUI provide a way to set up multiple HA relationships, each managing just a subset of the server’s subnets, using a different this-server-name, and synchronized with a different set of peers than the others? Or is OPNsense limited to a single HA relationship, which syncs everything with everyone else?
If OPNsense is limited in that respect, I see the following workarounds, though they are not particularly elegant:
- Set up an additional, independent DHCP server on LAN 1 (multiple DHCP servers, even different products, can coexist on the same LAN if their configurations are aligned):
- Split the address pool for LAN 1 between the two servers (each managing half of the pool). Manually keep configs (static leases, IP config deployed to clients etc.) in sync.
- Pros: Multiple LANs can have their own DHCP server. There is a certain degree of load-balancing between the two DHCP servers (both servers would respond to DHCP broadcasts and the client would choose, albeit possibly with a preference for the faster server; renewal requests would be sent to the server which issued the lease).
- Cons: If server configurations differ, strange things may happen (unpredictable IP configurations, static leases not getting honored, address collisions etc.). One server may end up managing most active leases due to selection bias, until its pool is exhausted. Slightly higher resource usage (as each DHCP broadcast will be answered by both servers).
- Synchronize the full database with the server on LAN 1, including leases for LAN 2:
- Configure the central server as the primary server, and the one on LAN 1 as the cold standby.
- Pros: Less danger of inconsistent configurations. No resource wastage from two servers answering the same request.
- Cons: HA mode must be cold-standby with the central server being primary (since in a load-balancing setup each server figures out locally which one is going to answer a broadcast, based on data inferred from the client request, this would result in half the requests from LAN 2 not getting answered; if the central server is the cold standby, DHCP on LAN 2 will not work at all). Only one LAN can have its own DHCP server, else strange things will happen if the central server fails (either one LAN server becomes the active node and the others cannot reach it, or each LAN server will consider itself active and the central server will get confused when it comes back online).
