Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Pfsense+Proxmox+AMD Ryzen+AES-NI

    Scheduled Pinned Locked Moved Russian
    20 Posts 4 Posters 24.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P Offline
      pigbrother
      last edited by

      Ес-но, потому что у него Intel. Об этом он и указал ранее.
      Как раз выбор RDRAND и не кажется естественным.
      Почему RDRAND, не имеющий отношения к шифорованию AES, а не BSD cryptodev engine?

      Официальный мануал, хотя, похоже, несколько устаревший:
      https://doc.pfsense.org/index.php/Are_cryptographic_accelerators_supported#OpenVPN

      Тут разработчики вообще советуют не включать поддержку:

      https://www.reddit.com/r/PFSENSE/comments/5lric3/aesni_not_selectable_in_24_beta/
      https://www.reddit.com/r/PFSENSE/comments/5nnwzy/openvpn_throughput_question/

      [–]jim-p 2 points 9 months ago

      OpenVPN will use what it can find automatically.

      Only AES-GCM will be accelerated with OpenVPN 2.4 and the AES-NI module loaded, so you might want to unload that so OpenVPN/OpenSSL can use AES-NI directly.

      [–]jim-p 2 points 9 months ago

      So unload aes-ni.

      It should not be loaded as the same time as the BSD cryptodev engine.

      Правда информация могла и устареть.

      Можно же и проверить (имея гигабитную сеть), создав на LAN openvpn-сервер и потестить, пользуя iperf\jperf.
      Непременно, но сейчас такой возможности нет.

      1 Reply Last reply Reply Quote 0
      • werterW Offline
        werter
        last edited by

        Немного по AES + HMAC

        https://www.reddit.com/r/PFSENSE/comments/5l45jk/openvpn_240_is_now_available_on_pfsense_24/

        OpenVPN 2.4 ignores the auth directive when using AES-GCM so it doesn't matter what you choose there, actually. That's handy, it prevents accidentally hobbling the setting.

        Choose AES-NI in misc, then select "Intel RDRAND engine (RAND)" at the OpenVPN client editor. If you can select AES-NI, you should be good to go for hardware accel. You can push data directly to your CPU over virtualization with modern CPUs, so your environment should support it.

        https://www.mail-archive.com/list@lists.pfsense.org/msg09463.html

        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.

        https://forum.pfsense.org/index.php?topic=107329.0

        AES-CBCis accelerated by AES-NI.  The issue is that the HMAC is not.  This is one of the two reasons why AES-GCM is faster.

        1 Reply Last reply Reply Quote 0
        • P Offline
          pigbrother
          last edited by

          Хороший конспект, свели многое, что читал и сам в единый список.

          Придется считать, что выбор rdrand для поддержки AES-NI - это багофича особенность реализации.
          И да, у вас с Ryzen rdrand выбрать возможно?

          1 Reply Last reply Reply Quote 0
          • P Offline
            pigbrother
            last edited by

            Bug #7810
            openssl/openvpn need to have loaded booth AESNI and cryptodev to accelerate AES operations , but gui alows you load only one at once
            Будет исправлено в 2.4.1
            https://redmine.pfsense.org/issues/7810

            https://doc.pfsense.org/index.php/2.4.1_New_Features_and_Changes

            1 Reply Last reply Reply Quote 0
            • G Offline
              Gektor
              last edited by

              Несколько недель сам разбирался с OpenVPN и аппаратным шифрованием, в версии 2.4.0 (и девелоп 2.4.2а) AES-NI вкл/вкл в настройках PFSense практически никак не влияют на результаты работы / тестов OpenVPN, т.к. если есть AES-NI, то он используется автоматически.
              Для CPU intel лучше использовать GCM шифрование в виду большей оптимизации процессора под этот алгоритм, RDRAND не имеет никакого отношения к AMD процессорам, это алгоритм аппараттной генерации рандомных чисел от интел начиная с процессоров Ivy Bridge. В некоторых сценариях шифрования незначительно повышает производительность на процессорах Intel.

              Для сравнения (процессор Celeron 3865U 2x1.8 ГГц):
              openssl speed -elapsed -evp aes-256-cbc
              type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes
              aes-256-cbc    443432.92k  472857.02k  477686.25k  482970.28k  483590.14k

              openssl speed -elapsed -evp aes-256-gcm
              type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes
              aes-256-gcm    293267.67k  786376.13k  1204654.15k  1294190.33k  1331465.46k

              На GCM разница с CBC колоссальная.

              На практике при шифровании 256-GCM скорость туннеля на данном процессоре порядка 50 МБ/с (до 500 мбит).

              Для AMD не могу знать, т.к. нет под руками ничего современно-толкового.

              1 Reply Last reply Reply Quote 0
              • P Offline
                pigbrother
                last edited by

                На GCM разница с CBC колоссальная

                Однако минус в том, что многие "железные" клиентские устройства c OpenVPN о GCM понятия не имеют.

                Можно ли спросить на каких настойках остановились? Чтоиз crypto  выбрано в настройках собственно сервера OpenVPN?

                1 Reply Last reply Reply Quote 0
                • G Offline
                  Gektor
                  last edited by

                  У меня установлено Intel RDRAND Engine, хотя что с ним что без него - практически никакой разницы… AES-NI работает по умолчанию.

                  1 Reply Last reply Reply Quote 0
                  • P Offline
                    pigbrother
                    last edited by

                    А каков реальный выигрыш, не в тестах openssl speed, а  в Open VPN? Болше скорости? Меньше загрузка CPU?

                    1 Reply Last reply Reply Quote 0
                    • G Offline
                      Gektor
                      last edited by

                      Больше скорость канала и меньше нагрузка на процессор — без оптимизации загрузка процессора под 90% и скорость до 100 мбит, с оптимизацией загрузка процессора менее 50% скорость до 500 мбит.

                      Есть понятие аппаратная оптимизация и если софт оптимизирован под железо, то на относительно дешевом железе можно получить приличные результаты.

                      1 Reply Last reply Reply Quote 0
                      • P Offline
                        pigbrother
                        last edited by

                        Спасибо.

                        Это цифры с AES-GCM?
                        Если да - то каковы будут результаты с AES-CBC?

                        1 Reply Last reply Reply Quote 0
                        • G Offline
                          Gektor
                          last edited by

                          Это с GCM, CBC точно не помню, но по-моему около 300 мбит было. Загрузку процессора при CBC не помню.

                          1 Reply Last reply Reply Quote 0
                          • G Offline
                            Gektor
                            last edited by

                            Еще немного синтетики на Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (pfSense 2.4.0 отдано 1 ядро под Hyper-V 2016):
                            openssl speed -elapsed aes-256-cbc
                            type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes
                            aes-256 cbc    104734.30k  107559.70k  108202.41k  254901.25k  258236.42k

                            openssl speed -elapsed -evp aes-256-cbc
                            type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes
                            aes-256-cbc    550018.00k  585781.97k  597035.43k  603340.80k  604815.36k

                            openssl speed -elapsed -evp aes-256-gcm
                            type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes
                            aes-256-gcm    383488.66k  940133.85k  2013853.10k  2815626.58k  3424714.75k

                            GCM на интел однозначно рулит )))

                            1 Reply Last reply Reply Quote 0
                            • A Offline
                              Alanku
                              last edited by

                              Заело меня немножко использование AES NI в реале. Решил смастерить стенд. Нашел у себя бук с i3 U6060, поставил на него ppfSense 2.4.1 в виртуалку под VirtualBox, отдал одно ядро для чистоты эксперимента, чтобы уж точно было видно, кто будет тупить. Сетка гигабитная.
                              IPSEC AES-GCM. Во результаты ниже:

                              –---------------------------------------------------------------------
                              CrystalDiskMark 5.2.0 x64 (C) 2007-2016 hiyohiyo
                                                        Crystal Dew World : http://crystalmark.info/

                              • MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
                              • KB = 1000 bytes, KiB = 1024 bytes

                              Sequential Read (Q= 32,T= 1) :    11.534 MB/s
                                Sequential Write (Q= 32,T= 1) :    10.380 MB/s
                                Random Read 4KiB (Q= 32,T= 1) :    7.028 MB/s [  1715.8 IOPS]
                              Random Write 4KiB (Q= 32,T= 1) :    8.680 MB/s [  2119.1 IOPS]
                                      Sequential Read (T= 1) :    7.969 MB/s
                                      Sequential Write (T= 1) :    9.857 MB/s
                                Random Read 4KiB (Q= 1,T= 1) :    2.133 MB/s [  520.8 IOPS]
                                Random Write 4KiB (Q= 1,T= 1) :    2.349 MB/s [  573.5 IOPS]

                              Test : 4096 MiB [W: 31.1% (37.0/118.8 GiB)] (x5)  [Interval=5 sec]
                                Date : 2017/10/27 9:36:19
                                  OS : Windows 7 Ultimate SP1 [6.1 Build 7601] (x64)
                                  AES NI off

                              –---------------------------------------------------------------------
                              CrystalDiskMark 5.2.0 x64 (C) 2007-2016 hiyohiyo
                                                        Crystal Dew World : http://crystalmark.info/

                              • MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
                              • KB = 1000 bytes, KiB = 1024 bytes

                              Sequential Read (Q= 32,T= 1) :    20.379 MB/s
                                Sequential Write (Q= 32,T= 1) :    15.336 MB/s
                                Random Read 4KiB (Q= 32,T= 1) :    15.471 MB/s [  3777.1 IOPS]
                              Random Write 4KiB (Q= 32,T= 1) :    12.260 MB/s [  2993.2 IOPS]
                                      Sequential Read (T= 1) :    19.923 MB/s
                                      Sequential Write (T= 1) :    14.889 MB/s
                                Random Read 4KiB (Q= 1,T= 1) :    2.554 MB/s [  623.5 IOPS]
                                Random Write 4KiB (Q= 1,T= 1) :    2.562 MB/s [  625.5 IOPS]

                              Test : 4096 MiB [W: 31.0% (36.9/118.8 GiB)] (x5)  [Interval=5 sec]
                                Date : 2017/10/27 9:49:10
                                  OS : Windows 7 Ultimate SP1 [6.1 Build 7601] (x64)
                                  AES NI ON

                              Загрузка проца на pfSense была под 100 процентов, для себя сделал вывод AES NI в реальной работе очень даже рулит!

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.