Does an Idle VPN Use Bandwidth? Read the Right Counter

Your tunnel has been up all night, nothing streamed, and the usage graph still moved. That is normal: a VPN holds a conversation open rather than reserving part of your line, so the reserved share is zero while the bytes are small and real. The two ideas get swapped constantly, which is why "does an idle VPN use bandwidth" is answered badly in both directions. Measuring the right counter over a window you can describe settles it in an afternoon.

Why an idle tunnel still moves bytes

A tunnel is a mapping with a lifetime, and something has to keep that mapping alive. Handshakes expire, NAT devices drop idle translations, and a peer that stays silent for long enough can become unreachable with nothing failing at either end. Protocols differ in what they send when there is nothing to send: WireGuard transmits nothing by default once the handshake has settled, and the optional PersistentKeepalive setting adds a periodic packet so a peer behind a translation stays reachable. Turn that on deliberately and the interval becomes visible in a counter.

OpenVPN's keepalive helper works differently, defining ping-style checks so both ends can tell a live session from a dead one, and clients that bundle their own transport have equivalent timers under other names. None of this appears in an application window, which is why an empty screen says nothing about what is on the wire.

An idle application is not an idle device

An open tunnel serves every client attached to it, and clients rarely stop. Photo sync, resolver queries, update checks and a monitoring agent follow whatever route is default, and on a full-tunnel profile that route is the tunnel. A phone asleep in a pocket still polls, and a backup job does not care that nobody is watching a video. The tunnel is idle in the sense that you are not using it while your devices are.

Bridged and routed profiles carry different traffic, so the same observation can produce a different answer on each. Write down who was connected before you measure, because one sync client can outweigh every keepalive in the interval.

Pick one counter and say what it counts

Three totals exist and each answers a different question: what crossed the tunnel, what crossed the physical link, and what the provider decided to bill. Counting on the uplink also counts everything that never entered the tunnel, from ARP churn to a neighbour's streaming. Counting on the tunnel interface misses the outer header, the handshake retries and the keepalives that hold a translation open. Reading both is cheap, and it is the only way to see which side of the tunnel a byte was counted on.

ip -s link show wg0
ip -s link show eth0

Decide which of the two your question is about before you quote either, because adding them counts related work twice. Provider accounting can close in a later period than the one you measured, so a total that disagrees with the invoice is not automatically wrong. Attach the interface, the direction and the window to whatever number you publish.

Run a short supervised measurement

Leave the tunnel and its protection exactly as they run on a normal day, skip optional transfers, and note who stayed connected. Read the counters, wait a window long enough to be worth reading, read them again, and keep the elapsed time beside the difference. A large speed test answers a different question: it saturates the link and says nothing about idle cost.

Repeat the window once if the first result looks impossible, because one sample can catch a scheduled job mid-flight. Two intervals that agree are evidence; one interval is an anecdote with units.

Do not buy a cleaner zero with a worse tunnel

Switching off a keepalive or liveness check to tidy the graph changes the deployment you are measuring, and the tunnel may fail to come back after the next idle period. Ask whether the mechanism serves reachability or maintenance before you touch it, and measure with it running if it does, since that is the configuration you will be supporting. A cleaner zero that hides a broken recovery path is the most expensive result in this exercise.

When the number is genuinely large, find the process or client that produced it rather than assuming the protocol fills the line. Compare the inner and outer counters to see which side the bytes are on, then report usage for that period instead of capacity you think you own.