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
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.
Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!
Don't Forget To visit the YouTube Channel for the latest Fortinet Training Videos and Question / Answer sessions!
- FortinetGuru YouTube Channel
- FortiSwitch Training Videos