Is ISC DHCP going away? What is the replacement? kea or Dnsmasq?
Thanks
Yes.
Both.
Quote from: Patrick M. Hausen on May 14, 2025, 09:11:18 PMYes.
Both.
So do I need to configure both kea and Dnsmasq just to replace ISC DHCP?
Never mind, I found the answer in docs. Dnsmasq is recommended for small networks and is the most recent Opnsense offering. I will switch to using it as it seems to be a long term option.
I would wait for 25.1.7 if I were you. There are some glitches you probably do not want to research and many of them may be fixed until then.
There is no urgent need to switch at this time.
What is the approximate timeline for when ISC DHCP is going to be removed from OPNsense?
1 quarter? 1 year? 5 years?
It's all in the docs and in the announcements, folks ...
It's going to be relegated to a plugin instead of core probably in 26.1.
So if we want to keep isc we can?
For now, yes of course.
Infinitely - probably not. Someone has to maintain that plugin. What if there are security issues?
The project is EOL upstream, there is no way around replacing it at some time in the future. OTOH there is absolutely no need to rush to it *now*.
My network is dead simple. No VLAN, no guest network, just one LAN interface /24 subnet, no IPv6, one WAN interface. I have switched to Dnsmasq and Unbound combination as per the documentation example.
https://docs.opnsense.org/manual/dnsmasq.html#configuration-examples
See what happens...
Thanks for all the wonderful replies and clarification !!!
ISC DHCP will move to plugins in 26.1 next year. Probably stay there for at least 2-3 years.
Cheers,
Franco
Is there gonna be a migration path? Say, for the static mappings at least? Or is there maybe some script already?
Not yet, there is no immediate need to migrate just yet. Maybe we have something ready in the next major version that can export the reservations from ISC.
I haven't had good experiences with either Kea or DNSmasq so far.
Recently, I noticed with Kea that WiFi Call only works on the first WiFi subnet of my Wi-Fi subnets (I have three). This is the parent interface. For the other two Wi-Fi subnets, I use VLANs that use the Wi-Fi parent interface.
After switching back to ISC, WiFi Call worked with all three Wi-Fi subnets. I understand that ISC is EOL and that security vulnerabilities will emerge over time, but ISC worked absolutely flawlessly for me, and I find it very unfortunate that it is no longer being developed.
But have you found out /why/ the Wifi calling did not work anymore?
That's the information that is needed to fix something and improve the new alternatives for everybody with the same issues.
Quote from: Monviech (Cedrik) on May 16, 2025, 03:02:02 PMBut have you found out /why/ the Wifi calling did not work anymore?
That's the information that is needed to fix something and improve the new alternatives for everybody with the same issues.
No, i don't know why. Maybe KEA is filtering some Features. Also with DNSmasq WiFi Call doesn't work on all three WLAN-Subnets. On this point, it's very frustrating. I would like to continue to rely on OPNsense in the distant future, but if the DHCP alternatives don't work as smoothly as ISC currently does and ISC will no longer be available as a plugin at some point, things will look really bad.
What do you mean with filtering some features?
DHCP is quite simple, it provides your clients with an IP address to use, as well as with DHCP options which specify certain resources (e.g., default gateway (router), dns server).
Did you set any specific DHCP option to enable Wifi calling?
Quote from: Monviech (Cedrik) on May 16, 2025, 03:12:31 PMWhat do you mean with filtering some features?
DHCP is quite simple, it provides your clients with an IP address to use, as well as with DHCP options which specify certain resources (e.g., default gateway (router), dns server).
Did you set any specific DHCP option to enable Wifi calling?
No, I haven't configured anything special under KEA that could affect WiFi Call, that's the strange thing.
If it works fine with ISC and I've configured KEA correctly (which I have), then KEA must be filtering something or whatever. I just can't understand why KEA acts like this.
But generally, I agree with your statement that DHCP shouldn't filter anything, but rather handle the distribution of IP addresses.
You should compare the DHCP Offer packets sent via ISC and KEA to find out of the options inside them match and if the clients receive all of the options they request. If they do, it should not have anything to do with DHCP itself.
You could use Wireshark on a client, or the Packet Capture feature in the OPNsense GUI.
Alas, DHCP and its older brother BOOTP are probably the most awkward protocols ever invented. There were (and are) size limitations on what can be transmitted, so if you use too many (or too long) options, you may cause problems. Some clients bark on options they do not know.
Behind the DHCP daemons, there is some trickery going on, that may cause addition or modification of DHCP options that you do not see plainly in the configuration.
Thus, @Monviech's advice is correct: compare tcpdumps of the actual DHCP responses and see if you can find differences.
I could be reading your post incorrectly, but when you say "parent" interface do you mean a non-VLAN subnet? If you mix tagged and untagged traffic on the *same* trunk port, that could be the problem. See here and note the orange box: https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.html
BTW, I switched to DnsMasq for DHCP by stopping the ISC and adding ranges to DnsMasq config, but I cannot actually have ISC disabled (to avoid it starting on boot again), because ticking the "Enable DHCP server on the LAN interface" checkbox does nothing, as in the "Apply" button does not show up.
EDIT: nevermind, the ISC configuration page actually somehow has "Save" button on the bottom for any changes, a blast from the past.
Quote from: Monviech (Cedrik) on May 16, 2025, 03:21:46 PMYou should compare the DHCP Offer packets sent via ISC and KEA to find out of the options inside them match and if the clients receive all of the options they request. If they do, it should not have anything to do with DHCP itself.
You could use Wireshark on a client, or the Packet Capture feature in the OPNsense GUI.
With KEA, all clients receive both an IPv4 and an IPv6 address. However, the latter comes from ISC DHCPv6 and not from KEA. This shouldn't be a problem, because the main Wi-Fi subnet works with WiFi Call, but not the subnets that work with VLANs. From my understanding, everything should be fine as long as the clients have received their IP addresses successfully. So, you can be wrong.
So I suspect that KEA isn't embedded deep enough in the system yet, or that something is missing in the coding. But I have no idea about that, so I'll leave it to Franco and co.
Thanks for your helpful answers.