With OpenVPN 3 Linux, as with most newer releases, the community has improved upon the security. One of the ways this is done is by increasing requirements around user credentials. This increased security has removed a feature used in OpenVPN 2.x clients where the username and password are provided via a credentials file. Due to this security change, we have received several bug reports about this as a missing feature. Rather than considering it a bug, we consider it unsupported. We are concerned about storing unencrypted user credentials in memory or on disk.
OpenVPN 3 Linux does support --auth-user-pass, where user credentials are provided when starting the VPN session. We do not support providing these credentials via a pre-saved file using the openvpn3 and openvpn2 command line options.
Why is this feature not supported?
OpenVPN 3 Linux provides both configuration and session management. This allows unprivileged users to start their own VPN sessions. They no longer need administrative privileges as were required with OpenVPN 2.x. Privilege separation is built into the main design. OpenVPN 3 Linux is also designed to run with as few privileges as possible. Each task runs in separate processes, where they can only communicate with each other via an interface with strict access policies. D-Bus handles this interface and policy management.
OpenVPN 2.x generation clients required admin privileges to start. After that, it can drop them. It also does not provide any VPN session or configuration management. A single process is a single VPN session and managing the configurations and sessions was fairly manual or done with external tools like the NetworkManager OpenVPN plug-in.
Because of this, we want to avoid storing as much user sensitive information as possible. As OpenVPN 3 Linux evolves, we will take new steps to handle other aspects of the user sensitive configuration, like private keys in the VPN configuration profile.
There is a workaround.
While we do try to be strict, we also realize that specific setups require user credentials to be provided when starting a VPN session. One typical use case could be starting a VPN session during boot, where the system would be otherwise inaccessible without the VPN session running.
For this scenario, we added the openvpn3-autoload utility. This is provided with its own systemd unit file to use this service easily during boot. This might not be suitable for end-users logging into a host locally. But this utility can also be used by unprivileged users, using a file directory where the user stores its VPN profiles.
This utility depends on a single directory where the VPN configuration profile is saved (using a .conf or .ovpn file extension). But it needs a support configuration file as well.
OpenVPN 3 configuration files and profiles
As OpenVPN 3 was developed, we realized it was a natural separation in the configuration profiles. One part is generic across all clients inside an OpenVPN domain. This option provides information about where to connect, credentials, encryption settings, etc. But the other part covered more how to connect to the remote server and how to handle certain aspects of network configuration settings pushed by the server, typically network routing and DNS settings. We call this the site-local configuration. The OpenVPN 3 Linux clients build upon this separation as well.
The content of the VPN configuration file provided by the VPN service provider is considered the generic configuration. And the openvpn3-autoload utility needs an .autoload file which contains the site-local settings. Together they form the VPN configuration profile you need to get a functional connection.
Configuring OpenVPN3 Autoload to provide user-credentials
We must first emphasize that it is not a good idea to save user credentials in clear-text on a harddrive. We generally recommend that you avoid using username/password-based authentication for starting VPN sessions automatically.
If you have no alternative, this is how you configure openvpn3-autoload to achieve an automated session start:
As mentioned, openvpn3-autoload can be started during system boot by enabling and starting the systemd openvpn3-autoload.service. In this case the default configuration directory is /etc/openvpn3/autoload. For unprivileged usage, any directory the user can access and read from is usable, preferably a well-protected home directory ($HOME). We will use the latter approach in this description.
First, create a reasonable directory for the autoload service:
$ mkdir -m700 -p $HOME/.openvpn3/autoload
This creates a directory in the users’ home directory, which only the user will have read/write access to. Inside this directory, save the VPN configuration profile you need to connect to the VPN service of your choice. The file must be a standard OpenVPN configuration file and must have the .conf or .ovpn file extension. In this text, we will expect this file to be called client.conf.
Next, we will need to create the configuration file for the autoload utility. This is a plain JSON file with an .autoload file extension. Since our VPN configuration file is called client.conf, the autoload configuration file must be named client.autoload. If this file does not exist, the autoload utility will not consider the VPN configuration profile at all.
The openvpn3-autoload configuration file is described in the openvpn3-autoload(8) man page, but we will only consider a few of the possible options here.
Your .autoload file will need this information:
The first autostart setting tells openvpn3-autoload to both import and start this configuration file. The user-auth section’s information should be fairly obvious; this is where you tell it to automatically log in and use the credentials defined.
Now all you need to do is to start the autoload utility:
$ /usr/sbin/openvpn3-autoload --directory $HOME/.openvpn3/autoload
Configuration "client.conf" imported: /net/openvpn/v3/configuration/6ab9b09dx429fx4816xae7fx6ac063cb5b40 
Auto-started "client.conf": /net/openvpn/v3/sessions/b2301e1csce93s4e4asb24cs21d4bd662510
The VPN session is now running and you can check the status using the normal openvpn3 session management commands:
$ openvpn3 sessions-list
Created: Mon Sep 7 12:00:41 2020 PID: 12248
Owner: jdoe Device: tun0
Config name: client.conf
Status: Connection, Client connected
OpenVPN 3 Linux and future enhancements.
This approach is a less ideal workaround, but it can work. That said, OpenVPN 3 Linux currently lacks a proper GUI integration, like a NetworkManager OpenVPN 3 plug-in. Such a plug-in would integrate with the GNOME and KDE Keyring services, which can store user credentials in better ways.