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.