Phase 1 Settings¶

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

General Information¶

Description:

A name or brief description of the tunnel. The best practice is to enter a few words to describe the purpose of this VPN tunnel or about the remote end of the tunnel. For example Remote Office, HQ Tunnel, or ATX to NYC.

This functions as a reminder for anyone managing the firewall as to who or what will be using the tunnel. This description is also reflected in the IPsec status which makes it easier to match up status entries with a specific tunnel.

Disabled:

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

IKE ID:

This is a read-only field containing the IKE identifier for this tunnel.

IKE Endpoint Configuration¶

Key Exchange Version:

This can be IKEv1, IKEv2, or Auto.

See also

The differences between IKEv1 and IKEv2 are discussed in IKE.

IKEv1:: IKEv1 is more common and widely supported but has problems supporting common modern issues such as dealing with NAT or mobile clients.
IKEv2 (Default):: An updated version of the protocol which has increased capabilities and security, as well as built-in support for mobile clients and NAT.

Tip

IKEv2 is the best choice when supported by both endpoints.
Auto:: 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. In most cases 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.

Note

On current versions of pfSense software IPv4 and/or IPv6 traffic may be carried inside a tunnel no matter which type of Key Exchange Version or Internet Protocol is used outside the tunnel.

Some third party vendors may only support this when using IKEv2, and on IKEv1 the inner and outer traffic may need to match when connecting to those third party implementations.

Interface:

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 also

See Interface Selection earlier in this document for details on selecting the appropriate interface.

Remote Gateway:

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

This may be set to an IP address or a fully qualified domain name (FQDN). When set to an FQDN the firewall periodically resolves the name using DNS and updates the tunnel when it detects a change.

To allow connections from any remote endpoint with tunnel mode phase 2 entries, use 0.0.0.0/0 for IPv4 or :: for IPv6. When allowing connections from any remote endpoint the Child SA Start Action must be set to None and the Peer Identifier cannot be set to Peer IP Address.

Note

VTI tunnels require a specific remote endpoint address for their interface configuration. They cannot allow connections from “any” or unknown endpoints. Using an FQDN for the remote gateway is a viable workaround provided the remote peer is capable of using dynamic DNS.

Phase 1 Proposal (Authentication)¶

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 pre-defined string known to both endpoints. Since it is simple a string there is a possibility that it can be guessed. For this reason a long and complex key is more secure when using PSK mode.

Mutual Certificate:

A TLS CA and certificate are used to verify the peer. During the phase 1 exchange each peer sends its certificate to the other peer and then validates it against a 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.

Note

This option is only available when Enable PKCS#11 is checked on the Advanced IPsec settings.

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.

EAP-TLS:

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.

EAP-RADIUS:

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, or globally trusted by, the client, but no user certificate.

EAP-MSCHAPv2:

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 properties listed previously. The CA must be imported to, or globally trusted by, the client, but no user certificate.

Negotiation Mode:

(IKEv1 only) The type of authentication security used by this tunnel. This can be either Main or Aggressive.

Main:

Main is the most secure mode as it is strict in its validation. It requires several packets between the peers to accomplish a successful negotiation due to the strict validation procedures, thus is slower.

Using Main mode is the best practice where possible due to its higher security.

Aggressive:

Aggressive is generally the most compatible mode to use with other vendors and is the fastest mode. It is more forgiving with identifier types and tends to be more successful when negotiating with third-party devices.

Aggressive mode 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.

Avoid aggressive mode due to its weaker security unless it is required for interoperability with a third party IPsec implementation.

Identifiers:

Identifiers are used by IPsec to identify remote peers and associate specific peers with a tunnel and its related settings, such as authentication components (keys, certificates, etc).

My Identifier:

Identifier type and value sent by 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.

Most settings are viable so long as both sides agree on the identifier type and value.

Peer Identifier:

Identifies the remote peer on the other 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.

Most settings are viable so long as both sides agree on the identifier type and value.

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 incoming IPsec packets are received by this firewall, which should match the value used in Remote Gateway.

IP Address:

A specific static and manually-entered IP address to be used as the identifier. One potential use for this is when the firewall is behind NAT where the real external IP address could be used in this field.

Fully qualified domain name:

A fully qualified domain name (FQDN) such as host.example.com. Enter a value in that format into the box. This value is sent as-is and is not resolved to an IP address.

When using Mutual Certificate authentication this can be used to match the CN or SAN of a certificate to ensure the correct certificate is associated with this tunnel endpoint.

User fully qualified domain name / E-mail:

An e-mail address such as vpn@example.com.

ASN.1 Distinguished Name:

When using Mutual Certificate authentication this can be set to the subject of the certificate which also ensures the correct certificate is associated with this tunnel endpoint.

For example: /CN=host.example.com/C=US/ST=Texas/L=Austin/O=Example Co

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.

Any:

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) A string known by both peers used as a key to authenticate the tunnel, similar to a password. This key is case-sensitive and must be exactly the same on both endpoints.

The best practice is to make this as long and complex as possible. There is little incentive to keep the value simple as this only gets entered once on each peer and there is no need for a human to remember its contents.

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

Warning

This 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 copied to the peer. 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 > Certificates on the Certificate Authorities tab.

Phase 1 Proposal (Encryption Algorithm)¶

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. AES-GCM is the most desirable cipher for both speed and security, but may not be widely supported by other vendors and equipment. AES with a 128-bit key length is a common choice on endpoints which lack support for AES-GCM.

Multiple combinations of these options can be defined using the fa-plus Add Algorithm button to add another line. The order of the entries is the order of preference so configure the strongest and/or most desirable settings first.

Encryption Algorithm:

Use the strongest available option supported by both endpoints. 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 or whichever option is strongest in common between both sides.

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.

A tunnel configured for AES-GCM uses this solely as a PRF because AES-GCM performs hashing internally. The fastest choice to use in combination with AES-GCM on hardware capable of accelerating AES, such as AES-NI, is AES-XCBC. However, AES-XCBC is less secure than other algorithms such as SHA256 and may not be supported by other platforms. For different types of Encryption Algorithms, use SHA256 if possible. If the peer does not support any of these, use the strongest available option supported by the peer.

PRF:

Specifically set a manual Pseudo-Random Function 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.

Note

IPsec uses this DH group for the first child SA when initially building a tunnel. The PFS option of a phase 2 entry is used for subsequent child SA entries and when rekeying.

Expiration and Replacement¶

The total lifetime for phase 1 defines how often the connection will be rekeyed or reauthenticated by the IPsec daemon.

Warning

Take care when crafting these values. Incorrect or sub-optimal values can lead to problems such as tunnels failing to renegotiate in a timely manner or multiple duplicate security associations.

See Troubleshooting Duplicate IPsec SA Entries for more details.

The specific values for these fields depend on the IKE mode and which mechanisms are supported by both endpoints. In most cases setting only the Life Time value will allow the firewall to choose the best options.

Life Time:

The hard IKE SA life time, in seconds, after which the IKE SA will be expired. This value must be larger than Rekey Time and Reauth Time and cannot be set to the same value.

28800 total seconds is a good balance of frequent rekeying without being too aggressive.

Tip

Set one endpoint to this recommended value, but use a higher Life Time on the other endpoint by at least 10% (e.g. 31680) to help avoid overlap.

If left empty the value defaults to 110% of Rekey Time or Reauth Time, whichever is higher.

Rekey Time:

Time, in seconds, before the IPsec daemon 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 and allows both endpoints to seamlessly change to new keys on the fly. This is optimal, but implementation quality varies by vendor.

Leave blank to automatically calculate the value based on 90% of Life Time. Enter a value of 0 to disable rekeying.

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

Note

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. This also includes a new round of 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 to automatically calculate the value based on 90% of Life Time. Enter a value of 0 to disable reauthentication.

Rand Time:

Introduces randomness into the rekey or reauthentication process to avoid both endpoints attempting to renegotiate simultaneously.

A random value up to this amount will be subtracted from Rekey Time or Reauth Time for each scheduled renegotiation to reduce the chance of collisions.

If left empty, the value defaults to 10% of Life Time. Enter 0 to disable randomness.

Warning

Disabling Rand Time increases the likelihood of simultaneous renegotiation which can lead to duplicate security associations.

See Troubleshooting Duplicate IPsec SA Entries for more details.

Advanced Options¶

Child SA Start Action:

This option forces specific behavior performed by the IPsec daemon when loading a phase 2 configuration (“Child SA”) during initial service startup. This happens at boot and when the service is restarted for any reason.

Default:

Automatically chooses behavior based on other settings.

None (Responder Only):

The IPsec daemon will not attempt to initiate the tunnel. The tunnel will only be established by an initiation attempt from the far side. If DPD detects that the tunnel has failed, the tunnel will be left down rather than restarted. The far side must reconnect.

This is the default behavior for mobile IPsec and tunnels with unknown remote endpoints.

Initiate at Start (VTI or Tunnel Mode):

The firewall will attempt to establish the IPsec tunnel immediately when the IPsec daemon starts.

This is the default behavior for VTI mode.

Initiate on Demand (Tunnel mode only):

Traffic which matches the networks in phase 2 definitions for this tunnel (“interesting traffic”) will trigger initiation of the tunnel.

This is the default behavior of tunnel mode.

Note

Finding “interesting” traffic relies on trap policies to function and trap policies are not compatible with VTI mode.

Child SA Close Action:

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

Default:

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.

Restart/Reconnect:

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.

Warning

This option must not be set on both peers! Both peers would 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.

Auto:: (Default) Allows the IPsec daemon to detect and use NAT Traversal automatically when it determines one or both peers is behind NAT.
Force:: Instructs the IPsec daemon to always use NAT Traversal for the tunnel. This can help if there is a known issue detecting NAT. It can also help 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.

MOBIKE:

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 a connection active. Leave disabled unless the remote peer must change addresses dynamically.

Gateway Duplicates:

Allows multiple phase 1 configurations to use the same remote endpoint address.

Warning

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

Split Connections:

(IKEv2 Only) By default when an IKEv2 tunnel has multiple phase 2 definitions the settings are collapsed in the IPsec configuration such that all phase 2 combinations are held in a single child SA.

Split Connections changes this behavior to be more like IKEv1 where each phase 2 entry is configured by the daemon as its 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, Checkpoint, Fortinet, and Juniper 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:

Enables a GUI 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.

Custom IKE/NAT-T Ports:

In rare situations the remote endpoint may be running IPsec on alternate port numbers for IKE and NAT-T. These settings can accommodate such endpoints.

Remote IKE Port:: The UDP port for IKE on the remote gateway. Leave empty for the default automatic behavior (Port 500 for IKE and 4500 for NAT-T)
Remote NAT-T Port:: The UDP port for NAT-T on the remote gateway.

Note

If Remote IKE Port is empty and NAT-T contains a value the tunnel will use only NAT-T.

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 is otherwise 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.

Delay:: 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. This per-tunnel value is only honored for IKEv1.

Note

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