Choosing a VPN solution

Each VPN solution has pros and cons. This section will cover the primary considerations in choosing a VPN solution, providing the information necessary to choose the best solution for a given environment.

Interoperability

To interoperate with a firewall or router product from another vendor, the choices are limited by items supported by both sides.

Note

Interoperability in this sense isn’t applicable with VPN types not listed here since they are not intended for site-to-site applications.

IPsec

IPsec is usually the best choice since it is included with nearly every VPN-capable device. It also prevents being locked into any particular firewall or VPN solution. For interoperable site-to-site connectivity, IPsec is usually the only choice.

OpenVPN

OpenVPN is interoperable with a few other packaged firewall/VPN solutions, but not many.

WireGuard

WireGuard, like OpenVPN, is compatible with only a few other packaged firewall/VPN solutions. However, as it is a more recently developed protocol, support is even more rare.

Warning

WireGuard has been removed from the base system in releases after pfSense Plus 21.02-p1 and pfSense CE 2.5.0, when it was removed from FreeBSD.

If upgrading from a version that has WireGuard active, the upgrade will abort until all WireGuard tunnels are removed. For more details, see the Release Notes

WireGuard is available as an experimental add-on package on pfSense Plus 21.05, pfSense CE 2.5.2, and later versions. The settings for the WireGuard add-on package are not compatible with the older base system configuration.

Note

The WireGuard package is still under active development. Follow the development progress on the developer’s YouTube channel

Authentication considerations

All VPN types on the firewall support user authentication except for WireGuard. IPsec and OpenVPN can also work with shared keys or certificates. OpenVPN is a bit more flexible in this regard because it can work with only certificates, only shared keys, only user authentication, or a combination of these. Using OpenVPN with certificates, TLS authentication, and User Authentication is the most secure method. OpenVPN certificates can also be password protected, in which case a compromised certificate alone isn’t adequate for connecting to a VPN if it is set to only use certificates. The lack of additional authentication can be a security risk in that a lost, stolen, or compromised system containing a key or certificate means whoever has access to the device can connect to a VPN until that loss is discovered and the certificate revoked.

While not ideal, a lack of username and password authentication on a VPN isn’t as great a risk as it may seem. A compromised system can easily have a key logger installed to capture the username and password information and easily defeat that protection. In the case of lost or stolen systems containing keys, if the hard drive isn’t encrypted, the keys can be used to connect. However adding password authentication isn’t of great help there either, as usually the same username and password will be used to log into the computer, and most passwords are crackable within minutes using modern hardware when an attacker has access to an unencrypted drive. Password security is also frequently compromised by users with notes on their laptop or in their laptop case with their password written down. As with any security implementation, the more layers utilized, the better, but it’s always a good idea to keep these layers in perspective.

Ease of configuration

None of the available VPN options are extremely difficult to configure, but there are differences between the options.

IPsec

Has numerous configuration options and can be difficult for the uninitiated.

OpenVPN

OpenVPN requires the use of certificates for remote access in most environments, which comes with its own learning curve and can be a bit arduous to manage. There is a wizard to handle the most common OpenVPN remote access configurations and the OpenVPN client export packages eases the process of getting the clients up and running.

WireGuard

Has few options, thus configuration is simple. Lacks facilities for automated configuration and deployment leading to increased manual management.

Multi-WAN capable

If users require the ability to connect to multiple WANs, IPsec, OpenVPN, and WireGuard are capable of handling such configurations.

Client availability

VPN Client software is a program that handles connecting to the VPN and handling any other related tasks like authentication, encrypting, routing, etc. For remote access VPNs, the availability of VPN client software is a primary consideration. All options are cross platform compatible with many different operating systems but some require installing third-party clients. IPsec in EAP-MSCHAPv2 mode, IPsec in EAP-TLS mode, and IPsec in Xauth mode are the only options with client support built into some popular desktop and mobile operating systems. Other operating systems vary and may include more or less IPsec modes or may even include OpenVPN or WireGuard, as is the case with many Linux distributions. If using built-in clients is a must, consult the operating system documentation for all required client platforms to see if a common option is available and then check to see if that mode is possible.

In some cases multiple remote access VPNs may be required to accommodate all clients. For example, IPsec could be used for some and OpenVPN for others. Some organizations prefer to keep things consistent, so there is a trade-off to be made but for the sake of compatibility it may be worth offering multiple options.

IPsec

IPsec clients are available for Windows, Mac OS X, BSD, Linux, and others. Though the native clients may only support certain specific modes and configurations. General-use IPsec clients are not included in the OS except for some Linux and BSD distributions. Mac OS X includes both IKEv2 and Cisco (xauth) IPsec support. There are free and commercial options available with a user-friendly GUI.

OSX 10.11, along with Windows 7 and later include support for IPsec in specific modes using IKEv2: EAP-TLS and EAP-MSCHAPv2. Both options are supported and are covered in Mobile IPsec.

The Cisco-style IPsec client included with OS X and iOS devices is fully compatible with IPsec using xauth. Configuration for the iOS client is covered in Configuring IPsec IKEv2 Remote Access VPN Clients on iOS.

Many Android phones also include a compatible IPsec client, which is discussed in Configuring IPsec IKEv2 Remote Access VPN Clients on Android.

OpenVPN

OpenVPN has clients available for Windows, Mac OS X, all the BSDs, Linux, Solaris, and Windows Mobile, but the client does not come pre-installed in any of these operating systems.

Android devices can use a freely available OpenVPN client that works well and doesn’t require rooting the device. That client is covered in Installing the OpenVPN Client on Android. There are other options available if the device is rooted, but that is beyond the scope of this documentation.

iOS also has a native OpenVPN client. For more information, see Installing the OpenVPN Client on iOS.

WireGuard

WireGuard clients are available for a variety of operating systems including Windows, Mac OS X, FreeBSD, Linux, Android, iOS, and more. Some Linux installations include WireGuard but in most cases it requires installation of a third party client.

Firewall friendliness

VPN protocols can cause difficulties for many firewalls and NAT devices. This is primarily relevant to remote access connectivity, where users will be behind a myriad of firewalls mostly controlled by third parties with varying configurations and capabilities.

IPsec

IPsec uses both UDP port 500 and the ESP protocol to function. Some firewalls don’t handle ESP traffic well where NAT is involved, because the protocol does not have port numbers like TCP and UDP that make it easily trackable by NAT devices. IPsec clients behind NAT may require NAT Traversal to function, which encapsulates the ESP traffic over UDP port 4500.

OpenVPN

OpenVPN is very firewall-friendly. Since it uses a single UDP or TCP port and is not affected by common NAT functions such as rewriting of source ports, it is rare to find a firewall which will not work with OpenVPN. The only possible difficulty is if the protocol and port in use is blocked. Some administrators use a common port like UDP 53 (usually DNS), or TCP 80 (usually HTTP) or TCP 443 (usually HTTPS) or to evade most egress filtering.

WireGuard

Similar to OpenVPN in this regard, WireGuard uses a single UDP port and thus is not affected by firewall and NAT issues which may affect other protocols.

Cryptographically secure

One of the critical functions of a VPN is to ensure the confidentiality of the data transmitted.

IPsec

Tunnels using pre-shared keys can be broken if a weak key is used. Use a strong key, at least 10 characters in length containing a mix of upper and lowercase letters, numbers and symbols. Use of certificates is preferred, though somewhat more complicated to implement.

OpenVPN

Encryption is compromised if the PKI or shared keys are disclosed, though the use of multiple factors such as TLS authentication on top of PKI can mitigate some of the danger.

WireGuard

WireGuard encryption relies on pre-generated public/private key pairs and an optional pre-shared key. The peers only need the public keys of other peers, and the optional pre-shared key. The private keys and pre-shared key (if present) must be protected.

Support for NAT inside tunnels

While any use of NAT is undesirable, there are some occasions which can benefit from its use inside tunnels. Primarily, it can be useful for working around subnet conflicts or for setting up “outbound” style NAT when the remote endpoint only expects a single address (e.g. a VPN provider with no LAN-to-LAN routing)

IPsec

Support for NAT with IPsec depends on the mode, either tunnel or VTI.

Tunnel

Phase 2 entries in Tunnel mode support BINAT (1:1) and Overload/PAT style NAT. See NAT with IPsec Phase 2 Networks for details.

VTI

Phase 2 entries in VTI mode do not currently support NAT. See #8686 for details.

OpenVPN

OpenVPN supports inbound (e.g. port forwards) and outbound NAT using the group OpenVPN tab and also on assigned interfaces. Depending on the environment and configuration there may be some special considerations, such as ensuring proper return routing for post-NAT subnets.

WireGuard

WireGuard supports inbound (e.g. port forwards) and outbound NAT using the group WireGuard tab and also on assigned interfaces. Some cases may require using single peer tunnels or carefully crafted Allowed IPs lists to ensure correct return routing. See Design Considerations and WireGuard and Rules / NAT.

Per-tunnel Firewall Rules

Each VPN type has a common group tab for rules, and some also support rules for individual tunnels.

Warning

Rules on group tabs are considered before per-interface rules. For per-interface rules to match, rules on the group tab must not match the same packets.

IPsec

IPsec does not currently support per-tunnel rules, its traffic can only be filtered by rules on the IPsec tab.

Even though phase 2 entries in VTI mode have an interface which can be assigned, they do not currently support interface rules. See #8686 for details.

OpenVPN

When assigned as an interface, OpenVPN instances fully support per-tunnel rules. See Assigning OpenVPN Interfaces.

WireGuard

When assigned as an interface, WireGuard instances fully support per-tunnel rules. See Assign a WireGuard Interface and WireGuard and Rules / NAT.

Automatic Mobile Client Configuration

Depending on the deployment, mobile (Remote Access) clients can receive automatic configuration in certain cases.

IPsec

In IKEv2 mode, clients can automatically receive an IP address allocated from a pool, along with DNS configuration.

In IKEv1 mode with Xauth, in addition to the above, clients can also receive a list of networks to route across the VPN.

OpenVPN

OpenVPN clients can automatically receive an IP address allocated from a pool, and numerous additional options can be pushed to clients to control their behavior from the server side (routing, DNS, and many others).

WireGuard

WireGuard mobile clients must be configured statically. On the server side, a client tunnel address must be setup in the Allowed IPs for a peer. The same address must be configured on the client. This varies by OS/Platform, some read it from the configuration and other require it to be configured on interfaces via CLI commands. Networks to route must likewise be manually added on the client configuration Allowed IPs list and, depending on the client, may also need to be added to its operating system routing table.

Routing Support

IPsec

IPsec in Tunnel mode uses policies, not routes, and thus does not respect the operating system routing table.

IPsec in VTI mode supports static and dynamic routing (e.g. BGP, OSPF) and works with the operating system routing table.

OpenVPN

In SSL/TLS tun mode with multiple clients, OpenVPN uses its internal routing on client-specific configurations to determine which clients receive traffic for specific subnets. In this type of configuration, dynamic routing is not possible.

In SSL/TLS tun mode with a /30 subnet (one client per server) or in Shared Key mode, dynamic routing is possible using OSPF or BGP. This is due to the fact that in these cases, OpenVPN does not need to track internal routing and can rely on the operating system routing table alone.

In tap mode, dynamic routing is possible as packets can be handed off using L2/ARP information rather than relying on internal routing in OpenVPN.

WireGuard

WireGuard routes specific subnets to peers based on the Allowed IPs list, but also requires operating system routing table entries for traffic to enter a WireGuard tunnel.

When a WireGuard tunnel has more than one peer, the Allowed IPs list lets WireGuard determine internally which clients receive traffic for specific subnets. Due to this internal routing, dynamic routing is not possible in a configuration where WireGuard has multiple peers per tunnel.

For a WireGuard tunnel with a single peer, WireGuard can forward arbitrary networks to the peer without having them all listed in Allowed IPs. Thus, in this situation, it can take advantage of dynamic routing using BGP. OSPF is also possible but requires additional configuration.

See WireGuard Routing for more information.

Recap

Table Features and Characteristics by VPN Type shows an overview of the considerations provided in this section.

Features and Characteristics by VPN Type

VPN Feature

IPsec

OpenVPN

WireGuard

User Authentication

Yes

Yes

No

Client included in most OSes

Varies by mode

No

No

Widely interoperable

Yes

No

No

Multi-WAN

Yes

Yes

Yes

Cryptographically secure

Yes

Yes

Yes

Firewall friendly

Yes (NAT-T or IKEv2)

Yes

Yes

In-tunnel NAT

Limited

Yes

Yes

Per-tunnel Firewall Rules

No

Yes

Yes

Automatic Mobile Config

Yes

Yes

No

Static Routing

Yes (VTI Only)

Internal

Internal

Dynamic Routing

Yes (VTI Only)

Varies

Varies