Before Blaming the VPN, Measure the Path With iperf3

File copies between two sites feel like network tests, but each one is a combined result: protocol overhead, storage at both ends, endpoint processing and the path. Blaming the VPN from that number alone is guesswork. A short controlled stream between the same endpoints gives a second observation, and the comparison is what shows which part deserves attention. The plan below does that without inventing results.

A file copy is a workload, not a measurement

Bandwidth is one property of a path, while the file copy measures several properties at once. Many small files stress per-file operations far more than a single large stream does. Slow storage on either side caps the copy regardless of the tunnel. Encryption and framing add overhead, but so does a file server doing checksums or antivirus scanning. Only a comparison that holds endpoint and direction steady separates those contributions.

Public speed tests measure a route to a nearby test server, which is not the route to your private file server. They answer a different question.

Run a one-off stream in each direction

When both ends are yours to manage, schedule a brief iperf3 run inside an approved window. Use the file server as the far endpoint where possible, and note it when a stand-in host is used instead.

iperf3 -s -1 -B 10.77.0.20

The server binds to one private address and accepts a single client before exiting. A one-off listener does not expire on its own when no client arrives, so stop it when the approved window closes.

iperf3 -c 10.77.0.20 -t 10

By default the client sends to the server on TCP 5201, and a ten-second window keeps the test short. Restrict the listener to the intended private source and destination in the firewall rather than exposing it publicly.

iperf3 -c 10.77.0.20 -t 10 -R

The reverse flag makes the server the sender, which matters because upload and download paths often differ. Binding an address does not prove the client chose the intended route, so record the path actually tested. Keep the VPN state, direction, duration and endpoint load with the results, then remove the temporary access.

Compare like with like

Re-run a representative file operation under similar conditions, with the same service endpoint and no unrelated configuration change in between. Note whether it is an upload or a download, one large file or many small ones, and whether storage on either side is busy. A short burst is not the sustained rate of the whole copy, and neither observation should silently become the other. If both the stream and the copy are slow in the same direction, look at their shared path and endpoint limits.

When the stream is healthy and the copy is not, the difference is what the workload adds, and that is where the next investigation belongs.

Read the units before drawing conclusions

Megabits per second and megabytes per second differ by a factor of eight, and support threads routinely compare the two as if they were the same unit. A low iperf3 result can also come from the test host itself: CPU saturation, a slow interface or a busy disk can cap the process before the network does. A single number is therefore not a verdict against the ISP or the protocol. The baseline is useful because it is observed rather than assumed, and it narrows the question to one direction and one endpoint.

Write down endpoint, direction, duration and rate for both observations. That quartet makes the comparison defensible, and it costs far less than replacing software on a hunch.