VPN Drops During Big Uploads: Read the Queue First

The tunnel is stable all day, then drops whenever a large upload starts. Interactive requests stall first, the client reports a timeout, and the connection comes back when the transfer finishes. That pattern points at queueing and processing rather than at the remote server being down, because the server was never given the chance to answer in time. The work is to reproduce it under a controlled load and read the right counters.

Change one variable per run, and keep the endpoint fixed.

Build a Repeatable Load Comparison

Record a baseline with the link idle: round-trip time, a few application requests and the tunnel's own event log. Then start an upload of known size and repeat exactly those measurements while it runs. Keep the endpoint, the client and the test destination unchanged, because changing two of them at once tells you nothing.

Note which event appears first. A rising round-trip time before any error suggests queueing; a hard timeout with stable latency suggests something else, such as a rekey or an account action. The two patterns lead to different next steps. Write the observation down before changing anything.

Save the output with timestamps so the loaded and idle runs can be compared line by line.

Read the Queue, Not the Speed

Consumer links buffer packets in the provider's equipment, and a full upstream queue delays everything including the small control packets that keep a tunnel alive. A speed test that reports a high figure says little about that delay, which is why an idle speed test passes while a saturated link fails.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Compare the loaded latency figures with the idle ones. A jump from tens of milliseconds to hundreds, without packet loss, is queueing; loss with stable latency points at a different fault.

Check the Device and the Control Path

Encryption and forwarding cost processor time, and a small router or a thermally throttled laptop can drop packets while it is busy. Watch overall load rather than one process percentage, because kernel forwarding and interrupt handling do not appear where people usually look.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

A client timeout can also coincide with a scheduled rekey or with a session policy event. Read the client's own log for the order of events, not only the application's error message.

Change One Thing and Repeat

Where the platform supports it, limit the upload rate or classify bulk traffic below interactive traffic so the queue never fills. Then repeat the identical workload and compare the same three numbers as before. A change that improves a speed test but leaves the timeout in place has not fixed anything.

Raising timeouts across the board and weakening encryption are the two changes that make the symptom disappear without identifying the boundary that failed. Neither is a repair. Both move the failure later, where it is harder to attribute.

Finish by testing a fresh request and the reconnect behaviour the user actually relies on. Stability under the load that caused the complaint is the only result worth recording.