What Does PersistentKeepalive Do in WireGuard?

WireGuard PersistentKeepalive sends an authenticated empty packet after a configured period without outgoing traffic. Its narrow purpose is to keep a NAT or stateful-firewall mapping alive so a peer behind that device can remain reachable. It does not test whether the internet works, repair a broken route, or guarantee that an application session survives an interruption.

The complete VPN guide explains the larger protected path. This article isolates one optional per-peer timer inside WireGuard, so you can decide whether a quiet connection actually needs it.

Key Takeaways

• PersistentKeepalive is disabled by default and is configured separately for each peer.
• It sends an authenticated packet with no application payload only after the peer has been idle in the outgoing direction.
• Its job is to refresh NAT or stateful-firewall state, not to monitor tunnel health.
• Twenty-five seconds is a widely documented example, not a universal requirement.
• The peer behind restrictive state normally sends the keepalive; enabling it everywhere adds needless traffic and wakeups.

What is WireGuard PersistentKeepalive?

The wg(8) manual defines PersistentKeepalive as an optional interval, in seconds, from 1 through 65,535. When the interval passes without traffic being sent to that peer, WireGuard sends an authenticated empty packet. A value of zero or off disables the behavior, and that is the default.［1］

“Authenticated” matters. The packet is part of the established WireGuard peer relationship and passes the protocol's normal cryptographic checks. “Empty” means it carries no tunneled application payload; it is still an outer UDP datagram with WireGuard protocol overhead. A packet capture therefore shows traffic even though no browser, messenger, or other application generated data.

The setting belongs to a peer, not to an interface as one global pulse. A laptop may need keepalives toward one remote peer while another peer on a stable public address does not. The configured side decides when to transmit them; the other side does not remotely command the interval.

This distinction fits the protocol overview: WireGuard supplies an encrypted UDP tunnel and peer state, while the surrounding operating system, network, and applications have their own timers and failure behavior.

Why idle NAT and firewall state expires

Many clients sit behind a router that translates a private source address and port into a temporary public mapping. A stateful firewall may maintain a similar record so return UDP packets are accepted. These devices cannot keep every inactive flow forever, so they expire entries after an implementation- and policy-dependent idle period.

Suppose a home peer sends a packet to a server. The home router creates a mapping, and the server can reply through it. If neither direction produces enough traffic before the mapping expires, an unsolicited packet from the server may no longer match live state. The server still knows the last observed outer address, but that address and port no longer provide a usable return path.

The WireGuard whitepaper describes keepalive packets as useful when a peer behind NAT or a stateful firewall needs to remain reachable while idle. It also emphasizes that most peers should avoid them because WireGuard is otherwise intentionally silent when there is no data to send.［2］ Silence saves bandwidth and lets battery-powered devices sleep.

Figure key: 1 is the quiet peer behind the edge device; 2 is the temporary NAT or stateful-firewall mapping; 3 is the remote peer that may need to send traffic back; 4 is the idle interval after which an authenticated empty UDP packet refreshes the mapping. The arrows show datagram direction, not a health-check response.

Why ordinary traffic may already be enough

Every valid outgoing WireGuard packet can refresh relevant network state. An active voice call, file transfer, or frequent request stream may therefore keep the mapping alive without a special keepalive. The timer becomes relevant when the tunnel must accept future inbound traffic after a quiet period.

That is why “the tunnel carries traffic all day” and “the idle peer must be reachable all day” are different requirements. Measure the idle case. Do not enable a periodic packet merely because it sounds like a general reliability switch.

Why 25 seconds is common but not mandatory

Both the manual and official quick-start guidance use 25 seconds as a sensible example for keeping many NAT and firewall mappings valid.［1］［2］ It is deliberately shorter than common UDP idle timeouts, but neither document declares it a protocol constant. WireGuard accepts other nonzero intervals, and the actual network may retain state for a shorter or longer period.

A shorter interval creates more datagrams, radio wakeups, and server work. A longer interval reduces overhead but may allow an aggressive middlebox to expire the mapping first. The useful value is the longest interval that reliably stays below the relevant idle timeout, with reasonable margin. That timeout may vary across home routers, carrier networks, enterprise firewalls, and firmware versions.

Do not tune it from ping latency. Round-trip time says how long a packet takes while a path works; it does not reveal how long a middlebox retains an idle UDP mapping. Likewise, setting one second cannot make a fundamentally blocked or misrouted path healthy.

Situation	Likely keepalive decision	Reason
Publicly reachable server	Usually off	It can already receive a new authenticated initiation
Client behind NAT that only initiates traffic	Usually off	New outgoing traffic recreates state when needed
Client behind NAT that must receive after being idle	Often useful	Periodic outgoing traffic preserves the return mapping
Active tunnel with frequent bidirectional data	Often unnecessary	Existing traffic refreshes state
UDP blocked on the path	Not a remedy	More UDP packets do not remove the block

What PersistentKeepalive does not do

PersistentKeepalive is not an echo request with a required answer. The sender does not learn “healthy” merely because it transmitted the packet. WireGuard's latest handshake and transfer counters can provide observations, but the keepalive itself is not a complete liveness protocol and does not verify DNS, routing, internet access, or application reachability.

It is also not the mechanism that selects the remote address. The Endpoint explanation covers the outer IP or hostname and UDP port. Nor does a keepalive decide which inner destinations belong to a peer; that is the job of AllowedIPs and, separately, system routes.

If a device changes from Wi-Fi to cellular, the new path and source mapping must be learned through authenticated traffic. That behavior belongs to WireGuard roaming. A keepalive may cause useful traffic to be sent sooner or preserve a current NAT entry, but it does not define peer identity or the roaming rule.

Finally, a valid WireGuard tunnel does not guarantee continuity for every application. TCP sessions, real-time media, DNS caches, captive portals, operating-system suspend behavior, and application retry policies can all react independently when the outer path changes.

Which peer should send it?

Start with the reachability requirement. If a peer behind NAT must remain available for traffic initiated by a remote peer, configure the keepalive on the NATed peer. Its outgoing packet refreshes the state needed for the remote packet to return. Configuring only the public server to send periodically may not recreate a mapping that the private side has already lost.

If both peers can always initiate new authenticated traffic and neither requires unsolicited reachability while idle, leave the default. If both are behind independent NATs, one side still needs a known initial Endpoint and a viable path to begin; periodic traffic cannot conjure a route when neither side can address the other.

The wg-quick(8) helper may derive operating-system routes from AllowedIPs, but that automation is separate from the keepalive timer.［3］ A route can be present while a NAT mapping is stale, and a mapping can be alive while the system selects the wrong route. Diagnose these layers separately.

To see how a managed client behaves after idle time, connect AethoVPN on a phone behind the same NAT, leave it idle for the interval that breaks your own peer, then load a page and note whether it resumes at once, reconnects, or needs a manual retry. Repeat once on a second location so a single busy server does not skew the result. The product does not document a keepalive setting or promise uninterrupted connectivity, so record what the client actually does rather than assuming a 25-second interval. Start a free trial with your email for the idle test.

How to reason about a keepalive problem

First compare active and idle behavior. If traffic works continuously but the remote peer cannot reach the client after a predictable quiet period, expired state is plausible. Record the interval and whether a new packet initiated by the client immediately restores communication.

Then separate the evidence:

1. Confirm that the peer can complete an authenticated handshake on the current path.
2. Confirm that the intended inner address is associated with the correct peer and route.
3. Observe whether outgoing data after the idle gap recreates reachability.
4. Test a conservative nonzero keepalive interval below the observed failure window.
5. Compare transfer counters and packet captures without treating transmission alone as a successful reply.

If the tunnel fails even under continuous traffic, the root cause is probably not an idle mapping. Investigate Endpoint reachability, UDP policy, keys, clock, routes, MTU, or application behavior instead. A narrow timer should not conceal a broader failure.

Summary

• PersistentKeepalive sends an authenticated empty packet after an outgoing idle interval.
• Its purpose is to retain NAT or stateful-firewall state for a peer that must stay reachable.
• It is off by default, and most continuously active or initiator-only peers do not need it.
• Twenty-five seconds is an official example, not a universal optimum.
• It does not test health, choose routes, learn identity, or guarantee application continuity.

FAQ

Does PersistentKeepalive send application data?

No. It sends an authenticated WireGuard packet without tunneled application payload. It still consumes a small amount of network data and processing.

Is PersistentKeepalive enabled by default?

No. Zero or off disables it, which is the default. Set a nonzero per-peer interval only for a concrete idle-reachability need.

Why do examples use 25 seconds?

It is a practical interval intended to remain below many NAT and stateful-firewall UDP idle timeouts. It is guidance, not a protocol constant or a promise for every network.

Should both WireGuard peers enable it?

Usually not. The peer behind stateful translation that must remain reachable is the typical sender. Enable both directions only when each direction has an independently demonstrated need.

Does a keepalive prove the peer is online?

No. Sending one proves only that the local system attempted transmission. Use handshake timing, counters, logs, and controlled traffic to evaluate reachability.

Can PersistentKeepalive fix a blocked UDP path?

No. If UDP is blocked, the Endpoint is wrong, or routing is broken, periodic UDP packets do not repair the underlying condition.

Does PersistentKeepalive make roaming seamless?

No. Authenticated packets allow Endpoint learning after an address change. Keepalive traffic may help maintain or exercise a path, but application sessions and operating-system transitions have separate continuity rules.

Sources:

1. WireGuard Tools, wg(8): https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
2. WireGuard, “WireGuard: Next Generation Kernel Network Tunnel”: https://www.wireguard.com/papers/wireguard.pdf
3. WireGuard Tools, wg-quick(8): https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8

Sources checked 12 September 2026.

---

Related Articles:

• Understand the complete VPN path
• Compare major VPN protocol designs
• Check why a VPN fails after waking from sleep
• Separate a WireGuard Endpoint from tunnel routing