FortiGate IPSec Phase 1 parameters

Phase 1 parameters

This chapter provides detailed step-by-step procedures for configuring a FortiGate unit to accept a connection from a remote peer or dialup client. The Phase 1 parameters identify the remote peer or clients and supports authentication through preshared keys or digital certificates. You can increase access security further using peer identifiers, certificate distinguished names, group names, or the FortiGate extended authentication (XAuth) option for authentication purposes.

For more information on Phase 1 parameters in the web-based manager, see IPsec VPN in the web-based manager on page 1611.

The information and procedures in this section do not apply to VPN peers that perform negotiations using manual keys.

The following topics are included in this section: Overview

Defining the tunnel ends

Choosing Main mode or Aggressive mode

Choosing the IKE version Authenticating the FortiGate unit Authenticating remote peers and clients Defining IKE negotiation parameters Using XAuth authentication

Dynamic IPsec route control

Overview

To configure IPsec Phase 1 settings, go to VPN > IPsec Tunnels and edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

IPsec Phase 1 settings define:

The remote and local ends of the IPsec tunnel
If Phase 1 parameters are exchanged in multiple rounds with encrypted authentication information (main mode) or in a single message with authentication information that is not encrypted (aggressive mode)
If a preshared key or digital certificates will be used to authenticate the FortiGate unit to the VPN peer or dialup client
If the VPN peer or dialup client is required to authenticate to the FortiGate unit. A remote peer or dialup client can authenticate by peer ID or, if the FortiGate unit authenticates by certificate, it can authenticate by peer certificate.
The IKE negotiation proposals for encryption and authentication
Optional XAuth authentication, which requires the remote user to enter a user name and password. A FortiGate VPN server can act as an XAuth server to authenticate dialup users. A FortiGate unit that is a dialup client can also be configured as an XAuth client to authenticate itself to the VPN server.

For all the Phase 1 web-based manager fields, see IPsec VPN in the web-based manager on page 1611.

If you want to control how IKE is negotiated when there is no traffic, as well as the length of time the unit waits for negotiations to occur, use the negotiation-timeout and auto-negotiate commands in the CLI.

Defining the tunnel ends

To begin defining the Phase 1 configuration, go to VPN > IPsec Tunnels and select Create New. Enter a unique descriptive name for the VPN tunnel and follow the instructions in the VPN Creation Wizard.

The Phase 1 configuration mainly defines the ends of the IPsec tunnel. The remote end is the remote gateway with which the FortiGate unit exchanges IPsec packets. The local end is the FortiGate interface that sends and receives IPsec packets.

The remote gateway can be:

A static IP address
A domain name with a dynamic IP address
A dialup client

A statically addressed remote gateway is the simplest to configure. You specify the IP address. Unless restricted in the security policy, either the remote peer or a peer on the network behind the FortiGate unit can bring up the tunnel.

If the remote peer has a domain name and subscribes to a dynamic DNS service, you need to specify only the domain name. The FortiGate unit performs a DNS query to determine the appropriate IP address. Unless restricted in the security policy, either the remote peer or a peer on the network behind the FortiGate unit can bring up the tunnel.

If the remote peer is a dialup client, only the dialup client can bring up the tunnel. The IP address of the client is not known until it connects to the FortiGate unit. This configuration is a typical way to provide a VPN for client PCs running VPN client software such as the FortiClient Endpoint Security application.

The local end of the VPN tunnel, the Local Interface, is the FortiGate interface that sends and receives the IPsec packets. This is usually the public interface of the FortiGate unit that is connected to the Internet (typically the WAN1 port). Packets from this interface pass to the private network through a security policy.

By default, the local VPN gateway is the IP address of the selected Local Interface. If you are configuring an interface mode VPN, you can optionally use a secondary IP address of the Local Interface as the local gateway.

Choosing Main mode or Aggressive mode

The FortiGate unit and the remote peer or dialup client exchange Phase 1 parameters in either Main mode or Aggressive mode. This choice does not apply if you use IKE version 2, which is available only for route-based configurations.

In Main mode, the Phase 1 parameters are exchanged in multiple rounds with encrypted authentication information
In Aggressive mode, the Phase 1 parameters are exchanged in a single message with unencrypted authentication information.

Although Main mode is more secure, you must select Aggressive mode if there is more than one dialup Phase 1 configuration for the interface IP address, and the remote VPN peer or client is authenticated using an identifier local ID. Aggressive mode might not be as secure as Main mode, but the advantage to Aggressive mode is that it is faster than Main mode (since fewer packets are exchanged). Aggressive mode is typically used for remote access VPNs. But you would also use aggressive mode if one or both peers have dynamic external IP addresses. Descriptions of the peer options in this guide indicate whether Main or Aggressive mode is required.

Choosing the IKE version

If you create a route-based VPN, you have the option of selecting IKE version 2. Otherwise, IKE version 1 is used. IKEv2, defined in RFC 4306, simplifies the negotiation process that creates the security association (SA).

If you select IKEv2:

There is no choice in Phase 1 of Aggressive or Main mode.
FortiOS does not support Peer Options or Local ID.
Extended Authentication (XAUTH) is not available.
You can select only one Diffie-Hellman Group.
You can utilize EAP and MOBIKE.

IKEv2 cookie notification for IKE_SA_INIT

IKEv2 offers an optional exchange within IKE_SA_INIT (the initial exchange between peers when establishing a secure tunnel) as a reuslt of an inherent vulnerability in IPsec implementations, as described in RFC 5996.

Two expected attacks against IKE are state and CPU exhaustion, where the target is flooded with session initiation requests from forged IP addresses. These attacks can be made less effective if a responder uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which it claims to be sending them.

If the IKE_SA_INIT response includes the cookie notification, the initiator MUST then retry the IKE_SA_INIT request, and include the cookie notification containing the received data as the first payload, and all other payloads unchanged.

Upon detecting that the number of half-open IKEv2 SAs is above the threshold value, the VPN dialup server requires all future SA_INIT requests to include a valid cookie notification payload that the server sends back, in order to preserve CPU and memory resources.

For most devices, the threshold value is set to 500, half of the maximum 1,000 connections. This feature is enabled by default in FortiOS 5.4.

IKEv2 Quick Crash Detection

There is support for IKEv2 Quick Crash Detection as described in RFC 6290.

RFC 6290 describes a method in which an IKE peer can quickly detect that the gateway peer that it has and established an IKE session with has rebooted, crashed, or otherwise lost IKE state. When the gateway receives IKE messages or ESP packets with unknown IKE or IPsec SPIs, the IKEv2 protocol allows the gateway to send the peer an unprotected IKE message containing INVALID_IKE_SPI or INVALID_SPI notification payloads.

RFC 6290 introduces the concept of a QCD token, which is generated from the IKE SPIs and a private QCD secret, and exchanged between peers during the protected IKE AUTH exchange.

To add Quick Crash Detection – CLI Syntax

config system settings

set ike-quick-crash-detect [enable | disable]

end

Authenticating the FortiGate unit

The FortiGate unit can authenticate itself to remote peers or dialup clients using either a pre-shared key or an RSA Signature (certificate).

Authenticating the FortiGate unit with digital certificates

To authenticate the FortiGate unit using digital certificates, you must have the required certificates installed on the remote peer and on the FortiGate unit. The signed server certificate on one peer is validated by the presence of the root certificate installed on the other peer. If you use certificates to authenticate the FortiGate unit, you can also require the remote peers or dialup clients to authenticate using certificates.

For more information about obtaining and installing certificates, see the FortiOS User Authentication guide.

To authenticate the FortiGate unit using digital certificates

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button):

Name Enter a name that reflects the origination of the remote connection. For interface mode, the name can be up to 15 characters long.

Remote Gateway Select the nature of the remote connection.

Each option changes the available fields you must configure. For more information, see Authenticating the FortiGate unit on page 1627.

Local Interface Select the interface that is the local end of the IPsec tunnel. For more information, see Authenticating the FortiGate unit on page 1627. The local interface is typically the WAN1 port.

Mode Select a mode. It is easier to use Aggressive mode.

In Main mode, parameters are exchanged in multiple encrypted rounds. In Aggressive mode, parameters are exchanged in a single unencrypted message.

Aggressive mode must be used when the remote VPN peer or client has a dynamic IP address, or the remote VPN peer or client will be authenticated using an identifier (local ID).

For more information, see Authenticating the FortiGate unit on page 1627.

Authentication Method Select Signature.

Certificate Name Select the name of the server certificate that the FortiGate unit will use to authenticate itself to the remote peer or dialup client during Phase 1 nego- tiations.

You must obtain and load the required server certificate before this selec- tion. See the FortiOS User Authentication guide. If you have not loaded any certificates, use the certificate named Fortinet_Factory.

Peer Options Peer options define the authentication requirements for remote peers or dialup clients. They are not for your FortiGate unit itself.

See Authenticating the FortiGate unit on page 1627.

Advanced You can use the default settings for most Phase 1 configurations. Changes are required only if your network requires them. These settings includes IKE version, DNS server, P1 proposal encryption and authentication set- tings, and XAuth settings. See Authenticating the FortiGate unit on page 1627.

3. If you are configuring authentication parameters for a dialup user group, optionally define extended authentication

(XAuth) parameters in the Advanced section. See Authenticating the FortiGate unit on page 1627.

4. Select OK.

Authenticating the FortiGate unit with a pre-shared key

The simplest way to authenticate a FortiGate unit to its remote peers or dialup clients is by means of a pre-shared key. This is less secure than using certificates, especially if it is used alone, without requiring peer IDs or extended authentication (XAuth). Also, you need to have a secure way to distribute the pre-shared key to the peers.

If you use pre-shared key authentication alone, all remote peers and dialup clients must be configured with the same pre-shared key. Optionally, you can configure remote peers and dialup clients with unique pre-shared keys. On the FortiGate unit, these are configured in user accounts, not in the phase_1 settings. For more information, see Authenticating the FortiGate unit on page 1627.

The pre-shared key must contain at least 6 printable characters and best practices dictate that it be known only to network administrators. For optimum protection against currently known attacks, the key must consist of a minimum of 16 randomly chosen alphanumeric characters.

If you authenticate the FortiGate unit using a pre-shared key, you can require remote peers or dialup clients to authenticate using peer IDs, but not client certificates.

To authenticate the FortiGate unit with a pre-shared key

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button):

Name Enter a name that reflects the origination of the remote connection.

Remote Gateway Select the nature of the remote connection. For more information, see Authenticating the FortiGate unit on page 1627.

Mode Select Main or Aggressive mode.

In Main mode, the Phase 1 parameters are exchanged in multiple rounds with encrypted authentication information.

In Aggressive mode, the Phase 1 parameters are exchanged in single message with authentication information that is not encrypted.

When the remote VPN peer or client has a dynamic IP address, or the remote VPN peer or client will be authenticated using an identifier (local ID), you must select Aggressive mode if there is more than one dialup Phase 1 configuration for the interface IP address.

For more information, see Authenticating the FortiGate unit on page 1627.

Authentication Method Select Pre–shared Key.

Pre–shared Key Enter the preshared key that the FortiGate unit will use to authenticate itself to the remote peer or dialup client during Phase 1 negotiations. You must define the same value at the remote peer or client. The key must con- tain at least 6 printable characters and best practices dictate that it only be known by network administrators. For optimum protection against currently known attacks, the key must consist of a minimum of 16 randomly chosen alphanumeric characters.

Peer options Peer options define the authentication requirements for remote peers or dialup clients, not for the FortiGate unit itself. You can require the use of peer IDs, but not client certificates. For more information, see Authentic- ating the FortiGate unit on page 1627.

Advanced You can retain the default settings unless changes are needed to meet your specific requirements. See Authenticating the FortiGate unit on page 1627.

3. If you are configuring authentication parameters for a dialup user group, optionally define extended authentication

(XAuth) parameters. See Authenticating the FortiGate unit on page 1627.

4. Select OK.

Authenticating remote peers and clients

Certificates or pre-shared keys restrict who can access the VPN tunnel, but they do not identify or authenticate the remote peers or dialup clients. You have the following options for authentication:

Methods of authenticating remote VPN peers

Certificates or Pre-shared key Local ID User account pre- shared keys

Reference

Certificates See Enabling VPN access for specific certificate holders on page 1630.

Either X See Enabling VPN access by peer identifier on page 1632.

Pre–shared key X See Enabling VPN access with user accounts and pre-shared keys on page 1633.

Pre–shared key X X

See Enabling VPN access with user accounts and pre-shared keys on page 1633.

Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

This feature provides the option to control whether a device requires its peer to re-authenticate or whether re-key is sufficient. It does not influence the re-authentication or re-key behavior of the device itself, which is controlled by the peer (with the default being to re-key).

This solution is in response to RFC 4478. This solution is intended to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer.

CLI Syntax:

config vpn ipsec phase1-interface edit p1

set reauth [enable | disable]

next end

disable: Disable IKE SA re-authentication.

enable: Enable IKE SA re-authentication.

Enabling VPN access for specific certificate holders

When a VPN peer or dialup client is configured to authenticate using digital certificates, it sends the Distinguished Name (DN) of its certificate to the FortiGate unit. This DN can be used to allow VPN access for the certificate holder. That is, a FortiGate unit can be configured to deny connections to all remote peers and dialup clients except the one having the specified DN.

Before you begin

The following procedures assume that you already have an existing Phase 1 configuration (see Authenticating remote peers and clients on page 1629). Follow the procedures below to add certificate-based authentication parameters to the existing configuration.

Before you begin, you must obtain the certificate DN of the remote peer or dialup client. If you are using the FortiClient application as a dialup client, refer to FortiClient online help for information about how to view the certificate DN. To view the certificate DN of a FortiGate unit, see To view server certificate information and obtain the local DN on page 1631.

Use the config user peer CLI command to load the DN value into the FortiGate configuration. For example, if a remote VPN peer uses server certificates issued by your own organization, you would enter information similar to the following:

config user peer edit DN_FG1000

set cn 192.168.2.160 set cn-type ipv4

end

The value that you specify to identify the entry (for example, DN_FG1000) is displayed in the Accept this peer certificate only list in the IPsec Phase 1 configuration when you return to the web-based manager.

If the remote VPN peer has a CA-issued certificate to support a higher level of credibility, you would enter information similar to the following in the CLI:

config user peer edit CA_FG1000

set ca CA_Cert_1

set subject FG1000_at_site1

end

The value that you specify to identify the entry (for example, CA_FG1000) is displayed in the Accept this peer certificate only list in the IPsec Phase 1 configuration when you return to the web-based manager. For more information about these CLI commands, see the “user” chapter of the FortiGate CLI Reference.

A group of certificate holders can be created based on existing user accounts for dialup clients. To create the user accounts for dialup clients, see the “User” chapter of the FortiGate Administration Guide. To create the certificate group afterward, use the config user peergrp CLI command. See the “user” chapter of the FortiGate CLI Reference.

To view server certificate information and obtain the local DN

1. Go to System > Certificates.

2. Note the CN value in the Subject field (for example, CN = 16.10.125, CN = info@fortinet.com, or CN = www.example.com).

To view CA root certificate information and obtain the CA certificate name

1. Go to System > Certificates > CA Certificates.

2. Note the value in the Name column (for example, CA_Cert_1).

Configuring certificate authentication for a VPN

With peer certificates loaded, peer users and peer groups defined, you can configure your VPN to authenticate users by certificate.

To enable access for a specific certificate holder or a group of certificate holders

1. At the FortiGate VPN server, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

3. From the Authentication Method list, select RSA Signature.

4. From the Certificate Name list, select the name of the server certificate that the FortiGate unit will use to authenticate itself to the remote peer or dialup client

5. Under Peer Options, select one of these options:

To accept a specific certificate holder, select Accept this peer certificate only and select the name of the certificate that belongs to the remote peer or dialup client. The certificate DN must be added to the FortiGate configuration through CLI commands before it can be selected here. See Before you begin on page 1630.
To accept dialup clients who are members of a certificate group, select Accept this peer certificate group only and select the name of the group. The group must be added to the FortiGate configuration through CLI commands before it can be selected here. See Before you begin on page 1630.

6. If you want the FortiGate VPN server to supply the DN of a local server certificate for authentication purposes, select Advanced and then from the Local ID list, select the DN of the certificate that the FortiGate VPN server is to use.

7. Select OK.

Enabling VPN access by peer identifier

Whether you use certificates or pre-shared keys to authenticate the FortiGate unit, you can require that remote peers or clients have a particular peer ID. This adds another piece of information that is required to gain access to the VPN. More than one FortiGate/FortiClient dialup client may connect through the same VPN tunnel when the dialup clients share a preshared key and assume the same identifier.

A peer ID, also called local ID, can be up to 63 characters long containing standard regular expression characters. Local ID is set in phase1 Aggressive Mode configuration.

You cannot require a peer ID for a remote peer or client that uses a pre-shared key and has a static IP address.

To authenticate remote peers or dialup clients using one peer ID

1. At the FortiGate VPN server, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

3. Select Aggressive mode in any of the following cases:

The FortiGate VPN server authenticates a FortiGate dialup client that uses a dedicated tunnel
A FortiGate unit has a dynamic IP address and subscribes to a dynamic DNS service
FortiGate/FortiClient dialup clients sharing the same preshared key and local ID connect through the same VPN tunnel

4. For the Peer Options, select This peer ID and type the identifier into the corresponding field.

5. Select OK.

To assign an identifier (local ID) to a FortiGate unit

Use this procedure to assign a peer ID to a FortiGate unit that acts as a remote peer or dialup client.

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

3. Select Advanced.

4. In the Local ID field, type the identifier that the FortiGate unit will use to identify itself.

5. Set Mode to Aggressive if any of the following conditions apply:

The FortiGate unit is a dialup client that will use a unique ID to connect to a FortiGate dialup server through a dedicated tunnel.
The FortiGate unit has a dynamic IP address, subscribes to a dynamic DNS service, and will use a unique ID to connect to the remote VPN peer through a dedicated tunnel.
The FortiGate unit is a dialup client that shares the specified ID with multiple dialup clients to connect to a FortiGate dialup server through the same tunnel.

6. Select OK.

To configure the FortiClient application

Follow this procedure to add a peer ID to an existing FortiClient configuration:

1. Start the FortiClient application.

2. Go to VPN > Connections, select the existing configuration.

3. Select Advanced > Edit > Advanced.

4. Under Policy, select Config.

5. In the Local ID field, type the identifier that will be shared by all dialup clients. This value must match the This peer ID value that you specified previously in the Phase 1 gateway configuration on the FortiGate unit.

6. Select OK to close all dialog boxes.

7. Configure all dialup clients the same way using the same preshared key and local ID.

Enabling VPN access with user accounts and pre-shared keys

You can permit access only to remote peers or dialup clients that have pre-shared keys and/or peer IDs configured in user accounts on the FortiGate unit.

If you want two VPN peers (or a FortiGate unit and a dialup client) to accept reciprocal connections based on peer IDs, you must enable the exchange of their identifiers when you define the Phase 1 parameters.

Before you begin, you must obtain the identifier (local ID) of the remote peer or dialup client. If you are using the FortiClient Endpoint Security application as a dialup client, refer to the Authenticating FortiClient Dialup Clients Technical Note to view or assign an identifier. To assign an identifier to a FortiGate dialup client or a FortiGate unit that has a dynamic IP address and subscribes to a dynamic DNS service, see To assign an identifier (local ID) to a FortiGate unit on page 1632.

If required, a dialup user group can be created from existing user accounts for dialup clients. To create the user accounts and user groups, see the User Authentication handbook chapter.

The following procedure supports FortiGate/FortiClient dialup clients that use unique preshared keys and/or peer IDs. The client must have an account on the FortiGate unit and be a member of the dialup user group.

The dialup user group must be added to the FortiGate configuration before it can be selected. For more information, see the User Authentication handbook chapter.

The FortiGate dialup server compares the local ID that you specify at each dialup client to the FortiGate user- account user name. The dialup-client preshared key is compared to a FortiGate user-account password.

To authenticate dialup clients using unique preshared keys and/or peer IDs

1. At the FortiGate VPN server, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

3. If the clients have unique peer IDs, set Mode to Aggressive.

4. Clear the Pre–shared Key field.

The user account password will be used as the preshared key.

5. Select Peer ID from dialup group and then select the group name from the list of user groups.

6. Select OK.

Follow this procedure to add a unique pre-shared key and unique peer ID to an existing FortiClient configuration.

To configure FortiClient – pre-shared key and peer ID

1. Start the FortiClient Endpoint Security application.

2. Go to VPN > Connections, select the existing configuration.

3. Select Advanced > Edit.

4. In the Preshared Key field, type the FortiGate password that belongs to the dialup client (for example, 1234546).

The user account password will be used as the preshared key.

5. Select Advanced.

6. Under Policy, select Config.

7. In the Local ID field, type the FortiGate user name that you assigned previously to the dialup client (for example, FortiClient).

8. Select OK to close all dialog boxes.

Configure all FortiClient dialup clients this way using unique preshared keys and local IDs. Follow this procedure to add a unique pre-shared key to an existing FortiClient configuration.

To configure FortiClient – preshared key only

1. Start the FortiClient Endpoint Security application.

2. Go to VPN > Connections, select the existing configuration

3. Select Advanced > Edit.

4. In the Preshared Key field, type the user name, followed by a “+” sign, followed by the password that you specified previously in the user account settings on the FortiGate unit (for example, FC2+1FG6LK)

5. Select OK to close all dialog boxes.

Configure all the FortiClient dialup clients this way using their unique peer ID and pre-shared key values.

Defining IKE negotiation parameters

In Phase 1, the two peers exchange keys to establish a secure communication channel between them. As part of the Phase 1 process, the two peers authenticate each other and negotiate a way to encrypt further communications for the duration of the session. For more information see Defining IKE negotiation parameters on page 1635. The Phase 1 Proposal parameters select the encryption and authentication algorithms that are used to generate keys for protecting negotiations.

The IKE negotiation parameters 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 preshared or private key
Which Diffie-Hellman group (DH Group) will be used to generate a secret session key

Phase 1 negotiations (in main mode or aggressive mode) begin as soon as a remote VPN peer or client attempts to establish a connection with the FortiGate unit. Initially, the remote peer or dialup client sends the FortiGate unit a list of potential cryptographic parameters along with a session ID. The FortiGate unit compares those parameters to its own list of advanced Phase 1 parameters and responds with its choice of matching parameters to use for authenticating and encrypting packets. The two peers handle the exchange of encryption keys between them, and authenticate the exchange through a preshared key or a digital signature.

Generating keys to authenticate an exchange

The FortiGate unit supports the generation of secret session keys automatically using a Diffie-Hellman algorithm. These algorithms are defined in RFC 2409. The Keylife setting in the Phase 1 Proposal area determines the amount of time before the Phase 1 key expires. Phase 1 negotiations are re-keyed automatically when there is an active security association. See Dead peer detection on page 1638.

You can enable or disable automatic re-keying between IKE peers through the phase1-rekey attribute of the config system global CLI command. For more information, see the “System” chapter of the FortiGate CLI Reference.

When in FIPS-CC mode, the FortiGate unit requires DH key exchange to use values at least 3072 bits long. However most browsers need the key size set to 1024. You can set the minimum size of the DH keys in the CLI.

config system global set dh-params 3072

end

When you use a preshared key (shared secret) to set up two-party authentication, the remote VPN peer or client and the FortiGate unit must both be configured with the same preshared key. Each party uses a session key derived from the Diffie-Hellman exchange to create an authentication key, which is used to sign a known combination of inputs using an authentication algorithm (such as HMAC-MD5, HMAC-SHA-1, or HMAC-SHA-256). Hash-based Message Authentication Code (HMAC) is a method for calculating an authentication code using a hash function plus a secret key, and is defined in RFC 2104. Each party signs a different combination of inputs and the other party verifies that the same result can be computed.

For information regarding NP accelerated offloading of IPsec VPN authentication algorithms, please refer to the Hardware Acceleration handbook chapter.

When you use preshared keys to authenticate VPN peers or clients, you must distribute matching information to all VPN peers and/or clients whenever the preshared key changes.

As an alternative, the remote peer or dialup client and FortiGate unit can exchange digital signatures to validate each other’s identity with respect to their public keys. In this case, the required digital certificates must be installed on the remote peer and on the FortiGate unit. By exchanging certificate DNs, the signed server certificate on one peer is validated by the presence of the root certificate installed on the other peer.

The following procedure assumes that you already have a Phase 1 definition that describes how remote VPN peers and clients will be authenticated when they attempt to connect to a local FortiGate unit. For information about the Local ID and XAuth options, see Defining IKE negotiation parameters on page 1635 and Defining IKE negotiation parameters on page 1635. Follow this procedure to add IKE negotiation parameters to the existing definition.

Defining IKE negotiation parameters

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

3. Select Phase 1 Proposal and include the appropriate entries as follows:

Phase 1 Proposal Select the encryption and authentication algorithms that will be used to generate keys for protecting negotiations.

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.

Authentication You can select either of the following message digests to check the authen- ticity 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 com- bination, use the Add button beside the fields for the second combination.

For information regarding NP accelerated offloading of IPsec VPN authen- tication algorithms, please refer to the Hardware Acceleration handbook chapter.

Diffie–Hellman Group Select one or more Diffie-Hellman groups from DH groups 1, 2, 5, and 14 through 21. When using aggressive mode, DH groups cannot be nego- tiated. By default, DH group 14 is selected, to provide sufficient protection for stronger cipher suites that include AES and SHA2. If you select multiple DH groups, the order they appear in the configuration is the order in which they are negotiates.

If both VPN peers (or a VPN server and its client) have static IP addresses and use aggressive mode, select a single DH group. The setting on the FortiGate unit must be identical to the setting on the remote peer or dialup client.

When the remote VPN peer or client has a dynamic IP address and uses aggressive mode, select up to three DH groups on the FortiGate unit and one DH group on the remote peer or dialup client. The setting on the remote peer or dialup client must be identical to one of the selections on the FortiGate unit.

If the VPN peer or client employs main mode, you can select multiple DH groups. At least one of the settings on the remote peer or dialup client must be identical to the selections on the FortiGate unit.

Keylife Type the amount of time (in seconds) that will be allowed to pass before the IKE encryption key expires. When the key expires, a new key is gen- erated without interrupting service. The keylife can be from 120 to 172800 seconds.

Nat-traversal Enable this option if a NAT device exists between the local FortiGate unit and the VPN peer or client. The local FortiGate unit and the VPN peer or cli- ent must have the same NAT traversal setting (both selected or both cleared). When in doubt, enable NAT-traversal. See NAT traversal on page 1638.

Keepalive Frequency If you enabled NAT traversal, enter a keepalive frequency setting. The value represents an interval from 0 to 900 seconds where the connection will be maintained with no activity. For additional security this value must be as low as possible. See NAT keepalive frequency on page 1638.

Dead Peer Detection Enable this option to reestablish VPN tunnels on idle connections and clean up dead IKE peers if required. This feature minimizes the traffic required to check if a VPN peer is available or unavailable (dead). See Dead peer detection on page 1638.

NAT traversal

Network Address Translation (NAT) is a way to convert private IP addresses to publicly routable Internet addresses and vise versa. When an IP packet passes through a NAT device, the source or destination address in the IP header is modified. FortiGate units support NAT version 1 (encapsulate on port 500 with non-IKE marker), version 3 (encapsulate on port 4500 with non-ESP marker), and compatible versions.

NAT cannot be performed on IPsec packets in ESP tunnel mode because the packets do not contain a port number. As a result, the packets cannot be demultiplexed. To work around this, the FortiGate unit provides a way to protect IPsec packet headers from NAT modifications. When the Nat-traversal option is enabled, outbound encrypted packets are wrapped inside a UDP IP header that contains a port number. This extra encapsulation allows NAT devices to change the port number without modifying the IPsec packet directly.

To provide the extra layer of encapsulation on IPsec packets, the Nat-traversal option must be enabled whenever a NAT device exists between two FortiGate VPN peers or a FortiGate unit and a dialup client such as FortiClient. On the receiving end, the FortiGate unit or FortiClient removes the extra layer of encapsulation before decrypting the packet.

Additionally, you can force IPsec to use NAT traversal. If NAT is set to Forced, the FortiGate will use a port value of zero when constructing the NAT discovery hash for the peer. This causes the peer to think it is behind a NAT device, and it will use UDP encapsulation for IPsec, even if no NAT is present. This approach maintains interoperability with any IPsec implementation that supports the NAT-T RFC.

NAT keepalive frequency

When a NAT device performs network address translation on a flow of packets, the NAT device determines how long the new address will remain valid if the flow of traffic stops (for example, the connected VPN peer may be idle). The device may reclaim and reuse a NAT address when a connection remains idle for too long.

To work around this, when you enable NAT traversal specify how often the FortiGate unit sends periodic keepalive packets through the NAT device in order to ensure that the NAT address mapping does not change during the lifetime of a session. To be effective, the keepalive interval must be smaller than the session lifetime value used by the NAT device.

The keepalive packet is a 138-byte ISAKMP exchange.

Dead peer detection

Sometimes, due to routing issues or other difficulties, the communication link between a FortiGate unit and a VPN peer or client may go down. Packets could be lost if the connection is left to time out on its own. The FortiGate unit provides a mechanism called Dead Peer Detection, sometimes referred to as gateway detection or ping server, to prevent this situation and reestablish IKE negotiations automatically before a connection times out: the active Phase 1 security associations are caught and renegotiated (rekeyed) before the Phase 1 encryption key expires.

By default, Dead Peer Detection sends probe messages every five seconds by default (see dpd- retryinterval in the FortiGate CLI Reference). If you are experiencing high network traffic, you can experiment with increasing the ping interval. However longer intervals will require more traffic to detect dead peers which will result in more traffic.

In the web-based manager, the Dead Peer Detection option can be enabled when you define advanced Phase 1 options. The config vpn ipsec phase1 CLI command supports additional options for specifying a retry count and a retry interval.

For more information about these commands and the related config router gwdetect CLI command, see the FortiGate CLI Reference.

For example, enter the following CLI commands to configure dead peer detection on the existing IPsec Phase 1 configuration called test to use 15 second intervals and to wait for 3 missed attempts before declaring the peer dead and taking action.

config vpn ipsec phase1 edit test

set dpd [disable | on-idle | on-demand]

set dpd-retryinveral 15 set dpd-retrycount 3

next end

Using XAuth authentication

Extended authentication (XAuth) increases security by requiring the remote dialup client user to authenticate in a separate exchange at the end of Phase 1. XAuth draws on existing FortiGate user group definitions and uses established authentication mechanisms such as PAP, CHAP, RADIUS, and LDAP to authenticate dialup clients. You can configure a FortiGate unit to function either as an XAuth server or an XAuth client.If the server or client is attempting a connection using XAuth and the other end is not using XAuth, the failed connection attempts that are logged will not specify XAuth as the reason.

Using the FortiGate unit as an XAuth server

A FortiGate unit can act as an XAuth server for dialup clients. When the Phase 1 negotiation completes, the FortiGate unit challenges the user for a user name and password. It then forwards the user’s credentials to an external RADIUS or LDAP server for verification.

If the user records on the RADIUS server have suitably configured Framed-IP-Address fields, you can assign client virtual IP addresses by XAuth instead of from a DHCP address range. See FortiClient dialup-client configurations on page 1702.

The authentication protocol to use for XAuth depends on the capabilities of the authentication server and the XAuth client:

Select PAP Server whenever possible.
You must select PAP Server for all implementations of LDAP and some implementations of Microsoft RADIUS.
Select Auto Server when the authentication server supports CHAP Server but the XAuth client does not. The FortiGate unit will use PAP to communicate with the XAuth client and CHAP to communicate with the authentication server. You can also use Auto Server to allows multiple source interfaces to be defined in an IPsec/IKE policy

Before you begin, create user accounts and user groups to identify the dialup clients that need to access the network behind the FortiGate dialup server. If password protection will be provided through an external RADIUS or LDAP server, you must configure the FortiGate dialup server to forward authentication requests to the authentication server. For information about these topics, see the FortiGate User Authentication Guide.

To authenticate a dialup user group using XAuth settings

1. At the FortiGate dialup server, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

3. Under XAuth, select the Server Type setting, which determines the type of encryption method to use between the XAuth client, the FortiGate unit and the authentication server. Select one of the following options:

PAP Server —Password Authentication Protocol.
CHAP Server — Challenge-Handshake Authentication Protocol.
Auto Server —Use PAP between the XAuth client and the FortiGate unit, and CHAP between the FortiGate unit and the authentication server. This option allows multiple source interfaces to be defined in an IPsec/IKE policy.

4. From the User Group list, select the user group that needs to access the private network behind the FortiGate unit. The group must be added to the FortiGate configuration before it can be selected here. For multiple source interfaces to be defined in the IPsec/IKE policy, select Inherit Groups from Policy.

5. Select OK.

Using the FortiGate unit as an XAuth client

If the FortiGate unit acts as a dialup client, the remote peer, acting as an XAuth server, might require a username and password. You can configure the FortiGate unit as an XAuth client, with its own username and password, which it provides when challenged.

To configure the FortiGate dialup client as an XAuth client

1. At the FortiGate dialup client, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.

2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

3. Under XAuth, select Enable as Client.

4. In the Username field, type the FortiGate PAP, CHAP, RADIUS, or LDAP user name that the FortiGate XAuth server will compare to its records when the FortiGate XAuth client attempts to connect.

5. In the Password field, type the password to associate with the user name.

6. Select OK.

Dynamic IPsec route control

You can add a route to a peer destination selector by using the add-route option, which is available for all dynamic IPsec Phases 1 and 2, for both policy-based and route-based IPsec VPNs. This option was previously only available when mode-cfg was enabled in Phase 1.

The add-route option adds a route to the FortiGate unit’s routing information base when the dynamic tunnel is negotiated. You can use the distance and priority options to set the distance and priority of this route. If this results in a route with the lowest distance, it is added to the FortiGate unit’s forwarding information base.

You can also enable add-route in any policy-based or route-based Phase 2 configuration that is associated with a dynamic (dialup) Phase 1. In Phase 2, add-route can be enabled, disabled, or set to use the same route as Phase 1.

The add-route feature is enabled by default and is configured in the CLI.

Syntax

Phase 1

config vpn ipsec edit <name>

set type dynamic

set add-route {enable | disable}

end end

Phase 2

config vpn ipsec {phase2 | phase2-interface}

edit <name>

set add-route {phase1 | enable | disable}

end end

Blocking IPsec SA Negotiation

For interface-based IPsec, IPsec SA negotiation blocking can only be removed if the peer offers a wildcard selector. If a wildcard selector is offered then the wildcard route will be added to the routing table with the distance/priority value configured in Phase 1 and, if that is the route with the lowest distance, it is installed into the forwarding information base.

In cases where this occurs, it is important to ensure that the distance value configured on Phase 1 is set appropriately.

Fortinet GURU

FortiGate Guides and MORE!

Tag Archives: FortiGate IPSec Phase 1 parameters

FortiGate IPSec Phase 1 parameters