Like many of you, I use DHCP on my OPNsense. Due to "it's what I've always done" I'm using ISC DHCP. However, Kea DHCP and DNSMasq DHCP are both options. Are there any comparisons between the three and when I would want to use them with OPNSense?
The story is quite short:
ISC DHCP is at the end of its lifetime and will eventually get pushed to plugins section. This means it will not be so well supported any more - well, it isn't by ISC, either. Yet, there is no rush to end using it, but if you just start out, you should consider the alternatives.
Kea DHCP is the strategic replacement product from ISC, but feature-wise, it is not quite up to par with ISC. Also, not everything that Kea offers is supported by the OpnSense GUI (at least when I looked at it the other day).
Deciso has decided to add DNSmasq as an easy alternative. It is quite fresh (first release of the DHCP-relevant parts was just in some of the last updates), so not all features worked as expected, but today's release 25.1.7 adds many bugfixes and additions to what was missing.
The documentation now has a big section on how to use it. Its charm is that it addresses DHCP, DNS and RA in one product. The only thing missing is a DNS resolver and DoT / DoH, but that can easily be added by an upstream DNS service, as is depicted in the docs.
@kbreit
Like you I'm still on ISC DHCP. When Kea appeared as an option I was going to switch but decided to wait. Now I think my switch will be to DNSmasq, as that is now what is recommended for my type of small, simple setup. Up to this point, at least, I have no regrets waiting for the various alternatives to appear and cook a little within OPNsense. As Meyergru says, "there is no rush". But at some point, maybe soon, maybe when it becomes a plug-in, it's going to make more sense to switch than stick with ISC.
Thanks for the information. I'll need to compare manually but I'm assuming either DNSmasq or Kea will have the features I need. Are there steps for how to do the migration in a seamless manner? I'm thinking it's something like...
1. Download static leases (or manually record them)
2. Import or manually enter them into the new DHCP server
4. Migrate any other settings
3. Turn off the old DHCP server and enable the new one
Since the configuration differs a lot between these servers, it has to be carried out manually.
The tedious part is mostly to carry over the reservations, esp. if you have many of them.
This may help in doing the latter:
https://github.com/meyergru/iscdhcp_to_kea
https://github.com/meyergru/iscdhcp_to_dnsmasq
I did notice Kea seems to lack the ability to do two things (which are probably the same thing):
- Custom DHCP options
- Set a DNS server
Am I missing a setting in the UI?
I switched from ISC to Kea. Unbound listens on all ports and I have a redirection rule for DNS. Kea is not involved.
Quote from: passeri on May 21, 2025, 04:41:28 AMI switched from ISC to Kea. Unbound listens on all ports and I have a redirection rule for DNS. Kea is not involved.
I agree Kea isn't normally involved in DHCP. But how does a DHCP client know where to send DNS requests to?
Services > Kea DHCP > Kea DHCPv4 > Subnets > edit a subnet and either
- check "auto collect option data" --> interface IP of OPNsense will be sent as gateway and DNS server or
- uncheck it, manually enter settings
I switched to KEA IPv4 when it first became available and have waited on IPv6 to be added, that's now available too. The reason I'm going with KEA is Prefix Delegation, that is the only reason. Most of my devices have reservations, so I do not really need the ability to add dynamics to Unbound, though there is a modified unbound_watcher.py out there that does appear to work, maybe something like that may be added in the future. However, as I said I run a test router down stream from the primary and need to be able to delegate a v6 prefix to that.
Quote from: kbreit on May 21, 2025, 03:36:49 AMI did notice Kea seems to lack the ability to do two things (which are probably the same thing):
- Custom DHCP options
- Set a DNS server
Am I missing a setting in the UI?
We are stuck on ISC until the Kea interface supports multiple arbitrary DHCP options. I looked at doing a PR to add this but the config syntax for Kea is very byzantine.
Which options exactly do you need?
At least for the DNS server, you can uncheck "Auto collect option data" and then set it.
I am with Patrick here: As for "arbitrary DHCP options", the way it is done in DNSmasq now, is complete, but confusing. Actually, it were better if specific options were explicitely offered in the GUI than to just list all of them and let the user fill in the blanks. As an example as to why:
QuoteThis was much easier in ISC DHCP, because often-used options like these (and some more) were summarized nicely on one page per interface. Maybe tabs for each interface would be a nice addition. It is also easier to have strong types for the most-often fields. As an example, consider the IPv6 DNSSL feature of RADVD (domain-search (24)), which should give DNS search domains in this syntax as seen with radvdump:
DNSSL lan iot guest dmz
{
AdvDNSSLLifetime 86400;
}; # End of DNSSL definition
where the original GUI input was "lan;iot;guest;dmz" and which is correct for the "domain-search (119)" option for DHCPv4.
You have to specifiy "lan;iot;guest;dmz" for IPv4 but "lan iot guest dmz" for IPv6, or else you will end up with:
DNSSL lan;iot;guest;dmz
{
AdvDNSSLLifetime 86400;
}; # End of DNSSL definition
ISC DHCP and RADVD did this automagically by using "lan;iot;guest;dmz" in the GUI only in one input field.
Other options are problematic because of type, e.g. the Unifi option (43). It should be specified as a hex string with colons, but if you accidentally use quotes around that, it will get interpreted as string and fail to work. Thus, it was better if the specific Unifi option was present in the GUI with an IP and the real configuration was then adapted to prevent such user errors.
Home user running business edition on an official appliance
Moved to kea when it was first suggested and it's run fine since then. A year maybe more?
Decided to try dnsmasq it's surprising to read it's a one man army from the UK. Compared to kea an actual company
Manually moved my kea static mappings over which I was fine with doing its only 17 devices
I had an issue with dnsmasq initially caused by mine own Alias error but since then all devices seem to be more responsive
Still using unbound for dns. Forwarding to either quad 9, nextdns, or controld dns over tls...
I do not see a reason to move away from Kea.
Quote from: meyergru on May 22, 2025, 07:14:12 PMOther options are problematic because of type, e.g. the Unifi option (43).
It should be specified as a hex string with colons, but if you accidentally use quotes around that, it will get interpreted as string and fail to work. Thus, it was better if the specific Unifi option was present in the GUI with an IP and the real configuration was then adapted to prevent such user errors.
Even tho it's a bit weird to say "Hi! We are OPNsense and we now support UniFi products!" ^_^ it would still be very cool to perhaps consider supporting well known DHCP Options that are used by some vendors like CISCO/HPE/Ubiquiti/TP-Link/etc. if the OPNsense Developer Team feels like adding such a feature ?!
Quote from: DEC670airp414user on November 08, 2025, 04:54:50 PMDecided to try dnsmasq it's surprising to read it's a one man army from the UK.
Still using unbound for dns.
If you want "DNSmasq on steroids" you could consider running Pi-Hole and using it's FTLDNS which is based on whatever is the latest DNSmasq code + extra code added by the Pi-Hole Developer Team :)
Combined with running your own Unbound instance to query DNS Root Servers as seen here : https://docs.pi-hole.net/guides/dns/unbound/
It's the best DNS solution I have ever had running on my LAN for about 10 years or so by now!
Quote from: Patrick M. Hausen on November 08, 2025, 06:25:16 PMI do not see a reason to move away from Kea.
I am experimenting
I just want the most reliable
We shall see I guess
I had almost no issues with Kea. What I found issues with I could work around
@nero355: The DHCP option is just one (inferior) way of telling Unifi devices where their controller lives.
The other is to use an unqualified DNS entry "unifi", which can either be a CNAME or an A/AAAA record. The latter is better anyways, because the DHCP variant can only point to an IP address, which would neither work for a dynamic DNS server nor one that uses IPv6.
Thus, the corresponding feature request was futile.