Home / server / Questions / 232901
In Process
leto
Asked: 2011-02-09 12:04:45 +0800 CST

How to make OpenVPN use VIA Padlock on OpenBSD?

  • 772

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.

openvpn cryptography openbsd

3 Answers

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

    • 1

  2. 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 :-)

    • 0

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

    • 0