Choosing configuration options¶
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.
Phase 1 Settings¶
The settings here control the phase 1 negotiation portion of the tunnel, as described previously.
The Disabled checkbox controls whether or not this tunnel (and its associated phase 2 entries) are active and used.
Key Exchange Version¶
The Key Exchange Version selector controls whether the tunnel will use IKE version 1 (V1) or IKE version 2 (V2). IKEv2 is a newer version of IKE that is desirable in many ways. The differences are discussed in IKE. In most cases, IKEv1 will be used unless both sides properly support IKEv2.
The Internet Protocol selector sets 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.
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 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.
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 pfSense firewall, 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.
The Remote Gateway is the IPsec peer for this phase 1. This is the endpoint on the other side of the tunnel to which IPsec will negotiate this phase 1. 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.
The Description for the phase 1 is some text to use for identifying this phase 1. It’s not used in the IPsec settings, it’s only for reference.
An IPsec phase 1 can be authenticated using a pre-shared key (PSK) or RSA 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.
When using 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.
In Mutual RSA mode, 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.
Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with a shared (or “group”) pre-shared key.
Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with RSA certificate authentication using certificates on both the client and server.
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 RSA+Xauth , but it is easier on the clients.
Used with mobile IPsec and IKEv2, RSA EAP-TLS verifies that certificates on the client and server are from the same shared CA, similar to Mutual RSA. The client and server certificates require special handling:
- The server certificate must have the firewall’s name as it exists in DNS listed in its Common Name, and again as a Subject Alternative Name (SAN). The firewall’s IP address must also be listed in a SAN.
- The identifier in Phase 1 must also be set to match the firewall’s hostname as listed in the Common Name of the certificate.
- The client certificate must have the user’s name 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.
For IKEv1, two Negotiation Mode choices are supported: main , aggressive. This selection is not present when using IKEv2.
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.
Aggressive is generally the most compatible and is the fastest mode. It is a bit more forgiving with identifier types, and tends to be more successful when negotiating with third-party devices in some cases. 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 / Peer Identifier¶
Here, choose the identifier used to send to the remote peer, and also for verifying the identity of the remote peer. The following identifier types can be chosen for the My Identifier and Peer Identifier selectors. If needed, a text box will appear to enter a value to be used for the identifier.
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.
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.
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
rather than an FQDN.
ASN.1 Distinguished Name¶
If using Mutual RSA authentication, this can be the subject of the certificate being used, or a similar string.
An arbitrary string to use as the identifier.
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 not relevant or available for a Peer Identifier as the hostname may be used directly in the Remote Gateway field and use Peer IP Address for the 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.
Phase 1 Encryption algorithms¶
There are many options for encryption algorithms on both phase 1 and phase 2.
The current options are all considered cryptographically secure. Which to choose depends on the device to which the tunnel will connect, and the hardware available in this firewall. Generally speaking, AES is the most desirable cipher and the longest key length (256 bits) is best. 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.
More information about ciphers and acceleration is available in Phase 2 Encryption algorithms.
Phase 1 Hash algorithms¶
Hash algorithms are used with IPsec to verify the authenticity of packet data. MD5, SHA1, SHA256, SHA384, SHA512, and AES-XCBC are the available hash algorithms on phase 1 and phase 2. All are considered cryptographically secure, though SHA1 (Secure Hash Algorithm, Revision 1) and its variants are considered the stronger than MD5. SHA1 does require more CPU cycles than MD5, and the larger values of SHA in turn require even greater CPU power. 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.
The implementation of SHA256-512 is RFC 4868 compliant on the FreeBSD version used by pfSense. RFC 4868 compliance breaks compatibility with stacks that implemented draft-ietf-ipsec-ciph-sha-256-00, including FreeBSD 8.1 and earlier. Before using SHA256, 384, or 512, check with the other side to ensure they are also RFC 4868 compliant implementations or they will not work. The relevant FreeBSD commit message when this happened explains in a little more detail.
DH key group¶
All of the DH (Diffie-Hellman, named after its authors) key group options are considered cryptographically secure, though the higher numbers are slightly more secure at the cost of increased CPU usage.
The lifetime specifies how often the connection must be rekeyed, specified in seconds. 28800 seconds on phase 1 is a common configuration and is appropriate for most scenarios.
My Certificate (If using Mutual RSA)¶
This option only appears if using an RSA-based Authentication Mode. The list is populated using the certificates present in the firewall’s configuration. Certificates can be imported and managed under System > Cert Manager on the Certificates tab. Choose the certificate to use for this IPsec phase 1 from the list. The CA for this certificate must match the one chosen in the My Certificate Authority selector.
Selecting this option will instruct pfSense to not initiate a rekey event on the tunnel. Some clients (Especially Windows clients behind NAT) will misbehave when they receive a rekey request, so it is safer in these cases to allow the client to initiate the rekey by disabling the option on the server. Normally both sides would rekey as needed, but if the tunnel often fails when a rekey event occurs, try selecting this option on only one side.
This option only appears for IKEv2 tunnels, IKEv1 will always re-authenticate. If this option is checked, then when a tunnel rekeys it does not re-authenticate the peer. When unchecked, the SA is removed and negotiated in full rather than only rekeying.
If Responder Only is selected, then pfSense will not attempt to initiate the tunnel when traffic attempts to cross. The tunnel will only be established when the far side initiates the connection. 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.
The NAT Traversal option, also known as NAT-T, is only available for IKEv1. IKEv2 has NAT Traversal integrated in such a way that the option is unnecessary. NAT Traversal can encapsulate the 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 will be behind a NAT device, then NAT Traversal will likely be necessary. The default setting of Auto will use NAT Traversal in cases where its need is detected. The option may also be set to Force to ensure NAT Traversal will always be used for the tunnel. This can help if there is a known issue carrying ESP traffic between the two endpoints.
MOBIKE is an extension to IKEv2 that handles multi-homed clients and clients that roam between different IP addresses. This is primarily used with mobile clients to allow them to switch remote addresses while keeping the connection active.
This option is specific to IKEv2 and configures the Phase 2 entries such a way they use separate connection entries, rather than one single traffic selector per child Security Association. Specifically, this is known to be an issue with Cisco products such as ASA.
If an IKEv2 tunnel is in use with multiple Phase 2 entries, and only one Phase 2 network pair will establish a connection, activate this option.
Dead Peer Detection (DPD)¶
Dead Peer Detection (DPD) is a periodic check that the host on the other end of the IPsec tunnel is still alive. If a DPD check fails, the tunnel is torn down by removing its associated SAD entries and renegotiation is attempted.
The Delay field controls how often a DPD check is attempted, and the Max
Failures field controls how many of these checks must fail before a tunnel is
considered to be a down state. The default values of
10 seconds and
failures will result in the tunnel being considered down after approximately one
minute. These values may be increased for bad quality links to avoid tearing
down a usable, but lossy, tunnel.
Phase 2 Settings¶
The phase 2 settings for an IPsec tunnel govern what traffic will enter the tunnel as well as how that traffic is encrypted. For normal tunnels, this controls the subnets that will enter the firewall. For mobile clients this primarily controls the encryption for phase 2, but can also optionally supply a list of networks to the clients for use in split tunneling. Multiple phase 2 definitions can be added for each phase 1 to allow using multiple subnets inside of a single tunnel.
This setting controls whether or not this phase 2 entry is active.
This option allows traditional tunneling mode of IPsec, or transport mode. Tunneling mode can also specify either IPv4 or IPv6.
Tunnel IPv4/IPv6 Mode¶
When using either Tunnel IPv4 or Tunnel IPv6 for this phase 2 entry, the firewall will tunnel IPv4 or IPv6 traffic matching the specified Local Network and Remote Network. A phase 2 can be for either IPv4 or IPv6, and the network values are validated based on that choice. Traffic matching both the Local Network and Remote Network will enter the tunnel and be delivered to the other side.
With IKEv1, only one of IPv4 or IPv6 may be used, and it must match the same address family used to establish the tunnel’s Phase 1. With IKEv2, both types may be used in the same tunnel.
Transport mode will encrypt traffic between the IP addresses used as the phase 1 endpoints. This mode allows encrypting traffic from the firewall’s external IP address to the external IP address on the far side. Any traffic sent between the two nodes will be encrypted, so using other tunneling methods that do not employ encryption, such as a GIF or GRE tunnel, can be safely used. The Local Network and Remote Network are not set for transport mode, it assumes the addresses based on the phase 1 settings.
Local Network (If using a Tunnel mode)¶
As the name implies, this option sets the Local Network which will be associated with this phase 2. 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 subnet choices for each interface (e.g. LAN subnet ), as well as Address and Network choices that allow entering an IP address or subnet manually.
To perform NAT on local network addresses to make them appear as a different subnet or as a public IP address, use the NAT/BINAT Translation fields. If a single IP address is specified in Local Network and a single IP address in the NAT/BINAT Translation Type field, then a 1:1 NAT translation will be set up between the two. 1:1 NAT is also setup if a subnet of the same size is used in both fields. If the Local Network is a subnet, but the NAT/BINAT Translation is set to a single IP address, then a 1:many NAT (PAT) translation is set up that works like an outbound NAT rule on WAN, all outbound traffic will be translated from the local network to the single IP in the NAT field. If NAT is not needed on the IPsec traffic, leave it set to None.
Remote Network (If using a Tunnel mode)¶
This option (only present for non-mobile tunnels) specifies the IP Address or Network that exists on the other (remote) side of the VPN. It operates similarly to the Local Network option mentioned previously.
IPsec has the option of choosing AH (Authenticated Header) or ESP (Encapsulating Security Payload). In nearly all circumstances, ESP is used as it is the only option that encrypts traffic. AH only provides assurance the traffic came from the trusted source and is rarely used.
Phase 2 Encryption algorithms¶
In systems with AES-NI, the fastest and most secure choice is AES-GCM, provided the remote device supports it as well. When using AES-GCM in Phase 2, use AES in Phase 1 with an equivalent key length. Also if AES-CGM is used, do not select any options for Hash Algorithms in Phase 2.
When using systems with glxsb accelerators, such as ALIX, choose AES 128 for best performance. For systems with hifn accelerators, chose 3DES or AES for best performance. Both AES and Blowfish allow selecting the key length of the cipher in varying steps between 128-bit and 256-bit. Lower values will be faster, larger values are more cryptographically secure. For systems without a hardware cryptography accelerator, Blowfish and CAST are the fastest options.
The phase 2 encryption choices allow for multiple selections so that either multiple choices will be accepted when acting as a responder, or multiple combinations will be tried when working as an initiator. It’s best to only select the single desired cipher, but in some cases selecting multiple will allow a tunnel to work better in both a responder and initiator role.
Phase 2 Hash algorithms¶
As with the Encryption Algorithms, multiple hashes may be selected. It is still best to only select the single desired choice if possible. For more discussions on the quality of the various hash types, see Phase 1 Hash algorithms.
When using AES-GCM for the Phase 2 Encryption Algorithm, do not select any options for the Hash algorithm!
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 when rekeying occurs. 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 Lifetime option specifies how often the connection must be rekeyed, in seconds. 3600 seconds on phase 2 is a common configuration and is appropriate for most scenarios.
Automatically Ping Host (Keep Alive)¶
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.