Securing Pritunl

Improving Pritunl security

The steps below should be taken to keep your Pritunl server as secure as possible.

OpenVPN is one of the most secure VPN protocols, and if all of the following steps are taken, almost all network security issues can be avoided.

Block public access to the web console

For a high level of security, the web console should not be accessible to the public internet. If single sign-on or key links are used, the web console access should be limited to secure environments, such as requiring users to download their keys at the office on the local network.

If the Pritunl server is on a remote host, use firewall rules to allow access only from the public IP addresses of your organization (office, etc). If remote access is needed, consider whitelisting the users IP address on the firewall or opening the firewall temporarily for users to download their keys.

Always use an external firewall

Avoid using software firewalls that may exist on the Pritunl server itself, such as iptables or ufw. Instead, always use a firewall that is external to the server such as a hardware firewall or AWS security groups. Only the VPN ports should be open to the public internet.

Never route

Routing all internet traffic through the VPN server on a cloud or enterprise network will almost always produce unintended results. This configuration is intended for simple VPN servers running on one isolated host. It should never be used in a cloud or enterprise environment. Cloud and enterprise networks often have a lot of network resources that may not be considered when providing VPN users with full network access. One example is unintentionally providing VPN users with access to the AWS metadata service. With all network traffic routed and NATed through the VPN server a simple HTTP query from the VPN client to the metadata service curl will return potentially sensitive information. This can be a significant issue if IAM roles are used on the Pritunl instance. Another example is unintentionally providing VPN users with access to the MongoDB database that is used by Pritunl. If the MongoDB database is not sufficiently protected the user could modify the database to gain additional access to VPN servers.

Never email or transfer keys

VPN keys should never be emailed or transferred between client computers. Always download the keys directly from the Pritunl server using temporary key links or single sign-on.

In addition to compromising the security of the keys, copying keys will result in duplicating the unique identifier generated by Pritunl for each key. This can reduce security and increase network complications by allowing users to connect multiple devices concurrently.

Use single sign-on with Okta or Duo

Single sign-on with Okta is the most straightforward secure way to authenticate users by requiring them to permit key downloads and VPN connections with the Okta Verify app.

Alternatively, Duo can be used alone or in combination with another single sign-on service. This avoids potential security issues involved with emailing or sending temporary key links and also provides an additional layer of security in the event that a key is compromised.

Use secure encryption

Always use the AES 256bit cipher with a DH param size of at least 2048 bits. A 4096 bit DH param will provide the best security but can take several hours to generate, this process will only need to be done once for each VPN server.

Sign up for the mailing list

Join the mailing list (also on the homepage) and follow Pritunl to be notified of Pritunl updates and any potential security notifications.

Block all public access to your networks

All ports for ssh, internal tools, and any other internal services on your network should be blocked at the firewall. These services should always be accessed using the VPN connection.

Always use a password on the MongoDB server

It is important to consider that with most configurations, the VPN users will have NAT'd access to the same network that contains the MongoDB server for Pritunl.

If you are running an Enterprise cluster with a separate MongoDB database and the VPN users are given access to that same network, the users will have access to the MongoDB database.

Often, it is the intention to give the VPN users access to all the servers on the local network, but if it isn't necessary for the users to access the Pritunl MongoDB database adding a password will prevent an unnecessary risk.