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 -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Client-to-client setup fails mysteriously...
Hi, On Fri, Jun 04, 2021 at 10:23:07PM +0200, Bo Berglund wrote: > 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. My gut feeling points to the NAT box. Especially if it "heals" itself after a few minutes. Not sure why that box would get into "I can only have one session to 1193" stuck mode, but it very much looks like it. You could move the server to 1193, and avoid the port translation on the NAT box. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Client-to-client setup fails mysteriously... (1/1)
On Fri, 4 Jun 2021 20:19:22 -0400, Selva Nair 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
Re: [Openvpn-users] Client-to-client setup fails mysteriously...
On Fri, 4 Jun 2021 20:19:22 -0400, Selva Nair 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
Re: [Openvpn-users] Openvpn install ubuntu 20.04 compile
> I believe you need rst2html or rst2man from docutils or docutils-common. It was actually established. So it's working right now. :) It gave an error, but I noticed that it works. Thank you for your interest. On Fri, Jun 4, 2021 at 7:08 PM tincantech wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > ‐‐‐ Original Message ‐‐‐ > On Friday, 4 June 2021 16:04, Gokan Atmaca wrote: > > > Hello > > > > I am getting an error as below in openvpn installation. what would be > > the reason ? > > > > make[5]: Leaving directory '/root/tmp1/openvpn/src/plugins/down-root' > > make[4]: Leaving directory '/root/tmp1/openvpn/src/plugins/down-root' > > make[4]: Entering directory '/root/tmp1/openvpn/src/plugins' > > make[5]: Entering directory '/root/tmp1/openvpn/src/plugins' > > make[5]: Nothing to be done for 'install-exec-am'. > > make[5]: Nothing to be done for 'install-data-am'. > > make[5]: Leaving directory '/root/tmp1/openvpn/src/plugins' > > make[4]: Leaving directory '/root/tmp1/openvpn/src/plugins' > > make[3]: Leaving directory '/root/tmp1/openvpn/src/plugins' > > Making install in tapctl > > make[3]: Entering directory '/root/tmp1/openvpn/src/tapctl' > > make[4]: Entering directory '/root/tmp1/openvpn/src/tapctl' > > make[4]: Nothing to be done for 'install-data-am'. > > make[4]: Leaving directory '/root/tmp1/openvpn/src/tapctl' > > make[3]: Leaving directory '/root/tmp1/openvpn/src/tapctl' > > make[3]: Entering directory '/root/tmp1/openvpn/src' > > make[4]: Entering directory '/root/tmp1/openvpn/src' > > make[4]: Nothing to be done for 'install-exec-am'. > > make[4]: Nothing to be done for 'install-data-am'. > > make[4]: Leaving directory '/root/tmp1/openvpn/src' > > make[3]: Leaving directory '/root/tmp1/openvpn/src' > > make[2]: Leaving directory '/root/tmp1/openvpn/src' > > Making install in sample > > make[2]: Entering directory '/root/tmp1/openvpn/sample' > > make[3]: Entering directory '/root/tmp1/openvpn/sample' > > make[3]: Nothing to be done for 'install-exec-am'. > > make[3]: Leaving directory '/root/tmp1/openvpn/sample' > > make[2]: Leaving directory '/root/tmp1/openvpn/sample' > > Making install in doc > > make[2]: Entering directory '/root/tmp1/openvpn/doc' > > Making install in doxygen > > make[3]: Entering directory '/root/tmp1/openvpn/doc/doxygen' > > make[4]: Entering directory '/root/tmp1/openvpn/doc/doxygen' > > make[4]: Nothing to be done for 'install-exec-am'. > > make[4]: Nothing to be done for 'install-data-am'. > > make[4]: Leaving directory '/root/tmp1/openvpn/doc/doxygen' > > make[3]: Leaving directory '/root/tmp1/openvpn/doc/doxygen' > > make[3]: Entering directory '/root/tmp1/openvpn/doc' > > Missing python-docutils - skipping man page generation > > make[4]: Entering directory '/root/tmp1/openvpn/doc' > > make[4]: Nothing to be done for 'install-exec-am'. > > /usr/bin/mkdir -p '/usr/local/share/doc/openvpn' > > /usr/bin/install -c -m 644 management-notes.txt gui-notes.txt > > '/usr/local/share/doc/openvpn' > > Missing python-docutils - skipping man page generation > > /usr/bin/mkdir -p '/usr/local/share/man/man8' > > /usr/bin/install -c -m 644 ./openvpn.8 '/usr/local/share/man/man8' > > /usr/bin/install: cannot stat './openvpn.8': No such file or directory > > make[4]: *** [Makefile:515: install-man8] Error 1 > > make[4]: Leaving directory '/root/tmp1/openvpn/doc' > > make[3]: *** [Makefile:773: install-am] Error 2 > > make[3]: Leaving directory '/root/tmp1/openvpn/doc' > > make[2]: *** [Makefile:606: install-recursive] Error 1 > > make[2]: Leaving directory '/root/tmp1/openvpn/doc' > > make[1]: *** [Makefile:615: install-recursive] Error 1 > > make[1]: Leaving directory '/root/tmp1/openvpn' > > make: *** [Makefile:915: install] Error 2 > > > > I believe you need rst2html or rst2man from docutils or docutils-common. > > > -BEGIN PGP SIGNATURE- > Version: ProtonMail > > wsBzBAEBCAAGBQJgulADACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec > 9muQuJ0Pcgf/VEEAZ8GcYHYNlmETEkcLlyys1w5Eb0E/yDR5HL0pQRf782gr > M16NGbxJsetHIzUFQajoCedR6qqZztoi8ms6ZNd9pHM2ToXrucdM1OaU/6Fu > fEHfNY4vC1bOUCCT6ZpoWNBoNKavXrDA/WUkcOLlBFW+QYQ+rr9HJirmF+PL > ehZKWZrfhkOo7VQKoV4jnM4f0UluNdoSnBCJLZPFhGwHhlXbQx6sw0elB+Fk > F0bCv9nJT3p2Rl6ty67ms719ah+HZTXPGnVVZj6QlSRZbag+z+qZU++qMuLG > qyyxtEROYkdFOS/5Ixk4TQMI55irM+cH3lXX+V6ue8uj/l5t5Z8Cfg== > =UJkD > -END PGP SIGNATURE- ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] log
Hello I want to keep the records of all the clients connected to the ovpn ip addresses for 1 year. How can I do that ? Thanks. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄ ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Client-to-client setup fails mysteriously...
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 Sent: Saturday, 5 June 2021 11:26 To: Bo Berglund 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 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
Re: [Openvpn-users] log
A way, although not perfect, is to implement the status log. You would have to back it up periodically and retain a year's copies. The limitation is that it is a snapshot of the status and you could easily miss a temporary connection. A better way would be to implement a client-connect script. -Original Message- From: Gokan Atmaca To: openvpn users list (openvpn-users@lists.sourceforge.net) Sent: Sun, Jun 6, 2021 7:33 am Subject: [Openvpn-users] log Hello I want to keep the records of all the clients connected to the ovpn ip addresses for 1 year. How can I do that ? Thanks. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄ ___ 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
Re: [Openvpn-users] Client-to-client setup fails mysteriously...
Hi, On Sat, Jun 05, 2021 at 11:35:39AM +0200, Bo Berglund wrote: > 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... The sf.net lists were acting up over the weekend. Seems to be back to normal now. Anyway, as I suggested: check with packet traces, check without the port translation 1193->1194. It smells like the NAT box is getting confused about things. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Client-to-client setup fails mysteriously...
On Sat, 5 Jun 2021 11:28:52 +0200, Gert Doering wrote: >On Fri, Jun 04, 2021 at 10:23:07PM +0200, Bo Berglund wrote: >> 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. > >My gut feeling points to the NAT box. Especially if it "heals" itself >after a few minutes. > >Not sure why that box would get into "I can only have one session to >1193" stuck mode, but it very much looks like it. > >You could move the server to 1193, and avoid the port translation on >the NAT box. > >gert While the GMane news service was down over the week-end (or possibly the actual openvpn-users mail list) I was also starting to think that something with the port number translation could be afoot here. Since I have a company OpenVPN server also available I added a new user to that for no-password login (in the ovpn file) and then used that server to check if it would work. It does not use port number change in the port forward rules... And it did work! So something at my test site router is not working correctly. Now I have confirmed this by reconfiguring the port forward rules on the test server so the incoming port number is also used on the ovpn server device. I had to modify the openvpn server ports to be the same as on the router port forward incoming of course. After a router and openvpn restart it now works as it should! So your suggestion was spot on! Much obliged, thank you! -- Bo Berglund Developer in Sweden ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Client-to-client setup fails mysteriously...
On Fri, 04 Jun 2021 20:17:59 +0200, Bo Berglund wrote: >What could be causing this strange behavior? ISSUE RESOLVED! >From Gert Doering: >My gut feeling points to the NAT box. Especially if it "heals" itself >after a few minutes. > >Not sure why that box would get into "I can only have one session to >1193" stuck mode, but it very much looks like it. > >You could move the server to 1193, and avoid the port translation on >the NAT box. And this was the problem all along! The router incoming port was different than the openvpn server used so the router port forward had to translate the port number and apparently it is only able to handle a single connection if that is done! Now changed the openvpn server ports to be the same as the incoming ports and use no port number translation. This works as intended! -- Bo Berglund Developer in Sweden ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Client-to-client setup fails mysteriously...
Hi, On Mon, Jun 07, 2021 at 08:17:24AM +0200, Bo Berglund wrote: > >You could move the server to 1193, and avoid the port translation on > >the NAT box. [..] > So something at my test site router is not working correctly. > > Now I have confirmed this by reconfiguring the port forward rules on the test > server so the incoming port number is also used on the ovpn server device. > I had to modify the openvpn server ports to be the same as on the router port > forward incoming of course. > > After a router and openvpn restart it now works as it should! > > So your suggestion was spot on! Glad to hear that it works now :-) And indeed, troubleshooting "openvpn does not connect / work" issues can sometimes be painful, if there are too many moving parts "in between". Like, NAT boxes, mobile ISPs with rate limiting on UDP or fragments, ... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
