IPsec provides a standards-based VPN implementation that is compatible with a
wide range of clients for mobile connectivity, and other firewalls and routers
for site-to-site connectivity. It supports numerous third party devices and is
being used in production with devices ranging from consumer grade Linksys
routers all the way up to IBM z/OS mainframes, and everything imaginable in
between. This chapter describes the configuration options available, and how to
configure various common scenarios.

See also

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

pfSense software supports IPsec with IKEv1 and IKEv2, multiple phase 2
definitions for each tunnel, as well as NAT traversal, NAT on Phase 2
definitions, a large number of encryption and hash options, and many more
options for mobile clients, including xauth and EAP.

Before delving too deeply into configuration, there are a few terms that are
used throughout the chapter that require explanation. Other terms are explained
in more detail upon their use in configuration options.

IKE stands for Internet Key Exchange, and comes in two different varieties:
IKEv1 and IKEv2. Nearly all devices that support IPsec use IKEv1. A growing
number of devices also support the newer IKEv2 protocol which is an updated
version of IKE that solves some of the difficulties present in the earlier
version. For example, IKEv2 has MOBIKE, which is a standard for mobile clients
that allows them to switch addresses dynamically. It also has built-in NAT
traversal, and standard mechanisms for reliability similar to DPD. In general
IKEv2 provides a more stable and reliable experience, provided both ends support
it sufficiently.

ISAKMP stands for Internet Security Association and Key Management Protocol. It
gives both parties a mechanism by which they can set up a secure communications
channel, including exchanging keys and providing authentication.

An ISAKMP Security Association (ISAKMP SA) is a one-way policy which defines how
traffic will be encrypted and handled. Each active IPsec tunnel will have two
security associations, one for each direction. The ISAKMP Security Associations
are setup between the public IP addresses for each endpoint. Knowledge of these
active security associations is kept in the Security Association Database (SAD).

A Security Policy manages the complete specifications of the IPsec tunnel. As
with Security Associations, these are one-way, so for each tunnel there will be
one in each direction. These entries are kept in the Security Policy Database
(SPD). The SPD is populated with two entries for each tunnel connection as soon
as a tunnel is added. By contrast, SAD entries only exist upon successful
negotiation of the connection.

In pfSense software, Security Policies control which traffic will be intercepted
by the kernel for delivery via IPsec.

There are two phases of negotiation for an IPsec tunnel. During phase 1, the two
endpoints of a tunnel setup a secure channel between using ISAKMP to negotiate
the SA entries and exchange keys. This also includes authentication, checking
identifiers, and checking the pre-shared keys (PSK) or certificates. When phase
1 is complete the two ends can exchange information securely, but have not yet
decided what traffic will traverse the tunnel or its encryption.

In phase 2, the two endpoints negotiate how to encrypt and send the data for the
private hosts based on Security Policies. This part builds the tunnel used for
transferring data between the endpoints and clients whose traffic is handled by
those endpoints. If the policies on both side agree and phase 2 is successfully
established, the tunnel will be up and ready for use for traffic matching the
phase 2 definitions.