OpenVPN | pfSense Documentation (2024)

Docs »
pfSense® software »
Virtual Private Networks
Give Feedback

Next
OpenVPN Data Channel Offload (DCO)

Previous
VPN Scaling

OpenVPN Data Channel Offload (DCO)
OpenVPN Configuration Options
OpenVPN Firewall Rules
OpenVPN clients and Internet Access
Assigning OpenVPN Interfaces
OpenVPN and Multi-WAN
OpenVPN and High Availability
Sharing a Port with OpenVPN and a Web Server
Controlling Client Parameters via RADIUS
OpenVPN Adapter Address ICMP Behavior

OpenVPN Client Export Package
OpenVPN Server and Client Status
OpenVPN Logs
Connecting OpenVPN Sites with Conflicting IP Subnets
OpenVPN Remote Access Configuration Example
Authenticating OpenVPN Users with FreeRADIUS
Authenticating OpenVPN Users with RADIUS via Active Directory
Installing OpenVPN Remote Access Clients
Installing the OpenVPN Client on iOS
Adding OpenVPN Remote Access Users
OpenVPN Site-to-Site Configuration Example with SSL/TLS
Routing Internet Traffic Through A Site-To-Site OpenVPN Tunnel
Bridging OpenVPN Connections to Local Networks
OpenVPN Site-to-Site with Multi-WAN and OSPF
See Also
VPN firewall definition – Glossary
Troubleshooting OpenVPN
Troubleshooting OpenVPN Internal Routing (iroute)
Troubleshooting Windows OpenVPN Client Connectivity

OpenVPN is an open source VPN solution which can provide access to remoteaccess clients and enable site-to-site connectivity. OpenVPN supports clients ona 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 remoteaccess and site-to-site deployments. In the case of site-to-site VPNs, onefirewall acts as the server and the other as the client. In most cases it doesnot matter which firewall acts in a particular role. Typically the location ofthe primary firewall will provide server connectivity for all remote locations,whose firewalls are configured as clients. This is functionally equivalent tothe opposite configuration the primary location configured as a clientconnecting to servers running on the firewalls at the remote locations. Inpractice, 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 offersstrong security as it cannot be guessed or brute forced.

User authentication:

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

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

X.509 and User authentication together:

The most secure combination, combining multiple factors of authentication thatthe 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 consideredsufficiently secure for modern requirements.

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

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

Note

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

For general discussion of the various types of VPNs available in pfSensesoftware 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 VPNsbecause 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 withan individual certificate is compromised, or access needs to be revoked for anyother reason, simply revoke that certificate. No other clients are affected.

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