Fortinet black logo

Handbook

Configuring Phase 2 parameters

6.0.0
Copy Link
Copy Doc ID 4afb0436-a998-11e9-81a4-00505692583a:156465
Download PDF

Configuring Phase 2 parameters

If you are creating a hub-and-spoke configuration or an Internet-browsing configuration, you may have already started defining some of the required Phase 2 parameters. If so, edit the existing definition to complete the configuration.

Specifying the Phase 2 parameters

  1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
  2. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
  3. Enter a Name for the Phase 2 configuration, and select a Phase 1 configuration from the drop-down list.
  4. Select Advanced.
  5. Include the appropriate entries as follows:

Phase 2 Proposal

Select the encryption and authentication algorithms that will be used to change data into encrypted code.

Add or delete encryption and authentication algorithms as required. Select a minimum of one and a maximum of three combinations. The remote peer must be configured to use at least one of the proposals that you define.

It is invalid to set both Encryption and Authentication to null.

Encryption

Select a symmetric-key algorithms:

NULL — Do not use an encryption algorithm.
DES — Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key.
3DES — Triple-DES; plain text is encrypted three times by three keys.
AES128 — A 128-bit block algorithm that uses a 128-bit key.
AES192 — A 128-bit block algorithm that uses a 192-bit key.
AES256 — A 128-bit block algorithm that uses a 256-bit key.
ChaCha20/Poly1305— A 128-bit block algorithm that uses a 128-bit key and a symmetric cipher. Only available for IKEv2.

Authentication

You can select either of the following message digests to check the authenticity of messages during an encrypted session:

NULL — Do not use a message digest.
MD5 — Message Digest 5.
SHA1 — Secure Hash Algorithm 1 - a 160-bit message digest.

To specify one combination only, set the Encryption and Authentication options of the second combination to NULL. To specify a third combination, use the Add button beside the fields for the second combination.

For information regarding NP accelerated offloading of IPsec VPN authentication algorithms, see Hardware Acceleration.

Enable replay detection

Optionally enable or disable replay detection. Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel.

Enable perfect forward secrecy (PFS)

Enable or disable PFS. Perfect forward secrecy (PFS) improves security by forcing a new Diffie‑Hellman exchange whenever keylife expires.

Diffie-Hellman Group

Select one Diffie-Hellman group (1, 2, 5, 14 through 21, or 27 through 30). The remote peer or dialup client must be configured to use the same group.

Keylife

Select the method for determining when the Phase 2 key expires: Seconds, KBytes, or Both. If you select Both, the key expires when either the time has passed or the number of KB have been processed. The range is from 120 to 172800 seconds, or from 5120 to 2147483648 KB.

Autokey Keep Alive

Enable the option if you want the tunnel to remain active when no data is being processed.

Auto-negotiate

Enable the option if you want the tunnel to be automatically renegotiated when the tunnel expires.

DHCP-IPsec

Select Enable if the FortiGate unit acts as a dialup server and FortiGate DHCP server or relay will be used to assign VIP addresses to FortiClient dialup clients. The DHCP server or relay parameters must be configured separately.

If the FortiGate unit acts as a dialup server and the FortiClient dialup client VIP addresses match the network behind the dialup server, select Enable to cause the FortiGate unit to act as a proxy for the dialup clients.

This is available only for Phase 2 configurations associated with a dialup Phase 1 configuration. It works only on policy-based VPNs.

Autokey Keep Alive

The Phase 2 SA has a fixed duration. If there is traffic on the VPN as the SA nears expiry, a new SA is negotiated and the VPN switches to the new SA without interruption. If there is no traffic, however, the SA expires (by default) and the VPN tunnel goes down. A new SA will not be generated until there is traffic.

The Autokey Keep Alive option ensures that a new Phase 2 SA is negotiated, even if there is no traffic, so that the VPN tunnel stays up.

Auto-negotiate

By default, the Phase 2 security association (SA) is not negotiated until a peer attempts to send data. The triggering packet and some subsequent packets are dropped until the SA is established. Applications normally resend this data, so there is no loss, but there might be a noticeable delay in response to the user.

If the tunnel goes down, the auto-negotiate feature (when enabled) attempts to re-establish the tunnel. Auto-negotiate initiates the Phase 2 SA negotiation automatically, repeating every five seconds until the SA is established.

Automatically establishing the SA can be important for a dialup peer. It ensures that the VPN tunnel is available for peers at the server end to initiate traffic to the dialup peer. Otherwise, the VPN tunnel does not exist until the dialup peer initiates traffic.

The auto-negotiate feature is available through the Command Line Interface (CLI) via the following commands:

config vpn ipsec phase2

edit <phase2_name>

set auto-negotiate enable

end

Installing dynamic selectors via auto-negotiate

The IPsec SA connect message generated is used to install dynamic selectors. These selectors can now be installed via the auto-negotiate mechanism. When phase 2 has auto-negotiate enabled, and phase 1 has mesh-selector-type set to subnet, a new dynamic selector will be installed for each combination of source and destination subnets. Each dynamic selector will inherit the auto-negotiate option from the template selector and begin SA negotiation. Phase 2 selector sources from dial-up clients will all establish SAs without traffic being initiated from the client subnets to the hub.

DHCP-IPsec

Select this option if the FortiGate unit assigns VIP addresses to FortiClient dialup clients through a DHCP server or relay. This option is available only if the Remote Gateway in the Phase 1 configuration is set to Dialup User and it works only on policy-based VPNs.

With the DHCP-IPsec option, the FortiGate dialup server acts as a proxy for FortiClient dialup clients that have VIP addresses on the subnet of the private network behind the FortiGate unit. In this case, the FortiGate dialup server acts as a proxy on the local private network for the FortiClient dialup client. A host on the network behind the dialup server issues an ARP request, corresponding to the device MAC address of the FortiClient host (when a remote server sends an ARP to the local FortiClient dialup client). The FortiGate unit then answers the ARP request on behalf of the FortiClient host, and forwards the associated traffic to the FortiClient host through the tunnel.

Acting as a proxy prevents the VIP address assigned to the FortiClient dialup client from causing possible ARP broadcast problems — the normal and VIP addresses can confuse some network switches by two addresses having the same MAC address.

IPsec support for ChaCha20/Poly1305 AEAD cipher

In IKEv2, to support RFC 7634, crypto algorithms ChaCha20 and Poly1305 can be used together as a combined mode AEAD cipher (like aes-gcm) in the new crypto_ftnt cipher in cipher_chacha20poly1305.c.

Syntax

config vpn ipsec phase2-interface

edit <name>

set phase1name <name>

set proposal chacha20poly1305

next

end

IPsec support for AES-GCM for IKEv2 Phase 1

In IKEv2, to support RFC 5282, AEAD algorithm AES-GCM is now supported, both 128 and 256-bit variants.

Syntax

config vpn ipsec phase2-interface

edit <name>

set phase1name <name>

set proposal [aes128gcm | aes256gcm]

next

end

Configuring Phase 2 parameters

If you are creating a hub-and-spoke configuration or an Internet-browsing configuration, you may have already started defining some of the required Phase 2 parameters. If so, edit the existing definition to complete the configuration.

Specifying the Phase 2 parameters

  1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
  2. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
  3. Enter a Name for the Phase 2 configuration, and select a Phase 1 configuration from the drop-down list.
  4. Select Advanced.
  5. Include the appropriate entries as follows:

Phase 2 Proposal

Select the encryption and authentication algorithms that will be used to change data into encrypted code.

Add or delete encryption and authentication algorithms as required. Select a minimum of one and a maximum of three combinations. The remote peer must be configured to use at least one of the proposals that you define.

It is invalid to set both Encryption and Authentication to null.

Encryption

Select a symmetric-key algorithms:

NULL — Do not use an encryption algorithm.
DES — Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key.
3DES — Triple-DES; plain text is encrypted three times by three keys.
AES128 — A 128-bit block algorithm that uses a 128-bit key.
AES192 — A 128-bit block algorithm that uses a 192-bit key.
AES256 — A 128-bit block algorithm that uses a 256-bit key.
ChaCha20/Poly1305— A 128-bit block algorithm that uses a 128-bit key and a symmetric cipher. Only available for IKEv2.

Authentication

You can select either of the following message digests to check the authenticity of messages during an encrypted session:

NULL — Do not use a message digest.
MD5 — Message Digest 5.
SHA1 — Secure Hash Algorithm 1 - a 160-bit message digest.

To specify one combination only, set the Encryption and Authentication options of the second combination to NULL. To specify a third combination, use the Add button beside the fields for the second combination.

For information regarding NP accelerated offloading of IPsec VPN authentication algorithms, see Hardware Acceleration.

Enable replay detection

Optionally enable or disable replay detection. Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel.

Enable perfect forward secrecy (PFS)

Enable or disable PFS. Perfect forward secrecy (PFS) improves security by forcing a new Diffie‑Hellman exchange whenever keylife expires.

Diffie-Hellman Group

Select one Diffie-Hellman group (1, 2, 5, 14 through 21, or 27 through 30). The remote peer or dialup client must be configured to use the same group.

Keylife

Select the method for determining when the Phase 2 key expires: Seconds, KBytes, or Both. If you select Both, the key expires when either the time has passed or the number of KB have been processed. The range is from 120 to 172800 seconds, or from 5120 to 2147483648 KB.

Autokey Keep Alive

Enable the option if you want the tunnel to remain active when no data is being processed.

Auto-negotiate

Enable the option if you want the tunnel to be automatically renegotiated when the tunnel expires.

DHCP-IPsec

Select Enable if the FortiGate unit acts as a dialup server and FortiGate DHCP server or relay will be used to assign VIP addresses to FortiClient dialup clients. The DHCP server or relay parameters must be configured separately.

If the FortiGate unit acts as a dialup server and the FortiClient dialup client VIP addresses match the network behind the dialup server, select Enable to cause the FortiGate unit to act as a proxy for the dialup clients.

This is available only for Phase 2 configurations associated with a dialup Phase 1 configuration. It works only on policy-based VPNs.

Autokey Keep Alive

The Phase 2 SA has a fixed duration. If there is traffic on the VPN as the SA nears expiry, a new SA is negotiated and the VPN switches to the new SA without interruption. If there is no traffic, however, the SA expires (by default) and the VPN tunnel goes down. A new SA will not be generated until there is traffic.

The Autokey Keep Alive option ensures that a new Phase 2 SA is negotiated, even if there is no traffic, so that the VPN tunnel stays up.

Auto-negotiate

By default, the Phase 2 security association (SA) is not negotiated until a peer attempts to send data. The triggering packet and some subsequent packets are dropped until the SA is established. Applications normally resend this data, so there is no loss, but there might be a noticeable delay in response to the user.

If the tunnel goes down, the auto-negotiate feature (when enabled) attempts to re-establish the tunnel. Auto-negotiate initiates the Phase 2 SA negotiation automatically, repeating every five seconds until the SA is established.

Automatically establishing the SA can be important for a dialup peer. It ensures that the VPN tunnel is available for peers at the server end to initiate traffic to the dialup peer. Otherwise, the VPN tunnel does not exist until the dialup peer initiates traffic.

The auto-negotiate feature is available through the Command Line Interface (CLI) via the following commands:

config vpn ipsec phase2

edit <phase2_name>

set auto-negotiate enable

end

Installing dynamic selectors via auto-negotiate

The IPsec SA connect message generated is used to install dynamic selectors. These selectors can now be installed via the auto-negotiate mechanism. When phase 2 has auto-negotiate enabled, and phase 1 has mesh-selector-type set to subnet, a new dynamic selector will be installed for each combination of source and destination subnets. Each dynamic selector will inherit the auto-negotiate option from the template selector and begin SA negotiation. Phase 2 selector sources from dial-up clients will all establish SAs without traffic being initiated from the client subnets to the hub.

DHCP-IPsec

Select this option if the FortiGate unit assigns VIP addresses to FortiClient dialup clients through a DHCP server or relay. This option is available only if the Remote Gateway in the Phase 1 configuration is set to Dialup User and it works only on policy-based VPNs.

With the DHCP-IPsec option, the FortiGate dialup server acts as a proxy for FortiClient dialup clients that have VIP addresses on the subnet of the private network behind the FortiGate unit. In this case, the FortiGate dialup server acts as a proxy on the local private network for the FortiClient dialup client. A host on the network behind the dialup server issues an ARP request, corresponding to the device MAC address of the FortiClient host (when a remote server sends an ARP to the local FortiClient dialup client). The FortiGate unit then answers the ARP request on behalf of the FortiClient host, and forwards the associated traffic to the FortiClient host through the tunnel.

Acting as a proxy prevents the VIP address assigned to the FortiClient dialup client from causing possible ARP broadcast problems — the normal and VIP addresses can confuse some network switches by two addresses having the same MAC address.

IPsec support for ChaCha20/Poly1305 AEAD cipher

In IKEv2, to support RFC 7634, crypto algorithms ChaCha20 and Poly1305 can be used together as a combined mode AEAD cipher (like aes-gcm) in the new crypto_ftnt cipher in cipher_chacha20poly1305.c.

Syntax

config vpn ipsec phase2-interface

edit <name>

set phase1name <name>

set proposal chacha20poly1305

next

end

IPsec support for AES-GCM for IKEv2 Phase 1

In IKEv2, to support RFC 5282, AEAD algorithm AES-GCM is now supported, both 128 and 256-bit variants.

Syntax

config vpn ipsec phase2-interface

edit <name>

set phase1name <name>

set proposal [aes128gcm | aes256gcm]

next

end