Fortinet white logo
Fortinet white logo

Administration Guide

Phase 2 configuration

Phase 2 configuration

After phase 1 negotiations end successfully, phase 2 begins. In Phase 2, the VPN peer or client and the FortiGate exchange keys again to establish a secure communication channel. The phase 2 proposal parameters select the encryption and authentication algorithms needed to generate keys for protecting the implementation details of security associations (SAs). The keys are generated automatically using a Diffie-Hellman algorithm.

The basic phase 2 settings associate IPsec phase 2 parameters with the phase 1 configuration that specifies the remote end point of the VPN tunnel. In most cases, you need to configure only basic Phase 2 settings.

Some settings can be configured in the CLI. The following options are available in the VPN Creation Wizard after the tunnel is created:

New Phase 2

Name

Phase 2 definition name.

Local Address

A value of 0.0.0.0/0 means all IP addresses behind the local VPN peer. Add a specific address or range to allow traffic from and to only this local address.

See Quick mode selectors.

Remote Address

Enter the destination IP address that corresponds to the recipients or network behind the remote VPN peer. A value of 0.0.0.0/0 means all IP addresses behind the remote VPN peer.

See Quick mode selectors.

Advanced

Select the encryption and authentication algorithms that will be proposed to the remote VPN peer. To establish a VPN connection, at least one of the proposals specified must match the configuration on the remote peer.

Encryption

The following symmetric-key encryption algorithms are available:

  • 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: Advanced Encryption Standard, a 128-bit block algorithm that uses a 128-bit key.
  • AES128GCM: AES in Galois/Counter Mode, a 128-bit block algorithm that uses a 128-bit key. Only available for IKEv2.
  • AES192: a 128-bit block algorithm that uses a 192-bit key.
  • AES256: a 128-bit block algorithm that uses a 256-bit key.
  • AES256GCM: AES in Galois/Counter Mode, a 128-bit block algorithm that uses a 256-bit key. Only available for IKEv2.
  • CHACHA20POLY1305: a 128-bit block algorithm that uses a 128-bit key and a symmetric cipher. Only available for IKEv2.

See ChaCha20 and Poly1305 AEAD cipher, AES-GCM for IKEv2 phase 1, and HMAC settings.

Authentication

The following message digests that check the message authenticity during an encrypted session are available:

  • NULL: do not use a message digest.
  • MD5: message digest 5.
  • SHA1: secure hash algorithm 1; a 160-bit message digest.
  • SHA256: a 256-bit message digest.
  • SHA384: a 384-bit message digest.
  • SHA512: a 512-bit message digest.

See also HMAC settings.

Enable Replay Detection

Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel.

Replay detection allows the FortiGate to check all IPsec packets to see if they have been received before. If any encrypted packets arrive out of order, the FortiGate discards them.

Note that 64-bit extended sequence numbers (as described in RFC 4303, RFC 4304 as an addition to IKEv1, and RFC 5996 for IKEv2) are supported for IPsec when replay detection is enabled.

Enable Perfect Forward Secrecy (PFS)

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

Diffie-Hellman Group

Asymmetric key algorithms used for public key cryptography.

Select one or more from groups 1, 2, 5, and 14 through 32. At least one of the Diffie-Hellman Groups (DH) settings on the remote peer or client must match one the selections on the FortiGate. Failure to match one or more DH groups will result in failed negotiations.

Local Port

Enter the port number that the local VPN peer uses to transport traffic related to the specified service (protocol number). The range is from 0 to 65535. To specify all ports, select All, or enter 0.

Remote Port

Enter the port number that the remote VPN peer uses to transport traffic related to the specified service (protocol number). To specify all ports, select All, or enter 0.

Protocol

Enter the IP protocol number of the service. To specify all services, select All, or enter 0.

Auto-negotiate

Select this option for the tunnel to be automatically renegotiated when the it expires. See Auto-negotiate.

Autokey Keep Alive

Select this option for the tunnel to remain active when no data is being processed.

Key Lifetime

Select the method for determining when the phase 2 key expires:

  • Seconds
  • Kilobytes
  • Both

Enter a corresponding value for Seconds and/or Kilobytes in the text boxes.

If Both is selected, the key expires when either the time has passed or the number of kilobytes have been processed.

Quick mode selectors

Quick mode selectors determine which IP addresses can perform IKE negotiations to establish a tunnel. By only allowing authorized IP addresses access to the VPN tunnel, the network is more secure.

The default settings are as broad as possible: any IP address or configured address object using any protocol on any port.

Caution

While the dropdown menus for specifying an address also show address groups, the use of address groups may not be supported on a remote endpoint device that is not a FortiGate.

When configuring a quick mode selector for Local Address and Remote Address, valid options include IPv4 and IPv6 single addresses, subnets, or ranges.

There are some configurations that require specific selectors:

  • The VPN peer is a third-party device that uses specific phase2 selectors.
  • The FortiGate connects as a dialup client to another FortiGate, in which case (usually) you must specify a local IP address, IP address range, or subnet. However, this is not required if you are using dynamic routing and mode-cfg.

With FortiOS VPNs, your network has multiple layers of security, with quick mode selectors being an important line of defense:

  • Routes guide traffic from one IP address to another.
  • Phase 1 and phase 2 connection settings ensure there is a valid remote end point for the VPN tunnel that agrees on the encryption and parameters.
  • Quick mode selectors allow IKE negotiations only for allowed peers.
  • Security policies control which IP addresses can connect to the VPN.
  • Security policies also control what protocols are allowed over the VPN along with any bandwidth limiting.

If you are editing an existing phase 2 configuration, the local address and remote address fields are unavailable if the tunnel has been configured to use firewall addresses as selectors. This option exists only in the CLI.

Using the add-route option

Consider using the add-route option to add a route to a peer destination selector in phase 2 to automatically match the settings in phase 1.

To configure add-route:
config vpn ipsec {phase2 | phase2-interface}
    edit <name>
        set add-route {phase1 | enable | disable}
    next
end

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.

To configure auto-negotiate:
config vpn ipsec phase2
    edit <phase2_name>
        set auto-negotiate enable
    next
end

Installing dynamic selectors via auto-negotiate

The IPsec SA connect message generated is used to install dynamic selectors. These selectors can 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 dialup clients will all establish SAs without traffic being initiated from the client subnets to the hub.

DHCP

The dhcp-ipsec option lets the FortiGate assign VIP addresses to FortiClient dialup clients through a DHCP server or relay. This option is only available if the remote gateway in the phase 1 configuration is set to dialup user, and it only works in policy-based VPNs.

With dhcp-ipsec, 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. 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 then answers the ARP request on behalf of the FortiClient host, and then 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 when two addresses have the same MAC address.

ChaCha20 and Poly1305 AEAD cipher

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

config vpn ipsec phase2-interface
    edit <name>
        set phase1name <name>
        set proposal chacha20poly1305
    next
end

AES-GCM for IKEv2 phase 1

In IKEv2 to support RFC 5282, the AEAD algorithm AES-GCM supports 128- and 256-bit variants:

config vpn ipsec phase2-interface
    edit <name>
        set phase1name <name>
        set proposal [aes128gcm | aes256gcm]
    next
end

Phase 2 configuration

Phase 2 configuration

After phase 1 negotiations end successfully, phase 2 begins. In Phase 2, the VPN peer or client and the FortiGate exchange keys again to establish a secure communication channel. The phase 2 proposal parameters select the encryption and authentication algorithms needed to generate keys for protecting the implementation details of security associations (SAs). The keys are generated automatically using a Diffie-Hellman algorithm.

The basic phase 2 settings associate IPsec phase 2 parameters with the phase 1 configuration that specifies the remote end point of the VPN tunnel. In most cases, you need to configure only basic Phase 2 settings.

Some settings can be configured in the CLI. The following options are available in the VPN Creation Wizard after the tunnel is created:

New Phase 2

Name

Phase 2 definition name.

Local Address

A value of 0.0.0.0/0 means all IP addresses behind the local VPN peer. Add a specific address or range to allow traffic from and to only this local address.

See Quick mode selectors.

Remote Address

Enter the destination IP address that corresponds to the recipients or network behind the remote VPN peer. A value of 0.0.0.0/0 means all IP addresses behind the remote VPN peer.

See Quick mode selectors.

Advanced

Select the encryption and authentication algorithms that will be proposed to the remote VPN peer. To establish a VPN connection, at least one of the proposals specified must match the configuration on the remote peer.

Encryption

The following symmetric-key encryption algorithms are available:

  • 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: Advanced Encryption Standard, a 128-bit block algorithm that uses a 128-bit key.
  • AES128GCM: AES in Galois/Counter Mode, a 128-bit block algorithm that uses a 128-bit key. Only available for IKEv2.
  • AES192: a 128-bit block algorithm that uses a 192-bit key.
  • AES256: a 128-bit block algorithm that uses a 256-bit key.
  • AES256GCM: AES in Galois/Counter Mode, a 128-bit block algorithm that uses a 256-bit key. Only available for IKEv2.
  • CHACHA20POLY1305: a 128-bit block algorithm that uses a 128-bit key and a symmetric cipher. Only available for IKEv2.

See ChaCha20 and Poly1305 AEAD cipher, AES-GCM for IKEv2 phase 1, and HMAC settings.

Authentication

The following message digests that check the message authenticity during an encrypted session are available:

  • NULL: do not use a message digest.
  • MD5: message digest 5.
  • SHA1: secure hash algorithm 1; a 160-bit message digest.
  • SHA256: a 256-bit message digest.
  • SHA384: a 384-bit message digest.
  • SHA512: a 512-bit message digest.

See also HMAC settings.

Enable Replay Detection

Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel.

Replay detection allows the FortiGate to check all IPsec packets to see if they have been received before. If any encrypted packets arrive out of order, the FortiGate discards them.

Note that 64-bit extended sequence numbers (as described in RFC 4303, RFC 4304 as an addition to IKEv1, and RFC 5996 for IKEv2) are supported for IPsec when replay detection is enabled.

Enable Perfect Forward Secrecy (PFS)

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

Diffie-Hellman Group

Asymmetric key algorithms used for public key cryptography.

Select one or more from groups 1, 2, 5, and 14 through 32. At least one of the Diffie-Hellman Groups (DH) settings on the remote peer or client must match one the selections on the FortiGate. Failure to match one or more DH groups will result in failed negotiations.

Local Port

Enter the port number that the local VPN peer uses to transport traffic related to the specified service (protocol number). The range is from 0 to 65535. To specify all ports, select All, or enter 0.

Remote Port

Enter the port number that the remote VPN peer uses to transport traffic related to the specified service (protocol number). To specify all ports, select All, or enter 0.

Protocol

Enter the IP protocol number of the service. To specify all services, select All, or enter 0.

Auto-negotiate

Select this option for the tunnel to be automatically renegotiated when the it expires. See Auto-negotiate.

Autokey Keep Alive

Select this option for the tunnel to remain active when no data is being processed.

Key Lifetime

Select the method for determining when the phase 2 key expires:

  • Seconds
  • Kilobytes
  • Both

Enter a corresponding value for Seconds and/or Kilobytes in the text boxes.

If Both is selected, the key expires when either the time has passed or the number of kilobytes have been processed.

Quick mode selectors

Quick mode selectors determine which IP addresses can perform IKE negotiations to establish a tunnel. By only allowing authorized IP addresses access to the VPN tunnel, the network is more secure.

The default settings are as broad as possible: any IP address or configured address object using any protocol on any port.

Caution

While the dropdown menus for specifying an address also show address groups, the use of address groups may not be supported on a remote endpoint device that is not a FortiGate.

When configuring a quick mode selector for Local Address and Remote Address, valid options include IPv4 and IPv6 single addresses, subnets, or ranges.

There are some configurations that require specific selectors:

  • The VPN peer is a third-party device that uses specific phase2 selectors.
  • The FortiGate connects as a dialup client to another FortiGate, in which case (usually) you must specify a local IP address, IP address range, or subnet. However, this is not required if you are using dynamic routing and mode-cfg.

With FortiOS VPNs, your network has multiple layers of security, with quick mode selectors being an important line of defense:

  • Routes guide traffic from one IP address to another.
  • Phase 1 and phase 2 connection settings ensure there is a valid remote end point for the VPN tunnel that agrees on the encryption and parameters.
  • Quick mode selectors allow IKE negotiations only for allowed peers.
  • Security policies control which IP addresses can connect to the VPN.
  • Security policies also control what protocols are allowed over the VPN along with any bandwidth limiting.

If you are editing an existing phase 2 configuration, the local address and remote address fields are unavailable if the tunnel has been configured to use firewall addresses as selectors. This option exists only in the CLI.

Using the add-route option

Consider using the add-route option to add a route to a peer destination selector in phase 2 to automatically match the settings in phase 1.

To configure add-route:
config vpn ipsec {phase2 | phase2-interface}
    edit <name>
        set add-route {phase1 | enable | disable}
    next
end

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.

To configure auto-negotiate:
config vpn ipsec phase2
    edit <phase2_name>
        set auto-negotiate enable
    next
end

Installing dynamic selectors via auto-negotiate

The IPsec SA connect message generated is used to install dynamic selectors. These selectors can 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 dialup clients will all establish SAs without traffic being initiated from the client subnets to the hub.

DHCP

The dhcp-ipsec option lets the FortiGate assign VIP addresses to FortiClient dialup clients through a DHCP server or relay. This option is only available if the remote gateway in the phase 1 configuration is set to dialup user, and it only works in policy-based VPNs.

With dhcp-ipsec, 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. 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 then answers the ARP request on behalf of the FortiClient host, and then 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 when two addresses have the same MAC address.

ChaCha20 and Poly1305 AEAD cipher

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

config vpn ipsec phase2-interface
    edit <name>
        set phase1name <name>
        set proposal chacha20poly1305
    next
end

AES-GCM for IKEv2 phase 1

In IKEv2 to support RFC 5282, the AEAD algorithm AES-GCM supports 128- and 256-bit variants:

config vpn ipsec phase2-interface
    edit <name>
        set phase1name <name>
        set proposal [aes128gcm | aes256gcm]
    next
end