Slow IPsec and slightly faster OpenVPN



  • 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>


  • LAYER 8 Netgate

    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.



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



  • @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


  • LAYER 8 Netgate

    No.



  • @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!


  • LAYER 8 Netgate

    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



  • 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.


Log in to reply