Suggested issue title: Expose decline-probation-period (and related timing/reclamation knobs) in Kea DHCPv4 settings
Important notices
Is your feature request related to a problem? Please describe.
For the purpose of recovering from DHCPDECLINE storms on small networks, I am missing a way to configure Kea's decline-probation-period from the OPNsense UI.
When a client sends DHCPDECLINE for an offered IP, Kea marks that address as declined and holds it unusable for decline-probation-period seconds (upstream default 86400 — 24 hours). On a small home/SOHO network, a single misbehaving client can decline dozens of IPs in a short window, removing chunks of the pool from circulation for a full day at a time.
I hit this on a /24 IoT VLAN: a single LXC with a broken DHCP-client setup entered a DHCPDECLINE loop and burned through 91 IPs in roughly 5 hours, leaving the dynamic pool effectively exhausted. Other devices on the VLAN could no longer obtain leases. Even after fixing the misbehaving client, the pool could not recover for the full 24-hour probation window without manually stopping Kea, editing /var/db/kea/kea-leases4.csv* to remove declined entries, and restarting.
The setting is supported natively by Kea (see Kea ARM — DHCPv4, section "Duplicate Addresses (DHCPDECLINE Support)"), but OPNsense's Kea plugin does not track it in /conf/config.xml, so it cannot be configured via the GUI. Direct edits to /usr/local/etc/kea/kea-dhcp4.conf revert the next time anything in the Kea settings is saved, because the file is regenerated from the OPNsense XML config.
Describe the solution you'd like
An optional integer field under Services → Kea DHCPv4 (in an Advanced or Timers sub-section) labelled "Decline probation period (seconds)", which:
- Defaults to Kea's upstream default (
86400) when left blank, preserving existing behaviour
- Accepts any non-negative integer
- Is emitted into the generated
kea-dhcp4.conf as "decline-probation-period": <value> at the Dhcp4 top level
While the plugin is being extended, it would make sense to expose the related timing and reclamation knobs at the same time, as they form a natural group and all suffer from the same "not in schema → not configurable" issue:
min-valid-lifetime / max-valid-lifetimerenew-timer / rebind-timerhold-reclaimed-timereclaim-timer-wait-timeflush-reclaimed-timer-wait-time
valid-lifetime is already exposed, so the precedent and emission pattern exist.
Describe alternatives you considered
- Direct edit of
/usr/local/etc/kea/kea-dhcp4.conf. Works until the next config save in the GUI regenerates the file. Not a permanent fix.
- Post-regeneration hook that re-injects the setting after each save. Fragile; breaks silently on plugin updates.
- Local patch to the OPNsense Kea plugin to emit the value. Non-portable; lost on update.
- Run Kea outside OPNsense and disable the plugin. Loses the integration value entirely; significant operational overhead.
Additional context
The upstream Kea default of 86400 makes sense on large managed networks where address-recycling carries security concerns. On a typical home/SOHO /24, where the pool is small and the trust model is different, that default turns a single misbehaving client into a multi-hour, network-wide outage. Most small-network operators would benefit from values in the 60–600 second range, but there is currently no supported way to set them.
The OPNsense Kea plugin is still maturing relative to the ISC DHCP plugin it is replacing, and a number of these timing knobs are not yet covered. Grouping them when the UI is extended would also reduce the amount of one-off plumbing required.
Important notices
Is your feature request related to a problem? Please describe.
For the purpose of recovering from
DHCPDECLINEstorms on small networks, I am missing a way to configure Kea'sdecline-probation-periodfrom the OPNsense UI.When a client sends
DHCPDECLINEfor an offered IP, Kea marks that address as declined and holds it unusable fordecline-probation-periodseconds (upstream default86400— 24 hours). On a small home/SOHO network, a single misbehaving client can decline dozens of IPs in a short window, removing chunks of the pool from circulation for a full day at a time.I hit this on a
/24IoT VLAN: a single LXC with a broken DHCP-client setup entered aDHCPDECLINEloop and burned through 91 IPs in roughly 5 hours, leaving the dynamic pool effectively exhausted. Other devices on the VLAN could no longer obtain leases. Even after fixing the misbehaving client, the pool could not recover for the full 24-hour probation window without manually stopping Kea, editing/var/db/kea/kea-leases4.csv*to remove declined entries, and restarting.The setting is supported natively by Kea (see Kea ARM — DHCPv4, section "Duplicate Addresses (DHCPDECLINE Support)"), but OPNsense's Kea plugin does not track it in
/conf/config.xml, so it cannot be configured via the GUI. Direct edits to/usr/local/etc/kea/kea-dhcp4.confrevert the next time anything in the Kea settings is saved, because the file is regenerated from the OPNsense XML config.Describe the solution you'd like
An optional integer field under Services → Kea DHCPv4 (in an Advanced or Timers sub-section) labelled "Decline probation period (seconds)", which:
86400) when left blank, preserving existing behaviourkea-dhcp4.confas"decline-probation-period": <value>at theDhcp4top levelWhile the plugin is being extended, it would make sense to expose the related timing and reclamation knobs at the same time, as they form a natural group and all suffer from the same "not in schema → not configurable" issue:
min-valid-lifetime/max-valid-lifetimerenew-timer/rebind-timerhold-reclaimed-timereclaim-timer-wait-timeflush-reclaimed-timer-wait-timevalid-lifetimeis already exposed, so the precedent and emission pattern exist.Describe alternatives you considered
/usr/local/etc/kea/kea-dhcp4.conf. Works until the next config save in the GUI regenerates the file. Not a permanent fix.Additional context
The upstream Kea default of
86400makes sense on large managed networks where address-recycling carries security concerns. On a typical home/SOHO/24, where the pool is small and the trust model is different, that default turns a single misbehaving client into a multi-hour, network-wide outage. Most small-network operators would benefit from values in the 60–600 second range, but there is currently no supported way to set them.The OPNsense Kea plugin is still maturing relative to the ISC DHCP plugin it is replacing, and a number of these timing knobs are not yet covered. Grouping them when the UI is extended would also reduce the amount of one-off plumbing required.