I have an OpenVPN server on CentOS 7 that had been running for about 6 months. But since the last few days, I just can't connect to it anymore. No configuration has been changed, no version has been updated, nothing really. The server is running on CentOS 7 and is version 2.3.11:
OpenVPN 2.3.11 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on May 10 2016
I have confirmed that the service is running and listening on port 1194:
[root@vps257466 pki]# netstat -uap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:openvpn 0.0.0.0:* 13798/openvpn
The firewall rules allow for that port to enter:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:openvpn state NEW
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
All the certificates on the server are valid and not expired. On the server side I can see the packets coming on the wire using tcpdump.
When a client attempts to connect, I can confirm that it talks to the server because there's some activity in the log (I cranked the log level up to 6) and I can see my client connecting. There's no client certificate error reported (I replaced the real client IP address by one that doesn't exist for the purpose of anonymization):
Mon Aug 1 08:12:51 2016 us=429299 MULTI: multi_create_instance called
Mon Aug 1 08:12:51 2016 us=429550 186.296.344.411:44685 Re-using SSL/TLS context
Mon Aug 1 08:12:51 2016 us=429637 186.296.344.411:44685 LZO compression initialized
Mon Aug 1 08:12:51 2016 us=429886 186.296.344.411:44685 Control Channel MTU parms [ L:1542 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Mon Aug 1 08:12:51 2016 us=429903 186.296.344.411:44685 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:143 ET:0 EL:3 AF:3/1 ]
Mon Aug 1 08:12:51 2016 us=430021 186.296.344.411:44685 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Mon Aug 1 08:12:51 2016 us=430042 186.296.344.411:44685 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Mon Aug 1 08:12:51 2016 us=430069 186.296.344.411:44685 Local Options hash (VER=V4): '14168603'
Mon Aug 1 08:12:51 2016 us=430084 186.296.344.411:44685 Expected Remote Options hash (VER=V4): '504e774e'
Mon Aug 1 08:12:51 2016 us=430173 186.296.344.411:44685 UDPv4 READ [42] from [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Mon Aug 1 08:12:51 2016 us=430200 186.296.344.411:44685 TLS: Initial packet from [AF_INET]186.296.344.411:44685, sid=b5a632f8 60fc32b3
Mon Aug 1 08:12:51 2016 us=430238 186.296.344.411:44685 UDPv4 WRITE [54] to [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Mon Aug 1 08:12:52 2016 us=646343 186.296.344.411:44685 UDPv4 READ [42] from [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
Mon Aug 1 08:12:52 2016 us=646443 186.296.344.411:44685 UDPv4 WRITE [50] to [AF_INET]186.296.344.411:44685: P_ACK_V1 kid=0 pid=[ #2 ] [ 0 ]
Mon Aug 1 08:12:53 2016 us=633568 186.296.344.411:44685 UDPv4 WRITE [42] to [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
Mon Aug 1 08:12:57 2016 us=524182 186.296.344.411:44685 UDPv4 READ [42] from [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
Mon Aug 1 08:12:57 2016 us=524341 186.296.344.411:44685 UDPv4 WRITE [54] to [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #4 ] [ 0 ] pid=0 DATA len=0
Mon Aug 1 08:13:04 2016 us=684670 186.296.344.411:44685 UDPv4 READ [42] from [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
Mon Aug 1 08:13:04 2016 us=684805 186.296.344.411:44685 UDPv4 WRITE [50] to [AF_INET]186.296.344.411:44685: P_ACK_V1 kid=0 pid=[ #5 ] [ 0 ]
Mon Aug 1 08:13:05 2016 us=696178 186.296.344.411:44685 UDPv4 WRITE [42] to [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #6 ] [ ] pid=0 DATA len=0
Mon Aug 1 08:13:20 2016 us=894139 186.296.344.411:44685 UDPv4 READ [42] from [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0
Mon Aug 1 08:13:20 2016 us=894376 186.296.344.411:44685 UDPv4 WRITE [50] to [AF_INET]186.296.344.411:44685: P_ACK_V1 kid=0 pid=[ #7 ] [ 0 ]
Mon Aug 1 08:13:22 2016 us=86712 186.296.344.411:44685 UDPv4 WRITE [42] to [AF_INET]186.296.344.411:44685: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #8 ] [ ] pid=0 DATA len=0
Mon Aug 1 08:13:51 2016 us=901561 186.296.344.411:44685 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Aug 1 08:13:51 2016 us=901719 186.296.344.411:44685 TLS Error: TLS handshake failed
Mon Aug 1 08:13:51 2016 us=901970 186.296.344.411:44685 SIGUSR1[soft,tls-error] received, client-instance restarting
I'm not sure what all those "P_CONTROL_HARD_RESET_CLIENT[SERVER]_V2" are but all I know is that I can't open tunnels anymore. It's the same on three different computers so I'm thinking it must be something on the server side.
Any suggestions? I've spent hours on this, even re-installed the server from scratch.
