Hi Thibault, There might be countless reasons for that you described.
Personally, I met with them twice. One irregular returning, was caused by an unstable DNS-server, causing random delays. The other was caused by the single-thread auth architecture of openvpn, where the connection set-up by one client, caused unpleasantries for other clients. Drastically limiting the number of clients per process was the answer to that… Kind regards, Hans From: Thibault JY Derrien <derr...@fzu.cz> Sent: Sunday, July 4, 2021 8:44 PM To: openvpn-users@lists.sourceforge.net Subject: [Openvpn-users] OpenVPN freezes few seconds after each connection Dear OpenVPN community, I'm writing as I obtain a systematic freeze on a production machine today. Problem is that is gets frozen systematically few seconds after connection. It is not the first time and seem to be random. This is preventing any remote work to be performed on the machine at the moment (urgent task needed). I'm using OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 27 2021 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 1/ From verbose = 5, freezing can be evidenced in the LOG below. Sun Jul 4 20:14:40 2021 us=254348 Initialization Sequence Completed WrWrWrWRwrWrWRwrWRwrWRwRwrWrWRwRwRwrWRwrWRwrWrWRwrWrWrWRwrWRwrWRwrWRWrWRwrWRwrWRwrWRWRrWRwrWrWRwrWRwrWRwrWRWRWffrWRwrWrWRwrWRWWRWRrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWWrWWWrWWWWW Sun Jul 4 20:18:36 2021 us=233613 [server] Inactivity timeout (--ping-restart), restarting Sun Jul 4 20:18:36 2021 us=233829 TCP/UDP: Closing socket Sun Jul 4 20:18:36 2021 us=233888 SIGUSR1[soft,ping-restart] received, process restarting Sun Jul 4 20:18:36 2021 us=233915 Restart pause, 5 second(s) 2/ Using a ping-restart helps to mitigate the situation. However, the delay is far too long and destroys the workflow (120 s). I have tried to force it using various options: 2.1/ keepalive 1 10 ... but the delays are imposed by the server, as indicated below. Sun Jul 4 20:22:48 2021 us=696911 [server] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xx:1194 Sun Jul 4 20:22:49 2021 us=839159 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) WRRSun Jul 4 20:22:49 2021 us=851173 PUSH: Received control message: 'PUSH_REPLY,route [...] 255.255.255.0,dhcp-option DNS xx.xx.xx.xx [...], route 192.168.191.0 255.255.255.0,ping 10,ping-restart 120,ifconfig [...],peer-id 4,cipher AES-256-GCM As a result, it seems not possible to force the ping-restart from client side? 2.2/ Same effect is obtained if imposing ping-restart 10 ping-restart 10 ping 2 Sun Jul 4 20:38:18 2021 us=930677 PUSH: Received control message: 'PUSH_REPLY,[...] ping 10,ping-restart 120,ifconfig [...],peer-id 4,cipher AES-256-GCM' 2.3/ Trying: push "ping-restart 20" Sun Jul 4 20:41:12 2021 us=348560 PUSH: Received control message: 'PUSH_REPLY,route [...] ,ping 10,ping-restart 120,ifconfig [...],peer-id 2,cipher AES-256-GCM' 3/ I thought about MTU issues, but the server is imposing its own MTU values as well. I tried to customize the MTUs using the procedure given here: https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn This resulted in adding and trying the following lines in my ovpn config file (of course, they are commented here, none of these lines helps to improve situation, though). 3.1/ mssfix 1430 #value obtained by using the procedure given in above URL (sonassi.com) Result of this parameter seems to fail, as I see in log (verbose = 5): Sun Jul 4 20:30:26 2021 us=464060 OPTIONS IMPORT: adjusting link_mtu to 1625 3.2/ link-mtu 1558 #value provided by the server Sun Jul 4 20:32:02 2021 us=245042 OPTIONS IMPORT: WARNING: peer-id set, but link-mtu fixed by config - reducing tun-mtu to 1433, expect MTU problems Sun Jul 4 20:32:02 2021 us=248381 /sbin/ip link set dev tun0 up mtu 1505 3.3/ tun-mtu 1500 #value provided by the server Sun Jul 4 20:34:01 2021 us=961669 OPTIONS IMPORT: adjusting link_mtu to 1625 Sun Jul 4 20:34:01 2021 us=961720 Data Channel MTU parms [ L:1553 D:1450 EF:53 EB:406 ET:0 EL:3 ] Sun Jul 4 20:34:01 2021 us=962697 /sbin/ip link set dev tun0 up mtu 1500 3.4/ fragment 2 This option is not supported by the server. 4/ I wonder what can be done from this point. Next step would be to request administrator to decrease the MTU to e.g. 1430 ... but he would have to do it for all users, something I guess will not be accepted. I'm looking forward to any help / explanation. Thibault Derrien -- Thibault J.-Y. Derrien, PhD Senior Researcher. Leader of "Ultrafast Photonics" group. Main contact for Marie Curie RISE "ATLANTIC" Associate editor at Optics Express (Optical Society of America) Responsible for HPC projects at HiLASE. Websites: (i) http://www.quantumlap.eu/ (ii) http://www.hilase.cz/en/ (iii) http://www.atlantic-rise.eu/ Personal: https://sites.google.com/site/tjyderrien/ Department of Scientific Applications (Leader: Prof. N. M. Bulgakova) Room 201, HiLASE Centre, Institute of Physics Academy of Science of the Czech Republic (AS CR) Za Radnicí 828 25241 Dolní Břežany Czech Republic Landline (CZ) : +420 314 007 709 Skype: "cybertib" Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
