OpenVPN Performance Tuning Basics

OpenVPN has been used for a very long time, and it comes with a long list of options. That is a blessing and a trap. Online forums are full of configuration snippets with a dozen tweaks, copied from one setup to another without anyone measuring whether they help. Most of those tweaks do nothing, a few are harmful, and only a small number really change performance.

This article covers the basics of OpenVPN performance tuning: what actually limits speed, which settings are worth touching, in what order, and how to check that a change helped. It is aimed at people who control their own configuration, such as a self-hosted server or a configuration file they were given, and it also helps anyone who wants to understand why the same protocol feels fast in one setup and slow in another. It does not claim that any specific service uses OpenVPN. If you use a consumer app that hides these options, the sensible approach is to keep its defaults, and the general lessons here still explain what is going on. If you are new to the protocol, start with what OpenVPN is.

Measure first, tune later

Tuning without measurement is guessing. Before changing anything, collect a baseline.

1. Connect by cable if possible and close background applications.
2. Record download and upload speed three times and take the median.
3. Record idle latency with a hundred pings, and note the range as jitter and any loss.
4. Record latency while a large download runs.
5. Watch the processor use of the device that runs the tunnel.
6. Write all of this down with the date, time and server.

The processor figure matters more than people expect. OpenVPN's data path traditionally runs on a single thread, so one processor core can become the limit while the others are idle. If the core is saturated, no network setting will help; you need a faster core, a lighter cipher choice or hardware encryption support. Our guide on how to test a VPN covers the measurement side in more detail.

Setting 1: UDP or TCP transport

OpenVPN can carry its tunnel over UDP or TCP. This is the largest single choice.

• UDP sends packets without its own retransmission, which keeps latency low and avoids a problem called TCP-over-TCP.
• TCP is reliable, but wrapping a tunnel that itself carries TCP traffic can cause duplicate retransmission and sharp slowdowns when packets are lost.

When both are available, UDP is usually the better choice for speed and responsiveness. TCP is mainly a fallback for networks that block or interfere with UDP. A full comparison, including when TCP is the right answer, is in OpenVPN TCP vs UDP.

Practical rule: if your connection is on TCP and feels sluggish, especially with packet loss, try UDP before touching anything else.

Setting 2: packet size, MTU and mssfix

Every network link has a maximum packet size. The tunnel adds its own headers, so the largest packet your applications can send inside the tunnel is smaller than normal. If packets are too large they must be fragmented, which costs performance, or dropped, which causes stalls. The mechanism for discovering the largest workable size along a path is described in RFC 1191, but it relies on cooperation from every device on the path, and some networks filter the messages it uses.

Symptoms of a packet-size problem:

• Some websites load only partly, or hang after the first part of a page, while others work.
• Large uploads stall while small ones succeed.
• Speed is far lower than expected without any processor or network explanation.

The usual remedies are directives in the configuration file:

• mssfix tells the tunnel to limit the TCP segment size of traffic passing through it, so packets fit without fragmentation. A common approach is to set it to a conservative value, such as 1400, and test.
• tun-mtu sets the interface's packet size. Changing this is usually less necessary than mssfix.
• fragment lets the tunnel itself split large UDP packets. It works only over UDP and adds overhead, so treat it as a last resort.

Test one value at a time. If lowering mssfix fixes stalling pages with no loss in speed, keep it. If it slows things, go back. Do not shrink packets more than necessary, because smaller packets mean more overhead per byte.

Setting 3: cipher and processor cost

Encryption takes processing time, and the cipher you choose affects how much. Two broad families are common in modern configurations.

• AES in GCM mode is fast on processors with built-in AES acceleration, which includes most modern laptops, phones and many servers.
• ChaCha20-Poly1305 is designed to be fast in software, so it can be a better choice on devices without AES hardware support, such as some older phones, small routers and single-board computers.

The right choice depends on your hardware. The test is simple: with the processor monitor open, run a throughput test with each cipher and compare both speed and processor use. Choose the one that reaches the speed you need with the processor to spare. Do not choose a weak or obsolete cipher to gain speed; the gain is small on modern hardware and the security cost is real. Our short piece on ChaCha20-Poly1305 explains why it exists.

Remember that both ends of the tunnel must agree on the cipher, so for a configuration you do not control, this is a question for the server's operator.

Setting 4: leave compression off

Older tutorials recommend compression directives to squeeze more data through the tunnel. Today that advice is out of date, for two reasons. First, researchers have shown that compression inside an encrypted tunnel can leak information about the data, so current guidance is to avoid it. Second, most traffic is already encrypted or compressed, such as video, images and anything over HTTPS, and cannot be compressed further, so the gain is close to zero while the processor cost remains. If a configuration you inherited contains a compression line, check with its source before removing it, but do not add one.

Setting 5: socket buffers

Buffers hold data in transit between the tunnel and the operating system. If they are too small on a fast link, packets can be dropped when a burst arrives, and throughput suffers. The directives are sndbuf and rcvbuf.

• On many systems the defaults are small compared with what a fast connection needs.
• Setting both to a larger value, such as 512 KiB, can help on high-speed links, especially when you see packet loss on the tunnel interface but not on the underlying connection.
• Operating systems cap the maximum, so a very large value may be silently reduced.

Change both together, test, and keep the change only if it helps. On slow links, larger buffers do nothing and can add delay.

Setting 6: keepalive and reconnection

Keepalive settings do not make a connection faster, but they decide how quickly a dead tunnel is noticed and rebuilt, which feels like performance when you move between networks.

• A keepalive directive sends periodic pings and restarts the tunnel when they stop arriving. A typical pair of values is a ping every ten seconds with a restart after sixty seconds of silence.
• Shorter intervals notice a dead link sooner but use slightly more data and battery.
• On a mobile device that switches between Wi-Fi and mobile data often, a short interval and automatic reconnection give a better experience.

If you are mostly interested in staying connected, improving VPN connection stability covers the practical side.

Other options that sometimes matter

• Multi-core use. OpenVPN's classic design is single-threaded per tunnel, so on a server with many cores, running multiple tunnel processes or using newer data-channel offload features, where your version supports them, is the way to use more of the hardware.
• Hardware crypto offload. Where available, it removes cipher work from the main processor.
• DNS settings. Slow page starts can come from slow name lookups, not from the tunnel. Test a lookup separately.
• Server load and location. Even a perfect configuration cannot fix an overloaded or distant server. A nearby location often outweighs every tweak above. See why a VPN is slow for the wider checklist.

A worked tuning session

Here is an invented but realistic walk-through, to show the rhythm.

A user runs a self-hosted OpenVPN server on a small home computer and connects from a laptop on a 300 Mbps connection. Baseline without the tunnel is 280 Mbps. With the tunnel it is 45 Mbps and the home computer's processor is at 100 percent on one core.

Step	Change	Result
0	Baseline with tunnel	45 Mbps, one core saturated
1	Move from TCP to UDP	70 Mbps, still saturated
2	Switch cipher from the old default to an AES-GCM option; the small computer has hardware AES	160 Mbps, core at 70 percent
3	Remove an inherited compression line	165 Mbps, processor use slightly lower
4	Raise sndbuf and rcvbuf	190 Mbps, loss on tunnel interface gone
5	Try lower mssfix	no change in speed, two stalling sites now load
6	Adjust keepalive for a laptop that sleeps	no speed change, reconnects faster after sleep

The biggest wins came from transport and cipher, which matches the ordering in this article. The later steps added smaller but real improvements. Nothing here required exotic options. Note also that the user changed one thing per step and measured each time.

What not to do

• Do not copy a long configuration from a forum without understanding each line.
• Do not disable encryption or authentication to gain speed. That removes the point of the tunnel.
• Do not choose old ciphers because they are lighter.
• Do not change many settings at once. You will not know what helped or hurt.
• Do not tune a congested server's problems on the client. If the server is overloaded, change the server or location.
• Do not alter the settings of a managed app without guidance from its support; the defaults were chosen for that service.

Summary

OpenVPN performance depends mostly on a few things: UDP rather than TCP where possible, packet sizes that fit the path, a cipher that suits the hardware, compression left off, buffers sized for fast links and a keepalive that suits how you move. Measure a baseline, change one setting at a time, record results and keep only the changes that clearly help. If the processor is saturated or the server is far away, no setting will rescue the result, so check those first.

If you would rather skip configuration and use a ready-made app with a short fixed-length pass, see the pricing page, and the free VPNclient app is available from the download page.