A branch office runs two internet lines, head office runs one router on a fixed address, and between them sits the tunnel that carries the accounting system everyone notices within a minute of it dropping. Choosing WireGuard vs IPsec for that site-to-site VPN, you will mostly find comparisons of speed and setup effort. Neither is what takes the tunnel down.
Two things do: the branch's main line dying, and the router at the other end restarting. We staged both on one Linux VM, with a branch router on two ISPs and a head office router, and ran the tunnel first as WireGuard on the Linux 7.0 kernel, then as IPsec with strongSwan 6.0.4. ISP 1 stopped forwarding while its box kept the link up. Separately, head office went dark for about 30 seconds and came back with its configuration and none of its tunnel state, which is what a power cut leaves a router with. On IKEv2, the protocols split on the second test, not the first.
Does WireGuard or IPsec recover faster when the main line fails?
Neither, on IKEv2. The branch router's health check (one ping a second to a host past ISP 1, three misses to move the default route) switched to ISP 2 at 3.09 seconds. Pings through the WireGuard tunnel answered again at 3.28 seconds and through IPsec at 3.30. Both gaps measured 3.33 seconds, and almost all of that was the health check.
Both moved because both run on the router and follow its routing table. Linux's WireGuard sends from the local address the peer last reached it on, and forgets that address when the route to the peer starts leaving by a different interface (send4 in the kernel's WireGuard source). Its next packet left from ISP 2's address, and head office simply answered there. strongSwan saw the same route change, logged "old path is not available anymore", and moved the security associations to ISP 2 with MOBIKE, an IKEv2 extension its swanctl configuration enables by default, all within the same second. Moving back to ISP 1 cost neither tunnel a ping gap over 0.7 seconds.
The TCP session we held open through each tunnel paused for about 3.5 seconds and carried on, same connection, no reset. In our earlier lab, a plain TCP session through a masquerading NAT router during failover was reset at the switch, and its replacement again at failback. Inside a tunnel the session's own addresses never change. Only the outside of the packet does.
One configuration did not move. On IKEv1, the version strongSwan's documentation calls deprecated, the router logged the route change and did nothing with it, because IKEv1 has no MOBIKE and strongSwan ignores roam events for it. The tunnel kept sending from ISP 1's address out of ISP 2. Our ISP 2 filters spoofed sources and dropped all 580 of those packets; without that filter, head office's replies would have gone back to ISP 1, which was dead. Pings came back only when the route moved home, 122.5 seconds after the failure. On strongSwan, an IKEv1 tunnel with dead peer detection off got nothing from a good failover underneath it.
What happens when the router at the other end restarts?
This is where they split. We took head office's internet link down, deleted its tunnel state, and 30 seconds later brought both back with the same configuration. Head office only answered in both setups (its strongSwan kept the default start_action, which loads a connection without initiating it, and its WireGuard had no address for the branch), so recovery was up to the branch.
WireGuard needed nothing from us. Fifteen seconds after its traffic stopped getting answers, the branch started a fresh handshake, then retried about every 5.6 seconds. The first attempt after head office returned went through, and pings answered 2.35 seconds after it came back. Those timers are constants in the Linux implementation (15 seconds of silence before a new handshake, then a retry timer set at 5 seconds), not settings anyone can leave off. The TCP session survived, though it took another 20 seconds to resume, because TCP had been backing off its own retries the whole time.
IPsec with strongSwan's default of no dead peer detection had not come back when we stopped watching. The branch did not write a single log line about it. Five minutes after head office was up again, the branch still listed the tunnel as established and installed, its counters at 1,755 packets out and 150 in, the last inbound one 331 seconds old. Head office had no record of that session and answered none of it. Nothing on either side was due to notice soon, because strongSwan's dead peer detection is off by default (dpd_delay = 0s) and the next scheduled rekey was 48 minutes away. We did not wait to see what the rekey does.
Lab run: Linux 7.0 WireGuard and strongSwan 6.0.4 on one VM; the health check (1 s ping, 3 misses) is our setting.
If your offices are linked by IPsec and nobody can say whether dead peer detection is on, that is the setting to check this week. Send us the tunnel's settings with the key removed on WhatsApp at +254 713 403 044, and we will tell you what a restart at either end does to it.
Dead peer detection at 30 seconds: back in 174.7
Setting dpd_delay = 30s on the branch, whose tunnel was already set to dpd_action = restart, brought it back, slowly. The first liveness check went out about nine seconds into the outage, 30 seconds after the session had been set up. Head office was dark, so strongSwan retried at its default retransmission schedule, roughly 4, 7, 13, 23 and 42 seconds apart, and gave up about 165 seconds after the first try. A new session was up in the same second. Three of those retries left after head office was back, and none was answered, since head office held no session they belonged to. That is 174.7 seconds without a reply for a 31-second outage, against WireGuard's 32.4.
Charon's log, in whole seconds from the start of the outage:
+9 sending DPD request
+13 retransmit 1 of request with message ID 2
+21 retransmit 2 of request with message ID 2
+33 retransmit 3 of request with message ID 2
+57 retransmit 4 of request with message ID 2
+99 retransmit 5 of request with message ID 2
+174 giving up after 5 retransmits
+174 restarting CHILD_SA lanDo not read strongSwan's defaults as IPsec's. MikroTik's IPsec profile ships with dead peer detection on, every 8 seconds, so a RouterOS pair starts from a different place. We did not run RouterOS. What carries over to any IPsec stack is the question: when the far end loses its state, what notices, and after how long?
Which one to run between your offices
Between two routers you control, WireGuard. It followed the failover as fast as IPsec and came back from a far-end restart 2.35 seconds after the far end did, with no detection timer to configure. The protocol names one set of primitives (ChaCha20 with Poly1305, Curve25519), where IPsec's two ends negotiate a proposal, so there is no cipher proposal for them to mismatch. Linux carries it in the kernel, and MikroTik documents it for RouterOS.
When one end is a cloud VPN gateway, IPsec. AWS Site-to-Site VPN describes its connections as IPsec, Azure's site-to-site link is IPsec/IKE, Google Cloud VPN connects through IPsec, and none of those three overview pages mentions WireGuard. That covers the VPN that backs up a Direct Connect circuit to AWS. Run IKEv2, and turn dead peer detection on at your end.
IPsec has one more card on some branch routers: the processor. MikroTik's acceleration table lists router CPUs and which of DES, AES and SHA their built-in engine speeds up, and ChaCha20 is not a column in it. We did not measure throughput, because one VM carrying both ends measures that VM. On a small router with a fast line, the router's own published test results settle it, read with the same suspicion as a firewall's datasheet.
CloudSpinx designs, builds and monitors office networks in Kenya, and the tunnels between branches are part of that work. Our installs end with the primary link pulled in front of you, and for a site-to-site tunnel the far-end restart is the second test worth watching.
Send us what sits at each end of each tunnel (the router make and model, or the cloud gateway), whether each line has a fixed public address, and whether the IPsec peers run dead peer detection today, through the network scoping form, choosing "Site-to-site links", or on WhatsApp at +254 713 403 044. You get back which protocol we would run on each link and the settings that bring it back after a restart at either end. If your IPsec only needs that one setting switched on, we will say so, and you will not need us for it. If we run the network afterwards, the tunnels sit on our monitoring and the whole thing is one monthly figure. The reply costs nothing and commits you to nothing.
This is for two offices, or a handful, joined by tunnels between routers. Staff connecting from laptops at home is a remote-access question, where client apps and identity matter more than anything measured here. Past a handful of sites the comparison stops being about the protocol and becomes about managing dozens of tunnels, which is where SD-WAN starts to earn its license.