Messages

True. Should have read the documentation (again). My bad.

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

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. 

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

For 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! 🙏🏼

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.

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.

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. 

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

I reset the state table, but the firewall keeps blocking.

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

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?

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.

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


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.

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.

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

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!

Thanks, @meyergru and @Monviech (Cedrik). The issues have been resolved with v0.4.5 of the OPNsense integration "hass-opnsense".