VPN upload slower than download? Decide which limit you hit

Most access lines are asymmetric, so a tunnel will usually upload more slowly than it downloads, and that is the expected answer rather than a fault. The interesting question is whether your upload is limited by the line, by something else already using it, or by a flow that stalls instead of running steadily. Those three produce the same complaint and need different work.

Three limits that look identical from the progress bar

Capacity is the first, and it is a property of the access product rather than of the tunnel. An upstream of a few megabits is normal on consumer fibre and on many mobile plans, and encryption overhead is small next to that gap. Encapsulation also adds bytes per packet, which trims goodput in both directions rather than only one, so it cannot explain a large asymmetry on its own.

Contention is the second. Cloud sync, photo libraries and update agents upload while the machine looks idle, and a second device on the same line does the same. Queueing is the third: a saturated uplink pushes interactive traffic behind bulk data, so calls break up while the transfer itself reports healthy progress.

Measure one direction at a time

Use the same device, the same profile and the same destination, and never run both directions at once unless contention is the thing you want to observe. Pause your own optional transfers before the first run. Two runs with one flag between them settle most of it.

iperf3 sends from the client by default, so the plain run measures your upload path; -R reverses the direction and measures download. Run them minutes apart and record both numbers instead of averaging:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

If the upload figure is a small fraction of the download figure and stays stable across runs, the shape matches an asymmetric access line and the tunnel is not the story. If upload swings between runs or collapses after ten seconds, keep reading.

Decide by where the upload changes

Change one variable at a time and watch which direction moves. A second VPN endpoint that uploads better points at that endpoint or the route to it. The same slow upload from a second device on the same line points at the line. A different device on a different line that is also slow points at the destination's ingress policy, which you cannot fix locally.

Record bytes per second and elapsed time for the same workload, not a single speed score. A backup client and a speed test use different destinations and different concurrency, so comparing their numbers answers nothing. If small requests are fine and only large transfers crawl, the limit is probably not bandwidth at all.

For everyday use, capping a background upload or scheduling it outside meeting hours often helps more than any tunnel setting. Judge that change by the combined workload: a backup that finishes later but no longer ruins calls is usually the better trade.

When stalling beats slowness

A transfer that freezes at a repeatable point, then resumes, behaves like a path MTU problem rather than a rate limit. The tunnel reduces the usable payload per packet, and a device that drops the resulting ICMP message leaves the sender guessing. That pattern deserves its own test, because the repair is different from tuning a rate. A steady low number points at capacity, while a burst followed by silence points at a payload the path cannot carry.

Test the path with a payload that must not fragment, then compare the tunnel interface MTU with the value that passes:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

If the large probe disappears while a smaller one succeeds, clamp the TCP MSS on the tunnel rather than lowering the interface MTU for every protocol. Persistent stalls after that point belong to the receiving application's storage or pacing, not to the network path.

What to change, and what to leave alone

Change the things you control: background transfer schedules, endpoint choice and MSS for a stalling path. Keep each change reversible and scoped to one workload. Leave alone the things the measurement says are fine, including a download rate that already matches the line.

Write the before and after numbers down with the profile, endpoint and time of day, because an upload problem that moves with the endpoint is a routing question and one that moves with the device is a local one. That record is what turns a vague complaint into a decision, and it costs two runs of the same command.