I was testing the recently added DHCP support in DNSmasq and wanted to report that while IPv6 DHCP appears to be working fine, DHCPv4 was not. The service started up without issues, but no DHCPv4 requests seemed to reach it initially. After a reboot, requests started coming through, suggesting a possible firewall-related issue.
However, on the client side (Windows 11), things got even stranger: after said reboot the client received an IP address that was outside the assigned range, while an address within the assigned range was allocated as the DHCP server/DNS/Gateway. Very odd behavior.
Unfortunately, I wasn't able to investigate further because of angry users (a.k.a. my kids) demanding working internet.
I've been fighting with this since I upgraded this morning and have noticed some oddities as well.
I finally got everything configured and got dnsmasq to answer DNS requests and hand out (some) IP addresses via DHCP. But there were some devices on the network that work perfectly fine with ISC/KEA that just refuse to talk to the dnsmasq DHCP service and get an IP? I could tail the log file and see that dnsmasq was receiving DHCPREQUEST and sending DHCPACK packets to some devices on my network. But I had a few devices where I repeatedly tried renewing the IP address on and never saw an entry in the dnsmasq log file.
I would then disable dnsmasq dhcp and reenable KEA and boom. IP address got assigned each and every time. I rebooted the clients several times (but not the firewall itself) to no avail. DHCP services through dnsmasq seems rather intermittent where KEA (and ISC) give me no issues whatsoever.
For some reason others report the opposite so we will have to sort out what are common denominators and what seems like random observations during the first 24 hours of a release.
https://bsky.app/profile/slackadelic.com/post/3loob7tleqs2h
Cheers,
Franco
This - while good to have that option - will possibly lead to support issues 😉
(https://forum.opnsense.org/index.php?action=dlattach;attach=44735;image)
Activated is the default, so all good. Not criticising having it available.
I don't think it's nearly reliable enough at the moment and after all it is mimicking what ISC DHCP always did.
With "not nearly reliable" I mean that if you choose the old "all" default it will generate no firewall rules and if you happen to use that on a LAN with no default allow present you'll have some fun figuring out why it's not answering.
Still pondering what to do here but in general we are more or less expecting more support due to this new component either way. Dnsmasq is just a bit different from Kea and (ISC) DHCPD.
Just from the docs it wasn't absolutely obvious: is DNSmasq a full recursive resolver or does it need an upstream server?
It needs an upstream server, but you could chain it through local unbound ;)
No. Just no. Not another one in the chain.
So I really need to get into the vendor options for Kea business. Kea and Unbound it will be for me.
I thought I made it pretty clear in the docs inside its own note in deployment considerations right st the beginning:
https://docs.opnsense.org/manual/dnsmasq.html#dns-service
Quote from: franco on May 08, 2025, 10:47:39 PMI don't think it's nearly reliable enough at the moment and after all it is mimicking what ISC DHCP always did.
With "not nearly reliable" I mean that if you choose the old "all" default it will generate no firewall rules and if you happen to use that on a LAN with no default allow present you'll have some fun figuring out why it's not answering.
Still pondering what to do here but in general we are more or less expecting more support due to this new component either way. Dnsmasq is just a bit different from Kea and (ISC) DHCPD.
Indeed, turning off "DHCP register firewall rules" was part of my problem. That and not defining "Interfaces" under dnsmasq and leaving it with the default setting of "All" (which does not appear to register firewall rules on "All" interfaces as one might assume).
Once I fixed those things, all my issues where devices wouldn't connect to the dnsmasq DHCP server went away.
For what it's worth, when I was using KEA I did NOT have "Firewall rules" checked under its settings and my DHCP services still worked as expected? As such, I left that similar firewall configuration setting unchecked in dnsmasq as well thinking it would work too. Not sure whey KEA works without that checked but dnsmasq does not?
In any case, I'm still doing some testing but all seems much better now.
Quote from: Monviech (Cedrik) on May 08, 2025, 11:25:07 PMI thought I made it pretty clear in the docs inside its own note in deployment considerations right st the beginning:
https://docs.opnsense.org/manual/dnsmasq.html#dns-service
I missed that part because I went directly to the settings. Sorry.
All in all great work.
My personal gut feeling:
- I don't want YADS (yet another DNS server)
- I like Unbound
- It feels wrong somehow to run DNSmasq DHCP but not DNSmasq DNS - I bet there will be weird edge cases
- So it's Unbound and AGH and Kea for me, and probably my company, too
Not 100% sound technical arguments. I wrote "gut feeling", ok? :-)
The first free weekend in a couple of weeks. Roll up sleeves and get into this Kea and vendor options thing.
Quote from: Patrick M. Hausen on May 08, 2025, 11:32:04 PM- I don't want YADS (yet another DNS server)
Where the
simplest DHCP server would work and there are no other fancy requirements - but AGH is a must - one could simply use the DHCP provided by AGH.
I know dnsmasq is used in some big projects like pi-hole and OpenWRT, however because in so many years there's been no interest in adding support for encrypted DNS protocols makes it a very hard sell for internet traffic next to unbound/knot/stubby/powerdns/AdguardHome.
For relatively basic dhcp services you really cannot go wrong with either ISC DHCP, ISC Kea or dnsmasq, and it's not like either will be going away anytime soon. The biggest headache is finding out which must haves are needed and where do they exist or have a chance of being implemented in the next few years.
I moved to the new setup myself today, and had no issues; seems to be working as well as ISC did. My experience with Kea was a poor one, so at least so far, this seems to be a real improvement over that.
My suspicion is that the default of 'All' for the networks option is likely to cause problems with firewall rules not being applied, and I'd recommend changing that to be perhaps initially blank and requiring a selection to be made, in all cases ensuring that rules are created.
The documentation on this topic was, I felt, very good and easy to follow, and the forwarding setup from Unbound was particularly well described. The one thing I might want to change about it is that the 'DHCPv4 with DNS registration' portion seemed a more complicated use case than what I'd expect to be the norm, i.e., it sets up a subdomain per range, where the ranges correspond to security domains of 'lan' and 'guest'. I'd perhaps precede that use case with one of just setting up a default domain, e.g., 'lan.<tld>' and using that for all ranges.
In dnsmasq you cannot use the same fqdn for all ranges.
If you have devices that advertise the same hostname in different subnets, they would overwrite the managed dns records without having a special domain which makes it unique.
Quote from: Drinyth on May 08, 2025, 10:18:23 PMBut there were some devices on the network that work perfectly fine with ISC/KEA that just refuse to talk to the dnsmasq DHCP service and get an IP?
I believe I observed this behavior as well. In my case, it occurred when a client attempted to renew a lease for an IP address outside the configured range in DNSmasq. For example, requesting a .10 address while the DHCP range was set to .100–.199. 'New' leases were no problem.
For anyone that is feeling apprehensive about doing this swap-over from ISC to DNSmasq:
I'm a complete idiot with a semi-complicated setup, and still got it working first try. The guide is dumbed down enough that I didn't have any issues, and everything is working perfectly fine. It did take me ~1 hour to do it since there were a lot more steps than the initial setup for ISC, but it wasn't difficult (just repetitive).
Quote from: Monviech (Cedrik) on May 09, 2025, 06:47:21 AMIn dnsmasq you cannot use the same fqdn for all ranges.
If you have devices that advertise the same hostname in different subnets, they would overwrite the managed dns records without having a special domain which makes it unique.
But isn't that true even within a subnet? That is, I've got a number of cheap and cheerful WiFi-enabled outlets here, all of them referring to themselves as 'HS105', and, basically, last one in wins, it seems.
Quote from: bazineta on May 09, 2025, 05:07:47 PMQuote from: Monviech (Cedrik) on May 09, 2025, 06:47:21 AMIn dnsmasq you cannot use the same fqdn for all ranges.
If you have devices that advertise the same hostname in different subnets, they would overwrite the managed dns records without having a special domain which makes it unique.
But isn't that true even within a subnet? That is, I've got a number of cheap and cheerful WiFi-enabled outlets here, all of them referring to themselves as 'HS105', and, basically, last one in wins, it seems.
Yes you are correct.
I guess essentially it should not matter then if you use e.g., lan.internal for all ranges.
No success with dnsmasq DHCP - neither with IPv4 nor IPv6. I stuck with the examples from the documentation and only made a few specific tweaks, according to my setup and added a few additional DHCP options. Not sure why all of my devices refuse to get an IP address. I don't even see a request in the logs. A reboot of my OPNsense didn't help either. What a bummer. :(
Firewall rules not set? Automatic rules only work if interfaces are selected or of the LAN pass-all is used.
Cheers,
Franco
Quote from: franco on May 12, 2025, 06:52:02 PMFirewall rules not set? Automatic rules only work if interfaces are selected or of the LAN pass-all is used.
Not sure which rules exactly you mean. There's an allow any inbound traffic rule on my LAN interface. For DHCP ranges I selected my LAN interface.
Edit:
Ah, you might talk about the firewall rules with port 67 and 68. Yes, they're there.
I have to revise my statement: the Dnsmasq DHCP registers firewall rules, but the apply does not reload the filter to activate them. We discussed the code today and a possible solution.
Cheers,
Franco
Even if that is the case, I restarted my OPNsense and that didn't help either.
Ok, different problem. :)
Cheers,
Franco
Strange. I just tried it again without changing anything of the dnsmasq settings and it works now (IPv4 and IPv6). Obtaining an IP address takes much longer than with ISC DHCP though.
Edit:
Anything I can do to fix these warnings in the logs? Sounds like something isn't quite right with my IP reservation for this host.
not giving name Gaming-Server.home to the DHCP lease of XXXX:XX:XXXX:7c00::3 because the name exists in /var/etc/dnsmasq-hosts with address ::3(I censored the IPv6, because it's a valid lease.)
There seems to be still something strange going on with partial IPv6 address reservations in dhcpv6 ranges with constructor.
The documentation on that topic is quite thin though, but Im looking into it.
I'd rather not use partial IPv6 address reservations, but my ISP gives me a dynamic IPv6 prefix. Thanks for looking into it.
Maybe we simply need to stop writing /var/etc/dnsmasq-hosts?
Oh right yeah thats a good guess. We have a script that write all reservations in it.
Maybe we can skip partial ipv6 addresses.
Can anybody tell me what combination of RA modes in dnsmasq DHCPv6 is equivalent to "Assisted" in Services > Router Advertisement, please?
Heres some context I found, I might add this to the documentation later as there are requests to explain it better.
# Do Router Advertisements, BUT NOT DHCP for this subnet.
#dhcp-range=1234::, ra-only
# Do Router Advertisements, BUT NOT DHCP for this subnet, also try and
# add names to the DNS for the IPv6 address of SLAAC-configured dual-stack
# hosts. Use the DHCPv4 lease to derive the name, network segment and
# MAC address and assume that the host will also have an
# IPv6 address calculated using the SLAAC algorithm.
#dhcp-range=1234::, ra-names
# Do Router Advertisements, BUT NOT DHCP for this subnet.
# Set the lifetime to 46 hours. (Note: minimum lifetime is 2 hours.)
#dhcp-range=1234::, ra-only, 48h
# Do DHCP and Router Advertisements for this subnet. Set the A bit in the RA
# so that clients can use SLAAC addresses as well as DHCP ones.
#dhcp-range=1234::2, 1234::500, slaac
# Do Router Advertisements and stateless DHCP for this subnet. Clients will
# not get addresses from DHCP, but they will get other configuration information.
# They will use SLAAC for addresses.
#dhcp-range=1234::, ra-stateless
# Do stateless DHCP, SLAAC, and generate DNS names for SLAAC addresses
# from DHCPv4 leases.
#dhcp-range=1234::, ra-stateless, ra-names
# Do router advertisements for all subnets where we're doing DHCPv6
# Unless overridden by ra-stateless, ra-names, et al, the router
# advertisements will have the M and O bits set, so that the clients
# get addresses and configuration from DHCPv6, and the A bit reset, so the
# clients don't use SLAAC addresses.
#enable-ra
Thank you. Then just setting "slaac" is the right choice for stateful DHCP + SLAAC. "ra-names" is optional, but a good choice to generate DNS names for SLAAC from DHCPv4 leases, if needed.
As I understood it, ra-names does the DNS entries for the DHCPv6 leases, not the DHCPv4 ones. I do not use them, as I only use "unmanaged" RAs. I found that when you use the "dns-search [24]" DHCPv6 option and enable RA with DNSmasq, it also sends DNSSL.
That being said, I am aware of not all types of clients support DNS settings via RA, which is the reason for people using "assisted" mode, however: there is no clear-cut indication what a client should use when dual-stack is in use. What settings take precedence? DHCPv4 or DHCPv6?
That is why I do not use DHCPv6 in presence of DHCPv4 and stay mostly with IPv4 on my LANs. IPv6 is mostly used for internet access. Also, as many others, I only have dynamic IPv6 prefixes, so using DNS on that would be a hassle, anyway.
Quote from: Vexz on May 13, 2025, 05:55:28 PMStrange. I just tried it again without changing anything of the dnsmasq settings and it works now (IPv4 and IPv6). Obtaining an IP address takes much longer than with ISC DHCP though.
Edit:
Anything I can do to fix these warnings in the logs? Sounds like something isn't quite right with my IP reservation for this host.
not giving name Gaming-Server.home to the DHCP lease of XXXX:XX:XXXX:7c00::3 because the name exists in /var/etc/dnsmasq-hosts with address ::3(I censored the IPv6, because it's a valid lease.)
Thanks for this report, I think the fix might emerge from here now:
https://github.com/opnsense/core/issues/8642
https://github.com/opnsense/core/pull/8653