Do Not Reprint © Fortinet: Fortigate Infrastructure Lab Guide

DO NOT REPRINT
© FORTINET
FortiGate Infrastructure Lab Guide

for FortiOS 5.6.2
DO NOT REPRINT
© FORTINET
Fortinet Training
http://www.fortinet.com/training
Fortinet Document Library
http://docs.fortinet.com
Fortinet Knowledge Base
http://kb.fortinet.com
Fortinet Forums
https://forum.fortinet.com
Fortinet Support
https://support.fortinet.com
FortiGuard Labs
http://www.fortiguard.com
Fortinet Network Security Expert Program (NSE)

https://www.fortinet.com/support-and-training/training/network-security-expert-program.html
Feedback
Email: courseware@fortinet.com
2/8/2018
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
Virtual Lab Basics 7

Network Topology 7
Lab Environment 7
System Checker 8
Logging In 9
Disconnections and Timeouts 12
Transferring Files to the VM 12
Screen Resolution 12
International Keyboards 13
Student Tools: View Broadcast and Raise Hand 13
Troubleshooting Tips 14
Lab 1: Routing 16
Exercise 1: Configuring Route Failover 17
Verify the Routing Configuration 17
Configure a Second Default Route 18
Configure the Firewall Policies 19
View the Routing Table 21
Configure Link Health Monitors 22
Test the route failover 22
Restore the routing table 25
Exercise 2: Equal Cost Multipath and Policy Routing 26
Configure Administrative Distance 26
Change the ECMP Load Balancing Method 27
Verify Traffic Routing 27
Configure Priority 28
Verify ECMP 29
Configure Policy Route for HTTPS Traffic 30
Verify the Policy Route 32
Lab 2: SD-WAN 35
Exercise 1: SD-WAN 36
Remove Interface References 36
Configure SD-WAN Load Balancing 37
Create a Static Route for the SD-WAN Interface 38
DO NOT REPRINT
© FORTINET
Create a Firewall Policy for SD-WAN Load Balancing 38
Verify the SD-WAN Load Balancing Configuration 39
Lab 3: Virtual Domains 41
Exercise 1: Creating VDOMs and VDOM Objects 43
Create a VDOM 43
Create a Per-VDOM Administrator 44
Move an Interface to a Different VDOM 45
Add DNS service to an Interface 46
Test the Per-VDOM Administrator Account 47
Execute Per-VDOM CLI Commands 47
Exercise 2: Inter-VDOM Link 49
Create an Inter-VDOM Link 49
Configure Routing Between VDOMs 50
Configure Firewall Policies for Inter-VDOM Traffic 52
Test the Inter-VDOM Link 54
Lab 4: Transparent Mode 55
Exercise 1: Transparent Mode VDOM 57
Create a Transparent Mode VDOM 57
Moving an Interface to a Different VDOM 58
Exercise 2: Inter-VDOM Link 60
Create an Inter-VDOM Link 60
Create firewall policies 61
Route Inter-VDOM traffic 64
Test the Transparent Mode VDOM 64
Lab 5: Configuring a Site-to-Site IPsec VPN 67
Exercise 1: Configuring Route-Based IPsec VPN 69
Create a VPN Using the VPN Wizard 69
Review the Objects Created by the VPN Wizard 70
Exercise 2: Configuring Policy-Based IPsec VPN 73
Show Policy-Based VPN Settings in the GUI 73
Create a Policy-Based VPN 73
Create a Firewall Policy for a Policy-Based VPN 75
Move a Firewall Policy 76
Exercise 3: Testing and Monitoring the VPN 78
Test the VPN 78
Exercise 4: Configuring an IPsec VPN Between Two FortiGate Devices 79
Prerequisites 79
Create Phases 1 and 2 on Local-FortiGate 80
Create a Static Route for a Route-based VPN on Local-FortiGate 81
Create an Interface Zone on Local-FortiGate 81
Create Firewall Policies for VPN Traffic on Local-FortiGate 82
DO NOT REPRINT
© FORTINET
Review the VPN Configuration on Remote-FortiGate 84
Test the IPsec VPN 84
Exercise 5: Configuring a Backup IPsec VPN 85
Configure a Backup VPN on Local-FortiGate 85
Review the Backup VPN Configuration on Remote-FortiGate 86
Test the VPN Redundancy 86
Lab 6: Fortinet Single Sign-On (FSSO) 88
Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode 89
Install the FSSO Collector Agent 89
Configure the FSSO Collector Agent 91
Configure SSO on FortiGate 95
Assign Polled FSSO Users to a Firewall Policy 96
Test FSSO 97
Lab 7: High Availability (HA) 101
Lab HA Topology 101
Exercise 1: Configuring High Availability (HA) 103
Configure HA Settings on Local-FortiGate 103
Configure HA Settings on Remote-FortiGate 104
Observe and Verify the HA Synchronization Status 105
Verify FortiGate Roles in a HA Cluster 106
View Session Statistics 106
Exercise 2: High Availability Failover 108
Trigger Failover by Rebooting the Primary FortiGate 108
Verify the HA Failover and FortiGate Roles 109
Trigger an HA Failover by Resetting the HA Uptime 109
Observe HA Failover Using Diagnostic Commands 110
Exercise 3: Configuring the HA Management Interface 112
Access the Secondary FortiGate through the Primary FortiGate CLI 112
Set Up a Management Interface 113
Configure and Access the Primary FortiGate Using the Management Interface 114
Configure and Access the Secondary FortiGate Using the Management Interface 114
Disconnect FortiGate From the Cluster 115
Restore the Remote-FortiGate Configuration 116
Lab 8: Web Proxy 119
Exercise 1: Configuring an Explicit Web Proxy 120
Show the Explicit Web Proxy Settings 120
Enable Explicit Web Proxy 120
Create an Authentication Scheme 120
Create an Authentication Rule 121
Create a Proxy Policy 121
Configure Firefox for Explicit Web Proxy 122
DO NOT REPRINT
© FORTINET
Test the Explicit Web Proxy Configuration 124
List the Active Explicit Web Proxy Users 125
List the Active Explicit Web Proxy Sessions 125
Exercise 2: Configuring the Transparent Web Proxy 127
Disable the Explicit Web Proxy in Firefox 127
Redirect the Traffic to the Transparent Web Proxy 128
Create the Proxy Policies 130
Testing the Transparent Web Proxy 131
Lab 9: Diagnostics 133
Exercise 1: Knowing What is Happening Now 134
Execute Diagnostic Commands 134
Exercise 2: Troubleshooting a Connectivity Problem 136
Identify the Problem 136
Use the Sniffer 136
Use the Debug Flow Tool 137
Fix the Problem 138
Test the Fix 138
DO NOT REPRINT
Virtual Lab Basics Network Topology
© FORTINET
Virtual Lab Basics
In this course, you will use a virtual lab for hands-on exercises. This section explains how to connect to the lab
and its virtual machines. It also shows the topology of the virtual machines in the lab.
If your trainer asks you to use a different lab, such as devices physically located in your
classroom, then ignore this section. This section applies only to the virtual lab
accessed through the Internet. If you do not know which lab to use, please ask your
trainer.
Network Topology
Lab Environment
Fortinet's virtual lab for hands-on exercises is hosted on remote datacenters that allow each student to have their
own training lab environment or point of deliveries (PoD).
FortiGate Infrastructure Lab Guide 7

Fortinet Technologies Inc.
DO NOT REPRINT
System Checker Virtual Lab Basics
© FORTINET
System Checker
Before starting any course, check if your computer can connect to the remote datacenters successfully. The
System Checker fully verifies if your network connection and your web browser can support a reliable connection
to the virtual lab.
You do not have to be logged in to the lab portal in order to run the System Checker.
To run the System Checker

1. Click the URL for your location:
Region System Checker
AMER - North and South https://remotelabs.training.fortinet.com/training/syscheck/?location=NAM-

America West
EMEA - Europe, Middle East https://remotelabs.training.fortinet.com/training/syscheck/?location=Europe

and Africa
APAC - Asia and Pacific https://remotelabs.training.fortinet.com/training/syscheck/?location=APAC
If your computer connects successfully to the virtual lab, the Browser Check and Network Connection
Check each display a check mark icon. You can then proceed to log in.
If either of the tests fail:
l Browser Check: This affects your ability to access the virtual lab environment.
l Network Connection Check: This affects the usability of the virtual lab environment.
For solutions, click the Support Knowledge Base link, or ask your trainer.
8 FortiGate Infrastructure Lab Guide

DO NOT REPRINT
Virtual Lab Basics Logging In
© FORTINET
Logging In
After you use the system checker to confirm that your system can run the labs successfully, you can proceed to
log in.
To log on to the remote lab

1. Using the user name and password provided by your trainer, do one of the following:
l On the Check My System result screen, click LOGIN .
l Go to the URL for the virtual lab provided by your trainer, and then click LOGIN :
https://remotelabs.training.fortinet.com/

DO NOT REPRINT
Logging In Virtual Lab Basics
© FORTINET
l https://virtual.mclabs.com/
2. If prompted, select the time zone for your location, and then click Update.
This ensures that your class schedule is accurate.
3. Click Enter Lab.

DO NOT REPRINT
Virtual Lab Basics Logging In
© FORTINET
Your system dashboard appears, listing the virtual machines (VM) in your lab topology.
4. To open a VM, on the dashboard, do one of the following:

l Click a VM's thumbnail.
l In the System drop-down list for the VM you want to open, select Open.
Follow the same procedure to access any of your VMs.

DO NOT REPRINT
Disconnections and Timeouts Virtual Lab Basics
© FORTINET
A new web browser tab opens, granting you access to the virtual device. When you open a VM, your browser
uses HTML5 to connect to it.
Depending on the VM you select, the web browser provides access to either a text-based CLI or the GUI.
Connections to the Local-Windows VM use a GUI similar to a remote desktop. When you use a web-based
connection, you are logged in automatically and the Windows desktop opens.
For most lab exercises, you will connect to the Local-Windows VM.
Disconnections and Timeouts
If your computer’s connection to the VM times out or closes, to regain access, return to the window or tab that
contains the list of VMs for your session and reopen the VM.
If that fails, see Troubleshooting Tips on page 14.
Transferring Files to the VM
If you store files in a cloud service such as Dropbox or SugarSync, you can use the web browser to download the
files to your Local-Windows VM.
On the VM, you can use a web browser to upload the files to the Fortinet VM GUI.
After you connect your computerto a VM, a web browser opens in a new applet window.
Screen Resolution
The GUIs of some Fortinet devices require a minimum screen size.
To configure screen resolution in the HTML5 client, open the System menu.

DO NOT REPRINT
Virtual Lab Basics International Keyboards
© FORTINET
International Keyboards
If characters in your language don’t display correctly, keyboard mappings may not be correct.
To solve this, at the top of GUI, in the Keyboard drop-down list, select Show On-Screen Keyboard.
Student Tools: View Broadcast and Raise Hand
Your instructor can broadcast the lab systems to allow students to see ongoing tasks in real time. When an
instructor begins a broadcast, you will receive an alert at the top of all open lab pages.
To accept and view the broadcast, click the notification message or, on the left side of the window, click View
Broadcast.
If you have a question or comment, on the left side of the window, click Raise Hand. Your instructor will be
notified and will assist you.

DO NOT REPRINT
Troubleshooting Tips Virtual Lab Basics
© FORTINET
Troubleshooting Tips
l Do not connect to the virtual lab environment through Wi-Fi, 3G, VPN tunnels, or other low-bandwidth or high-
latency connections.
l For best performance, use a stable broadband connection, such as a LAN.
l Prepare your computer's settings by disabling screen savers and changing the power saving scheme so that your
computer is always on, and does not go to sleep or hibernate.
l If the connection to any VM or the virtual lab portal closes unexpectedly, try to reconnect. If you can't reconnect,
notify the instructor.
l If you can't connect to a VM, on the dashboard, right-click the VM,, and then select System > Power Cycle, to
force the VM to start up. This fixes most problems. If itdoes not solve the problem, select System > Revert to
Initial State, to return the VM to its initial state.
Reverting to the VM's initial snapshot will undo all of your work. Try other solutions
first.

DO NOT REPRINT
Virtual Lab Basics Troubleshooting Tips
© FORTINET
l During the labs, if the VM is waiting for a response from the authentication server, a license message similar to the
following example appears:
To retry immediately, on the CLI, enter the following command:

execute update-now

DO NOT REPRINT
© FORTINET
Lab 1: Routing
In this lab, you will configure the router settings, and try scenarios to learn how FortiGate makes routing
decisions.
Objectives
l Route traffic based on the destination IP address, as well as other criteria.
l Balance traffic among multiple paths.
l Implement route failover.
l Implement policy routing.
l Diagnose a routing problem.
Time to Complete
Estimated: 50 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to Local-FortiGate.
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 as admin and
leave the password field empty.
2. In the upper-right corner of the screen, click admin, and then click Configuration > Restore.
3. Click Local PC, and then click Upload.

4. Click Desktop > Resources > FortiGate-Infrastructure > Routing > local-routing.conf, and then click
Open.
5. Click OK.
6. Click OK to reboot.

DO NOT REPRINT
© FORTINET
Exercise 1: Configuring Route Failover
In the lab network, Local-FortiGate has two interfaces connected to the Internet: port1 and port2. During this
exercise, you will configure the port1 connection as the primary Internet link, and the port2 connection as the
backup Internet link. Local-FortiGate should use the port2 connection only if the port1 connection is down. To
achieve this objective, you will configure two default routes with different administrative distances, as well as
configure two link health monitors.
Verify the Routing Configuration
First, you'll verify the existing routing configuration on Local-FortiGate.
Take the Expert Challenge!

On the Local-FortiGate GUI (10.0.1.254 | admin <blank password>), complete the following:
l View the existing static route configuration on Local-FortiGate.

l Enable the Distance and Priority columns in the static route configuration page.
l Make note of the Distance and Priority values of the existing default route.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Configure a Second Default Route on page 18.
To verify the routing configuration

2. Click Network > Static Routes.
3. Verify the existing default route for port1.
4. Right-click any of the columns to open the context-sensitive menu.

5. In the Available Columns section, select Distance and Priority, and then click Apply.

DO NOT REPRINT
Configure a Second Default Route Exercise 1: Configuring Route Failover
© FORTINET
The Distance and Priority columns display.
Note that, by default, static routes have a Distance value of 10, and a Priority value of 0.
Configure a Second Default Route
You will create a second default route using the port2 interface. To make sure this second default route remains
inactive, you will assign it a higher distance.

l On Local-FortiGate GUI, configure a second default route using port2.
l Assign it a Distance of 20, and Priority of 5.
After you complete the challenge, see Configure the Firewall Policies on page 19.

DO NOT REPRINT
Exercise 1: Configuring Route Failover Configure the Firewall Policies
© FORTINET
To configure a second default route
1. Continuing on the Local-FortiGate GUI, click Network > Static Routes.
2. Click Create New.
3. Configure the following settings:
Field Value
Device port2
Gateway 10.200.2.254
Administrative Distance 20
4. Click the plus (+) icon to expand the Advanced Options section.
5. In the Priority field, enter a value of 5.
6. Click OK.
A second default route is added.
Configure the Firewall Policies
You will modify the existing Full_Access firewall policy to log all sessions. You will also create a second firewall
policy to allow traffic through the secondary interface.

DO NOT REPRINT
Configure the Firewall Policies Exercise 1: Configuring Route Failover
© FORTINET

l Continuing on Local-FortiGate, enable logging for all sessions in the existing Full_Access firewall policy.
l Create a second firewall policy named Backup_Access.
l Configure the Backup_Access policy to allow traffic from port3 to port2 with NAT enabled.
l Enable logging on the Backup_Access policy for all sessions.
After you complete the challenge, see View the Routing Table on page 21
To configure the firewall policies

1. Continuing on the Local-FortiGate GUI, click Policy & Objects > IPv4 Policy.
2. Double-click the existing Full_Access policy to edit it.
3. Enable logging for All Sessions.
All Sessions logging ensures that all traffic is logged, and not just sessions inspected
by security profiles. This will assist in verifying traffic routing using the Forward
Traffic logs.
4. Click OK.
6. Configure a second firewall policy with the following settings:
Field Value
Name Backup_Access
Incoming Interface port3
Outgoing Interface port2
Source LOCAL_SUBNET

DO NOT REPRINT
Exercise 1: Configuring Route Failover View the Routing Table
© FORTINET
Field Value
Destination all
Schedule always
Service ALL
Action Accept
NAT <enable>
7. Enable logging for All Sessions.

8. Click OK.
View the Routing Table
The Local-FortiGate configuration now has two default routes with different distances. You will view the routing
table to see which one is active.
To view the routing table

1. Continuing on the Local-Windows VM, open PuTTY and connect over SSH to the LOCAL-FORTIGATE saved
session.
2. At the login prompt, enter the user name admin (all lower case).
3. Enter the following command to confirm the list of active routes in the routing table:
get router info routing-table all
Note that the second default route is not listed.
4. Enter the following CLI command to list both active and inactive routes:
get router info routing-table database
5. Confirm that the second default route is listed as inactive.

DO NOT REPRINT
Configure Link Health Monitors Exercise 1: Configuring Route Failover
© FORTINET
Stop and think!
Why is the port2 default route inactive?
The port2 default route has a higher administrative distance than the port1 default route. When two or
more routes to the same destination have different distances, the lower distance route is always active.
6. Leave the PuTTY session open.
Configure Link Health Monitors
You will configure two link health monitors to monitor the status of both the port1 and port2 routes.
To configure link health monitoring

1. Continuing on the LOCAL-FORTIGATE PuTTY session, enter the following CLI commands to create a link
health monitor for port1 on Local-FortiGate.
config system link-monitor
edit port1-monitor
set srcintf port1
set server 4.2.2.1
set gateway-ip 10.200.1.254
set protocol ping
set update-static-route enable
next
2. Configure another link health monitor for port2.

edit port2-monitor
set srcintf port2
set server 4.2.2.2
set gateway-ip 10.200.2.254
set protocol ping
set update-static-route enable
end
3. Leave your PuTTY session open.
Test the route failover
First you will access various websites, and use the Forward Traffic logs to verify that port1 route is being used.
Next you will force a failover by reconfiguring the port1 link health monitor to ping an invalid IP address. You will
then generate some more traffic, and use the Forward Traffic logs to verify that the port2 route is being used.
To confirm port1 route is primary

1. Return to the browser tab where you are logged into the Local-FortiGate GUI, and click Log & Report > Forward
Traffic.
2. Right-click any of the columns to open the context-sensitive menu.
3. In the Available Columns section, select Destination Interface.

DO NOT REPRINT
Exercise 1: Configuring Route Failover Test the route failover
© FORTINET
4. Scroll down in the right-click menu and click Apply.

The Destination Interface column is displayed.
5. Open a few new tabs in the web browser, and go to a few websites:
l http://www.pearsonvue.com/fortinet
l http://cve.mitre.org
l http://www.eicar.org
Traffic.
5. Click the refresh icon.
6. Locate the relevant log entries for the three websites you accessed, and verify that their Destination Interface
indicates port1.
This verifies that the port1 route is currently active and in use.

DO NOT
Test REPRINT
the route failover Exercise 1: Configuring Route Failover
© FORTINET
To force the failover
1. Return to the open LOCAL-FORTIGATE PuTTY session, and enter the following CLI commands to modify the
port1 link monitor:
edit port1-monitor
set server 10.200.1.13
next
end
2. Wait a few seconds.

Since 10.200.1.13 is a non-existent host in the lab network, the link health monitor will not receive any
replies. Because of this, the link health monitor will assume that the port1 Internet connection is down, and
remove the corresponding route from the routing table.
3. Leave your PuTTY session open.
To verify the route change

1. Return to the browser tab where you are logged into the Local-FortiGate GUI, and click Log & Report > System
Events.
Verify that Local-FortiGate detected the link monitor failure and removed the corresponding port1 route.
2. Click Monitor > Routing Monitor.

3. Verify that the port2 route is active in the routing table.
To verify traffic logs

1. Continuing on the Local-Windows VM, open a few new tabs in the web browser, and go to a few websites:
Traffic.
3. Locate the relevant log entries for the three websites you accessed, and verify that their Destination Interface
indicates port2.

DO NOT REPRINT
Exercise 1: Configuring Route Failover Restore the routing table
© FORTINET
This verifies that Local-FortiGate is using the port2 default route.
Restore the routing table
Before starting the next exercise, you will restore the port1 link health monitor's server configuration with a valid
host address, which will restore the port1 default route as the active route in the routing table.
To restore the port1 health monitor configuration

1. Return to the open LOCAL-FORTIGATE PuTTY session, and enter the following CLI commands.
edit port1-monitor
set server 4.2.2.1
next
end
2. Close the PuTTY session.
To verify the routing table

1. Return to the browser tab where you are logged into the Local-FortiGate GUI, and click Monitor > Routing
Monitor.
2. Verify that the port2 route is removed, and the port1 route is active.
3. Close the browser.

DO NOT REPRINT
© FORTINET
Exercise 2: Equal Cost Multipath and Policy Routing
In this exercise, you'll configure equal cost multipath (ECMP) routing on Local-FortiGate to balance the Internet
traffic between port1 and port2. After that, you'll configure a policy route to route HTTPS traffic through port1
only.
Configure Administrative Distance
To establish ECMP, first you will configure multiple static routes with the same administrative distance.

l Change the port2 static route administrative Distance to 10.

l Verify that both port1 and port2 default routes are active in the routing table.
After you complete the challenge, see Change the ECMP Load Balancing Method on page 27.
To configure administrative distance

3. Double-click the port2 static route to edit it.
4. Change the Administrative Distance to 10.
5. Click OK.

DO NOT REPRINT
Exercise 2: Equal Cost Multipath and Policy Routing Change the ECMP Load Balancing Method
© FORTINET
1. Continuing on the Local-FortiGate GUI, click Monitor > Routing Monitor.
2. Verify that both default routes are now active:
Change the ECMP Load Balancing Method
By default, the ECMP load balancing method is based on source IP. This works well when there are multiple
clients generating traffic. In the lab network, because you have only one client (Local-Windows), the source IP
method will not balance any traffic to the second route. Only one route will always be used. For this reason, you
will change the load balancing method to use both source and destination IP. Using this method, as long as the
traffic goes to multiple destination IP addresses, FortiGate will balance the traffic across both routes.
To modify the ECMP load balancing method

session.
3. Enter the following CLI commands to change the ECMP load-balancing method.
config system settings
set v4-ecmp-mode source-dest-ip-based
end
Verify Traffic Routing
You will generate some HTTP traffic and verify traffic routing using the Forward Traffic logs.

DO NOT REPRINT
Configure Priority Exercise 2: Equal Cost Multipath and Policy Routing
© FORTINET

l On Local-Windows, open a few new browser tabs and generate some HTTP traffic.
l Verify the traffic routing on Local-FortiGate using the Forward Traffic logs.
l Identify why all the outgoing packets are still being routed through port1.
After you complete the challenge, see Configure Priority on page 28.
To verify traffic routing

1. On the Local-Windows VM, open new tabs in the web browser, and go to a few websites:
Traffic.
3. Identify the Destination Interface in the relevant log entries for the websites you accessed.
Why are all the outgoing packets still being routed through port1?
Stop and think!

The port2 route is not being used because it was configured with a higher priority value than the port1
route (see Configure a Second Default Route on page 18). When two routes to the same destination have
the same administrative distance, both remain active. However, if the priorities are different, the route with
the lowest priority value is used. So, to achieve ECMP with static routes, the distance and priority values
must be the same for both routes.
Configure Priority
You will change the priority value for the port2 route to match the port1 route.

DO NOT REPRINT
Exercise 2: Equal Cost Multipath and Policy Routing Verify ECMP
© FORTINET

On Local-FortiGate, modify the static routing configuration so both default routes are eligible for ECMP.
After you complete the challenge, see Verify ECMP on page 29
To configure priority
2. Double-click the port2 default route to edit it.
3. Click the plus (+) icon to expand the Advanced Options section.
4. Change the Priority value to 0.
5. Click OK.
Verify ECMP
Now that both port1 and port2 routes share the same distance and priority values, they are eligible for
ECMP. First, you will verify the routing table, and then verify traffic routing using the Forward Traffic logs.

1. Return to the open LOCAL-FORTIGATE PuTTY session, and enter the following CLI commands on Local-
FortiGate:
get router info routing-table database
2. Verify that both default routes are currently active:

DO NOT REPRINT
Configure Policy Route for HTTPS Traffic Exercise 2: Equal Cost Multipath and Policy Routing
© FORTINET
To configure the CLI sniffer
1. Continuing on the LOCAL-FORTIGATE PuTTY session, enter the following CLI commands:
diagnose sniffer packet any 'tcp[13]&2==2 and port 80' 4
The filter 'tcp[13]&2==2' matches packets with the SYN flag on, so the output will show
all SYN packets to port 80 (HTTP).
2. Leave the PuTTY window open in the background.
To verify ECMP routing

l http://www.pearsonvue.com/fortinet/
2. Return to the open LOCAL-FORTIGATE PuTTY session, and press Ctrl+C to stop the sniffer.
3. Analyze the sniffer output.
The SYN packets are egressing both port1 and port2. This verifies that Local-FortiGate is now load
balancing all Internet traffic across both routes.
Configure Policy Route for HTTPS Traffic
You will force all HTTPS traffic to egress through port1 using a policy route. All other traffic should remain
unaffected and balanced between port1 and port2. To implement this, you will configure a policy route.

DO NOT REPRINT
Exercise 2: Equal Cost Multipath and Policy Routing Configure Policy Route for HTTPS Traffic
© FORTINET
To configure a policy route for HTTPS traffic
1. Return to the browser tab where you are logged into the Local-FortiGate GUI, and click Network > Policy
Routes.
Field Value
Protocol TCP
Incoming interface port3
Source address > IP/Netmask 10.0.1.0/24
Destination Address > IP/Netmask 0.0.0.0/0
Source Ports From 1 to 65535
Destination Ports From 443 to 443
Action Forward Traffic
Outgoing Interface <enable> and port1
Gateway Address 10.200.1.254
The policy route should look like the following example:

DO NOT
VerifyREPRINT
the Policy Route Exercise 2: Equal Cost Multipath and Policy Routing
© FORTINET
4. Click OK.
Verify the Policy Route
First, you will verify the routing table, and then verify policy routing by generating HTTPS traffic and viewing the
CLI sniffer output.
To verify the policy route table

1. Continuing on the Local-FortiGate GUI, click Monitor > Routing Monitor.
2. Click Policy.
3. Verify that the policy route is added to the policy route table.
To verify policy routing for HTTPS traffic

1. Return to the open LOCAL-FORTIGATE PuTTY session, and enter the following CLI commands on Local-
FortiGate:
As before, this sniffer filter matches packets with the SYN flag on, but this time for port
443 (HTTPS).
Leave the PuTTY window open in the background.
2. On the Local-Windows VM, open new tabs in the web browser, and then go to a few HTTPS websites:
l https://www.fortiguard.com
l https://support.fortinet.com
3. Return to the LOCAL-FORTIGATE PuTTY session, and then press Ctrl+C to stop the sniffer.
4. Analyze the sniffer output:

DO NOT REPRINT
Exercise 2: Equal Cost Multipath and Policy Routing Verify the Policy Route
© FORTINET
The SYN packets are egressing port1 only. This verifies that Local-FortiGate is applying the policy route for
HTTPS traffic.
To verify non-HTTPS traffic routing

1. Continuing on your LOCAL-FORTIGATE PuTTY session, enter the following CLI command:
2. On the Local-Windows VM, open new tabs in the web browser, and then go to a few HTTP websites:
3. Return to the open LOCAL-WINDOWS PuTTY session, and press Ctrl+C to stop the sniffer.
4. Analyze the sniffer output:
HTTP (port 80) traffic remains unaffected by the policy route, and is still load balanced across both port1 and
port2 routes.

DO NOT
VerifyREPRINT
the Policy Route Exercise 2: Equal Cost Multipath and Policy Routing
© FORTINET
Stop and think!
The Local-FortiGate configuration still has the two link health monitors for port1 and port2. Do they also
enable routing failover for ECMP scenarios?
Yes. If Local-FortiGate detects a problem in any of the routes, the link monitor will remove the
corresponding route, and all Internet traffic will be routed through the remaining route.
5. Close the PuTTY session and browser.

DO NOT REPRINT
© FORTINET
Lab 2: SD-WAN
In this exercise, you will configure SD-WAN on Local-FortiGate.
Objectives
l Configure SD-WAN load balancing.
l Configure routes and firewall policies for SD-WAN.
l Verify SD-WAN load balancing.
Time to Complete
Prerequisites


4. Click Desktop > Resources > FortiGate-Infrastructure > SDWAN > local-sdwan.conf, and then click
Open.
5. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 1: SD-WAN
In this exercise, you will configure SD-WAN using the port1 and port2 interfaces on Local-FortiGate.
Remove Interface References
Before you can add port1 and port2 as SD-WAN member interfaces, you must remove all configuration elements
referencing the two interfaces.

On the Local-FortiGate GUI (10.0.1.254 | admin <blank password>), remove all firewall policies and
routes referencing port1 and port2.
After you complete the challenge, see Configure SD-WAN Load Balancing on page 37.
To remove interface references

3. Select the port1 default route, and then click Delete.
4. Click OK.
5. Click Policy & Objects > IPv4 Policy.
6. Select the Full_Access policy, and then click Delete.
7. Click OK.

DO NOT REPRINT
Exercise 1: SD-WAN Configure SD-WAN Load Balancing
© FORTINET
Configure SD-WAN Load Balancing
You will configure SD-WAN load balancing for all Internet traffic between port1 and port2.

l Configure SD-WAN with port1 and port2 as the member interfaces.

l Set Source-Destination IP as the load-balancing method.
After you complete the challenge, see Create a Static Route for the SD-WAN Interface on page 38
To configure SD-WAN load balancing

1. Continuing on the Local-FortiGate GUI, click Network > SD-WAN .
2. Set Interface State to Enable.
3. In the SD-WAN section, click Create New.
4. Add port1 with the Gateway 10.200.1.254.
5. Click Create New one more time.
6. Add port2 with the Gateway 10.200.2.254.
7. Set Load Balancing Algorithm to Source-Destination IP.
8. Click Apply.
The SD-WAN configuration should look like the following example:

DO NOT REPRINT
Create a Static Route for the SD-WAN Interface Exercise 1: SD-WAN
© FORTINET
Create a Static Route for the SD-WAN Interface
You will create a default route using the sd-wan virtual interface.

On the Local-FortiGate GUI (10.0.1.254 | admin <blank password>), configure a default route using
the sdwan interface.
After you complete the challenge, see Create a Firewall Policy for SD-WAN Load Balancing on page 38.
To create a static route for SD-WAN

Field Value
Destination Subnet
0.0.0.0/0.0.0.0
Device sd-wan
4. Click OK.
Create a Firewall Policy for SD-WAN Load Balancing
You will create the firewall policy to allow the Internet traffic to pass from port3 to the sd-wan interface.
To create a firewall policy for SD-WAN load balancing

Field Value
Name SDWAN_Access

DO NOT REPRINT
Exercise 1: SD-WAN Verify the SD-WAN Load Balancing Configuration
© FORTINET
Field Value
Outgoing Interface sd-wan
Source LOCAL_SUBNET
Destination all
Schedule always
Service ALL
Action Accept
NAT <enable>
4. Click OK.
Verify the SD-WAN Load Balancing Configuration
First, you will review the Local-FortiGate routing table to examine the routes installed for SD-WAN. Then, you will
use the CLI packet capture tool to verify whether or not FortiGate is load balancing HTTP traffic between the SD-
WAN member interfaces.
To review the routing table

session.
3. Enter the following command to confirm the list of active routes in the routing table:
4. Verify that both default routes for port1 and port2 have the same distance value and are active in the routing
table.

DO NOT
VerifyREPRINT
the SD-WAN Load Balancing Configuration Exercise 1: SD-WAN
© FORTINET
After you create a static route for the sd-wan interface, FortiGate automatically adds
individual routes, with the same distance value, for all member interfaces. This
ensures all routes will be active in the routing table, which makes them eligible for load
balancing.
To verify the SD-WAN load balancing configuration

1. Continuing on the open LOCAL-FORTIGATE PuTTY session, enter the following CLI commands:
3. Return to the open LOCAL-FORTIGATE PuTTY session, and press Ctrl+C to stop the sniffer.
4. Analyze the sniffer output.
The SYN packets are egressing both port1 and port2. This verifies that Local-FortiGate is now load
balancing all Internet traffic across SD-WAN member interfaces.
5. Close the PuTTY session and your browser.

DO NOT REPRINT
© FORTINET
Lab 3: Virtual Domains
In this lab, you will create one VDOM and configure an inter-VDOM link.
Objectives
l Use VDOMs to split a FortiGate into multiple virtual devices.
l Create an administrative account and limit access to one VDOM.
l Route traffic between VDOMs by using inter-VDOM links.
Time to Complete
Topology
The goal of the lab is to create the following topology. You will use VDOMs to logically split the Local-FortiGate
into two virtual firewalls: the root VDOM, and the customer VDOM. Both VDOMs are running in NAT mode. So all
Internet traffic coming from Local-Windows must pass through the customer VDOM first, and then the root
VDOM.
Prerequisites

DO NOT REPRINT Lab 3: Virtual Domains
© FORTINET

4. Click Desktop > Resources > FortiGate-Infrastructure > VDOM > local-VDOM.conf, and then click Open.
5. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 1: Creating VDOMs and VDOM Objects
During this exercise, you will add a new VDOM. Then, you will create an inter-VDOM link between the VDOM you
added, and the root VDOM. You will also create an administrator account that will have access to only one
VDOM.
The configuration file for this exercise already has VDOMs enabled.
Create a VDOM
A FortiGate with enabled VDOMs always includes a root VDOM. Administrators can create additional VDOMs to
split the physical FortiGate into multiple virtual firewalls. In the next steps, you will add a second VDOM.
To create a VDOM
You will notice that the FortiGate menu has changed. This is because VDOMs are enabled. There is now a
drop-down menu at the top of the menu. In the drop-down menu, you can select the global settings or the
VDOM-specific settings for the root VDOM. The default setting is Global.
2. Click System > VDOM.

4. Configure the following VDOM.
Field Value
Virtual Domain customer
Inspection Mode Proxy

DO NOT REPRINT
Create a Per-VDOM Administrator Exercise 1: Creating VDOMs and VDOM Objects
© FORTINET
5. Click OK.
Notice that the drop-down menu at the top of the menu shows a third option: the VDOM-specific settings for
customer:
Create a Per-VDOM Administrator
You will create an administrator account that has access only to the customer VDOM .
To create a per-VDOM administrator

1. Return to the browser tab where you are logged into the Local-FortiGate GUI, and click Global > System >
Administrators.
2. Click Create New > Administrator.
3. Configure the following values:
Field Value
User Name customer-admin
Type Local User
Password fortinet
Confirm Password fortinet
Administrator Profile prof_admin
Virtual Domains customer
4. Remove root from the Virtual Domains list to restrict the new administrator's can access to customer only.

DO NOT REPRINT
Exercise 1: Creating VDOMs and VDOM Objects Move an Interface to a Different VDOM
© FORTINET
5. Click OK.
Move an Interface to a Different VDOM
The account customer-admin will be able to log in only through an interface in the customer VDOM. So, move
the port3 interface, which connects to the internal network, to the customer VDOM.
To move an interface to a different VDOM

1. Continuing on the Local-FortiGate GUI, click Global > Network > Interfaces.
2. Edit port3.
3. From the Virtual Domain drop-down menu, select customer.
4. Click OK.
5. Leave the port1 and port2 interfaces in the root VDOM.

DO NOT REPRINT
Add DNS service to an Interface Exercise 1: Creating VDOMs and VDOM Objects
© FORTINET
Add DNS service to an Interface
For Local-Windows, the DNS server is port3. First, you will enable the DNS database in the Feature Visibility
section. Then, you will add DNS service to port3.
To enable the DNS database

1. Continuing on the Local-FortiGate GUI, select the customer VDOM in the drop-down menu at the top of the
menu.
2. Click System > Feature Visibility.

3. In the Additional Features section, turn on the DNS Database switch.
4. Click Apply.
To add DNS service to an interface

1. Continuing on the Local-FortiGate GUI, in the customer VDOM, click Network > DNS Servers.
2. Under DNS Service on Interface, click Create New, and then configure the following values:
Field Value
Interface port3
Mode Forward to System DNS

DO NOT REPRINT
Exercise 1: Creating VDOMs and VDOM Objects Test the Per-VDOM Administrator Account
© FORTINET
3. Click OK.
4. Log out of the Local-FortiGate GUI.
Test the Per-VDOM Administrator Account
To see what access is available to the customer-admin account, try logging on to the FortiGate-Local GUI as
customer-admin.
To test the per-VDOM administrator account

1. Log in again to the Local-FortiGate GUI, but this time use the administrator name customer-admin with the
password fortinet.
2. View the GUI and examine what the VDOM administrator is allowed to control.
Because the customer-admin administrator can access only the customer VDOM , the GUI does not
display the Global configuration settings or the VDOM-specific settings for the root VDOM.
3. Log out of the Local-FortiGate GUI, and log in back as the admin user (blank password), which has access to the
global settings and all VDOMs.
Stop and think!

Why is the dashboard different between the two login sessions?
Logging in with the admin account gives you full access to both the root VDOM as well as the
FortiGate system resources. Logging in with the customer-admin account provides access
only to the customer VDOM, and does not provide access to the system resource details.
Execute Per-VDOM CLI Commands
After you enable VDOMs , the structure of the GUI menu and the tree structure of the CLI changes. In this
exercise, you will examine the differences in the CLI for VDOMs.

DO NOT REPRINT
Execute Per-VDOM CLI Commands Exercise 1: Creating VDOMs and VDOM Objects
© FORTINET
To execute per-VDOM CLI commands
session.
3. Try to execute the following command to list the routing table.
Did the CLI reject the command? To execute this command when VDOMs are
enabled, you must specify the VDOM first, in order for FortiGate to know which
VDOM’s routing table to display.
4. To enter the customer VDOM context, type.
config vdom
edit customer
Be careful when typing VDOM names with the edit command.
VDOM names are case sensitive, and the edit command can both modify and create.
For example, if you enter edit Root, you will not enter the pre-existing root
VDOM. Instead, you will create and enter a new VDOM named Root.
5. Now that you've specified the VDOM, try looking at the routing table again.
The command works now. The information displayed in the routing table is specific to the customer VDOM.
Remember that each VDOM has its own routing table.
6. Go to the root VDOM context now.
next
edit root
7. Now use the command for listing the routing table:
This time, the information displayed in the routing table belongs to the root VDOM. You will observe that this
table is different from the one for the customer VDOM.

DO NOT REPRINT
© FORTINET
Exercise 2: Inter-VDOM Link
In this exercise, you will route traffic between two VDOMs using an inter-VDOM link.
Create an Inter-VDOM Link
You will create an inter-VDOM link to route traffic between two VDOMs.
To create an inter-VDOM link

2. In the Global VDOM, Click Network > Interfaces.
3. Click Create New, and then select VDOM Link.
4. In the Name field, type vlink.
5. In the Interface 0 (vlink0) section, configure the following settings:
Field Value
Virtual Domain root
IP/Network Mask 10.10.100.1/30
Administrative Access HTTPS, PING, SSH
Field Value
Virtual Domain customer

DO NOT REPRINT
Configure Routing Between VDOMs Exercise 2: Inter-VDOM Link
© FORTINET
7. Click OK.
After creating the inter-VDOM link, notice the two inter-VDOM sub-interfaces added within the root and
customer VDOMs (expand vlink). These interfaces are named vlink0 and vlink1. You can use them to
route traffic between two VDOMs.
Configure Routing Between VDOMs
You will add the static routes to both VDOMs to route traffic between them. The objective is to have Internet
traffic from Local-Windows crossing the customer VDOM first and then the root VDOM, before the traffic goes
to the Linux server and the Internet.

DO NOT REPRINT
Exercise 2: Inter-VDOM Link Configure Routing Between VDOMs
© FORTINET
To configure routing between VDOMs
1. Continuing on the Local-FortiGate GUI, in the VDOM drop-down list, select the customer VDOM.

3. Click Create New to specify a default route for the customer.
4. Add the following route.
Field Value
Destination Subnet
0.0.0.0/0.0.0.0
Device vlink1
Gateway 10.10.100.1
5. Click OK.
Now, you will specify a route for the root VDOM to the internal network.
6. In the VDOM drop-down menu, select root.

9. Configure the following route:

DO NOT REPRINT
Configure Firewall Policies for Inter-VDOM Traffic Exercise 2: Inter-VDOM Link
© FORTINET
Field Vlaue
Destination Subnet
10.0.1.0/24
Device vlink0
Gateway 10.10.100.2
10. Click OK.
Configure Firewall Policies for Inter-VDOM Traffic
You will create firewall policies to allow Internet traffic to pass through the customer and root VDOMs.

On the Local-FortiGate GUI (10.0.1.254 | admin <blank password>), configure the appropriate firewall
policies to allow traffic to flow freely across the inter-VDOM link. This will require two firewall policies, one
from port3 to vlink1, and one from vlink0 to port1.
After you complete the challenge, see Test the Inter-VDOM Link on page 54.
To configure firewall policies for inter-VDOM traffic for port3 to vlink1

1. Continuing on the Local-FortiGate GUI, in the VDOM drop-down list, click customer.

4. Configure the following firewall policy to allow traffic to pass from port3 to vlink1:

DO NOT REPRINT
Exercise 2: Inter-VDOM Link Configure Firewall Policies for Inter-VDOM Traffic
© FORTINET
Field Value
Name Internet
Outgoing Interface vlink1
Source all
Destination all
Schedule always
Service ALL
Action ACCEPT
NAT <disable>
5. Click OK.
To configure firewall policies for inter-VDOM traffic for vlink0 to port1

1. Continuing on the Local-FortiGate GUI, in the VDOM drop-down menu, click root.
4. Configure the following policy:
Field Value
Name Internet
Incoming Interface vlink0
Source all
Destination all
Schedule always
Service ALL
Action ACCEPT
NAT <enable>
5. Click OK.

DO NOT
Test REPRINT
the Inter-VDOM Link Exercise 2: Inter-VDOM Link
© FORTINET
Test the Inter-VDOM Link
Now, you will test your configuration to confirm that Internet traffic is being routed through the two VDOMs and
the inter-VDOM link.
To test the inter-VDOM link

1. Continuing on the Local-Windows VM, open a few browser tabs, and go to a few external HTTP websites, such as:
Traffic should be flowing through both VDOMs now.
2. Open a command prompt window, and then execute a traceroute command to an Internet public IP address:
tracert –d 4.2.2.2
3. Check the output.

The first hop IP address is 10.0.1.254, which is port3 in the customer VDOM. The second hop IP
address is 10.10.100.1, which is the inter-VDOM link in the root VDOM. The third hop IP address is
10.200.1.254, which is the Linux server.
4. Close the command prompt and your browser.

DO NOT REPRINT
© FORTINET
Lab 4: Transparent Mode
In this lab, you will create a transparent mode VDOM. You will also configure an inter-VDOM link, this time
between a transparent mode VDOM and a NAT mode VDOM.
Objectives
l Configure a transparent mode VDOM.
l Configure an inter-VDOM link.
Time to Complete
Lab Topology
The goal of this lab is to create the topology below. You will use VDOMs to logically split the Local-FortiGate into
two virtual firewalls: the root VDOM and the inspect VDOM. The root VDOM is in NAT mode. The inspect
VDOM is in transparent mode and will be inspecting the traffic for virus protection. So all Internet traffic coming
from Local-Windows must transverse first the root VDOM, and then the inspect VDOM.
Prerequisites

DO NOT REPRINT Lab 4: Transparent Mode
© FORTINET
To restore the FortiGate configuration file
3. Ensure the Scope is set for Global, then click Local PC, and then click Upload.
4. Click Desktop > Resources > FortiGate-Infrastructure > Layer2 > local-layer-2.conf, and then click
Open.
5. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 1: Transparent Mode VDOM
The configuration file for this exercise already has VDOMs enabled. In this exercise, you need to create only a
transparent mode VDOM called inspect and then move the interface to the inspect VDOM.
Create a Transparent Mode VDOM
You will create a new VDOM, and then change its operation mode to transparent.
To create a transparent mode VDOM

The configuration that you restored at the beginning of this lab has VDOMs enabled. For this reason, you will
see a drop-down menu at the top of the menu. It provides access to the global settings and to each VDOM-
specific setting.
2. In the drop-down menu, select Global.

3. Click System > VDOM, and then click Create New.
Field Value
Virtual Domain inspect
Inspection Mode Flow-Based
5. Click OK.
session.

DO NOT REPRINT
Moving an Interface to a Different VDOM Exercise 1: Transparent Mode VDOM
© FORTINET
8. Enter the following command to change the inspect VDOM operation mode from the default NAT mode to
transparent mode:
config vdom
edit inspect
config system settings
set opmode transparent
set manageip 10.200.1.200/24
end
end
Stop and think!

What is that 10.200.1.200 IP address for?
It is the management IP address for the transparent mode VDOM. Interfaces that belong to a transparent
mode VDOM do not have IP addresses, but the VDOM itself has one. You can use this IP address for
administrative access to the device and this VDOM.
Moving an Interface to a Different VDOM
You will move the interface port1 to the inspect VDOM.

On the Local-FortiGate GUI (10.0.1.254 | admin <blank password>), move the port1 interface to the
inspect VDOM.
To move an interface to a different VDOM

1. Return to the browser tab where you are logged into the Local-FortiGate GUI, select the Global VDOM and click
Network > Interfaces.
2. Edit port1.
3. In the Virtual Domain drop-down menu, select inspect.

DO NOT REPRINT
Exercise 1: Transparent Mode VDOM Moving an Interface to a Different VDOM
© FORTINET
4. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 2: Inter-VDOM Link
In this exercise, you will create an inter-VDOM link. Then, you will create the firewall policies that allow Internet
access across both VDOMs. Finally, you will configure and test antivirus inspection in the inspect VDOM.
Create an Inter-VDOM Link
Create the inter-VDOM link for routing traffic from the root VDOM to the Internet through the inspect VDOM.
To create an inter-VDOM link

2. Select the Global VDOM and click Network > Interfaces.
3. Click Create New, and then select VDOM Link.
4. In the Name field, type vlink.
Field Value
Virtual Domain root
Field Value
Virtual Domain inspect
7. Click OK.
The Interfaces page displays with the updated configurations.
8. Review the inter-VDOM link interfaces you just created (expand vlink).

DO NOT REPRINT
Exercise 2: Inter-VDOM Link Create firewall policies
© FORTINET
Note that vlink0 and vlink1 are logical interfaces that you can use to route traffic between the root and
inspect VDOMs. An IP address is configurable only on the NAT mode VDOM interface.
Create firewall policies
You will create firewall policies to allow Internet traffic to pass through both VDOMs. You will also enable antivirus
inspection in the inspect VDOM.

l Create two firewall policies to allow Internet traffic to pass through both VDOMs. One policy will be from
vlink1 to port1 and the other will be from port3 to vlink0.
l In the inspect VDOM, enable the default antivirus inspection profile on firewall policy.
After you complete the challenge, see Route Inter-VDOM traffic on page 64.
To create a firewall policy on the inspect VDOM

1. Continuing on the Local-FortiGate GUI, from the VDOM drop-down menu, select inspect.

DO NOT REPRINT
Create firewall policies Exercise 2: Inter-VDOM Link
© FORTINET
4. Configure the following settings.
Field Value
Name Inspected_Internet
Incoming Interface vlink1
Source all
Destination all
Schedule always
Service ALL
Action ACCEPT
5. In the Security Profiles section, turn on the AntiVirus switch, and then, in the antivirus profile drop-down menu,
select default.
6. Click OK.

DO NOT REPRINT
Exercise 2: Inter-VDOM Link Create firewall policies
© FORTINET
To create a firewall policy on the root VDOM
1. Continuing in the Local-FortiGate GUI, from the VDOM drop-down menu, select root.
2. Click Policy & Objects > IPv4 Policy, and then click Create New.
3. Configure the following settings.
Field Value
Name Internet
Outgoing Interface vlink0
Source all
Destination all
Schedule always
Service ALL
Action ACCEPT
4. In the Firewall/Network Options section, turn on the NAT switch.

5. In the Logging Options section, turn on the Log Allowed Traffic switch, and then select All Sessions.
6. Click OK.

DO NOT REPRINT
Route Inter-VDOM traffic Exercise 2: Inter-VDOM Link
© FORTINET
Route Inter-VDOM traffic
To route traffic from Local-Windows to the inspect VDOM, you must create a default route in the root VDOM.
To route inter-VDOM traffic

1. Continuing on the Local-FortiGate GUI and in the root VDOM, click Network > Static Routes.
Field Value
Destination Subnet
0.0.0.0/0.0.0.0
Device vlink0
Gateway 10.200.1.254
4. Click OK.
Test the Transparent Mode VDOM
You will use the traceroute command to confirm that Internet traffic is crossing the inter-VDOM link. Then, you
will try to download a virus to confirm that antivirus inspection in the inspect VDOM is working.
To test the transparent mode VDOM

1. Continuing on the Local-Windows VM, open a command prompt window.
2. Run the following traceroute to verify that your first two hops are 10.0.1.254 and 10.200.1.254.
tracert –d 10.200.3.1
Stop and think!

You will observe that the first hop IP address is 10.0.1.254, which is port3 in the root VDOM. The
second hop IP address is 10.200.1.254, which is the Linux server. Why isn't the traceroute showing any
IP address belonging to the inspect VDOM?
A transparent VDOM does not route packets like a NAT VDOM. Instead, it forwards frames based on the
destination MAC addresses as a LAN Layer 2 switch. A traceroute shows the IP addresses of all the routers
along a path to a destination. The inspect VDOM is not acting as a router, but as a Layer 2 switch.
3. Close the command prompt.

4. Open a new browser tab and go to:
http://www.eicar.org

DO NOT REPRINT
Exercise 2: Inter-VDOM Link Test the Transparent Mode VDOM
© FORTINET
4. Click Download ANTI MALWARE TESTFILE, and then click Download.
5. Select the option to download the eicar.com file using HTTP.
6. Confirm that the antivirus profile in the inspect VDOM blocks the following action.

DO NOT
Test REPRINT
the Transparent Mode VDOM Exercise 2: Inter-VDOM Link
© FORTINET
Review log files on root VDOM

1. Return to the browser tab where you are logged into the Local-FortiGate GUI and the root VDOM, and click Log
& Report > Forward Traffic.
2. Locate a log entry for the www.eicar.org website.
3. Click on one of the following entries to view more details.
Stop and think!

Why do the log entries indicate that the traffic was permitted?
Remember that the root VDOM is the unrestricted Internet side of the inter-VDOM link. In the next steps
you will review the logs for the inspect VDOM.
Review log files on the inspect VDOM

1. Continuing on the Local-FortiGate GUI, in the VDOM drop-down menu, select inspect.
2. Click Log & Report > Forward Traffic, and then locate a log entry for the www.eicar.org website.
3. Click the entry to view more details.
You should notice that the item was blocked by the antivirus policy.

DO NOT REPRINT
© 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
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.
To restore the Remote-FortiGate configuration file

1. On the Local-Windows VM, open a browser and log in to the Remote-FortiGate GUI at 10.200.3.1 as admin
and leave the password field empty.

4. Click Desktop > Resources > FortiGate-Infrastructure > Site-to-Site-IPsec > Route-vs-Policy-based-
IPSEC > remote-rvp.conf, and then click Open.

DO NOT REPRINT Lab 5: Configuring a Site-to-Site IPsec VPN
© FORTINET
5. Click OK.


4. Click Desktop > Resources > FortiGate-Infrastructure > Site-to-Site-IPsec > Route-vs-Policy-based-
IPSEC > local-rvp.conf, and then click Open.
5. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 1: Configuring Route-Based IPsec VPN
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.
Create a VPN Using the VPN Wizard
Now, you will configure Local-FortiGate using the VPN wizard, which creates the IPsec in route-based mode.
To create a VPN using the VPN wizard

2. Click VPN > IPsec Tunnels.
Field Value
Name ToRemote
Template Type Site to Site
Remote Device Type FortiGate
NAT Configuration No NAT between sites
5. Click Next .
Field Value
Remote Device IP Address
IP Address 10.200.3.1
Outgoing interface port1
Authentication Method Pre-shared Key
Pre-shared Key fortinet
7. Click Next.

DO NOT REPRINT
Review the Objects Created by the VPN Wizard Exercise 1: Configuring Route-Based IPsec VPN
© FORTINET
Field Value
Local Interface port3
Local Subnets 10.0.1.0/24
Remote Subnets 10.0.2.0/24
9. Click Create.
You should see the following screen:
10. Click Show Tunnel List.

You will see the VPN you just created.
Review the Objects Created by the VPN Wizard
Now, you will review the objects that were created by the VPN wizard.
To review the objects created by the VPN wizard

1. Continuing on the Local-FortiGate GUI, click VPN > IPsec Tunnels.
2. Select the VPN you just created, and then click Edit.
Notice the quick mode selectors that the wizard configured for you.

DO NOT REPRINT
Exercise 1: Configuring Route-Based IPsec VPN Review the Objects 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 OK.
5. Click Network > Interfaces.
6. Click the plus (+) icon that appears beside port1.
You will see a new virtual interface named ToRemote (matching the phase 1 name).
Stop and think!

What does this virtual interface tell us about the VPN created by the wizard? Is it policy-based or route-
based?
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.

DO NOT REPRINT
Review the Objects Created by the VPN Wizard Exercise 1: Configuring Route-Based IPsec VPN
© 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 Group in the upper right.
Observe two new firewall address objects: ToRemote_local_subnet_1, and ToRemote_remote_subnet_
1.

Observe the new two firewall policies: one from port3 to ToRemote and another from ToRemote to port3.
You will see that the Action is both cases is ACCEPT.
7. Click Network > Static Routes, and look at the static route added by the wizard.

DO NOT REPRINT
© FORTINET
Exercise 2: Configuring Policy-Based IPsec VPN
For learning purposes, you will configure the two FortiGate devices differently. During this exercise, you will
create the VPN on Remote-FortiGate using a policy-based configuration, without using the wizard.
Show Policy-Based VPN Settings in the GUI
By default, policy-based configurations are hidden in the GUI. Now, you will show policy-based VPN settings in
the GUI.
To show policy-based VPN settings in the GUI

3. Under the Additional Features section, enable Policy-based IPsec VPN .
4. Click Apply.
Create a Policy-Based VPN
Now, you will create phases 1 and 2.
To create a policy-based VPN

1. Continuing on the Remote-FortiGate GUI, click VPN > IPsec Tunnels.
3. Configure the following:
Field Value
Name ToLocal
Template Type Custom
4. Click Next.
5. Disable Enable IPsec Interface Mode.

DO NOT REPRINT
Create a Policy-Based VPN Exercise 2: Configuring Policy-Based IPsec VPN
© FORTINET
Field Value
Remote Gateway Static IP Address
Interface port4
Mode Config <disable> (leave it unchecked)
NAT Traversal <disable>
Dead Peer Detection On Idle
Method Pre-shared Key
7. Keep the default values for the remaining settings.

8. In the Phase 2 Selectors section, click the edit icon to edit the settings.
9. Complete the following:
Field Value
Local Address 10.0.2.0/24
Remote Address 10.0.1.0/24

DO NOT REPRINT
Exercise 2: Configuring Policy-Based IPsec VPN Create a Firewall Policy for a Policy-Based VPN
© FORTINET
10. Click OK.
Now the quick mode selectors on both sides mirror each other. If that is not the case,
the tunnel will not come up.
Create a Firewall Policy for a Policy-Based VPN
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.
To create a firewall policy for a policy-based VPN

1. Continuing on the Remote-FortiGate GUI, go to Policy & Objects > IPv4 Policy.
Field Value
Name VPN traffic to Local FGT
Source REMOTE_SUBNET
Destination LOCAL_SUBNET
Schedule always
Service ALL
Action IPsec

DO NOT
MoveREPRINT
a Firewall Policy Exercise 2: Configuring Policy-Based IPsec VPN
© FORTINET
Field Value
VPN Tunnel ToLocal
Allow traffic to be initiated <enable>

from the remote site
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.
Move a Firewall Policy
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.
To move a firewall policy

1. Continuing on the Remote-FortiGate GUI, click Policy & Objects > IPv4 Policy.
2. Expand the list of firewall policies for port6 to port4.
3. Drag the policy VPN traffic to Local FGT above the Internet policy.

DO NOT REPRINT
Exercise 2: Configuring Policy-Based IPsec VPN Move a Firewall Policy
© 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.

DO NOT REPRINT
© FORTINET
Exercise 3: Testing and Monitoring the VPN
You have finished the configuration on both FortiGate devices. Now, you will test the VPN.
Test the VPN
Now, you will test the VPN.
To test the VPN

2. Click Monitor > IPsec Monitor.
Notice that the VPN is currently down.
3. Right-click the VPN, and then select Bring Up.
The Status column of the VPN contains a green up arrow, indicating that the tunnel is up.
Stop and think!

Do I always have to bring up the tunnel manually after creating it?
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
The ping should work.
5. Close the command prompt window.

6. Return to the Local-FortiGate GUI, and then click Monitor > IPsec Monitor.
7. Click Refresh to refresh the screen.
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.

DO NOT REPRINT
© FORTINET
Exercise 4: Configuring an IPsec VPN Between Two

FortiGate Devices
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"
To restore the Remote-FortiGate configuration file


4. Click Desktop > Resources > FortiGate-Infrastructure > Site-to-Site-IPsec > Redundant IPsec VPN >
remote-redundant-VPN.conf, and then click Open.
5. Click OK.


DO NOT REPRINT
Create Phases 1 and 2 on Local-FortiGate Exercise 4: Configuring an IPsec VPN Between Two FortiGate Devices
© FORTINET

4. Click Desktop > Resources > FortiGate-Infrastructure > Site-to-Site-IPsec > Redundant IPsec VPN >
local-redundant-VPN.conf, and then click Open.
5. Click OK.
Create Phases 1 and 2 on Local-FortiGate
Now, you will configure the IPsec VPN by creating phases 1 and 2.
To create phases 1 and 2

2. Click VPN > IPsec Tunnels, and then click Create New.
Field Value
Name Remote_1
Template Type Custom
4. Click Next.
5. In the Network section, configure the following settings:
Field Value
Remote Gateway Static IP Address
Interface port1
Dead Peer Detection On Idle
6. In the Authentication section, configure the following settings:

Exercise 4: Configuring an IPsec VPN Between Two Create a Static Route for a Route-based VPN on Local-
DO NOT REPRINT
FortiGate Devices FortiGate
© FORTINET
Field Value
Method Pre-shared Key
7. Keep the default values for the remaining settings.

8. Click OK.
Create a Static Route for a Route-based VPN on Local-FortiGate
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.
To create a static route for a route-based VPN

Field Value
Destination Subnet
10.0.2.0/24
Device Remote_1
4. Click OK.
Create an Interface Zone on Local-FortiGate
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.
To create an interface zone

1. Continuing on the Local-FortiGate GUI, click Network > Interfaces.
2. Click Create New, and then select Zone.

Create Firewall Policies for VPN Traffic on Local- Exercise 4: Configuring an IPsec VPN Between Two FortiGate
DO NOT REPRINT
FortiGate Devices
© FORTINET
Field Value
Name VPN
Interface Members Remote_1
4. Click OK.
You will add a second VPN interface to the zone in a later exercise, when you
configure a backup VPN.
Create Firewall Policies for VPN Traffic on Local-FortiGate
Now, you will create two firewall policies between port3 and VPN , one for each traffic direction.
To create the firewall policies for VPN traffic

Field Value
Name Remote_out

Exercise 4: Configuring an IPsec VPN Between Two FortiGate Create Firewall Policies for VPN Traffic on Local-
DO NOT REPRINT
Devices FortiGate
© FORTINET
Field Value
Outgoing Interface VPN
Source LOCAL_SUBNET
Destination REMOTE_SUBNET
Schedule always
Service ALL
Action ACCEPT
4. In the Firewall/Network Options section, disable NAT.

5. Click OK.
6. Click Create New one more time.
Field Value
Name Remote_in
Incoming Interface VPN
Source REMOTE_SUBNET
Destination LOCAL_SUBNET
Schedule always
Service ALL
Action ACCEPT
8. In the Firewall/Network Options section, disable NAT.

9. Click OK.

Review the VPN Configuration on Remote- Exercise 4: Configuring an IPsec VPN Between Two FortiGate
DO NOT REPRINT
FortiGate Devices
© 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.
To review the Remote-FortiGate configuration

1. Continuing on the Local-Windows VM, open a browser and log in to the Remote-FortiGate GUI at 10.200.3.1
as admin and leave the password field empty.
2. To review the VPN configuration, click VPN > IPsec Tunnels, and review Local_1.
3. To review the static route for the route-based VPN, click Network > Static Routes, and review Local_1.
4. To review the interface zone, click Network > Interfaces, and in the Zone section, expand VPN , and review
Local_1.
5. To review the firewall policies for VPN traffic on Remote-FortiGate, click Policy & Objects > IPv4 Policy, and
review Local_out and Local_in.
Test the IPsec VPN
Now, you will test the VPN by generating some traffic and confirming that the VPN comes up.
To test the IPsec VPN

1. Continuing on the Local-Windows VM, open a command prompt window.
2. Generate a ping to the Remote-Windows VM (10.0.2.10):
ping 10.0.2.10
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.
5. Close the command prompt.

DO NOT REPRINT
© FORTINET
Exercise 5: Configuring a Backup IPsec VPN
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.
Remote FortiGate is pre-configured for VPN redundancy.
Configure a Backup VPN on Local-FortiGate
Now, you will configure a backup VPN on Local-FortiGate.

On the Local-FortiGate GUI (10.0.1.254 | admin <blank password>), configure the following to create a
route-based redundant VPN:
1. Create a new VPN IPsec tunnel:

l Use Remote_2 for the VPN name.
l Use 10.200.4.1 for the remote IP address.
l Use port2 for the interface.
2. Add a static route using Remote_2 with administrative distance of 20. Note the Distance and Priority
values of the existing default route.
3. Edit the network interface zone named VPN , and in Interface Members add Remote_2.
After you complete the challenge, see Review the Backup VPN Configuration on Remote-FortiGate on
page 86.
To configure a backup VPN on Local-FortiGate

2. Repeat the configuration steps in To create phases 1 and 2 on page 80 to create phases 1 and 2.
l Use Remote_2 for the VPN name.
l Use 10.200.4.1 for the remote IP address.
l Use port2 for the interface.

DO NOT REPRINT
Review the Backup VPN Configuration on Remote-FortiGate Exercise 5: Configuring a Backup IPsec VPN
© FORTINET
5. Add the following static route:
Field Value
Destination Subnet
10.0.2.0/24
Device Remote_2
6. Click OK.
7. Click Network > Interfaces.
8. Edit the zone VPN .
9. In the Interface Members field, add Remote_2.
10. Click OK.
Review the Backup VPN Configuration on Remote-FortiGate
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.
To review the Remote-FortiGate configuration

1. Continuing on the Local-Windows VM, open a browser and log in to the Remote-FortiGate GUI at 10.200.3.1
as admin and leave the password field empty.
2. To review the VPN configuration, click VPN > IPsec Tunnels, and review Local_2.
3. To review the static route for the route-based VPN, click Network > Static Routes and review Local_2.
4. To review the interface zone, click Network > Interfaces, and in the Zone section, expand VPN , and review
Local_2.
5. To review the firewall policies for VPN traffic on Remote-FortiGate, click Policy & Objects > IPv4 Policy, and
review Local_out and Local_in.
Test the VPN Redundancy
Now, you will test the VPN failover. You will use the sniffer tool to monitor which VPN the traffic is using.
To test the VPN redundancy

1. Continuing on Local-Windows, open PuTTY and connect over SSH to the LOCAL-FORTIGATE saved session.
3. Run the following command to sniffer all ICMP traffic to 10.0.2.10 with verbosity 4:

DO NOT REPRINT
Exercise 5: Configuring a Backup IPsec VPN Test the VPN Redundancy
© 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:
28.040086 port3 in 10.0.1.10 -> 10.0.2.10: icmp: echo request

28.040107 Remote_1 out 10.0.1.10 -> 10.0.2.10: icmp: echo request
28.041188 Remote_1 in 10.0.2.10 -> 10.0.1.10: icmp: echo reply
28.041196 port3 out 10.0.2.10 -> 10.0.1.10: icmp: echo reply
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:

546.352090 Remote_2 out 10.0.1.10 -> 10.0.2.10: icmp: echo request
546.353546 Remote_2 in 10.0.2.10 -> 10.0.1.10: icmp: echo reply
546.353560 port3 out 10.0.2.10 -> 10.0.1.10: icmp: echo reply
12. Close the PuTTY session and command prompt.

13. To finish this exercise, return to the browser tab where you are logged on to the Local-FortiGate GUI, and click
Network > Interfaces.
14. Edit port1.
15. Return the Interface State to Enabled.
16. Click OK.
Omitting these last steps may prevent you from doing the next exercise.
17. Close your browser.

DO NOT REPRINT
© FORTINET
Lab 6: Fortinet Single Sign-On (FSSO)
In this lab, you will configure Fortinet's solution for single sign-on (FSSO). FSSO enables FortiGate to identify
users by collecting user logon activity from Windows Active Directory.
This includes installing and configuring the domain controller agent and FSSO collector agent in order to monitor
and consolidate the user logon events and send them to FortiGate.
You will also configure the SSO option on FortiGate to enable communication with the collector agent,
specifically to poll event log information.
Objectives
l Install and configure the Fortinet domain controller agent.
l Install and configure the FSSO collector agent.
l Configure SSO on FortiGate.
l Test the transparent or automatic user identification by generating user logon events.
l Monitor the SSO status and operation.
Time to Complete
Prerequisites

1. On the Local-Windows VM, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254 and
2. In the upper-right corner of the screen, click admin, and then select Configuration > Restore.
3. Select Local PC, and then click Upload.

4. Click Desktop > Resources > FortiGate-Infrastructure > FSSO > local-fsso.conf, and then click Open.
5. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 1: Configuring FSSO Collector Agent-Based

Polling Mode
To configure FortiGate to identify users by polling their logon events using a Fortinet Single Sign-On (FSSO)
agent, you must install and configure a collector agent.
The following FSSO agents are available on the Fortinet Support website
(http://support.fortinet.com):
l DC agent
l Collector agent for Microsoft servers: FSSO_Setup
l Collector agent for Novell directories: FSSO_Setup_edirectoryController agent for
Citrix servers: TSAgent_Setup
Then, you will configure your FortiGate to communicate and poll information from the FSSO collector agent. For
this, you must assign the polled user to a firewall user group and add the user group as a source on a firewall
policy.
Finally, you can verify the user logon event collected by FortiGate. This event is generated after a user logs on to
the Windows Active Directory domain. Therefore, no firewall authentication is required.
Install the FSSO Collector Agent
In this section, you will install the FSSO collector agent on a Windows server.
To install the FSSO collector agent on a Windows server

1. On the desktop of the Local-Windows VM, click Resources > FortiGate-Infrastructure > FSSO.
2. Right-click FSSO_Setup_5.0.0261_x64, and then select Run as administrator.
The FSSO collector agent installation wizard opens.

DO NOT
InstallREPRINT
the FSSO Collector Agent Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode
© FORTINET
3. Click Next.
4. Accept the license agreement, and then click Next.
5. Accept the default destination folder, and then click Next.
6. Supply the following credentials, and then click Next:
l User Name: .\Administrator
l Password: password
The password is the administrative user password of the Local-Windows VM.
7. Accept the default settings, and then click Next.
8. Click Install to complete the installation.

9. Uncheck the Launch DC Agent Install Wizard check box.

DO NOT REPRINT
Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode Configure the FSSO Collector Agent
© FORTINET
10. Click Finish.
You successfully installed the FSSO collector agent.
Configure the FSSO Collector Agent
In this procedure, you will configure the FSSO collector agent to allow FortiGate to poll information from it using
collector agent-based polling mode without a DC agent.
To launch the FSSO collector agent

1. On the Local-Windows VM, click the Windows icon to open the Start menu.
2. At the bottom of the screen, click the down arrow .
3. Scroll right, and, in the Fortinet menu, select Configure Fortinet Single Sign On Agent.
The Fortinet Single Sign On Agent Configuration configuration window opens.
To enable an authenticated connection from FortiGate

1. Continuing in the Fortinet Single Sign On Agent Configuration wizard, in the Authentication section,
complete the following:
l Select the Require authenticated connection from FortiGate check box.
l In the Password field, type Fortinet.

DO NOT REPRINT
Configure the FSSO Collector Agent Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode
© FORTINET
You will use this password later when configuring FortiGate. This password allows
FortiGate to communicate and poll the logon events from the FSSO collector agent.
To select a DC to monitor
1. Continuing in the Fortinet Single Sign On Agent Configuration wizard, in the Common Tasks section, click
Show Monitored DCs to specify the monitored domain controller.
2. Click Select DC to Monitor.
3. In the Working Mode section, make sure the following elements are selected in order to poll the logon sessions
from the domain controller:
l Polling Mode (Polling logon sessions from Domain Controller)
l Check Windows Security Event Logs
Collector agent-based polling mode has three options for collecting login information:
1. NetAPI: Polls NetSessionEnum function on Windows every 9 seconds or less.

2. WinSecLog: Polls all security events on DC every 10 seconds or more.
3. WMI: DC returns all requested login events in three seconds.
The poll interval times are estimated and depend on the number of servers and
network latency.
4. In the Domain controller monitored by this collector agent section, select the TRAININGAD/Win-
Internal.trainingAD.training.lab check box to monitor by FSSO collector agent.
5. Click OK.
6. Once complete, click Refresh Now.
You will see a logon event for 10.0.1.10, which is the IP address for the Local-Windows VM.

DO NOT REPRINT
Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode Configure the FSSO Collector Agent
© FORTINET
7. Click Close.
To specify monitoring groups

1. Continuing in the Fortinet Single Sign On Agent Configuration wizard, in the Common Tasks section, click Set
Group Filters to specify the monitored groups.
2. Click Add.
3. Select the Default filter check box, and then click Advanced.
4. Expand TRAININGAD , and then select the AD-users check box.
5. Click Add selected user groups.

Your monitored group is named: TRAININGAD/AD-users.

DO NOT REPRINT
Configure the FSSO Collector Agent Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode
© FORTINET
6. Click OK.
7. Click OK.
FortiGate will poll this monitored group after you configure the SSO settings on FortiGate.
8. Click Save&close to finish the configuration.

The FSSO collector agent loads your settings.

DO NOT REPRINT
Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode Configure SSO on FortiGate
© FORTINET
Configure SSO on FortiGate
In this procedure, you will set up the SSO server on FortiGate. This process allows FortiGate to automatically
identify the user who connects using SSO. Then, you must add the polled FSSO users to an FSSO user group,
before configuring your firewall policies.
To configure the SSO server on FortiGate

2. Click User & Device > Single Sign-On.
3. Click Create New, and then enter the following settings.
Field Value
Type Fortinet Single-Sign-On Agent
Name TrainingDomain
Primary FSSO Agent 10.0.1.10
Password Fortinet
Note: This is the password you specified while configuring the Fortinet
Single Sign-On Agent. This password allows the FortiGate to
communicate and poll the logon events from the FSSO collector agent.
4. Click Apply & Refresh.

FortiGate identifies the group based on the filters from the FSSO collector agent.
5. Click View.
You will see the monitored group named: TRAININGAD/AD-USERS.
Stop and think!

Why does the User/Group field not automatically display after clicking Apply and Refresh?
Apply and Refresh allows FortiGate to communicate and poll information from the FSSO collector agent.
If FortiGate does not refresh with the correct polled information, it could be a password mismatch. The
agent IP password must be the same as the password you set up in the Authentication section during
the FSSO collector agent configuration.
6. Click X to close the Collector Agent Group Filters window.

7. Click OK.
A green checkmark in the Status column confirms the communication with the FSSO collector agent is up.

DO NOT REPRINT
Assign Polled FSSO Users to a Firewall Policy Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode
© FORTINET
To assign the polled FSSO user to an FSSO user group

1. Continuing on the FortiGate-Local GUI, click User & Device > User Groups.
2. Click Create New, and then enter the following settings:
Field Value
Name Training
Type Fortinet Single Sign-On (FSSO)
Members TRAININGAD/AD-USERS
The polled FSSO user is automatically listed because of the selected group type:
FSSO.
3. Click OK.
Assign Polled FSSO Users to a Firewall Policy
In this procedure, you will assign your polled FSSO user as a source on a firewall policy. This allows you to control
access to network resources based on user identity.
To test the connection without assigning the polled FSSO user to any firewall policy
1. On the Local-Windows VM, open a new browser tab, and go to https://www.fortinet.com.
You will note that all users can access the Fortinet website.
To add the FSSO user group to your firewall policy

1. Return to your browser tab where you are logged into the Local-FortiGate GUI, and click Policy & Objects >
IPv4 Policy.
2. Edit the firewall policy named Full_Access.
3. In the Source drop-down list, click LOCAL_SUBNET.
4. Then, in the Select Entries section, select User and add the Training group.

DO NOT REPRINT
Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode Test FSSO
© FORTINET
5. Click OK.
Test FSSO
After a user logs on to the Windows Active Directory domain, the user is automatically identified based on their
IP. As a result, FortiGate allows the user to access network resources as policy decisions are made.
For the purposes of this lab, you will generate a user logon event and monitor FortiGate to observe how it
identifies the user.
To test the connection after assigning the polled FSSO user to the firewall policy
1. On the Local-Windows VM, open a new browser tab, and go to http://support.fortinet.com.
Stop and think!

The Fortinet Support website does not load, why?
Because the current logged in user is not within the TRAININGAD/AD-USERS group.
To review the connection status between the FSSO collector agent and FortiGate
session.
3. Enter the following command to show the connection status between FortiGate and each collector agent.
diagnose debug enable

diagnose debug authd fsso server-status
4. Observe the CLI output.

Your FortiGate is connected to the FSSO collector agent.

DO NOT
Test REPRINT
FSSO Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode
© FORTINET
Server Name Connection Status Version
----------- ---------- --------------
TrainingDomain connected FSSO 5.0.0261
To monitor communication between the FSSO collector agent and the FortiGate (1)
1. On your lab dashboard, open the Local-FortiGate VM console.
2. Login as admin and leave the password blank.

3. Enter the below commands:
diagnose debug application authd 8256
You will return to this output after generating a logon event. Continue to the next procedure.
To generate a logon event

1. Return to the Local-Windows VM, and click the Windows button.
2. Select Administrator, and then click Sign out.
3. On the Local-Windows dashboard, in the upper-right corner of the screen, click Keyboard > Send Ctrl-Alt-Del.
4. Select Other User and to log in with the following credentials:
Field Value
User name aduser1
Note: This user has been precreated for you in Active Directory.
Password Training!

DO NOT REPRINT
Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode Test FSSO
© FORTINET
5. Press Enter.
To monitor communication between the FSSO collector agent and the FortiGate (2)
1. Return to the console session of the Local-FortiGate VM, and view the output of the diagnose command:
[_process_logon: 871]: ADUSER1(10.0.1.10, 0) logged from TrainingDomain.
You have generated a logon event in the Local-Windows VM and it has been captured
by your domain controller, polled by your collector agent, and forwarded to FortiGate.
You may see two IP addresses because the Local-Windows VM has two NICs in your
lab environment.
2. Enter the following command to stop the debug process:

diagnose debug reset
To display the FSSO logins

1. Continuing on the Local-FortiGate VM console, type the following command:
diagnose debug authd fsso list
2. Review the output, which shows the FSSO logins.
----FSSO logons----
IP:10.0.1.10 User: ADUSER1 Groups: TRAINING/AD-USERS
Workstation: WIN-INTERNAL.TRAININGAD.TRAINING.LAB MemberOf: Training
Total number of logons listed: 1, filtered: 0
----end of FSSO logons----
lab environment.
To review the user event logs

1. Return to your Local-Windows VM where you are logged into Windows as aduser1.
2. Open a browser and log in to the Local-FortiGate GUI at http://10.0.1.254 as admin and leave the
password field empty.
3. Click Log & Report > User Events.
4. Select a log, and then click Details to view more information about it.

DO NOT
Test REPRINT
FSSO Exercise 1: Configuring FSSO Collector Agent-Based Polling Mode
© FORTINET
To monitor FSSO logons

1. Continuing on the Local-FortiGate GUI, click Monitor > Firewall User Monitor.
lab environment.
To test the connection after generating a logon event

1. Continuing on the Local-Windows VM, open a new browser tab, and go to http://support.fortinet.com.
As expected, ADUSER1 is granted to access the network resources.
To reconnect to the admin user

1. Continuing on the Local-Windows VM, click the Windows button.
2. Select aduser1, and then click Sign out.
3. On the Local-Windows dashboard, in the upper-right corner of the screen, click Keyboard > Send Ctrl-Alt-Del.
4. Select Other User and log on with the following credentials.
Field Value
User name Administrator
Password password
5. Press Enter.

DO NOT REPRINT
© FORTINET
Lab 7: High Availability (HA)
In this lab, you will set up a FortiGate Clustering Protocol (FGCP) high availability (HA) cluster of FortiGate
devices. You will explore active-active HA mode and observe FortiGate HA behavior. You will also perform an HA
failover and use diagnostic commands to observe the election of a new primary in the cluster.
Finally, you will configure management port(s) on each FortiGate to reach each FortiGate individually for
management purposes.
Objectives
l Set up an HA cluster using FortiGate devices.
l Observe HA synchronization and interpret diagnostic output.
l Perform an HA failover.
l Manage individual cluster members by configuring a reserved management interface.
Time to Complete
Lab HA Topology
After you upload the required configurations to each FortiGate, the logical topology will change to the following:
Prerequisites
Before beginning this lab, you must restore a configuration file to each FortiGate.

DO NOT REPRINT
Lab HA Topology Lab 7: High Availability (HA)
© FORTINET
Use the procedure that follows to restore the correct configuration to each FortiGate.
Failure to restore the correct configuration to each FortiGate will prevent you from
doing the lab exercise.
To restore the Local-FortiGate configuration


4. Click Desktop > Resources > FortiGate-Infrastructure > HA > local-ha.conf, and then click Open.
5. Click OK.
To restore the Remote-FortiGate configuration


4. Click Desktop > Resources > FortiGate-Infrastructure > HA > remote-ha.conf, and then click Open.
5. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 1: Configuring High Availability (HA)
FortiGate High Availability (HA) uses the FortiGate Clustering Protocol (FGCP), which uses a heartbeat link for
HA-related communications to discover other FortiGate devices in same HA group, elect a primary device,
synchronize configuration, and detect failed devices in an HA cluster.
In this exercise, you will configure HA settings on both FortiGate devices. You will observe the HA synchronize
status, and verify the configuration is in sync on both FortiGate devices using the diagnose commands.
Configure HA Settings on Local-FortiGate
Now, you will configure HA-related settings using the Local-FortiGate GUI.
To configure HA settings on Local-FortiGate

2. Click System > HA, and then configure the following HA settings:
Field Value
Mode Active-Active
Device priority 200
Group name Training
Password Fortinet
Tip: Click Change, and then type the password.
Session pickup <enable>
Heartbeat interfaces port2
Click X to remove port4.
The configuration should like the following example:

DO NOT REPRINT
Configure HA Settings on Remote-FortiGate Exercise 1: Configuring High Availability (HA)
© FORTINET
3. Click OK.
Configure HA Settings on Remote-FortiGate
Now, you will configure HA-related settings on Remote-FortiGate using the console.
To configure HA settings on Remote-FortiGate

1. From the My Systems view, click Remote-FortiGate to open the Remote-FortiGate console window.
2. Log in as admin (blank password).

DO NOT REPRINT
Exercise 1: Configuring High Availability (HA) Observe and Verify the HA Synchronization Status
© FORTINET
3. Enter the following commands to configure the HA settings:
config system ha
set group-name Training
set mode a-a
set password Fortinet
set hbdev "port2" 0
set session-pickup enable
set override disable
set priority 100
end
Observe and Verify the HA Synchronization Status
Now that you have configured HA on both FortiGate devices, you will verify that HA has been established and the
configurations are fully synchronized.
The checksums for all cluster members must match, in order for the FortiGate devices to be in a synchronized
state.
To observe and verify the HA synchronization status

1. Continuing on the Remote-FortiGate console, you should see the error messages that FortiGate sends to the
console.
This sometimes shows useful status change information.
2. Wait four to five minutes for the FortiGate devices to synchronize.

After the FortiGate devices are synchronized, the FortiGate console will log out all admin users.
slave succeeded to sync external files with master
slave starts to sync with master
logout all admin users
3. When prompted, log back in to the Remote-FortiGate console as admin (blank password).
4. To check the HA synchronize status, run the following command: .
diagnose sys ha checksum show

DO NOT
VerifyREPRINT
FortiGate Roles in a HA Cluster Exercise 1: Configuring High Availability (HA)
© FORTINET
5. From the My Systems view, click Local-FortiGate to open the Local-FortiGate console window.
6. Log in as admin (blank password).

7. To check the HA synchronize status, run the following command:
diagnose sys ha checksum show
8. Compare the output from both FortiGate devices.

If both FortiGate devices are synchronized, then the checksums will match.
9. Alternatively, you can run the following command on the console of any FortiGate in the cluster, to view the
checksums of all cluster members:
diagnose sys ha checksum cluster
Verify FortiGate Roles in a HA Cluster
After the checksums of both FortiGate devices match, you will verify the cluster member roles to confirm the
primary and secondary devices.
To verify FortiGate roles in an HA cluster

1. From the My Systems view, on both the Local-FortiGate console and the Remote-FortiGate console, run the
following command to verify that the HA cluster has been established:
get system status
2. View the Current HA mode line on both consoles.

Notice that the Local-FortiGate is a-a master, and the Remote-FortiGate device is a-a backup.
In this configuration, the FortiGate device that is named Local-FortiGate is the master
in the HA cluster because override is disabled and monitored ports are not configured.
Next, the cluster checks for priority—Local-FortiGate, which has a priority of 200, has
greater priority than Remote-FortiGate, which has a priority of 100.
View Session Statistics
Now, you will view session statistics.

DO NOT REPRINT
Exercise 1: Configuring High Availability (HA) View Session Statistics
© FORTINET
To view session statistics
1. Return to the Local-Windows VM, and open few web browser tabs and connect to a few websites. For example:
l https://docs.fortinet.com
l www.yahoo.com
l www.bbc.com
2. Return to the Local-FortiGate console and the Remote-FortiGate console, and run the following command on
each:
get system session status
The primary FortiGate will have more sessions than the secondary FortiGate. This is
because all management traffic is with the primary; all non-TCP traffic is also handled
by the primary. By default, only TCP sessions that require a security profiles inspection
are load balanced between the primary and secondary FortiGate devices.

DO NOT REPRINT
© FORTINET
Exercise 2: High Availability Failover
You have set up an HA cluster. Now, you will trigger an HA failover and observe the renegotiation among devices
to elect a new primary device and redistribute the sessions.
Trigger Failover by Rebooting the Primary FortiGate
You will reboot the primary FortiGate in the cluster to trigger failover.

1. On the Local-FortiGate GUI (10.0.1.254 | admin <blank password>), complete the following:
l Play a long video on http://www.dailymotion.com.
l Run a continuous ping to IP address 4.2.2.2.
2. On the Local-FortiGate console (admin <blank password>), reboot Local-FortiGate.
After you have performed these steps, seeVerify the HA Failover and FortiGate Roles on page 109.
To trigger failover by rebooting the primary FortiGate

1. On the Local-Windows VM, open a web browser and go to the following URL:
http://www.dailymotion.com
If Java is not enabled, enable it.
2. Play a long video (over five minutes).

3. While the video is playing, open a command prompt, and then run a continuous ping to a public IP address.
ping 4.2.2.2 -t
4. To trigger a failover, on the Local-FortiGate console, run the following command to reboot the Local-FortiGate.
execute reboot
5. Press y to confirm that you want to reboot the FortiGate.

DO NOT REPRINT
Exercise 2: High Availability Failover Verify the HA Failover and FortiGate Roles
© FORTINET
Verify the HA Failover and FortiGate Roles
Now, you will verify the HA failover, and check the roles of FortiGate in an HA cluster.
To verify the HA failover and FortiGate roles

1. Return to the Local-Windows VM and check the command prompt and video that you started earlier.
Because of the failover, the Remote-FortiGate device is now the primary processor of traffic. Your ping and
video should still be running.
2. To verify that Remote-FortiGate is acting as the primary device in the HA cluster, on the Remote-FortiGate
console, run the following command:
get system status
Stop and think!

When Local-FortiGate finishes rebooting and rejoins the cluster, does it rejoin as the secondary, or resume
its initial role of primary?
3. To see the status of all cluster members, run the following command on any FortiGate in the cluster:
diagnose sys ha status
You should see that Local-FortiGate rejoins the cluster as a secondary. It has lost its role of primary.
In this configuration, the FortiGate device named Local-FortiGate becomes the

secondary in the HA cluster because override is disabled and monitored ports are not
configured. Next, the cluster checks for uptime. Because Local-FortiGate was
rebooted, it has less uptime than Remote-FortiGate.
Trigger an HA Failover by Resetting the HA Uptime
Now, you will trigger a failover by resetting the HA uptime on the current primary FortiGate—which should be
Remote-FortiGate—and verifying FortiGate's role in the HA cluster.
To trigger an HA failover by resetting the HA uptime on FortiGate

1. On the Remote-FortiGate console, run the following command:
diagnose sys ha reset-uptime
By resetting the HA uptime, you are forcing the cluster to use the next parameter to
determine which FortiGate has more priority for becoming the primary. As per the
configuration, Local-FortiGate has a priority of 200, and Remote-FortiGate has a
priority of 100. Local-FortiGate will become the primary device in the cluster.

DO NOT REPRINT
Observe HA Failover Using Diagnostic Commands Exercise 2: High Availability Failover
© FORTINET
2. To see the status of all cluster members, run the following command on any FortiGate console in the cluster:
diagnose sys ha status
Local-FortiGate now has the primary role in the cluster.
3. On the Remote-FortiGate console, run the following command to verify that the Uptime (system uptime) on
Remote-FortiGate remains unchanged:
get system performance status
Notice that only the HA uptime is reset, not the Remote-FortiGate uptime.
Observe HA Failover Using Diagnostic Commands
The HA synchronization process is responsible for FGCP packets that communicate cluster status and build the
cluster. You will use real-time diagnostic commands to observe this process.
To observe HA failover using diagnostic commands

1. On the Local-FortiGate console,log in as admin and leave the password field empty.
2. Run the following commands.

diagnose debug application hasync 0
diagnose debug application hasync 255
The diagnose debug application hasync 0 command is used to stop the

debug. You will use this entered command later.
3. On the Remote-FortiGate console, run the following command to reboot the Remote-FortiGate:
execute reboot
4. Press y to confirm that you want to reboot FortiGate.

5. On the Local-FortiGate console, view the output while the secondary device reboots and starts communicating
with the cluster.

DO NOT REPRINT
Exercise 2: High Availability Failover Observe HA Failover Using Diagnostic Commands
© FORTINET
The output will show that the current primary FortiGate is sending heartbeat packets and trying to
synchronize its configuration with the secondary FortiGate’s configuration.
6. To stop the debug output on Local-FortiGate, press the Up Arrow key twice, select the second-last command (in
this case, diagnose debug application hasync 0), and then press the Enter key.
7. Close the command prompt to stop the continuous ping.
8. Close the browser.

DO NOT REPRINT
© FORTINET
Exercise 3: Configuring the HA Management Interface
In this exercise, you will configure a spare interface in the cluster to be a nonsynchronizing management
interface. This will allow both FortiGate devices to be reachable only for SNMP and management purposes.
If a management interface is not configured, you will have access to the GUI of only the primary FortiGate in the
cluster. However, you can connect to the secondary FortiGate only through the primary FortiGate's CLI or through
the console connection.
You can also configure an in-band HA management interface, which is an alternative to the reserved HA
management interface feature and does not require reserving an interface that is only for management access.
Access the Secondary FortiGate through the Primary FortiGate CLI
You will connect to the secondary FortiGate through the CLI of the primary FortiGate.
To access the secondary FortiGate through the primary FortiGate CLI

1. On the Local-Windows VM, open PuTTY and connect over SSH to the LOCAL-FORTIGATE saved session.
3. Type the following command to access the secondary FortiGate CLI through the primary FortiGate’s HA link:
execute ha manage <id>
Use ? to list the id values.
4. When prompted, log in as admin to Remote-FortiGate.
5. Run the following command to get the status of the secondary FortiGate:

DO NOT REPRINT
Exercise 3: Configuring the HA Management Interface Set Up a Management Interface
© FORTINET
get system status
6. View the Current HA mode line.

You will notice that the Remote-FortiGate device is a-a backup.
7. To return to the CLI of Local-FortiGate, run the following command to return to the primary:
exit
8. Run the following command to refresh license information:

execute update-now
Set Up a Management Interface
You will use an unused interface on the FortiGate devices in an HA cluster to configure a management interface.
This allows you to configure a different IP address for this interface for each FortiGate in the HA cluster.
To set up a management interface

1. On the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI (usually the primary) at
10.0.1.254 as admin and leave the password field empty.
2. Click System > HA.
3. Right-click Local-FortiGate, and then click Edit.
4. Enable Management Interface Reservation, and in the Interface field, select port7.
5. Click OK.
port7 connects to the same LAN segment as port3.

Configure and Access the Primary FortiGate Using the Management Exercise 3: Configuring the HA Management
DO NOT REPRINT
Interface Interface
© FORTINET
Configure and Access the Primary FortiGate Using the Management Interface
You will configure and verify access to the primary FortiGate using the management interface.
To configure and verify access to the primary FortiGate using the management interface
1. From the My Systems view, on the Local-FortiGate console, log in as admin.
2. Run the following commands to configure port7:
config system interface

edit port7
set ip 10.0.1.253/24
set allowaccess http snmp ping ssh
end
Even though this address overlaps with port3, and would not usually be allowed
(FortiGate does not allow overlapping subnets), it is allowed here because the
interface now has a special purpose, and is excluded from the routing table.
3. Return to the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.253 (note
the IP address) as admin and leave the password field empty.
This will verify connectivity to port7.
Configure and Access the Secondary FortiGate Using the Management

Interface
You will configure and verify access to the secondary FortiGate using the management interface.

1. On the Remote-FortiGate console (admin | <blank password>, complete the following:
l Verify that the non synchronizing interface settings have been synced to the secondary.
show system ha
l Verify that port7 has no configuration, and then configure the port7 IP/Netmask as
10.0.1.252/24 with the same allowaccess configured for Local-FortiGate port7.
2. On the Local-Windows VM, log in to the Remote-FortiGate GUI (admin | <blank password>) using the
port7 IP address to verify connectivity.
After the configuration is ready, see Disconnect FortiGate From the Cluster on page 115.

DO NOT REPRINT
Exercise 3: Configuring the HA Management Interface Disconnect FortiGate From the Cluster
© FORTINET
To configure and verify access to the secondary FortiGate using the management interface
1. From the My Systems view, on the Remote-FortiGate console, log in as admin (blank password).
2. Verify that the non synchronizing interface settings have been synced to the secondary:
show system ha
Look for ha-mgmt-status and ha-mgmt-interface. These should be set.
3. Run the following command to verify that port7 has no configuration:
show system interface
4. Configure port7:
config system interface

edit port7
set ip 10.0.1.252/24
set allowaccess http ping ssh snmp
end
5. Return to the Local-Windows VM.

6. Open a browser and log in to the Remote-FortiGate GUI at 10.0.1.252 (note the IP address) as admin and
This will verify connectivity to port7.
Each device in the cluster now has its own management IP address for monitoring purposes.
Disconnect FortiGate From the Cluster
You will disconnect Remote-FortiGate from the cluster. FortiGate will prompt you to configure an IP address on
any port on FortiGate so that you can access it after disconnecting.
To disconnect FortiGate from the cluster

1. Continuing on the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 as
admin and leave the password field empty.
2. Click System > HA.
3. Right-click Remote-FortiGate, and then click Remove device from HA cluster.

DO NOT REPRINT
Restore the Remote-FortiGate Configuration Exercise 3: Configuring the HA Management Interface
© FORTINET
4. When prompted, configure the following settings:
Field Value
Interface port3
IP/Netmask 10.0.1.251/24
5. Click OK.
This removes FortiGate from the HA cluster.
Restore the Remote-FortiGate Configuration
Now, you will restore the Remote-FortiGate configuration so that you can use the Remote-FortiGate in the next
labs.
Failure to perform these steps will prevent you from doing the next exercise.

DO NOT REPRINT
Exercise 3: Configuring the HA Management Interface Restore the Remote-FortiGate Configuration
© FORTINET

l Log in to the Remote-FortiGate GUI using the IP address configured in the previous procedure. If Remote-
FortiGate is waiting for a response from the license authentication server, run the command below to force
an immediate license authentication retry.
execute update-now
l Restore the Remote-FortiGate configuration using the remote-initial.conf file located in Desktop
> Resources > FortiGate-Infrastructure > HA folder.
To restore the Remote-FortiGate configuration

1. On the Remote-FortiGate console, run the following command to validate license and support information for
Remote-FortiGate:
execute update-now
In this environment, the FortiManager is acting as a local FortiGuard server. It

validates the FortiGate licenses and replies to FortiGuard Web Filtering rating
requests from FortiGate VMs. As Remote-FortiGate is removed from the HA cluster, it
may take few minutes to validate its license. The execute update-now
command is used to force an immediate license authentication retry.

5. Click Desktop > Resources > FortiGate-Infrastructure > HA > remote-initial.conf, and then click
Open.
6. Click OK.

DO NOT REPRINT
Restore the Remote-FortiGate Configuration Exercise 3: Configuring the HA Management Interface
© FORTINET
Failure to perform these steps will prevent you from doing the next exercises.

DO NOT REPRINT
© FORTINET
Lab 8: Web Proxy
In this lab, you will learn how to configure FortiGate to be an explicit and transparent web proxy.
Objectives
l Configure FortiGate to act as a web proxy.
l Apply security policies to web proxy traffic based on HTTP headers.
l Authenticate, authorize, and monitor web proxy users.
Time to Complete
Prerequisites


4. Click Desktop > Resources > FortiGate-Infrastructure > Web-Proxy > local-web-proxy.conf, and then
click Open.
5. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 1: Configuring an Explicit Web Proxy
During this exercise, you will configure the FortiGate to act as an explicit web proxy. You will also configure the
FortiGate to authenticate and authorize Internet access for specific users. The authentication enforcement is
done with an authentication scheme and an authentication rule. The authorization is done by adding the allowed
user groups to the source of the proxy policy.
After that, you will manually configure Firefox with the proxy IP address and port.
Show the Explicit Web Proxy Settings
By default, the explicit web proxy settings are hidden on the GUI. You will show them.
To show the explicit web proxy settings

3. Under the Security Features section, enable Explicit Proxy.
4. Click Apply.
Enable Explicit Web Proxy
You will enable explicit web proxy on the network setting.
To enable explicit web proxy

1. Continuing on the Local-FortiGate GUI, click Network > Explicit Proxy.
2. Enable Explicit Web Proxy.
3. Click Listen on Interfaces, and select the interface port3.
4. In the HTTP port field, type 8080.
5. In the HTTPS port field, select Use HTTP Port.
6. Click Apply.
Create an Authentication Scheme
You will create an authentication scheme to use the local user database for web proxy authentication.
To create an authentication scheme

1. Continuing on the Local-Windows VM, open PuTTY and connect over SSH to the LOCAL_FORTIGATE saved
session.

DO NOT REPRINT
Exercise 1: Configuring an Explicit Web Proxy Create an Authentication Rule
© FORTINET
3. Enter the following commands to create the authentication scheme:
config authentication scheme
edit WebProxyScheme
set method form
set user-database local
next
end
Create an Authentication Rule
You will enforce web proxy authentication by creating an authentication rule that matches all traffic coming from
the internal subnet. You will use the authentication scheme created in the previous procedure.
To create an authentication rule

1. Continuing on the Local-FortiGate PuTTY session, enter the following commands to create the authentication
rule:
config authentication rule
edit WebProxyRule
set srcaddr LOCAL_SUBNET
set active-auth-method WebProxyScheme
set protocol http
next
end
2. Leave the PuTTY session open (you can minimize it on your desktop).
Create a Proxy Policy
You will create the policy to allow explicit proxy traffic to access the Internet. Only the user student will be
authorized to browse the Internet through the proxy.
To create a proxy policy

1. Return to the browser tab where you are logged in to the Local-FortiGate GUI, and click Policy & Objects >
Proxy Policy.
Field Value
Proxy Type Explicit Web
Enabled On port3

DO NOT REPRINT
Configure Firefox for Explicit Web Proxy Exercise 1: Configuring an Explicit Web Proxy
© FORTINET
Field Value
Source Address > LOCAL_SUBNET
User > STUDENTS (under the USER GROUP section)
Destination all
Schedule always
Action ACCEPT
4. Click OK.
Configure Firefox for Explicit Web Proxy
You have configured Local-FortiGate as an explicit web proxy. Now, you will configure Firefox to use the explicit
web proxy.
To configure Firefox to use the explicit web proxy

1. Continuing on the Local-Windows VM, and the Firefox browser, click the Open Menu icon in the upper-right
corner.
2. Click Options.

DO NOT REPRINT
Exercise 1: Configuring an Explicit Web Proxy Configure Firefox for Explicit Web Proxy
© FORTINET
3. Scroll down to the Network Proxy section, and click Settings.
4. Select Manual proxy configuration, and configure the following settings:
Field Value
HTTP Proxy 10.0.1.254
Port 8080

DO NOT
Test REPRINT
the Explicit Web Proxy Configuration Exercise 1: Configuring an Explicit Web Proxy
© FORTINET
5. Select Use this proxy server for all protocols.
6. In the No Proxy for field, add the subnet 10.0.1.0/24 (separated by a comma).
This list contains the names, IP addresses, and subnets of websites that will be exempted from using the
proxy.
7. Click OK.
8. Close Firefox.
Test the Explicit Web Proxy Configuration
You will test the explicit web proxy configuration.
To test the explicit web proxy configuration

1. Continuing on the Local-Windows VM, open Firefox, and browse to any HTTP website, such as:
FortiGate will request authentication.
2. Use the following credentials:

DO NOT REPRINT
Exercise 1: Configuring an Explicit Web Proxy List the Active Explicit Web Proxy Users
© FORTINET
Field Value
User Name student
Password fortinet
After entering these credentials, you should have Internet access through the explicit web proxy.
List the Active Explicit Web Proxy Users
You will execute a CLI command to display the list of active web proxy users.
To list the active web proxy users

1. Return to your Local- FortiGate PuTTY session, and type the following CLI command to check the list of active
web proxy users:
# diagnose wad user list
List the Active Explicit Web Proxy Sessions
For each explicit web proxy connection to a website, two TCP connections are usually created: one from the client
to the proxy, and one from the proxy to the server.
You will run some debug commands to list the sessions established between the client and the proxy. Then, you
will list the sessions established between the proxy and the servers.
To list the active explicit web proxy sessions between the client and the proxy
1. Continuing on the Local-Windows VM, open a few tabs in Firefox, and generate some HTTP traffic, such as:
2. Return to the Local-FortiGate PuTTY session, and type these CLI commands:
diagnose sys session filter clear

diagnose sys session filter dport 8080
diagnose sys session list
You can also use the grep command to display only the source and destination IP addresses and ports for
each session:
diagnose sys session list | grep hook=pre
3. Now browse the websites you just launched.

4. Review the Local-FortiGate PuTTY session output.

DO NOT REPRINT
List the Active Explicit Web Proxy Sessions Exercise 1: Configuring an Explicit Web Proxy
© FORTINET
Stop and think!
Why is the source IP address of all those sessions 10.0.1.10?
Why is the destination IP address of all those sessions 10.0.1.254?
Why don’t you see any public IP address listed in those sessions?
Two TCP sessions are usually created for any client-to-server connection that goes through an explicit web
proxy: one from the client to the proxy, and one from the proxy to the server. By using the destination port
8080 as the filter, you are listing only the sessions from the client (10.0.1.10) to the proxy's internal
interface (10.0.1.254).
5. Close your broswer.
To list the active explicit web proxy sessions between the proxy and the servers
1. Continuing on the Local-Windows VM, open a few tabs in Firefox, and generate some HTTP traffic, such as:
2. Return to the Local-FortiGate PuTTY session, and type these CLI commands:

diagnose sys session filter dport 80
diagnose sys session list | grep hook=out
3. Now browse the websites you just launched.

4. Review the Local-FortiGate PuTTY session output.
Stop and think!

Why is the source IP address of all these sessions 10.200.1.1?
Why don’t you see the IP address of the Windows server (10.0.1.10)?
By using the destination port 80 as the filter, you are listing only the sessions from the proxy's external
interface (10.200.1.1) to the server. The client's IP, in these cases, is not the source or the destination.

DO NOT REPRINT
© FORTINET
Exercise 2: Configuring the Transparent Web Proxy
During this exercise, you will configure the FortiGate to act as a transparent web proxy. You will use a proxy
address to selectively block web traffic to the Fortinet website while allowing traffic to other destinations.
Disable the Explicit Web Proxy in Firefox
With transparent web proxy, browsers do not need to be explicitly configured to send traffic to the proxy
IP address. HTTP packets are transparently inspected by the proxy as they flow from the client to the server.
To disable the explicit web proxy in Firefox

1. On the Local-Windows VM, open Firefox.
2. In the upper-right corner, click the Open Menu icon.
3. Click Options.
4. Scroll down to the Network Proxy section and click Settings.
5. Select No proxy.
6. Click OK.
7. Close Firefox.

DO NOT REPRINT
Redirect the Traffic to the Transparent Web Proxy Exercise 2: Configuring the Transparent Web Proxy
© FORTINET
Redirect the Traffic to the Transparent Web Proxy
To transparently redirect HTTP packets to the web proxy, the web traffic must match an allowed firewall policy
that is using a proxy options profile with the setting HTTP Policy Redirect enabled. So, you will create a proxy
options profile with this setting enabled and assign it to the outbound firewall policy.
To create a proxy options profile

2. Click Security Profiles > Proxy Options.
3. In the upper-right corner, click the plus (+) icon to create a new proxy options profile.
Field Value
Name HTTP_Redirect
HTTP Policy Redirect <enable>

DO NOT REPRINT
Exercise 2: Configuring the Transparent Web Proxy Redirect the Traffic to the Transparent Web Proxy
© FORTINET
5. Click OK.
To apply the proxy profile to the firewall policy

2. Edit the Full_Access firewall policy that goes from port3 to port1.
3. Under the Security Profiles section, change the Proxy Options profile to HTTP_Redirect.
4. Click OK.

DO NOT REPRINT
Create the Proxy Policies Exercise 2: Configuring the Transparent Web Proxy
© FORTINET
Create the Proxy Policies
You will create two proxy policies. One policy will block traffic to any hostname that contains eicar.org. The
other policy will allow traffic to any other destination. For the first policy, you will use a proxy address to match
traffic using the information in the host field of the HTTP headers.
To create a proxy address

1. Continuing on the Local-FortiGate GUI, click Policy & Objects > Addresses.
2. Click Create New, and then click Address.
Field Value
Category Proxy Address
Name EICAR
Type Host Regex Match
Host Regex Pattern .*eicar\.org
Note that the regex pattern that you entered starts with a dot.
4. Click OK.

l Configure the first proxy policy to block traffic to the EICAR website using the proxy address created in To
create a proxy address on page 130.
l Configure a second proxy policy to allow all other traffic.
After you complete the challenge, seeTesting the Transparent Web Proxy on page 131.
To create a proxy policy to block traffic to the Fortinet web site

1. Continuing on the Local-FortiGate GUI, click Policy & Objects > Proxy Policy.

DO NOT REPRINT
Exercise 2: Configuring the Transparent Web Proxy Testing the Transparent Web Proxy
© FORTINET
Field Value
Proxy Type Transparent Web
Source LOCAL_SUBNET
Destination EICAR (under the PROXY ADDRESS section)
Schedule always
Action DENY
4. Click OK.
To create a proxy policy to allow traffic to other destinations

1. Continuing on the Local-FortiGate GUI, click Policy & Objects > Proxy Policy.
Field Value
Proxy Type Transparent Web
Source LOCAL_SUBNET
Destination all
Schedule always
Action ACCEPT
4. Click OK.
5. Click Apply.
Testing the Transparent Web Proxy
You will test the two transparent proxy policies.
To test the transparent web proxy

1. Continuing on the Local-Windows VM, open a new Firefox browser tab.
2. In the upper-right corner, click the Open Menu icon.

DO NOT REPRINT
Testing the Transparent Web Proxy Exercise 2: Configuring the Transparent Web Proxy
© FORTINET
3. Click History and click Clear Recent History.

4. Click Clear Now.
5. Try to connect to www.eicar.org.
You should get an Access Denied message, indicating that the transparent proxy is blocking the traffic.
6. Try to connect to any other HTTP site, such as:

Traffic should be allowed.
7. Close your browser.

DO NOT REPRINT
© FORTINET
Lab 9: Diagnostics
In this lab, you will run some diagnostic commands to learn about the current status of FortiGate. You will also
use the sniffer and debug flow tools to troubleshoot and fix a connectivity problem.
Objectives
l Identify your network’s normal behavior.
l Monitor for abnormal behavior, such as traffic spikes.
l Diagnose problems at the physical and network layers.
l Diagnose connectivity problems using the debug flow.
l Diagnose resource problems, such as high CPU or memory usage.
Time to Complete
Prerequisites

1. On the Local-Windows VM, open a browser and log in to the Local-Fortigate GUI at 10.0.1.254 as admin and

4. Click Desktop > Resources > FortiGate-Infrastructure > Diagnostics > local-diagnostics.conf, and
then click Open.
5. Click OK.

DO NOT REPRINT
© FORTINET
Exercise 1: Knowing What is Happening Now
During this exercise you will use CLI commands to get information about FortiGate, such as traffic volume, CPU
usage, memory usage, and ARP table.
Execute Diagnostic Commands
You will execute some diagnostic commands and take note of some of the information displayed.
To execute diagnostic commands

1. On Local-Windows, open PuTTY and connect over SSH to the LOCAL_FORTIGATE saved session.
3. Find the following information and write down your answers in the spaces provided. Below, see the list of
commands you should use to get the answers.
Field Value
Firmware branch point
Current HA mode
Hostname
CPU utilization
Memory utilization
Average network usage
Average session setup rate
Negotiated speed and duplex mode for interface

port1
MTU for port1
MAC address for the IP address 10.200.1.254
Name of the process consuming most CPU (if any)
Name of the process consuming most memory

DO NOT REPRINT
Exercise 1: Knowing What is Happening Now Execute Diagnostic Commands
© FORTINET
Use the following CLI commands to find the information requested above:
get system status
get system performance status
get hardware nic port1
diagnose ip arp list
diagnose sys top 1
(Press Shift-P to order the processes by CPU usage, Shift-M to order them by
memory usage, or Q to stop.)

DO NOT REPRINT
© FORTINET
Exercise 2: Troubleshooting a Connectivity Problem
During this exercise, you will use the sniffer and debug flow to troubleshoot a network connectivity problem.
Identify the Problem
As you will see in this procedure, there is a network connectivity problem between the Local-Windows VM and the
Linux server.
To identify the problem

1. On the Local-Windows VM, open a command prompt window.
2. Start a continuous ping to the Linux server (IP address 10.200.1.254):
ping -t 10.200.1.254
The ping is failing. You will use the sniffer and debug flow tools in Local-FortiGate to find out why.
3. Do not close the command prompt window. Keep the ping running.
Use the Sniffer

Now that you understand what the problem is, try to fix it without looking at the FortiGate configuration.
Use the built-in sniffer and debug flow tools to troubleshoot the problem.
After you complete the challenge, see Test the Fix on page 138.
You will start troubleshooting by sniffing the ICMP traffic going to the Linux server.
To use the sniffer

1. On the Local-Windows VM, open PuTTY and connect over SSH to the LOCAL-FORTIGATE saved session.
3. Enter the following command to sniffer the ICMP traffic to 10.200.1.254:
diagnose sniffer packet any "icmp and host 10.200.1.254" 4
4. Observe the output:

interfaces=[any]

DO NOT REPRINT
Exercise 2: Troubleshooting a Connectivity Problem Use the Debug Flow Tool
© FORTINET
filters=[icmp and host 10.200.1.254]
The packets are arriving to FortiGate, but FortiGate is not routing them.
5. Press Ctrl-C to stop the sniffer.
Use the Debug Flow Tool
To get information about why the packets are being dropped, you will run the debug flow tool.
To use the debug flow tool

1. Continuing on the Local-FortiGate PuTTY session, enter the commands below. You will configure the debug flow
filter to capture all ICMP traffic to and from the IP address 10.200.1.254:
diagnose debug flow filter clear

diagnose debug flow filter proto 1
diagnose debug flow filter addr 10.200.1.254
diagnose debug flow trace start 3
Output should be similar to what is shown below. The FortiGate receives the ICMP packet from 10.0.1.10
to 10.200.1.254 from port3:
id=20085 trace_id=1 func=print_pkt_detail line=5363 msg="vd-root received a packet
(proto=1, 10.0.1.10:1->10.200.1.254:2048) from port3. type=8, code=0, id=1,
seq=33."
It creates a new session:

id=20085 trace_id=1 func=init_ip_session_common line=5519 msg="allocate a new session-
00000340"
It finds a route for the destination 10.200.1.254, through port1:

id=20085 trace_id=1 func=vf_ip_route_input_common line=2583 msg="find a route:
flag=04000000 gw-10.200.1.254 via port1"
It drops the packet. The debug flow shows the error message:
id=20085 trace_id=1 func=fw_forward_handler line=586 msg="Denied by forward policy
check (policy 0)"
The message Denied by forward policy check indicates that the traffic is denied by a firewall
policy. It could be either a denied policy explicitly configured by the administrator, or the implicit denied policy
for traffic that does not match any configured policy.
The policy 0 indicates that the traffic was denied by the default implicit policy. If the traffic were blocked
by an explicitly configured policy, its policy ID number would be indicated in this output, instead of the
number zero.

DO NOT REPRINT
Fix the Problem Exercise 2: Troubleshooting a Connectivity Problem
© FORTINET
Fix the Problem
Now that we have found the cause of the problem, let's fix it.
To fix the problem

1. Continuing on the Local-Windows VM, open a browser and log in to the Local-FortiGate GUI at 10.0.1.254 as
admin and leave the password field empty.
3. Look at the firewall policies.
The Full_Access filewall policy does not allow ICMP traffic (only HTTP). This is why FortiGate is dropping
the ping packets.
4. Edit the Full_Access firewall policy.

5. Change the service from HTTP to ALL.
6. Click OK.
Test the Fix
You will test to confirm that the configuration change fixed the problem.
To test the fix

1. Continuing on the Local-Windows VM, check the command prompt window to see if the continuous ping is
working now.
2. Stop the ping by pressing Ctrl-C, but leave the command prompt open.
3. Return to the Local-FortiGate PuTTY session where you are running debug commands, and clear all the ICMP
sessions from the session table:

diagnose sys session filter proto 1
diagnose sys session clear
4. Start the debug flow again:
diagnose debug flow filter clear

diagnose debug flow filter proto 1
diagnose debug flow filter addr 10.200.1.254
diagnose debug flow trace start 3
There should not be any output yet, because the ping is not running.
5. Return to the command prompt window, and start the ping again:
ping -t 10.200.1.254
6. Check the debug flow output.

It is a bit different now. The error message is not displayed and you will see a few new logs.

DO NOT REPRINT
Exercise 2: Troubleshooting a Connectivity Problem Test the Fix
© FORTINET
Traffic is allowed by the firewall policy with the ID 1:
id=20085 trace_id=4 func=fw_forward_handler line=737 msg="Allowed by Policy-1: SNAT"
FortiGate applies source NAT (SNAT):

id=20085 trace_id=4 func=__ip_session_run_tuple line=3164 msg="SNAT 10.0.1.10-
>10.200.1.1:62464"
Additionally, you will see the debug flow logs from the return (ping reply) packets:
id=20085 trace_id=5 func=print_pkt_detail line=5363 msg="vd-root received a packet
(proto=1, 10.200.1.254:62464->10.200.1.1:0) from port1. type=0, code=0, id=62464,
seq=83."
id=20085 trace_id=5 func=resolve_ip_tuple_fast line=5438 msg="Find an existing session,
id-000003f2, reply direction"
id=20085 trace_id=5 func=__ip_session_run_tuple line=3178 msg="DNAT 10.200.1.1:0-
>10.0.1.10:1"
id=20085 trace_id=5 func=vf_ip_route_input_common line=2583 msg="find a route:
flag=04000000 gw-10.0.1.10 via port3"
The procedure in this exercise describes what you should usually do when
troubleshooting connectivity problems on a FortiGate. Sniffer the traffic first, to check
that the packets are arriving to FortiGate, and that FortiGate is properly routing them.
If the sniffer shows that the traffic is being dropped by FortiGate, use the debug flow
tool to find out why.

DO NOT REPRINT
© FORTINET
No part of this publication may be reproduced in any form or by any means or used to make any
derivative such as translation, transformation, or adaptation without permission from Fortinet Inc.,
as stipulated by the United States Copyright Act of 1976.
Copyright© 2018 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet,
Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company
names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and
actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein
represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written
contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified
performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For
absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate.
Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify,
transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.

Do Not Reprint © Fortinet: Fortigate Infrastructure Lab Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Do Not Reprint © Fortinet: Fortigate Infrastructure Lab Guide

Uploaded by

Copyright:

Available Formats

DO NOT REPRINT

FortiGate Infrastructure Lab Guide

Fortinet Network Security Expert Program (NSE)

Virtual Lab Basics 7

Virtual Lab Basics

FortiGate Infrastructure Lab Guide 7

To run the System Checker

Region System Checker

AMER - North and South https://remotelabs.training.fortinet.com/training/syscheck/?location=NAM-

EMEA - Europe, Middle East https://remotelabs.training.fortinet.com/training/syscheck/?location=Europe

APAC - Asia and Pacific https://remotelabs.training.fortinet.com/training/syscheck/?location=APAC

8 FortiGate Infrastructure Lab Guide

To log on to the remote lab

FortiGate Infrastructure Lab Guide 9

3. Click Enter Lab.

10 FortiGate Infrastructure Lab Guide

4. To open a VM, on the dashboard, do one of the following:

Follow the same procedure to access any of your VMs.

FortiGate Infrastructure Lab Guide 11

Disconnections and Timeouts

If that fails, see Troubleshooting Tips on page 14.

Transferring Files to the VM

The GUIs of some Fortinet devices require a minimum screen size.

12 FortiGate Infrastructure Lab Guide

Student Tools: View Broadcast and Raise Hand

FortiGate Infrastructure Lab Guide 13

14 FortiGate Infrastructure Lab Guide

To retry immediately, on the CLI, enter the following command:

FortiGate Infrastructure Lab Guide 15

To restore the Local-FortiGate configuration file

3. Click Local PC, and then click Upload.

16 FortiGate Infrastructure Lab Guide

Exercise 1: Configuring Route Failover

Verify the Routing Configuration

First, you'll verify the existing routing configuration on Local-FortiGate.

Take the Expert Challenge!

l View the existing static route configuration on Local-FortiGate.

To verify the routing configuration

4. Right-click any of the columns to open the context-sensitive menu.

FortiGate Infrastructure Lab Guide 17

The Distance and Priority columns display.

Configure a Second Default Route

Take the Expert Challenge!

18 FortiGate Infrastructure Lab Guide

Configure the Firewall Policies

FortiGate Infrastructure Lab Guide 19

Take the Expert Challenge!

To configure the firewall policies

Incoming Interface port3

Outgoing Interface port2

20 FortiGate Infrastructure Lab Guide

7. Enable logging for All Sessions.

View the Routing Table

To view the routing table

Note that the second default route is not listed.

5. Confirm that the second default route is listed as inactive.

FortiGate Infrastructure Lab Guide 21

6. Leave the PuTTY session open.

Configure Link Health Monitors

To configure link health monitoring

2. Configure another link health monitor for port2.

3. Leave your PuTTY session open.

Test the route failover