Hi,
I upgraded today from 2026.1.11_10 to 26.7
Since the upgrade my WireGuard setup connecting my home OpnSense with my Azure OpnSense does not come up again.
In error log of WireGuard there is following new entry:
2026-07-16T18:31:17Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </usr/bin/wg syncconf 'wg0' '/usr/local/etc/wireguard/wg0.conf'> returned exit code 1 and the output was "Name does not resolve: `xxxxxxxx.spdns.org:51820' Configuration parsing error"
I tried to recreate the entry but still get this error.
Try using an IP address instead of a DNS name. Name resolution is problematic with WG. It does it only once at startup.
I try to avoid depending on DNS for S2S VPN in general.
We added https://github.com/opnsense/core/commit/67ea4ad76c96 to 26.7, BTW. I'm happily awaiting feedback on this.
Cheers,
Franco
Hi,
since the update to 26.7 I've been having a major issue with Wireguard. It's not an S2S but a C2S setup. I use a Wireguard on-demand VPN on my iPhone that automatically activates when I'm outside my home WLAN (based on SSID). Only traffic to my home LAN is routed through the VPN tunnel to keep VPN usage minimal, while all other traffic goes outside the tunnel. This is achieved by setting the peer's Allowed IPs to 192.168.0.0/24.
After updating to 26.7, neither the traffic through the VPN tunnel nor the traffic outside of it works. The log only displayed the following error:
2026-07-16T07:25:01Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </sbin/ifconfig 'wg0' 'inet' '192.168.1.254' alias> returned exit code 1 and the output was "ifconfig: ERROR: setting interface address without mask is no longer supported."
I set the interface address to 192.168.1.254/32 and restarted the service. The original error disappeared, but four new ones showed up.
2026-07-16T20:25:21Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </sbin/route -q -n add -'inet' '192.168.1.4/32' -interface 'wg0'> returned exit code 1 and the output was "route: message indicates error: File exists"
2026-07-16T20:25:21Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </sbin/route -q -n add -'inet' '192.168.1.3/32' -interface 'wg0'> returned exit code 1 and the output was "route: message indicates error: File exists"
2026-07-16T20:25:21Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </sbin/route -q -n add -'inet' '192.168.1.2/32' -interface 'wg0'> returned exit code 1 and the output was "route: message indicates error: File exists"
2026-07-16T20:25:21Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </sbin/route -q -n add -'inet' '192.168.1.1/32' -interface 'wg0'> returned exit code 1 and the output was "route: message indicates error: File exists"
After another service restart, those errors didn't come back. However, my iPhone still can't send or receive any data while the VPN is active. Since my setup worked flawlessly for two years, it must be related to the update to 26.7.
What could I be missing? Any tips are greatly appreciated!
Best regards!
If you assigned the interface in Interfaces > Assignments try not to put an IP address configuration on it. Leave IPv4 and IPv6 at "none". The VPN > WireGuard > Instances setup will take care of placing an IP address on the interface.
> 2026-07-16T07:25:01Errorwireguard/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </sbin/ifconfig 'wg0' 'inet' '192.168.1.254' alias> returned exit code 1 and the output was "ifconfig: ERROR: setting interface address without mask is no longer supported."
I don't think FreeBSD realises how much damage this does to its users.
ifconfig was probably always setting /24 for 192.168.1.x as long as it existed and now that code is gone and needs to be manually changed everywhere or implemented downstream.
It's very similar to https://github.com/opnsense/core/commit/6e18d2f5c9a886d075dc4f8eea371f6806396602 but for some reason 127.0.0.1 defaults to /0 now.
I just don't see the point of breaking userspace here.
Cheers,
Franco
Quote from: Patrick M. Hausen on July 16, 2026, 09:05:24 PMIf you assigned the interface in Interfaces > Assignments try not to put an IP address configuration on it. Leave IPv4 and IPv6 at "none". The VPN > WireGuard > Instances setup will take care of placing an IP address on the interface.
Actually, in "Interfaces: [WireGuard]" both IPv4 and IPv6 have been and still are set to "none".
Quote from: franco on July 16, 2026, 09:22:38 PMI just don't see the point of breaking userspace here.
Indeed, I don't see it either. If adding it would at least solve my issue. But it doesn't. Error gone, issue not.
OK, then there's a problem introduced by upstream changes as @franco hinted at.
Weird that I do not experience that with my one always on S2S tunnel ... maybe we should try to find what's different?
Just checked ... probably I already got it. I do not have a tunnel address for this connection. You don't need one in WG, you can run just network to network like policy based IPsec. Do you have a tunnel address specified?
I just tried setting one, but both "192.168.0.1" and "192.168.0.1/24" work just the same and do not produce any error if I restart that WG instance.
@franco I rather appreciate that upstream change - what are we looking for in the WG context, specifically?
Quote from: Patrick M. Hausen on July 16, 2026, 11:25:49 PMOK, then there's a problem introduced by upstream changes as @franco hinted at.
Weird that I do not experience that with my one always on S2S tunnel ... maybe we should try to find what's different?
Just checked ... probably I already got it. I do not have a tunnel address for this connection. You don't need one in WG, you can run just network to network like policy based IPsec. Do you have a tunnel address specified?
Yes, let's try to narrow it down. My C2S tunnel has a tunnel address specified. It used to be "192.168.1.254" but due to the error mentioned above, I have changed it to "192.168.1.254/32". This is the only change of my WG configuration that I have made so far. The rest is as it has been for the last two years.
Quote from: Patrick M. Hausen on July 16, 2026, 11:25:49 PM@franco I rather appreciate that upstream change - what are we looking for in the WG context, specifically?
The patch was about the issue that the peer was not initialized during startup (https://github.com/opnsense/core/issues/10475). The reresolve script only changes parameters in the Wireguard connection, it does not restart from scratch.
A Wireguard connection can have a peer (like with outbound s2s or a c2s client), but it does not have to (like with inbound s2s or a c2s server), so the "allowedips" attribute can become empty during WG startup. It definitely will be when the DNS cannot be resolved on startup and the old script did not handle that case yet.
Essentially, the old script handled the case of a changed DNS entry (by reresolving the peer), but it could not create the full connection if the peer was not resolvable in the start phase due to timing conditions (it set the peer, but allowedips was still empty).
So I only mentioned this because: Name does not resolve: `xxxxxxxx.spdns.org:51820'
There's a re-resolve cron job you should use whenever you have DNS-based endpoints for WireGuard which should deal with this better now.
The issue in a nutshell:
wg will not accept the whole configuration if there is a single "syntax" error in the file. Since the kernel doesn't do DNS a syntax error is the absence of an IP address for the peer. Instead of loading everything but the peer address, wg loads nothing and their own example for re-resolve script will not address that fact either. So our re-resolve was extended to add the missing pieces. If these are all missing pieces we don't exactly know.
Cheers,
Franco
I have an IP configured on mine, no problem.
It is always a good idea to use an endpoint IP in WireGuard instead of DNS, if you can.
Quote from: franco on July 17, 2026, 08:55:38 AMSo I only mentioned this because: Name does not resolve: `xxxxxxxx.spdns.org:51820'
There's a re-resolve cron job you should use whenever you have DNS-based endpoints for WireGuard which should deal with this better now.
The issue in a nutshell:
wg will not accept the whole configuration if there is a single "syntax" error in the file. Since the kernel doesn't do DNS a syntax error is the absence of an IP address for the peer. Instead of loading everything but the peer address, wg loads nothing and their own example for re-resolve script will not address that fact either. So our re-resolve was extended to add the missing pieces. If these are all missing pieces we don't exactly know.
Thanks for the insight. What I can definetely say is that my issue is connected to DNS. My firewall log is full of "Default deny / state violation" blocks of my WG client (192.168.1.2) trying to access my DNS (192.168.0.254). This can't be right:
WireGuardIn2026-07-17T09:03:40UDP192.168.1.2:54353192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:03:40UDP192.168.1.2:58855192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:03:32UDP192.168.1.2:54353192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:03:32UDP192.168.1.2:58855192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:03:26UDP192.168.1.2:54353192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:03:26UDP192.168.1.2:58855192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:02:11UDP192.168.1.2:64609192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:02:11UDP192.168.1.2:54895192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:02:03UDP192.168.1.2:64609192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:02:03UDP192.168.1.2:54895192.168.0.254:53blockDefault deny / state violation rule
WireGuardIn2026-07-17T09:01:59UDP192.168.1.2:64609192.168.0.254:53blockDefault deny / state violation rule
There are multiple separate issues getting conflated in this thread. The original post was about failure resolving a peer address from a DNS name. @phaze75's issues have nothing to do with that - rather it (now) appears to be a firewall issue (after getting past the "address without a mask" change - also unrelated to the OP) - the VPN is apparently up, but the firewall is not allowing DNS traffic (and probably any other traffic, but DNS is the first victim). Do you have firewall rules to allow traffic from your WG interface?
Quote from: dseven on July 17, 2026, 10:09:20 AMThere are multiple separate issues getting conflated in this thread. The original post was about failure resolving a peer address from a DNS name. @phaze75's issues have nothing to do with that - rather it (now) appears to be a firewall issue (after getting past the "address without a mask" change - also unrelated to the OP) - the VPN is apparently up, but the firewall is not allowing DNS traffic (and probably any other traffic, but DNS is the first victim). Do you have firewall rules to allow traffic from your WG interface?
Sorry for piggybacking. Wasn't aware of it.
I checked my firewall rules and realized that there has been a change and they have become legacy rules. So, I just migrated them to the new format hoping this would be an easy fix. Unfortunately it was not.
To my understanding my firewall ruleset is the most basic one can have, only consisting of default rules. There is a rule that should cover the WG peers. See attached screenshot. Please correct me if I'm wrong.
Possibly a routing issue, then. I see an OpenVPN rule there - is it possible that you've configured OpenVPN to use the same IP addresses as WireGuard, or something?
Under System -> Routes -> Status, do you see a route for destination 192.168.1.2, pointing to your wireguard interface?
Quote from: dseven on July 17, 2026, 10:36:39 AMPossibly a routing issue, then. I see an OpenVPN rule there - is it possible that you've configured OpenVPN to use the same IP addresses as WireGuard, or soemthing?
Under System -> Routes -> Status, do you see a route for destination 192.168.1.2, pointing to your wireguard interface?
No, I don't use OpenVPN anymore. There is no instance running and no interface assigned.
Yes, there are four routes 192.168.1.1-.4 for each of my four peers pointing to "wg0", which is my WG interface.
It's a bit of a shot in the dark, but you could try:
Firewall -> Diagnostics -> States -> Actions -> Reset state table
in case there's something funky left over from earlier issues.
Failing that, I'm not sure why you'd be hitting the default rule....
Quote from: dseven on July 17, 2026, 11:28:44 AMIt's a bit of a shot in the dark, but you could try:
Firewall -> Diagnostics -> States -> Actions -> Reset state table
in case there's something funky left over from earlier issues.
Failing that, I'm not sure why you'd be hitting the default rule....
I reset the state table, but the firewall keeps blocking.
I just created a dedicated rule from "192.168.1.2" to "LAN network" and moved the rule to the top of the "Interface rules" stack. That works, but it can't be the solution.
Quote from: phaze75 on July 17, 2026, 12:15:21 PMI just created a dedicated rule from "192.168.1.2" to "LAN network" and moved the rule to the top of the "Interface rules" stack. That works, but it can't be the solution.
Oh, "WireGuard network" probably isn't covering your peers. Does your WireGuard interface have an IP address? Your "Instance" should have a "Tunnel address" with a netmask that covers the range of addresses of your peers.
Actually that might not do it - you might have to configure an address on the assigned interface for that to work. I'm not sure - my rule doesn't specify a source address - just allows anything coming from the WG interface.
Quote from: dseven on July 17, 2026, 12:29:09 PMOh, "WireGuard network" probably isn't covering your peers. Does your WireGuard interface have an IP address? Your "Instance" should have a "Tunnel address" with a netmask that covers the range of addresses of your peers.
Yes, the "Tunnel address" is "192.168.1.254/32" and my four peers are listed within the instance. Until 26.7 the "Tunnel address" was "192.168.1.254". This is where the whole mess started.
Quote from: phaze75 on July 17, 2026, 12:35:48 PMYes, the "Tunnel address" is "192.168.1.254/32" and my four peers are listed within the instance. Until 26.7 the "Tunnel address" was "192.168.1.254". This is where the whole mess started.
For giggles, try /24 instead of /32
Quote from: dseven on July 17, 2026, 12:38:25 PMFor giggles, try /24 instead of /32
I don't know if I should giggle, laugh, blush or cry. Maybe all of it. 🤦🏼That's it, issue SOLVED. Thank you so much! 🙏🏼
Nice :)
So (from what Franco said earlier), it sounds like FreeBSD used to just assume /24 if a netmask wasn't supplied. Whilst the breaking change is a bit inconvenient, that does seem a bit presumptuous, and I think they probably were right to fix it.
Why it matters for you: you're using a "dynamic alias" in your firewall rule - "WireGuard network" means "the local network currently configured for the WireGuard interface". If the interface address was 192.168.1.254/32. the local network would also be 192.168.1.254/32, and 192.168.1.2 is not part of that, hence the rule didn't match. By changing the netmask to /24, the network changes to 192.168.1.0/24, which 192.168.1.2 is part of.
Quote from: dseven on July 17, 2026, 12:54:23 PMWhy it matters for you: you're using a "dynamic alias" in your firewall rule - "WireGuard network" means "the local network currently configured for the WireGuard interface". If the interface address was 192.168.1.254/32. the local network would also be 192.168.1.254/32, and 192.168.1.2 is not part of that, hence the rule didn't match. By changing the netmask to /24, the network changes to 192.168.1.0/24, which 192.168.1.2 is part of.
Now that we've solved it, everything makes sense. Still, to save a bit of face, I'd like to point out that the term "Tunnel address" in the "Instance" config doesn't really suggest a netmask larger than one (tunnel) address. So it seemed logical to use the /32 netmask instead of /24 for the tunnel's single IP. I'd suggest adding a small note next to the field to save others the same confusion - though maybe that's just me. 😅
/32 will work for the tunnel address. It's just that you can't use the dynamic alias if you do that. You could use static aliases for the source address, or just not specify any source address (i.e. "any").
Quote from: dseven on July 17, 2026, 01:10:18 PM/32 will work for the tunnel address. It's just that you can't use the dynamic alias if you do that. You could use static aliases for the source address, or just not specify any source address (i.e. "any").
That's clear now. I don't remeber the exact steps I took when setting up WireGuard, but I'm 99.9% sure the firewall rule(s) were configured automatically or manually exactly as described in the documentation. If the standard rule uses a dynamic alias for "Source," I'd suggest making sure this "WireGuard network" alias aligns with whatever is entered as the "Tunnel address" in the "Instance" configuration. Especially if BSD has previously assumed or suggested a /24 netmask.
Not meaning to argue, but https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-1-configure-the-wireguard-instance does rather clearly state:
"The tunnel address must be in CIDR notation and must be a unique IP and subnet for your network, such as if it was on a physically different routed interface. The subnet should be an appropriate size that includes all the client peers that will use the tunnel. For IPv4 it should be a private (RFC1918) address, for example 10.10.10.1/24. For IPv6, it could either be a unique ULA /64 address, or a unique GUA /64 address derived from your prefix delegation. Do not use a tunnel address that is a /32 (IPv4) or a /128 (IPv6)"
True. Should have read the documentation (again). My bad.