IPsec Configuration

IPsec offers numerous configuration options, affecting the performance and security of IPsec connections. Realistically, for low to moderate bandwidth usage it matters little which options are chosen here as long as DES is not used, and a strong pre-shared key is defined, unless the traffic being protected is so valuable that an adversary with many millions of dollars worth of processing power is willing to devote it to breaking the IPsec encryption. Even in that case, there is likely an easier and much cheaper way to break into the network and achieve the same end result (social engineering, for one). Performance is the most important factor for most, and in cases when that is a concern, more care is needed when crafting a configuration.

IPsec Modes

pfSense® software supports several primary modes of IPsec operation:

Policy-based IPsec

This mode uses policies to match specific combinations of traffic which are grabbed by the kernel and pushed through an IPsec tunnel. It also uses special “trap” policies to detect when traffic intends to use IPsec so that it can bring the tunnel up automatically. Only traffic specifically matching phase 2 child SA entries can use IPsec, and all traffic matching those entries will be taken over by IPsec.

This mode is the most common and is supported by nearly all third party IPsec implementations.

Route-based IPsec (VTI)

Routed IPsec uses a special Virtual Tunnel Interface (VTI) for each IPsec tunnel. The VTI interface is assigned and used like other interfaces. Phase 2 entries define addresses for the tunnel interface itself, rather than policies which direct traffic to IPsec. Arbitrary traffic may cross IPsec tunnels, as traffic follows the system routing table. Static routes or dynamic routing daemons can control which traffic crosses a tunnel.

Support for routed IPsec varies by vendor.

Mobile IPsec

Similar to policy-based mode, but for remote access/mobile clients.

Transport Mode

This mode encrypts all traffic from the the external IP address on this firewall to the external IP address on the far side as defined in the Phase 1 settings. Since all traffic sent between the two nodes will be encrypted, other tunneling methods that do not employ encryption, such as a GIF or GRE tunnel, can be safely used by the firewall between the endpoints.

Interface Selection

In many cases, the Interface option for an IPsec tunnel will be WAN, since the tunnels are connecting to remote sites. However, there are plenty of exceptions, the most common of which are outlined in the remainder of this section.

CARP Environments

CARP type virtual IP addresses are also available in the Interface drop-down menu for use in High Availability environments (High Availability). In these environments, an appropriate CARP address must be chosen for the WAN where the IPsec tunnel will terminate. By using the CARP IP address, it ensures that the IPsec tunnel will be handled by the High Availability cluster member currently in MASTER state, so even if the primary firewall is down, the tunnel will connect to whichever cluster member has taken over the MASTER role.

IP Alias VIP

If multiple IP addresses are available on an interface using IP Alias type VIPs, they will also be available in this list. To use one of those IP addresses for the VPN instead, select it here.

Multi-WAN Environments

When using Multi-WAN (Multiple WAN Connections), pick the appropriate Interface choice for the WAN-type interface to which the tunnel will connect. If the connection will enter via WAN, pick WAN. If the tunnel will use a different WAN, choose whichever OPT WAN interface is needed. A static route will automatically be added to ensure that the traffic to the Remote Gateway routes through the appropriate WAN.

A gateway group may also be chosen from this list. A gateway group to be used with IPsec must only have one gateway per tier. When using a gateway group, if the first gateway goes down, the tunnel will move to the next available WAN in the group. When the first WAN comes back up, the tunnel will be rebuilt there again. If the endpoint on the far side is one that does not support multiple peer addresses, such as another firewall running pfSense software, this must be combined with a DynDNS host set using the same gateway group for failover. The DynDNS host will update the IP address as seen by the far side, so that the remote endpoint will know to accept traffic from the newly activated WAN.

Wireless Internal Protection

When configuring IPsec to add encryption to a wireless network, as described in Additional protection for a wireless network, choose the OPT interface which corresponds to the wireless card. When using an external wireless access point, pick the interface which is connected to the wireless access point.

Phase 1 Settings

The settings here control the phase 1 negotiation portion of the tunnel, as described previously.

General Information


Controls whether or not this tunnel (and its associated phase 2 entries) are active and used.

Key Exchange Version

This can be IKEv1, IKEv2, or Auto. The differences are discussed in IKE.


IKEv1 is more common and widely supported, but has known issues with supporting common modern issues such as dealing with NAT or mobile clients.


An updated version of the protocol which has increased capabilities and security, as well as built-in support for mobile clients and NAT.


IKEv2 is the best choice when both sides support it.


This option uses IKEv2 when initiating, but will accept either IKEv2 or IKEv1 when responding.

Internet Protocol

The protocol for the outside of the tunnel. That is, the protocol that will be used between the outside peer addresses. For most, this will be IPv4 , but if both ends are capable of IPv6, that may be used instead. Whichever protocol is chosen here will be used to validate the Remote Gateway and the associated identifiers.


A tunnel using IKEv1 can only carry the same protocol traffic in Phase 2 as was used for Phase 1. For example, IPv4 peer addresses restrict Phase 2 to IPv4 networks only. A tunnel using IKEv2 can carry both IPv4 and IPv6 traffic at the same time in Phase 2 no matter which protocol was used for Phase 1.


This determines which part of the network will be the termination point (end point) for the IPsec tunnel. If the tunnel will be connecting to a remote server, then WAN is likely the desired setting. This can also be a virtual IP address. A gateway group can also be used for automatic failover. See Interface Selection earlier in this document for details on selecting the appropriate interface.

Remote Gateway

The IP Address for the peer to which the tunnel will be established. This is most likely the WAN IP address of the remote firewall.

This may be set to an IP address or a fully qualified domain name. When set to use a name, the entry is periodically resolved by DNS and updated when a change is detected.


It is a good practice to leave notes about the purpose of a tunnel. Enter a few works to describe what this VPN tunnel is used for, or about the remote end of the tunnel. This serves as a reminder for anyone managing the firewall (present or future) as to who or what will be using the tunnel.

Authentication Method

An IPsec phase 1 can be authenticated using a pre-shared key (PSK) or certificates, the Authentication Method selector chooses which of these methods will be used for authenticating the remote peer. Fields appropriate to the chosen method will be displayed on the phase 1 configuration screen.

Mutual PSK

The peer is validated using a defined string. The longer the better, but since it is simple a string, there is a possibility that it can be guessed. For this reason a long/complex key is more secure when using PSK mode.

Mutual Certificate

Select a CA and certificate used to verify the peer. During the phase 1 exchange, each peer sends its certificate to the other peer and then validates it against their shared CA. The CA and certificate must be created for the tunnel before attempting to setup the phase 1.

Mutual Certificate (PKCS#11)

Similar to Mutual Certificate but the certificate is read from a locally attached PKCS#11 device.

Mutual PSK+Xauth

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with a shared (or “group”) pre-shared key.

Mutual Certificate+Xauth

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with certificate authentication using certificates on both the client and server.

Hybrid Certificate+Xauth

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with a certificate only on the server side. It is not quite as secure as Mutual Certificate+Xauth , but it is easier on the clients.


Used with mobile IPsec and IKEv2, EAP-TLS verifies that certificates on the client and server are from the same shared CA, similar to Mutual Certificate. The client and server certificates require special handling:

  • The server certificate must have the firewall hostname as it exists in DNS listed in its Common Name, and again as a Subject Alternative Name (SAN). The firewall IP address must also be listed in a SAN.

  • The identifier in Phase 1 must also be set to match the firewall hostname as listed in the Common Name of the certificate.

  • The client certificate must have the username listed as the common name and then again as a SAN.

The CA and server certificates must be generated before attempting to configure EAP-TLS. The CA and user certificate must be imported into the client.


Used with mobile IPsec and IKEv2, this selection performs CA verification along with username and password authentication via RADIUS. A RADIUS server must be selected on the Mobile Clients tab. Though user certificates are not necessary, EAP-RADIUS still requires that a CA and server certificate be present using the same attributes mentioned under EAP-TLS. The CA must be imported to the client, but no user certificate.


Used with mobile IPsec and IKEv2, EAP-MSCHAPv2 works identically to EAP-RADIUS except the usernames and passwords are defined on the Pre-Shared Key tab under VPN > IPsec with the Secret type set to EAP. It also requires a CA and server certificate with the same requirements listed previously. The CA must be imported to the client, but no user certificate.

Negotiation Mode

(IKEv1 only) This is the type of authentication security that this tunnel will use. This can be either Main or Aggressive.


Main is the most secure mode, though it also requires more packets between the peers to accomplish a successful negotiation. It is also much more strict in its validation. This mode is best for security, but not speed.


Aggressive is generally the most compatible and is the fastest mode. It is more forgiving with identifier types, and tends to be more successful when negotiating with third-party devices. It is faster because it sends all of the identifying information in a single packet, which also makes it less secure because the verification of that data is not as strict as that found in main mode.

My Identifier

Identifies this firewall to the far side. It is best left at My IP Address and the firewall will fill it in as needed. In some cases an FQDN or similar may be entered so that the value is constant. So long as both sides agree on the identifier, it will work.

Peer Identifier

Identifies the peer on the far side of the tunnel. It is best left at Peer IP Address and the firewall will fill it in as needed. In some cases an FQDN or similar may be entered so that the value is constant. So long as both sides agree on the identifier, it will work.

Identifier Types
My IP Address / Peer IP address

This choice is a macro that will automatically use the IP address on the interface, or the selected VIP, as the identifier. For peers, this is the IP address from which the packets were received, which should be the Remote Gateway.

IP Address

The IP Address option allows a different IP address to be used as the identifier. One potential use for this would be if the firewall is behind a router performing NAT. The real external IP address could be used in this field.

Distinguished Name

A Distinguished Name is another term for a fully qualified domain name, such as host.example.com. Enter a value in that format into the box.

User Distinguished Name

A User Distinguished Name is an e-mail address, such as vpn@example.com.

ASN.1 Distinguished Name

If using Mutual Certificate authentication, this can be the subject of the certificate being used, or a similar string.

KeyID Tag

An arbitrary string to use as the identifier.

Dynamic DNS

A hostname to resolve and use as the identifier. This is mostly useful if the firewall is behind NAT and has no direct knowledge of its external IP address aside from a dynamic DNS hostname. This is only available for My identifier, not the Peer identifier.


In cases when the remote identifier is unknown or cannot be matched, the Peer Identifier may be set to Any. This is more common on certain types of mobile configurations, but it is a much less secure choice than matching the identifier properly.

Pre-Shared Key

(Mutual PSK authentication only) This key must be exactly the same on both VPN peers. It is case sensitive. Think of this like a “password” for the tunnel. Since this only gets entered once on each side and there is no need to remember it, it is better to make this as long and complex as possible.

Click fa-refresh Generate new Pre-Shared Key to populate the field with a random long string suitable for use as a Pre-Shared Key.


This Pre-Shared Key must be as random as possible to protect the contents of the tunnel.

My Certificate

(Mutual Certificate authentication only) Defines the certificate which identifies this firewall. The CA which signed this certificate must be known by the peer, which may be sending them a copy of the CA certificate. If one is not shown, create or import it under System > Cert Manager on the Certificates tab.

Peer Certificate Authority

(Mutual Certificate authentication only) Defines the CA which has signed the certificate sent by the peer. This is used to validate the peer certificate. If it does not show in the list, import it under System > Cert Manager on the Certificate Authorities tab.

Phase 1 Encryption algorithms

There are many options for encryption algorithms on both phase 1 and phase 2.

Encryption choices depend on the device to which the tunnel will connect, and the hardware available in this firewall. Generally speaking, AES-GCM is the most desirable cipher. When connecting to third party devices, 3DES (also called “Triple DES”) is a common choice as it may be the only option the other end supports, though it is considered weak and should be avoided when possible.

Phase 1 Encryption Options

Multiple combinations of these options can be defined using the fa-plus Add Algorithm button to add another line.

Encryption Algorithm

If both sides support AES-GCM, use AES128-GCM with a 128 bit Key Length. This will combine strong encryption and hashing together and can be accelerated by AES-NI. Failing that, use AES With a Key Length of 128. If the peer does not support any of these, use the strongest available option supported by the peer.

Hash Algorithm

Hash algorithms are used with IPsec to verify the authenticity of packet data and as a Pseudo-Random Function (PRF). These hash algorithms may also be referred to with HMAC (Hash Message Authentication Code) in the name in some contexts, but that usage varies depending on the hardware or software in use.

When using AES-GCM, this is used solely as a PRF because AES-GCM already performs hashing internally. The best choice for use with AES-GCM is AES-XCBC. If a different type of Encryption Algorithm is in use, then use SHA256 if possible. If the peer does not support any of these, use the strongest available option supported by the peer.


Specifically set a manual PRF different than the one the IPsec daemon would choose automatically based on the Hash Algorithm. This control is hidden by the GUI unless PRF Selection is enabled in the Advanced Options section at the bottom of the page.

DH Key Group

The best practice is to use DH Group 14 (2048 bit) or higher if both sides support it. Avoid using groups 1, 2, 22, 23, and 24 as they do not provide sufficient security. As with the other options, if the suggested value is not supported by the peer, use the strongest available option.

Expiration and Replacement

The total lifetime for Phase 1 defines how often the connection will be rekeyed or reauthenticated by the IPsec daemon, in seconds.

In most cases, a tunnel should use either Rekey Time or Reauth Time, plus Over Time. The specific values depend on the IKE mode and which mechanisms are supported by both endpoints.

28800 total seconds is a good balance of frequent rekeying without being too aggressive. Place approximately 90% of this total in either Rekey Time or Reauth Time, and the remaining amount in Over Time.

Rekey Time

Time, in seconds, before the IPsec daemon attempts attempts to establish a new set of keys for the IKE SA. Only supported by IKEv2, and is the best choice for use with IKEv2.

Rekey works without interruption, allowing both endpoints to seamlessly change to new keys on the fly. This is optimal, but implementation quality varies by vendor.

Leave blank or enter a value of 0 to disable rekeying.

Normally both sides will rekey as needed, but if the tunnel often fails when a rekey event occurs, try disabling this feature on one side.


Some clients, especially Windows clients behind NAT, misbehave when they receive a rekey request. In those cases it is safer to allow the client to initiate the rekey by disabling the option on the server.

Reauth Time

Time, in seconds, before an IKE SA is torn down and recreated from scratch by the IPsec daemon, including authentication. Supported by IKEv1 and IKEv2, but should be avoided with IKEv2 where possible.

This process can be disruptive to traffic flow unless all peers support IKEv2 make-before-break (Advanced IPsec Settings) and overlapping IKE SA entries.

Leave blank or enter a value of 0 to disable reauthentication.

Over Time

Hard IKE SA life time, in seconds, after which the IKE SA will expire. This time is relative to reauthentication and rekey time.

If empty, defaults to 10% of whichever timer is higher (reauth or rekey).

Advanced Options

Responder Only

When set, then IPsec daemon will not attempt to initiate the tunnel. The tunnel will only be established by an initiation attempt from the far side. Also, if DPD detects that the tunnel has failed, the tunnel will be left down rather than restarted, leaving it up to the far side to reconnect.

Child SA Close Action

Controls how the IPsec daemon behaves when a child SA (P2) is unexpectedly closed by the peer.


Retains the default behavior based on other settings for the tunnel.

Close connection and clear SA

Removes the child SA and does not attempt to establish a new SA. This is the desired behavior when acting in a Responder Only or mobile IPsec role.


Immediately attempts to reconnect the child SA. This ensures that the tunnel reestablishes properly in cases that do not support trap policies, such as routed IPsec (VTI). Set this on one side only if the tunnel does not reconnect after it disconnects, rekeys, or reauthenticates.


This option must not be set on both peers! Otherwise both peers will attempt to initiate and hold open multiple copies of each child SA.

Close connection and reconnect on demand

Clears the child SA and reinstalls trap policies to watch for interesting traffic. Will reestablish the tunnel on demand when traffic attempts to cross the tunnel.

This option is not compatible with modes which do not support trap policies, such as routed IPsec (VTI).

NAT Traversal

(IKEv1 Only) Also known as NAT-T. NAT Traversal encapsulates ESP traffic for IPsec inside of UDP packets, to more easily function in the presence of NAT. If this firewall or the firewall on the other end of the tunnel is behind a NAT device, then NAT Traversal will likely be necessary for the tunnel to function properly.


(Default) Allows the IPsec daemon to detect and use NAT Traversal automatically when it determines one or both peers is behind NAT.


Instructs the IPsec daemon to always use NAT Traversal for the tunnel. This can help if there is a known issue detecting NAT, or with issues carrying ESP traffic between the two endpoints even when neither side is behind NAT.

IKEv2 integrates NAT Traversal natively so the option is unnecessary in that case.


An extension to IKEv2 which handles multi-homed clients and clients which roam between different IP addresses. This is primarily used with mobile clients to allow them to switch remote addresses while keeping the connection active. Leave disabled unless the remote peer must change addresses dynamically.

Gateway Duplicates

When set, the GUI validation allows multiple Phase 1 configurations to the same remote endpoint.

This option also disables automatic static routes to the peer via specific WAN gateways. Traffic will follow the default route, not the tunnel interface, unless manual static routes redirect the traffic.

Split Connections

(IKEv2 Only) When an IKEv2 tunnel has multiple Phase 2 definitions, by default the settings are collapsed in the IPsec configuration such that all P2 combinations are held in a single child SA.

Split Connections changes this behavior to be more like IKEv1 where each P2 is its configured by the daemon as own separate child SA.

Certain scenarios require this behavior, such as:

  • The remote peer does not properly handle multiple addresses in single traffic selectors. This is especially common in Cisco equipment.

  • Each child SA must have unique traffic selector or proposal settings. This could be due to the peer only allowing specific combinations of local/remote subnet pairs or different encryption options for each child SA.

PRF Selection

When set, the GUI enables a control to specifically set a Pseudo-Random Function (PRF) rather than allow the IPsec daemon to choose one automatically based on the selected Hash Algorithm. Can be useful in combination with AEAD encryption algorithms such as AES-GCM.

Dead Peer Detection

Dead Peer Detection (DPD) is a periodic check that the host on the other end of the IPsec tunnel is still alive. This detects when an IPsec peer has lost connectivity or otherwise is unreachable. If a DPD check fails, the tunnel is torn down by removing its associated SAD entries and a fresh negotiation is attempted.

The default settings are sufficient for most connections. Increase the values for bad quality links to avoid tearing down a usable, but lossy, tunnel.


Time between DPD probe attempts. The default of 10 is best.

Max Failures

Number of failures before the peer is considered down. The default of 5 is best.


The default values of 10 seconds and 5 failures will result in the tunnel being considered down after approximately one minute.

Phase 2 Settings

The phase 2 settings for an IPsec tunnel govern how the tunnel handles traffic (e.g. policy-based or route-based, see IPsec Modes) as well as the encryption of that traffic.

Phase 2 entries are used in a few different ways, depending on the IPsec configurations:

  • For policy-based IPsec tunnels, this controls which subnets will enter IPsec. Multiple phase 2 definitions can be added for each phase 1 to allow using multiple subnets inside of a single tunnel.

  • For route-based IPsec, this controls the VTI interface addresses.

  • For mobile IPsec this primarily controls the encryption for phase 2, but can also optionally be used by the IPsec daemon or export utilities to generate a list of networks to the clients for use in split tunneling.

Each Phase 2 entry has the following options:


An on/off switch for this Phase 2 entry only.


The IPsec Mode for this Phase 2 entry, which controls how the tunnel handles traffic. See IPsec Modes for more detailed explanations of each type of mode.

With policy-based IKEv1 tunnels, this must match the outer protocol of the tunnel, for example an IPv4 peer would be Tunnel IPv4. Policy-based IKEv2 tunnels can have either/or (or both).

Tunnel IPv4

A policy-based tunnel that will carry traffic between IPv4 networks matching the specified Local Network and Remote Network.

Tunnel IPv6

A policy-based tunnel that will carry traffic between IPv6 networks matching the specified Local Network and Remote Network.


Encrypts all traffic between the endpoints. The Local Network and Remote Network are not set for transport mode, it assumes the addresses based on the phase 1 settings.

Routed (VTI)

Routed IPsec using Virtual Tunnel Interfaces. The Local Network and Remote Network define the addresses used by the firewall for the VTI interface. Typically only one Phase 2 entry is present for each address family (e.g. one for IPv4, one for IPv6)

See Routed IPsec (VTI) for more information.

Local Network
Tunnel Mode

Defines which subnet or host can be accessed from the other side of the VPN tunnel. This is typically the LAN or other internal subnet for the VPN, but can also be a single IP address if only one client needs to use the tunnel. The Type selector is pre-loaded with choices for each interface (e.g. LAN subnet ), as well as Address and Network choices that allow entering an IP address or subnet manually.

Most often this is set to LAN subnet, meaning the entire LAN will be accessible from the remote network.


Sets a different subnet or address which is used by IPsec to perform NAT on the local network addresses to make them appear to the remote peer as a different subnet.

Set to None to disable NAT for the tunnel.

For more details, see NAT with IPsec Phase 2 Networks.

Routed (VTI) Mode

Sets the local IP address and subnet mask of the ipsecX interface.

Remote Network
Tunnel Mode

(Non-mobile only) Specifies the IP Address or Network which exists on the other (remote) side of the VPN. This field operates similarly to the Local Network option.

Routed (VTI) Mode

Sets the remote IP address for the ipsecX interface tunnel network (the remote address of the VTI).


A description for this Phase 2 entry. Shows up in the IPsec status for reference.

Phase 2 Proposal (Child SA)


Controls how IPsec protects its traffic.

ESP (Encapsulating Security Payload)

Encrypts traffic before sending it to the peer.

In nearly all circumstances, ESP is the correct choice.

AH (Authenticated Header)

Provides assurance the traffic came from a trusted source but does not provide encryption. Rarely used in practice.


With automatic VPN rules (Disable Auto-added VPN rules), the firewall automatically passes the appropriate ESP or AH protocol traffic from the remote endpoint. If automatic VPN rules are disabled, add manual rules to pass the traffic instead.

Encryption algorithms

Sets the encryption algorithms used when negotiating Phase 2 child SA entries with peers. Must match values available to and configured on the peer.

In systems with AES-NI, the fastest and most secure choice is AES-GCM, if it is supported by the peer. If AES-CGM is used, do not select any options for Hash Algorithms in Phase 2.

If AES-NI cannot be used both both peers, use AES with a 128-bit or higher key length.

This set of controls allows for multiple selections so that multiple choices will be accepted when acting as a responder, or proposed when working as an initiator. The best practice is to only select a single desired cipher on both peers, but in some cases, such as mobile clients, selecting multiple will allow a tunnel to work better in both a responder and initiator role.

Hash algorithms

Controls which hash algorithms are used when negotiating phase 2 child SA entries with peers. Must match values available to and configured on the peer.

As with the Encryption Algorithms, multiple hashes may be selected. The best practice is to select a single desired choice if possible. For more discussions on the quality of the various hash types, see Phase 1 Settings.

The optimal choice for speed and security is SHA256, unless using AES-GCM for the Encryption Algorithm. With AES-GCM, no Hash Algorithm should be selected as AES-GCM performs hashing on its own.

PFS key group

Perfect Forward Secrecy (PFS) provides keying material with greater entropy, hence improving the cryptographic security of the connection, at the cost of higher CPU usage during rekeying.

The options have the same properties as the DH key group option in phase 1 (See DH key group), and some products also refer to them as “DH” values even in Phase 2.

The optimal choice for speed and security is 14 (2048 bit). The default is off.


The lifetime for which the negotiated keys will be valid. One hour (3600) is a good setting. Do not set this to too high (e.g. more than about a day: 86400) as doing so will give people more time to crack the key. Don’t be over paranoid either; there is no need to set this to 20 minutes either.

Automatically ping host

For use on non-mobile tunnels, this option tells the firewall to initiate a ping periodically to the specified IP address. This option only works if the firewall has an IP address inside of the Local Network for this Phase 2 entry and the value of the ping host here must be inside of the Remote Network.

See Configuring IPsec Keep Alive for additional information.