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 configuration:

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. It 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:

General Information¶

Description:

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

A name or brief description for this entry. The best practice is to enter a few words to describe the purpose of this phase 2 entry or about the remote end of the tunnel. For example TNSR VTI, DC Management, or ATX DMZ to NYC DMZ.

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

Disabled:

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

Mode:

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.

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.

Transport:

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

Routed (VTI):

Routed IPsec using Virtual Tunnel Interfaces (e.g. ipsecX). 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.

Phase 1:

A link to the IPsec phase 1 entry under which this phase 2 entry exists, along with its IKE ID.

P2 Reqid:

The unique phase 2 request ID for this entry. It is used by IPsec in various contexts, such as for the IPsec VTI interface name.

Networks¶

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. It 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 which means the entire LAN will be accessible from the remote network.

NAT/BINAT:

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.

See also

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 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).

Phase 2 Proposal (SA/Key Exchange)¶

Protocol:

Controls how IPsec protects its traffic.

ESP (Encapsulating Security Payload):

Encrypts traffic before sending it to the peer.

ESP is the correct choice in nearly all circumstances.

AH (Authenticated Header):

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

Note

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. When using AES-GCM do not select any options for Hash Algorithms in phase 2.

If both peers cannot use AES-NI then 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. In some cases, such as mobile clients, selecting multiple will allow a tunnel to work with a variety of clients. It can also be better when acting 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.

See also

For more discussions on the quality of the various hash types see Phase 1 Settings.

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

PFS key group:

Perfect Forward Secrecy (PFS) provides keying material with greater entropy which improves the cryptographic security of the connection. This comes at a 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).

Note

When an IPsec tunnel is initially connected the first child SA will use the DH value from phase 1 in this context. The PFS value from phase 2 is used for subsequent child SA entries and when rekeying. This can lead to a misconfiguration not being noticed initially since it may work at first but fail after the first child SA expires.

Expiration and Replacement¶

Life Time:

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

3600 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. 5400) to help avoid overlap.

If left empty the value defaults to 110% of Rekey Time. If both Life Time and Rekey Time are empty it defaults to 3960.

Rekey Time:

Time, in seconds, before the child SA establishes a new set of keys. This works without interruption and allows both endpoints to seamlessly change to new keys on the fly.

Leave blank to automatically calculate the value based on 90% of Life Time. If both Life Time and Rekey Time are empty it defaults to 3600. Enter a value of 0 to disable rekeying.

Note

If rekeying is disabled connections can be interrupted while a new child SA is negotiated after an old entry expires.

Rand Time:

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

A random value up to this amount will be subtracted from Rekey 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.

Keep Alive¶

Methods which will attempt to keep this phase 2 entry up and active over time.

See also

See Configuring IPsec Keep Alive for additional discussion on these options.

Automatically ping host:

For use on non-mobile tunnel mode entries. 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 is inside the Remote Network.

This option will not initiate a tunnel if its phase 1 Child SA Start Action is set to Responder Only. This option will also not initiate VTI mode tunnels as they do not support trap policies.

Keep Alive:

Enables a periodic check to see if the child SA is connected and initiates when it is down. This function does not send traffic inside the tunnel.

This option works for VTI and tunnel mode phase 2 entries.

For IKEv2 without split connections this only needs enabled on the first phase 2 entry.

See also

See Configuring IPsec Keep Alive for additional information.