The role for the server, which specifies how peers connect to a server instance. Changing this also affects which options the GUI displays on the rest of the page.
- Peer to Peer (SSL/TLS)
A connection between local and remote networks that is secured by SSL/TLS.
This choice offers increased security as well as the ability for the server to push configuration commands to the remote peer router when using a 1:many style setup. Remote peer routers can also have certificates revoked to remove access if they become compromised.
- Peer to Peer (Shared Key)
A connection between local and remote networks that is secured by a single shared key known to both peers.
This choice is easier to setup, but is less secure. If a shared key is compromised, a new key must be generated and then copied to any router or client using the old shared key. This mode requires a separate server instance for each client.
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
- Remote Access (SSL/TLS)
A mobile client setup with per-user X.509 certificates.
As with the peer-to-peer SSL/TLS connection type, using this method offers increased security as well as the ability for the server to push configuration commands to clients. Mobile clients can also have keys revoked to remove access if a key is compromised, such as a stolen or misplaced phone or laptop.
- Remote Access (User Auth)
A remote access server configuration that does not use certificates, but requires the end user to supply a username and password to authenticate.
This is less secure than using certificates, but simpler to deploy as every client will use the same configuration file and only their credentials are different.
- Remote Access (SSL/TLS + User Auth)
Requires SSL/TLS and user authentication to connect.
This is the most secure choice available. Not only does it get the benefits of other SSL/TLS choices, but it also requires a username and password from the client when it connects. Client access can be removed not only by revoking the certificate, but also by changing the password. Also, if a compromised key is not immediately discovered, the danger is lessened because it is unlikely that the attacker has the keys and the password.
The OpenVPN wizard uses this mode when it configures a remote access VPN.
DCO (Plus Only)¶
Check Enable Data Channel Offload (DCO) for this instance to enable OpenVPN Data Channel Offload (DCO).
DCO is a pfSense® Plus exclusive feature that can potentially increase performance of OpenVPN well beyond the capabilities of traditional OpenVPN connections.
To be compatible with DCO the instance must use SSL/TLS in client/server mode.
This can either be remote access or peer-to-peer so long as the tunnel network
is large enough for multiple clients (e.g.
DCO can be enabled on one or more peers but the greatest speed increase comes when all peers have DCO enabled.
Several OpenVPN options are not compatible with DCO, which are noted on OpenVPN Data Channel Offload (DCO) and elsewhere in the documentation where relevant.
OpenVPN DCO is considered experimental at this time.
While testing has been successful in many scenarios during development, there is still a potential for instability or undesirable behavior. Additionally, some OpenVPN features and use cases are still not compatible with DCO. See Limitations for a list of known DCO limitations.
If a problem occurs with DCO, start a thread on the Netgate Forum to discuss and diagnose the issue.