Fix VPN Drops During Idle: A Wi-Fi Power Save Checklist

Your tunnel dies after the laptop sits untouched for a while, and it comes back the moment you touch the trackpad. That pattern points at the wireless link entering power save, not at the VPN gateway rejecting your credentials. A busy morning on the same profile is the tell: the tunnel survives while traffic flows and fails once the radio goes quiet. Work the checks below in order, stop at the first one that fails, and only then change a setting.

Check one: does the drop follow idleness?

Start by proving the correlation instead of assuming it. Note the wall-clock time of the last packet you sent, the time the client reported the tunnel down, and whether the screen turned off in between. If the gap is the same every time, you have an idle-path problem; if drops land randomly during active use, jump to check five.

A cheap test that costs nothing to undo: run a steady low-rate ping to your gateway for twenty minutes and leave the machine alone. If the tunnel stays up for the whole run, constant small traffic is masking the symptom rather than fixing it, which is still useful evidence. I keep that ping output in a scratch terminal and compare it with the client log afterwards, because the two clocks rarely agree.

Check two: is it only VPN traffic?

Before blaming the tunnel, find out whether the link itself is still usable. While the tunnel is dead but the screen is still off, try to reach the access point address and a public host by IP. If the plain ping fails too, the radio or the access point dropped you and the VPN client is a bystander.

If ordinary traffic flows while the tunnel stays silent, the link is healthy and the problem sits in the tunnel's own timers or in how the client handles a resume. Those are two different fixes, so do not skip this step. On a laptop with both Wi-Fi and Ethernet, unplug and repeat the idle test: an idle drop that disappears on wired Ethernet is strong evidence for the wireless layer.

Check three: read the power-save state

Most desktops give you a checkbox, but the checkbox is not the state the driver is in. Read the driver's own report first, then decide. On Linux with mac80211 the interface answers directly:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

The second command is a test, not a fix. It does not survive a disconnect, suspend or reboot, which makes it a clean way to check the hypothesis without leaving permanent changes behind.

On Windows, powercfg /q SCHEME_CURRENT prints the active scheme, and the wireless adapter subtree shows whether the adapter may be told to save power; the same choice also sits in Device Manager on the adapter's power management tab. On macOS the per-interface 802.11 power save is not exposed to you, so look at pmset -g for sleep and standby behaviour instead. There the failure usually turns out to be the sleep and wake path rather than the radio's idle behaviour.

Check four: change one thing, then re-test

Change exactly one variable per run and repeat the same workload. If the tunnel now survives an idle hour with power save off, you learned something real. If it still drops, revert before testing the next idea, otherwise you end up with three overlapping settings and no idea which one matters.

Keep-alive is the other independent variable and it gets conflated with power save constantly. WireGuard's PersistentKeepalive = 25 keeps a NAT mapping warm; OpenVPN uses keepalive and ping-restart on both ends. Both generate traffic on an otherwise silent tunnel, so a keep-alive that appears to fix the drop may be hiding a radio problem rather than solving it. Test them separately, one at a time:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

Check five: when the radio is innocent

If idle drops survive with power save off and a keep-alive on, look outside the laptop. Access points and consumer routers expire idle NAT or session entries on their own schedule, and a VPN server may drop a session that has no traffic. Roaming between access points that share one SSID can also reset the link without the client saying so clearly.

Then compare against a second device on the same network doing the same idle test. Two devices dropping at the same interval is a path or server story; one device dropping is a local driver or power story. That comparison costs ten minutes and saves you from rewriting the wrong configuration.

Before you make it permanent

Decide what you are willing to keep. A per-profile script that turns power save off only on the networks where you have seen the drop is defensible. A global disable-everything tweak paid for with battery life on every network usually is not.

• Record the original power-save value next to the script so it can be restored.
• Re-run the idle test after every driver or client update; defaults change.
• Keep the ping log and the client log together when you report the issue.
• If step two failed, stop changing VPN settings and treat it as a local link fault.

If you only do one thing, do check two. It decides whether the rest of this list applies to you at all, and it is the step people skip once they have already decided the answer is power saving.