[SOLVED] Dnsmasq DHCP - Not possible to delete dynamic lease?

[jamesaepp]

I'm feeling like an idiot right now. I tried STFW and the forum and not finding an obvious answer. I swear I read something recently that this was a (recently new?) feature but I'm struggling.

Is it seriously not possible to delete a DHCP lease under DNSmasq? I am looking at Services > Dnsmasq DNS & DHCP > Leases and staring at a table of leases, but there's no UI indication on a way to delete/forget a lease.

I tried rebooting the OPNsense firewall as a hail mary but unsurprisingly that didn't do anything.

[Monviech (Cedrik)]

It did not make the cut:

https://github.com/opnsense/core/pull/8899

[jamesaepp]

Thanks for sharing. If I'm reading that right, the "issue" that caused me to ask the question (reservation not seeming to take effect) is likely an issue with the client system in question not doing a release.

[Monviech (Cedrik)]

Yeah the client system either needs a reboot or a DHCP RELEASE, but it would need one anyway even if you delete a lease from dnsmasq.

There is no mechanism to tell the client "hey get rid of your current dhcp lease and take a new one".

Only the client can do this via a DHCP RELEASE, or when it asks via a new DHCP DISCOVER after e.g. restarting the network interface or a reboot.

Dnsmasq will then offer the new IP address that was reserved during the next DHCP DISCOVER cycle.

[jamesaepp]

What's funny is I did reboot the client system and that didn't influence the behavior either. Idk. Don't want to overthink it.

[abraxxa]

I just had the case where dnsmasq handed out the IPv4 or a lease instead of the static configured one requiring to delete the lease in /var/db/dnsmasq.leases manually.
Please reconsider this pull request!

[jamesaepp]

Idk. I'm on the fence on whether this "issue" merits a dev response or not.

It certainly would be a nice to have and similar router/firewall software offer lease deletion.

However, this is a "two to tango" and in my case, my client (TrueNAS, but I fail to recall what version it was at the time) eventually did pick up the new lease after the existing lease expired (IIRC my setting is a 24-hour lease). A simple administrator workaround is to appropriately configure their lease times.

I agree with a previous commentor where they said (paraphrasing) that if the DHCP client isn't RFC compliant and isn't assuming it should grab a totally new lease on reboot, it's the fault of the client and not OPNsense. To this part, I am in full agreement. I certainly can't quote the RFC off the top of my head, but I recall reading language within it that DHCP clients should not assume they're on the same network segment as before a major system event such as a reboot. I think there's something in there about a NIC connection change too, but again - none of this is direct quote, simply sensible.

[abraxxa]

My use case is onboarding a new device on the network not knowing its MAC address.
When the dynamic lease is created I create a static with some fixed IPv4/6 addresses for it and want it to be picked up immediately when I reconnect the device to my network.

This is from my dnsmasq logs where the dynamic assigned 10.0.0.92 from the initial dhcp discover was assigned by dnsmasq although I already had created a static entry for 10.0.0.231
2025-08-08T16:43:47 Informational dnsmasq-dhcp DHCPACK(re1_vlan1) 10.0.0.92 8c:30:66:7e:29:5c
2025-08-08T16:43:47 Informational dnsmasq-dhcp DHCPREQUEST(re1_vlan1) 10.0.0.92 8c:30:66:7e:29:5c
2025-08-08T16:43:43 Informational dnsmasq-dhcp DHCPOFFER(re1_vlan1) 10.0.0.92 8c:30:66:7e:29:5c
2025-08-08T16:43:43 Informational dnsmasq-dhcp DHCPDISCOVER(re1_vlan1) 8c:30:66:7e:29:5c

[Monviech (Cedrik)]

But it does without deleting a lease, just dont forget to hit apply.

https://github.com/opnsense/core/pull/8899#issuecomment-3033118948

[abraxxa]

It didn't work as my logs prove...

[jamesaepp]

Yeah....I just did a similar set of work today, not exactly the same....but dnsmasq doesn't appear to be respecting the host configuration. I absolutely hit the apply button and I even restarted dnsmasq for good measure, but the packet capture is clear as day. When the DHCP client rebooted, it did a DHCP discover requesting the temporary/dynamic/lease-pool address it had previously, offered it, and acknowledged it.

[Monviech (Cedrik)]

EDIT:

Ive read the RFC norm and there is an INIT-REBOOT behavior where the client will actually try to get the last IP it remembered before the reboot.

It looks like only a clean DHCP RELEASE will break this behavior.

Or DNSMASQ should send a DHCP-NAK to refuse giving out the IP the client requests.

RFC2131:

DHCPREQUEST generated during INIT-REBOOT state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST be filled in with client's notion of its previously
      assigned address. 'ciaddr' MUST be zero. The client is seeking to
      verify a previously allocated, cached configuration. Server SHOULD
      send a DHCPNAK message to the client if the 'requested IP address'
      is incorrect, or is on the wrong network.

[Monviech (Cedrik)]

The source code of dnsmasq shows specific behavior for this scenario:

https://github.com/imp/dnsmasq/blob/770bce967cfc9967273d0acfb3ea018fb7b17522/src/rfc2131.c#L1305

If client requests old IP but a matching dhcp-host exists with a different IP and that IP isn't currently leased → set reason "static lease available" → NAK.

If the requested IP is reserved for some other host → set reason "address reserved" → NAK.

Otherwise, ACK if valid/available.


Maybe checking the option DHCP Authoritative in the general dnsmasq options make a difference.

The code path seems to reference it as well.

[jamesaepp]

Setting the checkbox for "DHCP authoritative", applying, restarting dnsmasq, and then restarting the client had no effect. Client still requests and is given the leased IP.

[Monviech (Cedrik)]

Then you must have taken one of the code paths stated above:

- The reservation IP address was already dynamically leased to another host. In that case the original host will receive the old IP as fallback, until that lease expires. Otherwise there would be duplicate IP addresses.

Can you check for that?

(Please keep in mind, deleting a lease from the database does not tell any client in the network to drop their current lease)