DHCP via DNSmasq in 25.1.6: IPv6 OK, IPv4 not working properly

[dinguz]

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.

[Drinyth]

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.

[franco]

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

[Patrick M. Hausen]

This - while good to have that option - will possibly lead to support issues 😉



Activated is the default, so all good. Not criticising having it available.

[franco]

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.

[Patrick M. Hausen]

Just from the docs it wasn't absolutely obvious: is DNSmasq a full recursive resolver or does it need an upstream server?

[franco]

It needs an upstream server, but you could chain it through local unbound ;)

[Patrick M. Hausen]

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.

[Monviech (Cedrik)]

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

[Drinyth]

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.

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.

[Patrick M. Hausen]

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

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.

[newsense]

- 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.

[bazineta]

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.

[Monviech (Cedrik)]

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.

[dinguz]

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 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.