How to Benchmark WireGuard

Benchmarks without a method produce confident nonsense. WireGuard is fast on paper; your tunnel is only as fast as the VPS uplink, the path MTU, the CPU left after noisy neighbors, and the way you drive the test. This guide shows how to measure WireGuard throughput and latency so the numbers inform capacity planning—not slide decks.

You will use ordinary Linux tools (iperf3, ping, wg, ss), keep the topology honest, and separate path limits from tunnel overhead.

What You'll Learn

• How to define a WireGuard benchmark that answers a real capacity question
• How to baseline the path before you measure the tunnel
• How to run repeatable iperf3 tests through WireGuard
• How to interpret CPU, retransmits, and MTU symptoms
• How to compare regions, instance sizes, and MTU settings fairly
• Best practices, common mistakes, and FAQ for performance testing

Decide What Question You Are Answering

Pick one primary question per test series:

• “How much TCP throughput can one employee get through this VPN in region X?”
• “How much does WireGuard add versus the bare path?”
• “When does a 1‑vCPU droplet become CPU-bound with N concurrent streams?”
• “Does MTU 1280 vs 1420 change transfer time on this path?”

If you mix questions, you will optimize the wrong knob. Write the question down before you open a terminal.

Metrics that matter

Ignore vanity “Gbps” claims until you know the instance’s network cap and whether the test was single-stream or multi-stream.

Lab Topology

Use a minimal, known topology:

1. VPN server — Ubuntu 22.04 or 24.04 VPS with WireGuard installed, public endpoint, IP forwarding enabled if you hairpin traffic.
2. Client — another VPS in a different network or a laptop on a representative path. For capacity of the server, two cloud VMs in known regions are more repeatable than café Wi‑Fi. For user experience, add a laptop test later.
3. Tunnel addresses — e.g. server 10.66.66.1/24, client 10.66.66.2/32 in AllowedIPs.

Keep AllowedIPs tight for iperf between tunnel IPs so you are not accidentally measuring full-tunnel internet egress.

Install basics (Ubuntu)

sudo apt update
sudo apt install -y wireguard iperf3 iproute2 procps

Confirm the interface:

sudo wg show
ip -br addr show wg0

Step 1: Baseline the Path Without WireGuard

From the client host to the server’s public IP, run:

# On server
iperf3 -s

# On client
iperf3 -c SERVER_PUBLIC_IP -t 30 -P 1
iperf3 -c SERVER_PUBLIC_IP -t 30 -P 4

Record:

• Single-stream and 4-stream TCP throughput
• Retransmits reported by iperf3
• Approximate RTT via ping -c 20 SERVER_PUBLIC_IP

This is your ceiling. WireGuard cannot beat a saturated uplink or a bad peering path. If bare throughput is 200 Mbps, a 1 Gbps “WireGuard benchmark” elsewhere is irrelevant.

Step 2: Baseline Latency Through the Tunnel

With WireGuard up:

ping -c 50 10.66.66.1

Compare to public-IP ping. A few milliseconds of overhead is normal. Large jumps suggest wrong routing (traffic leaving via a longer path), CPU saturation, or middlebox pain—not “WireGuard is slow” as a slogan.

Check peer handshakes:

sudo wg show wg0

Look for recent handshakes and expected transfer counters during tests. No handshake means you are benchmarking failure.

Step 3: Throughput Through WireGuard

Bind iperf3 to tunnel IPs so results reflect the encrypted path.

Server (inside tunnel):

iperf3 -s -B 10.66.66.1

Client:

iperf3 -c 10.66.66.1 -t 30 -P 1
iperf3 -c 10.66.66.1 -t 30 -P 4

Also test reverse direction (-R) if your workload is download-heavy from the server’s perspective.

Optional: UDP mode

iperf3 -c 10.66.66.1 -u -b 500M -t 30

UDP mode is useful for spotting loss and jitter. Do not treat UDP iperf “throughput” as identical to real TCP application performance.

Step 4: Watch the Server While You Test

In another session on the VPN server:

mpstat 1
sudo wg show wg0 dump

Interpretation cheat sheet:

• Throughput ≈ bare path, CPU low — tunnel overhead is negligible; buy better path/region or accept the cap.
• Throughput << bare path, CPU pegged — scale CPU, reduce concurrent load, or ensure you are on kernel WireGuard (not a userspace bottleneck elsewhere on the box).
• Throughput << bare path, CPU low, many retransmits — suspect MTU/fragmentation, lossy path, or cloud rate limiting.
• Asymmetric results — check provider egress policies, reverse-path filters, and whether you tested both directions.

Step 5: MTU Experiments (Controlled)

WireGuard encapsulation consumes headroom. A common working tunnel MTU is in the 1280–1420 range depending on path. Change one side’s interface MTU at a time, reload, and re-run the same iperf3 commands.

Example:

sudo ip link set dev wg0 mtu 1280
# retest
sudo ip link set dev wg0 mtu 1420
# retest

Persist the winner in your wg-quick config (MTU = …). Pair with MSS clamping on routers/firewalls when TCP stalls on “large downloads only” tickets. For a deeper dive, see a dedicated MTU optimization guide—here the rule is: treat MTU as a measured variable, not folklore.

Step 6: Concurrency and Sizing

To approximate multi-user load, increase iperf parallel streams or run multiple client VMs:

iperf3 -c 10.66.66.1 -t 60 -P 8

Plot throughput vs CPU. Capacity planning needs the knee of the curve: the point where adding streams stops increasing aggregate throughput and only increases latency. That knee informs “users per droplet” far better than a single stream max.

On DigitalOcean and similar VPS providers, also watch for instance network caps and noisy-neighbor variance. Run each test 3 times at different hours if the result will drive a purchase decision.

Step 7: Record Results Like an Engineer

Store a small table per run:

• Date, region, instance type/size
• Kernel / WireGuard version (uname -r, wg version)
• MTU, port, cipher (fixed for WireGuard, but note PSK use)
• Bare iperf3 P1/P4
• Tunnel iperf3 P1/P4 (+ reverse)
• ping RTT public vs tunnel
• CPU during test
• Notes (loss, rate limits, background jobs)

Without this metadata, last month’s “900 Mbps” number is useless.

Interpreting Results for Capacity Planning

Once you have numbers, convert them into operational limits.

Suppose bare-path TCP is 940 Mbps, tunnel TCP is 820 Mbps, and CPU sits at 55% on 2 vCPUs during a 4-stream test. You have headroom. If tunnel TCP is 300 Mbps while bare path is 900 Mbps and softirq or the WireGuard path pegs a core, scale CPU or reduce concurrent bulk users on that node.

Translate throughput into concurrent users carefully. Interactive SSH and HTTPS to internal tools rarely need 50 Mbps each. Full-tunnel video and large sync jobs do. Build two profiles:

• Interactive concurrency — many peers, low bytes per second, watch connection tracking and CPU at login storms.
• Bulk concurrency — few peers, high bytes, watch NIC caps and egress invoices.

A gateway can “support 100 users” interactively and still melt when five of them push container images through full tunnel. Capacity is workload-shaped.

Client asymmetry

Phone clients on LTE, laptops on Wi‑Fi 5 GHz, and CI runners on cloud networks produce different loss and MTU behavior. Keep a representative client matrix for release testing whenever you change MTU or region—not only VM-to-VM benches.

Kernel and version notes

Record uname -r and whether you are on distro WireGuard packages versus out-of-tree modules on older kernels. Most Ubuntu 22.04/24.04 servers use in-tree WireGuard; still note it. Client apps (official WireGuard apps vs routers vs wg-quick on Linux) can differ in throughput under CPU constraints even when the server is fine.

Turning Benchmarks Into Runbooks

Attach a short “perf acceptance” block to every new region:

1. Bare iperf3 P1/P4 above an agreed floor for that SKU
2. Tunnel iperf3 within an agreed percentage of bare
3. ping RTT within expected geography bounds
4. CPU under X% during the standard test

Fail the region bring-up if acceptance fails. That prevents “we launched Europe and it feels terrible” from becoming a week of guesswork.

Best Practices

• Baseline bare path before every meaningful protocol comparison.
• Use tunnel IPs for iperf so you do not accidentally measure the wrong path.
• Hold region, instance size, and time-of-day as constant when comparing MTU or config changes.
• Prefer kernel WireGuard on Linux servers; know what your clients run.
• Test both directions for asymmetric cloud networks.
• Separate laptop-Wi‑Fi UX tests from VM-to-VM capacity tests.
• Automate peer setup so benchmark labs are reproducible.
• Stop tests when CPU steal or provider throttling dominates—fix the host class first.

Common Mistakes

• Benchmarking across the public internet and attributing all loss to WireGuard.
• Running iperf3 on the public IP while WireGuard is up and calling it a tunnel test.
• Single 5‑second run declared as truth.
• Ignoring CPU and declaring the protocol broken.
• Comparing different instance sizes between “before” and “after.”
• Leaving default MTU and concluding encryption is expensive when packets are fragmenting.
• Testing full-tunnel internet egress (variable CDN paths) when you meant site-to-site throughput.
• Publishing results without kernel version, region, and stream count.

FAQ

What throughput should I expect from WireGuard?

Enough to approach the lesser of: path capacity, instance NIC/cap, and CPU crypto budget. On small VPS plans, the plan cap usually wins. On large instances with good peering, multi-hundred Mbps to multi-Gbps is achievable—verify locally.

Is iperf3 enough?

For throughput and a first-pass congestion signal, yes. Add mtr for path diagnosis and application-level tests (clone a repo, transfer a known file) for UX validation.

Should I benchmark on Wi‑Fi?

Yes for employee experience. No as your only capacity number. Wi‑Fi variance will drown protocol differences.

Do I need dedicated benchmarking hosts?

For serious capacity planning, yes—two VMs with known sizes beat ad-hoc laptop tests. For a smoke test after deploy, a laptop is fine.

How often should I re-benchmark?

After instance resize, region change, major kernel updates, MTU policy changes, or when users report regressions. Not every day.

Can TunnelFleet help with this?

TunnelFleet focuses on provisioning and managing VPN servers on your cloud (DigitalOcean for automated provisioning today). You still run benchmarks with standard tools on the instances you own—the platform’s job is making those instances consistent and less manual to rebuild when you iterate on sizing.

Why is UDP iperf wildly different from TCP?

Different congestion control and loss behavior. Use UDP to study loss/jitter; use TCP for “how fast will scp/https feel” approximations.

Does keepalive affect benchmarks?

Keepalive maintains NAT mappings; it should not dominate throughput tests. If you see odd idle behavior, check keepalive and cloud firewall stateful timeouts separately from iperf runs.

Summary

Benchmark WireGuard by stating a clear question, baselining the bare path, measuring through tunnel IPs, watching CPU, and changing one variable at a time. Record region, instance size, MTU, and stream counts with every result. The goal is not a trophy number—it is a defensible capacity model for the VPN servers you operate.

If you want to automate VPN server deployment instead of configuring everything manually, TunnelFleet helps you provision and manage VPN infrastructure on your own cloud provider with minimal manual setup.