Learn WireGuard - Performance & Kernel Optimizations
Episode 15 of 23

Learn WireGuard - Performance & Kernel Optimizations

This episode covers WireGuard performance and kernel optimizations: the advantage of running in kernel-space, multiqueue TUN, GRO and GSO offloading, throughput and latency benchmarking with iperf3, and a comparison of WireGuard with OpenVPN and IPsec.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Introduction

One of the reasons WireGuard is popular is its speed. Running in kernel-space and using modern cryptography that can be hardware-accelerated makes it far faster than userspace VPNs like OpenVPN. But that speed is not automatic — it needs measurement and a little tuning to be optimal.

Episode 15 covers the foundations of WireGuard performance, the optimizations available in the kernel, how to measure with iperf3, and where WireGuard stands compared with OpenVPN and IPsec.

Why WireGuard Is Fast

Kernel-Space and Multiqueue

WireGuard processes packets inside the kernel, so there is no context switch between the kernel and a userspace process for each packet. The wg0 interface also supports multiqueue: parallel queues that allow several CPUs to process packets simultaneously, which greatly helps on machines with many cores.

Check the number of wg0 interface queues
ip link show wg0

On large systems, you can also increase the number of interface queues when creating it, to align with the number of CPUs:

Create wg0 with many queues
sudo ip link add dev wg0 type wireguard
sudo ethtool -l wg0

GRO and GSO Offloading

The kernel can merge small packets into larger ones before processing and split them again when sending — this is GRO and GSO. Merging reduces per-packet overhead and increases throughput:

Check offload status on the NIC
ethtool -k eth0 | grep -E "generic-receive-offload|generic-segmentation-offload"

Modern NICs also provide checksum offloading that lightens the CPU load. The combination of GRO, GSO, and checksum offloading is usually active by default.

Measuring with iperf3

Measuring Throughput

To measure the tunnel's maximum speed, run an iperf3 server on one side and a client on the other side over the tunnel address:

iperf3 server on one side
iperf3 -s
iperf3 client on the other side
iperf3 -c 10.0.0.1 -t 20

The 20 in iperf3 -c 10.0.0.1 -t 20 means the measurement runs for 20 seconds. Compare the result with a measurement without the tunnel (directly to the public address) to learn WireGuard's overhead. Normal overhead is in the range of a few percent.

Measuring Latency

Latency is measured with ping over the tunnel address:

Measure RTT through the tunnel
ping -c 20 10.0.0.1

Watch the average RTT and the minimum value. Tunnel RTT is always slightly above direct RTT due to encryption overhead, but the difference should be small and stable.

MTU and Tuning

Why MTU 1420

wg-quick uses MTU 1420 by default for IPv4. This number comes from the standard 1500 MTU minus WireGuard's 80 bytes of encapsulation overhead. If your physical link has a smaller MTU, the tunnel needs a smaller MTU too:

Set MTU in wg0.conf
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <kunci privat>
MTU = 1360

MTU = 1360 is used for PPPoE links, which usually only carry 1492 bytes. Too large an MTU triggers fragmentation and a drastic throughput drop.

Testing MTU with Ping

Find the ideal MTU with a no-fragment ping:

Test the maximum payload
ping -M do -s 1400 -c 3 10.0.0.1

If ping -M do -s 1400 succeeds but 1500 fails, the MTU limit lies between the two, and the tunnel MTU must be reduced.

Comparison with OpenVPN and IPsec

Common Field Results

Consistently across various public benchmarks, WireGuard wins in throughput on the same hardware because it runs in kernel-space and uses lightweight cryptography. OpenVPN, running in userspace, is usually slower, especially on a single core. IPsec can match WireGuard, but with far higher configuration complexity.

For your own needs, the exact numbers depend heavily on CPU, NIC, and kernel version. Always measure in your own environment before choosing — one iperf3 run gives a more convincing answer than claims on the internet.

Closing

Episode 15 completed the performance topic: the advantages of kernel-space and multiqueue, the role of GRO and GSO, measurement with iperf3, MTU tuning, and where WireGuard stands in comparison with OpenVPN and IPsec.

Key takeaways:

  • WireGuard processes packets in kernel-space without a per-packet context switch.
  • Multiqueue TUN leverages multiple CPUs.
  • GRO and GSO merge packets for higher throughput.
  • iperf3 -c <tunnel-address> -t 20 measures real throughput.
  • MTU 1420 is the default; reduce it for PPPoE links.
  • Always measure in your own environment before comparing protocols.

In episode 16 we cover cross-platform and mobile — WireGuard-Go as the userspace implementation, WireGuardNT for Windows, Android and iOS apps with QR code configuration import, and battery optimizations for mobile devices.

Learn WireGuard - Performance & Kernel Optimizations | Learn WireGuard