pfSense

A few things I noticed so far:

• If you select a self-signed certificate for TLS, the CA file is empty and Kea fails to start. It's not clear if we should either reject/filter self-signed or maybe it might work if the self-signed cert is copied into the CA file

• The default for max-unacked-clients is 10 which means it waits for 10 client requests before the secondary would take over for a failed primary. On smaller/less busy networks this results in clients sitting for long periods without a lease.
  • Changing the value to 1 allows Kea to answer the first client after the partner fails, but until that request comes in the status doesn't appear to acknowledge that the partner is down
  • Docs for the Kea hook suggest setting max-unacked-clients to a value of 0 so it transitions aggressively/immediately but the GUI currently rejects that value and only allows a minimum of 1
  • We should definitely allow a value of 0 to be set and that may be the ideal default. Users could always set it higher if it's too aggressive for their taste.

• The way the settings are structured can be a little confusing, since the main HA settings sync and advanced syncs, but TLS does not and is in between the two. It may be better the move the TLS options below advanced or into a separate heading denoting more prominently that they do not sync. Even keeping under the same heading they could be separated by a StaticText form row with the TLS/Sync general info.

A couple more notes after using it more:

• The Enabled Interfaces list on the Kea settings tab is prone to error and scales extremely poorly. It's very easy to attempt to select a new interface and accidentally deselect all of the other interfaces. On systems with many interfaces, this is a significant problem. Also the box is small, only four lines high, but increasing the size doesn't address the other issues.
  • If we move this back to a per-tab checkbox, we'd lose the "hide disabled" option but it would eliminate all the other concerns, and keep the interface config on each tab where users are more likely to expect it. The setting could still be maintained as a central list internally, just exposed as a per-interface checkbox instead of a multi-select list.
  • Alternately we could use a two-box+button approach like for user group membership, where one side has a list of disabled interfaces and the other has a list of enabled interfaces. Users select an entry and click a button to explicitly move an entry from one list to the other. This is much less prone to error, but still has scaling issues with many interfaces.

I removed the bit I had noted there about RA, it's working OK if you pick a CARP VIP for the "RA Interface" in the RA config for interfaces involved in failover, I had overlooked that somehow.