-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi,
there is very little, if anything at all, which can be done from the client side alone. You will require the assistance of your server admin. Regards R ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, July 4th, 2021 at 19:43, Thibault JY Derrien <derr...@fzu.cz> wrote: > 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" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBzBAEBCAAGBQJg4ggFACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ27NwgAvbN91lvFmIJiJJpPL+LrBnZ7+6bUi+SSNlYRLId8m7qWH5RJ X06WcDgWG0Kkf1njP1DxvHh7W/o2/cxa83MtUjUqQrfmapF3Ni376u4y4Lrw iY05FTha6UMNsGLoluIH4t9GdaDxOceRJdRAl0YWxDZuL4hkqCovGdU7HPzp DgT7LGMyDx+TtWh6/ueI3rJK8IObovPxZ7j+EteIgybe+RPBeTPhw6hu2JMU Ad1cX2RV8y4K/Eds0kWz2AzzT+x2TQDLKtIDhlLnPMNt7/wNih71/KZE1bqo /2omo0u0U57b8H0kv5EqjC4JrXNJcVNdwz/nDX/7KdrJzpYDsbM/Cg== =eT+y -----END PGP SIGNATURE-----
publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys
publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
