One-Click VPN (OCVPN)

One-Click VPN (OCVPN) is a cloud-based solution that greatly simplifies the provisioning and configuration of IPsec VPN. The administrator enables OCVPN with a single click, adds the required subnets, and then the configuration is complete. The OCVPN updates each FortiGate automatically as devices join/leave the VPN, as subnets are added/removed, when dynamic external IPs change (e.g. DHCP/PPPoE), and when WAN interface bindings change (as in the dual WAN redundancy case).

Configuration changes and events are automatically propagated across participating nodes without user intervention, so in a sense, the VPN manages itself as a unit with only bare minimum user input. The user specifies which subnets to participate in the VPN. Everything else happens transparently to the user.

After registering devices with FortiCare, devices use SSL to register local subnets with the OCVPN cloud service at https://productapi.fortinet.com. The WAN IP is determined automatically (devices must use a publicly routed external WAN IP address) and the gateway IP address and participating subnets are uploaded to a cloud repository that collects and stores the information in each customer’s FortiCare account.

The following limitations apply to FortiOS OCVPN:

l The FortiGate must be registered with a valid FortiCare Support license. l Only full-mesh VPN configurations using PSK cryptography are supported. l Public IPs must be used (FortiGates behind NAT cannot participate). l Non-root VDOMs and FortiGate VMs are not supported. l Up to 16 nodes can be added to the OCVPN cloud, each with a maximum of 16 subnets.

OCVPN support for High Availability (HA)

As of 6.0.2, HA-enabled devices are now supported by OCVPN.

Prior to establishing the HA cluster, if OCVPN is in use then both devices should be registered to the

OCVPN cloud service. During failover, the old serial number is withdrawn and a new serial number (and VPN) is added, to account for the change in status.

Hub-and-spoke configurations

This section describes how to set up hub-and-spoke IPsec VPNs. The following topics are included in this section:

Configuration overview

Configure the hub

Configure the spokes

Dynamic spokes configuration example

Configuration overview

In a hub-and-spoke configuration, VPN connections radiate from a central FortiGate unit (the hub) to a number of remote peers (the spokes). Traffic can pass between private networks behind the hub and private networks behind the remote peers. Traffic can also pass between remote peer private networks through the hub.

Example hub-and-spoke configuration

The actual implementation varies in complexity depending on:

Configuration overview

l Whether the spokes are statically or dynamically addressed l The addressing scheme of the protected subnets l How peers are authenticated

This guide discusses the issues involved in configuring a hub-and-spoke VPN and provides some basic configuration examples.

Hub-and-spoke infrastructure requirements

• The FortiGate hub must be operating in NAT mode and have a static public IP address.
• Spokes may have static IP addresses, dynamic IP addresses (see FortiGate dialup-client configurations on page 137), or static domain names and dynamic IP addresses (see Dynamic DNS configuration on page 115).

Spoke gateway addressing

The public IP address of the spoke is the VPN remote gateway as seen from the hub. Statically addressed spokes each require a separate VPN Phase 1 configuration on the hub. When there are many spokes, this becomes rather cumbersome.

Using dynamic addressing for spokes simplifies the VPN configuration because then the hub requires only a single Phase 1 configuration with “dialup user” as the remote gateway. You can use this configuration even if the remote peers have static IP addresses. A remote peer can establish a VPN connection regardless of its IP address if its traffic selectors match and it can authenticate to the hub. See Configuration overview on page 94 for an example of this configuration.

Protected networks addressing

The addresses of the protected networks are needed to configure destination selectors and sometimes for security policies and static routes. The larger the number of spokes, the more addresses there are to manage. You can l Assign spoke subnets as part of a larger subnet, usually on a new network or

l Create address groups that contain all of the needed addresses

Using aggregated subnets

If you are creating a new network, where subnet IP addresses are not already assigned, you can simplify the VPN configuration by assigning spoke subnets that are part of a large subnet.

Aggregated subnets

All spokes use the large subnet address, 10.1.0.0/16 for example, as:

• The IPsec destination selector l The destination of the security policy from the private subnet to the VPN (required for policy-based VPN, optional for route-based VPN)
• The destination of the static route to the VPN (route-based)

Each spoke uses the address of its own protected subnet as the IPsec source selector and as the source address in its VPN security policy. The remote gateway is the public IP address of the hub FortiGate unit.

Using an address group

If you want to create a hub-and-spoke VPN between existing private networks, the subnet addressing usually does not fit the aggregated subnet model discussed earlier. All of the spokes and the hub will need to include the addresses of all the protected networks in their configuration.

On FortiGate units, you can define a named firewall address for each of the remote protected networks and add these addresses to a firewall address group. For a policy-based VPN, you can then use this address group as the destination of the VPN security policy.

For a route-based VPN, the destination of the VPN security policy can be set to All. You need to specify appropriate routes for each of the remote subnets.

Authentication

Authentication is by a common pre-shared key or by certificates. For simplicity, the examples in this chapter assume that all spokes use the same pre-shared key.

Configure the hub

At the FortiGate unit that acts as the hub, you need to:

hub

l Configure the VPN to each spoke l Configure communication between spokes

You configure communication between spokes differently for a policy-based VPN than for a route-based VPN. For a policy-based VPN, you configure a VPN concentrator. For a route-based VPN, you must either define security policies or group the IPsec interfaces into a zone.

Define the hub-spoke VPNs

Perform these steps at the FortiGate unit that will act as the hub. Although this procedure assumes that the spokes are all FortiGate units, a spoke could also be VPN client software, such as FortiClient Endpoint Security.

Configuring the VPN hub

1. At the hub, define the Phase 1 configuration for each spoke. See Phase 1 parameters on page 46. Enter these settings in particular:

Name	Enter a name to identify the VPN in Phase 2 configurations, security policies and the VPN monitor.
Remote Gateway	The remote gateway is the other end of the VPN tunnel. There are three options: Static IP Address — Enter the spoke’s public IP Address. You will need to create a Phase 1 configuration for each spoke. Either the hub or the spoke can establish the VPN connection. Dialup User — No additional information is needed. The hub accepts connections from peers with appropriate encryption and authentication settings. Only one Phase 1 configuration is needed for multiple dialup spokes. Only the spoke can establish the VPN tunnel. Dynamic DNS — If the spoke subscribes to a dynamic DNS service, enter the spoke’s Dynamic DNS domain name. Either the hub or the spoke can establish the VPN connection. For more information, see Dynamic DNS configuration on page 1.
Local Interface	Select the FortiGate interface that connects to the remote gateway. This is usually the FortiGate unit’s public interface.

2. Define the Phase 2 parameters needed to create a VPN tunnel with each spoke. See Phase 2 parameters on page 66. Enter these settings in particular:

Name	Enter a name to identify this spoke Phase 2 configuration.
Phase 1	Select the name of the Phase 1 configuration that you defined for this spoke.

IPsec VPN in ADVPN hub-and-spoke

IPsec VPN traffic is allowed through a tunnel between an ADVPN hub-and-spoke.

CLI syntax:

config vpn ipsec phase1-interface edit “int-fgtb” … set auto-discovery-sender [enable | disable] set auto-discovery-receiver [enable | disable] set auto-discovery-forwarder [enable | disable] …

next

end

config vpn ipsec phase2-interface edit “int-fgtb” …

set auto-discovery-sender phase1 [enable | disable] …

next

end

Define the hub-spoke security policies

1. Define a name for the address of the private network behind the hub. For more information, see Defining policy addresses on page 1.
2. Define names for the addresses or address ranges of the private networks behind the spokes. For more information, see Defining policy addresses on page 1.
3. Define the VPN concentrator. See To define the VPN concentrator on page 99.
4. Define security policies to permit communication between the hub and the spokes. For more information, see Defining VPN security policies on page 1.

Route-based VPN security policies

Define ACCEPT security policies to permit communications between the hub and the spoke. You need one policy for each direction.

Adding policies

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter these settings in particular:

Incoming Interface	Select the VPN Tunnel (IPsec Interface) you configured in Step 1.
Source Address	Select the address name you defined in Step 2 for the private network behind the spoke FortiGate unit.
Outgoing Interface	Select the hub’s interface to the internal (private) network.
Destination Address	Select the source address that you defined in Step 1.
Action	Select ACCEPT.
Enable NAT	Enable.

hub

Incoming Interface	Select the VPN Tunnel (IPsec Interface) you configured inStep 1.
Source Address	Select the address name you defined in Step 2 for the private network behind the spoke FortiGate units.
Outgoing Interface	Select the source address that you defined in Step 1.
Destination Address	Select the hub’s interface to the internal (private) network.
Action	Select ACCEPT.
Enable NAT	Enable.

Policy-based VPN security policy

Define an IPsec security policy to permit communications between the hub and the spoke.

Adding policies

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Incoming Interface	Select the hub’s interface to the internal (private) network.
Source Address	Select the source address that you defined in Step 1.
Outgoing Interface	Select the hub’s public network interface.
Destination Address	Select the address name you defined in Step 2 for the private network behind the spoke FortiGate unit.
VPN Tunnel	Select Use Existing and select the name of the Phase 1 configuration that you created for the spoke in Step 1. Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

In the policy list, arrange the policies in the following order:

l IPsec policies that control traffic between the hub and the spokes first l The default security policy last

Configuring communication between spokes (policy-based VPN)

For a policy-based hub-and-spoke VPN, you define a concentrator to enable communication between the spokes.

To define the VPN concentrator

1. At the hub, go to VPN > IPsec Concentrator and select Create New.
2. In the Concentrator Name field, type a name to identify the concentrator.
3. From the Available Tunnels list, select a VPN tunnel and then select the right-pointing arrow.
4. Repeat Step 3 until all of the tunnels associated with the spokes are included in the concentrator.
5. Select OK.

Configuring communication between spokes (route-based VPN)

For a route-based hub-and-spoke VPN, there are several ways you can enable communication between the spokes:

l Put all of the IPsec interfaces into a zone and enable intra-zone traffic. This eliminates the need for any security policy for the VPN, but you cannot apply UTM features to scan the traffic for security threats. l Put all of the IPsec interfaces into a zone and create a single zone-to-zone security policy l Create a security policy for each pair of spokes that are allowed to communicate with each other. The number of policies required increases rapidly as the number of spokes increases.

Using a zone as a concentrator

A simple way to provide communication among all of the spokes is to create a zone and allow intra-zone communication. You cannot apply UTM features using this method.

1. Go to Network > Interfaces.
2. Select the down-arrow on the Create New button and select Zone.
3. In the Zone Name field, enter a name, such as Our_VPN_zone.
4. Clear Block intra-zone traffic.
5. In the Interface Members list, select the IPsec interfaces that are part of your VPN.
6. Select OK.

Using a zone with a policy as a concentrator

If you put all of the hub IPsec interfaces involved in the VPN into a zone, you can enable communication among all of the spokes and apply UTM features with just one security policy.

Creating a zone for the VPN

1. Go to Network > Interfaces.
2. Select the down-arrow on the Create New button and select Zone.
3. In the Zone Name field, enter a name, such as Our_VPN_zone.
4. Select Block intra-zone traffic.
5. In the Interface Members list, select the IPsec interfaces that are part of your VPN.
6. Select OK.

Creating a security policy for the zone

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter the settings: and select OK.

Incoming Interface

Select the zone you created for your VPN.

spokes

Source Address	Select All.
Outgoing Interface	Select the zone you created for your VPN.
Destination Address	Select All.
Action	Select ACCEPT.
Enable NAT	Enable.

Using security policies as a concentrator

To enable communication between two spokes, you need to define an ACCEPT security policy for them. To allow either spoke to initiate communication, you must create a policy for each direction. This procedure describes a security policy for communication from Spoke 1 to Spoke 2. Others are similar.

1. Define names for the addresses or address ranges of the private networks behind each spoke. For more information, see Defining policy addresses on page 1.
2. Go to Policy & Objects > IPv4 Policy and select Create New.
3. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
4. Enter the settings and select OK.

Incoming Interface	Select the IPsec interface that connects to Spoke 1.
Source Address	Select the address of the private network behind Spoke 1.
Outgoing Interface	Select the IPsec interface that connects to Spoke 2.
Destination Address	Select the address of the private network behind Spoke 2.
Action	Select ACCEPT.
Enable NAT	Enable.

Configure the spokes

Although this procedure assumes that the spokes are all FortiGate units, a spoke could also be VPN client software, such as FortiClient Endpoint Security.

Perform these steps at each FortiGate unit that will act as a spoke.

Creating the Phase 1 and phase_2 configurations

1. At the spoke, define the Phase 1 parameters that the spoke will use to establish a secure connection with the hub.

See Phase 1 parameters on page 46. Enter these settings:

Remote Gateway	Select Static IP Address.
IP Address	Type the IP address of the interface that connects to the hub.

 

Configure the spokes

2. Create the Phase 2 tunnel definition. See Phase 2 parameters on page 66. Select the set of Phase 1 parameters that you defined for the hub. You can select the name of the hub from the Static IP Address part of the list.

Configuring security policies for hub-to-spoke communication

1. Create an address for this spoke. See Defining policy addresses on page 1. Enter the IP address and netmask of the private network behind the spoke.
2. Create an address to represent the hub. See Defining policy addresses on page 1. Enter the IP address and netmask of the private network behind the hub.
3. Define the security policy to enable communication with the hub.

Route-based VPN security policy

Define two security policies to permit communications to and from the hub.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter these settings:

Incoming Interface	Select the virtual IPsec interface you created.
Source Address	Select the hub address you defined in Step 1.
Outgoing Interface	Select the spoke’s interface to the internal (private) network.
Destination Address	Select the spoke addresses you defined in Step 2.
Action	Select ACCEPT.
Enable NAT	Enable
Incoming Interface	Select the spoke’s interface to the internal (private) network.
Source Address	Select the spoke address you defined in Step 1.
Outgoing Interface	Select the virtual IPsec interface you created.
Destination Address	Select the hub destination addresses you defined in Step 2.
Action	Select ACCEPT.
Enable NAT	Enable

Policy-based VPN security policy

Define an IPsec security policy to permit communications with the hub. See Defining VPN security policies on page 1.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

spokes

Incoming Interface	Select the spoke’s interface to the internal (private) network.
Source Address	Select the spoke address you defined in Step 1.
Outgoing Interface	Select the spoke’s interface to the external (public) network.
Destination Address	Select the hub address you defined in Step 2.
VPN Tunnel	Select Use Existing and select the name of the Phase 1 configuration you defined. Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

Configuring security policies for spoke-to-spoke communication

Each spoke requires security policies to enable communication with the other spokes. Instead of creating separate security policies for each spoke, you can create an address group that contains the addresses of the networks behind the other spokes. The security policy then applies to all of the spokes in the group.

1. Define destination addresses to represent the networks behind each of the other spokes. Add these addresses to an address group.
2. Define the security policy to enable communication between this spoke and the spokes in the address group you created.

Policy-based VPN security policy

Define an IPsec security policy to permit communications with the other spokes. See Defining VPN security policies on page 1. Enter these settings in particular:

Route-based VPN security policy

Define two security policies to permit communications to and from the other spokes.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter these settings in particular:

Incoming Interface	Select the virtual IPsec interface you created.
Source Address	Select the spoke address group you defined in Step “Configure the spokes ” on page 101.
Outgoing Interface	Select the spoke’s interface to the internal (private) network.
Destination Address	Select this spoke’s address name.
Action	Select ACCEPT.
Enable NAT	Enable

4. Select Create New, leave the Policy Type as Firewall and leave the Policy Subtype as Address, and enter these settings:

Incoming Interface	Select the spoke’s interface to the internal (private) network.
Source Address	Select this spoke’s address name.
Outgoing Interface	Select the virtual IPsec interface you created.
Destination Address	Select the spoke address group you defined in Step 1.
Action	Select ACCEPT.
Enable NAT	Enable

Policy-based VPN security policy

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following:

Incoming Interface	Select this spoke’s internal (private) network interface.
Source Address	Select this spoke’s source address.
Outgoing Interface	Select the spoke’s interface to the external (public) network.
Destination Address	Select the spoke address group you defined in Step 1.
VPN Tunnel	Select Use Existing and select the name of the Phase 1 configuration you defined. Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

Place this policy or policies in the policy list above any other policies having similar source and destination addresses.

Dynamic spokes configuration example

This example demonstrates how to set up a basic route-based hub-and-spoke IPsec VPN that uses preshared keys to authenticate VPN peers.

 

Example hub-and-spoke configuration

In the example configuration, the protected networks 10.1.0.0/24, 10.1.1.0/24 and 10.1.2.0/24 are all part of the larger subnet 10.1.0.0/16. The steps for setting up the example hub-and-spoke configuration create a VPN among Site 1, Site 2, and the HR Network.

The spokes are dialup. Their addresses are not part of the configuration on the hub, so only one spoke definition is required no matter the number of spokes. For simplicity, only two spokes are shown.

In an ADVPN topology, any two pair of peers can create a shortcut, as long as one of the devices is not behind NAT.

The on-the-wire format of the ADVPN messages use TLV encoding. Because of this, this feature is not compatible with any previous ADVPN builds.

Configure the hub (FortiGate_1)

The Phase 1 configuration defines the parameters that FortiGate_1 will use to authenticate spokes and establish secure connections.

For the purposes of this example, one preshared key will be used to authenticate all of the spokes. Each key must contain at least 6 printable characters and best practices dictates that it only be known by network administrators. For optimum protection against currently known attacks, each key must consist of a minimum of 16 randomly chosen alphanumeric characters.

Define the IPsec configuration

1. At FortiGate_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). Define the Phase 1 parameters that the hub will use to establish a secure connection to the spokes.

Name	Enter a name (for example, toSpokes).
Remote Gateway	Dialup user
Local Interface	External
Mode	Main
Authentication Method	Preshared Key
Pre-shared Key	Enter the preshared key.
Peer Options	Any peer ID

The basic Phase 2 settings associate IPsec Phase 2 parameters with the Phase 1 configuration and specify the remote end points of the VPN tunnels.

3. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
4. Enter the following information, and select OK:

Name	Enter a name for the Phase 2 definition (for example, toSpokes_ph2).
Phase 1	Select the Phase 1 configuration that you defined previously (for example, toSpokes).

Define the security policies

security policies control all IP traffic passing between a source address and a destination address. For a routebased VPN, the policies are simpler than for a policy-based VPN. Instead of an IPSEC policy, you use an ACCEPT policy with the virtual IPsec interface as the external interface.

Before you define security policies, you must first define firewall addresses to use in those policies. You need addresses for:

• The HR network behind FortiGate_1
• The aggregate subnet address for the protected networks

Defining the IP address of the HR network behind FortiGate_1

1. Go to Policy & Objects > Addresses.
2. Select Create New, enter the following information, and select OK:

Name	Enter an address name (for example, HR_Network).
Type	Subnet
Subnet/IP Range		Enter the IP address of the HR network behind FortiGate_1 (for example, 10.1.0.0/24).

Specifying the IP address the aggregate protected subnet

1. Go to Policy & Objects > Addresses.
2. Select Create New, enter the following information, and select OK:

Address Name	Enter an address name (for example, Spoke_net).
Type	Subnet
Subnet/IP Range	Enter the IP address of the aggregate protected network, 10.1.0.0/16

Defining the security policy for traffic from the hub to the spokes 1. Go to Policy & Objects > IPv4 Policy and select Create New,

2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter the following information, and select OK:

Incoming Interface	Select the interface to the HR network, port 1.
Source Address	Select HR_Network.
Outgoing Interface	Select the virtual IPsec interface that connects to the spokes, toSpokes.
Destination Address	Select Spoke_net.
Action	Select ACCEPT.

Place the policy in the policy list above any other policies having similar source and destination addresses.

Configure communication between spokes

Spokes communicate with each other through the hub. You need to configure the hub to allow this communication. An easy way to do this is to create a zone containing the virtual IPsec interfaces even if there is only one, and create a zone-to-zone security policy.

1. Go to Network > Interfaces.
2. Select the down-arrow on the Create New button and select Zone.
3. In the Zone Name field, enter a name, such as Our_VPN_zone.
4. Select Block intra-zone traffic.

You could enable intra-zone traffic and then you would not need to create a security policy. But, you would not be able to apply UTM features.

5. In Interface Members, select the virtual IPsec interface, toSpokes.
6. Select OK.

Creating a security policy for the zone

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter these settings:

Incoming Interface	Select Our_VPN_zone.
Source Address	Select All.
Outgoing Interface	Select Our_VPN_zone.
Destination Address	Select All.
Action	Select ACCEPT.
Enable NAT	Enable.

4. Select OK.

Configure the spokes

In this example, all spokes have nearly identical configuration, requiring the following:

• Phase 1 authentication parameters to initiate a connection with the hub. l Phase 2 tunnel creation parameters to establish a VPN tunnel with the hub.
• A source address that represents the network behind the spoke. This is the only part of the configuration that is different for each spoke.
• A destination address that represents the aggregate protected network. l A security policy to ena.ble communications between the spoke and the aggregate protected network

Define the IPsec configuration

At each spoke, create the following configuration.

1. At the spoke, 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). Enter the following information:

Name	Type a name, for example, toHub.
Remote Gateway	Select Static IP Address.
IP Address	Enter 172.16.10.1.
Local Interface	Select Port2.
Mode	Main
Authentication Method	Preshared Key
Pre-shared Key	Enter the preshared key. The value must be identical to the preshared key that you specified previously in the FortiGate_1 configuration
Peer Options	Select Any peer ID.

1. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
2. Enter the following information and select OK:

Name	Enter a name for the tunnel, for example, toHub_ph2.
Phase 1	Select the name of the Phase 1 configuration that you defined previously, for example, toHub.
Advanced	Select to show the following Quick Mode Selector settings.
Source	Enter the address of the protected network at this spoke. For spoke_1, this is 10.1.1.0/24. For spoke_2, this is 10.1.2.0/24.
Destination	Enter the aggregate protected subnet address, 10.1.0.0/16.

Define the security policies

You need to define firewall addresses for the spokes and the aggregate protected network and then create a security policy to enable communication between them.

Defining the IP address of the network behind the spoke

1. Go to Policy & Objects > Addresses.
2. Select Create New and enter the following information:

Address Name	Enter an address name, for example LocalNet.
Type	Subnet
Subnet/IP Range	Enter the IP address of the private network behind the spoke. For spoke_1, this is 10.1.1.0/24. For spoke_2, this is 10.1.2.0/24.

Specifying the IP address of the aggregate protected network

1. Go to Policy & Objects > Addresses.
2. Select Create New and enter the following information:

Address Name	Enter an address name, for example, Spoke_net.
Type	Subnet
Subnet/IP Range	Enter the IP address of the aggregate protected network, 10.1.0.0/16.

Defining the security policy

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter the following information:

Incoming Interface	Select the virtual IPsec interface, toHub.
Source Address	Select the aggregate protected network address Spoke_net.
Outgoing Interface	Select the interface to the internal (private) network, port1.
Destination Address	Select the address for this spoke’s protected network LocalNet.
Action	Select ACCEPT.

4. Select Create New.
5. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
6. Enter the following information, and select OK:

Incoming Interface	Select the interface to the internal private network, port1.
Source Address	Select the address for this spoke’s protected network, LocalNet.
Outgoing Interface	Select the virtual IPsec interface, toHub.
Destination Address	Select the aggregate protected network address, Spoke_net.
Action	Select ACCEPT.

Place these policies in the policy list above any other policies having similar source and destination addresses.

 

Gateway-to-gateway

This section explains how to set up a basic gateway-to-gateway (site-to-site) IPsec VPN.

The following topics are included in this section:

Configuration overview

Gateway-to-gateway configuration

How to work with overlapping subnets Testing

Configuration overview

In a gateway-to-gateway configuration, two FortiGate units create a VPN tunnel between two separate private networks. All traffic between the two networks is encrypted and protected by FortiGate security policies.

Example gateway-to-gateway configuration

In some cases, computers on the private network behind one VPN peer may (by co-incidence) have IP addresses that are already used by computers on the network behind the other VPN peer. In this type of situation

(ambiguous routing), conflicts may occur in one or both of the FortiGate routing tables and traffic destined for the remote network through the tunnel may not be sent. To resolve issues related to ambiguous routing, see Configuration overview on page 78.

Configuration overview

In other cases, computers on the private network behind one VPN peer may obtain IP addresses from a local DHCP server. However, unless the local and remote networks use different private network address spaces, unintended ambiguous routing and/or IP-address overlap issues may arise. For a discussion of the related issues, see FortiGate dialup-client configurations on page 1.

Configuration overview

You can set up a fully meshed or partially meshed configuration (see below).

Fully meshed configuration

In a fully meshed network, all VPN peers are connected to each other, with one hop between peers. This topology is the most fault-tolerant: if one peer goes down, the rest of the network is not affected. This topology is difficult to scale because it requires connections between all peers. In addition, unnecessary communication can occur between peers. Best practices dictates a hub-and-spoke configuration instead.

Partially meshed configuration

A partially meshed network is similar to a fully meshed network, but instead of having tunnels between all peers, tunnels are only configured between peers that communicate with each other regularly.

Defining VPN security policies

This section explains how to specify the source and destination IP addresses of traffic transmitted through an IPsec VPN, and how to define appropriate security policies.

The following topics are included in this section:

Defining policy addresses

Defining security policies for policy-based and route-based VPNs

Defining policy addresses

A VPN tunnel has two end points. These end points may be VPN peers such as two FortiGate gateways. Encrypted packets are transmitted between the end points. At each end of the VPN tunnel, a VPN peer intercepts encrypted packets, decrypts the packets, and forwards the decrypted IP packets to the intended destination.

You need to define firewall addresses for the private networks behind each peer. You will use these addresses as the source or destination address depending on the security policy.

policy addresses

Example topology for the following policies

In general:

• In a gateway-to-gateway, hub-and-spoke, dynamic DNS, redundant-tunnel, or transparent configuration, you need to define a policy address for the private IP address of the network behind the remote VPN peer (for example, 168.10.0/255.255.255.0 or 192.168.10.0/24).
• In a peer-to-peer configuration, you need to define a policy address for the private IP address of a server or host behind the remote VPN peer (for example, 16.5.1/255.255.255.255 or 172.16.5.1/32 or 172.16.5.1).

For a FortiGate dialup server in a dialup-client or Internet-browsing configuration:

• If you are not using VIP addresses, or if the FortiGate dialup server assigns VIP addresses to FortiClient dialup clients through FortiGate DHCP relay, select the predefined destination address “all” in the security policy to refer to the dialup clients.
• If you assign VIP addresses to FortiClient dialup clients manually, you need to define a policy address for the VIP address assigned to the dialup client (for example, 254.254.1/32), or a subnet address from which the VIP addresses are assigned (for example, 10.254.254.0/24 or 10.254.254.0/255.255.255.0).
• For a FortiGate dialup client in a dialup-client or Internet-browsing configuration, you need to define a policy address for the private IP address of a host, server, or network behind the FortiGate dialup server.

Defining a security IP address

1. Go to Policy & Objects > Addresses and select Create New.
2. In the Name field, type a descriptive name that represents the network, server(s), or host(s).
3. In Type, select Subnet.
4. In the Subnet/IP Range field, type the corresponding IP address and subnet mask.

For a subnet you could use the format 172.16.5.0/24 or its equivalent 172.16.5.0/255.255.255.0. For a server or host it would likely be 172.16.5.1/32. Alternately you can use an IP address range such as 192.168.10.[80-100] or 192.168.10.80-192.168.10.100.

5. Select OK.

Defining security policies for policy-based and route-based VPNs

Security policies allow IP traffic to pass between interfaces on a FortiGate unit. You can limit communication to particular traffic by specifying source address and destination addresses. Then only traffic from those addresses will be allowed.

Policy-based and route-based VPNs require different security policies.

• A policy-based VPN requires an IPsec security policy. You specify the interface to the private network, the interface to the remote peer and the VPN tunnel. A single policy can enable traffic inbound, outbound, or in both directions.
• A route-based VPN requires an Accept security policy for each direction. As source and destination interfaces, you specify the interface to the private network and the virtual IPsec interface (Phase 1 configuration) of the VPN. The IPsec interface is the destination interface for the outbound policy and the source interface for the inbound policy. One security policy must be configured for each direction of each VPN interface.

There are examples of security policies for both policy-based and route-based VPNs throughout this guide. See Route-based or policy-based VPN on page 117.

If the security policy, which grants the VPN Connection is limited to certain services,

DHCP must be included, otherwise the client won’t be able to retrieve a lease from the FortiGate’s (IPsec) DHCP server, because the DHCP Request (coming out of the tunnel) will be blocked.

Policy-based VPN

An IPsec security policy enables the transmission and reception of encrypted packets, specifies the permitted direction of VPN traffic, and selects the VPN tunnel. In most cases, a single policy is needed to control both inbound and outbound IP traffic through a VPN tunnel. Be aware of the following considerations below before creating an IPsec security policy.

Allow traffic to be initiated from the remote site

Security policies specify which IP addresses can initiate a tunnel. By default, traffic from the local private network initiates the tunnel. When the Allow traffic to be initiated form the remote site option is selected, traffic from a dialup client, or a computer on a remote network, initiates the tunnel. Both can be enabled at the same time for bi-directional initiation of the tunnel.

Outbound and inbound NAT

When a FortiGate unit operates in NAT mode, you can also enable inbound or outbound NAT. Outbound NAT may be performed on outbound encrypted packets or IP packets in order to change their source address before they are sent through the tunnel. Inbound NAT is performed to intercept and decrypt emerging IP packets from the tunnel.

By default, these options are not selected in security policies and can only be set through the CLI. For more information on this, see the “config firewall” chapter of the FortiGate CLI Reference.

Source and destination addresses

Most security policies control outbound IP traffic. A VPN outbound policy usually has a source address originating on the private network behind the local FortiGate unit, and a destination address belonging to a dialup VPN client or a network behind the remote VPN peer. The source address that you choose for the security policy identifies from where outbound cleartext IP packets may originate, and also defines the local IP address or addresses that a remote server or client will be allowed to access through the VPN tunnel. The destination address that you choose identifies where IP packets must be forwarded after they are decrypted at the far end of the tunnel, and determines the IP address or addresses that the local network will be able to access at the far end of the tunnel.

Enabling other policy features

You can fine-tune a policy for services such as HTTP, FTP, and POP3, enable logging, traffic shaping, antivirus protection, web filtering, email filtering, file transfer, email services, and optionally allow connections according to a predefined schedule.

As an option, differentiated services (diffserv or DSCP) for the security policy can be enabled through the CLI. For more information on this feature, see the Traffic Shaping handbook chapter, or the “firewall” chapter of the FortiGate CLI Reference.

Before you begin

Before you define the IPsec policy, you must:

l Define the IP source and destination addresses. See Defining policy addresses on page 72. l Specify the Phase 1 authentication parameters. See Phase 1 parameters on page 46. l Specify the Phase 2 parameters. See Phase 2 parameters on page 66.

Defining an IPsec security policy

1. Go to Policy & Objects > IPv4 Policy.
2. Select Create New and set the following options:

Name		Enter a name for the security policy.
Incoming Interface		Select the local interface to the internal (private) network.
Outgoing Interface		Select the local interface to the external (public) network.
Source		Select the name that corresponds to the local network, server(s), or host(s) from which IP packets may originate.

 

Destination Address	Select the name that corresponds to the remote network, server(s), or host (s) to which IP packets may be delivered.
Schedule	Keep the default setting (always) unless changes are needed to meet specific requirements.
Service	Keep the default setting (ANY) unless changes are needed to meet your specific requirements.
Action	For the purpose of this configuration, set Action to IPsec. Doing this will close Firewall / Network Options and open VPN Tunnel options. Select the VPN tunnel of your choice, and select Allow traffic to be initiated from the remote site, which will allow traffic from the remote network to initiate the tunnel.

3. You may enable UTM features, and/or event logging, or select advanced settings to authenticate a user group, or shape traffic. For more information, see the Firewall handbook chapter.
4. Select OK.
5. Place the policy in the policy list above any other policies having similar source and destination addresses.

Defining multiple IPsec policies for the same tunnel

You must define at least one IPsec policy for each VPN tunnel. If the same remote server or client requires access to more than one network behind a local FortiGate unit, the FortiGate unit must be configured with an IPsec policy for each network. Multiple policies may be required to configure redundant connections to a remote destination or control access to different services at different times.

To ensure a secure connection, the FortiGate unit must evaluate policies with Action set to IPsec before

ACCEPT and DENY. Because the FortiGate unit reads policies starting at the top of the list, you must move all IPsec policies to the top of the list, and be sure to reorder your multiple IPsec policies that apply to the tunnel so that specific constraints can be evaluated before general constraints.

Adding multiple IPsec policies for the same VPN tunnel can cause conflicts if the policies specify similar source and destination addresses, but have different settings for the same service. When policies overlap in this manner, the system may apply the wrong IPsec policy or the tunnel may fail.

For example, if you create two equivalent IPsec policies for two different tunnels, it does not matter which one comes first in the list of IPsec policies — the system will select the correct policy based on the specified source and destination addresses. If you create two different IPsec policies for the same tunnel (that is, the two policies treat traffic differently depending on the nature of the connection request), you might have to reorder the IPsec policies to ensure that the system selects the correct IPsec policy.

Route-based VPN

When you define a route-based VPN, you create a virtual IPsec interface on the physical interface that connects to the remote peer. You create ordinary Accept security policies to enable traffic between the IPsec interface and the interface that connects to the private network. This makes configuration simpler than for policy-based VPNs, which require IPsec security policies.

security policies for policy-based and route-based VPNs

Defining security policies for a route-based VPN

1. Go to Policy & Objects > IPv4 Policy.
2. Select Create New and define an ACCEPT security policy to permit communication between the local private network and the private network behind the remote peer. Enter these settings in particular:

Name	Enter a name for the security policy.
Incoming Interface	Select the interface that connects to the private network behind this FortiGate unit.
Outgoing Interface	Select the IPsec Interface you configured.
Source	Select the address name that you defined for the private network behind this FortiGate unit.
Destination Address	Select the address name that you defined for the private network behind the remote peer.
Action	Select ACCEPT.
NAT	Disable NAT.

To permit the remote client to initiate communication, you need to define a security policy for communication in that direction.

3. Select Create New and enter these settings in particular:

Name	Enter a name for the security policy.
Incoming Interface	Select the IPsec Interface you configured.
Outgoing Interface	Select the interface that connects to the private network behind this FortiGate unit.
Source	Select the address name that you defined for the private network behind the remote peer.
Destination Address	Select the address name that you defined for the private network behind this FortiGate unit.
Action	Select ACCEPT.
NAT	Disable NAT.

 

Phase 2 parameters

This section describes the Phase 2 parameters that are required to establish communication through a VPN.

The following topics are included in this section:

Phase 2 settings

Configuring the Phase 2 parameters

Phase 2 settings

After IPsec VPN Phase 1 negotiations complete successfully, Phase 2 negotiation begins. Phase 2 parameters define the algorithms that the FortiGate unit can use to encrypt and transfer data for the remainder of the session. The basic Phase 2 settings associate IPsec Phase 2 parameters with a Phase 1 configuration.

When defining Phase 2 parameters, you can choose any set of Phase 1 parameters to set up a secure connection and authenticate the remote peer.

For more information on Phase 2 settings in the web-based manager, see IPsec VPN in the web-based manager on page 32.

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

Phase 2 proposals

In Phase 2, the VPN peer or client and the FortiGate unit exchange keys again to establish a secure communication channel. The Phase 2 Proposal parameters select the encryption and authentication algorithms needed to generate keys for protecting the implementation details of Security Associations (SAs). The keys are generated automatically using a Diffie-Hellman algorithm.

Replay detection

IPsec tunnels can be vulnerable to replay attacks. Replay Detection enables the FortiGate unit to check all IPsec packets to see if they have been received before. If any encrypted packets arrive out of order, the FortiGate unit discards them.

IKE/IPsec Extended Sequence Number (ESN) support

64-bit Extended Sequence numbers (as described in RFC 4303, RFC 4304 as an addition to IKEv1, and RFC 5996 for IKEv2.) are supported for IPsec when Replay Detection is enabled.

Perfect Forward Secrecy (PFS)

By default, Phase 2 keys are derived from the session key created in Phase 1. Perfect Forward Secrecy (PFS) forces a new Diffie-Hellman exchange when the tunnel starts and whenever the Phase 2 keylife expires, causing a new key to be generated each time. This exchange ensures that the keys created in Phase 2 are unrelated to the Phase 1 keys or any other keys generated automatically in Phase 2.

Phase 2 settings

Keylife

The Keylife setting sets a limit on the length of time that a Phase 2 key can be used. The default units are seconds. Alternatively, you can set a limit on the number of kilobytes (KB) of processed data, or both. If you select both, the key expires when either the time has passed or the number of KB have been processed. When the Phase 2 key expires, a new key is generated without interrupting service.

Quick mode selectors

Quick mode selectors determine which IP addresses can perform IKE negotiations to establish a tunnel. By only allowing authorized IP addresses access to the VPN tunnel, the network is more secure.

The default settings are as broad as possible: any IP address or configured address object, using any protocol, on any port.

While the drop down menus for specifying an address also show address groups, the use of address groups may not be supported on a remote endpoint device that is not a FortiGate.

The address groups are at the bottom of the list to make it easy to distinguish between addresses and address groups.

When configuring Quick Mode selector Source address and Destination address, valid options include IPv4 and IPv6 single addresses, IPv4 subnet, or IPv6 subnet. For more information on IPv6 IPsec VPN, see Overview of IPv6 IPsec support on page 1.

There are some configurations that require specific selectors:

• The VPN peer is a third-party device that uses specific phase2 selectors.
• The FortiGate unit connects as a dialup client to another FortiGate unit, in which case (usually) you must specify a source IP address, IP address range, or subnet. However, this is not required if you are using dynamic routing and mode-cfg.

With FortiOS VPNs, your network has multiple layers of security, with quick mode selectors being an important line of defence.

• Routes guide traffic from one IP address to another.
• Phase 1 and Phase 2 connection settings ensure there is a valid remote end point for the VPN tunnel that agrees on the encryption and parameters.
• Quick mode selectors allow IKE negotiations only for allowed peers. l Security policies control which IP addresses can connect to the VPN. l Security policies also control what protocols are allowed over the VPN along with any bandwidth limiting.

FortiOS is limited with IKEv2 selector matching. When using IKEv2 with a named traffic selector, no more than 32 subnets per traffic selector are added, since FortiOS doesn’t fully implement the IKEv2 selector matching rules.

The workaround is to use multiple Phase 2s. If the configuration is FGT <-> FGT, then the better alternative is to just use 0.0.0.0 <-> 0.0.0.0 and use the firewall policy for enforcement.

 

Using the add-route option

Consider using the add-route option to add a route to a peer destination selector. Phase 2 includes the option of allowing the add-route to automatically match the settings in Phase 1. For more information, refer to Phase 1 parameters on page 46.

Syntax

Phase 2

config vpn ipsec {phase2 | phase2-interface} edit <name> set add-route {phase1 | enable | disable}

end

end

Configuring the Phase 2 parameters

If you are creating a hub-and-spoke configuration or an Internet-browsing configuration, you may have already started defining some of the required Phase 2 parameters. If so, edit the existing definition to complete the configuration.

Specifying the Phase 2 parameters

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Enter a Name for the Phase 2 configuration, and select a Phase 1 configuration from the drop-down list.
4. Select Advanced.
5. Include the appropriate entries as follows:

Phase 2 Proposal

Select the encryption and authentication algorithms that will be used to change data into encrypted code. 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. ChaCha20/Poly1305— A 128-bit block algorithm that uses a 128-bit key and a symmetric cipher. Only available for IKEv2.
Authentication	You can select either of the following message digests to check the authenticity 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 combination, use the Add button beside the fields for the second combination. For information regarding NP accelerated offloading of IPsec VPN authentication algorithms, please refer to the Hardware Acceleration handbook chapter.
Enable replay detection	Optionally enable or disable replay detection. Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel.
Enable perfect forward secrecy (PFS)	Enable or disable PFS. Perfect forward secrecy (PFS) improves security by forcing a new Diffie-Hellman exchange whenever keylife expires.
Diffie-Hellman Group	Select one Diffie-Hellman group (1, 2, 5, 14 through 21, or 27 through 30). The remote peer or dialup client must be configured to use the same group.
Keylife	Select the method for determining when the Phase 2 key expires: Seconds, KBytes, or Both. If you select Both, the key expires when either the time has passed or the number of KB have been processed. The range is from 120 to 172800 seconds, or from 5120 to 2147483648 KB.
Autokey Keep Alive	Enable the option if you want the tunnel to remain active when no data is being processed.
Auto-negotiate	Enable the option if you want the tunnel to be automatically renegotiated when the tunnel expires.

 

DHCP-IPsec

Select Enable if the FortiGate unit acts as a dialup server and FortiGate DHCP server or relay will be used to assign VIP addresses to FortiClient dialup clients. The DHCP server or relay parameters must be configured separately. If the FortiGate unit acts as a dialup server and the FortiClient dialup client VIP addresses match the network behind the dialup server, select Enable to cause the FortiGate unit to act as a proxy for the dialup clients. This is available only for Phase 2 configurations associated with a dialup Phase 1 configuration. It works only on policy-based VPNs.

Autokey Keep Alive

The Phase 2 SA has a fixed duration. If there is traffic on the VPN as the SA nears expiry, a new SA is negotiated and the VPN switches to the new SA without interruption. If there is no traffic, however, the SA expires (by default) and the VPN tunnel goes down. A new SA will not be generated until there is traffic.

The Autokey Keep Alive option ensures that a new Phase 2 SA is negotiated, even if there is no traffic, so that the VPN tunnel stays up.

Auto-negotiate

By default, the Phase 2 security association (SA) is not negotiated until a peer attempts to send data. The triggering packet and some subsequent packets are dropped until the SA is established. Applications normally resend this data, so there is no loss, but there might be a noticeable delay in response to the user.

If the tunnel goes down, the auto-negotiate feature (when enabled) attempts to re-establish the tunnel. Autonegotiate initiates the Phase 2 SA negotiation automatically, repeating every five seconds until the SA is established.

Automatically establishing the SA can be important for a dialup peer. It ensures that the VPN tunnel is available for peers at the server end to initiate traffic to the dialup peer. Otherwise, the VPN tunnel does not exist until the dialup peer initiates traffic.

The auto-negotiate feature is available through the Command Line Interface (CLI) via the following commands:

config vpn ipsec phase2 edit <phase2_name> set auto-negotiate enable

end

Installing dynamic selectors via auto-negotiate

The IPsec SA connect message generated is used to install dynamic selectors. These selectors can now be installed via the auto-negotiate mechanism. When phase 2 has auto-negotiate enabled, and phase 1 has meshselector-type set to subnet, a new dynamic selector will be installed for each combination of source and destination subnets. Each dynamic selector will inherit the auto-negotiate option from the template selector and begin SA negotiation. Phase 2 selector sources from dial-up clients will all establish SAs without traffic being initiated from the client subnets to the hub.

DHCP-IPsec

Select this option if the FortiGate unit assigns VIP addresses to FortiClient dialup clients through a DHCP server or relay. This option is available only if the Remote Gateway in the Phase 1 configuration is set to Dialup User and it works only on policy-based VPNs.

With the DHCP-IPsec option, the FortiGate dialup server acts as a proxy for FortiClient dialup clients that have VIP addresses on the subnet of the private network behind the FortiGate unit. In this case, the FortiGate dialup server acts as a proxy on the local private network for the FortiClient dialup client. A host on the network behind the dialup server issues an ARP request, corresponding to the device MAC address of the FortiClient host (when a remote server sends an ARP to the local FortiClient dialup client). The FortiGate unit then answers the ARP request on behalf of the FortiClient host, and forwards the associated traffic to the FortiClient host through the tunnel.

Acting as a proxy prevents the VIP address assigned to the FortiClient dialup client from causing possible ARP broadcast problems — the normal and VIP addresses can confuse some network switches by two addresses having the same MAC address.

IPsec support for ChaCha20/Poly1305 AEAD cipher

In IKEv2, to support RFC 7634, crypto algorithms ChaCha20 and Poly1305 can be used together as a combined mode AEAD cipher (like aes-gcm) in the new crypto_ftnt cipher in cipher_chacha20poly1305.c.

Syntax

config vpn ipsec phase2-interface edit <name> set phase1name <name> set proposal chacha20poly1305

next

end

IPsec support for AES-GCM for IKEv2 Phase 1

In IKEv2, to support RFC 5282, AEAD algorithm AES-GCM is now supported, both 128 and 256-bit variants.

Syntax

config vpn ipsec phase2-interface edit <name> set phase1name <name> set proposal [aes128gcm | aes256gcm]

next end

 

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.

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 l 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. l 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 32.

 

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:

l A static IP address l A domain name with a dynamic IP address l 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.

l In Main mode, the Phase 1 parameters are exchanged in multiple rounds with encrypted authentication information l 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 Choosing the IKE version

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.

IPsec VPN in the web-based manager

To configure an IPsec VPN, use the general procedure below. With these steps, your FortiGate unit will automatically generate unique IPsec encryption and authentication keys. If a remote VPN peer or client requires a specific IPsec encryption or authentication key, you must configure your FortiGate unit to use manual keys instead.

1. Define Phase 1 parameters to authenticate remote peers and clients for a secure connection. See IPsec VPN in the web-based manager on page 32.
2. Define Phase 2 parameters to create a VPN tunnel with a remote peer or dialup client. See IPsec VPN in the webbased manager on page 32.
3. Create a security policy to permit communication between your private network and the VPN. Policy-based VPNs have an action of IPSEC, where for interface-based VPNs the security policy action is ACCEPT. See Defining VPN security policies on page 1.

The FortiGate unit implements the Encapsulated Security Payload (ESP) protocol. Internet Key Exchange (IKE) is performed automatically based on pre-shared keys or X.509 digital certificates. Interface mode, supported in NAT mode only, creates a virtual interface for the local end of a VPN tunnel.

This chapter contains the following sections:

Phase 1 configuration

Phase 2 configuration

Concentrator

IPsec Monitor

Phase 1 configuration

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.

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

Name	Type a name for the Phase 1 definition. The maximum name length is 15 characters for an interface mode VPN, 35 characters for a policy-based VPN. If Remote Gateway is Dialup User, the maximum name length is further reduced depending on the number of dialup tunnels that can be established: by 2 for up to 9 tunnels, by 3 for up to 99 tunnels, 4 for up to 999 tunnels, and so on. For a tunnel mode VPN, the name normally reflects where the remote connection originates. For a route-based tunnel, the FortiGate unit also uses the name for the virtual IPsec interface that it creates automatically.
Remote Gateway	Select the category of the remote connection: Static IP Address — If the remote peer has a static IP address. Dialup User — If one or more FortiClient or FortiGate dialup clients with dynamic IP addresses will connect to the FortiGate unit. Dynamic DNS — If a remote peer that has a domain name and subscribes to a dynamic DNS service will connect to the FortiGate unit.
IP Address	If you selected Static IP Address, enter the IP address of the remote peer.
Dynamic DNS	If you selected Dynamic DNS, enter the domain name of the remote peer.
Local Interface	This option is available in NAT mode only. Select the name of the interface through which remote peers or dialup clients connect to the FortiGate unit. By default, the local VPN gateway IP address is the IP address of the interface that you selected.
Mode	Main mode — the Phase 1 parameters are exchanged in multiple rounds with encrypted authentication information. Aggressive mode — the Phase 1 parameters are exchanged in single message with authentication information that is not encrypted. 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 phase1 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.
Authentication Method	Select Preshared Key or RSA Signature.

 

Pre-shared Key	If you selected Pre-shared Key, enter the pre-shared 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 key at the remote peer or client. The key must contain at least 6 printable characters. For optimum protection against currently known attacks, the key must consist of a minimum of 16 randomly chosen alphanumeric characters. The limit is 128 characters.
Certificate Name	If you selected RSA Signature, 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 negotiations. For information about obtaining and loading the required server certificate, see the FortiOS User Authentication guide.
Peer Options	Peer options are available to authenticate VPN peers or clients, depending on the Remote Gateway and Authentication Method settings.
Any peer ID	Accept the local ID of any remote VPN peer or client. The FortiGate unit does not check identifiers (local IDs). You can set Mode to Aggressive or Main. You can use this option with RSA Signature authentication. But, for highest security, configure a PKI user/group for the peer and set Peer Options to Accept this peer certificate only.
This peer ID	This option is available when Aggressive Mode is enabled. Enter the identifier that is used to authenticate the remote peer. This identifier must match the Local ID that the remote peer’s administrator has configured. If the remote peer is a FortiGate unit, the identifier is specified in the Local ID field of the Advanced Phase 1 configuration. If the remote peer is a FortiClient user, the identifier is specified in the Local ID field, accessed by selecting Config in the Policy section of the VPN connection’s Advanced Settings. In circumstances where multiple remote dialup VPN tunnels exist, each tunnel must have a peer ID set.
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 preshared keys only, you can set Mode to Main if there is only one dialup Phase 1 configuration for this interface IP address.

Phase 1 advanced configuration settings

You can use the following advanced parameters to select the encryption and authentication algorithms that the FortiGate unit uses to generate keys for the IKE exchange. You can also use the following advanced parameters to ensure the smooth operation of Phase 1 negotiations.

These settings are mainly configured in the CLI, although some options are available after the tunnel is created using the VPN Creation Wizard (using the Convert to Custom Tunnel option).

If the FortiGate unit 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.

Note that, since FortiOS 5.4, an exact match is required to optimize IKE’s gateway search utilizing binary trees. However, it is also possible to have partial matching of ‘user.peer:cn’ to match peers to gateways by performing a secondary match. When IKE receives IDi of type ASN1.DN, the first search is done with the whole DN string. If none is found, IKE will extract just the CN attribute value and perform a second search.

VXLAN over IPsec

Packets with VXLAN header are encapsulated within IPsec tunnel mode. To configure VXLAN over IPsec – CLI: 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	You can 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 – CLI: config vpn ipsec phase1-interface edit p1 set idle-timeout [enable | disable] set idle-timeoutinterval <integer> //IPsec tunnel idle timeout in minutes (10 – 43200). end end
IPv6 Version	Select if you want to use IPv6 addresses for the remote gateway and interface IP addresses.
Local Gateway IP	Specify an IP address for the local end of the VPN tunnel. Select one of the following: Main Interface IP — The FortiGate unit obtains the IP address of the interface from the network interface settings. Specify — Enter a secondary address of the interface selected in the Phase 1 Local Interface field. You cannot configure Interface mode in a transparent mode VDOM.
Phase 1 Proposal	Select the encryption and authentication algorithms used to generate keys for protecting negotiations and add encryption and authentication algorithms as required. You need to select a minimum of one and a maximum of three combinations. The remote peer or client must be configured to use at least one of the proposals that you define. Select one of the following symmetric-key encryption algorithms: 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. ChaCha20/Poly1305— A 128-bit block algorithm that uses a 128-bit key and a symmetric cipher. Only available for IKEv2.

 

	You can select either of the following message digests to check the authenticity of messages during an encrypted session: 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 combination, use the Add button beside the fields for the second combination.
Diffie-Hellman Group	Select one or more Diffie-Hellman groups from DH groups 1, 2, 5, and 14 through 21. At least one of the Diffie-Hellman Group settings on the remote peer or client must match one the selections on the FortiGate unit. Failure to match one or more DH groups will result in failed negotiations.
Keylife	Enter 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	If the FortiGate unit will act as a VPN client and you are using peer IDs for authentication purposes, enter the identifier that the FortiGate unit will supply to the VPN server during the Phase 1 exchange. If the FortiGate unit 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 unit will use for authentication purposes. If the FortiGate unit is a dialup client and will not be sharing a tunnel with other dialup clients (that is, the tunnel will be dedicated to this Fortinet dialup client), set Mode to Aggressive. Note that this Local ID value must match the peer ID value given for the remote VPN peer’s Peer Options.

 

XAuth	This option supports the authentication of dialup clients. It is available for IKE v1 only. Disable — Select if you do not use XAuth. Enable as Client — If the FortiGate unit is a dialup client, enter the user name and password that the FortiGate unit will need to authenticate itself to the remote XAuth server. Enable as Server — This is available only if Remote Gateway is set to Dialup User. Dialup clients authenticate as members of a dialup user group. You must first create a user group for the dialup clients that need access to the network behind the FortiGate unit. You must also configure the FortiGate unit to forward authentication requests to an external RADIUS or LDAP authentication server. Select a Server Type setting to determine the type of encryption method to use between the FortiGate unit, the XAuth client and the external authentication server, and then select the user group from the User Group list.
Username	Enter the user name that is used for authentication.
Password	Enter the password that is used for authentication.
NAT Traversal	Select the check box 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 client must have the same NAT traversal setting (both selected or both cleared) to connect reliably. 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.
Keepalive Frequency	If you enabled NAT-traversal, enter a keepalive frequency setting.
Dead Peer Detection	Select this check box to reestablish VPN tunnels on idle connections and clean up dead IKE peers if required. You can use this option to receive notification 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. With Dead Peer Detection selected, you can use the config vpn ipsec phase1 (tunnel mode) or config vpn ipsec phase1- interface (interface mode) CLI command to optionally specify a retry count and a retry interval.

IPsec VPN overview

This section provides a brief overview of IPsec technology and includes general information about how to configure IPsec VPNs using this guide.

The following topics are included in this section:

Types of VPNs

Planning your VPN

General preparation steps

How to use this guide to configure an IPsec VPN

VPN configurations interact with the firewall component of the FortiGate unit. There must be a security policy in place to permit traffic to pass between the private network and the VPN tunnel.

Security policies for VPNs specify:

• The FortiGate interface that provides the physical connection to the remote VPN gateway, usually an interface connected to the Internet
• The FortiGate interface that connects to the private network l IP addresses associated with data that has to be encrypted and decrypted l Optionally, a schedule that restricts when the VPN can operate l Optionally, the services (types of data) that can be sent

When the first packet of data that meets all of the conditions of the security policy arrives at the FortiGate unit, a VPN tunnel may be initiated and the encryption or decryption of data is performed automatically afterward. For more information, see Defining VPN security policies on page 1.

Where possible, you should create route-based VPNs. Generally, route-based VPNs are more flexible and easier to configure than policy-based VPNs — by default they are treated as interfaces. However, these two VPN types have different requirements that limit where they can be used.

Types of VPNs

FortiGate unit VPNs can be policy-based or route-based. There is little difference between the two types. In both cases, you specify Phase 1 and Phase 2 settings. However there is a difference in implementation. A route-based VPN creates a virtual IPsec network interface that applies encryption or decryption as needed to any traffic that it carries. That is why route-based VPNs are also known as interface-based VPNs. A policy-based VPN is implemented through a special security policy that applies the encryption you specified in the Phase 1 and Phase 2 settings.

Route-based VPNs

For a route-based VPN, you create two security policies between the virtual IPsec interface and the interface that connects to the private network. In one policy, the virtual interface is the source. In the other policy, the virtual interface is the destination. This creates bidirectional policies that ensure traffic will flow in both directions over the VPN.

A route-based VPN is also known as an interface-based VPN.

Each route-based IPsec VPN tunnel requires a virtual IPsec interface. As such, the amount of possible route-based IPsec VPNs is limited by the system.interface table size. The system.interface table size for most devices is 8192.

For a complete list of table sizes for all devices, refer to the Maximum Values table.

Policy-based VPNs

For a policy-based VPN, one security policy enables communication in both directions. You enable inbound and outbound traffic as needed within that policy, or create multiple policies of this type to handle different types of traffic differently. For example HTTPS traffic may not require the same level of scanning as FTP traffic.

A policy-based VPN is also known as a tunnel-mode VPN.

Comparing policy-based or route-based VPNs

For both VPN types you create Phase 1 and Phase 2 configurations. Both types are handled in the stateful inspection security layer, assuming there is no IPS or AV. For more information on the three security layers, see the FortiOS Troubleshooting guide.

The main difference is in the security policy.

You create a policy-based VPN by defining an IPSEC security policy between two network interfaces and associating it with the VPN tunnel (Phase 1) configuration.

You create a route-based VPN by creating a virtual IPsec interface. You then define a regular ACCEPT security policy to permit traffic to flow between the virtual IPsec interface and another network interface. And lastly, configure a static route to allow traffic over the VPN.

Where possible, you should create route-based VPNs. Generally, route-based VPNs are more flexible and easier to configure than policy-based VPNs — by default they are treated as interfaces. However, these two VPN types have different requirements that limit where they can be used.

Comparison of policy-based and route-based VPNs

Features	Policy-based	Route-based
Both NAT and transparent modes available	Yes	NAT mode only
L2TP-over-IPsec supported	Yes	Yes
GRE-over-IPsec supported	No	Yes
security policy requirements	Requires a security policy with IPSEC action that specifies the VPN tunnel	Requires only a simple security policy with ACCEPT action
Number of policies per VPN	One policy controls connections in both directions	A separate policy is required for connections in each direction