VPN throughput budget — accounting for the encryption cost in the firewall sizing

A firewall that delivers 1 Gbps of unencrypted traffic may deliver 200 Mbps of IPsec-encrypted traffic — or 100 Mbps if AES-NI is not enabled, or 10 Gbps if Intel QAT is available. The VPN throughput budget is the calculation that reconciles the deployment’s encryption needs with the firewall’s encryption capacity. Get it right and the firewall has plenty of headroom; get it wrong and the firewall is saturated the day the first tunnel goes up.

This lesson covers the encryption CPU cost for the algorithms OPNsense uses, the role of AES-NI and Intel QAT, the per-packet overhead, the effective throughput calculation, and the discipline of measuring the VPN throughput under the actual workload.

The encryption cost

Encryption is the dominant cost for VPN throughput. The algorithms and their CPU cost per core (modern x86, with AES-NI):

The numbers assume AES-NI is enabled. Without AES-NI, software AES is roughly 10x slower; the deployment sees throughput drop from 6 Gbps to 600 Mbps. The discipline: confirm AES-NI is enabled in the BIOS and exposed to FreeBSD.

# Confirm AES-NI is available.
sysctl -a | grep -i aes
# hw.ia32.crypt aesni: 1

# Confirm the aesni driver is loaded.
dmesg | grep -i aes
# aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-XTS> on motherboard

The per-packet overhead

Encrypted packets are larger than unencrypted packets. The overhead per packet:

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

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% 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% overhead. The operator who runs many small-packet flows over VPN sees the effective throughput drop dramatically.

Calculating the VPN throughput budget

The VPN throughput budget calculation:

vpn_throughput = min(encryption_throughput, link_throughput, packet_rate_throughput)

For a deployment with:

• AES-128-GCM with AES-NI: ~8 Gbps per core
• 4 cores: ~32 Gbps encryption capacity (with RSS)
• 1 Gbps WAN link: 1 Gbps link limit
• Many small packets: 1 Gbps link × (64 / 112) ≈ 570 Mbps effective

The binding constraint is the link, not the encryption. The firewall can encrypt faster than the link can carry.

For a deployment with:

• AES-128-CBC + HMAC-SHA256 (older IPsec configuration): ~2 Gbps per core
• 4 cores: ~8 Gbps encryption capacity
• 10 Gbps WAN link: 10 Gbps link limit

The binding constraint is the encryption. The firewall cannot encrypt fast enough for the link; effective throughput is ~8 Gbps, well below the 10 Gbps link.

The discipline: calculate the binding constraint for the deployment, not the theoretical maximum.

Intel QAT offload

Intel QuickAssist Technology (QAT) is a hardware accelerator that offloads cryptographic operations from the CPU. With QAT:

• Encryption throughput: 10-40 Gbps per QAT chip (depending on hardware generation).
• CPU usage: near-zero during encryption; the CPU is freed for other work.
• Latency: more predictable than software encryption.

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

# Confirm QAT is detected.
dmesg | grep -i qat
# qat0: <Intel QAT...> on pci0

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

Measuring VPN throughput

The discipline is to measure VPN throughput with iperf3 over the tunnel. The setup:

# 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.

The measurements to take:

1. AES-128-GCM with AES-NI. The modern standard.
2. AES-256-GCM with AES-NI. Slightly slower than AES-128; check if the deployment requires it.
3. ChaCha20 (WireGuard). The WireGuard default; faster on ARM, comparable on x86.
4. Without AES-NI (forced). The worst case; size for this if the deployment might run on hardware without AES-NI.

# Sample VPN throughput measurement table.
Configuration                              | Throughput
-------------------------------------------|------------
AES-128-GCM, AES-NI, 4 cores              | 3.2 Gbps
AES-256-GCM, AES-NI, 4 cores              | 2.8 Gbps
ChaCha20-Poly1305, 4 cores                 | 2.4 Gbps
AES-128-CBC + HMAC-SHA256, AES-NI, 4 cores| 1.2 Gbps
AES-GCM, no AES-NI, 4 cores               | 800 Mbps
AES-GCM, no AES-NI, 1 core                | 200 Mbps
With Intel QAT (single chip)               | 18 Gbps

The result is a table that says “firewall delivers X Gbps of VPN throughput with the chosen encryption”. The capacity plan uses this as the ceiling.

MTU and MSS clamping

VPN overhead 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 + inner IP)

If the path MTU is not respected, packets are fragmented or dropped. The discipline is to clamp the MSS for TCP connections inside the VPN:

# MSS clamping on firewall rules for VPN traffic.
# MSS = MTU - 40 (IP header + TCP header)
# For IPsec tunnel mode: 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.

Sizing for VPN headroom

The capacity plan for VPN works backwards from the application’s peak encrypted throughput, with headroom for:

• Growth. VPN usage grows. A firewall sized for today’s peak with no headroom is sized to fail.
• Burst. Real VPN traffic is bursty. Backup windows, business hours, scheduled transfers.
• HA failover. In an HA pair, one firewall carries 100% of the load when the other is down for maintenance.

The rule of thumb: size for 50% of peak. If the deployment needs 500 Mbps of peak VPN throughput, the firewall should be capable of 1 Gbps. The headroom absorbs growth, bursts, and HA failover.

Verification

After deploying the sized firewall, verify:

1. iperf3 over the tunnel at production load — must meet or exceed the target.
2. CPU usage at production load — must be below 70% on the busiest core (with AES-NI; without, expect high CPU).
3. QAT usage (if enabled) — must be below the accelerator’s capacity.
4. MTU black-hole test (large ping over the tunnel) — must succeed without fragmentation.
5. Behaviour under HA failover — the surviving firewall must carry the encrypted load.

A sizing exercise that meets 1-2 but fails 3-5 has throughput but loses packets; the sizing is wrong.