1

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 ?

Improve this question

2 Answers 2

Reset to default
5

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.

Improve this answer
1

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 :)

Improve this answer
3
  • SSL is just the previous version of what is now TLS...
    – vonbrand
    Apr 14, 2013 at 17:46
  • 1
    Welcome to ServerFault, Amir! This is not an answer to the questin that was asked. If you want to ask a question, please just click the Ask Question link in the top right corner.
    – Jenny D
    Apr 14, 2013 at 17:47
  • @JennyD It becomes an answer once you notice the posted IPs are in China.
    – sysadmin1138 ♦
    Apr 14, 2013 at 20:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .