Cryptographic Accelerator Support

Cryptographic acceleration is available on some platforms, typically on hardware that has it available in the CPU like AES-NI, or built into the board such as the ones used on Netgate ARM-based systems. Most cryptographic accelerator hardware supported by FreeBSD will work, provided the drivers are in the kernel or available as loadable modules.


Some modules and hardware are only supported by pfSense Plus software.

Supported Devices

Currently supported cryptographic accelerator devices include:


Supported natively by most modern CPUs.

Intel QuickAssist Technology (QAT) [Plus only]

Supported on certain Intel-based platforms such as select models of c3000 and c2000 SoCs, and also by QAT add-on cards. Present on several Netgate hardware models such as the 7100, 6100, 5100, and more.

CESA [Plus only]

Present on some ARM platforms such as the Netgate 3100.

SafeXcel [Plus only]

Present on some ARM platforms such as the Netgate 2100 and 1100.


For specifics on which hardware accelerators are available on Netgate hardware, and relevant performance data, visit the Netgate Store.

Activating the Hardware

Some hardware acceleration is active at all times and there is no way to disable it short of removing the crypto card if it is a hardware add-on. For example, CESA acceleration cannot be disabled because it’s an integrated feature of the system and the drivers are present the kernel.

Others, such as QAT, AES-NI, or SafeXcel require choosing the appropriate module under System > Advanced on the Miscellaneous tab. Choose the appropriate module to match the hardware for Cryptographic Hardware and then Save. The module will be loaded and available immediately.

To deactivate a loaded module, select None for Cryptographic Hardware, Save, and then reboot the system.

Confirming Accelerator Use

Confirming that the cryptographic acceleration device is being used by the firewall can be tricky, depending on the hardware in question.

Most often the evidence of cryptographic accelerator use is apparent in one or more of the following observations:

  • Increased VPN throughput

  • Decreased system load (e.g. CPU utilization) for similar levels of VPN throughput

In cases where it is not clear, some cryptographic accelerators show signs of use by checking for interrupt activity on the device using vmstat -i | grep <name>, where <name> corresponds to the name of the device:


Use the shell command vmstat -i | grep qat


Use the shell command vmstat -i | grep cesa


Use the shell command vmstat -i | grep safexcel

In each of these cases, first check that there is any output at all. If the device has not been used at all since the firewall last rebooted or loaded the device driver, there will be no output from the command.


To see if the driver is loaded, check kldstat -v | grep <name> to ensure the driver is present, and check dmesg | grep <name> to see if the device was detected.

If there is output from vmstat -i for the device, check the third entry on the line, which is the total number of interrupts observed on the device(s). If this number is increasing with VPN activity, the device is being used by the firewall. For example:

# vmstat -i | grep qat
irq300: qat0                     5481147          3

In that output the 5481147 number represents the number of interrupts on the qat0 device. Run the command again after transferring data across the VPN, and compare the number.


If the command produces no output at all, the device is not being used or the device driver is not loaded.

Verifying Cipher Support

To see a list of engines and associated transforms supported by the hardware and active modules though OpenSSL, run:

/usr/bin/openssl engine -t -c


That is only for support via OpenSSL. Other areas such as IPsec may support additional methods not listed.

Practical Use


IPsec will take advantage of acceleration automatically when an active accelerator supports the cipher chosen for a tunnel. For QAT and AES-NI, the optimal cipher choice is AES-GCM.


To take advantage of acceleration in OpenVPN, choose a supported cipher on each end of a given tunnel.

Nothing needs selected for OpenVPN to utilize AES-NI. The OpenSSL engine has its own code for handling AES-NI that works well without using additional modules.