Because OpenVPN uses tun/tap, and there is a HUGE amount of overhead in that.
“HUUUUUGGGEEE!” — Donald J. Trump
The statement "On a modern intel system, the intel chip itself (or AMD) has
AES128 or better implemented in hardware. “ is incorrect. Modern Intel / AMD
parts have instructions that can accelerate the AES algorithm.
• AESENC. This instruction performs a single round of encryption. The
instruction combines the four steps of the AES algorithm - ShiftRows, SubBytes,
MixColumns & AddRoundKey into a single instruction.
• AESENCLAST. Instruction for the last round of encryption. Combines
the ShiftRows, SubBytes, & AddRoundKey steps into one instruction.
• AESDEC. Instruction for a single round of decryption. This combines
the four steps of AES - InvShiftRows, InvSubBytes, InvMixColumns, AddRoundKey
into a single instruction
• AESDECLAST. Performs last round of decryption. It combines
InvShiftRows, InvSubBytes, AddRoundKey into one instruction.
• AESKEYGENASSIST is used for generating the round keys used for
encryption.
• AESIMC is used for converting the encryption round keys to a form
usable for decryption using the Equivalent Inverse Cipher.
• PCLMULQDQ is used for carryless multiply (CLMUL), which is used in
AES-GCM.
The other issue is that encryption without a HMAC is all but worthless. (It
increases privacy, but not security.) Typically the HMAC involves an entire
second pass over the packet, and this isn’t accelerated. Very new Intel CPUs
have some acceleration support for SHA (SHA1, SHA256, etc), but it’s not
anything like hardware offload.
This is why AEAD modes (such as AES-GCM) exist, and why we added support for
AES-GCM to IPsec for FreeBSD. OpenVPN is supposed to get support for AEAD
(GCM) in OpenVPN 2.4.
But that’s not going to solve the issue with the overhead of tun/tap. That’s
going to take actual work, putting OpenVPN over netmap, or DPDK, or something
like that.
Versus AES-NI, actual hardware offload, using something like Intel QuickAssist,
is much (much) faster. We’ve run nearly 20Gbps using a CPIC card. This tweet
says “10Gbps”, but using two tunnels, we got it to 17Gbps
https://twitter.com/gonzopancho/status/703677820694720512 with an otherwise
unmodified system. That was AES-CBC-128 + HMAC-SHA1, IIRC. Yes, QAT will
accelerate SHA. That’s not going to happen on FreeBSD without a lot of work,
because the IPsec stack on FreeBSD needs….. a lot of work. (It’s a bit of a
hot mess, see upcoming BSDcan talk.
http://www.bsdcan.org/2016/schedule/events/727.en.html)
net-net: we accelerated IPsec using AES-GCM (leveraging AES-NI) first, because
that was going to be the most benefit.
Jim
(Yes, we tried OpenVPN with QAT, tun/tap is the blocker here. See above, or my
repeated statements on this list, the forum, and elsewhere.)
> On Apr 29, 2016, at 1:10 PM, Olivier Mascia <[email protected]> wrote:
>
> Indeed.
> Why didn't the OpenVPN tunnel show me that level of perf, despite settings
> for using hardware acceleration, is another story, but I'm happy with the
> IPsec results and will stick to that on this link.
>
> Thanks for having confirmed me I hadn't fallen in a rabbit hole.
> :)
>
> --
> Meilleures salutations, Met vriendelijke groeten, Best Regards,
> Olivier Mascia, integral.be/om
>
>> Le 29 avr. 2016 à 19:58, ED Fochler <[email protected]> a écrit :
>>
>> On a modern intel system, the intel chip itself (or AMD) has AES128 or
>> better implemented in hardware. I get ~700Mb on sftp on my macbook air 2012
>> like that, so those numbers are exactly where I’d expect the CPU to be maxed
>> out doing AES128 or AES256 encryption. That’s what hardware acceleration
>> feels like. You should see the CPU (or one core at least) on the IPSec
>> tunnel ends being fully occupied at that throughput.
>>
>> ED.
>>
>>
>>> On 2016, Apr 29, at 1:52 PM, Olivier Mascia <[email protected]> wrote:
>>>
>>> Seeing throughput I did not expected with an IPsec tunnel compared to what
>>> I was seeing using OpenVPN (which I always used up to the perf discrepancy
>>> I discovered today on a new link), I wonder if it really encrypts anything.
>>>
>>> Phase 1 is set for AES256, SHA256 DH group 2.
>>> Phase 2 is set for ESP AES256-GCM 128 bits and SHA256.
>>>
>>> No other encryption / hash is checked as alternatives on Phase 2.
>>>
>>> I'd say I'm good to go that way, but I'm driving between 500 and 750 Mbps
>>> through the tunnel (transfer rate of ~45 to ~80 MB/sec in Windows File
>>> explorer between filesystems on each side of the tunnel), and I quite
>>> couldn't believe it.
>>>
>>> Could something be wrong?
>>>
>>> --
>>> Meilleures salutations, Met vriendelijke groeten, Best Regards,
>>> Olivier Mascia, integral.be/om
>>>
>>>
>>> _______________________________________________
>>> pfSense mailing list
>>> https://lists.pfsense.org/mailman/listinfo/list
>>> Support the project with Gold! https://pfsense.org/gold
>>
>> _______________________________________________
>> pfSense mailing list
>> https://lists.pfsense.org/mailman/listinfo/list
>> Support the project with Gold! https://pfsense.org/gold
>
>
> _______________________________________________
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
