openvpn3-systemd support for web authentication

[danielrivard]

I have tried to use openvpn3-systemd on my profile which needs web authentication.

However, it does not try to open a browser window, it just sticks at
openvpn3-systemd[15884]: 2022-09-01 21:09:49.485273 [STATUS] (StatusMajor.SESSION, StatusMinor.SESS_AUTH_URL) https://{MY_ORGANISATION}.openvpn.com/connect?embedded=true&node_id=.....

Manually opening the link (and authenticating) found in journalctl enables the rest of the flow to continue.

openvpn3-systemd[15884]: 2022-09-01 21:13:12.318508 Connected: {CONNECTION DETAILS}
openvpn3-systemd[15884]: 2022-09-01 21:13:12.318574 [STATUS] (StatusMajor.CONNECTION, StatusMinor.CONN_CONNECTED)

This is on Pop!_OS 22.04.

Is this a bug, or is this just not supported yet?
Or is it just not possible to call for a browser window from within systemd's process?

[dsommers]

Hey!

Starting VPN sessions via systemd is typically done to start sessions during boot; where there is no browser available. But it's not completely unsupported - the authentication can happen later on, the OpenVPN session will just not start until authentication has completed.

In v17_beta, the openvpn3 session-auth command was added. This aims to help authentications which has not completed yet.

$ openvpn3 session-auth --help
openvpn3: session-auth - Interact with on-going session authentication requests

   -h | --help                 - This help screen
        --auth-req ID          - Continue the authentication process for the given auth request ID

This command can be run without arguments, where it will list all running VPN sessions waiting for authentication to happen in some way or another. This list will contain an ID. By running openvpn3 session-auth --auth-id ${ID}, a browser will be attempted to be started for webauth or display the authenticaiton URL if a browser could not be started.

[danielrivard]

Thank you.
I guess I may just be trying to misuse the tool.

I'll try to explain. My ultimate goal was to try to implement a GUI workaround to start my VPN, so I found this gnome extension to which I can configure a bash script handling start/stop.

#!/bin/bash
if [ -z $1 ]
then
        exit 1
fi

if [ $1 == "start" ]
then
        openvpn3 session-start --config office-vpn
fi

if [ $1 == "stop" ]
then
        openvpn3 session-manage --config office-vpn --disconnect
fi

if [ $1 == "ip" ]
then
    ip -j addr show tun0 | jq -r '.[] | select(any(.flags[]; . == "UP")) |.addr_info|.[]|.local'
fi

It actually works relatively well as is, except for some times where I am able to hit the toggle button multiple times before authentication is completed and so multiple sessions start in parallel. So when comes the time to disconnect, the call to stop does not work because --disconnect detects multiple sessions and so it needs a specific --path to know which one to stop.

Then I found the [email protected] systemd unit, which I thought would help prevent multiple instances running at the same time. It almost worked except it never asked the browser to initiate the web auth.
(I symlink in my home dir ~.config/systemd/user/[email protected] -> /lib/systemd/system/[email protected] so my user can start it systemctl --user start openvpn3-session@office-vpn)

I guess one option would be to add a simple check in the start command to detect if there is already a session running, and prevent it from starting another one.

One option I tried was to set --timeout on the openvpn3 session-start command but it does not seem to actually timeout session still waiting for authentication.

--disconnect --cleanup did not work either, as I guess those sessions are not considered staled at this point.

So, long story short, I'll try to just prevent my little script from starting multiple sessions.

Maybe a feature request to add a way to disconnect all sessions linked to the provided --config name. But that might not be an actual wanted behaviour.

[danielrivard]

Little update trying to play with session-auth, it seems calling it too fast results in a D-Bus timeout.

openvpn3 session-auth --auth-req 143330
Continuing authentication for session office-vpn
Session path: /net/openvpn/v3/sessions/91a3cc0dse3f6s4a89sa697s907472342013

** ERROR ** Failed to start new session: Failed calling D-Bus method Connect: Timeout was reached

And the session state seems broken.

$ openvpn3 sessions-list
-----------------------------------------------------------------------------
        Path: /net/openvpn/v3/sessions/91a3cc0dse3f6s4a89sa697s907472342013
     Created: Fri Sep  2 19:14:55 2022                  PID: 143330
       Owner: daniel                                 Device: (None)
 Config name: office-vpn
      Status: (No status)
-----------------------------------------------------------------------------

Waiting ~10 secs and it works fine.

But again, I may be working out of the specs.

[danielrivard]

It would be nice if openvpn3 session-auth and openvpn3 sessions-list could have a --json output like the stats command.
Parsing the output would be much easier.

[dsommers]

Alright, now I see more what you're doing and expecting.

First, the issue you describe seems odd. No status and no device indicate that the backend VPN process died/crashed or somehow got lost. That should not be related to the main issue in this discussion.

But I would recommend you to have a look at using a different approach than the openvpn3 command line directly in this case. OpenVPN 3 Linux has a few front-end programs (openvpn2, openvpn3, openvpn3-as, openvpn3-systemd) and then several backend services (config manager, session manager, logger, network configuration). The communication between these back-ends and front-ends goes via D-Bus. And out of all the front-end programs, openvpn3 is the only one written in C++. The rest are written in Python.

OpenVPN 3 Linux ships with it's own openvpn3 Python module, which should provide most functionality needed to manager both configurations and sessions. I would recommend to have a look at the openvpn3-systemd and a few of the Python test programs, like the start-tunnel2.py and configimport.py.

Using that approach will give you far better fine-grained control for your own management front-end.