VRRP

A Virtual Router Redundancy Protocol (VRRP) configuration can be used as a high availability solution to make sure that a network maintains connectivity with the Internet (or with other networks) even if the default router for the network fails. Using VRRP, if a router or a FortiGate unit fails all traffic to this router transparently fails over to another router or FortiGate unit that takes over the role of the router or FortiGate unit that failed. If the failed router or FortiGate unit is restored, it will once again take over processing traffic for the network. VRRP is described by RFC 3768.

Example VRRP configuration

To configure VRRP you create a VRRP group that contains two or more routers. Some or all of these routers can be FortiGate units. You can include different FortiGate models in the same VRRP group. The group members are configured to be the master router and one or more backup routers of the VRRP group. The network directs all traffic to the master’s IP address and MAC address. If the master fails, VRRP dynamically shifts packet forwarding to a backup router. VRRP provides this redundancy without user intervention or additional configuration to any of the devices on the network.

The VRRP redundancy scheme means that devices on the network keep a single IP address for the default gateway and this IP address maps to a well-known virtual MAC address. If the VRRP master fails, one of the backup units becomes the new master and acquires virtual IP and MAC addresses that match the addresses of the master. The network then automatically directs all traffic to the backup unit. VRRP uses the broadcast capabilities of Ethernet networks. A long as one of the routers in a VRRP group is running, ARP requests for the default gateway IP address always receive replies. Additionally, hosts can send packets outside their subnet without interruption.

FortiGate units support VRRP and can be quickly and easily integrated into a network that has already deployed a group of routers using VRRP. You can also create a new VRRP configuration consisting of a FortiGate unit acting as a VRRP master with one or more VRRP-compatible routers acting as backup routers. Some or all of those backup routers can be FortiGate units.

During normal operation the VRRP master unit sends VRRP advertisement messages to the backup units. A backup unit will not attempt to become a master unit while it is receiving these messages. When a FortiGate unit operating as a VRRP master fails, a backup unit takes its place and continues processing network traffic. The backup unit assumes the master unit has failed if it stops receiving the advertisement messages from the master unit. The backup unit with the highest priority becomes the new master unit after a short delay. During this delay the new master unit sends gratuitous ARPs to the network to map the virtual router IP address it its MAC address. As a result, all packets sent to the default route IP address are sent the new master unit. If the backup unit is a FortiGate unit, the network continues to benefit from FortiOS security features. If the backup unit is a router, after a failure traffic will continue to flow, but FortiOS security features will be unavailable until the FortiGate unit is back on line.

During a VRRP failover, as the backup unit starts to forward traffic it will not have session information for all of the failed over in-progress sessions. If the backup unit is operating as a normal FortiGate unit it will not be able to forward this traffic because of the lack of session information. To resolve this problem, immediately after a failover and for a short time as its taking over traffic processing, the backup unit operates with asymmetric routing enabled. This allows the backup unit to re-create all of the in-progress sessions and add them to the session table. While operating with asymmetric routing enabled, the backup unit cannot apply security functions. When the start-time ends the backup unit disables asymmetric routing and returns to normal operation including applying security functions.

Adding a VRRP virtual router to a FortiGate interface

Use the following command to add a VRRP virtual router to the port10 interface of a FortiGate unit. This VRRP virtual router has a virtual router ID of 200, uses IP address 10.31.101.200 and has a priority of 255. Since this is the highest priority this interface is configured to be the master of the VRRP group with ID number 200.

VRRP can be configured only on physical interfaces or VLAN interfaces. You cannot configure VRRP on hardware-switch interfaces where multiple physical interfaces are combined into a hardware switch interface.

config system interface edit port10

config vrrp edit 200

set vrip 10.31.101.200 set priority 255

end

end

VRRP virtual MAC address

The VRRP virtual MAC address (or virtual router MAC address) is a shared MAC address adopted by the VRRP master. If the master fails the same virtual MAC master fails over to the new master. As a result, all packets for VRRP routers can continue to use the same virtual MAC address. You must enable the VRRP virtual MAC address feature on all members of a VRRP group.

Each VRRP router is associated with its own virtual MAC address. The last part of the virtual MAC depends on the VRRP virtual router ID using the following format:

00-00-5E-00-01-<VRID_hex>

Where <VRID_hex> is the VRRP virtual router ID in hexadecimal format in internet standard bit-order. For more information about the format of the virtual MAC see RFC 3768.

Some examples:

• If the VRRP virtual router ID is 10 the virtual MAC would be 00-00-5E-00-01-0a.
• If the VRRP virtual router ID is 200 the virtual MAC would be 00-00-5E-00-01-c8.

The VRRP virtual MAC address feature is disabled by default. Wen you enable the feature on a FortiGate interface, all of the VRRP routers added to that interface use their own VRRP virtual MAC address. Each virtual MAC address will be different because each virtual router has its own ID.

Use the following command to enable the VRRP virtual MAC address on the port2 interface:

config system interface edit port2

set vrrp-virtual-mac enable end

end

The port2 interface will now accept packets sent to the MAC addresses of the VRRP virtual routers added to this interface.

Using the VRRP virtual MAC address can improve network efficiency especially on large and complex LANs because when a failover occurs devices on the LAN do not have to learn a new MAC address for the new VRRP router.

If the VRRP virtual MAC address feature is disabled, the VRRP group uses the MAC address of the master. In the case of a FortiGate VRRP virtual router this is the MAC address of the FortiGate interface that the VRRP virtual routers are added to. If a master fails, when the new master takes over it sends gratuitous ARPs to associate the VRRP virtual router IP address with the MAC address of the new master (or the interface of the FortiGate unit that has become the new master). If the VRRP virtual MAC address is enabled the new master uses the same MAC address as the old master.

VRRP Groups

A VRRP group includes all the relevant VRRP IDs and tracks the VRRP status to force the status of all group members if a VRRP domain is changed from master to backup. VRRP groups are configured through the CLI. The VRRP group ID can be between 1 and 65535. Use the following command to add a VRRP group to the port20 interface that includes the virtual route identifiers 25, 50, 66 and 70 to VRRP group 10

config system interface edit port20

config vrrp edit 25

set vrgrp 10 next

edit 50

set vrgrp 10 next

end

edit 66

set vrgrp 10v next

edit 70

set vrgrp 10

Using a Second Destination IP (VRDST)

VRRP can now be configured with second destination IP (VRDST) for monitoring. When two IPs are used, VRRP failure will only be reported if both monitored IPs are down.

Use the following command to configure a second destination IP (VRDST) to port14:

config system interface edit port14

config vrrp edit 12

set vrdst 10.10.10.20 10.20.20.10

end

Configuring VRRP

To configure VRRP you must configure two or more FortiGate interfaces or routers with the same virtual router ID and IP address. Then these FortiGate units or routers can automatically join the same VRRP group. You must also assign priorities to each of the FortiGate units or routers in the VRRP group. One of the FortiGate units or routers must have the highest priority to become the master. The other FortiGate units or routers in the group are assigned lower priorities and become backup units. All of the units in the VRRP group should have different priorities. If the master unit fails, VRRP automatically fails over to the remaining unit in the group with the highest priority.

You configure VRRP from the FortiGate CLI by adding a VRRP virtual router to a FortiGate interface. You can add VRRP virtual routers to multiple FortiGate interfaces and you can add more than one virtual router to the same interface.

Example VRRP configuration: two FortiGate units in a VRRP group

This example includes a VRRP group consisting of two FortiGate units that connect an internal network to the Internet. As shown below, the internal network’s default route is 10.31.101.120.

The FortiGate port2 interfaces connect to the internal network. A VRRP virtual router is added to each FortiGate unit’s port2 interface. The virtual router IP address is 10.31.101.120 (the internal network’s default route) and the virtual router’s ID is 5. The VRRP priority of the master unit is set to 255 and the VRRP priority of the backup unit is 50. The port2 interface of each FortiGate unit should have an IP address that is different from the virtual router IP address and the port2 interface IP addresses should be different from each other.

This example also includes enabling the VRRP virtual MAC address on both FortiGate unit port2 interfaces so that the VRRP group uses the VRRP virtual MAC address.

Example VRRP configuration with two FortiGate units

To configure the FortiGate units for VRRP

1. Select one of the FortiGate units to be the VRRP master and the other to be the backup unit.

2. From the master unit’s CLI, enter the following command to enable the VRRP virtual MAC address on the port2 interface and add the VRRP virtual router to the port2 interface:

config system interface edit port2

set vrrp-virtual-mac enable config vrrp

edit 5

set vrip 10.31.101.120 set priority 255

end

end

3. From the backup unit’s CLI, enter the following command to enable the VRRP virtual MAC address on the port2 interface and add the VRRP virtual router to the port2 interface:

config system interface edit port2

set vrrp-virtual-mac enable config vrrp

edit 5

set vrip 10.31.101.120 set priority 50

end

end

Example VRRP configuration: VRRP load balancing two FortiGate units and two VRRP groups

In this configuration two VRRP groups are involved. Each FortiGate unit participates in both of them. One FortiGate unit is the master of one group and the other FortiGate unit is the master of the other group. The network distributes traffic between two different default routes (10.31.101.120 and 10.31.101.130). One VRRP group is configured with one of the default route IP addresses and the other VRRP group get the other default route IP address. So during normal operation both FortiGate units are processing traffic and the VRRP groups are used to load balance the traffic between the two FortiGate units.

If one of the FortiGate units fails, the remaining FortiGate unit becomes the master of both VRRP groups. The network sends all traffic for both default routes to this FortiGate unit. The result is a configuration that under normal operation load balances traffic between two FortiGate units, but if one of the FortiGate units fails, all traffic fails over to the unit that is still operating.

This example also includes enabling the VRRP virtual MAC address on both FortiGate unit port2 interfaces so that the VRRP groups use their VRRP virtual MAC addresses.

Example VRRP configuration with two FortiGate units and two VRRP groups

To configure the FortiGate units

1. 1. Log into the CLI of FortiGate unit A.
2. 2. Enter the following command to enable the VRRP virtual MAC address feature and add the VRRP groups to the port2 interface of FortiGate unit A:

config system interface

edit port2

set vrrp-virtual-mac enable config vrrp

edit 50 (32)

set vrip 10.31.101.120 set priority 255

next

edit 100 (64)

set vrip 10.31.101.130 set priority 50

end

end

3. 3. Log into the CLI of FortiGate unit B.
4. 4. Enter the following command to enable the VRRP virtual MAC address feature and add the VRRP groups to the port2 interface of FortiGate unit B:

config system interface edit port2

set vrrp-virtual-mac enable config vrrp

edit 50

set vrip 10.31.101.120 set priority 50

next

edit 100

set vrip 10.31.101.130 set priority 255

end

end

Optional VRRP configuration settings

In addition to the basic configuration settings, you can change to the VRRP configuration to:

• Adjust the virtual router advertisement message interval between 1 and 255 seconds using the adv-interval option.
• Adjust the startup time using the start-time option. The default start time is 3 seconds and the range is 1 to 255 seconds. The start time is the maximum time that the backup unit waits between receiving advertisement messages from the master unit. If the backup unit does not receive an advertisement message during this time it assumes the master has failed and becomes the new master unit. In some cases the advertisement messages may be delayed. For example, some switches with spanning tree enabled may delay some of the advertisement message packets. If you find that backup units are attempting to become master units without the master unit failing, you can extend the start time to make sure the backup units wait long enough for the advertisement messages.
• Enable or disable individual virtual router configurations using the status option. Normally virtual router configurations are enabled but you can temporarily disable one if its not required.
• Enable or disable preempt mode using the preempt option. In preempt mode a higher priority backup unit can preempt a lower priority master unit. This can happen if a master has failed, a backup unit has become the master unit, and the failed master is restarted. Since the restarted unit will have a higher priority, if preempt mode is enabled the restarted unit will replace the current master unit. Preempt mode is enabled by default.
• Monitor the route to a destination IP address using the vrdst option.

FortiGate Session Life Support Protocol (FGSP)

In a network that already includes load balancing (either with load balancers or routers) for traffic redundancy, two identical FortiGate units can be integrated into the load balancing configuration using the FortiGate Session Life Support Protocol (FGSP). The external load balancers or routers can distribute sessions among the FortiGate units and the FGSP performs session synchronization of IPv4 and IPv6 TCP, UDP, ICMP, expectation, and NAT sessions and IPsec tunnels to keep the session tables of both FortiGate units synchronized.

You can use the config system cluster-sync command to configure the FortiGate Session Life Support Protocol (FGSP) (previously called TCP session synchronization or standalone session synchronization) between two FortiGate units. The two FortiGate units must be the same model. The FGSP synchronizes both IPv4 and IPv6 TCP, UDP, ICMP, expectation, and NAT sessions and IPsec tunnels. You can use this feature with external routers or load balancers configured to distribute or load balance sessions between two peer FortiGate units. If one of the peers fails, session failover occurs and active sessions fail over to the peer that is still operating. This failover occurs without any loss of data. As well, the external routers or load balancers will detect the failover and re-distribute all sessions to the peer that is still operating.

In previous versions of FortiOS the FGSP was called TCP session synchronization or standalone session synchronization. However, the FGSP has been expanded to include configuration synchronization and session synchronization of connectionless sessions, expectation sessions, and NAT sessions and IPsec tunnels.

You cannot configure FGSP HA when FGCP HA is enabled. However FGSP HA is com- patible with VRRP.

FGSP or standalone session synchronization is not supported if the FortiGate units are running different firmware versions.

The FGSP can be used instead of FGCP HA to provide session synchronization between two peer FortiGate units. If the external load balancers direct all sessions to one peer the affect is similar to active-passive FGCP HA. If external load balancers or routers load balance traffic to both peers, the effect is similar to active-active FGCP HA. The load balancers should be configured so that all of the packets for any given session are processed by the same peer. This includes return packets.

FGSP HA

By default, FGSP synchronizes all IPv4 and IPv6 TCP sessions, IPsec tunnels, and also synchronizes the configuration of the FortiGate units.

You can optionally enable session pickup to synchronize connectionless (UDP and ICMP) sessions, expectation sessions, and NAT sessions. If you do not enable session pickup, the FGSP does not share session tables for the particular session type and sessions do not resume after a failover. All sessions that are interrupted by the failover and must be re-established at the application level. Many protocols can successfully restart sessions with little, or no, loss of data. Others may not recover easily. Enable session pickup for sessions that may be difficult to reestablish. Since session pickup requires FortiGate resources, only enable this feature for sessions that you need to have synchronized.

You can also optionally add filters to control which sessions are synchronized. You can add filters to only synchronize packets from specified source and destination addresses, specified source and destination interfaces, and specified services.

Load balancing and session failover is done by external routers or load balancers instead of by the FGSP. The FortiGate units just perform session synchronization to support session failover.

Synchronizing the configuration

The FGSP also includes configuration synchronization, allowing you to make configuration changes once for both FortiGate units instead of requiring you to make duplicate configuration changes on each FortiGate unit. Settings that identify the FortiGate unit to the network, for example, interface IP addresses and BGP neighbor settings, are not synchronized so each FortiGate unit maintains its identity on the network.

By default configuration synchronization is disabled. You can use the following command to enable it.

config system ha

set standalone-config-sync enable end

IPsec tunnel synchronization

When you use the config system cluster-sync command to enable FGSP, IPsec keys and other runtime data (but not actual tunnel sessions) are synchronized between cluster units . This means that if one of the cluster units goes down the cluster unit that is still operating can quickly get IPsec tunnels re-established without re-negotiating them. However, after a failover all existing tunnel sessions on the failed FortiGate have to be restarted on the still operating FortiGate.

IPsec tunnel sync only supports dialup IPsec. The interfaces on both FortiGates that are tunnel endpoints must have the same IP addresses and external routers must be configured to load balance IPsec tunnel sessions to the FortiGates in the cluster.

Synchronizing UDP and ICMP (connectionless) sessions

In many configurations, due to their non-stateful nature, UDP and ICMP sessions don’t need to be synchronized to naturally failover. However, if its required you can configure the FGSP to synchronize UDP and ICMP sessions by entering the following command:

config system ha

set session-pickup enable

set session-pickup-connectionless enable end

Synchronizing NAT sessions

By default, NAT session are not synchronized. However, the FGSP can synchronize NAT session if you enter the following command:

config system ha

set session-pickup enable

set session-pickup-nat enable end

However, if you want NAT sessions to resume after a failover you should not configure NAT to use the destination interface IP address since the FGSP FortiGate units have different IP addresses. With this configuration, after a failover all sessions that include the IP addresses of interfaces on the failed FortiGate unit will have nowhere to go since the IP addresses of the failed FortiGate unit will no longer be on the network.

Instead, in an FGSP configuration, if you want NAT sessions to failover you should use IP pools with the type set to overload (which is the default IP pool type). For example:

config firewall ippool edit FGSP-pool

set type overload

set startip 172.20.120.10 set endip 172.20.120.20

end

Then when you configure NAT firewall policies, turn on NAT and select to use dynamic IP pool and select the IP Pool that you added. Add the same IP pools and firewall policies to both FortiGate units.

Synchronizing expectation (asymmetric) sessions

By default, expectation sessions (or asymmetric sessions) are not synchronized. Normally, session synchronization cannot be asymmetric because it is stateful. So all of the packets of a given session must be processed on the same peer. This includes return packets.

However, if you have an asymmetric routing configuration, you can enter the following command to synchronize asymmetric sessions by dynamically detecting asymmetric sessions and disabling anti-reply for these sessions.

config system ha

set session-pickup enable

set session-pickup-expectation enable end

The FGSP enforces firewall policies for asymmetric traffic, including cases where the TCP 3-way handshake is split between two FortiGates. For example, FGT-A receives the TCP-SYN, FGT-B receives the TCP-SYN-ACK, and FGT-A receives the TCP-ACK. Under normal conditions a firewall will drop this connection since the 3-way handshake was not seen by the same firewall. However two FortiGates with FGSP configured will be able to properly pass this traffic since the firewall sessions are synchronized.

If traffic will be highly asymmetric, as described above, the following command must be enabled on both FortiGates.

config system ha

set session-pickup enable

set session-pickup-expectation enable end

This asymmetric function can also work with connectionless UDP and ICMP traffic. The following command needs to enabled on both FortiGates.

config system ha

set session-pickup enable

set session-pickup-connectionless enable end

Synchronizing asymmetric traffic can be very useful in situations where multiple Internet connections from different ISPs are spread across two FortiGates. Since it is typically not possible to guarantee Internet bound traffic leaving via an ISP will return using the exact same ISP, the FGSP provides critical firewall functions in this situation.

The FGSP also has applications in virtualized computing environments where virtualized hosts move between data centers. The firewall session synchronization features of FGSP allow for more flexibility than in traditional firewalling functions.

Security profile flow-based inspection and asymmetric traffic

Security profile inspection (flow or proxy based) for a session is not expected to work properly if the traffic in the session is balanced across more than one FortiGate in either direction. Flow-based inspection should be used in FGSP deployments.

For an environment where traffic is symmetric, security profile inspection can be used with the following limitations:

• No session synchronization for the sessions inspected using proxy-based inspection. Sessions will drop and need to be reestablished after data path failover.
• Sessions with flow-based inspection will failover; however, inspection of failed over sessions after the failover may not work.

A single FortiGate must see both the request and reply traffic for security profile inspection to function correctly. For environments where asymmetric traffic is expected, security profile inspection should not be used.

Notes and limitations

FGSP HA has the following limitations:

• The FGSP is a global configuration option. As a result you can only add one service to a filter configuration. You cannot add custom services or service groups even if virtual domains are not enabled.
• You can only add one filter configuration to a given FGSP configuration. However, you can add multiple filters by adding multiple identical FGSP configurations, each one with a different filter configuration.
• Sessions accepted by security policies with security profiles configured are not synchronized.
• FGSP HA is configured from the CLI.
• FGSP HA is available for FortiGate units or virtual domains operating in NAT/Route or Transparent mode. NAT sessions are not synchronized in either mode (unless NAT synchronization is enabled as described in Synchronizing NAT sessions on page 1581). In NAT/Route mode, only sessions for route mode security policies are synchronized. In Transparent mode, only sessions for normal Transparent mode policies are synchronized.
• FGSP HA is supported for traffic on physical interfaces, VLAN interfaces, zones, aggregate interfaces, and NPx (NP4, NP6 etc.) accelerated interfaces. The FGSP has not been tested for inter-vdom links, between HA clusters, and for redundant interfaces.
• The names of the matching interfaces, including VLAN interfaces, aggregate interfaces and so on, must be the same on both peers.

Configuring FGSP HA

You configure FGSP HA separately for each virtual domain to be synchronized. If virtual domain configuration is not enabled, you configure FGSP HA for the root virtual domain. When virtual domain configuration is enabled and you have added virtual domains you configure FGSP HA for each virtual domain to be synchronized. You don’t have to synchronize all virtual domains.

You must configure FGSP HA and network settings on both peers. Once you establish the initial configuration, the configurations of both FortiGate units are synchronized so when you change the configuration of one, the changes are synchronized to the other.

On each FortiGate unit, configuring FGSP HA consists of selecting the virtual domains to be synchronized using the syncvd field, selecting the virtual domain on the other peer that receives the synchronization packets using the peervd field, and setting the IP address of the interface in the peer unit that receives the synchronization packets using the peerip field. The interface with the peerip must be in the peervd virtual domain.

The syncvd and peervd settings must be the same on both peers. However, the peerip settings will be different because the peerip setting on the first peer includes the IP address of an interface on the second peer. And the peerip setting on the second peer includes the IP address of an interface on the first peer.

For FGSP HA to work properly all synchronized virtual domains must be added to both peers. The names of the matching interfaces in each virtual domain must also be the same; this includes the names of matching VLAN interfaces. Note that the index numbers of the matching interfaces and VLAN interfaces can be different. Also the VLAN IDs of the matching VLAN interfaces can be different.

Configuring the session synchronization link

When FGSP HA is operating, the peers share session information over an Ethernet link between the peers similar to an HA heartbeat link. Usually you would use the same interface on each peer for session synchronization. You should connect the session synchronization interfaces directly without using a switch or other networking equipment. For FortiGate-5000 systems you can use a backplane interface as the session synchronization link.

You can use different interfaces on each peer for session synchronization links. Also, if you have multiple sessions synchronization configurations, you can have multiple links between the peers. In fact if you are synchronizing a lot of sessions, you may want to configure and connect multiple session synchronization links to distribute session synchronization traffic to these multiple links.

You cannot configure backup session synchronization links. Each configuration only includes one session synchronization link.

The session synchronization link should always be maintained. If session synchronization communication is interrupted and a failure occurs, sessions will not failover and data could be lost.

Session synchronization traffic can use a considerable amount of network bandwidth. If possible, session synchronization link interfaces should only be used for session synchronization traffic and not for data traffic.

Basic example configuration

The following configuration example shows how to configure basic FGSP HA for the two peer FortiGate units shown below. The host names of peers are peer_1 and peer_2. Both peers are configured with two virtual domains: root and vdom_1. All sessions processed by vdom_1 are synchronized. The synchronization link interface is port3 which is in the root virtual domain. The IP address of port3 on peer_1 is 10.10.10.1. The IP address of port3 on peer_2 is 10.10.10.2.

Also on both peers, port1 and port2 are added to vdom_1. On peer_1 the IP address of port1 is set to 192.168.20.1 and the IP address of port2 is set to 172.110.20.1. On peer_2 the IP address of port1 is set to 192.168.20.2 and the IP address of port2 is set to 172.110.20.2.

Example FGSP HA network configuration

To configure FGSP HA

1. Configure the load balancer or router to send all sessions to peer_1.

2. Configure the load balancer or router to send all traffic to peer_2 if peer_1 fails.

3. Use normal FortiGate configuration steps on peer_1:

• Enable virtual domain configuration.
• Add the vdom_1 virtual domain.
• Add port1 and port2 to the vdom_1 virtual domain and configure these interfaces.
• Set the IP address of port1 to 192.168.20.1. l  Set the IP address of port2 to 172.110.20.1. l  Set the IP address of port3 to 10.10.10.1.
• Add route mode security policies between port1 and port2 to vdom_1.

4. Enter the following commands to configure session synchronization for peer_1

config system cluster-sync edit 1

set peerip 10.10.10.2 set peervd root

set syncvd vdom_1

end

5. Use normal FortiGate configuration steps on peer_2:

• Enable virtual domain configuration.
• Add the vdom_1 virtual domain.
• Add port1 and port2 to the vdom_1 virtual domain and configure these interfaces.
• Set the IP address of port1 to 192.168.20.2. l  Set the IP address of port2 to 172.110.20.2. l  Set the IP address of port3 to 10.10.10.1.
• Add route mode security policies between port1 and port2 to vdom_1.

6. Enter the following command to configure session synchronization for peer_1

config system cluster-sync edit 1

set peerip 10.10.10.1 set peervd root

set syncvd vdom_1

end

Now that the FortiGate units are connected and configured their configurations are synchronized, so when you make a configuration change on one FortiGate unit it is synchronized to the other one.

To add filters

You can add a filter to this basic configuration if you only want to synchronize some TCP sessions. For example you can enter the following command to add a filter so that only HTTP sessions are synchronized:

config system cluster-sync edit 1

config filter

set service HTTP

end

end

You can also add a filter to control the source and destination addresses of the IPv4 packets that are synchronized. For example you can enter the following command to add a filter so that only sessions with source addresses in the range 10.10.10.100 to 10.10.10.200 are synchronized.

config system cluster-sync edit 1

config filter

set srcaddr 10.10.10.100 10.10.10.200 end

end

You can also add a filter to control the source and destination addresses of the IPv6 packets that are synchronized. For example you can enter the following command to add a filter so that only sessions with destination addresses in the range 2001:db8:0:2::/64 are synchronized.

config system cluster-sync edit 1

config filter

set dstaddr6 2001:db8:0:2::/64 end

end

To synchronize UDP and ICMP sessions

You enter the following command to add synchronization of UDP and ICMP sessions to this configuration:

config system ha

set session-pickup enable

set session-pickup-connectionless enable end

To synchronize the configuration

Enter the following command to enable configuration synchronization.

config system ha

set standalone-config-sync enable end

Verifying FGSP configuration and synchronization

You can use the following diagnose commands to verify that the FGSP and its synchronization functions are operating correctly.

FGSP configuration summary and status

Enter the following command to display a summary of the FGSP configuration and synchronization status:

diagnose sys session sync

sync_ctx: sync_started=1, sync_tcp=1, sync_others=1, sync_expectation=1, sync_redir=0, sync_nat=1, stdalone_sessync=0. sync: create=12:0, update=0, delete=0:0, query=14

recv: create=14:0, update=0, delete=0:0, query=12

ses pkts: send=0, alloc_fail=0, recv=0, recv_err=0 sz_err=0 nCfg_sess_sync_num=5, mtu=16000

sync_filter:

1: vd=0, szone=0, dzone=0, saddr=0.0.0.0:0.0.0.0, daddr=0.0.0.0:0.0.0.0,

sync_started=1 shows that synchronization is working. If this is set to 0 then something is not correct with session synchronization and synchronization has not been able to start because of it.

sync_tcp=1, sync_others=1, sync_expectation=1, and sync_nat=1 show that the FGSP has been configured to synchronize TCP, connectionless, asymmetric, and NAT sessions.

sync: create=12:0 and recv: create=14:0 show that this FortiGate has synchronized 12 sessions to its peer and has received 14 sessions from its peer.

sync_filter shows the configured FGSP filter. In this case no filter has been created so all sessions are synchronized.

vd=0 indicates that root VDOM sessions are synchronized.

Verifying that sessions are synchronized

Enter the command diagnose sys session list to display information about the sessions being processed by the FortiGate. In the command output look for sessions that should be synchronized and make sure they contain output lines that include synced for example, state=log may_dirty ndr synced) to confirm that they are being synchronized by the FGSP.

diagnose sys session list

session info: proto=6 proto_state=05 duration=469 expire=0 timeout=3600 flags=00000000 sockflag=00000000 sockport=21 av_idx=0 use=4

origin-shaper= reply-shaper= per_ip_shaper=

ha_id=0 policy_dir=0 tunnel=/

state=log may_dirty ndr synced

statistic(bytes/packets/allow_err): org=544/9/1 reply=621/7/0 tuples=2 orgin->sink: org pre->post, reply pre->post dev=46->45/45->46 gwy=10.2.2.1/10.1.1.1

hook=pre dir=org act=noop 192.168.1.50:45327->172.16.1.100:21(0.0.0.0:0) hook=post dir=reply act=noop 172.16.1.100:21->192.168.1.50:45327(0.0.0.0:0) pos/(before,after) 0/(0,0), 0/(0,0)

misc=0 policy_id=1 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0 serial=00002deb tos=ff/ff ips_view=1 app_list=2000 app=16427 dd_type=0 dd_mode=0

per_ip_bandwidth meter: addr=192.168.1.50, bps=633

Chapter 14 – IPsec VPN

This FortiOS Handbook chapter contains the following sections:

IPsec VPN concepts explains the basic concepts that you need to understand about virtual private networks (VPNs).

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

IPsec VPN in the web-based manager describes the IPsec VPN menu of the web-based manager interface. Gateway-to-gateway configurations explains how to set up a basic gateway-to-gateway (site-to-site) IPsec VPN.

In a gateway-to-gateway configuration, two FortiGate units create a VPN tunnel between two separate private networks.

Hub-and-spoke configurations describes how to set up hub-and-spoke IPsec VPNs. In a hub-and-spoke configuration, connections to a number of remote peers and/or clients radiate from a single, central FortiGate hub.

Dynamic DNS configuration describes how to configure a site-to-site VPN, in which one FortiGate unit has a static IP address and the other FortiGate unit has a dynamic IP address and a domain name.

FortiClient dialup-client configurations guides you through configuring a FortiClient dialup-client IPsec VPN. In a FortiClient dialup-client configuration, the FortiGate unit acts as a dialup server and VPN client functionality is provided by the FortiClient Endpoint Security application installed on a remote host.

FortiGate dialup-client configurations explains how to set up a FortiGate dialup-client IPsec VPN. In a FortiGate dialup-client configuration, a FortiGate unit with a static IP address acts as a dialup server and a FortiGate unit with a dynamic IP address initiates a VPN tunnel with the FortiGate dialup server.

Supporting IKE Mode config clients explains how to set up a FortiGate unit as either an IKE Mode Config server or client. IKE Mode Config is an alternative to DHCP over IPsec.

Internet-browsing configuration explains how to support secure web browsing performed by dialup VPN clients, and hosts behind a remote VPN peer. Remote users can access the private network behind the local FortiGate unit and browse the Internet securely. All traffic generated remotely is subject to the security policy that controls traffic on the private network behind the local FortiGate unit.

Redundant VPN configurations discusses the options for supporting redundant and partially redundant tunnels in an IPsec VPN configuration. A FortiGate unit can be configured to support redundant tunnels to the same remote peer if the FortiGate unit has more than one interface to the Internet.

Transparent mode VPNs describes two FortiGate units that create a VPN tunnel between two separate private networks transparently. In transparent mode, all FortiGate unit interfaces except the management interface are invisible at the network layer.

IPv6 IPsec VPNs describes FortiGate unit VPN capabilities for networks based on IPv6 addressing. This includes IPv4-over-IPv6 and IPv6-over-IPv4 tunnelling configurations. IPv6 IPsec VPNs are available in FortiOS 3.0 MR5 and later.

L2TP and IPsec (Microsoft VPN) explains how to support Microsoft Windows native VPN clients.

GRE over IPsec (Cisco VPN) explains how to interoperate with Cisco VPNs that use Generic Routing Encapsulation (GRE) protocol with IPsec.

Protecting OSPF with IPsec provides an example of protecting OSPF links with IPsec.

Redundant OSPF routing over IPsec provides an example of redundant secure communication between two remote networks using an OSPF VPN connection.

OSPF over dynamic IPsec provides an example of how to create a dynamic IPsec VPN tunnel that allows OSPF. BGP over dynamic IPsec provides an example of how to create a dynamic IPsec VPN tunnel that allows BGP. Phase 1 parameters provides detailed step-by-step procedures for configuring a FortiGate unit to accept a connection from a remote peer or dialup client. The basic Phase 1 parameters identify the remote peer or clients

and support authentication through preshared keys or digital certificates. You can increase VPN connection security further using methods such as extended  uthentication (XAuth).

Phase 2 parameters provides detailed step-by-step procedures for configuring an IPsec VPN tunnel. During Phase 2, the specific IPsec security associations needed to implement security services are selected and a tunnel is established.

Defining VPN security policies explains how to specify the source and destination IP addresses of traffic transmitted through an IPsec VPN tunnel, and how to define a security encryption policy. Security policies control all IP traffic passing between a source address and a destination address.

Logging and monitoring and Troubleshooting provide VPN monitoring and troubleshooting procedures.

IPsec VPN concepts

Virtual Private Network (VPN) technology enables remote users to connect to private computer networks to gain access to their resources in a secure way. For example, an employee traveling or working from home can use a VPN to securely access the office network through the Internet.

Instead of remotely logging on to a private network using an unencrypted and unsecure Internet connection, the use of a VPN ensures that unauthorized parties cannot access the office network and cannot intercept any of the information that is exchanged between the employee and the office. It is also common to use a VPN to connect the private networks of two or more offices.

Fortinet offers VPN capabilities in the FortiGate Unified Threat Management (UTM) appliance and in the FortiClient Endpoint Security suite of applications. A FortiGate unit can be installed on a private network, and FortiClient software can be installed on the user’s computer. It is also possible to use a FortiGate unit to connect to the private network instead of using FortiClient software.

This chapter discusses VPN terms and concepts including: VPN tunnels

VPN gateways

Clients, servers, and peers

Encryption

Authentication

Phase 1 and Phase 2 settings

Security Association

IKE and IPsec packet processing

VPN tunnels

The data path between a user’s computer and a private network through a VPN is referred to as a tunnel. Like a physical tunnel, the data path is accessible only at both ends. In the telecommuting scenario, the tunnel runs between the FortiClient application on the user’s PC, or a FortiGate unit or other network device and the FortiGate unit on the office private network.

Encapsulation makes this possible. IPsec packets pass from one end of the tunnel to the other and contain data packets that are exchanged between the local user and the remote private network. Encryption of the data packets ensures that any third-party who intercepts the IPsec packets can not access the data.

Encoded data going through a VPN tunnel

You can create a VPN tunnel between:

• A PC equipped with the FortiClient application and a FortiGate unit
• Two FortiGate units
• Third-party VPN software and a FortiGate unit

For more information on third-party VPN software, refer to the Fortinet Knowledge Base for more information.

Tunnel templates

Several tunnel templates are available in the IPsec VPN Wizard that cover a variety of different types of IPsec VPN. A list of these templates appear on the first page of the Wizard, located at VPN > IPsec Wizard. The tunnel template list follows.

IPsec VPN Wizard options

VPN Type                Remote Device Type               NAT Options                   Description

Site to Site                FortiGate                                    l No NAT between sites

• This site is behind NAT
• The remote site is behind NAT

Static tunnel between this FortiGate and a remote FortiGate.

Cisco

• No NAT between sites
• This site is behind NAT
• The remote site is behind NAT

Static tunnel between this FortiGate and a remote Cisco firewall.

VPN tunnel list

Once you create an IPsec VPN tunnel, it appears in the VPN tunnel list at VPN > IPsec Tunnels. By default, the tunnel list indicates the name of the tunnel, its interface binding, the tunnel template used, and the tunnel status. If you right-click on the table header row, you can include columns for comments, IKE version, mode (aggressive vs main), phase 2 proposals, and reference number. The tunnel list page also includes the option to create a new tunnel, as well as the options to edit or delete a highlighted tunnel.

VPN gateways

A gateway is a router that connects the local network to other networks. The default gateway setting in your computer’s TCP/IP properties specifies the gateway for your local network.

A VPN gateway functions as one end of a VPN tunnel. It receives incoming IPsec packets, decrypts the encapsulated data packets and passes the data packets to the local network. Also, it encrypts data packets destined for the other end of the VPN tunnel, encapsulates them, and sends the IPsec packets to the other VPN gateway. The VPN gateway is a FortiGate unit because the private network behind it is protected, ensuring the security of the unencrypted VPN data. The gateway can also be FortiClient software running on a PC since the unencrypted data is secure on the PC.

The IP address of a VPN gateway is usually the IP address of the network interface that connects to the Internet. Optionally, you can define a secondary IP address for the interface and use that address as the local VPN gateway address. The benefit of doing this is that your existing setup is not affected by the VPN settings.

The following diagram shows a VPN connection between two private networks with FortiGate units acting as the VPN gateways. This configuration is commonly referred to as Gateway-to-Gateway IPsec VPN.

VPN tunnel between two private networks

Although the IPsec traffic may actually pass through many Internet routers, you can visualize the VPN tunnel as a simple secure connection between the two FortiGate units.

Users on the two private networks do not need to be aware of the VPN tunnel. The applications on their computers generate packets with the appropriate source and destination addresses, as they normally do. The FortiGate units manage all the details of encrypting, encapsulating, and sending the packets to the remote VPN gateway.

The data is encapsulated in IPsec packets only in the VPN tunnel between the two VPN gateways. Between the user’s computer and the gateway, the data is on the secure private network and it is in regular IP packets.

For example User1 on the Site A network, at IP address 10.10.1.7, sends packets with destination IP address 192.168.10.8, the address of User2 on the Site B network. The Site A FortiGate unit is configured to send packets with destinations on the 192.168.10.0 network through the VPN, encrypted and encapsulated. Similarly, the Site B FortiGate unit is configured to send packets with destinations on the 10.10.1.0 network through the VPN tunnel to the Site A VPN gateway.

In the site-to-site, or gateway-to-gateway VPN shown below, the FortiGate units have static (fixed) IP addresses and either unit can initiate communication.

You can also create a VPN tunnel between an individual PC running FortiClient and a FortiGate unit, as shown below. This is commonly referred to as Client-to-Gateway IPsec VPN.

VPN tunnel between a FortiClient PC and a FortiGate unit

On the PC, the FortiClient application acts as the local VPN gateway. Packets destined for the office network are encrypted, encapsulated into IPsec packets, and sent through the VPN tunnel to the FortiGate unit. Packets for other destinations are routed to the Internet as usual. IPsec packets arriving through the tunnel are decrypted to recover the original IP packets.

Clients, servers, and peers

A FortiGate unit in a VPN can have one of the following roles:

• Server — responds to a request to establish a VPN tunnel.
• Client — contacts a remote VPN gateway and requests a VPN tunnel.
• Peer — brings up a VPN tunnel or responds to a request to do so.

The site-to-site VPN shown above is a peer-to-peer relationship. Either FortiGate unit VPN gateway can establish the tunnel and initiate communications. The FortiClient-to-FortiGate VPN shown below is a client-server relationship. The FortiGate unit establishes a tunnel when the FortiClient PC requests one.

A FortiGate unit cannot be a VPN server if it has a dynamically-assigned IP address. VPN clients need to be configured with a static IP address for the server. A FortiGate unit acts as a server only when the remote VPN gateway has a dynamic IP address or is a client-only device or application, such as FortiClient.

As a VPN server, a FortiGate unit can also offer automatic configuration for FortiClient PCs. The user needs to know only the IP address of the FortiGate VPN server and a valid user name/password. FortiClient downloads the VPN configuration settings from the FortiGate VPN server. For information about configuring a FortiGate unit as a VPN server, see the FortiClient Administration Guide.

Encryption

Encryption mathematically transforms data to appear as meaningless random numbers. The original data is called plaintext and the encrypted data is called ciphertext. The opposite process, called decryption, performs the inverse operation to recover the original plaintext from the ciphertext.

The process by which the plaintext is transformed to ciphertext and back again is called an algorithm. All algorithms use a small piece of information, a key, in the arithmetic process of converted plaintext to ciphertext, or vice-versa. IPsec uses symmetrical algorithms, in which the same key is used to both encrypt and decrypt the data. The security of an encryption algorithm is determined by the length of the key that it uses. FortiGate IPsec VPNs offer the following encryption algorithms, in descending order of security:

AES–GCM                                Galois/Counter Mode (GCM), a block cipher mode of operation providing both confidentiality and data origin authentication.

AES256                                       A 128-bit block algorithm that uses a 256-bit key.

AES192                                       A 128-bit block algorithm that uses a 192-bit key.

AES128                                       A 128-bit block algorithm that uses a 128-bit key.

3DES                                           Triple-DES, in which plain text is DES-encrypted three times by three keys.

DES                                             Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key

The default encryption algorithms provided on FortiGate units make recovery of encrypted data almost impossible without the proper encryption keys.

There is a human factor in the security of encryption. The key must be kept secret, known only to the sender and receiver of the messages. Also, the key must not be something that unauthorized parties might easily guess, such as the sender’s name, birthday or simple sequence such as 123456.

IPsec overheads

The FortiGate sets an IPsec tunnel Maximum Transmission Unit (MTU) of 1436 for 3DES/SHA1 and an MTU of 1412 for AES128/SHA1, as seen with diag vpn tunnel list. This indicates that the FortiGate allocates 64 bytes of overhead for 3DES/SHA1 and 88 bytes for AES128/SHA1, which is the difference if you subtract this MTU from a typical ethernet MTU of 1500 bytes.

During the encryption process, AES/DES operates using a specific size of data which is block size. If data is smaller than that, it will be padded for the operation. MD5/SHA-1 HMAC also operates using a specific block size.

The following table describes the potential maximum overhead for each IPsec encryption:

IPsec Transform Set                                                                 IPsec Overhead (Max. bytes)

ESP–AES (256, 192, or 128),ESP-SHA-HMAC, or MD5               73

ESP–AES (256, 192, or 128)                                                           61

Authentication

To protect data via encryption, a VPN must ensure that only authorized users can access the private network. You must use either a preshared key on both VPN gateways or RSA X.509 security certificates. The examples in this guide use only preshared key authentication. Refer to the Fortinet Knowledge Base for articles on RSA X.509 security certificates.

Preshared keys

A preshared key contains at least six random alphanumeric characters. Users of the VPN must obtain the preshared key from the person who manages the VPN server and add the preshared key to their VPN client configuration.

Although it looks like a password, the preshared key, also known as a shared secret, is never sent by either gateway. The preshared key is used in the calculations at each end that generate the encryption keys. As soon as the VPN peers attempt to exchange encrypted data, preshared keys that do not match will cause the process to fail.

Additional authentication

To increase security, you can require additional means of authentication from users, such as:

• An identifier, called a peer ID or a local ID.
• Extended authentication (XAUTH) which imposes an additional user name/password requirement.

A Local ID is an alphanumeric value assigned in the Phase 1 configuration. The Local ID of a peer is called a Peer ID.

In FortiOS 5.2, new authentication methods have been implemented for IKE: ECDSA-256, ECDSA-384, and ECDSA-521. However, AES-XCBC is not supported.

Phase 1 and Phase 2 settings

A VPN tunnel is established in two phases: Phase 1 and Phase 2. Several parameters determine how this is done. Except for IP addresses, the settings simply need to match at both VPN gateways. There are defaults that are appropriate for most cases.

FortiClient distinguishes between Phase 1 and Phase 2 only in the VPN Advanced settings and uses different terms. Phase 1 is called the IKE Policy. Phase 2 is called the IPsec Policy.

Phase 1

In Phase 1, the two VPN gateways exchange information about the encryption algorithms that they support and then establish a temporary secure connection to exchange authentication information.

When you configure your FortiGate unit or FortiClient application, you must specify the following settings for Phase 1:

Remote gateway                        The remote VPN gateway’s address.

FortiGate units also have the option of operating only as a server by select- ing the “Dialup User” option.

Preshared key                           This must be the same at both ends. It is used to encrypt Phase 1 authen- tication information.

Local interface                          The network interface that connects to the other VPN gateway. This applies on a FortiGate unit only.

All other Phase 1 settings have default values. These settings mainly configure the types of encryption to be used. The default settings on FortiGate units and in the FortiClient application are compatible. The examples in this guide use these defaults.

For more detailed information about Phase 1 settings, see Phase 1 parameters on page 1624.

Phase 2

Similar to the Phase 1 process, the two VPN gateways exchange information about the encryption algorithms that they support for Phase 2. You may choose different encryption for Phase 1 and Phase 2. If both gateways have at least one encryption algorithm in common, a VPN tunnel can be established. Keep in mind that more algorithms each phase does not share with the other gateway, the longer negotiations will take. In extreme cases this may cause timeouts during negotiations.

To configure default Phase 2 settings on a FortiGate unit, you need only select the name of the corresponding Phase 1 configuration. In FortiClient, no action is required to enable default Phase 2 settings. For more detailed information about Phase 2 settings, see Phase 2 parameters on page 1642.

Security Association

The establishment of a Security Association (SA) is the successful outcome of Phase 1 negotiations. Each peer maintains a database of information about VPN connections. The information in each SA can include cryptographic algorithms and keys, keylife, and the current packet sequence number. This information is kept synchronized as the VPN operates. Each SA has a Security Parameter Index (SPI) that is provided to the remote peer at the time the SA is established. Subsequent IPsec packets from the peer always reference the relevant SPI. It is possible for peers to have multiple VPNs active simultaneously, and correspondingly multiple SPIs.

IKE and IPsec packet processing

Internet Key Exchange (IKE) is the protocol used to set up SAs in IPsec negotiation. As described in Phase 1 parameters on page 1624, you can optionally choose IKEv2 over IKEv1 if you configure a route-based IPsec VPN. IKEv2 simplifies the negotiation process, in that it:

• Provides no choice of Aggressive or Main mode in Phase 1.
• Does not support Peer Options or Local ID.
• Does not allow Extended Authentication (XAUTH).
• Allows you to select only one Diffie-Hellman Group.
• Uses less bandwidth.

The following sections identify how IKE versions 1 and 2 operate and differentiate.

IKEv1

Phase 1

A peer, identifed in the IPsec policy configuration, begins the IKE negotiation process. This IKE Security Association (SA) agreement is known as Phase 1. 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. Basically, Phase 1 authenticates a remote peer and sets up a secure communication channel for establishing Phase 2, which negotiates the IPsec SA.

IKE Phase 1 can occur in either Main mode or Aggressive mode. For more information, see Phase 1 parameters on page 1624.

IKE Phase 1 is successful only when the following are true:

• Each peer negotiates a matching IKE SA policy.
• Each peer is authenticated and their identities protected.
• The Diffie-Hellman exchange is authenticated (the pre-shared secret keys match). For more information on Phase 1, see Phase 1 parameters on page 1624.

Phase 2

Phase 2 parameters define the algorithms that the FortiGate unit can use to encrypt and transfer data for the remainder of the session in an IPsec SA. The basic Phase 2 settings associate IPsec Phase 2 parameters with a Phase 1 configuration.

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

In Phase 2, 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. For more information, see Phase 2 parameters on page 1642.

IKE Phase 2 is successful only when the following are true:

• The IPsec SA is established and protected by the IKE SA.
• The IPsec SA is configured to renegotiate after set durations (see Phase 2 parameters on page 1642 and Phase 2 parameters on page 1642).
• Optional: Replay Detection is enabled. Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel. See Phase 2 parameters on page 1642.
• Optional: Perfect Forward Secrecy (PFS) is enabled. PFS improves security by forcing a new Diffie-Hellman exchange whenever keylife expires. See Phase 2 parameters on page 1642.

For more information on Phase 2, see Phase 2 parameters on page 1642.

With Phase 2 established, the IPsec tunnel is fully negotiated and traffic between the peers is allowed until the SA terminates (for any number of reasons; time-out, interruption, disconnection, etc).

IKEv2

Phase 1

Unlike Phase 1 of IKEv1, IKEv2 does not provide options for Aggressive or Main mode. Furthermore, Phase 1 of IKEv2 begins immediately with an IKE SA initiation, consisting of only two packets (containing all the information typically contained in four packets for IKEv1), securing the channel such that all following transactions are encrypted (see Phase 1 parameters on page 1624).

The encrypted transactions contain the IKE authentication, since remote peers have yet to be authenticated. This stage of IKE authentication in IKEv2 can loosely be called Phase 1.5.

Phase 1.5

As part of this phase, IKE authentication must occur. IKE authentication consists of the following:

• The authentication payloads and Internet Security Association and Key Management Protocol (ISAKMP) identifier.
• The authentication method (RSA, PSK, ECDSA, or EAP).
• The IPsec SA parameters.

Due to the number of authentication methods potentially used, and SAs established, the overall IKEv2 negotiation can range from 4 packets (no EAP exchange at all) to many more.

At this point, both peers have a security association complete and ready to encrypt traffic.

Phase 2

In IKEv1, Phase 2 uses Quick mode to negotiate an IPsec SA between peers. In IKEv2, since the IPsec SA is already established, Phase 2 is essentially only used to negotiate “child” SAs, or to re-key an IPsec SA. That said, there are only two packets for each exchange of this type, similar to the exchange at the outset of Phase 1.5.

Support for IKEv2 session resumption described in RFC 5723

If a gateway loses connectivity to the network, clients can attempt to re-establish the lost session by presenting the ticket to the gateway. As a result, sessions can be resumed much faster, as DH exchange that is necessary to establish a brand new connection is skipped. This feature implements “ticket-by-value”, whereby all information necessary to restore the state of a particular IKE SA is stored in the ticket and sent to the client.

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
• IP addresses associated with data that has to be encrypted and decrypted
• Optionally, a schedule that restricts when the VPN can operate
• 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 1648.

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

Planning your VPN

It is a good idea to plan the VPN configuration ahead of time. This will save time later and help you configure your VPN correctly.

All VPN configurations are comprised of numerous required and optional parameters. Before you begin, you need to determine:

• Where the IP traffic originates and where it needs to be delivered
• Which hosts, servers, or networks to include in the VPN
• Which VPN devices to include in the configuration
• Through which interfaces the VPN devices communicate
• Through which interfaces do private networks access the VPN gateways

Once you have this information, you can select a VPN topology that suits the network environment.

Network topologies

The topology of your network will determine how remote peers and clients connect to the VPN and how VPN traffic is routed.

VPN network topologies and brief descriptions

Topology                                 Description

Gateway-to-gateway con- figurations

Standard one-to-one VPN between two FortiGate units. See Gateway-to- gateway configurations on page 1655.

Hub-and-spoke configurations     One central FortiGate unit has multiple VPNs to other remote FortiGate units. See Hub-and-spoke configurations on page 1671.

Dynamic DNS configuration        One end of the VPN tunnel has a changing IP address and the other end must go to a dynamic DNS server for the current IP address before estab- lishing a tunnel. See Dynamic DNS configuration on page 1688.

Typically remote FortiClient dialup-clients use dynamic IP addresses through NAT devices. The FortiGate unit acts as a dialup server allowing dialup VPN connections from multiple sources. See FortiClient dialup-client configurations on page 1702.

Similar to FortiClient dialup-client configurations but with more gateway-to- gateway settings such as unique user authentication for multiple users on a single VPN tunnel. See FortiGate dialup-client configurations on page 1716.

Secure web browsing performed by dialup VPN clients, and/or hosts behind a remote VPN peer. See Internet-browsing configuration on page 1729.

Topology                                 Description

Redundant VPN con- figurations

Options for supporting redundant and partially redundant IPsec VPNs, using route-based approaches. See Redundant VPN configurations on page 1734.

Transparent mode VPNs

In transparent mode, the FortiGate acts as a bridge with all incoming traffic being broadcast back out on all other interfaces. Routing and NAT must be performed on external routers. See Transparent mode VPNs on page 1759.

L2TP and IPsec (Microsoft VPN)

Configure VPN for Microsoft Windows dialup clients using the built in L2TP software. Users do not have to install any See L2TP and IPsec (Microsoft VPN) on page 1778.

These sections contain high-level configuration guidelines with cross-references to detailed configuration procedures. If you need more detail to complete a step, select the cross-reference in the step to drill-down to more detail. Return to the original procedure to complete the procedure. For a general overview of how to configure a VPN, see Planning your VPN .

General preparation steps

A VPN configuration defines relationships between the VPN devices and the private hosts, servers, or networks making up the VPN. Configuring a VPN involves gathering and recording the following information. You will need this information to configure the VPN.

• The private IP addresses of participating hosts, servers, and/or networks. These IP addresses represent the source addresses of traffic that is permitted to pass through the VPN. A IP source address can be an individual IP address, an address range, or a subnet address.
• The public IP addresses of the VPN end-point interfaces. The VPN devices establish tunnels with each other through these interfaces.
• The private IP addresses associated with the VPN-device interfaces to the private networks. Computers on the private networks behind the VPN gateways will connect to their VPN gateways through these interfaces.

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

2. Define Phase 2 parameters to create a VPN tunnel with a remote peer or dialup client. See IPsec VPN in the web- based manager on page 1611.

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

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 auto- negotiate commands in the CLI.

For more information, refer to Phase 2 parameters on page 1642 and Phase 2 parameters on page 1642.

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 con- nection originates. For a route-based tunnel, the FortiGate unit also uses the name for the virtual IPsec interface that it creates automatically.

Select the category of the remote connection:

Remote Gateway

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 sub-scribes 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 inter- face that you selected.

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.

Mode

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 con- figurations 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 cli- ent 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 con- sist of a minimum of 16 randomly chosen alphanumeric 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 Authentic- ation 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 option is available when Aggressive Mode is enabled. Enter the iden- tifier that is used to authenticate the remote peer. This identifier must match the Local ID that the remote peer’s administrator has configured.

This peer ID

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.

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

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

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

Phase 1 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).

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

New attributes in IPsec phase1 settings have been added.

To configure VXLAN over IPsec – CLI:

config vpn ipsec phase1-interface/phase1 edit ipsec

set interface <name>

set encapsulation vxlan/gre (new)

set encapsulation-address ike/ipv4/ipv6 (New)

set encap-local-gw4 xxx.xxx.xxx.xxx (New)

set encap-remote-gw xxx.xxx.xxx.xxx (New)

next end

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.

IPsec tunnel idle timer

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 inter- face IP addresses.

Specify an IP address for the local end of the VPN tunnel. Select one of the following:

Local Gateway IP

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 com- binations. 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.

You can select either of the following message digests to check the authen- ticity 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 com- bination, 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 sup- ply to the VPN server during the Phase 1 exchange.

If the FortiGate unit will act as a VPN client, and you are using security cer- tificates for authentication, select the distinguished name (DN) of the local server certificate that the FortiGate unit will use for authentication pur- poses.

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 dia- lup 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.

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

XAuth 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 imple- mentation 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 noti- fication whenever a tunnel goes up or down, or to keep the tunnel con- nection 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.

IKE fragmentation

UDP fragmentation can cause issues in IPsec when either the ISP or perimeter firewall(s) cannot pass or fragment the oversized UDP packets that occur when using a very large public security key (PSK). The result is that IPsec tunnels do not come up. The solution is IKE fragmentation.

For most configurations, enabling IKE fragmentation allows connections to automatically establish when they otherwise might have failed due to intermediate nodes dropping IKE messages containing large certificates, which typically push the packet size over 1500 bytes.

FortiOS will fragment a packet on sending if, and only if, all the following are true:

• Phase 1 contains “set fragmentation enable”.
• The packet is larger than the minimum MTU (576 for IPv4, 1280 for IPv6).
• The packet is being re-transmitted.

By default, IKE fragmentation is enabled, but upon upgrading, any existing phase1-interface may have have “set fragmentation disable” added in order to preserve the existing behaviour of not supporting fragmentation.

To enable or disable IKE fragmentation – CLI

config vpn ipsec phase1-interface edit 1

set fragmentation [enable | disable]

next end

Phase 2 configuration

After IPsec Phase 1 negotiations end successfully, you begin Phase 2. You can configure the Phase 2 parameters to define the algorithms that the FortiGate unit may use to encrypt and transfer data for the remainder of the session. During Phase 2, you select specific IPsec security associations needed to implement security services and establish a tunnel.

The basic Phase 2 settings associate IPsec Phase 2 parameters with the Phase 1 configuration that specifies the remote end point of the VPN tunnel. In most cases, you need to configure only basic Phase 2 settings.

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

Name                                           Type a name to identify the Phase 2 configuration.

Phase 1                                       Select the Phase 1 tunnel configuration. For more information on con- figuring Phase 1, see Phase 1 configuration on page 1611. The Phase 1 configuration describes how remote VPN peers or clients will be authen- ticated on this tunnel, and how the connection to the remote peer or client will be secured.

Advanced                                   Define advanced Phase 2 parameters. For more information, see Phase 2 advanced configuration settings below.

Phase 2 advanced configuration settings

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

You can use a number of additional advanced Phase 2 settings to enhance the operation of the tunnel.

Phase 2 Proposal                      Select the encryption and authentication algorithms that will be proposed to the remote VPN peer. You can specify up to three proposals. To estab- lish a VPN connection, at least one of the proposals that you specify must match configuration on the remote peer.

Initially there are two proposals. Add and Delete icons are next to the second Authentication field.

It is invalid to set both Encryption and Authentication to NULL.

Encryption                                 Select a symmetric-key algorithms:

NULL — Do not use an encryption algorithm.

DES — Digital Encryption Standard, a 64-bit block algorithm that uses a

56-bit key.

3DES — Triple-DES; plain text is encrypted three times by three keys.

AES128 — A 128-bit block algorithm that uses a 128-bit key. AES192 — A 128-bit block algorithm that uses a 192-bit key. AES256 — A 128-bit block algorithm that uses a 256-bit key.

Authentication                           You can select either of the following message digests to check the authen- ticity of messages during an encrypted session:

NULL — Do not use a message digest.

MD5 — Message Digest 5.

SHA1 — Secure Hash Algorithm 1 – a 160-bit message digest.

To specify one combination only, set the Encryption and Authentication options of the second combination to NULL. To specify a third com- bination, use the Add button beside the fields for the second combination.

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

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, or 14 through 21). This must match the DH Group that the remote peer or dialup client uses.

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.

Autokey Keep Alive                  Select the check box 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                                Provide IP addresses dynamically to VPN clients. This is available for Phase 2 configurations associated with a dialup Phase 1 configuration.

You also need configure a DHCP server or relay on the private network interface. You must configure the DHCP parameters separately.

If you configure the DHCP server to assign IP addresses based on RADIUS user group attributes, you must also set the Phase 1 Peer Options to Peer ID from dialup group and select the appropriate user group. See Phase 1 configuration on page 1611.

If the FortiGate unit acts as a dialup server and you manually assigned FortiClient dialup clients VIP addresses that match the network behind the dialup server, selecting the check box will cause the FortiGate unit to act as a proxy for the dialup clients.

Quick Mode Selector                Specify the source and destination IP addresses to be used as selectors for IKE negotiations. If the FortiGate unit is a dialup server, keep the default value of 0.0.0.0/0 unless you need to circumvent problems caused by ambiguous IP addresses between one or more of the private networks mak- ing up the VPN. You can specify a single host IP address, an IP address range, or a network address. You may optionally specify source and des- tination port numbers and a protocol number.

If you are editing an existing Phase 2 configuration, the Source address and Destination address fields are unavailable if the tunnel has been con- figured to use firewall addresses as selectors. This option exists only in the CLI.

Source address                         If the FortiGate unit is a dialup server, enter the source IP address that cor- responds to the local senders or network behind the local VPN peer (for example, 172.16.5.0/24 or 172.16.5.0/255.255.255.0 for a subnet, or 172.16.5.1/32 or 172.16.5.1/255.255.255.255 for a server or host, or 192.168.10.[80-100] or 192.168.10.80-192.168.10.100 for an address range). A value of 0.0.0.0/0 means all IP addresses behind the local VPN peer.

If the FortiGate unit is a dialup client, source address must refer to the private network behind the Fortinet dialup client.

Source port                                Enter the port number that the local VPN peer uses to transport traffic related to the specified service (protocol number). The range is from 0 to 65535. To specify all ports, type 0.

Destination address                 Enter the destination IP address that corresponds to the recipients or net- work behind the remote VPN peer (for example, 192.168.20.0/24 for a subnet, or 172.16.5.1/32 for a server or host, or 192.168.10.[80-100] for an address range). A value of 0.0.0.0/0 means all IP addresses behind the remote VPN peer.

Destination port                        Enter the port number that the remote VPN peer uses to transport traffic related to the specified service (protocol number). To specify all ports, enter 0.

Protocol                                      Enter the IP protocol number of the service. To specify all services, enter 0.

FortiClient VPN

Use the FortiClient VPN for OS X, Windows, and Android VPN Wizard option when configuring an IPsec VPN for remote users to connect to the VPN tunnel using FortiClient.

When configuring a FortiClient VPN connection, the settings for Phase 1 and Phase 2 settings are automatically configured by the FortiGate unit. They are set to:

• Remote Gateway — Dialup User
• Mode — Aggressive
• Default settings for Phase 1 and 2 Proposals
• XAUTH Enable as Server (Auto)
• IKE mode-config will be enabled
• Peer Option — “Any peer ID”

The remainder of the settings use the current FortiGate defaults. Note that FortiClient settings need to match these FortiGate defaults. If you need to configure advanced settings for the FortiClient VPN, you must do so using the CLI.

Name                                           Enter a name for the FortiClient VPN.

Local Outgoing Interface         Select the local outgoing interface for the VPN.

Authentication Method            Select the type of authentication used when logging in to the VPN.

Preshared Key                           If Pre–shared Key was selected in Authentication Method, enter the pre-shared key in the field provided.

User Group                                Select a user group. You can also create a user group from the drop-down list by selecting Create New.

Address Range Start IP            Enter the start IP address for the DHCP address range for the client.

Address Range End IP             Enter the end IP address for the address range.

Subnet Mask                              Enter the subnet mask.

Enable IPv4 Split Tunnel         Enabled by default, this option enables the FortiClient user to use the VPN to access internal resources while other Internet access is not sent over the VPN, alleviating potential traffic bottlenecks in the VPN connection. Dis- able this option to have all traffic sent through the VPN tunnel.

Accessible Networks                Select from a list of internal networks that the FortiClient user can access.

Client Options                           These options affect how the FortiClient application behaves when con- nected to the FortiGate VPN tunnel. When enabled, a check box for the cor- responding option appears on the VPN login screen in FortiClient, and is not enabled by default.

Save Password – When enabled, if the user selects this option, their pass- word is stored on the user’s computer and will automatically populate each time they connect to the VPN.

Auto Connect – When enabled, if the user selects this option, when the FortiClient application is launched, for example after a reboot or system startup, FortiClient will automatically attempt to connect to the VPN tunnel.

Always Up (Keep Alive) – When enabled, if the user selects this option, the FortiClient connection will not shut down. When not selected, during periods of inactivity, FortiClient will attempt to stay connected every three minutes for a maximum of 10 minutes.

Endpoint Registration              When selected, the FortiGate unit requests a registration key from FortiCli- ent before a connection can be established. A registration key is defined by going to System > Advanced.

For more information on FortiClient VPN connections to a FortiGate unit, see the FortiClient Administration Guide.

DNS Server                                 Select which DNS server to use for this VPN:

Use System DNS — Use the same DNS servers as the FortiGate unit. These are configured at Network > DNS. This is the default option. Specify — Specify the IP address of a different DNS server.

Concentrator

In a hub-and-spoke configuration, policy-based VPN connections to a number of remote peers radiate from a single, central FortiGate unit. Site-to-site connections between the remote peers do not exist; however, you can establish VPN tunnels between any two of the remote peers through the FortiGate unit’s “hub”.

In a hub-and-spoke network, all VPN tunnels terminate at the hub. The peers that connect to the hub are known as “spokes”. The hub functions as a concentrator on the network, managing all VPN connections between the spokes. VPN traffic passes from one tunnel to the other through the hub.

You define a concentrator to include spokes in the hub-and-spoke configuration. You create the concentrator in

VPN > IPsec Concentrator and select Create New. A concentrator configuration specifies which spokes to include in an IPsec hub-and-spoke configuration.

Concentrator Name                   Type a name for the concentrator.

Available Tunnels                     A list of defined IPsec VPN tunnels. Select a tunnel from the list and then select the right arrow.

Members                                    A list of tunnels that are members of the concentrator. To remove a tunnel from the concentrator, select the tunnel and select the left arrow.

IPsec Monitor

You can use the IPsec Monitor to view activity on IPsec VPN tunnels and start or stop those tunnels. The display provides a list of addresses, proxy IDs, and timeout information for all active tunnels, including tunnel mode and route-based (interface mode) tunnels.

To view the IPsec monitor, go to Monitor > IPsec Monitor.

For dialup VPNs, the list provides status information about the VPN tunnels established by dialup clients, and their IP addresses.

For static IP or dynamic DNS VPNs, the list provides status and IP addressing information about VPN tunnels, active or not, to remote peers that have static IP addresses or domain names. You can also start and stop individual tunnels from the list.

Phase 1 parameters

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

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

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

The following topics are included in this section: Overview

Defining the tunnel ends

Choosing Main mode or Aggressive mode

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

Dynamic IPsec route control

Overview

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

IPsec Phase 1 settings define:

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

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

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

Defining the tunnel ends

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

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

The remote gateway can be:

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

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

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

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

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

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

Choosing Main mode or Aggressive mode

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

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

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

Choosing the IKE version

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

If you select IKEv2:

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

IKEv2 cookie notification for IKE_SA_INIT

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

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

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

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

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

IKEv2 Quick Crash Detection

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

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

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

To add Quick Crash Detection – CLI Syntax

config system settings

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

end

Authenticating the FortiGate unit

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

Authenticating the FortiGate unit with digital certificates

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

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

To authenticate the FortiGate unit using digital certificates

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

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

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

Remote Gateway                       Select the nature of the remote connection.

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

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

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

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

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

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

Authentication Method            Select Signature.

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

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

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

See Authenticating the FortiGate unit on page 1627.

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

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

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

4. Select OK.

Authenticating the FortiGate unit with a pre-shared key

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

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

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

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

To authenticate the FortiGate unit with a pre-shared key

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

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

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

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

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

Mode                                           Select Main or Aggressive mode.

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

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

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

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

Authentication Method            Select Pre–shared Key.

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

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

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

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

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

4. Select OK.

Authenticating remote peers and clients

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

Methods of authenticating remote VPN peers

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

Reference

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

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

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

Pre–shared key                                        X                          X

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

Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

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

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

CLI Syntax:

config vpn ipsec phase1-interface edit p1

set reauth [enable | disable]

next end

disable: Disable IKE SA re-authentication.

enable: Enable IKE SA re-authentication.

Enabling VPN access for specific certificate holders

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

Before you begin

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

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

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

config user peer edit DN_FG1000

set cn 192.168.2.160 set cn-type ipv4

end

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

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

config user peer edit CA_FG1000

set ca CA_Cert_1

set subject FG1000_at_site1

end

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

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

To view server certificate information and obtain the local DN

1. Go to System > Certificates.

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

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

1. Go to System > Certificates > CA Certificates.

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

Configuring certificate authentication for a VPN

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

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

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

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

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

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

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

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

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

7. Select OK.

Enabling VPN access by peer identifier

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

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

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

To authenticate remote peers or dialup clients using one peer ID

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

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

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

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

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

5. Select OK.

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

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

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

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

3. Select Advanced.

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

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

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

6. Select OK.

To configure the FortiClient application

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

1. Start the FortiClient application.

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

3. Select Advanced > Edit > Advanced.

4. Under Policy, select Config.

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

6. Select OK to close all dialog boxes.

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

Enabling VPN access with user accounts and pre-shared keys

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

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

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

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

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

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

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

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

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

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

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

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

4. Clear the Pre–shared Key field.

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

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

6. Select OK.

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

To configure FortiClient – pre-shared key and peer ID

1. Start the FortiClient Endpoint Security application.

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

3. Select Advanced > Edit.

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

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

5. Select Advanced.

6. Under Policy, select Config.

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

8. Select OK to close all dialog boxes.

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

To configure FortiClient – preshared key only

1. Start the FortiClient Endpoint Security application.

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

3. Select Advanced > Edit.

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

5. Select OK to close all dialog boxes.

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

Defining IKE negotiation parameters

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

The IKE negotiation parameters determine:

• Which encryption algorithms may be applied for converting messages into a form that only the intended recipient can read
• Which authentication hash may be used for creating a keyed hash from a preshared or private key
• Which Diffie-Hellman group (DH Group) will be used to generate a secret session key

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

Generating keys to authenticate an exchange

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

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

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

config system global set dh-params 3072

end

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

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

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

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

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

Defining IKE negotiation parameters

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

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

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

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

Add or delete encryption and authentication algorithms as required. Select a minimum of one and a maximum of three combinations. The remote peer must be configured to use at least one of the proposals that you define.

It is invalid to set both Encryption and Authentication to null.

Encryption                                 Select a symmetric-key algorithms:

NULL — Do not use an encryption algorithm.

DES — Digital Encryption Standard, a 64-bit block algorithm that uses a

56-bit key.

3DES — Triple-DES; plain text is encrypted three times by three keys.

AES128 — A 128-bit block algorithm that uses a 128-bit key. AES192 — A 128-bit block algorithm that uses a 192-bit key. AES256 — A 128-bit block algorithm that uses a 256-bit key.

Authentication                           You can select either of the following message digests to check the authen- ticity of messages during an encrypted session:

NULL — Do not use a message digest.

MD5 — Message Digest 5.

SHA1 — Secure Hash Algorithm 1 – a 160-bit message digest.

To specify one combination only, set the Encryption and Authentication options of the second combination to NULL. To specify a third com- bination, use the Add button beside the fields for the second combination.

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

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

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

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

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

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

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

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

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

NAT traversal

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

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

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

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

NAT keepalive frequency

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

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

The keepalive packet is a 138-byte ISAKMP exchange.

Dead peer detection

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

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

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

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

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

config vpn ipsec phase1 edit test

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

set dpd-retryinveral 15 set dpd-retrycount 3

next end

Using XAuth authentication

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

Using the FortiGate unit as an XAuth server

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

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

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

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

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

To authenticate a dialup user group using XAuth settings

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

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

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

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

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

5. Select OK.

Using the FortiGate unit as an XAuth client

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

To configure the FortiGate dialup client as an XAuth client

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

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

3. Under XAuth, select Enable as Client.

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

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

6. Select OK.

Dynamic IPsec route control

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

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

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

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

Syntax

Phase 1

config vpn ipsec edit <name>

set type dynamic

set add-route {enable | disable}

end end

Phase 2

config vpn ipsec {phase2 | phase2-interface}

edit <name>

set add-route {phase1 | enable | disable}

end end

Blocking IPsec SA Negotiation

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

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

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

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.

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 is not supported.

The two types of objects have been broken into sections with the address groups at the bottom of the list to make it easy to determine if one of the choices in the drop down menu is an address or an address group.

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 IPv6 IPsec VPNs on page 1764.

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.
• Security policies control which IP addresses can connect to the VPN.
• 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 1624.

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.

or delete encryption and authentication algorithms as required. Select a minimum of one and a maximum of three combinations. The remote peer must be configured to use at least one of the proposals that you define.

It is invalid to set both Encryption and Authentication to null.

Encryption                                         Select a symmetric-key algorithms:

NULL — Do not use an encryption algorithm.

DES — Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key.

3DES — Triple-DES; plain text is encrypted three times by three keys.

AES128 — A 128-bit block algorithm that uses a 128-bit key.

AES192 — A 128-bit block algorithm that uses a 192-bit key.

AES256 — A 128-bit block algorithm that uses a 256-bit key.

Authentication                           You can select either of the following message digests to check the authen- ticity of messages during an encrypted session:

NULL — Do not use a message digest.

MD5 — Message Digest 5.

SHA1 — Secure Hash Algorithm 1 – a 160-bit message digest.

To specify one combination only, set the Encryption and Authentication options of the second combination to NULL. To specify a third com- bination, use the Add button beside the fields for the second combination.

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

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, or 14 through 21). 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 dia- lup clients. The DHCP server or relay parameters must be configured sep- arately.

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. Auto- negotiate 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 mesh- selector-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. When a host on the network behind the dialup server issues an ARP request that corresponds 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 answers the ARP request on behalf of the FortiClient host and forwards the associated traffic to the FortiClient host through the tunnel.

This feature 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.

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 VPN security policies

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.

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,192.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, 172.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, 10.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.

To define 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 VPN security policies

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 Dynamic DNS configuration on page 1688.

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 tun- nel) will be blocked.

Defining an IPsec security policy for a 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.

Allow traffic to be initiated from the remote site

In addition to these operations, 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 computers on the 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 on IP packets before they are sent through the tunnel.

Inbound NAT is performed on IP packets emerging from the tunnel. By default, these options are not selected in security policies.

When used in conjunction with the natip CLI attribute (see the “config firewall” chapter of the FortiGate CLI Reference), outbound NAT enables you to change the source addresses of IP packets before they go into the tunnel. This feature is often used to resolve ambiguous routing when two or more of the private networks making up a VPN have the same or overlapping IP addresses. .

When inbound NAT is enabled, inbound encrypted packets are intercepted and decrypted, and the source IP addresses of the decrypted packets are translated into the IP address of the FortiGate interface to the local private network before they are routed to the private network. If the computers on the local private network can communicate only with devices on the local private network (that is, the FortiGate interface to the private network is not the default gateway) and the remote client (or remote private network) does not have an IP address in the same network address space as the local private network, enable inbound NAT.

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, and email services throughout the VPN; and optionally allow connections according to a predefined schedule.

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

When a remote server or client attempts to connect to the private network behind a FortiGate gateway, the security policy intercepts the connection attempt and starts the VPN tunnel. The FortiGate unit uses the remote gateway specified in its Phase 1 tunnel configuration to reply to the remote peer. When the remote peer receives a reply, it checks its own security policy, including the tunnel configuration, to determine which communications are permitted. As long as one or more services are allowed through the VPN tunnel, the two peers begin to negotiate the tunnel. To follow this negotiation in the web-based manager, go to Monitor > IPsec Monitor. There you will find a list of the VPN tunnels, their status, and the data flow both incoming and outgoing.

Before you begin

Before you define the IPsec policy, you must:

• Define the IP source and destination addresses. See Defining VPN security policies on page 1650.
• Specify the Phase 1 authentication parameters. See Phase 1 parameters on page 1624.
• Specify the Phase 2 parameters. See Phase 2 parameters on page 1642.

To define an IPsec security policy

1. Go to Policy & Objects > IPv4 Policy.

2. Select Create New and set the following options:

Incoming Interface                   Select the local interface to the internal (private) network.

Source Address                        Select the name that corresponds to the local network, server(s), or host(s) from which IP packets may originate.

Outgoing Interface                   Select the local interface to the external (public) network.

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 spe- cific requirements.

Service                                       Keep the default setting (ANY) unless changes are needed to meet your specific requirements.

VPN Tunnel                                Select Use Existing and select the tunnel from the drop-down list.

Allo traffic to be initiated from the remote site

Select if traffic from the remote network will be allowed to initiate the tun- nel.

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 IPSEC policies before ACCEPT and DENY security policies. 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. When you define multiple IPsec policies for the same tunnel, you must reorder the 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. Reordering is especially important when the source and destination addresses in both policies are similar (for example, if one policy specifies a subset of the IP addresses in another policy). In this case, place the IPsec policy having the most specific constraints at the top of the list so that it can be evaluated first.

Defining security policies for a 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.

To define security policies for a route-based VPN

1. Go to Policy & Objects > IPv4 Policy.

2. Select Create New and leave the Policy Type as Firewall, and the Policy Subtype as Address.

3. Define an ACCEPT security policy to permit communications between the local private network and the private network behind the remote peer. Enter these settings in particular:

Incoming Interface                   Select the interface that connects to the private network behind this FortiGate unit.

Source Address                        Select the address name that you defined for the private network behind this FortiGate unit.

Outgoing Interface                   Select the IPsec Interface you configured.

Destination Address                 Select the address name that you defined for the private network behind the remote peer.

Action                                         Select ACCEPT.

Enable NAT                                Disable.

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

4. Select Create New and leave the Policy Type as Firewall, and the Policy Subtype as Address

5. Enter these settings in particular:

Incoming Interface                   Select the IPsec Interface you configured.

Source Address                        Select the address name that you defined for the private network behind the remote peer.

Outgoing Interface                   Select the interface that connects to the private network behind this FortiGate unit.

Destination Address                 Select the address name that you defined for the private network behind this FortiGate unit.

Action                                         Select ACCEPT.

Enable NAT                                Disable.

Gateway-to–gateway configurations

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
• General configuration steps
• Configuring the two VPN peers
• 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 1655.

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

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 (see Hub-and-spoke configurations on page 1671).

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.

General configuration steps

The FortiGate units at both ends of the tunnel must be operating in NAT mode and have static public IP addresses.

When a FortiGate unit receives a connection request from a remote VPN peer, it uses IPsec Phase 1 parameters to establish a secure connection and authenticate that VPN peer. Then, if the security policy permits the connection, the FortiGate unit establishes the tunnel using IPsec Phase 2 parameters and applies the IPsec security policy. Key management, authentication, and security services are negotiated dynamically through the IKE protocol.

To support these functions, the following general configuration steps must be performed by both FortiGate units:

• Define the Phase 1 parameters that the FortiGate unit needs to authenticate the remote peer and establish a secure connection.
• Define the Phase 2 parameters that the FortiGate unit needs to create a VPN tunnel with the remote peer.
• Create security policies to control the permitted services and permitted direction of traffic between the IP source and destination addresses.

Configuring the two VPN peers

Configure the VPN peers as follows. Each step is required, but these are general steps. For more detailed information on each step follow the cross references. See Phase 1 parameters on page 1624. All steps are required. Cross references point to required information that is repeated. No steps are optional.

Dynamic DNS configuration

This section describes how to configure a site-to-site VPN, in which one FortiGate unit has a static IP address and the other FortiGate unit has a domain name and a dynamic IP address.

• The following topics are included in this section: Dynamic DNS over VPN concepts
• Dynamic DNS topology
• General configuration steps
• Configure the dynamically-addressed VPN peer
• Configure the fixed-address VPN peer
• Testing

Dynamic DNS over VPN concepts

A typical computer has a static IP address and one or more DNS servers to resolve fully qualified domain names (FQDN) into IP addresses. A domain name assigned to this computer is resolved by any DNS server having an entry for the domain name and its static IP address. The IP address never changes or changes only rarely so the DNS server can reliably say it has the correct address for that domain all the time.

Dynamic DNS (DDNS)

It is different when a computer has a dynamic IP address, such as an IP address assigned dynamically by a DHCP server, and a domain name. Computers that want to contact this computer do not know what its current IP address is. To solve this problem there are dynamic DNS servers. These are public servers that store a DNS entry for your computer that includes its current IP address and associated domain name. These entries are kept up to date by your computer sending its current IP address to the dynamic DNS (DDNS) server to ensure its entry is always up to date. When other computers want to contact your domain, their DNS gets your IP address from your DDNS server. To use DDNS servers, you must subscribe to them and usually pay for their services.

When configuring DDNS on your FortiGate unit, go to Network > DNS and enable Enable FortiGuard DDNS. Then select the interface with the dynamic connection, which DDNS server you have an account with, your domain name, and account information. If your DDNS server is not on the list, there is a generic option where you can provide your DDNS server information.

Routing

When an interface has some form of changing IP address (DDNS, PPPoE, or DHCP assigned address), routing needs special attention. The standard static route cannot handle the changing IP address. The solution is to use the dynamic-gateway command in the CLI. Say for example you already have four static routes, and you have a PPPoE connection over the wan2 interface and you want to use that as your default route.

The route is configured on the dynamic address VPN peer trying to access the static address FortiGate unit.

To configure dynamic gateway routing – CLI

config router static edit 5

set dst 0.0.0.0 0.0.0.0

set dynamic-gateway enable set device wan2

next end

For more information on DDNS, see the System Administration handbook chapter.

Dynamic DNS over VPN

IPsec VPN expects an IP address for each end of the VPN tunnel. All configuration and communication with that tunnel depends on the IP addresses as reference points. However, when the interface the tunnel is on has DDNS enabled there is no set IP address. The remote end of the VPN tunnel now needs another way to reference your end of the VPN tunnel. This is accomplished using Local ID.

A FortiGate unit that has a domain name and a dynamic IP address can initiate VPN connections anytime. The remote peer can reply to the local FortiGate unit using the source IP address that was sent in the packet header because it is current. Without doing a DNS lookup first, the remote peer runs the risk of the dynamic IP changing before it attempts to connect. To avoid this, the remote peer must perform a DNS lookup for the domain name of to be sure of the dynamic IP address before initiating the connection.

Remote Gateway

When configuring the Phase 1 entry for a VPN tunnel, the Remote Gateway determines the addressing method the remote end of the tunnel uses as one of Static IP Address, Dialup User, or Dynamic DNS. There are different fields for each option.

When you select the Dynamic DNS VPN type there is a related field called Dynamic DNS. The Dynamic DNS field is asking for the FQDN of the remote end of the tunnel. It uses this information to look up the IP address of the remote end of the tunnel through the DDNS server associated with that domain name.

Local ID (peer ID)

The Local ID or peer ID can be used to uniquely identify one end of a VPN tunnel. This enables a more secure connection. Also if you have multiple VPN tunnels negotiating, this ensures the proper remote and local ends connect. When you configure it on your end, it is your Local ID. When the remote end connects to you, they see it as your peer ID.

If you are debugging a VPN connection, the Local ID is part of the VPN negotiations. You can use it to help troubleshoot connection problems.

To configure your Local ID

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

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

3. Select Advanced.

4. In the Phase 1 Proposal section, enter your Local ID.

5. Select OK.

The default configuration is to accept all local IDs (peer IDs). If you have the Local ID set, the remote end of the tunnel must be configured to accept your Local ID.

To accept a specific Peer ID

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

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

3. Select Aggressive mode.

4. For Peer Options, select This peer ID. This option becomes visible only when Aggressive mode is selected.

5. Enter the string the other end of the tunnel used for its Local ID.

6. Configure the rest of the Phase 1 entry as required.

7. Select OK.

Route–based or policy-based VPN

VPN over dynamic DNS can be configured with either route-based or policy-based VPN settings. Both are valid, but have differences in configuration. Choose the best method based on your requirements. For more information on route-based and policy-based, see IPsec VPN overview on page 1606.

Route-based VPN configuration requires two security policies to be configured (one for each direction of traffic) to permit traffic over the VPN virtual interface, and you must also add a static route entry for that VPN interface or the VPN traffic will not reach its destination. See Dynamic DNS over VPN concepts on page 1688 and Dynamic DNS over VPN concepts on page 1688.

Policy-based VPN configuration uses more complex and often more IPsec security policies, but does not require a static route entry. It has the benefit of being able to configure multiple policies for handling multiple protocols in different ways, such as more scanning of less secure protocols or guaranteeing a minimum bandwidth for protocols such as VoIP. See Dynamic DNS over VPN concepts on page 1688 and Dynamic DNS over VPN concepts on page 1688.

Dynamic DNS topology

In this scenario, two branch offices each have a FortiGate unit and are connected in a gateway-to-gateway VPN configuration. One FortiGate unit has a domain name (example.com) with a dynamic IP address. See branch_2 in the figure below.

Whenever the branch_2 unit connects to the Internet (and possibly also at predefined intervals set by the ISP), the ISP may assign a different IP address to the FortiGate unit. The unit has its domain name registered with a dynamic DNS service. The branch_2 unit checks in with the DDNS server on a regular basis, and that server provides the DNS information for the domain name, updating the IP address from time to time. Remote peers have to locate the branch_2 FortiGate unit through a DNS lookup each time to ensure the address they get is current and correct.

Example dynamic DNS configuration

When a remote peer (such as the branch_1 FortiGate unit above) initiates a connection to example.com, the local DNS server looks up and returns the IP address that matches the domain name example.com. The remote peer uses the retrieved IP address to establish a VPN connection with the branch_2 FortiGate unit.

Assumptions

• You have administrator access to both FortiGate units.
• Both FortiGate units have interfaces named wan1 and internal. (If not, you can use the alias feature to assign these labels as “nicknames” to other interfaces to follow this example.)
• Both FortiGate units have the most recent firmware installed, have been configured for their networks, and are currently passing normal network traffic.
• The branch_2 FortiGate unit has its wan1 interface defined as a dynamic DNS interface with the domain name of example.com.
• A basic gateway-to-gateway configuration is in place (see Gateway-to-gateway configurations on page 1655) except one of the FortiGate units has a static domain name and a dynamic IP address instead of a static IP address.
• The FortiGate unit with the domain name is subscribed to one of the supported dynamic DNS services. Contact one of the services to set up an account. For more information and instructions about how to configure the FortiGate unit to push its dynamic IP address to a dynamic DNS server, see the System Administration handbook chapter.

General configuration steps

When a FortiGate unit receives a connection request from a remote VPN peer, it uses IPsec Phase 1 parameters to establish a secure connection and authenticate the VPN peer. Then, if the security policy permits the connection, the FortiGate unit establishes the tunnel using IPsec Phase 2 parameters and applies the security policy. Key management, authentication, and security services are negotiated dynamically through the IKE protocol.

To support these functions, the following general configuration steps must be performed:

• Configure the branch_2 FortiGate unit with the dynamic IP address. This unit uses a Local ID string instead of an IP address to identify itself to the remote peer. See General configuration steps below.
• General configuration steps
• General configuration steps
• Configure the fixed-address VPN peer. To initiate a VPN tunnel with the dynamically-addressed peer, this unit must first retrieve the IP address for the domain from the dynamic DNS service. See General configuration steps on page 1691.
• General configuration steps
• General configuration steps

Configure the dynamically-addressed VPN peer

It is assumed that this FortiGate unit (branch_2) has already had its public facing interface, for example the wan1, configured with the proper dynamic DNS configuration.

Configure branch_2, the dynamic address side

Configuring the dynamically-addressed VPN peer includes:

• Configuring branch_2 VPN tunnel settings
• Configuring branch_2 security policies

Configuring branch_2 VPN tunnel settings

Define the Phase 1 parameters needed to establish a secure connection with the remote peer. See Phase 1 parameters on page 1624. During this procedure you need to choose if you will be using route-based or policy- based VPNs.

To configure branch_2 VPN tunnel settings

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

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

3. Enter the following information:

Name                                           Enter branch_2, a name to identify the VPN tunnel. This name appears in Phase 2 configurations, security policies, and the VPN monitor.

Remote Gateway                               Select Static IP Address.

The remote peer this FortiGate is connecting to has a static IP public address.

If the remote interface is PPPoE do not select Retrieve default gateway from server.

IP Address                                 Enter 172.16.20.1. The IP address of the public interface to the remote peer.

Enter 172.16.20.1

The IP address of the public interface to the remote peer.

Select Aggressive.

4. Select Advanced and complete the following:

Local ID                                              Enter example.com.

A character string used by the branch_2 FortiGate unit to identify itself to the remote peer.

This value must be identical to the value in the This peer ID field of the Phase 1 remote gateway configuration on the branch_1 remote peer. See Configure the dynamically- addressed VPN peer on page 1692.

5. Open the Phase 2 Selectors panel.

Define the Phase 2 parameters needed to create a VPN tunnel with the remote peer. For details on Phase 2, see

Phase 2 parameters on page 1642.

6. Enter the following information and select OK.

Name                                                  Enter branch_2_phase2.

A name to identify this Phase 2 configuration.

Phase 1                                              Select branch_2.

The name of the Phase 1 configuration that you defined earlier.

Configuring branch_2 security policies

Define security policies to permit communications between the private networks through the VPN tunnel. Route- based and policy-based VPNs require different security policies. For detailed information about creating security policies, see Defining VPN security policies on page 1648.

After defining the two address ranges, select one of Creating branch_2 route-based security policies on page 1694 or Creating branch_2 policy-based security policies on page 1696 to configure the appropriate VPN policies.

Define address ranges for branch_2 security policies

Define VPN connection names for the address ranges of the private networks. These addresses are used in the security policies that permit communication between the networks. For more information, see Defining VPN security policies on page 1648.

Define an address name for the IP address and netmask of the private network behind the local FortiGate unit.

To define branch_2 address ranges

1. Go to Policy & Objects > Addresses.

2. Select Create New.

3. Enter the following information, and select OK.

Name                                          Enter branch_2_internal. Enter a meaningful name.

Type                                            Select Subnet.

Subnet / IP Range                             Enter 10.10.10.0/24.

Include the netmask or specify a specific range.

Interface                                     Select internal. The interface that will be handling the traffic from the internal network.

Define an address name for the IP address and netmask of the private network behind the remote peer.

4. Select Create New.

5. Enter the following information, and select OK.

Name                                          Enter branch_1_internal. A meaningful name for the private network at the remote end of the VPN tunnel.

Type                                            Select Subnet.

Subnet / IP Range                             Enter 192.168.1.0/24.

Include the netmask. Optionally you can specify a range

Interface                                             Select any.

The interface that will be handling the remote VPN traffic on this FortiGate unit. If you are unsure, or multiple interfaces may be handling this traffic use any.

Creating branch_2 route-based security policies

Define ACCEPT security policies to permit communication between the branch_2 and branch_1 private networks. Once the route-based policy is configured a routing entry must be configured to route traffic over the VPN interface.

Define a policy to permit the branch_2 local FortiGate unit to initiate a VPN session with the branch_1 VPN peer.

To create route-based security 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 the following information, and select OK.

Incoming Interface                           Select internal.

The interface that connects to the private network behind this FortiGate unit.

Source Address                                Select branch_2_internal.

Select the address name for the private network behind this FortiGate unit.

Outgoing Interface                   Select branch_2. The VPN Tunnel (IPsec Interface).

Destination Address                         Select branch_1_internal.

The address name the private network behind the remote peer.

Action                                         Select ACCEPT.

Enable NAT                                Disable.

Comments                                  Route-based: Initiate a branch_2 to branch_1 VPN tunnel.

Define a policy to permit the branch_1 remote VPN peer to initiate VPN sessions.

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 branch_2. The VPN Tunnel (IPsec Interface).

Source Address                        Select branch_1_internal. The address name for the private network behind the remote peer.

Outgoing Interface                   Select internal. The interface connecting the private network behind this FortiGate unit.

Destination Address                 Select branch_2_internal. The address name for the private network behind this FortiGate unit.

Action                                         Select ACCEPT.

Enable NAT                                Disable.

Comments                                  Route-based: Initiate a branch_1 to branch_2 internal VPN tunnel.

7. Optionally configure any other security policy settings you require such as UTM or traffic shaping for this policy.

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

This will ensure VPN traffic is matched against the VPN policies before any other policies.

To create routing entry for VPN interface – CLI

config router static edit 5

set dst 0.0.0.0 0.0.0.0

set dynamic-dateway enable set device wan1

next end

This routing entry must be added in the CLI because the dynamic-gateway option is not available in the web- based manager.

Creating branch_2 policy-based security policies

Define an IPsec policy to permit VPN sessions between the private networks. Define an IPsec policy to permit the VPN sessions between the local branch_2 unit and the remote branch_1 unit.

1. Go to Policy & Objects > IPv4 Policy and select Create New.

2. Enter the following information, and select OK.

Incoming Interface                   Select internal. The interface connecting the private network behind this FortiGate unit.

Source Address                        Select branch_2_internal. The address name for the private network behind this local FortiGate unit.

Outgoing Interface                   Select wan1. The FortiGate unit’s public interface.

Destination Address                 Select branch_1_internal. The address name for the private network behind branch_1, the remote peer.

VPN Tunnel                                Select Use Existing and select branch_2 from the drop-down list. The name of the Phase 1 tunnel.

Select Allow traffic to be initiated from the remote site.

Comments                                  Policy-based: allows traffic in either direction to initiate the VPN tunnel.

3. Optionally configure any other security policy settings you require such as UTM or traffic shaping for this policy.

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

This will ensure VPN traffic is matched against the VPN policies before any other policies.

Configure the fixed-address VPN peer

The fixed-address VPN peer, branch_1, needs to retrieve the IP address from the dynamic DNS service to initiate communication with the dynamically-addressed peer, branch_2. It also depends on the peer ID (local ID) to initiate the VPN tunnel with branch_2.

Configure branch_1, the fixed address side

Configuring the fixed-address VPN peer includes:

• Configuring branch_1 VPN tunnel settings
• Configuring branch_1 security policies

Configuring branch_1 VPN tunnel settings

Define the Phase 1 parameters needed to establish a secure connection with the remote peer. For more information, see Phase 1 parameters on page 1624.

To configure branch_1 Phase 1 VPN settings

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

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

3. Enter the following information and select OK.

Name                                           Enter branch_1. A name to identify the VPN tunnel. This name appears in Phase 2 configurations, security policies and the VPN monitor.

Remote Gateway                       Select Dynamic DNS. The remote peer this FortiGate is connecting to has a dynamic IP address.

Dynamic DNS                            Type the fully qualified domain name of the remote peer (for example, example.com).

Interface                                     Select wan1. The public facing interface on the fixed-address FortiGate unit.

Mode                                           Select Aggressive.

Peer Options                             Select This peer ID, and enter example.com. This option only appears when the mode is set to Aggressive. The identifier of the FortiGate unit with the dynamic address.

4. Define the Phase 2 parameters needed to create a VPN tunnel with the remote peer. See Phase 2 parameters on page 1642. Enter these settings in particular:

Name                                           Enter branch_1_p2. A name to identify this Phase 2 configuration.

Phase 1                                       Select branch_1.

The name of the Phase 1 configuration that you defined for the remote peer. You can select the name of the remote gateway from the Dynamic DNS part of the list.

Configuring branch_1 security policies

The branch_1 FortiGate unit has a fixed IP address and will be connecting to the branch_2 FortiGate unit that has a dynamic IP address and a domain name of example.com. Remember if you are using route-based security policies that you must add a route for the VPN traffic.

Defining address ranges for branch_1 security policies

As with branch_2 previously, branch_1 needs address ranges defined as well. See Defining VPN security policies on page 1648.

1. Go to Policy & Objects > Addresses.

2. Select Create New.

3. Enter the following information, and select OK.

Name                                           Enter branch_2_internal. A meaningful name for the private network behind the branch_2 FortiGate unit.

Type                                            Select Subnet.

Subnet / IP Range                     Enter 10.10.10.0/24. Include the netmask or specify a specific range.

Interface                                     Select internal. This is the interface on this FortiGate unit that will be hand- ling with this traffic.

4. Define an address name for the IP address and netmask of the private network behind the remote peer.

5. Select Create New.

6. Enter the following information, and select OK.

Name                                           Enter branch_1_internal. A meaningful name for the private network behind the branch_1 peer.

Type                                            Select Subnet.

Subnet / IP Range                     Enter 192.168.1.0/24. Include the netmask or specify a specific range.

Interface                                     Select any. The interface on this FortiGate unit that will be handling with this traffic. If you are unsure, or multiple interfaces may be handling this traffic use any.

Creating branch_1 route-based security policies

Define an ACCEPT security policy to permit communications between the source and destination addresses. See Defining VPN security policies on page 1648.

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 internal. The interface that connects to the private network behind the branch_1 FortiGate unit.

Source Address                        Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.

Outgoing Interface                   Select branch_1. The VPN Tunnel (IPsec Interface) you configured earlier.

Destination Address                 Select branch_2_internal. The address name that you defined for the private network behind the branch_2 peer.

Action                                         Select ACCEPT.

Enable NAT                                Disable

Comments                                  Internal -> branch2

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

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 branch_1. The VPN Tunnel (IPsec Interface) you configured earlier.

Source Address                        Select branch_2_internal. The address name that you defined for the private network behind the branch_2 remote peer.

Outgoing Interface                   Select internal. The interface that connects to the private network behind this FortiGate unit.

Destination Address                 Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.

Action                                         Select ACCEPT.

Enable NAT                                Disable

Comments                                  branch_2 -> Internal

Creating branch_1 policy-based security policies

A policy-based security policy allows you the flexibility to allow inbound or outbound traffic or both through this single policy.

This policy-based IPsec VPN security policy allows both inbound and outbound traffic

1. Go to Policy & Objects > IPv4 Policy and select Create New.

2. Enter the following information, and select OK.

Incoming Interface                   Select internal. The interface that connects to the private network behind this FortiGate unit.

Source Address                        Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.

Outgoing Interface                   Select wan1. The FortiGate unit’s public interface.

Destination Address                 Select branch_2_internal. The address name that you defined for the private network behind the remote peer.

VPN Tunnel                                        Select Use Existing and select branch_1 from the drop-down list.