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

    Revisiting SG-5100 ipsec in the real world

    Scheduled Pinned Locked Moved Hardware
    14 Posts 2 Posters 1.3k 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.
    • L
      lguy2000
      last edited by

      Re: Better option for $$ than Protectcli FW6C with 16GB ram & 512GB M2?

      My recently bought SG-5100 works great, but gets nowhere near the expected ipsec throughput. The best it gets is about 220 mbps, over a gbps pipe, when copying large files; even though CPU utilization never tops 35%. And this is without running any ancillary packages like snort or suricata. Just FYI.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        What encryption settings are you using there? What latency over the link?

        35% total cpu usage could be 100% on one core. Check that with top -aSH at the command line.

        I would certainly expect more than that if the link allows it.

        Steve

        1 Reply Last reply Reply Quote 0
        • L
          lguy2000
          last edited by

          These are the settings I have on both boxes (an SG-5100 and an i3-4130t-powered box):

          AES128-GCM (128 bits)
          SHA256
          14 (2048 bit)

          FWIW, the i3 seems to use even less of the cpu than the C3558-powered SG-100.

          Both boxes have hardware acceleration enabled. And this is over a local gbps LAN with barely measurable latency.

          1 Reply Last reply Reply Quote 0
          • L
            lguy2000
            last edited by

            I will run top -aSH as soon as I am back in that location, later on today.

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              If you're using AES-GCM you don't need an authentication hash since it's an AEAD cipher so that's unnecessary cpu cycles.
              Enabling asynchronous crypto will usually accelerate things significantly. It cannot be enabled on all systems but the SG-5100 should be OK. That's an advanced ipsec setting.

              Steve

              1 Reply Last reply Reply Quote 0
              • L
                lguy2000
                last edited by

                I just checked and asynchronous crypto was enabled.

                1 Reply Last reply Reply Quote 0
                • L
                  lguy2000
                  last edited by

                  How do I remove the authentication hash? the UI seems to force at least SHA1.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    At phase 2, which is where it matters, it should not.

                    1 Reply Last reply Reply Quote 0
                    • L
                      lguy2000
                      last edited by

                      Problem completely solved. With crypto settings at suggested, ipsec throughput is 900 mbps on gbps LAN.

                      1 Reply Last reply Reply Quote 1
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Nice!

                        1 Reply Last reply Reply Quote 0
                        • L
                          lguy2000
                          last edited by

                          I spoke too fast.

                          ipsec throughput is 900 mbps flowing from the SG-5100 (C3558) to the i3-4130t box, but maxes out at only 100 mbps in the other direction. What could cause such asymmetry? could it be asymmetry in encryption vs decryption? on which side?

                          At 900 mbps (SG-5100 to i3 box), the C3558 is at 75-80%, the i3 at 25%. in other direction, at 100 mbps, the C3558 is at 20%, the i3 at 9%.

                          any thoughts?

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Generally I expect the encryption side to be more cpu intensive.
                            On some systems enabling async-crypto can actually limit throughput severely which is why we don't enable it by default in CE. You might try disabling that in the 4130T.

                            Though those cpu usage ratios look quite similar in both situations, like something else is limiting it to 100Mbps. I assume you have tested directly, outside the tunnel, and you can see >900Mbps?

                            Steve

                            L 1 Reply Last reply Reply Quote 0
                            • L
                              lguy2000 @stephenw10
                              last edited by

                              @stephenw10

                              Yes, both boxes were able to handle gbps outside the tunnel.

                              I was finally able to get 900 mbps in both ipsec directions. Once the i3's hardware encryption was enabled, there was no problem. Interestingly, the C3558 maxed out at 95% on the receiving end, while the i3 flowed along at about 30% encrypting on the upload side. It's just a much more capable chip, even though it draws just 35W and runs only 2 cores (4 threads).

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                Hmm, just enabling AES-NI on the i3 end? Interesting, that's a significant step up, more than I would expect there.

                                Steve

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