"
I'm a typical OPNsense user managing a home network and a small business environment. As a non-expert network engineer, I'm genuinely grateful for how reliably and efficiently OPNsense runs. Much of this is thanks to the outstanding work of the OPNsense developers and the helpful community here in the forum.
After the deprecation of ISC DHCP, I migrated to Kea. The transition was seamless, and my setup has continued to work flawlessly ever since.
Here's what my configuration looks like:
- **Clients** receive **IPv4 addresses via Kea DHCP**.
- **IPv6 addresses** are assigned via **SLAAC** using router advertisements.
- **DNS** is handled through **AdGuardHome** (for filtering), and **Unbound** for DNS-over-TLS.
Important clients in my LAN/VLANs have **static leases** via Kea, and I use those for internal DNS assignments. Since my network doesn't undergo significant dynamic changes, I don't currently require DDNS.
That said, I'm following this discussion with interest — not because I'm facing any issues now, but because I'm thinking ahead. The deprecation of ISC DHCP seems to have triggered a broader strategic discussion about the default DHCP system in OPNsense.
My concern is whether Kea will continue to be supported and actively integrated into OPNsense, or whether it will fall to a lower priority in favor of dnsmasq — even though dnsmasq itself hasn't seen much development since 2024 and may not be as future-proof.
I'm very happy with my current setup and could certainly continue using it as-is. But I wonder: why not make Kea more accessible for small environments by focusing the GUI integration on the most common use cases? For example, DDNS support could be added via a simple checkbox to enable the Kea D2 module. The user would just enter a BIND server address and a TSIG key name — no full mapping of all Kea capabilities would be needed in the GUI.
I don't know how much development effort this would take — and that may be the limiting factor — but from a user's perspective, such a step would make Kea much more approachable and clearly position it as the forward-looking standard in OPNsense.
After the deprecation of ISC DHCP, I migrated to Kea. The transition was seamless, and my setup has continued to work flawlessly ever since.
Here's what my configuration looks like:
- **Clients** receive **IPv4 addresses via Kea DHCP**.
- **IPv6 addresses** are assigned via **SLAAC** using router advertisements.
- **DNS** is handled through **AdGuardHome** (for filtering), and **Unbound** for DNS-over-TLS.
Important clients in my LAN/VLANs have **static leases** via Kea, and I use those for internal DNS assignments. Since my network doesn't undergo significant dynamic changes, I don't currently require DDNS.
That said, I'm following this discussion with interest — not because I'm facing any issues now, but because I'm thinking ahead. The deprecation of ISC DHCP seems to have triggered a broader strategic discussion about the default DHCP system in OPNsense.
My concern is whether Kea will continue to be supported and actively integrated into OPNsense, or whether it will fall to a lower priority in favor of dnsmasq — even though dnsmasq itself hasn't seen much development since 2024 and may not be as future-proof.
I'm very happy with my current setup and could certainly continue using it as-is. But I wonder: why not make Kea more accessible for small environments by focusing the GUI integration on the most common use cases? For example, DDNS support could be added via a simple checkbox to enable the Kea D2 module. The user would just enter a BIND server address and a TSIG key name — no full mapping of all Kea capabilities would be needed in the GUI.
I don't know how much development effort this would take — and that may be the limiting factor — but from a user's perspective, such a step would make Kea much more approachable and clearly position it as the forward-looking standard in OPNsense.
