Professional Documents
Culture Documents
LAB 5 - Configuring A Site-to-Site IPsec VPN
LAB 5 - Configuring A Site-to-Site IPsec VPN
© FORTINET
Lab 5: Configuring a Site-to-Site IPsec VPN
In this lab, you will configure a point-to-point IPsec VPN between two FortiGate devices. You will also configure
redundant VPN tunnels with failover capability between the two FortiGate devices.
Objectives
l Deploy a site-to-site VPN between two FortiGate devices.
l Compare route-based to policy-based VPNs.
l Monitor VPN tunnels.
l Configure redundant VPNs between two FortiGate devices.
Time to Complete
Estimated: 60 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Remote-FortiGate and Local-FortiGate.
Make sure to restore the correct configuration on each FortiGate using the following
steps. Failure to restore the correct configuration on each FortiGate will prevent you
from doing the lab exercise.
© FORTINET
During this lab, you will configure an IPsec tunnel between Local-FortiGate and the Remote-FortiGate for
communication between the Local-Windows VM and Remote-Windows VM.
Now, you will configure Local-FortiGate using the VPN wizard, which creates the IPsec in route-based mode.
Field Value
Name ToRemote
5. Click Next .
6. Configure the following settings:
Field Value
IP Address 10.200.3.1
7. Click Next.
8. Configure the following settings:
© FORTINET
Field Value
9. Click Create.
You should see the following screen:
Now, you will review the objects that were created by the VPN wizard.
© FORTINET
You will need this information to configure the other FortiGate. The quick mode selectors on both sides must
mirror each other. In other words, the Local Address on one side must match the Remote Address on the
other side.
3. Click Cancel.
4. Click Network > Interfaces.
5. Click the plus (+) icon that appears beside port1.
You will see a new virtual interface named ToRemote (matching the phase 1 name).
The wizard created the VPN using a route-based configuration. FortiGate automatically adds an IPsec
virtual interface for each VPN configured as route-based. This does not happen in a policy-based
configuration.
© FORTINET
A route-based VPN requires firewall policies and at least one route to the remote network. As you will see, the
wizard has created all of these additional objects for you.
5. Click Policy & Objects > Addresses, and then click + sign to expand Address and Address Group.
Observe two new firewall address objects: ToRemote_local_subnet_1, and ToRemote_remote_subnet_
1.
7. Click Network > Static Routes, and look at the static route added by the wizard.
© FORTINET
FortiGate drops all packets routed to the blackhole interface. The IPsec wizard added two static routes: one
to the IPsec virtual interface, with a distance of 10 and one to the blackhole interface, with a distance of
254. The route with the lowest distance, the one to the IPsec virtual interface, takes precedence. However,
if the VPN is down, the route to the blackhole interface becomes active,even though it was originally the
higher-distance route. So, traffic destined to the VPN is now routed to the blackhole interface and dropped.
The route to the blackhole interface prevents FortiGate from sending VPN traffic to the default route while
the VPN is down. The route to the blackhole interface also prevents FortiGate from creating unnecessary
sessions in the session table.
For learning purposes, you will configure the second FortiGate device differently. During this exercise, you will
create the VPN on Remote-FortiGate using a policy-based configuration, without using the wizard.
By default, policy-based configurations are hidden in the GUI. Now, you will show policy-based VPN settings in
the GUI.
Field Value
Name ToLocal
4. Click Next.
5. Disable Enable IPsec Interface Mode.
© FORTINET
6. Configure the following settings:
Field Value
IP Address 10.200.1.1
Interface port4
Field Value
© FORTINET
Now the quick mode selectors on both sides mirror each other. If that is not the case,
the tunnel will not come up.
Now, you will create a firewall policy to allow traffic. In a policy-based configuration, only one policy is required to
allow traffic initiated on either side. The policy is applied bidirectionally.
Field Value
Source REMOTE_SUBNET
Destination LOCAL_SUBNET
Schedule always
Service ALL
Action IPsec
© FORTINET
Field Value
4. Click OK.
This is probably the first time you have seen the action IPsec for a firewall policy. In
previous exercises, the available actions were Accept and Deny only. IPsec is
displayed in the GUI only when the policy-based VPN settings are not hidden.
The new policy was created below the firewall policy for Internet traffic. Now, you will need to move the new
policy up for the VPN traffic to match it.
© FORTINET
Stop and think!
In the previous exercise, the VPN wizard added a static route for the VPN traffic. Why don't you need to add
a static route in this case?
The VPN wizard creates the IPsec using a route-based configuration, which always requires additional
routes (usually static routes) to route the traffic through the IPsec virtual interface. This is usually not
required in a policy-based configuration. Policy-based configurations require the VPN traffic to match a
firewall policy with the action IPsec. Because traffic from 10.0.2.0/24 to 10.0.1.0/24 matches the
existing default route, and so the IPsec firewall policy from port6 to port4, no additional routes are needed.
You have finished the configuration on both FortiGate devices. Now, you will test the VPN.
The Status column of the VPN contains a green up arrow, indicating that the tunnel is up.
No. In the current configuration, the tunnel will stay down until you either bring it up manually, or there is
traffic that should be routed through the tunnel. Because you are not generating traffic between
10.0.1.0/24 and 10.0.2.0/24 yet, the tunnel is still down. If you had generated the required traffic
while the tunnel was down, it would have come up automatically.
4. On the Local-Windows VM, open a command prompt window, and then run the following command to ping
Remote-Windows:
ping 10.0.2.10
© FORTINET
You will notice that counters for Incoming Data and Outgoing Data have increased. This indicates that the
traffic between 10.0.1.10 and 10.0.2.10 is successfully being encrypted and routed through the tunnel.
In this exercise, you will configure one VPN for redundancy between Local-FortiGate and Remote-FortiGate.
Prerequisites
Before beginning this lab, you must restore a configuration file on Remote-FortiGate and Local-FortiGate.
Make sure to restore the correct configuration on each FortiGate using the following
steps. Failure to restore the correct configuration on each FortiGate will prevent you
from doing the lab exercise.
Once you load the configurations, Remote-FortiGate will be pre-configured for VPN
redundancy. The steps to configure Remote-FortiGate are included in this exercise,
however, this exercise provides instructions where you can review this configuration
for Remote-FortiGate.
© FORTINET
To restore the Local-FortiGate configuration file
1. On the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 with the user
name admin and password password.
2. In the upper-right corner of the screen, click admin, and then click Configuration > Restore.
Now, you will configure the IPsec VPN by creating phases 1 and 2.
Field Value
Name Remote_1
4. Click Next.
5. In the Network section, configure the following settings:
© FORTINET
Field Value
IP Address 10.200.3.1
Interface port1
Field Value
The VPN was created as route-based. This means that the VPN requires at least one route (static or dynamic) to
forward the traffic through the tunnel. Now, you will create a static route for that purpose.
Field Value
Destination Subnet
10.0.2.0/24
Interface Remote_1
4. Click OK.
Now, you will create an interface zone that will includes the two IPsec virtual interfaces (the virtual IPsec
interfaces for the primary and secondary VPNs). It is not mandatory to have an interface zone for redundant
VPNs, but it minimizes the number of firewall policies you must create later.
© FORTINET
To create an interface zone
1. Continuing on the Local-FortiGate GUI, click Network > Interfaces.
2. Click Create New, and then select Zone.
Field Value
Name VPN
4. Click OK.
You will add a second VPN interface to the zone in a later exercise, when you
configure a backup VPN.
Now, you will create two firewall policies between port3 and VPN , one for each traffic direction.
Field Value
Name Remote_out
Source LOCAL_SUBNET
© FORTINET
Field Value
Destination REMOTE_SUBNET
Schedule always
Service ALL
Action ACCEPT
Field Value
Name Remote_in
Source REMOTE_SUBNET
Destination LOCAL_SUBNET
Schedule always
Service ALL
Action ACCEPT
© FORTINET
Review the VPN Configuration on Remote-FortiGate
For the purposes of this lab, Remote-FortiGate is preconfigured for you. This configuration was included in the
configuration file you uploaded at the beginning of this exercise. You can review this configuration by completing
the steps that follow.
Now, you will test the VPN by generating some traffic and confirming that the VPN comes up.
FortiGate may not have previously established the VPN. If so, the first few pings will
fail while FortiGate negotiates and establishes the VPN.
3. Return to the browser tab where you are logged into the Local-FortiGate GUI, and click Monitor > IPsec
Monitor.
4. Confirm that the Remote_1 VPN is up.
You should see a green arrow in the Status column.
In this exercise, you will create a second route-based VPN for redundancy. This time, configure the VPN from
Local-FortiGate port2 to Remote-FortiGate port5.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Review the Backup VPN Configuration on Remote-FortiGate on
page 93.
© FORTINET
3. Click Network > Static Routes.
4. Click Create New.
5. Add the following static route:
Field Value
Destination Subnet
10.0.2.0/24
Interface Remote_2
Administrative Distance 20
6. Click OK.
7. Click Network > Interfaces.
8. Edit the zone VPN .
9. In the Interface Members field, add Remote_2.
10. Click OK.
For the purpose of this lab, Remote-FortiGate is preconfigured for you. This configuration was included in the
configuration file you uploaded at the beginning of the previous exercise. You can review this configuration by
completing the steps that follow.
Now, you will test the VPN failover. You will use the sniffer tool to monitor which VPN the traffic is using.
© FORTINET
diagnose sniffer packet any 'icmp and host 10.0.2.10' 4
4. Open a command prompt window, and then run a continuous ping to Remote-Windows:
ping –t 10.0.2.10
5. Return the the PuTTY session and view the sniffer output.
It will show that Local-FortiGate is routing the packets through the VPN Remote_1:
Now, you will simulate a failure in the VPN Remote_1 and observe how the FortiGate starts using the
secondary VPN Remote_2.
6. Return to the browser tab where you are logged into the Local-FortiGate GUI, and click Network > Interfaces.
7. Edit port1.
8. Set the Interface State to Disabled to bring down the tunnel Remote_1.
9. Click OK.
10. Wait a few minutes until FortiGate detects the failure in the VPN Remote_1 and reroutes the traffic through
Remote_2.
11. Return to the PuTTY session and view the sniffer output again.
Notice that the VPN Remote_2 is being used now:
Omitting these last steps may prevent you from doing the next exercise.