client-connect script blockes openvon server

[cfasnacht]

I had an issue with Openvpn server. We call a dns update script in which the curl takes 5 seconds, during the execution of this script all traffic on the openvpn server is blocked, or not processed.
I see this when I run a nload tun0. There is absolutly no traffic during the execution of the script. This leads to arround 3% Ping loss, UDP packages errors and UDP buffer errors.
If I have an open ssh connection over the VPN server the session hangs for the 5 seconds.

Openvpn software version: OpenVPN 2.4.3 x86_64-redhat-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 4 2018

I use a client-connect script : /etc/openvpn/scripts.sh

This script then calls a DNS update script:
# /etc/openvpn/scripts.sh
/etc/openvpn/dns_update.sh

In this script we execute a curl on Infoblox that takes 5 seconds until it returns an answer.
# /etc/openvpn/dns_update.sh

curl ​ https://example ....

In my opinion this is very severe, because most users would not even have notices this because the client-connect script would not have taken forever. They would just have package loss or session lag. I would not have found this if the execution of the script would have been just 1 or 2 seconds.
This work arround once noticed, is quite easy just add a & at the end of the dns_update.sh

[Gert Döring]

This is the way it is today and has been since ever.

A patch set to be able to do client-connect asynchronously is being worked on, but will not hit 2.4 (as this is fairly intrusive).

For the time being, this can be worked around by using a auth-user-pass-verify plugin that does deferred (async) authentication, creating the necessary files for the client-connect phase while at it.

[Gert Döring]

The patchset has been merged into "git master" a few weeks ago.

@cfasnacht: for your use case, you already found the workaround - just for this into the background. For other use cases, where you want feedback "has this worked? shall we block the user on failure?" this can now also be done.

I am closing this ticket as the workaround for the "easy case" has been properly documented now (here), and the necessary code for the "complicated case" has been written, tested and merged.