OpenVPN: OpenSSL error: cannot load engine 'padlock'



  • Hi there,

    since the latest Built (2.1-BETA1 (i386) built on Thu Jan 24 19:53:59 EST 2013) the hardwarecryptoengine "padlock" couldn't be loaded and therefore the OpenVPN Service refuses to start:

    openvpn[93108]: OpenVPN 2.3.0 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Jan 24 2013
    openvpn[54984]: Exiting due to fatal error
    openvpn[54984]: OpenSSL error: cannot load engine 'padlock'

    If I change or disable the hardware-crypto, OpenVPN works as usual.

    On all previous builts, the padlock-engine worked flawlessly. Any ideas? Tell me please, if you need other logs etc.

    Greetings!



  • Can you look up whch was the last buid you were previously on  - this may help to locate the day where things broke.

    And another thing: Can you hop onto the console and see if padlock.ko is even loaded?
    (dmesg might give you an idea whether padlock is loaded or not too)

    There was some minor change after the OpenVPN 2.3 bump, but at the OpenVPN port side, I don't remember seeing changes related to padlock (yet).



  • I'm not exactly sure, until which built it was working (I think not more than 2 days back it was ok).

    dmesg:


    padlock0: <aes-cbc,sha1,sha256>on motherboard
    ...

    I did a test with "openssl speed -evp aes-256-cbc -engine padlock"...that works:

    engine "padlock" set.
    To get the most accurate results, try to run this
    program when this computer is idle.
    Doing aes-256-cbc for 3s on 16 size blocks: 8359397 aes-256-cbc's in 2.99s
    Doing aes-256-cbc for 3s on 64 size blocks: 6815283 aes-256-cbc's in 2.99s
    Doing aes-256-cbc for 3s on 256 size blocks: 3729810 aes-256-cbc's in 3.00s
    Doing aes-256-cbc for 3s on 1024 size blocks: 1326763 aes-256-cbc's in 2.99s
    Doing aes-256-cbc for 3s on 8192 size blocks: 189146 aes-256-cbc's in 2.99s
    OpenSSL 0.9.8q 2 Dec 2010
    built on: date not available
    options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)
    compiler: cc
    available timing options: USE_TOD HZ=128 [sysconf value]
    timing function used: getrusage
    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-256-cbc      44801.33k   146020.49k   318807.94k   453637.05k   517451.10k

    Here is my OpenVPN server-config:

    dev ovpns1
    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_server1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-256-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    client-connect /usr/local/sbin/openvpn.attributes.sh
    client-disconnect /usr/local/sbin/openvpn.attributes.sh
    local ...
    engine padlock
    tls-server
    server 10.13.37.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc
    username-as-common-name
    auth-user-pass-verify /var/etc/openvpn/server1.php via-env
    tls-verify /var/etc/openvpn/server1.tls-verify.php
    lport 443
    management /var/etc/openvpn/server1.sock unix
    max-clients 3
    push "route 192.168.123.0 255.255.255.0"
    push "dhcp-option DOMAIN lan"
    push "dhcp-option DNS 192.168.123.1"
    client-to-client
    duplicate-cn
    ca /var/etc/openvpn/server1.ca
    cert /var/etc/openvpn/server1.cert
    key /var/etc/openvpn/server1.key
    dh /etc/dh-parameters.2048
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo
    persist-remote-ip
    float
    keepalive 20 120
    auth sha256
    tun-mtu 1500
    fragment 1450
    mssfix

    So something concerning OpenVPN must have changed the last 2 or 3 builts I think.</aes-cbc,sha1,sha256>



  • Since my changeset (a sync from FreeBSD ports) was just merged the day you updated, I looked up if this
    may have made it into the build.
    https://github.com/bsdperimeter/pfsense-tools/commit/28ad6b86f09f66e61f662b0ee85d1211a4be290a

    While I'm definitely bad at converting time zones back and forward, it does seem that my
    commit was only merged after the builder ran.

    I don't have a padlock capable VIA cpu that, but enabling cryptodev with SNI didn't break things here with the amd64 build from 24th 19:57 EST

    I know not all ports are being rebuilt at every run, but maybe @BSDPerimeter could fire
    up the OpenVPN port build to make sure your padlock problem is - or  is not related to to
    the related change :-\


  • Rebel Alliance Developer Netgate

    I can rebuild it again and see. I know the openvpn22 port was broken quite a bit for 2.0.x builds, but I can't remember if I've rebuilt openvpn 2.3 since then to see if it had any issues.



  • Thanks jim - and supposedly openvpn22 was broken by me while syncing to upstream - sorry about that.


  • Rebel Alliance Developer Netgate

    OpenVPN 2.3 is rebuilt, new snap run is starting now. Try it again later this evening once it's all uploaded.



  • I've upgraded to the latest built (2.1-BETA1 (i386) built on Fri Jan 25 11:42:50 EST 2013) - still same error as statet above:


    OpenVPN 2.3.0 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Jan 25 2013
    openvpn[17542]: Exiting due to fatal error
    openvpn[17542]: OpenSSL error: cannot load engine 'padlock'


  • Rebel Alliance Developer Netgate

    aha, I see why.

    Somehow it's latching onto the openssl from ports, and not from the base system, and we don't compile the openssl from ports with padlock support (not sure when that started to get included…)


  • Rebel Alliance Developer Netgate

    Next build will be fixed for this.

    Also, the next build will include ipsec-tool 0.8.1. Since I had to fix up openssl for this, I went ahead and used it for that.



  • Thank you guys for looking into this.

    Upgraded to 2.1-BETA1 (i386) built on Fri Jan 25 17:42:51 EST 2013 FreeBSD 8.3-RELEASE-p5

    I get still the same error.


  • Rebel Alliance Developer Netgate

    That's not the new image.

    It's uploading right now.



  • Thank you Jim for your efforts, if things work fine with padlock, I'd like to make a PR to the port maintainer concerning the messed up naming of the padlock patches you had to override in the openssl port.
    It doesn't seem many people use padlock -  otherwise that would have been fixed upstream already. ;-)



  • I'm not sure, if this is already the new image…I just tried it:

    2.1-BETA1 (i386) built on Fri Jan 25 22:52:45 EST 2013 FreeBSD 8.3-RELEASE-p5

    Still no working OpenVPN with padlock enabled.


  • Rebel Alliance Developer Netgate

    Same error? Different error?



  • I still get the same error.


  • Rebel Alliance Developer Netgate

    ok, I think I see what it is now, it didn't copy all of the package version's files to the image, so it's missing the .so files for the other engines. I'll fix that shortly.


  • Rebel Alliance Developer Netgate

    OK the next new image to go up should have the fixes.

    It's not up yet, it will take ~3-4 hours to build and upload.


  • Rebel Alliance Developer Netgate

    New image is up now.



  • Upgraded to the latest built (2.1-BETA1 (i386) built on Sat Jan 26 10:18:38 EST 2013 FreeBSD 8.3-RELEASE-p5):


    openvpn[18810]: Initializing OpenSSL support for engine 'padlock

    It works again  :)

    Thanx jimp & MatSim for the fast fix. You guys doing an amazing work!


  • Rebel Alliance Developer Netgate

    @MatSim:

    Thank you Jim for your efforts, if things work fine with padlock, I'd like to make a PR to the port maintainer concerning the messed up naming of the padlock patches you had to override in the openssl port.
    It doesn't seem many people use padlock -  otherwise that would have been fixed upstream already. ;-)

    Feel free to push that one up to FreeBSD. It was a simple fix, rename the patches and "make makesum" to update the checksum/names.

    I guess nobody goes out of their way to use the ports openssl+padlock, but it does work with the base version so people probably just use that.




  • Rebel Alliance Developer Netgate

    In addition to the other fixes I made, I just added some smarter code to the openvpn engine option that does better checking for not just the engines on the system but also which engines are actually usable.

    That way if something like this were to happen in the future, the VPN wouldn't have failed, it just would not have used the padlock engine.


Locked