Why a VPN Download Is Limited by the Server's Upload

The client shows a fast downlink, the server sits on a fibre connection, and the transfer still crawls. The number people compare is usually the one printed on the client's plan, while the packet actually crosses the server's outbound access link first. That link is the budget the transfer has to fit into. On a small home connection it is the smallest number in the path.

The Number You Read Was the Wrong Direction

A download toward a remote client consumes upload capacity at the server end of the tunnel. Advertised server download rates describe the opposite direction and tell you nothing about this one. The same asymmetry reverses when the client uploads, which is why one direction can feel fine while the other is unusable.

Encapsulation overhead and any competing traffic spend part of that same budget. Neither of them is visible in a speed test that measures the client alone.

Write the Path as a Budget

List every boundary the packet must cross and give each one a number in the same unit. Source delivery, server processing, the server's uplink, the intervening path, the client's downlink and the client's processing all apply. The usable rate is the smallest of those, minus overhead, and no tuning above that ceiling changes the outcome. Write the list down before measuring, because it tells you which number to disbelieve.

With a 20 Mbit/s server uplink and a 100 Mbit/s client downlink, the server caps the transfer long before the client notices. Overhead and any concurrent transfer take a further slice, and a saturated uplink also delays acknowledgements, which slows a TCP transfer below the raw ceiling. Neither effect appears in a plan comparison.

Keep megabits and megabytes apart, and say whether each figure measures encrypted link traffic or application payload. Mixing those two is the most common reason a budget appears not to add up. Label every figure with its unit and its measurement point.

Where the Board Actually Costs You

Once the access link is large enough, the endpoint hardware becomes visible, and only then does the processor matter. Identify the model, the interface arrangement and the implementation in use. An observation about an early board's shared bus does not describe every later revision.

Compare individual processing paths rather than a single CPU average. A moderate overall load can hide one saturated core doing all the per-packet work, and clock frequency does not transfer between processor designs as a performance score. Packet rate matters as much as throughput, since small packets cost more per byte than large ones. Measure with the packet sizes your workload actually uses.

Thermal and power limits decide sustained behaviour too. A short burst can look excellent while a ten-minute transfer throttles, which is why a benchmark of a few seconds is a poor guide to a nightly backup.

The vendor's performance guidance separates access bandwidth, CPU, packet processing, transport and packet size into distinct constraints. It is worth reading before changing a cipher, because a cipher change rarely moves a boundary that was never the limit.

Measure Before You Change a Cipher

Run a directional test that reports the rate actually achieved through the tunnel, then run the same test on the raw interface for comparison. The difference between those two numbers is the cost of the tunnel, and the smaller of the two ceilings tells you which boundary to attack.

Keep security policy intact while comparing. An old result obtained with a weak cipher or an overclocked board is not a plan for the current deployment.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Store the directional results next to the endpoint observations from the same run. The next change should target the measured ceiling rather than the component that looks smallest on the specification sheet.