Planning your VPN

Building a VPN between sites might involve complex association with sites and confusing configurations. Beginning hastily to configure settings without a comprehensive plan usually causes failure. Making a plan in advance for your VPN topology is a great help to the next VPN configurations. The following considerations help you determine the VPN topology and necessary information for configurations.

The locations of the sites that the site-to-site traffic originates from and needs to be delivered to l Choose the network sites that they need to communicate to each other through the VPN and define what kind of communication it is (what kind of services provided in a network site and what kind of services that users in a network site need to access).

The networks, individual hosts or server frames participating in the VPN communications l A network site consists of hosts, servers, and/or networks (private IP addresses deployment). You need to determine the participating private IP addresses (the source and destination of traffic) and make policies to permit traffic to pass through the VPN.

The VPN devices used to build the VPN

• A site-to-site VPN (tunnels) between two FortiWAN units, or a FortiWAN unit and a FortiGate unit. The network interfaces that two VPN devices communicate through l For any VPN tunnel between two VPN devices, you need to determine the participating network interface for each end-point. This implies the public IP addresses (local IP and remote IP) used to establish a VPN tunnel through Internet. Note that only static IP addresses are supported.
• One WAN interface cannot serve for more than one IPSec connectivity between any two FortiWAN devices. You need to take this for consideration when you determine the topology. See “Limitation in the IPSec deployment” for the details.

The VPN device interfaces that a private network accesses the VPN through l The private IP addresses associated with the VPN device interfaces to the private networks. Hosts in the private network behind the VPN device access VPN through these interface. Traffic is forwarded between the VPN tunnels and the private networks on each site. The types used to build the VPN l IPSec protected VPN without bandwidth aggregation and fault tolerance: IPSec Tunnel mode.

• IPSec protected VPN with bandwidth aggregation and fault tolerance: Tunnel Routing over IPSec Transport mode. l VPN with bandwidth aggregation and fault tolerance: Tunnel Routing (See “Tunnel Routing”).

IPSec VPN in the Web UI

The configurations introduced in this section are based on the deployment of FortiWAN-to-FortiWAN. For the IPSec VPN established between a FortiWAN unit and a FortiGate unit, see “Establish IPSec VPN with FortiGate”. This section focus on the configurations of IPSec protected VPN, IPSec Tunnel mode and Tunnel Routing over IPSec Transport mode. For configurations of Tunnel Routing, see “Tunnel Routing”.

To set up the IPSec VPN between two FortiWAN units, the following steps are necessary for each of the endpoints.

1. Define IKE Phase 1 parameters for establishment of ISAKMP Security Association with authenticated a remote peer.
2. Define IKE Phase 2 parameters for establishment of IPSec Security Association with authenticated a remote peer.
3. Create correspondent policies of NAT, Auto Routing (AR) and Tunnel Routing (TR) to correctly route the packets of IKE negotiations and IPSec VPN communications (will be discussed in next section, see “Define routing policies for an IPSec VPN”).

Configurations of IKE Phase 1

An IPSec VPN tunnel involves the connection of two FortiWAN units. Most of the settings used to establish an IPSec VPN tunnel are required to be corresponding on the both endpoints. Therefore, it is better to collect enough information in preparation for the configurations of an IPSec VPN tunnel.

Here are the items and information that you need to determine for IKE Phase 1 settings:

Defining the remote and local ends of the IPSec VPN tunnel

Basically, this is to specify the public IP addresses for the two ends (a local FortiWAN unit and a remote FortiWAN unit) of the IPSec VPN tunnel. The IPSec VPN tunnel is established through connection of the two public IP addresses. You need to determine the WAN link of a FortiWAN unit to connect with each other for an IPSec VPN tunnel; and the IP addresses deployed on the two WAN ports are actually the two ends (local IP and remote IP) of the IPSec VPN tunnel. FortiWAN’s IPSec VPN does not support dynamic IP addresses; it is only available for the WAN links that are deployed as Routing Mode, Bridge Mode: One Static IP or Bridge Mode: Multiple Static IP (see “Configuring your WAN” for details). For the settings of a IPSec VPN tunnel configured on the two endpoints, the Local IP of a FortiWAN unit becomes the Remote IP of the opposite FortiWAN unit and vice versa. An IPSec VPN tunnel consists of the IKE negotiations (for the security associations, SAs) and the data transmission tunnel; both are established through the two public IP addresses. You also have to give consideration to the limitation that we cannot deploy multiple IPSec connections between any two FortiWANs on the same local or remote IP address. See “Limitation in the IPSec deployment” for details.

A pre-shared key used to authenticate the FortiWAN unit to the remote unit

During the IKE Phase 1 negotiations, a FortiWAN unit need to authenticate itself to the remote unit by a preshared key. The two endpoints of an IPSec VPN tunnel share a common key in advance, so that they can authenticate itself to each other with the common key, like a password. You need to distribute the pre-shared key in a secure way. The pre-shared key configured on the two endpoints of a IPSec VPN tunnel must be equal, or the establishment of IPSec Security Association goes to failure (failed authentication results in failure of IKE Phase 1

and Phase 2.

The modes for parameters exchanging, Main mode and Aggressive mode, used for IKE Phase 1 negotiations

A FortiWAN unit exchange Phase 1 parameters with the remote unit in only Main mode. In Main mode, the Phase 1 parameters are exchanged in six messages with encrypted authentication information. As the previous introductions, Main mode gives securer authentication by a encryption with the negotiated secret key. By comparison, Aggressive mode is weak in authentication since the lack of encryption. However, with the simplified exchanging process, Aggressive mode is faster than Main mode indeed. Security and efficiency are the considerations you need to evaluate for IKE Phase 1 negotiations. Once it is determined, both the two endpoints must be configured with the same mode.

Enable Dead Peer Detection (DPD) or not

The connectivity between two endpoints communicating through IPSec may goes down unexpectedly due to routing problems, hardware broken, host rebooting, etc. In the situation, however, the IPSec entities are not aware of the loss of peer connectivity (availability of peer), and the security associations (SAs) of each peer remains. Packets of communication will continue being sent to oblivion, and reestablishment goes to failure. Dead Peer Detection (DPD) is such a method, by sending periodic HELLO/ACK messages, to confirm the availability of an IPSec endpoint, recognize a disconnection, reclaim the lost resources (SAs) and reestablish IKE negotiations automatically. When a disconnection is detected, the active ISAKMP SA and the correspondent IPSec SAs are removed and renegotiated immediately whether the secret keys expire or not.FortiWAN’s IPSec DPD is performed in the Always Send mode, which the detection messages are sent at configured intervals regardless of traffic activity between the peers (some products probe for a idle tunnel before sending DPD detection messages, but FortiWAN does not). Related SAs would be removed once a disconnection is recognized by FortiWAN’s IPSec DPD, but FortiWAN would not automatically perform the reestablishment (new establishment of the SAs is triggered only if an outgoing packets of the IPSec communication arrive at the FortiWAN unit).