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

Slow IPsec and slightly faster OpenVPN

Scheduled Pinned Locked Moved IPsec
8 Posts 2 Posters 2.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.
  • I
    itatcapital
    last edited by Jan 15, 2017, 11:04 PM Jan 15, 2017, 10:18 PM

    Hello,

    TL;DR

    I am trying to understand why our IPSec and OpenVPN transfers are slow compared to raw transfer. I realise there will be some overhead but the below transfer speeds are quite slow.

    • When I transfer data between the two sites over an open connection (not IPsec or OpenVPN) I see transfer speeds of 75 Mbps. I used two linux servers and transferred data a combination of "dd" and "nc"
    • When I use IPsec, the transfer rate fluctuates between 10 Mbps and 45 Mbps during the transfer, with the overall transfer at about 25 Mbps
    • When I use OpenVPN, the transfer rate fluctuates between 10 Mbps and 60 Mbps during the transfer, with the overall transfer at about 45 Mbps

    we have two sites with 100/100 Mbps connections to the internet at each site.
    Both sites use the same ISP (Telstra in Australia) and all traffic is carried over the same ISP's network.
    We plan on setting up VPN's between six different site so this performance and CPU usage is a concern

    Site 1: SG-2440 with Firmware 2.2.6-release
    Site 2: SG-2440 with firmware 2.3.2-RELEASE-p1

    When I transfer data between the two sites over an open connection (not IPsec or OpenVPN) I see transfer speeds of 75 Mbps. I used two linux servers and transferred data a combination of "dd" and "nc"

    On the server:

    nc –vvlnp 12345 > /dev/null

    On the client:
    dd if=/dev/zero bs=1M count=1k | nc -vvn <external-ip-address>12345

    HOWEVER:
    1. IPsec
    When I use IPsec, the transfer rate fluctuates between 10 Mbps and 45 Mbps during the transfer, with the overall transfer at about 25 Mbps

    2. OpenVPN
    When I use OpenVPN, the transfer rate fluctuates between 15 Mbps and 70 Mbps during the transfer, with the overall transfer at about 50 Mbps

    I note that

    • for IPsec, the CPU usage on both devices increases to about 35%
    • for OpenVPN, the CPU usage on both devices increases to about 70%

    IPSec settings (although I tried a few different settings)
    IPSec: Phase 1 : AES (256 bits)/SHA1
    IPSec: Phase 2 : ESP/ AES (auto)/SHA1

    OpenVPN settings:
    Peer-to-Peer (Shared Key)
    AES-256-CBC
    SHA1
    No compression

    I would prefer to use IPSec but may be ok with OpenVPN, although the high CPU usage on one link is a problem.

    Any assistance or thoughts would be welcome.</external-ip-address>

    1 Reply Last reply Reply Quote 0
    • D
      Derelict LAYER 8 Netgate
      last edited by Jan 16, 2017, 2:04 AM

      It sounds like you might have a path MTU issue. You might try enabling MSS Clamping in the advanced IPsec settings. Maybe try something around 1300 and test again to see if there are some improvements.

      To test to see what you're looking at you want to make sure at least one side's WAN address responds to pings then do something like:

      Diagnostics > Command prompt

      Execute command:

      ping -c 3 -D -s 1472 far_side_ip_address

      A full MTU 1500-byte path should be able to pass that and fail at size 1473.

      If that fails then reduce the size until you can pass frames.

      All of this is easier from the console/ssh option 8.

      Chattanooga, Tennessee, USA
      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
      Do Not Chat For Help! NO_WAN_EGRESS(TM)

      1 Reply Last reply Reply Quote 0
      • I
        itatcapital
        last edited by Jan 16, 2017, 2:25 AM

        Thanks for the reply, Derelict
        I will give that a try

        1 Reply Last reply Reply Quote 0
        • I
          itatcapital
          last edited by Jan 16, 2017, 4:00 AM

          @Derelict:

          It sounds like you might have a path MTU issue. You might try enabling MSS Clamping in the advanced IPsec settings. Maybe try something around 1300 and test again to see if there are some improvements.

          To test to see what you're looking at you want to make sure at least one side's WAN address responds to pings then do something like:

          Diagnostics > Command prompt

          Execute command:

          ping -c 3 -D -s 1472 far_side_ip_address

          A full MTU 1500-byte path should be able to pass that and fail at size 1473.

          If that fails then reduce the size until you can pass frames.

          All of this is easier from the console/ssh option 8.

          That did not seem to improve performance.
          Should I also set this value (MSS)and MTU in the Interfaces WAN or LAN section to ensure packets are sized correctly?

          thanks

          1 Reply Last reply Reply Quote 0
          • D
            Derelict LAYER 8 Netgate
            last edited by Jan 16, 2017, 5:26 AM

            No.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • I
              itatcapital
              last edited by Jan 16, 2017, 5:32 AM

              @Derelict:

              No.

              thanks again. I realised after I posted that it would not be necessary.

              I see the point of the settings. It did not make a difference but I will persevere.

              I wonder if the SG-2440 is just not up to the task of encrypting traffic at those speeds.

              cheers!

              1 Reply Last reply Reply Quote 0
              • D
                Derelict LAYER 8 Netgate
                last edited by Jan 16, 2017, 8:16 AM

                Those speeds are not something the SG-2440 will not keep up with.

                There is something else going on.

                You did not say what you did with the MSS or where.

                I would stick with IPsec. Set your phase 2 encryption settings to AES-GCM and turn off all hash algorithms.

                Make sure powerd is enabled in hi-adaptive mode for all contexts in System > Advanced, Misceallaneous

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • I
                  itatcapital
                  last edited by Feb 6, 2017, 1:16 AM

                  Sorry for my late response. I had some unexpected, personal leave.

                  1. MSS clamping
                  I tried a range of values from 1000 to 1500
                  –> no meaningful change, i.e. low and fluctuating speeds

                  2. Phase 2 encryption

                  • I tried all values of AES-GCM
                  • again, no meaningful change, i.e. low and fluctuating speeds

                  3. Turning off hash algorithms

                  • Do you mean in Phase 2 only?
                  • Hash algorithms cannot be turned off, so I chose SHA1

                  4. powerd

                  • this is set to Enabled and hi-adaptive in all contexts

                  I will have another connection available in a few days will be able to test using virtual endpoints, using the community edition, instead, running server-class CPUs

                  thanks for your assistance.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    This community forum collects and processes your personal information.
                    consent.not_received