OpenVPN client 2.6.X private key password prompt

Virtual Private Networks OpenVPN
1

Users with OpenVPN community clients 2.5.7 are able to establish VPN connections to my ipFire server with their Road Warrior credentials. OpenVPN credentials were created on the server at various times, running various CU versions, including today (CU v. 182).

Using newer 2.6.X OpenVPN clients does not work. Users are prompted for private key passwords and fail to get beyond that prompt.

I’ve kept users on v. 2.5.7, waiting for OpenSSL to be upgraded on ipFire, which I gather it has been. But that hasn’t resolved the issue with 2.6.X clients for me. Suggestions?

2

It depends on what the clients are.

On Android 11 or earlier the android keystore does not recognise the Openssl3 certificates due to the newer SHA version used. Basically it tries to open the certificate, the password is accepted but it doesn’t understand the content and so comes back saying that the password was not accepted. It looks like the Android keystore will not be updated on Android 11 and on my phone Android 11 will not be upgraded to a higher version. A new phone would be required for that.

The Android keystore on Android 12 or 13 is able to understand the openssl3 certificate contents.

On my laptop I run the openvpn plugin on NetworkManager with openvpn-2.6.x and it is accepted with no problems at all.

Running an openvpn tunnel by using the openvpn commands directly on the command line also works with no problems on my laptop.

What clients are you having the problem with.

3

Thank you for your reply. My clients are all Windows 10 & 11 PCs. Users are not command-line savvy.

4

I’ve been having this problem for some time. None of the OpenVPN community Windows clients since at least v. 2.6.1 have worked.

5

Ah okay. Can’t really help then as i have no windows systems at all so can’t do any testing to investigate.

6

Hi John, maybe you find the solution in this thread: New OpenVPN 2.6.0 Client (Windows 10 64bit) fails to connect

7

Thanks for the tip, Martin. I edited my .ovpn config file like so:

#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto udp
remote xxx.xxx.xxx.xxx 1194
providers legacy default
pkcs12 barkingdoggy.p12
data-ciphers-fallback AES-256-CBC
auth SHA256
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name ipfire.domain.local name
auth-nocache
auth-token-user USER
auth-token TOTP
auth-retry interact
sndbuf 0
rcvbuf 0
reneg-sec 0

It (still) works using the 2.5.7 client software but not with 2.6.8… Here’s the log from the 2.6.8 client attempt to connect:

2024-01-30 13:35:30 Note: --data-cipher-fallback with cipher 'AES-256-CBC' disables data channel offload.
2024-01-30 13:35:30 OpenVPN 2.6.8 [git:v2.6.8/3b0d9489cc423da3] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Nov 17 2023
2024-01-30 13:35:30 Windows version 10.0 (Windows 10 or greater), amd64 executable
2024-01-30 13:35:30 library versions: OpenSSL 3.1.4 24 Oct 2023, LZO 2.10
2024-01-30 13:35:30 DCO version: 1.0.0
2024-01-30 13:35:30 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25345
2024-01-30 13:35:30 Need hold release from management interface, waiting...
2024-01-30 13:35:30 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:62143
2024-01-30 13:35:31 MANAGEMENT: CMD 'state on'
2024-01-30 13:35:31 MANAGEMENT: CMD 'log on all'
2024-01-30 13:35:31 MANAGEMENT: CMD 'echo on all'
2024-01-30 13:35:31 MANAGEMENT: CMD 'bytecount 5'
2024-01-30 13:35:31 MANAGEMENT: CMD 'state'
2024-01-30 13:35:31 MANAGEMENT: CMD 'hold off'
2024-01-30 13:35:31 MANAGEMENT: CMD 'hold release'
2024-01-30 13:35:31 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.10.10:1194
2024-01-30 13:35:31 Socket Buffers: R=[65536->65536] S=[65536->65536]
2024-01-30 13:35:31 UDPv4 link local: (not bound)
2024-01-30 13:35:31 UDPv4 link remote: [AF_INET]192.168.10.10:1194
2024-01-30 13:35:31 MANAGEMENT: >STATE:1706639731,WAIT,,,,,,
2024-01-30 13:35:31 MANAGEMENT: >STATE:1706639731,AUTH,,,,,,
2024-01-30 13:35:31 TLS: Initial packet from [AF_INET]192.168.10.10:1194, sid=5eec3eea 3d569807
2024-01-30 13:35:31 VERIFY OK: depth=1, C=US, ST=Ohio, L=New York, O=Test Corp, OU=IT, CN=Test Corp CA, emailAddress=john.redmond@testcorp.com
2024-01-30 13:35:31 VERIFY KU OK
2024-01-30 13:35:31 Validating certificate extended key usage
2024-01-30 13:35:31 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-01-30 13:35:31 VERIFY EKU OK
2024-01-30 13:35:31 VERIFY X509NAME OK: C=US, ST=Ohio, O=Test Corp, OU=IT, CN=ipFire.domain.local
2024-01-30 13:35:31 VERIFY OK: depth=0, C=US, ST=Ohio, O=Test Corp, OU=IT, CN=ipFire.domain.local
2024-01-30 13:35:31 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2024-01-30 13:35:31 [ipFire.domain.local] Peer Connection Initiated with [AF_INET]192.168.10.10:1194
2024-01-30 13:35:31 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-01-30 13:35:31 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-01-30 13:35:32 MANAGEMENT: >STATE:1706639732,GET_CONFIG,,,,,,
2024-01-30 13:35:32 SENT CONTROL [ipFire.domain.local]: 'PUSH_REQUEST' (status=1)
2024-01-30 13:35:32 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:Sm9obiBSZWRtb25k:VE9UUA==:One Time Token: 
2024-01-30 13:35:32 SIGUSR1[soft,auth-failure (auth-token)] received, process restarting
2024-01-30 13:35:32 MANAGEMENT: >STATE:1706639732,RECONNECTING,auth-failure (auth-token),,,,,
2024-01-30 13:35:32 Restart pause, 1 second(s)
2024-01-30 13:35:33 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.10.10:1194
2024-01-30 13:35:33 Socket Buffers: R=[65536->65536] S=[65536->65536]
2024-01-30 13:35:33 UDPv4 link local: (not bound)
2024-01-30 13:35:33 UDPv4 link remote: [AF_INET]192.168.10.10:1194
2024-01-30 13:35:33 MANAGEMENT: >STATE:1706639733,WAIT,,,,,,
2024-01-30 13:35:33 MANAGEMENT: >STATE:1706639733,AUTH,,,,,,
2024-01-30 13:35:33 TLS: Initial packet from [AF_INET]192.168.10.10:1194, sid=08197420 20c19cc4
2024-01-30 13:35:33 VERIFY OK: depth=1, C=US, ST=Ohio, L=New York, O=Test Corp, OU=IT, CN=Test Corp CA, emailAddress=john.redmond@testcorp.com
2024-01-30 13:35:33 VERIFY KU OK
2024-01-30 13:35:33 Validating certificate extended key usage
2024-01-30 13:35:33 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-01-30 13:35:33 VERIFY EKU OK
2024-01-30 13:35:33 VERIFY X509NAME OK: C=US, ST=Ohio, O=Test Corp, OU=IT, CN=ipFire.domain.local
2024-01-30 13:35:33 VERIFY OK: depth=0, C=US, ST=Ohio, O=Test Corp, OU=IT, CN=ipFire.domain.local
2024-01-30 13:35:34 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2024-01-30 13:35:34 [ipFire.domain.local] Peer Connection Initiated with [AF_INET]192.168.10.10:1194
2024-01-30 13:35:34 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-01-30 13:35:34 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-01-30 13:35:35 MANAGEMENT: >STATE:1706639735,GET_CONFIG,,,,,,
2024-01-30 13:35:35 SENT CONTROL [ipFire.domain.local]: 'PUSH_REQUEST' (status=1)
2024-01-30 13:35:40 SENT CONTROL [ipFire.domain.local]: 'PUSH_REQUEST' (status=1)
2024-01-30 13:35:46 SENT CONTROL [ipFire.domain.local]: 'PUSH_REQUEST' (status=1)
2024-01-30 13:35:51 SENT CONTROL [ipFire.domain.local]: 'PUSH_REQUEST' (status=1)
2024-01-30 13:35:56 SENT CONTROL [ipFire.domain.local]: 'PUSH_REQUEST' (status=1)

And here’s the server log for the same period:

[root@ipFire openvpn]# tail -f /var/log/messages | grep openvpn
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 TLS: Initial packet from [AF_INET]192.168.10.10:63145, sid=e9fab864 7911de95
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 VERIFY SCRIPT OK: depth=1, C=US, ST=Ohio, L=New York, O=Test Corp, OU=IT, CN=Test Corp CA, emailAddress=john.redmond@newcorp.com
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 VERIFY OK: depth=1, C=US, ST=Ohio, L=New York, O=Test Corp, OU=IT, CN=Test Corp CA, emailAddress=john.redmond@newcorp.com
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 VERIFY SCRIPT OK: depth=0, C=US, ST=Ohio, O=Test Corp, OU=IT Contractor, CN=John Redmond
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 VERIFY OK: depth=0, C=US, ST=Ohio, O=Test Corp, OU=IT Contractor, CN=John Redmond
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_VER=2.6.8
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_PLAT=win
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_TCPNL=1
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_MTU=1600
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_NCP=2
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_PROTO=990
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_LZO_STUB=1
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_COMP_STUB=1
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_COMP_STUBv2=1
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_GUI_VER=OpenVPN_GUI_11.46.0.0
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 peer info: IV_SSO=openurl,webauth,crtext
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 TLS: Username/Password authentication deferred for username 'Q!_'
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1569'
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1472', remote='tun-mtu 1500'
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Jan 30 13:35:31 ipFire openvpnserver[9764]: 192.168.10.10:63145 [John Redmond] Peer Connection Initiated with [AF_INET]192.168.10.10:63145
Jan 30 13:35:31 ipFire openvpnserver[9764]: MANAGEMENT: CMD 'client-deny 5 0 "CRV1" "CRV1:R,E:Sm9obiBSZWRtb25k:VE9UUA==:One\ Time\ Token:\ "'
Jan 30 13:35:31 ipFire openvpnserver[9764]: MULTI: connection rejected: CRV1, CLI:CRV1:R,E:Sm9obiBSZWRtb25k:VE9UUA==:One Time Token:
Jan 30 13:35:32 ipFire openvpnserver[9764]: 192.168.10.10:63145 PUSH: Received control message: 'PUSH_REQUEST'
Jan 30 13:35:32 ipFire openvpnserver[9764]: 192.168.10.10:63145 Delayed exit in 5 seconds
Jan 30 13:35:32 ipFire openvpnserver[9764]: 192.168.10.10:63145 SENT CONTROL [John Redmond]: 'AUTH_FAILED,CRV1:R,E:Sm9obiBSZWRtb25k:VE9UUA==:One Time Token: ' (status=1)
Jan 30 13:35:33 ipFire openvpnserver[9764]: 192.168.10.10:63146 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 30 13:35:33 ipFire openvpnserver[9764]: 192.168.10.10:63146 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 30 13:35:33 ipFire openvpnserver[9764]: 192.168.10.10:63146 TLS: Initial packet from [AF_INET]192.168.10.10:63146, sid=9516794b 08e598fb
Jan 30 13:35:33 ipFire openvpnserver[9764]: 192.168.10.10:63146 VERIFY SCRIPT OK: depth=1, C=US, ST=Ohio, L=New York, O=Test Corp, OU=IT, CN=Test Corp CA, emailAddress=john.redmond@newcorp.com
Jan 30 13:35:33 ipFire openvpnserver[9764]: 192.168.10.10:63146 VERIFY OK: depth=1, C=US, ST=Ohio, L=New York, O=Test Corp, OU=IT, CN=Test Corp CA, emailAddress=john.redmond@newcorp.com
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 VERIFY SCRIPT OK: depth=0, C=US, ST=Ohio, O=Test Corp, OU=IT Contractor, CN=John Redmond
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 VERIFY OK: depth=0, C=US, ST=Ohio, O=Test Corp, OU=IT Contractor, CN=John Redmond
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_VER=2.6.8
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_PLAT=win
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_TCPNL=1
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_MTU=1600
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_NCP=2
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_PROTO=990
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_LZO_STUB=1
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_COMP_STUB=1
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_COMP_STUBv2=1
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_GUI_VER=OpenVPN_GUI_11.46.0.0
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 peer info: IV_SSO=openurl,webauth,crtext
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 TLS: Username/Password authentication deferred for username ''
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1569'
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1472', remote='tun-mtu 1500'
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Jan 30 13:35:34 ipFire openvpnserver[9764]: 192.168.10.10:63146 [John Redmond] Peer Connection Initiated with [AF_INET]192.168.10.10:63146
Jan 30 13:35:35 ipFire openvpnserver[9764]: 192.168.10.10:63146 PUSH: Received control message: 'PUSH_REQUEST'
Jan 30 13:35:38 ipFire openvpnserver[9764]: 192.168.10.10:63145 SIGTERM[soft,delayed-exit] received, client-instance exiting
Jan 30 13:35:40 ipFire openvpnserver[9764]: 192.168.10.10:63146 PUSH: Received control message: 'PUSH_REQUEST'
Jan 30 13:35:46 ipFire openvpnserver[9764]: 192.168.10.10:63146 PUSH: Received control message: 'PUSH_REQUEST'
Jan 30 13:36:01 ipFire openvpnserver[9764]: 192.168.10.10:63146 PUSH: Received control message: 'PUSH_REQUEST'
Jan 30 13:36:07 ipFire openvpnserver[9764]: 192.168.10.10:63146 PUSH: Received control message: 'PUSH_REQUEST'
Jan 30 13:38:08 ipFire openvpnserver[9764]: 192.168.10.10:63146 [John Redmo
Jan 30 13:38:08 ipFire openvpnserver[9764]: 192.168.10.10:63146 SIGUSR1[sof
^C
[root@ipFire openvpn]#
1 Like
8

The logs look to both be indicating failures with the 2FA process. Does the connection get to the point where you have top enter the 2FA code and if so does it seem to complete successfully or does it stop before that?

2 Likes
9

With the 2.6.8 client, there is no prompt for the TOTP/2FA code.

10

That sounds like a problem with that client and 2FA.

Maybe they have changed how 2FA works with openvpn.

Does the changelog for the client versions since the last one that worked mention anything about changes to 2FA?

11

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/
Happy reads.

edit: this link is only for server, not for client configuration

12

I think that is only covering the server not the client that @barkingdoggy is using.

13

@pike_it the link you provided is the server specifications. 2FA never worked in any OpenVPN Connect client except the windows client, community edition. This means that the Community Edition is doing something different from the other clients, beyond the common specs. I think It would be more useful to go to the change log of the version that stopped working.

14

Change logs for community clients since 2.5.7 are silent about 2FA, TOTP and multi-factor authentication.

15

thanks to @cfusco and @bonnietwin for pointing out my mistake, I edited my post accordingly.

16

I would just like to confirm which OpenVPN client @barkingdoggy is using.

The msi files available here
https://openvpn.net/community-downloads

or the ones here for v2 or v3
https://openvpn.net/client/client-connect-vpn-for-windows/

17

Here’s a link to the client that works: https://swupdate.openvpn.org/community/releases/OpenVPN-2.5.7-I602-amd64.msi

Thanks.

18

CU182, no OTP,
Windows 10 Pro + Client Community 2.6.8,
connections work.

obraz

obraz
obraz718×163 22.6 KB

obraz

edit

A password was used when generating the certificate.

obraz
obraz692×63 871 Bytes

Regards

1 Like
19

We’re using OTP for added security.

Also, for most users, their private key is not encrypted. With the 2.5.7 client, there’s no prompt for the private key password when none is required. There is a prompt for the TOTP code. Once the code is entered the connection is established. With the 2.6.8 client, the prompt for the private key password always comes up, even when the key is not encrypted.

20

Have you tried entering the TOTP code when that prompt comes up?

I had the problem in the past with an ssh access over vpn with 2FA where I had an ssh certificate in the ssh agent so the password was already dealt with but the 2FA then opened a box with the text Enter password but it was expecting the TOTP code. It might depend on the exact code used for the 2FA.

The other possibility is that the newer client is expecting a secure certificate with a password and no longer accepts the password-less option.

All my openvpn certificates are done with a password and without 2FA so I have not used the password-less option for a long time and don’t use the 2FA.

1 Like