Learn OpenVPN - Performance Tuning & Benchmarking

#Introduction

The DCO from episode 14 raises the throughput ceiling. But DCO alone isn't enough — many other factors determine how many Mbps you actually get. Buffers that are too small, MTUs that don't fit, or default configurations that don't match the network can push performance numbers far below potential.

Episode 18 covers performance tuning and benchmarking. You will learn to adjust buffers with sndbuf and rcvbuf, set the queue with txqueuelen, work around MTU with tun-mtu, fragment, and mssfix, then prove the results with iperf3.

The core principle: never change a parameter without measurement. Benchmark first, change one variable, measure again. Only that way do you know which change really has an impact.

#Buffer and Queue Tuning

#sndbuf and rcvbuf

Kernel buffers determine how much data can wait before being processed. sndbuf sets the send buffer, rcvbuf the receive buffer. Kernel defaults are often too small for high-speed VPNs:

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

sndbuf 393216 and rcvbuf 393216 raise the buffers to 384 KB. The push part is important: the values on server and client must align, because speed is limited by the slowest side.

#txqueuelen on the Tun Interface

The transmit queue of the tun0 interface affects how many packets can be processed at once. If the queue is too short, packets are dropped and TCP has to retransmit — performance nosedives:

ip link set tun0 txqueuelen 1000

ip link set tun0 txqueuelen 1000 raises the queue length. This value doesn't persist across reboot; for permanence, run it through a systemd unit or include it in the interface setup script.

#MTU Tuning

#Understanding MTU and MSS

Every tunnel packet has two layers of size: the tunnel MTU visible to applications, and the physical packet traversing the internet. If the physical packet exceeds the path MTU, it gets fragmented or dropped. This mismatch is a classic source of performance problems and dropped connections.

#tun-mtu and mssfix

The tun-mtu directive sets the MTU advertised inside the tunnel, and mssfix adjusts the TCP segment size so it fits within the limit:

tun-mtu 1400
mssfix 1360

tun-mtu 1400 reduces the tunnel MTU from the default 1500 to make room for UDP headers and OpenVPN encapsulation. mssfix 1360 tells TCP connections inside the tunnel to use smaller segments. Together they avoid fragmentation.

#fragment as a Fallback

For unpredictable paths, fragment breaks up packets on the sender side. This adds overhead and is generally only used when mssfix isn't enough — for example on PPPoE connections with non-standard MTU:

fragment 1300

fragment 1300 makes packets larger than that split into 1300-byte chunks before sending. This value must be smaller than or equal to the physical path MTU. Start with a safe value and lower it only if problems persist.

#Finding the Right MTU

The most accurate way to find the MTU: measure the path MTU with unfragmented ping:

ping -M do -s 1400 8.8.8.8

ping -M do -s 1400 8.8.8.8 tests a 1400-byte packet without fragmentation. Increase the size until ping fails; the last successful point indicates the path MTU. This information becomes the basis for the correct tun-mtu and mssfix values.

#Benchmarking with iperf3

#Setting Up an iperf3 Server

To measure real tunnel throughput, run iperf3 in server mode on one side of the tunnel:

iperf3 -s

iperf3 -s starts the measurement server. Run it on a machine reachable through the tunnel — ideally in the network behind the server, so the measurement covers the entire VPN path, not just the link between two interfaces.

#Measuring Throughput from the Client

From the client side, run iperf3 in client mode toward the tunnel address:

iperf3 -c 10.8.0.1 -t 30 -P 4

iperf3 -c 10.8.0.1 -t 30 -P 4 tests throughput for 30 seconds with 4 parallel streams. Test with 1 stream to see TCP latency behavior, and with many streams to see maximum throughput. Record both results as a baseline.

#Measuring Latency

Latency is measured by pinging the tunnel address versus pinging an ordinary network address:

ping -c 20 10.8.0.1
ping -c 20 8.8.8.8

ping -c 20 10.8.0.1 measures tunnel latency; compare it with ping -c 20 8.8.8.8 to see the VPN overhead. Normal overhead is in the order of milliseconds. Latency spikes usually indicate buffers that are too large or a congested path.

#A Disciplined Tuning Process

#One Variable, One Measurement

Change one parameter, benchmark, then compare. Trying many changes at once makes it impossible to know which one mattered. Keep results in a simple table: parameter, value, throughput, latency. The recommendations in episode 18 are just starting points — your network determines the final numbers.

#Keeping Safe Defaults

If there's no measurable performance problem, don't change anything. Wrong tuning parameters — especially overly large buffers — can create new problems: wasted memory and bloated latency. The benchmark is the final judge.

#Conclusion

Key takeaways:

• sndbuf and rcvbuf must align between server and client.
• txqueuelen prevents dropped packets on the tun interface.
• tun-mtu and mssfix work together to avoid fragmentation.
• fragment is only for paths with hard-to-predict MTU.
• iperf3 measures real throughput through the tunnel.
• Change one variable and re-measure before changing another.

In the next episode, episode 19, we will discuss observability and monitoring — using openvpn-status.log as a metrics source, exposing data to Prometheus with the openvpn exporter, building a Grafana dashboard, and alerting for dropped connection detection and certificate expiry warnings. After this episode, your VPN's health can be monitored on a single screen.