Gateway-to-gateway

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

The following topics are included in this section:

Configuration overview

Gateway-to-gateway configuration

How to work with overlapping subnets Testing

Configuration overview

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

Example gateway-to-gateway configuration

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

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

Configuration overview

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

Configuration overview

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

Fully meshed configuration

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

 

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.

Gateway-to-gateway configuration

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.

Gateway-to-gateway configuration

Configuring Phase 1 and Phase 2 for both peers

This procedure applies to both peers. Repeat the procedure on each FortiGate unit, using the correct IP address for each. You may wish to vary the Phase 1 names but this is optional. Otherwise all steps are the same for each peer.

The Phase 1 configuration defines the parameters that FortiGate_1 will use to authenticate FortiGate_2 and establish a secure connection. For the purposes of this example, a preshared key will be used to authenticate FortiGate_2. The same preshared key must be specified at both FortiGate units. Before you define the Phase 1 parameters, you need to:

• Reserve a name for the remote gateway.
• Obtain the IP address of the public interface to the remote peer. l Reserve a unique value for the preshared key.

The key must contain 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 have a minimum of 16 randomly chosen alphanumeric characters.

At the local FortiGate unit, define the Phase 1 configuration needed to establish a secure connection with the remote peer. See IPsec VPN in the web-based manager on page 38.

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). Enter the following information, and select OK.

Name	Enter peer_1. 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.
IP Address	Enter 172.20.0.2 when configuring FortiGate_1. Enter 172.18.0.2 when configuring FortiGate_2. The IP address of the remote peer public interface.
Local Interface	Select wan1.

The basic Phase 2 settings associate IPsec Phase 2 parameters with the Phase 1 configuration and specify the remote end point of the VPN tunnel. Before you define the Phase 2 parameters, you need to reserve a name for the tunnel. See IPsec VPN in the web-based manager on page 38.

1. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
2. Enter a Name of peer_1_p2.
3. Select peer_1 from the Phase 1 drop-down menu.

Creating security policies

Security policies control all IP traffic passing between a source address and a destination address.

An IPsec security policy is needed to allow the transmission of encrypted packets, specify the permitted direction of VPN traffic, and select the VPN tunnel that will be subject to the policy. A single policy is needed to control both inbound and outbound IP traffic through a VPN tunnel.

Before you define security policies, you must first specify the IP source and destination addresses. In a gatewayto-gateway configuration:

• The IP source address corresponds to the private network behind the local FortiGate unit. l The IP destination address refers to the private network behind the remote VPN peer.

When you are creating security policies, choose one of either route-based or policy-based methods and follow it for both VPN peers. DO NOT configure both route-based and policy-based policies on the same FortiGate unit for the same VPN tunnel.

The configuration of FortiGate_2 is similar to that of FortiGate_1. You must:

• Define the Phase 1 parameters that FortiGate_2 needs to authenticate FortiGate_1 and establish a secure connection.
• Define the Phase 2 parameters that FortiGate_2 needs to create a VPN tunnel with FortiGate_1.
• Create the security policy and define the scope of permitted services between the IP source and destination addresses.

When creating security policies it is good practice to include a comment describing what the policy does.

Creating firewall addresses

Define names for the addresses or address ranges of the private networks that the VPN links. These addresses are used in the security policies that permit communication between the networks.

To define the IP address of the network behind FortiGate_1

1. Go to Policy & Objects > Addresses and select Create New.
2. Enter the Name of Finance_network. Select a Type of Subnet.
3. Enter the Subnet of 21.101.0/24.
4. Select OK.

To specify the address of the network behind FortiGate_2

1. Go to Policy & Objects > Addresses and select Create New.
2. Enter the Name of HR_network.
3. Select a Type of Subnet.
4. Enter the Subnet/IP Range of 31.101.0/24. 5. Select OK.

Creating route-based VPN security policies

Define an ACCEPT security policy to permit communications between the source and destination addresses.

To create route-based VPN 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.

Gateway-to-gateway configuration

3. Enter the following, and select OK.

Incoming Interface	Select internal. The interface that connects to the private network behind this FortiGate unit.
Source Address	Select Finance_network when configuring FortiGate_1. Select HR_network when configuring FortiGate_2. The address name for the private network behind this FortiGate unit.
Outgoing Interface	Select peer_1. The VPN Tunnel (IPsec Interface) you configured earlier.
Destination Address	Select HR_network when configuring FortiGate_1. Select Finance_network when configuring FortiGate_2. The address name that you defined for the private network behind the remote peer.
Action	Select ACCEPT.
Enable NAT	Disable.
Comments	Allow Internal to remote VPN network traffic.

4. Optionally, configure any additional features you may want, such as UTM or traffic shaping.
5. Select Create New to create another policy for the other direction.
6. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
7. Enter the following information, and select OK.

Incoming Interface	Select peer_1. The VPN Tunnel (IPsec Interface) you configured.
Source Address	Select HR_network when configuring FortiGate_1. Select Finance_Network when configuring FortiGate_2. The address name defined for the private network behind the remote peer.
Outgoing Interface	Select internal. The interface that connects to the private network behind this FortiGate unit.
Destination Address		Select Finance_Network when configuring FortiGate_1. Select HR_network when configuring FortiGate_2. The address name defined for the private network behind this FortiGate unit.
Action		Select ACCEPT.
Enable NAT		Disable.
Comments		Allow remote VPN network traffic to Internal.

8. Configure any additional features such as UTM or traffic shaping you may want. (optional).

All network traffic must have a static route to direct its traffic to the proper destination. Without a route, traffic will not flow even if the security policies are configured properly. You may need to create a static route entry for both directions of VPN traffic if your security policies allow bi-directional tunnel initiation.

To configure the route for a route-based VPN:

1. On FortiGate_2, go to Network > Static Routes and select Create New.
2. Enter the following information, and then select OK:

Destination IP / Mask	10.21.101.0/24
Device	FGT2_to_FGT1_Tunnel
Gateway	Leave as default: 0.0.0.0.
Distance (Advanced)	Leave this at its default. If there are other routes on this FortiGate unit, you may need to set the distance on this route so the VPN traffic will use it as the default route. However, this normally happens by default because this route is typically a better match than the generic default route.

Creating policy-based VPN security policy

Define an IPsec security policy to permit communications between the source and destination addresses.

1. Go to Policy & Objects > IPv4 Policy.
2. Complete the following:

Incoming Interface

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

 

Source Address	Select Finance_network when configuring FortiGate_1. Select HR_network when configuring FortiGate_2. The address name defined for the private network behind this FortiGate unit.
Outgoing Interface	Select wan1. The FortiGate unit’s public interface.
Destination Address	Select HR_network when configuring FortiGate_1. Select Finance_network when configuring FortiGate_2.
VPN Tunnel	Select Use Existing and select peer_1 from the VPN Tunnel drop-down list. Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.
Comments	Bidirectional policy-based VPN policy.

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

How to work with overlapping subnets

A site-to-site VPN configuration sometimes has the problem that the private subnet addresses at each end are the same. You can resolve this problem by remapping the private addresses using virtual IP addresses (VIP).

VIPs allow computers on those overlapping private subnets to each have another set of IP addresses that can be used without confusion. The FortiGate unit maps the VIP addresses to the original addresses. This means if PC1 starts a session with PC2 at 10.31.101.10, FortiGate_2 directs that session to 10.11.101.10 — the actual IP address of PC2.The figure below demonstrates this — Finance network VIP is 10.21.101.0/24 and the HR network is 10.31.101.0/24.

How to work with overlapping subnets

Overlapped subnets example

Solution for route-based VPN

You need to:

• Configure IPsec Phase 1 and Phase 2 as you usually would for a route-based VPN. In this example, the resulting IPsec interface is named FGT1_to_FGT2.
• Configure virtual IP (VIP) mapping:
• the 10.21.101.0/24 network mapped to the 10.11.101.0/24 network on FortiGate_1
• the 10.31.101.0/24 network mapped to the 10.11.101.0/24 network on FortiGate_2 l Configure an outgoing security policy with ordinary source NAT on both FortiGates.
• Configure an incoming security policy with the VIP as the destination on both FortiGates.
• Configure a route to the remote private network over the IPsec interface on both FortiGates.

To configure VIP mapping on both FortiGates

1. Go to Policy & Objects > Virtual IPs and create a new Virtual IP.
2. Enter the following information, and select OK:

	Name		Enter a name, for example, my_vip.
	External Interface		Select FGT1_to_FGT2. The IPsec interface.
VIP Type		Depending on both FortiGates, select one of the following options: l    IPv4: If both FortiGates use IPv4 (Static NAT). l    IPv6: If both FortiGates use IPv6 (Static NAT). l    NAT46: Maps the IPv4 address into an IPv6 prefix. l    NAT64: Maps the IPv6 address into an IPv4 prefix.
External IP Address/Range		For the External IP Address field enter: 10.21.101.1  when configuring FortiGate_1, or 10.31.101.1  when configuring FortiGate_2.
Mapped IP Address/Range		For the Mapped IP Address enter 10.11.101.1. For the Range enter 10.11.101.254.
Port Forwarding		Disable

3. Repeat this procedure on both FortiGate_1 and FortiGate_2.

To configure the outbound security policy on both FortiGates

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

Incoming Interface	Select Port 1.
Outgoing Interface	Select FGT1_to_FGT2. The IPsec interface.
Source	Select all.
Destination Address	Select all.
Action	Select ACCEPT
NAT	Enable NAT.

3. Repeat this procedure on both FortiGate_1 and FortiGate_2.

To configure the inbound security policy on both FortiGates

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

Incoming Interface

Select FGT1_to_FGT2.

How to work with overlapping subnets

Outgoing Interface	Select Port 1. The IPsec interface.
Source	Select all.
Destination Address	Select my-vip.
Action	Select ACCEPT
NAT	Disable NAT.

3. Repeat this procedure on both FortiGate_1 and FortiGate_2.

To configure the static route for both FortiGates

1. Go to Network > Static Routes and create a new Route (or IPv6 Route as necessary).
2. Enter the following information, and then select OK:

Destination	Enter a subnet of 10.31.101.0/24 when configuring FortiGate_1. Enter a subnet of 10.21.101.0/24 when configuring FortiGate_2.
Device	Select FGT1_to_FGT2.
Gateway	Leave as default: 0.0.0.0.
Administrative Distance	Leave at default (10). If you have advanced routing on your network, you may have to change this value.
Advanced Options	If you have advanced routing on your network, enable Advanced Options and enter a Priority.

Solution for policy-based VPN

As with the route-based solution, users contact hosts at the other end of the VPN using an alternate subnet address. PC1 communicates with PC2 using IP address 10.31.101.10, and PC2 communicates with PC1 using IP address 10.21.101.10.

In this solution however, outbound NAT is used to translate the source address of packets from the

10.11.101.0/24 network to the alternate subnet address that hosts at the other end of the VPN use to reply. Inbound packets from the remote end have their destination addresses translated back to the 10.11.101.0/24 network.

For example, PC1 uses the destination address 10.31.101.10 to contact PC2. Outbound NAT on FortiGate_1 translates the PC1 source address to 10.21.101.10. At the FortiGate_2 end of the tunnel, the outbound NAT configuration translates the destination address to the actual PC2 address of 10.11.101.10. Similarly, PC2 replies to PC1 using destination address 10.21.101.10, with the PC2 source address translated to 10.31.101.10. PC1 and PC2 can communicate over the VPN even though they both have the same IP address.

You need to:

• Configure IPsec Phase 1 as you usually would for a policy-based VPN. l Configure IPsec Phase 2 with the use-natip disable CLI option.  l Define a firewall address for the local private network, 10.11.101.0/24.
• Define a firewall address for the remote private network:
• Define a firewall address for 10.31.101.0/24 on FortiGate_1
• Define a firewall address for 10.21.101.0/24 on FortiGate_2
• Configure an outgoing IPsec security policy with outbound NAT to map 10.11.101.0/24 source addresses:
• To the 10.21.101.0/24 network on FortiGate_1
• To the 10.31.101.0/24 network on FortiGate_2

To configure IPsec Phase 2 – CLI

config vpn ipsec phase2 edit “FGT1_FGT2_p2” set keepalive enable set pfs enable set phase1name FGT1_to_FGT2 set proposal 3des-sha1 3des-md5 set replay enable set use-natip disable

end

In this example, your Phase 1 definition is named FGT1_to_FGT2. use-natip is set to disable, so you can specify the source selector using the src-addr-type, src-start-ip / src-end-ip or src-subnet keywords. This example leaves these keywords at their default values, which specify the subnet 0.0.0.0/0.

The pfs keyword ensures that perfect forward secrecy (PFS) is used. This ensures that each Phase 2 key created is unrelated to any other keys in use.

To define the local private network firewall address

1. Go to Policy & Objects > Addresses and create a new Address. 2. Enter the following information and select OK.

Category	Set to Address.
Name	Enter vpn-local. A meaningful name for the local private network.
Type	Set to IP/Netmask.
Subnet / IP Range	10.11.101.0 255.255.255.0
Interface	Set to any.

To define the remote private network firewall address

1. Go to Policy & Objects > Addresses and create a new Address.
2. Enter the following information, and select OK:

Category

Set to Address.

Testing

Name	Enter vpn-remote. A meaningful name for the remote private network.
Type	Set to IP/Netmask.
Subnet / IP Range	10.31.101.0 255.255.255.0 on FortiGate_1. 10.21.101.0 255.255.255.0 on FortiGate_2.
Interface	Any

To configure the IPsec security policy

In the CLI on FortiGate_1, enter the commands:

config firewall policy edit 1 set srcintf “port1” set dstintf “port2” set srcaddr “vpn-local” set dstaddr “vpn-remote” set action ipsec set schedule “always” set service “ANY” set inbound enable set outbound enable set vpntunnel “FGT1_to_FGT2” set natoutbound enable

set natip 10.31.101.0 255.255.255.0

end

Optionally, you can set everything except natip in the web-based manager and then use the CLI to set natip.

Enter the same commands on FortiGate_2, but set natip be 10.21.101.0 255.255.255.0.

Testing

The best testing is to look at the packets both as the VPN tunnel is negotiated, and when the tunnel is up.

Determining what the other end of the VPN tunnel is proposing

1. Start a terminal program such as PuTTY and set it to log all output.

When necessary refer to the logs to locate information when output is verbose.

2. Logon to the FortiGate unit using a super_admin account.
3. Enter the following CLI commands.
4. Display all the possible IKE error types and the number of times they have occurred:

 

diag vpn ike errors

 

5. Check for existing debug sessions:

 

diag debug info

 

 

Testing

If a debug session is running, to halt it enter:

diag debug disable

 

6. Confirm your proposal settings:

 

diag vpn ike config list

 

7. If your proposal settings do not match what you expect, make a change to it and save it to force an update in memory. If that fixes the problem, stop here.
8. List the current vpn filter:

 

diag vpn ike filter

 

9. If all fields are set to any, there are no filters set and all VPN IKE packets will be displayed in the debug output. If your system has only a few VPNs, skip setting the filter.

If your system has many VPN connections this will result in very verbose output and make it very difficult to locate the correct connection attempt.

10. Set the VPN filter to display only information from the destination IP address for example 10.10.10.10:

 

diag vpn ike log-filter dst-addr4 10.10.10.10

To add more filter options, enter them one per line as above. Other filter options are:

clear	erase the current filter
dst-addr6	the IPv6 destination address range to filter by
dst-port	the destination port range to filter by
interface	interface that IKE connection is negotiated over
list	display the current filter
name	the phase1 name to filter by
negate	negate the specified filter parameter
src-addr4	the IPv4 source address range to filter by
src-addr6	the IPv6 source address range to filter by
src-port	the source port range to filter by
vd	index of virtual domain. 0 matches all

11. Start debugging:

diag debug app ike 255 diag debug enable

 

12. Have the remote end attempt a VPN connection.

If the remote end attempts the connection they become the initiator. This situation makes it easier to debug VPN tunnels because then you have the remote information and all of your local information. by initiate the connection, Testing

you will not see the other end’s information.

13. If possible go to the web-based manager on your FortiGate unit, go to the VPN monitor and try to bring the tunnel up.
14. Stop the debug output:

 

diag debug disable

 

15. Go back through the output to determine what proposal information the initiator is using, and how it is different from your VPN P1 proposal settings.

Things to look for in the debug output of attempted VPN connections are shown below.

Important terms to look for in VPN debug output

initiator	Starts the VPN attempt, in the above procedure that is the remote end
responder	Answers the initiator’s request
local ID	In aggressive mode, this is not encrypted
error no SA proposal chosen	There was no proposal match — there was no encryption-authentication pair in common, usually occurs after a long list of proposal attempts
R U THERE and R U THERE ack	dead peer detection (dpd), also known as dead gateway detection — after three failed attempts to contact the remote end it will be declared dead, no farther attempts will be made to contact it
negotiation result	lists the proposal settings that were agreed on
SA_life_soft and SA_life_ hard	negotiating a new key, and the key life
R U THERE	If you see this, it means Phase 1 was successful
tunnel up	the negotiation was successful, the VPN tunnel is operational