The IKE Phase 1 proposals for negotiating security parameters
The main object of IKE Phase 1 is to negotiate the encryption and authentication algorithms, and the correspondent keys between two FortiWAN units so that they can authenticate the identity to each other during the Phase 1 process, and protect the subsequent IKE Phase 2 negotiations.
IKE Phase 1 negotiations determine:
- Which encryption algorithms may be applied for converting messages into a form that only the intended recipient
can read
- Which authentication hash may be used for creating a keyed hash from a pre-shared or private key l Which Diffie-Hellman group (DH Group) will be used to generate a secret session key
The initiator of IKE Phase 1 proposes a list of potential cryptographic parameters that are supported (this is what the Proposal fields supposed to be configured on Web UI, algorithms and DH Group) to remote FortiWAN. The remote FortiWAN compares the received proposals with its own list of Phase 1 Proposal and responds with the choice of matching parameters to use for authenticating and encrypting packets. According the determined proposal, the two peers handle the subsequent exchanges to generate encryption keys between them, and authenticate the exchanges through a pre-shared key. The negotiated encryption algorithm, authentication algorithm and secret session key, which are the outcome of successful IKE Phase 1, will be used to protect the subsequent IKE Phase 2 negotiations.
To guarantee a successful IKE proposal negotiation, the configurations of proposals on both endpoints must be partially matched. However, FortiWAN’s IKE Phase 1 does not support multiple proposals, which means the IKE Phase 1 proposal must contain only one encryption algorithm, one authentication algorithm and one DH group. Therefore, you need to make sure that the IKE Phase 1 proposals on the two FortiWAN units are exactly the same, or Phase 1 negotiation goes to failure.
IKE Phase 1 Web UI fields
Go to Service > IPsec, select the Tunnel Mode or Transport Mode and click the add button to add a new configuration panel of Phase 1. The Phase 1 configuration defines the endpoints of the IPSec VPN tunnel, and the necessary parameters used to negotiate with the opposite unit to establish ISAKMP Security Association.
| Add / Delete / Move-Up / Move-Down | l | The buttons for:
Adding a new configuration panel below current Phase 1 configuration |
| l | Deleting the current Phase 1 configuration (all the Phase 2 configurations belong to the Phase 1 configuration will be deleted as well) | |
| l | Moving the current Phase 1 configuration up a row | |
| l | Moving the current Phase 1 configuration down a row
Packets that matching a Phase 2’s Quick Mode selector or Phase 1’s [Local IP, Remote IP] are allowed to pass through the correspondent IPSec VPN. However, both the two filters are required to be incompatible with the others, Phase 1 configurations moving-up or moving-down is nothing about rule first-match. |
| Name A “unique” description name for the Phase 1 definition. The name is not a parameter exchanged with the opposite unit during Phase 1 negotiations. This name can contain a piece of information used for simple management, such as it can reflect where the correspondent remote unit is or what the purpose it is. It is also the index used in IPSec Statistics (See “Statistics > IPSec”). |
| Hide Details / Show Details Click to expand or collapse the configuration details. |
| Local IP Type the IP address of local FortiWAN’s WAN port used to
establish the IPSec VPN tunnel with remote FortiWAN unit. Packets of IKE negotiations (Both Phase 1 and Phase 2) and IPSec VPN communications are transferred through the WAN port on the local side. Note that only static IP address is supported, please make sure the WAN link type is Routing Mode, Bridge Mode: One Static IP or Bridge Mode: Multiple Static IP. The local IP address must equal to the Remote IP on the opposite unit that the local unit establish the IPSec VPN with. |
| Remote IP Type the IP address of remote FortiWAN’s WAN port used to
establish the IPSec VPN tunnel with the local FortiWAN unit. Packets of IKE negotiations (Both Phase 1 and Phase 2) and IPSec VPN communications are transferred through the WAN port on the remote side. Note that only static IP address is supported, please make sure the WAN link type is Routing Mode, Bridge Mode: One Static IP or Bridge Mode: Multiple Static IP. The remote IP address must equal to the Local IP on the opposite unit that the local unit establish the IPSec VPN with. |
| Please make sure the entered IP address is equal to the IP address of the WAN port that you would like to employ to establish the IPSec VPN, system will not run error checking on this. Incorrect IP address causes the negotiations to go to failure.
A duplicate of Remote IP (or pair of Local IP and Remote IP) of a Phase 1 configuration is not acceptable to other Phase 1 configurations. Please make sure each Phase 1 configuration is incompatible with others on the Remote IP. See “Limitation in the IPSec deployment” for details. In Transport mode, the Local IP and Remote IP of a Phase 1 configuration must be equal to the Local IP and Remote IP of a TR tunnel that IPSec provides protection to, so that TR packets match the ISAKMP SA and are protected by ESP encapsulation. See “Tunnel Routing”. Additional routing policies are necessary for system to route the packets of IKE negotiations and IPSec VPN communications to the IP address (WAN port) you defined here (See “Define routing policies for an IPSec VPN”). |
l
l
l
l
| Authentication Method | Only Pre-Shared Key is supported. Enter the pre-shared key in the field “Input key” next to the drop-down menu. The pre-shared key is used to authenticate the identity to each other, the local and remote FortiWAN units, during IKE Phase 1 negotiations. Make sure both the local and remote units are defined an equal key. For stronger protection against currently known attacks, a key consisting of a minimum of 16 randomly chosen alphanumeric characters is suggested. | |
| Internet Key Exchange | Select either IKE v1 or IKE v2.
Note 1: It requires the two endpoints of an IPSec VPN connectivity running the same IKE protocol. Unequal IKE version fails the establishment of ISAKMP SA for an IPSec VPN connectivity. Note 2: To change the IKE version for an existing IPSec VPN connectivity, we strongly recommend to following steps: |
|
| 1. | Stop the traffic passing through the connectivity. | |
| 2. | Click the Delete button to remove the whole IKE configuration and click the Apply button. | |
| 3. | Click the Add button to create a new IKE configuration with the specified IKE version, and click the Apply button. | |
| 4. | Make sure the same change is done to both the two endpoint.
System might fail to reestablish the connectivity if you change the IKE version by simply editing the configuration field. |
|
| Mode | Main mode: the Phase 1 parameters are exchanged in six messages with securer authentication by a encryption with the negotiated secret key. | |
| Dead Peer Detection | Check to enable the monitoring of current existence and availability of the remote unit. PDP sends a detection message periodically to remote unit every specified time interval. The IPSec tunnel will be considered down if local unit sends the detection message without a response from the remote unit for five consecutive times. When a disconnection is recognized, the active ISAKMP SA (and the correspondent IPSec SAs) are removed immediately whether the secret keys expire or not (a renegotiation would not be performed automatically).
Delay: Set the time interval that PDP sends periodically the detection message. |
| Proposal | An IKE Phase 1 proposal is a combination of one encryption algorithm, one authentication algorithm, one strength of DH key exchange, and the key lifetime. Select the encryption and authentication algorithms, strength of DH key exchange, and enter the key lifetime for the IKE Phase 1 proposal that will be used in the IKE Phase 1 negotiations. The remote unit must be configured to use the same proposal that you define here. Make sure the Phase 1 proposals of the both units are exactly the same. Unmatched proposals result in failure of negotiations. |
| Encryption | Select one of the following symmetric-key encryption algorithms: | |
| l | DES: Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key. | |
| l | 3DES: Triple-DES; plain text is encrypted three times by three keys. | |
| l | AES128: A 128-bit block algorithm that uses a 128-bit key. | |
| l | AES192: A 128-bit block algorithm that uses a 192-bit key. | |
| l | AES256: A 128-bit block algorithm that uses a 256-bit key.
Note that AES128, AES192 and AES256 will be suggested for better performance. |
|
| Authentication | Select one of the following authentication algorithms: | |
| l | MD5: A MD5-based MAC algorithm (hmac-md5) with 128-bit message digest. | |
| l | SHA1: A SHA1-based MAC algorithm (hmac-sha1) with 160-bit message digest. | |
| l | SHA256: A SHA256-based MAC algorithm (hmac-sha256) with 256bit message digest. | |
| l | SHA384: A SHA384-based MAC algorithm (hmac-sha384) with 384bit message digest. | |
| l | SHA512: A SHA512-based MAC algorithm (hmac-sha512) with 512bit message digest. | |
| DH Group | Select one Diffie-Hellman group from the DH groups 1, 2, 5, and 14. Diffie-Hellman (DH) groups determine the strength of the private key material used in the Diffie-Hellman key exchange process. A higher group number implies a securer key against private key recover attacks, but additional processing time to calculate the key is required. | |
| l | DH Group 1: 768-bit group | |
| l | DH Group 2: 1024-bit group | |
| l | DH Group 5: 1536-bit group | |
| l | DH Group 14: 2048-bit group | |
| Keylife | Enter the time interval (in seconds) that the negotiated secret key
(used for ISAKMP SA) is valid during. For the expiration of a key, IKE Phase 1 is performed automatically to negotiate a new key without interrupting normal IPSec VPN communications. |
Configurations of IKE Phase 2
After IKE Phase 1 negotiations complete successfully, Phase 2 negotiation begins. Configurations of Phase 2 defines the parameters that are required to establish the IPSec Security Association. The basic parameters of IKE Phase 2 settings are associated with a Phase 1 configuration for an establishment of IPSec VPN (IPSec SA). This section we describe the configurations of IKE Phase 2.
Here are the items and information that you need to determine for IKE Phase 2 settings: