Why the VPN penalty looks worse on cellular than Ethernet

The same laptop, the same server and the same tunnel can lose a fifth of its throughput on Ethernet and three quarters of it on cellular, and neither number means the VPN is broken. Each access network supplies a different path, and the tunnel adds a second path on top of it. Comparing one tunneled figure with one untunneled figure answers nothing, because the two figures describe different denominators. Four cells and one retention fraction per row will tell you which question to ask next.

Four cells, not one penalty

Measure the direct baseline and the tunneled result on each access network, and keep them as a matrix rather than as a single verdict. The baseline is the same task performed on that network without the tunnel; the tunneled result is the same task with it.

Use an authorized workload for the direct tests and keep the privacy controls the environment requires. A test that violates policy produces a number you cannot publish and should not repeat.

Hold the variables still

Keep the device, application, destination, transfer direction and VPN endpoint fixed across all four cells. If a service silently switches its test server between runs, record the change and treat the pair as uncontrolled rather than averaging the difference away.

Repeat the matrix in both directions and at comparable times of day. A cellular radio's conditions and the load on its cell change within minutes, so a single unusually good baseline can exaggerate the apparent penalty. Record the spread of results next to a representative value, and note whether the tunneled runs were interleaved with the baselines or run in a block.

Interleaving matters more than most people expect. A baseline measured before lunch and a tunneled run measured after it are two different networks wearing the same name.

Keep the denominator visible

Report the retention fraction as well as the absolute rate: E1 divided by E0, and C1 divided by C0. A fast link that keeps a small share of its throughput and a slow link that keeps most of it are different findings, and only the fraction shows the difference.

Absolute throughput still decides what a user can do. The fraction decides where to look. When Ethernet retains most of its baseline and cellular retains much less, the interesting variable is on the cellular path rather than inside the encryption.

Both numbers belong in the report, because either one alone supports a conclusion the data does not.

Read the pattern before changing anything

Similar tunneled ceilings on both networks point at something shared: the endpoint, its CPU, a rate limit or a single congested hop. A decline that appears only on cellular points at that network's route, loss, latency and effective packet size.

These are leads, not diagnoses, and the difference matters when you write the ticket. A shared ceiling will not improve when you change the cellular modem, and a cellular-only decline will not improve when you resize the endpoint. State which of the two patterns you saw before proposing a change. That way the change carries a prediction, and the next measurement can confirm or kill it.

OpenVPN's own performance guidance separates bandwidth, CPU, transport and packet-size constraints along the same lines, which is a useful reminder that the tunnel is rarely one variable.

When packet size is the suspect

Encapsulation consumes packet space, so the effective size on a cellular path can be smaller than the one the interface advertises. Retain packet-size evidence for the path you are comparing instead of assuming a value from the access technology's name.

Datagram packetization-layer path MTU discovery describes discovering the effective size rather than hardcoding one. Use the implementation's supported observations, and do not push an arbitrary low MTU onto every client as a precaution, because that trades one problem for a worse one on paths that were fine.

A size hypothesis needs its own evidence: the same transfer at two sizes, with the loss pattern recorded.

Add one variable at a time

Compare an alternative transport only after the baseline matrix is saved. That keeps one deliberate variable in play, and it lets you attribute the change instead of guessing at it.

Keep TCP payload sizing separate from UDP datagram behaviour, since the two react differently to loss and to path size. An improvement from a transport change is evidence about that transport, not proof that encryption or coverage was the original cause.

Order of work: fill the four cells, compute both fractions, interleave the runs, then pick one hypothesis and test it with one change. Anything else is a comparison of two unknowns.