On Fri, 04 Jun 2021 19:49:36 +0000, tincantech via Openvpn-users <openvpn-users@lists.sourceforge.net> wrote:
>> I have set up an Openvpn server on a Raspberry Pi at a remote location I can >> access through another OpenVPN server. > >So: HOST:Client -> Server:HOST:Client -> Server:HOST I don't quite understand what you mean by this comment. What I wanted to say is that I heva two OpenVPN servers operational on the remote network. the origional one is what I use to access that remote network and I just mentioned it because I have a way to get to the remote network to inspect things NOT using the system I am working on now. But I am not connected to that VPN while doing these tests. >> 3. Now connect the RPi again to its (password-less) connection. >> 4. Connect the Windows 10 PC now fails with TLS negotiation error (timeout) >> 5. Close both connections. >> 6. Now again try to connect the RPi, but now it fails also on TLS as does >> the >> Windows 10 connection... >> >> 7. Go have dinner for some time... >> 8. Now back and can connect the RPi fine again! >> 9. But when the RPi is connected the Windows connection attempt fails with >> a TLS >> timeout error. >> >> What could be causing this strange behavior? > >That's not strange at all .. To me it is really strange that if I run an OVPN server and connect using a client on one computer, then the VPN server is no longer able to accept an incoming connection from another client computer (they use separate Common Names and separate keys and certs). In all of my 8 years of using OpenVPN servers on Raspberry Pi I have never seen such a block happening between clients. > >And now you have four logs to inspect at --verb 4. I guess you mean 3 logs? - The RPi server log - The Rpi client log - The Windows client log >You may have to forego dinner, in future. > I mentioned dinner just to indicate a pause with no activity during which the VPN server recovered.... Now I have made further tests and the failure pattern is repeatable: - Connect one client - Now the other clent cannot connect - Disconnect the first client - The second client cannot connect still - Now the first client also cannot connect anymore - Wait an as yet unspecified time in the range of 4-5 minutes or so - Now either of the two clients can connect. Concerning logs I already posted the Windows client log, but the RPi client apparently did not log anything anywhere I could find so I had to add a directive into the conf file to specify a log-append location. Then all user feedback when running the connect command vanished from the console, but afterwards I found a logfile containing a lot of message lines. The only items I find in the server log that can mean anything is this when trying to connect the RPi client while the Windows client is already connected: Fri Jun 4 21:50:55 2021 us=160902 MULTI: multi_create_instance called Fri Jun 4 21:50:55 2021 us=161247 158.174.104.130:44459 Re-using SSL/TLS context Fri Jun 4 21:50:55 2021 us=161341 158.174.104.130:44459 LZO compression initializing Fri Jun 4 21:50:55 2021 us=161776 158.174.104.130:44459 Control Channel MTU parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ] Fri Jun 4 21:50:55 2021 us=161878 158.174.104.130:44459 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Fri Jun 4 21:50:55 2021 us=162128 158.174.104.130:44459 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-au$ Fri Jun 4 21:50:55 2021 us=162208 158.174.104.130:44459 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize $ Fri Jun 4 21:50:55 2021 us=162379 158.174.104.130:44459 TLS: Initial packet from [AF_INET]158.174.104.130:44459, sid=99fc0e35 4c0bac25 Fri Jun 4 21:51:55 2021 us=2072 158.174.104.130:44459 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Fri Jun 4 21:51:55 2021 us=2301 158.174.104.130:44459 TLS Error: TLS handshake failed Fri Jun 4 21:51:55 2021 us=2674 158.174.104.130:44459 SIGUSR1[soft,tls-error] received, client-instance restarting Everything looks normal up until the TLS handshake, which fails. The previous RPi connection has this in the same position where it succeeds: Fri Jun 4 21:50:01 2021 us=71256 MULTI: multi_create_instance called Fri Jun 4 21:50:01 2021 us=71588 158.174.104.130:51803 Re-using SSL/TLS context Fri Jun 4 21:50:01 2021 us=71673 158.174.104.130:51803 LZO compression initializing Fri Jun 4 21:50:01 2021 us=71991 158.174.104.130:51803 Control Channel MTU parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ] Fri Jun 4 21:50:01 2021 us=72077 158.174.104.130:51803 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Fri Jun 4 21:50:01 2021 us=72297 158.174.104.130:51803 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-aut$ Fri Jun 4 21:50:01 2021 us=72366 158.174.104.130:51803 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 2$ Fri Jun 4 21:50:01 2021 us=72517 158.174.104.130:51803 TLS: Initial packet from [AF_INET]158.174.104.130:51803, sid=7b8bca62 d8037edd Fri Jun 4 21:50:01 2021 us=275558 158.174.104.130:51803 VERIFY OK: depth=1, C=US, ST=TX, L=Austin, O=AdvancedGeosciences, OU=IT, CN=AGIVPN, name=AGIVPN, emailAddress=x...@yyy.com At the point where the first connection succeeds using TLS the second fails, why is that? It really cannot be a client config problem because either client can connect if it is the first one after some undetermined idle time.... -- Bo Berglund Developer in Sweden _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
