Phase 1 definition name.

The maximum length is 15 characters for an interface mode VPN.

FortiGate also uses the name for the virtual IPsec interface that it creates automatically.

Protocol, either IPv4 or IPv6.

Category of the remote connection:

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

• Dialup User: one or more FortiClient, FortiGate, or remote dialup clients 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.

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

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

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

IP address for the local end of the VPN tunnel. When this setting is disabled, 0.0.0.0 is used.

• Primary IP: defaults to the IP address of the interface chosen as the Remote Gateway interface.

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

Enable in Dialup VPNs to select the IP stack (IPv4 and/or IPv6), select the method in which client IPs are assigned and configure the client IP address range, subnet mask/prefix length, DNS server, and split tunnel capability to automate remote client addressing.

By default, IPsec uses encapsulating security payload (ESP) for encrypting data in the VPN session. However, because it uses IP protocol 50 without port numbers, when traversing over a NAT device the packets cannot be demultiplexed. NAT traversal encapsulates the ESP packets inside a UDP packet, thereby adding a unique source port to the packet, allowing the NAT device to map the packet to the correction session.

Furthermore, FortiGate also allows ESP and IKE packets to be encapsulated in TCP and encrypted in TLS. See Encapsulate ESP packets within TCP headers.

Transport mode is configurable only when the Remote gateway type is Static. In Static mode, the Transport is defaulted to UDP. Go to VPN > VPN Tunnels > Settings to enable VPN over TCP to allow setting the Transport mode to Auto.

When Transport mode is in Auto, UDP will be attempted first. If the transport threshold has been reached, then connection over TCP will be attempted.

When the Remote gateway type is Dialup and VPN over TCP is allowed, it will behave as if Transport mode is Auto.

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

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.

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

Ensures that only licensed FortiClient endpoints can establish an IPsec VPN connection with FortiGate. Both the FortiGate and FortiClient endpoints must be connected to the same FortiClient EMS

In a dialup VPN, add a route to a peer destination selector when a dynamic tunnel is negotiated. See Dynamic IPsec route control.

In ADVPN, enable or disable sending of auto-discovery short-cut messages

In ADVPN, enable or disable accepting auto-discovery short-cut messages

In ADVPN, enable or disable forwarding auto-discovery short-cut messages

A Fortinet-specific setting to allow two FortiGates to exchange their overlay tunnel IP. This allows a dialup server to learn the tunnel IP of each client, or in ADVPN, it allow spokes to learn others’ tunnel IP during shortcut negotiation.

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

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

Authentication

Either Pre-shared Key or Signature.

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.

When Authentication Method is Signature, select 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.

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

Note: When using FortiClient for remote access, IKEv1 is not supported on FortiClient 7.4.4 and later.

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.

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

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 in IKEv1.

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

This option is only applicable when Aggressive Mode is enabled in IKEv1. 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. For more details, see Customizing IPsec tunnel settings.

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.

In IKEv2, use Network ID.

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 in IKEv1 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.

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.

Select a group from the User Peer Group.

FortiOS supports remote gateway matching in a dial-up IPsec tunnel connection based on the public source IP, geolocation or Security Posture of dial-up clients. When a dial-up client first makes an IPsec connection to the FortiGate VPN gateway, the FortiGate will use the source IP to match the IPsec tunnel based on the IP subnet, address range, or country/region defined for that IPsec tunnel. IPv4 and IPv6 are supported. This feature requires the dynamic (dial-up) tunnel to be defined in IKEv2.

For geolocation-based matching, see Matching IPsec tunnel gateway based on address parameters.

To configure remote gateway matching:

config vpn ipsec phase1-interface
    edit <name>
        set type dynamic
        set ike-version 2
        set remote-gw-match {any | ipmask | iprange | geography | ztna}
    next
end

This option is only available when IKEv2 is selected.

In a SD-WAN configuration where a Hub has multiple dialup VPN overlays across different interfaces, enable Network overlay and assign a Network ID to the VPN tunnel to identify the tunnels.

This can also be used to differentiate multiple dial-up VPNs terminating on the same interface and local IP address. The Network ID is used to VPN gateway lookup since it is included in the first packet from the initiator.

Finally, in ADVPN, use the auto-discovery-crossover setting to enable or disable shortcuts to be setup between different network IDs.

When Network Overlay is enabled, specify the 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.

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

• Disable: do not use XAuth.

• 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 Specify). See XAuth user authentication.

In IKEv2, use EAP to configure user authentication.

• IKEv2 IDi payload: Client uses the Identification – Initiator (IDi) payload in the IKE_AUTH exchange to identify itself using unique IDs like IP address, email address, or FQDN.
• EAP identity request: Request the client to send their identity when authentication is initiated. Use this method when using EAP-MSCHAPv2, EAP-TLS with RADIUS, and LDAP.

IPsec IKEv2 VPNs support certificate authentication and EAP authentication at the same time from a dialup FortiClient. With the eap-cert-auth setting enabled, FortiGate will validate the X.509 certificate sent from FortiClient when establishing an IKEv2 tunnel. After it is authenticated, FortiGate will continue to perform EAP authentication.

config vpn ipsec phase1-interface
    edit <tunnel>
        set eap enable
        set eap-cert-auth {*disable | enable}
        set peer <user peer>
    next
end

See VPN 2FA with EAP and certificate authentication.

When EAP is chosen, you can specify a single user group directly in the VPN phase 1 configurations, or inherit the user groups from the firewall policy.

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.

The following symmetric-key encryption algorithms are available:

• DES: Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key. Not Recommended.

• 3DES: triple-DES; plain text is encrypted three times by three keys. Not Recommended.

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

• SM4: a 128-bit block cipher that uses a 128-bit key and a symmetric cipher. See SM3/SM4 cryptographic algorithms for IKEv1/ IKEv2 NEW for model limitations.

DES and 3DES are considered insecure by Fortinet's Security Rating Insights. If a security rating warning appears, disable the use of the Encryption algorithms.

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

• MD5: message digest 5. Not Recommended.

• SHA1: secure hash algorithm 1; a 160-bit message digest. Not Recommended.

• SHA256: a 256-bit message digest.

• SHA384: a 384-bit message digest.

• SHA512: a 512-bit message digest.

• SM3: a cryptographic hash function that produces a 256 bit digest. See SM3/SM4 cryptographic algorithms for IKEv1/ IKEv2 NEW for model limitations.

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

MD5 and SHA1 are considered insecure by Fortinet's Security Rating Insights. If a security rating warning appears, disable the use of the Authentication algorithms.

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.

DH groups 1, 2, 5, 14, 22-27 are considered insecure by Fortinet's Security Rating Insights. If a security rating warning appears, disable the use of these DH groups. By default, FortiGate uses DH group 20 and 21 when configuring a VPN from the GUI or CLI.

Enable quantum-resistant encryption by applying hybrid key exchange per RFC 9370 and RFC 9242.

When creating a new PQC Additional KE group:

• Transform Type: Each Transform type represents an additional round of KE exchange. Choose up to seven rounds or groups

• KE Groups: Choose up to three Key Exchange groups from these Key Exchange Mechanisms (KEMs): ML KEM (Kyber), BIKE, HQC, and FRODO.

For more information, see Post-Quantum Cryptography for IPsec key exchange.

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.

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

To configure GRE over IPsec:

config vpn ipsec {phase1-interface | phase1}
    edit ipsec
        set interface <name>
        set encapsulation 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

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