WireGuard vs OpenVPN Speed on Low-Power Routers

A router can forward ordinary traffic quickly yet struggle once every packet needs encryption. Comparing VPN protocols on that hardware requires more than running a browser speed test and choosing the larger number.

This guide builds a repeatable experiment for a router you administer. You will separate tunnel throughput from internet congestion, watch CPU and temperature, and translate measured results into practical backup or download times without claiming a universal winner.

Define the workload before comparing protocols

Start with the job the router must handle: a single backup stream, several video calls, or multiple users downloading concurrently. Throughput capacity and latency under load answer different questions. A configuration that wins a bulk transfer can still feel poor when its upload queue is saturated.

Use the Bandwidth & Transfer Time Calculator below to turn your target file size and expected connection speed into a transfer-time budget. Try an optional overhead allowance as a planning assumption, not a measured property of either protocol. Later, replace the assumed speed with observed application throughput.

Write an acceptance target before testing. For example, require a nightly backup to finish within its maintenance window while interactive SSH remains usable. Avoid declaring that either protocol must reach the access line's advertised rate: ISP capacity is only one of several bottlenecks.

Record router model, firmware, processor, cooling, WAN connection, and VPN endpoint location. These details make a result reusable instead of merely impressive.

Build a controlled test path

Use one wired client behind the router and an iperf3 server on a remote Linux host you control. Restrict the server's TCP test port to the expected source addresses, and remove that access afterward. A test over the public internet still includes transit congestion, so repeat at different times.

Both VPNs should terminate on the same remote host, or on comparable hosts in the same location. Keep routing mode and MTU choices documented. Test protocols sequentially so the two tunnels do not compete for bandwidth or install conflicting default routes.

Use current, supported configurations from the WireGuard quick start and OpenVPN community resources. Record negotiated OpenVPN data ciphers and whether data-channel offload is actually active. Firmware and acceleration support can change the result substantially.

Establish a no-VPN baseline using the same wired client, server, and test duration. Confirm that the traffic really traverses the router rather than terminating on it. Generating test traffic on a small router itself can consume the CPU you intended to measure for forwarding.

For a home-server alternative to router-based termination, see the Raspberry Pi OpenVPN client setup. Moving the tunnel endpoint changes which CPU bears the workload, so do not mix those results into the same comparison.

Measure throughput in both directions

Install iperf3 on the client and server through their normal package managers. The example uses 10.20.0.10 as the server's tunnel-reachable address. For the baseline, substitute the server's authorized reachable address and confirm its firewall restrictions.

# Run on the remote test host.
iperf3 -s
# Run these separately on the wired client.
iperf3 -c 10.20.0.10 -t 30 -O 3 -J > upload.json
iperf3 -c 10.20.0.10 -t 30 -O 3 -R -J > download.json
iperf3 -c 10.20.0.10 -t 30 -O 3 -P 4 -J > parallel.json

The reverse test measures server-to-client transfer, while the default sends client-to-server. The omit period allows startup behavior to settle before reported statistics. Preserve the JSON files with descriptive names for each protocol and run number.

Run each direction at least three times. Report the median and range rather than the highest sample. Alternate protocol order across rounds so one tunnel does not always receive a cooler router or a quieter internet connection.

The parallel-stream test is a separate workload, not a replacement for the single-stream result. Multiple streams may hide a per-flow limitation or fill a high-latency path more effectively. Keep stream counts identical when comparing configurations.

Do not add UDP load tests until you understand the path's capacity and have permission for the generated traffic. An unlimited sender can create loss for other users without producing a useful application benchmark.

Observe CPU, heat, and responsiveness

While transfers run, collect CPU observations on the router. On Linux-based firmware, available commands vary; top and /proc are common, while mpstat may require an optional package. Do not install packages unsupported by the firmware vendor.

# Run on the router if these interfaces are available.
top -b -d 1 -n 35 > /tmp/vpn-cpu.txt
cat /proc/softirqs
cat /sys/class/thermal/thermal_zone0/temp
# Run from the wired client during each throughput test.
ping -c 30 10.20.0.10

The thermal file, when present, commonly reports millidegrees Celsius; identify its sensor before interpreting it. Take readings before and after a sustained run. A brief test may miss thermal throttling that appears during a large backup.

Inspect individual cores where your monitoring tools permit it. A low aggregate CPU percentage can conceal one saturated core. Kernel networking and softirq work also matter, so a quiet OpenVPN process does not prove the processor has spare capacity.

Compare idle ping with loaded ping, while remembering that ICMP may be rate-limited. If both protocols show large delay increases only when uploads saturate, investigate queue management rather than blaming encryption alone. The Bufferbloat project provides background on latency caused by oversized queues.

Interpret results and choose conservatively

WireGuard often performs well on modest hardware, but implementation details matter more than a protocol label. OpenVPN with supported offload and suitable acceleration can behave differently from an older userspace-only build. Keep security settings appropriate; do not weaken authentication or encryption merely to improve a chart.

If throughput stays low while CPU is mostly idle, check the remote host, link capacity, packet loss, negotiated Ethernet speed, and tunnel MTU. If large transfers stall while small requests work, investigate path MTU before repeatedly changing cryptographic options.

Convert the measured application rate using the transfer-time calculator. When the input already comes from iperf3 payload throughput, avoid subtracting guessed VPN overhead again. Use overhead estimates only when starting from a raw link rate, and label them clearly.

Keep operational reliability in the decision: reconnect behavior, key rotation, firmware updates, and troubleshooting access may outweigh a small speed difference. For broader context, the VPN privacy guides cover routing and failure handling that a throughput graph cannot capture.

Repeat the winning configuration after a longer warm-up with ordinary household traffic present. Save the configuration versions and raw logs so a later firmware update can be evaluated against a reproducible baseline.

Key takeaways

• Compare identical paths and workloads, with a no-VPN baseline and repeated runs in both directions.
• Measure CPU and loaded latency alongside throughput, including sustained heat effects.
• Distinguish single-stream performance from parallel transfers and account for offload support.
• Choose the configuration that meets your real transfer window and reliability needs, not the largest isolated number.