OpenVPN¶

See also

OpenVPN is an open source VPN solution which can provide access to remote access clients and enable site-to-site connectivity. OpenVPN supports clients on a wide range of operating systems including all the BSDs, Linux, Android, macOS, iOS, Solaris, Windows, and even some VoIP handsets.

Every OpenVPN connection consists of a server and a client, for both remote access and site-to-site deployments. In the case of site-to-site VPNs, one firewall acts as the server and the other as the client. In most cases it does not matter which firewall acts in a particular role. Typically the location of the primary firewall will provide server connectivity for all remote locations, whose firewalls are configured as clients. This is functionally equivalent to the opposite configuration the primary location configured as a client connecting to servers running on the firewalls at the remote locations. In practice, the servers are nearly always run on a central location.

OpenVPN supports several types of authentication methods:

X.509 (also known as TLS, SSL, or PKI):

Utilizes a certificate structure (CA, certificates, and keys). This offers strong security as it cannot be guessed or brute forced.

User authentication:

Clients authenticate using credentials such as a username and password which are checked against a local user database, LDAP, or RADIUS server.

Some authentication sources also support multi-factor authentication via mechanisms such as mOTP.

X.509 and User authentication together:

The most secure combination, combining multiple factors of authentication that the user has (e.g. certificates, keys) with something they know (credentials).

Shared key:

Client and server share a single shared key known to both parties.

Danger

Shared key mode has been deprecated by OpenVPN as it is no longer considered sufficiently secure for modern requirements.

Shared key mode will be removed from future versions of OpenVPN. Users should not create any new shared key tunnels and should immediately convert any existing shared key tunnels to SSL/TLS mode.

When an SSL/TLS instance is configured with a /30 tunnel network it behaves in a similar manner to shared key mode. The primary difference is the need to create and distribute the certificate structure to peers. See OpenVPN Site-to-Site Configuration Example with SSL/TLS for information on configuring OpenVPN in SSL/TLS mode.

Note

While OpenVPN utlizes TLS it is not a “clientless” SSL VPN in the sense that commercial firewall vendors commonly state. The OpenVPN client must be installed on all client devices and it is not browser-based. In reality no VPN solution is truly “clientless”, and this terminology is nothing more than a marketing ploy. For more in depth discussion on SSL VPNs, this post from Matthew Grooms, an IPsec tools and former pfSense® software developer, in the mailing list archives provides some excellent information.

For general discussion of the various types of VPNs available in pfSense software and their pros and cons, see Virtual Private Networks.

OpenVPN and Certificates¶

The best practice is to use certificates for remote access and site-to-site VPNs because it allows access to be revoked for individual clients or sites. Ideally, certificates should be unique per device or at least per user.

If a client machine is compromised, stolen, or lost, or otherwise needs revoked, a shared certificate would have to be re-issued to all clients. If a client with an individual certificate is compromised, or access needs to be revoked for any other reason, simply revoke that certificate. No other clients are affected.

The pfSense software GUI includes a certificate management interface that is fully integrated with OpenVPN. Certificate authorities (CAs) and server certificates are managed in the Certificate Manager in the web interface, located at System > Certificates. User certificates are also managed in the web interface, as a part of the built-in user manager found at System > User Manager. Certificates may be generated for any user account created locally on the firewall except for the default admin account.