TLS key negotiation failed to occur in OpenVPN Windows 10 Client with OpenVPN Arch Linux Server

Question

I can't set up an OpenVPN client, the server is on a VPS Arch Linux and has another Arch Linux client that works without any problems.

Im trying to add to the network a OpenVPN client Windows 10, with the same .conf that Arch client. I've also tried changing the server to TCP and Port 443 for, the same thing happens.

server.conf:

port 1194
proto udp
dev tun
ca ca.crt
cert servername.crt
key servername.key
dh none
ecdh-curve secp521r1
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-crypt ta.key # tls-auth ta.key 0
#cipher AES-256-CBC
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1
cipher AES-256-GCM
auth SHA512
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA

client.conf:

client
dev tun
proto udp
remote IPADDRESS 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert proyectapc.crt
key proyectapc.key
remote-cert-tls server
tls-crypt ta.key # tls-auth ta.key 1
cipher AES-256-CBC
#cipher AES-256-GCM
auth SHA512
#tls-version-min 1.2
#tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
verb 3

The init log of OpenVPN server:

Wed Dec 18 04:10:15 2019 OpenVPN 2.4.8 [git:makepkg/3976acda9bf10b5e+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 30 2019
Wed Dec 18 04:10:15 2019 library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
Wed Dec 18 04:10:15 2019 ECDH curve secp521r1 added
Wed Dec 18 04:10:15 2019 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Dec 18 04:10:15 2019 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Dec 18 04:10:15 2019 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Dec 18 04:10:15 2019 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Dec 18 04:10:15 2019 ROUTE_GATEWAY 192.99.152.1
Wed Dec 18 04:10:15 2019 TUN/TAP device tun0 opened
Wed Dec 18 04:10:15 2019 TUN/TAP TX queue length set to 100
Wed Dec 18 04:10:15 2019 /usr/bin/ip link set dev tun0 up mtu 1500
Wed Dec 18 04:10:16 2019 /usr/bin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Wed Dec 18 04:10:16 2019 /usr/bin/ip route add 10.8.0.0/24 via 10.8.0.2
Wed Dec 18 04:10:16 2019 Could not determine IPv4/IPv6 protocol. Using AF_INET
Wed Dec 18 04:10:16 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed Dec 18 04:10:16 2019 UDPv4 link local (bound): [AF_INET][undef]:1194
Wed Dec 18 04:10:16 2019 UDPv4 link remote: [AF_UNSPEC]
Wed Dec 18 04:10:16 2019 MULTI: multi_init called, r=256 v=256
Wed Dec 18 04:10:16 2019 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Wed Dec 18 04:10:16 2019 ifconfig_pool_read(), in='terminator,10.8.0.4', TODO: IPv6
Wed Dec 18 04:10:16 2019 succeeded -> ifconfig_pool_set()
Wed Dec 18 04:10:16 2019 IFCONFIG POOL LIST
Wed Dec 18 04:10:16 2019 terminator,10.8.0.4
Wed Dec 18 04:10:16 2019 Initialization Sequence Completed

The init log of OpenVPN client:

Wed Dec 18 10:12:02 2019 OpenVPN 2.4.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 31 2019
Wed Dec 18 10:12:02 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Dec 18 10:12:02 2019 library versions: OpenSSL 1.1.0l  10 Sep 2019, LZO 2.10
Wed Dec 18 10:12:02 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Dec 18 10:12:02 2019 Need hold release from management interface, waiting...
Wed Dec 18 10:12:03 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Dec 18 10:12:03 2019 MANAGEMENT: CMD 'state on'
Wed Dec 18 10:12:03 2019 MANAGEMENT: CMD 'log all on'
Wed Dec 18 10:12:03 2019 MANAGEMENT: CMD 'echo all on'
Wed Dec 18 10:12:03 2019 MANAGEMENT: CMD 'bytecount 5'
Wed Dec 18 10:12:03 2019 MANAGEMENT: CMD 'hold off'
Wed Dec 18 10:12:03 2019 MANAGEMENT: CMD 'hold release'
Wed Dec 18 10:12:03 2019 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Dec 18 10:12:03 2019 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Dec 18 10:12:03 2019 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Dec 18 10:12:03 2019 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Dec 18 10:12:03 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]IPADDRESS:1194
Wed Dec 18 10:12:03 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Dec 18 10:12:03 2019 UDP link local: (not bound)
Wed Dec 18 10:12:03 2019 UDP link remote: [AF_INET]192.99.152.152:1194
Wed Dec 18 10:12:03 2019 MANAGEMENT: >STATE:1576660323,WAIT,,,,,,
Wed Dec 18 10:12:03 2019 MANAGEMENT: >STATE:1576660323,AUTH,,,,,,
Wed Dec 18 10:12:03 2019 TLS: Initial packet from [AF_INET]192.99.152.152:1194, sid=580c2d02 8fcff9b9

So, this provokes on the server:

Wed Dec 18 04:12:03 2019 IPCLIENT:55713 TLS: Initial packet from [AF_INET]IPCLIENT:55713, sid=73a94d7c de9e850e
Wed Dec 18 04:12:03 2019 IPCLIENT:55713 TLS error: The server has no TLS ciphersuites in common with the client. Your --tls-cipher setting might be too restrictive.
Wed Dec 18 04:12:03 2019 IPCLIENT:55713 OpenSSL: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
Wed Dec 18 04:12:03 2019 IPCLIENT:55713 TLS_ERROR: BIO read tls_read_plaintext error
Wed Dec 18 04:12:03 2019 IPCLIENT:55713 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 18 04:12:03 2019 IPCLIENT:55713 TLS Error: TLS handshake failed
Wed Dec 18 04:12:03 2019 IPCLIENT:55713 SIGUSR1[soft,tls-error] received, client-instance restarting

And after 1 minute, the client:

Wed Dec 18 10:13:03 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Dec 18 10:13:03 2019 TLS Error: TLS handshake failed

What happens when you comment out `cipher` and `tls-cipher` parameters on both the server and client? I.e allow them to negotiate with the defaults — Alastair McCormack, Dec 18 '19 at 09:32
when I comment on both encrypted and tls-cipher in client and server parameters works ok — Fco Javier Balón, Dec 18 '19 at 09:44
Ok, it sounds like your Windows and Arch version have different ciphers compiled in. OpenVPN will still negotiate on a secure cipher. Is this acceptable or must you use a specific cipher? — Alastair McCormack, Dec 18 '19 at 09:51
I understand... if I keep ``cipher`` and ``tls-cipher`` commented on server and client, ``openvpn`` will use a default insurance? — Fco Javier Balón, Dec 18 '19 at 09:54
According to https://www.ivpn.net/knowledgebase/223/What-is-the-default-encryption-cipher-for-VPN-connections.html, 2.4.x will use AES-256-GCM. If you increase your logging level on both sides then you should see the agreed cipher and available ciphers. — Alastair McCormack, Dec 18 '19 at 09:59
Awesome, thanks! if you answer the question, I will be happy to mark it as a solution. — Fco Javier Balón, Dec 18 '19 at 10:02

score 1 · Accepted Answer · answered Dec 18 '19 at 10:04

1

Unless you really need specific ciphers, you can comment out the cipher and tls-cipher parameters from both client and server configuration.

OpenVPN will then negotiate using the standard set of secure ciphers.

answered Dec 18 '19 at 10:04

Alastair McCormack

2,184
1
15
22

TLS key negotiation failed to occur in OpenVPN Windows 10 Client with OpenVPN Arch Linux Server

1 Answers1