Crypto Card for a VPN Gateway: Four Handoffs Before Buying

Old cryptographic accelerators show up in the PCI inventory, and the assumption is that the VPN will now encrypt faster. Four separate handoffs must succeed before that is true: the system finds the device, a maintained driver drives it, an interface exposes the operation the VPN needs, and the VPN's active backend asks for it. Any one failing leaves the card outside the tunnel's real path.

Detection is the first handoff, not the last

Detection proves only that the bus sees a device and the kernel has some idea what it is. Driver support is the next gate, and it is version-specific: a module present in an old release may be missing from the current kernel package entirely. Beyond that, the driver has to register the specific algorithm and mode the data channel uses. A card that accelerates AES-CBC does nothing for a configuration negotiating AES-GCM.

Name each handoff separately in the evaluation, because a failure at the fourth looks identical to a failure at the first from the outside.

Read the kernel's algorithm inventory

Start by collecting what the host already knows about the device and the algorithms it registered.

lspci -nn | grep -i -E "crypt|hifn|soekris"
grep -E "^(name|driver|priority)" /proc/crypto | head -40

The PCI line gives the vendor and device identifiers needed for any driver search, and /proc/crypto lists registered implementations with their drivers and priorities. A priority value orders selection among implementations of the same algorithm, which is not the same as an application choosing one. If the card's algorithm does not appear there, the driver never registered it and no userspace change will call it. Record the identifiers and implementation names rather than a screenshot of the card.

The VPN must select that implementation

Kernel availability is a menu, not a guarantee that the VPN process ordered from it. Check what the backend actually uses.

openssl speed -evp aes-256-gcm
openssl engine -t -c

The speed command exercises the library's own path and gives a baseline for the machine as configured, while the engine listing shows whether any optional provider is available to OpenSSL at all. A userspace VPN using its own crypto library bypasses kernel implementations completely, so a registered driver can be irrelevant to it. Data-channel offload is a third mechanism again, changing packet processing rather than dispatching cipher requests to an expansion card. Establish which of those three describes your deployment before buying hardware for the fourth.

Compare against the CPU path you already have

Modern processors include AES instructions that a maintained library uses without extra hardware, and they avoid bus transfers and extra copies. An old accelerator can lose to that path while still reporting impressive raw cipher numbers. Measure the real workload: same traffic, same protection settings, baseline versus candidate, with CPU load and application throughput recorded together. Include update and recovery behaviour in the decision, because an unmaintained module raises the gateway's maintenance risk for its whole life.

The purchase case is a supported chain plus a measured benefit. A detected card, or a module someone once compiled, is not a reason to make a maintained gateway depend on obsolete hardware.