DO NOT REPRINT

© FORTINET

Enterprise Firewall
Study Guide
for FortiOS 6.4
DO NOT REPRINT
© FORTINET
Fortinet Training
https://training.fortinet.com

Fortinet Document Library

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 Support
https://support.fortinet.com

FortiGuard Labs
https://www.fortiguard.com

Fortinet Network Security Expert Program (NSE)

https://training.fortinet.com/local/staticpage/view.php?page=certifications

Fortinet | Pearson VUE

https://home.pearsonvue.com/fortinet

Feedback
Email: courseware@fortinet.com

6/26/2020
DO NOT REPRINT
© FORTINET

TABLE OF CONTENTS

01 Security Fabric 4
02 FortiOS Architecture 35
03 Traffic and Session Monitoring 87
04 Routing 128
05 FortiGuard 168
06 High Availability 202
07 Central Management 237
08 OSPF 265
09 Border Gateway Protocol 310
10 Web Filtering 349
11 Intrusion Prevention System 372
12 IPsec 412
13 Autodiscovery VPN 457
Solution Slides 491
 Security Fabric
DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the Fortinet Enterprise Firewall solution and the Fortinet Security Fabric.

Enterprise Firewall 6.4 Study Guide 4

 Security Fabric
DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in the Fortinet Security Fabric, you will be able to describe the Fortinet Enterprise
Firewall solution. You will also be able to configure the Fortinet Security Fabric, perform a security rating audit of
your Security Fabric, and configure automation.

Enterprise Firewall 6.4 Study Guide 5

 Security Fabric
DO NOT REPRINT
© FORTINET

In this section, you will learn about the Fortinet Enterprise Firewall solution at a high level.

Enterprise Firewall 6.4 Study Guide 6

 Security Fabric
DO NOT REPRINT
© FORTINET

The traditional way of protecting a network by securing the perimeter has become a thing of the past. Network
and security administrators today must protect against a wide range of threats such as zero-day attacks, APTs,
polymorphic malware, and many more. They must also protect the network from any potential insider threats.
BYOD and evolving cloud technologies are creating borderless networks, which is further compounding the
challenge of securing such complex networks.

Enterprise Firewall 6.4 Study Guide 7

 Security Fabric
DO NOT REPRINT
© FORTINET

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

Malware can easily bypass any entry-point firewall, and get inside the network. This could happen through an
infected USB stick, or an employee’s compromised personal device being connected to the corporate network.
Additionally, network administrators can no longer take for granted that everything and everyone inside the
network can be trusted. Attacks can now come from inside the network. To secure such a vast network, you must
apply the zero-trust model. The attack can come from anywhere, using any method, and affect anything.

Enterprise Firewall 6.4 Study Guide 8

 Security Fabric
DO NOT REPRINT
© FORTINET

In the same way that threats and network technologies have evolved, your network security strategies must
evolve too. You must apply end-to-end security, from the endpoints to the cloud. Additionally, you must deploy
internal segmentation firewalls to segment the network so that any breach coming from inside can be contained in
one segment of the network, without reaching other segments.

However, there are challenges to implementing these measures. You need to implement multiple layers of
security, from the endpoints, through the protected services, through the network entry points, and up to the
cloud. This usually implies the use of multiple vendors, which means no central management and no central
visibility over what is happening in the network.

Enterprise Firewall 6.4 Study Guide 9

 Security Fabric
DO NOT REPRINT
© FORTINET

The Fortinet Enterprise Firewall solution answers those challenges. It offers effective and fast end-to-end security
with a consolidated operating system: FortiOS. The core of the solution is the Security Fabric, which enables the
communication of all the security devices in an enterprise network. The Fortinet Enterprise Firewall solution offers
guidelines about where to install your network security devices and what roles they’ll have in each part of the
enterprise network. You can manage all of these deployments using a FortiManager, and deliver single-pane-of-
glass management and reporting across the enterprise.

Enterprise Firewall 6.4 Study Guide 10

 Security Fabric
DO NOT REPRINT
© FORTINET

In the Enterprise Firewall solution, each FortiGate device has a specific role, depending on where it is installed
and what assets it’s protecting. In general, there are five roles:
• Distributed enterprise firewall (DEFW)
• Cloud firewall (CFW)
• Next-generation firewall (NGFW)
• Datacenter firewall (DCFW)
• Internal segmentation firewall (ISFW)

In this lesson you will learn about the DEFW, NGFW, DCFW, and ISFW.

Please note that these are not different types of FortiGate models. You can define these roles depending on
where FortiGate is installed.

Enterprise Firewall 6.4 Study Guide 11

 Security Fabric
DO NOT REPRINT
© FORTINET

NGFWs are usually deployed for firewall, application visibility, intrusion prevention, malware detection, and VPNs.
NGFWs can play the traditional role of the entry-point firewall or, depending on the network infrastructure, can be
deployed in the core.

Enterprise Firewall 6.4 Study Guide 12

 Security Fabric
DO NOT REPRINT
© FORTINET

DCFWs protect corporate services. They focus on inspecting incoming traffic and are usually installed at the
distribution layer.

The throughput requirements of DCFW is the highest of all deployment roles. This can range from 10Gbps all the
way up to 1Tbps. Because of the high performance requirements, in most cases the security functions are kept to
a minimum: firewall, application control, and IPS.

Enterprise Firewall 6.4 Study Guide 13

 Security Fabric
DO NOT REPRINT
© FORTINET

ISFWs split your network into multiple security segments. They serve as breach containers for attacks that come
from inside. Firewall, application control, web filtering, and IPS are the features that are commonly enabled in
these firewalls. It’s also a good place to perform antivirus, and implement sandbox inspection so you can isolate
specific devices in specific segments and prevent propagation.

Enterprise Firewall 6.4 Study Guide 14

 Security Fabric
DO NOT REPRINT
© FORTINET

DEFWs are usually smaller devices installed in branch offices and remote sites. Distributed enterprises usually
don’t follow a standardized enterprise network design, and therefore multiple layers are collapsed into one or two
layers. They are connected to the corporate headquarters using a VPN.

DEFWs are all-in-one security devices, doing firewall, application control, IPS, web filtering, and antivirus
inspection.

Enterprise Firewall 6.4 Study Guide 15

 Security Fabric
DO NOT REPRINT
© FORTINET

In this section, you will learn about the Fortinet Security Fabric.

Enterprise Firewall 6.4 Study Guide 16

 Security Fabric
DO NOT REPRINT
© FORTINET

The Fortinet Security Fabric ties your network together to provide visibility and control. The Fortinet Security
fabric covers:

• Zero-trust network access

• Security-driven networking
• Dynamic cloud security
• AI-driven security operations
• Fabric management center

Enterprise Firewall 6.4 Study Guide 17

 Security Fabric
DO NOT REPRINT
© FORTINET

The Fortinet Security Fabric delivers a unified approach that is broad, integrated, and automated. It reduces and
manages the attack surface through integrated broad visibility, stopping advanced threats through integrated AI-
driven breach prevention, while reducing complexity through automated operations and orchestration.

The Fortinet Security Fabric segments the entire network—from the Internet of things (IoT) to the cloud—to
provide an end-to-end solution.

Enterprise Firewall 6.4 Study Guide 18

 Security Fabric
DO NOT REPRINT
© FORTINET

Two or more FortiGate devices and FortiAnalyzer are the mandatory products at the core of the solution. To add
more visibility and control, Fortinet recommends adding FortiManager, FortiAP, FortiClient, FortiSandbox,
FortiMail, and FortiSwitch. The solution can be extended by adding other network security devices.

Enterprise Firewall 6.4 Study Guide 19

 Security Fabric
DO NOT REPRINT
© FORTINET

The Security Fabric follows a tree model. You must configure the root FortiGate first. This includes FortiAnalyzer
registration and, if any, FortiManager registration. The branch FortiGate devices connect to upstream FortiGate
devices to form the Security Fabric tree.

All FortiGate devices in the Security Fabric must have bidirectional FortiTelemetry connectivity. FortiTelemetry
uses TCP port 8013. FortiGate uses the FortiTelemetry protocol to communicate with other FortiGate devices
and distribute information about the network topology. FortiGate also uses FortiTelemetry to integrate with
FortiClient.

The root FortiGate collects the network topology information and forwards it to FortiAnalyzer using the
FortiAnalyzer API. FortiAnalyzer combines that information with the logs received from all FortiGate devices to
generate different topology views, as well as indicators of compromise (IoC), in cases when end-points get
compromised. FortiAnalyzer sends the topology views and the IoC events to the root FortiGate. You can
configure FortiGate to take automatic actions any time an IoC has been received from FortiAnalyzer.

Enterprise Firewall 6.4 Study Guide 20

 Security Fabric
DO NOT REPRINT
© FORTINET

If a FortiGate is not the Security Fabric root, you can see which upstream or downstream FortiGate it is
connected to using the commands shown on this slide.

Enterprise Firewall 6.4 Study Guide 21

 Security Fabric
DO NOT REPRINT
© FORTINET

By default, in a Security Fabric, all FortiGate devices send logs to a single FortiAnalyzer. FortiAnalyzer is
configured on the root FortiGate, which is pushed to all downstream FortiGate devices as they join the Security
Fabric. In a similar way, the FortiManager configuration is also pushed from the root to all other FortiGate
devices. So, all Security Fabric members are managed by the same FortiManager. You can disabled this
configuration synchronization using the setting configuration-sync under config system csf.

All FortiGate devices in the Security Fabric maintain their own Security Fabric map. Security Fabric maps include
the MAC address and IP address of all connected FortiGate devices and their interfaces.

Enterprise Firewall 6.4 Study Guide 22

 Security Fabric
DO NOT REPRINT
© FORTINET

FortiGate devices in the Security Fabric know the MAC addresses of their upstream and downstream peers. If a
FortiGate receives a packet from a MAC address that belongs to another FortiGate in the Security Fabric, it will
not log that session. This helps to eliminate the repeated logging of a session by multiple FortiGate devices. A
session is always logged by the first FortiGate that handled it in the Security Fabric.

One exception to the behavior is that if upstream FortiGate performs NAT, then another log will be generated.
The additional log is needed to record NAT details such as translated ports and/or addresses.

Enterprise Firewall 6.4 Study Guide 23

 Security Fabric
DO NOT REPRINT
© FORTINET

Fortinet recommends using FortiManager for centralized management of all FortiGate devices, and access
devices in the Security Fabric. You can integrate FortiSwitch devices, and FortiAP devices to extend the Security
Fabric down to the access layer.

You can also extend the Security Fabric by integrating FortiMail, FortiWeb, and FortiClient EMS.

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

Enterprise Firewall 6.4 Study Guide 24

 Security Fabric
DO NOT REPRINT
© FORTINET

Fabric connectors allow you to integrate multi-cloud support, such as ACI and AWS, to name a few.

In an application-centric infrastructure (ACI), the SDN connector serves as a gateway bridging SDN controllers
and FortiGate devices. The SDN connector registers itself to APIC in the Cisco ACI fabric, polls interested
objects, and translates them into address objects. The translated address objects and associated endpoints
populate on FortiGate.

FortiGate VM for Microsoft Azure also supports cloud-init and bootstrapping.

Enterprise Firewall 6.4 Study Guide 25

 Security Fabric
DO NOT REPRINT
© FORTINET

You can view the Security Fabric topology on the root FortiGate GUI. There are two options: Physical Topology
view and Logical Topology view.

The Physical Topology view displays the physical structure of your network, by showing the devices in the
Security Fabric and the connections between them. The Logical Topology view displays the logical structure of
your network, by showing information about logical and physical network interfaces in the Security Fabric and the
interfaces that connect devices in the Security Fabric.

The topology views are interactive. You can authorize, and deauthorize access devices, such as FortiSwitch and
FortiAP. You can ban or unban compromised clients. You can also perform some device management tasks
directly in the topology view, such as device upgrades, or connect to a specific device CLI.

Only Fortinet devices are shown in the topology views.

Enterprise Firewall 6.4 Study Guide 26

 Security Fabric
DO NOT REPRINT
© FORTINET

Security rating is a subscription service that requires a security rating license. This service now provides the
ability to perform many best practices, including password checks, to audit and strengthen your network security.
The Security Rating page is separated into three major scorecards:
• Security Posture
• Fabric Coverage
• Optimization
These scorecards provide an executive summary of the three largest areas of security focus in the Security
Fabric.

The scorecards show an overall letter grade and breakdown of the performance in sub-categories. Clicking a
scorecard drills down to a detailed report of itemized results and compliance recommendations.
The point score represents the net score for all passed and failed items in that area. The report includes the
security controls that were tested against, linking to specific FSBP or PCI compliance policies. You can click the
FSBP and PCI buttons to reference the corresponding standard.

Enterprise Firewall 6.4 Study Guide 27

 Security Fabric
DO NOT REPRINT
© FORTINET

On the Security Rating page, click the Security Posture scorecard to expand it and see more details.

The security posture service now supports the following:

• Customer ranking based on the security audit information. FortiGuard data is used to provide customer
ratings. A customer rating is presented as a percentile. The rating is based on results sent to FortiGuard and
statistics received from FortiGuard.
• Security audits running in the background, not just on demand, when an administrator is logged into the GUI.
When you view the security audit page, the latest saved security audit data is loaded. From the GUI, you can
run audits on demand and view results for different devices in the Security Fabric. You can also view all
results or just failed test results.
• New security checks that can help you make improvements to your organization’s network. These checks
include enforcing password security, applying recommended login attempt thresholds, encouraging two-factor
authentication, and more.

Enterprise Firewall 6.4 Study Guide 28

 Security Fabric
DO NOT REPRINT
© FORTINET

Administrator-defined automated work flows (called stitches) use if/then statements 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 if/then statements for any device in the Security Fabric. However, Security Fabric is not a
requirement to use stiches.

Each automation 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. You can use automation stitches to detect
events from any source in the Security Fabric and apply actions to any destination.

You can configure the Minimum internal (seconds) setting to make sure you don’t receive repeat notifications
about the same event.

Enterprise Firewall 6.4 Study Guide 29

 Security Fabric
DO NOT REPRINT
© FORTINET

You can configure the Compromised Host trigger to create an automated threat response stitch. This trigger
uses indicator of compromise (IoC) event reporting from FortiAnalyzer. Based on the Threat level threshold
setting, you can configure the stitch to take different remediation steps:
• Quarantine the compromised host at the FortiSwitch or FortiAP
• Quarantine FortiClient on the compromised host using FortiClient EMS
• Ban the IP

You can also use the Quarantine widget to view quarantined and banned IP addresses. Quarantined addresses
are automatically removed from quarantine after a configurable period of time. Banned IP addresses can be
removed from the list only by administrator intervention.

Enterprise Firewall 6.4 Study Guide 30

 Security Fabric
DO NOT REPRINT
© FORTINET

You can test your automation stitch using the command shown on this slide. When an automation stitch is
triggered, FortiGate creates an event log.

Enterprise Firewall 6.4 Study Guide 31

 Security Fabric
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 about the Fortinet Enterprise Firewall solution and
the Fortinet Security Fabric.

Enterprise Firewall 6.4 Study Guide 32

 Security Fabric
DO NOT REPRINT
© FORTINET

Now, you will work on Lab 1–Security Fabric.

Enterprise Firewall 6.4 Study Guide 33

 Security Fabric
DO NOT REPRINT
© FORTINET

In the first exercise, you will configure the Security Fabric on NGFW-1 and DCFW. The Security Fabric follows a
tree topology. NGFW-1 will be the root of the tree and ISFW and DCFW will be branches.

Enterprise Firewall 6.4 Study Guide 34

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the architecture of FortiOS.

Enterprise Firewall 6.4 Study Guide 35

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in FortiOS architecture, 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.

Enterprise Firewall 6.4 Study Guide 36

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 37

 FortiOS Architecture

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 affects the path that a packet takes.

Enterprise Firewall 6.4 Study Guide 38

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

This slide shows all the steps that a packet goes through as it enters, passes though, and exits FortiGate. This
scenario is for FortiGate without network processors.

FortiGate performs some security inspections early in the life of the packet, such as DoS checking, reverse path
forwarding (RPF) checking, 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.

FortiGate offloads IPsec VPN encryption and decryption, and flow-based inspection to SPUs if they exist on the
FortiGate hardware. Additionally, some FortiGate models support network processors, such as the NP6 or
NP6lite. FortiGate offloads packets that don’t require any UTM or NGFW processing to these network processors
for acceleration.

Enterprise Firewall 6.4 Study Guide 39

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

In this section, you will learn about how FortiGate uses memory.

Enterprise Firewall 6.4 Study Guide 40

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

To understand how FortiGate uses its memory, you need to understand the architecture of FortiOS. The heart of
FortiOS is its kernel. The kernel is where FortiGate makes some of the most basic and important decisions, such
as how to route a packet, or when to offload a session to an NPU processor. FortiOS runs 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.

Enterprise Firewall 6.4 Study Guide 41

 FortiOS Architecture

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)

Enterprise Firewall 6.4 Study Guide 42

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 43

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 44

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

To check how much memory is being allocated to kernel slabs, use the command shown on this slide.

The first column shows the slab name. The second column shows the total number of active objects, and the third
and fourth columns show the number of available objects, and 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.

You can use the output of this command to identify how much memory the session table is using. If that value is
too high, it might indicate that the configuration needs some tuning (for example, setting shorter session TTLs), or
that the FortiGate model is too small for the amount of traffic crossing the device.

Enterprise Firewall 6.4 Study Guide 45

 FortiOS Architecture

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 the access to information stored in the hard and flash disk memories.
Some processes, such as logging, WAN optimization, and explicit proxy, store information in the hard disk, so
they get the performance boost provided by this memory allocation.

An I/O cache page is labeled as active when it has been recently been used or modified. It enters the inactive
state after it has not been used for some time. An inactive page may be reclaimed by the kernel if needed.

Enterprise Firewall 6.4 Study Guide 46

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

The command shown on this slide displays the total amount of memory allocated for the I/O cache. The cache
value is the overall sum of all active and inactive pages.

Enterprise Firewall 6.4 Study Guide 47

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 48

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

This slide shows how you can see how much memory space is being used by each process. The command
shown on this slide displays the information shown in the last column. For each process, the command also
displays the ID number, state, and CPU use. You can specify the refresh frequency and the number of lines to
display.

While the command is running, you can press Shift+P to sort the processes by CPU use, or Shift+M to sort them
by memory use. To stop the command, press Ctrl+C or Ctrl+Q.

Enterprise Firewall 6.4 Study Guide 49

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

The table on this slide shows some of the most common processes.

Enterprise Firewall 6.4 Study Guide 50

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

The table on this slide shows more of the most common processes.

Enterprise Firewall 6.4 Study Guide 51

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 52

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 53

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 54

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 55

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 56

 FortiOS Architecture

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’s important to disable any real-time debug after using
it because they consume FortiGate resources and some can be CPU intensive.

Enterprise Firewall 6.4 Study Guide 57

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 58

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

In this section, you will examine conserve mode, now that you have a better understanding of how FortiGate uses
memory.

Enterprise Firewall 6.4 Study Guide 59

 FortiOS Architecture

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: threshold at which FortiGate starts dropping new sessions
• Red: threshold at which FortiGate enters conserve mode
• Green: threshold at which FortiGate exits conserve mode

Enterprise Firewall 6.4 Study Guide 60

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

You can use the commands shown on this slide to change the default conserve mode threshold values.

Enterprise Firewall 6.4 Study Guide 61

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 62

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

Use the commands shown on this slide to control how FortiGate handles traffic that requires proxy-based content
inspection during conserve mode.

There are two settings―av-failopen-session and av-failopen. When av-failopen-session is

enabled, FortiGate applies the action configured in av-failopen. By default, FortiGate blocks new sessions
(av-failopen-session disable).

Enterprise Firewall 6.4 Study Guide 63

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

All flow-based inspection is handled by the IPS engine. You can configure the IPS failopen setting to manage
flow-based inspection while FortiGate is in conserve mode.

When you have mixed UTM profiles using proxy-based inspection, and flow-based inspection is enabled on
FortiGate, nTurbo does not work. In this case, all the packets for flow-based inspection need to go through the
socket buffer and deliver to IPS. When the socket buffer is full, the event is logged as a fail-open event and
sessionact is used to reflect the fail-open settings. By default, IPS fail-open is disabled, which means the IPS
engine will drop all new sessions that require flow-based inspection, but will try to process all existing sessions. If
IPS fail-open is enabled, IPS engine will not perform any scan, but will allow new packets.

If you have all flow based UTM profiles, nTurbo handles all packets, except the three-way handshake, and it does
not require any software socket buffer.

Enterprise Firewall 6.4 Study Guide 64

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

The command shown on this slide is used to identify if a FortiGate device is currently in conserve mode.

Enterprise Firewall 6.4 Study Guide 65

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 66

 FortiOS Architecture

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 unit memory.
FortiGate sets a hard limit on the maximum number of ephemeral sessions that can simultaneously exist in the
session table.

Enterprise Firewall 6.4 Study Guide 67

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

What can you do if FortiGate enters conserve mode frequently, or if its memory utilization is too high? In this
section, you will learn how to optimize memory use by fine-tuning the FortiGate configuration.

Enterprise Firewall 6.4 Study Guide 68

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

Many FortiGate processes, such as DLP or AV scanning, are memory intensive. So, memory optimization is
important, especially in small devices, to guarantee that these processes will 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 doing antispam, an administrator does not need to do antispam on FortiGate. Also, usually not
all the IPS signatures are required.

Another recommendation is to reduce the maximum file size to inspect, which is set to 10MB by default. You can
reduce this value to 2 or 3MB without significantly reducing the virus catching rate, as a typical virus size is less
than 1MB.

Enterprise Firewall 6.4 Study Guide 69

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 70

 FortiOS Architecture

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 quicker, 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

Enterprise Firewall 6.4 Study Guide 71

 FortiOS Architecture

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 or firewall policy.

Enterprise Firewall 6.4 Study Guide 72

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 73

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

In this section, you will learn about FortiOS workspace mode.

Enterprise Firewall 6.4 Study Guide 74

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

Workspace mode allows administrators to make a batch of changes that are not implemented until the transaction
is committed. Prior to committing, the changes can be reverted or edited as needed without impacting current
operations.

When an object is edited in workspace mode, it is locked, preventing other administrators from editing that object.
A warning message will be shown to let the administrator know that the object is currently being configured in
another workspace transaction.

All administrators can use workspace mode; their permissions in workspace mode are the same as the
permissions defined in their account profile.

A workspace mode transaction times out in five minutes if there is no activity. When a transaction times out, all
changes are discarded. A warning message will be shown to let the administrator know that a timeout is
imminent, or has already happened.

Workspace mode is only available from the FortiGate CLI.

Enterprise Firewall 6.4 Study Guide 75

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

The command config-transaction status shows if the current administrator is working on a workspace
that is pending being committed. If that is the case, the output shows the transaction ID for the workspace.

To view information about all the active workspace transactions (from multiple concurrent administrators), use the
command config-transaction show txn-info. The output shows the identifier for each transaction and
their expiration times. It also shows the usernames of the administrators working on each workspace, as well as
information about how and from where those administrators are connecting.

You can list the CLI changes pending to be committed in your workspace using the command config-
transaction show txn-cli-commands.

Enterprise Firewall 6.4 Study Guide 76

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

In this section, you will learn how to troubleshoot system crashes.

Enterprise Firewall 6.4 Study Guide 77

 FortiOS Architecture

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.

Enterprise Firewall 6.4 Study Guide 78

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 79

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

A 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 crashdump in the console port.
Additionally, and in the case of models with more than one CPU, you can enable the NMI watchdog feature,
which automatically causes a crash in the system (and forces the crashdump) when no new daemons have been
scheduled in the last 10 minutes. This is an indication that the unit is not operating normally and might be frozen.

Some FortiGate models also have an external NMI button. If the device is frozen and no crashdump has been
generated, you can press the NMI button to force a crash and generate a crashdump.

Enterprise Firewall 6.4 Study Guide 80

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

Each time an application crashes, or closes, an entry is generated in the crashlog. When an application crashes,
the entry contains the name of the application, the time it crashed, and the termination signal.

This slide shows a sample of a crash in the crashlog. In this example, the application that failed was the sslvpnd
process, which manages SSL VPN connections. The termination signal is 11, which is a segmentation fault.

Enterprise Firewall 6.4 Study Guide 81

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

The table shown on this slide contains the most common termination signal numbers. Any administrator can
manually kill 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 killing a process
is not usually required under normal circumstances. If you have to kill a process, use the termination signal 9.
Improperly killing a process can make a FortiGate system unstable.

Please note that not all the signal numbers will generate a crash log.

Enterprise Firewall 6.4 Study Guide 82

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

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

In most cases, entries in the crashlog are normal. A crashlog entry can be considered suspicious if it happens at
the same time as a failure in a FortiGate feature, or abnormal behaviour of the FortiGate.

For example, a crashlog entry that is generated when the 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 crashlog includes the details about the crash and information that can be used by Fortinet development to
identify which code triggered the problem.

Enterprise Firewall 6.4 Study Guide 83

 FortiOS Architecture

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 about the architecture of FortiOS.

Enterprise Firewall 6.4 Study Guide 84

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

Now, you will work on Lab 2–FortiOS Architechture.

Enterprise Firewall 6.4 Study Guide 85

 FortiOS Architecture

DO NOT REPRINT
© FORTINET

In this lab, you will run debug commands to gather information about resource utilization on ISFW.

Enterprise Firewall 6.4 Study Guide 86

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about traffic and session monitoring.

Enterprise Firewall 6.4 Study Guide 87

 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, configure and
troubleshoot session helpers and the SIP application layer gateway.

Enterprise Firewall 6.4 Study Guide 88

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 89

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

The FortiGate session table contains detailed information about every IP connection that crosses or terminates at
FortiGate. We can use the commands shown on the 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.

Enterprise Firewall 6.4 Study Guide 90

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 91

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 92

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 93

 Traffic and Session Monitoring

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 will be different from 0. The second digit is the client-side state. This
table and flow graph correlate the second-digit value with the different TCP session states. For example, when
FortiGate receives the SYN packet, the second digit is 2. It changes to 3 when the SYN/ACK packet is received.
After the three-way handshake, the state value changes to 1.

When a session is closed by both sides, FortiGate keeps that session in the session table for a few seconds
more, to allow for any out-of-order packets that might arrive after the FIN/ACK packet. This is the state value 5.

Enterprise Firewall 6.4 Study Guide 94

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 95

 Traffic and Session Monitoring

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 originated from FortiGate or terminates on
FortiGate.

Enterprise Firewall 6.4 Study Guide 96

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

Take a look at the dirty and may_dirty flags. When FortiGate receives the first packet for a new session, it
evaluates whether the traffic should or shouldn’t be allowed, based on firewall policies. As long as there are no
changes in the firewall policy configuration, this evaluation is done on only the first session packet. If the traffic is
allowed by a firewall policy, FortiGate creates a session and flags the session as may_dirty.

After that, if there is a change in the firewall policy configuration, all the existing sessions with the may_dirty
flag are also flagged as dirty. This indicates to FortiGate that it needs to reevaluate the next session packet to
determine if the session must be blocked. If the session is still allowed, the dirty flag is removed, but the
may_dirty flag is kept. If the session must be blocked, it is flagged as block and remains in the session table
until it expires. Any packet matching a session with the block flag is dropped.

Enterprise Firewall 6.4 Study Guide 97

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

You can use the CLI commands shown on this slide to modify FortiGate’s session handling behaviour after policy
changes.

The system-level setting is global, or per-VDOM, if you have VDOMs enabled. The default option is check-all,
where all policy information is removed from sessions affected by a policy change. When new packets arrive,
FortiGate re-evaluates them before adding them to the session table. This is the most resource-intensive
behavior.

The check-new option is another alternative. When this option is enabled, FortiGate does not modify any
existing session after a policy change. When new sessions arrive, FortiGate evaluates them against the modified
policies. You can use this option if you have policies handling millions of sessions.

The check-policy-option is the most granular setting you can use. When you enable this option, the firewall
policy-level settings become available, which you can use to modify how FortiGate handles sessions on a per-
policy level.

Enterprise Firewall 6.4 Study Guide 98

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

You can now configure FortiGate to operate in NGFW policy mode. NGFW policy mode is a flow-based
inspection mode that allows you to configure application signatures, categories, groups, and FortiGuard web filter
categories directly on the firewall policy. Other security inspection features, such as antivirus and DLP, are still
configured as profiles.

Enterprise Firewall 6.4 Study Guide 99

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

You should view NGFW policy mode session handling as having three distinct stages.

The FortiGate kernel can identify ICMP, DNS, and NTP traffic in the kernel. All other traffic types, the kernel
cannot identify. So, when the session first comes in, the kernel is not aware of any Layer 7 information, and uses
the Layer 4 headers to search the NGFW policy table for a match. At this point, the kernel creates a session table
entry with the may_dirty flag, creates an application ID of 0 for the app field, and allows the session to flow.

Enterprise Firewall 6.4 Study Guide 100

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

While the session is allowed, the kernel forwards packets to the IPS engine. The IPS engine performs Layer 7
identification, and updates the session table. The session table entry is flagged with the dirty flag, and the
identified application ID is added. The dirty flag notifies the kernel that the session needs to be re-evaluated.

Enterprise Firewall 6.4 Study Guide 101

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

The kernel uses the Layer 7 information to search the NGFW policy table again for a match. Once a match is
found, the kernel applies the configured action on the matching policy.

Enterprise Firewall 6.4 Study Guide 102

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 103

 Traffic and Session Monitoring

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 can later be analyzed with a tool such as WireShark.

Enterprise Firewall 6.4 Study Guide 104

 Traffic and Session Monitoring

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 don’t 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.

Enterprise Firewall 6.4 Study Guide 105

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

Another useful FortiGate troubleshooting tool is the debug flow.

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

Enterprise Firewall 6.4 Study Guide 106

 Traffic and Session Monitoring

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 being applied.

Enterprise Firewall 6.4 Study Guide 107

 Traffic and Session Monitoring

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 indicates that either no firewall policy allows the traffic, or that a
disclaimer has not been accepted yet
• Denied by end point ip filter check indicates that the IP address has been quarantined by the
DLP inspection
• exceeded shaper limit, drop indicates that the packet was dropped because of a traffic shaper that
has exceeded one of its thresholds

Enterprise Firewall 6.4 Study Guide 108

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 109

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 110

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

To understand what a session helper does, take a look at this example of a network protocol that might have
problems when a network device is doing NAT. The example on this slide 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.

Enterprise Firewall 6.4 Study Guide 111

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

Active FTP won’t work if the control channel crosses a network device doing NAT, 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.

Once the server receives that FTP command, it tries to bring up the TCP session for the data channel. It sends
the SYN packet to the IP address 10.0.1.10. This address is probably not routable because it is a private IP
behind a device doing NAT.

The file transfer fails.

Enterprise Firewall 6.4 Study Guide 112

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

The FTP session helper fixes this problem by replacing the router with a FortiGate device. The following
describes 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 will come from the server. That means that the administrator does not need to
manually create firewall policies to allow these incoming TCP sessions (which use random TCP ports numbers).
The session helper automatically creates the session and opens the door for the incoming 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.

Enterprise Firewall 6.4 Study Guide 113

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 114

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 115

 Traffic and Session Monitoring

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 doing NAT of 10.0.1.10 to 66.171.121.44.

Once the control channel is up, a SIP phone sends an invite packet with its IP address and port numbers for
two of the four data channels. The FortiGate session helper creates two expected sessions, and translates the IP
address inside the invite packet to 66.171.121.44.

The remote phone sends an OK packet to the right destination IP address (66.171.121.44). The packets
include the IP address and ports for the other two data channels. The session helper creates two more expected
sessions, this time using the information coming in the OK packet. After that, the four data channels can be
connected through the four expected sessions. Firewall policies are not needed to allow this traffic.

Enterprise Firewall 6.4 Study Guide 116

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 117

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 118

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 119

 Traffic and Session Monitoring

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.

Enterprise Firewall 6.4 Study Guide 120

 Traffic and Session Monitoring

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), the SIP ALG is used. If it is set to kernel-helper-based, the SIP helper is used.

If the SIP traffic matches a firewall policy with a VoIP profile, the SIP ALG is always used, regardless of the
default-voip-alg-mode setting.

Fortinet recommends using the SIP ALG. The SIP helper should be used only when the SIP ALG is not working
as expected.

Enterprise Firewall 6.4 Study Guide 121

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 122

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

You can display all active SIP calls and disconnect any active SIP calls using the commands shown on this slide.

Enterprise Firewall 6.4 Study Guide 123

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

You can use im and sip real-time debugs to display real-time information about SIP traffic.

Enterprise Firewall 6.4 Study Guide 124

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

Enterprise Firewall 6.4 Study Guide 125

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 126

 Traffic and Session Monitoring

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 127

 Routing

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about advanced routing concepts that are relevant to enterprise networks.

Enterprise Firewall 6.4 Study Guide 128

 Routing

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in routing, you will be able to describe how FortiGate routes traffic, diagnose
routing problems caused by reverse path forwarding check, identify sessions that will be routed through a
different path, and use debug commands to troubleshoot routing problems.

Enterprise Firewall 6.4 Study Guide 129

 Routing

DO NOT REPRINT
© FORTINET

In this section, you will learn about general routing concepts and troubleshooting.

Enterprise Firewall 6.4 Study Guide 130

 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 sent
by the originator and another one on the first reply packet coming from the responder. After that, all the routing
information is written in the FortiGate session table. However, after a change to the routing table, the route
information is flushed from the affected entries in the session table. So, FortiGate would perform additional
routing table lookups in order to repopulate the session table with the new routing information.

Enterprise Firewall 6.4 Study Guide 131

 Routing

DO NOT REPRINT
© FORTINET

How does FortiGate decide routes? FortiGate has multiple routing modules. The diagram shown on this slide
illustrates the logic of the routing modules.

First, FortiGate searches its policy routes. You can view them using the command diagnose firewall
proute list. If there is a match in a policy route, and the action is Forward Traffic, FortiGate routes the
packet accordingly. If the action is Stop Policy Routing, FortiGate goes to the next table, which is the route
cache. You can view that content using the CLI command diagnose ip rtcache list.

Finally, FortiGate searches the forwarding information base (FIB). The FIB is generated by the routing process,
and is the table used for packet forwarding. Think of the routing table’s purpose as management, while the FIB’s
purpose is forwarding. This separation becomes clearer in a FortiGate high availability (HA) cluster. In an HA
cluster, both route management and forwarding tables exist on the master FortiGate. But on the slave FortiGate,
only the FIB exists.

If there’s no match in any of those tables, FortiGate drops the packet because it is unroutable.

Enterprise Firewall 6.4 Study Guide 132

 Routing

DO NOT REPRINT
© FORTINET

When there is more than one route to a destination, this is the process for selecting which route to use.

First, FortiGate uses the most specific route, which is the one with the longest netmask (smallest subnet). If there
are two or more routes with the same longest netmask, the unit selects the one with the shortest distance. After
that, the lowest metric is used as the tiebreaker for dynamic routes. In the case of static routes, the priority is
used 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 multipath (ECMP). ECMP is supported for static, BGP, and
OSPF routes.

Enterprise Firewall 6.4 Study Guide 133

 Routing

DO NOT REPRINT
© FORTINET

FortiGate adds a static route to the routing table only if all of the following requirements are met:
• The outgoing interface is up
• There is no other route to the same destination with a shorter distance
• The link health monitor (if configured) is up

Enterprise Firewall 6.4 Study Guide 134

 Routing

DO NOT REPRINT
© FORTINET

Now, you will review an important routing concept: reverse path forwarding (RPF) check.

RPF check protects against IP spoofing attacks and routing loops by checking the route to the source IP address.
This check is performed only on 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.

Enterprise Firewall 6.4 Study Guide 135

 Routing

DO NOT REPRINT
© FORTINET

There are two RPF check modes: feasible path (formerly known as loose) and strict. Feasible path is the default
mode.

In feasible path mode, the packet is accepted as long as there is one active route to the source IP through the
incoming interface. It does not have to be the best route, just an active one. In the example shown on this slide,
the packet from 10.4.0.1 to 10.1.0.1 is accepted because FortiGate has an active route (the default route) to
10.4.0.1 through port2. However, the packet from 172.16.1.1 to 10.1.0.1 is not accepted, because there
is no active route to the IP address 172.16.1.1 through port3.

Enterprise Firewall 6.4 Study Guide 136

 Routing

DO NOT REPRINT
© FORTINET

In strict mode, FortiGate checks that the best route to the source IP address is through the incoming interface.
The route not only has to be active (as in the case of feasible path mode), but it also has to be the best.

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

Enterprise Firewall 6.4 Study Guide 137

 Routing

DO NOT REPRINT
© FORTINET

Content inspection requires to routing to 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, under some network topologies, FortiGate
might not route the return traffic through the best path, but through the same path that the originating traffic used.
For that purpose, FortiGate remembers the interface to source and uses that interface to route the return packets,
even when a better route using a different interface exists. You will look at an example on the next slides.

Enterprise Firewall 6.4 Study Guide 138

 Routing

DO NOT REPRINT
© FORTINET

Now, you will analyze this network topology. The local network, 10.1.0.0/24 has three network devices: a local
workstation, a local router, and a FortiGate port1. Also, the FortiGate port2 is directly connected to the local router
(using the subnet 10.2.0.0/24).

There is a remote router connected to FortiGate port3 and, behind that, a remote server (10.4.0.1). So, any
traffic destined to the remote server must be routed through 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 unit route cache. This entry contains the interface to source, or the incoming
interface where the packet arrived which, in this case, is port2.

Enterprise Firewall 6.4 Study Guide 139

 Routing

DO NOT REPRINT
© FORTINET

Additionally, FortiGate creates an entry in the session table. This entry also contains information about the
interface to source.

As explained earlier, FortiGate does a first routing lookup to find the next-hop to the destination. That IP address
is also stored in the session information.

Because there is no ICMP echo reply yet, you will notice that the next-hop to source is still unknown (it is
0.0.0.0). It will be identified with the second routing lookup that happens with the first reply packet.

Enterprise Firewall 6.4 Study Guide 140

 Routing

DO NOT REPRINT
© FORTINET

Now, take a look at how FortiGate routes the return packet.

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

Enterprise Firewall 6.4 Study Guide 141

 Routing

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 142

 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.

This example shows how FortiGate might, in some network topologies, route packets to the same destination
differently, depending on who initiated the session.

Enterprise Firewall 6.4 Study Guide 143

 Routing

DO NOT REPRINT
© FORTINET

Take a look at the reply traffic in this example.

Because the local workstation default gateway is 10.1.0.254, the ICMP echo reply goes to the local router first.
Then, the packet arrives at FortiGate port2. The result is asymmetric routing: the return traffic is following a
different path than the originating traffic. The return packet is arriving at port2 instead of port1 (where the
originating traffic was sent).

In these particular cases, FortiGate accepts this asymmetry, no packets are dropped, and security inspection is
not affected.

Enterprise Firewall 6.4 Study Guide 144

 Routing

DO NOT REPRINT
© FORTINET

When FortiGate is not applying SNAT, after a change in the routing table, the routing information is removed from
the sessions that are affected by the change. Additionally, related route cache entries are deleted. So, two more
routing lookups are done for the next packets in order to learn the new routing information and store it in the
routing table.

This slide shows a sample of a session just after a routing change. The gateways in both directions change to
0.0.0.0/0 and the interfaces to 0, indicating that this information must be learned again. Additionally, the
dirty flag is added.

Enterprise Firewall 6.4 Study Guide 145

 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 will continue to pass
without being affected by the routing changes. The routing changes will apply only to new sessions.

Enterprise Firewall 6.4 Study Guide 146

 Routing

DO NOT REPRINT
© FORTINET

In sessions where SNAT is applied, the action that FortiGate takes after a routing change depends on the snat-
route-change setting.

Enterprise Firewall 6.4 Study Guide 147

 Routing

DO NOT REPRINT
© FORTINET

When this setting is disabled, the behavior that occurs after a routing change is different for sessions using
SNAT. Sessions using SNAT keep using the same outbound interface, as long as the old route is still active.

In the example shown on this slide, FortiGate is connected to two different ISPs. A client with the IP address
10.1.0.1/24 is connected behind a FortiGate. FortiGate is doing SNAT of the client traffic to a public IP
address, depending on which ISP is using it. The FortiGate routing table contains two default routes: one for each
ISP. The two default routes are the same distance, but have different priorities. The route with the lowest priority
(port1) is the primary. When both ISP connections are up, the primary route is selected by FortiGate for internet
traffic. So, all sessions to the internet are created using port1 as the outbound interface.

Enterprise Firewall 6.4 Study Guide 148

 Routing

DO NOT REPRINT
© FORTINET

If you increase the priority assigned to port1 to a value that is higher than the value assigned to port2, and if
snat-route-change is disabled, all new sessions start using port2, because it has the lowest priority.
However, all the existing sessions continue to use port1. The default route is through port1. Even though the
default route is no longer the best route, it is still active. If FortiGate is doing SNAT, the existing sessions will
continue to use the original route until they expire. If FortiGate isn’t doing SNAT, all the existing sessions will
switch to port2 after the change.

Enterprise Firewall 6.4 Study Guide 149

 Routing

DO NOT REPRINT
© FORTINET

When this setting is enabled, after a routing change, the actions are the same as they are for sessions without
SNAT:

• Routing information is flushed from the session table

• Route cache entries are removed
• Routing lookups are done again for the next packets, which can potentially change the outbound interface
being used to route the traffic
• RPF check is done again for the first packet in the original direction

In the example shown on this slide, FortiGate is connected to two different ISPs. A client with the IP address
10.1.0.1/24 is connected behind a FortiGate device. The FortiGate routing table contains two default routes:
one for each ISP. The two default routes are the same distance, but have different priorities. The route with the
lowest priority (port1) is the primary. When both ISP connections are up, the primary route is selected by
FortiGate for internet traffic. So, all sessions to the internet are created using port1 as the outbound interface.

Enterprise Firewall 6.4 Study Guide 150

 Routing

DO NOT REPRINT
© FORTINET

The scenario shown on this slide has multiple ISPs. If the customer owns a pool of public IP addresses, the
customer can configure a single IP pool for SNAT for all the internet providers. The advantage is that if the main
ISP goes down, sessions are routed through a secondary ISP, maintaining the same public source IP address. In
this way, sessions can remain up.

So, in the example shown on this slide, if you increase the priority for port1 to a value higher than the priority for
port2, and if snat-route-change is enabled, after a routing change, routing information is flushed from existing
SNAT sessions. All sessions start using port2, because it has the lowest priority. Additionally, if the port2 route
shared a common IP pool with the old best route of port1, the SNAT session swill keep using the same public IP
addresses for the translation of the private IP addresses.

Enterprise Firewall 6.4 Study Guide 151

 Routing

DO NOT REPRINT
© FORTINET

With auxiliary-session enabled, the FortiGate kernel will create a new auxiliary session and attach it to the main
session. For each traffic path (incoming or outgoing), FortiGate will continue to create a new auxiliary session.

Enterprise Firewall 6.4 Study Guide 152

 Routing

DO NOT REPRINT
© FORTINET

In this example, 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 will see how sessions are handled on FortiGate:
1. Initially, traffic is coming from port1 to port3. FortiGate creates a new session: the main session.
2. The reply from the server comes from port4 to port1. FortiGate creates auxiliary session 1 and attaches it to
the main session.
3. The client sends traffic from port1 to port4. FortiGate matches auxiliary session 1.
4. The client sends traffic from port2 to port3. FortiGate creates auxiliary session 2 and attaches it to the main
session.
5. The server replies back from port3 to port2. FortiGate matches auxiliary session 2.
6. The server replies back from port4 to port2. FortiGate creates auxiliary session 3 and attaches it to the main
session.
7. The client sends traffic from port2 to port4. FortiGate matches auxiliary session 3.
8. Finally, the server replies back from port3 to port1. FortiGate matches main session.

All of these sessions can be offloaded if the policy allows offloading.

Enterprise Firewall 6.4 Study Guide 153

 Routing

DO NOT REPRINT
© FORTINET

The command shown on this slide displays all the active routes in the routing table. The left column indicates the
source for the route. The first number inside the square brackets is the distance, and the second number is the
metric.

This command shows only installed routes in the RIB. For example, if you had two static routes to the same
destination subnet with different distances, the one with the shorter distance would be installed, and the one with
the longer distance would not.

Enterprise Firewall 6.4 Study Guide 154

 Routing

DO NOT REPRINT
© FORTINET

If you want to display both installed and non-installed routes, use the command shown on this slide. In the
example shown on this slide, the output shows one inactive route. The route is shown as inactive when:

• Its gateway is detected dead by link monitor

• Its interface is administratively down
• Its interface has a link down

Other routes that exist only in a routing database and are not marked as inactive, are there because they were
not selected as the best route for a destination and thus were not installed in the RIB. For example:

• Two static default routes with different distances. The one with the lower distance appears in the RIB and the
one with the higher distance appears in the database only.
• Two default routes, one of them is static and the other is BGP. The static one is preferred and thus appears in
the RIB, but the BGP one is listed in the database only.

Enterprise Firewall 6.4 Study Guide 155

 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.

Enterprise Firewall 6.4 Study Guide 156

 Routing

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 157

 Routing

DO NOT REPRINT
© FORTINET

In this section, you will learn about virtual routing and forwarding.

Enterprise Firewall 6.4 Study Guide 158

 Routing

DO NOT REPRINT
© FORTINET

Virtual routing and forwarding (VRF) is a technology included in some routers that allows multiple instances of a
routing table to exist in a router. This increases functionality by allowing network paths to be segmented without
using multiple devices. Because traffic is automatically segregated, VRF also increases network security. Internet
service providers often take advantage of VRFs to create separate VPNs for customers.

Enterprise Firewall 6.4 Study Guide 159

 Routing

DO NOT REPRINT
© FORTINET

This slide shows another example of a data center service provider. Using VRFs, the service provider achieves
full Layer 3 path isolation. VRFs can include IPsec interfaces, so the routing isolation stretches all the way to the
tunnel termination at the data center edge. This setup reduces the configuration complexity, when compared to a
similar solution you can achieve using VLANs.

Enterprise Firewall 6.4 Study Guide 160

 Routing

DO NOT REPRINT
© FORTINET

FortiGate supports Layer 3 routing isolation using VRFs. You can configure a VRF ID on an interface. A wide
range of interfaces are supported, such as physical, VLAN, IPsec, switch, and aggregate interfaces. Interfaces
with matching VRF IDs are isolated to a VRF instance.

This slide shows the commands required to configure a VRF ID on an interface. The VRF ID is an integer
between 0 and 31.

OSPF and BGP are the only dynamic routing protocols that support VRF. RIP does not support VRF.

FortiGate also supports route leaking capabilities between locally defined VRFs.

Enterprise Firewall 6.4 Study Guide 161

 Routing

DO NOT REPRINT
© FORTINET

After you configure VRF IDs on interfaces, the routing table diagnostic command output changes. FortiGate
groups routes based on VRF ID. From the routing table output shown on this slide, you can see that port1 and
port3 are in the same VRF instance (VRF=1), and port2 is segregated in a separate VRF instance (VFR=2).

Enterprise Firewall 6.4 Study Guide 162

 Routing

DO NOT REPRINT
© FORTINET

The routing table database output also changes. Both active and inactive routes are grouped based on their VRF
instance.

Enterprise Firewall 6.4 Study Guide 163

 Routing

DO NOT REPRINT
© FORTINET

The route cache entries will also show VRF ID information for recently used route entries.

Enterprise Firewall 6.4 Study Guide 164

 Routing

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

Enterprise Firewall 6.4 Study Guide 165

 Routing

DO NOT REPRINT
© FORTINET

Now, you will work on Lab 5–Routing.

Enterprise Firewall 6.4 Study Guide 166

 Routing

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 167

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 168

 FortiGuard

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in FortiGuard, and how FortiGate connects to public FortiGuard servers, you will
be able to troubleshoot problems that occur when FortiGate is connecting to public FortiGuard services, and
when FortiManager is acting as a local FortiGuard server.

Enterprise Firewall 6.4 Study Guide 169

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 170

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 171

 FortiGuard

DO NOT REPRINT
© FORTINET

FortiGate uses different ports for rating services (such as web filtering and antispam) and for update services
(such as antivirus and IPS).

In the case of rating services, and when communicating with public FortiGuard services, FortiGate uses one of
these ports:
• UDP port 8888
• UDP port 53
• HTTPS port 8888
• HTTPS port 53
• HTTPS port 443

In the case of rating services, and when communicating with a FortiManager configured as a local FortiGuard
server, FortiGate uses one of these ports:
• UDP port 8888
• UDP port 53
• HTTP port 8888
• HTTPS port 53

In the case of update services, FortiGate uses HTTPS port 443.

By default, FortiGate uses public FortiGuard servers located worldwide. You can configure FortiGate to use public
FortiGuard servers located only in USA.

Enterprise Firewall 6.4 Study Guide 172

 FortiGuard

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 (usually two or three) that can be contacted to validate the
FortiGuard license.
3. FortiGate contacts one of those servers to check the license, and obtains a list of servers that can be used to
submit web filtering and antispam rating queries.
4. FortiGate gets the list of servers.
5. FortiGate starts sending rating queries to one of the servers in the list. (You will learn how FortiGate chooses
the server later in this lesson.)
6. If the chosen server does not reply in two seconds, FortiGate contacts the next server 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

Enterprise Firewall 6.4 Study Guide 173

 FortiGuard

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 push.

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 (usually two or three) that can be contacted.
3. FortiGate periodically connects to one of the servers to check for pending updates.
4. If there is an update, FortiGate downloads the update.

The first two steps used for the push method are also used for the pull method: FortiGate gets a list of IP
addresses from a DNS server for the domain name update.fortiguard.net. After that, FortiGate registers its public
IP address in FortiGuard. With this information, FortiGuard starts sending notifications each time there are new
updates. FortiGate then proceeds to download the updates.

Enterprise Firewall 6.4 Study Guide 174

 FortiGuard

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.

Enterprise Firewall 6.4 Study Guide 175

 FortiGuard

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's time zone
• The number of recent and consecutive queries without reply
• The historical total number of queries without reply. These values are reset when the device restarts.

Enterprise Firewall 6.4 Study Guide 176

 FortiGuard

DO NOT REPRINT
© FORTINET

This is how FortiGate selects the server to send the rating requests to:
• FortiGate initially uses the delta between the server's time zone and the FortiGate's system time zone
multiplied by 10.
• This is the server’s initial weight. To lower the possibility of using a remote server, the weight is not
allowed to drop below the initial weight.
• The weight goes up with each packet lost
• The weight goes down 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 delay (RTT).

Enterprise Firewall 6.4 Study Guide 177

 FortiGuard

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

Enterprise Firewall 6.4 Study Guide 178

 FortiGuard

DO NOT REPRINT
© FORTINET

In many cases, problems related to FortiGuard are caused by ISPs. Some ISPs block traffic on port 53 that is not
DNS or that contains large packets. In those cases, the solution is to switch FortiGuard traffic from port 53 to port
8888.

Other ISPs (or upstream firewalls) block traffic to port 8888. In those cases, the solution is to use port 53.

There are also a few cases where ISPs block traffic based on source ports. Changing the source port range for
FortiGuard to the range shown on this slide usually fixes the issue.

Enterprise Firewall 6.4 Study Guide 179

 FortiGuard

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 every two hours 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.

Enterprise Firewall 6.4 Study Guide 180

 FortiGuard

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.

Enterprise Firewall 6.4 Study Guide 181

 FortiGuard

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.

Enterprise Firewall 6.4 Study Guide 182

 FortiGuard

DO NOT REPRINT
© FORTINET

If there are problems updating the antivirus or the IPS, or if there are problems validating the license, you can use
the FortiGuard real-time debug to get more information.

After enabling debug, you can force a manual update from the CLI using the command execute update-now.

Enterprise Firewall 6.4 Study Guide 183

 FortiGuard

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 one or two hours to update a contract on all the servers, it could
take up to 24 hours in some cases. So, if you have just changed or renewed your FortiGuard contract and you do
not see the change on FortiGate, most likely you need to wait a bit longer, to give FortiGuard time to synchronize
the information on all the servers.

Enterprise Firewall 6.4 Study Guide 184

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 185

 FortiGuard

DO NOT REPRINT
© FORTINET

FortiManager can function as a local FDS. It continuously connects to public FDS servers to obtain managed
device license information and check for firmware availability updates.

All FortiManager devices can provide antivirus, IPS, vulnerability scanning, and signature updates to supported
devices. FortiManager devices can also provide web filtering and antispam rating services.

You need to configure the service access settings for each interface under System Settings > Network on
FortiManager. FortiManager supports requests from registered (managed) devices and unregistered
(unmanaged) devices. After you enable the FortiManager built-in FDS, you can configure FortiGate devices to
use FortiManager FortiGuard services.

Enterprise Firewall 6.4 Study Guide 186

 FortiGuard

DO NOT REPRINT
© FORTINET

Now, you will take a look at what is required on FortiGate in order to use FortiManager for FortiGuard services.
You need to configure the server-list. This is where you define the server-address, which is the IP of
FortiManager where FortiGate will query ratings and package updates.

You can also define the following options in the server-type setting:
• rating: web filtering, antispam, and so on
• update: antivirus, IPS, and so on

By default, include-default-servers is enabled. This allows FortiGate to communicate with the public
FortiGuard servers, if the FortiManager devices (configured in server-list) are unavailable. If it is disabled,
FortiGate devices will never go to the public FDSs, even when the FortiManager devices are down.

Enterprise Firewall 6.4 Study Guide 187

 FortiGuard

DO NOT REPRINT
© FORTINET

The GUI section shown on this slide, and related CLI commands, show the status of FortiGuard licenses for all
FortiGate devices.

Enterprise Firewall 6.4 Study Guide 188

 FortiGuard

DO NOT REPRINT
© FORTINET

The antivirus and IPS signature packages are managed in FortiGuard > Package Management. Packages
received from FortiGuard are listed under Receive Status. It displays the package received; version; size;
version to be deployed; and update history for FortiGate, FortiMail, FortiAnalyzer, and FortiClient.

Click Update History to open the update history page for a package. It shows the update times, the events that
occurred, the status of the updates, and the versions downloaded.

You can change the version of the package that will be deployed by selecting Change in the To Be Deployed
Version column.

Enterprise Firewall 6.4 Study Guide 189

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 190

 FortiGuard

DO NOT REPRINT
© FORTINET

The command shown on this slide contains details about which updates were installed or will be installed on
devices managed by FortiManager (displayed by S/N).

Enterprise Firewall 6.4 Study Guide 191

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 192

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 193

 FortiGuard

DO NOT REPRINT
© FORTINET

The web filtering and antispam databases are managed under FortiGuard Management > Query Server
Management. The databases received from FortiGuard are listed under Receive Status.

This page displays the date and time when updates were received from the server, the update version, the size of
the update, and the update history.

Select Update History to open the update history page for a package. It shows the update times, the events that
occurred, the status of the updates, the version number, and size of the download.

Enterprise Firewall 6.4 Study Guide 194

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 195

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 196

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 197

 FortiGuard

DO NOT REPRINT
© FORTINET

These are other debug commands available on FortiManager to troubleshoot FortiGuard-related problems.

Enterprise Firewall 6.4 Study Guide 198

 FortiGuard

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 about FortiGuard. You also learned how to
troubleshoot problems that occur when FortiGate is connecting to public FortiGuard services, and when
FortiManager is acting as a local FortiGuard server.

Enterprise Firewall 6.4 Study Guide 199

 FortiGuard

DO NOT REPRINT
© FORTINET

Now, you will work on Lab 6–FortiGuard.

Enterprise Firewall 6.4 Study Guide 200

 FortiGuard

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 201

 High Availability

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to troubleshoot high availability(HA) issues.

Enterprise Firewall 6.4 Study Guide 202

 High Availability

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in HA, you will be able to monitor and troubleshoot common HA problems,
unexpected reboots, and frozen units.

Enterprise Firewall 6.4 Study Guide 203

 High Availability

DO NOT REPRINT
© FORTINET

In this section, you will review HA operations.

Enterprise Firewall 6.4 Study Guide 204

 High Availability

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 205

 High Availability

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 206

 High Availability

DO NOT REPRINT
© FORTINET

You can use the command shown on this slide to display the HA virtual MAC address assigned to an interface.

Enterprise Firewall 6.4 Study Guide 207

 High Availability

DO NOT REPRINT
© FORTINET

After a failover, the new primary broadcasts gratuitous ARP packets, notifying the network that each virtual MAC
address is now reachable through a different switch port.

In most networks, that’s enough for the switches to update their MAC forwarding tables with the new information.
However, some high-end switches might not clear their MAC tables properly after a failover. So, they keep
sending packets to the former primary even after receiving the gratuitous ARPs. In these cases, you should use
the command shown on this slide to force the former primary to shut down all its non-heartbeat interfaces for 1
second when the failover happens. This simulates a link failure that clears the related entries from the switches'
MAC tables.

Enterprise Firewall 6.4 Study Guide 208

 High Availability

DO NOT REPRINT
© FORTINET

FortiGate HA uses the FortiGate Clustering Protocol (FGCP), for HA-related communications. FGCP travels
among the clustered FortiGate devices over the links that you have designated as the heartbeats.

The FGCP traffic uses a different Ethernet type than the IP protocol. It actually uses three different Ethernet
types, depending on the operation mode (transparent or NAT/route).

Enterprise Firewall 6.4 Study Guide 209

 High Availability

DO NOT REPRINT
© FORTINET

Let’s look at how an HA cluster in active-active mode handles traffic.

First, the client sends a SYN packet, which is always forwarded to the primary FortiGate using the internal
interface’s virtual MAC address as the destination. If the primary decides that the session is going to be inspected
by a secondary, the primary forwards the SYN packet to the respective secondary.

In the example shown on this slide, the destination MAC address is the physical MAC address of the secondary
FortiGate. The secondary responds with SYN/ACK to the client and starts the connection with the server by
directly sending a SYN packet.

Enterprise Firewall 6.4 Study Guide 210

 High Availability

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 211

 High Availability

DO NOT REPRINT
© FORTINET

When the server responds to the TCP SYN, the packet is sent to the primary using the external interface’s virtual
MAC. The primary signals the secondary, and it is the secondary that replies to the server.

As you can see, the objective of active-active mode is not to load balance bandwidth. The traffic is always sent to
the primary first. The main objective is to share CPU and memory among multiple FortiGate devices for traffic
inspection.

Enterprise Firewall 6.4 Study Guide 212

 High Availability

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 213

 High Availability

DO NOT REPRINT
© FORTINET

In this section, you will learn about FGCP virtual clustering.

Enterprise Firewall 6.4 Study Guide 214

 High Availability

DO NOT REPRINT
© FORTINET

Virtual clustering is essentially a cluster of two FortiGate devices operating with multiple VDOMs enabled.

You can configure a virtual cluster in active-passive mode to provide standard failover protection between two
instances of a VDOM operating on two different devices. You can also configure a virtual cluster in active-active
mode to load balance sessions between two cluster devices. There is another way you can load balance
sessions in a virtual cluster, which is VDOM partitioning.

Virtual clustering operates on a cluster of only two FortiGate devices. If you want to create a cluster of more than
two FortiGate devices operating with multiple VDOMs, you could consider other solutions that either do not
include multiple VDOMs in one cluster or employ a feature, such as standalone session synchronization with
FGSP.

Other requirements to configure virtual clustering are the same as in a standard HA configuration.

Enterprise Firewall 6.4 Study Guide 215

 High Availability

DO NOT REPRINT
© FORTINET

There are two ways to configure load balancing for virtual clustering. The first method is to set the HA mode to
active-active, and the second method is to configure VDOM partitioning.

For virtual clustering, setting the HA mode to active-active, the primary device receives all sessions and load
balances them among the cluster devices according to the load balancing schedule. All cluster devices process
traffic for all VDOMs.

Enterprise Firewall 6.4 Study Guide 216

 High Availability

DO NOT REPRINT
© FORTINET

In VDOM partitioning, the HA mode is set to active-passive. To configure VDOM partitioning, you configure one
cluster device as the primary for some VDOMs and you set the other cluster device as the primary for other
VDOMs. All traffic for a VDOM is processed by the primary device for that VDOM. You can control the distribution
of traffic between cluster devices by adjusting which cluster device is the primary unit for each VDOM.

Enterprise Firewall 6.4 Study Guide 217

 High Availability

DO NOT REPRINT
© FORTINET

In this example, HA is configured in active-passive mode. Traffic for VDOM A will be processed by FortiGate 1
and for VDOM B, FortiGate 2 will process all traffic. In case of a failover, one device in the cluster will process all
traffic for all VDOMs.

Enterprise Firewall 6.4 Study Guide 218

 High Availability

DO NOT REPRINT
© FORTINET

In this section, you will learn about some HA troubleshooting commands.

Enterprise Firewall 6.4 Study Guide 219

 High Availability

DO NOT REPRINT
© FORTINET

If the HA cluster forms successfully, the GUI displays all the FortiGate members with their hostnames, serial
numbers, role, uptime, and synchronization status.

Enterprise Firewall 6.4 Study Guide 220

 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, use the question mark at the end of that same command.

Enterprise Firewall 6.4 Study Guide 221

 High Availability

DO NOT REPRINT
© FORTINET

Using the CLI, you can get more information about the status of the 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 heartbeat interface IP address automatically assigned to the primary FortiGate.

Enterprise Firewall 6.4 Study Guide 222

 High Availability

DO NOT REPRINT
© FORTINET

You can use the command shown on this slide to display following information:
• HA health status
• Cluster uptime
• Criteria used to select the master unit
• Override status
• Status of the monitored interfaces
• Status of the HA ping servers

Enterprise Firewall 6.4 Study Guide 223

 High Availability

DO NOT REPRINT
© FORTINET

The HA uptime is one of variables used to elect the primary device. Depending on other variables and
configuration, the device might compare their system uptimes to elect the primary. If that happens, and if there is
one member whose system uptime is five minutes more than the system uptimes of all the other devices, that
member is elected 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.

Enterprise Firewall 6.4 Study Guide 224

 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 exactly 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 applying them 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.

Enterprise Firewall 6.4 Study Guide 225

 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.

Enterprise Firewall 6.4 Study Guide 226

 High Availability

DO NOT REPRINT
© FORTINET

By default, HA session synchronization is disabled. If you enable it, you can check the primary's session table 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.

Enterprise Firewall 6.4 Study Guide 227

 High Availability

DO NOT REPRINT
© FORTINET

There are four 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 sent by the primary. 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. Only available for devices with SSDs.

Enterprise Firewall 6.4 Study Guide 228

 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’s logs should show these log entries.

Enterprise Firewall 6.4 Study Guide 229

 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 here, the primary unit is reporting a problem with
the monitored interface port1.

Enterprise Firewall 6.4 Study Guide 230

 High Availability

DO NOT REPRINT
© FORTINET

Another useful way to determine the reason of a HA failover is by running the command shown on this slide. This
command provides details about past HA events, allowing admins to identify the reason for previous failover
events. This is a useful HA command, especially when HA logs are not available.

Enterprise Firewall 6.4 Study Guide 231

 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 unit 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.

Enterprise Firewall 6.4 Study Guide 232

 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 could also create HA heartbeat problems. In those cases, troubleshoot and fix the high CPU
problem first, before checking the HA status.

Enterprise Firewall 6.4 Study Guide 233

 High Availability

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

Enterprise Firewall 6.4 Study Guide 234

 High Availability

DO NOT REPRINT
© FORTINET

Now, you will work on Lab 3–System Troubleshooting.

Enterprise Firewall 6.4 Study Guide 235

 High Availability

DO NOT REPRINT
© FORTINET

In this lab, you will configure virtual clustering and distribute traffic between two FortiGate devices in the virtual
cluster.

Enterprise Firewall 6.4 Study Guide 236

 Central Management

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about using FortiManager for the central administration of all FortiGate devices in an
enterprise network.

Enterprise Firewall 6.4 Study Guide 237

 Central Management

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in using FortiManager, you will be able to centralize the administration of all
FortiGate devices in an enterprise network.

Enterprise Firewall 6.4 Study Guide 238

 Central Management

DO NOT REPRINT
© FORTINET

In this section, you will review the key features of FortiManager.

Enterprise Firewall 6.4 Study Guide 239

 Central Management

DO NOT REPRINT
© FORTINET

When should you use FortiManager in your network?

In large enterprises and managed security service providers (MSSPs), the size of the network introduces
challenges that smaller networks don’t have: mass provisioning; scheduling rollout of configuration changes; and
maintaining, tracking, and auditing many changes.

Centralized management through FortiManager can help you to more easily manage many deployment types
with many devices, and to reduce the cost of operation.

What can FortiManager do?

• Provision firewall policies across your network

• Act as a central repository for configuration revision control and security audits
• Deploy and manage complex mesh and star IPsec VPNs
• Act as a private FortiGuard distribution server (FDS) for your managed devices
• Script and automate device provisioning, policy changes, and more with JSON APIs

Enterprise Firewall 6.4 Study Guide 240

 Central Management

DO NOT REPRINT
© FORTINET

FortiManager can help you to better organize and manage your network. Key features of FortiManager include:

• Centralized management: Instead of logging in to hundreds of FortiGate devices individually, you can use
FortiManager to manage them all from a single console.
• Administrative domains (ADOMs): FortiManager can group devices into geographic or functional ADOMs,
which is ideal if you have a large team of network security administrators.
• Configuration revision control: Your FortiManager keeps a history of all configuration changes. You can
schedule FortiManager to deploy a new configuration or revert managed devices to a previous configuration.
• Local FortiGuard service provisioning: To reduce network delays and minimize Internet bandwidth usage,
your managed devices can use FortiManager as a private FDN server.
• Firmware management: FortiManager can schedule firmware upgrades for managed devices.
• Scripting: FortiManager supports CLI-based and TCL-based scripts for configuration deployments.
• Pane Managers (VPN, FortiAP, FortiSwitch, and Fabric View): FortiManager management panes simplify
the deployment and administration of VPN, FortiAP, FortiSwitch and Fabric View (Security Fabric).
• Logging and reporting: Managed devices can store logs on FortiManager. From that log data, you can
generate SQL-based reports, because FortiManager has many of the same logging and reporting features as
FortiAnalyzer.
• FortiMeter: Allows you turn FortiOS-VMs and FortiWebOS-VMs on and off as needed, paying only for the
volume and consumption of traffic that you use. These VMs are also sometimes called pay-as-you-go VMs.
You must have a FortiMeter license and the FortiMeter license must be linked with the FortiManager unit by
using FortiCare.

Enterprise Firewall 6.4 Study Guide 241

 Central Management

DO NOT REPRINT
© FORTINET

In this section, you will examine FortiManager software architecture.

Enterprise Firewall 6.4 Study Guide 242

 Central Management

DO NOT REPRINT
© FORTINET

Inside FortiManager, there are management layers that are represented as panes on the GUI. The device
management layer, for example, is represented by the Device Manager pane, which performs revision history
and scripting.

Now, you will look at the management layers in further detail.

Enterprise Firewall 6.4 Study Guide 243

 Central Management

DO NOT REPRINT
© FORTINET

To organize and efficiently manage a large-scale network, FortiManager has multiple management layers.

The Global ADOM layer has two key pieces: the global object database and header and footer policy packages.
Header and footer policy packages envelop each ADOM’s policies. An example of where policy packages are
used is in a carrier environment, where the carrier allows customer traffic to pass through their network, but does
not allow the customer to have access to the carrier’s network infrastructure.

The ADOM layer is where policy packages are created, managed, and installed on managed devices or device
groups. Multiple policy packages can be created here. The ADOM layer includes one common object database
for each ADOM. The common object database contains information such as addresses, services, and security
profiles.

The Device Manager layer records information on devices that are centrally managed by the FortiManager
device, such as the name of the device, type of device, model, IP address, current firmware installed, revision
history, and real-time status.

Enterprise Firewall 6.4 Study Guide 244

 Central Management

DO NOT REPRINT
© FORTINET

Understanding the layers of FortiManager’s management model is important.

In the Global ADOM layer, you create header and footer policy rules. These policy rules can be assigned to
multiple ADOMs. If multiple ADOM policy packages require the same policies and objects, you can create them in
this layer so that you don’t have to maintain copies in each ADOM.

In the ADOM layer, objects and policy packages in each ADOM share a common object database. You can
create, import from, and install policy packages on many managed devices at once.

In the Device Manager layer, you can configure and install device settings for each device. If a configuration
change is detected—made locally or on FortiManager—FortiManager compares the current configuration to the
changed configuration, and creates a new configuration revision on FortiManager. Whether the configuration
change is big or small, FortiManager records it and saves the new configuration. This can help administrators to
audit configuration changes, and to revert to a previous revision, if required.

Enterprise Firewall 6.4 Study Guide 245

 Central Management

DO NOT REPRINT
© FORTINET

What is an ADOM?

ADOMs enable the admin account to create groupings of devices for administrators to monitor and manage. For
example, administrators can manage devices specific to their geographic location or business division. ADOMs
are not enabled by default and must be enabled by the administrator.

The purpose of ADOMs is to divide the administration of devices, by grouping them based on management
criteria, and to control (restrict) administrative access. Administrative access is assigned based on an
administrator profile that allows access to one or multiple ADOMs on the device. If virtual domains (VDOMs) are
used, ADOMs can further restrict access to data from only a specific device’s VDOM. The number of available
ADOMs varies based on model.

Enterprise Firewall 6.4 Study Guide 246

 Central Management

DO NOT REPRINT
© FORTINET

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

You can open the Import policy and Re-install Policy wizards by right-clicking your managed device in the
Device Manager.

Enterprise Firewall 6.4 Study Guide 247

 Central Management

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 248

 Central Management

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 249

 Central Management

DO NOT REPRINT
© FORTINET

Depending on the VPN topology you are installing, there are three types of communities:
• Full meshed
• Star
• Dial-up

Enterprise Firewall 6.4 Study Guide 250

 Central Management

DO NOT REPRINT
© FORTINET

The VPN community contains the IPsec phase 1 and 2 settings that are common to all the gateways.

Enterprise Firewall 6.4 Study Guide 251

 Central Management

DO NOT REPRINT
© FORTINET

The next step is to add gateways to the community. There are two types of gateways:
• Managed gateways
• External gateways

Managed gateways are managed by FortiManager in the current ADOM. Devices in a different ADOM or other
vendor devices can be treated as external gateways. VPN configuration must be handled manually by the
administrator in that ADOM.

Enterprise Firewall 6.4 Study Guide 252

 Central Management

DO NOT REPRINT
© FORTINET

In VPN gateways, you configure the node type (hub, spoke, and so on), depending on the VPN topology you
select. For example, hub and spoke options are available only in star and dial-up topologies.

For each gateway, you can also configure the protected subnet, interfaces, and some advanced settings.

Enterprise Firewall 6.4 Study Guide 253

 Central Management

DO NOT REPRINT
© FORTINET

In this section, you will learn about the scripting options that are available on FortiManager.

Enterprise Firewall 6.4 Study Guide 254

 Central Management

DO NOT REPRINT
© FORTINET

A script can make many changes to a managed device and is useful for bulk configuration changes and
consistency across multiple managed devices. FortiManager supports two types of scripts: CLI scripts and TCL
scripts.

CLI scripts include only FortiOS CLI commands as they are entered on the command line prompt on a FortiGate
device. TCL is a dynamic scripting language that extends the functionality of CLI scripting. In FortiManager TCL
scripts, the first line of the script is #!. This is standard for TCL scripts. Do not include the exit command that
normally ends TCL scripts because it will prevent the script from running. You need to be familiar with the TCL
language and regular expressions. For more information on TCL scripts, refer to the official TCL website:
http://www.tcl.tk.

CLI scripts are enabled by default.

CLI scripts can be run in three different ways:

• Device database: By default, a script is run on the device database. It is recommend that you run the
changes on the device database (default setting), because this allows you to check what configuration
changes you will send to the managed device. After scripts run on the device database, you can install these
changes to a managed device using the installation wizard.
• Policy package, ADOM database: If a script contains changes related to ADOM-level objects and policies,
you can change the default selection to run on policy package, ADOM database and then install it using the
installation wizard.
• Remote FortiGate directly (through CLI): A script can be run directly on the device and you don’t need to
install these changes using the installation wizard. Because the changes are directly installed on the managed
device, no option is provided to verify and check the configuration changes through FortiManager prior to
executing it.

Enterprise Firewall 6.4 Study Guide 255

 Central Management

DO NOT REPRINT
© FORTINET

For TCL scripts, you need to enable show command for TCL scripts on the FortiManager CLI.

Note that TCL scripts do not run through the FGFM tunnel like CLI scripts do. TCL scripts use SSH to tunnel
through FGFM and they require SSH authentication to do so. If FortiManager does not use the correct
administrative credentials in Device Manager, the TCL script will fail. CLI scripts use the FGFM tunnel and the
FGFM tunnel is authenticated using the FortiManager and FortiGate serial numbers.

TCL scripts can only be run on Remote FortiGate directly (through the CLI).

Enterprise Firewall 6.4 Study Guide 256

 Central Management

DO NOT REPRINT
© FORTINET

The example on this slide shows how you can run a CLI command from a TCL script. Any TCL script must start
with #!.

The next line, exec TCL, runs the CLI command get system status.

The CLI command runs only if the TCL interpreter gets the # from the FortiGate command prompt within 10
seconds. If that is not the case, the CLI command is not run, and the script generates an error.

The output of the CLI command is saved to the FortiManager script history log using the TCL command puts.

Enterprise Firewall 6.4 Study Guide 257

 Central Management

DO NOT REPRINT
© FORTINET

This slide shows an example of using TCL variables.

The TCL set command creates a new variable (newhostname) and sets its value to NGFW.

The value of the variable is then used (prepending the $ sign) to configure the FortiGate hostname.

Enterprise Firewall 6.4 Study Guide 258

 Central Management

DO NOT REPRINT
© FORTINET

If you are running a command, or a group of commands, multiple times in a script, you can add those commands
to a TCL procedure for simplification. You can pass one or more parameters to a TCL procedure.

In the example shown on this slide, we are creating a TCL procedure called do_cmd. This procedure instructs the
interpreter to run a CLI command (received through the parameter cmd) if the # is received within 10 seconds.

After that, the script calls that procedure five times (each time passing a different parameter) to configure the IP
address on port1.

Enterprise Firewall 6.4 Study Guide 259

 Central Management

DO NOT REPRINT
© FORTINET

This slide contains a more complex TCL example that shows the power of TCL scripts. Say that you have 150
hosts in your network and you need to create 150 different firewall addresses: one for each of your hosts. This
TCL script uses a loop to do that.

The script uses two variables. The variable numhosts contains the number of addresses to create. The variable
i starts with the value 1 and is incremented after each loop. The loop is run a number of times equal to the
variable numhosts.

Inside each loop, the variable i is used to set the name of the firewall address and its IP address. What is
actually run on FortiGate are the hundred and fifty firewall addresses.

Enterprise Firewall 6.4 Study Guide 260

 Central Management

DO NOT REPRINT
© FORTINET

When creating CLI scripts, follow these best practices:

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

Enterprise Firewall 6.4 Study Guide 261

 Central Management

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

Enterprise Firewall 6.4 Study Guide 262

 Central Management

DO NOT REPRINT
© FORTINET

You will now work on Lab 7–Central Management.

Enterprise Firewall 6.4 Study Guide 263

 Central Management

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 264

 OSPF

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about Open Shortest Path First (OSPF) concepts, and how to configure and
troubleshoot OSPF.

Enterprise Firewall 6.4 Study Guide 265

 OSPF

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in understanding OSPF, you will be able to understand, configure, and
troubleshoot OSPF.

Enterprise Firewall 6.4 Study Guide 266

 OSPF

DO NOT REPRINT
© FORTINET

In this section, you will review OSPF.

Enterprise Firewall 6.4 Study Guide 267

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 268

 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's routing table.

Enterprise Firewall 6.4 Study Guide 269

 OSPF

DO NOT REPRINT
© FORTINET

The topology information interchanged by OSPF peers is contained in LSAs. A router's LSDB is populated with
the information from the local LSAs and all the LSAs received from other routers.

Enterprise Firewall 6.4 Study Guide 270

 OSPF

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

Enterprise Firewall 6.4 Study Guide 271

 OSPF

DO NOT REPRINT
© FORTINET

The next two slides explain how an OSPF router builds its OSPF tree. The initial information for each router is the
locally connected networks, together with the OSPF cost for each interface. In 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.

Enterprise Firewall 6.4 Study Guide 272

 OSPF

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 is repeated
multiple times until the best routes are found. For example, this slide shows the OSPF tree for router R2. It
indicates that the best route to Net 5 and Net 4 is through R3, and that Net 1, Net 2, and Net 3 are locally
connected.

Enterprise Firewall 6.4 Study Guide 273

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 274

 OSPF

DO NOT REPRINT
© FORTINET

Each area has its own separate LSDB. All routers in the same area maintain an identical copy of the area's
LSDB. 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.

Enterprise Firewall 6.4 Study Guide 275

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 276

 OSPF

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.

Enterprise Firewall 6.4 Study Guide 277

 OSPF

DO NOT REPRINT
© FORTINET

This slide shows an example of each router type.

Enterprise Firewall 6.4 Study Guide 278

 OSPF

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. But they do not support broadcasting.

Enterprise Firewall 6.4 Study Guide 279

 OSPF

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.

Enterprise Firewall 6.4 Study Guide 280

 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.

Enterprise Firewall 6.4 Study Guide 281

 OSPF

DO NOT REPRINT
© FORTINET

In any multiaccess network there is one DR and one BDR. The router with the highest priority is elected as the
DR. If two or more routers are tied with the highest priority, the router with the highest OSPF ID is elected.

The BDR monitors the DR status. If the DR fails, the BDR takes the DR role.

Other routers form adjacencies only with the DR and the BDR. The DR forwards the link state information from
one router to another. This simplifies the amount of adjacencies required in multi-access networks.

Enterprise Firewall 6.4 Study Guide 282

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 283

 OSPF

DO NOT REPRINT
© FORTINET

There are 11 LSA types. This lesson covers the five most commonly used:
• Type 1 describes all the links connected to a router
• Type 2 describes all the routers (if more than one) in a multiaccess 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.

Enterprise Firewall 6.4 Study Guide 284

 OSPF

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.

Enterprise Firewall 6.4 Study Guide 285

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 286

 OSPF

DO NOT REPRINT
© FORTINET

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

Something similar happens with the ABR 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.

Enterprise Firewall 6.4 Study Guide 287

 OSPF

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 this example, an
ASBR that is redistributing RIP routes into OSPF announces itself by sending type 1 LSAs to the backbone area.
The ABR receives that LSA and sends a type 4 LSA to the area 1.

Enterprise Firewall 6.4 Study Guide 288

 OSPF

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.

Enterprise Firewall 6.4 Study Guide 289

 OSPF

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 over the type 2.

Enterprise Firewall 6.4 Study Guide 290

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 291

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 292

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 293

 OSPF

DO NOT REPRINT
© FORTINET

The command shown on this slide provides detailed information about the OSPF process.

Enterprise Firewall 6.4 Study Guide 294

 OSPF

DO NOT REPRINT
© FORTINET

This command also shows information about each area the router belongs to.

Enterprise Firewall 6.4 Study Guide 295

 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 multi-access
• If it is a DR or a BDR
• DR and BDR IDs and IP addresses
• Number of adjacencies and traffic statistics

Enterprise Firewall 6.4 Study Guide 296

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 297

 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 (net link states).

Enterprise Firewall 6.4 Study Guide 298

 OSPF

DO NOT REPRINT
© FORTINET

The command shown on this slide lists the LSAs that originated on the local FortiGate.

Enterprise Firewall 6.4 Study Guide 299

 OSPF

DO NOT REPRINT
© FORTINET

Use the command shown on this slide to see details about type 1 LSAs.

Enterprise Firewall 6.4 Study Guide 300

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 301

 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.

Enterprise Firewall 6.4 Study Guide 302

 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.

Enterprise Firewall 6.4 Study Guide 303

 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.

Enterprise Firewall 6.4 Study Guide 304

 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

Enterprise Firewall 6.4 Study Guide 305

 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.

Enterprise Firewall 6.4 Study Guide 306

 OSPF

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

Enterprise Firewall 6.4 Study Guide 307

 OSPF

DO NOT REPRINT
© FORTINET

Now, you will work on Lab 8–OSPF.

Enterprise Firewall 6.4 Study Guide 308

 OSPF

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 309

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about Border Gateway Protocol (BGP).

Enterprise Firewall 6.4 Study Guide 310

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in BGP, you will be able to configure FortiGate for BGP, monitor and check the
status of a BGP communication and troubleshoot the most common external BGP issues.

Enterprise Firewall 6.4 Study Guide 311

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 312

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

An 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.

Enterprise Firewall 6.4 Study Guide 313

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

BGP can serve one of two purposes: EBGP and IBGP.

An exterior gateway protocol (EGP) exchanges routing information between autonomous systems. BGP4, which
runs in the Internet, is the dominant EGP protocol today. EBGP is typically used when strict control is required
over a large number of routes.

Two EBGP routers exchange AS path information for destination prefixes or subnets. When two routers start a
EBGP communication, the whole BGP routing table is interchanged. After that, only network updates are sent.

Enterprise Firewall 6.4 Study Guide 314

 Border Gateway Protocol

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.

Enterprise Firewall 6.4 Study Guide 315

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

There are three types of autonomous systems:

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

Enterprise Firewall 6.4 Study Guide 316

 Border Gateway Protocol

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.

Enterprise Firewall 6.4 Study Guide 317

 Border Gateway Protocol

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. A FortiGate can be configured as either an RR or client.

Enterprise Firewall 6.4 Study Guide 318

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 319

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 320

 Border Gateway Protocol

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 autonomous systems through which
the traffic must pass to reach the destination.

Enterprise Firewall 6.4 Study Guide 321

 Border Gateway Protocol

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 are supported by FortiGate.

Enterprise Firewall 6.4 Study Guide 322

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 323

 Border Gateway Protocol

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.

Enterprise Firewall 6.4 Study Guide 324

 Border Gateway Protocol

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.

Enterprise Firewall 6.4 Study Guide 325

 Border Gateway Protocol

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 whose destination subnet matches the prefix, FortiGate doesn’t advertise the prefix. You
can change this behavior by disabling the network-import-check setting. After you disable the setting,
FortiGate advertises all prefixes in the BGP network table, regardless of the active routes present in the routing
table.

Enterprise Firewall 6.4 Study Guide 326

 Border Gateway Protocol

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. In this example, we are
creating a prefix list that allows the prefix 10.0.0.0/8, but blocks the prefix 10.1.0.0/16. By default, all the
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 the prefix advertisements coming from
10.3.1.254.

When applying a prefix list, all the prefixes that don’t match an entry in the list are denied by default.

Enterprise Firewall 6.4 Study Guide 327

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 328

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

When implementing an RR, the configuration is done on the RR only. You can use the commands shown on this
slide to configure each neighbor that will be participating in the RR cluster.

Enterprise Firewall 6.4 Study Guide 329

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

By default, a BGP route reflector propagates only one path for each prefix. If you enable additional-path, a
FortiGate acting as a RR can propagate multiple paths for a same prefix. This allows a more efficient use of BGP,
while it can prevent sub-optimal routing.

ADVPN requires all the hubs to be configured as BGP RR. Additionally, scenarios where you want to combine
ADVPN with SDWAN requires BGP additional path. In those ADVPN and SDWAN scenarios, it is common to
have multiple redundant IPsec tunnels between two locations. BGP additional path enables the ADVPN hub to
dynamically propagate all the redundant paths to each remote location through BGP.

Enterprise Firewall 6.4 Study Guide 330

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

In this scenario, there are two redundant IPsec tunnels between Spoke-1 and Hub. There is also an IPsec
between Spoke-2 and Hub. BGP over IPsec propagates the routing information. Hub is a route reflector with BGP
additional path enabled.

As BGP additional path is enabled, Spoke-2 receives two BGP route advertisements from Hub: one for each
redundant tunnel. ADVPN can use this routing to dynamically create on-demand IPsec tunnels between Spoke-2
and Spoke-1.

Enterprise Firewall 6.4 Study Guide 331

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 332

 Border Gateway Protocol

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

Enterprise Firewall 6.4 Study Guide 333

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 334

 Border Gateway Protocol

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.

Enterprise Firewall 6.4 Study Guide 335

 Border Gateway Protocol

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.

Enterprise Firewall 6.4 Study Guide 336

 Border Gateway Protocol

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

Enterprise Firewall 6.4 Study Guide 337

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 338

 Border Gateway Protocol

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.

Enterprise Firewall 6.4 Study Guide 339

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 340

 Border Gateway Protocol

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 establishing of the connection.
The output also lists the prefixes FortiGate received after the BGP session is established.

Enterprise Firewall 6.4 Study Guide 341

 Border Gateway Protocol

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.

Enterprise Firewall 6.4 Study Guide 342

 Border Gateway Protocol

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 command shown on this slide.

Enterprise Firewall 6.4 Study Guide 343

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

You can view BGP-related router events on the GUI. You can click any logged entry to view the details.

Enterprise Firewall 6.4 Study Guide 344

 Border Gateway Protocol

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
• Check the TCP session
• Check the BGP session
• If the BGP session is established, check the prefixes received and advertised by each peer

Enterprise Firewall 6.4 Study Guide 345

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

Enterprise Firewall 6.4 Study Guide 346

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

Now you will work on Lab 9–BGP.

Enterprise Firewall 6.4 Study Guide 347

 Border Gateway Protocol

DO NOT REPRINT
© FORTINET

In this lab, you will configure BGP routing between the next generation firewall one (NGFW-1) and the Linux-
Router. You will also use the BGP real-time debug to troubleshoot BGP issues.

Enterprise Firewall 6.4 Study Guide 348

 Web Filtering

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about web filtering.

Enterprise Firewall 6.4 Study Guide 349

 Web Filtering

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in web filtering, you will be able to implement, maintain, and troubleshoot web
filtering on FortiGate.

Enterprise Firewall 6.4 Study Guide 350

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 351

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 352

 Web Filtering

DO NOT REPRINT
© FORTINET

With encrypted traffic making up between 60% to 80% of most organization’s traffic, it has become critical that
encrypted traffic is inspected in order to maintain a secure network. In the context of web filtering, FortiGate has
two methods of inspecting outbound encrypted sessions—SSL certificate inspection and full SSL inspection.

You can configure an SSL/SSH inspection profile to use either method of inspection.

Enterprise Firewall 6.4 Study Guide 353

 Web Filtering

DO NOT REPRINT
© FORTINET

When using SSL certificate inspection, FortiGate doesn’t decrypt or inspect any encrypted traffic. Using this
method, FortiGate inspects only the initial unencrypted SSL handshake. If the SNI field exists, FortiGate uses it to
obtain the FQDN to rate the site. If the SNI isn’t present, FortiGate retrieves the FQDN from the CN field of the
server's certificate.

In some cases, the CN server name might not match the requested FQDN. For example, the value of the CN
field in the digital certificate of youtube.com is google.com. So, if you connect to youtube.com from a
browser that doesn’t support SNI, and FortiGate uses the SSL certificate inspection method, FortiGate assumes,
incorrectly, that you are connecting to google.com, and uses the google.com category instead of the category
for youtube.com.

You should also keep in mind that SSL certificate inspection will work only with web filtering, and with some
application signature detection when doing application control. It does not work with antivirus, IPS, or DLP
scanning, where the full payload needs to be inspected.

Enterprise Firewall 6.4 Study Guide 354

 Web Filtering

DO NOT REPRINT
© FORTINET

When doing certificate-based inspection, by default, FortiGate validates the information in the SNI field of the
client's certificate against the information in CN and SAN fields coming from the server's certificate. If the domain
in the SNI field does not match any of the domains listed in the CN and SAN fields, FortiGate uses the domain in
the CN field instead of the domain in the SNI field.

You can configure FortiGate to be more strict, so it closes the client connection if the domain in the SNI field does
not match any of the domains listed in the CN and SAN fields.

You can also configure FortiGate to disable SNI checking altogether, so that FortiGate always uses the SNI
information to obtain the FQDN to rate the site.

Enterprise Firewall 6.4 Study Guide 355

 Web Filtering

DO NOT REPRINT
© FORTINET

You can configure full SSL inspection to inspect all of the packet contents, including the payload. FortiGate
performs this inspection by proxying the SSL connection. Two SSL sessions are established—client-to-FortiGate
and FortiGate-to-server. The two established sessions allows FortiGate to encrypt and decrypt packets using its
own keys, which allows FortiGate to fully inspect all data inside the encrypted packets.

Enterprise Firewall 6.4 Study Guide 356

 Web Filtering

DO NOT REPRINT
© FORTINET

You can access the FortiGuard portal to check which category a URL belongs to. In the portal, you can also
request that a URL be reclassified.

You can also view the FortiGuard web filter categories.

Enterprise Firewall 6.4 Study Guide 357

 Web Filtering

DO NOT REPRINT
© FORTINET

You can use the FortiOS CLI to display the list of FortiGuard categories and their numerical values.

You can use FortiGuard category numbers when you create web profiles using the FortiOS CLI, or using scripts
on FortiManager. Similar to the using the GUI, you can configure different actions for each category using the
CLI.

Enterprise Firewall 6.4 Study Guide 358

 Web Filtering

DO NOT REPRINT
© FORTINET

You can use category numbers to test whether a specific category or subcategory is allowed or blocked. Use the
URL format shown on this slide for that purpose.

In the example shown on this slide, the category number 11 is Gambling. The test confirms that all sites listed in
this category will be blocked. The replacement message page displays the category that is blocked, with other
information, such as client IP, server IP, and user information.

Enterprise Firewall 6.4 Study Guide 359

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 360

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 361

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 362

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 363

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 364

 Web Filtering

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 convert the ID number from hexadecimal to decimal. Then, use the second
command to find the category name for that ID number.

Enterprise Firewall 6.4 Study Guide 365

 Web Filtering

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 output of the real-time debug when the URL to categorize isn't in the FortiGuard
cache. The output shows the URL, category, source, destination IP addresses, and service.

IPS, and WAD will only send request to urlfilter daemon when cache is missed. Once the URL is in the
FortiGuard cache, IPS Engine/WAD will start looking up the cache themselves before sending requests to
urlfilter.

Enterprise Firewall 6.4 Study Guide 366

 Web Filtering

DO NOT REPRINT
© FORTINET

Tips for troubleshooting web filtering:

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

Enterprise Firewall 6.4 Study Guide 367

 Web Filtering

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.

Enterprise Firewall 6.4 Study Guide 368

 Web Filtering

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 implement, maintain, and troubleshoot
web
filtering on FortiGate.

Enterprise Firewall 6.4 Study Guide 369

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 370

 Web Filtering

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 371

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the intrusion prevention system (IPS).

Enterprise Firewall 6.4 Study Guide 372

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in IPS, you will be able to deploy, tune, and troubleshoot IPS in an enterprise
network.

Enterprise Firewall 6.4 Study Guide 373

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 374

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

IPS uses signature databases to detect known attacks. You can also use IPS signatures to detect network errors
and anomalies.

Like the antivirus signature databases, the IPS signature databases are also updated through FortiGuard.

Enterprise Firewall 6.4 Study Guide 375

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

There is no single correct way to deploy an IPS solution. It depends greatly on the network and application
requirements. However, in most cases, you will follow the steps shown on this slide.

There are usually three stages in the deployment of an IPS solution:

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

You will learn more about each stage in this lesson.

Enterprise Firewall 6.4 Study Guide 376

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

During the analysis stage, you must identify:

• What services to protect
• The threats to those services
• Where to enable IPS inspection

Set realistic expectations. Focus on protecting the services that need protection. Start with the most critical
services, and classify the threats into groups.

Enterprise Firewall 6.4 Study Guide 377

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 378

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

To minimize the number of false positives, make the list of signatures that you set to block small and precise. The
list should include the attacks that are most dangerous to critical services.

After you deploy the IPS solution, you must continue to monitor IPS events.

Enterprise Firewall 6.4 Study Guide 379

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

When you check IPS events, start with the events that have been generated the most, or have high priority.

For each event type, analyze the IP addresses, services, and type of attack. The analysis should help you identify
whether the event is a genuine attack or a false positive.

Enterprise Firewall 6.4 Study Guide 380

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 381

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 382

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 383

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

The intelligent-mode command controls the adaptive scanning behavior of the IPS.

When you enable adaptive scanning, IPS determines when it is secure enough to stop scanning the traffic in each
session. When disabled, IPS scans every byte in every session.

Enterprise Firewall 6.4 Study Guide 384

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

In this section, you will learn how to create custom signatures.

Enterprise Firewall 6.4 Study Guide 385

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

There are two categories of Fortinet IPS signatures:

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

Enterprise Firewall 6.4 Study Guide 386

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

A custom signature is made up of a type header, and a series of option and value pairs.

All custom signatures require a header of F-SBID. An option starts with "--", followed by the option name, and,
sometimes, a value. Some options don't require a value.
You must enclose the string of option and value pairs in parentheses. Also, keywords are case insensitive and
values are case sensitive.

Enterprise Firewall 6.4 Study Guide 387

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 388

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

Now you’ll learn about supported option types. The options are divided into four categories based on their
purpose.

Enterprise Firewall 6.4 Study Guide 389

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

When creating a custom signature, you must define required options which are name, service, and flow.

The signature name must be unique for each custom signature. The maximum length of a signature name is 64
characters.

The service option specifies the session type, such as HTTP, FTP. You can only use the service keyword once in
a signature. If a signature has neither a service keyword nor a port keyword, it will be added to all service trees
including the unknown_service tree.

Similar to service option, the flow option can appear only once in the signature because it defines flow direction of
the detection packet.

Enterprise Firewall 6.4 Study Guide 390

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

Use protocol-related options to match protocol headers.

Enterprise Firewall 6.4 Study Guide 391

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 392

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

Use special options for various purposes for more granular filtering.

In this example, specifying application category will result in this signature appearing under application control
instead of IPS configuration.

Enterprise Firewall 6.4 Study Guide 393

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

If you are planning to create a custom signature, gather as many samples of the traffic as possible. Good
samples help you to identify patterns, for example, source ports, destination ports, specific string patterns in the
packet payload, and so on.

Try to match payload patterns in addition to protocol patterns, because payload patterns tend to be unique to the
specific traffic that you want to match. In this way, you might be able to reduce the number of false positives for
the custom signature.

Enterprise Firewall 6.4 Study Guide 394

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 395

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

The CP is a co-processor for the CPU. It accelerates many common resource-intensive, security-related
processes.

Since the very first FortiGate model, Fortinet has included a CP in the design. The CP works at the system level.

CP8 and CP9 provide a fast path for traffic inspected by IPS, including sessions with flow-based inspection.

CP processors also accelerate intensive proxy-based tasks:

• Encryption and decryption (SSL)
• Antivirus

Enterprise Firewall 6.4 Study Guide 396

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

Network processors (NPs) provide the following features:

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

Enterprise Firewall 6.4 Study Guide 397

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

SoC combines a general-purpose CPU, NPs, and CPs, into a single chip. It accelerates IPS-inspected traffic.

SoC is found in desktop or small office models.

Enterprise Firewall 6.4 Study Guide 398

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

In this section, you will learn about IPS troubleshooting.

Enterprise Firewall 6.4 Study Guide 399

 Intrusion Prevention System

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

In some FortiGate models, it is normal to see multiple instances of the ipsengine daemon running.

Enterprise Firewall 6.4 Study Guide 400

 Intrusion Prevention System

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.

Enterprise Firewall 6.4 Study Guide 401

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 402

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 403

 Intrusion Prevention System

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 for the type of traffic being inspected, and
disable IPS profiles on policies that don’t need them.

Enterprise Firewall 6.4 Study Guide 404

 Intrusion Prevention System

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.

Enterprise Firewall 6.4 Study Guide 405

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

If there are high CPU use problems caused by the IPS, you can use the diagnose test application
ipsmonitor command with option 5 to isolate where the problem might be. Option 5 enables IPS bypass
mode. In this mode, the IPS is still running, but it is not inspecting traffic. If the CPU use decreases after that, it
usually indicates that the volume of traffic being inspected is too high for that particular FortiGate model. If the
CPU use remains high after enabling IPS bypass mode, it usually indicates a problem in the IPS engine that you
must report to Fortinet's support.

If you enable IPS bypass mode, remember to disable it, after you finish troubleshooting, using option 5.

Another recommendation to keep in mind: if you need to restart the IPS, don't use the diagnose sys top
kill command. Instead, use option 99, as shown on this slide. This guarantees that all the IPS-related
processes will restart properly.

Enterprise Firewall 6.4 Study Guide 406

 Intrusion Prevention System

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.

Enterprise Firewall 6.4 Study Guide 407

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

False negatives are more difficult to discover and troubleshoot. Check the following:
• Is traffic hitting the correct policy or IPS profile? Use sniffer and debug flow if necessary.
• CPU and memory use is normal
• IPS engines aren’t crashing
• IPS configuration is correct

Again, after you verify all of those factors, you can collect sniffer samples and, along with details of the application
traffic, provide all the information to the Fortinet IPS team for investigation.

Enterprise Firewall 6.4 Study Guide 408

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

Enterprise Firewall 6.4 Study Guide 409

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

Now, you will work on Lab 11–IPS.

Enterprise Firewall 6.4 Study Guide 410

 Intrusion Prevention System

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 411

 IPsec

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about IPsec.

Enterprise Firewall 6.4 Study Guide 412

 IPsec

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in IPsec, you will be able to configure IPsec using the FortiManager VPN
manager, troubleshoot IPsec problems using debug flow, check IPsec encryption and decryption behavior,
capture IPsec traffic, and monitor the IPsec VPN status.

Enterprise Firewall 6.4 Study Guide 413

 IPsec

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 414

 IPsec

DO NOT REPRINT
© FORTINET

IPsec is a suite of protocols for authenticating and encrypting traffic between two peers. The two most-used
protocols in the suite are:
• IKE, which does the handshake, tunnel maintenance, and disconnection
• ESP, which ensures data integrity and encryption

Enterprise Firewall 6.4 Study Guide 415

 IPsec

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 416

 IPsec

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 417

 IPsec

DO NOT REPRINT
© FORTINET

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

Enterprise Firewall 6.4 Study Guide 418

 IPsec

DO NOT REPRINT
© FORTINET

Extended authentication (XAuth) can be used as an additional level of authentication. When XAuth is used, one
side must provide credentials (username and password) in order to successfully authenticate.

XAuth happens after the phase 1 is up and before any phase 2 negotiation. That is why XAuth is sometimes
referred to as phase 1.5.

In any XAuth communication, there is always one client and one server. The server sends a CFG_REQUEST
packet, which must be replied by the client with a CFG_REPLY packet. The CFG_REPLY packet includes the user
credentials. If the authentication is ok, the server sends CFG_SET and the client replies with CFG-ACK.

Enterprise Firewall 6.4 Study Guide 419

 IPsec

DO NOT REPRINT
© FORTINET

A FortiGate supports three different methods for automatically configuring the IP settings of IPsec clients: IKE
mode configuration, DHCP over IPsec, and L2TP over IPsec.

This slide shows the IKE mode configuration.

After phase 1 is up, and before the phase 2, the client sends a CFG_REQUEST message listing the required IP
settings (or attributes). The server replies with a CFG_REPLY, which contains the assigned values for each of
the attributes requested.

Enterprise Firewall 6.4 Study Guide 420

 IPsec

DO NOT REPRINT
© FORTINET

When the first phase 1 IPsec packet arrives, the FortiGate acting as the responder uses the first phase 1
configuration (in alphabetical order) that matches the following:

• Local gateway IP
• Mode (aggressive or main)
• Peer ID, if aggressive mode is used. As explained, only aggressive mode includes the peer ID in the first
packet.
• Authentication method (for pre-shared key and certificates)
• Digital certificate information, if certificates are used as the authentication method
• Proposal
• DH group

However, in some circumstances, FortiOS can switch to a different phase 1, if it finds that it initially selected the
wrong phase 1. This is called gateway revalidation and applies only to the following:

• IKEv1 with certificate authentication

• IKEv2 with pre-shared key authentication
• IKEv2 with certificate authentication

Enterprise Firewall 6.4 Study Guide 421

 IPsec

DO NOT REPRINT
© FORTINET

If a FortiGate has multiple dialup VPNs using pre-shared keys and sharing the same local gateway, proposal, and
DH group, you must use aggressive mode and different peer IDs. Using this method, the FortiGate identifies the
right VPN configuration for each incoming IPsec proposal.

Enterprise Firewall 6.4 Study Guide 422

 IPsec

DO NOT REPRINT
© FORTINET

In this section, you will learn how FortiGate routes IP traffic.

Enterprise Firewall 6.4 Study Guide 423

 IPsec

DO NOT REPRINT
© FORTINET

If the IPsec VPN has been configured in interface mode, statics routes are automatically added to clients each
time a dialup IPsec connects. The destination subnets of the static routes are the ones received in the phase 2
quick mode selectors. When IKE mode configuration, or DHCP over IPsec is used, those subnets (with a /32
mask) matched the IP addresses assigned to dialup users.

If you are running a dynamic routing protocol over IPsec, disable add-route. This will prevent FortiGate from
dynamically adding the route, as that is not required because the dynamic routing protocol updates the routing
table once the tunnel is up.

By default, the distance assigned to those dynamic routes is 15, and the priority is 0. You can change those
values in the phase 1 configuration.

Enterprise Firewall 6.4 Study Guide 424

 IPsec

DO NOT REPRINT
© FORTINET

When the phase 1 setting net-device is enabled, FortiGate creates separate virtual interfaces for each dialup
client. The names of those interfaces comprise the phase 1 name and an index number.

When you use this configuration, FortiGate uses the information in the destination subnets of the quick-mode
selectors to learned the networks behind each remote IPsec client. Each virtual IPsec interface is associated with
one client (or one IKE SA).

Enterprise Firewall 6.4 Study Guide 425

 IPsec

DO NOT REPRINT
© FORTINET

If net-device is disabled, FortiGate creates a single IPsec virtual interface that is shared by all IPsec clients
connecting to the same dialup VPN.

In this case, the tunnel-search setting determines how FortiGate learns the networks behind each remote
client. If tunnel-search is set to selectors, FortiGate uses, as in the previous case, the destination subnets
of the quick-mode selectors to populate the routing table with information about the remote networks.

However, in this scenario there can be multiple clients (or IKE SA) associated with a single interface. FortiGate
needs more information (specifically, the tunnel index to each remote network) to route traffic to the clients
properly.

Enterprise Firewall 6.4 Study Guide 426

 IPsec

DO NOT REPRINT
© FORTINET

You can use the command diagnose vpn tunnel list. to display extra routing information.

The output from this command shows the mapping between each remote subnet (learned through quick-mode
selectors) and the phase 1 index that must be used to properly route the traffic to the correct destinations.

Enterprise Firewall 6.4 Study Guide 427

 IPsec

DO NOT REPRINT
© FORTINET

If net-device is set to disable, and tunnel-search is set to nexthop, FortiGate does not use the quick-
mode selectors to learn about remote networks. FortiGate will learn those routes with the assistance of a dynamic
routing protocol, which must be configured to run over the IPsec tunnels.

Enterprise Firewall 6.4 Study Guide 428

 IPsec

DO NOT REPRINT
© FORTINET

As with tunnel-search set to nexthop, FortiGate creates one single IPsec virtual interface that is shared by
all IPsec clients. FortiGate needs more information about how to route the IPsec traffic through the correct IKE
SA. With this configuration, FortiGate learns the remote IPs for each client through IKE messages. By default,
these remote IPs belong to the IPsec virtual interfaces of the clients. FortiGate combines this information, with the
routes learned through a routing protocol, to properly route the IPsec traffic, selecting the correct outbound IPsec
virtual interface and IKE SA.

The output of the diagnose vpn tunnel list command shows the list of remote IPs and the associated
tunnel indexes.

Enterprise Firewall 6.4 Study Guide 429

 IPsec

DO NOT REPRINT
© FORTINET

If two remote sites have the same subnets, they might create overlapping static routes in the central FortiGate.
The setting route-overlap, found in phase 2, defines what action FortiGate will take when a new remote site
is connecting and there is a remote site already connected with an overlapping subnet. The possible actions
include:

• use-new (default): Disconnect the existing dialup VPN and accept the new VPN.
• use-old: Keep the existing dialup VPN up and reject the new one.
• allow: Keep the existing dialup VPN up and accept the new one. Traffic for sessions that start from the
central FortiGate will be load balanced (ECMP) between both VPNs.

Enterprise Firewall 6.4 Study Guide 430

 IPsec

DO NOT REPRINT
© FORTINET

Two or more IPsec tunnels between two sites can be combined to create an aggregated tunnel. This is similar to
LACP port aggregation. One single aggregated IPsec interface is created and used for routing and firewall
policing.

Aggregated IPsec tunnels support five load-balancing methods:

• round-robin: Traffic is balanced per-packet.

• L3: Traffic is balanced based on the Layer 3 header information.
• L4: Traffic is balanced based on the Layer 4 header information.
• redundant: All traffic is sent though the tunnel that came up first. The other tunnels are used for backup.
• weighted-round-robin: Traffic is load balanced in a round-robin manner based on link weights configured
for each tunnel.

Enterprise Firewall 6.4 Study Guide 431

 IPsec

DO NOT REPRINT
© FORTINET

Forward Error Correction (FEC) is a phase 1 setting that, when enabled, adds additional packets with redundant
data. The recipient can use this redundant information to reconstruct any lost packet, or any packet that arrived
with errors. Although this feature increases the bandwidth usage, it improves reliability that can overcome
adverse WAN conditions such as lossy or noisy links. FEC can be critical for delivering a better user experience
for business-critical applications like voice and video services.

Enterprise Firewall 6.4 Study Guide 432

 IPsec

DO NOT REPRINT
© FORTINET

In this section, you will learn the basics of IPsec troubleshooting.

Enterprise Firewall 6.4 Study Guide 433

 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 goes 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 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.

Enterprise Firewall 6.4 Study Guide 434

 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.

Enterprise Firewall 6.4 Study Guide 435

 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 bit-mask. The most
common value for the bit-mask is -1 (all outputs enabled). It shows the DPD packets and all the information
required for troubleshooting IPsec negotiation problems.

Enterprise Firewall 6.4 Study Guide 436

 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
once FortiGate identifies the VPN configuration to use (with the name of the VPN).

Enterprise Firewall 6.4 Study Guide 437

 IPsec

DO NOT REPRINT
© FORTINET

Next, the output shows the remote peers information. The second and third main mode messages arrive. After
the authentication is successful and the preshared key matches, a final message is generated to indicate that the
phase 1 is up.

Enterprise Firewall 6.4 Study Guide 438

 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 interchanged, and the proposals.

Enterprise Firewall 6.4 Study Guide 439

 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.

Enterprise Firewall 6.4 Study Guide 440

 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.

Enterprise Firewall 6.4 Study Guide 441

 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.

Enterprise Firewall 6.4 Study Guide 442

 IPsec

DO NOT REPRINT
© FORTINET

Next, the output shows the negotiated phase 2 settings. The last messages confirm that the phase 2 is up.

Enterprise Firewall 6.4 Study Guide 443

 IPsec

DO NOT REPRINT
© FORTINET

If the VPN is up but the traffic can’t cross the tunnel, you should use the debug flow. This slide shows an example
output of the debug flow for traffic that is crossing an IPsec tunnel. The output shows the following:
• Packet arriving
• Packet being allowed by a firewall policy
• Packet entering the tunnel
• Packets being encrypted and sent

If the traffic is not crossing the tunnel because of a routing misconfiguration, the output of the debug flow shows it.
The debug flow also displays if the traffic drops and why (for example, when packets don’t match the quick mode
selector).

Enterprise Firewall 6.4 Study Guide 444

 IPsec

DO NOT REPRINT
© FORTINET

If you need to capture the IPsec traffic, remember that the IP protocol and UDP port numbers depend on NAT-T
and the use of NAT.

If there is no FortiGate located in the middle that is running NAT, IKE traffic uses UDP port 500 and ESP traffic
uses IP protocol 50. This slide shows the two sniffer filters that the sniffer command must use to capture each of
those traffic protocols.

If NAT-T is enabled, and there is a FortiGate located in the middle that is running NAT, the sniffer command must
use a different filter. In this case, IKE traffic uses port UDP 500, but switches to UDP port 4500 during the tunnel
negotiation. Additionally, ESP traffic is encapsulated inside the UDP-4500 channel.

Enterprise Firewall 6.4 Study Guide 445

 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.

Enterprise Firewall 6.4 Study Guide 446

 IPsec

DO NOT REPRINT
© FORTINET

get vpn ipsec tunnel details provides detailed information for the active IPsec tunnels.

Enterprise Firewall 6.4 Study Guide 447

 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
as it has a global effect, meaning that running it without specifying the phase 1 name will result in all phase 1s of
all VDOMs being cleared.

Enterprise Firewall 6.4 Study Guide 448

 IPsec

DO NOT REPRINT
© FORTINET

The command get vpn ipsec stats tunnel provides some global overall counters related to all the VPNs
currently active.

The other two commands shown on this slide provide summarized information about the VPNs.

Enterprise Firewall 6.4 Study Guide 449

 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 unit that is offloading the encryption and
decryption.

By default, hardware offloading is enabled for the supported algorithms. This slide shows the commands you can
use to disable hardware offloading per tunnel, if necessary.

Enterprise Firewall 6.4 Study Guide 450

 IPsec

DO NOT REPRINT
© FORTINET

All IPsec SAs have an npu_flag field indicating offloading status. In the case of IPsec traffic, the FortiGate
session table also includes that field.

First, when phase 2 goes up, the IPsec SAs are created and loaded to the kernel. As long as there is no traffic
crossing the tunnel, the SAs are not copied to the NPU, and the npu_flag shows 00. The value of that field also
remains 00 when IPsec offloading is disabled.

Second, if the first IPsec packet that arrives is an outbound packet that can be offloaded, the outbound SA is
copied to the NPU and the npu_flag changes to 01. However, if the first IPsec packet is inbound and can be
offloaded, the inbound SA is copied to the NPU and the npu_flag changes to 02.

After both SAs are copied to the NPU, the npu_flag changes to 03.

The value 20 in the npu_flag field indicates that hardware offloading is unavailable because of an unsupported
cipher or HMAC algorithm.

Enterprise Firewall 6.4 Study Guide 451

 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.

Enterprise Firewall 6.4 Study Guide 452

 IPsec

DO NOT REPRINT
© FORTINET

This slide shows the objectives that you covered in this lesson.

Enterprise Firewall 6.4 Study Guide 453

 IPsec

DO NOT REPRINT
© FORTINET

Now, you will now work on Lab 12–IPsec.

Enterprise Firewall 6.4 Study Guide 454

 IPsec

DO NOT REPRINT
© FORTINET

In this lab, you will troubleshoot an IPsec problem between Spoke-1 and Spoke-2.

Enterprise Firewall 6.4 Study Guide 455

 IPsec

DO NOT REPRINT
© FORTINET

Then, you will configure a hub-and-spoke VPN network using the FortiManager VPN manager.

Enterprise Firewall 6.4 Study Guide 456

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about autodiscovery VPN (ADVPN).

Enterprise Firewall 6.4 Study Guide 457

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide.

By demonstrating competence in the Fortinet ADVPN, you will be able to configure and test ADVPN with IBGP,
as well as use the IKE real-time debug to troubleshoot ADVPN problems.

Enterprise Firewall 6.4 Study Guide 458

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

In this section, you will learn how to deploy and manage ADVPN.

Enterprise Firewall 6.4 Study Guide 459

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Why should you use ADVPN? To find the answer, you will review the most common VPN topologies.

One point-to-multipoint topology variation is called hub-and-spoke. As its name describes, all clients connect
through a central hub, similar to the way spokes connect to hubs on wheels.

In the example shown on this slide, each client—spoke—is a branch-office FortiGate. For any branch office to
reach another branch office, its traffic must pass through the hub.

One advantage of using this topology is that you can easily manage the VPN configuration and firewall policies.
Also, system requirements are minimal for the FortiGate devices that function as branch offices, because each
FortiGate must maintain only one tunnel, or two SAs. In this example, four tunnels, or eight security associations
(SAs), are necessary in the hub.

A disadvantage of using this topology is that communication between branch offices through headquarters (HQ)
is slower than it would be using a direct connection, especially if HQ is physically distant, as it can be for global
companies. For example, if your company’s HQ is in Brazil, and your company also has offices in Japan and
Germany, latency can be significant. Another disadvantage is lack of redundancy. For example, if FortiGate at
HQ fails, the VPN fails company-wide. Also, FortiGate at HQ must be more powerful, because it handles four
tunnels simultaneously, or eight SAs.

Enterprise Firewall 6.4 Study Guide 460

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows a VPN that has a partial mesh topology. There are two types of mesh topologies, partial mesh
and full mesh.

Partial mesh attempts to compromise, minimizing required resources as well as latency. Partial mesh can be
appropriate if communication is not required between every location. This slide shows additional connections
between Spoke-1 and Spoke-2 and, Spoke-3 and Spoke-4 connections. However, each FortiGate’s configuration
is still more complex than hub-and-spoke. Routing, especially, may require extensive planning.

Enterprise Firewall 6.4 Study Guide 461

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows a VPN that has a full mesh topology.

Full mesh connects every location to every other location. Like the previous hub-and-spoke example, the
example on this slide shows only five locations. In order to fully interconnect, each FortiGate needs four VPN
tunnels, or eight SAs, to the other FortiGate devices. This equals three more tunnels for each spoke FortiGate. In
total, 10 tunnels are needed. If your company were to expand to six locations, it would require 15 tunnels. Seven
locations would need 21 tunnels, and so on. You can use the formula N sites = N (N-1) / 2 to calculate
the number of tunnels. This topology causes less latency and requires much less HQ bandwidth than hub-and-
spoke. Its disadvantages? Every spoke FortiGate must be more powerful. Additionally, both administration and
troubleshooting get more complicated.

So, in general, if your company has many locations, hub-and-spoke will be cheaper, but slower, than a mesh
topology. Mesh toplogies place less strain on the central location and can be more fault-tolerant, but are also
more expensive.

Enterprise Firewall 6.4 Study Guide 462

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

ADVPN was introduced in FortiOS 5.4. It combines the benefits of hub-and-spoke and full-mesh topologies
because all the spoke-to-spoke tunnels are dynamically created on demand. After a shortcut tunnel is established
between two spokes and routing has converged, spoke-to-spoke traffic no longer needs to flow through the hub.
ADVPN provides direct connectivity.

Enterprise Firewall 6.4 Study Guide 463

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

• ADVPN supports single or multiple hub architectures

• NAT is supported for the on-demand tunnels
• ADVPN requires the use of a routing protocol. Currently, it supports BGP, OSPF and RIPv2/RIPng. It also
supports PIM and multicast.
• Both IPv4 and IPv6 are supported

Enterprise Firewall 6.4 Study Guide 464

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows an example of how ADVPN works.

An administrator configures IPsec VPNs in multiple FortiGate devices to form VPN hub-and-spoke topologies. In
this example, there are two hubs. Hub 1 has three spokes. Hub 2 has two spokes. There is also a VPN
connecting both hubs.

The dynamic tunnels between spokes are created on demand. Say that a user in Boston sends traffic to London.
Initially, the direct tunnel between Boston and London has not been negotiated. So, the first packets from Boston
to London are routed through Hub 1 and Hub 2. When Hub 1 receives those packets, it knows that ADVPN is
enabled in all the VPNs all the way to London because of auto-discovery-sender enable settings. So,
Hub 1 sends an IKE message to Boston informing it that it can try to negotiate a direct connection to London. On
receipt of this IKE message, Boston creates a FortiOS-specific IKE information message that contains its public
IP address, its local subnet, the desired destination subnet (London's subnet), and an auto-generated PSK
(alternatively can also use digital certificate authentication). This IKE message is sent to London through Hub 1
and Hub 2. When London receives the IKE message from Boston, it stores the PSK and replies with another IKE
information message that contains London's public IP address. After the reply arrives in Boston, the dynamic
tunnel is negotiated between both peers. The negotiation succeeds because London is expecting a connection
attempt from Boston's public IP address. You will explore this in greater detail in the next few slides.

Enterprise Firewall 6.4 Study Guide 465

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Now, you will examine the IKE messages that are exchanged when an on-demand tunnel is being negotiated:
1. The client behind Spoke-1 generates traffic for devices located on Spoke-2’s network.
2. Spoke-1 receives the packet, encrypts it, and sends it to the Hub.
3. The Hub receives the packet from Spoke-1 and forwards it to Spoke-2.
4. Spoke-2 receives the packet, decrypts it, and forwards it to the destination device.
5. The Hub knows that a more direct tunnel option might be available from Spoke-1 to Spoke-2. The Hub sends
a shortcut offer message to Spoke-1.
6. Spoke-1 acknowledges the shortcut offer by sending a shortcut query to the Hub.
7. The Hub forwards the shortcut query message to Spoke-2.
8. Spoke-2 acknowledges the shortcut query and sends a shortcut reply to the Hub.
9. The Hub forwards the shortcut reply to Spoke-1.
10. Spoke-1 and Spoke-2 initiate the tunnel IKE negotiation.

Enterprise Firewall 6.4 Study Guide 466

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

As mentioned earlier, ADVPN requires the use of a dynamic routing protocol. In the next slides, you will learn how
to configure ADVPN with IBGP.

As an example, you will use an IBGP topology made up of one hub with two spokes. All the devices are in the AS
65100.

Enterprise Firewall 6.4 Study Guide 467

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows the following ADVPN configuration in the hub:

• Disable set add-route to ensure that dynamic routing is used for learning the spokes’ protected subnets.
• Set tunnel-search to nexthop, to ensure the next-hop IP of the route matched by a packet is used to
decide into which tunnel the packet must be sent.
• Disable set net-device to ensure FortiGate does not create dynamic interface.
• You must enable set auto-discovery-sender if you want ADVPN. This setting indicates that when
IPsec traffic transits the hub, it should send a shortcut offer to the initiator of the traffic to indicate that it could
perhaps establish a more direct connection (shortcut).
• Assign an overlay IP address to the IPsec virtual interface. This is a requirement for having a dynamic routing
protocol over IPsec.
• The overlay IPs of all hub-and-spoke participants are in the same subnet.
• For the remote-ip, you can use an unused IP from the overlay subnet. You will need to add the appropriate
subnet based on the number of hub and spokes.
• For the phase 2 configuration, ensure that quick modes are set to all (0.0.0.0/0.0.0.0).
• Set a firewall policy to allow the traffic from the spokes to the hub, from the hub to the spokes, and between
spokes through the hub.

Enterprise Firewall 6.4 Study Guide 468

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows the following ADVPN configuration in a spoke:

• Enable ADVPN with the command auto-discovery-receiver. Use this command to indicate that this
IPsec tunnel wants to participate in an autodiscovery VPN (that is, receive a SHORTCUT-OFFER).
• Assign an interface IP, remote IP, and subnet to the IPsec virtual interface.

Enterprise Firewall 6.4 Study Guide 469

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows the following IBGP configuration in the hub:

• Configure a BGP neighbor group. All the spokes are part of it.
• Create a neighbor range with a prefix that includes all the spokes. In this way, you don’t need to define each
spoke individually as a neighbor.
• If you are using IBGP for ADVPN, you must configure the hub as a route reflector. So, routes learned from one
spoke are forwarded to the other spokes.
• Add the local network(s) behind the hub to be advertised over BGP.

Enterprise Firewall 6.4 Study Guide 470

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows the following IBGP configuration in one of the spokes:
• Configure the hub as a BGP neighbor
• Define the internal network that will be advertised over the BGP

Enterprise Firewall 6.4 Study Guide 471

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

If you are configuring ADVPN on FortiManager using the VPN manager, remember the following:
• Set the protected networks to all
• Use scripts to enable ADVPN in phase 1
• Disable the option Add Route on the hub
• Use scripts to enable net-device on spokes
• Configure IP addresses on the IPsec virtual interfaces
• Configure dynamic routing. If you are using IBGP, use a script to enable route reflector on the hub.
• It is important to know that when creating phase-1 using a FortiManager VPN console, the phase-1 name is
created with an underscore and a zero (phase1name_0). For example, a phase-1 named VPN will be created
as VPN_0.

Enterprise Firewall 6.4 Study Guide 472

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

The configuration of the Protected Subnet is under All VPN Communities.

Enterprise Firewall 6.4 Study Guide 473

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

For ADVPN, turn off the Add Route switch under the VPN gateway configuration of the hub.

This prevents the hub from adding routes based on IKE negotiations. For that purpose, ADVPN uses a dynamic
routing protocol instead.

Enterprise Firewall 6.4 Study Guide 474

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

After the tunnels between the hub and the spokes come up, you can run the commands, shown on this slide, on
the spokes to verify that routing updates are taking place:

This slide shows that Spoke-1 learned the routes to the hubs and to the networks of Spoke-2, through BGP.
Spoke-2 is currently accessible through the hub.

Enterprise Firewall 6.4 Study Guide 475

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

You can specify multiple IP addresses when debugging IKE. This is very useful when debugging ADVPN
shortcuts and spoke-to-spoke ADVPN negotiation issues.

Enterprise Firewall 6.4 Study Guide 476

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

If you run the IKE real-time debug during the negotiation of an ADVPN tunnel, you will see the exchange of all
shortcuts. This slide shows an example of the output of the real-time debug . You can see the Spoke-1 receives a
OFFER from the Hub because of the data traffic from Spoke-1 to Spoke-2.

Spoke-1 sends a shortcut-query to Spoke-2 and the Hub receives this shortcut-query and forwards it to
Spoke-2.

Enterprise Firewall 6.4 Study Guide 477

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

In the example shown on this slide, Spoke-2 receives the shortcut-query and sends a shortcut-reply to
Spoke-1.

Hub receives the shortcut-reply and forwards it to Spoke-1.

Enterprise Firewall 6.4 Study Guide 478

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Finally, Spoke-1 receives the reply message and initiates a shortcut negotiation directly with Spoke-2, and the
dynamic tunnel interface is created.

Enterprise Firewall 6.4 Study Guide 479

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Using the get ipsec tunnel list command, you can verify which on-demand tunnels are up. It is important
to note that on-demand tunnels remain active until their SAs are manually flushed, or until they time out.

Enterprise Firewall 6.4 Study Guide 480

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows the routing table after the on-demand tunnel is up.

You can confirm that the network of Spoke-2 is directly accessible using the on-demand tunnel: H2S_0_0.

Enterprise Firewall 6.4 Study Guide 481

 Autodiscovery VPN

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 about ADVPN.

Enterprise Firewall 6.4 Study Guide 482

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Now, you will work on Lab 13–ADVPN.

Enterprise Firewall 6.4 Study Guide 483

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

In this lab, you will run CLI and TCL scripts to configure ADVPN and IBGP on the three FortiGate devices.

Enterprise Firewall 6.4 Study Guide 484

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows your IBGP network, including router IDs and the IP addresses used in the IPsec interfaces.

Enterprise Firewall 6.4 Study Guide 485

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

This slide shows the CLI script that configures the NGFW with ADVPN and IBGP. The first part enables ADVPN.
The second part configures the IP address in the IPsec interface. The last part configures IBGP with route-
reflector-client enabled.

Enterprise Firewall 6.4 Study Guide 486

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Configuration is slightly different from one spoke to another, so you will use TCL to create a single script that can
run on all the spokes, and configure each spoke individually. What changes from one spoke to another is the
router ID, the prefix to advertise, and the IP address in the IPsec interface. The script derives those items from
the spoke hostname.

The first part of the CLI script shown on this slide defines a function that is called each time a CLI command
needs to be run. This simplifies the TCL script.

The second part extracts the hostname from the output of the command get system status.

The third part extracts the spoke number from the hostname. For example, Spoke-1 is the spoke number 1,
Spoke-10 is the spoke number 10, and so on.

Two variables are created:

• $spokenumber is the spoke number. It is used to set the prefix to advertise.
• $spokenumberplusone is the spoke number plus 1. It is used to set the router ID and IPsec interface IP
address.

Enterprise Firewall 6.4 Study Guide 487

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Next, the TCl script enables ADVPN. After that, it configures the IPsec interface IP address: for example,
172.16.1.2 for Spoke-1, 172.16.1.11 for Spoke-10, and so on. It uses the variable
$spokenumberplusone.

Enterprise Firewall 6.4 Study Guide 488

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Finally, the TCL configures BGP. For example, the router ID for Spoke-1 is 172.16.1.2, for Spoke-7 is
172.16.1.8, and so on. The script uses the variable $spokenumberplusone again.

In the case of the BGP prefix, Spoke-1 advertises 10.1.1.0/24, Spoke-5 advertises 10.1.5.0/24, and so on.
The script uses the variable $spokenumber.

Enterprise Firewall 6.4 Study Guide 489

 Autodiscovery VPN

DO NOT REPRINT
© FORTINET

Additionally, you will troubleshoot a routing problem with OSPF and BGP.

Enterprise Firewall 6.4 Study Guide 490

 Solution Slides

DO NOT REPRINT
© FORTINET

These slides contain the solutions to the troubleshooting exercises.

Enterprise Firewall 6.4 Study Guide 491

 Solution Slides

DO NOT REPRINT
© FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the traffic and session monitoring lab.

Enterprise Firewall 6.4 Study Guide 492

 Solution Slides

DO NOT REPRINT
© FORTINET

There were four problems:

• Unable to telnet to ISFW (10.1.10.254)
• Client-10 was unable to access the web server at 10.1.4.10
• No Internet access
• Unable to telnet to Linux-Router (100.64.1.254)

Enterprise Firewall 6.4 Study Guide 493

 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.

Enterprise Firewall 6.4 Study Guide 494

 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

Enterprise Firewall 6.4 Study Guide 495

 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.

Enterprise Firewall 6.4 Study Guide 496

 Solution Slides

DO NOT REPRINT
© FORTINET

For the second problem, the sniffer displayed only incoming SYN packets.

Enterprise Firewall 6.4 Study Guide 497

 Solution Slides

DO NOT REPRINT
© FORTINET

The debug flow showed the same error as with the first problem: iprope_in_check() check failed on
policy 0, drop. However, in this case, the cause was different because this traffic was not intended to
terminate in the FortiGate. As explained in this lesson, the cause might be a wrong VIP or IP pool configuration.

Enterprise Firewall 6.4 Study Guide 498

 Solution Slides

DO NOT REPRINT
© FORTINET

There was actually an IP pool on ISFW with the 10.1.4.0/24 subnet. As the web server's IP address is part of
the IP pool, the FortiGate assumes that it owns this address. So, any traffic destined to 10.1.4.10 terminates in
the FortiGate. The solution was removing the IP pool configuration.

Enterprise Firewall 6.4 Study Guide 499

 Solution Slides

DO NOT REPRINT
© FORTINET

For the third problem, users were unable to access public websites. Attempts to connect to yahoo.com were
failing, however you could still ping 8.8.8.8. This means that Client-10 does have Internet connectivity but it is
having issues resolving domain names. We could confirm this by running a debug flow of the traffic to port 53
(DNS).

Enterprise Firewall 6.4 Study Guide 500

 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.

Enterprise Firewall 6.4 Study Guide 501

 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.

Enterprise Firewall 6.4 Study Guide 502

 Solution Slides

DO NOT REPRINT
© FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the routing lab.

Enterprise Firewall 6.4 Study Guide 503

 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.

Enterprise Firewall 6.4 Study Guide 504

 Solution Slides

DO NOT REPRINT
© FORTINET

The default route configuration was not working as desired. The default route using port2 was inactive.

Enterprise Firewall 6.4 Study Guide 505

 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.

Enterprise Firewall 6.4 Study Guide 506

 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.

Enterprise Firewall 6.4 Study Guide 507

 Solution Slides

DO NOT REPRINT
© FORTINET

Removing the policy-based route fixed the problem.

Enterprise Firewall 6.4 Study Guide 508

 Solution Slides

DO NOT REPRINT
© FORTINET

Now, we will look at the solutions for the troubleshooting exercises in the FortiGuard lab.

Enterprise Firewall 6.4 Study Guide 509

 Solution Slides

DO NOT REPRINT
© FORTINET

The first problem was that DCFW was experiencing issues connecting to FortiManager for license information.
The output of the FortiGuard real time debug showed that DCFW was trying to connect to the wrong IP address.

Enterprise Firewall 6.4 Study Guide 510

 Solution Slides

DO NOT REPRINT
© FORTINET

Correcting the IP address in the central management configuration solved the problem.

Enterprise Firewall 6.4 Study Guide 511

 Solution Slides

DO NOT REPRINT
© FORTINET

The second issue involved web filtering rating on ISFW. The web filtering real time debug showed that ISFW was
not able to find any available FortiGuard servers.

Enterprise Firewall 6.4 Study Guide 512

 Solution Slides

DO NOT REPRINT
© FORTINET

Enterprise Firewall 6.4 Study Guide 513

 Solution Slides

DO NOT REPRINT
© FORTINET

We will see the solutions for the troubleshooting exercise in the OSPF lab.

Enterprise Firewall 6.4 Study Guide 514

 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.

Enterprise Firewall 6.4 Study Guide 515

 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.

Enterprise Firewall 6.4 Study Guide 516

 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.

Enterprise Firewall 6.4 Study Guide 517

 Solution Slides

DO NOT REPRINT
© FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the BGP lab.

Enterprise Firewall 6.4 Study Guide 518

 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.

Enterprise Firewall 6.4 Study Guide 519

 Solution Slides

DO NOT REPRINT
© FORTINET

Changing the remote AS number from 200 to 100 fixes the problem.

Enterprise Firewall 6.4 Study Guide 520

 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.

Enterprise Firewall 6.4 Study Guide 521

 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.

Enterprise Firewall 6.4 Study Guide 522

 Solution Slides

DO NOT REPRINT
© FORTINET

Now, we will look at the solutions for the troubleshooting exercises in the web filtering and antivirus lab.

Enterprise Firewall 6.4 Study Guide 523

 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.

Enterprise Firewall 6.4 Study Guide 524

 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.

Enterprise Firewall 6.4 Study Guide 525

 Solution Slides

DO NOT REPRINT
© FORTINET

Now, we will see the solutions for the troubleshooting exercise in the IPsec lab.

Enterprise Firewall 6.4 Study Guide 526

 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.

Enterprise Firewall 6.4 Study Guide 527

 Solution Slides

DO NOT REPRINT
© FORTINET

The second problem was a mismatch in the pre-shared key.

Enterprise Firewall 6.4 Study Guide 528

 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).

Enterprise Firewall 6.4 Study Guide 529

 Solution Slides

DO NOT REPRINT
© FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the ADVPN lab.

Enterprise Firewall 6.4 Study Guide 530

 Solution Slides

DO NOT REPRINT
© FORTINET

The cause of the routing problem was that the NGFW was not advertising the 10.1.4.0/24 prefix through BGP.

Enterprise Firewall 6.4 Study Guide 531

 Solution Slides

DO NOT REPRINT
© FORTINET

There are different ways to solve the problem. One of them is adding the 10.1.4.0/24 prefix to the BGP
networks configuration. Another solution is redistributing the OSPF routes to BGP.

Enterprise Firewall 6.4 Study Guide 532

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© 2020 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.