Fortinet Network Security Support Engineer Study Guide For Fortios 72

DO NOT REPRINT
© FORTINET
Network Security Support

Engineer
Study Guide
for FortiOS 7.2
DO NOT REPRINT
© FORTINET
Fortinet Training Institute - Library
https://training.fortinet.com
Fortinet Product Documentation
https://docs.fortinet.com
Fortinet Knowledge Base
https://kb.fortinet.com
Fortinet Fuse User Community
https://fusecommunity.fortinet.com/home
Fortinet Forums
https://forum.fortinet.com
Fortinet Product Support
https://support.fortinet.com
FortiGuard Labs
https://www.fortiguard.com
Fortinet Training Program Information
https://www.fortinet.com/nse-training
Fortinet | Pearson VUE
https://home.pearsonvue.com/fortinet
Fortinet Training Institute Helpdesk (training questions, comments, feedback)
https://helpdesk.training.fortinet.com/support/home
6/2/2023
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
01 Troubleshooting Concepts 4
02 System Resources 29
03 Sessions, Traffic Flow, and Networking 81
04 Security Fabric 126
05 Firewall Authentication 153
06 FSSO 183
07 Security Profiles 220
08 High Availability 273
09 IPSec 303
10 IPsec―IKEv2 331
11 Routing 352
12 BGP 384
13 OSPF 418
Solution Slides 450
Dynamic Routing Supplement 495
Troubleshooting Concepts
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about troubleshooting concepts on a FortiGate device.
Network Security Support Engineer 7.2 Study Guide 4

DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating a competent understanding of troubleshooting concepts, you will be able to set up a

baseline and identify the GUI tools and CLI commands you should use to monitor and diagnose issues on
FortiGate.

DO NOT REPRINT
© FORTINET
In this section, you will learn about the troubleshooting methods used to approach and diagnose an issue.

DO NOT REPRINT
© FORTINET
Good administrators know their network. This network knowledge includes an understanding of the normal
behavior related to traffic volume, network applications, traffic flows, and the CPU and memory utilization. So,
when a problem happens, administrators can identify quickly where the abnormal behavior is happening.
Having this knowledge speeds up the troubleshooting process and helps the administrator to isolate the cause
of the problem.
FortiGate devices operate at all layers of the OSI model. For this reason, troubleshooting problems can be
complex. If you establish what normal operating parameters are, or establish a baseline for your system
before a problem occurs, it will help reduce the complexity of the issue when you are troubleshooting.

DO NOT REPRINT
© FORTINET
You can use many different tools to gather statistics and information while the network is operating normally:
SNMP, logging, and the monitors located on the FortiGate GUI.

DO NOT REPRINT
© FORTINET
It is also important to keep the network documentation up to date. Network diagrams should include physical
connections, interface names, and subnets. Good network documentation also includes change control
records to track any change in the network, such as who made the change, when the change was made, and
what the change was.

DO NOT REPRINT
© FORTINET
If a problem occurs, the first step is to define it well. For example, if the problem definition is “web filtering is
not working”, the scope of the problem is too imprecise. Too many things could cause this problem. This
makes troubleshooting slow. So, you must ask questions to understand the details. Is the problem happening
with one web site? Is it happening with all users? Is it happening randomly? How can you reproduce the
problem?
After answering the right questions, you can define the problem with details. For example, “web filtering is not
blocking website X for user Y”. Having this level of detail, provides a better place to start the troubleshooting
process.
The following questions can help determine the scope of the problem and isolate it:
• What is the problem?
• Has the configuration ever worked?
• Can you reproduce the problem at will, or is it intermittent?
• What has changed?
• What applications, users, operating systems does the problem effect?

DO NOT REPRINT
© FORTINET
One general approach to troubleshooting network issues is to follow the TCP/IP model and work the problem
either from the highest layer to the bottom, or from the lowest layer to the top.
When you work from the bottom to the top you check the physical layer first. As you determine that a layer is
operating properly, you move to the next layer, and so on, until you find the layer where the problem is
happening.
When you approach the problem from the top down, you check the application layer first. If a layer is not
working properly, you move to the layer below to rule out issues in the lower layers.

DO NOT REPRINT
© FORTINET
In a typical network, you can approach troubleshooting by systematically reviewing the settings of each layer
of the network. Working through the problem using the TCP/IP model or OSI model, is one approach that you
can take when reviewing issues. As you gain more experience, you may try to resolve issues by forming an
hypothesis and go through the resolution step by step. Issues are often very specific. An example is, an HA
sync issue, or a routing issue, where a routing protocol has a higher precedence over the static or dynamic
protocol. In a case like this, a good understanding of the routing flowchart will be very important. Of course, it
is also very important to understand the nuance of routing protocols. When OSPF is used, the hello timers
and dead interval must match on both ends, to form a neighbor relationship. In addition, the MTU size must
match. In FortiOS, there are other unique parameters and settings that must be configured “correctly” for
some features to work as expected.

DO NOT REPRINT
© FORTINET
Another step to narrowing down the issue and identifying the source is analyzing what could trigger the issue.
Figuring out how to reproduce the issue can be a very useful tool for gathering data.
After you have identified how to trigger the issue, as a next step, you can analyze what tools you can use to
collect debug data, for example, sniffer and CLI debug commands, logs, GUI widgets, and so on.

DO NOT REPRINT
© FORTINET
In this section, you will learn about the troubleshooting tools available on the GUI.

DO NOT REPRINT
© FORTINET
The status dashboard is the FortiGate GUI welcome screen. Some of the widgets on the status dashboard
contain information that is useful for troubleshooting, such as the CPU, Memory, and Bandwidth widgets, as
well as others.
Other default widgets on the dashboard include, Security, Network, User & Devices and WiFi. You can
configure custom widgets as well. These widgets can deliver useful information for monitoring and
troubleshooting FortiGate.

DO NOT REPRINT
© FORTINET
In addition the dashboard widgets, the GUI includes FortiView, where you can monitor screens for specific
features. For example, the FortiView Policies monitor lists the most active firewall policies. Another example
is the Routing monitor, which lists the routes that are active in the routing table.

DO NOT REPRINT
© FORTINET
Another important tool for troubleshooting is the FortiGate logs. The log viewer includes a filter setting that you
can use to display only the log entries related with a specific user name, IP address, URL, or event type.
Other logs, like System Events, can provide a source of data about FortiGate status when performing analysis
of FortiGate.

DO NOT REPRINT
© FORTINET
This table lists the expected log behavior associated with the different logging settings.
Moving from left to right, the first column shows the possible values for the log setting in the firewall policies:
no log, log security events, or log all sessions.
The second column indicates if the antivirus, web filtering, or email filtering log setting is enabled or disabled.
Remember, DLP and IPS profiles always generate logs in the security log section.
The last column shows the expected behavior. If you enable any profiles and your policy and logging is not
enabled, you will not get logs of any kind—even when profile is blocking traffic. So if you apply a security
profile, it’s important to consider the logging settings.

DO NOT REPRINT
© FORTINET
In this section, you will learn about CLI troubleshooting commands to gather data to diagnose an issue on
FortiGate.

DO NOT REPRINT
© FORTINET
FortiGate includes a number of CLI commands that help you monitor the current status of FortiGate and start
diagnosing an issue.
Some commands, such as diagnose sys top are useful to monitor process activity in real time.
While collecting debug data, execute tac report is a very useful command to collect initial data.

DO NOT REPRINT
© FORTINET
It is very useful for an administrator to be familiar with the fundamental debug commands used during
troubleshooting sessions. This helps to speed up the diagnosis and troubleshooting of a FortiGate.

DO NOT REPRINT
© 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. This depends on
each process. For all cases though, a debug level of 0 means no output (disabled), and a debug level of -1
means enabling all possible message types.

DO NOT REPRINT
© FORTINET
This slide shows the two commands 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 is important to disable any real-time debug application after using it. Debug applications consume FortiGate
resources and some could be CPU-intensive.

DO NOT REPRINT
© FORTINET
Application layer test commands do not display information in real time. They display 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.

DO NOT REPRINT
© FORTINET
FortiGate includes the sniffer command, which is a useful tool when troubleshooting requires you to dig further
to diagnose the source of the issue.
The sniffer command can sniff packets on physical or virtual interfaces. If the sniffer command is set to any, it
can sniff all available interfaces simultaneously.
You can use a filter to customize and narrow down the packets that you want to capture. The sniffer filter uses
Berkeley Packet Filters syntax.
The verbose setting has six verbosity levels:

• 1: print header of packets
• 2: print header and data from the IP header of the packets
• 3: print header and data from the Ethernet header of the packets
• 4: print header of packets with interface name
• 5: print header and data from IP of packets with interface name
• 6: print header and data from Ethernet of packets with interface name

DO NOT REPRINT
© FORTINET
Some CLI debug commands generate a lot of output. If you know that the required information is contained in
one specific line of the output, and if you know a keyword that you can use to find that line, you can use the
GREP utility. The GREP utility displays only the lines from the output that match a text string. Using the GREP
utility, you can reduce the output to only the one line (that contains exactly the information that you need),
instead of a long list of entries.

DO NOT REPRINT
© FORTINET
When you display the FortiGate configuration using 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, for example, when you need to find all the references to a specific object. In the example shown on this
slide, the –f option is being used to find all the references to the port1 interface. The output shows the two
tables where port1 is referenced: the definition of the interface itself, and a static route where port1 is the
assigned device interface.

DO NOT REPRINT
© FORTINET
This slide shows the objectives that you covered in this lesson.
By mastering the objectives covered in this lesson, you learned how to diagnose an issue with a FortiGate
device by using troubleshooting methods, and the appropriate GUI and CLI command tools.

System Resources
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about FortiOS System Resources.

System Resources
DO NOT REPRINT
© FORTINET
By demonstrating a competent understanding of FortiOS system resources, you will be able to identify how
FortiOS processes packets and uses memory. You will be able to also diagnose high-resource utilization and
conserve mode issues and optimize memory usage.

System Resources
DO NOT REPRINT
© FORTINET
In this section, you will learn about the life of a packet.

System Resources
DO NOT REPRINT
© FORTINET
PPP uses the firewall policy configuration to choose from a group of parallel options to identify the optimal path
for processing a packet. The path identified by PPP is made up of the various processes the packet must pass
through. Hardware, such as CP8, CP9, or network processors, can offload and accelerate many of these
processes. FortiGate hardware and software configuration affect the path that a packet takes. The next few slides
provide flowcharts displaying examples of packet processing in several scenarios. Note that these examples do
not cover all possible scenarios, nor do they show every step or process packets are subjected to during
inspection. The purpose of these slides is to provide common examples of packet flow on FortiGate.

System Resources
DO NOT REPRINT
© FORTINET
This slide shows the steps that the first packets of a session go through as they enter, pass though, and exit
FortiGate. This scenario is for FortiGate with SPUs.
FortiGate performs some security inspections early in the life of the packet, such as ACL, Host Protection Engine,
and IP integrity header checking. FortiGate does this to make sure the packets are within acceptable parameters
before allowing the packet to move through the rest of the processes. These inspections are handled by the
network processor in order to minimize impact on the FortiGate CPU.
Each version of the network processor has criteria that defines which traffic can be offloaded. The network
processor enhances overall performance by allowing offloaded sessions to bypass the FortiGate CPU after the
session is established and the session key is installed in the network processor. The network processor can also
handle IPsec VPN encryption and decryption operations, where the configured encryption and hashing algorithms
are supported in hardware.
The content processor functions like a co-processor for the FortiGate CPU to improve overall system
performance by offloading certain tasks, such as pattern matching for flow-based UTM inspection with the IPS
engine, SSL/TLS decryption and encryption for deep SSL inspection, and IPsec encryption and decryption
operations for supported algorithms.
Note that the packet processing for virtual FortiGate devices is identical with the only difference being that the
CPU handles all processes instead of being able to offload some of them to network and content processors.

System Resources
DO NOT REPRINT
© FORTINET
This slide shows how subsequent packets in an established session where UTM/NGFW inspection is not
configured are handled by FortiGate after being offloaded to a network processor. After the session key is
installed in the network processor, subsequent packets for the offloaded session skip routing and kernel
processors, bypassing the FortiGate CPU, and are forwarded out the egress interface by the network processor.
An important consideration is the impact offloading has on troubleshooting. When a session is offloaded to the
network processor, you are unable to view these accelerated packets through the diagnose sniffer packet
or diagnose debug flow CLI commands or the packet capture feature on the GUI.

System Resources
DO NOT REPRINT
© FORTINET
This slide shows how subsequent packets in an established session with flow-based UTM/NGFW configured are
handled by FortiGate where NTurbo and IPSA are supported and enabled.
NTurbo is a feature that enables flow-based UTM/NGFW sessions to be accelerated by NP6 or NP7 network
processors to and from the IPS engine.
IPSA is a feature that allows basic or advanced pattern matching operations required for flow-based security
profile inspection to be offloaded to CP8 or CP9 content processors. When IPSA is enabled, flow-based pattern
matching databases are compiled and downloaded to the content processors from the IPS engine and IPS
database.
After the session key is installed in the network processor, subsequent packets for the accelerated session skip
routing and kernel processors but UTM/NGFW operations are still handled by the CPU with IPSA offloading
pattern matching to the CP8 or CP9 content processors.

System Resources
DO NOT REPRINT
© FORTINET
This slide shows how subsequent packets in an established session with proxy-based UTM/NGFW configured
are handled by FortiGate.
The network processor does not offload sessions where proxy-based features are configured, so the FortiGate
CPU handles packet processing and inspection through a combination of the IPS engine and the FortiOS proxy.
The network processor still conducts some early security inspections before handing off the packets to the IPS
engine, and can still be leveraged for IPsec tunnel decryption and encryption.
The FortiGate CPU can leverage the content processors to handle SSL/TLS encryption and decryption—if SSL
deep inspection is configured. Note that the packet flow is modified when SSL deep inspection is configured.
If the IPS engine determines that the session needs to be decrypted:

• The IPS engine sends the packet to the proxy for decryption.
• The proxy decrypts the SSL/TLS packet by offloading the operation to the content processor.
• The proxy sends the decrypted packet back to the IPS engine for IPS and application control inspection.
• The IPS engine sends the decrypted packet back to the proxy for the configured proxy-based inspection.
• The proxy encrypts the SSL/TLS packet by offloading the operation to the content processor.

System Resources
DO NOT REPRINT
© FORTINET
In this section, you will learn about how FortiGate uses memory.

System Resources
DO NOT REPRINT
© FORTINET
To understand how FortiGate uses its memory, you must 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 on 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.

System Resources
DO NOT REPRINT
© FORTINET
FortiOS is a 64-bit architecture, therefore the kernel doesn't need to use memory paging to access the whole
memory space. All the memory space is directly accessible by the kernel.
The command shown on this slide displays:

• The total amount of system memory (MemTotal)
• The total amount of free memory (MemFree)

System Resources
DO NOT REPRINT
© 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.

System Resources
DO NOT REPRINT
© FORTINET
The kernel memory slabs are collections of objects with a common purpose. They are used by the kernel to store
information in 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 memory slabs.

System Resources
DO NOT REPRINT
© 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 then the size of each object.
You can calculate the total amount of memory allocated to each slab type by multiplying the number of available
objects by their size.

System Resources
DO NOT REPRINT
© FORTINET
There are no direct reads and writes made to hard disks or flash disks. Each access is done through a cache held
in memory—the system I/O cache.
The system I/O cache is used to speed up access to information stored in the hard and flash disk memories.
Some processes, such as logging, WAN optimization, and explicit proxy store information on 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 used or modified. It enters the inactive state
after it has not been used for some time. The kernel may reclaim an inactive page if needed.

System Resources
DO NOT REPRINT
© FORTINET
Use the command shown on this slide to display the total amount of memory allocated for the I/O cache. This
command is useful when troubleshooting high memory issues to determine where memory is being allocated. A
high amount of memory allocated to the I/O cache could indicate that too many logs are being created.

System Resources
DO NOT REPRINT
© FORTINET
Above the kernel layer, there are multiple application processes or daemons running. The operating system
allocates separate blocks of memory to each process. A process can access the memory that was allocated to it,
but it cannot access the memory that was allocated to any other 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). Multiple processes can access the SHM,
allowing them to share information.

System Resources
DO NOT REPRINT
© FORTINET
Next, examine the output for diagnose sys top. It lists processes that use the most CPU or memory. Some
common processes include:
• ipsengine, scanunitd, and other inspection processes

• reportd
• fgfmd for FortiGuard and FortiManager connections
• forticron for scheduling
• Management processes (newcli, miglogd, cmdb, sshd, and httpsd)
To sort the list by highest CPU usage, press c. To sort by highest RAM usage, press m.

System Resources
DO NOT REPRINT
© FORTINET
The table on this slide shows some of the most common processes.

System Resources
DO NOT REPRINT
© FORTINET
The table on this slide shows more of the most common processes.

System Resources
DO NOT REPRINT
© 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 the D state. The Z state is not normal.
Also, it is not normal if a process stays in the D state for a long time. This usually indicates that the process is not
working properly.

System Resources
DO NOT REPRINT
© FORTINET
In this section, you will learn about general system troubleshooting commands.

System Resources
DO NOT REPRINT
© FORTINET
The command shown on this slide 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.

System Resources
DO NOT REPRINT
© FORTINET
The command shown on this slide displays overall memory and CPU use. 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.

System Resources
DO NOT REPRINT
© FORTINET
The command shown on this slide displays overall memory and CPU use. 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.

System Resources
DO NOT REPRINT
© 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.

System Resources
DO NOT REPRINT
© FORTINET
This slide shows the two commands you use to enable the IPsec real-time debug output. You can also enable the
option to prepend the system time to each debug line. It is important to disable any real-time debug after using it
because they consume FortiGate resources and some can be CPU intensive. The command diagnose debug
reset resets any filters that are configured for debugging, and disables debug output for all administrators
currently running debugs on FortiGate.

System Resources
DO NOT REPRINT
© 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.

System Resources
DO NOT REPRINT
© FORTINET
In this section, you will examine conserve mode, now that you have a better understanding of how FortiGate uses
memory.

System Resources
DO NOT REPRINT
© FORTINET
Conserve mode is a protection mechanism that is triggered when FortiGate doesn’t have enough memory
available to handle traffic. Content inspection (especially proxy-based) increases memory use beyond simple
firewall policies. In other words, when antivirus is enabled, FortiGate is more likely to use more memory, which
can cause FortiGate to enter conserve mode. You can identify whether antivirus or any other process is using too
much memory by running the CLI command diagnose sys top.
FortiGate has only one conserve mode. It is triggered based on memory usage. There are three memory
thresholds that you can configure on the CLI:
• Extreme: The threshold at which FortiGate starts dropping new sessions.
• Red: The threshold at which FortiGate enters conserve mode.
• Green: The threshold at which FortiGate exits conserve mode.

System Resources
DO NOT REPRINT
© FORTINET
You can use the commands shown on this slide to change the default conserve mode threshold values.

System Resources
DO NOT REPRINT
© FORTINET
This slide shows the entries that are generated in the event logs when FortiGate enters memory conserve mode.
If the GUI is under a heavy load, it may be unresponsive, making the GUI logs inaccessible. In this case, you can
view the crash log on the CLI for conserve mode messages. This slide shows an example of a typical conserve
mode crash log entry.

System Resources
DO NOT REPRINT
© FORTINET
What actions does FortiGate take to preserve memory while in conserve mode?
• FortiGate does not accept configuration changes, because they might increase memory usage.
• FortiGate does not run any quarantine action, including forwarding suspicious files to FortiSandbox.
• FortiGate activates protection measures to recover memory space.

System Resources
DO NOT REPRINT
© FORTINET
The av-failopen setting defines the action that is applied to any proxy-based inspected traffic, while the unit
is in conserve mode (and as long as the memory usage does not exceed the extreme threshold). This setting also
applies to flow-based antivirus inspection. Three different actions can be configured:
• off: All new sessions with content scanning enabled are not passed but FortiGate processes the current
active sessions.
• pass (default): All new sessions pass without inspection until FortiGate switches back to non-conserve mode.
• one-shot: Similar to pass in that traffic passes without inspection. However, it will keep bypassing the
antivirus proxy even after it leaves conserve mode. Administrators must either change this setting, or restart
the unit to restart the antivirus scanning
However, if memory usage exceeds the extreme threshold, new sessions are always dropped, regardless of the
FortiGate configuration.

System Resources
DO NOT REPRINT
© FORTINET
Use the command shown on this slide to identify whether a FortiGate device is currently in conserve mode.

System Resources
DO NOT REPRINT
© FORTINET
Another undesirable state for FortiGate is the AV fail-open session mode. This mode kicks in, not during a high-
memory situation, but when a proxy on FortiGate runs out of available sockets to process more proxy-based
inspected traffic.
If av-failopen-session is enabled, FortiGate allows all the sessions. Otherwise, by default, it blocks new
sessions that require proxy-based inspection until new sockets become available.

System Resources
DO NOT REPRINT
© 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 shown on this slide displays the
numbers of sessions deleted by the kernel because of this mechanism.

System Resources
DO NOT REPRINT
© FORTINET
FortiGate has a mechanism to protect memory use 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 a UDP session with only one packet received. During some DoS attacks,
the number of these types of sessions tends to increase abnormally, potentially consuming the device’s memory.
FortiGate sets a hard limit on the maximum number of ephemeral sessions that can exist at the same time in the
session table.

System Resources
DO NOT REPRINT
© FORTINET
In this section, you will learn how to optimize memory use by fine-tuning the FortiGate configuration.

System Resources
DO NOT REPRINT
© FORTINET
Many FortiGate processes, such as DLP or antivirus scanning, are memory-intensive. So, memory optimization is
important, especially in small devices, to guarantee that these processes do not force FortiGate into memory
conserve mode. This slide shows some recommendations for optimizing memory use. These tips might
significantly increase the available memory in a device that is frequently entering 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 device for antispam, an administrator does not need to configure antispam on FortiGate. Also, usually
not all IPS signatures are required.
Another recommendation is to reduce the maximum file size to inspect, which is set to 10 MB by default. You can
reduce this value to 2 or 3 MB without significantly reducing the virus catching rate, because a typical virus size is
less than 1 MB.

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

System Resources
DO NOT REPRINT
© 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 a TTL this high 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 more quickly, increasing the amount of
available memory.
There are four places in the FortiGate configuration where you can reduce the session TTL. Two of them are:
• Globally, for all the traffic
• On an IP protocol and port number basis

System Resources
DO NOT REPRINT
© FORTINET
The other two places where you can reduce the session TTL are:
• 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, you can
also set it to a higher number for the specific application port number, firewall policy, or with an application control
application override entry by setting the session-ttl option using the CLI.

System Resources
DO NOT REPRINT
© FORTINET
You can also reduce most TCP session timers 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 use.
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.

System Resources
DO NOT REPRINT
© FORTINET
In this section, you will learn how to troubleshoot system crashes.

System Resources
DO NOT REPRINT
© FORTINET
On some FortiGate models, you can configure the device to store all console logs in the flash memory. This is
especially useful when troubleshooting unexpected restarts and devices that randomly become unresponsive.
Once FortiGate stores the logs, you can display them on the CLI or download them from the GUI for further
analysis.
This slide shows the commands for enabling, displaying, and clearing the console logs.

System Resources
DO NOT REPRINT
© FORTINET
A crash dump message is usually generated through the console port when the device crashes. Crash dump
messages can provide useful information to Fortinet developers. If the problem is a FortiGate device that is
restarting unexpectedly, you should check the logs, the console logs, and the crash log. If the FortiGate model
doesn’t support a console log, keep a laptop connected to the console port and wait until another crash happens.

System Resources
DO NOT REPRINT
© FORTINET
FortiGate freezes when it stops handling traffic, you cannot connect to it, and you can’t access its console port.
Only power cycling fixes the issue. In these cases, you could capture any crash dump message 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 causes a crash in the system (and forces the crash dump) when no new daemons have been
scheduled in the last 10 minutes. This is an indication that the device is not operating normally and might be
frozen.
Some FortiGate models also have an external NMI button. If the device freezes and no crash dump message was
generated, you can press the NMI button to force a crash and generate a crash dump message.

System Resources
DO NOT REPRINT
© FORTINET
Each time an application crashes, or closes, an entry is generated in the crash log. 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 crash log. In this example, the application that failed was the
miglogd process, which handles logging. The termination signal is 11, which is a segmentation fault.

System Resources
DO NOT REPRINT
© FORTINET
The table shown on this slide contains the most common termination signal numbers. Any administrator can
manually terminate a process by using the command shown on this slide, followed by the termination signal
number and the process ID. The command diagnose sys top lists the process ID numbers. Manually
terminating a process is not usually required under normal circumstances. If you must terminate a process, use
the termination signal 9. Improperly terminating a process can make a FortiGate system unstable.
Note that not all the signal numbers generate a crash log.
Processes can also be killed through the GUI under admin > System > Process Monitor. If you want to
generate a crash log, select Kill&Trace in the Kill Process drop-down menu.

System Resources
DO NOT REPRINT
© FORTINET
So, how do you know if the crash log is normal or not?
In most cases, entries in the crash log are normal. You can consider a crash log entry to be suspicious if it
happens at the same time as a failure in a FortiGate feature, or abnormal behavior of FortiGate.
For example, a crash log entry that is generated when the device unexpectedly restarts, might provide
information about the cause. A crash in the sslvpnd process when all SSL VPN users get disconnected is also
relevant. The crash log includes the details about the crash and information that can be used by Fortinet support
to identify which code triggered the problem.

System Resources
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to use and optimize FortiOS system
resources.

Sessions, Traffic Flow, and Networking
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about traffic and session monitoring.

DO NOT REPRINT
© FORTINET
After completing this section, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in traffic and session monitoring, you will be able to interpret the information in the
session table, capture traffic using the built-in sniffer, analyze the output of the debug flow, and configure and
troubleshoot session helpers and the SIP application layer gateway.

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

DO NOT REPRINT
© FORTINET
The FortiGate session table contains detailed information about every IP connection that crosses or terminates at
FortiGate. You can use the commands shown on this slide to display the total number of sessions in an active
VDOM, and to view a brief summary of each session. The session list 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.

DO NOT REPRINT
© FORTINET
To display detailed information about sessions, use the command shown on this slide. It is recommended that
you set the session filter first, because 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.

DO NOT REPRINT
© 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 shown on this slide 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
clearing out any sessions, use appropriate filters.

DO NOT REPRINT
© FORTINET
This slide shows an example output detailing information particular to a single session table entry. From left to
right, and from top to bottom, the following information is highlighted:
• The IP protocol number and the protocol state

• The length of time until the session expires (if no more traffic matches the session)
• Traffic shaping counters
• Session flags
• Received and transmitted packet and byte counters
• The original and reply direction of the traffic. If the device is using NAT, this portion shows the type of NAT
(source or destination) for each traffic direction, and the NAT IP address.
• The ID of the matching policy
• Counters for hardware acceleration—The presence of the npu info field indicates the session has been
offloaded to hardware acceleration.
Use the CLI command diagnose sys session list for IPv4 traffic, and the command diagnose sys
session6 list for IPv6 traffic.
The output for both commands is similar (it displays the same fields, in the same order).

DO NOT REPRINT
© FORTINET
The protocol state in the session table is a two-digit number. For TCP, the first number (from left to right) is
related to the server-side state and is 0 when the session is not subject to any inspection (flow or proxy). If flow or
proxy inspection is done, then the first digit is different from 0. The second digit is the client-side state.
The table and flow graph shown on this slide correlate the digit value with the different TCP session states. The
values apply for both server-side and client-side states. For example, for the client-side state, when FortiGate
receives the SYN packet, the second digit is 2. It changes to 3 when FortiGate receives the SYN/ACK packet.
Similarly, for the server-side state, the first digit is 2 after FortiGate sends the SYN packet, and then changes to 3
after FortiGate sends the SYN/ACK packet. In addition, proto_state=11 means that the TCP three-way
handshake for both server-side and client-side is completed (ESTABLISHED).
When a session is closed by both the sender and receiver, FortiGate keeps that session in the session table for a
few seconds, to allow for any out-of-order packets that might arrive after the FIN/ACK packet. This is the state
value 5.

DO NOT REPRINT
© FORTINET
For UDP, the session state can have only 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.

DO NOT REPRINT
© 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 originates from FortiGate or terminates on
FortiGate.

DO NOT REPRINT
© FORTINET
When working with FortiGate, it’s important to understand the concept of may_dirty and dirty sessions.
The may_dirty sessions are firewall sessions that were created after matching a firewall policy with accept
as action. For FortiGate to identify the matching policy, it performs a firewall policy lookup, selecting the first
matching policy in the configuration from the top down. Most firewall sessions contain the may_dirty flag.
However, some sessions such as expectation sessions, do not contain the may_dirty flag because they are not
created as a result of matching a firewall policy.
For new sessions, FortiGate performs route and firewall policy lookups upon receiving the first packet (in the
original direction). FortiGate also performs a route lookup—but not a firewall policy lookup—for the first reply
packet. FortiGate then saves the information that results from the route lookup—the outgoing interface and
gateway to use—and the firewall policy lookup—policy ID, address translation, inspection, authentication, logging,
and so on—to the session.
FortiGate doesn’t perform additional lookups for the session unless, the session is flagged as dirty.

DO NOT REPRINT
© FORTINET
By default, FortiGate flags all may_dirty sessions as dirty if there is a routing, firewall policy, or interface
change. The FortiGate must re-evaluate every dirty session. During re-evaluation, it checks both directions of the
dirty session.

DO NOT REPRINT
© FORTINET
After a routing change, the routing information of impacted sessions is flushed. The default re-evaluation process
following a routing change for sessions without source NAT (SNAT) is as follows:
• If the impacted session is offloaded to the NPU, FortiGate instructs the NPU to send the next packet from each
direction of the session to the CPU. This ensures that the session is handled by the CPU, and thus re-
evaluated. If the session is not offloaded to the NPU, then the packets are always handled by the CPU, and
this step is not required.
• In the original direction, FortiGate performs route and firewall policy lookups for the first packet.
• In the reply direction, FortiGate performs only a route lookup for the first packet.
• FortiGate updates the session with the new routing and firewall policy information, and removes the dirty
flag.
• If the matching firewall policy action is still accept, FortiGate forwards the packet.
• If the matching firewall policy action is deny, FortiGate flags the session as block, drops the packet, and
retains the session in the session table until it expires. FortiGate also drops any additional packets that match
the session .
• FortiGate eventually offloads allowed sessions again to the NPU, if they still meet the NPU offloading
requirements.

DO NOT REPRINT
© FORTINET
This slide shows the transition of an ICMP session from may_dirty to dirty, and then back to may_dirty,
following a route change. Note that only relevant lines of the session are displayed.
Before the route change, the session is flagged as may_dirty. The session output shows the index number of
the outgoing interface in use (19), as well as the gateway information (gwy).
After the route change, the session is flagged as dirty. Note that the may_dirty flag is still there, and the
dirty flag is just added. The gateway information is also flushed.
After re-evaluation, the dirty flag is removed, and the index number of the outgoing interface and the gateway
information are updated based on the new route.
Note that the firewall policy (policy_id) didn’t change. This is because the firewall policy lookup during re-
evaluation resulted in the same firewall policy, but this is not always the case.

DO NOT REPRINT
© FORTINET
By default, SNAT sessions are not flagged as dirty following a routing change that impacts the session. This is
true if the route in use is still in the FIB. However, if the route is removed from the FIB, then FortiGate flags the
session as dirty, flushes the outgoing interface and gateway information, and then re-evaluates the session on
the next packet received.
To force the re-evaluation of SNAT sessions following a related routing change, regardless of whether the route
in use is still in the FIB or not, enable the snat-route-change setting, as shown on this slide.
Note that during re-evaluation of SNAT sessions, if the new route and firewall policy lookup results in a change of
the SNAT IP, then FortiGate drops the packet and clears the session. This means that the impacted application
could have to initiate a new connection to resume network connectivity, especially if the application is TCP-based.
This slide shows the debug flow output for an SNAT session during re-evaluation. Because the SNAT IP of the
new path (192.2.0.9) is different from the SNAT IP of the current path (192.2.0.1), FortiGate drops the
packet and clears the session. This also means that, from a connectivity point of view, it makes sense to enable
snat-route-change only when the new path for the session uses the same SNAT IP, which can be achieved
using IP pools.

DO NOT REPRINT
© FORTINET
When you make a change to a firewall policy, all existing sessions with the flag may-dirty change to status
dirty. FortiGate then performs a firewall policy lookup for the first packet received for each existing session; it
updates the session table entry and resets the flag to may-dirty. Then, it processes the next packets based on
the new firewall settings.
If the firewall handles a huge number of sessions, flagging the sessions as dirty, and performing a firewall
policy lookup for the sessions may result in high CPU utilization. To prevent this, you can configure FortiGate to
flag only new sessions as dirty by setting firewall-session-dirty to check-new. The result is that
FortiGate evaluates only new sessions against the new firewall policy configuration.
The firewall-session-dirty setting is available on the VDOM and firewall policy levels. It is set to check-
all by default, which instructs FortiGate to flag all sessions as dirty. To instruct FortiGate to follow the firewall
policy-level setting, you must set the VDOM-level setting to check-policy-option. Note that the firewall
policy-level setting is available only if the VDOM-level setting is set to check-policy-option.

DO NOT REPRINT
© FORTINET
This slide shows the details of an established SSH session when firewall-session-dirty is set to check-
new.
Note the presence of the persistent flag in the session, and the absence of the may_dirty flag, which
indicates that FortiGate does not perform a new firewall policy lookup if there is a configuration change.

DO NOT REPRINT
© FORTINET
In this section, you will learn about two useful troubleshooting tools: the built-in sniffer and the debug flow, and
how they are affected by hardware acceleration.

DO NOT REPRINT
© FORTINET
Now you will learn about the built-in sniffer. When you enable this tool, you can choose from six verbosity levels.
The table on this slide shows what information is displayed in each level. Level 4 is usually used to check how the
traffic is flowing and that FortiGate is not dropping packets. Level 3 or level 6 are usually used to convert the
output to PCAP format, which you can later analyze with a tool, such as WireShark.

DO NOT REPRINT
© 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.
If you do not specify an option for the timestamp, the debug shows the time, in seconds, since it started running.
As you learned earlier in the lesson, you can prepend the local system time to easily correlate a packet with
another recorded event.

DO NOT REPRINT
© FORTINET
In the GUI under Network > Diagnostics > Sniffer, you can perform the same function as on the previous slide
without using a CLI command. You also have the option to save the captured packets as a PCAP.

DO NOT REPRINT
© FORTINET
Another useful FortiGate troubleshooting tool is the debug flow.
The debug flow is also called the 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.

DO NOT REPRINT
© FORTINET
This slide shows an example of a debug flow output. In this example, the debug flow has captured the three
packets of a TCP three-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 applied.

DO NOT REPRINT
© FORTINET
The debug flow can also help you identify 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 (policy 0) indicates that either no firewall policy allows the
traffic, or that a disclaimer has not been accepted yet.
• Denied by quota check indicates that the packet was dropped because of a traffic shaper that has
exceeded one of its thresholds.

DO NOT REPRINT
© 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 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.

DO NOT REPRINT
© FORTINET
Just like with the sniffer tool, there is the option to run the debug flow in the GUI. Once completed, the output can
be saved as a CSV file.

DO NOT REPRINT
© FORTINET
In order for the packet sniffer and debug flow to pick up traffic, all packets must hit the CPU. This can be
accomplished by disabling hardware acceleration. As a best practice, this is only done for troubleshooting
purposes. Permanently disabling hardware acceleration will significantly decrease the performance of a FortiGate
device.
Hardware acceleration can be disabled at the firewall level or the global level.
Once disabled, all packets are processed by the CPU, and the sniffer and debug flow will be able to display traffic
flow information.

DO NOT REPRINT
© FORTINET
Hardware acceleration can be disabled at the firewall level by setting auto-asic-offload to disable. This
can be useful when the scope of troubleshooting traffic is known to be specific to one firewall policy.
It is also possible to disable hardware acceleration globally.

DO NOT REPRINT
© FORTINET
There are two ways to disable hardware acceleration globally. The first way is to disable it using the diagnose
command shown on this slide. Depending on the FortiGate model, one or more NP6 units must be disabled. In
this example, the partial output of diagnose npu np6 port-list on a FortiGate 1500D is shown. Since this
is a diagnose command, fastpath is automatically re-enabled when the FortiGate reboots.
The second way to disable hardware acceleration globally is to use the config command shown on this slide.
Fastpath is enabled by default. This will disable all network processor offloading for all traffic.
Be aware that disabling hardware acceleration globally could have a significant impact on CPU performance.
Disabling hardware acceleration should only be considered for troubleshooting purposes. It is recommended to
re-enable hardware acceleration, once troubleshooting has been concluded.

DO NOT REPRINT
© FORTINET
In this section, you will learn how FortiGate can create sessions for traffic that is expected to come but hasn't
arrived yet.

DO NOT REPRINT
© FORTINET
To understand what a session helper does, take a look at the example shown on this slide of a network protocol
that might have problems when a network device is performing NAT. The example shows the 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.

DO NOT REPRINT
© FORTINET
Active FTP does not work if the control channel crosses a network device performing NAT, and that does not
have a session helper. In the example shown on this slide, 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.
After 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 because it is a private IP
behind a device performing NAT.
The file transfer fails.

DO NOT REPRINT
© FORTINET
The FTP session helper fixes this problem by replacing the router with a FortiGate device. The following
paragraph describe what the FortiGate session helper does.
When the packet with the FTP port command arrives at FortiGate, 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 temporarily create an expected session (or pinhole) for the
data channel connection that comes 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 port numbers).
The session helper automatically creates the session and opens the door for the incoming 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.

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

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

DO NOT REPRINT
© 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
the example shown on this slide, there are two SIP phones with the IP addresses 10.0.1.10 and
172.168.100.205. Additionally, FortiGate is performing 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 are
connected through the four expected sessions. Firewall policies are not needed to allow this traffic.

DO NOT REPRINT
© FORTINET
There is a way to list the expected sessions created by the session helpers. In the example shown on this slide,
the command lists an expected session to allow traffic from 10.171.121.38 to 100.64.1.1, port TCP 60426.

DO NOT REPRINT
© 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.

DO NOT REPRINT
© FORTINET
There are other protocols that, in some circumstances, also require a session helper. Examples includes PPTP,
H323, and RSH. You can list the active session helpers by using the command shown on this slide. 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-helper entry or add a new entry.

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

DO NOT REPRINT
© 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), FortiGate uses the SIP ALG. If it is set to kernel-helper-based, FortiGate uses the SIP
helper.
If the SIP traffic matches a firewall policy with a VoIP profile, FortiGate always uses the SIP ALG, regardless of
the default-voip-alg-mode setting.
Fortinet recommends that FortiGate use the SIP ALG. FortiGate should use the SIP helper only when the SIP
ALG is not working as expected.

DO NOT REPRINT
© FORTINET
This slide shows 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.

DO NOT REPRINT
© FORTINET
You can display all active SIP calls, and disconnect any active SIP calls, using the commands shown on this
slide.

DO NOT REPRINT
© FORTINET
You can use sip real-time debugs to display real-time information about SIP traffic.

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned about traffic and session monitoring.

Security Fabric
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about the Fortinet Security Fabric.

Security Fabric
DO NOT REPRINT
© FORTINET
By demonstrating competence in the Security Fabric, you will be able to describe what the Security Fabric is, the
protocols it operates on, and how to troubleshoot common communication and resource issues. You will also
learn how to diagnose automation stitches.

Security Fabric
DO NOT REPRINT
© FORTINET
In this section, you will get a quick overview of the Security Fabric.

Security Fabric
DO NOT REPRINT
© FORTINET
The Security Fabric provides an intelligent architecture that allows security devices to communicate with each
other. This integrated approach allows for the detection, monitoring, and remediation of attacks across the entire
attack surface.
Hardware, virtual, and cloud-based systems are supported, delivering broad protection and visibility throughout
the network.

Security Fabric
DO NOT REPRINT
© FORTINET
At the core of the solution, the mandatory products are two or more FortiGate devices in NAT mode and a logging
system. The logging system must be FortiAnalyzer, FortiAnalyzer Cloud, or FortiGate Cloud.
Note that all FortiGate devices must be operate in NAT mode in order to participate in the Security Fabric.
To add more visibility and control, Fortinet recommends adding FortiManager, FortiAP, FortiClient, FortiSandbox,
FortiMail, and FortiSwitch. You can extend the solution by adding other network security devices.

Security Fabric
DO NOT REPRINT
© FORTINET
The Security Fabric uses two Fortinet proprietary protocols: FortiTelemetry and Neighbor Discovery.
The default TCP port 8013 for FortiTelemetry can be changed if necessary. In order for a downstream FortiGate
to join the Security Fabric, it must initiate the session to the upstream FortiGate through TCP port 8013. For an
upstream FortiGate to be able to accept connections from a downstream FortiGate, the Security Fabric
Connection setting must be enabled on the network interface (on the GUI under Administrative Access).
UDP port 8014 is used for the Neighbor Discovery protocol. This protocol and port are used to exchange
informational updates, such as topology changes, among Security Fabric member nodes. It is also used to control
logging behavior, so that the same traffic is not logged multiple times. Only FortiGate, or the device connected to
the source of the session, creates the log. Unlike the FortiTelemetry port, the Neighbor Discovery port cannot be
changed.

Security Fabric
DO NOT REPRINT
© FORTINET
In this section, you will learn about FortiGate-to-FortiGate communications within the Security Fabric, as well as
how to diagnose and troubleshoot potential issues.

Security Fabric
DO NOT REPRINT
© FORTINET
The screenshot on this slide shows a communication issue between an upstream FortiGate and a downstream
FortiGate. Some common causes of this issue include:
• The Security Fabric Connection setting has not been enabled on the upstream FortiGate GUI (under
Administrative Access).
• The FortiGate devices in the Security Fabric are not using the same firmware.
• The device has not been authorized on the root FortiGate yet.
• The wrong root FortiGate IP address is configured on the downstream FortiGate.
• The FortiGate is not configured in NAT mode.
• TCP port 8013 is blocked. You can use the diagnose sniffer command to verify this.

Security Fabric
DO NOT REPRINT
© FORTINET
The first step in troubleshooting communication issues related to the Security Fabric is to run a sniffer on TCP
port 8013 or UDP port 8014. In this example, the downstream FortiGate with the the IP address 192.168.1.112
is unable to establish a connection with the upstream FortiGate configured with 192.168.1.111. Since you can
see the traffic arriving on the upstream FortiGate, TCP port 8013 is not blocked along the way. Instead,
FortiTelemetry has not been enabled on the appropriate interface.

Security Fabric
DO NOT REPRINT
© FORTINET
After you select the Security Fabric Connection checkbox, and then apply the changes, FortiTelemetry
becomes active on the FortiGate interface, which allows incoming Security Fabric connection requests to be
accepted. The downstream FortiGate has successfully established a connection with the upstream FortiGate.

Security Fabric
DO NOT REPRINT
© FORTINET
Use the command diagnose test app csfd 1 to confirm that two ore more devices in the Security Fabric
are communicating properly. The command lists Security Fabric statistics, such as all upstream and downstream
devices, including their IP address, serial number, and status. In this example, the command was run on a
FortiGate connected to an upstream FortiGate as well as a downstream FortiGate.

Security Fabric
DO NOT REPRINT
© FORTINET
On this slide, you can see the differences when the command is run on the root FortiGate. The group name is
shown, and no upstream information is available, because this FortiGate sits at the top of the topology.

Security Fabric
DO NOT REPRINT
© FORTINET
Use the commands shown on this slide on a non-root FortiGate to view detailed information about upstream and
downstream devices.

Security Fabric
DO NOT REPRINT
© FORTINET
The command diagnose sys csf global shows a summary of all connected devices in the Security Fabric.

Security Fabric
DO NOT REPRINT
© FORTINET
In this section, you will learn how to troubleshoot performance issues related to the Security Fabric.

Security Fabric
DO NOT REPRINT
© FORTINET
Use the real-time application debug shown on this slide to troubleshoot issues as they are occurring.
For example, if the GUI lags during login, run the debug before navigating to the FortiGate management IP.
This same debug can also be used to troubleshoot communication issues. In this output, you can see
communication with the downstream FortiGate. The downstream FortiGate always establishes the Security
Fabric session with the upstream FortiGate. This is why the TCP source port in this example is 11405, not 8013.

Security Fabric
DO NOT REPRINT
© FORTINET
When csfd causes high CPU usage, use the same real-time debug. In addition, it is helpful to gather the output
that the three additional diagnose commands shown on this slide provide. All three commands dump CPU
information about the csfd process, which can reveal a potential bug.
You can find the process ID of csfd by running the diagnose sys top command.

Security Fabric
DO NOT REPRINT
© FORTINET
When troubleshooting high memory usage issues caused by csfd with Fortinet Support, you should collect the
output of the commands shown. Each command output contains valuable information about the cause of the high
memory use. Note that the diagnose test application command is not a real-time debug and therefore
will not cause additional performance impacts on FortiGate.

Security Fabric
DO NOT REPRINT
© FORTINET
In this section, you will learn about automation stitches and how to troubleshoot them.

Security Fabric
DO NOT REPRINT
© FORTINET
Administrator-defined automated workflows (called stitches) use if/then logic to cause FortiOS to automatically
respond to an event in a preprogrammed way. Because this workflow is part of the Security Fabric, you can set
up stitches for any device in the Security Fabric. If you configure stitches in a Security Fabric, you must configure
them on the root FortiGate. You configure stitches to run on all FortiGate devices in the Security Fabric or a
subset of FortiGate devices. Stitches configured on the root FortiGate are pushed to the relevant leaf FortiGate
devices. The root FortiGate does not need to be operational for previously configured stitches to function on leaf
FortiGate devices.
Each automation stitch pairs an event trigger and one or more actions, which allows you to monitor your network
and take appropriate action when the Security Fabric detects a threat or other actionable event. You can use
automation stitches to detect events from many sources. Some examples include high CPU, conserve mode, HA
failover, reboot, FortiOS event logs with customizable filters, IoCs, and event handlers from FortiAnalyzer.
You can configure the Minimum interval (seconds) setting to make sure you don’t receive repeat notifications
about the same event.
There are several CLI commands available to test, log, and display settings and statistics. These commands will
be covered in this lesson.

Security Fabric
DO NOT REPRINT
© FORTINET
You can use the diagnose automation test command to manually test an automation stitch. The resulting
output reveals whether or not the test was successful. Reasons for a failed test include the wrong stitch name
was used or the stitch was unable to perform one or more actions.

Security Fabric
DO NOT REPRINT
© FORTINET
The real-time application debug shown on this slide can be used to troubleshoot automation stitches as they are
running.

Security Fabric
DO NOT REPRINT
© FORTINET
Use the diagnose test application autod 1 command to toggle log dumping. Executing the command
once enables the log dump. Executing it again outputs the dump, while simultaneously disabling it.

Security Fabric
DO NOT REPRINT
© FORTINET
The diagnose test application autod 2 command displays the settings for all automation stitches.

Security Fabric
DO NOT REPRINT
© FORTINET
The diagnose test application autod 3 command provides detailed statistics on every automation
stitch configured in the Security Fabric.

Security Fabric
DO NOT REPRINT
© FORTINET
The output of the diagnose test application autod 5 command shows the number of stitches currently
running. It also shows how many stitches have been successfully or unsuccessfully completed.

Security Fabric
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned about the Security Fabric.

Firewall Authentication
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about firewall authentication and how to troubleshoot issues.

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding firewall authentication, you will be able to understand how to
monitor the status of authenticated users and troubleshoot the most common problems with local, LDAP, and
RADIUS authentication.

DO NOT REPRINT
© FORTINET
In this section, you will learn about local authentication troubleshooting commands.

DO NOT REPRINT
© FORTINET
When a problem occurs, the first thing that you should do is define the problem. The first step in
troubleshooting authentication problems is to collect specific information so that you can narrow the scope of
the problem. Is the problem occurring for more than one user? Is the problem related to user authentication
and not to user permissions?
The first place you should check is the logs. What do they show? Is the username correct? Is the traffic being
blocked after the authentication? What user profile is assigned to the user?
In the case of remote server authentication (such as RADIUS or LDAP), you should also check the logs on the
server side. In remote server authentication cases, FortiGate authentication depends on the server response.
If the RADIUS credentials are invalid, what do the RADIUS server logs show? Is the user account still active
on the RADIUS server?

DO NOT REPRINT
© FORTINET
This slide shows an example of the Firewall User Monitor. A log and event can be generated each time a user
authentication action is successful or fails. This FortiView menu is not included on the GUI menu by default,
you must enable it.

DO NOT REPRINT
© FORTINET
You can check the list of active users on the GUI or CLI. On the CLI, the command is diagnose firewall
auth list. You can filter the output with the command diagnose firewall auth filter. In the
example on this slide, you can see some of the filter options that are available.

DO NOT REPRINT
© FORTINET
Any session for traffic coming from an authenticated user contains the authed flag. Additionally, the
username is added to the session information.

DO NOT REPRINT
© FORTINET
There is a real-time debug for troubleshooting problems that are related to any user authentication methods:
local, remote, and even FSSO. The debug command is diagnose debug application authd.

DO NOT REPRINT
© FORTINET
In this section, you will learn about troubleshooting commands and common issues with LDAP authentication.

DO NOT REPRINT
© FORTINET
Now you will have a quick review of the LDAP protocol.

The hierarchy of an LDAP schema is not required to resemble the organization. However, the naming
conventions and group structure is usually a close match to the company hierarchy.
On this slide, you can see the root or DC. In any LDAP schema, this is where an LDAP tree always starts.
After that, the groups (or branches) are defined using C, OU, or O. The exact behavior and options used
depend on the schema and what exactly is being defined. Branches may contain objects and each object
contains attributes. Objects are uniquely identified by their distinguished names (DNs). The full DN specifies
where the object is, and the name and value of an attribute that can be used to find it.

DO NOT REPRINT
© FORTINET
There are three different methods, or bind types, that FortiGate can use to access an LDAP server: simple,
anonymous, and regular. In this lesson, you will learn about regular bind, which is the most complex, versatile,
and commonly used method.
There are four steps to LDAP authentication using regular bind. First, FortiGate logs in to (binds to) the LDAP
server using an LDAP administrator account. At this point, FortiGate knows only the username, but it doesn't
know the branch where the user is located. During the second step, FortiGate does a search query in the
LDAP database to find the user’s location―in other words, the user’s DN. If the user is found, the server
replies with the user’s DN. After that, FortiGate logs out of (unbinds from) the LDAP server.
The third step is another bind, but this time using the user credentials. FortiGate sends the DN, which it
learned in the previous step, and password.
The last step is to get the user group information. How this is done depends on the type of LDAP server, but it
is generally achieved through an LDAP query.
When you are isolating an issue with LDAP, the first step is to determine which of these four steps is failing.

DO NOT REPRINT
© FORTINET
Most LDAP authentication issues are caused by misconfigurations. So, now you will learn how to check if the
regular-bind LDAP configuration is correct. You will analyze a use case in which an LDAP server is based on
Windows AD, which is the most common use case.
Misconfigurations usually occur in one of these LDAP settings:

• Common Name Identifier
• Distinguished Name
• Username
• Password

DO NOT REPRINT
© FORTINET
How do you check if the DN is configured correctly? You can run either of these two commands in the
Windows AD server command prompt:
• dsquery user –name <full_user_name>
• dsquery user –samid <login_username>
The output displays the user DN. The DN configuration specifies a parent branch that all users are located
under. FortiGate searches users in any sub-branch below the parent branch. In the example on this slide, the
DN settings are: dc=california,dc=fortinet,dc=com.

DO NOT REPRINT
© FORTINET
The user DN (or bind DN) setting is the full DN of the LDAP admin account.
You can use the Windows LDAP server command (dsquery) to find that information.

DO NOT REPRINT
© FORTINET
You can simply copy and paste the full DN output from the server command prompt to the FortiGate
configuration.

DO NOT REPRINT
© FORTINET
This is a summary of how to properly configure regular bind for Windows AD. A different type of LDAP server
might require a different approach.
You usually set the Common Name Identifier to CN or sAMAccountName. If you set it to CN, users must
authenticate using their full names (for example, John Smith). If you set it to sAMAccountName, users must
authenticate using their login names (for example, jsmith).
You can find the DN that you must type in the Distinguished Name field by querying the user’s DN with the
Windows AD command dsquery.
You can find the information that you must type in the Username field by querying the admin DN with the
same Windows AD command dsquery.
Finally, the password setting is the LDAP administrator password.

DO NOT REPRINT
© FORTINET
The CLI includes an LDAP authentication test command, which is diagnose test authserver ldap. If
both the credentials and LDAP configuration are correct, you receive an authentication confirmation, as well
as a list of the user groups for that user.
You can run this test command as soon as you complete the LDAP server configuration—even before you
add any user groups, or authentication firewall policies are added to FortiGate. The command tests only the
LDAP server configuration and LDAP communication between FortiGate and the server.

DO NOT REPRINT
© FORTINET
There is a real-time debug for LDAP and RADIUS. This slide shows a sample of the output you will see when
the configuration is correct.
A start_search_dn message indicates that FortiGate is performing step two: searching for the user in the
LDAP tree. This message includes the base branch (distinguished name setting) and the name of the
attribute used to locate the user (common name identifier setting).
If the LDAP server finds the user, the output shows Found DN, followed by the user’s full DN.

DO NOT REPRINT
© FORTINET
After that, FortiGate performs the third step: binding using the user credentials.
Finally, the output shows the fourth step: getting the list of user groups.

DO NOT REPRINT
© FORTINET
If there is a problem with the first step (admin bind) or the third step (user bind), you can sniff the traffic
between the FortiGate and the LDAP server, to get the error code. The error code states explicitly why the
binding is failing.

DO NOT REPRINT
© FORTINET
Now, you will learn about some of the most common bind issues, and how to identify them in the output of the
real-time debug.
If you see the invalid credentials error right after an authentication attempt, this means a problem occurred in
step one. There is probably an issue with the admin account credentials.

DO NOT REPRINT
© FORTINET
The message No more DN left indicates that a problem occurred in step two. The LDAP server couldn't
find the user in the LDAP tree.

DO NOT REPRINT
© FORTINET
If the output shows that the user was found, but an Auth denied message appears below, this indicates that
a problem occurred in step three. Either the user credentials are wrong or the user account is not active.

DO NOT REPRINT
© FORTINET
The error message get_member_of_groups-attr=<attribute_name> - found 0 values indicates

that a problem occurred in step four. The user credentials are correct, but no user group information was
found.
In some LDAP implementations, the user group information is not used. All LDAP users have the same
privileges, regardless of their AD group memberships. In those implementations, this error message can be
ignored.

DO NOT REPRINT
© FORTINET
What do you do if the problem occurs in step one (admin bind is not working)?
• Use the dsquery query command to check the admin DN.
• Check the admin password.
• Sniff the error code coming from the server.
What do you do if the problem occurs in step two (LDAP server could not find the user)?
• If the common name identifier is set to sAMAccountName, the user must use their login name. If it is set to
cn, the user must use their full name.
• Check the distinguished name setting with the dsquery command.

DO NOT REPRINT
© FORTINET
In this section, you will learn about RADIUS authentication troubleshooting commands.

DO NOT REPRINT
© FORTINET
Normal authentication queries with the RADIUS protocol begin with an Access-Request being sent from the
FortiGate to the RADIUS server. A valid response to this query is Access-Accept or Access-Reject (yes or no,
effectively).
If two-factor authentication is enabled on the server, the response is an Access-Challenge message, which
means that the server is essentially looking for more information.

DO NOT REPRINT
© FORTINET
Just like there is for LDAP, there is a CLI test command for RADIUS. To respond, you must provide not only
the credentials for a test user, but also the authentication scheme. FortiGate supports the following RADIUS
schemes: CHAP, PAP, MS-CHAP, and MS-CHAPv2.
Also, just like it does for LDAP, this command tests only the FortiGate RADIUS server configuration. It does
not require any user group or firewall policy in the FortiGate configuration.

DO NOT REPRINT
© FORTINET
RADIUS is either a one-step or two-step process (depending on the use of two-factor authentication). It is not
as long as the four-step process that happens with LDAP regular bind. So, the output of the real-time debug is
usually shorter.

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned about firewall authentication and how to
troubleshoot issues.

FSSO
DO NOT REPRINT
© FORTINET
In this lesson, you will review FSSO operation and learn about tools and tips for troubleshooting FSSO
problems.

FSSO
DO NOT REPRINT
© FORTINET
By demonstrating a competent understanding of FSSO and its components, you will be able to understand
how to track user login events, list authenticated FSSO users, and troubleshoot common FSSO authentication
issues.

FSSO
DO NOT REPRINT
© FORTINET
In this section, you will learn about FSSO modes, its components, and how they interact.

FSSO
DO NOT REPRINT
© FORTINET
FSSO enables FortiGate to leverage your network’s existing authentication system for firewall authentication.
Once a user logs in, they can access other network resources without having to authenticate again.
The two most common FSSO methods are DC agent and polling.
DC agent mode requires one collector agent. It also requires DC agents installed in all Windows domain
controllers. The DC agents detect the login events and "push" this information to the collector agent. The
collector agent forwards the login events to FortiGate, together with the workstation IP address and user's
group information.
The polling mode does not require a DC agent to be installed. In polling mode, the collector agent frequently
polls each DC to get the latest login events. There are three types of polling mode:
• NetAPI: Polls NetSessionEnum API.

• WinSecLog: Polls all security event logs.
• WMI: Polls specific security event logs.
Poll intervals are estimated times that depend on the number of servers and network latency.
If a standalone collector agent is used, the three types of polling modes are supported. Alternatively, polling
can be performed directly from FortiGate (agentless polling mode), so a standalone collector agent is not
required. However, FortiGate acting as a collector agent supports only the WinSecLog polling type.

FSSO
DO NOT REPRINT
© FORTINET
We can break FSSO Components into four phases:
• Phase 1: This phase starts when a user authenticates on a workstation and triggers a user login event.
This phase detects the login event and records the workstation name, domain, and user.
• Phase 2: In this phase, FSSO receives login information from sources such as: DC agents, NTLM, API
polling mode, Win Sec, or TS/CITRIX. After collecting the login information, FortiGate gathers the user
group membership performing an active directory query, which can be in standard or advanced mode, or,
in the case of eDirectory, using native API or LDAP. This phase resolves the workstation name to an IP
address and determines which user groups the user belongs to.
• Phase 3: This phase handles the process of sending and receiving the user logon information, including
the IP address and groups list, to FortiGate.
• Phase 4: FortiGate receives the authentication details and creates one or more log entries for this login
event, as appropriate.

FSSO
DO NOT REPRINT
© FORTINET
This slide shows how FSSO traffic flows and which ports are used.
When polling mode is used, the polling is performed by either the FortiGate or the collector agent, and in both
cases, port TCP 445 is used.
The communication between the collector agent and FortiGate, by default, uses port TCP 8000. The
communication between the DCs and the collector agent uses, also by default, port UDP 8002.
FSSO commonly works by identifying each user based on the source IP address of the traffic. Each active
FSSO user is associated with one or more IP addresses and one IP address is associated only with one user.
This creates conflicts in network using terminal or Citrix servers, where more than one user shares the same
IP address. For those cases, you can install a terminal server (TS) agent. The TS agent provides the collector
agent and FortiGate with not only the source IP address of each user, but also with the source TCP/UDP
ports they are using. So, multiple users sharing the same IP address can be identified by combining the
source IP address with the source port. The communication between the TS agent and the collector agent
also uses port UDP 8002.

FSSO
DO NOT REPRINT
© FORTINET
Each time the collector agent receives a login event, it checks if the user is in the ignore list.
If it is, the login event is discarded. After that, the collector agent checks if the user's group information is still
in the cache.
If it is not, the collector agent performs either an LDAP or an API query to get the group information from
Windows AD. Once the collector agent knows the user groups, it checks if any of them are included in the list
of monitored groups.
If none of the groups are included, the login event is not forwarded to FortiGate. If at least one group is
included, the login event is forwarded to FortiGate.

FSSO
DO NOT REPRINT
© FORTINET
An external collector agent periodically checks if each active FSSO user is still logged in. It does this by
polling all known active workstations, based on a configurable interval.
How this checking is done depends on the FSSO mode. For WMI polling mode, the collector agent checks the
WMI service. For all the other modes, the collector agent checks the HKEY_USERS hive through remote
registry services.
If a workstation does not respond to these checks, the collector agent starts a timer (dead entry timeout
interval). After the expiration of that timer, the workstation goes to not verified status and the collector agent
assumes that the user has logged out.

FSSO
DO NOT REPRINT
© FORTINET
You can also configure the external collector agent to periodically check if the IP address of an active FSSO
user has changed. This might happen, for example, when a user switches from a wired to a wireless network.
When this collector agent feature is enabled, the collector agent periodically uses the DNS server to resolve
the workstation name.
If the DNS server replies with a new IP address, the collector agent sends first a logout event to FortiGate,
followed by a login event with the new IP address.
Therefore, it is important for the DNS server to be immediately and automatically updated each time a user
changes their IP address.

FSSO
DO NOT REPRINT
© FORTINET
There are three important requirements for any FSSO network, and most of the FSSO problems happen when
any of these requirements are not fulfilled.
The collector agent frequently polls each active workstation. For this polling to work properly, TCP ports 139
and 445 must be open between the collector agent and the workstations. Firewalls must allow this traffic.
Additionally, the remote registry service must be up and running on the workstations.
DNS is used to get the user’s IP address. So, administrators must ensure that each workstation name is
registered in the DNS server with the correct and up-to-date IP address.

FSSO
DO NOT REPRINT
© FORTINET
In this section, you will learn about diagnosing FSSO issues and troubleshooting commands.

FSSO
DO NOT REPRINT
© FORTINET
What steps should an administrator take when troubleshooting an FSSO problem? This slide offers a general
checklist.
In this lesson, you will learn how to perform the recommended troubleshooting steps.

FSSO
DO NOT REPRINT
© FORTINET
Before you start the troubleshooting, it is recommended that you gather configuration and topology
information. Analyze what FSSO version is in place, how many DCs are in the network, the FortiGate
configuration file, and so on.
If an issue occurs, the diagnose debug auth fsso list can show the user information that the
collector agent is sending to FortiGate.

FSSO
DO NOT REPRINT
© FORTINET
As part of the initial troubleshooting steps, make some changes to the collector agent logging settings to
ensure that all the required debug information is captured. First, in the Log level field, select Information.
Second, increase the setting in the Log file limit (MB) field. If the log file limit is too low, especially in big
FSSO networks, you might not have time to see the relevant debug information, because it will be overridden
quickly by new log events.
Third, you can optionally record the login events in a different file by selecting Log logon event in separate
logs.

FSSO
DO NOT REPRINT
© FORTINET
If the FSSO issue can be reproduced, there are different tools to track the login event as it travels from the
DC, to the collector agent, and then to FortiGate. Follow these steps:
1. Perform the login.
2. Check which DC received the login using the Windows command: echo %logonserver%
3. Go to that DC and use the Windows event viewer to find the generated login event.
4. Check the collector agent logs and the list of active FSSO users.
5. Check that at least one user's group is listed as monitored in the group filter.
6. Go to FortiGate and check that the login event was received.
7. List the active FSSO users.
8. Generate traffic from the user workstation and verify that it is added to the FortiGate user monitor.

FSSO
DO NOT REPRINT
© FORTINET
By clicking Show Service Status in the collector agent, you can check the connectivity between FortiGate
and the collector agent. The window displays the serial numbers of all the active FortiGate devices.

FSSO
DO NOT REPRINT
© FORTINET
When a FortiGate successfully connects to a collector agent, the collector agent logs show these messages.
Additionally you can confirm a successful connection while running the FSSO real-time debug on FortiGate.

FSSO
DO NOT REPRINT
© FORTINET
While the TCP session between FortiGate and the collector agent is up, the collector agent sends heartbeat
messages to FortiGate. Both the collector agent logs and the FortiGate real-time debug show this heartbeat
interchange.

FSSO
DO NOT REPRINT
© FORTINET
The error server authentication failed, aborting in the FortiGate real-time debug might indicate
a mismatch in the password shared between the collector agent and FortiGate.
The error connection refused might indicate that the TCP communication between FortiGate and the
collector agent is blocked by a firewall or another device.
The error no route to host might indicate that the IP address of the collector agent is not routable from
FortiGate.

FSSO
DO NOT REPRINT
© FORTINET
If you click Show Monitored DCs on the collector agent, you can check the communication between the
collector agent and each DC. The table includes the time when the last login event was received from each
DC.

FSSO
DO NOT REPRINT
© FORTINET
The Event Viewer is a Windows tool that displays all the server logs. You can use it to search for login event
logs.

FSSO
DO NOT REPRINT
© FORTINET
The FortiGate FSSO real-time debug generates messages each time a login event arrives. They include the
name and IP address of the user, together with the workstation name and user's group information.

FSSO
DO NOT REPRINT
© FORTINET
You can check the list of logon users by clicking Show Logon Users. The status OK indicates that the user is
active. A user goes to not verified status when they log out, or when there is a problem in the polling done by
the collector agent to the workstation.

FSSO
DO NOT REPRINT
© FORTINET
To get the list of active users from FortiGate, use the command diagnose debug authd fsso list. You
can set up a filter first with the command diagnose debug authd fsso filter.

FSSO
DO NOT REPRINT
© FORTINET
The CLI command diagnose debug authd fsso refresh-logons refreshes the active FSSO user list
in the FortiGate by getting this information again from the collector agent.
The CLI command diagnose debug authd fsso clear-logons flushes the list of active FSSO users
in the FortiGate.
The CLI command diagnose debug authd fsso refresh-groups refreshes the user group
information in the FortiGate by getting this information again from the collector agent.
To list the monitored user groups, use the command get user adgrp.

FSSO
DO NOT REPRINT
© FORTINET
The commands on this slide are executed on a Windows command prompt. They can be useful while
diagnosing FSSO issues and analyzing data on the server side.
On a Windows server, the command, dsquery user -name is useful to query the DN. You can run this
command from the LDAP server’s command prompt.
When you use the command wmic, it should return the username of the user currently logged in to the remote
workstation.
You can use the command netstat to verify that port 8000 is open.

FSSO
DO NOT REPRINT
© FORTINET
In this section, you will learn about the FSSO agentless method and specific troubleshooting commands for
this mode.

FSSO
DO NOT REPRINT
© FORTINET
The command diagnose debug fsso-polling detail displays the status and some statistics related
to the polls done by the FortiGate on each DC.
The command diagnose debug fsso-polling refresh-user flushes the information about all active
FSSO users.
In agentless polling mode, the FortiGate frequently polls all workstations (as a standalone collector agent
does) to check which users are still logged on. You can sniffer this traffic on port 445.

FSSO
DO NOT REPRINT
© FORTINET
There is a specific FortiGate daemon that handles the polling mode. It is the fssod daemon. To enable
agentless polling mode real-time debug use:
diagnose debug application fssod -1.
The slide shows the most common real-time debug errors and the possible causes.

FSSO
DO NOT REPRINT
© FORTINET
In this section, you will learn about the most common FSSO issues.

FSSO
DO NOT REPRINT
© FORTINET
What should you do if the collector agent does not have login information?
• Verify that the collector agent is monitoring all DCs.
• Check that the collector agent is receiving login events from the DCs.
• Test the user account and check the collector agent logs.
What should you do if the collector agent has the login information, but FortiGate does not?
• Check that FortiGate is connected to the collector agent.
• Run the real time debugs while testing the user account.

FSSO
DO NOT REPRINT
© FORTINET
If an FSSO user is listed as active in FortiGate but it cannot browse the internet, you should first confirm that
the correct IP address is listed in FortiGate. Also check the user's group information, firewall policies, and
collector agent logs.
If FortiGate is randomly blocking some users, you should check that the collector agent service, or any
FortiGate process, is not crashing. Confirm that the connection between FortiGate and collector agent is up
and stable. Try to reproduce the problem and then check the collector agent logs.

FSSO
DO NOT REPRINT
© FORTINET
DNS resolution is essential for FSSO operation. If a collector agent cannot resolve a workstation name, the
user will not be listed as active and the collector agent logs show the errors shown on this slide.

FSSO
DO NOT REPRINT
© FORTINET
Another common problem with FSSO authentication happens when applications generate login events with an
AD account that is different from the users’ accounts.
In these cases, the login event overrides the user information for a workstation IP address (a different user is
listed as active for the IP address).
The collector agent is coded to ignore any login events for anonymous accounts, and accounts with a name
starting with '$' (which are system accounts). If any application is using an account that is overriding the user
information, the solution is to add that account to the ignore user list.

FSSO
DO NOT REPRINT
© FORTINET
Active users with the status not verified are also a common problem. That status is normal after a user has
logged out. However, it is not normal for a user that is still logged in. This means that polling from the collector
agent to the workstation is failing. In these cases, check the collector agent logs. They provide more
information about the cause of the problem.

FSSO
DO NOT REPRINT
© FORTINET
What should you do if a user loses internet access after their IP address changes?
This might happen when the user moves back and for from a wired to a wireless network. It might also
happen when a workstation comes out of hibernate mode and gets a new IP address from the DHCP server.
The first step is to check the DNS resolution. When a user changes their IP address, the DNS server must be
automatically updated with the new IP address information. If that is not possible, one workaround is to
configure FSSO guest access. So, users whose IP addresses have changed can still have some (probably
limited) access to some network resources.
For the cases where a workstation was assigned more than one IP address (for example, one address for the
wired network and another one for the wireless), the DNS server should be able to return all those IP
addresses when resolving the workstation name. The user is then listed multiple times in the FSSO active
user list, one time for each IP address.

FSSO
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned about FSSO modes, the most common FSSO
issues, and how to troubleshoot them.

Security Profiles
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to troubleshoot some of the security profile features.

Security Profiles
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding security profiles, you will be able to understand how to
troubleshoot FortiGuard and web filtering issues. You will also learn how to fix certificate warning problems,
and monitor IPS and antivirus events.

Security Profiles
DO NOT REPRINT
© FORTINET
In this section, you will learn about how FortiGuard and FortiGate communicate. You will also learn
troubleshooting commands.

Security Profiles
DO NOT REPRINT
© FORTINET
You can check the status of FortiGuard licenses and the communication to FortiGuard on the FortiGate GUI.
You can also check the versions of the locally installed databases for each of the FortiGuard services.

Security Profiles
DO NOT REPRINT
© 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 from
the communication for antivirus and IPS. First, you will look at how FortiGuard web filtering and antispam
work:
1. FortiGate contacts the DNS server to resolve the FortiGuard service name.
2. FortiGate gets a list of IP addresses for servers that it can contact to validate the FortiGuard license.
3. FortiGate contacts one of those servers to check the license and request a list of servers that it can
submit web filtering and antispam rating queries to.
4. FortiGate gets the list of servers.
5. FortiGate starts sending rating queries to one of the servers in the list.
6. If the server it contacted does not reply in 2 seconds, FortiGate contacts the next server on the list.
The FortiGuard service name depends on the FortiGate configuration:
• service.fortiguard.net: FortiGate is configured to use UDP and communicate with servers located
worldwide.
• securewf.fortiguard.net: FortiGate is configured to use HTTPS and communicate with servers
located worldwide.
• usservice.fortiguard.net: FortiGate is configured to use UDP and communicate with servers
located only in the USA.
• ussecurewf.fortiguard.net: FortiGate is configured to use HTTPS and communicate with servers
located only in the USA.

Security Profiles
DO NOT REPRINT
© FORTINET
Now, you will look at how antivirus and IPS work. How FortiGuard communication works for antivirus and IPS
depends on the method used: pull or persistent connection. Note that the persistent connection method is
available only on FortiGate models that are 2U and above, and is displayed on the FortiGate GUI as
Immediately download updates.
The steps in 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 that it can contact.
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 in the pull method are also used in the persistent connection method: FortiGate gets
a list of IP addresses from a DNS server for the domain name update.fortiguard.net. After that,
FortiGate forms an HTTPS connection with FortiGuard. Once this connection is established, FortiGuard uses
this connection to send notifications each time there are new updates. FortiGate then proceeds to form a
separate secure connection to FortiGuard to download the update.

Security Profiles
DO NOT REPRINT
© FORTINET
The command shown on this slide displays the list of servers for web filtering and antispam queries. For each
IP address, the table shows:
• The round trip delay
• The server time zone
• The number of recent and consecutive queries without reply
• The historical total number of queries without reply—these values reset when the device restarts.

Security Profiles
DO NOT REPRINT
© FORTINET
FortiGate uses the following method to select the server to send the rating requests to:
• FortiGate initially uses the delta between the server time zone and the FortiGate system time zone,
multiplied by 10.
• This is the initial weight of the server. To lower the possibility of using a remote server, the weight
is not allowed to drop below the initial weight.
• The weight increases with each packet lost.
• The weight decreases over time if there are no packets lost.
• FortiGate uses the server with the lowest weight as the one for the rating queries. If two or more servers
have the same weight, FortiGate uses the server with the lowest round-trip time (RTT).

Security Profiles
DO NOT REPRINT
© FORTINET
In many cases, problems related to FortiGuard are caused by ISPs. Some ISPs block traffic that is not DNS or
that contains large packets on port 53. 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.
When anycast is enabled, which is by default, the protocol is HTTPS and the port is 443.
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 on this slide usually fixes the issue.

Security Profiles
DO NOT REPRINT
© 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 FortiManager.
• T = The server is not replying to FortiGate queries.
• F = The server is down.

Security Profiles
DO NOT REPRINT
© 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 website or
email (if the information is not in the FortiGate cache).
In the case of the pull method for antivirus and IPS, by default, FortiGate contacts FortiGuard at an interval
calculated based on the FortiGate model and the percentage of valid subscriptions. The update interval is
within one hour 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 through a web proxy do not contact the DNS server to resolve names, because it is the web proxy
that does it. When connecting through a web proxy, FortiGate can access FortiGuard without DNS resolution.

Security Profiles
DO NOT REPRINT
© FORTINET
Both the antivirus and IPS databases can be updated either automatically or manually. Automatic updates
download the portions of the databases that have changed since the last update.
Manual updates download the whole database if there is new version available.
In a few cases, FortiGuard problems are fixed by doing a manual update. This forces FortiGate to download
and install the whole database. For example, if the antivirus database is corrupted, a manual update might fix
the problem.

Security Profiles
DO NOT REPRINT
© 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 on
FortiGate.

Security Profiles
DO NOT REPRINT
© FORTINET
The command shown on this slide lists all the FortiGuard databases and engines installed. The information
includes the version, contract expiration date, time it was updated, and what happened during the last update.

Security Profiles
DO NOT REPRINT
© FORTINET
If there are problems updating the AV or IPS databases, 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 you enable the debug, you can force a manual update on the CLI with the command execute
update-now.

Security Profiles
DO NOT REPRINT
© FORTINET
Remember that FortiGuard traffic always originates from the management VDOM. So, the management
VDOM (which is root by default) must have internet access.
Correct DNS access from the management VDOM is also important. FortiGate must be able to resolve the
names:
• update.fortiguard.net
• service.fortiguard.net
Also, keep in mind that, although it usually takes 1 or 2 hours to update a contract on all the servers, in some
cases, it can take up to 24 hours. So, if you have just changed or renewed your FortiGuard contract, and you
do not see the change on FortiGate, you may need to wait a bit longer to give FortiGuard time to synchronize
the information on all servers.

Security Profiles
DO NOT REPRINT
© FORTINET
In this section, you will learn how FortiGate processes a packet.

Security Profiles
DO NOT REPRINT
© FORTINET
On the following slides, we are going to analyze how a FortiGate processes a packet from when it arrives on
the FortiGate to when it leaves the FortiGate. You will see the actions that the FortiGate takes and the order of
those actions. We have split the process into four stages. The first stage happens when the packet arrives on
the FortiGate.
First, you can set a limit on the incoming bandwidth (inbandwidth parameter). If the traffic exceeds that
limit, the packet is dropped.
After that, FortiGate checks the thresholds in the DoS policies.

The next steps are the reverse path forwarding and IP header integrity checks.
If the traffic terminates at the FortiGate (for example, management, web proxy, and DNS traffic), the specific
daemon that handles the requested feature processes the packet. If the traffic does not terminate at the
FortiGate, it moves to the second stage, which is the routing and firewall policy.

Security Profiles
DO NOT REPRINT
© FORTINET
Before doing the routing lookup, the FortiGate (if required) applies the destination NAT. If there is no route to
the destination, the packet is dropped. In a similar way, if a firewall policy denies the packet, it will not be
allowed. If the packet is allowed, FortiGate checks if the policy requires authentication. After those steps,
FortiGate proceeds to identify the traffic, which is then inspected by any session helper that might be required.

Security Profiles
DO NOT REPRINT
© FORTINET
The third stage is UTM inspection. If the traffic is encrypted and full SSL inspection is used, the FortiGate
proceeds to decrypt the traffic. After that, the inspection profiles are applied in this order: IPS, application
control, VoIP, DLP, antispam, web filtering, and antivirus.

Security Profiles
DO NOT REPRINT
© FORTINET
After inspection, FortiGate applies traffic shaping and source NAT. Finally, if the packet must be routed
through an IPsec VPN, it is encrypted before leaving the FortiGate.

Security Profiles
DO NOT REPRINT
© FORTINET
In this section, you will learn web filtering troubleshooting commands.

Security Profiles
DO NOT REPRINT
© FORTINET
Similar to other UTM features, one of the best troubleshooting tools for web filtering is the FortiGate logs.
FortiGate can generate a log each time a website is blocked. The log lists the URL, category, action taken,
and so on.

Security Profiles
DO NOT REPRINT
© FORTINET
You can see a list of error counters that are related to web filtering by entering the command diagnose
webfilter fortiguard statistics list.

Security Profiles
DO NOT REPRINT
© FORTINET
The output also shows counters for the number of sites allowed and blocked, and statistics about the cache
(including hit and miss rates).

Security Profiles
DO NOT REPRINT
© FORTINET
Another tool you can use to troubleshoot web filtering is the web filter real-time debug. You can use the
commands shown on this slide.
This slide shows an example of real-time debug output when the URL to categorize isn't in the FortiGuard
cache. The output shows the URL, category, source, destination IP addresses, and service.

Security Profiles
DO NOT REPRINT
© FORTINET
To list the content of the FortiGuard web filtering cache, use the command diagnose webfilter
fortiguard cache dump. 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 then convert the ID number from hexadecimal to decimal. Then,
use the second command to find the category name for that ID number.

Security Profiles
DO NOT REPRINT
© FORTINET
Now, you will learn some 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.

Security Profiles
DO NOT REPRINT
© 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 device is not entering conserve mode.

Security Profiles
DO NOT REPRINT
© FORTINET
In this section, you will learn about SSL inspection modes and how to handle certificate warnings.

Security Profiles
DO NOT REPRINT
© FORTINET
There are two SSL inspection modes: SSL certificate inspection and full SSL inspection. When using SSL
certificate inspection, FortiGate is not decrypting the traffic. It is only inspecting the server digital certificates
and the name indication (SNI) field, which are interchanged before the encryption.
First, FortiGate tries to get the URL from the SNI field. The SNI field is a TLS extension that contains the
complete URL that the user is connecting to. It is supported by most modern browsers.
If the SNI field is not present (because the web client may not support it), FortiGate proceeds to inspect the
server digital certificate.

Security Profiles
DO NOT REPRINT
© FORTINET
With full SSL inspection, FortiGate does decrypt (and re-encrypt) the SSL traffic.
Under normal circumstances (without full SSL inspection), encrypted traffic cannot be inspected, because the
firewall does not have the key required to decrypt the data.
In order to work, the FortiGate must be located in the middle of the communication between the user’s
browser and the website. When the browser connects to the website, the web server sends its certificate,
which contains its public key.
The FortiGate intercepts the web server certificate and generates a new one. The new certificate is issued by
the certificate authority (CA) installed on the FortiGate, which is not a well-known public CA. The FortiGate
also generates a new pair of public and private keys.

Security Profiles
DO NOT REPRINT
© FORTINET
When you enable SSL inspection, browsers start displaying a certificate warning each time a user is
connecting to an HTTPS site. The reason is that the certificates that the browsers receive are now being
signed by the FortiGate, which is a CA that the browsers do not trust. There are two ways to fix this warning.
The first option is to download the default FortiGate certificate for SSL proxy inspection and install it in all the
browsers.
The second option is to generate a new SSL proxy certificate from a private CA. In this case, the private CA
certificate must still be installed in all the browsers.
This is not a limitation on FortiGate, but a consequence of how digital certificates are designed to work.

Security Profiles
DO NOT REPRINT
© FORTINET
Replacing the certificate for the traffic can cause problems. Some software and servers have specific
limitations on the certificates that are allowed to be used.
HSTS and PKP are security features designed to detect man-in-the-middle SSL attacks by making sure that
any certificate presented when accessing a server resource is signed by a specific CA.
If the browser detects any other CA, it simply refuses to continue the SSL handshake and prevents access to
the website.
The solutions available for these issues are limited. One option is to bypass SSL inspection for that traffic.
Another option is to use SSL certificate inspection instead.

Security Profiles
DO NOT REPRINT
© FORTINET
In this section, you will learn how to verify the antivirus status and detections.

Security Profiles
DO NOT REPRINT
© FORTINET
This is the order of how antivirus inspection is executed. First, the device does the virus scan, then the
grayware scan, and finally the machine learning detection.
Up to FortiOS 6.4, a heuristic scan could be enabled to perform antivirus inspection after the grayware scan.
On FortiOS 7.0 and later, the previous heuristic settings are not kept. On FortiOS 7.0 and later, there is a
machine-learning-detection setting, which is an AI-based malware detection feature.

Security Profiles
DO NOT REPRINT
© FORTINET
One of the best tools for troubleshooting antivirus issues is the FortiGate logs. This is a sample of a log
generated when FortiGate detects a virus. You can see the name of the file, time, and name of the virus.

Security Profiles
DO NOT REPRINT
© FORTINET
What should an administrator do if a virus is detected in a workstation behind a FortiGate performing antivirus.
Again, the first step is to get specific information. What antivirus software detected the virus? What is the
name of the virus? How did it get inside the network? It might have gotten inside, for example, through a CD
or USB stick, so the infected file never went through the FortiGate.

Security Profiles
DO NOT REPRINT
© FORTINET
Test if FortiGate antivirus is correctly inspecting the user traffic. Go to eicar.org from a user workstation and
try to download the EICAR sample file.
If you have a sample of the virus, submit it to FortiGuard and check if it is present in any of the FortiGate virus
databases. If it is, check the name of the antivirus database where it is present. Does your FortiGate have that
database installed?

Security Profiles
DO NOT REPRINT
© FORTINET
There are three FortiGate AV databases: normal, extended, and extreme. Not all FortiGate models support
the three databases, and all three databases may not be installed on your FortiGate.

Security Profiles
DO NOT REPRINT
© FORTINET
Remember the restrictions for antivirus inspection:

• SSL traffic requires SSL deep inspection.
• Archive files, such as ZIP files, are examined to certain limits, such as the maximum number of
subdirectories and nested archives—there is also the CPU impact of this.
• Password protected archives cannot be scanned.

Security Profiles
DO NOT REPRINT
© FORTINET
In this section, you will learn about IPS troubleshooting.

Security Profiles
DO NOT REPRINT
© 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. ipshelper
also monitors configuration changes that impact IPS so it can also start or spawn additional instances of
ipsengine. For this reason, it’s normal to see ipshelper running even if you don’t have IPS configured
on FortiGate.
On some FortiGate models, it is normal to see multiple instances of the ipsengine daemon running.

Security Profiles
DO NOT REPRINT
© FORTINET
IPS goes into fail open mode when there is not enough available memory in the IPS socket buffer for new
packets. The IPS also goes into fail open mode when the FortiGate is in conserve mode. 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. Note that NTurbo doesn’t support the fail-open setting. If fail open is triggered, new
sessions that would typically be accelerated with NTurbo are dropped, even if the fail-open setting is
enabled.

Security Profiles
DO NOT REPRINT
© FORTINET
The IPS fail open event generates a log in the crash log. The log indicates if new packets are dropped or
passed through.

Security Profiles
DO NOT REPRINT
© FORTINET
IPS fail open entry and exit events also generate event logs.

Security Profiles
DO NOT REPRINT
© 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 to the type of traffic being inspected,
and disable IPS profiles on policies that don’t need them.

Security Profiles
DO NOT REPRINT
© FORTINET
The Protocol Options setting, which is configurable within each firewall policy, can impact the performance
of a FortiGate due to the need for the IPS engine to identify the protocol where particular protocol-to-port
mappings are not explicitly set.
When a policy is set to proxy-based inspection, the settings in Protocol Options instruct FortiGate to direct
specified destination ports to their respective proxy processes, except when Any is set for an enabled
protocol.
In this scenario, the traffic must be sent to the IPS engine and processed by the CPU, in order to identify the
protocol before directing it to the proxy process. This is significant, because it can affect how traffic is
processed during an IPS fail open event for both proxy-based and flow-based traffic.
Protocol port mapping only works with proxy-based inspection. Flow-based inspection inspects all ports
regardless of the protocol port mapping configuration.

Security Profiles
DO NOT REPRINT
© 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.

Security Profiles
DO NOT REPRINT
© FORTINET
If there are high CPU usage problems that the IPS caused, 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 usage decreases after that, it
usually indicates that the volume of traffic being inspected is too high for that particular FortiGate model.
If the CPU usage remains high after you enable IPS bypass mode, it usually indicates a problem in the IPS
engine that you must report to Fortinet support.
If you enable IPS bypass mode, remember to disable it after you finish troubleshooting, using option 5.
Another recommendation to keep in mind is if you need to restart the IPS, don't use the diagnose sys
kill command. Instead, use option 99, as shown on this slide. This guarantees that all IPS-related
processes will restart correctly.

Security Profiles
DO NOT REPRINT
© 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
FortiGuard team for further investigation.

Security Profiles
DO NOT REPRINT
© FORTINET
False negatives are more difficult to discover and troubleshoot. Check the following:
• Traffic is hitting the correct policy or IPS profile (use the 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.

Security Profiles
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to troubleshoot some of the security
profile features.

High Availability
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to monitor the status of a high availability (HA) cluster, configure session
synchronization, and use the troubleshooting steps and commands for HA issues.

High Availability
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding HA, you will understand how to monitor the status of an HA
cluster, configure session synchronization, and diagnose and resolve HA cluster issues.

High Availability
DO NOT REPRINT
© FORTINET
In this section, you will learn how to monitor the HA configuration status among devices in the HA cluster.

High Availability
DO NOT REPRINT
© FORTINET
The HA framework consists of two daemons: hatalk and hasync.
The process hatalk monitors cluster management and failure monitoring. The process hasync handles the
synchronization of configuration files, the upgrade process, IKE notifications, external files, the ARP table, and
FIB.
The process hasync engages other processes to fulfill its purpose, like configuration daemons cmdb,
update, iked, authd, and snmpd.

High Availability
DO NOT REPRINT
© FORTINET
The HA heartbeats are generated by the kernel. This gives this traffic priority over other types of packets. HA
heartbeat packets are prioritized to guarantee the health of the HA cluster and traffic flow.
The command diagnose sys ha heartbeat displays how many CPU cores handle the heartbeats and
their distribution.

High Availability
DO NOT REPRINT
© FORTINET
The hbdev interface is configured under config system ha which assigns the interface that will transmit
and receive the HA heartbeats.
As part of the kernel processing of heartbeat packets, the kernel signals to the hatalk daemon the presence
of heartbeat packets to process.
The process hatalk time stamps the HA packets that process and perform a diff time function to monitor if it
has reached the hb-lost-threshold that could trigger an HA heartbeat timeout.
HA heartbeat packets consume more bandwidth if the heartbeat interval is short, but if the heartbeat interval is
very long, the cluster is not as sensitive to topology changes and other network changes.

High Availability
DO NOT REPRINT
© FORTINET
If the HA cluster forms successfully, the GUI displays all the FortiGate members with their host names, serial
numbers, role, uptime, and synchronization status.

High Availability
DO NOT REPRINT
© FORTINET
If the HA cluster forms, but the configurations are not synchronized, the GUI tooltip for the cluster members
displays the portions of their configuration that are out of sync.

High Availability
DO NOT REPRINT
© FORTINET
When troubleshooting a problem in an HA cluster, it is useful to know that you can connect to the CLI of any
secondary device from the CLI of the primary device. Using the command shown on this slide with the HA
index of the secondary device, you can connect to the CLI of the secondary device. To get the list of
secondary FortiGate devices and their HA indexes, type a question mark at the end of that same command.

High Availability
DO NOT REPRINT
© FORTINET
Using the CLI, you can get more information about the status of HA. For example, the command shown on
this slide displays heartbeat traffic statistics, as well as the serial number and HA priority of each FortiGate.
This command also shows the IP address of the heartbeat interface that is automatically assigned to the
primary FortiGate.

High Availability
DO NOT REPRINT
© FORTINET
You can use the command shown on this slide to display the following information:
• HA health status
• Cluster uptime
• Criteria used to select the primary device
• Override status
• Status of the monitored interfaces
• Status of the HA ping servers

High Availability
DO NOT REPRINT
© FORTINET
The HA uptime is one of the variables used to elect the primary device. Depending on other variables and
configurations, the devices might compare their system uptimes to elect the primary. If that happens, and if
there is one member whose system uptime is 5 minutes more than the system uptimes of all the other
devices, that member is elected as the primary. You can use this command to compare the system uptimes of
all the devices in a cluster.
The reset_cnt value shows you how many times the HA uptime has been reset with the diagnose sys
ha reset-uptime command.

High Availability
DO NOT REPRINT
© FORTINET
A good indication of the health of an HA cluster is the status of the configuration synchronization. To verify
that all the secondary configurations are synchronized with the primary configuration, you can use the
command shown on this slide on all the HA devices. If a secondary FortiGate displays the same sequence of
numbers as the primary, its configuration is synchronized. Also, and as long as there are no configuration
changes happening, on 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 on the device. The
debugzone is where configuration changes are first stored before they are applied to the running
configuration. So, during a configuration change you might see that the debugzone checksum differs from
the checksum for a short time, while the configuration changes are copied to the running configuration. After
that short time, both checksums should match again.

High Availability
DO NOT REPRINT
© FORTINET
Instead of using the checksum show command on each of the cluster devices, you can use the command
shown on this slide 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 devices and the
primary, you might need to use the checksum show command instead.

High Availability
DO NOT REPRINT
© FORTINET
The command checksum show allows you to drill down to different levels.
It can provide a general checksum at the global level, including all the VDOMs configured on FortiGate, as
well as provide the checksum for a specific VDOM or the checksum of a specific configuration section from a
VDOM.
These different levels can be very useful while troubleshooting an HA cluster that needs to identify what
setting is triggering an out-of-sync issue.

High Availability
DO NOT REPRINT
© FORTINET
In this section, you will learn about session synchronization among devices in an HA cluster.

High Availability
DO NOT REPRINT
© FORTINET
By default, HA session synchronization is disabled. Most sessions can be resumed as a normal result of how
TCP/IP communications resume communication after a network interruption. You should balance the traffic
requirements and performance impact before enabling session-pickup.
If you enable it, a number of session requirements and limitations take place because the primary device
synchronizes sessions with the secondary device. Under ideal conditions, all TCP sessions should be
resumed.
Optionally, you can enable session synchronization for connectionless, ICMP/UDP, and short-lived sessions.

High Availability
DO NOT REPRINT
© FORTINET
There are some factors and criteria that the primary device follows when synchronizing a session to a
secondary device.
By default, once session-pickup is enabled, as soon as a new TCP session is added to the primary device
session table, that session is synchronized to all devices in the cluster. This synchronization happens as
quickly as possible to keep the session tables synchronized.
Other events that trigger the session table synchronization from the primary device to the other devices in the
cluster occur if there is a session state update or if a session has been deleted.
Most of the session synchronization communication comes from the primary to the rest of the devices in the
cluster; secondary devices would send queries to the primary device about session timer updates.

High Availability
DO NOT REPRINT
© FORTINET
By default, session synchronization activity takes place over the HA heartbeat link using TCP/703 and
UDP/703 packets.
The command get sys ha status displays if session pickup is enabled. The HBDev stats section
should show that the RX and TX counters are incrementing.
If there is a large number of session synchronizations, this could cause network congestion and impact the
HA cluster communication. One option is to select one or more ports to use for synchronizing sessions, which
can improve HA heartbeat traffic and the performance of the HA cluster.

High Availability
DO NOT REPRINT
© FORTINET
You can check the session table of the primary device to see which sessions have been synchronized to the
secondary devices. They are the ones with the synced flag. Additionally, and in the case of all sessions, the
ha_id field shows the HA member ID of the device that is processing the traffic.

High Availability
DO NOT REPRINT
© FORTINET
In this section, you will learn about some HA troubleshooting steps and commands.

High Availability
DO NOT REPRINT
© FORTINET
There are five 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 an HA cluster to monitor the
link status of one or more interfaces.
• When a server (IP address) stops replying to the ping that the primary sent. You can configure an HA
cluster to periodically send a ping to one or more servers to test the connectivity between the primary
device and the network services.
• When FortiOS detects a failure in an SSD. This is only available for devices with SSDs.
• When memory-based failover is enabled and the configured conditions for utilization exceed the threshold
during each sample over the monitor period

High Availability
DO NOT REPRINT
© 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 device failed, the secondary device logs should show these log
entries.

High Availability
DO NOT REPRINT
© FORTINET
If a new primary was elected because one or more monitored interfaces failed, the former primary displays
logs similar to the ones shown on this slide. In the example shown on this slide, the primary device is
reporting a problem with the monitored interface port1.

High Availability
DO NOT REPRINT
© FORTINET
Another useful way to determine the reason for an HA failover is by running the command shown on this slide.
This command provides details about past HA events, which allows administrators to identify the reason for
previous failover events. This is a useful HA command, especially when HA logs are not available.

High Availability
DO NOT REPRINT
© FORTINET
An HA split-brain scenario occurs when the FortiGate devices in an HA cluster lose heartbeat communication
through the heartbeat links. Because of the lost communication, each FortiGate assumes the role of the
primary device.
When this issue occurs, the results are very evident because traffic flow is impacted. While experiencing a
split-brain issue, the administrative access to the devices in the cluster is intermittent; console access might
be required to troubleshoot the device and perform configuration changes, if required.
This issue could be triggered by a faulty physical port or cable, a failed firmware upgrade, or a congested
heartbeat link.

High Availability
DO NOT REPRINT
© FORTINET
There are some basic HA troubleshooting steps to verify the HA cluster health and get the cluster out of this
situation:
1. Verify that all devices in the cluster are running the same firmware version.
2. Check that the configuration is synchronized.
3. Verify the status of the heartbeat ports.
4. Verify that the Ethernet packets are transmitted and received successfully between the cluster members.
Following these steps will help to diagnose the root cause that triggered this behavior.

High Availability
DO NOT REPRINT
© 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 device tries to join the cluster. Run the debug on both the primary
device and the device 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.

High Availability
DO NOT REPRINT
© 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-lived sessions are not synchronized.
High CPU issues can also create HA heartbeat problems. In those cases, troubleshoot and fix the high CPU
problem first, before you check the HA status.

High Availability
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to monitor an HA cluster and steps to
troubleshoot FortiGate devices running in HA.

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

IPsec
DO NOT REPRINT
© FORTINET
By demonstrating a competent understanding of IPsec, you will be able to manage, monitor, diagnose, debug,
and troubleshoot IPsec.

IPsec
DO NOT REPRINT
© FORTINET
In this section, you will learn the CLI commands to monitor the status and statistics of IPsec VPNs.

IPsec
DO NOT REPRINT
© FORTINET
The same command diagnose vpn tunnel offers options for shutting down, activating, or flushing a VPN
tunnel.

IPsec
DO NOT REPRINT
© 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.

IPsec
DO NOT REPRINT
© FORTINET
The command get vpn ipsec tunnel details provides detailed information for the active IPsec
tunnels.
For detailed information about each tunnel, use the command diagnose vpn IPsec tunnel detail.
The output shows traffic counters, negotiated quick mode selectors, and negotiated encryption, authentication,
and keys.

IPsec
DO NOT REPRINT
© 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. Be careful when using this
command because it has a global effect. This means that running it without specifying the phase 1 name
results in all phase 1s of all VDOMs being cleared.

IPsec
DO NOT REPRINT
© FORTINET
The command get vpn IPsec stats tunnel provides some global overall counters related to all the
VPNs that are currently active.
The other two commands shown on this slide provide summarized information about the VPNs.

IPsec
DO NOT REPRINT
© FORTINET
In this section, you will learn the CLI commands to debug a phase 1 and 2 negotiations.

IPsec
DO NOT REPRINT
© 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 that is 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. Also, multiple addresses are supported. Filtering by name is helpful when the remote peer IP
address is unknown.

IPsec
DO NOT REPRINT
© FORTINET
After setting the filter, enable the IKE real-time debug using the commands shown on this slide.
The table shown on this slide includes the type of output that is enabled by each bit in the bitmask. The most
common value for the bitmask is -1 (all outputs enabled). It shows the DPD packets and all the information
required for troubleshooting IPsec negotiation problems.

IPsec
DO NOT REPRINT
© FORTINET
Now, you will 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 after FortiGate identifies the VPN configuration to use (with the name of the VPN).

IPsec
DO NOT REPRINT
© FORTINET
Next, the output shows the remote peer’s 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 phase 1 is up.

IPsec
DO NOT REPRINT
© FORTINET
This slide shows the output of the real-time debug for phase 1 aggressive mode. It displays the three
aggressive-mode packets exchanged, and the proposals.

IPsec
DO NOT REPRINT
© FORTINET
The IKE real-time debug shows, after phase 1, the exchange of XAuth packets. On this slide, you can see the
CFG_REQUEST packet. You can also see the CFG_REPLY, showing the XAuth user and group name.
After that, the IKE real-time debug shows the CFG_SET and CFG_ACK.

IPsec
DO NOT REPRINT
© FORTINET
After the extended authentication, the remote site proceeds to request and receive the IP settings through IKE
mode configuration.
The output shows the CFG_REQUEST and CFG_REPLY packets.

IPsec
DO NOT REPRINT
© 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.

IPsec
DO NOT REPRINT
© FORTINET
Next, the output shows the negotiated phase 2 settings. The last messages confirm that the phase 2 is up.

IPsec
DO NOT REPRINT
© FORTINET
In this section, you will learn how to configure and monitor IPsec encryption and decryption on hardware
offload.

IPsec
DO NOT REPRINT
© 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 device 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.

IPsec
DO NOT REPRINT
© FORTINET
All IPsec SAs have an npu_flag field that indicates the offloading status. In the case of IPsec traffic, the
FortiGate session table also includes that field.
First, when phase 2 comes 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.

IPsec
DO NOT REPRINT
© FORTINET
This command shows the number of packets encrypted and decrypted by software (CPU), and by each type
of processor unit on FortiGate.

IPsec
DO NOT REPRINT
© FORTINET
In this section, you will learn IPsec troubleshooting steps and commands.

IPsec
DO NOT REPRINT
© FORTINET
When isolating IPsec problems, it is useful to understand that an IPsec connection can be described as a
multistep 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 comes up.
3. If extended authentication is required, one side authenticates.
4. If one side requires IP settings, the other side sends the required settings through the IKE mode
configuration.
5. One or more phase 2s go up. Two IPsec SAs are negotiated for each phase 2.
6. Traffic crosses the tunnel.
So, if you have an IPsec issue, you should identify in which of these steps the problem has occurred.

IPsec
DO NOT REPRINT
© FORTINET
Now assume that when the phase 1 comes up, the phase 2 also comes up, but, for some reason, the traffic is
not crossing the tunnel.
If the VPN is up but the traffic can’t cross the tunnel, you should use the debug flow. If possible, run it in both
gateways. This will let you know if the local gateway is dropping the packets or not routing the packets
through the tunnel, or if the remote gateway is dropping the packets.
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
• Packet 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).

IPsec
DO NOT REPRINT
© FORTINET
If you need to capture 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.
Note that port 500 and port 4500 are the default UDP port numbers for IKE and IKE NAT-T, respectively.
These ports can be configured using the command config system settings and options set ike-
port <value> and set ike-natt-port <value>.

IPsec
DO NOT REPRINT
© 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.

IPsec
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to manage, monitor, diagnose, debug,
and troubleshoot IPsec.

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

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
By demonstrating a competent understanding of IPsec IKEv2, you will be able to explain the differences and
advantages of IKEv2 and its negotiation process.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
In this section, you will learn about the differences between IKEv1 and IKEv2.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
Although IKEv1 is still widely used, you must consider multiple factors when deciding whether to continue
using IKEv1 or replace it.
Notably, IKEv1 development ceased over a decade ago—and unmaintained code can result in security
vulnerabilities.
IKEv1 has been moved to historic status and some of its RFC specifications have become obsolete.
Some algorithms used in IKEv1 are no longer actively deployed or researched, which presents an unknown
security risk that you should avoid.
Some IKEv1 functionalities never reached the standard state and some do not even have an RFC.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
Even though IKEv1 is deprecated, it can still fulfill some system requirements:
• When RADIUS or LDAP authentication is required for a FortiGate device acting as a dialup client:
Because FortiOS doesn't have an EAP client, a FortiGate device cannot authenticate itself against
a RADIUS/LDAP server. In this case, IKEv1 must be used.
• When multiple stages of authentication are required: Although IKEv2 can provide a solution to this
requirement, it requires multiple authentication exchanges or EAP chaining (EAP TEAP).
FortiOS has used IKEv1 for more than 20 years, which has driven fixes and optimizations.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
IKEv1 and IKEv2 are incompatible protocols that achieve the same goal, but in different ways.
IKE version 2 does not interoperate with IKE version 1, but they both have enough of the header format in
common that both versions can unambiguously run over the same UDP port.
While the core IKEv1 functionalities are defined through multiple RFCs, the main IKEv2 RFC covers, in a
single document, many of the same functionalities, like NAT, mode-cfg, EAP, DPD, and so on.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
There are multiple reasons to transition to IKEv2:
• IKEv2 is a robust and reliable protocol that developers are actively working on.
• One of its improvements is that negotiations require fewer messages, which translates into
decreased latency for establishing a tunnel. The initial exchange is two round trips (four
messages), which allows the ability to piggyback the setup of a child SA on that exchange.
• Other new improvements are:

• The negotiation of fragmentation starts with the first message
• DoS protection
• The rekey logic for IKE/IPSEC SA is more accurately defined
• The cryptographic syntax for protecting the IKE messages has been replaced with one
based closely on ESP to simplify implementation and security analysis

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
Other reasons to move to IKEv2 are:

• The use of standard EAP as authentication and asymmetric authentication
• The option to have matching dial-up phase 1 by ID
IKEv2 provides flexibility for traffic selectors. You can specify the payload type for each traffic selector rather
than overloading them with ID payloads.
IKEv2 also supports a setup with an overlay network ID, SA session resumption, and quick crash detection.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
In this section, you will learn about the steps IKEv2 exchange uses to netgotiate an IPsec tunnel.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
Unlike IKEv1, IKEv2 is a reliable protocol: The initiator retransmits a request until it either receives a
corresponding response or it deems the IKE SA to have failed. In the latter case, the initiator discards the IKE
SA and any Child SAs negotiated with the unresponsive peer.
IKEv1 has a clearly demarcated phase 1 exchange, which contains six packets followed by a phase 2
exchange of three packets. The IKEv2 exchange is variable. At best, it can exchange as few as four packets.
At worst, this can increase to as many as 30 packets, depending on the complexity of authentication.
Once the initial exchange takes place, any subsequent traffic then triggers the CREATE_CHILD_SA
exchange, which is the equivalent of the phase 2 exchange in IKEv1.
IKEv2 does not have aggressive mode or main mode.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
IKEv2 doesn’t have a concept of phase 1 or phase 2, but FortiOS CLI and GUI commands and terminology
are IKEv1-centric, so you use that format to configure IKEv2 settings.
The setting configuration for IKEv2 SA takes place in phase 1. The setting configuration for Child_SA is in
phase 2.
There are four exchanges during the IKEv2 negotiation. The initial exchanges are: IKE_SA_INIT and
IKE_AUTH.
IKE_SA_INIT exchange:
• Negotiation of security settings to protect the IKE traffic
• DoS protection (cookie mechanism)
IKE_Auth exchange:
• Mutual authentication of two IKE endpoints
• Configuration settings like IP/mask, DNS and so on
• Child SA: Piggyback setup of a Child_SA. Negotiates IP flow and security settings for the IPsec SA
Create_Child_SA exchange:
• Creates a new Child_SA or rekey an existing Child_SA
• Rekey an IKE SA
Informational exchange:
• Convey control messages between the IKE endpoints

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as
phase 1). SA_INIT is the first round trip of an IKEv2 initial exchange. An SA_INIT exchange usually takes one
round trip.
The exchange is extended to two round trips if the responder requests another KE (INVALID_KE_PAYLOAD
notification), or if the DoS protection (cookie notification) kicks in.
If both KE renegotiation and DoS protection are completed, the exchange increases to three round trips.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
IKE_AUTH (authentication) takes place after SA_INIT and is the last stage of the initial exchange.
It is protected by the cryptographic algorithms and the keys from the SA_INIT.
The peers exchange their identities (IDi, IDr) and provide the proof of their claimed identity (AUTH).
When EAP is not used, IKE_AUTH consists of a single request/response exchange. When EAP is used,
IKE_AUTH consists of multiple request/response exchanges. The number of exchanges depends on the EAP
method being used.
By default, a piggyback Child (IPsec) SA is negotiated along with the IKEv2 SA during IKE_AUTH.
If additional IPsec SAs are needed (i.e. multiple FortiOS phase 2s are configured), they are negotiated during
subsequent CREATE_CHILD_SA exchanges.
By IKEv2 design, no Diffie-Hellman public key (KE) is exchanged during an IKE_AUTH exchange.
Consequently, any phase 2 DH group configuration mismatch between the FGT and the peer, is only
experienced during the first rekey (CREATE_CHILD_SA exchange) of the Child_SA created during
IKE_AUTH.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
This exchange consists of a single request/response pair, and was referred to as a phase 2 exchange in
IKEv1. It be initiated by either end of the IKE_SA after the initial exchanges are completed. All messages
following the initial exchange are cryptographically protected using the cryptographic algorithms and keys
negotiated in the first two messages of the IKE exchange. All subsequent messages included an encrypted
payload, even if they are referred to in the text as "empty". Either endpoint may initiate a CREATE_CHILD_SA
exchange, so in this section the term "initiator" refers to the endpoint initiating this exchange.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
At various points during the operation of an IKE_SA, peers may desire to convey control messages to each
other regarding errors or notifications of certain events. To accomplish this, IKE defines an Informational
exchange. Informational exchanges must occur only after the initial exchanges and are cryptographically
protected with the negotiated keys.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
In this section, you will learn the commands to monitor an IKEv2 tunnel and the commands to debug and
troubleshoot IKEv2.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
The commands to monitor, debug, and troubleshoot IKEv2 are the same as IKEv1.
The command diagnose vpn ike gateway list provides some details about a tunnel. The command
diagnose vpn ike gateway clear closes a phase 1. It’s useful while troubleshooting to force a tunnel
negotiation, but it has to be used with caution.
The command diagnose vpn tunnel list displays the current IPsec SA information for all active
tunnels.
In order to debug the connection of an IPsec IKEv2, use the diagnose debug application ike
command, like you would in IKEv1, and apply a filter with diagnose vpn ike log-filter to gather the
debug output of a specific tunnel.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
Once the debug command diagnose debug application ike is enabled and an IPsec negotiation
starts, you can analyze the IKEv2 negotiation process.
In the initial negotiation, you can see the SA_INIT exchange. The slide shows the SAN_INIT was sent and
that the initiator received the SA_INIT response.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
After a successful SA_INIT exchange, the IKE_AUTH exchange takes place. The debug output shows the
messages received and their response.
The slide shows the AUTH exchange sent by the initiator and the responses that it receives.

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
After IKE_SA_INIT and IKE_AUTH exchanges are successful, the CHILD_SA exchange takes place.
In this exchange, the peers negotiate the CHILD_SA and the traffic selectors (TSr/Tsi).

IPsec―IKEv2
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned about the improvements made to IKEv2, its
negotiation process, and how to debug an IPsec tunnel using the IKEv2 protocol.

Routing
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about advanced routing concepts. You will also learn useful troubleshooting
commands to debug routing issues.

Routing
DO NOT REPRINT
© FORTINET
By demonstrating competence in routing, you will be able to describe how FortiGate routes traffic, diagnose
routing problems that the reverse path forwarding (RPF) check causes, identify sessions that are routed through
a different path, and use debug commands to troubleshoot routing problems.

Routing
DO NOT REPRINT
© FORTINET
In this section, you will learn about general routing concepts and troubleshooting.

Routing
DO NOT REPRINT
© FORTINET
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 that
the originator sends and another one on the first reply packet that the responder sends. 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.

Routing
DO NOT REPRINT
© FORTINET
The flowchart on this slide describes the route lookup process on FortiOS. Note that policy routes can be regular
policy routes, Internet Service Database (ISDB) routes, or SD-WAN rules.
First, FortiGate checks the policy routes. The first type of policy routes that FortiGate checks are the regular
policy routes. If there is a match, and the action is Forward Traffic, FortiGate routes the packet accordingly, as
long as the policy route passes the forward information base (FIB) validation process. If the action is Stop Policy
Routing, FortiGate moves on to check its route cache.
If the packet doesn’t match any of the regular policy routes, FortiGate moves on to check the ISDB routes first,
and then the SD-WAN rules. If the packet doesn’t match any of the SD-WAN rules, FortiGate checks its route
cache.
Next, FortiGate checks the FIB, which is the table that is used to perform standard routing. The FIB can be
described as the routing table from the kernel point of view, and is built mostly out of routes in the routing table,
but also from system-specific entries that FortiOS requires. If the packet doesn’t match any of the routes in the
FIB, FortiGate drops the packet and sends an ICMP destination network unreachable message to the sender.
This slide also shows the FortiOS CLI commands you can use to display the policy routes, route cache entries,
routing table entries, and FIB entries.

Routing
DO NOT REPRINT
© FORTINET
This slide shows the process for selecting which route to use, if there is more than one route to a destination.
First, FortiGate uses the most specific route, which is the one with the longest netmask (smallest subnet). If there
are two or more routes with the same longest netmask, the device selects the one with the shortest distance.
After that, FortiGate uses the lowest metric as the tiebreaker for dynamic routes. In the case of static routes,
FortiGate uses the lowest priority instead. If there are multiple routes with the same netmask, distance, metric,
and priority, FortiGate shares the traffic among all of them. This is called equal-cost multi-path (ECMP). ECMP is
supported for static, BGP, and OSPF routes.

Routing
DO NOT REPRINT
© FORTINET
FortiGate adds a static route to the routing table only if the route meets all of the following requirements:
• The outgoing interface is up
• There is no duplicate route with a shorter distance
• The link health monitor (if configured) is up

Routing
DO NOT REPRINT
© FORTINET
Now, you will review an important routing concept: the reverse path forwarding (RPF) check.
The RPF check protects against IP spoofing attacks and routing loops by checking the route to the source IP
address. This check is performed on only the first packet when the session is being created. If the check fails, the
packet is dropped and the debug flow shows this error: reverse path check fail, drop.

Routing
DO NOT REPRINT
© FORTINET
The example on this slide shows FortiGate using the feasible path RPF check mode. When FortiGate performs
the RPF check, it checks the routing table for a route that matches the source address and incoming interface of
the first original packet.
Based on the topology and routing table shown on this slide, the RPF check results for traffic sourced from each
user are:
• User A: Pass. There is a default route through wan1. This means that all packets received at wan1 pass the
RPF check, regardless of the source address.
• User B: Fail. FortiGate doesn’t have a route to 95.56.234.24 through wan2 in its routing table.
• User C: Fail. Like the user B case, FortiGate doesn’t have a route to 10.0.4.63 through port1 in its routing
table.

Routing
DO NOT REPRINT
© FORTINET
If you consider the packets from user B and user C to be legitimate packets, you can solve the RPF check fail
issue by making sure the routing table contains routes for the return path.
In the example shown on this slide, the administrator adds two new static routes. The static route through wan2 is
a duplicate default route of wan1, but has a lower priority. The two default routes are not ECMP routes because
of the priority difference, but FortiGate keeps both routes in the routing table. The result is that packets from user
B now pass the RPF check.
The static route through port1 references the 10.0.4.0/24 subnet. The subnet includes the user C address
(10.0.4.63), and as a result, packets from user C also pass the RPF check.

Routing
DO NOT REPRINT
© FORTINET
The example on this slide shows FortiGate using the strict RPF check mode. In strict mode, FortiGate also
checks if the matching route is the best route to the source.
Based on the topology and routing table shown on this slide, the RPF check results for traffic sourced from each
user are:
• User A: Pass. There is a default route through wan1. The route is also the best (and only) route to
71.234.149.16.
• User B: Fail. There is a default route through wan2. However, there is a better (more specific) static route to
95.56.234.24 through wan1.
• User C: Pass. FortiGate has a route to 10.0.4.63 through port1 in its routing table. Although the default
routes through wan1 and wan2 are also valid routes for 10.0.4.63, the best route to user C is the route
through port1.
Like the feasible path example, you can solve the RPF fail issue for user B by making the respective changes in
the routing table so the best route to user B is through wan2.

Routing
DO NOT REPRINT
© FORTINET
Content inspection requires that routing be kept as symmetric as possible; that is, traffic must follow the same
path both ways. There are multiple scenarios where asymmetric routing prevents FortiGate from inspecting traffic
content. So, FortiGate routes traffic symmetrically. This means that, in 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 the source and uses that interface to route the return packets,
even when a better route using a different interface exists.

Routing
DO NOT REPRINT
© FORTINET
Now, you will analyze the network topology shown on this slide. The local network 10.1.0.0/24 has three
network devices: a local workstation, local router, and FortiGate port1. Also, 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 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 an ICMP echo request from
the local workstation to the remote server, the packet goes to the local router first, then to FortiGate, then to the
remote router, and finally to the destination. When the ICMP packet arrives at FortiGate, an entry for the
originating traffic is created in the device route cache, which can be validated using the command diagnose ip
rtcache list. This entry contains the interface to source—or the incoming interface where the packet arrived,
which is port2 in this case.

Routing
DO NOT REPRINT
© FORTINET
Additionally, FortiGate creates an entry in the session table. This entry also contains information about the source
interface. To view this information, use the diagnose sys session list command.
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.
Because there is no ICMP echo reply yet, the next hop to the source is still unknown (it is 0.0.0.0). It is
identified with the second routing lookup that occurs with the first reply packet.

Routing
DO NOT REPRINT
© FORTINET
Now, take a look at how FortiGate routes the return packet.
Because there is already a session and route cache entry, when FortiGate receives the ICMP echo reply, it uses
the interface to the source. So, in this case, the device routes the packet through port2 toward the local router,
even though 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, FortiGate adds a second entry to the route cache, this time for the
return traffic.

Routing
DO NOT REPRINT
© FORTINET
Additionally, FortiOS 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, which was previously set to 0.0.0.0.

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

Routing
DO NOT REPRINT
© FORTINET
Take a look at the reply traffic in the example shown on this slide. Use the sniffer tool to view the traffic flow.
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 particular cases, FortiGate accepts this asymmetry, no packets are dropped, and security inspection is
not affected.

Routing
DO NOT REPRINT
© FORTINET
This slide shows an example in which asymmetric routing is not allowed by FortiOS.
1. The server sends an echo request to the PC through port 2 of the local router, effectively bypassing
FortiGate.
2. When it receives the echo request, the PC responds with an echo reply through its default gateway,
10.1.0.2, which is port1 on FortiGate.
3. Because there is no existing session, the echo reply is dropped.
4. All subsequent echo replies are also blocked.
By default, if an echo request does not pass through FortiGate but the response does, the packet is dropped.

Routing
DO NOT REPRINT
© FORTINET
There are scenarios in which it might make sense to allow this type of asymmetric routing. Example cases
include when you are troubleshooting or when you cannot resolve asymmetric routing issues by ensuring that
both ingress and egress traffic pass through FortiGate.
Enabling asymmetric routing causes FortiOS to be unable to inspect all traffic. Malicious traffic could pass
through the FortiGate undetected and compromise the network.
Using the commands on this slide, changes the default routing behavior explained on the previous slide to the
following:
1. The server’s ICMP request bypasses FortiGate reaching the PC.
2. The PC’s echo reply passes through FortiGate. No session is matched. However, the packet is not dropped.
Instead, the packet is passed to the CPU of FortiGate and is then forwarded using the FIB.
3. All subsequent echo replies are handled the same way as in step 2.
4. FortiGate essentially acts as a router. No security inspection is performed.
Remember to disable asymmetric routing if it is used for troubleshooting purposes, once the issue has been
resolved.

Routing
DO NOT REPRINT
© FORTINET
When FortiGate is not applying SNAT, when the routing table changes, FortiGate removes the routing information
from the sessions that are affected by the change. Additionally, FortiGate deletes related route cache entries. So,
FortiGate does two more routing lookups for the next packets in order to learn the new routing information and
store it in the routing table.
This slide shows an example 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 FortiGate must learn this information again. Additionally, the
dirty flag is added.

Routing
DO NOT REPRINT
© FORTINET
You can configure session route persistence at the interface level using the commands shown on this slide. The
default value is disable. If you enable this setting, sessions passing through that interface continue to pass
without being affected by the routing changes. The routing changes apply only to new sessions.
If the route is removed from the FIB, then FortiGate must flag the session as dirty, flush its gateway
information, and reevaluate the session.

Routing
DO NOT REPRINT
© FORTINET
This slide shows the details of an ICMP session established through an interface (T_INET_0) that has the setting
preserve-session-route enabled. Note that only relevant lines of the session are displayed.
Also, note the presence of the route_preserve flag in the session. You can find out the interface name by
using the diagnose netlink interface list command.

Routing
DO NOT REPRINT
© FORTINET
By default, SNAT sessions are not flagged as dirty following a routing change that impacts the session. This is
true if the route in use is still in the FIB. However, if the route is removed from the FIB, then FortiGate flags the
session as dirty, flushes the outgoing interface and gateway information, and then reevaluates the session when
the next packet is received.
To force the reevaluation of SNAT sessions following a related routing change, regardless of whether or not the
route in use is still in the FIB, enable the snat-route-change setting, as shown on this slide.
Note that during the reevaluation of SNAT sessions, if the new route and firewall policy lookup results in a change
of the SNAT IP, then FortiGate drops the packet and clears the session. This means that the impacted application
might have to initiate a new connection to resume network connectivity, especially if the application is TCP based.
This slide shows the debug flow output for a SNAT session during reevaluation. Because the SNAT IP of the new
path (192.2.0.9) is different than the SNAT IP of the current path (192.2.0.1), FortiGate drops the packet
and clears the session. This also means that, from a connectivity point of view, it makes sense to enable snat-
route-change only when the new path for the session uses the same SNAT IP, which can be achieved using
IP pools.

Routing
DO NOT REPRINT
© FORTINET
When you enable auxiliary-session, the FortiGate kernel creates a new auxiliary session and attaches it to
the main session. For each traffic path (incoming and outgoing), FortiGate continues to create a new auxiliary
session.
By default, the system CPU handles dirty sessions that are triggered by reply interface changes. Therefore,
hardware offloading is not used. For this reason, a large amount of traffic that these dirty sessions handle may
result in high CPU utilization and poor performance.
Enabling auxiliary-session under config system settings solves this, by offloading asymmetric
sessions to hardware by creating an auxiliary session (also known as a reflect session). Symmetric traffic
matches the main session, and asymmetric traffic matches the auxiliary session. Both sessions can be offloaded
to hardware. For FortiGate VMs, although hardware offload does not apply, performance is improved because
FortiGate does not have to reevaluate the asymmetric traffic.
Because a new session is created for each route change, the session table could potentially grow significantly in
size.

Routing
DO NOT REPRINT
© FORTINET
In the example shown on this slide, ECMP is configured for both client and server. FortiGate uses ECMP through
port1 and port2 to the client, and ECMP through port3 and port4 to the server.
Based on this example, you can see how sessions are handled on FortiGate:
1. Initially, traffic flows from port1 to port3. FortiGate creates a new session: the main session.
2. The reply from the server is received on port4 and forwarded out port1. FortiGate creates auxiliary session 1
and attaches it to the main session.
3. The next packet from the client is received on port1 and forwarded out port4. FortiGate matches auxiliary
session 1.
4. Additional traffic from the client is received on port2 and leaves through port3. FortiGate creates auxiliary
session 2 and attaches it to the main session.
5. The server reply is received on port3 and leaves through port2. FortiGate matches auxiliary session 2.
6. The second reply is received on port4 and forwarded out port2. FortiGate creates auxiliary session 3 and
attaches it to the main session.
7. The last packet from the client flows from port2 to port4. FortiGate matches auxiliary session 3.
8. Finally, the server reply is received on port3 and leaves through port1. FortiGate matches the main session.
FortiGate can offload all these sessions, if the policy allows offloading.

Routing
DO NOT REPRINT
© FORTINET
The CLI command shown on this slide displays all entries in the routing table. The routing table displays the
routes that make it to the FIB—that is, the best active routes to a destination.
The column on the left indicates the route source. Route attributes are shown inside square brackets. The first
number, in the first pair of attributes, is distance, which applies to both dynamic and static routes. The second
number is metric, which applies to dynamic routes only.
Static routes and dynamic routes also have priority and weight attributes, which are shown as the last pair of
attributes for the respective route. In the case of dynamic routes, the weight is always zero.
This command doesn't show standby or inactive routes, which are present in the routing table database only. For
example, when two static routes to the same destination subnet have different distances, the one with the lower
distance is installed in the routing table, and the one with the higher distance is installed in the routing table
database.

Routing
DO NOT REPRINT
© FORTINET
If you want to view active, standby, and inactive routes, use the CLI command shown on this slide to display the
routing table database entries.
In the example on this slide, the command shows two standby routes: one static and the other BGP. Both standby
routes are standby because there are better routes—lower distance—to the same destination. The better routes
show an asterisk beside the route source to indicate they are FIB entries, and therefore, are used for routing
traffic.
The output also shows one inactive route. Routes are marked as inactive when the corresponding interface is
administratively down, its link is down, or when the link health monitor detected it as down and the update static
route action is enabled.

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

Routing
DO NOT REPRINT
© FORTINET
The route cache contains recently used routing entries in a quick-to-search table. FortiGate consults the route
cache before it consults the routing table, to speed up the routing lookup process.

Routing
DO NOT REPRINT
© FORTINET
FortiOS maintains a policy route table that you can view by running the diagnose firewall proute list
command.
There are three types of policy routes displayed in the policy route table: regular policy routes, ISDB routes, and
SD-WAN rules. Follow these rules to identify each type of policy route in the table:
• Regular policy routes are assigned an ID no higher than 65535. In the output shown on this slide, the first
entry is assigned ID 1, which makes it a regular policy route.
• ISDB routes and SD-WAN rules are assigned an ID higher than 65535. However, SD-WAN rule entries
include the vwl_service field, and ISDB route entries do not. The vwl_service field indicates the ID and
the name of the rule from the SD-WAN configuration perspective. In the output shown on this slide, the second
entry is an ISDB route and the third entry is an SD-WAN rule.
Note that although IDs for regular policy routes are in the 1 to 65535 range, the maximum number of regular
policy routes that you can configure are much lower and varies among FortiGate models. For example, you can
configure up to 512 regular policy routes on a FortiGate 300D. For more information about the maximum
supported values per FortiGate model, refer to the FortiOS Maximum Values Table on docs.fortinet.com.
Alternatively, you can run the print tablesize command on the FortiGate CLI to get the maximum values for
your FortiGate.

Routing
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned about advanced routing concepts and useful
troubleshooting commands to debug routing issues.

BGP
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about Border Gateway Protocol (BGP) and how to monitor it and troubleshoot
common issues.

BGP
DO NOT REPRINT
© FORTINET
By demonstrating competence in BGP, you will be able to monitor and check the status of BGP communication,
as well as troubleshoot the most common BGP issues.

BGP
DO NOT REPRINT
© FORTINET
In this section, you will briefly review BGP.

BGP
DO NOT REPRINT
© 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 (IGP), such as OSPF or RIP.

BGP
DO NOT REPRINT
© 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.

BGP
DO NOT REPRINT
© FORTINET
A BGP router stores routing information in three logical tables:

• The RIB-in table contains all 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.

BGP
DO NOT REPRINT
© FORTINET
This slide shows a flowchart 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.

BGP
DO NOT REPRINT
© 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 ASs through which the traffic must
pass to reach the destination.

BGP
DO NOT REPRINT
© 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
This slide shows a list of the BGP attributes and their attribute types that FortiGate supports.

BGP
DO NOT REPRINT
© FORTINET
FortiGate uses some of the BGP attributes during the routing selection process. If all the 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.

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

BGP
DO NOT REPRINT
© 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

BGP
DO NOT REPRINT
© FORTINET
This slide shows the debug command you usually use first, to get an overview of the BGP status, and the status
of all its neighbors. This 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 that the local FortiGate
received from that neighbor.

BGP
DO NOT REPRINT
© FORTINET
You can use the command shown on this slide to get detailed information about each BGP neighbor. The
information includes peer IP, peer router ID, remote AS, BGP state, various timers, and message counters.

BGP
DO NOT REPRINT
© FORTINET
The information also shows the number of prefixes announced and accepted, number of times that the session
has dropped, and the last time it was reset.

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

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

BGP
DO NOT REPRINT
© FORTINET
You can use the get router info bgp network command to display the BGP database. It lists all prefixes
that all neighbors advertise, as well as the local router.
Highlighted on this slide are also the origin codes used for the BGP table. i for IGP indicates the network
command was used to advertise a route. This applies to the last route in the table, 10.20.30.0/24. All other
advertised routes are tagged with the ? sign indicating the route was advertised from another routing protocol
using redistribution. e for EGP is used only for legacy route advertisement and is rarely seen.

BGP
DO NOT REPRINT
© 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 commands shown on this slide.

BGP
DO NOT REPRINT
© FORTINET
You can view BGP-related router events on the GUI. You can click any logged entry to view the details.

BGP
DO NOT REPRINT
© FORTINET
In this section, you will learn about common BGP issues and how to solve them.

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

• Check that the local router can reach the remote peer.
• Ensure that TCP port 179 is not blocked between the peers.
• Check the TCP session.
• Check the BGP session.
• If the BGP session is established, check the prefixes received and advertised by each peer.

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

BGP
DO NOT REPRINT
© FORTINET
One common issue is that there is no route to the BGP neighbor in the FortiOS FIB. If that is the case, the real-
time BGP application debug will output the message shown on this slide: Sock Status: 113-No route to
host. You can also verify this using the get router info bgp summary and get router info bgp
neighbor commands. Both outputs show that the status is Active, meaning the TCP 3-way handshake could
not be established. The solution is to ensure there is an active route to the IP address of the BGP neighbor.

BGP
DO NOT REPRINT
© FORTINET
This slide and the next slide 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 the OpenSent state.

BGP
DO NOT REPRINT
© FORTINET
This slide shows the real-time debug output containing the OpenConfirm after the keepalive is received from
the neighbor, as well as the establishment of the connection.
The output also lists the prefixes FortiGate received after the BGP session is established.

BGP
DO NOT REPRINT
© FORTINET
The command shown on this slide 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.

BGP
DO NOT REPRINT
© FORTINET
In the troubleshooting example shown on this slide, FGT-A is not receiving the prefix that FGT-B advertised. The
issue here is that the subnet mask of the prefix is misconfigured on FGT-B, prompting FortiOS to not advertise
the network to other BGP peers.

BGP
DO NOT REPRINT
© FORTINET
There are two ways to fix the issue seen on the previous slide. The first way is to change the prefix manually to
represent the network assigned to port3 on FGT-B. This is the recommended method. Changing the subnet mask
from 255.255.0.0 to 255.255.255.0 allows FGT-B to advertise the prefix to its peers.
Another option is to disable the set network-import-check. This is the safety mechanism that prevented
FOS from advertising the falsely configured route. It is generally not recommended to disable this because it
ensures only the correct networks are advertised to avoid routing issues.

BGP
DO NOT REPRINT
© FORTINET
In the scenario shown on this slide, FGT-A again does not receive the expected prefix from FGT-B. FGT-A has
been configured with a prefix-list-in, which controls whether networks that neighbors advertise are accepted into
the routing table.

BGP
DO NOT REPRINT
© FORTINET
A closer look into the prefix configuration reveals that any peer advertised network within the 172.16.0.0/16
subnet is not accepted into the BGP database.

BGP
DO NOT REPRINT
© FORTINET
The preferred solution is to add an additional rule, specifically allowing the 172.16.54.0 prefix in the same
prefix-list. Unlike firewall policies, the list is not evaluated from the top-down. Every rule in the list is
inspected.

BGP
DO NOT REPRINT
© FORTINET
After configuring the additional rule, the prefix is accepted and added into the BGP database.

BGP
DO NOT REPRINT
© FORTINET

OSPF
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about OSPF and how to monitor and troubleshoot it.

OSPF
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding OSPF, you will be able to understand, monitor, and troubleshoot
OSPF.

OSPF
DO NOT REPRINT
© FORTINET
In this section, you will briefly review OSPF.

OSPF
DO NOT REPRINT
© FORTINET
With 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 advertise their OSPF information
again. Between these 30-minute intervals, routers send updates only if they detect topology changes. So, it is a
relatively quiet protocol, as long as the network topology is stable. In large networks, using OSPF requires good
planning and may be difficult to troubleshoot.

OSPF
DO NOT REPRINT
© 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 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 into the device routing table.

OSPF
DO NOT REPRINT
© FORTINET
LSAs contain the topology information that OSPF peers exchange. The LSDB of a router is populated with
information from the local LSAs and all the LSAs received from other routers.

OSPF
DO NOT REPRINT
© FORTINET
A 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 that both
routers have identical copies of the LSDB.

OSPF
DO NOT REPRINT
© 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.

OSPF
DO NOT REPRINT
© FORTINET
In this section, you will learn the commands necessary for monitoring OSPF.

OSPF
DO NOT REPRINT
© FORTINET
The command shown on this slide provides detailed information about the OSPF process.

OSPF
DO NOT REPRINT
© FORTINET
The command on this slide shows information about each area the router belongs to.

OSPF
DO NOT REPRINT
© FORTINET
For OSPF information about each interface, use the command shown on this slide. It shows:
• Network type, in this case broadcast multiaccess
• If the interface is a DR or a BDR
• DR and BDR IDs and IP addresses
• Number of adjacencies and traffic statistics

OSPF
DO NOT REPRINT
© FORTINET
The command on this slide shows a summary of the statuses of all the OSPF neighbors. For each neighbor, it
displays the adjacency state and whether the interface is a DR, a BDR, or neither (DROther). The response
displays a dash after the state if the neighbor is in a point-to-point network.

OSPF
DO NOT REPRINT
© FORTINET
The command shown on this slide provides a summary of all the LSDB entries on FortiGate, ordered by LSA
types. It shows the type 1 LSAs (router link states) first, then the type 2 LSAs (net link states).

OSPF
DO NOT REPRINT
© FORTINET
The command shown on this slide lists the LSAs that originated on the local FortiGate.

OSPF
DO NOT REPRINT
© FORTINET
Use the command shown on this slide to see details about type 1 LSAs.

OSPF
DO NOT REPRINT
© FORTINET
This slide shows a sample of more output from the command get router info ospf database router
lsa.

OSPF
DO NOT REPRINT
© FORTINET
In this section, you will learn the tools and tips to troubleshoot OSPF issues.

OSPF
DO NOT REPRINT
© FORTINET
Follow these steps to troubleshoot an OSPF problem between two peers:

• Check that the local router can reach the remote peer. IP addresses must be in the same subnet and have the
same subnet mask.
• Ensure that IP protocol 89 is not blocked.
• Hello and Dead intervals must match.
• The OSPF router ID for each peer must be unique. Duplicate router IDs are not allowed.
• Do the MTUs match?
• If authentication is enabled, the type and password must match on both sides.

OSPF
DO NOT REPRINT
© FORTINET
The OSPF real-time debug displays information about adjacency establishments and OSPF errors. It also shows
information about network topology changes.
You can enable the zl flag for the real-time debug to persist after a routing-process restart.

OSPF
DO NOT REPRINT
© FORTINET
This is a sample of output generated by the OSPF real-time debug. This sample shows the Hello packet being
sent.

OSPF
DO NOT REPRINT
© FORTINET
This is another sample of output generated by the OSPF real-time debug. This sample shows the Hello packet
being received.

OSPF
DO NOT REPRINT
© FORTINET
This slide shows a sample output of the OSPF real-time debug when adjacency fails. In this case, OSPF
authentication fails. We can see the DR sending a Hello message with AuType 1, indicating authentication is
configured and required for successful adjacency. In the received HELLO messages from the neighbor router, the
AuType is 0. As such, the error message in the received HELLO indicates that there is an authentication type
mismatch.

OSPF
DO NOT REPRINT
© FORTINET
This slide shows additional error messages that are helpful for troubleshooting common adjacency issues.
Authentication error indicates that the authentication type is the same for both peers, but the passwords
configured are not. A hello or dead interval timer mismatch can be confirmed by the error messages
HelloInterval mismatch and RouterDeadInterval mismatch respectively. The error message: MTU size
is too large, indicates an MTU mismatch.

OSPF
DO NOT REPRINT
© FORTINET
In the scenario shown on this slide, FGT-A is configured to redistribute all static routes. Note that default static
routes are not advertised by default. In this case, only the 8.8.8.8/32 route is advertised.

OSPF
DO NOT REPRINT
© FORTINET
The routing table on FGT-B shows that the advertised route 8.8.8.8/32 is missing in the routing table. However,
you can confirm that the route is being advertised successfully by looking at the LSDB using the command get
router info ospf database brief. This also verifies successful OSPF adjacency between FGT-A and
FGT-B.

OSPF
DO NOT REPRINT
© FORTINET
The issue in scenario 1 is that FGT-B is configured with a distribute-list-in that denies any subnet within
the 8.8.8.0/24 network to be injected into the routing table. The distribute-list-in is configured under
config router ospf. The list itself is configured under config router prefix-list.

OSPF
DO NOT REPRINT
© FORTINET
The recommended way to solve this is by adding another rule to the prefix list that applies to the OSPF
configuration. In this case, the change is made to the Deny-8.8.8.0/24 prefix list. To have FortiOS inject the
route from the LSDB into the routing table, you must add the subnet 8.8.8.8/32. Unlike firewall policies, the list is
not evaluated from the top down. Every rule within the list is inspected.

OSPF
DO NOT REPRINT
© FORTINET
The routing table shown on this slide confirms that the advertised route from FGT-A has been successfully
injected. You can also see that the distribution-list-in command has no impact on the LSDB.

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

OSPF
DO NOT REPRINT
© FORTINET
You can view OSPF-related router events on the GUI. You can click any logged entry to view the details.

OSPF
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned about OSPF concepts, and how to configure and
troubleshoot OSPF.

Solution Slides
DO NOT REPRINT
© FORTINET
These slides contain the solutions to the troubleshooting exercises.

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the traffic and session monitoring lab.

Solution Slides
DO NOT REPRINT
© FORTINET
There were four problems:

• Unable to telnet to ISFW (10.1.10.254)
• No Internet access
• Unable to telnet to Linux-Router (100.64.1.254)

Solution Slides
DO NOT REPRINT
© FORTINET
In the first problem, packets were arriving to ISFW as verified with the sniffer command. However ISFW was not
replying with the SYN/ACK packets.

Solution Slides
DO NOT REPRINT
© FORTINET
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 could be 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

Solution Slides
DO NOT REPRINT
© FORTINET
The problem was actually a local-in policy blocking the telnet traffic. Removing that policy fixed the problem.
If you tried to view the local-in policy on the GUI, you wouldn’t have seen the user created policy. You can only
view them on the CLI.

Solution Slides
DO NOT REPRINT
© FORTINET
For the second 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).

Solution Slides
DO NOT REPRINT
© 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.

Solution Slides
DO NOT REPRINT
© 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.

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the security fabric lab.

Solution Slides
DO NOT REPRINT
© FORTINET
There were three problems:

1. Unable to reach ISFW from NGFW-1
Solution: Enable or create policy on NGFW-2 to allow TCP port 8013
2. Security Fabric is not enabled on port4 on ISFW
Solution: Enable Security Fabric for port4 on ISFW
3. NGFW-1 is not authorized
Solution:NGFW-1 needs to be authorized on ISFW

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the Authentication lab.

Solution Slides
DO NOT REPRINT
© FORTINET
There are two problems:

1. Why User Authentication request is not displayed?
Solution: The LDAP “User” group is nor configured on Firewall Policy #1, that’s why the User Authentication
request is not displayed.
2. Why FortiGate doesn’t forward an authentication request to the LDAP server?

Solution: The password for the account student fails because there’s a local “student” user account, and
FortiGate doesn’t forward an authentication request to the LDAP server. Remove the local “student” account.

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the FSSO lab.

Solution Slides
DO NOT REPRINT
© FORTINET
The problem is that the user on Client-10 VM is unable to browse the internet. The FSSO user pushed by the
script is on FSSO group AD_USERS. Firewall policy #1 has configured the Local User Group “Training” which is
linked to the FSSO Group “Users”.
Solution: On local user group “Training”, replace the FSSO group “Users” with FSSO group “AD_Users”.

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercises in the Security Profile lab.

Solution Slides
DO NOT REPRINT
© 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 Technology), which is allowed in the FortiGate configuration.

Solution Slides
DO NOT REPRINT
© FORTINET
The second problem was that ISFW was not blocking the FTP file transfer of an infected file. The debug flow was
not showing the message sent to the application layer, which means that ISFW was actually not
inspecting the traffic. The reason that this was not happening was because the FTP connection was using a non-
standard port—222. Switch the

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the High Availability lab.

Solution Slides
DO NOT REPRINT
© FORTINET
The sniffer capture shows that Ethernet proto 0x8890 is flowing in one direction from NGFW-1 to NGFW-2. This
is because, NGFW-2 has configured a customized “ha-eth-type”.
Solution: On NGFW-2 set setting “ha-eth-type” to default value “8890”

Solution Slides
DO NOT REPRINT
© FORTINET
The debug output from command diagnose debug application hatalk -1 on both FortiGate devices
show a password mismatch issue:
Solution: Configure a new password for the HA configuration on both FortiGate devices

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will see the solutions for the troubleshooting exercise in the IPsec lab.

Solution Slides
DO NOT REPRINT
© FORTINET
The first problem was a misconfiguration in the phase 1. One side was configured with 3DES, the other side was
configured with AES.

Solution Slides
DO NOT REPRINT
© FORTINET
The second problem was a mismatch in the pre-shared key.

Solution Slides
DO NOT REPRINT
© FORTINET
The third problem is that the sniffer shows that the ESP packets from Spoke-2 are not arriving at Spoke-1. So the
most likely reason for this is that the ESP packets are being blocked or dropped in transit (Linux-Router).

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will see the solutions for the troubleshooting exercise in the IPSec-IKEv2 lab.

Solution Slides
DO NOT REPRINT
© FORTINET
The first problem was a misconfiguration in the phase 1. One side was configured with 3DES, the other side was
configured with AES.

Solution Slides
DO NOT REPRINT
© FORTINET
Status of Phase 1 will be shown as up, but Phase 2 as down.
Solution: Under Phase 2 configure matching dhgrp setting

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the routing lab.

Solution Slides
DO NOT REPRINT
© 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.
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. You can enable the snat-route-change setting as shown on
this slide.

Solution Slides
DO NOT REPRINT
© FORTINET
The default route configuration was not working as desired. The default route using port2 was inactive.

Solution Slides
DO NOT REPRINT
© FORTINET
The port2 default route’s distance was higher than the port1 default route. In order for both default routes to be
active, they must have the same distance. Also, the port2 priority value was lower than port1 route’s priority
value.

Solution Slides
DO NOT REPRINT
© FORTINET
Why was traffic to 100.64.3.1 taking port2? The debug flow showed the reason. There was a policy-based
route overriding the static route configuration.

Solution Slides
DO NOT REPRINT
© FORTINET
Removing the policy-based route fixed the problem.

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the BGP lab.

Solution Slides
DO NOT REPRINT
© FORTINET
The BGP neighbors were not coming up because NGFW-1 was configured with the remote AS 200, but the ISP
AS is 100.

Solution Slides
DO NOT REPRINT
© FORTINET
Changing the remote AS number from 200 to 100 fixes the problem.

Solution Slides
DO NOT REPRINT
© FORTINET
The second problem is that NGFW-1 is receiving the prefix 8.8.8.8/32 through port2. This was causing all the
traffic destined to 8.8.8.8 to be routed through port2 instead of port1.

Solution Slides
DO NOT REPRINT
© 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.
Static route can also be used to configure 8.8.8.8/32 traffic to traverse port1.

Solution Slides
DO NOT REPRINT
© FORTINET
We will see the solutions for the troubleshooting exercise in the OSPF lab.

Solution Slides
DO NOT REPRINT
© FORTINET
The OSPF real time debug showed why the adjacency was not coming up. The Linux Server is using the router
ID 0.0.0.2, which is also being used by DCFW.

Solution Slides
DO NOT REPRINT
© FORTINET
To solve this problem from the DCFW side, change the DCFW router ID from 0.0.0.2 to any other ID available.

Solution Slides
DO NOT REPRINT
© FORTINET
If you applied the fix on DCFW, you should see the Linux-Router (0.0.0.0.2) adjacency coming up.

Solution Slides
DO NOT REPRINT
© FORTINET
DCFW real-time debug is showing authentication type mis-match.

Solution Slides
DO NOT REPRINT
© FORTINET
To solve this problem from the DCFW side, delete or modify the interface configuration to require no
authentication.

Dynamic Routing Supplement
DO NOT REPRINT
© FORTINET
In this lesson, you will review Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP) concepts.

DO NOT REPRINT
© FORTINET
In this section, you will review OSPF concepts.

DO NOT REPRINT
© FORTINET
With 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 advertise their OSPF information
again. Between these 30-minute intervals, routers send updates only if they detect topology changes.. So, it is a
relatively quiet protocol, as long as the network topology is stable. In large networks, using OSPF requires good
planning and may be difficult to troubleshoot.

DO NOT REPRINT
© 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 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 into the device routing table.

DO NOT REPRINT
© FORTINET
The topology information exchanged by OSPF peers is contained in LSAs. The LSDB of a router is populated
with information from the local LSAs and all the LSAs received from other routers.

DO NOT REPRINT
© 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 to how fast or preferable that
interface is. An OSPF route cost is the sum of the costs of all interfaces to the final destination.

DO NOT REPRINT
© FORTINET
This slide and the next slide 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 the example shown on
this slide, 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.

DO NOT REPRINT
© 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 the router
repeats multiple times until it finds the best routes. 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.

DO NOT REPRINT
© FORTINET
You can segment an OSPF network into areas. Each area is identified by a unique number, which you can define
in decimal or IP address formats.

DO NOT REPRINT
© FORTINET
Each area has its own separate LSDB. All routers in the same area maintain an identical copy of the LSDB of an
area. As you will learn in this lesson, 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.

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

DO NOT REPRINT
© 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 ABR 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.

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

DO NOT REPRINT
© FORTINET
There are three types of OSPF networks:
• Point-to-point networks contain only two peers, one at each end of a point-to-point link.
• Broadcast networks support more than two attached routers. They also support sending messages to
multiple recipients (broadcasting).
• Point-to-multipoint networks support more than two attached routers. However, they do not support
broadcasting.

DO NOT REPRINT
© 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.

DO NOT REPRINT
© 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.

DO NOT REPRINT
© FORTINET
In any multi-access network there is one DR and one BDR. The OSPF network elects the router with the highest
priority as the DR. If two or more routers are tied with the highest priority, the network elects the router with the
highest OSPF ID.
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 BDR. The DR forwards the link state information from one
router to another. This simplifies the number of adjacencies required in multi-access networks.

DO NOT REPRINT
© FORTINET
This slide shows the multicast addresses that OSPF uses 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.

DO NOT REPRINT
© FORTINET
There are 11 LSA types. This lesson covers the following five most commonly used types:
• 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.
You will see examples of each of these five types in the next slides.

DO NOT REPRINT
© 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.

DO NOT REPRINT
© FORTINET
Only DRs advertise Type 2 LSAs. In the example shown on this slide, 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.

DO NOT REPRINT
© FORTINET
Type 3 LSAs contain summarized link state information. They are advertised only by ABRs. In the example
shown on this slide, 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 shown on the right side of the diagram. 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.

DO NOT REPRINT
© FORTINET
An ASBR advertises itself by sending type 1 LSAs. These LSAs have the E-bit on in the OSPF header. Like 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 the example shown
on this slide, 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 area 1.

DO NOT REPRINT
© 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), which are not covered in this lesson. Type 5 LSAs are not advertised to stub or NSSAs.

DO NOT REPRINT
© 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 route over the type 2 route.

DO NOT REPRINT
© FORTINET
In this section, you will review BGP concepts and how to configure BGP on FortiGate.

DO NOT REPRINT
© 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.

DO NOT REPRINT
© FORTINET
BGP can serve one of two purposes: external BGP (EBGP) or internal BGP (IBGP).
An exterior gateway protocol (EGP) exchanges routing information between ASs. 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 an
EBGP communication, the whole BGP routing table is exchanged. After that, only network updates are sent.

DO NOT REPRINT
© 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.

DO NOT REPRINT
© FORTINET
There are three types of ASs:

• 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.
• Multihomed AS also handles and routes local traffic only, but it has multiple connections to different ASs. 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 ASs
(transit traffic). An ISP is an example of a transit AS.

DO NOT REPRINT
© 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.
RRs help to reduce the number of IBGP sessions inside an AS. An RR forwards the routes learned from one peer
to the other peers. If you configure RRs, you don’t need to create a full mesh IBGP network. RRs pass the routing
updates to other RRs and border routers within the AS.

DO NOT REPRINT
© FORTINET
In a BGP RR configuration, the AS is divided into different clusters that each include an RR and clients. The client
routers communicate route updates only to the RR in the cluster. The RR communicates with other RRs and
border routers. FortiGate can be configured as either an RR or a client.

DO NOT REPRINT
© FORTINET
A BGP router stores routing information in three logical tables. The RIB-in table contains all 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.

DO NOT REPRINT
© FORTINET
This slide shows a flowchart 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.

DO NOT REPRINT
© 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 ASs through which the traffic must
pass to reach the destination.

DO NOT REPRINT
© 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
This slide shows a list of the BGP attributes and their attribute types that FortiGate supports.

DO NOT REPRINT
© FORTINET
FortiGate uses some of the BGP attributes during the routing selection process. If all the 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.

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

DO NOT REPRINT
© 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.

DO NOT REPRINT
© 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 with a destination subnet that 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.

DO NOT REPRINT
© FORTINET
By default, the subnets under the config network command, and the subnets redistributed from other routing
protocols, are advertised to all the neighbors.
With a prefix list, you can be more selective about which prefixes to advertise to each neighbor. Additionally,
prefix lists allow you to select which prefixes you want to use from each neighbor. This example shows a prefix
list that allows the prefix 10.0.0.0/8, but blocks the prefix 10.1.0.0/16. By default, all traffic that does not
match a prefix list is denied. The prefix list is applied in the incoming direction from the neighbor 10.3.1.254.
The local FortiGate applies this filter for all 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.

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

Fortinet Network Security Support Engineer Study Guide For Fortios 72

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fortinet Network Security Support Engineer Study Guide For Fortios 72

Uploaded by

Copyright:

Available Formats

DO NOT REPRINT

Network Security Support

Fortinet Product Documentation

Fortinet Knowledge Base

Fortinet Fuse User Community

Fortinet Product Support

Fortinet Training Program Information

Fortinet | Pearson VUE

Fortinet Training Institute Helpdesk (training questions, comments, feedback)

Network Security Support Engineer 7.2 Study Guide 4

By demonstrating a competent understanding of troubleshooting concepts, you will be able to set up a

Network Security Support Engineer 7.2 Study Guide 5

Network Security Support Engineer 7.2 Study Guide 6

Network Security Support Engineer 7.2 Study Guide 7

Network Security Support Engineer 7.2 Study Guide 8

Network Security Support Engineer 7.2 Study Guide 9

Network Security Support Engineer 7.2 Study Guide 10

Network Security Support Engineer 7.2 Study Guide 11

Network Security Support Engineer 7.2 Study Guide 12

Network Security Support Engineer 7.2 Study Guide 13

Network Security Support Engineer 7.2 Study Guide 14

Network Security Support Engineer 7.2 Study Guide 15

Network Security Support Engineer 7.2 Study Guide 16

Network Security Support Engineer 7.2 Study Guide 17

Network Security Support Engineer 7.2 Study Guide 18

Network Security Support Engineer 7.2 Study Guide 19

Network Security Support Engineer 7.2 Study Guide 20

Network Security Support Engineer 7.2 Study Guide 21

Network Security Support Engineer 7.2 Study Guide 22

Network Security Support Engineer 7.2 Study Guide 23

Network Security Support Engineer 7.2 Study Guide 24

The verbose setting has six verbosity levels:

Network Security Support Engineer 7.2 Study Guide 25

Network Security Support Engineer 7.2 Study Guide 26

Network Security Support Engineer 7.2 Study Guide 27

Network Security Support Engineer 7.2 Study Guide 28

In this lesson, you will learn about FortiOS System Resources.

Network Security Support Engineer 7.2 Study Guide 29

Network Security Support Engineer 7.2 Study Guide 30

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

Network Security Support Engineer 7.2 Study Guide 31

Network Security Support Engineer 7.2 Study Guide 32

Network Security Support Engineer 7.2 Study Guide 33

Network Security Support Engineer 7.2 Study Guide 34

Network Security Support Engineer 7.2 Study Guide 35

If the IPS engine determines that the session needs to be decrypted:

Network Security Support Engineer 7.2 Study Guide 36

Network Security Support Engineer 7.2 Study Guide 37

Network Security Support Engineer 7.2 Study Guide 38

The command shown on this slide displays:

Network Security Support Engineer 7.2 Study Guide 39

FortiGate allocates memory for five main purposes:

You will learn about each of these purposes in this lesson.

Network Security Support Engineer 7.2 Study Guide 40

Network Security Support Engineer 7.2 Study Guide 41

Network Security Support Engineer 7.2 Study Guide 42

Network Security Support Engineer 7.2 Study Guide 43

Network Security Support Engineer 7.2 Study Guide 44

Network Security Support Engineer 7.2 Study Guide 45

• ipsengine, scanunitd, and other inspection processes

Network Security Support Engineer 7.2 Study Guide 46

Network Security Support Engineer 7.2 Study Guide 47

Network Security Support Engineer 7.2 Study Guide 48