2015-10-02 18:11 GMT+03:00 Jan Just Keijser <janj...@nikhef.nl>: > 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. >
Not in Russia. There is some censorship here but nobody ban VPN (yet). > > 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 >
------------------------------------------------------------------------------
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
