Setting VPN IPSec tunnel with Fortigate

In this post we will see how to configure an IPSEC VPN tunnel between two remote locations through Fortigate firewalls.

The scenario that we will use as example is the following:

The objective will be to create a IPSEC VPN tunnel that communicates securely both offices (10.11.1.0/24 and 10.11.2.0/24). We will need to configure both firewalls FGT1 and FGT2 accordingly to stablish that tunnel.

The establishment of an IPSEC VPN tunnel consists of two phases:

During IKE Phase I

The peers authenticate, either by certificates or via a pre-shared secret. A Diffie-Hellman key is created. The nature of the Diffie-Hellman protocol means that both sides can independently create a shared secret, a key which is known only to the peers. Key material (random bits and other mathematical data) as well as an agreement on methods for IKE phase II are exchanged between the peers.

The initiator and recipient send three two-way exchanges (six messages total) to accomplish the following services:

1. First exchange (messages 1 and 2)—Proposes and accepts the encryption and authentication algorithms. The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in each peer
2. Second exchange (messages 3 and 4)—Executes a DH exchange by exchanging public and private keys. Through math they arrive at a symmetric shared key
3. Third exchange (messages 5 and 6)—Sends and verifies the identities of the initiator and recipient.
   The information transmitted in the third exchange of messages is protected by the encryption algorithm established in the first two exchanges. The identity value is the IPSec peer’s IP address in encrypted form.

During IKE Phase II

The purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase 2 performs the following functions:

1. Negotiates IPSec SA parameters protected by an existing IKE SA stablished on Phase I
2. Establishes IPSec security associations

The IPsec SA is an agreement on keys and methods for IPsec. By default, the phase 2 security association (SA) is not negotiated until a peer attempts to send data.

Configure a VPN IPSec tunnel on Fortigate

Now we proceed to show how to configure a VPN IPSec tunnel on a Fortigate appliance. We will take the config of the appliance “FGT1” of our example.

Inside the Fortigate’s web UI navigate to “VPN > IPSec Wizard”.

• Enter the name of the VPN tunnel, choose the “Site to Site” configuration and choose Fortigate as the remote device as well (no matter if the remote device is not Fortigate we could change the config later)

• Enter the public IP address of the remote device (in our case of FGT2) and write the pre-shared (FGT2 must be configured with the same pre-sahred key)

• Enter the local subnet which will use the VPN as well as the remote subnet which the local office will be capable of connect to.

After pressing “Create” several thigs will be configured on Fortigate device:

• A static route in order to send all traffic destined to the remote subnet through the VPN

• Two access policies in order to allow traffic between local subnet and remote VPN subnet

• A VPN interface associated with the physical interface

• And of course, the VPN IPSec tunnel (which will be Inactive/Down until remote device FGT2 will be configured)

NOTE: If the remote device is not a Fortigate device we can modify the IKE Phase I and Phase II parameters editing the tunnel:

Once VPN Tunnel is configured on the remote device FGT2, if we perform a packet capture on WAN interface in FGT1 we will see the exchange of packets negotiating IKE Phase I:

If we inspect that packets we will see the first exchange is negotiating the ISAKMP security association, the second exchange is private/public Diffie Hellman key exchange and the third exchange will be the authentication of each peer using the pre-shared key encrypting that exchange:

Testing the VPN connection

IKE Phase II will not be negotiated until there is any traffic through the VPN, so we can force traffic to go through the VPN tunnel. To do that we must connect via SSH to FGT1 for example and execute the following commands:

NOTE: We must configure the ping option to use as source IP the local interface in order to get that ping routed through the VPN

Now, we can see that VPN tunnel is UP:

In fact, if we perform a packet capture on WAN interface in FGT1 we will see the IKE Phase II echange (ISAKMP packets) and then the encrypted ping traffic (ESP packets):

Troubleshooting the VPN connection

If the ping doesn’t work and the VPN tunnel doesn’t come up, we must debug the VPN connection. In order to do that, we should connect via SSH to one of the nodes (FGT1 for example) and execute the following commands:

With above commands we start to debug all IKE events on FGT1. Then open a new SSH terminal on FGT1 and execute the following command in order to reset the VPN tunnel:

As example, a proper VPN connection stablishmen will look like the following debug trace:

IKE Phase I:

IKE Phase II:

Example I: Pre-shared key doesn’t match

If pre-shared key doesn’t match on both nodes, we will see something like the following on the debug trace:

Example II: Diffie Hellman groups doesn’t match in any case

If both nodes cannot choose a common Diffie Hellman group the Phase II will not complete and we will see something like this: