Odd issue that has plagued this install over the past year, was hoping the most recent update would fix it but it does not.
Whenever the device reboots I have to manually log into the UI and hit "Apply" on the main WireGuard configuration page for the service to start correctly. I have attempted to uninstall and reinstall with no improvements, my next step being a complete OS rebuild that I am trying to avoid.
When I hop on the console/shell after a reboot I see the following:
root@pdx1fw1:~ # service wireguard status
Unable to access interface: Device not configured
Starting it via CLI does not work correctly, while the status/interfaces are created. Traffic is not actually passible untill I login to the UI and again hit "Apply" on the config page
root@pdx1fw1:~ # service wireguard start
[#] ifconfig wg create name wg0
[#] wg setconf wg0 /dev/stdin
[#] ifconfig wg0 inet 192.168.255.3/24 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 10.2.0.0/16 -interface wg0
[#] route -q -n add -inet 10.1.0.0/16 -interface wg0
[+] Backgrounding route monitor
root@pdx1fw1:~ # service wireguard status
interface: wg0
public key: <snip>
private key: (hidden)
listening port: 51280
peer: <snip>
endpoint: <snip>:51280
allowed ips: 10.1.0.0/16
latest handshake: 1 minute, 8 seconds ago
transfer: 15.31 KiB received, 852 B sent
persistent keepalive: every 30 seconds
peer: <snip>
endpoint: <snip>:51280
allowed ips: 10.2.0.0/16
latest handshake: 1 minute, 8 seconds ago
transfer: 8.96 KiB received, 3.83 KiB sent
persistent keepalive: every 30 seconds
CLI Start command, while it appears to look functional, does not actually pass traffic untill I hit "Apply" in the UI so I am not able to fix this with a cron. Anyone know some additional troubleshooting steps I can take before I rebuild from scratch? Remote sides are setup the same and do not have this issue.
Ironic part being we are starting wireguard multiple times through the boot process just to see if it reacts. If it doesn't either your WAN (DHCP) or WireGuard itself (cannot resolve host names for example) isn't ready.
Cheers,
Franco
Have you set up the Cron script to restart stale WG tunnels to be excuted every minute? Works fine here...
Do you have an example of the commands your running in that cron? service wireguard start/restart does not appear to correctly get traffic flowing. I see the tunnels up but traffic wont flow until I hit Apply in the UI. If there is a wg command I can cron I would be happy to simply do that :)
Go System -> Settings -> Cron and add a new job with
* * * * *
and the "Command" (from drop-down menu):
"Renew DNS for WireGuard on stale connections"
The underlying script monitors the handshakes for WG tunnels and if necessary restarts DNS resolution and starts tunnel.
I have been hit by this too. I am running
OPNsense 23.7.5-amd64
FreeBSD 13.2-RELEASE-p3
OpenSSL 1.1.1w 11 Sep 2023
After a reboot my wireguard clients can connect through wireguard and ping the peer, but not access the internet. If I log into the OPNsense gui and restart the service everything works as expected.
Restarting the service via console does not work?
root@opn:~ # service restart wireguard
restart does not exist in /etc/rc.d or the local startup
directories (/usr/local/etc/rc.d), or is not executable
Activating the cron job "Renew DNS for WireGuard on stale connections" does not help.
Any news on this, or a open bug. I could not find anything.
Instead of just randomly starting or restarting WG, you should look into what is actually failing.
Are the WG connections dropping and not immediately picking back up? They're getting timed out because WG doesn't send any traffic if there's nothing to send. Add keepalive 25 to both OPNSense and the client.
Are DNS queries not being resolved on WG? Set Unbound back to listen on all interfaces and change the access list back to allow.
That fixes the vast majority of WG issues. If you don't fall into either of those cases, then post a new thread documenting the actual failure point. Test each piece of the chain, from the DNS resolution of the server name, to the incoming connection, to the firewall rules, to local DNS resolution, to outbound connections.
Lastly, starting things via CLI can cause problems or give false results if you don't use the same commands and options that OPNSense does.
I had the same issue, but it's gone away now and the only thing I can remeber changing was toggling the "Lock" - "Preventing interface removal" for my LAN and WAN interfaces.
Coincidentally, a patch was added to 24.1.3 that addressed this sort of problem. ;)
Cheers,
Franco