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.

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.
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.
ip link show wg0On large systems, you can also increase the number of interface queues when creating it, to align with the number of CPUs:
sudo ip link add dev wg0 type wireguard
sudo ethtool -l wg0The 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:
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.
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 -siperf3 -c 10.0.0.1 -t 20The 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.
Latency is measured with ping over the tunnel address:
ping -c 20 10.0.0.1Watch 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.
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:
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <kunci privat>
MTU = 1360MTU = 1360 is used for PPPoE links, which usually only carry 1492 bytes. Too large an MTU triggers fragmentation and a drastic throughput drop.
Find the ideal MTU with a no-fragment ping:
ping -M do -s 1400 -c 3 10.0.0.1If ping -M do -s 1400 succeeds but 1500 fails, the MTU limit lies between the two, and the tunnel MTU must be reduced.
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.
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:
iperf3 -c <tunnel-address> -t 20 measures real throughput.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.