Securing Pritunl

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

Always use an external firewall

Avoid using software firewalls that may exist on the Pritunl server itself, such as iptables, firewalld or ufw. Pritunl will modify iptables rules on the server and these firewalls will break the Pritunl configuration.

Instead, always use a firewall that is external to the server such as a hardware firewall or virtual instance security rules.

Never route 0.0.0.0/0

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 http://169.254.169.254 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 potentially create issues when using multiple devices.

Use single sign-on with secondary authentication

Single sign-on with Okta and OneLogin support the secondary Okta Verify and OneLogin Protect apps. The secondary push or passcode authentication will allow users to quickly verify each connection to the server. Duo can also be used as a secondary provider in combination with another single sign-on service.

Avoid push authentication

Push authentication provided by Okta, OneLogin and Duo is inherently insecure because some users will press approve on any prompt shown on their device. Switching these to the passcode mode will require the user to actively enter the passcode from the phone into the VPN client.

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.