OpenVPN – OpenVPN TLS Error: TLS Key Negotiation Failed

openvpn

I have two servers with exact same config. One of them works fine but the other gives TLS error!
None of the solutions mentioned in other threads worked…

Server Ubuntu 16.04

OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08

Server Config:

port 1398
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 4.2.2.4"
keepalive 10 120
tls-auth ta.key 0
key-direction 0
cipher none
auth SHA1
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Client Config:

client
dev tun
proto tcp
remote XX.XX.173.7 1398
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
cipher none
auth SHA1
key-direction 1
verb 3

UFW Status:

root@static:~# sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
1398/tcp                   ALLOW       Anywhere
1398/udp                   ALLOW       Anywhere
1398/tcp (v6)              ALLOW       Anywhere (v6)
1398/udp (v6)              ALLOW       Anywhere (v6)

Route Table:

root@static:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         static.1.173.9. 0.0.0.0         UG    0      0        0 ens32
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
root@static:~# ip route
default via XX.XX.173.1 dev ens32 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1

Server Log:

May 19 10:39:54 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [1184] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=1170
May 19 10:39:55 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [314] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=300
May 19 10:40:09 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [1184] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1170
May 19 10:40:10 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [1184] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=1170
May 19 10:40:11 static ovpn-server[2231]: 91.92.125.54:63515 TCPv4_SERVER WRITE [314] to [AF_INET]91.92.125.54:63515: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=300
May 19 10:40:37 static ovpn-server[2231]: 91.92.125.54:63515 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
May 19 10:40:37 static ovpn-server[2231]: 91.92.125.54:63515 TLS Error: TLS handshake failed
May 19 10:40:37 static ovpn-server[2231]: 91.92.125.54:63515 Fatal TLS error (check_tls_errors_co), restarting
May 19 10:40:37 static ovpn-server[2231]: 91.92.125.54:63515 SIGUSR1[soft,tls-error] received, client-instance restarting
May 19 10:40:37 static ovpn-server[2231]: TCP/UDP: Closing socket

Client Log:

Sun May 19 15:08:28 2019 NOTE: --user option is not implemented on Windows
Sun May 19 15:08:28 2019 NOTE: --group option is not implemented on Windows
Sun May 19 15:08:28 2019 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Sun May 19 15:08:28 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Sun May 19 15:08:28 2019 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Sun May 19 15:08:28 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun May 19 15:08:28 2019 Need hold release from management interface, waiting...
Sun May 19 15:08:29 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'state on'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'log all on'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'echo all on'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'bytecount 5'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'hold off'
Sun May 19 15:08:29 2019 MANAGEMENT: CMD 'hold release'
Sun May 19 15:08:29 2019 ******* WARNING *******: '--cipher none' was specified. This means NO encryption will be performed and tunnelled data WILL be transmitted in clear text over the network! PLEASE DO RECONSIDER THIS SETTING!
Sun May 19 15:08:29 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 19 15:08:29 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun May 19 15:08:29 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]5.9.173.7:1398
Sun May 19 15:08:29 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun May 19 15:08:29 2019 Attempting to establish TCP connection with [AF_INET]5.9.173.7:1398 [nonblock]
Sun May 19 15:08:29 2019 MANAGEMENT: >STATE:1558262309,TCP_CONNECT,,,,,,
Sun May 19 15:08:30 2019 TCP connection established with [AF_INET]5.9.173.7:1398
Sun May 19 15:08:30 2019 TCP_CLIENT link local: (not bound)
Sun May 19 15:08:30 2019 TCP_CLIENT link remote: [AF_INET]5.9.173.7:1398
Sun May 19 15:08:30 2019 MANAGEMENT: >STATE:1558262310,WAIT,,,,,,
Sun May 19 15:08:30 2019 MANAGEMENT: >STATE:1558262310,AUTH,,,,,,
Sun May 19 15:08:30 2019 TLS: Initial packet from [AF_INET]5.9.173.7:1398, sid=aa04c80d cadbb603
Sun May 19 15:08:30 2019 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=MyOrganizationalUnit, CN=Fort-Funston CA, name=EasyRSA, emailAddress=me@myhost.mydomain
Sun May 19 15:08:30 2019 VERIFY KU OK
Sun May 19 15:08:30 2019 Validating certificate extended key usage
Sun May 19 15:08:30 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun May 19 15:08:30 2019 VERIFY EKU OK
Sun May 19 15:08:30 2019 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=MyOrganizationalUnit, CN=server, name=EasyRSA, emailAddress=me@myhost.mydomain
Sun May 19 15:09:30 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun May 19 15:09:30 2019 TLS Error: TLS handshake failed
Sun May 19 15:09:30 2019 Fatal TLS error (check_tls_errors_co), restarting
Sun May 19 15:09:30 2019 SIGUSR1[soft,tls-error] received, process restarting
Sun May 19 15:09:30 2019 MANAGEMENT: >STATE:1558262370,RECONNECTING,tls-error,,,,,
Sun May 19 15:09:30 2019 Restart pause, 5 second(s)

and it is strange that in client log it says "VERIFY OK"

PS1:
A new finding is that while I CANNOT connect to the server with my cellphone over WiFi, the same device CAN connect with MOBILE DATA, and yet other mobile devices DON'T connect neither on WiFi nor MOBILE DATA!!!!!! Means Different ISPs Different results. And in all cases server sees the client and just fails to handshake TLS. BUT the other server works fine with exactly the same config with all devices!!!!

Best Answer

I see that you configured your server to use tcp.

As far as I understand, in order to use tls-auth directive, you must use "udp" protocol rather than "tcp".

From OpenVPN official documents:

The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

* DoS attacks or port flooding on the OpenVPN UDP port.
* Port scanning to determine which server UDP ports are in a listening state.
* Buffer overflow vulnerabilities in the SSL/TLS implementation.
* SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

Edit #1:

I believe you are missing a "push route" to the OpenVPN subnet, try adding that to your server.conf:

push "route 10.8.0.0 255.255.255.0" 

Also, if you want OpenVPN clients to be able to establish connection to other machine in your LAN, then add another push like so (replace 10.10.1.0 with your LAN cidr):

push "route 10.10.1.0 255.255.255.0"

Let me know how it works.