WireGuard PersistentKeepalive Explained

Most people never touch the WireGuard setting called PersistentKeepalive, and for many setups that is fine. Then one day a tunnel that worked perfectly at lunch is dead by mid-afternoon: the app still says connected, yet nothing loads until you toggle it off and on. If that sounds familiar, you have probably met the problem that vpn persistent keepalive exists to solve. This article explains what the setting does, why idle tunnels go quiet, how to choose a value, and what it costs.

It is written for readers who open a config file or an app setting and want to understand a single line, not for people who want a full protocol tour. For the bigger picture, see what a VPN protocol is and the comparison in WireGuard vs OpenVPN. Here we stay on one number and the reasons behind it.

What PersistentKeepalive actually is

WireGuard is a deliberately quiet protocol. When a tunnel has no traffic to carry, it sends nothing at all. There are no constant heartbeat messages the way some older designs have. That is good for privacy and for battery life, but it has a side effect: to the network in the middle, an idle WireGuard tunnel looks like a conversation that ended.

PersistentKeepalive is an optional per-peer setting, measured in seconds. If you set it to 25, then whenever the peer has not sent anything for 25 seconds, it sends an empty, authenticated packet to the other end. The packet carries no user data. Its only job is to be seen by every device along the path that keeps a timer.

A minimal client-side example looks like this:

[Peer]
PublicKey = (the server's public key)
Endpoint = vpn.example.net:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

The value 0 means off, and 0 is the default. Anything from 1 to 65535 turns the feature on at that interval. In practice almost everyone uses 25, which is the value the WireGuard project itself suggests in its documentation for peers behind NAT, and we explain why 25 is a good compromise below.

Do not confuse this with WireGuard's built-in behaviour. The protocol already sends a short keepalive after it has received data and has nothing to reply with for about 10 seconds, so the sender knows the tunnel is healthy. That passive keepalive only happens after traffic has flowed. PersistentKeepalive is the setting that makes a peer speak first and keep speaking even when everything has been silent for a long time.

Why idle tunnels die: NAT and firewall timers

Almost every home router, mobile network and office firewall performs NAT, short for network address translation. When your phone sends a UDP packet out, the router creates a temporary table entry that says "replies from that server on that port belong to this device". The entry is what lets the return packet find its way back to you.

Table entries cost memory, so routers delete them after a period of inactivity. For UDP, which has no connection to close politely, the timers are short. Typical home routers keep a UDP mapping for somewhere between 30 seconds and a few minutes, and some carrier networks are more aggressive. Linux connection tracking, for example, uses a short timer for UDP flows that have seen traffic in only one direction and a longer one for flows that have seen both. Exact numbers differ between devices and you rarely know them for the network you are using.

When the entry disappears, two things can go wrong:

1. Your outgoing packets still work. The next time you send something, the router simply creates a new mapping, possibly with a different outside port. WireGuard copes with this well, because it learns the peer's new endpoint from authenticated packets.
2. Incoming packets are dropped. If the other side tries to send first, for example a server pushing data to your laptop, the router has no entry, so it discards the packet. From your side the tunnel looks dead until you send something.

This second case is the one that bites. A chat message arrives late, a remote desktop does not wake, a phone does not receive a call through the tunnel, and the problem vanishes the moment you open a page. That is the signature of an expired NAT mapping, and a regular keepalive prevents it by refreshing the entry before the timer runs out.

Carrier-grade NAT makes the situation more common. When your internet provider shares one public address among many customers using the shared range described in RFC 6598, you have an extra layer of translation outside your own router, and you cannot change its timers. Our article on using a VPN behind CGNAT goes deeper into that case.

Who needs it and who does not

The rule is simple to state: set PersistentKeepalive on the peer that sits behind NAT and needs to be reachable while idle.

Situation	Set a keepalive?	Reason
Phone or laptop connecting out to a VPN server, mostly browsing	Often not needed	Your own traffic keeps the mapping fresh
Laptop that must receive pushes or calls while the screen is idle	Yes, on the laptop	The server cannot reach you through an expired mapping
Home server or NAS behind a router, reachable from outside via a tunnel	Yes, on the device behind NAT	It must keep the path open
Server with a public static address	Normally no	Nothing in front of it forgets the mapping
Two peers both behind NAT, relayed through a public peer	Yes, on both toward the public peer	Each one needs its own mapping kept alive
Tunnel used only in short bursts you start yourself	Usually no	A new mapping is created on each burst

Notice that a keepalive solves reachability, not speed. If your tunnel is simply slow, look at why a VPN is slow instead.

Choosing the value: why 25 seconds

The interval must be shorter than the shortest idle timer on the path, but not so short that you waste battery and airtime. That is why guidance clusters around 25 seconds.

• Too long. At 120 seconds you may beat a router that holds mappings for 180 seconds, but you lose against one that forgets after 30. The tunnel will fail on some networks and not others, which is the most irritating pattern to debug.
• Too short. At 5 seconds the tunnel stays alive almost anywhere, but you send an extra packet every 5 seconds, 24 hours a day. A phone will wake its radio hundreds of times per hour for no good reason.
• Around 25. Below the 30-second timer that some devices use for unanswered UDP, yet infrequent enough to be cheap. If you find a stubborn network that still drops, trying 15 or 20 is reasonable. Going lower than that is rarely justified.

A worked example helps. Suppose a laptop at a cafe is behind a router whose UDP mapping lasts 60 seconds. With the keepalive off, you open a document, put the laptop down for two minutes, then a colleague tries to reach a service you host through the tunnel. The mapping expired at 60 seconds, so they get nothing. With a keepalive of 25, the mapping is refreshed at 25, 50, 75 and so on, so it never expires and the colleague connects at once.

The data cost is easy to estimate. A keepalive packet is small, roughly a few dozen bytes once IP and UDP headers are included. One packet every 25 seconds is about 3,456 packets a day. At around 100 bytes each that is roughly 350 KB per day, far below what a single web page costs. The tunnel will not eat a mobile data plan.

What it costs: battery, privacy and noise

A keepalive is cheap but not free, and it is worth knowing the trade-offs.

Battery. The cost is not the bytes but the wake-ups. A phone in deep sleep has to bring up its radio to send even a tiny packet, and mobile operating systems try hard to batch background work. Frequent keepalives on a phone can add noticeable drain over a day, particularly on a weak mobile signal. If your phone VPN is only for browsing, leave the keepalive off. Read does a VPN drain your battery for the wider picture.

Privacy. A regular packet every 25 seconds is a visible rhythm. The content is encrypted, but someone watching the network could notice that a WireGuard-like flow exists between you and a given address. A VPN does not hide that a tunnel exists from the network operator, only what is inside. That is also true without a keepalive, just less obvious.

Noise on shared links. On a very constrained link, such as a metered satellite or an airline connection, even tiny periodic packets add up in the operator's eyes. If you are on such a link, only enable the keepalive while you actually need reachability.

Troubleshooting: is a keepalive the right fix?

Before you edit anything, confirm the symptom matches. A keepalive helps when:

• The tunnel works after you have just connected, then goes silent after a quiet period.
• The tunnel recovers the moment you send traffic yourself, such as opening a page or running a ping.
• The same setup works at home but fails on a particular cafe, hotel or mobile network.
• The server shows an old handshake time for your peer even though your app says connected.

Try this order:

1. Check the basics first. Is the device really online? Is the pass or account still valid? Are the credentials correct? Our guide on improving VPN connection stability covers these.
2. Look at the last handshake. WireGuard tools show the time since the last handshake. A very old value with no traffic points to a mapping or filter problem rather than a bad key.
3. Turn on PersistentKeepalive = 25 on the side behind NAT and reconnect. Wait twice as long as the idle period that used to break it.
4. Test a different network. If it works on mobile data but not on one Wi-Fi, the Wi-Fi's firewall or timers are the cause.
5. Lower the value to 15-20 only if 25 still fails, and keep notes on which network needed it.
6. Check other causes if nothing changes: MTU problems, a battery-saving mode that kills background apps, or a firewall blocking UDP. See VPN handshake for how the key exchange works and what a stalled one looks like.

If you use a VPN app rather than your own config, you may not see this setting at all. Apps usually choose sensible defaults or handle reconnection themselves. When you connect with the free VPNclient app that comes with an XPASS pass, keep the app's default settings unless support tells you otherwise; you can find the apps on the download page.

Common mistakes

• Setting the keepalive on both ends by habit. The public server rarely needs it, and it just doubles the chatter.
• Using a huge value to save battery. An interval longer than the network's timer is the same as off, only less predictable.
• Setting 1 or 2 seconds. There is almost never a network that needs it, and the cost to the battery is real.
• Blaming the keepalive for slow speed. It carries almost no data, and speed is a separate subject covered in why internet speed changes with a VPN.
• Forgetting that the NAT might be yours and theirs. Both your home router and your provider's CGNAT can drop mappings, and you only control the traffic you send.
• Confusing keepalive with a kill switch or auto-reconnect. A keepalive keeps a mapping alive. It does not restart a tunnel whose keys or session have genuinely failed.

Quick reference

Question	Short answer
Default value	0, meaning off
Common value	25 seconds
Where to set it	On the peer behind NAT that must stay reachable
Cost in data	A few hundred KB per day at most
Cost in battery	Small but real on phones
Fixes	Idle timeouts caused by NAT or firewall state
Does not fix	Slow speed, bad Wi-Fi, wrong MTU, expired accounts

Summary

PersistentKeepalive is a small WireGuard setting that makes a peer send an empty authenticated packet at a fixed interval, so NAT routers and firewalls do not forget an idle tunnel. It is off by default, 25 seconds is the usual value for a peer behind NAT, and it costs almost no data but a little battery on phones. Use it when a tunnel goes quiet after idle periods and recovers as soon as you send traffic, and look elsewhere when the cause is speed, MTU, account validity or a blocked network.

If you would like a simple prepaid way to try these tunnels on your own devices, you can look at the pricing page whenever it suits you.