How to Implement Linux IPsec ESP (Encapsulating Security Payload) Offload for Hardware Crypto Acceleration

Establishing secure, encrypted site-to-site VPN tunnels using IPsec is foundational to enterprise networking. However, IPsec relies heavily on the Encapsulating Security Payload (ESP) protocol to encrypt and decrypt every single packet traversing the tunnel (typically using AES-GCM or AES-CBC). At speeds of 10 Gbps or higher, the mathematical overhead of AES cryptography will completely saturate modern CPU cores, turning the hypervisor or Linux router itself into the network bottleneck.

To achieve wire-speed IPsec without destroying CPU performance, Linux administrators must implement Hardware ESP Offload. This technology allows the Linux kernel to instruct the physical Network Interface Card (NIC) to perform the AES encryption and decryption directly on the networking silicon, entirely freeing up the CPU.

This guide explains the architecture of the Linux XFRM framework and how to configure strongSwan to offload IPsec ESP to compatible hardware.

Understanding IPsec ESP Offload Architecture

The Linux IPsec stack is managed by the XFRM (Transform) framework within the kernel. When strongSwan negotiates an IPsec Security Association (SA) with a remote peer via IKEv2, it passes the resulting cryptographic keys down to the XFRM subsystem in the kernel.

Normally, when a packet needs to be encrypted, XFRM uses the kernel’s software crypto API to process the payload.

When Hardware Offload is enabled:

1. strongSwan instructs the kernel to offload the specific SA to the hardware.
2. The kernel passes the AES encryption keys down to the NIC driver (e.g., the Intel ixgbe or Mellanox mlx5 driver).
3. When a plain-text packet is routed to the VPN interface, the kernel simply prepends the IPsec headers and sends the unencrypted packet to the NIC.
4. The NIC silicon encrypts the packet in-line just before placing it on the wire.
5. Conversely, for incoming traffic, the NIC decrypts the packet in hardware, verifies the ESP sequence number, and passes plain-text traffic up to the kernel.

Prerequisites for ESP Offload

You cannot offload IPsec arbitrarily; it requires strict hardware and software alignment:

• Hardware: A NIC that explicitly supports IPsec inline crypto offload (e.g., Mellanox ConnectX-6 Dx, Intel E810).
• Kernel: Linux Kernel 4.20 or newer (modern kernels are highly recommended).
• Software: strongSwan 5.8.1 or newer, compiled with the kernel-netlink plugin.

To verify if your specific network interface (e.g., eth0) supports ESP offload, use the ethtool command:

ethtool -k eth0 | grep esp

You should see output indicating that esp-hw-offload is enabled:

esp-hw-offload: on
esp-tx-csum-hw-offload: on

Step 1: Configuring strongSwan (swanctl.conf)

The modern configuration syntax for strongSwan uses the VICI plugin and the swanctl.conf file, rather than the legacy ipsec.conf.

Open your strongSwan configuration file:

sudo nano /etc/swanctl/swanctl.conf

Define your site-to-site connection. The critical parameter for hardware acceleration is hw_offload = yes inside the children section (which defines the ESP IPsec SA).

connections {
    site-to-site-aws {
        local_addrs  = 198.51.100.10
        remote_addrs = 203.0.113.50
        
        local {
            auth = psk
            id = 198.51.100.10
        }
        remote {
            auth = psk
            id = 203.0.113.50
        }
        
        children {
            vpc-subnet {
                local_ts  = 10.0.0.0/24
                remote_ts = 172.16.0.0/16
                
                # ENFORCE HARDWARE ESP OFFLOAD
                hw_offload = yes
                
                esp_proposals = aes256gcm128-modp2048
            }
        }
        version = 2
    }
}

Note: Hardware offload generally only supports AEAD ciphers (like AES-GCM). Using legacy ciphers like AES-CBC + SHA256 will often cause the offload request to fail and fallback to software.

Step 2: Reloading the strongSwan Daemon

Load the new configuration into the strongSwan daemon via the swanctl tool:

sudo swanctl --load-all

Initiate the IPsec connection to the remote peer:

sudo swanctl --initiate --child vpc-subnet

Step 3: Verifying Hardware Offload in the Kernel

It is vital to confirm that the offload actually succeeded. If strongSwan requests offload but the kernel or driver rejects it (e.g., due to an unsupported cipher), strongSwan will silently fall back to software encryption.

You must query the Linux kernel’s XFRM state directly using the ip command:

ip xfrm state

Examine the output for the active Security Associations. You are looking for a specific flag injected by the driver.

src 198.51.100.10 dst 203.0.113.50
    proto esp spi 0xc0a80101 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    aead rfc4106(gcm(aes)) 0x1122334455667788112233445566778811223344 128
    anti-replay context: seq 0x0, oseq 0x1, bitmap 0x00000000
    crypto offload parameters: dev eth0 dir out

The presence of crypto offload parameters: dev eth0 dir out is the absolute proof that the kernel has successfully handed the cryptographic keys to the physical silicon on eth0.

Conclusion

Software-based IPsec is an unacceptable bottleneck in 10G+ datacenter environments. By aligning compatible NIC hardware with the Linux XFRM subsystem and enforcing the hw_offload parameter in strongSwan, network engineers can achieve zero-CPU-overhead, wire-speed encryption, radically increasing VPN throughput and liberating server resources for application workloads.