WireGuard PersistentKeepalive: What It Is and When to Use It

Of all the WireGuard settings, PersistentKeepalive is the most misunderstood: a tiny number that fixes an outsized share of "my tunnel randomly stalls" complaints. If your VPN works fine during active use but dies during quiet stretches, especially on hotel WiFi or cellular, this setting is probably the answer. Here's WireGuard PersistentKeepalive explained: what it actually does, why 25 seconds became the standard, and when to adjust it.

The Problem: NAT Sessions Expire and Kill Idle Tunnels

To understand the fix, you need the problem. Between your travel router and your home server sit one or more NAT devices: the hotel gateway, the carrier's CGNAT, your home router. Each maintains a session table mapping your outbound packets to return paths. These tables are finite, so devices expire idle entries aggressively: hotel gateways often after a minute or two, some cellular carriers even faster.

WireGuard, left alone, is silent when idle. Beautiful for battery life; fatal for NAT sessions. The sequence:

1. You're working; tunnel is live; NAT sessions are fresh.
2. You stop typing to read something. Thirty seconds pass. A minute.
3. The hotel gateway's NAT table expires your tunnel's entry. Return packets from home now have nowhere to go: dropped silently.
4. You type again. Your router sends a packet out (outbound still works: NAT creates a fresh entry on the way out), the server responds, and… depending on timing, things recover in seconds or stall awkwardly.

From your side, this looks like the tunnel "dying" whenever you pause. It's not the tunnel: it's the NAT forgetting you exist during the quiet.

PersistentKeepalive fixes it by refusing to be quiet: it tells the WireGuard client to send a tiny keepalive packet every N seconds, even with no real traffic. That chatter refreshes the NAT session table continuously, so the entry never expires and return packets always find their way home. A few bytes every 25 seconds: negligible bandwidth, negligible battery, and the tunnel stays warm through any pause.

The 25-Second Standard (and When to Deviate)

Twenty-five seconds didn't come from a spec; it came from experience. It's shorter than nearly every NAT timeout in the wild (most are 60 seconds to several minutes), so it keeps sessions alive essentially everywhere, while being infrequent enough to cost nothing measurable. It's the default I'd suggest to anyone who isn't troubleshooting a specific problem.

When to go shorter (10-15 seconds, sometimes even 5):

• Aggressive hotel or corporate NATs that expire sessions in under 30 seconds. Rare, but they exist, usually on networks that are hostile to long-lived connections generally.
• Some cellular carriers with very short CGNAT timeouts. If your tunnel stalls on one specific carrier's data but not others, shorter keepalives are worth trying before anything drastic.
• During diagnosis. When you're not sure NAT expiry is the cause, a short interval is a good experiment: if the stalls vanish at 10 seconds, you've confirmed the diagnosis and can settle on the longest interval that works.

When to go longer, or turn it off:

• Stable home networks. A WireGuard tunnel between two stable endpoints (say, a home server and a VPS) often needs no keepalive at all: neither side sits behind an expiring NAT, or the traffic is constant anyway. Zero (disabled) is fine there.
• Battery-critical phones. On a phone with an always-on tunnel, every keepalive wakes the radio. 25 seconds is still cheap, but if the tunnel is only needed intermittently, longer intervals (60-120s) or on-demand tunnels save more power. Match the interval to how quickly you need the tunnel to be responsive.
• Metered connections. Keepalives are bytes, not megabytes; even at 5-second intervals the monthly total is trivial. Don't optimize this unless you're counting kilobytes, which you aren't.

The general principle: use the longest interval that keeps your tunnel alive on your worst network. Start at 25, shorten only with evidence, lengthen when the network allows.

Setting It: Client Side, and What the Server Sees

PersistentKeepalive is a client-side (peer) setting: it goes on the side behind the NAT (your travel router, your phone), in the [Peer] section of the WireGuard config, as PersistentKeepalive = 25. The server doesn't need it for the client's benefit (though the server might set its own keepalive toward the client if the server sits behind NAT too: unusual for home setups, common for double-NAT situations).

On GL.iNet and similar travel routers, the VPN client UI usually exposes a keepalive field: fill in 25 and you're done. If you're editing configs directly, the line goes under the peer definition, not the interface. (Putting it in [Interface] is a common mistake; it's silently ignored there, and you'll wonder why nothing changed.)

What the server sees: tiny authenticated packets arriving every N seconds. It responds in kind only if it has its own keepalive set toward you; otherwise it just notes you're alive. There's no negotiation of the interval: each side sends at its own configured rate. Asymmetric setups (client at 25s, server at 0) are completely normal.

Verifying it's working: watch the "latest handshake" time on either side. With keepalives active, handshakes refresh on roughly the keepalive cadence during idle periods. No keepalive: the handshake timestamp goes stale during silence. It's a quick, definitive check that the setting took effect.

One caveat: keepalives keep the NAT session alive, not the network. If the hotel WiFi itself drops, or the carrier loses signal, no keepalive interval fixes that: the packets can't get out at all. Keepalives solve idle-expiry; they don't solve outages. If your tunnel dies during active use, look elsewhere (signal, congestion, firewall).

FAQ

Need Help Setting This Up?

Keepalive tuning is a five-minute job when you know which end needs it and what the network's doing, and a confusing afternoon when you don't. If your tunnel keeps going quiet at the wrong moments, our $79 consultation will sort out whether it's NAT expiry or something sneakier: https://homeipvpn.com/appointment. It is a remote screen-share session at your scheduled time, and the $79 consultation fee is credited toward the $379 Secure Home IP VPN System session cost.