Does a VPN Run Out of Entropy? What entropy_avail Really Shows
A boot-time stall and a slow established tunnel are different faults. Read the stage, the counter's real meaning, and the queue before blaming randomness.
Running out of kernel randomness is an appealing explanation for a slow VPN, and almost always the wrong one for the symptom people report. A host waiting on random output stalls at a particular moment, usually early in boot or during key handling. A tunnel that connects quickly and then transfers slowly is describing throughput instead. Separate those two observations before installing a daemon to fix a number you have not finished reading.
Why the myth survives
Both problems are real and they look alike from a distance. Startup stalls on a freshly booted virtual machine do happen, and a slow established tunnel is equally real. The error is assuming the second is caused by the first because cryptography appears somewhere in both stories. Nothing about the word encryption implies that each transferred byte consumes a fresh byte of environmental noise.
That is not how these generators work. A cryptographic library keeps a seeded generator and draws output from it, reseeding under its own policy, so the expensive moment is seeding rather than steady transfer.
What a generator does per packet
In OpenSSL 3 the default generator hierarchy is built from DRBG instances that seed and reseed according to configuration and state. In OpenVPN 2.6 the AEAD data path derives its nonce from the packet's sequence number combined with a per-session implicit value, while the older CBC path draws a pseudo-random IV per packet. Neither pattern supports a rule that moving a gigabyte consumes a gigabyte of fresh kernel noise. Both do support the idea that key generation and handshakes are where seeding matters.
The CBC case is worth naming because it looks like the myth and is not: its per-packet IV comes from the library generator on the library's own reseed schedule, never from a kernel call per packet. When somebody quotes a per-byte entropy cost, ask which library version and which code path they measured.
Where the waiting actually shows
Put timestamps around the stages rather than around the session: startup, authentication, key change and transfer. A wait before the tunnel becomes usable is a different complaint from a low steady rate, and only one of them points at randomness. On Linux a normal getrandom() request can block until the kernel's random source is initialised, which is why the boot-time version of this problem is real on virtual machines and embedded boards that have little to feed the pool early.
| Stage | What to run | Reading that means waiting | Reading that means throughput |
|---|---|---|---|
| Boot, before any tunnel | systemd-analyze critical-chain | a unit sitting for seconds before the tunnel starts | not applicable, nothing is transferring yet |
| Handshake | journalctl -u openvpn-server@server -b | a long gap before the initialization sequence completes | not applicable, the tunnel is not up |
| Established transfer | ss -tin beside sar -n DEV 1 | a blocked process with empty socket queues | full queues, retransmits and one busy thread |
Two cheap commands belong at the start of that collection, and they settle the easy questions before the table is even needed. The counter they read is entropy accounting rather than a bandwidth meter, and a single snapshot cannot show that a process is blocked, how long it waited, or which interface its library calls. A sample taken after recovery usually misses the stall entirely, so keep the kernel version beside the reading.
cat /proc/sys/kernel/random/entropy_avail
uname -rMatch the correction to the reading
If the kernel genuinely waits for initialisation, look at the platform's supported seeding path rather than at the tunnel. A virtual machine can be given a host-provided random device such as virtio-rng, and image preparation matters because a seed copied unchanged into many guests is not independent initialisation. If a library reports seeding failures after boot, inspect its configured source and provider behaviour instead of changing kernel settings.
ss -tin dst 203.0.113.7
sar -n DEV 1 5The OpenSSL generator documentation describes how that hierarchy obtains input and when reseeding happens, which is a far narrower claim than the myth and one that holds only for that implementation. An entropy daemon is not a universal speed repair, and installing one to make a counter rise alters a security assumption without demonstrating a delay. For throughput, follow the data path: one saturated thread, retransmissions, outer loss and queue drops each need a different fix, and buffer sizes address socket buffering with their own queue evidence.