openvpn3 session-start Ignores Your Credentials File

Connect with the 2.x client and the profile works; hand the same file to the 3.x client and it stops at a password prompt. Hand --auth-user-pass creds.txt to openvpn3 session-start and the result is the same, because the newer client has no stage that reads the file. The refusal is deliberate: credentials belong to a session, and a session is created by a service rather than by the process in your terminal. Choose between the interactive prompt and the autoload helper, and know what each one stores.

Why the saved file has nowhere to go

In the newer design, configuration management and session management are separate services talking over the system bus. That separation is what lets an ordinary user start a session without a privileged daemon reading a protected password file on their behalf. File-based credentials have no place in that model, because there is no daemon-side startup that would read them. The refusal is a consequence of the architecture, not a missing feature.

The old pattern is worth naming so it is easier to unlearn: a profile references a credentials file, and the daemon reads it when the tunnel starts. In the new model, credentials belong to a session and are supplied when that session begins. openvpn3 session-start --config work.ovpn prompts for them, and --auth-user-pass creds.txt is rejected because nothing in that path would open the file. Every 2.x recipe you find assumes a stage that no longer exists.

Configuration and site-local settings are also separated, which explains a second surprise. A profile can look complete while the connection it produces lacks routing and resolver configuration. Those pieces are applied as site-local settings, separately from the imported file.

The prompt path and the session it leaves

Supplying the password when the session starts is the intended workflow. The client prompts once, hands the credentials to the session backend, and continues:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Nothing is written to disk by that path. The session also keeps running after the terminal closes, which surprises people who expect the process to die with their shell. That is the point of moving session handling into a service. The session outlives the terminal that asked for it, and it has to be stopped explicitly.

For a workstation with a human in front of it, this is also the safest option, because there is no stored secret to protect or forget. It is unsuitable only where nobody is present to type.

Automation without a person at the keyboard

Where a machine has to connect without a person, the project ships openvpn3-autoload. It reads a directory of profiles and a matching descriptor per profile, and the descriptor supplies the credentials in plain text. The helper is a separate binary, usually at /usr/sbin/openvpn3-autoload, not a flag on session-start. Setting it up means creating the directory, copying the profile under the name the descriptor expects, and writing the descriptor.

A per-user setup looks like this, run as the account that will own the session. The directory mode keeps other local users out:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

The descriptor names the credentials and asks for an automatic start. Keep the password value out of version control:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Then invoke the helper once and confirm the session appears. The second command is the check, not another setup step:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

At boot, a packaged unit named openvpn3-autoload.service uses the system-wide directory /etc/openvpn3/autoload, not the per-user one. That location needs root ownership and a tighter mode, and the descriptor still holds the password in clear text. The trade-off is explicit: the password now sits on disk, so treat that directory as a secret, exclude it from off-host backups, and choose the interactive path whenever a person is present.

Bus failures that look like password failures

Some failures attributed to credentials are nothing of the kind. A permission error naming the service activation path means one of two things: the backend is not up, or the caller lacks permission to activate it. No profile edit will change either. Check the service state and the shipped bus policy before you touch the configuration.

The commands below separate the two. The first reports whether the backend is running; the second shows recent bus errors:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

The other frequent misread is a session that appears and then disappears at once. That pattern usually means the site-local settings were never applied, so the tunnel came up without the routes and resolver changes that make it useful. Read the sequence rather than the last line: whether the session was created, whether it reached a connected state, and whether it survived are three separate facts.

When the older client is still in use

The 2.x client still accepts a credentials file, and a keyring can answer its prompt without the secret ever reaching disk. A wrapper resolves the entry, so the file names the lookup rather than the password. This arrangement depends on an unlocked keyring, which a container with no login session or a unit that starts before anyone signs in cannot provide. The lookup tool then reports a collection it cannot write to, so the error looks like a credential fault when it is a keyring fault.

Before building any of that, check whether a keepalive setting in the profile removes the need to restart at all. A session that stays up never reaches the prompt you are trying to automate.