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

    Real status of cryptographic accelerators in pfsense 2.2.6?

    Scheduled Pinned Locked Moved Hardware
    10 Posts 5 Posters 8.8k 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.
    • A
      ashoka
      last edited by

      Hi,

      Does anybody know the real status of (relatively) popular cryptographic accelerators in pfsense 2.2.6?
      I have already seen the information regarding this topic in the official documentation of pfsense (https://doc.pfsense.org/index.php/Are_cryptographic_accelerators_supported)

      There are old posts in his forum that suggest different results/performances but nothing really conclusive.

      Then, I also read that these cards are useless if they need to operate with services in the userland of FreeBSD (or OpenBSD) such as OpenVPN. But it they are still useful if you run IPSec because it runs "within" the kernel…

      Then, some people suggest that using these cards is even counterproductive because of multiple interrupts or the chunks of data in VPN connections can be problematic.

      I have a Soekris vpn1411 in an old Soekris-5501 and I really can't notice any improvement (in speed or CPU usage) in OpenVPN connections using AES256-CBC. I ran the tests using plain openssl and the same test setting the cryptodev engine, and I get very similar results. The same happens in an ALIX board.

      Do you have any experience using this kind of cards with OpenVPN? Specially the vpn1411.

      Thank you!

      1 Reply Last reply Reply Quote 0
      • ?
        Guest
        last edited by

        Does anybody know the real status of (relatively) popular cryptographic accelerators in pfsense 2.2.6?
        I have already seen the information regarding this topic in the official documentation of pfsense (https://doc.pfsense.org/index.php/Are_cryptographic_accelerators_supported)

        There are some crypto acceleration cards in the miniPCI and PCI/PCIe format and you should be
        reading on the website of the manufacturers which algorithms are supported and then you might
        be have a closer look to what is available in OpenVPN. And not vice versa.

        There are old posts in his forum that suggest different results/performances but nothing really conclusive.

        As todays modern CPUs are often comes with Intel AES-NI and QuickAssist this crypto accelerator cards
        might be not so important as in older times and days.

        Then, I also read that these cards are useless if they need to operate with services in the userland of FreeBSD (or OpenBSD) such as OpenVPN. But it they are still useful if you run IPSec because it runs "within" the kernel…

        Not really, in normal I would be thinking the IPSec will be mostly supported and also pushed or speed up,
        but OpenVPN is not really getting a huge benefit from this cards.

        Then, some people suggest that using these cards is even counterproductive because of multiple interrupts or the chunks of data in VPN connections can be problematic.

        By using older hardware running only with 100 MBit/s LAN Ports it might be really fine speeding up
        the IPSec VPN, pending on the use algorithm likes AES-128, AES-256 or AES-192 this might be perhaps sounding then something like this:

        • IPSec with AES-128
          Throughput without vpn1411 = ~14 MBit/s
          And with vpn1411 = ~42 MBit/s

        This might be nearly tree times speeding up the entire throughput!

        • IPSec with AES-256
          Throughput without vpn1411 = ~12 MBit/s
          Throughput with vpn1411 = ~22 MBit/s

        So this might be rthen not so fast as before but more tending to double the entire throughput!

        I have a Soekris vpn1411 in an old Soekris-5501 and I really can't notice any improvement (in speed or CPU usage) in OpenVPN connections using AES256-CBC. I ran the tests using plain openssl and the same test setting the cryptodev engine, and I get very similar results. The same happens in an ALIX board.

        You are using OpenVPN and not as above told IPSec together with the AES algorithm.

        Do you have any experience using this kind of cards with OpenVPN? Specially the vpn1411.

        No this crypto cards are today not really needed because the lowest Intel Atom comes often together with
        AES-NI and this might be speeding up the entire throughput IPSec (AES-GCM) 4x or 5x times!!!

        • OpenSSL is using the AES-NI option
        • OpenVPN is using the AES-NI if it is present in the system
        • But OpenVPN is not offering the AES-GCM algorithm and this is the only one what is getting a
          benefit from this CPU registers, OpenVPN only supports at this time AES-CBC and this is not gaining
          any throughput or significant speed improvement!!!

        OpenVPN is more CPU frequency and CPU core based at this time, only if Intel QuickAssist is activated
        (not ready yet) in pfSense or OpenVPN will be coming with the support of the AES-NI CPU register it
        would be speed up many.

        So in your case you could try out IPSec together with AES-128/256/192 or perhaps you might not be
        changed from the crypto engine in the AMD CPU to the vpn1411 card, could this be?

        1 Reply Last reply Reply Quote 0
        • A
          Aluminum
          last edited by

          OpenVPN just wants 1 modern x86 core with high clockspeed, right now a cheap desktop cpu will crush any of those old cards.

          This isn't changing much in the near future.

          1 Reply Last reply Reply Quote 0
          • A
            ashoka
            last edited by

            @BlueKobold:

            […]

            No this crypto cards are today not really needed because the lowest Intel Atom comes often together with
            AES-NI and this might be speeding up the entire throughput IPSec (AES-GCM) 4x or 5x times!!!

            • OpenSSL is using the AES-NI option
            • OpenVPN is using the AES-NI if it is present in the system
            • But OpenVPN is not offering the AES-GCM algorithm and this is the only one what is getting a
              benefit from this CPU registers, OpenVPN only supports at this time AES-CBC and this is not gaining
              any throughput or significant speed improvement!!!

            OpenVPN is more CPU frequency and CPU core based at this time, only if Intel QuickAssist is activated
            (not ready yet) in pfSense or OpenVPN will be coming with the support of the AES-NI CPU register it
            would be speed up many.

            So in your case you could try out IPSec together with AES-128/256/192 or perhaps you might not be
            changed from the crypto engine in the AMD CPU to the vpn1411 card, could this be?

            Thank you!

            I am using only OpenVPN in two scenarios:

            • To connect to my lab network (and the IT guys configured openvpn because they think it offers the most stable connections… I am not so sure about that)
            • To connect to a VPN-provider (e.g. StrongVPN, but this is not the real case) that just offers OpenVPN.
              So I guess I am "married" to OpenVPN.

            The AMD Geode options are turned off in my Soekris and the vpn1411 (using hifn) is properly detected and configured in the VPN client. So, I think that using this cards (at least those based in hifn) and OpenVPN is not really worth.

            As Aluminum suggests, I would need a modern CPU. The APU boards, specially the new version using Intel NICs and AES-NI look really promising. But it is still hard to find them, they're quite expensive and as far as I know the BIOS was still somewhat buggy.

            So, I guess I will have to wait for a while.

            PD. I am not interested in a full-tower computer because it needs to run 24/7 in my sitting-room.

            1 Reply Last reply Reply Quote 0
            • ?
              Guest
              last edited by

              OpenVPN just wants 1 modern x86 core with high clockspeed, right now a cheap desktop cpu will crush any of those old cards.

              Yes you are right, but for a better or more electric power saving platform together with AES-NI
              and/or Intel QuickAssist would be better and more future proof, as I see it right.

              This isn't changing much in the near future.

              For sure I would consider, the net5501 & vpn1411 were a pretty good duo in later times or old days
              because they are also coming only with 100 MBit/s LAN ports and there fore in earlier times this was
              working well together with IPSec VPNs.

              I am using only OpenVPN in two scenarios:

              • To connect to my lab network (and the IT guys configured openvpn because they think it offers the most stable connections… I am not so sure about that)
              • To connect to a VPN-provider (e.g. StrongVPN, but this is not the real case) that just offers OpenVPN.
                So I guess I am "married" to OpenVPN.

              So for this scenarios the vpn1411 will not be a gain or win, it will be not used for the VPN itselfs, based on the
              information that only AES-GCM will be benefit from this card and not AES-CBC as you are using it together with
              OpenVPN.

              The AMD Geode options are turned off in my Soekris and the vpn1411 (using hifn) is properly detected and configured in the VPN client. So, I think that using this cards (at least those based in hifn) and OpenVPN is not really worth.

              OpenVPN is using AES-CBC and this algorithm is not taking any advantage or is taking no benefit from this
              crypto acceleration card!

              As Aluminum suggests, I would need a modern CPU.

              If your want to be on the safe site, I would suggest something that is coming together with AES-NI and
              Intel QuickAssist, AES-NI would speed up the IPSec (AES-GCM) VPN and Intel QuickAssist is able to
              compress and decompress packets and also speeding up other cryptographic processes and so the
              OpenVPN could be more getting from the QuickAssist as we could imagine today.

              The APU boards, specially the new version using Intel NICs and AES-NI look really promising. But it is still hard to find them, they're quite expensive and as far as I know the BIOS was still somewhat buggy.

              All this points are right, for the moment. You should wait until the APU2 board is coming out of his beta phase
              and is more stable and also working without any kind of issues.

              So, I guess I will have to wait for a while.

              Could be a solution for this, but the APU2 board is also lagging of Intel QuickAssist and the AES-NI is
              not speeding up any kind of OpenVPN parts until the OpenVPN is also sorted with AES-GCM.

              PD. I am not interested in a full-tower computer because it needs to run 24/7 in my sitting-room.

              For sure who is doing so? Electric power is in many regions of the world going to be really expensive.
              And so electric power saving is one of the mostly major things customers are looking for, so many of
              us are looking to a strong, powerful and fast platform that is really power saving. The intel Atom C2x58
              SoC could also be a really hint to build a really fast appliance that matches nearly to all criteria are named
              here. So a SG-2440 or SG-4860 could be the solution or a self made box based on Supermicro spare parts
              will also match to this case. But this would be also more pending on your budget and real use case.

              1 Reply Last reply Reply Quote 0
              • M
                mauroman33
                last edited by

                @BlueKobold:

                No this crypto cards are today not really needed because the lowest Intel Atom comes often together with
                AES-NI and this might be speeding up the entire throughput IPSec (AES-GCM) 4x or 5x times!!!

                • OpenSSL is using the AES-NI option
                • OpenVPN is using the AES-NI if it is present in the system
                • But OpenVPN is not offering the AES-GCM algorithm and this is the only one what is getting a
                  benefit from this CPU registers, OpenVPN only supports at this time AES-CBC and this is not gaining
                  any throughput or significant speed improvement!!!

                OpenVPN is more CPU frequency and CPU core based at this time, only if Intel QuickAssist is activated
                (not ready yet) in pfSense or OpenVPN will be coming with the support of the AES-NI CPU register it
                would be speed up many.

                So in your case you could try out IPSec together with AES-128/256/192 or perhaps you might not be
                changed from the crypto engine in the AMD CPU to the vpn1411 card, could this be?

                I am a complete beginner, so I apologize in advance if I'm writing something wrong.
                I've considered to get something with AES-NI to run an OpenVPN connections using AES256-CBC, because in this link (https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/) Intel explicitly says (in Performance Improvement) AES-CBC have some benefits from AES-NI. Nothing about AES-GCM.
                So now I'm more confused than before. Could someone help me to understand, please?
                Thanks
                M.

                1 Reply Last reply Reply Quote 0
                • J
                  jwt Netgate
                  last edited by

                  @Aluminum:

                  OpenVPN just wants 1 modern x86 core with high clockspeed, right now a cheap desktop cpu will crush any of those old cards.

                  OpenVPN is much more constrained by the tun/tap architecture than it is by crypto.
                  The other issue is that the HMAC (SHA-N, MD5) isn't accelerated by AES-NI, and it's pretty slow on a core.

                  Avoiding this requires either a crypto accelerator that can accelerate these (such as QuickAssist) or running an AEAD mode (such as the AES-GCM modes we put in FreeBSD/pfSense for IPsec).

                  OpenVPN 2.4 will have AEAD modes (the code made it in about 2 months ago).
                  https://community.openvpn.net/openvpn/ticket/301

                  This isn't changing much in the near future.

                  You're wrong.  QuickAssist support should be available in 2016.

                  1 Reply Last reply Reply Quote 0
                  • J
                    jwt Netgate
                    last edited by

                    @BlueKobold:

                    I am using only OpenVPN in two scenarios:

                    • To connect to my lab network (and the IT guys configured openvpn because they think it offers the most stable connections… I am not so sure about that)
                    • To connect to a VPN-provider (e.g. StrongVPN, but this is not the real case) that just offers OpenVPN.
                      So I guess I am "married" to OpenVPN.

                    So for this scenarios the vpn1411 will not be a gain or win, it will be not used for the VPN itselfs, based on the
                    information that only AES-GCM will be benefit from this card and not AES-CBC as you are using it together with
                    OpenVPN.

                    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
                    • ?
                      Guest
                      last edited by

                      You're wrong.  QuickAssist support should be available in 2016.

                      +1 from for that information!

                      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.

                      Again +1 from me about that, in the past or the former 3 month again and again here in the forum we all
                      were discussing about and around that things and even other peoples were linking to new but also even
                      other and different locations where different statements were done about that. Nice to hear about something
                      that is clearing up that points definitive or plain what is coming and we could imagine. For sure a clear roadmap
                      or way will also often be changed against other things or features or functions but to see what´s going on or can
                      be imagined is even a fine thing.

                      1 Reply Last reply Reply Quote 0
                      • J
                        jwt Netgate
                        last edited by

                        https://wiki.freebsd.org/DevSummit/201606#Schedule-1

                        https://twitter.com/gonzopancho/status/715262054832033792

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