2

I've bought a VIA based router for the only purpose to run OpenVPN on it. Unfortunately it seems that Padlock is not used. Here is the important part from dmesg:

OpenBSD 4.8 (GENERIC) #136: Mon Aug 16 09:06:23 MDT 2010
[email protected]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: VIA C7 Processor 1500MHz ("CentaurHauls" 686-class) 1.51 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2,xTPR

My OpenVPN-Config has these options related to the ciphers/padlock:

cipher AES-128-CBC
engine cryptodev

I can verify that usercrypto is enabled by benchmarking with openssl speed command. The sysctl also reads:

kern.usercrypto=1

I'm deducing that Padlock is no used from these top informations which are taken @40 Mbit/sec (of 70/sec maximum) going through the VPN tunnel:

load averages:  0.66,  0.62,  0.54                                                                                                                                                          crypto.b0nd4ge.de 21:03:04
28 processes:  2 running, 25 idle, 1 on processor
CPU states:  1.9% user,  0.0% nice,  2.9% system,  3.2% interrupt, 92.1% idle
Memory: Real: 30M/142M act/tot  Free: 839M  Swap: 0K/1214M used/tot

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
20161 root      59    0 1224K 2676K run       -       116:45 53.42% openvpn
11092 named      2    0   18M   19M sleep     select   67:50  0.10% named

What else can I do to get Padlock working with OpenVPN? It's really a shame to no be able to max out my internet connection with this VPN.

Please help. Any suggestion would be appreciated. I've been googling for this since a couple of weeks.

Improve this question

3 Answers 3

Reset to default
1

I am not familiar with VIA Padlock, but ...

  1. Does the CPU for OpenVPN ever climb to ~100% in top?
  2. What is the average packet size being encapsulated (Crypto acceleration should not help for small packets a lot)?
  3. Could you share "openssl speed aes" results with us?

For reference I can give you my OpenVPN and OpenSSL performance numbers for aes128-cbc cipher and sha1 HMAC on Xeon E5530 2.40GHz when crypto happens on CPU and average packet size ~1400bytes: openssl=1360Mbit/s openvpn=320Mbit/s (with the same cipher)

With Intel AES-NI engine I was able to get only 30% improvements for OpenVPN, while OpenSSL speed test improved ~4 times.

Edit:

You can also performance test OpenVPN with "cipher none" to rule out/prove bottlenecks in non-encryption related code. The bandwidth you will get will be the upper bound and OpenVPN will never work faster than that with any crypto engine.

If it turns out that bottleneck is in non-crypto code I would suggest you to use IPSec - that one has less overhead (no TUNs, no Userspace processes, context switches, no TCP/UDP stack involved). If you still want to stick with OpenVPN then run multiple OpenVPN processes and try to load balance traffic (helps only if you have multiple CPU cores on the router).

Improve this answer
7
  • @AnsisAtteka Hello here are my aes-128-cbc results: with openssl sleep -evp aes-128-cbc type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 38258.00k 139150.25k 428578.23k 785673.65k 1021974.48k and with openssl speed aes-128-cbc type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 18690.44k 21683.94k 22475.08k 22569.64k 23092.98k. To 1. yes the CPU reaches 100% util when doing around 40 Mbit/sec. The average packet size? I guess it's 1500 bytes UDP packets (BitTorrent).
    – leto
    Commented Feb 9, 2011 at 9:38
  • @leto Here is how I understand it - with OpenSSL you are able to use Hardware Crypto, but when OpenVPN is using OpenSSL it does not get hardware crypto benefits at all. For me it seems like OpenVPN problem (was it ./configured with correct flags?). Copy output of following command "openvpn --show-engines"
    – user2138912
    Commented Feb 9, 2011 at 17:57
  • @leto: I just did a quick test with Intel AES-NI hardware crypto acceleration. AES-NI improved raw encryption speed almost 4 times, while OpenVPN bandwidth increased only by ~30%. The explanation could be that a lot of CPU work is needed to switch packets to/from userspace (TCP/IP stack<->OpenVPN process). So benefts of hardware crypto are not that much noticeable anymore. IPSec does not have this problem because it directly hooks to TCP/IP stack. Anyway I will take a look into this much deeper and let you know what I found out, because sometimes I got impression crypto engine did not start up
    – user2138912
    Commented Feb 9, 2011 at 22:37
  • I'm using the stock OpenBSD version, it says: # openvpn --show-engines OpenSSL Crypto Engines BSD cryptodev engine [cryptodev] Dynamic engine loading support [dynamic]
    – leto
    Commented Feb 10, 2011 at 8:56
  • @leto: To give further hints: 1. Take a look into forums.freebsd.org/showthread.php?t=7418 - looks similar to your problem 2. The syslog should indicate which engine openvpn is setting as the default one (I have following line "Initializing OpenSSL support for engine 'aesni'") 3. In that post I saw that there is padlock engine next to cryptodev (albeit cryptodev could be using padlock). 4. Maybe the bottleneck is somewhere else - not int the crypto speed. So how much bandwidth OpenVPN can handle when you run it without crypto engines at all? 5. What OpenSSL version do you have?
    – user2138912
    Commented Feb 10, 2011 at 17:15
0

Google is not always your friend :-)

Do search on the misc@openbsd mailing list archive here: http://marc.info/

Last I remember, VIA's hardware implementation leaves a lot to be desired.

Also, why are using the OpenVPN package? OpenBSD has ipsec vpn and openSSH built-in and integrated with the network stack and pf firewall. All these are supported by cross-platform clients, and yes, even on the most inefficient of them all :-)

Improve this answer
1
  • Because OpenVPN is easier to setup and mantain. I only need one tunnel from point A to point B. It's so simple I'm even using static keys. But I really need the throughput and am now even considering switching to Debian GNU/Linux just to get it going faster.
    – leto
    Commented Feb 9, 2011 at 9:44
0

When seeing high CPU usage with OpenVPN, remember that it is a userland application, and aside from crypto, there is a lot of context-switching required to shuffle both encapsulated and non-encapsulated packets to and from the kernel, as well as CPU interrupts for the actual network communication. Assuming a single ICMP ping packet from the remote end to the network made available by the OpenVPN server:

  1. Kernel receives encapsulated packet from remote client
  2. Kernel hands encapsulated packet to OpenVPN
  3. OpenVPN decrypts packet and copies the payload into memory
  4. OpenVPN creates a new packet containing the payload and hands it to the kernel
  5. Kernel sends the packet out on the local network
  6. Kernel receives response packet from local network
  7. Kernel hands response packet to OpenVPN
  8. OpenVPN creates an encapsulated packet and hands it to the kernel
  9. Kernel sends encapsulated packet to remote client

Context switches happen whenever the execution changes from kernel context to userland, so 2-3, 4-5, 7-8, 8-9. Contrast this to IPSec, which is in-kernel, so all that encapsulation/de-encapsulation happens in kernel context.

This is why, as Ansis says, increasing encryption throughput does not directly translate into better OpenVPN throughput. As the packet rate increases, the context switching overwhelms the gains from hardware crypto acceleration.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .