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. Post-Quantum cryptographic algorithms can also be used in additional Key Exchange just like in phase 1.
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 can be configured when you create a custom VPN tunnel by clicking Create New in the Phase 2 selectors table.
|
Command |
Description |
||
|---|---|---|---|
|
Name |
Phase 2 definition name. |
||
| Encapsulation |
Define whether you encapsulate the entire IP packet or leave the original IP headers intact.
For NAT traversal and IKEv2 over TCP, the ESP packet is further encapsulated in UDP or TCP. |
||
| IP version |
Tunnel Mode only. Choose the IP version for the packet |
||
| Named address |
Tunnel Mode only. Instead of defining the local and remote selector address directly in Phase 2 settings, select address objects instead. |
||
|
Local Address |
Tunnel Mode only. A value of See Quick mode selectors. |
||
|
Remote Address |
Tunnel Mode only. Enter the destination IP address that corresponds to the recipients or network behind the remote VPN peer. A value of 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:
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:
See also HMAC settings. |
|
|
|
L2TP |
Enable or disable L2TP over IPsec. Typically used by native VPN clients such as Windows VPN client. See Native VPN as dialup client - Windows New. |
|
|
|
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. |
|
|
|
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. Fortinet recommends choosing DH groups in the range 15-21 and 28-32 for security best practices. |
|
|
|
Post Quantum Cryptography Additional Key Exchanges |
Enable quantum-resistant encryption by applying hybrid key exchange per RFC 9370 and RFC 9242. When creating a new PQC Additional KE group:
For more information, see Post-Quantum Cryptography for IPsec key exchange. |
|
|
|
Local Port |
Tunnel Mode only. 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 |
|
|
|
Remote Port |
Tunnel Mode only. 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 |
|
|
|
Protocol |
Tunnel Mode only. Enter the IP protocol number of the service. To specify all services, select All, or enter |
|
|
|
Auto-negotiate |
Select this option for the tunnel to be automatically renegotiated when the it expires. See Auto-negotiate. This option is only available when the Remote Gateway mode in phase 1 is not a dialup user. |
|
|
|
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:
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.
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 IP addresses to FortiClient dialup clients through a DHCP server or relay in IKEv1. This option is only available if the remote gateway in the phase 1 configuration is set to dialup user and mode-cfg is disabled.
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.
Bypassing the FortiGate and using DHCP is not recommended. Using mode-cfg or IPAM is preferred.
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