Information Security Policies - TEMPLATE

DO NOT REPRINT
© FORTINET
Enterprise Firewall
Student Guide
for FortiGate 5.4.1
DO NOT REPRINT
© FORTINET
Enterprise Firewall Student Guide
for FortiGate 5.4.1
Last Updated: 7 June 2017
We would like to acknowledge the following contributors: Francois Ropert, Rodrigo Vázquez,
Stephane Hamelin, Claudio Capone and Don Murray
® ® ®
Fortinet , FortiGate , and FortiGuard are registered trademarks of Fortinet, Inc. in the U.S. and other
jurisdictions, and other Fortinet names herein may also be trademarks, registered or otherwise, of
Fortinet. All other product or company names may be trademarks of their respective owners. Copyright
© 2002 - 2017 Fortinet, Inc. All rights reserved. Contents and terms are subject to change by Fortinet
without prior notice. 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.
DO NOT REPRINT
© FORTINET
Table of Contents
VIRTUAL LAB BASICS ...................................................................................5
LAB 1—SECURITY FABRIC ...........................................................................15
1 Configuring the Security Fabric ...........................................................................................19
2 Troubleshooting: Security Fabric .........................................................................................24
3 Physical and Logical Topology Views .................................................................................26
LAB 2 —FORTIOS ARCHITECTURE ..............................................................28
1 System Information ..............................................................................................................29
LAB 3 —SYSTEM TROUBLESHOOTING .........................................................30
1 Crash Log.............................................................................................................................31
LAB 4 —TRAFFIC AND SESSION MONITORING ..............................................34
1 Exploring the Session Table ................................................................................................37
2 Troubleshooting: Connectivity Issues ..................................................................................40
LAB 5—ROUTING .........................................................................................43
1 Failover of Existing Sessions ...............................................................................................46
2 Troubleshooting: Routing .....................................................................................................49
LAB 6—FORTIGUARD ..................................................................................52
1 Troubleshooting: Local FDS Issue.......................................................................................56

DO NOT REPRINT
© FORTINET
2 Troubleshooting: Rating Lookups ........................................................................................58
LAB 7—CENTRAL MANAGEMENT..................................................................60
1 FortiManager Registration ...................................................................................................64
LAB 8—OSPF .............................................................................................70
1 Configuring OSPF ................................................................................................................72
2 Troubleshooting: OSPF .......................................................................................................78
LAB 9—WEB FILTERING AND ANTIVIRUS ......................................................80
1 Configuring Web Filtering and AV .......................................................................................82
2 Troubleshooting: Web Filtering ............................................................................................86
3 Troubleshooting: Antivirus ...................................................................................................88
LAB 10—IPS ...............................................................................................91
1 Configuring IPS ....................................................................................................................93
2 IPS Custom Signatures........................................................................................................100
LAB 11—BGP .............................................................................................109
1 Configuring BGP ..................................................................................................................111
2 Troubleshooting: BGP Neighbor ..........................................................................................115
3 Troubleshooting: BGP Routing ............................................................................................117
4 Configuring Prefix Lists ........................................................................................................118
LAB 12—IPSEC ...........................................................................................120
1 Troubleshooting: IPsec ........................................................................................................124
2 VPN Manager.......................................................................................................................126
DO NOT REPRINT
© FORTINET
LAB 13—AUTO DISCOVERY VPN .................................................................138
1 Configuring ADVPN and IBGP ............................................................................................140
2 Troubleshooting: OSPF and BGP........................................................................................145
APPENDIX A: USING RAVELLO ......................................................................147
APPENDIX B: ADDITIONAL RESOURCES ........................................................155
APPENDIX C: PRESENTATION SLIDES............................................................156
1 Enterprise Firewall Solution Overview ................................................................................157
2 FortiOS Architecture ...........................................................................................................181
3 System Troubleshooting .....................................................................................................223
4 Traffic and Session Monitoring ...........................................................................................267
5 Routing ................................................................................................................................303
6 FortiGuard ...........................................................................................................................344
7 Central Management ..........................................................................................................377
8 OSPF...................................................................................................................................398
9 Web Filtering .......................................................................................................................443
10 Intrusion Prevention System .............................................................................................464
11 BGP ...................................................................................................................................511
12 IPsec .................................................................................................................................548
13 Auto Discovery VPN (ADVPN) .........................................................................................584
Solution Slides ........................................................................................................................614

DO NOT REPRINT  Virtual Lab Basics
© FORTINET
Virtual Lab Basics
Network Topology
Enterprise Firewall Student Guide 5

© FORTINET
The following table shows the login credentials for the devices:
Device Username Password
Client-10
student password
ISFW
admin
DCFW
admin
NGFW
admin
Linux Server
student password
FortiManager
admin
Linux Router
student password
Spoke-1
admin
Spoke-2
admin
Using Hatsize
In this class, you will use a virtual lab for hands-on exercises. The virtual labs can run on either one of
the following two platforms: Hatsize or Ravello. Ask your instructor which platform your lab is running
on.
This section explains how to connect to the lab and its virtual machines (VMs) if they are running on
Hatsize.
If your lab is running on Ravello, please ignore this section and read the appendix A instead.
Logging In
1. Run the System Checker. This will fully verify both:
 compatibility with the virtual lab environment's software, and
 that your computer can connect
It can also diagnose problems with your Java Virtual Machine, firewall, or web proxy.
Use the URL for your location.
North America/South America:
https://remotelabs.training.fortinet.com/training/syscheck/?location=NAM-West
Europe/Middle East/Africa:
https://remotelabs.training.fortinet.com/training/syscheck/?location=Europe

© FORTINET
Asia/Pacific:
https://remotelabs.training.fortinet.com/training/syscheck/?location=APAC
If a security confirmation dialog appears, click Run.
If your computer successfully connects to the virtual lab, the result messages for the browser and
network checks will each display a check mark icon. Continue to the next step.
If a browser test fails, this will affect your ability to access the virtual lab environment. If a network
test fails, this will affect the usability of the virtual lab environment. For solutions, either click the
Support Knowledge Base link or ask your trainer.
2. With the user name and password from your trainer, log into the URL for the virtual lab. Either:

© FORTINET
https://remotelabs.training.fortinet.com/
https://virtual.mclabs.com/
3. If prompted, select the time zone for your location, and then click Update.
This ensures that your class schedule is accurate.
4. Click Enter Lab.
A list of virtual machines that exist in your virtual lab should appear.

© FORTINET
From this page, you can access the console of any of your virtual devices by either:
 clicking on the device’s square, or
 selecting System > Open.
5. Click Windows to open a connection to that server.
A new window should open within a few seconds. (Depending on your account’s preferences, the
window may be a Java applet. If this fails, you may need change browser settings to allow Java to
run on this web site. You also may need to review and accept an SSL certificate.)

© FORTINET
Depending on the virtual machine, the applet provides access to either the GUI or a text-based
CLI. Connections to Windows machines will use a Remote Desktop-like GUI. The applet should
automatically log in, then display the Windows desktop. For most lab exercises, you will connect to
this VM.
Disconnections/Timeouts
If your computer’s connection with the virtual machine times out or if you are accidentally
disconnected, to regain access, return to the initial window/tab that contains your session’s list of VMs
and open the VM again.
If that does not succeed, see Troubleshooting Tips.
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 them to your Windows VM. From there, if required, you can use a web browser to upload
them to Fortinet VMs' GUI.
Using Java Instead of HTML5

When you open a VM, by default, your browser will use HTML5 to connect to your lab's VM.
Alternatively, you may be able to use Java instead. Your browser will download and use a Java
application to connect to the virtual lab’s VM. Not all browsers support the Java plug-in, so if you want
to use Java, Mozilla Firefox is recommended. This means that Java must be installed, updated,
and enabled in your browser. Once you have done that, in your virtual lab, click the Settings
button, and then select Use Java Client. Click Save & Disconnect, then log in again. (To use this
preference, your browser must allow cookies.)

© FORTINET
When connecting to a VM, your browser should then open a display in a new applet window.
Screen Resolution
Some Fortinet devices' user interfaces require a minimum screen size.
In the HTML 5 client, to configure screen resolution, open the System menu.

© FORTINET
In the Java client, to configure the screen resolution, click the arrow at the top of the window.
International Keyboards
If characters in your language don’t display correctly, keyboard mappings may not be correct.
To solve this in the HTML 5 client, open the Keyboard menu at the top of the window. Choose to
either display an on-screen keyboard, or send text from your computer to the VM's clipboard.

© FORTINET
To solve this in the Java client, copy and paste between your computer and the Java applet. This
sends special characters or combinations using the keyboard icon at the top of the applet window.
Troubleshooting Tips
 Do not connect to the virtual lab environment through Wi-Fi, 3G, VPN tunnels or other low-
bandwidth or high-latency connections. For best performance, use a stable broadband connection
such as a LAN.
 If disconnected unexpectedly from any of the virtual machines (or from the virtual lab portal),
please attempt to reconnect. If unable to reconnect, please notify the instructor.
 If you can't connect to a VM, on the VM's icon, click System > Power Cycle. This fixes most
problems by forcing VM startup and connection initiation. If that does not solve the problem, try
System > Power Cycle and revert to initial state.
Note: Reverting to the VM's initial snapshot will undo all of your work. Try other solutions first.
 If the HTML 5 client does not work, try the Java client instead. Remembering this preference
requires that your browser allows cookies.
 Do not disable or block Java applets if you want to use the Java client. Network firewalls can
block Java executables. Not all browsers/systems allow Java. In late 2015, Google Chrome
removed Java compatibility, so it cannot be used with the Java client. On Mac OS X since early
2014, to improve security, Java has been disabled by default. In your browser, you must allow
Java for this web site. On Windows, if the Java applet is allowed and successfully downloads,
but does not appear to launch, you can open the Java console while troubleshooting. To do this,

© FORTINET
open the Control Panel, click Java, and change the Java console setting to be Show console.
Note: JavaScript is not the same as Java.
 Prepare your computer's settings:

o Disable screen savers
o Change the power saving scheme so that your computer is always on, and does not go to
sleep or hibernate

DO NOT REPRINT  Lab 1—Security Fabric
© FORTINET
Lab 1—Security Fabric
In this lab, you will learn to configure and troubleshoot the security fabric. Once the security fabric is
configured, you will access the physical and logical topology views.
Objectives
 Use the security fabric to share traffic and threat information among multiple FortiGate devices
 Use FortiView to have a logical and physical view of your network topology
 Troubleshoot common FortiTelemetry problems using a real-time debug
Time to Complete
Estimated: 35 minutes
Which Network Segment Will You Work On?

In this lab, you will configure the ISFW, DCFW, and NGFW FortiGates.

© FORTINET
Prerequisite
Before you begin this lab, you must restore the initial configuration files to the FortiGate devices. The
configuration files are located in the desktop of the Client-10 VM. So, you will connect to the FortiGate
devices from Client-10 to restore them.
To restore the configuration file for the ISFW FortiGate

6. Open the Client-10 VM desktop. Then, open a browser and log in as admin to the ISFW GUI at
10.1.10.254.
Note: If your lab is running on Ravello, you should connect to the Client-10 VM directly
using HTTP, by clicking the link on the lab dashboard. You can also connect directly using
RDP. Click the RDP link displayed in the lab dashboard to download an RDP file. Open
the RDP file to start the RDP client and connect to Client-10. Use the login name
student and the password password. As an alternative, you can connect to the VM
console by clicking the link in the dashboard.
7. Click Dashboard, and then, in the System Information widget, click Restore:

© FORTINET
8. Select Local PC, and then click Upload.

9. Click Desktop > Resources > Enterprise-FW > Initial, and then select ISFW_initial.conf.
10. Click OK.
11. Click OK.
12. FortiGate reboots. Wait until it restarts.
To restore the configuration file for the DCFW FortiGate

13. On the Client-10 VM, open a browser and log in as admin to the DCFW GUI at 10.1.0.100.
14. Click Dashboard, and then, in the System Information widget click Restore.

16. Browse to Desktop > Resources > Enterprise-FW > Initial and select
DCFW_initial.conf.
17. Click OK.

© FORTINET
18. Click OK.
To restore the configuration file for the NGFW FortiGate

1. On the Client-10 VM, open a browser and log in as admin to the NGFW GUI at 10.1.0.254.
2. Click Dashboard and, in the System Information widget, click Restore.

4. Click Desktop > Resources > Enterprise-FW > Initial, and then select NGFW_initial.conf.
5. Click OK.
6. Click OK.

© FORTINET
1 Configuring the Security Fabric
You will configure the security fabric in the FortiGate devices. The NGFW will be the root of the
security fabric tree.
Configuring the Security Fabric in the NGFW

You will start configuring the root of the security fabric tree. Usually, you must complete three steps for
each FortiGate:
 Enabling FortiTelemetry in the interfaces
 Enabling device detection
 Enabling the security fabric
To enable FortiTelemetry in the NGFW interface

1. Open the NGFW GUI and log in as admin.
Note: If your lab is running in Ravello, you should connect to the FortiGate GUI directly by
clicking the link on the lab dashboard.
If your lab is running on Hatsize, connect first to the Client-10 VM, open a browser, and
then connect HTTP to the NGFW IP address 10.1.0.254.
2. Click Network > Interfaces.

3. Click port3, and then click Edit to open it.
4. In Administrative Access, enable FortiTelemetry:
5. Click OK.

© FORTINET
Stop and Think
Why are you enabling FortiTelemetry in port3 and not in port1?
Discussion
The port3 interface is the one facing your internal network. The FortiTelemetry traffic from
the other two FortiGate devices will arrive at this interface.
To enable device detection in the NGFW

1. In the NGFW GUI, click Network > Interfaces.
2. Click port3, and then click Edit to open it one more time.
3. In the Networked Devices section, turn on the Device Detection switch:
4. Click OK.
To enable the security fabric in the NGFW

1. In the NGFW GUI, click System > Cooperative Security Fabric.
2. Enable Cooperative Security Fabric (CSF).
3. Configure the following group name and group password:
Field Value
Group name fortinet
Group password fortinet
Connect to upstream FortiGate Disabled
4. Click Apply.

© FORTINET
Configuring the Security Fabric in the DCFW
You will configure one of the branches of the security fabric tree. Follow the same three steps:
 Enabling FortiTelemetry in the interfaces
 Enabling device detection
 Enabling the security fabric
To enable FortiTelemetry in the DCFW interface

1. Open the DCFW GUI and log in as admin.
Note: If your lab is running on Ravello, you should connect to the FortiGate GUI directly by
clicking the link on the lab dashboard.
If your lab is running on Hatsize, connect first to the Client-10 VM, open a browser and
connect HTTP to the DCFW IP address 10.1.0.100.
2. Click Network > Interfaces.

3. Click port1, and then click Edit to open it.
4. In the Administrative Access section, select the FortiTelemetry check box:
5. Click OK.
Stop and Think

Why are you enabling FortiTelemetry in port1 now?
Discussion
The port1 interface is the one facing the security fabric tree root. The FortiTelemetry traffic
from this FortiGate originates from this interface.

© FORTINET
To enable device detection in the DCFW
1. In the DCFW GUI, click Network > Interfaces.
2. Click port3, and then click Edit to open it one more time.
3. In the Networked Devices section, turn on the Device Detection switch:
4. Click OK.
5. Select port1, and then click Edit.
6. In the Networked Devices section, turn on the Device Detection switch.
7. Click OK.
To enable the security fabric in the DCFW

1. In the DCFW GUI, click System > Cooperative Security Fabric.
2. Enable Cooperative Security Fabric (CSF).
3. Configure the following group name and group password:
Field Value
Group name fortinet
Group password fortinet
4. Enable Connect to upstream FortiGate.

5. Enter the FortiGate IP address 10.1.0.254. This is the address of the upstream FortiGate
which, in this case, is the NGFW.
6. Click Apply.

© FORTINET
Monitoring the FortiTelemetry connection
In the CLI of the NGFW, you will check the status of the FortiTelemetry connection between the
DCFW and the NGFW.
To monitor the FortiTelemetry connection

1. Open the NGFW CLI and log in as admin.
Note: If your lab is running on Ravello, you should connect to the FortiGate CLI directly by
using an SSH client (such as PuTTY) and the respective IP address and SSH port number
displayed in the lab dashboard. Another alternative is to connect to the FortiGate console
port by clicking the link in the lab dashboard.
If your lab is running on Hatsize, connect first to the Client-10 VM, open PuTTY, and
connect SSH to the NGFW IP address 10.1.0.254.
2. Run the following CLI command:
# diagnose sys csf downstream

The IP address and serial number of the DCFW should appear, indicating that the FortiTelemetry
connection is up:
3. Run the following command to display security fabric statistics:
# diagnose test application csfd 1

The status of the DCFW should appear as: link-ok SSL-ok auth-ok hello-ok

© FORTINET
2 Troubleshooting: Security Fabric
Network topology
Problem description
The ISFW has been pre-configured as a branch of the security fabric tree. However, it is not
connecting to the NGFW, which is the security fabric root.
Objective
Use the security fabric real-time debug to fix the problem. Don’t review the FortiGate configurations
until you identify where the problem is located, based on the output of the debug commands.
Tips for troubleshooting

 Run the following command in the NGFW:

The output shows only one downstream FortiGate (DCFW) connecting to the NGFW. Why isn't
the ISFW there?
 Run the built-in sniffer in the NGFW to capture the traffic coming from the ISFW:
# diagnose sniffer packet any "port 8013 and host 10.1.0.1" 4

© FORTINET
 Run the security fabric real-time debug in both the ISFW and the NGFW:
# diagnose debug application csfd -1
# diagnose debug enable

 Make the configuration changes necessary to fix the problem.
 To confirm the fix, use the following command again:
Downstream FGT 1: FGVM010000077646 (vdom: root) (10.1.0.1)
Downstream FGT 2: FGVM010000077648 (vdom: root) (10.1.0.100)

The output should display both downstream FortiGates.
 After you finish troubleshooting, disable the real-time debug using the following commands:
# diagnose debug application csfd 0
# diagnose debug disable

© FORTINET
3 Physical and Logical Topology Views
Now that the FortiTelemetry connections from the DCFW and the ISFW are up, you can use FortiView
to view your security topology.
Generating Web Traffic from Client-10

You will generate web traffic from Client-10. In this way, the FortiGate will display the device in
FortiView after FortiGate detects and identifies the device.
To generate web traffic from Client-10

1. Open the Client-10 VM desktop. If you need to authenticate, use the username student with the
password password.
using HTTP, by clicking the link in the lab dashboard. You can also connect directly using
RDP. Click the RDP link in the lab dashboard to download an RDP file. Open this file to
run Windows RDP automatically and connect to Client-10. Alternatively, you can use the
Client-10 console connection.
If your lab is running on Hatsize, connect directly to Client-10 VM.
2. Open a browser and connect to any HTTP site.
Viewing the Physical Topology

The physical topology displays the network devices and how they are connected.
To display the physical topology

1. Open the NGFW GUI and log in as admin.
2. Click FortiView > Physical Topology.
You should see the three FortiGates and the Linux station connected behind the ISFW:

© FORTINET
Viewing the Logical Topology

The logical topology displays the interfaces where each device is connected.
To display the logical topology

1. In the NGFW GUI, click FortiView > Logical Topology.
You should see the devices and interfaces:

DO NOT REPRINT  Lab 2 —FortiOS Architecture
© FORTINET
Lab 2 —FortiOS Architecture
In this lab, you will learn to use system and memory debug commands to describe the status of the
unit.
Objectives
 Use debug commands to diagnose system problems
Time to Complete

In this lab, you will access the ISFW:

DO NOT REPRINT  Lab 2 —FortiOS Architecture
© FORTINET
1 System Information
You will run debug commands to get information about the resources utilization in the ISFW.
Checking the Resources Use

The following group of commands provides information about the memory and CPU use.
To check the resources use

1. Log in to the ISFW GUI, and then click Dashboard.
2. Analyze the information displayed in the System Information and System Resources widgets.
3. Open the ISFW CLI.
4. Run the following two commands:
# get system status
# get system performance status

Analyze the outputs.
5. To get more details about the memory use, run the following commands:
# diagnose hardware sysinfo memory
# diagnose hardware sysinfo shm
# diagnose hardware sysinfo slab

Using the above outputs, can you answer the following questions?
 Does the ISFW have a hard disk for logging?
 How much memory is available?
 Is the unit in conserve mode?
 Has the ISFW ever entered system conserve mode?

DO NOT REPRINT  Lab 3 —System Troubleshooting
© FORTINET
Lab 3 —System Troubleshooting
During this lab you will stop a process manually and view the corresponding crash log.
Objectives
 Generate a crash log and analyze the output
Time to Complete

During this lab you will access the ISFW.

© FORTINET
1 Crash Log
In this exercise you will stop a process manually and analyze the entry generated in the crash log.
Displaying the Processes

You will use a diagnostics command to display the list of processes running the ISFW.
To display the processes

1. Open the ISFW CLI.
2. Run the following command to display the CPU and memory use by process:
# diagnose sys top

What is the process using the most CPU? (Check the fourth column from left to right.)
What is the process using the most memory? (Check the last column from left to right.)
3. The processes that are running with high priority are indicated with a '<':
Can you identify which processes in the ISFW are running with high priority?
Don’t stop the diagnose sys top command yet. Keep it running for the next procedure.
Generating a Crash Log Entry

You will stop a process manually to generate a crash log entry.
To generate a crash log

1. In the ISFW CLI, and from the output of the diagnose sys top command, try to find one the
following two processes: miglogd, or ipshelper. Do you see them running?
2. Choose one of the processes and write down its process ID (the number in the second column
from left to right).
3. Press Ctrl-C to stop the diagnose sys top command.
4. Use the following command to stop the chosen process:
# diagnose sys kill 11 <process_id>

Eleven (11) is the kill signal. In this case the FortiGate stops the process by sending a
segmentation fault (number 11) signal.

© FORTINET
Caution: You use the kill command in this exercise to reproduce a process failure. Be
careful when running it in a FortiGate that is in production. Improperly stopping a process
might make a FortiGate system unstable.
5. Run the following command one more time:
# diagnose sys top

Observe that the stopped process is running again, but this time it is using a higher ID number.
Each time a process starts, it uses the next available process ID number.
6. Press Ctrl-C to stop the diagnose sys top.
Checking the Crashlog

You will review the entry in the crash log by the process stopped in the previous procedure.
To check the crash log

1. In the ISFW CLI, run the following command:
# diagnose debug crashlog read

The output should contain entries similar to the following:
63: 2017-01-23 08:53:49 <00109> firmware FortiGate-VM64

v5.4.1,build1064b1064,160608 (GA) (Release)
64: 2017-01-23 08:53:49 <00109> application miglogd
65: 2017-01-23 08:53:49 <00109> *** signal 11 (Segmentation fault)

received ***
66: 2017-01-23 08:53:49 <00109> Register dump:
67: 2017-01-23 08:53:49 <00109> RAX: 0000000000000001 RBX:

0000000000dc15c0
68: 2017-01-23 08:53:49 <00109> RCX: ffffffffffffffff RDX:

0000000000000400
...
79: 2017-01-23 08:53:49 <00109> CR2: 0000000000000000
80: 2017-01-23 08:53:49 <00109> Backtrace:
81: 2017-01-23 08:53:49 <00109> [0x7f40386ce453] => /fortidev4-

x86_64/lib/libc.so.6
82: 2017-01-23 08:53:49 (epoll_wait+0x00000013) liboffset 000e5453
83: 2017-01-23 08:53:49 <00109> [0x01affd11] => /bin/miglogd

© FORTINET
...
90: 2017-01-23 08:53:49 <00109> [0x7f403860a475] => /fortidev4-

x86_64/lib/libc.so.6
91: 2017-01-23 08:53:49 (__libc_start_main+0x000000f5) liboffset

00021475
92: 2017-01-23 08:53:49 <00109> [0x00424b89] => /bin/miglogd
93: 2017-01-23 08:53:49 miglogd received a signal - 11
94: 2017-01-23 08:53:49 Signal <11> was sent to process <00109> by

user <admin>
95: 2017-01-23 08:53:49 the killed daemon is /bin/miglogd: status=0xb

2. Check the first three lines. They contain the FortiOS build number, the name of the process that
failed (or was stopped) and the kill signal number.

DO NOT REPRINT  Lab 4 —Traffic and Session Monitoring
© FORTINET
Lab 4 —Traffic and Session Monitoring
The following lab exercises show how to use debug commands to troubleshoot connectivity problems.
You will also analyze the information in the FortiGate session table, run the built-in sniffer, and use the
debug flow to understand how FortiGate is processing each IP packet.
Objectives
 Analyze the information in the session table
 Capture traffic using the built-in sniffer tool
 Troubleshoot IP connectivity problems
Time to Complete

In this lab, you will work on Client-10 and the ISFW:

© FORTINET
Prerequisite
Before you begin this lab, you must restore an initial configuration file to the ISFW. The configuration
file is located on the desktop of the Client-10 VM. So, you will connect to the ISFW from Client-10 to
restore it.

1. Open the Client-10 VM desktop. Then, open a browser and log in as admin to the ISFW GUI at
10.1.10.254.
2. Click Dashboard, and then, in the System Information widget, click Restore.

© FORTINET

4. Click Desktop > Resources > Enterprise-FW > Session_Monitoring, and then select
ISFW_Session_Monitoring_initial.conf.
5. Click OK.
6. Click OK.

© FORTINET
1 Exploring the Session Table
In this exercise, you will analyze the information displayed in the FortiGate session table.
Analyzing the Session Table

You will generate SSH traffic from Client-10. Then, you will analyze the entry for this traffic created in
the ISFW's session table.
To analyze the session table

1. Open the Client-10 command prompt using the username student and password password.
Note: If your lab is running on Ravello, you should connect to the Client-10 command
prompt using an SSH client. As an alternative, you can connect to the Client-10 desktop
and open MATE Terminal.
If your lab is running on Hatsize, connect to the Client-10 desktop and open MATE
Terminal.
2. Run the following command to connect SSH to the NGFW:
$ ssh admin@10.1.0.254
Don’t close the SSH session. Keep it connected.
3. Connect to the ISFW CLI and run these commands:
# diagnose sys session filter clear
# diagnose sys session filter dport 22
# diagnose sys session filter dst 10.1.0.254
# diagnose sys session list

4. Analyze the information related to the SSH session created for the test traffic:
session info: proto=6 proto_state=01 duration=241 expire=3570
timeout=3600 flags=00000010 sockflag=00000000 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=log may_dirty none
statistic(bytes/packets/allow_err): org=3677/27/1 reply=3461/24/1
tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0

© FORTINET
orgin->sink: org pre->post, reply pre->post dev=9->3/3->9
gwy=10.1.0.254/10.1.10.10
hook=pre dir=org act=noop 10.1.10.10:34440->10.1.0.254:22(0.0.0.0:0)
hook=post dir=reply act=noop 10.1.0.254:22->10.1.10.10:34440(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
src_mac=2c:c2:60:14:93:55
misc=0 policy_id=2 auth_info=0 chk_client_info=0 vd=0
serial=00000440 tos=ff/ff app_list=0 app=0 url_cat=0
dd_type=0 dd_mode=0
total session 1
Observe the following from the session:
 The may_dirty flag
 The line containing statistics, which displays the number of SSH packets sent and
received
 The ID of the policy matching the traffic
 The protocol state, whose value is 01 indicating that the TCP session is established
Creating a Dirty Session

You will change the configuration in the firewall policies to deny the SSH traffic coming from Client-10.
Then, you will notice that the dirty flag is added to the existing SSH session.
To change the firewall policy

1. Access the ISFW GUI, and then and click Policy & Objects > IPv4 Policy.
2. Edit the firewall policy using the sequence number 1 (the first one from top to bottom).
3. Change the Action to DENY.
4. Click OK.
After a firewall policy configuration change, the FortiGate adds the dirty flag to all the session
with the may_dirty flag. Next time there is traffic matching any of those sessions, FortiGate re-
evaluates the action to take.
To check the dirty flag

1. In the ISFW CLI, run this command again:

You should see the dirty flag:

© FORTINET
2. Switch from the SSH connection on Client-10 to the NGFW and press some keys to generate
more SSH traffic in the existing session. You won’t see the keys you press in the output because
FortiGate is now blocking SSH, but the SSH client is still connected and sending those keys.
3. Switch quickly to the ISFW CLI and check the session information one more time:

If you do all these steps fast enough, you will notice that the session is still there but the block
flag is added. All traffic matching a session with that flag is denied. Also, the session expiration
time is much smaller now. The session remains in FortiGate’s memory until this timer expires (30
seconds):

© FORTINET
2 Troubleshooting: Connectivity Issues
Network topology
Problem description
In this part of the lab, you will troubleshoot various connectivity issues on the ISFW. Don’t make
changes on any other device in the network.
There are four problems:
1. Although the telnet protocol is enabled for administrative access in the ISFW port3
(10.1.10.254), you can’t access the unit's CLI using telnet from Client-10 to 10.1.10.254.
2. You can’t access the web server (http://10.1.4.10) using HTTP from Client-10.
3. You can’t access any public website from Client-10.
4. You can’t telnet the Linux Router (10.200.1.254) from Client-10.
Note: To test the telnet connections, on the Client-10 desktop, use PuTTY.

© FORTINET
Objective
Find the causes of these problems by using debug commands first, before you look for configuration
mistakes.
In which of the four problem scenarios is FortiGate is doing something wrong and in which ones it is
not?
Note: You can change the ISFW configuration only. Don’t make configuration changes
on any other FortiGate device.

 Can you ping the destination IP address from Client-10?
 Use the sniffer tool to verify that the traffic is actually arriving to the ISFW's port3. Use verbosity 4
and a filter that can capture the traffic both ways.
Examples:
# diagnose sniffer packet any "icmp and host 10.1.10.10" 4

 If the traffic is not intended to terminate on FortiGate, use the sniffer again to check that is the
traffic being forwarded to the next-hop IP address (use the network diagram provided). Again, use
a filter in the sniffer that can capture the traffic both ways.
 Check the session table. Is the ISFW creating the session? Check the session protocol state. Do
you see anything wrong there?
# diagnose sys session filter clear
# diagnose sys session filter src 10.1.10.10
# diagnose sys session filter dport <port_number>

 Clear the related session (if any) from the session table, enable the debug flow, and generate
more test traffic. Do you see any debug flow error?
# diagnose debug flow filter clear
# diagnose debug flow filter dport <port_number>
# diagnose debug flow filter addr 10.1.10.10
# diagnose debug flow trace start 10
# diagnose debug flow show console en

© FORTINET
 As a reference, the following table contains the most common debug flow error messages and
possible causes:
Error Possible cause
Denied by forward No firewall policy allows the traffic

policy check
A firewall policy allows the traffic but disclaimer is enabled. Disclaimer must
be accepted first.
Denied by end Source IP address has been quarantined by DLP

point ip filter
check
exceeded shaper Packet dropped because of traffic shaping

limit, drop
Reverse path Packet dropped because of the reverse path forwarding check
check fail, drop
Iprope_in_check() Packet is destined for a FortiGate IP address (management traffic) but:

check failed,
drop  The service is not enabled
 Or the service is using a different TCP port
 Or the source IP address isn’t included in the trusted host list
 Or the packet matches a local-in policy with action deny
Packet is not destined for a FortiGate IP address, but there is a virtual IP or
IP pool configuration using the destination IP address

DO NOT REPRINT  Lab 5—Routing
© FORTINET
Lab 5—Routing
In this lab, you will troubleshoot routing problems. You will test how FortiGate handles a routing
failover scenario.
Objectives
 Analyze the information in the routing table
 Troubleshoot routing problems
Time to Complete

In this lab, you will work on Client-10, the ISFW and the NGFW:

© FORTINET
Prerequisite
Before you begin this lab, you must restore an initial configuration file to ISFW. The configuration file is
located on the desktop of the Client-10 VM. So, you will connect to the ISFW from Client-10 to restore
it.

1. On the Client-10 VM, open a browser and log in as admin to the ISFW GUI at 10.1.10.254.

4. Click Desktop > Resources > Enterprise-FW > Routing, and then select
ISFW_Routing_initial.conf.
5. Click OK.
6. Click OK.

1. On the Client-10 VM, open a browser and log in as admin to the NGFW GUI at 10.1.0.254.

© FORTINET

4. Click Desktop > Resources > Enterprise-FW > Routing, and then select
NGFW_Routing_inital.conf.
5. Click OK.
6. Click OK.

© FORTINET
1 Failover of Existing Sessions
In this exercise, you will test routing failover when the FortiGate has two static routes with the same
distance but different priorities. You will also learn how the route fail-back works when the FortiGate is
doing source NAT of the traffic.
Checking the Routing Table

Before testing the route failover, you will check the current NGFW routing configuration.
To check the routing table

1. Open the NGFW GUI, and then click Network > Static Routes. Analyze the information
displayed.
2. Open the NGFW CLI, and then view the routing table:
NGFW # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default
S* 0.0.0.0/0 [10/0] via 10.200.1.254, port1

[10/0] via 10.200.2.254, port2, [20/0]
C 10.1.0.0/24 is directly connected, port3
S 10.1.4.0/24 [10/0] via 10.1.0.100, port3
S 10.1.10.0/24 [10/0] via 10.1.0.1, port3
Analyze the routing table output. There are two default routes, one using port1, and another
one using port2. The route using port1 is the primary one because it has a lower priority that
the route using port2.
Testing the Primary Default Route

You will generate Internet traffic from Client-10 and confirm that the NGFW is using the port1
default route.

© FORTINET
To test the primary default route
1. Open the Client-10 MATE Terminal, and then start a continuous ping to Spoke-1:
$ ping 10.200.3.1
Leave the ping running.
2. Connect to NGFW CLI, and then start a sniffer:
# diagnose sniffer packet any "icmp and host 10.200.3.1" 4

You should see the echo requests coming in to port3 and going out on port1. You should also the
echo replies coming in to port1:
Testing the Failover

You will simulate a failure in the primary route by disabling the interface port1. Then, you will confirm
that FortiGate is routing the traffic through the secondary default route (port2).
To test the failover

1. Check that both the ping from Client-10 and the sniffer in the NGFW CLI are still running.
2. Open the NGFW GUI, and then click Network > Interfaces.
3. Edit port1.
4. Change the Interface State to Disabled.
5. Click OK.
6. Take a look at sniffer output. The default route using port2 took over. Traffic was automatically
moved to port1 from port2:
This confirms that the default route failover works.

© FORTINET
Testing the Failback
You will restart port1, and then check how the NGFW is routing the continuous ping traffic from
Client-10.
To test the failback

1. In the NGFW GUI, click Network > Interfaces.
2. Edit port1.
3. Change the Interface State to Enabled.
4. Click OK.
The GUI page should display a green status icon to show that port1 is enabled:
5. Take a look at the sniffer output; you will notice that the ICMP traffic is still using port2 even after
you restarted port1.
Why is FortiGate still routing the ping traffic through port2 (and not through port1)?
What can be done to prevent this problem?

© FORTINET
2 Troubleshooting: Routing
You will use routing debug commands and the built-in sniffer to troubleshoot routing problems.
Prerequisite
Before you begin this lab, you must restore an initial configuration file to the NGFW. The configuration
file is located on the desktop of the Client-10 VM. So, you will connect to the NGFW from Client-10 to
restore it.

1. On the Client-10 VM, open a browser, and then log in as admin to the NGFW GUI at
10.1.0.254.

4. Click admin
5. Desktop > Resources > Enterprise-FW > Routing and select
NGFW_Routing_troubleshooting.conf.
6. Click OK.
7. Click OK.
Network topology

© FORTINET
Problem description
The NGFW configuration includes two default routes, one using port1, and the other one using
port2. Both routes should be active in the routing table. However, only one of them is active.
Objective
This is what is necessary to complete the lab:
1. Both default routes (port1 and port2) must be active in the routing table. This means the output
of the following command must display both default routes:
# get router info routing-table all

2. The route using port1 must be the primary route.
3. The traffic from Client-10 to the IP address 10.200.3.1 must use the port1 route.

 Try to accomplish objectives 1 and 2 first. Use these commands to check the routing table:
# get router info routing-table database

 Remember the requirements for a route to be active in the routing table:

© FORTINET
 The outgoing interface is up
 There is no other matching route with a lower distance
 If configured, the link health monitor is successful
 The next-hop IP address belongs to one of the outgoing interface subnets
 After both default routes are active and the port1 route is the primary route, generate a
continuous ping from Client-10 to 10.200.3.1 and sniffer the traffic:
# diagnose sniffer packet any "host 10.200.3.1 and icmp" 4

Why is the NGFW routing this ICMP traffic through port2 instead of port1?
 Stop the ping and clear the existing ICMP session:
# diagnose sys session filter proto 1
# diagnose sys session clear

Then, enable the debug flow and restart the ping to 10.200.3.1:
# diagnose debug flow filter clear
# diagnose debug flow filter proto 1
# diagnose debug flow show console en
# diagnose debug flow trace start 10

DO NOT REPRINT  Lab 6—FortiGuard
© FORTINET
Lab 6—FortiGuard
In this lab, you will troubleshoot two FortiGuard problems in the DCFW and the ISFW.
Objectives
 Analyze the FortiGuard diagnostic information
 Use the FortiGuard real-time debug to troubleshoot FortiGuard connectivity problems
 Troubleshoot web filtering rating problems
Time to Complete

In this lab, you will work on the ISFW and the DCFW:
.

© FORTINET
Prerequisite
configuration files are located on the desktop of the Client-10 VM. So, you will connect to the FortiGate

1. On the Client-10 VM, open a browser, and then log in as admin to the NGFW GUI at
10.1.0.254.

© FORTINET

4. Click Desktop > Resources > Enterprise-FW > FortiGuard, and then select
NGFW_FortiGuard_initial.conf.
5. Click OK.
6. Click OK.

1. On the Client-10 VM, open a browser, and then log in as admin to the DCFW GUI at
10.1.10.100.
3. Select Local PC, and then click Upload:
4. Click Desktop > Resources > Enterprise-FW > FortiGuard and select
DCFW_FortiGuard_initial.conf.

© FORTINET
5. Click OK.
6. Click OK.

1. On the Client-10 VM, open a browser, and then log in as admin to the ISFW GUI at
10.1.10.254.

4. Click Desktop > Resources > Enterprise-FW > FortiGuard, and then select
ISFW_FortiGuard_initial.conf.
5. Click OK.
6. Click OK.

© FORTINET
1 Troubleshooting: Local FDS Issue
Network topology
Problem description
DCFW is not able to get license information and FortiGuard updates from the local FortiGuard server
(FortiManager).
Note: This lab environment uses FortiManager for license validation and updates.
FortiManager is configured as a local FDS server to validate FortiGate licenses and install
updates.
Objective
Fix the FortiGuard connectivity problem.
Why isn't the DCFW able to validate its license and download FortiGuard update?
Can you change the DCFW configuration to solve the issue?

© FORTINET
 The problem is not on the FortiManager side, but on the DCFW side.
 Enable the FortiGuard real-time debug on the DCFW:
# diagnose debug application update -1

Then, run the following command to force an update:
# execute update-now

© FORTINET
2 Troubleshooting: Rating Lookups
Network topology
Problem description
The ISFW is doing web filtering inspection. However, users are getting rating errors when trying to
browse any public web side. The administrator has done some initial troubleshooting and determined
that the ISFW is not sending the web filtering rating request to FortiGuard.
Objective
Fix the web filtering problem.
Why isn't the ISFW able to rate websites?
Can you change the ISFW configuration to solve the issue?

 The problem is not on the FortiManager side, but on the ISFW side.
 There is nothing wrong with the web-filtering configuration. The issue is strictly with the ISFW,
having a problem communicating with the local FDS (FortiManager).
 Run the web filtering real-time debug while browsing any website from Client-10:

© FORTINET
# diagnose debug application urlfilter -1

DO NOT REPRINT  Lab 7—Central Management
© FORTINET
Lab 7—Central Management
FortiManager is one of the key pieces of an enterprise firewall solution. Without it, managing multiple
FortiGate devices would be cumbersome. Using FortiManager, you can centralize the management of
all the FortiGate devices and create common security policies that can be shared easily by multiple
devices. In enterprise networks, FortiManager ADOMs are used to organize your FortiGate devices
into groups whose members all share similar security roles and policies.
Objectives
 Configure the FortiGate devices and FortiManager to centralize the management of the enterprise
network
 Use ADOMs to group the FortiGate devices based on their security roles in the enterprise network
Time to Complete

In this lab, you will configure the NGFW, DCFW, and ISFW to use FortiManager for central
management. As the security roles of the three firewalls are different, they will be assigned to different
FortiManager ADOMs. Three ADOMs have been already created in FortiManager. The Core ADOM
will contain the NGFW, Spoke-1 and Spoke-2. The ADOM Access will contain the ISFW. And the
Data Center (DC) ADOM will contain the DCFW. Spoke-1 and Spoke-2 are already registered to
FortiManager and added to the Core ADOM. You will add the other FortiGate devices.

© FORTINET
Prerequisite
configuration files are located on the desktop in the Client-10 VM. So, you will connect to the FortiGate

1. On the Client-10 VM, open a browser, and then and log in as admin to the NGFW GUI at
10.1.0.254.

© FORTINET

4. Click Desktop > Resources > Enterprise-FW > Central_Management, and then select
NGFW_Central_Management_initial.conf.
5. Click OK.
6. Click OK.

1. On the Client-10 VM, open a browser, and then log in as admin to the DCFW GUI at
10.1.10.100.
3. Select Local PC, and then click Upload:
DCFW_Central_Management_initial.conf.

© FORTINET
5. Click OK.
6. Click OK.

1. On the Client-10 VM, open a browser, and then log in as admin to the ISFW GUI at
10.1.10.254.

ISFW_Central_Management_initial.conf.
5. Click OK.
6. Click OK.

© FORTINET
1 FortiManager Registration
You will register three FortiGate devices (NGFW, DCFW, and ISFW) on FortiManager.
Registering the NGFW on FortiManager

You will register the NGFW on FortiManager. After that, you will import the policies.
Note: To simplify the set-up time for these labs, the FortiGate devices have been pre-
configured to validate their licenses on the local FortiManager. For this reason, the
FortiGate devices are listed initially as unregistered in the FortiManager CLI.
FortiManager will add a FortiGate to the unregistered list each time an unknown FortiGate
contacts FortiManager for any reason. In this case, the FortiGate devices contact
FortiManager when they boot to validate the licenses. As a consequence, the auto-
discovery method for registering FortiGate devices on FortiManager won’t work until the
administrator manually deletes the devices from the unregistered list. One alternative,
which is what you will do in this lab, is to use the manual registration method.
To add FortiManager to the NGFW configuration

1. Open the NGFW GUI.
2. Click System > Settings.
3. In the Central Management section, in the IP/Domain Name field, enter the FortiManager IP
address 10.1.0.241:
4. Click Apply.
5. Click Send Request. You will see the following message:
6. Click OK.

© FORTINET
To register NGFW on FortiManager
1. Open the FortiManager GUI and log in as admin.
Note: If your lab is running on Ravello, you should connect to the FortiManager GUI
directly by clicking the HTTPS link on the lab dashboard.
If your lab is running on Hatsize, connect first to the Client-10 VM, open a browser, and
then connect HTTPS to the NGFW IP address 10.1.0.241.
2. Select the root ADOM:
3. Click Device Manager.

4. Click Unregistered Devices. You will see the NGFW listed as unregistered:
5. Select FortiGate, and then click Add.

6. In the drop-down list, select the ADOM Core, and then change the device name to NGFW:
7. Click OK. Wait until FortiManager finishes registering the unit.

8. After the progress bar reaches 100%, click Close:

© FORTINET
To import the NGFW policies

1. In the FortiManager GUI, click the Core ADOM.
3. Click Managed FortiGates.
4. Right-click NGFW.
5. In the drop-down list, select Import Policy:
6. Configure the following interface mapping:

© FORTINET
Device Interface ADOM Interface
port1 external
port2 backup
port3 internal
7. Click Next.
8. Keep the default values for the Policy Package Name and Folder, and then select Import All (1)
and Import all objects:
9. Click Next.
10. The import wizard will report conflicts. Keep the default values (Use Value From: FortiGate), and
then click Next.
11. In the review window, click Next. Wait until FortiManager finishes importing the policies.
12. Click Finish.
Registering the DCFW into FortiManager

You will register the DCFW on FortiManager. Try to do it yourself using the procedure you followed to
register the NGFW:
1. Add the FortiManager to the FortiGate configuration.
2. Register FortiGate on FortiManager. In this case, use the device name DCFW and add it to the
DC ADOM.
3. Import the policies. Use the following interface mapping:

© FORTINET
port1 external
port3 internal
Registering the ISFW into FortiManager

You will register the ISFW on FortiManager. Try to do it yourself using the procedure you followed to
register the NGFW:
1. Add FortiManager to the FortiGate configuration.
2. Register FortiGate on FortiManager. In this case, use the device name ISFW and add it to the
Access ADOM.
3. Import the policies. Use the same interface mapping you used for the case of the DCFW:
port1 external
port3 internal
Checking the FortiGate Registrations

You will confirm that all your FortiGate devices are registered to the correct FortiManager ADOM. You
will also check that the policies were imported correctly.
To check FortiGate registrations

1. Open the FortiManager CLI.

© FORTINET
Note: If your lab is running on Ravello, you should connect to the FortiManager CLI
directly by using an SSH client (such as PuTTY) and the IP address and SSH port number
displayed in the lab dashboard.
If your lab is running on Hatsize, connect first to the Client-10 VM, open PuTTY, and then
connect SSH to the FortiManager IP address 10.0.1.241.
2. Run the following command:
# diagnose dvm device list

3. Read the output. Confirm that there are five devices being managed.
4. Confirm that each FortiGate is registered to the right ADOM:
5. Confirm that the policies for each FortiGate were imported to the right policy package:
Stop and Think

You might have noticed that Spoke-1 and Spoke-2 are sharing the same policy package
(Spokes). Why?
Discussion
Spoke-1 and Spoke-2 should always share the same security policies so they can share
the same policy package. This simplifies management, as you will see later. Each change
made in the Spoke policy package is applied to both spokes automatically.

DO NOT REPRINT  Lab 8—OSPF
© FORTINET
Lab 8—OSPF
In this lab, on FortiManager, you will configure the FortiGate devices to use OSPF as the dynamic
routing protocol for the enterprise network. You will also learn to use OSPF troubleshooting
commands.
Objectives
 Use OSPF to dynamically distribute the routes inside an enterprise network
 Diagnose the status of a OSPF network
 Troubleshoot OSPF problems
Time to Complete

On FortiManager, you will configure OSPF on the ISFW, DCFW and NGFW.

© FORTINET
Prerequisite
You must complete the previous lab before you start this one. If you haven’t, tell your instructor.

© FORTINET
1 Configuring OSPF
You will configure OSPF on the three FortiGate devices that are part of the hub network: ISFW, DCFW
and NGFW. The objective is to remove all the static routes from the three firewalls and use only OSPF
to route traffic internally. You will use a single OSPF area (0.0.0.0.)
Configuring OSPF in the NGFW

You will configure OSPF on the NGFW. Then, you will remove the two static routes and install the
changes.
To configure OSPF
1. Open the FortiManager GUI.
2. Open the Core ADOM.
4. Click NGFW, to display its dashboard:
5. Select Router > OSPF.

6. Enter the Router ID: 0.0.0.1.
7. Create a new area and configure the following settings:

© FORTINET
Field Value
Area 0.0.0.0
Type Regular
Authentication None
8. Click OK.
9. Create a new network and configure the following settings:
Field Value
IP/Netmask 10.1.0.0/24
Area 0.0.0.0
10. Click OK.

11. Click Apply.
To remove the static routes

1. In the FortiManager GUI, in the Device Manager of the Core ADOM, click NGFW.
2. Select Router > Static Route.
3. Select the two static routes used to route internal traffic (don’t select the default routes), and click
Delete:
4. Click OK to confirm.
To install the configuration changes

1. In the FortiManager GUI, in the Device Manager of the Core ADOM, click Managed FortiGates.
Observe the Config Status of the NGFW. It should appear as Modified:

© FORTINET
2. Select the NGFW and click Install Wizard:
3. Select Install Device Settings (only), and then click Next.

4. Check that the NGFW is selected, and then click Next.
5. Click Install to confirm.
6. Wait until the installation finishes. Click Finish. The Config Status of the NGFW should change to
Synchronized.
Configuring OSPF in the DCFW

Try to configure OSPF in the DCFW yourself. You will need to do on the DC ADOM. Use the same
steps you followed to configure OSPF in the NGFW:
1. Configure OSPF. Use the Route ID 0.0.0.2. Use the same area 0.0.0.0. In this case, you will
need to add two OSPF networks: 10.1.4.0/24 and 10.1.0.0/24.
2. Remove the static route(s) to the internal subnets. Again, don’t remove the default route.
3. Install the configuration settings.

© FORTINET
Configuring OSPF in the ISFW
Now try to configure OSPF on the ISFW yourself. You will need to do it on the Access ADOM. Use
the same steps you followed to configure OSPF in the NGFW:
1. Configure OSPF. Use the route ID 0.0.0.3. Use the same area 0.0.0.0. In this case, you will need
to add the following OSPF networks: 10.1.10.0/24 and 10.1.0.0/24.
2. Remove the static routes. Again, don’t remove the default route. Remove only the route(s) to the
internal subnets.
3. Install the configuration settings.
Checking OSPF status

You will run diagnostics commands on the three FortiGates to confirm that OSPF is running and that
the correct OSPF routes are active in the routing tables.
You will run the diagnostics commands in the NGFW, and then you will check the DCFW and the
ISFW.
To check OSPF status

1. Open the CLI of the NGFW.
# get router info ospf neighbor

You should see that the NGFW has two neighbors: DCFW and ISFW. The State column should
display Full:

© FORTINET
Stop and Think
The three FortiGate devices are connected to the same broadcast network (10.1.0.0/24).
Can you determine from this output what the designated router is?
Discussion
The State of the designated router is displayed as Full/DR. If none of the two routers
display that state, it means that the designated router is the local FortiGate which, in this
case, is the NGFW.

You should observe that the NGFW has learned the routes to the subnets 10.1.4.0/24 and
10.1.10.0/24 through OSPF:
Run the same two diagnostics commands in the DCFW and the ISFW. Analyze their outputs.
Checking connectivity
You will confirm that the FortiGate devices are routing traffic properly by running a ping from Client-10
to the Linux Server.
To check connectivity
1. Open the Client-10 command prompt.

© FORTINET
using HTTP, by clicking the link in the lab dashboard. You can also connect directly using
RDP. Click the RDP link in the lab dashboard to download an RDP file. Run this file to run
Windows RDP automatically and connect to Client-10. Alternatively, you can use the
Client-10 console connection.
2. Run a ping to the Linux Server (10.1.4.10). The ping should succeed, confirming that the
FortiGate devices are properly routing the traffic between the 10.1.10.0/24 and 10.1.4.0/24
subnets.

© FORTINET
2 Troubleshooting: OSPF
Network topology
Problem description
The Linux server is running OSPF. It is configured to form an OSPF adjacency with the DCFW.
However, it is not coming up. The DCFW doesn’t show the Linux server as an OSPF neighbor.
Objective
You don’t have access to the Linux server. Use the OSPF debug commands available in the
DCFW to find out why the OSPF adjacency between the Linux Server and the DCFW is down.

 Check the OSPF neighbor status in the DCFW:
# get router info ospf status
# get router info ospf neighbor

Initially, you’ll see that the DCFW has only two neighbors: 10.1.0.1 and 10.1.0.254. Why is the
Linux server (10.1.4.10) not showing up as a neighbor?

© FORTINET
 Run the real-time debug:
# diagnose ip router ospf all enable
# diagnose ip router ospf level info

Do you see any error in the real-time debug that could explain why the adjacency establishment is
failing?
 After troubleshooting the problem, use the following commands to disable the real-time debug:
# diagnose ip router ospf all disable

DO NOT REPRINT  Lab 9—Web Filtering and Antivirus
© FORTINET
Lab 9—Web Filtering and Antivirus
In this lab, you will configure web filtering and antivirus on FortiManager. Then, you will test the
configuration by generating traffic from a client behind the ISFW. Additionally, you will troubleshoot a
web filtering problem and an antivirus problem.
Objectives
 Harden the security of the clients by using web filtering and antivirus
 Use web filtering to block traffic to unwanted sites
 Troubleshoot a web filtering problem
Time to Complete

You will configure web filtering and AV in the ISFW. Then, you will generate test traffic from Client-10:

© FORTINET
Prerequisite
You must complete the previous lab before you start this one. If you haven't, tell your instructor.

© FORTINET
1 Configuring Web Filtering and AV
You will start hardening the network. In this lab, you will install web filtering and antivirus in the ISFW
to protect the clients connected behind it.
Configuring the Web Filter Profile

First, configure a web filtering profile with the FortiGuard categories that you want to block.
To configure the web filter profile

2. Open the Access ADOM.
3. Click Policy & Objects.
4. Click Object Configurations > Security Profiles > Web Filter.
5. Click Create New.
6. Enter the name Block.
7. Click OK.
8. Select the FortiGuard Categories check box.
9. Select the check boxes for the following categories:
 Adult/Mature Content
 Bandwidth Consuming
 Security Risk
10. Right click any of the selected categories, and then, in the drop-down list, select Block.

© FORTINET
11. Click OK.
Configuring the AV Profile

You will configure an AV profile to block malware.
To configure the AV profile

1. In the FortiManager GUI, in the Access ADOM, click Policy & Objects > Object Configurations
> Security Profiles > AntiVirus.
3. Enter the name Block, and then, in the Inspected Protocols section, turn on the HTTP, SMTP,
POP3, IMAP, and FTP switches:
4. Click OK.
Applying the Security Profiles

You will modify the existing policy in the FortiManager policy package to apply the created web
filter and AV profiles.
To apply the security profiles

1. In the FortiManager GUI, in the Access ADOM, click Policy & Objects > Policy Packages.
2. Select ISFW > IPv4 Policy.
3. In the left pane, select the first policy at the top of the list, and then, in the right pane, click Edit:

© FORTINET
4. Click the Security Profiles check box.

5. Configure the following settings:
Field Value
AntiVirus Block
Web Filter Profile Block
SSL/SSH Inspection certificate-inspection
Proxy Options default
The configuration should look like the following example:
6. Click OK.
Installing the Policy

© FORTINET
You will install the policy and object changes on the ISFW.
To install the policy

2. Select Install > Install Wizard:
3. Select Install Policy Package & Device Settings.

4. Click Next.
5. Confirm that the ISFW device is selected, and then click Next.
6. Click Install.
7. Wait until the installation finishes, and then click Finish.
Testing the Web Filter

You will confirm that the ISFW is not allowing access to websites that belong to blocked FortiGuard
categories.
To test the web filter

1. Open the Client-10 VM desktop.
2. Open a Mozilla Firefox.
3. Try to connect to the following websites:
www.metacafe.com
www.tunein.com
You will observe that these websites are blocked because they belong to blocked categories.

© FORTINET
2 Troubleshooting: Web Filtering
Network topology
Problem description
In the previous exercises, you configured the ISFW to apply web filtering on the Internet traffic coming
from Client-10. The applied web filter blocks the following FortiGuard categories:
 Bandwidth Consuming
 Adult/Mature Content
 Security Risk
Many restricted sites seem to be properly blocked, such as:
www.metacafe.com
www.tunein.com
However, the following site is not blocked. According to the users, it should be blocked as it
belongs to the Security Risk category:
www.eicar.org

© FORTINET
Objective
Use the web filtering debug commands available in the ISFW to find out why the website is not being
blocked.

 Clear the browser cache before each test. Also, clear the FortiGate web filtering cache using the
following command:
# diagnose test application urlfilter 2

 Enable the following real-time debug while browsing the website:
# diagnose debug application urlfilter -1

Can you spot how FortiGuard is categorizing the website?
The output can be verbose, so save it from PuTTY to a local file.
 After finishing the troubleshooting, disable the real-time debug using the following commands:
# diagnose debug application urlfilter 0

© FORTINET
3 Troubleshooting: Antivirus
Network topology
Problem description
Even though you enabled antivirus in the ISFW, a user connecting from Client-10 complains that it is
still possible to download the virus sample eicar.com located at the ftp server 10.200.3.254. Follow
these steps to test antivirus:
2. On Client-10, open FileZilla.
3. Open the site manager:

© FORTINET
4. Select the preconfigured site FTPSite and click Connect:
5. Select the Desktop as the local site folder and pub as the remote site folder.
6. Right-click the eicar.com file and select Download:

© FORTINET
Why isn't the ISFW detecting the EICAR virus?
Objective
Use the debug commands available in the ISFW to find out why FortiGate isn’t blocking the FTP file
transfer.

 Sniffer the FTP traffic:
# diagnose sniffer packet any "host 10.200.3.254" 4

 Analyze the output of the debug flow:
# diagnose debug flow trace start

Can you confirm from the above output that FortiGate is inspecting the traffic? If it isn’t, can you
explain why?

DO NOT REPRINT  Lab 10—IPS
© FORTINET
Lab 10—IPS
In this lab, you will configure FortiGate to protect a web server using IPS inspection. Then, you will test
the configuration by generating suspicious traffic from outside and sending it to the server. In the
second exercise, you will use the information gathered by the built-in sniffer to write a custom IPS
signature.
Objectives
 Use IPS to protect a web server
 Monitor IPS operation
 Create and test custom IPS signatures
Time to Complete

In the first exercise, you will configure IPS inspection in the DCFW. You will also configure a virtual IP
(VIP) in the NGFW. Then, you will generate suspicious traffic from the Linux router to the Linux server.
In the second exercise, you will work on Client-10 and the ISFW.

© FORTINET
Prerequisite
You must complete the previous lab before you start this one. If you haven’t, tell your instructor.

© FORTINET
1 Configuring IPS
You will protect the Linux server by applying an IPS profile to the incoming traffic. To allow access to
the server from outside, you will also configure a virtual IP (VIP) in the NGFW.
Configuring the IPS Profile

You will use a per-configured IPS profile and change its configuration to enable logging.
To configure the IPS profile

2. Open the DC ADOM.
4. Click Object Configurations > Security Profiles > Intrusion Protection.
5. Edit the profile protect_http_server.
6. Right-click the existing IPS filter and select Packet Logging > Enable:
7. Click OK.
Applying the IPS Profile

You will apply the IPS profile to the incoming firewall policy.
To apply the IPS profile

1. In the FortiManager GUI, in the DC ADOM, click Policy & Objects > Policy Packages.
2. Select DCFW > IPv4 Policy.

© FORTINET
3. In the left pane, select the second policy from the top, and then click Edit:
4. Enable Security Profiles.

5. In the IPS Profile drop-down list, select the protect_http_server profile.
6. In the Proxy Options drop-down list, select the default profile.
7. Click OK.

You will install the policy and object changes to the DCFW.

1. In the FortiManager GUI, and still in the DC ADOM, click Policy & Objects > Policy
Packages.
2. Select Install , Install Wizard:

© FORTINET

4. Click Next.
5. Confirm that the DCFW device is selected, and then click Next.
6. Click Install.
Configuring the VIP

First, you will create the VIP object. The VIP will map the external-facing IP address 10.200.1.10 to the
internal-facing IP address 10.1.4.10.
Then, you will create an incoming firewall policy using the VIP object as the destination.
Finally, you will install the changes on the NGFW.
To configure the VIP

4. Click Object Configurations > Firewall Objects > Virtual IPs.
5. Select Create New > Virtual IP:

© FORTINET
Field Value
Name Linux_Server
Interface external
Type Static NAT
External IP Address/Range 10.200.1.10 - 10.200.1.10
Mapped IP Address/Range 10.1.4.10 - 10.1.4.10
7. Click OK.
Configuring the Firewall Policy

You will create an incoming firewall policy using the VIP object as destination.
To configure the firewall policy

1. In the FortiManager GUI, in the Core ADOM, click Policy & Objects > Policy Packages.
2. Select NGFW > IPv4 Policy.
Field Value
Incoming Interface external
Outgoing Interface internal
Source Address all
Destination Address Select Virtual IP > Linux_Server
Service HTTP

© FORTINET
Schedule always
Action Accept
Log Traffic Log All Sessions
5. Click OK.

You will install the policy and object changes on the NGFW.


4. Click Next.
5. Confirm that the NGFW device is selected, and then click Next.
6. Click Install.
Testing the IPS

You will run a vulnerability scanner from the Linux router to the Linux server. This will test the IPS
configuration and block some of the traffic as an attack.
To test the IPS

1. Open the command prompt of the Linux router and log in using the username student with
the password password.
Note: If your lab is running on Ravello, you should connect directly to the Linux router's
command prompt using an SSH client. As an alternative, you can connect SSH to the
Linux router from Client-10.

© FORTINET
If your lab is running on Hatsize, connect SSH to the Linux router (10.200.1.254) from
Client-10 using PuTTY.
$ nikto.pl -h 10.200.1.10
3. Let the scan run for approximately five minutes.
4. Close the SSH connection to stop the scan.
Checking the Attack Logs

You will review the attack logs.
To check the attack logs

1. Open the DCFW GUI.
2. Click Login Read-Only.
3. Click Log & Repot > Intrusion Protection.
Note: The Intrusion Protection logs section will not display if there are no IPS logs.
FortiGate will show it after creating logs. After the attacks, if this menu item does not
display, log out from the FortiGate GUI and log in again to refresh it.
4. Analyze all the attack logs generated by the IPS and related to the scan running on the Linux
router:
Checking the Attack Statistics

You will review FortiView to check the attack statistics.
To check the attack statistics

1. In the DCFW GUI, click FortiView > Threats.
2. Analyze the information displayed:

© FORTINET

© FORTINET
2 IPS Custom Signatures
In this exercise, you will create a custom IPS signature, based on the information taken from a packet
capture, to block the downloading of files using FTP.
Capturing and Analyzing the Traffic

You will sniffer the FTP traffic while downloading a file from an FTP server. Then, you will use a Perl
script to convert the packet capture to a PCAP file that can be analyzed using WireShark. The
objective of the analysis is to determine what information in the packet payload you can use to block
FTP downloads.
To start the packet capture

2. Open PuTTY.
3. Click Session, and then enter the ISFW IP address (10.1.10.254) in Host Name (or IP address):
4. Click Session > Logging.

© FORTINET
5. Select All session output.

6. Click Browse, and then select the folder FGT2ETH on the Client-10 VM desktop. Use the file
name ftp.log:
7. Click OK.
8. Click Open to connect.
9. Start the sniffer with this command:
# diagnose sniffer packet port3 "port 21" 3

Keep the SSH connection open and the sniffer running.
To generate FTP traffic

1. On the Client-10 VM, open FileZilla.
2. Open the site manager:

© FORTINET
3. Connect to the Linux site:
4. Select Desktop as the local site folder and pub as the remote site folder.
5. Right-click the test.text file, and then select Download.
You should see the packets captured in the PuTTY window.
To convert the capture to PCAP

1. On the Client-10 VM, close PuTTY to terminate the SSH connection to the ISFW.
2. Open a MATE Terminal window.

© FORTINET
3. Run the following commands:
$ cd Desktop/FGT2ETH
$ ./fgt2eth.pl -in ftp.log

The Perl script fgt2eth.pl converted the output captured to a PCAP file with the name
ftp.log.pcap.
To analyze the PCAP file

1. On the Client-10 VM desktop, open the folder labeled FGT2ETH.
2. Double-click the file labeled ftp.log.pcap to open it.
This starts Wireshark and opens the file for analysis.
3. Observe the information in the packets captured. You will notice that FileZilla used the FTP RETR
command to request the download:
You will use this information to create the custom signature.
Creating and Installing the Custom Signature

You will use the information you gathered in the previous steps to create a custom IPS that will
block the requests for downloading files from any FTP server. On FortiManager, you will add the
custom signature to an IPS profile and then push the configuration change to the ISFW.
To create the custom signature

1. Open the FortiManager GUI, and then click the Access ADOM.

© FORTINET
2. Click Policy and Objects > Object Configuration.
3. On the left side of the screen, click Security Profiles > IPS Custom Signature.
Field Value
Name Block.FTP.RETR
Signature F-SBID (--attack_id 1001;--name "Block.FTP.RETR"; --protocol tcp;--service ftp; --flow

from_client; --pattern "RETR"; --no_case;)
The signature will block any FTP packet coming from the client whose payload contains the
pattern RETR.
6. Click OK.
To apply the custom signature to an IPS profile

1. In the FortiManager GUI, in the Access ADOM, click Policy & Objects > Object Configuration >
Security Profiles > Intrusion Protection.
2. Select the predefined profile labeled protect_client, and then click Edit.
3. Click Add Signatures:
4. In the pop-up window, select the Block.FTP.RETR signature, and then click Use Selected
Signatures:

© FORTINET
5. Right-click the signature Block.FTP.RETR, and then change the Action to Reset:
6. Click OK to save the changes on the sensor.
To apply the IPS profile to a firewall policy

1. In the FortiManager GUI, in the Access VDOM, click Policy & Objects > Policy Package.
2. On the left side of the screen, click ISFW > IPv4 Policy.
3. Edit the first policy from the internal to the external interfaces.

© FORTINET
4. Change the IPS Profile to protect_client:
5. Click OK.


4. Click Next.
5. Confirm that the ISFW device is selected, and then click Next.
6. Click Install.
Testing the Custom Signature

You will test the custom signature by generating FTP traffic from Client-10.
To test the custom signature

1. On the Client-10 VM, open FileZilla, and then connect to the Linux site:

© FORTINET
2. Select Desktop as the local site folder and pub as the remote site folder.
3. Right-click the test.text file, and then select Download.
You will see the following error message:
Note: If you sniffer the FTP traffic now, you will capture a reset (RST) packet sent by the
FortiGate to drop the TCP connection after the packet with the RETR command is
received.
4. In the ISFW GUI, click Log & Report > Intrusion Prevention.

© FORTINET
You should see the log messages showing the name of the IPS sensor that blocked the packets:
Note: The Intrusion Protection logs section will not display if there are no IPS logs.
FortiGate will show it after creating logs. After the attacks, if this menu item does not
display, log out from the FortiGate GUI and log in again to refresh it.

DO NOT REPRINT  Lab 11—BGP
© FORTINET
Lab 11—BGP
In this lab, you will configure BGP routing between the NGFW and the Linux router. You will also use
the BGP real-time debug to troubleshoot BGP problems.
Objectives
 Configure BGP using FortiManager
 Diagnose the status of a BGP network
 Troubleshoot BGP problems
Time to Complete

In this lab, you will configure the NGFW using FortiManager:

© FORTINET
Prerequisite

© FORTINET
1 Configuring BGP
The NGFW has two connections to the Internet, one using port1, the other one using port2. The
Linux router is the "ISP router" and is running BGP advertising default routes. You will configure BGP
in the NGFW to receive the two default routes from the ISP.
Configuring BGP on the NGFW

Since the NGFW is currently managed by FortiManager, you must perform the BGP configuration on
FortiManager, and then install it on the NGFW. You will also delete the static default routes currently
installed in the NGFW. By default, the BGP settings are hidden in the FortiManager GUI. The first step
is to display the BGP settings.
To display the BGP settings in FortiManager

3. Click Device Manager > NGFW:
4. Click on Display Option.

5. Select Customize and, in the Router section, select the BGP check box.

© FORTINET
6. Click OK.
To configure BGP
1. In the FortiManager GUI, in the Core ADOM, select the NGFW and click Router > BGP.
2. Configure the following Local AS and Router ID:
Field Value
Local AS 65100
Router ID 172.16.1.254
3. Create the following neighbor:

© FORTINET
Field Value
IP 10.200.1.254
Remote AS 200
4. Click OK.
5. Create a second neighbor:
Field Value
IP 10.200.2.254
Remote AS 200
6. Click OK.
Your BGP configuration should look like the following example:
7. Click Apply to save the changes.
To remove the static routes

1. In the FortiManager GUI, in the Device Manager of the Core ADOM, click NGFW.
2. Select Router > Static Route.
3. Select the two default static routes, and then click Delete:

© FORTINET
4. Click OK to confirm.
To install the BGP configuration

3. Select Install Device Settings (only).

4. Click Next.
6. Click Install.

© FORTINET
2 Troubleshooting: BGP Neighbor
Network topology
Problem description
You have installed the BGP configuration on the NGFW on FortiManager. However, the BGP neighbor
(Linux router) isn’t coming up. The output of the following command doesn’t show any active BGP
neighbor:
# get router info bgp summary
Objective
You don’t have access to the Linux router configuration. Use the BGP debug commands available
in the NGFW to find out why the BGP neighbor is down. Change the BGP configuration in the
NGFW to fix the problem.
Note: Don’t make any changes to Linux router. All changes to fix the problem must be
done on the NGFW using FortiManager.

© FORTINET
 Check the BGP status in the NGFW using the following commands:
# get router info bgp summary
# get router info bgp neighbor

 Run the BGP real-time debug using the following commands:
# diagnose ip router bgp all enable
# diagnose ip router bgp level info

Do you see any error in the real-time debug that could explain why the BGP neighbor is not
running?
 After making any BGP configuration changes in the NGFW, use the following command to restart
the BGP connections:
# execute router clear bgp all

 After troubleshooting the problem, use the following commands to disable the real-time debug:
# diagnose ip router bgp all disable

© FORTINET
3 Troubleshooting: BGP Routing
Network topology
Problem description
After the BGP neighbor is running, the administrator reports a problem with the current configuration.
The default BGP route using port1 is the primary link for Internet traffic. However, all traffic destined
for the IP address 8.8.8.8 is using port2 instead.
Objective
Use the routing and BGP diagnostic commands in the NGFW to find out why this is happening.
You don’t have to fix this issue, just explain why the issue is happening. You will fix this problem in
the next lab exercise.

 Sniffer a ping from Client-10 to 8.8.8.8.
 Use the following commands to check the routing table:
# get router info routing-table database

© FORTINET
4 Configuring Prefix Lists
As you saw in the previous exercise, the ISP (Linux router) is wrongly advertising the prefix 8.8.8.8/32
through one of the links. This exercise explains what you can do on the NGFW while the Linux router's
administrator fixes the problem. You will create a prefix list denying the subnet 8.8.8.8/32 and apply it
to the prefixes learned from the ISP.
Creating a Prefix List

Prefix lists are available only using the CLI. You will run a script from FortiManager to configure one
prefix list on the NGFW.
To create a prefix list

1. Open the FortiManager GUI, and then click the Core ADOM.
2. Click the Device Manager > Scripts:
3. Right-click the BGP-Prefix-List script, and then select Edit. This will display the content of the
script. Analyze the CLI commands that are going to be run:
4. Click Cancel to close the window.

5. Right-click the BGP-Prefix-List script one more time, and then select Run.
6. In the pop-up window, under Device, select the NGFW check box, and then click OK.

© FORTINET
Wait for the script to run. The script has been configured to apply the CLI commands directly on
FortiGate. If everything goes well, the window closes automatically without errors.
Clearing the BGP Connections

You will clear the BGP connections, so the new prefix list can take effect.
To clear the BGP connections

1. Open the NGFW CLI.
# execute router clear bgp all
Verifying the Prefix List

You will verify that the prefix list is working as expected.
To verify the prefix list

1. In the CLI of the NGFW, type the following command:

You will see that the route to the 8.8.8.8/32 is no longer there. Although the Linux router is still
advertising this prefix, the NGFW is not adding it to its BGP database, neither to the routing
table.

DO NOT REPRINT  Lab 12—IPsec
© FORTINET
Lab 12—IPsec
In this lab, you will first troubleshoot an IPsec problem between Spoke-1 and Spoke-2. Then, you will
configure a hub-and-spoke VPN network using the FortiManager VPN manager.
Objectives
 Troubleshoot IPsec problems
 Configure multiple IPsec VPN tunnels using the VPN manager on FortiManager
 Run CLI commands to gather IPsec status and statistics
Time to Complete

You will work with the NGFW, Spoke-1, and Spoke-2:

© FORTINET
Prerequisite
Before you begin this lab, you must restore the initial configuration files to Spoke-1 and Spoke-2. The
configuration files are located on the desktop of the Client-10 VM. To restore the FortiGate devices,
you will connect to them using Client-10.
Additionally, you must have completed the previous lab. Notify your instructor if that is not the case.
To restore the configuration file for Spoke-1

1. On the Client-10 VM, open a browser and log in as admin to the Spoke-1 GUI at 10.200.3.1.
2. Click Login Read-Write:
3. Click Yes to confirm you understand that FortiGate will become out-of-sync on FortiManager.:

© FORTINET
6. Click Desktop > Resources > Enterprise-FW > IPsec and select Spoke-
1_IPsec_initial.conf.
7. Click OK.
8. Click OK.

1. On the Client-10 VM, open a browser and log in as admin to the Spoke-2 GUI at 10.200.5.1.
2. Click Login Read-Write:
3. Click Yes to confirm you understand that FortiGate will become out-of-sync on FortiManager:

© FORTINET
6. Browse to Desktop > Resources > Enterprise-FW > IPsec and select Spoke-
2_IPsec_initial.conf.
7. Click OK.
8. Click OK.

© FORTINET
1 Troubleshooting: IPsec
Network topology
Problem description
An administrator has configured an IPsec connection between Spoke-1's port2 (10.200.4.1) and
Spoke-2's port1 (10.200.5.1). However, the tunnel fails to come up.
Objective
Use IPsec diagnostic commands in the FortiGate devices to find out why the tunnel isn’t connecting.
Make all the changes in the VPN configurations to fix the problems and connect the tunnel.
After the tunnel is up, you will notice that traffic is not crossing the tunnel. Use the debug flow and
sniffer tools to find out why. You don’t need to fix this traffic flow problem, just explain why it is
happening.

 In the initial configuration files you have restored, Spoke-1 and Spoke-2 are now not centrally
managed on FortiManager. You can make configuration changes in these two FortiGate
devices directly.
 Use IKE real-time debug to view the negotiations for phases 1 and 2 using the following
command:

© FORTINET
# diagnose debug application ike -1
Do you see any error message that could point out where the problems are?
Could you fix the problems by changing the VPN configurations?
 After the tunnel connects, ping from Spoke-2 to Spoke-1, using the following commands:
# execute ping-options source 10.1.2.254
# execute ping 10.1.1.254

Also, test the ping from Spoke-1 to Spoke-2:

Why isn't it working? Use the sniffer and debug flow tools to explain why. Sniffer not only the ICMP
traffic, but also the ESP traffic between the FortiGate devices.

© FORTINET
2 VPN Manager
In this exercise, you will configure IPsec tunnels between the spokes and the NGFW using the VPN
manager on FortiManager. You will configure the NGFW as hub, and the other two FortiGate devices
as spokes. You will:
1. Configure a VPN community
2. Add each of the FortiGate devices to the community as managed devices
3. Install the VPN configuration
4. Add the firewall policies
5. Install the firewall policies configuration
At the end of the lab, you will use CLI commands to display IPsec tunnel information.
Prerequisite
After you complete the previous troubleshooting exercise, you must restore configuration files on both
Spoke-1 and Spoke-2. This will undo the changes made in the previous exercise, remove the IPsec
tunnel between spokes, and re-enable centralized management from FortiManager.

1. On the Client-10 VM, open a browser, and then log in as admin to the Spoke-1 GUI at
10.200.3.1.
4. Click Desktop > Resources > Enterprise-FW > IPsec and select Spoke-1_IPsec_FMG.conf.
5. Click OK.
6. Click OK.

1. On the Client-10 VM, open a browser, and then log in as admin to the Spoke-2 GUI at
10.200.5.1.
4. Browse to Desktop > Resources > Enterprise-FW > IPsec and select Spoke-
2_IPsec_FMG.conf.
5. Click OK.
6. Click OK.

© FORTINET
Creating a VPN Community
You will create a new VPN community under central VPN manager. VPN communities allow users to
create a specific type of VPN topology for FortiGate devices sharing a similar IPsec configuration.
Within the same VPN topology, users can assign different roles to the FortiGate devices, such as hub
or spoke.
Note: All FortiGate devices for use in this lab (NGFW, Spoke-1 and spoke-2) are already
added to the Core ADOM.
To create a VPN community

3. Click VPN Manager:
4. On the VPN Manager pane, click IPsec VPN.

5. Click All VPN community > Create New. The VPN Topology Setup Wizard launches.
6. In the name field, enter H2S, and then click Dial up as the VPN topology:

© FORTINET
7. Click Next.
8. In the Authentication section, click Pre-shared Key, select Specify, and then, in the Specify
field, enter the key fortinet.
9. Keep the default values for the other settings, and then Next.
10. On the next page, keep the default values for all the options, and then click Next.
11. Review the settings under the Summary page, and then click OK.
Adding the Managed Devices

After you create a VPN community, you must add gateways to the topology. Now, you will assign
roles (hub or spoke) to the FortiGate devices. First, you will add the NGFW to the VPN community
as a hub device. Later, you will add Spoke-1 and Spoke-2 as spoke devices.

© FORTINET
To add the NGFW as Hub
1. In the FortiManager GUI, on the Core VDOM, click VPN Manager > IPsec VPN > All VPN
Community.
2. Click H2S.
3. Click Create New > Managed Gateway. The VPN Gateway Setup Wizard opens.
4. For Protected Subnet select all, and then click Next.
5. In the Role section, select Hub, and then, in the Device drop-down list, select NGFW[root]:
6. Click Next.
7. For Default VPN Interface, select external. Leave the Hub-to-Hub interface field empty.

© FORTINET
Stop and Think
Look at the network topology. The Internet is facing the interface port1 on the NGFW, why
isn’t port1 available in the drop-down list?
Discussion
For the Default VPN Interface, usually the WAN port is used because it is connected to
the Internet. NGFW’s port1 is connected to the Internet, however, when you imported
FortiGate into FortiManager in Lab 1, you mapped port1 to external.
8. Click Next.
9. Leave Local Gateway IP Address field empty, and then click Next.
10. This is the advanced settings page. Make sure you clear the check boxes for the following
settings:
 Enable IKE Configuration Method ("mode config")
 DHCP Server
 Add Route (scroll down to see this setting)
11. Keep the default values for all other options, and then click OK.
To add Spoke-1 as spoke

1. In the FortiManager GUI, in the VPN manager of the Core ADOM, click VPN Community > H2S:
2. Click Create New > Managed Gateway. Just like in the previous exercise, the VPN Gateway
Setup Wizard pops up.
3. Under Protected Subnet, select all.

© FORTINET
4. Click Next.
5. In the Role section, select Spoke, and then, in the Device drop-down list, select Spoke-1[root].
6. Click Next.
7. On the next page, select external as the Default VPN Interface.
8. Click Next.
9. Leave the Local Gateway IP Address field empty, and then click Next.
10. On the next page, clear the check boxes for the following settings:
 Enable IKE Configuration Method ("mode config")
 Enable IP Assignment
 Add Route
11. Keep the default values for the other options, and then click OK.
To add Spoke-2 as spoke

You will now add Spoke-2 to the VPN community. Try to do it yourself using the procedure you
followed to add Spoke-1.
 For Protected Subnet use all.
 Make sure that Role is set to Spoke and select Spoke-2[root] as the device.
 For all other parameters, use the same settings as Spoke-1.
Installing the VPN Configuration

Before you create firewall policies, you must install the VPN settings in the FortiGate devices. This
creates the IPsec virtual interfaces that are required in the firewall policies.
To install the VPN configuration in the NGFW

1. In the FortiManager GUI, in the VPN Manager, click Install Wizard.
3. Select NGFW as Policy Package.
4. Click Next.
6. Click Install.

© FORTINET
To install the VPN configuration in both spokes

1. In the FortiManager GUI, in the VPN Manager, click Install Wizard.
3. Select Spokes as Policy Package.
4. Click Next.
5. Confirm that both Spoke-1 and Spoke-2 are selected, and then click Next.
6. Click Install.
Configuring the Firewall Policies

After you install the VPN configuration on all FortiGate devices, you can configure the firewall policies
to allow IPsec traffic to pass.
In the NGFW you will configure three firewall policies:
 Allow traffic from the spokes to the NGFW
 Allow traffic from the NGFW to the spokes
 Allow the traffic between spokes
In the spokes, you will configure two firewall policies:
 Allow traffic from the spokes to the NGFW
 Allow traffic from the NGFW to the spokes
Because Spoke-1 and Spoke-2 share the same policy package, you will create the firewall policies in
one policy package (Spokes). Then, you will push the changes to both FortiGate devices. This is the
advantage of having multiple FortiGates with the same security policies sharing the same policy
package.
To configure the firewall policies for traffic between the NGFW and the spokes
2. Select NGFW > IPv4 Policy.
Field Value
Name Internal to IPsec
Incoming Interface internal
Outgoing Interface vpnmgr_H2S_hub2spoke
Source Address all

© FORTINET
Destination Address all
Service ALL
Schedule always
Action Accept
5. Click OK.
6. To create another firewall policy to allow incoming traffic, click Create New.
Field Value
Name IPsec to Internal
Incoming Interface vpnmgr_H2S_hub2spoke
Source Address all
Service ALL
Schedule always
Action Accept
8. Click OK.
To configure the firewall policy for traffic between spokes

1. In the FortiManager GUI, in the Core VDOM, click Policy & Objects > Policy Packages.
2. Select NGFW > IPv4 Policy:

© FORTINET
Field Value
Name Spoke to Spoke
Incoming Interface vpnmgr_H2S_hub2spoke
Outgoing Interface vpnmgr_H2S_hub2spoke
Source Address all
Service ALL
Schedule always
Action Accept
5. Click OK.
The final configuration in the NGFW should look like this:
To configure the firewall policies on the spokes

2. Select Spokes > IPv4 Policy:

© FORTINET

Field Value
Name Internal to IPsec
Incoming Interface internal
Outgoing Interface vpnmgr_H2S_spoke2hub
Source Address all
Service ALL
Schedule always
Action Accept
5. Click OK.
6. To create another firewall policy to allow incoming traffic, click Create New.
Field Value
Name IPsec to Internal
Incoming Interface vpnmgr_H2S_spoke2hub
Source Address all

© FORTINET
Service ALL
Schedule always
Action Accept
8. Click OK.
The final configuration for the Spokes policy package should look like the following example:
Stop and Think

Look at the VPN zone name for the spokes. Is it the same one as the one you used when
configuring the NGFW? If not, why is it different?
Discussion
FortiManager created three separate VPN zones (vpnmgr_H2S_spoke2hub,
vpnmgr_H2S_hub2spoke and vpnmgr_H2S_mesh). Depending on the role defined for
each managed gateway, different VPN zones were pushed to the proper FortiGate
devices. vpnmgr_H2S_hub2spoke will only be used when defining firewall policy on the
hub, and vpnmgr_H2S_spoke2hub on the spokes.
Installing the Policy Packages

Follow the same procedure you used earlier to install the policy packages on the managed gateways.
First, install the policy package NGFW, and then install the policy package Spokes.
Testing the VPN

You will not be able to send traffic through the tunnel yet, because the routing component is still
missing (you will add IBGP routing in the next lab). However, you will test if the VPNs can be
established by manually bringing up the tunnels from the spokes. You can do this in the FortiGate
GUI, FortiManager GUI, or FortiGate CLI. In this procedure, you will use the FortiGate CLI.

© FORTINET
To test the tunnel from spoke-1
1. Open the Spoke-1 CLI.
2. Run the command:
# diagnose vpn tunnel up H2S_0_0
This will bring the tunnel up. Let’s verify it.
3. Open the Spoke-1 GUI.
4. Click Monitor > IPsec Monitor. You should see the green arrow, indicating that the tunnel is up:
To test the tunnel from spoke-2

Now that the tunnel between Spoke-1 and the NGFW is up, bring up the tunnel between Spoke-2 and
the NGFW. Use the same command to do it. Check the VPN monitor in Spoke-2 to confirm that it is
up.
Running IPsec VPN Diagnostics

You will run CLI commands to view the IPsec tunnel status.
 To view the details of the IPsec tunnels, use the following command:
# get vpn ipsec tunnel details
 To display tunnel statistics, use the following command:
# diagnose vpn tunnel list name H2S_0
 To display the tunnel list, use the following command:
# get ipsec tunnel list
Run these commands on the FortiGate devices. Review the differences between the outputs.

DO NOT REPRINT  Lab 13—Auto Discovery VPN
© FORTINET
Lab 13—Auto Discovery VPN
You will modify the IPsec VPN configuration performed in the previous lab to enable auto discovery
VPN (ADVPN). You will create an on-demand tunnel between the two spokes. Routing will be handled
by IBGP with route reflector enabled on the hub device. Since ADVPN parameters are not available in
the FortiManager GUI, you will push the required settings using CLI and TCL scripts.
Objectives
 Configure ADVPN to dynamically create IPsec tunnels between spokes
 Use TCL scripts to run individualized configuration changes on multiple FortiGate devices
Time to Complete

In this lab, you will configure the NGFW, Spoke-1, and Spoke-2 for ADVPN. You will test the
connectivity between Spoke-1 and the NGFW, between Spoke-2 and the NGFW, and finally, between
both spokes.

© FORTINET
Prerequisite

© FORTINET
1 Configuring ADVPN and IBGP
In this exercise, you will configure ADPN in the NGFW and the two spokes.
Configuring ADVPN and IBGP in the NGFW

You will start configuring the NGFW. You will run a script to enable the auto-discovery sender option,
and configure IBGP and the IPsec interfaces.
To configure ADVPN and IBGP in the NGFW

You will use a script on the FortiManager to push the phase-1 ADVPN option. The script also contains
the IBGP configuration and IP address for the IPsec interface. The script is already created in
FortiManager.
1. Open the FortiManager GUI, and then click the Core ADOM.
2. Click the Device Manager > Scripts:
3. Right-click the ADVPN-Hub script, and then select Edit. This will display the content of the script.
Analyze the CLI commands that are going to be run:

5. Right-click the ADVPN-Hub script one more time, and then select Run.
6. In the pop-up window, under Device, select NGFW, and then click OK.

© FORTINET
Wait for the script to run. The script has been configured to apply the CLI commands directly on
FortiGate. If the script runs correctly, the window closes automatically, without errors.
Configuring ADVPN and IBGP in the Spokes

You will configure ADVPN and IBGP in the spokes. You will run a TCL script to enable the auto-
discovery receiver option, configure IBGP, and configure the IPsec interface. The TCL script will do
the following:
1. Get the FortiGate hostname
2. Extract the spoke number from the hostname
3. Configure ADVPN and IBGP using the spoke number to set the BGP router ID, network to
advertise, and IP address of the IPsec interface
To configure ADVPN and IBGP in the spokes

1. In the FortiManager GUI, in the Core ADOM, click the Device Manager > Scripts:
2. Right-click the ADVPN-Spokes script, and then select Edit. This displays the content of the
script. Analyze the CLI commands that are going to run.
4. Right-click the ADVPN-Spokes script one more time, and then select Run.
5. In the pop-up window, under Device, select Spoke-1 and Spoke-2, and then click OK:

© FORTINET
Wait for the script to run. The script has been configured to apply the CLI commands directly to
the FortiGate devices. If the script runs correctly, the window closes automatically, without errors.
Bringing Up the Static IPsec Tunnels

Before you generate traffic to trigger the on-demand tunnel, it is a good idea to verify that the BGP
route databases are in sync. But first, and in case the tunnels between spokes and hub closed after
the last configuration changes, you will reconnect the tunnels.
To bring up the IPsec tunnel on Spoke-1

# diagnose vpn tunnel up H2S_0_0

3. This brings up the tunnel. Verify it. Open the Spoke-1 GUI.
4. Click Monitor > IPsec Monitor and check the tunnel status.
To bring up the IPsec Tunnel on Spoke-2

Now that the tunnel between Spoke-1 and NGFW is up, you might need to bring up the tunnel
between Spoke-2 and NGFW. Use the same command to do it. Check the VPN monitor in Spoke-2 to
confirm that it is up.
Checking the BGP Routes

You will check that BGP is up between FortiGate devices.
To check the BGP routes

1. Open the NGFW GUI, and then click Monitor > Routing Monitor. The routing table should
look like this:

© FORTINET
2. Open the Spoke-1 GUI, and then click Monitor > Routing Monitor. The routing table should look
like this:
3. Check the routing in Spoke-2 as well.
Enabling the IKE Real Time Debug

You will see the output of the real-time debug while you trigger the on-demand tunnel.
To enable the IKE real-time debug

2. Run the following commands:
# diagnose debug application ike -1

3. Keep the connection open and the real-time debug running.
Bringing Up the On-Demand Tunnel

After you verify the BGP routes are up, you can bring up the on-demand tunnel between Spoke-1
and Spoke-2 by generating traffic.
To bring up the on-demand tunnel

2. Run the following commands to ping the ISFW located in the 10.1.0.0/24 subnet:

© FORTINET

3. Run the following ping to trigger the on-demand tunnel:

4. Return to the IKE real-time debug running in Spoke-2 and stop it:
# diagnose debug application ike 0

5. Analyze the output, especially the SHORTCUT messages exchanged:
Verifying the On-demand Tunnel

You should now have the on-demand tunnel up between the two spokes.
To verify the on-demand tunnel

1. Open the Spoke-1 GUI, and then click Monitor > IPsec Monitor. You will see two tunnels:

© FORTINET
2 Troubleshooting: OSPF and BGP
Network topology
Problem description
Currently, there is connectivity between the spokes (subnets 10.1.1.0/24 and 10.1.2.0/24), and
between the spokes and the subnet 10.1.0.0/24. However the spoke clients can’t reach other subnets
in the hub (such as 10.1.4.0/24). So, you haven’t achieved end-to-end connectivity yet.
Objective
Use the routing and sniffer commands to explain why there is no connectivity between the spokes and
the 10.1.4.0/24 subnet.
Note: Spoke FortiGates shouldn’t be able to ping Client-10 because there is no firewall
policy in the ISFW to allow this incoming traffic. This is how the network is designed.

 Open the Spoke-1 CLI, and then run a ping to the Linux Server using the following commands:

© FORTINET
# execute ping-options repeat-count 9999

 Open a second CLI connection to Spoke-1 and run a sniffer to check the outbound interface using
the following command:
# diagnose sniffer packet any "host 10.1.4.10" 4

What outbound port is the traffic taking? Why?
 View the full routing table in the NGFW using the following command:
# get router info routing-table details

 View the routing table in Spoke-1 and Spoke-2 using the following command:
# get router info routing-table details
# get router info bgp network

Do you see all the routes required to achieve end-to-end connectivity? What routes are missing?
 What can you do in the NGFW so that both spokes can receive routing information for the other
subnets behind the NGFW?
This is strictly a routing problem and it is not related to the VPN or firewall policies configuration.

DO NOT REPRINT  Appendix A: Using Ravello
© FORTINET
Appendix A: Using Ravello
This section explains how to access the remote lab environment when it is running on Ravello. If your
lab is running on Hatsize, follow the instructions at the beginning of this guide instead.
Logging In
 We strongly recommend not using a wireless connection to access the labs. The lab access
requires a reliable and fast Internet connection, which can’t always be guaranteed when
connecting wireless.
 Your trainer will provide your personal URL link for accessing the labs. This is all what you need
for the access. The link contains a token that is unique to each student. This token is used for
authenticating and identifying the student.
 You can access the labs only after the class starts. The access expires when the class ends.
If you open your lab URL link before the class starts, you will see this message:
If you open your lab URL link after the class has ended, you will see this message:
 Once connected to the remote lab, you will see the lab dashboard, which contains the name of
the lab and each of the VMs that are part of the network topology:

© FORTINET
 The lab dashboard contains one widget for each VM. Each widget displays from top to bottom:
 The name of the VM
 The links for connecting HTTP, HTTPS, and/or RDP
 The IP address and port number for connecting SSH
 The link for connecting to the console of the VM
 Action buttons to start, stop, restart and power off the VM

© FORTINET
 A green line on the top of the widget indicates that the VM is running. A blue line indicates that the
VM is either starting or stopping. If the VM is starting, wait a few minutes before trying to connect.
A yellow line indicates that the VM is not running, click the start action button to start it:
Note: Even after the VM status turns green (indicating that the VM is running) you might
need to wait a few minutes more to be able to connect, as the VM’s operative system
might have not finished booting.

© FORTINET
How to Access the Fortinet Devices
Each of the VMs is assigned its own public IP address, which you can use to access the VM’s user
interfaces directly from your computer. This section explains how to access the Fortinet devices, such
as the FortiManager and FortiGate devices.
 To access the VM graphical user interface (GUI), click the HTTP or HTTPS link in the respective
widget:
 To access the VM command line interface (CLI), take note of the IP address and SSH port
number provided, and use a SSH client, such as PuTTY:
 Alternatively, you can connect to the VM CLI using the CONSOLE link:

© FORTINET
How to Access the Linux VMs

Each of the VMs is assigned its own public IP address, which you can use to access the VM’s user
interfaces directly from your computer. This section explains how to access the Linux routers, servers
and clients.
 Some Linux VM desktops can be accessed using HTTP. A HTTP link is displayed in their widgets.
Click this HTTP link to connect:
After authenticated, you will see the following screen. Click the RDP link to connect to the VM
desktop using HTTP:

© FORTINET
Note: If you get the error message problem connecting while attempting the HTTP
connection, it might indicate that the RDP service didn’t start correctly. Close the browser
tab and try one more time.
 You can also connect to all the Linux VM desktops using a RDP client. Click the RDP link to
download a .RDP file:
Open the .RDP file to start the RDP client and automatically connect to the VM desktop.
Note: If you get the error message problem connecting while attempting the RDP
connection, it might indicate that the RDP service didn’t start correctly. Close the RDP
client and try one more time.

© FORTINET
 Alternatively, you can connect to any Linux VM desktop using the CONSOLE link:
 To connect to the Linux VM command prompt, take note of the IP address and SSH port number
provided, and use a SSH client, such as PuTTY:
Troubleshooting Tips
 Don’t connect to the remote lab environment through Wi-Fi, 3G, VPN tunnels or other low-
bandwidth or high-latency connections. For best performance, use a stable broadband
connection such as a LAN.

© FORTINET
 If disconnected unexpectedly from any of the VM (or from the lab dashboard), please attempt to
reconnect. If unable to reconnect, please notify the instructor.
 If you get the following error while trying to connect HTTP or RDP, close the browser tab, or the
RDP client and try to connect again:
 If you can’t connect to any of the VMs, try restarting the lab environment. Click the All VMs: Stop
link, and wait until all the VMs have stopped (this could take a few minutes):
Then, click the All VMs: Start link and wait a few minutes more for the VMs to be back up.
Note: Even after a VM status turned green (indicated that the VM is running) you might
need to wait a few minutes more to be able to connect, as the VM’s operative system
might have not finished booting.
 If a VM does not come up after rebooting (for example, after restoring a configuration file), connect
to the VM’s console and check if it has finished booting. If the console is unresponsive, or if the
unit is having problem booting, click the Power off button to turn it off:
Then, wait a few minutes for the VM to completely stop and start it again.

DO NOT REPRINT  Appendix B: Additional Resources
© FORTINET
Appendix B: Additional Resources
Technical Training Courses http://www.fortinet.com/training
Technical Documentation http://docs.fortinet.com
Knowledge Base http://kb.fortinet.com
Forums https://forum.fortinet.com/
Customer Service & Support https://support.fortinet.com
FortiGuard Threat Research & Response http://www.fortiguard.com
Network Security Expert Program (NSE) https://www.fortinet.com/support-and-

training/training/network-security-expert-
program.html

DO NOT REPRINT  Appendix C: Presentation Slides
© FORTINET
Appendix C: Presentation Slides

DO NOT REPRINT  Enterprise Firewall Solution Overview
© FORTINET
In this lesson, you will learn about the Fortinet Enterprise Firewall solution.

© FORTINET
After completing this lesson, you should have the practical skills and knowledge required to:
• Describe the Enterprise Firewall solution
• Use the security fabric for multiple FortiGate units to share traffic and threat information

© FORTINET
Let's start taking a high-level look at the Fortinet Enterprise Firewall solution.

© FORTINET
In the 80's, the traditional way of protecting a network was securing the perimeter and installing a firewall
at the entry point. Network administrators used to trust everything and everyone inside the perimeter.

© FORTINET
Now, malware can easily bypass any entry-point firewall, and get inside the network. This could happen
through an infected USB stick, or an employee’s compromised personal device being connecting to the
corporate network. Additionally, network administrators can no longer take for granted that everything and
everyone inside the network can be trusted. Attacks can now come from inside the network.

© FORTINET
The perimeter of an enterprise network is no longer recognizable. What happens when employees connect
to the corporate network from home? Does the network perimeter extend to each employee's home
network? Where is the perimeter when there are services running in the cloud? What about employees'
personal devices (BYOD)?

© FORTINET
In the same way that threats and network technologies have evolved, your network security strategies
must evolve too. Administrators must apply end-to-end security, from the end points to the cloud.
Additionally, they must deploy internal segmentation firewalls to segment the network so that any breach
coming from inside can be contained in one segment of the network, without reaching other segments.
However, there are challenges to implementing these measures. You need to implement multiple layers of
security, from the end points, through the protected services, through the network entry points, and up to
the cloud. This usually implies the use of multiple vendors, which means no central management and no
central visibility over what is happening in the network.

© FORTINET
The Fortinet Enterprise Firewall solution answers those challenges. It offers effective and fast end-to-end
security with a consolidated operating system: FortiOS. The core of the solution is the security fabric,
which enables the communication of all the security devices in an enterprise network. The Fortinet
Enterprise Firewall solution offers guidelines about where to install your network security devices and what
roles they’ll have in each part of the enterprise network.

© FORTINET
In the Enterprise Firewall solution, each FortiGate device has a specific role, depending on where it is
installed and what assets it’s protecting. In general, there are four roles (or deployment modes):
• Distributed enterprise firewall (also known as UTM)
• Next generation firewall (NGFW)
• Internal segmentation firewall (ISFW)
• Datacenter firewall (DCFW)
You will learn about each of these roles in this lesson.

© FORTINET
Next generation firewalls (NGFWs) play the role of the traditional entry-point firewalls. They are the first
line of defense. In a traditional network architecture, where there is an access layer, a distribution layer,
and a core layer, NGFWs are installed between the core layer and the Internet. The features that are
usually enabled in these FortiGates are firewall, application control, VPNs, and IPS.

© FORTINET
Data center firewalls (DCFWs) protect corporate services. They focus on inspecting incoming traffic and
are usually installed between the distribution layer and the service layer. IPS inspection is one of the
primary tasks these FortiGates must execute.

© FORTINET
Internal segmentation firewalls (ISFWs) split your network into multiple security segments. They serve as
breach containers for attacks that come from inside. Firewall, web filtering, and IPS are the features that
are commonly enabled in these firewalls.

© FORTINET
Distributed enterprise firewalls are usually smaller devices installed in branch offices and remote sites.
They are all-in-one security devices, doing firewall, application control, IPS, web filtering, and antivirus
inspection. They connect to the corporate headquarters through IPsec VPNs.

© FORTINET
There’s a FortiGate for all these deployment modes: the smaller distributed enterprise firewalls, the
internal segmentation firewalls, the entry-point firewalls, the firewalls protecting your data centers, and the
firewalls protecting your services in the cloud. Fortinet offers a consolidated solution using a single
operating system, FortiOS.

© FORTINET
The heart of the Enterprise Firewall solution is the security fabric.

© FORTINET
The security fabric is a Fortinet solution that enables the communication between network security devices
to coordinate the actions upon any security event. The core of the solution includes FortiGate devices and
FortiAnalyzer. To add more visibility and control, Fortinet recommends adding FortiAPs, FortiClient, and
FortiSwitch. The solution can be extended by adding other network security devices, such as FortiMail,
FortiWeb, and FortiSandbox.

© FORTINET
The security fabric offers a single pane of glass for management and reporting, a single point of security
updates, and a single point of authentication.

© FORTINET
The security fabric is open. The API and protocol itself is available for other vendors to join and for partner
integration. This allows for communication between Fortinet and third-party devices.

© FORTINET
The security fabric is a solution that started to evolve in FortiOS 5.4. In FortiOS 5.4.1, the security fabric
can integrate FortiGate, FortiAnalyzer, FortiAP, FortiSwitch, FortiEMS, and FortiClient. It offers a logical,
physical, and endpoint view of each security segment in the network.

© FORTINET
The protocol running the security fabric is FortiTelemetry. FortiView offers short and long term logging and
reporting.

© FORTINET
In this lesson you learned about the Fortinet Enterprise Firewall solution, the various FortiGate deployment
modes in an Enterprise Firewall solution, and the security fabric at the heart of the solution.

© FORTINET
Now you will work on Lab 1–Security Fabric.

© FORTINET
In the first exercise, you will configure the security fabric in the NGFW and the DCFW. The security fabric
follows a tree topology. The NGFW will be the root of the tree and the ISFW and DCFW will be branches.

© FORTINET
In each of the FortiGates, you will do the following:

• Enable FortiTelemetry
• Enable device detection
• Enable security fabric
During the second exercise, you will troubleshoot a security fabric problem between the ISFW and the
NGFW.

DO NOT REPRINT  FortiOS Architecture
© FORTINET
In this lesson, you will learn about the architecture of FortiOS.

© FORTINET
• Describe how FortiOS processes a packet
• Describe how FortiOS uses the memory
• Diagnose high memory and high CPU problems
• Differentiate between system, kernel, and FDS conserve modes
• Optimize the memory usage

© FORTINET
In this section, you will learn about the life of a packet.

© FORTINET
Parallel path processing (PPP) uses the firewall policy configuration to choose from a group of parallel
options to determine the optimal path for processing a packet. That path that PPP chooses also depends
on the hardware configuration.

© FORTINET
This slide shows all the steps that a packet goes through as it enters, passes though, and exits a FortiGate
without any hardware processors.

© FORTINET
Now you will learn about how FortiGate uses the memory.

© FORTINET
To understand how a FortiGate uses its memory, you need to understand the architecture of FortiOS. The
heart of FortiOS is its kernel. The kernel is where FortiGate makes some of the most basic and important
decisions, such as how to route a packet, or when to offload a session to an NPU processor. FortiOS runs
over hardware. The device drivers bridge the kernel with the hardware. The user space is located above
the kernel. Several application processes or daemons run in the user space. Above the kernel and the
user space is the configuration layer, which is basically composed of two modules: the command line
interface and the graphical user interface.

© FORTINET
How FortiGate’s memory is segmented depends on the model. There are two cases. One case applies to
32-bit models with more than 1 GB of memory. The second case applies to both 64-bit models, and 32-bit
models with less than 1 GB of memory. Let’s take a look at the first case.
When the FortiOS is 32 bits and the system memory is more than 1 GB, the kernel cannot access the
whole memory space directly. So, memory paging is used to reach the portion of the memory that cannot
be accessed directly. The part of the memory that the kernel can access directly is called low memory. The
part of the memory that is accessed using memory paging is called high memory. The command
diagnose hardware sysinfo memory displays:
- The total amount of low memory (LowTotal)
- The amount of free low memory (LowFree)
- The total amount of high memory (HighTotal)
- The amount of free high memory (HighFree)
- The total amount of system memory (MemTotal = LowTotal + HighTotal)
- The total amount of free memory (MemFree = LowFree + HighFree)

© FORTINET
For models running 32-bit FortiOS with less than 1 GB, and for models running 64-bit FortiOS, the kernel
doesn't need to use memory paging to access the whole memory space. In those cases the command
diagnose hardware sysinfo memory shows a size of 0 kB for the total high memory and free high
memory. All the memory space is considered low memory.

© FORTINET
FortiGate allocates memory for five main purposes:

- Kernel memory slabs
- System I/O cache
- Buffers
- Shared memory
- Process memory
You will learn about each of these purposes in this lesson.

© FORTINET
The kernel memory slabs are collections of objects with a common purpose. They are used by the kernel
to store information in the low memory.
This slide shows an example of some slabs. There are slabs for storing information about the TCP
sessions. The entries in the route cache are also stored in low-memory slabs.

© FORTINET
To check how much memory is being allocated to kernel slabs, use the command diagnose hardware
sysinfo slab.
The first column shows the slab name. The second column shows the total amount of active objects, then
the amount of available objects, and the size of each object.
The total amount of memory allocated to each slab type can be calculated by multiplying the number of
available objects by their size.
You can use the output of this command to determine how much memory the session table is using. If that
value is too high, it might indicate that the configuration needs some tuning (for example, setting shorter
session TTLs), or that the FortiGate model is too small for the amount of traffic crossing the device.

© FORTINET
The system I/O cache is used to speed up the access to information stored in the hard and flash disk
memories. Some processes, such as logging, WAN optimization, and explicit proxy, store information in
the hard disk, so they get the performance boost provided by this memory allocation.
An I/O cache page is labeled as active when it has been recently accessed. It goes to inactive state after
not been used for some time. An inactive page can be reclaimed by the kernel if needed.

© FORTINET
The command diagnose hardware sysinfo memory displays the total amount of memory allocated
for I/O cache. It also lists the amount of memory allocated for buffers.

© FORTINET
Above the kernel layer there are multiple application processes or daemons running. The operating system
allocates separated blocks of memory for each process. One process can access the memory that was
allocated to it, but it cannot access any memory that was allocated to a different process. So, a process
cannot share information with another process by reading or writing data into the memory allocated to that
other process. For that purpose, the operating system dynamically allocates shared memory (SHM). The
SHM can be accessed by multiple processes, allowing the sharing the information among them.

© FORTINET
You can see how much memory space is being used by each process. The command diagnose sys
top shows that information in the last column. The command also displays, for each process: its ID
number, its state, and the amount of CPU usage. You can specify the refresh frequency and the number of
lines to display.
While the command is running, you can press <shift-P> to sort the processes by CPU usage, or <shift-M>
to sort them by memory usage. To stop the command, press <ctrl-C>.

© FORTINET
Another useful command for displaying information about process memory usage is diagnose sys
top-summary. The –h option displays the different options available for this command.

© FORTINET
You can use the option –s mem to sort the processes by memory usage, the option –i 60 to refresh it
every 60 seconds, and the option –n 10 to display the top 10 processes.
One advantage of this command is that it shows the total amount of memory allocated by all forked or child
processes, including shared memory. In the case of diagnose sys top, each child process is displayed
separately. Here, we have an aggregated view of all of them.
The output also shows the amount of file descriptors allocated. If the amount of any of the descriptors
keeps constantly increasing, it might indicate that there is a memory leak problem. If a process has forked,
the number of child processes is displayed after its name.

© FORTINET
This table shows some of the most common processes.

© FORTINET
This table shows more of the most common processes.

© FORTINET
The command diagnose sys top shows the state of each process. A process can be in one of four
states: sleeping (S), running (R), do not disturb (D) or zombie (Z).
The S and R states are normal. It is also normal if a process goes briefly to D state. The Z state is not
normal. Also, it is not normal if a process stays in D state for a long time. This usually indicates that the
process is not working properly.

© FORTINET
Now that you have a better understanding of how FortiGate uses the memory, let’s look at conserve mode.

© FORTINET
If your FortiGate memory usage is high, you should examine the event log. Look for messages related to
conserve mode. Memory conserve mode occurs when FortiGate doesn’t have enough RAM available to
handle traffic.
Content inspection (especially proxy-based) increases memory usage beyond simple firewall policies. In
other words, when antivirus is enabled, FortiGate is more likely to use more memory, which can cause
FortiGate to go in to conserve mode. You can determine whether antivirus or any other process is using
too much memory by running the CLI command diagnose sys top.
There are two types of memory conserve mode: kernel and system.

© FORTINET
Two margins or thresholds determine when FortiGate enters and exits the kernel conserve mode. For all
FortiGate models that have 64-bit CPUs, the margins for kernel conserve mode depend on the total overall
memory. When a FortiGate is in kernel conserve mode, any proxy inspection is bypassed, and
administrators cannot perform configuration changes.

© FORTINET
Like kernel conserve mode, two different thresholds determine when FortiGate enters and exits system
conserve mode. The margins also depend on the total amount of overall memory.

© FORTINET
This slide shows the entries that are generated in the event logs when a FortiGate enters kernel and
system conserve mode.

© FORTINET
av-fail-open is the CLI setting that controls FortiGate’s behavior while it is in system conserve mode.

© FORTINET
File descriptors (FDs) are used as handlers to access input and output resources, such as a file.
FortiGates will become unresponsive if all available FDs are used. To prevent this from happening a new
conserve mode was introduced in 5.4. FDS conserve mode will prevent a single process/process group
from using up all the available free FDS. This allows the system to continue to operate under heavy load.
A FortiGate enters in FDS conserve mode when the amount of free available FDS is less than 5%.
FDS conserve mode only affects the WAD processes.

© FORTINET
This command is used to determine if a FortiGate device is currently in system conserve mode, FDS
conserve mode, or both.

© FORTINET
An option related to fail-open, is av-failopen-session. This setting is used when a proxy on the
FortiGate runs out of available sessions to process the traffic, not during a high memory situation.
If you enable av-failopen-session, then FortiGate acts according to the av-failopen setting.
Otherwise, by default, it blocks new sessions until proxy connections become available.

© FORTINET
FortiGate has one more mechanism to free memory when there is not much available. If the kernel cannot
allocate more memory pages, it deletes the oldest sessions. The command diagnose sys session
stat shows the numbers of sessions deleted by the kernel due to this mechanism.

© FORTINET
FortiGate has a mechanism to protect memory usage against some forms of DoS attacks. FortiGate
categorizes an entry in the session table as an ephemeral session when it is a TCP session that is not fully
established (three-way handshake not completed), or it is UDP session with only one packet received.
During some DoS attacks, the number of these types of sessions tend to increase abnormally, potentially
consuming the unit memory. FortiGate sets a hard limit in the maximum number of ephemeral sessions
that can simultaneously exist in the session table.

© FORTINET
What can you do if a FortiGate enters in conserve mode frequently, or if its memory utilization is too high?
You can optimize memory usage by fine tuning the FortiGate configuration.

© FORTINET
Many FortiGate processes, such as DLP or AV scanning, are memory intensive. So, memory optimization
is important, especially in small units, to guarantee that these processes will stay away from memory
conserve mode. This slide shows some recommendations for optimizing memory usage. These tips might
significantly increase the available memory in a device that is frequently going to conserve mode.
The first and most logical step is to disable features that are not required. For example, if the network
already has a FortiMail doing antispam, an administrator does not need to do antispam in the FortiGate.
Also, usually not all the IPS signatures are required.
Another recommendation is to reduce the maximum file size to inspect, which is set to 10MB by default.
This value can be reduced to 2 or 3 MB without significantly reducing the virus catching rate, as a typical
virus size is less than 1 MB.

© FORTINET
Additionally, you can reduce the amount of memory allocated to some caches, such as the ones for
FortiGuard and DNS.

© FORTINET
The FortiGate session table can consume an important portion of memory, especially in networks with a
high rate of traffic. By default, a session without traffic remains in the table for up to one hour. Although
this high a time to live (TTL) might be required by some applications, in most networks, you can reduce the
session TTL. When you reduce the TTL, FortiGate ages out idle sessions much quicker, increasing the
amount of available memory. There are four places in FortiGate configuration where the session TTL can
be reduced. Two of them are:
- Globally, for all the traffic
- On an IP protocol and port number basis

© FORTINET
The other two places where the session TTL can be reduced:
- For each firewall policy
- For each application control
If an application requires a high session TTL, you can reduce the TTL globally to five minutes. However,
set it to one hour only for the specific application port number, or firewall policy.

© FORTINET
Most TCP session timers can also be reduced from their default values without causing problems to the
applications. This slide shows some recommended values that are equal to or below the default values.
Use these recommended values to optimize the memory usage.

© FORTINET
The tcp-halfopen-timer controls for how long, after a SYN packet, a session without SYN/ACK
remains in the table.
The tcp-halfclose-timer controls for how long, after a FIN packet, a session without FIN/ACK
remains in the table.
The tcp-timewait-timer controls for how long, after a FIN/ACK packet, a session remains in the
table. A closed session remains in the session table for a few seconds more to allow any out-of-sequence
packet.

© FORTINET
In this lesson, you learned about the following:

• The life of a packet
• How FortiOS uses memory
• The most common FortiOS processes and process states
• System and kernel conserve mode
• FDS conserve mode
• Optimizing memory usage

© FORTINET
Now you will work on Lab 2–FortiOS Architechture.

© FORTINET
In this lab you will run debug commands to gather information about resource utilization in the ISFW.

DO NOT REPRINT  System Troubleshooting
© FORTINET
In this lesson, you will learn about how to troubleshoot system issues.

© FORTINET
After completing this lesson, you will have the practical skills and knowledge required to:
• Monitor process activity using real time debugs
• Describe how HA virtual MAC addresses are assigned
• Monitor an HA cluster
• Check the status of the HA configuration and session synchronization
• Sniffer the HA heartbeat traffic
• Troubleshoot some common HA problems
• Troubleshoot unexpected reboots and frozen units
• Use the crashlog for diagnostics

© FORTINET
In this section you will learn about general system troubleshooting commands.

© FORTINET
The get sys status command is usually one of the first debug commands that you use when
troubleshooting. The output shows the firmware version, FortiGuard database versions, license status,
operation mode, number of VDOMs, and system time.

© FORTINET
The get system performance status command shows the overall memory and CPU utilization. It
also shows session creation rate, number of viruses caught, and number of attacks blocked by the IPS.
The last line displays the system uptime. This output gives you a quick view of how much traffic the device
is handling.

© FORTINET
The real time debug commands generate information in real time about what a specific FortiGate process
or feature is doing.
The debug level is a bitmask value that specifies which types of messages are displayed. The meaning of
the debug value depends on each process. However, for all cases, a debug level of 0 means no output
(disabled) and a debug level of -1 means enabling all possible message types.

© FORTINET
This slide shows the two commands you use to enable all the IPsec real time debug output. You can also
enable the option to prepend the system time to each debug line. It’s important to disable any real time
debug after using it because they consume FortiGate resources and some can be CPU intensive.

© FORTINET
Application layer test commands don’t display information in real time, but they do show statistics and
configuration information about a feature or process. You can also use some of these commands to restart
a process or execute a change in its operation.

© FORTINET
Some CLI debug commands generate a lot of output. If you know that the information that you need is
contained in a specific line of the output, and if you know a keyword that you can use to find that line, then
you can use the GREP utility. This utility displays only the lines that match a text string. For example, in
this slide we used the GREP utility to find the IP address 10.0.0.2 in the ARP table. We used the debug
command diagnose ip arp list to get the ARP table, and then we appended the GREP utility to
display only the information for one IP address. The result: the output is only one line, containing exactly
the information we need, instead of a long list of entries.

© FORTINET
When you display the FortiGate configuration through the CLI, you can use the GREP utility with the option
–f. It will display only the configuration sections (or tables) where the text string matches at least one
value. This is useful, when you want to find all the references in the configuration to a specific object. In
this slide, we used the –f option to find all the references to the wan1 interface. The output shows only the
two tables where wan1 is referenced: the definition of the interface itself, and a firewall policy where wan1
is the destination interface.

© FORTINET
In this section, you will review HA operations and learn about some HA troubleshooting commands.

© FORTINET
To forward traffic correctly, a FortiGate HA solution uses virtual MAC addresses. When a primary joins an
HA cluster, each interface is given a virtual MAC address. The primary informs all secondary units about
the assigned virtual MAC addresses. Upon failover, a secondary adopts the same virtual MAC addresses
for equivalent interfaces.

© FORTINET
The HA virtual MAC addresses assigned to each interface are determined by the HA group ID, the virtual
cluster ID, and the interface index. So, if you have two or more HA clusters in the same broadcast domain,
and using the same HA group ID, you might get MAC address conflicts. For those cases, it is strongly
recommended that you assign different HA group IDs to each cluster.

© FORTINET
You can use the diagnose hardware deviceinfo nic command, the same command you use to
get interface traffic statistics, to display the HA virtual MAC address assigned to an interface.

© FORTINET
After a failover, the new primary broadcasts gratuitous ARP packets, notifying the network that each virtual
MAC address is now reachable through a different switch port.
In most networks, that’s enough for the switches to update their MAC forwarding tables with the new
information. However, some high-end switches might not clear their MAC tables properly after a failover.
So, they keep sending packets to the former primary even after receiving the gratuitous ARPs. In these
cases, you should use the command link-failed-signal to force the former primary to shut down all
its non-heartbeat interfaces for one second when the failover happens. This simulates a link failure that
clears the related entries from the switches' MAC tables.

© FORTINET
FortiGate HA uses FGCP, the FortiGate clustering protocol, for HA-related communications. FGCP travels
among the clustered FortiGate units over the links that you have designated as the heartbeats.
The FGCP traffic uses a different Ethernet type than the IP protocol. It actually uses three different
Ethernet types, depending on the operation mode (transparent or NAT/route).

© FORTINET
Let’s look at how an HA cluster in active-active mode distributes traffic. First, the client side sends a SYN
packet. It’s always forwarded to the primary FortiGate using the internal interface’s virtual MAC address as
the destination. If the primary decides that the session is going to be inspected by a secondary, the
primary forwards the SYN packet to the respective secondary. In the example shown in this slide, the
destination MAC address is the physical MAC address of the secondary FortiGate. The secondary
responds with SYN/ACK to the client and starts the connection with the server by directly sending a SYN
packet.

© FORTINET
When the server responds to the TCP SYN, the packet is sent to the primary using the external interface’s
virtual MAC. The primary signals the secondary, and it is the secondary that replies to the server.
As you can see, the objective of active-active mode is not to load balance bandwidth. The traffic is always
sent to the primary first. The main objective is to share CPU and memory among multiple FortiGates for
traffic inspection.

© FORTINET
Next, the client acknowledges the SYN/ACK. It’s forwarded to the primary using the virtual MAC address
as the destination. The primary device forwards the packet to the secondary inspecting that session, using
the secondary’s physical MAC address.

© FORTINET
If you connect to a secondary's console port while it is joining an HA cluster, you should see the messages
shown in this slide. First, the secondary tries to synchronize the external files. The external files include the
FortiGuard databases and digital certificates. After that, the secondary synchronizes the configuration. The
last message indicates that the secondary has successfully joined the cluster.

© FORTINET
If the HA cluster forms successfully, the GUI displays all the FortiGate members with their hostnames and
serial numbers.

© FORTINET
When troubleshooting a problem in an HA cluster, it is useful to know that you can connect to the CLI of
any secondary from the primary CLI using the command execute ha manage with the secondary HA
index. To get the list of secondary FortiGates and their HA indexes, use the question mark at the end of
that same command.

© FORTINET
Using the CLI, you can get more information about the status of the HA. For example, the command
diagnose sys ha status displays heartbeat traffic statistics, as well as the serial number and HA
priority of each FortiGate. This command also shows the heartbeat interface IP address automatically
assigned to the primary FortiGate.

© FORTINET
The get sys ha status command provides much of the same information as the diagnose sys ha
status command, plus the following additional output:
• HA health status
• Cluster uptime
• Criteria used to select the master unit
• Override status
• Status of the monitored interfaces
• Status of the HA ping servers

© FORTINET
The HA uptime is one of variables used to elect the primary unit. Depending on other variables and
configuration, the units might compare their system uptimes to elect the primary. If that happens and if
there is one member whose system uptime is five minutes more than the system uptimes of all the other
units, that member is elected primary. You can use this command to compare the system uptimes of all
the units in a cluster.

© FORTINET
A good indication of the health of an HA cluster is the status of the configuration synchronization. To check
that all the secondary configurations are synchronized with the primary configuration, you can execute the
command diagnose sys ha checksum show in all the HA units. If a secondary FortiGate displays
exactly the same sequence of numbers as the primary, its configuration is synchronized. Also, and as long
as there are no configuration changes happening, in each of the devices, the debugzone and the
checksum zone must display the same sequence of numbers. Later in this lesson, you will learn some tips
for troubleshooting when this is not the case.
The checksum zone contains the checksum of the configuration that is actually running in the device. The
debugzone is where configuration changes are first stored before applying them to the running
configuration. So, during a configuration change you might see that the debugzone checksum differs from
the checksum for short time, while the configuration changes are copied to the running configuration. After
that short time, both checksums should match again.

© FORTINET
Instead of running the diagnose sys ha checksum show command in each of the cluster units, you
can run the diagnose sys ha checksum cluster command only on the primary. It shows the
checksum for all the cluster members. This command is easier to use; however, if there are
communication problems between one of the secondary units and the primary, you might need to use the
diagnose sys ha checksum show command instead.

© FORTINET
HA session synchronization is disabled by default. If you enable it, you can check the primary's session
table to see which sessions have been synchronized to the secondary units. They are the ones with the
synced flag. Additionally, and for the case of all sessions, the ha_id field shows the HA member ID of
the unit that is processing the traffic.

© FORTINET
There are three occurrences that can trigger a failover:

• When the primary stops replying to heartbeats
• When the link status of a monitored interface goes down. You can configure a HA cluster to monitor the
link status of one or more interfaces.
• When a server (IP address) stops replying to the ping sent by the primary. You can configure a HA
cluster to periodically send a ping to one or more servers to test the connectivity between the primary
unit and the network services.

© FORTINET
If a failover happens, the best tool to use to get information about the failover is the FortiGate logs. If the
failover happened because the primary unit failed, the secondary unit's logs should show these log entries.

© FORTINET
If a new primary was elected because one or more monitored interfaces failed, the former primary displays
logs similar to the ones shown in this slide. In the example shown here, the primary unit is reporting a
problem with the monitored interface port1.

© FORTINET
If a device can’t join a cluster, follow these steps:

1. Verify the HA settings
2. Verify the firmware versions and hardware models
3. Verify the physical layer connections
4. Use the HA real time debug while the unit tries to join the cluster. Run the debug both in the primary
and the unit with the problem.
If the problem is that the checksums between the debugzone and checksum zones don’t match, you can
try to fix it by forcing the recalculation.

© FORTINET
Traffic from session synchronization is bandwidth intensive. If the session creation rate is high, session
synchronization traffic can interfere with heartbeat traffic, creating delays in heartbeat replies. There are
two configuration changes that you can make that might help:
• Use a different interface from the heartbeat interface for session synchronization
• Delay the synchronization of new sessions by 30 seconds, so short-live sessions are not synchronized
High CPU issues could also create HA heartbeat problems. In those cases, troubleshoot and fix the high
CPU problem first, before checking the HA status.

© FORTINET
In the final section of this module, you will learn how to troubleshoot system crashes.

© FORTINET
In some FortiGate models, you can configure the device to store all the console logs into the flash
memory. This is especially useful when troubleshooting unexpected reboots and units that randomly
become unresponsive. Once the logs are stored, they can be displayed from the CLI, or downloaded from
the GUI for further analysis.

© FORTINET
This slide shows the commands for enabling, displaying, and clearing the console logs.

© FORTINET
A crashdump message is usually generated through the console port when the device crashes.
Crashdump messages can provide useful information to Fortinet developers. If the problem is a FortiGate
that is rebooting unexpectedly, the administrator should check the logs, the console logs, and the crashlog.
If the FortiGate model doesn’t support a console log, keep a laptop connected to the console port, run the
commands in this slide, and wait until another crash happens.

© FORTINET
We say that a FortiGate freezes when it stops handling traffic, and there’s no way to connect to it; you
can’t even access its console port. Only power cycling fixes the issue. For those cases, you could capture
any crashdump in the console port. Additionally, and in the case of models with more than one CPU, you
can enable the NMI watchdog feature, which automatically crashes the system (and forces the
crashdump) when no new daemons have been scheduled in the last 10 minutes. This is an indication that
the unit is not operating normally and might be frozen.
Some FortiGate models also have an external NMI button. If the unit is frozen and no crashdump has been
generated, you can press the NMI button to force a crash and get a crashdump.

© FORTINET
Each time an application crashes, or closes, an entry is generated in the crashlog. When an application
crashes, the entry contains the name of the application, the time it crashed, and the termination signal.
This slide shows a sample of a crash in the crashlog. In this example, the application that failed was the
sslvpnd process, which manages SSL VPN connections. The termination signal is 11, which is a
segmentation fault.

© FORTINET
This table contains the most common termination signal numbers. Any administrator can manually kill a
process by using the command diagnose sys kill, followed by the process ID, and the termination
signal number. The command diagnose sys top lists the process ID numbers. Manually killing a
process is not usually required under normal circumstances. If you have to kill a process, use the
termination signal 9. Improperly killing a process can make a FortiGate system unstable.

© FORTINET
So, how do you know if the crashlog is normal or not?

In most cases, entries in the crashlog are normal. A crashlog entry can be considered suspicious if it
happens at the same time as a failure in a FortiGate feature, or abnormal behaviour of the FortiGate.
For example, a crashlog entry that is generated when the unit unexpectedly reboots might provide
information about the cause. A crash in the sslvpnd process when all SSL VPN users get disconnected
is also relevant. The crashlog includes the details about the crash and information that can be used by
Fortinet development to determine which code triggered the problem.

© FORTINET

• General system troubleshooting commands
• Enabling real time debugs
• HA virtual MAC addresses
• Traffic flow in HA active-active
• Monitoring a HA cluster
• Checking configuration and session synchronization
• FGCP and HA log samples
• HA troubleshooting tips
• Crashlog
• Troubleshooting unexpected reboots and frozen units

© FORTINET
Now you will work on Lab 3–System Troubleshooting.

© FORTINET
In this lab, you will manually kill a process and view the corresponding crashlog.

DO NOT REPRINT  Traffic and Session Monitoring
© FORTINET
In this lesson, you will learn about traffic and session monitoring.

© FORTINET
• Interpret the information in the session table
• Capture traffic using the built-in sniffer
• Analyze the output of the debug flow
• Configure and troubleshoot session helpers
• Configure and troubleshoot the SIP application layer gateway

© FORTINET
In this section, you will learn about session table entries.

© FORTINET
The FortiGate session table contains detailed information about every IP connection that crosses or
terminates at the FortiGate. The command get system session status displays the total number of
sessions in the active VDOM. The command get system session list provides a brief summary of
each session. This command lists one session on each line, and includes information such as protocol,
source IP address, destination IP address, and port. You can use the grep utility with this command to
list only the sessions for a specific IP address.

© FORTINET
To display detailed information about sessions, use the command diagnose sys session list. It is
recommended that you set the session filter first, as an unfiltered output displays all the details about all
the existing sessions. For high-end devices, a list of all existing sessions could be in the thousands, or
even millions. You can filter the output by policy ID, source IP address, source port, destination IP address,
and destination port.

© FORTINET
Some configuration changes, such as security profile changes or session helper changes, apply only to
new sessions. In the case of those changes, existing sessions keep using the previous configuration until
they expire or are terminated. This is important to remember when troubleshooting problems. After a
security profile change, you should clear any sessions related to that change, and generate new sessions.
Use the command diagnose sys session clear to remove all sessions that match the session filter.
You must be careful with this command because it can, potentially, clear all the existing sessions if no filter
has been set. Before you remove all sessions, use the command diagnose sys session filter to
check the filters.

© FORTINET
This slide shows a sample of the output contained in the FortiGate session table. From left to right, and
from top to bottom, the following information is highlighted:
- The IP protocol number and the protocol state (this value is covered in this lesson)
- The length of time until the session expires (if there is no more traffic)
- Traffic shaping counters
- Session flags
- Received and transmitted packet and byte counters
- If the unit is doing NAT, this portion shows the type of NAT (source or destination) for each traffic
direction, and the NAT IP address
- The source MAC address of the packet
- The ID number of the matching policy
- Counters for hardware acceleration

© FORTINET
The protocol state in the session table is a two-digit number. For TCP, the first number is related to the
client-side state and is not 0, when the session is being handled by a FortiGate proxy (for example, when
the FortiGate is doing proxy-based inspection). The second digit is the server-side state and is used to
identify the status of the TCP session. This table and flow graph correlate the second-digit value with the
different TCP session states. For example, when the FortiGate receives the SYN packet, the second digit
is 2. It changes to 3 when the SYN/ACK packet is received. After the three-way handshake, the state value
changes to 1.
When a session is closed by both sides, FortiGate keeps that session in the session table for a few
seconds more, to allow for any out-of-order packets that might arrive after the FIN/ACK packet. This is the
state value 5.

© FORTINET
For UDP, the session state can only have two values: 00 when traffic is only one way, and 01 when there
is traffic two ways. For ICMP, the protocol state is always 00.

© FORTINET
This table shows the meaning of the most important session flags. For example, the log flag indicates that
the session is being logged. The local flag indicates that the session originated from the FortiGate or is
terminates in the FortiGate.

© FORTINET
Let’s take a look at the dirty and may_dirty flags. When FortiGate receives the first packet for a new
session, it evaluates whether the traffic should or shouldn’t be allowed, based on firewall policies. As long
as there are no changes in the firewall policy configuration, this evaluation is done only on the first session
packet. If the traffic is allowed by a firewall policy, FortiGate creates a session and flags the session as
may_dirty.
After that, if there is a change in the firewall policy configuration, all the existing sessions with the
may_dirty flag are also flagged as dirty. This indicates to the FortiGate that it needs to reevaluate the
next session packet to determine if the session must be blocked. If the session is still allowed, the dirty
flag is removed, but the may_dirty flag is kept. If the session must be blocked, it is flagged as block
and remains in the session table until it expires. Any packet matching a session with the block flag is
dropped.

© FORTINET
In this section, you will learn about two useful troubleshooting tools: the built-in sniffer and the debug flow.

© FORTINET
Let's review the built-in sniffer. When you enable this tool, you can chose from six verbosity levels. The
table shows what information is displayed in each level. We usually use level 4 to check how the traffic is
flowing and if the FortiGate is not dropping packets. We also use level 3 or level 6 to convert the output to
PCAP format, which can be later analyzed with a tool such as WireShark.

© FORTINET
To sniffer traffic in all interfaces, use the keyword any as the interface name.
Stop the sniffer by pressing Ctrl-C, and check for dropped packets. If there were dropped packets during
the sniffer, it means that not all the traffic that matched the sniffer filter could be captured. So, you might
need to capture the traffic again, using a stricter filter or with a reduced amount of traffic to capture.
If you don’t specify an option for the timestamp, the debug shows the time, in seconds, since it started
running. As explained earlier in the lesson, you can prepend the local system time to easily correlate a
packet with another recorded event.

© FORTINET
Another useful FortiGate troubleshooting tool is the debug flow.

The debug flow is also called internal sniffer because it works similarly to the built-in sniffer, but the output
shows step-by-step, and with details, what the kernel is doing with each packet.

© FORTINET
This is a sample of a debug flow output. In this example, the debug flow has captured the three packets of
a TCP 3-way handshake. The output for the SYN packet shows when the kernel creates a new session
(with its session ID), finds the route to the destination, and applies NAT. It also shows the ID of the policy
that matches this traffic.
The output of the SYN/ACK and ACK packets shows the session ID and NAT information.
This tool is useful for many troubleshooting cases, such as when you need to understand why a packet is
taking a specific route, or why a specific NAT IP address is being applied.

© FORTINET
The debug flow can also help you determine why FortiGate is dropping packets. In those cases, the debug
flow usually shows an error message explaining why a packet was dropped.
This slide shows three messages that you commonly see in debug flow output when FortiGate is dropping
packets:
• Denied by forward policy check indicates that either no firewall policy allows the traffic, or that
a disclaimer has not been accepted yet
• Denied by end point ip filter check indicates that the IP address has been quarantined by
the DLP inspection
• exceeded shaper limit, drop indicates that the packet was dropped due to a traffic shaper that
has exceeded one of its thresholds

© FORTINET
This slide shows two more common debug flow error messages. The first error message indicates that the
packet failed the reverse path forwarding check.
The second error message usually indicates one of the following:
• The packet is destined to a FortiGate IP address (for example, management traffic), but the service is
not enabled, the service is using a different port, the source IP address is not included in the trusted
list, or the packet matches a local-in policy with the action deny.
• The packet is destined to a device on the other side of the FortiGate, but a virtual IP or IP pool is
wrongly using that IP address. In this case, check your virtual IP or IP pool configuration.

© FORTINET
Not all the sessions are created by traffic matching existing firewall policies. In this section, we will look at
how FortiGate can create sessions for traffic that is expected to come, but hasn't arrived yet. This is part of
what session helpers and the application layer gateway do.

© FORTINET
To understand what a session helper does, let’s look at an example of a network protocol that might have
problems when a network device is doing NAT. This example shows FTP protocol working in active mode.
Any FTP file transfer is composed of two TCP sessions: one for the control channel and one for data
transfer. The control channel is always initiated from the client to the server and is used to send the FTP
commands. The FTP commands allow the client to move through the server folder, specify the type of file
transfer, and initiate the data channel for uploading or downloading a file.
FTP has two modes: active and passive. The mode determines who initiates the data channel. In passive
mode, the data channel is initiated by the client. In active mode, the client sends the port command
through the control channel. The command includes the client IP address and the TCP port for the
incoming data channel. Then, the server initiates the TCP session to the IP address and port number
specified by the port command.

© FORTINET
Active FTP won’t work if the control channel crosses a network device doing NAT, that does not have a
session helper. In this example, an FTP client is connecting to an active mode FTP server. There is a
router in the middle doing NAT of the client IP address 10.0.1.10 to the NAT IP address 10.200.1.1.
After the control channel is up, the client sends the port command with its IP address, 10.0.1.10, as the
destination for the data channel.
When that FTP packet crosses the router, the source IP address in the IP header is changed from
10.0.1.10 to 10.200.1.1. However, the IP address in the FTP port command is not translated to
10.200.1.1.
Once the server receives that FTP command, it tries to bring up the TCP session for the data channel. It
sends the SYN packet to the IP address 10.0.1.10. This address is probably not routable, as it is a private
IP behind a device doing NAT.
The file transfer fails.

© FORTINET
The FTP session helper fixes this problem. Let’s replace the router with a FortiGate. This is what the
FortiGate session helper does.
When the packet with the FTP port command arrives at the FortiGate, the FortiGate not only translates
the source IP address in the IP header, the session helper also translates the IP address inside the FTP
port command. If the source port is also translated in the TCP header, the session helper also does the
same in the port command.
Another important function of the session helper is to temporally create an expected session (or pin hole)
for the data channel connection that will come from the server. That means that the administrator does not
need to manually create firewall policies to allow these incoming TCP sessions (which use random TCP
ports numbers). The session helper automatically creates the session and opens the door for the incoming
(click) connection.
After that, the server connects the data channel to the right IP address: 10.200.1.1. That incoming TCP
connection is allowed by the expected session previously created by the session helper, even when there
is no firewall policy allowing it.

© FORTINET
This slide shows a packet capture of the previous FTP traffic before the port command reaches the
FortiGate. We see the original client IP address, 10.0.1.10.

© FORTINET
This slide shows another packet capture, this time after the port command crosses the FortiGate. The
session helper has translated the IP address inside the port command to 10.200.1.1.

© FORTINET
SIP is another protocol that requires a session helper in a NAT environment. Similar to FTP, SIP uses
control channels and data channels. In SIP, four data channels, two for each traffic direction, are required
for each call. In this slide, there are two SIP phones with the IP addresses 10.0.1.10 and 172.168.100.205.
Additionally, a FortiGate is doing NAT of 10.0.1.10 to 66.171.121.44.
Once the control channel is up, a SIP phone sends an invite packet with its IP address and port
numbers for two of the four data channels. The FortiGate session helper creates two expected sessions,
and translates the IP address inside the invite packet to 66.171.121.44.
The remote phone sends an OK packet to the right destination IP address (66.171.121.44). The packets
include the IP address and ports for the other two data channels. The session helper creates two more
expected sessions, this time using the information coming in the OK packet. After that, the four data
channels can be connected through the four expected sessions. Firewall policies are not needed to allow
this traffic.

© FORTINET
There is a way to list the expected sessions created by the session helpers. In this example, the
diagnose sys session list expectation command lists an expected session to allow traffic from
10.171.121.38 to 10.0.1.10, port TCP 50365.

© FORTINET
The debug flow shows the name of the session helper (if any) that is inspecting the traffic. In this case, it is
the FTP session helper.
Also, for traffic that matches an expected session previously created by a session helper, the debug flow
shows the message: Find an EXP session.

© FORTINET
There are other protocols that, in some circumstances, also require a session helper, for example PPTP,
H323, and RSH. We can list the active session helpers by typing the command show after the command
config system session-helper. The output lists the TCP or UDP port numbers that each session
helper is listening to. If one of those protocols is using a different port number, you need to change the
FortiGate configuration to match it. You can either change the port number in the existing session-help
entry, or add a new entry.

© FORTINET
For SIP traffic inspection, the FortiGate includes a feature smarter and more versatile than the SIP session
helper. It is the SIP application layer gateway (SIP ALG).
The SIP ALG has all the same functions of the SIP helper, but provides more features. Also, while session
helpers run in the kernel, SIP ALG runs as a user space process.

© FORTINET
FortiGate uses either the SIP helper or the SIP ALG, depending on the configuration. The system setting
default-voip-alg-mode specifies which one is used when no VoIP profile is applied. If it is set to
proxy-based (default), SIP ALG is used. If it is set to kernel-helper-based, SIP helper is used.
If the SIP traffic matches a firewall policy with a VoIP profile, SIP ALG is always used, regardless of the
default-voip-alg-mode setting.
Fortinet recommends the use of SIP ALG. The SIP helper should be used only when the SIP ALG is not
working as expected.

© FORTINET
These are the commands you use to change the ports for the SIP ALG. The SIP ALG supports SIP over
UDP, SIP over TCP, and encrypted (SSL) SIP.

© FORTINET
The command diagnose sys sip-proxy calls list displays all the active SIP calls.
The command diagnose sys sip-proxy calls clear disconnects all the active SIP calls.

© FORTINET
There are two real time debugs that display information about SIP traffic:
• diagnose debug application im 31
• diagnose debug application sip <debug_level>

© FORTINET
In this lesson, you learned how to do the following:

• Interpret the information in session table
• Capture traffic using the built-in sniffer
• Analyze the output of the debug flow
• Configure and troubleshoot session helpers
• Configure and troubleshoot the SIP application layer gateway

© FORTINET
Now you will work on Lab 4–Traffic and Session Monitoring.

© FORTINET
In this lab, you will use debug commands to troubleshoot four connectivity problems. You will also analyze
the information in the FortiGate session table, run the built-in sniffer, and use the debug flow to understand
how FortiGate is processing each IP packet.

DO NOT REPRINT  Routing
© FORTINET
In this lesson you will learn about advanced routing concepts that are relevant to enterprise networks.

© FORTINET
• Describe how FortiGate routes traffic
• Diagnose routing problems caused by reverse path forwarding check
• identify sessions that will be routed through a different path after a routing table change
• Use debug commands to troubleshoot routing and WAN link load balancing problems

© FORTINET
This section covers general routing concepts and troubleshooting.

© FORTINET
A FortiGate is a stateful device, so it decodes a lot of information at the beginning of a session, based on
the first packets. For any traffic session, FortiGate usually performs only two routing lookups: one on the
first packet sent by the originator and another one on the first reply packet coming from the responder.
After that, all the routing information is written in the FortiGate session table. However, after a change to
the routing table, the route information is flushed from the affected entries in the session table. So,
FortiGate would perform additional routing table lookups in order to repopulate the session table with the
new routing information.

© FORTINET
How does FortiGate decide routes? FortiGate has multiple routing modules. The diagram shown in this
slide illustrates the logic of the routing modules.
First, FortiGate searches its policy routes. You can view them using the command diagnose firewall
proute list. If there is a match in a policy route, and the action is Forward Traffic, FortiGate
routes the packet accordingly. If the action is Stop Policy Routing, FortiGate goes to the next table,
which is the route cache. You can view that content using the CLI command diagnose ip rtcache
list.
Finally, FortiGate searches the forwarding information base (FIB). The FIB is generated by the routing
process, and is the table used for packet forwarding. Think of the routing table’s purpose as management,
while the FIB’s purpose is forwarding. This separation becomes clearer in FortiGate active-active HA. In an
HA cluster, both route management and forwarding tables exist on the master FortiGate. But on the slave
FortiGate, only the FIB exists.
If there’s no match in any of those tables, FortiGate drops the packet because it is unroutable.

© FORTINET
When there is more than one route to a destination, this is the process for selecting which route to use.
First, FortiGate uses the most specific route, which is the one with the longest net mask (smallest subnet).
If there are two or more routes with the same longest net mask, the unit selects the one with the shortest
distance. After that, the lowest metric is used as the tie breaker for dynamic routes. In the case of static
routes, the priority is used instead. If there are multiple routes with the same net mask, distance, metric,
and priority, FortiGate shares the traffic among all of them. This is called equal cost multipath (ECMP).
ECMP is supported for static, BGP, and OSPF routes.

© FORTINET
The FortiGate adds a static route to the routing table only if all these requirements are met:
• The outgoing interface is up
• There is no other route to the same destination with a shorter distance
• The link health monitor (if configured) is up
• The next-hop IP address is in the same subnet as one of the IP addresses assigned to the outgoing
interface

© FORTINET
Let's review an important routing concept: reverse path forwarding (RPF) check.
RPF check protects against IP spoofing attacks and routing loops by checking the route to the source IP
address. This check is performed on the originating packet only, not on reply packets. This check is
performed only before the session is created, or after the routing table is changed. If the check fails, the
packet is dropped and the debug flow shows this error: reverse path check fail, drop.

© FORTINET
There are two RPF check modes: feasible path (formerly known as loose) and strict. Feasible path is the
default mode.
In feasible path mode, the packet is accepted as long as there is one active route to the source IP through
the incoming interface. It does not have to be the best route, just an active one. In the example shown in
this slide, the packet from 10.4.0.1 to 10.1.0.1 is accepted because FortiGate has an active route (the
default route) to 10.4.0.1 through port2. However, the packet from 172.16.1.1 to 10.1.0.1 is not accepted,
because there is no active route to the IP address 172.16.1.1 through port3.

© FORTINET
In strict mode, the FortiGate checks that the best route to the source IP address is through the incoming
interface. The route not only has to be active (as in the case of feasible path mode), but it also has to be
the best.
If you use the same example, but change FortiGate from feasible path mode to strict mode, you will get the
following results:
• The packet from 172.16.1.1 to 10.1.0.1 is still blocked because there is no route to the source IP
address through port3.
• The packet from 10.4.0.1 to 10.1.0.1 is also blocked. There is an active route to 10.4.0.1 through port2,
but it is not the best route to the source IP address. The best route to 10.4.0.1 is through port3. So,
strict mode accepts traffic from the subnet 10.4.0.0/24 only when port3 is the incoming interface.

© FORTINET
Content inspection requires symmetric routing; that is, traffic must follow the same path both ways. So,
FortiGate routes traffic symmetrically. This means that, under some network topologies, FortiGate might
not route the return traffic through the best path, but through the same path that the originating traffic used.
For that purpose, FortiGate remembers the interface to source and uses that interface to route the return
packets, even when a better route using a different interface exists. Let’s take a look at an example in the
next slides.

© FORTINET
Let’s analyze this network topology. The local network 10.1.0.0/24 has three network devices: a local
workstation, a local router, and a FortiGate (port1). Also, the FortiGate port2 is directly connected to the
local router (using the subnet 10.2.0.0/24). There is a remote router connected to FortiGate port3 and,
behind that, a remote server (10.4.0.1). So, any traffic destined to the remote server must be routed
through the FortiGate. One important detail in this network is that the local workstation default gateway is
10.1.0.254. This means that if you send a ICMP echo request from the local workstation to the remote
server, the packet goes to the local router first, then to the FortiGate, then to the remote router, and finally
to the destination. When the ICMP packet arrives to the FortiGate, an entry for the originating traffic is
created in the unit route cache. This entry contains the interface to source, or the incoming interface where
the packet arrived, which in this case, is port2.

© FORTINET
Additionally, FortiGate creates an entry in the session table. This entry also contains information about the
interface to source.
As explained earlier, FortiGate does a first routing lookup to find the next-hop to the destination. That IP
address is also stored in the session information.
As there is not an ICMP echo reply yet, you will notice that the next-hop to source is still undetermined (it
is 0.0.0.0). It will be determined with the second routing lookup that happens with the first reply packet.

© FORTINET
Now, let’s take a look at how FortiGate routes the return packet.
When the FortiGate receives the ICMP echo reply, because there is already a session and a route cache
created, it uses the interface to source. So, in this case the unit routes the packet through port2 towards
the local router, even when there is a better route to the destination 10.1.0.1. The FortiGate routing table
shows port1 as the best route to 10.1.0.1 (locally connected), but it still uses port2. The objective is to keep
the traffic flow symmetric. With the first ICMP echo reply, a second entry is added to the route cache, this
time for the return traffic.

© FORTINET
Additionally, the unit does a second routing lookup, this time to find the next-hop (or gateway) to the
source. That IP address is added to the session (where 0.0.0.0 was before).

© FORTINET
What happens if the traffic originates from the server side instead? Let’s say that the ping is sent from the
remote server to the local workstation.
In this case, when the ICMP echo request arrives at the FortiGate, there is no session yet. So, the unit
uses the best route to 10.1.0.1, which is through port1.
This example shows how a FortiGate might, in some network topologies, route packets to the same
destination differently, depending on who initiated the session.

© FORTINET
Let’s take a look at the reply traffic in this example. Because the local workstation default gateway is
10.1.0.254, the ICMP echo reply goes to the local router first. Then, the packet arrives at FortiGate port2.
The result is asymmetric routing: the return traffic is following a different path than the originating traffic.
The return packet is arriving at port2 instead of port1 (where the originating traffic was sent). In these
cases, the FortiGate accepts this asymmetry, no packets are dropped, and UTM inspection is not affected.

© FORTINET
When FortiGate is not applying source NAT (SNAT), after a change in the routing table, the routing
information is removed from the sessions that are affected by the change. Additionally, related route cache
entries are deleted.
So, two more routing lookups are done for the next packets, in order to learn the new routing information,
and store it in the routing table. Also, RFP check is done again for the first packet in the original direction.
This slide shows a sample of a session just after a routing change. The gateways in both directions
change to 0.0.0.0/0 and the interfaces to 0, indicating that this information must be learned again.
Additionally, the dirty flag is added.

© FORTINET
In sessions where SNAT is applied, the action that FortiGate takes after a routing change depends on the
snat-route-change setting. When this setting is enabled, the action is the same as it is for sessions
without SNAT:
• Routing information is flushed from the session table
• Route cache entries are removed
• Routing lookups are done again for the next packets. This can potentially change the outbound
interface being used to route the traffic
• RPF check is done again for the first packet in the original direction

© FORTINET
When the snat-route-change setting is disabled, the behavior that occurs after a routing change is
different for sessions using SNAT. Sessions using SNAT keep using the same outbound interface, as long
as the old route is still active.
In the example shown in this slide, the FortiGate is connected to two different ISPs. A client with the IP
address 10.1.0.1/24 is connected behind a FortiGate. The FortiGate is doing SNAT of the client traffic to a
public IP address, depending on which ISP is using it. The FortiGate routing table contains two default
routes; one for each ISP. The two default routes are the same distance, but have different priorities. The
route with the lowest priority (port1) is the primary. When both ISP connections are up, the primary route is
selected by FortiGate for Internet traffic. So, all sessions to the Internet are created using port1 as the
outbound interface.

© FORTINET
If the administrator increases the priority for port1 to a value higher than port2, and if snat-route-
change is disabled, all new sessions start using port2, because it has the lowest priority. However, all the
existing sessions continue to use port1. The default route is through port1. Even though the default route is
no longer the best route, it is still active and FortiGate is doing SNAT. The existing sessions will continue
to use the old route until they expire. If FortiGate wasn’t doing SNAT, all the existing sessions would switch
to port2 after the change.

© FORTINET
The command get router info routing-table all displays all the active routes in the routing
table. The left column indicates the source for the route. The first number inside the square brackets is the
distance, and the second number is the metric.
This command doesn't show inactive routes. For example, if you had two static routes to the same
destination subnet with different distances, the one with the shorter distance would be active, and the one
with the longer distance would be inactive. If you entered this command, it would display only the active
route.

© FORTINET
If you want to display both the active and the inactive routes, use the command get router info
routing-table database. In the example shown in this slide, the get router info routing-
table database command shows one inactive route. The route is inactive because it has a longer
distance.

© FORTINET
This low-level command shows the forward information database (FIB), which is the routing information
that the kernel uses to route traffic. All active routes in the routing table must be also present in the FIB.
Additionally, the FIB may contain routes that are not in the routing table, but were automatically added by
the FortiGate, such as routes that are dynamically added to reach SSL VPN users.

© FORTINET
The route cache contains recently used routing entries in a fast-to-search table. It is consulted before the
routing table to speed up the routing lookup process.

© FORTINET
In this section, you will learn about Internet services.

© FORTINET
The Internet Services Database contains the list of IP addresses, IP protocols, and port numbers used by
the most common Internet services, such as Netflix, Dropbox, and Facebook. FortiGate periodically
downloads the newest version of this database from FortiGuard. FortiGate uses the information in this
database to route traffic to those common Internet services though specific WAN interfaces.

© FORTINET
You can use Internet services as the destination of a static route. In this example, we are configuring the
FortiGate to route all the Adobe FTP traffic through interface port1.
Static routes that you create using Internet services are not added to the routing table. The routes that you
create this way are added as policy routes. Also, you can display these policy routes only by using the
command diagnose firewall proute list. The GUI does not show these policy routes. This slide
shows the partial output of the policy route created when adding a static route for the Adobe FTP services.
Note that static routes that you create using subnets or named addresses as the destination are added to
the routing table.

© FORTINET
To list the Internet services in the database, use the command get application internet-service
status. Each service has a unique ID number, which is used in the command diagnose internet-
service id-summary, to get summarized information about the port numbers and number of IP ranges
associated with the service.

© FORTINET
To get all the details about an Internet service, use the command diagnose internet-service id. It
displays each and all the IP address ranges, together with the port and IP protocol numbers.

© FORTINET
The diagnose internet-service info command checks if a tuple IP address, IP protocol, and port
number are associated with a well-known Internet service. In the example shown in this slide, we ran the
command in the root VDOM to check the IP address 217.89.105.154, IP protocol 6 (TCP), and port
number 443. The output indicates that the tuple is associated with Google Mail. The following values must
match to perform a reverse lookup: VDOM, protocol, port number, and an IP address. Otherwise, you will
receive this error: Cannot find application id and name. ret=-1.

© FORTINET
In this section, you will learn about WAN link load balancing.

© FORTINET
WAN link load balancing consists of a group of interfaces connected to multiple ISPs. Once created,
FortiGate sees all those Internet interfaces as a single logical interface: the WAN load balancing interface.
This simplifies the configuration because the administrator can configure a single set of routes and firewall
policies that are applied to all ISPs. There can be only one WAN load balancing interface for each VDOM.

© FORTINET
You can configure FortiGate to check the status (health) of each interface member. If you configure a
detect protocol, a detect server IP address, and a failure threshold, the FortiGate will periodically send IP
packets to the detect server through each interface member. If the number of consecutive packets that
receive no reply for one member goes above the threshold, that member is removed from WAN link load
balancing.
WAN link load balancing status checks also measure the quality of the links connected to each member.
There are three different criteria that you can use to measure quality: latency, jitter, or packet loss
percentage. You can use priority rules to route traffic based on the link quality of each member.

© FORTINET
Once WAN link load balancing is enabled, FortiGate starts balancing traffic among all the interface
members based on the load balancing method that you select. Priority rules allow you to be more specific
about what traffic you want to route through which interface member. You can use priority rules to route
traffic through specific interface members, or through the interface with the highest link quality. Remember,
status checks are used to measure link quality based on latency, jitter, or packet loss percentage.
The priority rules are evaluated in the same way as the firewall policies: from top to bottom, using the first
match. The following parameters can be used to match the traffic:
• Source IP address
• Destination IP address
• Destination port number
• Internet service
• Users and/or user groups
• Type of service (ToS)

© FORTINET
Similar to static routes with Internet services as a destination, the priority rules are added as policy routes
that can be displayed only from the CLI using the command diagnose firewall proute list.
In this example, we have added a rule to route traffic to Google DNS through the interface member port1.
This slide shows the partial output of the added policy route.

© FORTINET
Two debug commands display the state and measured link quality of each interface member. The
command at the bottom can also be used to find the member ID number of each interface member.

© FORTINET
The command diagnose sys link-monitor vwl-status displays some information about the
priority rules, such as the mode.
The auto mode indicates that the route is selected based on link quality. For those rules using auto
mode, the command displays all the members ordered by link quality. The link with the best quality is listed
first.
The manual mode indicates that the FortiGate uses the interface statically configured in the priority rule.
The command also displays the ID numbers of the policy routes added by the priority rules.

© FORTINET
In this lesson, you learned about the following topics:

• Routing table lookup
• The route selection process
• Reverse path forwarding check
• Return packet forwarding
• Routing changes and existing sessions
• General debug commands
• Internet services
• WAN link load balancing troubleshooting

© FORTINET
Now you will work on Lab 5–Routing.

© FORTINET
In this lab, you will use routing debug information on the FortiGate to troubleshoot routing problems.

DO NOT REPRINT  FortiGuard
© FORTINET
In this lesson you will learn about FortiGuard. You will learn how to troubleshoot problems that occur when
FortiGate is connecting to public FortiGuard services, and when FortiManager is acting as a local
FortiGuard server.

© FORTINET
• Monitor the status of the FortiGuard updates
• Use FortiManager as a local FortiGuard server
• Troubleshoot common FortiGuard issues

© FORTINET
In this section, you will learn how FortiGate connects to public FortiGuard servers.

© FORTINET
The FortiGuard Distribution Network (FDN) provides FortiGuard services for your FortiManager system, as
well as its managed FortiGate devices and FortiClient agents. It provides updates and rating services for:
• Antivirus
• IPS
• Web filtering
• Antispam
• Application control
• Vulnerability scanning
• IP reputation
• Web security
• Database security
• Geographic IP addresses

© FORTINET
To learn how to troubleshoot FortiGuard problems, you need to understand how FortiGuard
communication works. The communication between FortiGate and FortiGuard for web filtering and
antispam is different than the communication for antivirus and IPS. Let's look at how FortiGuard web
filtering and antispam work first:
1. FortiGate contacts the DNS server to resolve the name service.fortiguard.net.
2. FortiGate gets a list of IP addresses for servers (usually two or three) that can be contacted to validate
the FortiGuard license.
3. FortiGate contacts one of those servers to check the license, and obtains a list of servers that can be
used to submit web filtering and antispam rating queries.
4. FortiGate gets the list of servers.
5. FortiGate starts sending rating queries to one of the servers in the list. (You will learn how FortiGate
chooses the server later in this lesson.)
6. If the chosen server does not reply in two seconds, FortiGate contacts the next server in the list.

© FORTINET
Now let’s look at how antivirus and IPS work. How FortiGuard communication works for antivirus and IPS
depends on the method used: pull or push.
The steps used for the pull method are:
1. FortiGate contacts the DNS server to resolve the name update.fortiguard.net.
2. FortiGate gets a list of server IP addresses (usually two or three) that can be contacted.
3. FortiGate periodically connects to one of the servers to check for pending updates.
4. If there is an update, FortiGate downloads the update.
The first two steps used for the push method are also used for the pull method: FortiGate gets a list of IP
addresses from a DNS server for the domain name update.fortiguard.net. After that, FortiGate registers its
public IP address in FortiGuard. With this information, FortiGuard starts sending notifications each time
there are new updates. FortiGate then proceeds to download them.

© FORTINET
You can check the status of FortiGuard licenses and the communication to FortiGuard from the FortiGate
GUI. You can also check the versions of the locally installed databases for each of the FortiGuard
services.

© FORTINET
The command diagnose debug rating shows the list of servers for web filtering and antispam
queries. For each IP address, the table shows:
• The round trip delay
• The server's time zone
• The number of recent and consecutive queries without reply
• The historical total number of queries without reply

© FORTINET
This is how FortiGate selects the server to send the rating requests to.
• FortiGate initially uses the delta between the server's time zone and the FortiGate's system time zone
multiplied by 10. This is the server initial weight
• The weight goes up with each packet lost
• The weight goes down over time if there are no packets lost; however, it never goes below the initial
value
• FortiGate uses the server with the lowest weight as the one for the rating queries

© FORTINET
The output of the command diagnose debug rating shows flags beside some of the servers:
• I = The server initially contacted to validate the license and get the server list. Usually, there is only
one server with this flag.
• D = The IP address FortiGate got when resolving the name service.fortiguard.net. If the administrator
has not overwritten the FortiGuard FQDN or IP address in the FortiGate configuration, there are usually
two or three servers with this flag.
• S = The IP address FortiGate got from a FortiManager
• T = The server is not replying to FortiGate queries
• F = The server is down

© FORTINET
In many cases, problems related to FortiGuard are caused by ISPs. Some ISPs block traffic in port 53 that
is not DNS or that contains large packets. In those cases, the solution is to switch FortiGuard traffic from
port 53 to port 8888.
Other ISPs (or upstream firewalls) block traffic to port 8888. In those cases the solution is to use port 53.
There are also a few cases where ISPs block traffic based on source ports. Changing the source port
range for FortiGuard to the range shown in this slide usually fixes the issue.

© FORTINET
For antivirus and IPS, communication between FortiGate and FortiGuard happens much less frequently. In
the case of web filtering and antispam, FortiGate goes to FortiGuard each time it needs to rate a web site
or email (if the information is not in the FortiGate cache). In the case of the pull method for antivirus and
IPS, FortiGate goes to FortiGuard usually once a day to check and download any new version of the
antivirus or IPS databases and engines. This is done using port TCP 443.
This slide shows the commands you use if FortiGate must connect through a web proxy. Usually, clients
connecting to a web proxy do not contact the DNS server to resolve names, as it is the web proxy that
does it. But, in the case of FortiGuard, FortiGate always requires DNS access, even when connecting
through a web proxy.

© FORTINET
The command diagnose test application dnsproxy 7 displays the FQDN and IP addresses of
the FortiGuard servers available for antivirus and IPS updates.
The command diagnose autoupdate status provides a summary of the FortiGuard configuration in
the FortiGate.

© FORTINET
The command diagnose autoupdate versions lists all the FortiGuard databases and engines
installed. The information includes the version, contract expiration date, time it was updated, and what
happened during last update.

© FORTINET
If there are problems updating the antivius or the IPS, or if there are problems validating the license, you
can use the FortiGuard real time debug:
diagnose debug application update -1
diagnose debug enable
After enabling debug, you can force a manual update from the CLI using this command:
execute update-now

© FORTINET
Remember that FortiGuard traffic originates always from the management VDOM. So, the management
VDOM (which is root by default) must have Internet access.
Proper DNS access from the management VDOM is also important. The FortiGate must be able to resolve
the names:
update.fortiguard.net
service.fortiguard.net
Also, keep in mind that, although it usually takes one or two hours to update a contract in all the server, it
could take up to 24 hours in some cases. So, if you have just changed or renewed your FortiGuard
contract and you do not see the change in the FortiGate, most probably you just need to wait a bit more, to
give FortiGuard time to synchronize the information in all the servers.

© FORTINET
In this section, you will learn about FortiManager acting as a local FortiGuard distribution server (FDS.)

© FORTINET
FortiManager can function as a local FDS. It continuously connects to public FDS servers to obtain
managed device license information and check for firmware availability updates.
All FortiManager devices can provide antivirus, IPS, vulnerability scanning, and signature updates to
supported devices. FortiManager devices can also provide web filtering and antispam rating services.
You need to configure the service access settings for each interface from System Settings > Network
on FortiManager. FortiManager supports requests from registered (managed) devices and unregistered
(unmanaged) devices. After you enable the FortiManager’s built-in FDS, you can configure FortiGate
devices to use FortiManager FortiGuard services.

© FORTINET
Let's take a look at what is required on FortiGate in order to use FortiManager for FortiGuard services.
You need to configure the server-list. This is where you define the server-address, which is the
IP of FortiManager. You can also define the following options in the server-type setting:
• rating — Web filtering, antispam, and so on
• update — Antivirus, IPS, and so on
By default, include-default-servers is enabled. This allows the FortiGate to communicate with
the public FortiGuard servers, if the FortiManager devices (configured in server-list) are
unavailable. If it is disabled, FortiGate units will never go to the public FDSs, even when the
FortiManagers are down.

© FORTINET
This GUI section, and related CLI command, show the status of FortiGuard licenses for all FortiGates.

© FORTINET
The antivirus and IPS signature packages are managed in FortiGuard > Package Management.
Packages received from FortiGuard are listed under Receive Status. It displays the package received;
version; size; version to be deployed; and update history for FortiGate, FortiMail, FortiAnalyzer, and
FortiClient.
Click Update History to open the update history page for a package. It shows the update times, the
events that occurred, the status of the updates, and the versions downloaded.
You can change the version of the package that will be deployed by selecting Change in the To Be
Deployed Version column.

© FORTINET
Click Package Management > Service Status to see a list of all the managed FortiGate devices, their
last update time, and their status.
There are five possible statuses:
• Up to Date: The latest package has been received by the FortiGate device
• Never Updated: The device has never requested or received the package
• Pending: The FortiGate device has an older version of the package due to an acceptable reason
(such as a pending scheduled update)
• Problem: The FortiGate device missed the scheduled query, or did not correctly receive the latest
package
• Unknown: The FortiGate device’s status is not currently known

© FORTINET
This command shows details about which updates were installed or will be installed on devices managed
by FortiManager (displayed by S/N).

© FORTINET
FortiManager can log update services events. They are useful for troubleshooting. Set the logging level to
debug first. The next slide shows the command you must use to display the logs. Alternatively, you can
export the logs to an SFTP or FTP server.

© FORTINET
The update services logs display the FortiGate requests made to FortiManager and the FortiManager
requests made to the public FortiGuard servers.

© FORTINET
The web filtering and antispam databases are managed in FortiGuard Management > Query Server
Management. The databases received from FortiGuard are listed under Receive Status. This page
displays the date and time when updates were received from the server, the update version, the size of
the update, and the update history.
Select Update History to open the update history page for a package. It shows the update times, the
events that occurred, the status of the updates, the version number, and size of the download.

© FORTINET
You can view statistics about rating requests made by FortiGate to FortiManager using the command
diagnose fmupdate fgd-wfas-rate. By default, this command displays the request rates for the last
60 minutes. However, the time period can be changed using the command shown in this slide. This
information is also periodically logged in the event log.

© FORTINET
FortiManager can log rating services events in the same way that it logs update services events. For troubleshooting,
it is recommended that you enable the debug level first.

© FORTINET
You can use the steps shown in this slide to reinitialize the web filtering and antispam databases and
services.

© FORTINET
These are other debug commands available in FortiManager to troubleshoot FortiGuard-related

problems:
• diagnose fmupdate vm-license: Lists FortiGate VM license information.
• diagnose fmupdate getdevice [fct|fds|fgd|fgc]: Lists the latest package
information download by the FortiGate/FortiClient through FortiManager
• diagnose fmupdate service-restart [fct|fds|fgd|fgc]: Restarts the linkd service
for fct, fds, fgd, and fgc
• diagnose fmupdate fds-get-downstream-device <serialnum>: Gets information of all
downstream FortiGate antivirus-IPS devices. Optionally, enter the device serial number
• diagnose fmupdate fds-getobject: Lists downloaded antivirus, IPS, and vulnerability
scanner packages
• diagnose fmupdate fds-update-info: Displays the FDS update info
• diagnose fmupdate fgd-dbver: Gets the version of the database
• diagnose fmupdate fgd-get-downstream-device: Gets information on all downstream
FortiGate web filter and spam devices.
• diagnose fmupdate fgd-url-rating: Rates a URL

© FORTINET
In this lesson you learned about the following topics:

• FortiGuard services
• Verifying the FortiGuard connectivity status
• Monitoring the status of FortiGuard updates versions
• Real time debug commands
• FortiManager troubleshooting commands
• How to troubleshoot common FortiGuard issues

© FORTINET
Now you will work on Lab 6–FortiGuard.

© FORTINET
In this lab you will troubleshoot FortiGuard issues on the DCFW, and rating lookup issues on the ISFW.

DO NOT REPRINT  Central Management
© FORTINET
In this lesson, you will learn about using FortiManager for the central administration of all the FortiGate
devices in an enterprise network.

© FORTINET
• Review FortiManager key features
• Use FortiManager to centralize the management of the enterprise network
• Use scripts to execute individualized configuration changes to FortiGates

© FORTINET
Let’s review FortiManager key features.

© FORTINET
When should you use FortiManager in your network?

In large enterprises and managed security service providers (MSSPs), the size of the network introduces
challenges that smaller networks don’t have: doing mass provisioning; scheduling the rollout of
configuration changes; and maintaining, tracking, and auditing many changes.
Centralized management through FortiManager can help you easily manage many deployment types with
many devices, and reduce the cost of operation.
You can use FortiManager to do the following:
• Provision firewall policies across your network
• Act as a central repository for configuration revision control and security audits
• Deploy and manage complex mesh and star IPsec VPNs
• Act as a private FortiGuard distribution server (FDS) for your managed devices and FortiClient
installations
• Script (CLI and TCL) and automate device provisioning, policy changes, and more with JSON APIs

© FORTINET
FortiManager can help you to better organize and manage your network. Key features include:
• Centralized management: Instead of logging into hundreds of FortiGates individually, you can use
FortiManager to manage them all from a single console.
• Administrative domains (ADOMs): FortiManager can group devices into geographic or functional
ADOMs, ideal if you have a large team of network security administrators.
• Configuration revision control: Your FortiManager keeps a history of all configuration changes. You can
schedule FortiManager to deploy a new configuration or revert managed devices to a previous
configuration.
• Local FortiGuard service provisioning: To reduce network delays and minimize Internet bandwidth
usage, your managed devices can use FortiManager as a private FortiGuard Distribution Network
(FDN) server.
• Firmware management: FortiManager can schedule firmware upgrades for the managed devices.
• Scripting: FortiManager supports CLI- and TCL-based scripts for configuration deployments.
• Pane management (VPN, FortiAP, and FortiClient): FortiManager management panes simplify the
deployment and administration of VPN, FortiAP, and FortiClient.
• Logging and reporting: Managed devices can store logs on FortiManager. From that log data, you can
generate SQL-based reports, because FortiManager has many of the same logging and reporting
features as FortiAnalyzer.
• Pay-as-you-go licensing: Fortinet VMs are now available through the Fortinet VM On-Demand program.

© FORTINET
Let’s take a look at FortiManager software architecture.

© FORTINET
Inside FortiManager, there are management layers that are represented as panes in the GUI. The device
management layer, for example, is represented by the Device Manager pane, which performs revision
history and scripting.
Let’s look at the management layers in further detail.

© FORTINET
To organize and efficiently manage a large scale network, FortiManager has multiple management layers.
• The Global ADOM layer has two key pieces: the global object database and header and footer policy
packages. Header and footer policy packages envelop each ADOM’s policies. An example of where
policy packages are used is in a carrier environment, where the carrier allows customer traffic to pass
through their network, but does not allow the customer to have access to the carrier’s network
infrastructure.
• The ADOM layer is where policy packages are created, managed, and installed on managed devices or
device groups. Multiple policy packages can be created here. The ADOM layer includes one common
object database for each ADOM. The common object database contains information such as
addresses, services, and security profiles.
• The Device Manager layer records information on devices that are centrally managed by the
FortiManager device, such as the name of the device, type of device, model, IP address, current
firmware installed, revision history, and real-time status.

© FORTINET
Understanding the layers of FortiManager’s management model is important.
• In the Global ADOM layer, you create header and footer policy rules. These policy rules can be
assigned to multiple ADOMs. If multiple ADOM policy packages require the same policies and objects,
you can create them in this layer so that you don’t have to maintain copies in each ADOM.
• In the ADOM layer, objects and policy packages in each ADOM share a common object database. You
can create, import from, and install policy packages on many managed devices at once.
• In the Device Manager layer, you can configure and install device settings for each device. If a
configuration change is detected—made locally or on FortiManager—FortiManager compares the
current configuration to the changed configuration, and creates a new configuration revision on
FortiManager. Whether the configuration change is big or small, FortiManager records it and saves the
new configuration. This can help administrators to audit configuration changes, and to revert to a
previous revision, if required.

© FORTINET
What is an ADOM?
Administrative domains (ADOMs) enable the admin administrator to create groupings of devices for
administrators to monitor and manage. For example, administrators can manage devices specific to their
geographic location or business division. ADOMs are not enabled by default and must be enabled by the
administrator.
The purpose of ADOMs is to divide the administration of devices, by grouping them based on management
criteria, and to control (restrict) administrative access. Administrative access is assigned based on an
administrator profile that allows access to one or multiple ADOMs on the device. If virtual domains
(VDOMs) are used, ADOMs can further restrict access to data from only a specific device’s VDOM. The
number of available ADOMs varies based on model.

© FORTINET
The Device Manager pane provides device and installation wizards to aid you in various administrative
and maintenance tasks. Using these wizards can decrease the amount of time it takes to do many
common tasks.
There are four main wizards in the Device Manager pane:
• Add Device is used to add devices to central management and import their configurations.
• Install Wizard is used to install configuration changes from the Device Manager pane or Policies &
Objects pane to the managed devices. It allows you to preview the changes and, if the administrator
doesn’t agree with the changes, cancel and modify them.
• Import Policy is used to import interface mapping, policy database, and objects associated with the
managed devices into a policy package under the Policy & Object pane. It runs with the Add Device
wizard, by default, and may be run at any time from the managed device list.
• Re-install Policy is used to perform a quick install of the policy package. It provides the ability to
preview the changes that will be installed to the managed device.
You can open the Import policy and Re-install Policy wizards by right-clicking your managed device in
the Device Manager.

© FORTINET
Let’s take a look at the scripting options that are available on FortiManager.

© FORTINET
A script can make many changes to a managed device and is useful for bulk configuration changes and
consistency across multiple managed devices.
FortiManager supports two types of scripts: CLI scripts and TCL scripts.
CLI scripts include only FortiOS CLI commands as they are entered at the command line prompt on a
FortiGate device.
TCL is a dynamic scripting language that extends the functionality of CLI scripting. In FortiManager TCL
scripts, the first line of the script is #!. This is standard TCL scripts. Do not include the exit command that
normally ends TCL scripts because it will prevent the script from running. You need to be familiar with the
TCL language and regular expressions. For more information on TCL scripts, please refer to the official
TCL website: http://www.tcl.tk
In FortiManager’s GUI, scripts are enabled under Admin Settings and configured from the Device
Manager. For TCL scripts, you also need to enable show command for TCL scripts from the FortiManager
CLI.
CLI scripts can be run in three different ways:
• Device Database: By default, a script is executed on the device database. It is recommend you run the
changes on the device database (default setting), as this allows you to check what configuration
changes you will send to the managed device. Once scripts are run on the device database, you can
install these changes to a managed device using the installation wizard.
• Policy Package, ADOM database: If a script contains changes related to ADOM level objects and
policies, you can change the default selection to run on Policy Package, ADOM database and can then
be installed using the installation wizard.
• Remote FortiGate directly (through CLI): A script can be executed directly on the device and you don’t
need to install these changes using the installation wizard. As the changes are directly installed on the
managed device, no option is provided to verify and check the configuration changes through
FortiManager prior to executing it.

© FORTINET
This is how you can execute a CLI command from a TCL script. Any TCL script must start with #!.
The next line, exec TCL, executes the CLI command get system status.
The CLI command executes only if the TCL interpreter gets the # from the FortiGate command prompt
within 10 seconds. If that is not the case, the CLI command is not executed, and the script generates an
error.
The output of the CLI command is saved to the FortiManager script history log using the TCL command
puts.

© FORTINET
This slide shows an example of using TCL variables.
The TCL set command creates a new variable (newhostname) and sets its value to NGFW.
The value of the variable is then used (prepending the $ sign) to configure the FortiGate hostname.

© FORTINET
If you are executing a command, or a group of commands, multiple times in a script, you can add those
commands to a TCL procedure for simplification. You can pass one or more parameters to a TCL
procedure.
In this example, we are creating a TCL procedure called do_cmd. This procedure instructs the interpreter
to execute a CLI command (received through the parameter cmd) if the # is received within 10 seconds.
After that, the script calls that procedure five times (each time passing a different parameter) to configure
the IP address in port1.

© FORTINET
This is a more complex TCL example that shows the power of TCL scripts. Let's say that you have 150
hosts in your network and you need to create 150 different firewall addresses; one for each of your hosts.
This TCL script uses a loop to do that.
The script uses two variables. The variable numhosts contains the number of addresses to create. The
variable i starts with the value 1 and is incremented after each loop. The loop is executed a number of
times equal to the variable numhosts.
Inside each loop, the variable i is used to set the name of the firewall address and its IP address. What is
actually executed in the FortiGate are the following CLI commands:
config firewall address

edit host-1
set subnet 10.0.1.1/32
next
edit host-2
set subnet 10.0.1.2/32
next
...
...
edit host-150
set subnet 10.0.1.150/32
next
end

© FORTINET
When creating CLI scripts, follow these best practices:

• Use complete FortiOS CLI commands. Partial syntax can be used; however, it may cause the script to
fail.
• Comment lines that start with the number sign (#) will not execute.
• In the FortiGate CLI, ensure the console output is set to standard. Otherwise, scripts and other output
longer than a screen in length will not execute or display correctly.

© FORTINET
In this lesson, we reviewed FortiManager key features, FortiManager architecture, scripts, and
FortiManager wizards.

© FORTINET
You will now work on Lab 7–Central Management.

© FORTINET
In this lab, you will configure the FortiGate units and FortiManager to centralize the management of the
enterprise network.

DO NOT REPRINT  OSPF
© FORTINET
In this lesson, you will review some OSPF concepts, learn to configure OSPF, and troubleshoot OSPF
problems.

© FORTINET
• Understand OSPF components
• Describe the link state advertisement types
• Determine the OSPF cost for any route
• Establish OSPF adjacencies
• Differentiate between designated router and backup designated router in a multiaccess network
• Troubleshoot common OSPF problems
• Monitor the status of an OSPF network
• Segment an OSPF network into areas

© FORTINET
First, let’s review OSPF.

© FORTINET
In a link state protocol like OSPF, every router has a complete view of the network topology. Advantages
of OSPF include scalability and fast convergence. Every 30 minutes, routers readvertise their OSPF
information. Between those 30-minute intervals, updates are sent when a topology change is detected. So,
it is a relatively quiet protocol as long as the network topology is stable. In large networks, using OSPF
requires good planning and it may be difficult to troubleshoot.

© FORTINET
Each router in the same area, has identical and synchronized databases. You will learn about OSPF areas
later in this lesson. An OSPF router uses the information in the LSDB and the Dijkstra's algorithm to
generate an OSPF tree, which contains the shortest path from the local router to each other router and
network. This tree gives the best route to each destination, which is the information that OSPF can inject in
to the device's routing table.

© FORTINET
The topology information interchanged by OSPF peers is contained in LSAs. A router's Link State
Database (LSDB) is populated with the information from the local LSAs and all the LSAs received from
other routers.

© FORTINET
If there are multiple OSPF routes to the same destination subnet, OSPF selects the route with the lowest
cost. Each router interface is associated with an interface cost, which is usually related with how fast or
preferable that interface is. An OSPF route cost is the sum of all interfaces' costs to the final destination.

© FORTINET
The next two slides explain how an OSPF router builds its OSPF tree. The initial information for each
router is the locally connected networks, together with the OSPF cost for each interface. In this example,
the router R2 has three locally connected subnets: subnet Net 1 with a cost of 2, subnet Net 2 with a cost
of 3, and subnet Net 3 with a cost of 1. Router R1 has only one subnet connected: Net 1 with a cost of 2,
and so on.
Each router starts advertising its locally connected subnets by sending LSAs.

© FORTINET
OSPF routers use Dijkstra’s algorithm to determine the best route to each destination. The best routes can
be represented as a tree with the local router at the root. Dijkstra’s algorithm is a recursive process that is
repeated multiple times until the best routes are found. For example, this slide shows the OSPF tree for
router R2. It indicates that the best route to Net 5 and Net 4 is through R3, and that Net 1, Net 2, and Net 3
are locally connected.

© FORTINET
An OSPF network can be segmented into areas. Each area is identified by a unique number, which can be
represented either in decimal or IP address format.

© FORTINET
Each area has its own separated LSDB. All routers in the same area maintain an identical copy of the
area's LSDB. As we will see later, a router can belong to more than one area. In those cases, the router
maintains multiple LSDBs, one LSDB for each area connected to it.
Segmenting big OSPF networks into areas reduces the sizes of the LSDB tables. Additionally, a topology
change does not impact the whole network, but only the area where the change happens.
Using OSPF areas requires good planning and may complicate the troubleshooting process.

© FORTINET
All OSPF networks must have at least one area, the backbone area. The backbone is the core of the
network, and all the other areas connected to it in a hub-and-spoke topology.

© FORTINET
An internal OSPF router has all its interfaces connected to the same area. So, it maintains only one LSDB.
On the other hand, an area border router is connected to multiple areas, so it keeps multiple LSDBs.
A backbone router has at least one interface connected to the backbone area.
An ASBR redistributes non-OSPF routes into the OSPF network.

© FORTINET
This slide shows an example of each router type.

© FORTINET
An OSPF session between two OSPF peers is called an adjacency. This slide shows the initial
interchange between two peers that are forming an adjacency. Any new adjacency goes through different
states: Init, 2-way, ExStart, Exchange, Loading, and Full. The Full state indicates that the adjacency has
successfully formed, and both routers have identical copies of the LSDB.

© FORTINET
This slide lists the requirements for two peers to form an OSPF adjacency. If any of the requirements are
not met, the adjacency fails and will not reach the full state.

© FORTINET
There are two types of OSPF networks. Point-to-point networks contain only two peers, one at each end of
a point-to-point link. Multi-access networks support two or more peers.
There are two subtypes of multi-access networks. Broadcast networks support multicasting. An example of
a broadcast multi-access network is an Ethernet network. Non-broadcast multi-access networks (NBMAs)
do not support multicasting. An example of an NBMA network is Frame Relay.

© FORTINET
In any multi-access network there is one designated router (DR) and one backup designated router (BDR).
The router with the highest priority is elected as the DR. If two or more routers are tied with the highest
priority, the router with the highest OSPF ID is elected.
The BDR monitors the DR status. If the DR fails, the BDR takes the DR role.
Other routers form adjacencies only with the DR and the BDR. The DR forwards the link state information
from one router to another. This simplifies the amount of adjacencies required in multi-access networks.

© FORTINET
This slide shows the multicast addresses used by OSPF in broadcast multi-access, and point-to-point
networks. Keep in mind that OSPF also uses unicast addresses for LSA retransmissions and database
description packets.

© FORTINET
There are 11 LSA types. This lesson covers the five most commonly used:
• Type 1 describes all the links connected to a router
• Type 2 describes all the routers (if more than one) in a multi-access network
• Type 3 describes the networks within an area (only generated by an ABR)
• Type 4 describes the path to reach an ASBR
• Type 5 describes the external destinations originated by an ASBR
We will see examples of each of these five types in the next slides.

© FORTINET
Type 1 describes the networks connected to a router. They are advertised by all the routers in an area.
Type 1 LSAs are not advertised outside the area where they originate.

© FORTINET
Type 2 LSAs are advertised only by DRs. In this example, the area has two multi-access networks, each of
them with one DR. The two DRs advertise type 2 LSAs, which contain information about the other routers
connected to their multi-access networks.

© FORTINET
Type 3 LSAs contain summarized link state information. They are advertised only by ABRs. In this
example, the ABR on the left sends type 3 LSAs to area 1. They contain link state information for the
summarized subnets in areas 0 and 2. This same ABR also sends type 3 LSAs to the backbone area, with
a summary of the subnets in area 1.
Something similar happens with the ABR on the right. It sends type 3 LSAs to area 2. They contain link
state information for the summarized subnets in areas 0 and 1. This same ABR also sends type 3 LSAs to
the backbone area, with a summary of the subnets in area 2.

© FORTINET
An ASBR advertises itself by sending type 1 LSAs. These LSAs have the E-bit on in the OSPF header. As
any other type 1, the LSAs with the E-bit are confined to the area where they originate. However, ABRs in
the same area send a type 4 LSA to the other areas with information about how to reach the ASBR. In this
example, an ASBR that is redistributing RIP routes into OSPF announces itself by sending type 1 LSAs to
the backbone area. The ABR receives that LSA and sends a type 4 LSA to the area 1.

© FORTINET
The last type of LSA covered in this lesson is type 5. Type 5 LSAs are sent only by the ASBRs and are not
confined to one area. They reach all the standard areas. They contain link state information for routes
redistributed to OSPF (also called external routes).
Note that all the area examples in this lesson are standard areas. There are also stub and Not So Stubby
Areas (NSSA) areas, which are not covered in this lesson. Type 5 LSAs are not advertised to stub or
NSSA areas.

© FORTINET
Each external route is assigned a metric. There are two types of external-route metrics. A type 1 metric is
the sum of the external cost plus the internal cost to reach the ASBR. A type 2 metric is only the external
cost (the internal cost is not considered). If there are two external routes to the same destination, one type
1 and one type 2, an OSPF router selects the type 1 over the type 2.

© FORTINET
This slide shows a basic FortiGate OSPF configuration. It has the list of areas, the list of OSPF networks,
and the OSPF router ID.

© FORTINET
Any FortiGate that is redistributing non-OSPF routes into OSPF is an ASBR.

© FORTINET
In this section, you will learn about tools and tips for troubleshooting OSPF problems.

© FORTINET
The output of get router info ospf status provides detailed information about the OSPF process.

© FORTINET
The output of the get router info ospf status command also shows information about each area
the router belongs to.

© FORTINET
For OSPF information about each interface, use the command get router info ospf interface. It
shows:
• Network type, in this case broadcast multi-access
• If it is a DR or a BDR
• DR and BDR IDs and IP addresses
• Number of adjacencies and traffic statistics

© FORTINET
This command shows a summary of the statuses of all the OSPF neighbors. For each neighbor, it displays
the adjacency state and if it is a DR, a BDR, or none of them (DROther). A dash is displayed after the
state, if the neighbor is in a point-to-point network.

© FORTINET
The command get router info ospf database brief provides a summary of all the LSDB
entries in the FortiGate, ordered by LSA types. It shows the type 1 LSAs (router link states) first, then type
2 (net link states).

© FORTINET
The command get router info ospf database self-originate lists the LSAs originated in the
local FortiGate.

© FORTINET
To get details about type-1 LSAs, use the command get router info ospf database router
lsa.

© FORTINET
This is a sample of more output from the command get router info ospf database router
lsa.

© FORTINET
The OSPF real time debug displays information about adjacency establishments and OSPF errors. It also
shows information about network topology changes.

© FORTINET
This is a sample of output generated by the OSPF real time debug. This sample shows the HELLO packet
being sent.

© FORTINET
This is another sample of output generated by the OSPF real time debug. This sample shows the HELLO
packet being received.

© FORTINET
By default, FortiGate logs the most important OSPF routing events, such as:
• Neighbor down or up
• OSPF message exchange
• Negotiation errors

© FORTINET
The routing logs can be displayed from Log & Report > Router Events. You can double click any log to
view the details.

© FORTINET

• OSPF components
• Cost and external route metric
• Area types
• OSPF router types
• Forming OSPF adjacencies
• Designated router (DR) and backup DR (BDR)
• Types of link state advertisements
• OSPF Configuration
• Troubleshooting OSPF issues
• OSPF logging

© FORTINET
Now you will work on Lab 8–OSPF.

© FORTINET
In this lab, you will configure FortiGate devices from FortiManager to use OSPF as the dynamic routing
protocol for the enterprise network. You will learn how to use OSPF diagnostics commands, and you will
use the debug commands available in FortiGate to troubleshoot an OSPF problem.

DO NOT REPRINT  Web Filtering
© FORTINET
In this lesson, you will learn about web filtering.

© FORTINET
This lesson covers:

• Test a web filter configuration
• Inspect HTTPS traffic using web filtering methods
• Check web filtering statistics
• Troubleshoot common web filtering issues

© FORTINET
Web filtering in FortiOS operates in one of three inspection modes: proxy, flow, or DNS. By default,
FortiGate caches the rating results it receives from FortiGuard. So, before it sends rating requests to
FortiGuard, FortiGate checks that the website category isn’t already in the local cache. You can configure
the time-to-live (TTL) of the entries in the web filtering cache.

© FORTINET
During web filtering inspection, FortiGate first checks the static URL filter list, then the FortiGuard
categories, and then the content filtering list. Finally, FortiGate can execute some advanced options, such
as manipulation of HTTP headers.

© FORTINET
FortiGate scans HTTPS sites using the SSL inspection profile settings. There are two SSL inspection
methods for web filtering.
The full SSL inspection method proxies the SSL session, allowing full content inspection of encrypted
traffic. FortiGate decrypts the traffic, inspects it, and re-encrypts it. This is known as man-in-the-middle
inspection.
During SSL certificate inspection, FortiGate doesn’t decrypt or inspect encrypted traffic. Using this method,
FortiGate inspects only the initial unencrypted portion of the SSL communication. If the SSL
communication includes the server name indication (SNI) field, FortiGate uses the server name contained
there to categorize the site. If the SNI isn’t present (because the browser might not support it), FortiGate
gets the server name from the Issued To field in the server digital certificate. Keep in mind, in some
cases, the server name in the Issued To field doesn’t match the name of the site. For example, the value
of the Issued To field in the digital certificate of youtube.com is google.com. So, if you connect to
youtube.com, from a browser that doesn’t support SNI, and FortiGate uses the SSL certificate inspection
method, FortiGate assumes incorrectly that you are connecting to google.com (and uses the
google.com category instead of the category for youtube.com.)

© FORTINET
An administrator can access the FortiGuard portal to check which category a URL belongs to. In the portal,
administrators can also request to reclassify a URL.

© FORTINET
You can use the FortiOS CLI to display the list of FortiGuard categories and their numerical values.
You can use FortiGuard category numbers when you create web profiles using the FortiOS CLI, or using
scripts on FortiManager. Similar to the using the GUI, you can configure different actions for each category
using the CLI.

© FORTINET
You can use category numbers to test whether a specific category or sub-category is allowed or blocked.
Use this URL format shown on this slide for that purpose.
In the example shown on this slide, the category number 65 is Tobacco. The test confirms that all sites
listed in this category will be blocked. The replacement message page displays the category that is
blocked, with other information, such as client IP, server IP, and user information.

© FORTINET
Two session flags indicate whether the traffic is inspected in proxy-based mode or flow-based mode. The
flag redir means the traffic is inspected in proxy-based mode. The flag ndr means the traffic is inspected
in flow-based mode. In the case of proxy-based inspection, the debug flow contains the message sent
to the application layer.

© FORTINET
Use the following CLI command to list error counters and other statistics related to web filtering:
diagnose webfilter fortiguard statistics list. A continual increase in some of the error
counters usually indicates communication problems with FortiGuard.

© FORTINET
The output also shows counters for the number of sites that were allowed, blocked, logged, monitored, and
so on.

© FORTINET
Use the same command to display counters for web filtering cache, including memory, requests, and hits
and misses.

© FORTINET
Use the diagnose test application urlfilter 1 command to display all options available for
the web filtering test command. You can use this command to troubleshoot issues related to web filtering.

© FORTINET
To list the content of the FortiGuard web filtering cache, use the command diagnose test
application urlfilter 3. For each URL, the output lists its rating by domain name and IP address.
The rating by domain name is the first two digits of the first number from left to right. It is the category ID
represented in hexadecimal. The rating by IP address is the first two digits of the second number. It is also
the category ID represented in hexadecimal.
The command get webfilter categories lists all the categories with their respective ID numbers. In
this list, the IDs are represented in decimal. So, if you want to find the category name for a URL in the
cache, use the first command to list the cache, and convert the ID number from hexadecimal to decimal.
Then, use the second command to find the category name for that ID number.

© FORTINET
Another tool you can use to troubleshoot web filtering is the web filter real-time debug. First, you can filter
by user (source) IP address using the following command:
diagnose debug urlfilter src-addr
After that, you can enable the real-time debug using the following command:
diagnose debug application urlfilter -1
This slide shows an example output of the real-time debug when the URL to categorize isn't in the
FortiGuard cache. The two messages display the URL, category, source, destination IP addresses, and
service.

© FORTINET
This slide shows another example of the real-time debug. But in this case, the URL category exists in the
FortiGuard cache.

© FORTINET
Tips for troubleshooting web filtering:

• Get the specifics first: What URLs are having the problem? Is it random? Does it happen with all the
users?
• Check the logs
• Is the problem caused by an incorrect user group configuration? Are the user access privileges correct?
• Run the real-time debug while reproducing the issue

© FORTINET
Additional tips:
• Check that web filtering isn't disabled globally
• If users are having intermittent issues, check that the communication with FortiGuard is stable (check
the web filtering statistics.) Check also that the unit is not entering into conserve mode

© FORTINET

• Order of inspection
• HTTPS inspection
• Testing web filtering
• Web filtering statistics
• Troubleshooting web filtering problems

© FORTINET
Now you will work on Lab 9–Web Filtering and Antivirus.

© FORTINET
In this lab, you will configure web filtering and antivirus from FortiManager. After that, you will test it by
generating traffic from a client behind the ISFW. Additionally, you will troubleshoot a web filtering and an
antivirus problem.

DO NOT REPRINT  IPS
© FORTINET
In this lesson, you will learn about IPS.

© FORTINET
After completing this lesson, you will have the skills and knowledge required to:
• Deploy IPS protection in an enterprise network
• Tune an IPS solution
• Accelerate IPS inspection using hardware offloading
• Troubleshoot IPS problems

© FORTINET
In this section, you will learn how to deploy and tune IPS inspection in an enterprise network.

© FORTINET
IPS uses signature databases to detect known attacks. You can also use IPS signatures to detect network
errors and anomalies.
Like the AV signature databases, the IPS signature databases are also updated through FortiGuard.

© FORTINET
There is no single correct way to deploy an IPS solution. It depends greatly on the network and application
requirements. However, in most cases, you will follow the steps shown on this slide.
There are usually three stages in the deployment of an IPS solution:

• Analysis: The administrator defines what to protect and where
• Evaluation: After an initial IPS configuration, the administrator makes further adjustments based on the
IPS logs. During this stage, you configure the IPS only to monitor traffic, not block it.
• Maintenance: After the IPS configuration is working correctly, the administrator sets IPS to protect. The
administrator must continue to monitor the logs, and make further adjustments if any false positives or
negatives occur.
You will learn more about each stage in this lesson.

© FORTINET
During the analysis stage, you must identify:

• What services to protect
• The threats to those services
• Where to enable IPS inspection
Set realistic expectations. Focus on protecting the services that need protection. Start with the most critical
services, and classify the threats into groups.

© FORTINET
During the evaluation stage, enable just one group of signatures at a time, starting with the more critical
ones. Wait and analyze the logs. If the logs indicate any problems, fine tune the IPS configuration. After
you feel comfortable with one signature group, enable IPS protection for the next group. This process can
take from one to two weeks.

© FORTINET
To minimize the number of false positives, make the list of signatures that you set to block small and
precise. The list should include the attacks that are most dangerous to critical services.
After you deploy the IPS solution, you must continue to monitor IPS events.

© FORTINET
When you check IPS events, start with the events that have been generated the most, or have high
priority.
For each event type, analyze the IP addresses, services, and type of attack. The analysis should help you
identify whether the event is a genuine attack or a false positive.

© FORTINET
Eliminate as many false positives as possible. For each false positive, try to fix the problem by making
changes in either the source or destination of the traffic first. You can also use IPS exemptions.

© FORTINET
In this section, you will learn about advanced IPS configuration settings.

© FORTINET
The global IPS configuration settings affect the IPS engine operations for the whole unit. Most of the time,
you don't need to modify these values because the default ones work well in most scenarios. However,
under certain circumstances, changes to these settings may be beneficial.

© FORTINET
The algorithm setting tells the IPS engine how to do signature matching.
There are four methods:
• engine-pick – IPS engine chooses the algorithm based on available memory and the type of
inspection being performed. This is the recommended option.
• low – Slower matching algorithm using less memory
• high – Faster matching algorithm using more memory. Recommended when IPS and application
control performance are the only focus of the FortiGate deployment.
• super – Fastest matching algorithm, designed for units with more than 4 GB of memory

© FORTINET
The engine-count setting controls the number of IPS engine processes running on FortiGate.
When it is set to the default (0), FortiGate determines the optimal number based on system load.
More IPS processes may result in better performance, but could risk overloading the system. Conversely,
reducing the number of IPS engine processes alleviates system resources, but reduces IPS performance.
You should tune this parameter if IPS is the only purpose for deploying FortiGate, and only after you
thoroughly test the setting change in a lab environment.

© FORTINET
The intelligent-mode command controls the adaptive scanning behavior of the IPS.
When you enable adaptive scanning, IPS determines when it is secure enough to stop scanning the traffic
in each session. When disabled, IPS scans every byte in every session.

© FORTINET
In this section, you will learn how to create custom signatures on FortiManager.

© FORTINET
There are two categories of Fortinet IPS signatures:

• Predefined signatures are developed by FortiGuard analysts, which are distributed as a part of regular
FortiGuard update packages
• Custom signatures are created by users for specialized applications

© FORTINET
A custom signature is made up of a type header, and a series of option and value pairs.
All custom signatures require a header of F-SBID. An option starts with "--", followed by the option
name, and, sometimes, a value. Some options don't require a value.
You must enclose the string of option and value pairs in parentheses. All fields are case insensitive.

© FORTINET
You can include multiple options in the rule by separating them with a semi-colon. The maximum length is
1024 bytes for custom signatures and 4096 bytes for predefined signatures.

© FORTINET
Now you’ll learn about supported option types. The options are divided into four categories based on their
purpose.
Basic options are not related to packet inspection. You use basic options to identify and control a
signature. These options will not be covered in this course.

© FORTINET
Use protocol-related options to match protocol headers.

© FORTINET
Use payload-related options to match portions of the packet payload.

© FORTINET
Use special options for various purposes for more granular filtering.

© FORTINET
If you are planning to create a custom signature, gather as many samples of the traffic as possible. Good
samples help you to identify patterns, for example, source ports, destination ports, specific string patterns
in the packet payload, and so on.
Try to match payload patterns in addition to protocol patterns, because payload patterns tend to be unique
to the specific traffic that you want to match. In this way, you might be able to reduce the number of false
positives for the custom signature.

© FORTINET
By default, the custom signature settings are hidden in FortiManager. After you enable them, a new tab
appears in the GUI: Security Profiles > IPS Custom Signature.

© FORTINET
Copy the custom signature and, in the Create New Custom Signature window, paste it into the
Signature field. In the Name field, enter a name.

© FORTINET
After you add the signature to the FortiManager database, you can apply the signature to an IPS sensor.

© FORTINET
In this section, you will learn about hardware acceleration options for IPS inspection.

© FORTINET
The strength of an ASIC chip is in its specialization; therefore, Fortinet develops several key ASICs
identified by their type (network processor or content processor) and version. Fortinet also develops
security processors, which are not considered FortiASICs.
The convention name is made up of the family abbreviation plus the revision number. Generally, newer
versions have more features and better performance. The graphic on this slide shows the difference in
performance between an older FortiGate that uses CPU-only gear, and a newer, faster FortiGate with
hardware acceleration.
ASICs are wired into the circuit board; therefore, you can’t upgrade them.

© FORTINET
The CP is a co-processor for the CPU. It accelerates many common resource-intensive, security-related
processes.
Since the very first FortiGate model, Fortinet has included a CP in the design. The CP works at the system
level.
CP8 and CP9 provide a fast path for traffic inspected by IPS, including sessions with flow-based
inspection.
CP processors also accelerate intensive proxy-based tasks:

• Encryption and decryption (SSL)
• Antivirus

© FORTINET
Network processors provide the following features:

• Pre-IPS anomaly filtering and logging
• Packet offloading
• Link aggregation
• HA traffic offloading
• IPsec encryption and decryption

© FORTINET
SPs provide an integrated, high-performance, fast-path multilayer solution for both IPS and firewall
functions.
The IPS starts at a hardware accelerated engine, which ensures that each packet is without anomalies.
Then, DDoS protection, policy-based intrusion protection, and firewall fast path are employed to prevent
attacks.
SPs can also offload packet transmission (multicast, IPv4, IPv6, and NAT64 traffic). It accelerates IPsec
encryption and decryption, performs flow-based content inspection, and provides SYN proxy
functionalities.

© FORTINET
SoC combines a general-purpose CPU, NPs, and CPs, into a single chip. It accelerates IPS-inspected
traffic.
SoC is found in desktop or small office models.

© FORTINET
In this section, you will learn about IPS troubleshooting.

© FORTINET
There are two important types of daemons that handle IPS-related tasks:
• ipsengine is the main type of daemon that handles all inspection and detection tasks
• ipshelper handles actions whose results can be shared by different ipsengine daemons
In some FortiGate models, it is normal to see multiple instances of the ipsengine daemon running.

© FORTINET
IPS goes into fail open mode when there is not enough available memory in the IPS socket buffer for new
packets. What happens during that state depends on the IPS configuration. If the fail-open setting is
enabled, some new packets (depending on the system load) might pass through without being inspected.
If it is disabled, new packets might be dropped.

© FORTINET
The IPS fail open event generates a log in the crashlog. The log indicates if new packets are dropped or
passed through.

© FORTINET
IPS fail open entry and exit events also generate event logs.

© FORTINET
Frequent IPS fail open events usually indicate that the IPS is not able to keep up with the traffic demands.
So, try to identify patterns. Has the traffic volume increased recently? Have throughput demands
increased?
Tune and optimize your IPS configuration: create IPS profiles specific for the type of traffic being
inspected, and disable IPS profiles on policies that don’t need them.
As a last resource, you can try to increase the IPS buffer size. You should do this type of tuning only after
thoroughly testing the new values in a lab environment.

© FORTINET
The command diagnose test application ipsmonitor includes many options that are useful for
troubleshooting purposes. This slide shows two of those options.
Option 3 displays the log entries generated every time an IPS engine process stopped. There are various
reasons why these logs are generated:
• Manual: Because of the configuration, IPS no longer needs to run (that is, all IPS-related features have
been disabled)
• cfg init: There was a problem communicating with the management database (CMDB)
• memory cap: The amount of memory used by the IPS process has exceeded the model-specific
predefined value
• seg fault: This is a IPS engine crash, and it usually indicates a bug
You can clear the IPS engine exit logs using option 4.

© FORTINET
Short spikes in the CPU usage by IPS processes could be caused by firewall policy or profile changes.
These spikes are usually normal. Spikes might happen when FortiGate has hundreds of policies and
profiles, or many virtual domains. Continuous high CPU usage by the IPS engines is not normal, and you
should investigate it.

© FORTINET
If there are high CPU use problems caused by the IPS, you can use the diagnose test application
ipsmonitor command with option 5 to isolate where the problem might be. Option 5 enables IPS
bypass mode. In this mode, the IPS is still running, but it is not inspecting traffic. If the CPU use decreases
after that, it usually indicates that the volume of traffic being inspected is too high for that particular
FortiGate model. If the CPU use remains high after enabling IPS bypass mode, it usually indicates a
problem in the IPS engine that you must report to Fortinet's support.
If you enable IPS bypass mode, remember to disable it, after you finish troubleshooting, using option 5.
Another recommendation to keep in mind: if you need to restart the IPS, don't use the diagnose sys
top kill command. Instead, use option 99, as shown on this slide. This guarantees that all the IPS-
related processes will restart properly.

© FORTINET
If the IPS is generating false positives, first determine which signature is generating them. You can use IP
exemptions as a solution. Additionally, you can provide sniffer samples and the matching logs to the
Fortinet IPS team for further investigation.

© FORTINET
False negatives are more difficult to discover and troubleshoot. Check the following:
• Is traffic hitting the correct policy or IPS profile? Use sniffer and debug flow if necessary.
• CPU and memory use is normal
• IPS engines aren’t crashing
• IPS configuration is correct
Again, after you verify all of those factors, you can collect sniffer samples and, along with details of the
application traffic, provide all the information to the Fortinet IPS team for investigation.

© FORTINET

• Tuning IPS configuration
• Advanced IPS configuration
• Custom signatures
• Accelerating IPS inspection
• IPS troubleshooting

© FORTINET
Now you will work on Lab 10–IPS.

© FORTINET
In this lab, you will configure a FortiGate device to protect a web server using IPS inspection. Then, you
will test the configuration by generating suspicious traffic from outside to the server. Additionally, you will
use the information gathered by the built-in sniffer to write a custom IPS signature.

DO NOT REPRINT  BGP
© FORTINET
In this lesson, you will learn about border gateway protocol (BGP).

© FORTINET
In this lesson, you will learn how to do the following:

• Configure FortiGate for BGP
• Monitor and check the status of a BGP communication
• Troubleshoot the most common external BGP issues

© FORTINET
In this section, you will review the BGP protocol and how to configure it on FortiGate.

© FORTINET
An autonomous system (AS) is a set of routers and networks under the same administration. Each AS is
identified by a unique number, and usually runs an interior gateway protocol, such as OSPF or RIP.

© FORTINET
BGP can serve one of two purposes: external BGP (EBGP) and internal BGP (IBGP).
An exterior gateway protocol (EGP) exchanges routing information between autonomous systems. BGP4,
which runs in the Internet, is the dominant EGP protocol today. EBGP is typically used when strict control
is required over a large number of routes.
Two EBGP routers exchange AS path information for destination prefixes or subnets. When two routers
start a EBGP communication, the whole BGP routing table is interchanged. After that, only network
updates are sent.

© FORTINET
A BGP speaker or peer is a router that sends and receives BGP routing information. The connection
between two BGP peers is called a BGP session.

© FORTINET
There are three types of autonomous systems:

• A stub AS handles and routes local traffic only and has only one connection to another AS. One
example is a company that is running BGP, and has its own AS number and one ISP connection.
• Multi-homed AS also handles and routes local traffic only , but it has multiple connections to different
autonomous systems. One example is a company that is running BGP, and has its own AS number and
multiple ISP connections.
• Transit AS handles and routes local traffic as well as traffic that originates and terminates in different
autonomous systems (transit traffic). An ISP is an example of a transit AS.

© FORTINET
When running IBGP, you usually need to configure full mesh peering between all the routers. In large
networks, full mesh peering between routers can be difficult to administer and is not scalable.

© FORTINET
Route reflectors help to reduce the number of IBGP sessions inside an AS. A route reflector forwards the
routes learned from one peer to the other peers. If you configure route reflectors, you don’t need to create
a full mesh IBGP network. All clients in a cluster only talk to route reflector to get sync routing updates.
Route reflectors pass the routing updates to other route reflectors and border routers within the AS.

© FORTINET
A BGP router stores the routing information in three logical tables. The RIB-in table contains all the routing
information received from other BGP routers before any filtering. The local RIB table contains that same
information after the filtering. The RIB-out table contains the BGP routing information selected to advertise
to other BGP routers.

© FORTINET
This slide shows a flow chart that summarizes the BGP process. The BGP router stores the BGP routes it
receives from other routers in the RIB-in table. The BGP router applies a filter, and the resulting routes are
stored in the local RIB table. Then, the BGP router adds routes that were redistributed from the routing
table, and applies another filter (outbound). The BGP router advertises the resulting routes.

© FORTINET
BGP routes traffic based on AS paths. Each AS path includes attributes, which BGP uses to select the
best route to each destination. One of the attributes is the AS list, which contains the autonomous systems
through which the traffic must pass to reach the destination.

© FORTINET
There are four types of BGP attributes:

• Well-known mandatory
• Well-known discretionary
• Optional transitive, which can be passed from one AS to another
• Optional non-transitive, which can’t be passed from one AS to another

© FORTINET
This slide shows a list of the BGP attributes and their attribute types that are supported by FortiGate.

© FORTINET
FortiGate uses some of the attributes during the routing selection process. If all those attributes for multiple
routes to the same destination match, and if ECMP is enabled, FortiGate shares the traffic among up to 10
BGP routes. If you don’t enable ECMP, FortiGate uses the route that goes to the router with the lowest
BGP router ID.

© FORTINET
There are three important things to consider when you implement BGP on FortiGate.
First, there are no hard-coded limits. Limitations on the number of neighbors, routes and policies depend
exclusively on the available system memory.
Second, by default, FortiGate doesn’t announce any prefix. You must enable redistribution, or manually
indicate the prefixes that FortiGate advertises.
Third, by default, FortiGate accepts all the prefixes it receives. Optionally, you can filter out or modify some
prefixes.

© FORTINET
By default, FortiGate BGP doesn’t advertise prefixes. You can use the redistribution command to
configure FortiGate to advertise prefixes. You can redistribute connected and static routes, and routes
learned from other routing protocols, into BGP. Optionally, you can add route maps to filter the prefixes or
modify some of their BGP attributes.

© FORTINET
You can also use the network command to configure FortiGate BGP to advertise prefixes. However, an
exact match of the prefix in the network command must be active in the routing table. If the routing table
doesn’t contain an active route whose destination subnet matches the prefix, FortiGate doesn’t advertise
the prefix. You can change this behavior by disabling the network-import-check setting. After you
disable the setting, FortiGate advertises all prefixes in the BGP network table, regardless of the active
routes present in the routing table.

© FORTINET
By default, the subnets under the config network command, and the subnets redistributed from other
routing protocols, are advertised to all the neighbours.
With a prefix list, you can be more selective about which prefixes to advertise to each neighbour.
Additionally, prefix lists allow you to select which prefixes you want to use from each neighbour. In this
example, we are creating a prefix list that allows the prefix 10.1.0.0/16, but blocks the prefix 10.2.0.0/16.
The prefix list is applied in the incoming direction from the neighbour 10.3.1.254. The local FortiGate
applies this filter for all the prefix advertisements coming from 10.3.1.254.
When applying a prefix list, all the prefixes that don’t match an entry in the list are denied by default.

© FORTINET
This slide shows an example of a basic FortiGate configuration. In this case, remote-as is the same as
local AS, which means it is an IBGP configuration.

© FORTINET
In this section, you will learn about tools and tips for troubleshooting BGP.

© FORTINET
This slide shows a flow chart of the BGP neighbor states and how they change:
• Idle: Initial state
• Connect: Waiting for a successful three-way TCP connection
• Active: Unable to establish the TCP session
• OpenSent: Waiting for an OPEN message from the peer
• OpenConfirm: Waiting for the keepalive message from the peer
• Established: Peers have successfully exchanged OPEN and keepalive messages

© FORTINET
This slide shows the debug command you usually use first to get an overview of the BGP’s status, and the
status of all of its neighbors. The slide shows the local router ID and AS. For each neighbor, the output
also displays the following:
• The AS
• Packet counters
• How long the neighbor has been up
The last column is the neighbor state and number of prefixes. If the state is not established, this column
displays the BGP state. If the state is established, this column displays the number of prefixes received by
the local FortiGate from that neighbor.

© FORTINET
You can use the command get router info bgp neighbors to get detailed information about each
BGP neighbor. The information includes packet counters, and the number of prefixes announced and
accepted.

© FORTINET
The information also shows the number of times that the session has dropped, and last time it was reset.

© FORTINET
This slide shows the command you can use to get details about the prefixes the local router is advertising.
Status codes indentifies codes associated with a routing entry. For each prefix, the command displays
the following:
• Next hop IP
• Local preference
• Weight
• AS path

© FORTINET
This slide shows the command you can use to display the routes advertised by a neighbor.

© FORTINET
This slide shows the commands you can use to enable and disable the BGP real-time debug. Note: this
example enables debug output from event and level information.

© FORTINET
The next two slides show examples of real-time debug outputs from the successful establishment of a
BGP session. In this example, the output shows when the session goes to OpenSent state.

© FORTINET
This slide shows the real-time debug output containing the OpenConfirm after the keepalive is
received from the neighbor, as well as the setting up of the connection.
The output also lists the prefixes FortiGate receives after the BGP session is set up.

© FORTINET
This slide shows how the command execute router clear bgp is used to restart a BGP session
between two peers. You can also use this command to run a BGP soft reset, which forces both peers to
exchange their complete BGP routing tables.

© FORTINET
Now FortiGate can log routing events, which enables you to get information that used to be available only
when you ran the BGP real-time debug. By default, BGP event logging is enabled. You can disable BGP
event logging by using the command shown on this slide.

© FORTINET
To display the routing logs, click Log & Report > Router Events. You can double-click a specific log to
view the details of the log.

© FORTINET
Follow these steps to troubleshoot a BGP problem between two peers:

• Check that the local router can reach the remote peer
• Check the TCP session
• Check the BGP session
• If the BGP session is established, check the prefixes received and advertised by each peer

© FORTINET

• BGP overview and components
• Autonomous system (AS)
• Route reflector
• Routing information bases
• BGP attributes
• BGP route selection
• BGP router event logs
• BGP troubleshooting

© FORTINET
No you will work on Lab 11–BGP.

© FORTINET
In this lab, you will configure BGP routing between the NGFW and the Linux Router. You will also use the
BGP real time debug to troubleshoot BGP issues.

DO NOT REPRINT  IPsec
© FORTINET
In this lesson, you will learn about IPsec.

© FORTINET

• Configure IPsec using the FortiManager VPN manager
• Troubleshoot the most common IPsec problems
• Check whether IPsec encryption and decryption is offloaded to hardware
• Use the debug flow to isolate IPsec traffic issues
• Capture IPsec traffic
• Monitor the status of an IPsec VPN

© FORTINET
In this section, you will review some IPsec concepts from the NSE 4 course.

© FORTINET
IPsec is a suite of protocols for authenticating and encrypting traffic between two peers. The two most-
used protocols in the suite are:
• Internet Key Exchange (IKE), which does the handshake, tunnel maintenance, and disconnection
• Encapsulation Security Payload (ESP), which ensures data integrity and encryption

© FORTINET
IKE negotiates the private keys, authentications, and encryption that FortiGate uses to create an IPsec
tunnel. Security associations (SAs) provide the basis for building security functions into IPsec. There are
two distinct phases that IKE uses: phase 1 uses a single bi-directional SA, and phase 2 uses two IPsec
SAs, one for each traffic direction.

© FORTINET
Next, you will review the differences between aggressive mode and main mode. This slide shows main
mode, where six packets are exchanged:
1. The client initiates by proposing the security policies
2. The responder selects which security policy it will agree to use, and replies
3. The initiator sends its Diffie Hellman public value
4. The responder replies with its own Diffie Hellman public value
5. The initiator sends its peer ID and hash payload
6. The responder replies with its peer ID and hash payload

© FORTINET
In comparison, this slide shows the aggressive mode negotiation in which only three packets are
exchanged:
1. The client initiates by suggesting the security policies, and providing its Diffie Hellman public value and
peer ID
2. The responder replies with the same information, plus a hash
3. The initiator sends its hash payload

© FORTINET
In this section, you will learn how to configure IPsec VPNs using the FortiManager VPN manager.

© FORTINET
On the VPN manager screen, you can configure IPsec VPN settings that you can install on multiple
devices. The settings are stored as objects in the objects database. You push the IPsec VPN settings to
one or more devices by installing a policy package. Follow these steps to configure VPNs with the VPN
manager:
1. Create a VPN community
2. Add gateways (members) to the community
3. Install the VPN community and gateways configuration
4. Add the firewall policies
5. Install the firewall policies

© FORTINET
To create the VPN community, click VPN Manager > IPsec VPN > VPN Communities, and then click
Create New.
Depending on the VPN topology to install, there are three types of communities:
• Full meshed
• Star
• Dial-up

© FORTINET
The VPN community contains the IPsec phase 1 and 2 settings that are common to all the gateways.

© FORTINET
The next step is to add gateways to the community. There are two types of gateways:
• Managed gateways are FortiGate devices managed by FortiManager
• External gateways are FortiGate devices not managed by FortiManager, such as devices made by
other vendors

© FORTINET
In VPN gateways, you configure the node type (hub, spoke, and so on), depending on the VPN topology
you select. For example, hub and spoke options are only available in star and dial-up topologies.
For each gateway you can also configure the protected subnet, interfaces, and some advanced settings.

© FORTINET
When you configure VPNs using the VPN manager, they are always created as interface-based. As such,
you can’t create the firewall policies for IPsec using FortiManager until the IPsec community and gateways
configuration are pushed to the device first, in order to create the interface. After that, the FortiGate and
FortiManager display the IPsec interfaces that you need to create the firewall policies.

© FORTINET
In this section, you will learn the basics of IPsec troubleshooting.

© FORTINET
When isolating IPsec problems, it is useful to understand that an IPsec connection can be described as a
four-step process:
1. Interesting traffic triggers the VPN negotiation. Traffic is called interesting when it must travel through
an IPsec tunnel (encrypted and encapsulated) to reach a remote network.
2. Phase 1 goes up
3. One or more phase 2s go up; two IPsec security associations are negotiated for each phase 2
4. Traffic crosses the tunnel
So, if you have an IPsec issue, you should determine in which of these four steps the problem has
occurred.

© FORTINET
The command diagnose vpn tunnel list displays the current IPsec SA information for all active
tunnels.
The command diagnose vpn tunnel list name <tunnel name> provides SA information about
a specific tunnel.

© FORTINET
get vpn ipsec tunnel details provides detailed information for the active IPsec tunnels.

© FORTINET
The command diagnose vpn ike gateway list also provides some details about a tunnel.
The command diagnose vpn ike gateway clear closes a phase 1.

© FORTINET
The command get vpn ipsec stats tunnel provides some global overall counters related to all the
VPNs currently active.
The other two commands shown on this slide provide summarized information about the VPNs.

© FORTINET
The IKE daemon handles all IPsec connections on FortiGate. It’s important to familiarize yourself with the
available filter options. You use these options to filter the output of the IKE real-time debug, so that only
information relevant to you is displayed. The most common filter option is dst-addr4, which you use to
filter the output by the IP address of the remote peer.
Filtering by name is helpful when the remote peer IP address is unknown.

© FORTINET
After setting the filter, enable the IKE real-time debug using the following commands:
diagnose debug application ike <bit-mask>
diagnose debug enable
The table shown on this slide includes the type of output that is enabled by each bit in the bit-mask. The
most common values for the bit-mask are 255 (all outputs enabled) and 63 (shorter output). They both
show the DPD packets and all the information required for troubleshooting IPsec negotiation problems.

© FORTINET
Let's look at the output of the IKE real-time debug during a main-mode negotiation. As explained earlier,
main mode requires the interchange of six packets. The real-time debug shows when the first packet (first
main mode message) arrives. Then the debug shows the negotiated settings for the phase 1. A message
is generated once FortiGate identifies the VPN configuration to use (with the name of the VPN).

© FORTINET
Next, the output shows the remote peers information. The second and third main mode messages arrive.
After the authentication is successful and the pre-shared key matches, a final message is generated to
indicate that the phase 1 is up.

© FORTINET
This slide shows the output of the real-time debug for phase-1 aggressive mode. It displays the three
aggressive-mode packets interchanged and the proposals.

© FORTINET
This slide shows the phase 2 negotiation.
The debug shows the phase 2 proposal from the local gateway, and the phase 2 proposal coming to the
remote gateway. In this case, both proposals (local and remote) match.

© FORTINET
Next, the output shows the negotiated phase 2 settings. The last messages confirm that the phase 2 is up.

© FORTINET
If the VPN is up but the traffic can’t cross the tunnel, you should use the debug flow. This slide shows an
example output of the debug flow for traffic that is crossing an Ipsec tunnel. The output shows the
following:
• Packet arriving
• Packet being allowed by a firewall policy
• Packet entering the tunnel
• Packets being encrypted and sent
If the traffic is not crossing the tunnel because of a routing misconfiguration, the output of the debug flow
shows it. The debug flow also displays if the traffic drops and why (for example, when packets don’t match
the quick mode selector).

© FORTINET
If you need to capture the IPsec traffic, remember that the IP protocol and UDP port numbers depend on
NAT-T and the use of NAT.
If there is no FortiGate located in the middle that is running NAT, IKE traffic uses UDP port 500 and ESP
traffic uses IP protocol 50. This slide shows the two sniffer filters that the sniffer command must use to
capture each of those traffic protocols.
If NAT-T is enabled, and there is a FortiGate located in the middle that is running NAT, the sniffer
command must use a different filter. In this case, IKE traffic uses port UDP 500, but switches to UDP port
4500 during the tunnel negotiation. Additionally, ESP traffic is encapsulated inside the UDP-4500 channel.

© FORTINET
On some FortiGate models, you can offload the encryption and decryption of IPsec traffic to hardware. The
supported algorithms depend on the model and type of processor on the unit that is offloading the
encryption and decryption.
By default, hardware offloading is enabled for the supported algorithms. This slide shows the commands
you can use to disable hardware offloading per tunnel, if necessary.

© FORTINET
All IPsec SAs have an npu_flag field indicating offloading status. In the case of IPsec traffic, the
FortiGate session table also includes that field.
First, when phase 2 goes up, the IPsec SAs are created and loaded to the kernel. As long as there is no
traffic crossing the tunnel, the SAs are not copied to the NPU, and the npu_flag shows 00. The value of
that field also remains 00 when Ipsec offloading is disabled.
Second, if the first IPsec packet that arrives is an outbound packet that can be offloaded, the outbound SA
is copied to the NPU and the npu_flag changes to 01. However, if the first IPsec packet is inbound and
can be offloaded, the inbound SA is copied to the NPU and the npu_flag changes to 02.
After both SAs are copied to the NPU, the npu_flag changes to 03.
The value 20 in the npu_flag field indicates that hardware offloading is unavailable because of an
unsupported cipher or HMAC algorithm.

© FORTINET
This slide shows a summary of the most common IPsec problems and solutions.
If the tunnel doesn’t come up, use the IKE real-time debug. In such cases, an error message usually
appears.
When the tunnel is unstable, you usually see that DPD packets are being lost, which indicates that the
problem might be on the ISP side.
If the tunnel is up but traffic isn’t passing through it, use the debug flow. One of the peers might be
dropping packets or routing traffic incorrectly. Another possibility is that the packets don’t match the quick
mode selectors, so FortiGate drops the packets.

© FORTINET

• Deploy IPsec using VPN manager on FortiManager
• Troubleshoot IPsec
• Offload hardware for encryption and decryption
• Identify common IPsec problems
• Capture IKE and IPsec traffic

© FORTINET
Now, you will now work on Lab 12–IPsec.

© FORTINET
In this lab, you will troubleshoot an IPsec problem between Spoke-1 and Spoke-2.

© FORTINET
After that, you will configure a hub-and-spoke VPN network using the FortiManager VPN manager.

DO NOT REPRINT  ADVPN
© FORTINET
In this lesson, you will learn about autodiscovery VPN (ADVPN.)

© FORTINET

• Configure and test autodiscovery VPN with IBGP
• Use the IKE real-time debug to troubleshoot ADVPN problems

© FORTINET
Why should you use ADVPN? To find the answer, you will review the most common VPN topologies.
One point-to-multipoint topology variation is called hub-and-spoke. As its name describes, all clients
connect through a central hub, similar to the way spokes connect to hubs on wheels.
In the example shown on this slide, each client—spoke—is a branch-office FortiGate. For any branch
office to reach another branch office, its traffic must pass through the hub.
One advantage of using this topology is that you can easily manage the VPN configuration and firewall
policies. Also, system requirements are minimal for the FortiGate devices that function as branch offices,
because each FortiGate must maintain only one tunnel, or two SAs. In this example, four tunnels, or eight
SAs, are necessary in the hub.
A disadvantage of using this topology is that communication between branch offices through headquarters
(HQ) is slower than it would be using a direct connection, especially if HQ is physically distant, as it can be
for global companies. For example, if your company’s HQ is in Brazil, and your company also has offices
in Japan and Germany, latency can be significant. Another disadvantage is lack of redundancy. For
example, if the FortiGate at HQ fails, the VPN fails company-wide. Also, FortiGate at HQ must be more
powerful, as it handles four tunnels simultaneously, or eight SAs.

© FORTINET
This slide shows a VPN that has a mesh topology. There are two types of mesh topologies.
Full mesh connects every location to every other location. Like the previous hub-and-spoke example, the
example on this slide shows only five locations. In order to fully interconnect, each FortiGate needs four
VPN tunnels, or eight SAs, to the other FortiGate devices. This equals three more tunnels for each spoke
FortiGate. In total, 20 tunnels are needed. If your company were to expand to six locations, it would require
30 VPNs. Seven locations would need 42 VPNs, and so on. This topology causes less latency and
requires much less HQ bandwidth than hub-and-spoke. Its disadvantages? Every spoke FortiGate must be
more powerful. Additionally, both administration and troubleshooting get more complicated.
Partial mesh attempts to compromise, minimizing required resources as well as latency. Partial mesh can
be appropriate if communication is not required between every location. However, each FortiGate’s
configuration is still more complex than hub-and-spoke. Routing, especially, may require extensive
planning.
So, in general, if your company has many locations, hub-and-spoke will be cheaper, but slower, than a
mesh topology. Mesh toplogies place less strain on the central location and can be more fault-tolerant, but
are also more expensive.

© FORTINET
Autodiscovery VPN was introduced in FortiOS 5.4. It combines the benefits of hub-and-spoke and full-
mesh topologies, because all the spoke-to-spoke tunnels are dynamically created on demand.

© FORTINET
• ADVPN supports single or multiple hub architectures

• NAT is supported for the on-demand tunnels, as long as one of the spokes is not behind NAT
• ADVPN requires the use of a routing protocol. Currently it supports iBGP and RIPv2/RIPng
• Both IPv4 and IPv6 are supported

© FORTINET
This slide shows an example of how ADVPN works.
An administrator configures IPsec VPNs in multiple FortiGate devices to form VPN hub-and-spoke
topologies. In this example, there are two hubs. Hub 1 has three spokes. Hub 2 has two spokes. There is
also a VPN connecting both hubs.
The dynamic tunnels between spokes are created on demand. Let's say that a user in Boston sends traffic
to London. Initially, the direct tunnel between Boston and London has not been negotiated. So, the first
packets from Boston to London are routed through Hub 1 and Hub 2. When Hub 1 receives those packets,
it knows that ADVPN is enabled in all the VPNs all the way to London. So, Hub 1 sends an IKE message
to Boston informing that it can try to negotiate a direct connection to London. On receipt of this IKE
message, Boston creates a FortiOS-specific IKE information message that contains its public IP address,
its local subnet, the desired destination subnet (London's subnet), and an auto-generated PSK
(alternatively digital certificate authentication can also be used). This IKE message is sent to London
through Hub 1 and Hub 2. When London receives the IKE message from Boston, it stores the PSK and
replies with another IKE information message that contains London's public IP address. After the reply
arrives in Boston, the dynamic tunnel is negotiated between both peers. The negotiation succeeds
because London is expecting a connection attempt from Boston's public IP address.

© FORTINET
Let's look at the IKE messages that are exchanged when an on-demand tunnel is being negotiated:
1. The client behind Spoke1 generates traffic for devices located on Spoke2’s network.
2. Spoke1 receives the packet, encrypts it, and sends it to the Hub.
3. The Hub receives the packet from Spoke1 and forwards it to Spoke2.
4. Spoke2 receives the packet, decrypts it, and forwards it to the destination device.
5. The Hub knows that a more direct tunnel option might be available from Spoke1 to Spoke2. The Hub
sends a Shortcut Offer message to Spoke1.
6. Spoke1 acknowledges the shortcut offer by sending a Shortcut Query to the Hub.
7. The Hub forwards the shortcut query message to Spoke2.
8. Spoke2 acknowledges the shortcut query and sends a Shortcut Reply to the Hub.
9. The Hub forwards the shortcut reply to Spoke1.
10. Spoke 1 and Spoke 2 initiate the tunnel IKE negotiation.

© FORTINET
As mentioned, ADVPN requires the use of a dynamic routing protocol. In the next slides, you will learn how
to configure ADVPN with IBGP.
As an example, you will use an IBGP topology made up of one hub with two spokes. All the devices are in
the AS 65100.

© FORTINET
This slide shows the following ADVPN configuration in the hub:

• Disable set add-route to ensure that the hub won’t automatically install routes to the spokes after
their tunnels go up
• Enable ADVPN with the command auto-discovery-sender
• Assign an IP address to the IPsec virtual interface. This is a requirement for having a dynamic routing
protocol over IPsec. For the remote IP, use any dummy IP address not being used by any spoke
• For the phase-2 configuration, ensure that quick modes are set to all (0.0.0.0/0.0.0.0)
• Set a firewall policy to allow the traffic from the spokes to the hub, from the hub to the spokes, and
between spokes through the hub

© FORTINET
This slide shows the following ADVPN configuration in a spoke:

• Enable ADVPN with the command auto-discovery-receiver
• Assign an IP address to the IPsec virtual interface
• Add a static route to a summarized subnet that contains all the IPsec virtual IP addresses

© FORTINET
This slide shows the following IBGP configuration in the hub:

• Configure a BGP neighbor group. All the spokes are part of it.
• Create a neighbor range with a prefix that includes all the spokes. In this way, you don’t need to define
each spoke individually as a neighbor
• If you are using IBGP for ADVPN, you must configure the hub as a route reflector. So, routes learned
from one spoke are forwarded to the other spokes.
• Add the local network(s) behind the hub to be advertised over BGP

© FORTINET
This slide shows the following IBGP configuration in one of the spokes:
• Configure the hub as a BGP neighbor
• Define the internal network that will be advertised over the BGP

© FORTINET
If you are configuring ADVPN on FortiManager using the VPN manager, remember the following:
• Set the protected networks to all
• Use scripts to enable ADVPN in phase 1
• Disable the option Add Route on the hub
• Configure IP addresses on the IPsec virtual interfaces
• Add a summarized static route on all spokes for the IPsec virtual interfaces
• Configure dynamic routing. If you are using IBGP, use a script to enable route reflector on the hub

© FORTINET
The configuration of the Protected Subnet is under VPN Communities.

© FORTINET
For ADVPN, disable Add Route under the VPN gateway configuration of the hub.
This prevents the hub from adding routes based on IKE negotiations. For that purpose, ADVPN uses a
dynamic routing protocol instead.

© FORTINET
After the tunnels between the hub and the spokes are up, you can run the following commands in the
spokes to verify that routing updates are taking place:
get router info bgp network
get router info routing-table all
This slide shows that spoke 1 learned the routes to the hubs and to the networks of spoke 2, through
BGP. Spoke 2 is currently accessible through the hub.

© FORTINET
If you run the IKE real-time debug during the negotiation of an ADVPN tunnel, you see the exchange of all
shortcuts. This slide shows an example of the output of the real-time debug in the hub. You can see the
shortcut offer being sent, and the shortcut’s query and reply being received and forwarded.

© FORTINET
This slide shows the IKE real-time debug output from one spoke when the on-demand tunnel is triggered.
The first two messages indicate that a shortcut offer is received from the hub. After that, a shortcut query
message is sent. A shortcut reply message is received and the dynamic tunnel interface is created.

© FORTINET
Using the get ipsec tunnel list command, you can verify which on-demand tunnels are up. It is
important to note that on-demand tunnels remain active until their SAs are manually flushed, or until they
time out.

© FORTINET
This slide shows the routing table after the on-demand tunnel is up.
We can confirm that the network of spoke 2 is directly accessible using the on-demand tunnel: VPN_0_0.

© FORTINET

• Configure ADVPN
• Troubleshoot ADVPN

© FORTINET
Now you will work on Lab 13–ADVPN.

© FORTINET
In this lab, you will run CLI and TCL scripts to configure ADVPN and IBGP in the three FortiGate devices.

© FORTINET
This slide shows your IBGP network, including router IDs and the IP addresses used in the IPsec
interfaces.

© FORTINET
This slide shows the CLI script that configures the NGFW with ADVPN and IBGP. The first part enables
ADVPN. The second part configures the IP address in the IPsec interface. The last part configures IBGP
with route-reflector-client enabled.

© FORTINET
Configuration is slightly different from one spoke to another, so you will use TCL to create a single script
that can run on all the spokes, and configure each of them individually. What changes from one spoke to
another is the router ID, the prefix to advertise, and the IP address in the IPsec interface. The script
derives those from the spoke hostname.
The first part defines a function that is called each time a CLI command needs to be executed. This
simplifies the TCL script.
The second part extracts the hostname from the output of the command get system status.
The third part extracts the spoke number from the hostname. For example, Spoke-1 is the spoke number
1, Spoke-10 is the spoke number 10, and so on.
Two variables are created:
$spokenumber is the spoke number. It is used to set the prefix to advertise.
$spokenumberplusone is the spoke number plus 1. It is used to set the router ID and IPsec interface IP
address.

© FORTINET
Next, the TCl script enables ADVPN. After that, it configures the IPsec interface IP address: for example,
172.16.1.2 for Spoke-1, 172.16.1.11 for Spoke-10, and so on. It uses the variable
$spokenumberplusone.

© FORTINET
Finally, the TCL configures BGP. For example, the router ID for Spoke-1 is 172.16.1.2, for Spoke-7 is
172.16.1.8, and so on. The script uses the variable $spokenumberplusone again.
In the case of the BGP prefix, Spoke-1 advertises 10.1.1.0/24, Spoke-5 advertises 10.1.5.0/24, and so on.
The script uses the variable $spokenumber.

© FORTINET
Additionally, you will troubleshoot a routing problem with OSPF and BGP.

DO NOT REPRINT  Solution Slides
© FORTINET
These slides contain the solutions to the troubleshooting exercises.

© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the security fabric lab.

© FORTINET
The sniffer in port 8013 (FortiTelemetry) shows that the NGFW was resetting the TCP connection.

© FORTINET
The security fabric real time debug showed the reason for the reset packets. The authentication between
the ISFW and the NGFW was failing. The ISFW was configured with an incorrect password.

© FORTINET
Retyping the password (password) in the ISFW fixed the problem.

© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the traffic and session monitoring lab.

© FORTINET
There were four problems:

• Unable to telnet to the ISFW (10.1.10.254)
• Client-10 was unable to access the web server at 10.1.4.10
• No Internet web access
• Unable to telnet to the Linux Router (10.200.1.254)

© FORTINET
In the first problem, packets were arriving to the ISFW as verified with the sniffer command. However the
ISFW was not replying with the SYN/ACK packets. The next step was to use the debug flow, which
showed the error iprope_in_check() check failed on policy 1, drop. As this is FortiGate
management traffic, the problem was one of the following:
• The telnet service was not enabled in port3
• The telnet service was using a different port
• The source IP address was not in the trusted host list
• There was a local-in firewall configured to block telnet traffic

© FORTINET
The problem was actually a local-in policy blocking the telnet traffic. Removing that policy fixed the
problem.

© FORTINET
For the second problem, the sniffer displayed only incoming SYN packets. The debug flow showed the
same error as with the first problem: iprope_in_check() check failed on policy 0, drop.
However, in this case, the cause was different because this traffic was not intended to terminate in the
FortiGate. As explained in this lesson, the cause might be a wrong VIP or IP pool configuration.

© FORTINET
There was actually an IP pool on the ISFW with the 10.1.4.0/24 subnet. As the web server's IP address is
part of the IP pool, the FortiGate assumes that it owns this address. So, any traffic destined to 10.1.4.10
terminates in the FortiGate. The solution was removing the IP pool configuration.

© FORTINET
For the third problem, users were unable to access public websites. Attempts to connect to yahoo.com
were failing, however you could still ping 8.8.8.8. This means that Client-10 does have Internet connectivity
but it is having issues resolving domain names. We could confirm this by running a debug flow of the traffic
to port 53 (DNS).

© FORTINET
The problem was that DNS traffic was not allowed in the firewall policies. Adding the DNS service to the
firewall policy solved the problem.

© FORTINET
In the last problem, the sniffer of traffic to port 23 showed that the FortiGate was actually routing the SYN
packets properly this time. However, the router was replying with RST packets. So, the problem was not
on the FortiGate side, but on the server side.

© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the routing lab.

© FORTINET
When the primary Internet link went down, the routing table changed. So, all the routing information was
flushed from the affected sessions and traffic was routed to port2. When port1 came back up, all SNAT
sessions continued using port2, because the port2 route was still valid and the interface was still up.
Existing SNAT sessions would continue using port2 until they expire.
Starting from FortiOS 5.4, there is a global setting that instructs FortiGate to reroute existing SNAT
sessions upon any routing change, even for the cases where the old route is still up.

© FORTINET
The default route configuration was not working as desired. The default route using port2 was inactive.

© FORTINET
There were two misconfigurations that were preventing the port2 default route from becoming active.
First, its distance was higher than the port1 default route. In order for both default routes to be active,
they must have the same distance. Second, the IP address for the gateway was wrong. It must be
10.200.2.254 for the port2 default route.

© FORTINET
Why was traffic to 10.200.3.1 taking port2? The debug flow showed the reason. There was a policy-
based route overriding the static route configuration.

© FORTINET
Removing the policy-based route fixed the problem.

© FORTINET
Now, we will look at the solutions for the troubleshooting exercises in the FortiGuard lab.

© FORTINET
The first problem was that the DCFW was having issues connecting to FortiManager for license and
update information. The output of the FortiGuard real time debug showed that the FortiGate was trying to
connect to the wrong IP address.

© FORTINET
Correcting the IP address in the central management configuration solved the problem.

© FORTINET
The second issue involved web filtering rating. The web filtering real time debug showed that the ISFW
was not able to find an available FortiGuard server.

© FORTINET
Like the previous issue, fixing this issue also involved working with the central management configuration.
There was no rating server in the server list. The only server in the list was for updates. Changing that
server configuration to be for both updates and ratings fixed the problem.

© FORTINET
We will see the solutions for the troubleshooting exercise in the OSPF lab.

© FORTINET
The OSPF real time debug showed why the adjacency was not coming up. The Linux Server was using
the router ID 0.0.0.2, which was also being used by the DCFW.

© FORTINET
To solve this problem from the DCFW side, change the DCFW router ID from 0.0.0.2 to any other ID
available.

© FORTINET
If you applied the fix in the DCFW, you would have seen the Linux Router (0.0.0.0.2) adjacency coming up.

© FORTINET
Now, we will look at the solutions for the troubleshooting exercises in the web filtering and antivirus lab.

© FORTINET
The first problem was that some users reported that www.eicar.org should be blocked because it belongs
to the security risk category. However, the output of the web filtering real time debug showed that it
belongs to a different category (information and computer security), which is allowed in the FortiGate
configuration.

© FORTINET
The second problem was that the ISFW was not blocking the FTP file transfer of an infected file. The
debug flow was not showing the message being sent to the application layer, which means
that the ISFW was actually not inspecting the traffic. The reason that this was not happening was because
the FTP connection was using the non-standard port 222.

© FORTINET
The fix was to add port 222 to the list of FTP ports.

© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the BGP lab.

© FORTINET
The BGP neighbors were not coming up because the NGFW was configured with the remote AS 200, but
the ISP AS is 100.

© FORTINET
Changing the remote AS number from 200 to 100 fixed the problem.

© FORTINET
The second problem was that the NGFW was receiving the prefix 8.8.8.8/32 through port2. This was
causing that all the traffic destined to 8.8.8.8 to be routed through port2 instead of port1.

© FORTINET
For this issue, the fix is in the hands of the ISP router's administrator. However, while the ISP fixes the
problem, we used a prefix list to block the incoming advertisement to the subnet 8.8.8.8/32.

© FORTINET
Now, we will see the solutions for the troubleshooting exercise in the IPsec lab.

© FORTINET
The first problem was a misconfiguration in the phase 1. One side was configured with 3DES, the other
side was configured with AES.

© FORTINET
The second problem was a mismatch in the pre-shared key.

© FORTINET
The third problem was an ESP problem. The tunnel came up, but the sniffer shows that the ESP packets
that came from Spoke-1 were being blocked by the ISP (Linux router.) For this issue the solution is on the
ISP side.

© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the ADVPN lab.

© FORTINET
The cause of the routing problem was that the NGFW was not advertising the 10.1.4.0/24 prefix through
BGP.

© FORTINET
There are different ways to solve the problem. One of them is adding the 10.1.4.0/24 prefix to the BGP
networks configuration. Another solution is redistributing the OSPF routes to BGP.

Information Security Policies - TEMPLATE

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Information Security Policies - TEMPLATE

Caricato da

Copyright:

Formati disponibili

DO NOT REPRINT

VIRTUAL LAB BASICS ...................................................................................5

LAB 1—SECURITY FABRIC ...........................................................................15

1 Configuring the Security Fabric ...........................................................................................19

2 Troubleshooting: Security Fabric .........................................................................................24

3 Physical and Logical Topology Views .................................................................................26

LAB 2 —FORTIOS ARCHITECTURE ..............................................................28

1 System Information ..............................................................................................................29

LAB 3 —SYSTEM TROUBLESHOOTING .........................................................30

LAB 4 —TRAFFIC AND SESSION MONITORING ..............................................34

1 Exploring the Session Table ................................................................................................37

2 Troubleshooting: Connectivity Issues ..................................................................................40

LAB 5—ROUTING .........................................................................................43

1 Failover of Existing Sessions ...............................................................................................46

2 Troubleshooting: Routing .....................................................................................................49

LAB 6—FORTIGUARD ..................................................................................52

1 Troubleshooting: Local FDS Issue.......................................................................................56

LAB 7—CENTRAL MANAGEMENT..................................................................60

1 FortiManager Registration ...................................................................................................64

LAB 8—OSPF .............................................................................................70

1 Configuring OSPF ................................................................................................................72

2 Troubleshooting: OSPF .......................................................................................................78

LAB 9—WEB FILTERING AND ANTIVIRUS ......................................................80

1 Configuring Web Filtering and AV .......................................................................................82

2 Troubleshooting: Web Filtering ............................................................................................86

3 Troubleshooting: Antivirus ...................................................................................................88

LAB 10—IPS ...............................................................................................91

1 Configuring IPS ....................................................................................................................93

2 IPS Custom Signatures........................................................................................................100

LAB 11—BGP .............................................................................................109

1 Configuring BGP ..................................................................................................................111

2 Troubleshooting: BGP Neighbor ..........................................................................................115

3 Troubleshooting: BGP Routing ............................................................................................117

4 Configuring Prefix Lists ........................................................................................................118

LAB 12—IPSEC ...........................................................................................120

1 Troubleshooting: IPsec ........................................................................................................124

1 Configuring ADVPN and IBGP ............................................................................................140

2 Troubleshooting: OSPF and BGP........................................................................................145

APPENDIX A: USING RAVELLO ......................................................................147

APPENDIX B: ADDITIONAL RESOURCES ........................................................155

APPENDIX C: PRESENTATION SLIDES............................................................156

1 Enterprise Firewall Solution Overview ................................................................................157

2 FortiOS Architecture ...........................................................................................................181

3 System Troubleshooting .....................................................................................................223

4 Traffic and Session Monitoring ...........................................................................................267

7 Central Management ..........................................................................................................377

9 Web Filtering .......................................................................................................................443

10 Intrusion Prevention System .............................................................................................464

13 Auto Discovery VPN (ADVPN) .........................................................................................584

Solution Slides ........................................................................................................................614

Enterprise Firewall Student Guide 5

Device Username Password

Enterprise Firewall Student Guide 6

Enterprise Firewall Student Guide 7

4. Click Enter Lab.

Enterprise Firewall Student Guide 8

5. Click Windows to open a connection to that server.

Enterprise Firewall Student Guide 9

Transferring Files to the VM

Using Java Instead of HTML5

Enterprise Firewall Student Guide 10

Enterprise Firewall Student Guide 11

Enterprise Firewall Student Guide 12

Enterprise Firewall Student Guide 13