How to use Deferred client-connect

Marc05

New in OpenVPN 2.5 is "Deferred client-connect":
https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst

The --client-connect option and the connect plugin API allow asynchronous/deferred return of the configuration file in the same way as the auth-plugin.

It sounded as if current implementations of client-connect would be able to take advantage of this async functionality, but that is not the case. I'm wondering if there's any examples or documentation on this. From what I can tell, it seems as if a new plugin has to be built and used:
https://github.com/OpenVPN/openvpn/tree/master/sample/sample-plugins

TinCanTech

https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/script-options.rst

Marc05

Thank you!

If I understand correctly, then it would look something like this:

if client-connect
   run $script in background
   echo 2 >> ${client_connect_deferred_file} # deferred
   exit 0
 
within $script:
   # do async stuff
   echo 1 >> ${client_connect_deferred_file} #success; client connects
   exit

Is that right?

TinCanTech

Read it again. a bit more carefully.

Marc05

I've read it a handful of times.

Is it that I'm missing something with "client_connect_config_file"? My reasons for not using it are it says "(optional, if per-session configuration is desired)" and I'm not entirely sure what configuration I would write to it.

Or perhaps you're referring to an issue with this line "echo 1 >> ${client_connect_deferred_file} #success; client connects", which I included because it said ""when finished, write the a 1 to this file".

Or maybe is none of those!

TinCanTech

Your first script above would probably work, Have you tested it yet ?

Marc05

Yeah it works. Granted there's a lot of error handling that needs to be done with the pseudocode, but that's why it's not actual code lol.

TinCanTech

If you are in the mood for experimenting the try this:
https://github.com/TinCanTech/easy-tls

Marc05

Thanks @TinCanTech!

There's something odd I've noticed; note that the server is using duplicate-cn.

Currently, the client-connect script will run some code which client-disconnect is supposed to undo. For the sake of discussion, let's say client-connect does:

touch /tmp/${username}_${trusted_port}.lock
# code to check for active client connections for this user and remove any lock files that don't match up.

and client-disconnect does:

rm -f /tmp/${username}_${trusted_port}.lock

The issue is that sometimes the .lock file isn't removed meaning the client-disconnect script was not called. The extra code in client-connect to remove the lock files helps, but it doesn't solve the scenario in which old user sessions have yet to time out (hence considered active and file not removed); this scenario is supposed to be dealt with client-disconnect which presumable gets run after the timeout.

This happens rarely (a few weeks has passed before it happened), but it's happened more than a handful of times now. Any thoughts on this?

TinCanTech

https://community.openvpn.net/openvpn/ticket/160

Marc05

I must admit, I had lost hope of figuring it out. Nice job with the troubleshooting there.

TinCanTech

I have been preparing a work around, which I intend to release soon:
https://github.com/TinCanTech/easy-tls

Marc05

Trying to understand the issue to have a workaround myself. It seems the issue isn't that the client-disconnect script doesn't get called, but rather with environment variables. From what I can tell, there is no issue with the username variable - correct? If so, I'm not clear on why the client-disconnect script doesn't work.

Marc05

Hmm, not able to edit the post.

I saw the commit there and it looks like you are falling back to using username if common_name fails. So if client-disconnect is indeed being called fine (but with sometimes incorrect env variables), then I'm not sure how I could be hitting that bug.

TinCanTech

Your script is triggering a known variant.

Marc05

Would you mind expanding on how? I read through the reports and I don't see the username variable being affected. The script I'm using only relies on $username, e.g.:
if [ -n "${username}" ]; then
# etc

TinCanTech

Marc05 wrote The script I'm using only relies on $username, e.g.:
if [ -n "${username}" ]; then
# etc

Marc05 wrote touch /tmp/${username}_${trusted_port}.lock
# code to check for active client connections for this user and remove any lock files that don't match up.

TinCanTech wrote Your script is triggering a known variant

Marc05 wrote Would you mind expanding on how?

It's complicated ..

Marc05

You probably understand the issue better than anyone in the world right now. If that's the best answer then I'm screwed lol.

TinCanTech

Simply use Easy-TLS

Marc05

Unfortunately things are indeed more complicated for me. I do appreciate the work though, thank you!