WireGuard does not start after reboot.

[Lucid1010]

You cannot view this attachment.


You cannot view this attachment.


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.

[trumee]

I am facing the same issue after upgrading to latest patch OPNsense 26.1.10-amd64.

[Lucid1010]

The issue also occurred in version v26.1.9

[sopex]

Was it working before? 26.1.9? Or we don't know?

[Lucid1010]

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.

[OPNenthu]

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.

[Lucid1010]

- no wireguard group
- set(check) Disable routes

[tigo003]

- 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

[AlPi]

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

Code Select Expand

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

Code Select Expand

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

Code Select Expand

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

Code Select Expand

netstat -s -p udp | grep "no socket"
        6154189 dropped due to no socket

sockstat — socket process ownership shows as unknown

Code Select Expand

sockstat -4 | grep -E "57011"
?        ?          ?     ?   udp4   *:57011               *:*

Code Select Expand

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.

[chemlud]

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