Why a VPN sends keepalives

A VPN keepalive is a tiny packet the phone sends at a fixed interval, typically every 25 seconds, purely to prove the connection is still in use. It exists because of NAT, the address-sharing trick that nearly every home router and mobile carrier relies on. NAT keeps a table of live connections and forgets any that go quiet for too long; once yours is forgotten, packets from the server can no longer reach your phone. A keepalive resets that timer before it runs out.

What NAT does

Your phone almost never has a public address of its own. On home Wi-Fi it has a private address behind the router; on mobile data it usually shares a carrier address with thousands of other subscribers. NAT, network address translation, is what makes that work. When your phone sends a packet out, the router rewrites the source address to its own public one and remembers, in a mapping table, which internal address and port the reply should go back to.

That mapping is created by outbound traffic and lives only as long as the router chooses to remember it. For TCP the router can see the connection open and close. For UDP, which is what WireGuard, IKEv2 and most VPNs use, there is no open or close, so the router uses a timer: if no packet has crossed the mapping for a while, it is deleted. RFC 4787 recommends that a UDP mapping survive at least two minutes of silence, but many routers and carrier networks use less, and some drop mappings well inside a minute.

What happens when the mapping expires

Nothing, at first. The phone sends its next packet whenever it has one, the router creates a fresh mapping, and the server, which identifies the client by its key rather than its address in WireGuard's case, replies to the new address. From the phone's side the tunnel just works.

The problem is the other direction. If the server has something to send while the mapping is gone, a reply that arrives late, a notification pushed through the tunnel, or a rekey initiated from its side, the packet reaches the router and matches nothing. It is dropped, and the phone never knows it was sent. For traffic the phone initiates this is rarely noticed. For anything that has to arrive unprompted it is a silent failure, and it is why a VPN that seems to work perfectly during use can look dead after a few quiet minutes.

What a keepalive does

The keepalive is the simplest possible fix: send something before the timer expires. A WireGuard keepalive is a data packet with no payload, 32 bytes of header plus the UDP and IP wrapping, encrypted and authenticated like any other. It crosses the NAT, refreshes the mapping, and is discarded by the server on arrival. IKEv2 has the equivalent built in for its NAT-traversal mode, and OpenVPN has a keepalive option that does the same job with a ping.

Twenty-five seconds is chosen because it sits comfortably under the shortest common timeout while being long enough that the radio can sleep between packets.

The battery trade

Every keepalive is a packet, and on a phone a packet can mean waking the radio from its low-power state. A single 25-second interval over a full day is a few thousand small transmissions. The data is negligible, well under a megabyte. The energy is small but real, and it is why keepalives should be a decision rather than a default: a tunnel that only ever carries traffic the phone initiates does not strictly need them, while one that must stay reachable does. The battery drain post puts this beside the other things that cost a VPN power.

The good news is that a keepalive is far cheaper than the alternative. When a mapping expires and a rekey from the server is lost, the tunnel goes stale and has to be re-established with a full handshake, which costs more radio time than a day of keepalives would have.

When you need them, and when you do not

You need keepalives when there is a NAT between your phone and the server, which is almost always, and when anything needs to reach the phone unprompted through the tunnel, which is common: push notifications from apps routed through the VPN, long-lived connections to messaging services, and the VPN's own rekeys. Behind a carrier NAT on mobile data, which tends to have the shortest timeouts, they are close to mandatory.

You do not need them when the phone has a public address with no NAT, or when the tunnel is only ever used for short bursts of phone-initiated traffic and a brief stale period afterwards does not matter.

A keepalive is not the fix for every idle disconnect. Android may have put the VPN app to sleep, in which case no keepalive is sent because nothing is running to send it, and the answer is in the post on VPNs that disconnect when the screen turns off rather than here. The post on VPNs that keep disconnecting helps tell the two apart.

Culvert VPN sends a WireGuard persistent keepalive on its tunnels so the NAT mapping survives idle periods on home routers and carrier networks alike, and treats a stale tunnel as a signal to reconnect rather than something to wait out; it is on Google Play.