Messages

All I can see from these reports is that DNS resolution isn't working when the tunnel is supposed to come up (if the message is actually the error to look into and not a cosmetic oddity as it could be restarted later anyway). A reboot is also the most likely point DNS resolution isn't up and running yet or is worst case routed through a tunnel that isn't up yet.


Cheers,
Franco

I agree that is definitely the issue here. I just don't know what changed in the last two versions where this is now a factor and it wasn't before. I never had the issue and I've had the same configuration since 24.x series.

I would love to bisect this issue if there's a way to go change-by-change in the router

I started seeing the same exact issue as you that started happening on all my routers. Some regression was introduced in the previous release (26.1.6) or the one before that (26.1.5). I don't know which one it was because 26.1.5 didn't require a reboot so that could have been the culprit but I don't know because I didn't reboot. I only had to reboot after applying 26.1.6, and it started happening on all my routers after that reboot.

https://forum.opnsense.org/index.php?topic=51578.msg

Other people have reported it as well:

https://forum.opnsense.org/index.php?topic=50748.msg
https://forum.opnsense.org/index.php?topic=32232.msg

And if you do a search, there's many, many, more older posts with the same problem.

I'm not sure what changed in the last month or two, but I have never changed my configuration or had this issue up until I applied two updates and then rebooted.

So the issue is either a regression in 26.1.5 or 26.1.6

[2026-04-10T07:35:41-04:00Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </usr/bin/wg syncconf 'wg1' '/usr/local/etc/wireguard/wg1.conf'> returned exit code 1 and the output was "Name does not resolve: `mydomain.com:1234' Configuration parsing error"]

I just upgraded to 26.1.6 which required a reboot. When my opnsense router came back online, my Wireguard tunnel was not working. Looking at the logs:

2026-04-10T07:35:41-04:00Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </usr/bin/wg syncconf 'wg1' '/usr/local/etc/wireguard/wg1.conf'> returned exit code 1 and the output was "Name does not resolve: `mydomain.com:1234' Configuration parsing error"

Restarting the Wireguard service fixed this. I'm using Kea DHCP and I'm using Unbound for DNS but it appears that Wireguard was perhaps started before DNS could start. "Renew DNS for WireGuard on stale Connections" Cron does not fix this because the service never successfully started.

I'm not sure whether this regression was introduced in 26.1.6 or one of the last few versions that didn't require an OS reboot. I've never had this issue before on this router for the last few years until this recent OS reboot

kea 2.6.3 supports DHCP lease affinity, but the configuration options haven't yet been exposed in OPNsense GUI

https://forum.opnsense.org/index.php?topic=48462.0

https://github.com/opnsense/core/issues/9094

In current OPNsense 25.7.1_1 release, manually editing the kea config file to add the options, are overwritten / removed when kea service is re-started ( from either OPNsense GUI or cli)...

Thanks for posting this. https://github.com/opnsense/core/issues/9094 is exactly what we would need to address the issue.

Basically, the good news is KEA does expose some tunables to make it behave like ISC with regard to lease recycling. The bad news is, opnsense doesn't expose any of that to the user via the web gui.

What I can picture though, is Kea more aggressively reusing addresses for which the lease has expired and handing them out to a different client.
I would make a protocol with tcpdump when you power on such a client after a couple of days to watch if that is what happens.

That's exactly what's going on. Same clients I've been using for years. I ran tcpdump and fed the pcap into wireshark to look at. KEA is just recycling addresses much more aggressively than ISC.

I don't see an option to change this behavior in the opnsense web gui, so I'd probably have to change something in the KEA conf file.

I'm not sure, but I think that the conf file would get overwritten by opnsense on boot/upgrade/config change, so I'd have to manually change the KEA conf file every time, unless there is a better way to do this? Ideally like a "free-form" "advanced options" that can get appended to the KEA Conf file via the opnsense web gui. I've seen opnsense do this for other things like OpenVPN settings.

Just switched everything over from using ISC DHCP to KEA DHCP. I noticed one annoyance.

Assume IPv4 only and a 1 hour DHCP lease for both ISC and KEA:

In ISC DHCP, If I have a host that I only turn on every few days or so, it will always get the same address from the pool.

In KEA DHCP, If I have a host that I only turn on every few days or so, it will get a different address from the pool.

So for example, if the reservation range is from .100 to .120, one day I may get .101, and another day I might get .100 if I didn't give out any IPs since the last time the machine was on.

I don't want to increase the lease time because I want the client to request a new lease frequently in case something changes.

ISC DHCP was much better about giving previous addresses out. I never exhaust the pool range, so it was pretty much similar to having static entries without needing to make static entries.

With ISC DHCP, I can have the machine off for weeks and still get the same dynamic IP address it gave me  a while back.

Is there any way to make KEA remember IP addresses better and behave like ISC in that regard?

[For people that have this issue:]

I figured it out. You were right franco, thanks. It was an invalid configuration that was allowed through the opnsense validator at some point in the past.

For people that have this issue: Check if you've assigned a static ip address to your wireguard interface. You would be able to see this under Interface->[Your wireguard interface].

If you go to this page and press save without making ANY changes, opnsense will yell at you with an error message. Make the fix (in my case, don't assign a static ip address), then press save, apply the changes, and then restart wireguard. The routes will now get propagated.

I feel like the page should not have had "Static IPv4" as a drop down option if it's a wireguard interface.

Is there anything in opnsense that could find invalid configuration entries like that in the future? I did a health check previous to this and that said everything looked good.

I suspect it's related to commits on:

https://github.com/opnsense/core/issues/7304

Routes are no longer being propagated in Wireguard since the update. Statically adding the routes is a workaround, but there is a bug in opnsense:

Configuration:

Code Select Expand


root@router:~ # cat /usr/local/etc/wireguard/wg1.conf
####################################################
# Interface settings, not used by `wg`             #
# Only used for reference and detection of changes #
# in the configuration                             #
####################################################
# Address =  192.168.10.2/24
# DNS =
# MTU =
# disableroutes = 0
# gateway =

[Interface]
PrivateKey = ...
ListenPort = ...

[Peer]
# friendly_name = ...
PublicKey = ...
PresharedKey = ...
Endpoint = ...:...
AllowedIPs = 192.168.10.1/32,192.168.20.1/24


I can successfully ping the remote "Wireguard transfer net IP"

Code Select Expand


root@router:~ # ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=60.482 ms
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=28.849 ms
^C
--- 192.168.10.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.849/44.666/60.482/15.817 ms


I can't ping the remote network

Code Select Expand


root@router:~ # ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
^C
--- 192.168.20.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss


The remote network is not showing up in the routing table even though its in the "Allowed IPs"

Code Select Expand


root@router:~ # netstat -rn|grep wg1
192.168.10.0/24    link#15            U           wg1


Manually adding the remote network as a static route to the wireguard interface

Code Select Expand


root@router:~ # route add -net 192.168.20.1/24 -interface wg1
add net 192.168.20.1: gateway wg1


Confirming it's there

Code Select Expand


root@router:~ # netstat -rn|grep wg1
192.168.20.0/24    link#15            US          wg1
192.168.10.0/24    link#15            U           wg1


Now I can ping the remote network as it's getting routed through the wireguard interface

Code Select Expand


root@router:~ # ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=29.310 ms
64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=30.184 ms
^C
--- 192.168.20.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 29.310/29.747/30.184/0.437 ms


I would love a better workaround for this until it's fixed as I don't want to be manually adding static routes.

Seeing the same issue here. WG site to site worked fine until I upgraded.

Code Select Expand

# opnsense-revert -r 24.1.4 opnsense

does not fix it.

I noticed that the OS routing table is not showing any of the allowed IPs I have under the Site to Site peer. I can successfully ping the remote "Wireguard transfer net IP" when I SSH into the router but that's about it.

"Disable routes" is Unchecked and I've rebooted multiple times.

I looked at `/usr/local/etc/wireguard/*.conf` and everything looks good.

Performing a traceroute on the router, I can see that the issue is that because the routes from the "Allowed IPs" are not getting propagated to the OS the packets are exiting the WAN / default gateway interface instead of going to the wireguard interface.

Anything under Wireguard->Peers->Allowed IPs should be showing up when I do a `netstat -rn` on the router, correct? I think there was a regression introduced and that's the bug.

I just found this post and figured it would be helpful to people here who are watching it for any updates / progress.

For people who are doing MAC spoofing, the port flapping was caused by a bug that was introduced in 22.1.2.

It's been fixed as of this commit thanks to Franco:

https://github.com/opnsense/core/commit/d19cd6cdbf4da581f71e5483b279f82fb4396bec

[EDIT:]

I changed:

Code Select Expand

if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif, $ifconfig_details))) {

to

Code Select Expand

if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif))) {

and that fixed it as it used $interface with legacy_interface_details() in get_interface_mac() because $ifconfig_details is null.

Wow, I can't believe mac spoofing has been broken that long and nobody complained! I guess nobody uses that feature.

EDIT:

Saw your commit here:

https://github.com/opnsense/core/commit/d19cd6cdbf4da581f71e5483b279f82fb4396bec

Thanks.

Code Select Expand

    /*
     * Don't try to reapply the spoofed MAC if it's already applied.
     * When ifconfig link is used, it cycles the interface down/up,
     * which triggers the interface config again, which attempts to
     * spoof the MAC again which cycles the link again...
     */
    if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif, $ifconfig_details))) {
        mwexecf('/sbin/ifconfig %s link %s', [$realhwif, $wancfg['spoofmac']]);
    }

I believe this is the code that keeps calling ifconfig and cycling the interface up and down. New logic was added in the conditional that broke this check:

https://github.com/opnsense/core/commit/13388839e7e

Even the comment above it describes the issue that is popping up.

I tried a few different versions and discovered that it works on 22.1.1. I believe it's one of these two commits that broke mac spoofing:

https://github.com/opnsense/core/commit/13388839e7e
https://github.com/opnsense/core/commit/84cd38adb558

My bet is on the former since it specifically has to do with mac spoofing.