Phase 2 parameters
This section describes the Phase 2 parameters that are required to establish communication through a VPN.
The following topics are included in this section:
Phase 2 settings
Configuring the Phase 2 parameters
Phase 2 settings
After IPsec VPN Phase 1 negotiations complete successfully, Phase 2 negotiation begins. Phase 2 parameters define the algorithms that the FortiGate unit can use to encrypt and transfer data for the remainder of the session. The basic Phase 2 settings associate IPsec Phase 2 parameters with a Phase 1 configuration.
When defining Phase 2 parameters, you can choose any set of Phase 1 parameters to set up a secure connection and authenticate the remote peer.
For more information on Phase 2 settings in the web-based manager, see IPsec VPN in the web-based manager on page 32.
The information and procedures in this section do not apply to VPN peers that perform negotiations using manual keys.
Phase 2 proposals
In Phase 2, the VPN peer or client and the FortiGate unit 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.
Replay detection
IPsec tunnels can be vulnerable to replay attacks. Replay Detection enables the FortiGate unit to check all IPsec packets to see if they have been received before. If any encrypted packets arrive out of order, the FortiGate unit discards them.
IKE/IPsec Extended Sequence Number (ESN) support
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)
By default, Phase 2 keys are derived from the session key created in Phase 1. Perfect Forward Secrecy (PFS) forces a new Diffie-Hellman exchange when the tunnel starts and whenever the Phase 2 keylife expires, causing a new key to be generated each time. This exchange ensures that the keys created in Phase 2 are unrelated to the Phase 1 keys or any other keys generated automatically in Phase 2.
Phase 2 settings
Keylife
The Keylife setting sets a limit on the length of time that a Phase 2 key can be used. The default units are seconds. Alternatively, you can set a limit on the number of kilobytes (KB) of processed data, or both. If you select both, the key expires when either the time has passed or the number of KB have been processed. When the Phase 2 key expires, a new key is generated without interrupting service.
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 drop down 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.
The address groups are at the bottom of the list to make it easy to distinguish between addresses and address groups.
When configuring Quick Mode selector Source address and Destination address, valid options include IPv4 and IPv6 single addresses, IPv4 subnet, or IPv6 subnet. For more information on IPv6 IPsec VPN, see Overview of IPv6 IPsec support on page 1.
There are some configurations that require specific selectors:
- The VPN peer is a third-party device that uses specific phase2 selectors.
- The FortiGate unit connects as a dialup client to another FortiGate unit, in which case (usually) you must specify a source 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 defence.
- 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. l Security policies control which IP addresses can connect to the VPN. l Security policies also control what protocols are allowed over the VPN along with any bandwidth limiting.
FortiOS is limited with IKEv2 selector matching. When using IKEv2 with a named traffic selector, no more than 32 subnets per traffic selector are added, since FortiOS doesn’t fully implement the IKEv2 selector matching rules.
The workaround is to use multiple Phase 2s. If the configuration is FGT <-> FGT, then the better alternative is to just use 0.0.0.0 <-> 0.0.0.0 and use the firewall policy for enforcement.
Using the add-route option
Consider using the add-route option to add a route to a peer destination selector. Phase 2 includes the option of allowing the add-route to automatically match the settings in Phase 1. For more information, refer to Phase 1 parameters on page 46.
Syntax
Phase 2
config vpn ipsec {phase2 | phase2-interface} edit <name> set add-route {phase1 | enable | disable}
end
end
Configuring the 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
- Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
- Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
- Enter a Name for the Phase 2 configuration, and select a Phase 1 configuration from the drop-down list.
- Select Advanced.
- 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, please refer to the Hardware Acceleration handbook chapter. |
| 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. Autonegotiate 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 meshselector-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