wgdown.webp
wg1.webp
An error occurs on the WireGuard peer configured for selective routing, and it does not start after boot. If the service is restarted manually, it works correctly.
I am facing the same issue after upgrading to latest patch OPNsense 26.1.10-amd64.
The issue also occurred in version v26.1.9
Was it working before? 26.1.9? Or we don't know?
Before v26.1.9, everything was working normally. The only difference is that I had configured one OPNsense native WireGuard instance and one selective routing setup.
In v26.1.10, the OPNsense WireGuard tunnel still works properly even after a reboot, but the selective routing configuration does not work.
This is not an issue with the VPN server or the configuration file.
Did you install any public VPN instances (e.g. Mullvad) into the WireGuard group without the "Disable routes" option?
I think I saw this too when I was adding instances recently, but I moved the VPNs off to dedicated interfaces (with gateways in my case) and rebooted to flush the routing table.
I'm only keeping my private s2s and road warrior instances on the default WG group and this seems OK.
IIRC, instances with peers having 0.0.0.0/0 or ::/0 in the Allowed IPs list might be getting added as default routes, causing a conflict. I'd need to retest this though because my memory could be failing.
- no wireguard group
- set(check) Disable routes
Quote from: Lucid1010 on June 19, 2026, 07:25:47 AM- no wireguard group
- set(check) Disable routes
Can you elaborate on the "no wireguard group"?
It was created for me when I created the initial road-warrior WG connection, but it is only present in the FW Rules section, and I've kept it blank. All of the rules are at the individual WG interface - firewall rules. I currently have about 8 WG connections working with "set (check) disable routes)". Traffic is per interface routed, and rules per interface, nothing is configured for the WG Group that only appears at the firewall rules section.
thanks
I was thinking about opening my own topic but don't want to clutter the forum.
If it turns out our cases are totally not related, I'll open another topic.
Really been pulling my hairs the last couple of days.
Had a perfectly working dual wireguard connection to Torguard in failover mode using a gateway group with separate monitor IPs. (FAR Gateway enabled and Disable routes enabled on the instance)
Currently running OPNsense 26.1.10 (amd64) on a physical box but unsure when the issues started to be honest.
I'm seeing strange issues with my wireguard setup.
With strange I mean:
packet loss with simple pings
ping -c 20 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=5.76 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=5.98 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=8.22 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=12.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=7.69 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=116 time=7.89 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=116 time=5.56 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=9.48 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=116 time=6.35 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=5.65 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=116 time=5.94 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=116 time=6.88 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=116 time=6.69 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=116 time=5.89 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=116 time=5.81 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=116 time=6.22 ms
--- 8.8.8.8 ping statistics ---
20 packets transmitted, 16 received, 20% packet loss, time 19141ms
rtt min/avg/max/mdev = 5.558/7.035/12.573/1.791 ms
I do the test again a few minutes later and I get no ping timeouts.
commands like curl ifconfig.io taking 1 second and 4-5 seconds the next minute or not giving a reply at all.
Things I tried:
- Decreased the priority of the wireguard from 255 to 10
- Changed keepalive to 15
- Changed my dual tunnel setup to a single tunnel and deleted my gateway group..
- doubled checked mtu
ifconfig wg2
wg2: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
description: TorGuard_WG_Tunnel_00 (opt9)
options=80000<LINKSTATE>
inet 10.13.128.145 netmask 0xfffffffe
groups: wg wireguard
nd6 options=9<PERFORMNUD,IFDISABLED>- I'm seeing the issues from a VM that is only allowed access to the outside through wireguard so added firewall rules and outbound NAT rules to place a laptop also behind the VPN and also the same packet loss issue. (up to 70% on the first attempt, 0% on the second attempt,30% on the third attempt)
- Checked github:
maybe somewhat related? https://github.com/opnsense/core/issues/10421
Things I also have that are mentioned in that thread:
UDP "no socket" drops — counter climbing continuously
netstat -s -p udp | grep "no socket"
6154189 dropped due to no socket
sockstat — socket process ownership shows as unknown
sockstat -4 | grep -E "57011"
? ? ? ? udp4 *:57011 *:*netstat -I wg2
Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll
wg2 1420 <Link#21> wg2 12511586 0 0 943160 0 0
wg2 - 10.13.128.144/31 10.13.128.145 16 - - 0 - -
I'm now going to try to connect to another ip at the VPN provider to see if that makes any difference.
...I see stuff with WG tunnels (non-connecting, stopping randomly, not starting services on reboot) which shows no pattern or is not related to any changes at the endpoints. There is something weird going on.
Sometimes a restart of the service resolves it, sometimes a reboot is needed. On an ancient pfsense I have to re-install (!) the WG plugin (via another, working WG tunnel to another opnsense, really scary if you are remote...) to make a specific tunnel to an opnsense come up again from time to time.
Well as this point at my end it looks like things are stable at the moment after switching to another peer server at the VPN provider.
Never experienced something like that but pings are now not seeing packet loss and curl command are also stable.
Maybe the server I was connecting to was overloaded or having a bad week.
Sorry did not mean to muddle the water of the original poster.
Quote from: chemlud on June 20, 2026, 10:50:41 PM...I see stuff with WG tunnels (non-connecting, stopping randomly, not starting services on reboot) which shows no pattern or is not related to any changes at the endpoints. There is something weird going on.
Are you using DNS names for peer configuration, possibly?
I manage (mostly IPsec) VPNs for more than 30 years, now. It's a good rule of thumb to never do that. Only use IP addresses for your peers - unless you don't need an explicit peer setting, of course, like with "road warriors" dialing in. VPN connections should not depend on DNS.
I've checked everything again, and I believe all of the settings are configured correctly.
There were definitely no issues up to version v26.1.8.
The issue started occurring after updating to v26.1.9.
I wrote a monit/bash to restart wg0
https://forum.opnsense.org/index.php?topic=52172.0