Hi, David Raison wrote: > 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. > > the log output you're seeing normally happens when the TCP connection is interrupted, either by the server (which you should see in the logs) or by a firewall or buggy router between the client and the server. If the client happens to be in a country like China, Iran or Russia then these things tend to happen as well.
HTH, JJK > 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 > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Openvpn-users mailing list > Openvpn-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-users > ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
