This reply is from my Outlook 2019 rather than the news reader. My latest 2-3 posts via Gmane News seem to have been blocked, they do not come through into the news reader. ☹ It started when I was asked to supply FULL logs and the post got too big...
-----Original Message----- From: Gert Doering <g...@greenie.muc.de> Sent: Saturday, 5 June 2021 11:26 To: Bo Berglund <bo.bergl...@gmail.com> Cc: openvpn-users@lists.sourceforge.net Subject: Re: [Openvpn-users] Client-to-client setup fails mysteriously... Hi, On Fri, Jun 04, 2021 at 09:40:28PM +0200, Bo Berglund wrote: > I changed the Windows and RPi cient configs to verb4 > Then I connected the RPi client and it succeeded. > Next I tried to connect teh Windows client but it failed as before just > hanging > until I disconnect. > > I don't know where to look for the RPi client log, do you know where it may be > located? If the RPi succeeds, the client log is not overly interesting. > Fri Jun 04 21:30:15 2021 us=301476 UDP link local: (not bound) > Fri Jun 04 21:30:15 2021 us=301476 UDP link remote: [AF_INET]95.192.35.35:1193 > Fri Jun 04 21:30:15 2021 us=301476 MANAGEMENT: >STATE:1622835015,WAIT,,,,,, > Fri Jun 04 21:30:40 2021 us=307700 SIGTERM received, sending exit notification > to peer It's sending packets, and nothing is coming back. I see that Selva commented on the server side logs that the server sees the first packet, and nothing after. Since there is a NAT box in between, this could be part of the problem - to figure that out, you need to go "deeper": run a packet trace (tcpdump, wireshark) on client and server - and possibly on that router - to see where packets get lost. For example, if the packet trace on the server sees "packet coming in, reply going out" and the client sees "packet sent to server, nothing coming back" the problem is outside OpenVPN. Gert --------------- Below is my reply to Selva, which did not come through to the newsreader --------- 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? Best Regards, Bo Berglund _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
