Problem with otp in OpenVPN

Hi,

I’m having a problem implementing the OpenVPN OTP (maybe I don’t know how to do it).

I have the 197. I installed the OpenVPN Client 2.6.15 on my laptop running Windows 11. If I log in without enabling the OTP, I get in just fine. But when I enable the OTP, it doesn’t work.

I’ll post the log:

2025-10-16 10:46:03 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add ‘–data-ciphers-fallback BF-CBC’ to your configuration and/or add BF-CBC to --data-ciphers.
2025-10-16 10:46:03 OpenVPN 2.6.15 [git:v2.6.15/90bdd59a95170169] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Sep 22 2025
2025-10-16 10:46:03 Windows version 10.0 (Windows 10 or greater), amd64 executable
2025-10-16 10:46:03 library versions: OpenSSL 3.5.3 16 Sep 2025, LZO 2.10
2025-10-16 10:46:03 DCO version: 1.3.3
2025-10-16 10:46:06 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:46:06 ovpn-dco device [OpenVPN Data Channel Offload] opened
2025-10-16 10:46:06 UDP link local: (not bound)
2025-10-16 10:46:06 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:46:08 [bs.northsecure.es] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:46:08 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:TGVub3Zv:VE9UUA==:One Time Token:
2025-10-16 10:46:08 SIGUSR1[soft,auth-failure (auth-token)] received, process restarting
2025-10-16 10:46:12 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:46:12 ovpn-dco device [OpenVPN Data Channel Offload] opened
2025-10-16 10:46:12 UDP link local: (not bound)
2025-10-16 10:46:12 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:46:13 [bs.northsecure.es] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:47:13 AUTH: Received control message: AUTH_FAILED
2025-10-16 10:47:13 SIGUSR1[soft,auth-failure] received, process restarting
2025-10-16 10:47:19 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:47:19 ovpn-dco device [OpenVPN Data Channel Offload] opened
2025-10-16 10:47:19 UDP link local: (not bound)
2025-10-16 10:47:19 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:47:21 [bs.northsecure.es] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194
2025-10-16 10:48:19 AUTH: Received control message: AUTH_FAILED
2025-10-16 10:48:19 SIGUSR1[soft,auth-failure] received, process restarting
2025-10-16 10:48:29 ERROR: could not read Private Key username/password/ok/string from management interface
2025-10-16 10:48:29 Exiting due to fatal error

Does this happen to anyone else?

Cheers

:thinking: Are there appropriate lines in the OpenVPN client configuration file?

edit

I created a new connection and added a line to the configuration file

auth-user-pass

After adding auth-user-pass, a window appeared for entering the OTP token.

Regards

1 Like

Thanks for responding @tphz .

The weird thing is that it asks me for my password twice. I mean, I log in, it asks me for the password, it asks me for the OTP, and it asks me for the password again.

Is this normal? Why isn’t this line that has to be written by hand created automatically? Is it a bug?

Best regards and thanks again.

That line was accidentally removed in the creation of the openvpn-2.6.x compatible version as in CU197.

The line was put back in on 24th September into CU199.

Unfortunately no one highlighted the issue during the Testing phase of CU197.

1 Like

The auth-nocache line has also been removed in CU199.

This seems to have some weird effects on Windows clients using OpenVPN
2.6.14 where username/password popup appears after one hour. Since we
don’t use any real username/password authentication, we will have to
make sure that the client keeps using the fake data that we have added
to the configuration.

That should not be an issue for you as you are using version 2.6.15 with your windows client but removing it would just ensure no peculiar responses.

So from CU199 onwards clients will get auth-user-pass and no longer have auth-nocache

1 Like