Separate OPNsense KEA configuration sync from lease failover

Bottom line: Review the configuration copied to the standby separately from the lease behavior expected during an outage. Make both server identities and the client-facing gateway and DNS values explicit before scheduling an HA exercise.

Source fact: what the authority says

The OPNsense KEA guide requires the Control Agent for HA and says it can remain bound to loopback because HA communication uses a separate listener by default. Its peer definitions must match on all nodes, normally identifying primary and standby servers. In the DHCPv4 HA example, automatic option collection is unchecked and the router and DNS options explicitly use the LAN CARP address. The example enables KEA in services to synchronize, then synchronizes and reconfigures the pair, making KEA active on both with bidirectional lease synchronization.

What the source does not establish

These statements concern the source’s DHCPv4 HA example, not an assertion that an existing pair has correct lease service. They do not establish a tested outage duration or authorize applying the example addresses to another network.

Applicability questions

• Do both servers have the intended names and identical HA peer definitions?
• Which actual CARP address should clients receive as their gateway and DNS server?
• Is KEA selected for configuration synchronization through the intended master?
• What observations will distinguish copied settings from actual lease exchange and client service?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends separate configuration and lease-service checklists. On the configuration sheet, record each peer’s own address, role and communication endpoint alongside the shared client-facing values. Preserve both exports before synchronization and identify which node is the approved configuration authority.

Review the source example’s explicit option values against the real subnet design. Have the network owner verify the chosen gateway and DNS service. Do not accept matching peer configuration if both peers contain an incorrect client-facing address.

Plan a proposed controlled allocation test using one new test client and one renewing test client on an approved segment. Write the expected address range and client options before the run. Keep an eventual partner-loss exercise separate from the initial configuration comparison.

Treat a discrepancy between peers as a reason to stop and reconcile direction and authority before synchronizing again. Record which configuration was intended to win and why. Do not use a broad production client release as a convenient way to generate the test traffic.

Verification and evidence

Proposed verification: inspect both effective peer definitions and subnet options, then compare test-client leases and returned gateway and DNS values. Preserve the observation time and responding server evidence available through the supported tooling. Confirm lease exchange independently of the configuration-copy action.

If partner loss is separately approved, observe both renewal and new allocation during that bounded exercise, then reconcile the recovered pair before closing it. Retain actual timings as observations rather than a promised failover target. Keep any DNS integration review outside this article’s narrower DHCPv4 HA acceptance.

Official references

• OPNsense — KEA DHCP — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.