Is low VPN throughput an entropy problem? Usually not

Slow throughput through a tunnel and a machine stalled waiting for random numbers produce very different experiences, yet they get filed under the same complaint. One shows up as a pause before anything works. The other shows up as a connection that works and moves data slowly for as long as you watch it. Deciding which one you have takes ten minutes and saves a week of guessing.

Two symptoms that look alike

A service that hangs after a fresh boot, before it accepts a single connection, is waiting for something. A tunnel that establishes quickly and then transfers at a fraction of the expected rate is limited by something else. The word encryption appears in both stories, which is why they get merged. Separate them before you touch a configuration file.

Put timestamps around startup, authentication, key renegotiation and the transfer itself. A long delay before the tunnel is usable is not a low steady rate, and averaging the two into one number destroys the evidence.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

The first two commands place startup work on a timeline. The third prints the kernel's entropy accounting value, which is useful as a single data point and useless as a bandwidth meter.

What a random-number wait actually looks like

A request for secure random bytes can block until the kernel has initialized its random source. That matters most on virtual machines and small embedded boards early in boot, when little environmental noise has been collected. It does not follow that every encrypted byte consumes fresh entropy.

Modern generators seed once and then produce output from a deterministic construction, reseeding on their own schedule. Bulk transfer does not drain a pool byte for byte, so a low pool value during a slow transfer proves nothing about the cause.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

The first command shows whether the process is sitting in a random-number call while you watch. The second shows the kernel's own initialization messages, which is where an early-boot stall becomes visible.

Record the kernel version and the library the service actually links against, because the behaviour differs between implementations and between releases. A trace taken after recovery usually misses the pause entirely.

What sustained slowness actually looks like

A tunnel that transfers slowly throughout is limited by the data path. One saturated thread, outer-packet loss, retransmissions or full socket queues each produce that pattern, and each has its own fix. Aggregate CPU percentage hides a single busy thread, which is the most common misreading. Look at per-thread time before you look at total load.

Measure in both directions with a comparable baseline, and watch the interface counters rather than the application's own report.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

The first command shows queue and congestion state for one peer. The second and third report drops and retransmissions at the stack and at the interface, which is where the cause usually appears first.

Pick the correction for the bottleneck you measured

If the evidence points at early-boot initialization, look at the platform's supported seeding path, which on a virtual machine may include a host-provided random device. A seed image copied unchanged into many guests is not a substitute for independent initialization.

If the evidence points at the data path, tune what the counters implicate. Buffer sizes help when queues overflow and do nothing when one thread is saturated. Installing an entropy daemon to raise a counter is not a throughput repair, and changing seeding assumptions to make a graph look better trades a security property for a number.

Accept the change only when the same measurement improves under the same conditions. A larger counter is not a result; a shorter measured wait or a faster transfer with an identified cause is.