Hi all, We're seeing some connection-resets to one of our clients since this morning that we do not quite understand. The client, which is behind a NAT, connected just fine until it went down this morning around 04:30.
It came back up around 06:00, at which time establishing a VPN connection no longer works. Instead, we're seeing this repeat itself indefinitely on verbosity level 5: Thu Oct 1 09:40:08 2015 us=92076 MULTI: multi_create_instance called Thu Oct 1 09:40:08 2015 us=92127 Re-using SSL/TLS context Thu Oct 1 09:40:08 2015 us=92160 LZO compression initialized Thu Oct 1 09:40:08 2015 us=92292 Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ] Thu Oct 1 09:40:08 2015 us=92324 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ] Thu Oct 1 09:40:08 2015 us=92364 Local Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' Thu Oct 1 09:40:08 2015 us=92377 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client' Thu Oct 1 09:40:08 2015 us=92400 Local Options hash (VER=V4): '3e6d1056' Thu Oct 1 09:40:08 2015 us=92419 Expected Remote Options hash (VER=V4): '31fdf004' Thu Oct 1 09:40:08 2015 us=92446 TCP connection established with [AF_INET]83.xx.xx.89:32949 Thu Oct 1 09:40:08 2015 us=92459 TCPv4_SERVER link local: [undef] Thu Oct 1 09:40:08 2015 us=92472 TCPv4_SERVER link remote: [AF_INET]83.xx.xx.89:32949 RThu Oct 1 09:40:09 2015 us=76404 83.xx.xx.89:32949 TLS: Initial packet from [AF_INET]83.xx.xx.89:32949, sid=d31598eb 072b702e WRRWRWRWWWWRWRWWWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWThu Oct 1 09:40:09 2015 us=445899 83.xx.xx.89:32949 Connection reset, restarting [0] Thu Oct 1 09:40:09 2015 us=445946 83.xx.xx.89:32949 SIGUSR1[soft,connection-reset] received, client-instance restarting Thu Oct 1 09:40:09 2015 us=446013 TCP/UDP: Closing socket Connecting to the server with any other client works, it seems to be only that one client that does not connect. The WRRWR… chars are short for what is more detailed on verbosity level 6 (just an excerpt): Thu Oct 1 09:36:31 2015 us=92983 TCP connection established with [AF_INET]83.xx.xx.89:6821 Thu Oct 1 09:36:31 2015 us=92991 TCPv4_SERVER link local: [undef] Thu Oct 1 09:36:31 2015 us=93002 TCPv4_SERVER link remote: [AF_INET]83.xx.xx.89:6821 Thu Oct 1 09:36:32 2015 us=80231 83.xx.xx.89:6821 TCPv4_SERVER READ [14] from [AF_INET]83.xx.xx.89:6821: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0 Thu Oct 1 09:36:32 2015 us=80289 83.xx.xx.89:6821 TLS: Initial packet from [AF_INET]83.xx.xx.89:6821, sid=e5e2123c aaf16c13 Thu Oct 1 09:36:32 2015 us=80344 83.xx.xx.89:6821 TCPv4_SERVER WRITE [26] to [AF_INET]83.xx.xx.89:6821: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0 Thu Oct 1 09:36:32 2015 us=94308 83.xx.xx.89:6821 TCPv4_SERVER READ [22] from [AF_INET]83.xx.xx.89:6821: P_ACK_V1 kid=0 [ 0 ] Thu Oct 1 09:36:32 2015 us=146026 83.xx.xx.89:6821 TCPv4_SERVER READ [114] from [AF_INET]83.xx.xx.89:6821: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=100 Thu Oct 1 09:36:32 2015 us=146096 83.xx.xx.89:6821 TCPv4_SERVER WRITE [22] to [AF_INET]83.xx.xx.89:6821: P_ACK_V1 kid=0 [ 1 ] Thu Oct 1 09:36:32 2015 us=146242 83.xx.xx.89:6821 TCPv4_SERVER READ [114] from [AF_INET]83.xx.xx.89:6821: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100 Thu Oct 1 09:36:32 2015 us=146284 83.xx.xx.89:6821 TCPv4_SERVER WRITE [22] to [AF_INET]83.xx.xx.89:6821: P_ACK_V1 kid=0 [ 2 ] Thu Oct 1 09:36:32 2015 us=444922 83.xx.xx.89:6821 TCPv4_SERVER READ [22] from [AF_INET]83.xx.xx.89:6821: P_ACK_V1 kid=0 [ 24 ] Thu Oct 1 09:36:32 2015 us=444981 83.xx.xx.89:6821 TCPv4_SERVER WRITE [114] to [AF_INET]83.xx.xx.89:6821: P_CONTROL_V1 kid=0 [ ] pid=28 DATA len=100 […] Server and client do seem to be communicating, yet, the server resets the connection. Or are we misinterpreting the ACKs we're seeing? We'd be grateful for any help or idea on what might be the cause of this. Unfortunately, we don't have physical access to the client, so we cannot, at least not at the current point in time, hard-reset the client device. Best regards, David Raison -- TenTwentyFour S.à r.l. W: www.tentwentyfour.lu T: +352 20 211 1024 F: +352 20 211 1023 9 av. des Hauts-Fourneaux 4362 Esch-sur-Alzette
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
