Fortinet white logo
Fortinet white logo

Administration Guide

Phase 1 configuration

Phase 1 configuration

Phase 1 configuration primarily defines the parameters used in IKE (Internet Key Exchange) negotiation between the ends of the IPsec tunnel. The local end is the FortiGate interface that initiates the IKE negotiations. The remote end is the remote gateway that responds and exchanges messages with the initiator. Hence, they are sometimes referred to as the initiator and responder. The purpose of phase 1 is to secure a tunnel with one bi-directional IKE SA (security association) for negotiating IKE phase 2 parameters.

The auto-negotiate and negotiation-timeout commands control how the IKE negotiation is processed when there is no traffic, and the length of time that the FortiGate waits for negotiations to occur.

IPsec tunnels can be configured in the GUI using the VPN Creation Wizard. Go to VPN > IPsec Wizard. The wizard includes several templates (site-to-site, hub and spoke, remote access), but a custom tunnel can be configured with the following settings.

Note

The IPsec phase 1 interface type cannot be changed after it is configured. This is due to the tunnel ID parameter (tun_id), which is used to match routes to IPsec tunnels to forward traffic. If the IPsec phase 1 interface type needs to be changed, a new interface must be configured.

Caution

For FortiOS 7.4.0, SSL VPN web mode, explicit web proxy, and interface mode IPsec VPN features will not work with the following configuration:

  1. An IP pool with ARP reply enabled is configured.

  2. This IP pool is configured as the source IP address in a firewall policy for SSL VPN web mode, in a proxy policy for explicit web proxy, or as the local gateway in the Phase 1 settings for an interface mode IPsec VPN.

  3. A matching blackhole route is configured for IP pool reply traffic.

Configuring an IP pool as the source NAT IP address in a regular firewall policy works as before.

For details, see Technical Tip: IP pool and virtual IP behaviour changes in FortiOS 6.4, 7.0, 7.2, and 7.4.

Name

Phase 1 definition name.

The maximum length is 15 characters for an interface mode VPN and 35 characters for a policy-based VPN.

For a policy-based VPN, the name normally reflects where the remote connection originates. For a route-based tunnel, the FortiGate also uses the name for the virtual IPsec interface that it creates automatically.

Network

IP Version

Protocol, either IPv4 or IPv6.

Remote Gateway

Category of the remote connection:

  • Static IP Address: the remote peer has a static IP address.

  • Dialup User: one or more FortiClient or FortiGate dialup clients with dynamic IP addresses will connect to the FortiGate.

  • Dynamic DNS: a remote peer that has a domain name and subscribes to a dynamic DNS service will connect to the FortiGate.

IP Address

The IP address of the remote peer. This option is only available when the Remote Gateway is Static IP Address.

Dynamic DNS

The domain name of the remote peer. This option is only available when the Remote Gateway is Dynamic DNS.

Interface

The interface through which remote peers or dialup clients connect to the FortiGate. This option is only available in NAT mode.

By default, the local VPN gateway IP address is the IP address of the interface that was selected (Primary IP in the Local Gateway field).

Local Gateway

IP address for the local end of the VPN tunnel (Primary IP is used by default):

  • Secondary IP: secondary address of the interface selected in the Interface field.
  • Specify: manually enter an address.

Interface mode cannot be configured in a transparent mode VDOM.

Mode Config

This option is only available when the Remote Gateway is Dialup User.

Configure the client IP address range, subnet mask/prefix length, DNS server, and split tunnel capability to automate remote client addressing.

NAT Traversal

This option is only available when the Remote Gateway is Static IP Address or Dynamic DNS.

ESP (encapsulating security payload), the protocol for encrypting data in the VPN session, uses IP protocol 50 by default. However, it does not use any port numbers so when traversing a NAT device, the packets cannot be demultiplexed. Enabling NAT traversal encapsulates the ESP packet inside a UDP packet, thereby adding a unique source port to the packet. This allows the NAT device to map the packets to the correct session.

  • Enable: a NAT device exists between the local FortiGate and the VPN peer or client. Outbound encrypted packets are wrapped inside a UDP IP header that contains a port number. The local FortiGate and the VPN peer or client must have the same NAT traversal setting (both selected or both cleared) to connect reliably. When in doubt, enable NAT traversal.

  • Disable: disable the NAT traversal setting.

  • 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.

Keepalive Frequency

Keepalive frequency setting. This option is only available when NAT Traversal is set to Enable or Forced. The NAT device between the VPN peers may remove the session when the VPN connection remains idle for too long.

The value represents an interval in seconds where the connection will be maintained with periodic keepalive packets. 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

Reestablishes VPN tunnels on idle connections and cleans up dead IKE peers if required. This feature minimizes the traffic required to check if a VPN peer is available or unavailable (dead). The available options are:

  • Disable: disable dead peer detection (DPD).

  • On Idle: triggers DPD when IPsec is idle.

  • On Demand: Passively sends DPD to reduce load on the firewall. Only triggers DPD when IPsec outbound packets are sent, but no reply is received from the peer. When there is no traffic and the last DPD-ACK has been received, IKE will not send DPDs periodically.

Notifications are received whenever a tunnel goes up or down, or to keep the tunnel connection open when no traffic is being generated inside the tunnel. For example, in scenarios where a dialup client or dynamic DNS peer connects from an IP address that changes periodically, traffic may be suspended while the IP address changes.

When Dead Peer Detection is selected, optionally specify a retry count and a retry interval using dpd-retrycount and dpd-retryinterval. See Dead peer detection.

Forward Error Correction

Enable on both ends of the tunnel to correct errors in data transmission by sending redundant data across the VPN.

Device creation

Advanced option. When enabled, a dynamic interface (network device) is created for each dialup tunnel.

Aggregate member

Advanced option. When enabled, the tunnel can be used as an aggregate member candidate.

Authentication

Method

Either Pre-shared Key or Signature.

Pre-shared Key

The pre-shared key that the FortiGate will use to authenticate itself to the remote peer or dialup client during phase 1 negotiations. The same key must be defined at the remote peer or client. See Pre-shared key.

Certificate Name

The server certificate that the FortiGate will use to authenticate itself to the remote peer or dialup client during phase 1 negotiations. See Digital certificates.

IKE Version

Either 1 or 2. See Choosing IKE version 1 and 2.

Mode

This option is only available when IKEv1 is selected. The two available options are:

  • Aggressive: the phase 1 parameters are exchanged in a single message with unencrypted authentication information.

  • Main (ID protection): the phase 1 parameters are exchanged in multiple rounds with encrypted authentication information.

When the remote VPN peer has a dynamic IP address and is authenticated by a pre-shared key, you must select Aggressive mode if there is more than one dialup phase 1 configuration for the interface IP address.

When the remote VPN peer has a dynamic IP address and is authenticated by a certificate, you must select Aggressive mode if there is more than one phase 1 configuration for the interface IP address and these phase 1 configurations use different proposals.

Peer Options

Options to authenticate VPN peers or clients depending on the Remote Gateway and Authentication Method settings.

Any peer ID

Accepts the local ID of any remote VPN peer or client. The FortiGate does not check identifiers (local IDs). Mode can be set to Aggressive or Main.

This option can be used with digital certificate authentication, but for higher security, use Peer certificate.

Specific peer ID

This option is only available when Aggressive Mode is enabled. Enter the identifier that is used to authenticate the remote peer. The identifier must match the local ID configured by the remote peer’s administrator.

If the remote peer is a FortiGate, the identifier is specified in the Local ID field of the Phase 1 Proposal settings.

If the remote peer is a FortiClient user, the identifier is specified in the Local ID field.

In circumstances where multiple remote dialup VPN tunnels exist, each tunnel must have a peer ID set.

Peer certificate

Define the CA certificate used to authenticate the remote peer when the authentication mode is Signature.

If the FortiGate will act as a VPN client, and you are using security certificates for authentication, set the Local ID to the distinguished name (DN) of the local server certificate that the FortiGate unit will use for authentication purposes.

Peer ID from dialup group

Authenticate multiple FortiGate or FortiClient dialup clients that use unique identifiers and unique pre-shared keys (or unique pre‑shared keys only) through the same VPN tunnel.

You must create a dialup user group for authentication purposes. Select the group from the list next to the Peer ID from dialup group option.

You must set Mode to Aggressive when the dialup clients use unique identifiers and unique pre-shared keys. If the dialup clients use unique pre-shared keys only, you can set Mode to Main if there is only one dialup Phase 1 configuration for this interface IP address.

Phase 1 Proposal

The encryption and authentication algorithms used to generate keys for the IKE SA.

There must be a minimum of one combination. The remote peer or client must be configured to use at least one of the proposals that you define.

Encryption

The following symmetric-key encryption algorithms are available:

  • 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 also HMAC settings.

Authentication

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

  • 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.

In IKEv2, encryption algorithms include authentication, but a PRF (pseudo random function) is still required (PRFSHA1, PRFSHA256, PRFSHA384, PRFSHA512). See also HMAC settings.

Diffie-Hellman Groups

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.

Key Lifetime

The time (in seconds) that must pass before the IKE encryption key expires. When the key expires, a new key is generated without interrupting service. The keylife can be from 120 to 172 800 seconds.

Local ID

Optional setting. This value must match the peer ID value given for the remote VPN peer’s Peer Options.

  • If the FortiGate will act as a VPN client and you are using peer IDs for authentication purposes, enter the identifier that the FortiGate will supply to the VPN server during the phase 1 exchange.

  • If the FortiGate will act as a VPN client and you are using security certificates for authentication, select the distinguished name (DN) of the local server certificate that the FortiGate will use for authentication purposes.

XAUTH

This option supports the authentication of dialup clients. It is only available for IKE version 1.

  • Disable: do not use XAuth.

  • Client: available only if the Remote Gateway is set to Static IP Address or Dynamic DNS. If the FortiGate is a dialup client, enter the user name and password for the FortiGate to authenticate itself to the remote XAuth server.

  • PAP Server, CHAP Server, Auto Server: available only if Remote Gateway is set to Dialup User. Dialup clients authenticate as members of a dialup user group. A user group must be created first for the dialup clients that need access to the network behind the FortiGate.

    The FortiGate must be configured to forward authentication requests to an external RADIUS or LDAP authentication server.

    Select the server type based on the encryption method used between the FortiGate, the XAuth client, and the external authentication server. Then select the user group (Inherit from policy or Choose). See Using XAuth authentication.

Username

User name used for authentication.

Password

Password used for authentication.

Additional CLI configurations

The following phase 1 settings can be configured in the CLI:

VXLAN over IPsec

Packets with a VXLAN header are encapsulated within IPsec tunnel mode.

To configure VXLAN over IPsec:
config vpn ipsec phase1-interface/phase1
    edit ipsec
        set interface <name>
        set encapsulation vxlan/gre 
        set encapsulation-address ike/ipv4/ipv6
        set encap-local-gw4 xxx.xxx.xxx.xxx  
        set encap-remote-gw xxx.xxx.xxx.xxx  
    next
end

IPsec tunnel idle timer

Define an idle timer for IPsec tunnels. When no traffic has passed through the tunnel for the configured idle-timeout value, the IPsec tunnel will be flushed.

To configure IPsec tunnel idle timeout:
config vpn ipsec phase1-interface
    edit p1
        set idle-timeout [enable | disable]
        set idle-timeoutinterval <integer> IPsec tunnel idle timeout in minutes (10 - 43200).
    next
end

Monitor tunnel for failover

Monitor a site-to-site tunnel to guarantee operational continuity if the primary tunnel fails. Configure the secondary phase 1 interface to monitor the primary interface.

To configure the monitor:
config vpn ipsec phase1-interface
    edit <secondary phase1-interface>
        set monitor <primary phase1-interface>
    next
end

Passive mode

Passive mode turns one side of the tunnel to be a responder only. It does not initiate VPN tunnels either by auto-negotiation, rekey, or traffic initiated behind the FortiGate.

To configure passive mode:
config vpn ipsec phase1-interface
    edit <example>
        set rekey {enable | disable}
        set passive-mode {enable | disable}
        set passive-tunnel-interface {enable | disable}
    next
end

Network ID

The network ID is a Fortinet-proprietary attribute that is used to select the correct phase 1 between IPsec peers, so that multiple IKEv2 tunnels can be established between the same local/remote gateway pairs.

In a dial-up VPN, network-id is in the first initiator message of an IKEv2 phase 1 negotiation. The responder (Hub) uses the network-id to match a phase 1 configuration with a matching network-id. The Hub can then differentiate multiple dial-up phase 1s that are bound to the same underlay interface and IP address. Without a network-id, the Hub cannot have multiple phase 1 dialup tunnels on the same interface.

In static phase 1 configurations, network-id is used with the pair of gateway IPs to negotiate the correct tunnel with a matching network-id. This allows IPsec peers to use the same pair of underlay IPs to establish multiple IPsec tunnels. Without it, only a single tunnel can be established over the same pair of underlay IPs.

To configure the network ID:
config vpn ipsec phase1-interface
    edit <example>
        set ike-version 2
        set network-overlay enable
        set network-id <integer>
    next
end

Dead peer detection

By default, dead peer detection (DPD) sends probe messages every five seconds. 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.

Note

In a dynamic (dialup) connection, the On Idle option encourages dialup server configurations to more proactively delete tunnels if the peer is unavailable.

In the GUI, the dead peer detection option can be configured when defining phase 1 options. The following CLI commands support additional options for specifying a retry count and a retry interval.

For example, enter the following to configure DPD on the existing IPsec phase 1 configuration to use 15-second intervals and to wait for three missed attempts before declaring the peer dead and taking action.

To configure DPD:
config vpn ipsec phase1-interface
    edit <value>
        set dpd [disable | on-idle | on-demand]
        set dpd-retryinveral 15
        set dpd-retrycount 3
    next
end

DPD scalability

On a dialup server, if many VPN connections are idle, the increased DPD exchange could negatively impact the performance/load of the daemon. The on-demand option in the CLI triggers DPD when IPsec traffic is sent, but no reply is received from the peer.

When there is no traffic and the last DPD-ACK had been received, IKE will not send DPDs periodically. IKE will only send out DPDs if there are outgoing packets to send, but no inbound packets have since been received.

HMAC settings

The FortiGate uses the HMAC based on the authentication proposal that is chosen in phase 1 or phase 2 of the IPsec configuration. Each proposal consists of the encryption-hash pair (such as 3des-sha256). The FortiGate matches the most secure proposal to negotiate with the peer.

To view the chosen proposal and the HMAC hash used:
# diagnose vpn ike gateway list

vd: root/0
name: MPLS
version: 1
interface: port1 3
addr: 192.168.2.5:500 -> 10.10.10.1:500
tun_id: 10.10.10.1
virtual-interface-addr: 172.31.0.2 -> 172.31.0.1
created: 1015820s ago
IKE SA: created 1/13 established 1/13 time 10/1626/21010 ms
IPsec SA: created 1/24 established 1/24 time 0/11/30 ms

  id/spi: 124 43b087dae99f7733/6a8473e58cd8990a
  direction: responder
  status: established 68693-68693s ago = 10ms
  proposal: 3des-sha256
  key: e0fa6ab8dc509b33-aa2cc549999b1823-c3cb9c337432646e
  lifetime/rekey: 86400/17436
  DPD sent/recv: 000001e1/00000000

Phase 1 configuration

Phase 1 configuration

Phase 1 configuration primarily defines the parameters used in IKE (Internet Key Exchange) negotiation between the ends of the IPsec tunnel. The local end is the FortiGate interface that initiates the IKE negotiations. The remote end is the remote gateway that responds and exchanges messages with the initiator. Hence, they are sometimes referred to as the initiator and responder. The purpose of phase 1 is to secure a tunnel with one bi-directional IKE SA (security association) for negotiating IKE phase 2 parameters.

The auto-negotiate and negotiation-timeout commands control how the IKE negotiation is processed when there is no traffic, and the length of time that the FortiGate waits for negotiations to occur.

IPsec tunnels can be configured in the GUI using the VPN Creation Wizard. Go to VPN > IPsec Wizard. The wizard includes several templates (site-to-site, hub and spoke, remote access), but a custom tunnel can be configured with the following settings.

Note

The IPsec phase 1 interface type cannot be changed after it is configured. This is due to the tunnel ID parameter (tun_id), which is used to match routes to IPsec tunnels to forward traffic. If the IPsec phase 1 interface type needs to be changed, a new interface must be configured.

Caution

For FortiOS 7.4.0, SSL VPN web mode, explicit web proxy, and interface mode IPsec VPN features will not work with the following configuration:

  1. An IP pool with ARP reply enabled is configured.

  2. This IP pool is configured as the source IP address in a firewall policy for SSL VPN web mode, in a proxy policy for explicit web proxy, or as the local gateway in the Phase 1 settings for an interface mode IPsec VPN.

  3. A matching blackhole route is configured for IP pool reply traffic.

Configuring an IP pool as the source NAT IP address in a regular firewall policy works as before.

For details, see Technical Tip: IP pool and virtual IP behaviour changes in FortiOS 6.4, 7.0, 7.2, and 7.4.

Name

Phase 1 definition name.

The maximum length is 15 characters for an interface mode VPN and 35 characters for a policy-based VPN.

For a policy-based VPN, the name normally reflects where the remote connection originates. For a route-based tunnel, the FortiGate also uses the name for the virtual IPsec interface that it creates automatically.

Network

IP Version

Protocol, either IPv4 or IPv6.

Remote Gateway

Category of the remote connection:

  • Static IP Address: the remote peer has a static IP address.

  • Dialup User: one or more FortiClient or FortiGate dialup clients with dynamic IP addresses will connect to the FortiGate.

  • Dynamic DNS: a remote peer that has a domain name and subscribes to a dynamic DNS service will connect to the FortiGate.

IP Address

The IP address of the remote peer. This option is only available when the Remote Gateway is Static IP Address.

Dynamic DNS

The domain name of the remote peer. This option is only available when the Remote Gateway is Dynamic DNS.

Interface

The interface through which remote peers or dialup clients connect to the FortiGate. This option is only available in NAT mode.

By default, the local VPN gateway IP address is the IP address of the interface that was selected (Primary IP in the Local Gateway field).

Local Gateway

IP address for the local end of the VPN tunnel (Primary IP is used by default):

  • Secondary IP: secondary address of the interface selected in the Interface field.
  • Specify: manually enter an address.

Interface mode cannot be configured in a transparent mode VDOM.

Mode Config

This option is only available when the Remote Gateway is Dialup User.

Configure the client IP address range, subnet mask/prefix length, DNS server, and split tunnel capability to automate remote client addressing.

NAT Traversal

This option is only available when the Remote Gateway is Static IP Address or Dynamic DNS.

ESP (encapsulating security payload), the protocol for encrypting data in the VPN session, uses IP protocol 50 by default. However, it does not use any port numbers so when traversing a NAT device, the packets cannot be demultiplexed. Enabling NAT traversal encapsulates the ESP packet inside a UDP packet, thereby adding a unique source port to the packet. This allows the NAT device to map the packets to the correct session.

  • Enable: a NAT device exists between the local FortiGate and the VPN peer or client. Outbound encrypted packets are wrapped inside a UDP IP header that contains a port number. The local FortiGate and the VPN peer or client must have the same NAT traversal setting (both selected or both cleared) to connect reliably. When in doubt, enable NAT traversal.

  • Disable: disable the NAT traversal setting.

  • 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.

Keepalive Frequency

Keepalive frequency setting. This option is only available when NAT Traversal is set to Enable or Forced. The NAT device between the VPN peers may remove the session when the VPN connection remains idle for too long.

The value represents an interval in seconds where the connection will be maintained with periodic keepalive packets. 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

Reestablishes VPN tunnels on idle connections and cleans up dead IKE peers if required. This feature minimizes the traffic required to check if a VPN peer is available or unavailable (dead). The available options are:

  • Disable: disable dead peer detection (DPD).

  • On Idle: triggers DPD when IPsec is idle.

  • On Demand: Passively sends DPD to reduce load on the firewall. Only triggers DPD when IPsec outbound packets are sent, but no reply is received from the peer. When there is no traffic and the last DPD-ACK has been received, IKE will not send DPDs periodically.

Notifications are received whenever a tunnel goes up or down, or to keep the tunnel connection open when no traffic is being generated inside the tunnel. For example, in scenarios where a dialup client or dynamic DNS peer connects from an IP address that changes periodically, traffic may be suspended while the IP address changes.

When Dead Peer Detection is selected, optionally specify a retry count and a retry interval using dpd-retrycount and dpd-retryinterval. See Dead peer detection.

Forward Error Correction

Enable on both ends of the tunnel to correct errors in data transmission by sending redundant data across the VPN.

Device creation

Advanced option. When enabled, a dynamic interface (network device) is created for each dialup tunnel.

Aggregate member

Advanced option. When enabled, the tunnel can be used as an aggregate member candidate.

Authentication

Method

Either Pre-shared Key or Signature.

Pre-shared Key

The pre-shared key that the FortiGate will use to authenticate itself to the remote peer or dialup client during phase 1 negotiations. The same key must be defined at the remote peer or client. See Pre-shared key.

Certificate Name

The server certificate that the FortiGate will use to authenticate itself to the remote peer or dialup client during phase 1 negotiations. See Digital certificates.

IKE Version

Either 1 or 2. See Choosing IKE version 1 and 2.

Mode

This option is only available when IKEv1 is selected. The two available options are:

  • Aggressive: the phase 1 parameters are exchanged in a single message with unencrypted authentication information.

  • Main (ID protection): the phase 1 parameters are exchanged in multiple rounds with encrypted authentication information.

When the remote VPN peer has a dynamic IP address and is authenticated by a pre-shared key, you must select Aggressive mode if there is more than one dialup phase 1 configuration for the interface IP address.

When the remote VPN peer has a dynamic IP address and is authenticated by a certificate, you must select Aggressive mode if there is more than one phase 1 configuration for the interface IP address and these phase 1 configurations use different proposals.

Peer Options

Options to authenticate VPN peers or clients depending on the Remote Gateway and Authentication Method settings.

Any peer ID

Accepts the local ID of any remote VPN peer or client. The FortiGate does not check identifiers (local IDs). Mode can be set to Aggressive or Main.

This option can be used with digital certificate authentication, but for higher security, use Peer certificate.

Specific peer ID

This option is only available when Aggressive Mode is enabled. Enter the identifier that is used to authenticate the remote peer. The identifier must match the local ID configured by the remote peer’s administrator.

If the remote peer is a FortiGate, the identifier is specified in the Local ID field of the Phase 1 Proposal settings.

If the remote peer is a FortiClient user, the identifier is specified in the Local ID field.

In circumstances where multiple remote dialup VPN tunnels exist, each tunnel must have a peer ID set.

Peer certificate

Define the CA certificate used to authenticate the remote peer when the authentication mode is Signature.

If the FortiGate will act as a VPN client, and you are using security certificates for authentication, set the Local ID to the distinguished name (DN) of the local server certificate that the FortiGate unit will use for authentication purposes.

Peer ID from dialup group

Authenticate multiple FortiGate or FortiClient dialup clients that use unique identifiers and unique pre-shared keys (or unique pre‑shared keys only) through the same VPN tunnel.

You must create a dialup user group for authentication purposes. Select the group from the list next to the Peer ID from dialup group option.

You must set Mode to Aggressive when the dialup clients use unique identifiers and unique pre-shared keys. If the dialup clients use unique pre-shared keys only, you can set Mode to Main if there is only one dialup Phase 1 configuration for this interface IP address.

Phase 1 Proposal

The encryption and authentication algorithms used to generate keys for the IKE SA.

There must be a minimum of one combination. The remote peer or client must be configured to use at least one of the proposals that you define.

Encryption

The following symmetric-key encryption algorithms are available:

  • 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 also HMAC settings.

Authentication

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

  • 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.

In IKEv2, encryption algorithms include authentication, but a PRF (pseudo random function) is still required (PRFSHA1, PRFSHA256, PRFSHA384, PRFSHA512). See also HMAC settings.

Diffie-Hellman Groups

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.

Key Lifetime

The time (in seconds) that must pass before the IKE encryption key expires. When the key expires, a new key is generated without interrupting service. The keylife can be from 120 to 172 800 seconds.

Local ID

Optional setting. This value must match the peer ID value given for the remote VPN peer’s Peer Options.

  • If the FortiGate will act as a VPN client and you are using peer IDs for authentication purposes, enter the identifier that the FortiGate will supply to the VPN server during the phase 1 exchange.

  • If the FortiGate will act as a VPN client and you are using security certificates for authentication, select the distinguished name (DN) of the local server certificate that the FortiGate will use for authentication purposes.

XAUTH

This option supports the authentication of dialup clients. It is only available for IKE version 1.

  • Disable: do not use XAuth.

  • Client: available only if the Remote Gateway is set to Static IP Address or Dynamic DNS. If the FortiGate is a dialup client, enter the user name and password for the FortiGate to authenticate itself to the remote XAuth server.

  • PAP Server, CHAP Server, Auto Server: available only if Remote Gateway is set to Dialup User. Dialup clients authenticate as members of a dialup user group. A user group must be created first for the dialup clients that need access to the network behind the FortiGate.

    The FortiGate must be configured to forward authentication requests to an external RADIUS or LDAP authentication server.

    Select the server type based on the encryption method used between the FortiGate, the XAuth client, and the external authentication server. Then select the user group (Inherit from policy or Choose). See Using XAuth authentication.

Username

User name used for authentication.

Password

Password used for authentication.

Additional CLI configurations

The following phase 1 settings can be configured in the CLI:

VXLAN over IPsec

Packets with a VXLAN header are encapsulated within IPsec tunnel mode.

To configure VXLAN over IPsec:
config vpn ipsec phase1-interface/phase1
    edit ipsec
        set interface <name>
        set encapsulation vxlan/gre 
        set encapsulation-address ike/ipv4/ipv6
        set encap-local-gw4 xxx.xxx.xxx.xxx  
        set encap-remote-gw xxx.xxx.xxx.xxx  
    next
end

IPsec tunnel idle timer

Define an idle timer for IPsec tunnels. When no traffic has passed through the tunnel for the configured idle-timeout value, the IPsec tunnel will be flushed.

To configure IPsec tunnel idle timeout:
config vpn ipsec phase1-interface
    edit p1
        set idle-timeout [enable | disable]
        set idle-timeoutinterval <integer> IPsec tunnel idle timeout in minutes (10 - 43200).
    next
end

Monitor tunnel for failover

Monitor a site-to-site tunnel to guarantee operational continuity if the primary tunnel fails. Configure the secondary phase 1 interface to monitor the primary interface.

To configure the monitor:
config vpn ipsec phase1-interface
    edit <secondary phase1-interface>
        set monitor <primary phase1-interface>
    next
end

Passive mode

Passive mode turns one side of the tunnel to be a responder only. It does not initiate VPN tunnels either by auto-negotiation, rekey, or traffic initiated behind the FortiGate.

To configure passive mode:
config vpn ipsec phase1-interface
    edit <example>
        set rekey {enable | disable}
        set passive-mode {enable | disable}
        set passive-tunnel-interface {enable | disable}
    next
end

Network ID

The network ID is a Fortinet-proprietary attribute that is used to select the correct phase 1 between IPsec peers, so that multiple IKEv2 tunnels can be established between the same local/remote gateway pairs.

In a dial-up VPN, network-id is in the first initiator message of an IKEv2 phase 1 negotiation. The responder (Hub) uses the network-id to match a phase 1 configuration with a matching network-id. The Hub can then differentiate multiple dial-up phase 1s that are bound to the same underlay interface and IP address. Without a network-id, the Hub cannot have multiple phase 1 dialup tunnels on the same interface.

In static phase 1 configurations, network-id is used with the pair of gateway IPs to negotiate the correct tunnel with a matching network-id. This allows IPsec peers to use the same pair of underlay IPs to establish multiple IPsec tunnels. Without it, only a single tunnel can be established over the same pair of underlay IPs.

To configure the network ID:
config vpn ipsec phase1-interface
    edit <example>
        set ike-version 2
        set network-overlay enable
        set network-id <integer>
    next
end

Dead peer detection

By default, dead peer detection (DPD) sends probe messages every five seconds. 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.

Note

In a dynamic (dialup) connection, the On Idle option encourages dialup server configurations to more proactively delete tunnels if the peer is unavailable.

In the GUI, the dead peer detection option can be configured when defining phase 1 options. The following CLI commands support additional options for specifying a retry count and a retry interval.

For example, enter the following to configure DPD on the existing IPsec phase 1 configuration to use 15-second intervals and to wait for three missed attempts before declaring the peer dead and taking action.

To configure DPD:
config vpn ipsec phase1-interface
    edit <value>
        set dpd [disable | on-idle | on-demand]
        set dpd-retryinveral 15
        set dpd-retrycount 3
    next
end

DPD scalability

On a dialup server, if many VPN connections are idle, the increased DPD exchange could negatively impact the performance/load of the daemon. The on-demand option in the CLI triggers DPD when IPsec traffic is sent, but no reply is received from the peer.

When there is no traffic and the last DPD-ACK had been received, IKE will not send DPDs periodically. IKE will only send out DPDs if there are outgoing packets to send, but no inbound packets have since been received.

HMAC settings

The FortiGate uses the HMAC based on the authentication proposal that is chosen in phase 1 or phase 2 of the IPsec configuration. Each proposal consists of the encryption-hash pair (such as 3des-sha256). The FortiGate matches the most secure proposal to negotiate with the peer.

To view the chosen proposal and the HMAC hash used:
# diagnose vpn ike gateway list

vd: root/0
name: MPLS
version: 1
interface: port1 3
addr: 192.168.2.5:500 -> 10.10.10.1:500
tun_id: 10.10.10.1
virtual-interface-addr: 172.31.0.2 -> 172.31.0.1
created: 1015820s ago
IKE SA: created 1/13 established 1/13 time 10/1626/21010 ms
IPsec SA: created 1/24 established 1/24 time 0/11/30 ms

  id/spi: 124 43b087dae99f7733/6a8473e58cd8990a
  direction: responder
  status: established 68693-68693s ago = 10ms
  proposal: 3des-sha256
  key: e0fa6ab8dc509b33-aa2cc549999b1823-c3cb9c337432646e
  lifetime/rekey: 86400/17436
  DPD sent/recv: 000001e1/00000000