Automate 2FA client response?

[robross0606]

We have a situation where the server-side has implemented 2FA for all client connections. However, some clients open site-to-site tunnels using CLI automation. We have cli tools registered to generate the expected TOTP code, but have been unable to determine a means of scripting the generated TOTP submission during OpenVPN client connection. Is this possible with OpenVPN 2.x or 3.x?

[cron2]

How do you pass in the 2FA result? As "pseudo password"? Or as proper challenge-response reply?

If it's a pseudo-password, for 2.x, you can just generate a file with username+password in it and point the config to it (auth-user-pass /path/to/myauth.txt). With "proper" challenge-response, you might need to script the management interface to get the challenges and feed back the replies.

For 3.x, I have no idea, @dsommers knows.

[robross0606]

By "script the management interface" are you suggesting using something like expect?

[cron2]

I would never suggest the use of expect under any but the worst threats...

The OpenVPN management interface (for 2.x) is a fairly simple line-oriented API which can be used by programs like Tunnelblick on Mac or Windows-GUI on Windows to "talk to the openvpn core", get status information, and feed in authentication credentials (and answer challenges). See doc/management-notes.txt in the 2.x source tree.

It might be possible to do something with expect, but people have used all the languages around, most notably python and C to talk to the management interface. I'd probably use perl, but that's because it's my thing.

[robross0606]

Just for my own tracking purposes, the reference management-notes.txt file can be found here: https://github.com/OpenVPN/openvpn/blob/master/doc/management-notes.txt

[dsommers]

Okay, there's more things to tackle here.

First, it is not really a good practice to have site-to-site clients use username/password authentication - there are no "user" using the VPN tunnel, it is a "host" using it. So I would strongly recommend to look into the server side setup and read-up on the --auth-user-pass-optional option in the man-page. Such "host clients" should only use certificate based authentication. When using said option, the configuration file on these "host clients" can drop the auth-user-pass option from the config file. Taking this approach will make life a lot easier.

If you for some reason cannot avoid the username/password with OTP authentication, OpenVPN 3 Linux provides a Python module to easily write your own "front-end" to provide start the VPN session and provide user credentials. I would recommend you to have a look at the systemd integration; as I suspect you would want to use that approach to start the VPN automatically during boot. The code section dealing with retrieving user credentials can be found in openvpn3-systemd:281. This is called from line 232 in the Start method.

What I'm suggesting is that you create your own version of this Python script using a new filename under /usr/libexec/openvpn3-linux/ (or the similar location of your Linux distro). Then use systemctl edit openvpn3-session@CONFIGNAME.service and add these lines:

 [Service]
 ExecStart=/usr/libexec/openvpn3-linux/NEW_SCRIPT_NAME --start %i
 ExecReload=/usr/libexec/openvpn3-linux/NEW_SCRIPT_NAME --restart %i
 ExecStop=/usr/libexec/openvpn3-linux/NEW_SCRIPT_NAME --stop %i

With this in place, all you need to do now:

 # systemctl start openvpn3-session@CONFIGNAME.service

and it will hopefully work.

During testing and development, you can run the openvpn3-systemd script manually, using:

 # /usr/libexec/openvpn3-linux/NEW_SCRIPT_NAME --start CONFIGNAME

It will respond to SIGINT/CTRL-C to stop the tunnel.

[robross0606]

@dsommers, I understand the "best practice" point of view here. Also appreciate the extra info and recognition that, sometimes, we cannot always reach "best practice" goals in the short-term. This is all great info. Thank you for the suggestions!