On Fri, 4 Jun 2021 20:19:22 -0400, Selva Nair <selva.n...@gmail.com> wrote:
>You can share large logs using some service like pastebin in pure text >format. Compressed logs are hard to look through. Well, I don't have any accounts with such services. I thought that by compressing the logs using 7zip and attaching the reulting files they could be expanded at the other end and readable (without line wrap too). IN any case my original post has not yet appeared so it was probably permanently blocked. >As per the logs the server gets the initial TLS packet from the second >client, but hears nothing after that. The client gets nothing back >from the server. So something is blocking the return path from the >server. And this something depends upon the server having established a valid connection to another client first... > >Do you know which client is triggering the HMAC error at the end of >the server log? This may be unrelated, though. It looks like the OpenVPN server is trying to re-establish a connection and fails. The IP address on the log lines is my home router's external address. Don't know why it is rotating the port number either. Or maybe it is the client on my end trying to establish a connection after the close? I can't read these logs well, though. Sat Jun 5 00:29:30 2021 us=336241 Authenticate/Decrypt packet error: packet HMAC authentication failed Sat Jun 5 00:29:30 2021 us=336502 TLS Error: incoming packet authentication failed from [AF_INET]158.174.104.130:52827 >Does your server have multiple interfaces? If yes, you will need to >add --multihome. Though the error in this case should be more random >than the systematic failure of the second connection. Otherwise try to >see what's going on the routers on both ends. Yes the RaspberryPi server is connected by Ethernet wired LAN, but the device also has a WiFi NIC on board and this is connected to the same router too. Where is --multihome used? In a conf file? If so are the hyphens really used? Anyway: I have now *disabled* wlan0 so the only interfaces are eth0 and tun0. Then I made a new attempt with the same dismal result... The RPi connection was first established and then the Windows client refused to connect... So the multi-home config seems to not be the cause. Another observation: -------------------- In the server log I see this when I try to connect the second client: Sat Jun 5 09:14:23 2021 us=819040 MULTI: multi_create_instance called Sat Jun 5 09:14:23 2021 us=819391 158.174.104.130:55766 Re-using SSL/TLS context <= WHY DOES THIS HAPPEN???? Sat Jun 5 09:14:23 2021 us=819485 158.174.104.130:55766 LZO compression initializing Sat Jun 5 09:14:23 2021 us=819908 158.174.104.130:55766 Control Channel MTU parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ] Sat Jun 5 09:14:23 2021 us=820007 158.174.104.130:55766 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Sat Jun 5 09:14:23 2021 us=820258 158.174.104.130:55766 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 15$ Sat Jun 5 09:14:23 2021 us=820338 158.174.104.130:55766 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,$ Sat Jun 5 09:14:23 2021 us=820509 158.174.104.130:55766 TLS: Initial packet from [AF_INET]158.174.104.130:55766, sid=61115e13 58$ Sat Jun 5 09:14:48 2021 us=565373 SSRemote001/158.174.104.130:34220 SIGTERM[soft,remote-exit] received, client-instance exiting Sat Jun 5 09:15:23 2021 us=325374 158.174.104.130:55766 TLS Error: TLS key negotiation failed to occur within 60 seconds (check $ Sat Jun 5 09:15:23 2021 us=325617 158.174.104.130:55766 TLS Error: TLS handshake failed Sat Jun 5 09:15:23 2021 us=326025 158.174.104.130:55766 SIGUSR1[soft,tls-error] received, client-instance restarting Sat Jun 5 09:15:49 2021 us=935494 Authenticate/Decrypt packet error: packet HMAC authentication failed Sat Jun 5 09:15:49 2021 us=935785 TLS Error: incoming packet authentication failed from [AF_INET]158.174.104.130:51665 Why is the server re-using an old SSL/TLS context when the second client tries to connect? The two clients are *different* computers and the only commonality they have is that they are on the same local network. Apart from using the same Internet router they are completely separate units. Can this be the cause of the problem and if so how to fix it? -- Bo Berglund Developer in Sweden _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
