Opened 2 years ago

Closed 16 months ago

#1244 closed Feature Wish (fixed)

client-connect script blockes openvon server

Reported by: cfasnacht Owned by: plaisthos
Priority: major Milestone: release 2.5
Component: Generic / unclassified Version: OpenVPN 2.4.3 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: Openvpn Server blocked blocked client-connect
Cc:

Description

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

Change History (2)

comment:1 Changed 2 years ago by Gert Döring

Milestone: release 2.4.3release 2.5
Owner: set to plaisthos
Status: newassigned
Type: Bug / DefectFeature Wish

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.

comment:2 Changed 16 months ago by Gert Döring

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.