Thank you for the follow-up and the clarification, Andreas. After extensive testing and analysis, it appears that the issue isn’t with WireGuard itself, but rather with the systemd unit ordering as packaged in Ubuntu. The root cause seems to be that [email protected] uses:
After=network.target Wants=network-online.target but not After=network-online.target This allows WireGuard to start before the underlying network interface (in this case ens3, DHCP via Oracle Cloud) is fully ready. The result is an intermittent failure during boot, depending on timing. Once the system is fully online, the tunnel works flawlessly and can be brought up manually without issue. Adding a simple override to enforce After=network-online.target Requires=network-online.target resolves the problem completely and consistently. So the root cause seems to be a race condition in Ubuntu’s systemd ordering for the WireGuard unit, rather than in WireGuard itself. While the local override is a valid workaround, perhaps this dependency could be reviewed for inclusion in the default unit for environments that depend on delayed network initialization (e.g., cloud VMs, DHCP). Thank you again for your time and help in reviewing this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2128680 Title: Race condition in systemd startup order causes WireGuard to fail at boot on Ubuntu 24.04.3 (Oracle Cloud image) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/2128680/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
