If you have the traffic (many streams) it should be possible, yes. First thing you can do (if you haven't yet) is move from AES-CBC + HMAC-SHA1 to AES-GCM on t

If you have the traffic (many streams) it should be possible, yes. First thing you can do (if you haven't yet) is move from AES-CBC + HMAC-SHA1 to AES-GCM on the P2s, otherwise you're limited to the throughput of SHA1 (AES-NI accelerates AES, but the SHA1 will hold you back. AES-GCM doesn't need the HMAC (it's an AEAD algorithm), so it's faster. In theory, with AES-NI and AES-GCM, you should be able to get 2gbps per core. In fact, we've proven with with a different packet processing architecture (which I'll get to below). Problem: the GCM implementation we did for FreeBSD is slower than that, because I took the decision that the ability to resist side-channel attacks was more important that ultimate speed. It's also limited to a single core. There is some recent work in pfSense to use > 1 core for the AES encryption. So the second thing you can do is set net.inet.ipsec.async_crypto=1 Details are in https://reviews.freebsd.org/D10680 https://reviews.freebsd.org/D10680 We've exposed a knob for this in pfSense 2.4.4 https://redmine.pfsense.org/issues/8772#change-37604 https://redmine.pfsense.org/issues/8772#change-37604 But after that, you're going to be out of gas. Kernel networking will only go so fast, and the FreeBSD IPsec stack / cryptdev and AES-GCM implementation are all straight-forward packet-at-a-time. The FreeBSD (and linux) kernel stack(s) are inherently packet-at-a-time. This tends to limit available throughput. We are adding support for QAT to pfSense in 2.4.4, so there should be some additional gain there, as well. That all said, it is possible to get to 10Gbps IPsec. We did some testing on a pair of i7-6950X boxes equipped with 40Gbps NICs. (Details cam be found in https://www.netgate.com/blog/building-a-behemoth-router.html https://www.netgate.com/blog/building-a-behemoth-router.html) and achieved the following results. Remember these are on linux and, where noted, VPP. Measurements were to/from two more Xeon boxes equipped with 40gbps NICs as well. Lite details in the slides / video linked below. - kernel, AES-NI, AES-CBC-128 + HMAC-SHA1, 1 SA, 1 stream: 2.09 Gbps. - kernel, AES-NI, AES-CBC-128 + HMAC-SHA1, 1 SA, 4 streams: 2.07 Gbps. - kernel, AES-NI, AES-CBC-128 + HMAC-SHA1, 8 SAs, 8 streams: 10.85 Gbps. - kernel, AES-NI, AES-GCM-128-16, 1 SA, 1 stream: 5.06 Gbps. - kernel, AES-NI, AES-GCM-128-16, 1 SA, 4 streams: 5.06 Gbps. - kernel, AES-NI, AES-GCM-128-16, 8 SAs, 8 streams: 25.25 Gbps. Note in both the above that using > 1 SA and > 1 'stream' (TCP flow) allows the traffic to be spread across the cores. Remember also that this is linux. FreeBSD isn't able to turn in this type of result. Then we tested with a CPIC (https://www.netgate.com/products/cpic-8955.html https://www.netgate.com/products/cpic-8955.html) QuickAssist card in the tunnel endpoints: - kernel, QAT, AES-CBC-128 + HMAC-SHA1, 1 SA, 1 stream: 8.74 Gbps. - kernel, QAT, AES-CBC-128 + HMAC-SHA1, 1 SA, 4 streams: 8.74 Gbps. - kernel, QAT, AES-CBC-128 + HMAC-SHA1, 8 SAs, 8 streams: 27.08 Gbps. Note that 8.74 Gbps is quite close the the maximum you'll get through a 10 Gbps NIC, once the framing and packet overheads are accounted for. But look what happens when we move the processing to userspace with VPP: - vpp, AES-NI, AES-CBC-128 + HMAC-SHA1, 1 SA, 1 stream: 7.42 Gbps. - vpp, AES-NI, AES-CBC-128 + HMAC-SHA1, 1 SA, 4 streams: 8.28 Gbps. - vpp, AES-NI, AES-GCM-128-16, 1 SA, 1 stream: 13.70 Gbps. - vpp, AES-NI, AES-GCM-128-16, 1 SA, 4 streams: 15.93 Gbps. And with hardware offload, we can get to the maximum possible throughput on a 40Gbps NIC: - vpp, QAT, AES-CBC-128 + HMAC-SHA1, 1 SA, 1 stream: 32.68 Gbps. - vpp, QAT, AES-CBC-128 + HMAC-SHA1, 1 SA, 4 streams: 35.72 Gbps. - vpp, QAT, AES-CBC-128 + HMAC-SHA1, 8 SAs, 8 streams: 36.32 Gbps. - vpp, QAT, AES-GCM-128-16, 1 SA, 1 stream: 32.73 Gbps. - vpp, QAT, AES-GCM-128-16, 1 SA, 4 stream: 32.98 Gbps. Note that this was all with an internal build of VPP (as used in our TNSR product) in April 2017. Things have progressed since then. I talked about this some in 2017. Video https://www.safaribooksonline.com/library/view/oscon-2017-/9781491976227/video306685.html https://www.safaribooksonline.com/library/view/oscon-2017-/9... Slides https://wiki.fd.io/view/File:40_Gbps_IPsec_on_commodity_hardware.pdf https://wiki.fd.io/view/File:40_Gbps_IPsec_on_commodity_hard... https://www.netgate.com/products/tnsr/ https://www.netgate.com/products/tnsr/