opnsense
DNSmasq: Fails to start during boot
Since the release that introduced the DHCP functionality to DNSmasq I am having issues with it after boot.
When OPNsense starts I always find the DNSmasq dead with these two lines in the log:
Critical dnsmasq FAILED to start up
Critical dnsmasq unknown interface wg1
When I manually start DNSmasq it works just fine without any issues reported in the log.
After some googling I have found that it can be workarounded by disabling the Strict Interface Binding option of DNSmasq.
That sort of works, but doesn't solve the root cause.
DNSmasq starts after boot with that option disabled, but there are following two lines in the log:
Warning dnsmasq warning: interface wg1 does not currently exist
Warning dnsmasq warning: interface wg2 does not currently exist
And Wireguard clients are not able to use the DNS, so they report not having internet access. When I manually restart DNSmasq it starts working for them.
My assumption is, that something changed regarding the order in which things are initialized during boot and due to it DNSmasq is being started before all the interfaces are initialized (at least Wireguard interfaces are obviously not yet available). Maybe it was introduced by this commit as it changes how DNSmasq binds to interfaces🤷♂️
I am now on OPNsense 25.1.9_2-amd64 and it still behaves the same.
Thank you for creating an issue. Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
The easiest option to gain traction is to close this ticket and open a new one using one of our templates.
strict interfaces binding can only be used reliably for static (physical) interfaces as noted in the help text.
FWIW, curious as to why "interfaces" are not created at startup: if wg1 and wg2 are assigned as interfaces they would be created on startup before Dnsmasq, but that is currently not the case for unassigned devices (and never was). I don't think this ever came up and there are far superior mechanisms to deal with dynamic device bindings.
@fichtner what do you mean by this?
if wg1 and wg2 are assigned as interfaces they would be created on startup before Dnsmasq, but that is currently not the case for unassigned devices
In case you are talking about the assignments defined on the Interfaces: Assignments screen, then I have both Wireguard interfaces (wg1/2) assigned. Yet they are obviously not created or available before the DNSmasq 🤷
I have the same issue, but can't remember when it exactly started. Just finished migrating OPNSense from phiysical to virtual on my homelab, and rebooting more then normally. Currently on OPNSense 25.1.11
Simular log entries: 2025-07-16T17:40:54 Critical dnsmasq FAILED to start up 2025-07-16T17:40:54 Critical dnsmasq unknown interface wg1
If I have to guess I'd say that dnsmasq is started early in the boot process, while wireguard isn't started yet, so there is no wg1 interface yet. After OPNsense finished booting (And wireguard is running) there is no issue when starting dnsmasq manually.
My workaround was removing the wireguard interface from dnsmasq's listening interfaces. My wireguard clients are now using my Pi-Hole DNS servers instead of OPNSense/dnsmasq.
I get similar error with dnsmasq on ovpns2. Though interestingly I also have a wg1 interface that doesn't show an error, but possibly it's erroring out on ovpns2 before getting to wg1. I also have both ovpns2 and wg1 assigned interfaces. Things also work fine by starting dnsmasq manually after bootup.
Critical dnsmasq FAILED to start up Critical dnsmasq unknown interface ovpns2
disable strict binding to prevent race conditions...
@AdSchellevis as explained in the OP that doesn't fix the problem. It only prevents dnsmasq from crashing. But the result is it doesn't listen on the interfaces which are not present when it starts. For example in my case wireguard clients do not have dns until I manually restart dnsmasq 🙁
https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
According to the source, it's only warning, it doesn't change the actual list of interfaces used by Dnsmasq:
https://github.com/imp/dnsmasq/blob/770bce967cfc9967273d0acfb3ea018fb7b17522/src/dnsmasq.c#L941
(when listening on any, it omits these)
I can confirm the same. Strict binding doesn't crash but wireguard doesn't work until dnsmasq restart. In the same time, wireguard may not start because if you have dns name for endpoint it will not resolve. So it is a loop. Maybe togetherof listening to interface, listen to IP? They can be combined
Then you simply cannot use a WireGuard host name in the setup you have set up.
Yeah maybe if you have static IP could be used instead of or some external DNS server (so no dependencies from dnsmasq) but that somehow defeat the reasons why exist the possibility of adding domain in case of DDNS which is the vast majority of internet users around the world. I planning to add as extra configuration the listening IP to see if that works better.
The OPNsense simply needs a working DNS server in /etc/resolv.conf for WireGuard to work. The issue that Dnsmasq fails to use WireGuard is because it expects an IP address which it cannot get since there is no working DNS. The other issue is that if you use strict binding you run into circular dependencies like this that you cannot solve with a simple DNS -> VPN start sequence. Look at rc.syshook facility to wire your restarts correctly... https://docs.opnsense.org/development/backend/autorun.html
So I tried the option and it didn't work because combining both needs the IP to belong to some interface. Also I can't really use the listen-address alone because in GUI not selecting interface means ALL. Interestingly selecting one, two or none (aka all) interface, sockstat has the same output. nobody dnsmasq 28297 4 udp4 *:67 : nobody dnsmasq 28297 8 udp6 *:547 : nobody dnsmasq 28297 10 udp4 *:53 : nobody dnsmasq 28297 11 tcp4 *:53 : nobody dnsmasq 28297 12 udp6 *:53 : nobody dnsmasq 28297 13 tcp6 *:53 :
While I see in dnsmasq.conf the option inteface= it seems that doesn't really have effect, except if the for opnsense DNS (for DHCP is written) is working with firewall to "block" interfaces from DNS
On Tue, Nov 25, 2025 at 2:43 PM Franco Fichtner @.***> wrote:
fichtner left a comment (opnsense/core#8895) https://github.com/opnsense/core/issues/8895#issuecomment-3575730495
Ok, I cannot recommend doing that in your case.
— Reply to this email directly, view it on GitHub https://github.com/opnsense/core/issues/8895#issuecomment-3575730495, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWRA63LY766YX4ZOWYPMUL36RMIRAVCNFSM6AAAAACAPM4GOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZVG4ZTANBZGU . You are receiving this because you commented.Message ID: @.***>
-- Thank you Alexandros
I have found out that with the dnsmasq configured to not use strict binding (to prevent it to crash on missing WG interface) what makes the DNS to start working for Wireguard clients is also to reload the firewall.
Restarting dnsmasq fixes it too.
So it looks like something is not done in correct order when opnsense boots and something in the network stack needs to get reloaded once everything is up🤷♂️
So whenever my opnsense restarts, I have to poke it manually to make it work again😞 Luckily I am able to do it even over the WG from my phone as I can access it just fine, it just doesn't resolve DNS requests till I poke it...
You can (re)start any service with the rc.syshook facility with a tiny script.