VPN performance and crypto offload — what determines how fast the tunnel goes

VPNs add two costs beyond plain packet forwarding: encryption and overhead. The encryption CPU cost can dominate the firewall’s CPU budget on a busy tunnel; the overhead reduces the effective bandwidth by 5 to 15 percent. An operator who designs for VPN performance must understand both costs, know how to enable cryptographic offload (AES-NI and Intel QAT), and measure the actual throughput before the user reports a slowdown.

This lesson covers the encryption algorithms used by IPsec and WireGuard, the role of hardware offload, the overhead calculation, and the discipline of measuring real VPN throughput.

The two VPN stacks on OPNsense

OPNsense supports two VPN stacks commonly used in production:

• IPsec (via the strongSwan plugin) — the IETF-standard VPN suite with IKEv2 key exchange and ESP for encryption. Used for site-to-site tunnels and remote access (with or without client software). Mature, interoperable with most vendors, but complex configuration.
• WireGuard (via the os-wireguard plugin) — a modern, simpler VPN using Curve25519 for key exchange and ChaCha20 for encryption. Used for site-to-site and remote access. Newer, simpler, faster in software, but fewer enterprise features.

Both can carry significant traffic; both are CPU-bound by their encryption work. The throughput difference between them in software is small; the difference with hardware offload is large.

The encryption CPU cost

Encryption cost depends on the algorithm and the key size. For symmetric encryption:

The numbers assume AES-NI is enabled in the CPU. Without AES-NI, software AES is roughly 10× slower (300 to 600 Mbps per core) — a modern CPU without AES-NI may not even have the instruction set.

The per-packet CPU cost of encryption:

• AES-GCM is an authenticated encryption mode that produces ciphertext and an authentication tag in one pass. Hardware AES-NI accelerates it to near wire-rate.
• AES-CBC + HMAC is older; it requires two separate cryptographic operations (encryption and authentication). It is significantly slower than AES-GCM.
• ChaCha20-Poly1305 is the modern alternative for CPUs without AES-NI; it is fast in software and the preferred default for WireGuard.

The discipline: configure IPsec with AES-GCM (not AES-CBC + HMAC), use 128-bit keys (not 256-bit unless required), and confirm AES-NI is enabled in the BIOS and exposed to FreeBSD.

Confirming AES-NI is available

The operator can confirm AES-NI is active:

$ sysctl -a | grep -i aes; echo '---'; dmesg | grep -i aes

hw.ia32.crypt aesni: 1
---
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS> on motherboard

The discipline:

• Modern server CPUs (Intel Xeon, AMD EPYC) all have AES-NI. Confirm in dmesg after boot.
• Some hypervisors do not expose AES-NI to VMs. Check the hypervisor settings; enable “expose hardware-assisted AES” or equivalent.
• Some low-power CPUs do not have AES-NI. ARM-based firewalls may use ChaCha20 instead; WireGuard handles this transparently.

Intel QAT and hardware crypto offload

Beyond AES-NI (which accelerates AES on the general-purpose CPU), some Intel server CPUs and NICs have a QuickAssist Technology (QAT) chip that offloads cryptographic operations entirely. QAT can process encryption at multi-Gbps rates with minimal CPU usage.

OPNsense’s IPsec implementation (strongSwan) can use QAT via the qat driver and the intel-qat kernel module. The configuration is non-trivial; the operator should consult the OPNsense documentation and confirm the QAT hardware is detected.

The benefits:

• CPU offload. Encryption no longer consumes the general-purpose CPU.
• Higher throughput. QAT can sustain 10 to 40 Gbps of encrypted traffic depending on the hardware generation.
• Lower latency. Hardware offload has more predictable latency than software.

The discipline: enable QAT if the hardware supports it and the deployment requires sustained high-throughput VPN. For smaller deployments, AES-NI alone is sufficient.

The overhead calculation

Encrypted packets have more overhead than unencrypted packets. The total overhead per packet:

• IPsec ESP (transport mode): 4-byte ESP header + 16-byte ICV (GCM tag) + 8-byte ESP trailer = ~28 bytes per packet. Plus 20-byte outer IP header.
• IPsec ESP (tunnel mode): same as transport + 20-byte inner IP header = ~48 bytes per packet.
• WireGuard: 32-byte header + 16-byte Poly1305 tag = ~48 bytes per packet.

For a typical 1500-byte IP packet in tunnel mode:

Original: 1500 bytes payload + 20 IP = 1520 IP packet
ESP:      1520 + 48 overhead = 1568 bytes on the wire
WireGuard: 1520 + 48 overhead = 1568 bytes on the wire

The effective throughput ratio:

effective ≈ line-rate × (payload / (payload + overhead))
        ≈ 1 Gbps × (1500 / 1568)
        ≈ 957 Mbps

The overhead is small — about 4 percent for typical packets. The bigger problem is when packets are small; a 64-byte payload with 48 bytes of overhead is 112 bytes on the wire — a 75 percent overhead. The operator who runs many small-packet flows over VPN sees the effective throughput drop dramatically.

MTU and MSS clamping

VPN overhead also affects MTU. The IP packet inside the tunnel can be at most (path MTU) - (VPN overhead) without fragmentation. For a typical Ethernet path MTU of 1500:

Tunnel MTU = 1500 - 48 = 1452 bytes

For IPsec tunnel mode with IP header overhead:

Inside MTU = 1452 - 20 = 1432 bytes (for the TCP MSS)

If the path MTU is not respected, the firewall or the destination host will fragment the packet — a costly operation that breaks performance. The discipline is to clamp the MSS (Maximum Segment Size) for TCP connections inside the VPN to avoid fragmentation:

# Firewall rule on the VPN traffic:
# Set MSS to MTU - 40 (IP header + TCP header) - VPN overhead
# For IPsec tunnel mode with default overhead: MSS = 1452 - 40 = 1412

OPNsense exposes MSS clamping in the firewall rule advanced options. The operator should configure it for every VPN that carries TCP traffic.

$ tcpdump -ni igb0 'ip proto 50' -c 2

12:34:56.789012 192.0.2.1 > 203.0.113.50: ESP(spi=0xc0ffee00,seq=42), length 1568
12:34:56.789345 203.0.113.50 > 192.0.2.1: ESP(spi=0xc0ffee01,seq=87), length 128

Measuring VPN throughput

The discipline is to measure VPN throughput with iperf3 over the tunnel. From a host behind one side of the VPN to a host behind the other:

# Substitute your own values before running:
# Private address of the iperf3 server at the far end of the tunnel
REMOTE_IPERF_SERVER=198.51.100.10

# On the iperf3 server (behind one end of the tunnel):
iperf3 -s

# From the iperf3 client (behind the other end):
iperf3 -c "$REMOTE_IPERF_SERVER" -t 60 -P 4

The result is the encrypted throughput through the firewall. A typical 1 Gbps link with AES-128-GCM and AES-NI delivers 800 to 950 Mbps through the tunnel — close to the line rate minus overhead. Without AES-NI, the same link may deliver only 100 to 200 Mbps.

The operator should:

• Measure once during initial deployment (baseline).
• Re-measure after any CPU upgrade, BIOS change, or OPNsense upgrade.
• Re-measure if users report VPN slowness.

Summary

• IPsec and WireGuard are the two main VPN stacks on OPNsense; both are CPU-bound by encryption.
• AES-GCM with AES-NI delivers near-line-rate throughput; AES-CBC + HMAC is significantly slower.
• Intel QAT offloads encryption entirely; useful for sustained high-throughput VPN tunnels.
• VPN overhead is ~48 bytes per packet; the effective throughput ratio is approximately 1 - (overhead / payload).
• MSS clamping avoids fragmentation inside the tunnel; configure it for every VPN that carries TCP.
• Measure VPN throughput with iperf3 over the tunnel; re-measure after any change.