1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

OpenVPN - estimate performance via OpenVPN

Discussion in 'VPN' started by sfx2000, Jul 1, 2016.

  1. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    13,988
    Location:
    San Diego, CA
    Been tinkering around a bit more with OpenVPN, and seeing how to estimate performance across the link... found this one over on the pfSense forums, and it seems to scale pretty well...

    In the past, folks were testing OpenSSL speeds, but that's only one part of OpenVPN, and doesn't take into account the OpenVPN application, or the HMAC...

    So for comparing OpenVPN performance, I have started using this benchmark instead:

    Code:
    openvpn --genkey --secret /tmp/secret
    time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc
    
    This generates a temporary key (it won't mess with your primary key configs), and then asks OpenVPN to run a shedload of packets thru the OpenVPN app - see the note below...

    Then to give the execution time in seconds a real-world meaning:

    ( 3200 / execution_time_seconds ) = Projected Maximum OpenVPN Performance in Mbps

    The projected speed should be an upper limit under optimum conditions...

    The magic number of 3200 comes from summing 1 to 20000, multiply by 2 for encrypt and decrypt and by 8 bits/byte and divide by 1,000,000 for a result of Mbps

    so for an intel J1800 (Baytrail-D @ 2.41GHz) on Ubuntu 16.04LTS

    Code:
    [email protected]:~$ openvpn --genkey --secret /tmp/secret
    [email protected]:~$ time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc
    
    real    0m18.405s
    user    0m18.420s
    sys    0m0.012s
    
    This gives us;

    3200/18.405 = 173.87 Mbps max thruput over OpenVPN

    Compare notes across other platforms?
     
  2. john9527

    john9527 Part of the Furniture

    Joined:
    Mar 28, 2014
    Messages:
    6,096
    Location:
    United States
    Was playing around and ran this on an AC68P overclocked to 1200MHz (I added the time command to my fork, it's not standard)....

    Code:
    [email protected]:/tmp/home/root# /jffs/scripts/openvpnperf.sh
    aes-128-cbc results
    real    0m 45.24s
    user    0m 42.86s
    sys     0m 2.33s
    aes-256-cbc results
    real    0m 48.57s
    user    0m 45.98s
    sys     0m 2.53s
    
    So for
    aes-128-cbc, 3200/45.24 = 70.73 Mbps
    aes-256-cbc, 3200/48.57 = 65.88 Mbps

    My gut feel from actual results was that the max was in the low-mid 60's, so it's close. Maybe just a bit optimistic.
     
    sfx2000 likes this.
  3. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    13,988
    Location:
    San Diego, CA
    And to link the two threads together - this was the OpenSSL numbers thread...

    http://www.snbforums.com/threads/req-need-some-openssl-numbers-info.31444/

    OpenSSL performance is important, but these numbers are more relevent for real-world expectations of what an end-point _can_ do... it's up to the broadband connection after that...

    Comments - respond here, as this is more OpenVPN oriented, and useful for those who are looking to get the most out of their OVPN solution...
     
  4. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    13,988
    Location:
    San Diego, CA
    Suggests that Tribal Knowledge, e.g. AES-128 is much faster than AES-256 - looks like it is not - so to be more secure, it's not that much overhead...
     
  5. john9527

    john9527 Part of the Furniture

    Joined:
    Mar 28, 2014
    Messages:
    6,096
    Location:
    United States
    Agreed....and matches my 'real world' observations. Could be due to OpenSSL having optimized assembler for AES ARM support.

    For me the performance killer is the auth digest. I normally run with auth SHA1. Again, real world, changing to auth SHA256 results in about a 40-50% throughput hit.
     
  6. maurer

    maurer Regular Contributor

    Joined:
    May 13, 2014
    Messages:
    106
    i've seen this benchmarking first on pfsense forums and i've noticed that openvpn-polarssl (since supported 1.3.x) got up to 70% boost for mipsel boxes.
    so for openvpn on rt-n/ac/16/66 (MIPS based) I recommend to run entware's openvpn-polarssl
     
    Mike Pruett likes this.
  7. CiscoX

    CiscoX Senior Member

    Joined:
    Aug 13, 2013
    Messages:
    205
    Code:
    [2.3.2-RELEASE][xxxxxxxxxxxxxxxxxxxxx]/xxxxxx: time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc
    
    9.454u 0.425s 0:09.88 99.8%  742+178k 0+0io 0pf+0w
    
    This gives me:
    3200/9.88 = 323.88 Mbps
     
  8. Xentrk

    Xentrk Part of the Furniture

    Joined:
    Jul 21, 2016
    Messages:
    2,125
    Location:
    The Land of Smiles
    Here are my results
    Code:
    aes-256-cbc:  3200/9.33 = 342.97 Mbps
    aes-128-cbc:  3200/9.18 = 348.58 Mpbs
    aes-128-gcm: 3200/8.54 = 374.70 Mbps
    
     
  9. sfx2000

    sfx2000 Part of the Furniture

    Joined:
    Aug 11, 2011
    Messages:
    13,988
    Location:
    San Diego, CA
    Fun stuff - playing around with a Kaby Lake NUC - i5-7260... Should get around wired speed on a gigabit connection...

    aes-256-gcm: 3200/2.99 = 1070
    aes-128-gcm: 3200/2.95 = 1084
    aes-256-cbc: 3200/3.59 = 891
    aes-128-cbc: 3200/3.52 = 909
     
  10. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    30,222
    Location:
    Canada
    Something changed with OpenSSL 1.1.x BTW, I get 3 seconds regardless of whether it runs on a Cortex B53 or an Intel i7 7700K...