-
25.11 takes more than 10 minute to complete booting up. It seems to hang when executing early shell commands to configure WireGuard tunnels. This started when I upgraded to 25.11, I've never had this behavior in any previous version of pfSense.
I don't believe it's related to any IPv6 or TSO issues as all of the tunnels are IPv4 and TSO was disabled on a fresh upgrade.
I hit 'ctl+t' several times during the boot up to see what it might be hanging on.
Any idea what might be going on?
-
G g.shaffer referenced this topic on
-
Today I ran into this (or something similar) too. I can't say if pfSense would boot at all, I didn't had the patience to wait 10 minutes I guess but it was close to that minutes. I restored from backup.
Before, I decided to give pfSense another chance for all of my privacy-VPN-WG-tunnels, so I "imported*" them all *(by hand) from my OpenWRT-Routers, it was work. Also changed gateways and so on. Everything seem to work until I rebooted pfSense, it wouldn't come back. Tried it multiple times.
On the screenshot there is none of the Privacy-VPNs shown, only S2S-Tunnels that do work without any problems before.To me that looks like a serious problem.
-
This has been reported before, see:
- https://redmine.pfsense.org/issues/15435
- https://forum.netgate.com/topic/187532/long-boot-times-when-using-wireguard-vpn-was-syslogs-starts-late-in-the-boot-process-leading-to-misrepresentation-of-events-incorrect-time-stamps
Give this patch a try:
diff --git a/src/usr/local/pkg/wireguard/includes/wg.inc b/src/usr/local/pkg/wireguard/includes/wg.inc index 42e16a8b3992..ddd115ae609a 100644 --- a/src/usr/local/pkg/wireguard/includes/wg.inc +++ b/src/usr/local/pkg/wireguard/includes/wg.inc @@ -315,9 +315,13 @@ function wg_destroy_rogue_peers($tunnel_name, &$cmds = null) { function wg_resolve_endpoints() { // Get the latest info wg_globals(); + $dns_available = get_dnsavailable(); // Do we have any peers? foreach (config_get_path('installedpackages/wireguard/peers/item', []) as $peer) { + if (!$dns_available && !is_ipaddr($peer['endpoint'])) { + continue; + } // Strip port if empty $peer['port'] = !empty($peer['port']) ? ":{$peer['port']}" : null; -
M marcosm moved this topic from General pfSense Questions on
-
@marcosm said in 25.11 Long Boot Time Issue with WireGuard:
https://redmine.pfsense.org/issues/15435
The newly added tunnels had FQDN endpoints. I will stick with OpenWRT though.
-
@marcosm said in 25.11 Long Boot Time Issue with WireGuard:
https://forum.netgate.com/topic/187532/long-boot-times-when-using-wireguard-vpn-was-syslogs-starts-late-in-the-boot-process-leading-to-misrepresentation-of-events-incorrect-time-stamps
I should be able to try this patch out later today.
While I understand this may be similar to a previously reported problem (over a year ago), This issue was not present in 25.07.1 or any previous version of pfSense+ I've used and I've had numerous WG tunnels setup and working since its implementation in pfSense.
-
@g.shaffer Maybe all your other tunnels weren't configured to use FQDNs? Maybe you just never noticed increased boot times under <25.11?
The Redmine issue is worth a thorough read.
-
@marcosm The patch worked. The FW booted up quickly and once I could log into the GUI, the WG tunnels were all up and connected.
Half of my WG tunnels use FQDN, but this was not an issue with 25.07.1. So, Is this a regression or did the timing and mechanics of setting up WG tunnels change significantly in 25.11?
-
@tinfoilmatt I did read both of the threads marcosm provided.
I've been rebooting between 25.11 and 25.07.1 lately, I'm very aware of the time it takes my FW to boot up. This behavior was not happening in 25.07.1
-
@g.shaffer The "Affected Plus Version" noted in the Redmine issue is/was
24.03. -
After the related (I think) WireGuard-Update from today, WireGuard was not restarting itself on one of two machines, so I did the update on the remote one outside of the tunnel.
-
@Bob.Dig With the patch tunnels with FQDN endpoints are skipped when the DNS server isn't responding. If that happens the tunnel endpoint will be tried again after the time specified in "Endpoint Hostname Resolve Interval". If you mean the service didn't automatically start after reinstalling/updating the package, I believe that's always been the case. It should start automatically on reboots and system upgrades however.
-
@marcosm Will this patch make into the next update?
-
@Bob.Dig said in 25.11 Long Boot Time Issue with WireGuard:
WireGuard was not restarting itself on one of two machines
Same here, must restart the wg service manual.
-
@g.shaffer said in 25.11 Long Boot Time Issue with WireGuard:
@marcosm Will this patch make into the next update?
Patch no longer relevant! They just dropped a new wireguard package into the 25.11, 25.07 repos. You can remove the patch, update wireguard package in the package manager and reboot. This just came out a few hours ago.
-
@marcosm said in 25.11 Long Boot Time Issue with WireGuard:
If you mean the service didn't automatically start after reinstalling/updating the package, I believe that's always been the case.
Yep that is what I meant. On One it did and on the other it didn't.
-
@mfld Yep here's the commit in case anyone wants to review the change
https://github.com/pfsense/FreeBSD-ports/commit/2ad4d245c30b2543e9661c00d497a72624062611
-
Seems this issue has returned with the update to pfSense+ 26.03
-
@lnguyen I haven't updated to 26.03 yet, maybe I will hold off for a bit.
-
It stalled at “Configuring WireGuard tunnels…”
I rolled back to 25.11.1 Boot Environment and it booted
-
I updated my box this morning (25.11.1 to 26.03), I did notice a short pause at the "Configuring WireGuard tunnels...", but it was nothing like the original issue. Paused for about a minute.
Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.