Centos 7, Openvpn not working with Yubikey and pkcs11

[BigDog]

Hi All

I think there is a bug with the way Openvpn interacts with pkcs11 on centos 7. I have trawled the sites/forums to see if there is any resolution but there seems to be none. I have attached relevant files for investigation your perusal.

I have successfully authenticated my centos 7 (4.19.7-1.el7.elrepo.x86_64) client with a linksys lrt214 router using the openvpn --config /etc/openvpn/client/info.ovpn command. The ovpn file working.ovpn is attached with relevant information.

I moved the cert and private key from working.ovpn, to slot 9e on a yubikey5, and replaced them with the following 2 lines in the /etc/openvpn/client/info.ovpn file.

pkcs11-id piv_II/PKCS
x2315
x20emulated/00000000/REMOVED/04
pkcs11-providers /usr/lib64/opensc-pkcs11.so

When now attempting to connect to the router with the yubikey attached the openvpn command returns these last few lines and hangs at the creation of the tun device .The complete log with verb5 is openvpn.output-verb5

Thu Jan 24 15:50:46 2019 us=29344 ROUTE_GATEWAY 172.20.10.1/255.255.255.240 IFACE=wlp2s0 HWADDR=34:41:5d:36:e2:c3
Thu Jan 24 15:50:46 2019 us=29959 TUN/TAP device tun0 opened
Thu Jan 24 15:50:46 2019 us=30109 TUN/TAP TX queue length set to 100
Thu Jan 24 15:50:46 2019 us=30181 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Jan 24 15:50:46 2019 us=30242 /sbin/ip link set dev tun0 up mtu 1500 <- HANGS HERE

A successful connection generated by the working.ovpn looks like
Tue Jan 22 15:20:55 2019 TUN/TAP device tun0 opened
Tue Jan 22 15:20:55 2019 TUN/TAP TX queue length set to 100
Tue Jan 22 15:20:55 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Jan 22 15:20:55 2019 /sbin/ip link set dev tun0 up mtu 1500
Tue Jan 22 15:20:55 2019 /sbin/ip addr add dev tun0 local 172.32.0.6 peer 172.32.0.5
Tue Jan 22 15:20:55 2019 /sbin/ip route add 10.1.0.0/24 via 172.32.0.5
Tue Jan 22 15:20:55 2019 /sbin/ip route add 172.32.0.0/24 via 172.32.0.5
Tue Jan 22 15:20:55 2019 Initialization Sequence Completed

A review of "ip ad" for a failed connection shows that the tun is partially created but not in its entirety.

19: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 100 link/none

Manually creating the ip address and routes does not help.

A successful tun looks like
20: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100

link/none
inet 172.32.0.6 peer 172.32.0.5/32 scope global tun0

valid_lft forever preferred_lft forever

inet6 fe80::5280:9a6b:7d5c:e8d7/64 scope link flags 800

valid_lft forever preferred_lft forever

I would appreciate if you could advise why this is happening when the yubikey is attached. and whether there is any work-around?

Glad to supply more info if required.

PS - I have confirmed that the same yubikey with the attached keys/certs works with OpenVPN on windows 10.

[BigDog]

Working ovpn file

[BigDog]

pkcs11 ovpn file not working

[BigDog]

Verb 5 output from openvpn command

[BigDog]

Hi

Thanks for assigning ownership to review this case. I have done some further testing and switched the cert/private key to a passwd controlled slot (9a) on the YubiKey? and the behaviour is different to that when the key/cert is on slot (9e). In this situation the openvpn hangs at, potentially, the point where the PIN for the yubikey is expected to be entered. I have included a further verb 5 output with strace details in the file openvpn.output-verb5-additionalinfo for your expert perusal.

Thanks

[BigDog]

Hi - Was this bug fixed pls?

Thanks

BigDog?

[Gert Döring]

Since this is CentOS, and pkcs11 - to @dazo. You might know.

[Gert Döring]

bump

[Gert Döring]

My guess is that this is related to forking (to run the "ip add" command), which interferes with pkcs11-helper stuff.

I *also* assume that this bug is fixed, because the whole "forking and pkcs11" topic was addressed in a few patches, early in the 2.4 series.

I can't test this myself, though. I'm not using pkcs#11 tokens, and I'm not using CentOS.

So it would be good to have feedback if current 2.5.x works with pkcs#11 on CentOS - up-to-date packages are in the EPEL repository (one noteworthy aspect of 2.5 is also that it can use netlink to do interface+route configuration, so even if the fork() problem is not fixed, 2.5 would sidestep the issue due to "fork not needed")