Dnsmasq DHCP on new guest interface receives Discover but sends no Offer

[bernieo]

Dnsmasq DHCP on new guest interface receives Discover but sends no Offer until a manual dnsmasq override is added

## Summary

I ran into what looks like a Dnsmasq/OPNsense edge case while adding a new guest Wi-Fi interface.

A new guest subnet/interface was created and DHCP was enabled in the OPNsense GUI. The network path itself was confirmed working:

* client DHCP Discover packets reached the correct guest interface
* `dnsmasq` was running and listening on UDP 67
* the generated `dnsmasq.conf` already contained a DHCP range for the new interface

Despite that, no `DHCPOFFER` or `DHCPACK` was sent.

The issue was only resolved after adding a manual override file under:

```text id="y967c9"
/usr/local/etc/dnsmasq.conf.d/
```

with an explicit interface-scoped DHCP definition for the guest interface, then restarting `dnsmasq`.

After that, DHCP immediately worked and guest clients could:

* obtain leases
* resolve DNS
* access the internet
* remain isolated from internal RFC1918 networks

## What makes this look like a bug / edge case

Before the workaround:

* DHCP Discover packets were definitely arriving on the intended guest interface
* the interface was up and addressed correctly
* the generated `dnsmasq.conf` already had a DHCP range for that interface
* but `dnsmasq` never sent an Offer

After adding an explicit manual override for that interface:

* `DHCPOFFER`
* `DHCPREQUEST`
* `DHCPACK`

all appeared immediately.

So it seems the GUI-generated scope existed, but was not actually sufficient for live DHCP service on that new interface.

## Workaround that fixed it

A custom dnsmasq drop-in file was added with explicit interface binding plus router/DNS options for the guest subnet, followed by:

```sh id="c8b9xw"
configctl dnsmasq restart
```

## Question

Has anyone seen this before with newly added interfaces/VLAN-backed guest networks in OPNsense using dnsmasq?

I have a fuller write-up with config excerpts and before/after packet captures if needed, but I wanted to start with a cleaner summary first in case this is already a known issue.