FortiOS 5.4 Online Help Link FortiOS 5.2 Online Help Link FortiOS 5.0 Online Help Link FortiOS 4.3 Online Help Link

Home > Online Help

> Chapter 1 - What's New for FortiOS 5.2 > IPsec VPN

IPsec VPN

New IPsec VPN features include:

VPN Creation Wizard

Several improvements have been made to the VPN Creation Wizard.

New Menu

The Wizard can now be found by going to VPN > IPsec > Wizard.

Expanded VPN Options

The number of VPN options available in the Wizard has increased to allows you to easily create VPN tunnels for a greater variety of scenarios.

Expanded VPN Options for the VPN Creation Wizard

For more information about using the VPN Wizard, see The FortiGate Cookbook recipe IPsec VPN for iOS devices.

Tunnel Templates

Several tunnel templates have been added to the Wizard that cover a variety of different types of IPsec VPNs. A list of these templates appears on the first page of the Wizard, which is found by going to VPN > IPsec > Tunnels.

To view more information about a template, highlight the template and select View.

Tunnel Templates list

Internet Key Exchange (IKE)

There have been several changes in FortiOS 5.2 made concerning Internet Key Exchange (IKE) protocol.

Multiple Interfaces

An IPsec policy can now contain multiple source and destination interfaces. This feature is supported for combinations of IPsec interfaces, physical interfaces, and zones (including those with a combination of physical and IPsec interfaces).

It is not supported for SSL VPN interfaces.

Mode-Configuration

When IKE Mode-Configuration is enabled, multiple server IPs can be defined in IPsec Phase 1. This mode also allows IP information to be sent the client if attribute 28681 is requested.

Mode-Configuration is configured through the CLI. An example of a complete configuration is shown below:

config vpn ipsec phase1-interface

edit "vpn-p1"

set type dynamic

set interface "wan1"

set xauthtype auto

set mode aggressive

set mode-cfg enable

set proposal 3des-sha1 aes128-sha1

set dpd disable

set dhgrp 2

set xauthexpire on-rekey

set authusrgrp "FG-Group1"

set ipv4-start-ip 10.10.10.10

set ipv4-end-ip 10.10.10.20

set ipv4-dns-server1 1.1.1.1

set ipv4-dns-server2 2.2.2.2

set ipv4-dns-server3 3.3.3.3

set ipv4-wins-server1 4.4.4.4

set ipv4-wins-server2 5.5.5.5

set domain "fgt1c-domain"

set banner "fgt111C-banner"

set backup-gateway "100.100.100.1" "100.100.100.2" "host1.com" "host2"

end

end

Certificates Groups

IKE certificate groups consisting of up to four RSA certificates can now be used in IKE phase 1. Since CA and local certificates are global, the IKE daemon loads them once for all VDOMs and indexes them into trees based on subject and public key hash (for CA certificates), or certificate name (for local certificates). Certificates are linked together based on the issuer, and certificate chains are built by traversing these links. This reduces the need to keep multiple copies of certificates that could exist in multiple chains.

IKE certificate groups can be configured through the CLI.

Configuring the IKE local ID

config vpn certificate local

edit <name>

set ike-localid <string>

set ike-localid-type {asn1dn | fqdn}

end

end

Adding certificates to the group

config vpn ipsec {phase1 | phase1-interface}

edit <name>

set rsa-certificate <name>

end

end

Authentication Methods

Three new authentication methods have been implemented for IKE: ECDSA-256, ECDSA-384, ECDSA-521.

In order to support these three methods, the following changes have been made to the CLI:

  1. rsa-signature has been renamed to signature for both policy-based and interface-based IPsec VPN.
  2. rsa-certificate has been renamed to certificate for both policy-based and interface-based IPsec VPN.

Inheriting Groups from the Security Policy

IPsec VPNs can now be configured to authenticate users again the group(s) specified in a policy that refers to the VPN's phase 1. To use this feature, do the following:

  1. Go to VPN > IPsec > Tunnels and edit a tunnel.
  2. Set XAUTH Type to Auto Server.
  3. Set User Group to Inherit Groups from Policy.

This feature can be used for both interface-based and policy-based IPsec VPN phase 1s.

Syntax

config vpn ipsec {phase1 | phase1-interface}

edit <name>

set xauthtype auto

end

end

Assigning Client IP Addresses Using the DHCP Proxy

IKE can now use the system DHCP proxy to assign client IP addresses.

To use this feature, the DHCP proxy must be enabled and a IP set. Up to 8 addresses can be selected for either IPv4 or IPv6. After the DHCP proxy has been configured, the assign-ip-from command is used to select assign IP address via DHCP.

Syntax
  1. Enabling the DHCP proxy and setting an IP range.

config system settings

set dhcp-proxy enable

set dhcp-server-ip <IP_address>

set dhcp6-server-ip <IP_address>

end

 

  1. Setting the IPsec phase one to assign IP addresses using the DHCP proxy.

config vpn ipsec phase1

edit <id>

set assign-ip-from dhcp

end

end

IP assignment can also come from a locally defined range or via the user group.

Transform Matching

FortiOS 5.2 supports combining multiple encryption, authentication, PRF, and DH transforms in a single IKEv2 proposal, which is used for selecting a transform set when the FortiGate unit is the responder. Each proposal now holds lists of transforms, instead of having just a single value per transform type. When negotiating, the proposal iterates over the transform lists to find a match.

Cookie Notification

Upon detecting that the number of half-open IKEv2 SAs is above the threshold value, the VPN dialup server will require 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.

Message ID Sync for High Availability

IKE Message ID Sync is supported in FortiOS 5.2. Message ID Sync allows IKEv2 to re-negotiate send and receive message ID counters after a high availability fail over. By doing this, the established IKE SA can remain up, instead of re-initializing.

A diagnose command has also been added to show statistics for the number of HA messages sent/received for IKE: diagnose vpn ike ha stats.

Dynamic IPsec Route Control

Greater control has been added in FortiOS 5.2 concerning adding routes for IPsec VPN.

add-route

The add-route option is now available for all dynamic IPsec phase 1s and phase 2s, for both policy-based and route-base IPsec VPNs. This allows you to control the addition of a route to a peer destination selector.

This option was previously only available when mode-cfg was enabled in phase 1. Also, in phase 2, a new option has been added allowing add-route to automatically match the settings in phase 1.

This feature is enabled by default.

Syntax
  1. Configuring phase 1:

config vpn ipsec {phase1 | phase1-interface}

edit <name>

set type dynamic

set add-route {enable | disable}

end

 

  1. Configuring phase 2:

config vpn ipsec {phase2 | phase2-interface}

edit <name>

set add-route {phase1 | enable | disable}

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 information base with the distance/priority value configured in the phase1 and, if that is the route with the lowest distance, it will be installed into the forwarding information base.

In a case where this occurs, it is important to ensure that the distance value on the phase1 is set appropriately.

Default Lifetimes and Proposal Values

The default lifetimes for IKE and IPsec have been lengthened in FortiOS 5.2. The number of proposals has also increased and new default proposals have been created for Phase 1 and Phase 2. The changes are as follows:

  • The default Phase1 lifetime is 86400 seconds (1 day).
  • The default Phase2 lifetime is 43200 seconds (12 hours).
  • The default Phase1 proposals are: aes128-sha256, aes256-sha256, 3des-sha256, aes128-sha1, aes256-sha1, and 3des-sha1.
  • The default Phase2 proposals are: aes128-sha1, aes256-sha1, 3des-sha1, aes128-sha256, aes256-sha256, and 3des-sha256.
  • The maximum number of proposals has been increased from 3 to 10.
  • The default Diffie-Hellman (DH) group for phase1 and phase2 has changed from 5 to 14.

Prioritizing DH Group Configuration

In FOS 5.2, the default Diffie-Hellman DH group has changed from 5 to 14, to provide sufficient protection for stronger cipher suites that include AES and SHA2. Because of this change, both IKEv1 and IKEv2 now allow up to 3 DH groups to be configured in the phase 1 and phase 2 settings, while preserving the ordering since the initiator always begins by using the first group in the list. The default DH group in the configuration has been updated to include group 14 and 5, in that order. You can add and remove other groups and the order they appear in the configuration is the order in which they are negotiated.

The IKEv1 protocol does not natively provide for DH group negotiation in Aggressive Mode and Quick Mode. As a result, when multiple DH groups are used with IKEv1 Aggressive Mode or Quick Mode, delays in tunnel establishment can occur and so it is recommended to continue to configure matching DH groups on both peers whenever possible.

During negotiation with multiple DH groups, the new operation is as follows:

  1. IKEv1 Aggressive Mode Initiator: Since Aggressive Mode includes the KE payload in the first message, FortiOS must select a group to use to generate the DH public number. FortiOS starts with the first group in the list. If the negotiation fails due to timeout, it will try the second group, and finally the third. If the third also fails, FortiOS goes back to the first DH group again, and starts over. Once it finds the correct group and the tunnel is established, it will continue to use that group for re-keying as long as the VPN connection remains up.
  2. IKEv1 Aggressive Mode Responder: If the group proposed by the initiator doesn't match the group proposed by the responder, the negotiation fails due to no proposal chosen. Since authentication has not been established the responder cannot send a notify message to the initiator. The initiator will try the next DH group in its configuration when the negotiation time out occurs, which takes 30 seconds by default. At that point, if the next DH group is a successful match, the tunnel comes up.
  3. IKEv1 Main Mode Initiator: In Main Mode, the SA and KE payloads come in different messages. The SA parameters, including DH group, are negotiated first in MM1 and MM2, then the KE payloads are exchanged in the MM3 and MM4 messages. So no change was made for Main Mode.
  4. IKEv1 Main Mode Responder: As above, no change for Main Mode.
  5. IKEv1 Quick Mode Initiator: Quick Mode has the same problem as Aggressive Mode, in that the SA proposal and KE payloads arrive in the same message. So unlike Main Mode, the initiator does not know the negotiated DH group prior to constructing its KE payload. Like with AM, it will start with the first group in the configured DH group list. If the negotiation times out, or if we receive a No-Proposal-Chosen notify message from the responder, we will switch to the next group in the list and try again.
  6. IKEv1 Quick Mode Responder: Similar to Aggressive Mode, if the initiator's first group doesn't match, the Quick Mode will fail with a no proposal chosen error. In Quick Mode, you have the benefit of an authenticated IKE SA by which you can immediately notify the peer of the error. Sending the No-Proposal-Chosen notify to the initiator allows the initiator to try the next group immediately without waiting for a timeout.
  7. IKEv2 SA_INIT/CHILD_SA Initiator: Like Aggressive Mode, in IKEv2 both the SA_INIT and CHILD_SA exchanges have the SA proposal and KE payload in the same message. However, unlike IKEv1, the IKEv2 RFC specifies a mechanism to handle this. In IKEv2, if the negotiated DH group does not match the group specified in the KE payload, the INVALID_KE notify message is sent and the initiator retries the exchange using the DH group specified in the notify message. Initiator side support for handling the INVALID_KE message has been added. This code wasn't needed previously, as the IKEv2 CLI allowed only one DH group to be configured. Now that the CLI restriction has been removed and multiple DH groups can be configured for IKEv2 in the phase1 and phase2 settings, the initiator will handle receipt of INVALID_KE messages as per the IKEv2 RFC. As long as the VPN connection remains up, the initiator will subsequently re-key using the negotiated group.
  8. IKEv2 SA_INIT/CHILD_SA Responder: The responder side of our IKEv2 code already supports handling of the INVALID_KE message.

IPv6 Support for IPsec Phase 2

IPv6 support has been added to IPsec phase 2, allowing IPv6 firewall address and address groups to be used for phase 2 source and destination address types. The management of static selector rules has also been moved into the IKE daemon, allowing named selectors to be reloaded if any named address or address groups are changed, without requiring the FortiGate unit to be rebooted before changes are applied.

IPsec VPN Support with the FortiController-5103B

The FortiController-5103B can now learn the routing table as a slave to receive the update from master. When packets are received, the 5103B blade tests the routing table to determine whether the traffic will be routed to the IPsec interface, if it does, it will trigger 5103 to forward the traffic to dedicated IPsec blade. This ensures that all IPsec traffic is sent to the dedicated IPsec blade, even traffic originating from the 5000 system, such as monitoring systems or internal emails.