Client fails to connect with 2.5, succeeds with 2.4.9

[BrianKopp]

System information:
Arch Linux
Client Version (failing) 2.5.0-3
Client Version (succeeding) 2.4.9
Server Version 2.1.4b

Using autologin openvpn-client@… and user-specific login failed on version 2.5.0-3, had to revert to 2.4.9 to succeed.

Segment of client logs. Server logs showed auth succeeded, and then auth failed a few seconds later.

2020-11-05 23:18:00 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
2020-11-05 23:18:00 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-11-05 23:18:00 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-11-05 23:18:00 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-11-05 23:18:00 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:443
2020-11-05 23:18:00 Socket Buffers: R=[131072->200000] S=[16384->200000]
2020-11-05 23:18:00 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XXX:443 [nonblock]
2020-11-05 23:18:00 TCP connection established with [AF_INET]XXX.XXX.XXX.XXX:443
2020-11-05 23:18:00 TCP_CLIENT link local: (not bound)
2020-11-05 23:18:00 TCP_CLIENT link remote: [AF_INET]XXX.XXX.XXX.XXX:443
2020-11-05 23:18:00 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:443, sid=e6709db4 2241870f
2020-11-05 23:18:00 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-11-05 23:18:00 net_route_v4_best_gw query: dst 0.0.0.0
2020-11-05 23:18:00 net_route_v4_best_gw result: via 10.0.0.1 dev eno1
2020-11-05 23:18:01 VERIFY OK: nsCertType=SERVER
2020-11-05 23:18:01 VERIFY OK: depth=0, CN=OpenVPN Server
2020-11-05 23:18:01 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
2020-11-05 23:18:01 [OpenVPN Server] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:443
2020-11-05 23:18:02 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
2020-11-05 23:18:02 AUTH: Received control message: AUTH_FAILED
2020-11-05 23:18:02 SIGTERM[soft,auth-failure] received, process exiting

[Gert Döring]

The server is refusing this client.

So you need to check the server logs why it is failing - "Server logs showed auth succeeded, and then auth failed a few seconds later" this is a bit thin, it should normally log some more verbose indication what it dislikes.

I can guess that it's related to the --cipher related changes, but since you are talking about "autologin profiles", this sounds like OpenVPN Access Server, and that one should be giving you a more clear indication what it isn't liking.

So - more details needed.

• which version of what is running on the server?
• what does the server log say (--verb 3), in full detail?
• if it's the commercial version, OpenVPN Inc support should be able to help pinpoint the issue

[tct]

No reply in 11 months - Closed

[hakster]

I have seen this exact behaviour - a client connection log that reports just AUTH_FAILED when using a certain openvpn 2.5.x client profile, but if you use the exact same connection profile with an openvpn 2.4.x client, it connects fine. In my case, adding the below line to the client profile if using openvpn 2.5.x fixed it immediately:

cipher BF-CBC

[tct]

Do NOT use --cipher because it is deprecated, use --data-ciphers.

Do NOT use BF-CBC because it is not secure, change your Server configuration to use a secure cipher.

[hakster]

Indeed, good advice @tct - assuming of course that you can influence or reconfigure/upgrade the server (eg. might be a customer's server). Not always possible to do, at least immediately. It would have been better if OpenVPN 2.5.x clients could detect and explicitly warn about this condition, with the appropriate advice to upgrade the server (preferable) or use a cipher downgrade (quick, but not secure, not recommended). Instead, the connection fails and it looks just like an incorrect password or token was entered.

[Gert Döring]

Without seeing the server log, it's hard to give good advice here.

A 2.6 client might refuse to connect to a server that is only offering BF-CBC (but it would log something about "no common cipher, use ... to fix this"), but a 2.5.x client should connect just fine. With a 2.3 server, falling back to BF-CBC, with a 2.4 and higher server, negotiating AES-GCM.

It might be a server that is configured to use --opt-verify and --cipher BF-CBC. Such a server needs to be upgraded.

There is no way to incrementally move to more secure defaults(!) with servers that insists on clients having explicitly-configured insecure configs.

So, it would be really good to understand what is happening on the server side in this case (= see a server log with verb 3, with the server version).