Wireguard S2S broken

[QuisaZaderak]

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.

[Patrick M. Hausen]

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.

[franco]

We added https://github.com/opnsense/core/commit/67ea4ad76c96 to 26.7, BTW.  I'm happily awaiting feedback on this.


Cheers,
Franco

[phaze75]

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:

Code Select Expand

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.

Code Select Expand

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!

[Patrick M. Hausen]

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.

[franco]

> 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

[phaze75]

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.

Actually, in "Interfaces: [WireGuard]" both IPv4 and IPv6 have been and still are set to "none".

[phaze75]

I 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.

[Patrick M. Hausen]

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?

[phaze75]

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?

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.

[meyergru]

@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. 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).

[franco]

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

[Bob.Dig]

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.

[phaze75]

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.

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:

Code Select Expand

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


[dseven]

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?