Home / server / Questions / 479892
In Process
WoooHaaaa
Asked: 2013-02-19 02:56:03 +0800 CST

OpenVPN TLS key negotiation failed

  • 772

I've setup my OpenVPN server and client before and it works perfect last month.

But now i can't connect to the server without any config changing.

Here's the cilent side log(Win7):

Mon Feb 18 08:26:06 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Feb 18 08:26:06 2013 Re-using SSL/TLS context
Mon Feb 18 08:26:06 2013 LZO compression initialized
Mon Feb 18 08:26:06 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 18 08:26:06 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Feb 18 08:26:06 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 18 08:26:06 2013 Local Options hash (VER=V4): '41690919'
Mon Feb 18 08:26:06 2013 Expected Remote Options hash (VER=V4): '530fdded'
Mon Feb 18 08:26:06 2013 UDPv4 link local: [undef]
Mon Feb 18 08:26:06 2013 UDPv4 link remote: 106.187.96.123:1194
Mon Feb 18 08:27:06 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Feb 18 08:27:06 2013 TLS Error: TLS handshake failed
Mon Feb 18 08:27:06 2013 TCP/UDP: Closing socket
Mon Feb 18 08:27:06 2013 SIGUSR1[soft,tls-error] received, process restarting
Mon Feb 18 08:27:06 2013 Restart pause, 2 second(s)
Mon Feb 18 08:27:08 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Feb 18 08:27:08 2013 Re-using SSL/TLS context
Mon Feb 18 08:27:08 2013 LZO compression initialized
Mon Feb 18 08:27:08 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 18 08:27:08 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Feb 18 08:27:08 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 18 08:27:08 2013 Local Options hash (VER=V4): '41690919'
Mon Feb 18 08:27:08 2013 Expected Remote Options hash (VER=V4): '530fdded'
Mon Feb 18 08:27:08 2013 UDPv4 link local: [undef]
Mon Feb 18 08:27:08 2013 UDPv4 link remote: 106.187.96.123:1194
Mon Feb 18 08:28:08 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Feb 18 08:28:08 2013 TLS Error: TLS handshake failed
Mon Feb 18 08:28:08 2013 TCP/UDP: Closing socket
Mon Feb 18 08:28:08 2013 SIGUSR1[soft,tls-error] received, process restarting
Mon Feb 18 08:28:08 2013 Restart pause, 2 second(s)
Mon Feb 18 08:28:10 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Feb 18 08:28:10 2013 Re-using SSL/TLS context
Mon Feb 18 08:28:10 2013 LZO compression initialized
Mon Feb 18 08:28:10 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 18 08:28:10 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Feb 18 08:28:10 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 18 08:28:10 2013 Local Options hash (VER=V4): '41690919'
Mon Feb 18 08:28:10 2013 Expected Remote Options hash (VER=V4): '530fdded'
Mon Feb 18 08:28:10 2013 UDPv4 link local: [undef]
Mon Feb 18 08:28:10 2013 UDPv4 link remote: 106.187.96.123:1194

And this is the server side:

Mon Feb 18 00:43:19 2013 114.249.236.187:26913 SIGUSR1[soft,tls-error] received, client-instance restarting
Mon Feb 18 00:43:21 2013 MULTI: multi_create_instance called
Mon Feb 18 00:43:21 2013 114.249.236.187:26854 Re-using SSL/TLS context
Mon Feb 18 00:43:21 2013 114.249.236.187:26854 LZO compression initialized
Mon Feb 18 00:43:21 2013 114.249.236.187:26854 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 18 00:43:21 2013 114.249.236.187:26854 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 18 00:43:21 2013 114.249.236.187:26854 Local Options hash (VER=V4): '530fdded'
Mon Feb 18 00:43:21 2013 114.249.236.187:26854 Expected Remote Options hash (VER=V4): '41690919'
Mon Feb 18 00:43:21 2013 114.249.236.187:26854 TLS: Initial packet from 114.249.236.187:26854, sid=d04721a3 d361dccf
Mon Feb 18 00:44:21 2013 114.249.236.187:26854 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Feb 18 00:44:21 2013 114.249.236.187:26854 TLS Error: TLS handshake failed
Mon Feb 18 00:44:21 2013 114.249.236.187:26854 SIGUSR1[soft,tls-error] received, client-instance restarting
Mon Feb 18 00:44:23 2013 MULTI: multi_create_instance called
Mon Feb 18 00:44:23 2013 114.249.236.187:26855 Re-using SSL/TLS context
Mon Feb 18 00:44:23 2013 114.249.236.187:26855 LZO compression initialized
Mon Feb 18 00:44:23 2013 114.249.236.187:26855 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 18 00:44:23 2013 114.249.236.187:26855 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 18 00:44:23 2013 114.249.236.187:26855 Local Options hash (VER=V4): '530fdded'
Mon Feb 18 00:44:23 2013 114.249.236.187:26855 Expected Remote Options hash (VER=V4): '41690919'
Mon Feb 18 00:44:23 2013 114.249.236.187:26855 TLS: Initial packet from 114.249.236.187:26855, sid=d46a451d f7d88d11
Mon Feb 18 00:45:23 2013 114.249.236.187:26855 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Feb 18 00:45:23 2013 114.249.236.187:26855 TLS Error: TLS handshake failed
Mon Feb 18 00:45:23 2013 114.249.236.187:26855 SIGUSR1[soft,tls-error] received, client-instance restarting
Mon Feb 18 00:45:25 2013 MULTI: multi_create_instance called
Mon Feb 18 00:45:25 2013 114.249.236.187:26925 Re-using SSL/TLS context
Mon Feb 18 00:45:25 2013 114.249.236.187:26925 LZO compression initialized
Mon Feb 18 00:45:25 2013 114.249.236.187:26925 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 18 00:45:25 2013 114.249.236.187:26925 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 18 00:45:25 2013 114.249.236.187:26925 Local Options hash (VER=V4): '530fdded'
Mon Feb 18 00:45:25 2013 114.249.236.187:26925 Expected Remote Options hash (VER=V4): '41690919'
Mon Feb 18 00:45:25 2013 114.249.236.187:26925 TLS: Initial packet from 114.249.236.187:26925, sid=34f4dc94 f7092f67
Mon Feb 18 00:46:25 2013 114.249.236.187:26925 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Feb 18 00:46:25 2013 114.249.236.187:26925 TLS Error: TLS handshake failed
Mon Feb 18 00:46:25 2013 114.249.236.187:26925 SIGUSR1[soft,tls-error] received, client-instance restarting
Mon Feb 18 00:46:27 2013 MULTI: multi_create_instance called
Mon Feb 18 00:46:27 2013 114.249.236.187:26926 Re-using SSL/TLS context
Mon Feb 18 00:46:27 2013 114.249.236.187:26926 LZO compression initialized
Mon Feb 18 00:46:27 2013 114.249.236.187:26926 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Feb 18 00:46:27 2013 114.249.236.187:26926 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Feb 18 00:46:27 2013 114.249.236.187:26926 Local Options hash (VER=V4): '530fdded'
Mon Feb 18 00:46:27 2013 114.249.236.187:26926 Expected Remote Options hash (VER=V4): '41690919'
Mon Feb 18 00:46:27 2013 114.249.236.187:26926 TLS: Initial packet from 114.249.236.187:26926, sid=3dfa89e1 b1ff7f3a
^C
[root@li460-123 openvpn]#

Could anyone help ?

ssl

2 Answers

  1. From your logs, it looks like you're establishing an OpenVPN connection from China (114.249.236.187) to Japan (106.187.96.123). China has been aggressively blocking OpenVPN connections since November, and a lot of it looks to be based on protocol sniffing. In other words, they see packets with OpenVPN signatures coming through the Great Firewall and then they filter or alter remaining packets to block the connection. Typically, this behavior manifests as a timeout during the TLS negotiation sequence.

    In short, you didn't break anything. China did.

    You might try altering your OpenVPN server to use TCP rather than UDP for communication, or using a different port. That said, I've seen reports that any changes made to evade detection have been quickly nullified.

    • 5

  2. I'm from Iran, the problem is china and Iran both analyse packets through any port , when they detect TLS wana to works for establish a openvpn connection its corrupted automatically , I have set openvpn on tcp port 80 and it works only on iphone and ipad and the point is exactly here because iphone and ipad do't use TLS for authentication they use SSL, we should force client side on windows and Mac to use ssl instead of TLS to solve it then it would be very hard for them to block it , is there anyone who knows how it is possible?

    best wishes for free people around the world :)

    • 1