This documentation will describe the full recommended configuration for environments requiring the highest level of security.

Installation

Oracle Linux 8 should be used as the host operating system. If available automatic Ksplice kernel updates should be enabled. This is included for free with Oracle Cloud instances, other installations would require a Oracle Linux support subscription.

sudo sed -i 's/^autoinstall =.*/autoinstall = yes/g' /etc/uptrack/uptrack.conf

Automatic system updates should be enabled. This will not disrupt Pritunl VPN connections. The Pritunl service will need to be manually restarted to complete updates. The Pritunl web server will restart automatically on updates without impacting the availability of the server.

sudo dnf -y update
sudo dnf -y install dnf-automatic
sudo sed -i 's/^upgrade_type =.*/upgrade_type = default/g' /etc/dnf/automatic.conf
sudo sed -i 's/^download_updates =.*/download_updates = yes/g' /etc/dnf/automatic.conf
sudo sed -i 's/^apply_updates =.*/apply_updates = yes/g' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer

The OpenVPN package from the EPEL repository should be replaced with the newer Pritunl build using the command below.

sudo yum --allowerasing install pritunl-openvpn

MongoDB

The latest version of MongoDB should be used. For both single and multi-host configurations password authentication should be enabled on the database. For mutli-host configurations where the database connection is going over untrusted networks SSL should be enabled. It is not recommended to configure SSL if the local network is secure, expiring SSL certificates can cause service disruptions. The Securing MongoDB documentation has information on configuring these options.

Systemd Web Server Process

The Pritunl web server process by default runs as a root user to ensure compatibility with different Linux hosts. The web server can run in a separate systemd service to significantly improve the isolation of the process. This will run the web server under the pritunl-web non-root user and also utilizes several systemd options including ProtectSystem=full to further isolate the web server process. Run the command below on one of the Pritunl hosts then restart the service to enable this option.

sudo pritunl set app.web_systemd true

After restarting the Pritunl service run the command below to verify the systemd service is active.

sudo systemctl status pritunl-web

Insecure Single Sign-On Modes

The Radius, SAML (not including listed SAML providers) and Duo Security (not including modes using Duo as secondary authentication) single sign-on modes should be avoided if possible.

Radius is vulnerable to phishing attacks and uses outdated security mechanisms.

When using an unsupported SAML provider without API support additional user checks cannot be done. The supported SAML providers use the providers API to verify the user is active on each connection and every hour while connected. With this API support if a user is disabled or deleted from the SAML provider new VPN connections will fail and existing VPN connections will be stopped within an hour.

The Duo only single sign-on mode relies on the Duo authenticator alone to provide authentication.

Secure Single Sign-On Modes

The recommended single sign-on configurations are listed below. These modes provide multi-factor authentication from two separate sources.

• Azure + Duo Security
• Google + Duo Security
• JumpCloud + Duo Security
• Okta + Duo Security
• OneLogin + Duo Security
• Azure + Yubico
• Google + Yubico
• JumpCloud + Yubico
• Okta + Yubico
• OneLogin + Yubico

OneLogin and Okta Multi-Factor

Both OneLogin and Okta have multi-factor authenticators. Pritunl can be configured to use these but it is not recommended. This will require a broadly scoped API key that has almost full access to the single sign-on provider. A read-only API key can otherwise be used when not using the multi-factor authenticators.

Authentication Cache

In the top right settings the Pritunl Authentication Cache should be enabled and the OpenVPN Authentication Cache should be disabled. The Pritunl authentication cache is only compatible with the Pritunl VPN client, the OpenVPN authentication cache is compatible with all VPN clients.

The Pritunl authentication cache uses a token that is stored only in the memory of the clients background service running as root. If the computer is turned off this key will no longer be available. This system is very secure and attempting to use several layers of multi-factor authentication without authentication cache will result in an almost unusable user experience.

The OpenVPN authentication cache is limited to only specific secondary authentication modes and relies primarily on the users IP address, this option should not be used.

Drop OpenVPN Permissions

The Drop OpenVPN Permissions option should be enabled in the top right settings. This will run the OpenVPN server process as a non-root user.

Restrict Profile Import

The Restrict Profile Import option in the top right settings will prevent the user from easily downloading the VPN profile outside of the Pritunl Client. When enabled the user will only be provided with a import URI for the Pritunl Client, options to directly download the VPN profile as a file or archive will be removed. This option will only work when the user is using the Pritunl Client.

Auditing

The Auditing Mode should be set to All in the top right settings. This will log important security related events. The Monitoring Mode is intended for monitoring the server resources and is not relevant to security.

Administrators

All administrator users should have a YubiKey configured. This will require setting the Yubico API key in the top right settings. Configuring administrators with YubiKeys does not require users to also have YubiKeys. This system uses Yubico OTP, the FIDO only Security Key series YubiKeys will not work. The YubiKey 4, 5 and Bio series keys are supported.

Device Authentication

Device Authentication provides the highest level of assurance that each physical client device connecting to the VPN has been authorized. This system provides a high level of protection against authentication and phishing attacks. Even if an attacker is able to obtain a user VPN profile and fully compromises the users account and two-factor authentication the device making the connection would be prompted for approval when attempting to connect. This can be enabled in the server settings. Refer to the Device Authentication documentation for more information.

Dynamic Firewall

The Dynamic Firewall provides the highest level of server security available in Pritunl. When a server is run with the dynamic firewall enabled the VPN port will not be open to the internet. The Pritunl server will block access to the port with iptables. When configured the only port open to the internet on a Pritunl server will be the web server. This design in combination with the high level of security provided from the dual web server can make a Pritunl server nearly impossible to attack from unauthenticated attackers. When using the dynamic firewall only the Pritunl Client that is updated to a supported version will be able to connect. Other OpenVPN clients are not supported. Currently server linking is not supported with the dynamic firewall.

To enable the option an enterprise subscription is required. In the advanced server settings enable the Dynamic Client Firewall option.

Single Sign-On Connection Authentication

Single Sign-On Connection Authentication provides an additional layer of authentication for single sign-on connections. By default when single sign-on is used in Pritunl the user will authenticate with the single sign-on provider from the Pritunl web console then import a VPN profile into a client. The VPN profile will contain a certificate and private key that will be used to authenticate the user to the VPN server. Instead of requiring the user to re-authenticate with single sign-on for each connection the Pritunl server will utilize the API from the single sign-on provider to verify the status of the user. This check will verify that the user exists and is not disabled. Most providers also support defining a single sign-on application, the API will also be used to verify the user has access to the defined application. These checks will occur for every connection even when authentication cache is enabled. If a single sign-on user were to fail the check the VPN connection would be blocked. This can be enabled in the server settings.

Server Settings

In the server settings DH Param Bits should be set to either 2048 or 4096. The Encryption Cipher should be set to AES 128bit GCM. Using AES 256bit GCM will result in significantly slower connection speeds and reduced capacity for concurrent client connections. The Hash Algorithm should be set to SHA-256. The Restrict Routing option should be enabled.