FortiOS 6.4.7 Administration Guide
FortiOS 6.4.7 Administration Guide
Version 6.4.7
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com
FORTINET BLOG
https://blog.fortinet.com
NSE INSTITUTE
https://training.fortinet.com
FORTIGUARD CENTER
https://www.fortiguard.com
FEEDBACK
Email: [email protected]
Change Log 17
Getting started 18
Differences between models 18
Using the GUI 18
Connecting using a web browser 18
Menus 19
Tables 20
Entering values 22
Using the CLI 23
Connecting to the CLI 23
CLI basics 26
Command syntax 32
Subcommands 35
Permissions 37
FortiExplorer for iOS 37
Getting started with FortiExplorer 38
Connecting FortiExplorer to a FortiGate via WiFi 41
Running a security rating 42
Upgrading to FortiExplorer Pro 43
Basic administration 43
Basic configuration 44
Registration 46
FortiCare and FortiGate Cloud login 49
Transferring a FortiCloud account title 52
Configuration backups 54
Troubleshooting your installation 58
Zero touch provisioning 60
Zero touch provisioning with FortiDeploy 60
Zero touch provisioning with FortiManager 61
Dashboards and widgets 64
Using dashboards 64
Viewing device dashboards in the security fabric 66
Creating a fabric system and license dashboard 67
Using widgets 69
Changing the default dashboard template 70
Monitor dashboards and widgets 71
Static & Dynamic Routing Monitor 72
DHCP monitor 74
IPsec monitor 75
SSL-VPN monitor 77
Firewall Users Monitor 77
Implement a user device store to centralize device data 78
WiFi Dashboard 79
Device inventory 86
Change Log
2021-09-03 Added Dialup IPsec VPN with certificate authentication on page 1396.
Reorganized Traffic shaping on page 1068 section.
Not all FortiGates have the same features, particularly entry-level models (models 30 to 90). A number of features on
these models are only available in the CLI.
Consult your model's QuickStart Guide, hardware manual, or the Feature / Platform Matrix for
further information about features that vary by model.
FortiGate models differ principally by the names used and the features available:
l Naming conventions may vary between FortiGate models. For example, on some models the hardware switch
interface used for the local area network is called lan, while on other units it is called internal.
l Certain features are not available on all models. Additionally, a particular feature may be available only through the
CLI on some models, while that same feature may be viewed in the GUI on other models.
If you believe your FortiGate model supports a feature that does not appear in the GUI, go to System > Feature
Visibility and confirm that the feature is enabled. For more information, see Feature visibility on page 925.
This section presents an introduction to the graphical user interface (GUI) on your FortiGate.
The following topics are included in this section:
l Connecting using a web browser
l Menus
l Tables
l Entering values
For information about using the dashboards, see Dashboards and widgets on page 64.
In order to connect to the GUI using a web browser, an interface must be configured to allow administrative access over
HTTPS or over both HTTPS and HTTP. By default, an interface has already been set up that allows HTTPS access with
the IP address 192.168.1.99.
Browse to https://192.168.1.99 and enter your username and password. If you have not changed the admin account’s
password, use the default user name, admin, and leave the password field blank.
The GUI will now display in your browser, and you will be required to provide a password for the administrator account.
1. Go to Network > Interfaces and edit the interface you wish to use for access. Take note of its assigned IP address.
2. In Administrative Access, select HTTPS, and any other protocol you require. You can also select HTTP, although
this is not recommended as the connection will be less secure.
3. Click OK.
4. Browse to the IP address using your chosen protocol.
The GUI will now be displayed in your browser.
Menus
If you believe your FortiGate model supports a menu that does not appear in the GUI, go to
System > Feature Visibility and ensure the feature is enabled. For more information, see
Feature visibility on page 925.
The GUI contains the following main menus, which provide access to configuration options for most FortiOS features:
Dashboard The dashboard displays various widgets that display important system
information and allow you to configure some system options.
For more information, see Dashboards and widgets on page 64.
Security Fabric Access the physical topology, logical topology, automation, and settings of the
Fortinet Security Fabric.
For more information, see Fortinet Security Fabric on page 129.
Network Options for networking, including configuring system interfaces and routing
options.
For more information, see Network on page 385.
Policy & Objects Configure firewall policies, protocol options, and supporting content for policies,
including schedules, firewall addresses, and traffic shapers.
For more information, see Policy and Objects on page 945.
Security Profiles Configure your FortiGate's security features, including Antivirus, Web Filter, and
Application Control.
For more information, see Security Profiles on page 1102.
VPN Configure options for IPsec and SSL virtual private networks (VPNs).
For more information, see IPsec VPNs on page 1276 and SSL VPN on page
1547.
User & Authentication Configure user accounts, groups, and authentication methods, including external
authentication and single sign-on (SSO).
WiFi & Switch Controller Configure the unit to act as a wireless network controller, managing the wireless
Access Point (AP) functionality of FortiWiFi and FortiAP units.
On certain FortiGate models, this menu has additional features allowing for
FortiSwitch units to be managed by the FortiGate.
For more information, see Wireless configuration on page 1747 and Switch
Controller on page 1748.
Tables
Many GUI pages contain tables of information that can be filtered and customized to display specific information in a
specific way. Some tables allow content to be edited directly on that table, or rows to be copied and pasted.
Navigation
Some tables contain information and lists that span multiple pages. Navigation controls will be available at the bottom of
the page.
Filters
Filters are used to locate a specific set of information or content in a table. They can be particularly useful for locating
specific log entries. The filtering options vary, depending on the type of information in the log.
Depending on the table content, filters can be applied using the filter bar, using a column filter, or based on a cell's
content. Some tables allow filtering based on regular expressions.
Administrators with read and write access can define filters. Multiple filters can be applied at one time.
1. Click Add Filter at the top of the table. A list of the fields available for filtering is shown.
2. Select the field to filter by.
3. Enter the value to filter by, adding modifiers as needed.
4. Press Enter to apply the filter.
1. Click the filter icon on the right side of the column header
2. Choose a filter type from the available options.
3. Enter the filter text, or select from the available values.
4. Click Apply.
Column settings
1. Right a column header, or click the gear icon on the left side of the header row that appears when hovering the
cursor over the headers.
2. Select columns to add or remove.
3. Click Apply.
To resize a column:
1. Click the dots or filter icon on the right side of the column header and select Resize to Contents.
1. Right a column header, or click the gear icon on the left side of the header row that appears when hovering the
cursor over the headers.
2. Click Best Fit All Columns.
1. Right a column header, or click the gear icon on the left side of the header row that appears when hovering the
cursor over the headers.
2. Click Reset Table.
Resetting a table does not remove filters.
Editing objects
In some tables, parts of a configuration can be edited directly in the table. For example, security profiles can be added to
an existing firewall policy by clicking the edit icon in a cell in the Security Profiles column.
Copying rows
In some tables, rows can be copied and pasted using the right-click menu. For example, a policy can be duplicated by
copying and pasting it.
Entering values
Numerous fields in the GUI and CLI require text strings or numbers to be entered when configuring the FortiGate. When
entering values in the GUI, you will be prevented from entering invalid characters, and a warning message will be shown
explaining what values are not allowed. If invalid values are entered in a CLI command, the setting will be rejected when
you apply it.
l Text strings on page 22
l Numbers on page 23
Text strings
Text strings are used to name entities in the FortiGate configuration. For example, the name of a firewall address,
administrator, or interface are all text strings.
The following characters cannot be used in text strings, as they present cross-site scripting (XSS) vulnerabilities:
l “ - double quotes
l ' - single quote
l > - greater than
l < - less than
Most GUI text fields prevent XSS vulnerable characters from being added.
VDOM names and hostnames can only use numbers (0-9), letters (a-z and A-Z), dashes, and
underscores.
The tree CLI command can be used to view the number of characters allowed in a name field. For example, entering
the following commands show that a firewall address name can contain up to 80 characters, while its FQDN can contain
256 characters:
config fire address
(address) # tree
-- [address] --*name (80)
|- uuid
|- subnet
|- type
|- start-mac
|- end-mac
|- start-ip
|- end-ip
|- fqdn (256)
|- country (3)
|- wildcard-fqdn (256)
|- cache-ttl (0,86400)
|- wildcard
|- sdn (36)
|- interface (36)
|- tenant (36)
|- organization (36)
|- epg-name (256)
|- subnet-name (256)
|- sdn-tag (16)
|- policy-group (16)
|- comment
|- visibility
|- associated-interface (36)
|- color (0,32)
|- filter
|- sdn-addr-type
|- obj-id
|- [list] --*ip (36)
|- obj-id (128)
+- net-id (128)
|- [tagging] --*name (64)
|- category (64)
+- [tags] --*name (80)
+- allow-routing
Numbers
Numbers are used to set sizes, rated, addresses, port numbers, priorities, and other such numeric values. They can be
entered as a series of digits (without commas or spaces), in a dotted decimal format (such as IP addresses), or
separated by colons (such as MAC addresses). Most numeric values use base 10 numbers, while some use
hexadecimal values.
Most GUI and CLI fields prevent invalid numbers from being entered. The CLI help text includes information about the
range of values allowed for applicable settings.
The Command Line Interface (CLI) can be used in lieu of the GUI to configure the FortiGate. Some settings are not
available in the GUI, and can only be accessed using the CLI.
This section briefly explains basic CLI usage. For more information about the CLI, see the FortiOS CLI Reference.
l Connecting to the CLI on page 23
l CLI basics on page 26
l Command syntax on page 32
l Subcommands on page 35
l Permissions on page 37
You can connect to the CLI using a direct console connection, SSH, the FortiExplorer app on your iOS device, or the CLI
console in the GUI.
You can access the CLI outside of the GUI in three ways:
l Console connection: Connect your computer directly to the console port of your FortiGate.
l SSH access: Connect your computer through any network interface attached to one of the network ports on your
FortiGate.
l FortiExplorer: Connect your device to the FortiExplorer app on your iOS device to configure, manage, and monitor
your FortiGate. See FortiExplorer for iOS on page 37 for details.
To open a CLI console, click the _> icon in the top right corner of the GUI. The console opens on top of the GUI. It can be
minimized and multiple consoles can be opened.
To edit policies and objects directly in the CLI, right-click on the element and select Edit in CLI.
Console connection
A direct console connection to the CLI is created by directly connecting your management computer or console to the
FortiGate using its DB-9 or RJ-45 console port.
Direct console access to the FortiGate may be required if:
l You are installing the FortiGate for the first time and it is not configured to connect to your network.
l You are restoring the firmware using a boot interrupt. Network access to the CLI will not be available until after the
boot process has completed, making direct console access the only option.
To connect to the FortiGate console, you need:
l A console cable to connect the console port on the FortiGate to a communications port on the computer. Depending
on your device, this is one of:
l null modem cable (DB-9 to DB-9)
1. Using the console cable, connect the FortiGate unit’s console port to the serial communications (COM) port on your
management computer.
2. Start a terminal emulation program on the management computer, select the COM port, and use the following
settings:
Data bits 8
Parity None
Stop bits 1
SSH access
SSH access to the CLI is accomplished by connecting your computer to the FortiGate using one of its network ports. You
can either connect directly, using a peer connection between the two, or through any intermediary network.
If you do not want to use an SSH client and you have access to the GUI, you can access the
CLI through the network using the CLI console in the GUI.
SSH must be enabled on the network interface that is associated with the physical network port that is used.
If your computer is not connected either directly or through a switch to the FortiGate, you must also configure the
FortiGate with a static route to a router that can forward packets from the FortiGate to the computer. This can be done
using a local console connection, or in the GUI.
To connect to the FortiGate CLI using SSH, you need:
l A computer with an available serial communications (COM) port and RJ-45 port
l An appropriate console cable
l Terminal emulation software
l A network cable
l Prior configuration of the operating mode, network interface, and static route.
1. Using the network cable, connect the FortiGate unit’s port either directly to your computer’s network port, or to a
network through which your computer can reach the FortiGate.
2. Note the number of the physical network port.
3. Using direct console connection, connect and log into the CLI.
4. Enter the following command:
config system interface
edit <interface_str>
append allowaccess ssh
next
end
Where <interface_str> is the name of the network interface associated with the physical network port, such as
port1.
5. Confirm the configuration using the following command to show the interface’s settings:
show system interface <interface_str>
For example:
show system interface port1
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
set allowaccess ping https ssh
set type hard-switch
set stp enable
set role lan
set snmp-index 6
next
end
Once the FortiGate is configured to accept SSH connections, use an SSH client on your management computer to
connect to the CLI.
The following instructions use PuTTy. The steps may vary in other terminal emulators.
If three incorrect log in or password attempts occur in a row, you will be disconnected. If this
occurs, wait for one minute, then reconnect and attempt to log in again.
CLI basics
Basic features and characteristics of the CLI environment provide support and ease of use for many CLI tasks.
Help
Press the question mark (?) key to display command help and complete commands.
l Press the question mark (?) key at the command prompt to display a list of the commands available and a
description of each command.
l Enter a command followed by a space and press the question mark (?) key to display a list of the options available
for that command and a description of each option.
l Enter a command followed by an option and press the question mark (?) key to display a list of additional options
available for that command option combination and a description of each option.
l Enter a question mark after entering a portion of a command to see a list of valid complete commands and their
descriptions. If there is only one valid command, it will be automatically filled in.
Left or Right arrow Move the cursor left or right within the command line.
Ctrl + C Abort current interactive commands, such as when entering multiple lines.
If you are not currently within an interactive command such as config or edit,
this closes the CLI connection.
\ then Enter Continue typing a command on the next line for a multiline command.
For each line that you want to continue, terminate it with a backslash ( \ ). To
complete the command, enter a space instead of a backslash, and then press
Enter.
Command tree
Enter tree to display the CLI command tree. To capture the full output, connect to your device using a terminal
emulation program and capture the output to a log file. For some commands, use the tree command to view all
available variables and subcommands.
Command abbreviation
You can abbreviate words in the command line to their smallest number of non-ambiguous characters.
For example, the command get system status could be abbreviated to g sy stat.
When configuring a list, the set command will remove the previous configuration.
For example, if a user group currently includes members A, B, and C, the command set member D will remove
members A, B, and C. To avoid removing the existing members from the group, the command set members A B C D
must be used.
To avoid this issue, the following commands are available:
Environment variables
The following environment variables are support by the CLI. Variable names are case-sensitive.
$USERFROM The management access type (ssh, jsconsole, and so on) and the IPv4 address of the
administrator that configured the item.
$USERNAME The account name of the administrator that configured the item.
For example, to set a FortiGate device's host name to its serial number, use the following CLI command:
config system global
set hostname $SerialNum
end
Special characters
The following characters cannot be used in most CLI commands: <, >, (, ), #, ', and "
If one of those characters, or a space, needs to be entered as part of a string, it can be entered by using a special
command, enclosing the entire string in quotes, or preceding it with an escape character (backslash, \).
To enter a question mark (?) or a tab, Ctrl + V or Ctrl + Shift + - must be entered first.
Question marks and tabs cannot be copied into the CLI Console or some SSH clients. They
must be typed in.
Character Keys
Character Keys
' \'
(as part of a string value, not to begin or end
the string)
" \"
(as part of a string value, not to begin or end
the string)
\ \\
The get, show, and diagnose commands can produce large amounts of output. The grep command can be used to
filter the output so that it only shows the required information.
The grep command is based on the standard UNIX grep, used for searching text output based on regular expressions.
For example, the following command displays the MAC address of the internal interface:
get hardware nic internal | grep Current_HWaddr
Current_HWaddr 00:09:0f:cb:c2:75
The following command will display all TCP sessions that are in the session list, including the session list line number in
the output:
get system session list | grep -n tcp
The following command will display all of the lines in the HTTP replacement message that contain URL or url:
show system replacemsg http | grep -i url
The -f option is available to support contextual output, in order to show the complete configuration. The following
example shows the difference in the output when -f is used versus when it is not used:
edit 2
set srcintf "port31"
set dstintf "port32"
set srcaddr "all"
set action accept
set identity-based enable
set nat enable
config identity-based-policy
edit 1
set schedule "always"
set groups "ldap-group1"
set dstaddr "all"
set service "ALL"
next
end
next
end
Characters such as ñ and é, symbols, and ideographs are sometimes acceptable input. Support varies depending on the
type of item that is being configured. CLI commands, objects, field names, and options must use their exact ASCII
characters, but some items with arbitrary names or values can be input using your language of choice. To use other
languages in those cases, the correct encoding must be used.
Input is stored using Unicode UTF-8 encoding, but is not normalized from other encodings into UTF-8 before it is stored.
If your input method encodes some characters differently than in UTF-8, configured items may not display or operate as
expected.
Regular expressions are especially impacted. Matching uses the UTF-8 character values. If you enter a regular
expression using a different encoding, or if an HTTP client sends a request in a different encoding, matches may not be
what is expected.
For example, with Shift-JIS, backslashes could be inadvertently interpreted as the symbol for the Japanese yen ( ¥ ), and
vice versa. A regular expression intended to match HTTP requests containing monetary values with a yen symbol may
not work it if the symbol is entered using the wrong encoding.
For best results:
l use UTF-8 encoding, or
l use only characters whose numerically encoded values are the same in UTF-8, such as the US-ASCII characters
that are encoded using the same values in ISO 8859-1, Windows code page 1252, Shift-JIS, and other encoding
methods, or
l for regular expressions that must match HTTP requests, use the same encoding as your HTTP clients.
HTTP clients may send requests in encodings other than UTF-8. Encodings usually vary
based on the client’s operating system or input language. If the client's encoding method
cannot be predicted, you might only be able to match the parts of the request that are in
English, as the values for English characters tend to be encoded identically, regardless of the
encoding method.
If the FortiGate is configured to use an encoding method other than UTF-8, the management computer's language may
need to be changed, including the web browse and terminal emulator. If the FortiGate is configured using non-ASCII
characters, all the systems that interact with the FortiGate must also support the same encoding method. If possible, the
same encoding method should be used throughout the configuration to avoid needing to change the language settings
on the management computer.
The GUI and CLI client normally interpret output as encoded using UTF-8. If they do not, configured items may not
display correctly. Exceptions include items such as regular expression that may be configured using other encodings to
match the encoding of HTTP requests that the FortiGate receives.
Screen paging
By default, the CLI will pause after displaying each page worth of text when a command has multiple pages of output.
this can be useful when viewing lengthy outputs that might exceed the buffer of terminal emulator.
When the display pauses and shows --More--, you can:
l Press Enter to show the next line,
l Press Q to stop showing results and return to the command prompt,
l Press an arrow key, Insert, Home, Delete, End, Page Up, or Page Down to show the next few pages,
l Press any other key to show the next page, or
l Wait for about 30 seconds for the console to truncate the output and return to the command prompt.
When pausing the screen is disabled, press Ctrl + C to stop the output and log out of the FortiGate.
The baud rate of the local console connection can be changed from its default value of 9600.
The FortiGate configuration file can be edited on an external host by backing up the configuration, editing the
configuration file, and then restoring the configuration to the FortiGate.
Editing the configuration file can save time is many changes need to be made, particularly if the plain text editor that you
are using provides features such as batch changes.
4. Restore the modified configuration to the FortiGate. See Configuration backups on page 54 for details.
The FortiGate downloads the configuration file and checks that the model information is correct. If it is correct, the
configuration file is loaded and each line is checked for errors. If a command is invalid, that command is ignored. If
the configuration file is valid, the FortiGate restarts and loads the downloaded configuration.
Command syntax
When entering a command, the CLI console requires that you use valid syntax and conform to expected input
constraints. It rejects invalid commands. Indentation is used to indicate the levels of nested commands.
Each command line consists of a command word, usually followed by configuration data or a specific item that the
command uses or affects.
Notation
Brackets, vertical bars, and spaces are used to denote valid syntax. Constraint notations, such as <address_ipv4>,
indicate which data types or string patterns are acceptable value input.
All syntax uses the following conventions:
Angle brackets < > Indicate a variable of the specified data type.
Square brackets [ ] Indicate that the variable or variables are optional.
For example:
show system interface [<name_str>]
To show the settings for all interfaces, you can enter show system interface
To show the settings for the Port1 interface, you can enter show system interface
port1.
Any field that is optional will use square-brackets. The overall config command will still be valid whether or not the option
is configured.
Square-brackets can be used is to show that multiple options can be set, even intermixed with ranges. The following
example shows a field that can be set to either a specific value or range, or multiple instances:
config firewall service custom
set iprange <range1> [<range2> <range3> ...]
end
next
The next command is used to maintain a hierarchy and flow to CLI commands. It is at the same indentation level as the
preceding edit command, to mark where a table entry finishes.
The following example shows the next command used in the subcommand entries:
After configuring table entry <2> then entering next, the <2> table entry is saved and the console returns to the
entries prompt:
You can now create more table entries as needed, or enter end to save the table and return to the filepattern table
element prompt.
end
The end command is used to maintain a hierarchy and flow to CLI commands.
The following example shows the same command and subcommand as the next command example, except end has
been entered instead of next after the subcommand:
Entering end will save the <2> table entry and the table, and exit the entries subcommand entirely. The console
returns to the filepattern table element prompt:
Subcommands
Subcommands are available from within the scope of some commands. When you enter a subcommand level, the
command prompt changes to indicate the name of the current command scope. For example, after entering:
config system admin
Applicable subcommands are available until you exit the command, or descend an additional level into another
subcommand. Subcommand scope is indicated by indentation.
For example, the edit subcommand is only available in commands that affects tables, and the next subcommand is
available only in the edit subcommand:
config system interface
edit port1
set status up
next
end
The available subcommands vary by command. From a command prompt under the config command, subcommands
that affect tables and fields could be available.
Table subcommands
show Show the configuration. Only table entries that are not set to default values are
shown.
end Save the configuration and exit the current config command.
Purging the system interface or system admin tables does not reset default table
values. This can result in being unable to connect to or log in to the FortiGate, requiring the
FortiGate to be formatted and restored.
Field subcommands
For example, the command set fsso enable sets the fsso field to the value
enable.
get List the configuration of the current table entry, including default and customized
values.
show Show the configuration. Only values that are not set to default values are shown.
next Save changes to the table entry and exit the edit command so that you can
configure the next table entry.
end Save the configuration and exit the current config command.
Permissions
Administrator (or access) profiles control what CLI commands an administrator can access by assigning read, write, or
no access to each area of FortiOS. For information, see Administrator profiles on page 786.
Read access is required to view configurations. Write access is required to make configuration changes. Depending on
your account's profile, you may not have access to all CLI commands. To have access to all CLI commands, an
administrator account with the super_admin profile must be used, such as the admin account.
Accounts assigned the super_admin profile are similar to the root administrator account. They have full permission to
view and change all FortiGate configuration options, including viewing and changing other administrator accounts.
To increase account security, set strong passwords for all administrator accounts, and change the passwords regularly.
FortiExplorer for iOS is a user-friendly application that helps you to rapidly provision, deploy, and monitor Security Fabric
components from your iOS device.
FortiExplorer for iOS requires iOS 10.0 or later and is compatible with iPhone, iPad, and Apple TV. It is supported by
FortiOS 5.6 and later, and is only available on the App Store for iOS devices.
Advanced features are available with the purchase of FortiExplorer Pro. Paid features include the ability to add more
than two devices, and firmware upgrades for devices with active licenses.
Up to six members can use this app with 'Family Sharing' enabled in the App Store.
Firmware upload requires a valid firmware license. Users can download firmware for models
with a valid support contract.
If your FortiGate is accessible on a wireless network, you can connect to it using FortiExplorer provided that your
iOS device is on the same network (see Connecting FortiExplorer to a FortiGate via WiFi). Otherwise, you will need to
physically connect your iOS device to the FortiGate using a USB cable.
1. Connect your iOS device to your FortiGate USB A port. If prompted on your iOS device, Trust this computer.
2. Open FortiExplorer and select your FortiGate from the FortiGate Devices list . A blue USB icon will indicate that you
are connected over a USB connection.
9. Optionally, configure Administrative Access to allow HTTPS access. This will allow administrators to access the
FortiGate GUI using a web browser.
10. Go to Network > Interfaces and configure the local network (internal) interface.
11. Set the Address mode as before and configure Administrative Access if required.
12. Configure a DHCP Server for the internal network subnet.
13. Return to the internal interface using the < button at the top of the screen.
14. Go to Network > Static Routes and configure the static route to the gateway.
15. Go to Policy & Objects > Firewall Policy and edit the Internet access policy. Enter a Name for the policy, enable the
required Security Profiles, configure Logging Options, then tap OK.
You can wirelessly connect to the FortiGate if your iOS device and the FortiGate are both connected to the same
wireless network.
1. Open the FortiExplorer app and tap Add on the Devices page.
2. On the Add Device By page, tap HTTPS.
5. Tap Done.
6. If the FortiGate device identity cannot be verified, tap Connect at the prompt.
FortiExplorer opens the FortiGate management interface to the Device Status page.
After configuring your network, run a security rating check to identify vulnerabilities and highlight best practices that
could improve your network's security and performance.
Go to Security Fabric > Security Rating and follow the steps to determine the score. See Security rating on page 220 for
more information.
FortiExplorer Pro allows you to add unlimited devices, and download firmware images for devices with active licenses.
1. In FortiExplorer, go to Settings.
2. Tap Manage Subscription.
3. Follow the on-screen prompts.
Basic administration
This section contains information about basic FortiGate administration that you can do after you installing the unit in your
network.
l Basic configuration on page 44
l Registration on page 46
l FortiCare and FortiGate Cloud login on page 49
Basic configuration
This topic will help you configure a few basic settings on the FortiGate as described in the Using the GUI on page 18 and
Using the CLI on page 23 sections, including:
l Configuring an interface to be part of your existing network for further configuration
l Configuring the hostname
l Configuring the default route
l Ensuring internet/FortiGuard connectivity
Configuring an interface
It is unlikely the default interface configuration will be appropriate for your environment and typically requires some effort
of the administrator to use these settings, such as being physically near the FortiGate to establish a serial connection.
Therefore, the first step is to configure an interface that can be used to complete the FortiGate configuration.
Setting the FortiGate’s hostname assists with identifying the device, and it is especially useful when managing multiple
FortiGates. Choose a meaningful hostname as it is used in the CLI console, SNMP system name, device name for
FortiGate Cloud, and to identify a member of an HA cluster.
1. Go to System > Settings.
2. Enter a name in the Host name field.
3. Click Apply.
Setting the default route enables basic routing to allow the FortiGate to return traffic to sources that are not directly
connected. The gateway address should be your existing router or L3 switch that the FortiGate is connected to. If you are
directly connecting to the FortiGate, you may choose your endpoint’s IP address as the gateway address. Set the
interface to be the interface the gateway is connected to.
This step is not necessary for the configuration; however, it is necessary in order to keep your FortiGate up to date
against the latest threats. Updates are provided to FortiGates that are registered and make a request to the FortiGuard
network to verify if there are any more recent definitions.
Use execute ping <domain.tld> to ensure the DNS resolution is able to resolve the following FortiGuard servers:
l fds1.fortinet.com
l service.fortiguard.net
l update.fortiguard.net
You also need to ensure the necessary ports are permitted outbound in the event your FortiGate is behind a filtering
device. Refer to the Ports and Protocols document for more information.
Registration
The FortiGate, and then its service contract, must be registered to have full access to Fortinet Customer Service and
Support, and FortiGuard services. The FortiGate can be registered in either the FortiGate GUI or the FortiCloud support
portal. The service contract can be registered from the FortiCloud support portal.
The service contract number is needed to complete registrations on the FortiCloud support
portal. You can find this 12-digit number in the email that contains your service registration
document (sent from [email protected]) in the service entitlement summary.
1. Connect to the FortiGate GUI. A dialog box appears, which indicates the steps you should take to complete the
setup of your FortiGate. These steps include:
a. Specify Hostname
b. Change Your Password
c. Upgrade Firmware
d. Dashboard Setup
If you completed the Basic configuration on page 44, the hostname and password steps are already marked as
complete (checkmark). If you chose to deploy the latest firmware, the Upgrade Firmware step is marked as
complete.
2. Click Begin to complete the dashboard setup. Two options appear (Optimal and Comprehensive).
3. Select the desired setting and click OK. The System > FortiGuard page opens.
4. Click Enter Registration Code.
5. Enter the contract registration code from your service registration document.
6. Click OK.
1. Go to support.fortinet.com and log in using your FortiCloud account credentials. If you do not have an account, click
Register to create one.
2. In the left-side menu, click Register Product.
3. Enter the product serial number or license certificate number for a VM, select an end user type, then click Next.
4. Enter the Support Contract number and FortiCloud Key (optionally, enter a product description), then click Next.
5. Review the product entitlement information, select the checkbox to accept the terms, then click Confirm.
6. Go to Products > Product List. The FortiGate is now visible in the product list.
With FortiCloud, FortiGate supports a unified login to FortiCare and FortiGate Cloud. The FortiGate Cloud setup is a
subset of the FortiCare setup.
l If the FortiGate is not registered, activating FortiGate Cloud will force you to register with FortiCare.
l If a FortiGate is registered in FortiCare using a FortiCloud account, then only that FortiCloud account can be used to
activate FortiGate Cloud.
l If a different FortiCloud account was already used to activate FortiGate Cloud, then a notification asking you to
migrate to FortiCloud is shown in the GUI after upgrading FortiOS.
The CLI can be used to activate FortiGate Cloud without registration, or with a different FortiCloud account.
To activate FortiGate Cloud and register with FortiCare at the same time:
3. Enter the password for the account that was used to register the FortiGate.
4. Click OK.
The FortiGate Cloud widget now shows the FortiCloud account.
To migrate from the activated FortiGate Cloud account to the registered FortiCloud account:
3. Enter the password for the account that was used to register the FortiGate, then click OK.
The FortiGate Cloud widget now shows the FortiCloud account.
To activate FortiGate Cloud using an account that is not used for registration:
Where the <account_id> and <password> are the credentials for the account that you are using to activate
FortiGate Cloud.
2. Check the account type with following command:
# diagnose fdsm contract-controller-update
Protocol=2.0|Response=202|Firmware=FAZ-4K-FW-2.50-
100|SerialNumber=FAMS000000000000|Persistent=false|ResponseItem=HomeServer:172.16.95.151
:443*AlterServer:172.16.95.151:443*Contract:20200408*NextRequest:86400*UploadConfig:Fals
e*ManagementMode:Local*ManagementID:737941253*AccountType:multitenancy
Result=Success
A FortiCloud account that is not used for the support portal account cannot be used to register
FortiGate. Attempting to activate FortiGate Cloud with this type of account will fail.
Master account users can transfer a FortiCloud and FortiCare account from one device to another. Users can transfer up
to three accounts within a twelve-month time period.
Requirements:
You can transfer up to three accounts in a twelve-month time period. If more transfers are
required within the twelve-month time period, contact Technical Support to request the
transfer.
1. Go to Dashboard > Status. In the Status dashboard, hover over the FortiCare Support link, and click Transfer
FortiGate to Another Account.
2. In the Current FortiCloud Account fields, enter the username and password for the current account. In the Target
FortiCloud Account fields, enter the new username and password. Click Next.
After the transfer is complete, FortiGate displays the new the FortiCloud account.
Configuration backups
Once you successfully configure the FortiGate, it is extremely important that you backup the configuration. In some
cases, you may need to reset the FortiGate to factory defaults or perform a TFTP upload of the firmware, which will erase
the existing configuration. In these instances, the configuration on the device will have to be recreated, unless a backup
can be used to restore it. You should also backup the local certificates, as the unique SSL inspection CA and server
certificates that are generated by your FortiGate by default are not saved in a system backup.
We also recommend that you backup the configuration after any changes are made, to ensure you have the most current
configuration available. Also, backup the configuration before any upgrades of the FortiGate’s firmware. Should anything
happen to the configuration during the upgrade, you can easily restore the saved configuration.
Always backup the configuration and store it on the management computer or off-site. You have the option to save the
configuration file to various locations including the local PC, USB key, FTP, and TFTP server. The last two are
configurable through the CLI only.
If you have VDOMs, you can back up the configuration of the entire FortiGate or only a specific VDOM. Note that if you
are using FortiManager or FortiGate Cloud, full backups are performed and the option to backup individual VDOMs will
not appear.
You can also backup and restore your configuration using Secure File Copy (SCP). See How
to download/upload a FortiGate configuration file using secure file copy (SCP).
You enable SCP support using the following command:
config system global
set admin-scp enable
end
For more information about this command and about SCP support, see config system global.
1. Click on the user name in the upper right-hand corner of the screen and select Configuration > Backup.
2. Direct the backup to your Local PC or to a USB Disk.
The USB Disk option will not be available if no USB drive is inserted in the USB port. You can also backup to the
FortiManager using the CLI.
3. If VDOMs are enabled, indicate whether the scope of the backup is the entire FortiGate configuration (Global) or
only a specific VDOM configuration (VDOM).
If backing up a VDOM configuration, select the VDOM name from the list.
4. Enable Encryption. Encryption must be enabled on the backup file to back up VPN certificates.
5. Enter a password, and enter it again to confirm it. This password will be required to restore the configuration.
6. Click OK.
7. When prompted, select a location on the PC or USB disk to save the configuration file. The configuration file will
have a .conf extension.
or:
execute backup config usb <backup_filename> [<backup_password>]
or for FTP, note that port number, username are optional depending on the FTP site:
execute backup config ftp <backup_filename> <ftp_server> [<port>] [<user_name>]
[<password>]
or for TFTP:
execute backup config tftp <backup_filename> <tftp_servers> <password>
Use the same commands to backup a VDOM configuration by first entering the commands:
config vdom
edit <vdom_name>
Restoring a configuration
1. Click on the user name in the upper right-hand corner of the screen and select Configuration > Restore.
2. Identify the source of the configuration file to be restored: your Local PC or a USB Disk.
The USB Disk option will not be available if no USB drive is inserted in the USB port. You can restore from the
FortiManager using the CLI.
3. Click Upload, locate the configuration file, and click Open.
4. Enter the password if required.
5. Click OK.
or:
execute restore config usb <filename> [<password>]
or for FTP, note that port number, username are optional depending on the FTP site:
execute restore config ftp <backup_filename> <ftp_server> [<port>] [<user_name>]
[<password>]
or for TFTP:
execute restore config tftp <backup_filename> <tftp_server> <password>
The FortiGate will load the configuration file and restart. Once the restart has completed, verify that the configuration has
been restored.
Troubleshooting
When restoring a configuration, errors may occur, but the solutions are usually straightforward.
Configuration file error This error occurs when attempting to upload a configuration file that is
incompatible with the device. This may be due to the configuration file being for a
different model or being saved from a different version of firmware.
Solution: Upload a configuration file that is for the correct model of FortiGate
device and the correct version of the firmware.
Invalid password When the configuration file is saved, it can be protected by a password. The
password entered during the upload process is not matching the one associated
with the configuration file.
Solution: Use the correct password if the file is password protected.
Configuration revision
You can manage multiple versions of configuration files on models that have a 512MB flash memory and higher.
Revision control requires either a configured central management server or the local hard drive, if your FortiGate has this
feature. Typically, configuration backup to local drive is not available on lower-end models.
The central management server can either be a FortiManager unit or FortiGate Cloud.
If central management is not configured on your FortiGate unit, a message appears instructing you to either
l Enable central management, or
l Obtain a valid license.
When revision control is enabled on your FortiGate unit, and configuration backups have been made, a list of saved
revisions of those backed-up configurations appears.
Configuration revisions are viewed by clicking on the user name in the upper right-hand corner of the screen and
selecting Configuration > Revisions.
This procedure exports a server (local) certificate and private key together as a password protected PKCS12 file. The
export file is created through a customer-supplied TFTP server. Ensure that your TFTP server is running and accessible
to the FortiGate before you enter the command.
where:
l <cert_name> is the name of the server certificate.
l <filename> is a name for the output file.
l <tftp_ip> is the IP address assigned to the TFTP server host interface.
1. Move the output file from the TFTP server location to the management computer.
2. Go to System > Certificates and click Import > Local.
3. Select the certificate type, then click Upload in the Certificate file field.
4. On the management computer, browse to the file location, select it, and click Open.
5. If the Type is Certificate, upload the Key file as well.
6. If required, enter the Password that is required to upload the file or files.
7. Click OK.
There may be a need to reset the FortiGate to its original defaults; for example, to begin with a fresh configuration. There
are two options when restoring factory defaults. The first resets the entire device to the original out-of-the-box
configuration.
You can reset the device with the following CLI command:
execute factoryreset
If your FortiGate does not function as desired after installation, try the following troubleshooting tips:
1. Check for equipment issues
Verify that all network equipment is powered on and operating as expected. Refer to the QuickStart Guide for
information about connecting your FortiGate to the network.
2. Check the physical network connections
Check the cables used for all physical connections to ensure that they are fully connected and do not appear
damaged, and make sure that each cable connects to the correct device and the correct Ethernet port on that
device.
3. Verify that you can connect to the internal IP address of the FortiGate
Connect to the GUI from the FortiGate’s internal interface by browsing to its IP address. From the PC, try to ping the
internal interface IP address; for example, ping 192.168.1.99. If you cannot connect to the internal interface,
verify the IP configuration of the PC. If you can ping the interface but can't connect to the GUI, check the settings for
administrative access on that interface. Alternatively, use SSH to connect to the CLI, and then confirm that HTTPS
has been enabled for Administrative Access on the interface.
4. Check the FortiGate interface configurations
Check the configuration of the FortiGate interface connected to the internal network (under Network > Interfaces)
and check that Addressing mode is set to the correct mode.
5. Verify the security policy configuration
Go to Policy & Objects > Firewall Policy and verify that the internal interface to Internet-facing interface security
policy has been added and is located near the top of the policy list. Check the Active Sessions column to ensure that
traffic has been processed (if this column does not appear, right-click on the table header and select Active
Sessions). If you are using NAT mode, check the configuration of the policy to make sure that NAT is enabled and
that Use Outgoing Interface Address is selected.
6. Verify the static routing configuration
Go to Network > Static Routes and verify that the default route is correct. Go to Monitor > Routing Monitor and verify
that the default route appears in the list as a static route. Along with the default route, you should see two routes
shown as Connected, one for each connected FortiGate interface.
7. Verify that you can connect to the Internet-facing interface’s IP address
Ping the IP address of the Internet-facing interface of your FortiGate. If you cannot connect to the interface, the
FortiGate is not allowing sessions from the internal interface to Internet-facing interface. Verify that PING has been
enabled for Administrative Access on the interface.
8. Verify that you can connect to the gateway provided by your ISP
Ping the default gateway IP address from a PC on the internal network. If you cannot reach the gateway, contact
your ISP to verify that you are using the correct gateway.
9. Verify that you can communicate from the FortiGate to the Internet
Access the FortiGate CLI and use the command execute ping 8.8.8.8. You can also use the execute
traceroute 8.8.8.8 command to troubleshoot connectivity to the Internet.
10. Verify the DNS configurations of the FortiGate and the PCs
Check for DNS errors by pinging or using traceroute to connect to a domain name; for example: ping
www.fortinet.com.
If the name cannot be resolved, the FortiGate or PC cannot connect to a DNS server and you should confirm that
the DNS server IP addresses are present and correct.
11. Confirm that the FortiGate can connect to the FortiGuard network
Once the FortiGate is on your network, you should confirm that it can reach the FortiGuard network. First, check the
License Information widget to make sure that the status of all FortiGuard services matches the services that you
have purchased. Go to System > FortiGuard, and, in the Filtering section, click Test Connectivity. After a minute, the
GUI should indicate a successful connection. Verify that your FortiGate can resolve and reach FortiGuard at
service.fortiguard.net by pinging the domain name. If you can reach this service, you can then verify the
connection to FortiGuard servers by running the command diagnose debug rating. This displays a list of
FortiGuard IP gateways you can connect to, as well as the following information:
l Weight: Based on the difference in time zone between the FortiGate and this server
l RTT: Return trip time
l Flags: D (IP returned from DNS), I (Contract server contacted), T (being timed), F (failed)
You can use this feature only when the FortiGate boots up from factory reset.
Topology
1. Add the FortiGate Cloud product key to the FortiGate Cloud portal so that the FortiGate serial number appears in
the portal.
2. Set up a configuration template with the basic configuration in the FortiGate Cloud portal.
4. Ensure the FortiGate has an interface in default DHCP client mode and is connected to the ISP outlet.
5. Boot the FortiGate in factory reset. The FortiGate gets the DHCP lease so that it can access FortiGate Cloud in the
Internet and join FortiGate Cloud.
The FortiGate Cloud server checks that the FortiGate key is valid and then deploys the FortiGate to FortiGate
Cloud.
To prevent spoofing, FortiGate Cloud invalidates that key after a successful join.
6. Complete zero touch provisioning by obtaining configuration from platform template in the Cloud.
0: set admintimeout 50
0: end
0: config system interface
0: edit "wan1"
0: set allowaccess ping ssh fgfm
0: next
0: edit "port1"
0: set allowaccess ping
0: set ip 1.1.1.1 255.255.255.0
0: next
0: edit "port2"
0: set allowaccess ping
0: set ip 2.2.2.2 255.255.255.0
0: next
0: end
7. The FortiGate Cloud admin can change the template for different configuration requirements and then deploy the
updated template to the FortiGate.
For example, you can add a secondary DNS to the template and deploy it to FortiGate.
You can use this feature only when the FortiGate boots up from factory reset. This feature is for FortiGate devices that
cannot access the Internet.
A DHCP server includes option 240 and 241 which records FortiManager IP and domain name. FortiGate has an
interface with the default DHCP client mode that is connected to the DHCP server in the intranet.
The FortiManager admin can authorize the FortiGate the specific ADOMs and install specific configurations on the
FortiGate.
In the whole operation, you do not need to do any manual configuration on the FortiGate except connect to the DHCP
server. This is called zero touch deployment.
To prevent spoofing, if a different FortiManager IP comes from the DHCP server later, FortiGate does not change the
central management configuration.
3. If FortiGate changes from factory reset, you can see it in central management in config-touched=1.
FG201E4Q17901047 # diagnose fdsm fmg-auto-discovery-status
dhcp: fmg-ip=172.18.60.115, fmg-domain-name='', config-touched=1(/bin/dhcpcd)
config options
edit 1
set code 240
set type ip
set ip "172.18.60.117"
end
After FortiGate reboots and gets DHCP renew, central management will not use the fake FortiManager IP because
config-touched=1 shows that the FortiGate is not in factory reset.
FG201E4Q17901047 # diagnose fdsm fmg-auto-discovery-status
dhcp: fmg-ip=0.0.0.0, fmg-domain-name='', config-touched=1(/bin/dhcpcd)
FortiOS includes predefined dashboards so administrators can easily monitor device inventory, security threats, traffic,
and network health. You can customize the appearance of a default dashboard to display data pertinent to your security
fabric, or combine widgets to create custom dashboards. Many dashboards also allow you to switch views between
fabric devices.
Each dashboard contains a set of widgets and monitors that allow you to view drill down data and take actions to prevent
threats. Use widgets to perform tasks such as viewing device inventory, creating and deleting DHCP reservations, and
disconnecting dial-up users. You can add or remove widgets to a dashboard, or save a widget as a standalone monitor.
This section contains the following topics:
l Using dashboards on page 64
l Using widgets on page 69
l Monitor dashboards and widgets on page 71
l FortiView on page 91
Using dashboards
You can use the dashboard GUI to view fabric devices in the security fabric. You can also combine widgets to create
custom dashboards.
1. At the right side of dashboard, click the device dropdown and select a device.
The device dropdown is available in the Status, Security, Network, Users & Devices, and
WiFi dashboards. You can also enable the dropdown when you create a dashboard.
1. Under Dashboard, click the Add Dashboard button. The Add Dashboard window opens.
2. Enter a name in the Name field and click OK. The new dashboard opens.
1. Click the Actions menu at the right side of the dashboard and selectDelete Dashboard.
1. Click the Actions menu at the right side of the dashboard and selectEdit Dashboard.
2. Edit the dashboard and click OK.
Use the device dropdown in the built-in dashboards to quickly navigate between downstream fabric devices. You can
also create dedicated device dashboards devices or log in and configure fabric devices.
To view fabric devices, click the device dropdown at the right side of the page, and select a device from the list.
The device dropdown is available in the Status, Security, Network, Users & Devices, and WiFi
dashboards. You can also enable the dropdown when you create a dashboard.
1. Hover over the device in the dropdown, and click Login You are redirected to the device login page or System
dashboard if you are already logged in.
1. Hover over the device in the dropdown, and click Configure. The Configure page opens.
Create a dashboard summary page to monitor all the fabric devices in a single view. You can use the dashboard to
monitor aspects of the devices such as system information, VPN, and routing.
1. Click the Add Dashboard button. The Add Dashboard window opens.
2. In the Name field, enter a name such as Fabric System & License, and click OK. The new dashboard appears.
3. In the banner, click Add Widget. The Add Dashboard Widget window opens. You can use the Search field to search
for a specific widget (for example, License Status, System Information, and Memory Usage).
4. Click the Add button next to widget. The Add Dashboard Widget window opens.
5. In the Fabric member area, select Specify and select a device in the security fabric.
6. Click Add Widget. The widget is added to the dashboard.
Repeat this step for all the devices you want to view in the dashboard.
7. (Optional) Arrange the widgets in the dashboard by fabric device.
Using widgets
You can save a widget as a standalone monitor, change the view type, as well as configure tables and filter data.
1. Hover over a widget in the dashboard, and click Expand to Full Screen.
2. In the top menu, click the Save as Monitor icon. The Add Monitor window opens.
3. Enter a name for the monitor in the Name field, and click OK.
1. Click the menu dropdown at the right side of the widget and select Settings.
2. Configure the widget settings and click OK.
1. Hover over the left side of the table header and click the Configure Table icon.
2. Configure the table options.
Option Description
Best Fit All Columns Resizes all of the columns in a table to fit their content.
3. Click Apply.
1. Hover over a column heading, and click the Filter/Configure Column icon.
2. Configure the column options, and click Apply.
Option Description
Group by this Column Groups the table rows by the contents in the selected column.
3. To filter a column, enter a value in the Filter field, and click Apply.
You can use the GUI to change the default dashboard template. The Optimal template contains a set of popular default
dashboards and FortiView monitors. The Comprehensive template contains a set of default dashboards as well as all
monitors and FortiViews. The Comprehensive template will be familiar to users coming from previous versions of
FortiOS.
Changing the default template will remove the dashboards and monitors you added and reset
the settings in the widgets.
1. Click the Actions menu at the right side of Add Dashboard or Add Monitor and click Reset All Dashboards. The
Dashboard Setup window opens.
l FortiView Threats
l FortiView Compromised Hosts
l FortiView Policies
l FortiView Sessions
l Device Inventory Monitor
l Routing Monitor
l DHCP Monitor
l SD-WAN Monitor
l FortiGuard Quota Monitor
l IPsec Monitor
l SSL-VPN Monitor
l Firewall User Monitor
l Quarantine Monitor
l FortiClient Monitor
l FortiAP Clients Monitor
l Rogue APs Monitor
Monitor dashboards and widgets allows you to view various states of your FortiGate pertaining to routing, VPN, DHCP,
devices, users, quarantine, and wireless connections.
The following default monitor dashboards are built into FortiOS:
l Network
l Users & Devices
l WiFi
Each built-in dashboard contains multiple widgets which can be expanded for detail view. To save a view as its own
monitor, click Save as Monitor at the right side of the banner.
Users & Devices l View users and devices connected to the network
l Identify threats from individual users and devices, and quarantine them.
l View FortiGuard and FortiClient data
l Monitor traffic bandwidth over time
The Static & Dynamic Routing Monitor displays the routing table on the FortiGate including all static and dynamic routing
protocols in IPv4 and IPv6. You can also use this monitor to view the firewall policy route.
Sample output:
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
Sample output:
list route policy info(vf=root):
DHCP monitor
The DHCP monitor displays all the addresses leased out by FortiGate's DHCP servers. You can use the monitor to
revoke an address for a device, or create, edit, and delete address reservations.
To filter or configure a column in the table, hover over the column heading and click
Filter/Configure Column.
To revoke a lease:
To create a DHCP reservation:
1. Right-click a device in the table and click Show in FortiView. The Top Sources by Bytes widget opens.
IPsec monitor
The IPsec monitor displays all connected Site to Site VPN and Dial-up VPNs. You can use the monitor to bring a phase 2
tunnel up or down or disconnect dial-up users.
To filter or configure a column in the table, hover over the column heading and click
Filter/Configure Column.
To reset statistics:
Sample output:
list all ipsec tunnel in vd 0
------------------------------------------------------
name=fct-dialup ver=1 serial=4 10.100.67.5:0->0.0.0.0:0 dst_mtu=0
bound_if=3 lgwy=static/1 tun=intf/0 mode=dialup/2 encap=none/512 options[0200]=frag-rfc
accept_traffic=1 overlay_id=0
SSL-VPN monitor
The SSL-VPN monitor displays user logins and active connections. You can use the monitor to disconnect a specific
connection.
To filter or configure a column in the table, hover over the column heading and click
Filter/Configure Column.
To disconnect a user:
Sample output
SSL VPN Login Users:
Index User Group Auth Type Timeout From HTTP in/out HTTPS in/out
0 amitchell TAC 1(1) 296 10.100.64.101 3838502/11077721 0/0
1 mmiles Dev 1(1) 292 10.100.64.101 4302506/11167442 0/0
The Firewall Users monitor displays all firewall users currently logged in. You can use the monitor to diagnose user-
related logons or to highlight and deauthenticate a user.
To filter or configure a column in the table, hover over the column heading and click
Filter/Configure Column.
To deauthenticate a user:
Device data collected from different daemons is centralized in a user device store for quick access and performance.
Thousands of devices can be displayed in the GUI in seconds. The maximum number of devices and users that are
stored in the database can be configured.
For example, go to Dashboard > Users & Devices and expand the Device Inventory widget.
To configure the maximum number of devices and users that are stored in the database:
WiFi Dashboard
The WiFi Dashboard is one of the default monitor dashboards built into FortiOS. It allows you to view FortiAP status,
channel utilization, WiFi clients and associated information, login failures and signal strength, and so on.
Go to Dashboard > WiFi to access the WiFi Dashboard:
You may customize the WiFi dashboard as per your requirements. To know more about using and modifying
dashboards and widgets, see Dashboards and widgets on page 64.
This section describes the following monitors available for the WiFi Dashboard:
l FortiAP Status monitor on page 80
l Clients by FortiAP monitor on page 82
The FortiAP Status monitor displays the status and the channel utilization of the radios of FortiAP devices connected to a
FortiGate. It also provides access to tools to diagnose and analyze connected APs.
1. Select and right-click on an Access Point entry in the table on the FortiAP Status monitor page.
2. Click Diagnostics and Tools. The Diagnostics and Tools dialog for the selected FortiAP device slides in on the
screen.
3. You may click on the various tabs in the Diagnostics and Tools dialog like Clients, Spectrum Analysis, VLAN Probe,
and so on, to monitor and analyze the FortiAP device.
The Diagnostics and Tools dialog is similar to the device dialog from WiFi & Switch Controller > Managed FortiAPs. To
learn more about the various tabs and their functions, see Support for spectrum analysis of FortiAP E models, VLAN
probe report, and Standardize wireless health metrics.
The Clients by FortiAP monitor allows you to view detailed information about the health of individual WiFi connections in
the network. It also provides access to tools to diagnose and analyze connected wireless devices.
1. Select a client entry in the table on the Clients by FortiAP monitor page.
2. Right-lick on the selected client entry in the table and select Diagnostics and Tools. The summary dialog for the
selected client slides in on the screen.
3. You may click on Quarantine to quarantine, or Disassociate to disassociate the selected wireless client.
From the summary page, the Health section displays the overall health for the wireless connection. The overall health of
the connection is:
l Good if the value range for all three conditions are Good
l Fair or poor if one of the three conditions is Fair or Poor respectively.
l Applications
l Destinations
l Policies
l Logs
The Clients by FortiAP monitor is a drilled-down version of the WiFi & Switch Controller > WiFi Clients page.
Device inventory
You can enable device detection to allow FortiOS to monitor your networks and gather information about devices
operating on those networks, including:
l MAC address
l IP address
l Operating system
l Hostname
l Username
l When FortiOS detected the device and on which interface
You can enable device detection separately on each interface in Network > Interfaces.
Device detection is intended for devices directly connected to your LAN ports. If enabled on a WAN port, device
detection may be unable to determine the OS on some devices. You can enable active scanning on the interface to find
hosts whose device types FortiOS cannot determine passively.
You can also manually add devices to Device Inventory to ensure that a device with multiple interfaces displays as a
single device.
To filter or configure a column in the table, hover over the column heading, and click
Filter/Configure Column. See Device inventory and filtering on page 87.
The Device Inventory widget contains a series of summary charts that provide an overview of the hardware, operating
system, status, and interfaces. You can use these clickable charts to simplify filtering among your devices.
Filter examples
Assets detected by device detection appear in the Device Inventory widget. You can manage policies around devices by
adding a new device object (MAC-based address) to a device. Once you add the MAC-based address, the device can be
used in address groups or directly in policies.
Use the Name field to assign a descriptive name to a device so it is easier to find it in the
Device column. After you finish configuring the device, refresh the page to see the new
name in the dashboard.
5. Click OK. The MAC address icon appears in the Address column next to the device name.
FortiView
FortiView is the FortiOS log view tool and comprehensive monitoring system for your network. FortiView integrates real-
time and historical data into a single view on your FortiGate. It can log and monitor network threats, keep track of
administration activities, and more.
Use FortiView dashboards and widgets to investigate traffic activity such as user uploads and downloads, or videos
watched on YouTube. You can view the traffic on the whole network, by user group or by individual. FortiView displays
the information in both text and visual format, giving you an overall picture of your network traffic activity so that you can
quickly decide on actionable items.
FortiView is integrated with many UTM functions and each release adds more features. For example, you can
quarantine an IP address directly in FortiView or create custom devices and addresses from a FortiView entry.
The logging range and depth will depend on the FortiGate model.
FortiView dashboards and widgets are available in the tree menu under the Dashboards module. The module contains
several core dashboards for the top categories. Non-core FortiView pages are available as widgets that can be added to
the dashboards. You can also use non-core pages to create standalone monitors.
The following core dashboards are available in the tree menu under the Dashboard console:
Dashboard Usage
FortiView Sources Displays Top Sources by traffic volume and drilldown by Source.
FortiView Destinations Displays Top Destinations by traffic volume and drilldown by Destination.
FortiView Applications Displays Top Applications by traffic volume and drilldown by Application.
FortiView Websites Displays Top Websites by session count and drilldown by Domain.
FortiView Policies Displays Top Policies by traffic volume and drilldown by Policy number
FortiView Sessions Displays Top Sessions by traffic source and can be used to end sessions.
Usage is based on default settings. The pages may be customized further and sorted by other fields.
You can quarantine a host and ban an IP from all of the core FortiView monitors.
FortiView widgets
FortiView widgets allow you to create custom dashboards to monitor vulnerabilities, scan summaries, and top items from
selected FortiView categories. You can also customize widgets to show information that is most important to you, such
as the time range, source logging device, and other information. For information, see Adding FortiView widgets on page
93
Non-core FortiView pages are available in the Add Dashboard window.You can add a FortiView widget to a dashboard
or save the widget as a monitor.
Widgets by category
Usage is based on the default settings. The widgets may be customized further and sorted by other fields.
LAN/DMZ
Threats Threat level/Threat Score/Sessions Displays top threats and drilldown by threat.
WAN
Threats Threat Level/Threat Score/Sessions Displays top threats and drilldown by threat.
All Segments
Dashboards are created per VDOM when VDOM mode is enabled. Some features and widgets are not available
depending on Multi or Split-task VDOM mode.
Multi-VDOM mode
The following widgets and dashboard setting are not available Multi-VDOM mode because it does not support Security
Fabric:
l Security Fabric related widgets
l FortiGate Selection option
Split-task mode
Split-task VDOM mode is limited to two VDOMs, the root VDOM and the FortiGate traffic VDOM. The root VDOM is for all
management related settings and the FortiGate traffic VDOM is for all traffic related settings.
The FortiGate Selection option is available when you create a dashboard in Split-Task VDOM mode.
For information about VDOM modes, see Virtual Domains on page 818.
Examples
When VDOM mode is disabled, the FortiGate Selection option is available in the Add Dashboard window:
When Multi-VDOM mode is enabled, the FortiGate Selection is not available in the Add Dashboard window:
When Multi-VDOM mode is disabled, all the widgets in the Add Dashboard Widget menu are enabled:
When Multi-VDOM mode is enabled, the Security Fabric Status widget is disabled:
FortiView interface
Use the FortiView interface to customize the view and visualizations within a dashboard to find the information you are
looking for. The tools in the top menu bar allow you to change the time display, refresh the data, customize the data
source, and filter the results. You can also right-click a table in the dashboard to view drilldown information for an entry.
Use the time display dropdown to select the time period to display on the current dashboard. Time display options vary
depending on the dashboard and can include current information (now) and historical information (1 hour, 24 hours, and
7 days).
You can use a chart to create a custom time display by selecting the time range with your cursor.
The icon next to the time period identifies the data source (FortiGate Disk, FortiAnalyzer, or FortiGate Cloud). You can
hover over the icon to see a description of the device.
View settings
Use the Settings menu to change the data source, sort by information, and visualization.
1. Click the dropdown menu at the right side of the top menu bar, and select Settings.
The Data Source dropdown only appears when FortiGate is connected to another data
source.
For information about widget settings, see Adding FortiView widgets on page 93
For dashboards with multiple widgets, you cannot access the settings dropdown when the
widget is expanded to full screen. To change the settings, click the back button to return to the
dashboard, and click the dropdown.
Data source
FortiView gathers information from a variety of data sources. If there are no log disk or remote logging configured, the
data will be drawn from the FortiGate's session table, and the Time Period is set to Now.
When Data Source is set to Best Available Device, FortiAnalyzer is selected when available,
then FortiGate Cloud, and then FortiGate Disk.
Display types
Bubble charts
Display types include table view, bubble charts, and country maps. Not all display types are supported by all
dashboards.
Bubble charts allow you to sort information using the Compare By dropdown menu. The size of each bubble represents
the related amount of data. You can place your cursor over a bubble to display a tool-tip with detailed information on that
item, and click on a bubble to drilldown into greater detail.
Country maps
Country maps display traffic activity as regions on a map. Hover over the highlighted region to view information about the
entry. You can also compare data by Bytes, Sessions, Bandwidth, and Packets. Country maps are not available in all
dashboards and widgets.
Table view
Table view displays traffic activity as a graph and a table. To remove the table, click close, at the top right corner of the
graph. To view the graph, click Show Graph.
Source view
Time l Now entries are determined by the FortiGate's system session list.
l Historical or 1 hour or later entries are determined by traffic logs, with additional
information coming from UTM logs.
Graph l The graph shows the bytes sent/received in the time frame.
l Users can customize the time frame by selecting a time period within the graph.
Columns l Source shows the IP address (and user as well as user avatar if configured) of the source
device.
l Device shows the device information as listed in the Device Inventory widget. Device
detection should be enabled on the applicable interfaces for best function. For
Hover over linked items in an entry to view additional information. Some information windows provide links to other areas
of FortiOS such as the application signatures page.
To select the columns displayed in a table, hover over the header in the first column, and click the configure table icon.
Drilldown information
Double-click or right-click an entry in a FortiView dashboard and select Drill Down to Details to view additional details
about the selected traffic activity. Click the Back icon in the toolbar to return to the previous view.
You can group drilldown information into different drilldown views. For example, you can group the drilldown information
in the Top FortiView Destinations dashboard by Sources, Applications, Threats, and Policies.
Double-click an entry to view the logs in Sessions view. Double-click a session to view the logs.
Graph l The graph shows the bytes sent/received in the time frame. Realtime does not include a
chart.
l Users can customize the time frame by selecting a time period within the graph.
Summary l Shows information such as the user/avatar, avatar/source IP, bytes, and sessions total
Information for the time period.
l Can quarantine host (access layer quarantine) if they are behind a FortiSwitch or
FortiAP.
l Can ban IP addresses, adds the source IP address into the quarantine list.
Tabs l Drilling down entries in any of these tabs (except sessions tab) will take you to the
underlying traffic log in the sessions tab.
l Applications shows a list of the applications attributed to the source IP. This can include
scanned applications (using Application Control in a firewall policy or unscanned
applications.
config log gui-display
set fortiview-unscanned-apps enable
end
l Destinations shows destinations grouped by IP address/FQDN.
l Threats lists the threats caught by UTM profiles. This can be from antivirus, IPS, Web
Filter, Application Control, etc.
l Web Sites contains the websites which were detected either with webfilter, or through
FQDN in traffic logs.
l Web Categories groups entries into their categories as dictated by the Web Filter
Database.
l Policies groups the entries into which polices they passed through or were blocked by.
l Sessions shows the underlying logs (historical) or sessions (realtime). Drilldowns from
other tabs end up showing the underlying log located in this tab.
l Search Phrases shows entries of search phrases on search engines captured by a Web
Filter UTM profile, with deep inspection enabled in firewall policy.
l More information can be shown in a tooltip while hovering over these entries.
To view matching logs or download a log, click the Security tab in the Log Details .
Restrictions
Desktop models (100 series) with Five minutes and one hour
SSD
Configuration
A firewall policy needs to be in place with traffic logging enabled. For optimal operation with FortiView, internal interface
roles should be clearly defined as LAN. DMZ and internet facing or external interface roles should be defined as WAN.
3. Click Apply.
To include sniffer traffic and local-deny traffic when FortiView from Disk:
Troubleshooting
Use execute report flush-cache and execute report recreate-db to clear up any irregularities that may
be caused by upgrading or cache issues.
Attach a FortiAnalyzer to FortiGate to increase the functionality of FortiView. Adding a FortiAnalyzer is useful when
adding widgets such as the Compromised Hosts widget. It also allows historical view for up to seven days.
Requirements
l A FortiGate or FortiOS
l A compatible FortiAnalyzer (see Compatibility with FortiOS)
1. On the FortiGate, go to Security Fabric > Fabric Connectors, and double-click the FortiAnalyzer Logging card.
2. Enter the IP address of the FortiAnalyzer device.
3. Click Test Connectivity. A message will be shown stating that the FortiGate is not authorized on the FortiAnalyzer.
6. On FortiGate, go to Security Fabric > Fabric Connectors, and double-click the FortiAnalyzer Logging card.
When Data Source is set to Best Available Device, FortiAnalyzer is selected when
available, then FortiGate Cloud, and then FortiGate Disk.
This function requires a FortiGate that is registered and logged into a compatible FortiGate Cloud. When using FortiGate
Cloud, the Time Period can be set to up to 24 hours.
1. Go to Security Fabric > Fabric Connectors, and double-click the Cloud Logging card.
2. For Status, click Enabled.
3. For Type, click FortiGate Cloud.
If the FortiGate is registered and logged into FortiGate Cloud, the Account and Region is displayed.
If the FortiGate is logged out from FortiGate Cloud, click Activate and log in, and ensure Send logs to FortiGate
Cloud is selected.
You can select FortiGate Cloud as the data source for all available FortiView pages and
widgets.
FortiView sources
The FortiView Sources dashboard displays top sources sorted by Bytes, Sessions or Threat Score. The information can
be displayed in real time or historical views. You can use the dashboard to create or edit a firewall device address or
1. In the Device column, hover over the device MAC address. An information window opens.
Use the Name field to assign a descriptive name to a device so it is easier to find it in the
Device column. After you finish configuring the device, refresh the page to see the new
name in the dashboard.
1. In the Device column, hover over the device MAC address. An information window opens.
Use the Name field to assign a descriptive name to a device so it is easier to find it in the
Device column. After you finish configuring the device, refresh the page to see the new
name in the dashboard.
To ban an IP address:
1. In the Device column, hover over the device MAC address. An information window opens.
FortiView Sessions
The FortiView Sessions dashboard is one of the core FortiView dashboards available in FortiOS. It displays Top
Sessions by traffic source and can be used to end sessions. You may customize the dashboard as per your needs by
using the sort and filter capabilities.
To view the FortiView Sessions dashboard, go to Dashboard > FortiView Sessions.
The session table displayed on the FortiView Sessions dashboard is useful when verifying open connections. For
example, if you have a web browser open to browse the Fortinet website, you would expect a session entry from your
computer on port 80 to the IP address for the Fortinet website. You can also use a session table to investigate why there
are too many sessions for FortiOS to process.
You can filter the sessions displayed in the session table by setting up the available filtering options.
1. Click on the Add Filter button at the top of the session table. A list of selectable filtering options drops down.
2. Select the required filtering option. For example you may select Country/Region, and select a country from the list of
countries. The session table updates as per the selected country.
3. You may add one or more filters depending upon your requirements. To add more filters, repeat the above steps for
a different set of filters.
You can be really specific with the way you use filters and target sessions based on different filter combinations. For
example, you may want to view all sessions from a computer with a particular IP, and you can do that by adding the
Source IP filter. Similarly, you may need to target all the sessions having a particular Destination IP and Destination Port,
and so on.
You may also see the session data in the CLI.
The session table output in the CLI is very large. You can use the supported filters in the CLI to show only the data you
need.
See Using a session table on page 1856 to learn more about using the supported filters in the CLI.
You may also decide to end a particular session or all sessions for administrative purposes.
1. Select a session that you want to end by clicking on it. To select multiple sessions, hold the Ctrl or Shift key on your
keyboard while clicking the session entries in the table.
2. Right-click on the selected sessions you want to end. A menu with options appears.
3. Click on End Session(s) to end the selected sessions, or End All Sessions to end all the active sessions.
4. Click OK in the confirmation dialog. The selected sessions are now ended.
You can use FortiGuard web categories to populate the category fields in various FortiView pages such as FortiView
Web Categories, FortiView Websites or FortiView Sources. To view the categories in a dashboard, the web filter profile
must be configured to at least monitor for FortiGuard category based filter, and applied to a firewall policy for outbound
traffic.
1. Under Dashboard, click Add Dashboard. The Add Dashboard window opens.
2. In the Name field, enter a name such as FortiView Web Categories and click OK. The new dashboard opens.
3. In the banner, click Add Widget. The Add Dashboard Widget window opens.
4. In the Search field, type FortiView Web Categories and click the Add button next to the widget name.
5. In the Fabric Member area, click Default or Specify to select a device in the security fabric.
6. From the Time Period dropdown, select a time period greater than Now.
7. From the Sort By dropdown, select Bytes, Sessions, Bandwidth, or Packets.
8. Click Add Widget. The widget is added to the dashboard.
The web filter category name appears in the Category column of the dashboard.
Click an entry in the table. The category name appears at the top of Summary of box.
Click the Web Sites tab. The category name appears in the Category column.
Click the Sessions tab. The category name appears in the Category Description column.
The category name also appears in the Category column in the FortiView Websites and FortiView Sources dashboards.
Cloud applications
All cloud applications require SSL Inspection set to deep-inspection on the firewall policy. For example, Facebook_
File.Download can monitor Facebook download behavior which requires SSL deep-inspection to parse the deep
information in the network packets.
1. In the Application Signature page, ensure the Behavior column is displayed. If necessary, add the Behavior column.
a. Hover over the left side of the table column headings to display the Configure Table icon.
b. Click Configure Table and select Behavior.
c. Click Apply.
2. Click the filter icon in the Behavior column and select Cloud to filter by Cloud. Then click Apply.
3. The Application Signature page displays all applications with cloud behavior.
4. Use the Search box to search for applications. For example, you can search for youtube.
On the Edit Application Sensor page in the Categories section, the eye icon next to a category means that category is
monitored and logged.
1. Hover over the widget in the dashboard, and click Expand to full screen.
2. For details about a specific entry, double-click the entry or right-click the entry and select Drill Down to Details.
3. To see all the sessions for an application, click Sessions.
In this example, the Application Name column shows all applications related to YouTube.
4. To view log details, double-click a session to display the Log Details pane.
Sessions monitored by SSL deep inspection (in this example, Youtube_Video.Play) captured deep information such
as Application User, Application Details, and so on. The Log Details pane also shows additional deep information
such as application ID, Message, and so on.
Sessions not monitored by SSL deep inspection (YouTube) did not capture the deep information.
5. To display a specific time period, select and drag in the timeline graph to display only the data for that time period.
This example of monitors network traffic for YouTube using FortiView Applications view with SSL deep inspection.
1. Use a firewall policy with the following settings. If necessary, create a policy with these settings.
l Application Control is enabled.
To view the application signature description, click the ID link in the information window.
7. On the test PC, log into YouTube and play some videos.
8. On the FortiGate, go to Log & Report > Application Control and look for log entries for browsing and playing
YouTube videos.
In this example, note the Application User and Application Details. Also note that the Application Control ID is 38569
showing that this entry was triggered by the application sensor YouTube_Video.Play.
This example of monitors network traffic for YouTube using FortiView cloud application view without SSL deep
inspection.
1. Use a firewall policy with the following settings. If necessary, create a policy with these settings.
l Application Control is enabled.
2. On the test PC, log into YouTube and play some videos.
3. On the FortiGate, go to Log & Report > Application Control and look for log entries for browsing and playing
YouTube videos.
In this example, the log shows only applications with the name YouTube. The log cannot show YouTube application
sensors which rely on SSL deep inspection.
The FortiView Source Firewall Objects and FortiView Destination Firewall Objects widgets leverage UUID to resolve
firewall object address names for improved usability.
Requirements
To have a historical Firewall Objects-based view, address objects' UUIDs need to be logged.
1. Open a dashboard and click Add Widget. The Add Dashboard Widget window opens.
2. In the Search field, type Destination Firewall Objects and click the Add button next to the dashboard name.
3. In the Fabric Member area, select Default or Specify to select a device in the security fabric.
4. In the Data Source area, select Best Available or Specify. For information about data sources, see FortiView
interface on page 96.
5. From the Time Period dropdown, select the time period.
6. In the Visualization area, select Table View or Bubble Chart.
7. From the Sort By dropdown, select Bytes, Sessions, Bandwidth, or Packets.
8. Click Add Widget.
Example
In this example, firewall addresses have been configured and associated with a unique UUID.
In the FortiView Source Firewall Objects and FortiView Destination Firewall Objects widgets, firewall objects can be
displayed in real-time or in a historical chart. Objects can also be drilled down for more details.
1. Open a dashboard, and click Add Widget. The Add Dashboard Widget window opens.
2. In the Search field, type Destination Firewall Objects and click the Add button next to the widget name.
3. From the Time Period dropdown, select Now.
4. Click Add Widget.
1. Open a dashboard, and click Add Widget. The Add Dashboard Widget window opens.
2. In the Search field, type Destination Firewall Objects and click the Add button next to the widget name.
3. From the Time Period dropdown, select a time period other than Now.
4. Click Add Widget.
You can use the Compromised Hosts by Verdict widget to view the session information for a compromised host.
2. Double-click a compromised host to view the session information. You can also right-click a compromised host, and
select View Sessions.
3. Double-click a session, or right-click the session and select View Sessions to view the information.
The Fortinet Security Fabric provides an intelligent architecture that interconnects discrete security solutions into an
integrated whole to detect, monitor, block, and remediate attacks across the entire attack surface. It delivers broad
protection and visibility into every network segment and device, be they hardware, virtual, or cloud based.
l The physical topology view shows all connected devices, including access layer devices. The logical topology view
shows information about the interfaces that each device is connected to.
l Security rating checks analyze the Security Fabric deployment to identify potential vulnerabilities and highlight best
practices to improve the network configuration, deploy new hardware and software, and increase visibility and
control of the network.
l Fabric connectors provide integration with multiple SDN, cloud, and partner technology platforms to automate the
process of managing dynamic security updates without manual intervention.
l Automation pairs an event trigger with one or more actions to monitor the network and take the designated actions
automatically when the Security Fabric detects a threat.
This section contains information about how to configure the following devices as part of the Fortinet Security Fabric:
l Components on page 130
l Configuring the root FortiGate and downstream FortiGates
l Configuring FortiAnalyzer
l Configuring other Security Fabric devices on page 140
l Using the Security Fabric
l Deploying the Security Fabric on page 178
l Synchronizing objects across the Security Fabric on page 186
l Security Fabric over IPsec VPN on page 195
l Leveraging LLDP to simplify security fabric negotiation on page 201
System requirements
To set up the Security Fabric, the devices that you want to include must meet the Product Integration and Support
requirements in the FortiOS Release Notes.
Some features of the Security Fabric are only available in certain firmware versions and models. Not all FortiGate
models can run the FortiGuard Security Rating Service if they are the root FortiGate in a Security Fabric. For more
information, see the Special Notices in the FortiOS Release Notes.
Prerequisites
l If devices are not already installed in your network, complete basic installation and configuration tasks by following
the instructions in the device documentation.
l FortiGate devices must either have VDOMs disabled or be running in split-task VDOM mode in order to be added to
the Security Fabric. See Virtual Domains on page 818.
l FortiGate devices must be operating in NAT mode.
Components
The Fortinet Security Fabric consists of different components that work together to secure you network.
The following devices are required to create a Security Fabric:
Device Description
FortiGate FortiGate devices are the core of the Security Fabric and can have one of the following roles:
l Root:
The root FortiGate is the main component in the Security Fabric. It is typically located on
the edge of the network and connects the internal devices and networks to the Internet
through your ISP. From the root FortiGate, you can see information about the entire
Security Fabric on the Physical and Logical Topology pages in the GUI.
l Downstream:
After a root FortiGate is installed, all other FortiGate devices in the Security Fabric act as
Internal Segmentation Firewalls (ISFWs), located at strategic points in your internal
network, rather than on the network edge. This allows extra security measures to be
taken around key network components, such as servers that contain valuable intellectual
property. ISFW FortiGate devices create network visibility by sending traffic and
information about the devices that are connected to them to the root FortiGate.
See Configuring the root FortiGate and downstream FortiGates on page 132 for more
information about adding FortiGate devices in the Security Fabric.
FortiGate documentation: https://docs.fortinet.com/product/fortigate
FortiAnalyzer FortiAnalyzer gives you increased visibility into your network, centralized monitoring, and
awareness of threats, events, and network activity by collecting and correlating logs from all
Security Fabric devices. This gives you a deeper and more comprehensive view across the
entire Security Fabric.
See Configuring FortiAnalyzer on page 139 for more information about adding FortiAnalyzer
devices in the Security Fabric.
FortiAnalyzer documentation: https://docs.fortinet.com/product/fortianalyzer
FortiAnalyzer Cloud 6.4.4 can be included in the security fabric if the root
FortiGate is running FortiOS 6.4.4 and later.
Device Description
FortiADC FortiADC devices optimize the availability, user experience, and scalability of enterprise
application delivery. They enable fast, secure, and intelligent acceleration and distribution of
even the most demanding enterprise applications.
Device Description
See Additional devices on page 164 for more information about adding FortiADC devices in
the Security Fabric.
FortiADC documentation: https://docs.fortinet.com/product/fortiadc
FortiAP Add FortiAP devices to extend the Security Fabric to your wireless devices. Devices
connected to a FortiAP appear in the Physical and Logical Topology pages in the Security
Fabric menu.
See FortiAP and FortiSwitch on page 161 for more information about adding FortiAP devices
in the Security Fabric.
FortiAP documentation: https://docs.fortinet.com/product/fortiap
FortiClient FortiClient adds endpoint control to devices that are located in the Security Fabric, allowing
only traffic from compliant devices to flow through the FortiGate. FortiClient compliance
profiles are applied by the first FortiGate that a device’s traffic flows through. Device
registration and on-net status information for a device that is running FortiClient appears only
on the FortiGate that applies the FortiClient profile to that device.
FortiClient documentation: https://docs.fortinet.com/product/forticlient
FortiClient EMS FortiClient EMS is used in the Security Fabric to provide visibility across your network,
securely share information, and assign security profiles to endpoints.
See FortiClient EMS on page 151 for more information about adding FortiClient EMS devices
in the Security Fabric.
FortiClient EMS documentation: https://docs.fortinet.com/product/forticlient
FortiDDoS FortiDDoS is a Network Behavior Anomaly (NBA) prevention system that detects and blocks
attacks that intend to disrupt network service by overutilizing server resources.
See Additional devices on page 164 for more information about adding FortiDDoS devices in
the Security Fabric.
FortiDDoS documentation: https://docs.fortinet.com/product/fortiddos
FortiMail FortiMail antispam processing helps offload from other devices in the Security Fabric that
would typically carry out this process.
See Additional devices on page 164 for more information about adding FortiMail devices in
the Security Fabric.
FortiMail documentation: https://docs.fortinet.com/product/fortimail
FortiManager Add FortiManager to simplify the network management of devices in the Security Fabric by
centralizing management access in a single device. This allows you to easily control the
deployment of security policies, FortiGuard content security updates, firmware revisions, and
individual configurations for devices in the Security Fabric.
See FortiManager on page 146 for more information about adding FortiManager devices in
the Security Fabric.
FortiManager documentation: https://docs.fortinet.com/product/fortimanager
FortiSandbox Add FortiSandbox to your Security Fabric to improve security with sandbox inspection.
Sandbox integration allows FortiGate devices in the Security Fabric to automatically receive
signature updates from FortiSandbox and add the originating URL of any malicious file to a
blocked URL list.
Device Description
See FortiSandbox on page 149 for more information about adding FortiSandbox devices in
the Security Fabric.
FortiSandbox documentation: https://docs.fortinet.com/product/fortisandbox
FortiSwitch A FortiSwitch can be added to the Security Fabric when it is managed by a FortiGate that is in
the Security Fabric with the FortiLink protocol, and connected to an interface with Security
Fabric Connection enabled. FortiSwitch ports to become logical extensions of the FortiGate.
Devices connected to the FortiSwitch appear in the Physical and Logical Topology pages in
the Security Fabric menu, and security features, such as FortiClient compliance profiles, are
applied to them.
See FortiAP and FortiSwitch on page 161 for more information about adding FortiSwitch
devices in the Security Fabric.
FortiSwitch documentation: https://docs.fortinet.com/product/fortiswitch
FortiWeb Add FortiWeb to defend the application attack surface from attacks that target application
exploits. You can also configure FortiWeb to apply web application firewall features, virus
scanning, and web filtering to HTTP traffic to help offload from other devices in the Security
Fabric that would typically carry out these processes.
See Additional devices on page 164 for more information about adding FortiWeb devices in
the Security Fabric.
FortiWeb documentation: https://docs.fortinet.com/product/fortiweb
FortiWLC FortiWLC delivers seamless mobility and superior reliability with optimized client distribution
and channel utilization. Both single and multi channel deployment options are supported,
maximizing efficiency to make the most of available wireless spectrum.
See Additional devices on page 164 for more information about adding FortiWLC devices in
the Security Fabric.
FortiWLC documentation: https://docs.fortinet.com/product/wireless-controller
Device Description
Other Fortinet Many other Fortinet products can be added to the Security Fabric, including
products FortiAuthenticator, FortiToken, FortiCache, and FortiSIEM.
Documentation: https://docs.fortinet.com/
Third-party Third-party products that belong to the Fortinet Fabric-Ready Partner Program can be added
products to the Security Fabric.
The following procedures include configuration steps for a typical Security Fabric implementation, where the edge
FortiGate is the root FortiGate, and the downstream FortiGate devices are all devices that are downstream from the root
FortiGate.
For information about the recommended number of downstream FortiGates, see the FortiOS 6.4 Best Practices.
Prerequisites
l FortiGate devices must either have VDOMs disabled or be running in split-task VDOM mode in order to be added to
the Security Fabric. See Virtual Domains on page 818.
l FortiGate devices must be operating in NAT mode.
The edge FortiGate is typically configured as the root FortiGate, as this allows you to view the full topology of the
Security Fabric from the top down.
1. On the root FortiGate, go to Security Fabric > Fabric Connectors and double-click the Security Fabric Setup card.
2. For Status, click Enable.
3. Set the Security Fabric role to Serve as Fabric Root. FortiAnalyzer logging is automatically enabled and the settings
can be configured.
4. Optionally, enable Source Interface and select an interface to communicate with FortiAnalyzer. If disabled, the
interface will be determined based on the routing table.
5. Enter the FortiAnalyzer IP and select the Upload option.
6. In the FortiAnalyzer Logging section, in the IP address field, enter the IP address of the FortiAnalyzer.
7. If required, enable Allow access to FortiGate REST API and, optionally, Verify FortiAnalyzer certificate.
The REST API accesses the FortiGate topology and shares data and results. The FortiGate will verify the
FortiAnalyzer by retrieving its serial number and checking it against the FortiAnalyzer certificate. When verified, the
FortiAnalyzer serial number is stored in the FortiGate configuration. When authorizing the FortiGate on the
FortiAnalyzer, the FortiGate admin credentials do not need to be entered.
8. Click Test Connectivity.
If you select Test Connectivity and this is the first time that you are connecting the FortiGate to the FortiAnalyzer,
you will receive a warning message because the FortiGate has not yet been authorized on the FortiAnalyzer. You
can configure this authorization when you configure the FortiAnalyzer. See Configuring FortiAnalyzer on page 139.
9. Click OK. The FortiAnalyzer serial number is verified.
10. Enter a Fabric name.
11. Ensure Allow other Security Fabric devices to join is enabled and add the interfaces.
12. Click OK.
Using the root FortiGate with disk to store historic user and device information
This backend implementation allows the root FortiGate in a Security Fabric to store historic user and device information
in a database on its disk. This will allow administrators to visualize users and devices over a period of time.
A new daemon, user_info_history, stores this data on the disk. The information source for the historical data will be the
user_info daemon, which would be recorded on the disk when user_info notifies user_info_history that a user has logged
out or the device is no longer connected.
Downstream FortiGate devices can be securely added to the Security Fabric without sharing the password of the root
FortiGate.
Downstream device serial numbers can be authorized from the root FortiGate, or allowed to join by request. New
authorization requests include the device serial number, IP address, and HA members. HA members can include up to
four serial numbers and is used to ensure that, in the event of a fail over, the secondary FortiGate is still authorized.
A downstream device's certificate can also be used to authorize the device by uploaded the certificate to the root
FortiGate.
You can use the FortiIPAM service to automatically assign subnets to downstream FortiGates
to prevent duplicate IP addresses from overlapping within the same Security Fabric. See
Assign a subnet with the FortiIPAM service on page 420.
When a downstream Fortinet device's serial number or certificate is added to the trusted list on the root FortiGate, the
device can join the Security Fabric as soon as it connects. After the new device is authorized, connected FortiAP and
FortiSwitch devices are automatically included in the topology, where they can be authorized with one click.
The interface that connects to the downstream FortiGate must have Security Fabric Connection enabled.
To pre-authorize a FortiGate:
Using LLDP
You can automatically prompt downstream FortiGate devices to join the Security Fabric using Link Layer Discovery
Protocol (LLDP) and interface role assignments.
1. On the root FortiGate, assign the LAN role to all interfaces that may connect to downstream FortiGate devices.
When the LAN role is assigned to an interface, LLDP transmission is enabled by default.
2. When a downstream FortiGate is installed, assign the WAN role to the interface that connects to the upstream
FortiGate.
When the WAN role is assigned, LLDP reception is enabled by default. The newly installed FortiGate uses LLDP to
discover the upstream FortiGate, and the administrator is prompted to configure the FortiGate to join the Security
Fabric.
3. On the root FortiGate, the new FortiGate must be authorized before it can join the Security Fabric.
If the network contains switches or routers, LLDP may not function as expected because some
devices do not pass LLDP packets.
When you log in to an unauthorized, downstream FortiGate, the log in prompt includes the option to authorize the device
on the root FortiGate.
When the Security Fabric is disabled on the FortiGate, and a neighboring FortiGate is detected on the same network
using LLDP, the log in prompt gives the option to join the Security Fabric.
3. Enter the log in credentials for the root FortiGate, then click Login.
A list of pending authorizations is shown.
4. Select Allow and then click OK to authorize the downstream FortiGate. You can also select Deny to reject the
authorization, or Later to postpone the decision to the next time that you log in.
When authorization is allowed, the pop-up window closes, and the log in prompt shows that the downstream
FortiGate has been authorized.
Device request
A device can request to join the Security Fabric from another FortiGate, but it must have the IP address of the root
FortiGate. The administrator of the root FortiGate must also authorize the device before it can join the Security Fabric.
The root FortiGate must have Security Fabric Connection enabled on the interface that the device connects to.
1. Connect to the unauthorized FortiGate or FortiWiFi device, and go to Security Fabric > Fabric Connectors and
double-click the Security Fabric Setup card.
2. For Status, click Enable.
3. Set Security Fabric role to Join Existing Fabric.
4. Set Upstream FortiGate IP to the IP address of the upstream FortiGate.
5. Connect to the root FortiGate and go to Security Fabric > Fabric Connectors. The new FortiGate appears in the
topology tree as unauthorized.
6. Click the unauthorized device and select Authorize to authorize the device.
CLI commands
Use the following commands to view, accept, and deny authorization requests, to view upstream and downstream
devices, and to list or test fabric devices:
Command Description
diagnose sys csf authorization View pending authorization requests on the root FortiGate.
pending-list
diagnose sys csf authorization Authorize a device to join the Security Fabric.
accept <serial-number-value>
diagnose sys csf authorization Deny a device from joining the Security Fabric.
deny <serial-number-value>
diagnose sys csf fabric-device list List all known fabric devices.
diagnose sys csf fabric-device Test connections to locally configured fabric devices.
test
Desynchronizing settings
By default, the settings for FortiAnalyzer logging, central management, sandbox inspection, and FortiClient EMS are
synchronized between all FortiGate devices in the Security Fabric. To disable the automatic synchronization of these
settings, use the following CLI command:
config system csf
set configuration-sync local
end
Deauthorizing a device
To deauthorize a device:
Configuring FortiAnalyzer
FortiAnalyzer is a required component for the Security Fabric. In 6.4.4 and above, either FortiAnalyzer or FortiAnalyzer
Cloud can be used to meet this requirement. FortiAnalyzer allows the Security Fabric to show historical data for the
Security Fabric topology and logs for the entire Security Fabric.
For more information about using FortiAnalyzer, see the FortiAnalyzer Administration Guide.
1. Enable FortiAnalyzer Logging on the root FortiGate. See Configure the root FortiGate on page 133.
2. On the FortiAnalyzer, go to System Settings > Network and click All Interfaces.
3. Edit the port that connects to the root FortiGate.
4. Set the IP Address/Netmask to the IP address that is used for the Security Fabric on the root FortiGate.
5. Click OK.
If the FortiGates have already been configured, it will now be listed as an unauthorized device.
6. Go to Device Manager > Devices Unauthorized. The unauthorized FortiGate devices are listed.
7. Select the root FortiGate and downstream FortiGate devices in the list, then click Authorize. The Authorize Device
page opens.
8. Click OK to authorize the selected devices.
9. On the FortiGate devices, go to Security Fabric > Fabric Connectors and double-click the FortiAnalyzer Logging
card. The page will now show the ADOM on the FortiAnalyzer that the FortiGate is in, and the storage, analytics,
and archive usage.
FortiGates running version 6.4.4. or later, with a FortiCloud Premium subscription (AFAC) for Cloud-based Central
Logging & Analytics, can send traffic logs to FortiAnalyzer Cloud in addition to UTM logs and event logs. After the
Premium subscription is registered through FortiCare, FortiGuard will verify the purchase and authorize the AFAC
contract. Once the contract is verified, FortiGuard will deliver the contract to FortiGate.
FortiGates with a Standard FortiAnalyzer Cloud subscription (FAZC) can only send UTM and event logs. FortiGates with
a Premium subscription will send the UTM and event logs even if the Standard subscription has expired.
For information about cloud logging, see FortiAnalyzer Cloud service on page 143
The FAZC and AFAC fields display the subscription expiration date. The Support contract field displays the
FortiCare account information. The User ID field displays the ID for FortiAnalyzer-Cloud instance.
...
FAZC,Tue Sep 24 16:00:00 2030
AFAC,Mon Nov 29 16:00:00 2021
...
Support contract: pending_registration=255 got_contract_info=1
account_id=[****@fortinet.com] company=[Fortinet] industry=[Technology]
User ID: 979090
This section contains information about configuring the following devices as part of the Fortinet Security Fabric:
l FortiGate Cloud on page 141
l FortiAnalyzer Cloud service on page 143
l FortiManager on page 146
Prerequisites
l FortiGate devices must either have VDOMs disabled or be running in split-task VDOM mode in order to be added to
the Security Fabric. See Virtual Domains on page 818.
l FortiGate devices must be operating in NAT mode.
FortiGate Cloud
FortiGate Cloud is a hosted security management and log retention service for FortiGate devices. It provides centralized
reporting, traffic analysis, configuration management, and log retention without the need for additional hardware or
software.
FortiGate Cloud offers a wide range of features:
l Simplified central management
FortiGate Cloud provides a central GUI to manage individual or aggregated FortiGate and FortiWiFi devices.
Adding a device to the FortiGate Cloud management subscription is straightforward. FortiGate Cloud has detailed
traffic and application visibility across the whole network.
l Hosted log retention with large default storage allocated
Log retention is an integral part of any security and compliance program, but administering a separate storage
system is onerous. FortiGate Cloud takes care of this automatically and stores the valuable log information in the
cloud. Each device is allowed up to 200GB of log retention storage. Different types of logs can be stored, including
Traffic, System Events, Web, Applications, and Security Events.
l Monitoring and alerting in real time
Network availability is critical to a good end-user experience. FortiGate Cloud enables you to monitor your FortiGate
network in real time with different alerting mechanisms to pinpoint potential issues. Alerting mechanisms can be
delivered via email.
l Customized or pre-configured reporting and analysis tools
Reporting and analysis are your eyes and ears into your network’s health and security. Pre-configured reports are
available, as well as custom reports that can be tailored to your specific reporting and compliance requirements.
The reports can be emailed as PDFs, and can cover different time periods.
l Maintain important configuration information uniformly
The correct configuration of the devices within your network is essential for maintaining optimum performance and
security posture. In addition, maintaining the correct firmware (operating system) level allows you to take advantage
of the latest features.
l Service security
All communication (including log information) between the devices and the cloud is encrypted. Redundant data
centers are always used to give the service high availability. Operational security measures have been put in place
to make sure your data is secure — only you can view or retrieve it.
Before you can activate a FortiGate Cloud account, you must first register your device.
FortiGate Cloud accounts can be registered manually through the FortiGate Cloud website, https://www.forticloud.com,
or you can easily register and activate your account directly from your FortiGate.
1. Go to Security Fabric > Fabric Connectors > Cloud Logging or Log & Report > Log Settings.
2. Enable Cloud Logging.
3. Select an upload option: Realtime, Every Minute, or Every 5 Minutes (default).
4. Click Apply.
Once logging has been configured and you have registered your account, you can log into the FortiGate Cloud portal
and begin viewing your logging results. There are two methods to reach the FortiGate Cloud portal:
l If you have direct network access to the FortiGate:
a. Go to Dashboard > Status.
b. In the FortiGate Cloud widget, in the Status field, click Activated > Launch Portal, or, in the Licenses widget,
click FortiCare Support > Launch Portal.
l If you do not have access to the FortiGate’s interface, visit the FortiGate Cloud website (https://www.forticloud.com)
and log in remotely, using your email and password. It will ask you to confirm the FortiGate Cloud account you are
connecting to and then you will be granted access.
Cloud sandboxing
FortiGate Cloud can be used for automated sample tracking, or sandboxing, for files from a FortiGate. This allows
suspicious files to be sent to be inspected without risking network security. If the file exhibits risky behavior, or is found to
contain a virus, a new virus signature is created and added to the FortiGuard antivirus signature database.
1. Go to Security Fabric > Fabric Connectors and double-click the FortiSandbox card.
2. For status, click Enable.
3. Set the Type to FortiSandbox Cloud.
By default, the FortiSandbox Cloud option is not visible. See Feature visibility on page 925
for instructions on making it visible.
Traffic logs are not currently supported by FortiAnalyzer Cloud without a FortiCloud Premium
subscription (AFAC). For information, see Configuring FortiAnalyzer on page 139.
When FortiAnalyzer Cloud is licensed and enabled (see Deploying FortiAnalyzer Cloud for more information), all
event logs are sent to FortiAnalyzer Cloud by default. All traffic logs, security logs, and archive files are not sent to
FortiAnalyzer Cloud.
FortiAnalyzer Cloud differs from FortiAnalyzer in the following ways:
l You cannot enable FortiAnalyzer Cloud in vdom override-setting when global FortiAnalyzer Cloud is
disabled.
l You must use the CLI to retrieve and display logs sent to FortiAnalyzer Cloud. The FortiOS GUI is not supported.
l You cannot enable FortiAnalyzer Cloud and FortiGate Cloud at the same time.
In the FortiOS Security Fabric > Fabric Connectors > Cloud Logging card settings page, FortiAnalyzer Cloud is grayed
out when you do not have a FortiAnalyzer Cloud entitlement.
Sample log
FortiManager
When a FortiManager device is added to the Security Fabric, it automatically synchronizes with any connected
downstream devices.
To add a FortiManager to the Security Fabric, configure it on the root FortiGate. The root FortiGate then pushes this
configuration to downstream FortiGate devices. The FortiManager provides remote management of FortiGate devices
over TCP port 541. The FortiManager must have internet access for it to join the Security Fabric.
Once configured, the FortiGate can receive antivirus and IPS updates, and allows remote management through
FortiManager or the FortiGate Cloud service. The FortiGate management option must be enabled so that the FortiGate
can accept management updates to its firmware and FortiGuard services.
1. On the root FortiGate, go to Security Fabric > Fabric Connectors and double-click the FortiManager card.
2. For Status, click Enable.
This cloud-based SaaS management service is available through FortiManager. This service is included in the 360
Protection Bundle (per-device license) and in FortiCloud accounts with a FortiManager Cloud account level subscription
(ALCI).
Once the FortiGate has acquired a contract named FortiManager Cloud, FortiCloud creates a cloud-based FortiManager
instance under the user account. You can launch the portal for the cloud-based FortiManager from FortiCloud, and its
URL starts with the User ID.
You can use a FortiGate with a contract for FortiManager Cloud to configure central management by using the FQDN of
fortimanager.forticloud.com. A FortiGate-FortiManager tunnel is established between FortiGate and the FortiManager
instance.
After the tunnel is established, you can execute FortiManager functions from the cloud-based FortiManager portal.
d. Click OK.
The FortiManager Cloud button can only be selected if you have a FortiManager Cloud
product entitlement.
2. In the FortiManager Cloud instance, go to Device Manager and authorize the FortiGate. See Authorizing devices for
more information.
When using FortiGate to enable FortiManager Cloud, the FortiGate appears as an unauthorized device.
In FortiOS, the Security Fabric > Fabric Connectors page now displays green arrow in the FortiManager card
because FortiManager Cloud is registered.
Diagnostics
To verify the FortiManager Cloud instance has launched and the FortiGate is registered:
FortiSandbox
The Security Fabric supports FortiSandbox appliances and FortiSandbox Cloud. A FortiGate Cloud account is not
required.
To use FortiSandbox in a Security Fabric, connect the FortiSandbox to the Security Fabric, then configure an antivirus
profile to send files to the FortiSandbox. Sandbox inspection can also be used in web filter profiles.
FortiSandbox settings are configured on the root FortiGate of the Security Fabric. After configuration, the root FortiGate
pushes the settings to other FortiGate devices in the Security Fabric.
1. On the root FortiGate, go to Security Fabric > Fabric Connectors and double-click the FortiSandbox card.
2. Set Status to Enable.
3. In the Server field, enter the FortiSandbox device's IP address.
1. On the root FortiGate, go to Security Fabric > Fabric Connectors and double-click the FortiSandbox Cloud card.
2. Set Status to Enable.
3. Select the FortiSandbox cloud Region from the dropdown list. Data from your network will only be sent to servers in
the selected region.
4. Click OK.
If FortiSandbox Cloud is not visible in the GUI, run the execute forticloud-sandbox
region and execute forticloud-sandbox update commands.
Antivirus profiles
3. Under APT Protection Options, set Send Files to FortiSandbox Appliance for Inspection to All Supported Files.
4. Optionally, configure file exceptions.
5. Enable Use FortiSandbox database.
6. Click OK.
FortiClient EMS
The FortiGate Security Fabric root device can link to FortiClient Endpoint Management System (EMS) and FortiClient
EMS Cloud (a cloud-based EMS solution) for endpoint connectors and automation. Up to three EMS servers can be
added to the Security Fabric, including a FortiClient EMS Cloud server. EMS settings are synchronized between all
fabric members.
To enable cloud-based EMS services, the FortiGate must be registered to FortiCloud with an appropriate user account.
The following examples presume that the EMS certificate has already been configured.
To add an on-premise FortiClient EMS server to the Security Fabric in the GUI:
1. On the root FortiGate, go to System > Feature Visibility and enable Endpoint Control.
2. Go to Security Fabric > Fabric Connectors.
3. Click Create New and click FortiClient EMS.
4. For Type, click FortiClient EMS.
5. Enter a name and IP address or FQDN. When connecting to a multitenancy-enabled EMS, Fabric connectors must
use an FQDN to connect to EMS, where the FQDN hostname matches a site name in EMS (including "Default").
The following are examples of FQDNs to provide when configuring the connector to connect to the default site and
to a site named SiteA, respectively: default.ems.yourcompany.com, sitea.ems.yourcompany.com. See
Multitenancy.
6. Click OK.
A window appears to verify the EMS server certificate:
7. Click Accept.
The FortiClient EMS Status section displays a Successful connection and an Authorized certificate:
To add a FortiClient EMS Cloud server to the Security Fabric in the GUI:
5. Click OK.
A window appears to verify the EMS server certificate.
6. Click Accept.
The FortiClient EMS Status section displays a Successful connection and an Authorized certificate.
1. Go to Security Fabric > Fabric Connectors and double-click the FortiClient EMS or FortiClient EMS Cloud card.
2. In the FortiClient EMS Status section under Connection, click Refresh.
To add an on-premise FortiClient EMS server to the Security Fabric in the CLI:
The https-port is the EMS HTTPS access port number, and the source-ip is the REST API call source IP address.
To add a FortiClient EMS Cloud server to the Security Fabric in the CLI:
keyid:66:54:0F:78:78:91:F2:E4:08:BB:80:2C:F6:BC:01:8E:3F:47:43:B1
DirName:/C=CA/ST=bc/L=burnaby/O=devqa/OU=top3/CN=fac155.fortinet.com/emailAddress=xyguo@fort
inet.com
serial:01:86:A4
Troubleshooting
When configuring a new connection to an EMS server, the certificate might not be trusted.
When you click Authorize, a warning displays: The server certificate cannot be authenticated with installed CA
certificates. Please install its CA certificates on this FortiGate.
In the CLI, an error message displays when you try to verify the certificate:
# execute fctems verify Win2K16-EMS
certificate not configured/verified: 2
Could not verify server certificate based on current certificate authorities.
Error 1--92-60-0 in get SN call: EMS Certificate is not signed by a known CA.
The default FortiClient EMS certificate that is used for the SDN connection is signed by the CA certificate that is saved on
the Windows server when FortiClient EMS is first installed. You can manually export and install it on the FortiGate.
1. Export the EMS certificate on the server that EMS is installed on:
a. On the Windows server that EMS is installed on, go to Settings > Manage computer certificates.
b. In the certificate management module, go to Trusted Root Certification Authorities > Certificates.
c. Right click on the certificate issued by FortiClient Enterprise Management Server and select All Tasks > Export.
d. The Certificate Export Wizard opens. Click Next.
e. Select Base-64 encoded X.509, then click Next.
f. Enter a file name for the certificate and click Browse to select the folder where it will be located, then click Next.
g. Review the settings, then click Finish. The certificate is downloaded to the specified folder.
2. On the FortiGate, import the certificate:
a. Go to System > Certificate. By default, the Certificate option is not visible, see Feature visibility on page 925 for
information.
b. Click Import > CA Certificate.
c. Set Type to File, and click Upload to import the certificate from the management computer.
d. Click OK. The imported certificate is shown in the Remote CA Certificate section of the certificate table.
3. Try to authorize the certificate on the FortiGate:
a. Go to Security Fabric > Fabric Connectors and edit the FortiClient EMS connector. The connection status
should now say that the certificate is not authorized.
b. Click Authorize. The following warning is shown:
d. Click OK.
An option under the FortiClient EMS settings on the FortiGate consolidates the setup of EMS connectors to support EMS
tags. EMS tags are pulled into the FortiGate via TCP/8013 and automatically synced with the EMS server. They are
converted into read-only dynamic firewall addresses that can be used in firewall policies, routing, and so on.
You can test connectivity to the EMS on the FortiGate with the diagnose endpoint
fctems test-connectivity <EMS_ENTRY_NAME> command.
These examples presume the following have been configured in FortiClient EMS:
l Tags have been created on the Compliance Verification > Compliance Verification Rules page.
l There are registered users who match the defined tags that are visible on the Compliance Verification > Host Tag
Monitor page.
FCTEMS0580226579_ems137_winscp_tag: ID(155)
ADDR(100.100.100.141)
FCTEMS0580226579_ems137_win10_tag: ID(182)
ADDR(10.1.100.120)
# diagnose firewall dynamic address FCTEMS0580226579_ems137_vuln_critical_tag
FCTEMS0580226579_ems137_vuln_critical_tag: ID(118)
ADDR(10.1.100.120)
ADDR(10.1.100.198)
3. Configure a firewall policy that uses the EMS tag dynamic firewall address as a source.
FortiNAC
A FortiNAC device can be added to the Security Fabric on the root FortiGate. After the device has been added and
authorized, you can log in to the FortiNAC from the FortiGate topology views.
Adding a FortiNAC to the Security Fabric requires a FortiNAC with a license issued in the year
2020 that includes an additional certificate. The device cannot be added if it has an older
license. Use the licensetool in the FortiNAC CLI to determine if your license includes the
additional certificate
1. On the FortNAC, configure telemetry and input the IP address of the root FortiGate.
2. On the root FortiGate, authorize the FortiNAC.
3. Verify the connection status in the topology views.
1. Go to System > Settings, and in the Folder View select Security Fabric Connection.
2. Add a new entry with the root FortiGate device's IP address. The default port is 8013.
See Security Fabric Connection in the FortiNAC Administration Guide for more information.
Optionally, you can also deny authorization to the FortiNAC to remove it from the list.
1. After the FortiNAC is authorized, go to Security Fabric > Physical Topology and confirm that it is included in the
topology.
2. Go to Security Fabric > Logical Topology and confirm the FortiNAC is also displayed there.
3. Run the following command in the CLI to view information about the FortiNAC device's status:
# diagnose sys csf downstream-devices fortinac
{
"path":"FG5H1E5818900126:FNVMCATM20000306",
"mgmt_ip_str":"10.1.100.197",
"mgmt_port":0,
"admin_port":8443,
"serial":"FNVMCATM20000306",
"host_name":"adnac",
"device_type":"fortinac",
"upstream_intf":"port2",
"upstream_serial":"FG5H1E5818900126",
"is_discovered":true,
"ip_str":"10.1.100.197",
"downstream_intf":"eth0",
"authorizer":"FG5H1E5818900126",
"idx":1
}
1. On the FortiGate, go to Security Fabric > Physical Topology or Security Fabric > Logical Topology.
2. Click on the FortiNAC and select Login to <serial_number>.
FortiAP and FortiSwitch devices can be authorized in the Security Fabric with one click. After connecting a FortiAP or
FortiSwitch device to an authorized FortiGate, it will automatically be listed in the topology tree.
For more information about configuring FortiAPs, see Configuring the FortiGate interface to manage FortiAP units and
Discovering, authorizing, and deauthorizing FortiAP units.
For more information about configuring FortiSwitches, see Using the FortiGate GUI.
FortiMail
FortiMail can be authorized into the Security Fabric using either the gutter on the Fabric Connectors page, or by pre-
authorizing using the FortiMail serial number or certificate.
1. Go to System > Customization and click the Corporate Security Fabric tab (or the Corporate Security Fabric tab in
FortiMail 6.4.2 and earlier).
2. Click the toggle to enable the Fabric.
3. Enter the Upstream IP Address (root FortiGate) and the Management IP of the FortiMail.
4. Click Apply.
If the FortiMail was added to the Security Fabric but not pre-authorized, you can authorize it in FortiOS on the Fabric
Connectors page.
To authorize FortiMail:
FortiMail can be pre-authorized using its serial number or certificate. When you pre-authorize, the FortiMail can join at
any time, and you will not need to authorize it FortiOS. In this example, FortiMail is pre-authorized using a certificate.
1. Log in to FortiMail.
2. Download the certificate. For example, in Chrome:
a. In the left side of the address bar, click the icon to view the site information.
b. Click Certificate.
c. Click the Details tab, then click Copy to File.
e. For the file format, select Base-64 encoded X.509 (.CER), then click Next.
f. Browse to the folder location and enter a file name, then click Next.
g. Click Finish, then click OK to close the dialog box.
3. In FortiOS, go to Security Fabric > Fabric Connectors and double-click the Security Fabric Setup card.
4. Beside Device authorization, click Edit and configure the following:
a. Enter the FortiMail serial number.
b. For Authorization type, select Serial Number.
c. For Certificate, upload the .CER file you saved previously.
d. Click OK.
Additional devices
In FortiOS, the device details can be shown in the Security Fabric and Fabric Device dashboard widgets, as well as the
Fabric Connectors page, and physical and logical topologies.
To add one or more of the devices to the Security Fabric in the GUI:
4. Click Generate to generate an access token. The Generate Access Token pane opens.
a. Enter the device's username and password.
b. Click OK.
5. Click OK.
6. Add more devices as required.
The additional devices are shown on the Fabric Connectors page under Other Fortinet Products and in the
Topology tree.
To add one or more of the devices to the Security Fabric in the CLI:
edit "FortiADC"
set device-ip 172.18.64.36
set access-token xxxxxx
next
end
end
Dashboard widgets
The Security Fabric status widget shows a summary of the devices in the Security Fabric.
Hover the cursor over the top icons to view pop-ups showing the statuses of the devices in the fabric.
The device tree shows devices that are connected, or could be connected, to you Security Fabric, according to the
following color scheme:
l Blue: connected to the network
l Gray: not configured or not detected
l Red: no longer connected or not authorized
Hover over a device in the tree to view details about the device, such as it's serial number, operation mode, IP address,
CPU and memory usage, and others, depending on the device type.
Unauthorized FortiAP and FortiSwitch devices are highlighted in the list, and can be authorized by clicking on the device
name.
Fabric Device
The Fabric Device widget shows statistics and system information about the selected fabric device.
For a FortiMail device, the widget can show:
l Mail Statistics: a chart of the total messages and total spam messages over time.
l Statistics Summary: a pie chart summarizes mail statistics.
l System Information: The FortiMail System Information widget
l System Usage: System usage information, such as CPU, memory, and disk usage, as well as the number of active
sessions.
FortiGate Cloud
The FortiGate Cloud widget shows the FortiGate Cloud status and information. If your account is not activated, you can
activate it from the widget.
1. Click on the Not Activated button and select Activate. The Activate FortiGate Cloud pane opens.
2. If you already have an account:
a. Fill in your email address, password, country or region, and reseller.
b. Click OK.
3. If you are creating an account:
a. In the FortiCloud field select Create Account.
b. Fill in all of the required information.
c. Click OK.
Topology
The full Security Fabric topology can be viewed on the root FortiGate. Downstream FortiGate devices' topology views do
not include upstream devices.
The Physical Topology shows the physical structure of your network, including all connected devices and the
connections between them. The Logical Topology shows information about the interfaces that connect devices to the
Security Fabric. Only Fortinet devices are shown in the topologies.
In both topology pages, you can use filtering and sorting options to control the information that is shown. Hover the
cursor over a device icon, port number, or endpoint to open a tooltip that shows information about that specific device,
port, or endpoint. Right-click on a device to log in to it or to deauthorize it. Right-click on an endpoint to perform various
tasks, including drilling down for more details on sources or compromised hosts, quarantining the host, and banning the
IP address.
The small number that might be shown on the top right corner of a device icon is the number of security ratings
recommendations or warnings for that device. The color of the circle shows the severity of the highest security rating
check that failed. Clicking it opens the Security Rating page. See Security rating on page 220 for more information.
Servers and server clusters are represented by squares with rounded corners. They are grouped separately from
circular endpoints. Devices are grouped by type and are colored based on their risk level. Endpoint groups are
represented by donut charts or bubble packs depending on the current view settings (see Endpoint groups for more
information). The size of the bubbles in the topology vary based on traffic volume.
AWS assets are grouped by AWS security groups or subnets, and information about detected Common Vulnerabilities
and Exposures (CVEs), as well as the instance details and ID, are shown.
Views
The topology views can be focused using filters and by sorting in different ways to help you locate the information that
you need.
Select one of Access Device or No Access Device to only show access or no access devices in the physical topology.
From the Endpoint Option dropdown list, select one of the following views:
Endpoint groups
The Device Traffic and Device Count views display endpoint groups as donut charts, with the total number of endpoints
in the group in the center of the chart. Each sector of the donut chart represents a different endpoint operating system.
To zoom in on a donut chart, click any chart sector. Each sector represents a different endpoint OS. Hovering over each
sector allows you to see the OS that the sector represents and the number of endpoints that have that OS installed.
In this example, the endpoint group contains a total of nine endpoints, with the following OSes installed:
Orange Linux 2
Green FortiMail 1
Red FortiManager 1
Blue Other 5
To view the endpoint group in a bubble pack display, click the + button in the center of the donut chart. You can view
each individual endpoint in the bubble pack view.
WAN cloud
The WAN cloud icon includes a dropdown menu for selecting where the destination data comes from. The available
options are: Internet, Owner, IP Address, and Country/Region. These options are only available when the filtering is
based on Device Traffic.
When Owner is selected, the destination hosts are shown as donut charts that show the percentage of internal (with
private IP addresses) and Internet hosts. Hover over either color in the chart to see additional information.
To view more details, right-click on the chart and select Destination Owner Details. The Top Destination Owners by
Bytes widget opens. Click the green icon (Standalone FortiView page icon) to add the widget to a new dashboard.
Alternatively, you can add the FortiView Destination Owners widget as a standalone page or to an existing dashboard
(see Adding FortiView widgets on page 93).
Newly discovered FortiAP and FortiSwitch devices are initial shown in the topologies with gray icons to indicate that they
have not been authorized. To authorize a device, click on the device icon or name and select Authorize. Once
authorized, the device icon will turn blue.
Right-click on an authorized FortiAP device to Deauthorize or Restart the device. Right-click on a FortiSwitch device to
Deauthorize, Restart, or Upgrade the device, or to Connect to the CLI.
FortiAP and FortiSwitch links are enhanced to show link aggregation groups for the inter-switch link (ISL-LAG). To
differentiate them from physical links, ISL-LAG links are shown with a thicker line. The endpoint circles can also be used
as a reference to identify ISL-LAG groups that have more than two links.
Critical risks
Click the Critical Risks button to see a list of endpoints that are deemed critical risks, organized by threat severity. These
are the red endpoints in the current topology view.
For each endpoint, the user's photo, name, IP address, email address, and phone number are shown. The number of
vulnerabilities of each severity is shown, and if the IoC verdict is that the endpoint is compromised.
If applicable, the endpoint's host can be quarantined or their IP address banned, by clicking the Quarantine Host on Ban
IP button.
The dropdown menu also provides options to drill down to more information on compromised hosts or endpoint
vulnerabilities.
Click Drill Down to Compromised Hosts to open the Top Compromised Hosts page that shows a summary for the
selected endpoint.
Compromised host information can also be viewed on the FortiAnalyzer in SOC > FortiView > Threats > Compromised
Hosts.
The FortiAnalyzer must have a FortiGuard Indicators of Compromise service license in order
to see compromised hosts.
Click Drill Down to Endpoint Vulnerability to open the vulnerabilities page that shows a summary of the vulnerabilities on
the selected endpoint.
FortiAnalyzer
The Security Fabric topology can also be seen on the FortiAnalyzer device. In the Device Manager, FortiGate devices
are shown as part of a Security Fabric group with an asterisk next to the name of the root FortiGate.
To view the Security Fabric topology, right-click on the fabric group and select Fabric Topology. Only Fortinet devices
are shown in the Security Fabric topology views.
The topology view shows endpoints based on their highest severity event.
In the default topology view, you can view hosts with critical vulnerabilities and compromised hosts identified as critical
risks.
The consolidated Risk view mode displays different risks within the Security Fabric topology. You can use the Risk view
mode to filter threats by Compromised Hosts, Vulnerability, and Threat Score.
2. Select one of the following options from the Risk Type dropdown menu:
l All
l Compromised Hosts
l Vulnerability
l Threat Score
This topic shows how to view and control compromised hosts via the Security Fabric > Physical Topology or Security
Fabric > Logical Topology view.
In the following topology, the downstream FortiGate (Marketing) is connected to the root FortiGate (Edge) through a
FortiSwitch (Distribution). The Endpoint Host is connected to the downstream FortiGate (Marketing) through another
FortiSwitch (Access).
1. Test that FortiGate detects a compromised endpoint host by opening a browser on the endpoint host and entering a
malicious website URL. The browser displays a Web Page Blocked! warning and does not allow access to the
website.
2. In FortiOS on the root FortiGate, go to Security Fabric > Physical Topology. The endpoint host, connected to the
Access FortiSwitch, is highlighted in red. Mouse over the endpoint host to view a tooltip that shows the IoC verdict.
The endpoint host is compromised.
3. Go to Security Fabric > Logical Topology. The endpoint host, connected to the downstream FortiGate, is highlighted
in red. Mouse over the endpoint host to view a tooltip that shows the IoC verdict. The endpoint host is compromised.
3. Go to Monitor > Quarantine Monitor. From the dropdown list at the top right corner, select All FortiGates. The
quarantined endpoint host displays in the content pane.
4. On the endpoint host, open a browser and visit a website such as https://www.fortinet.com/. If the website cannot be
accessed, this confirms that the endpoint host is quarantined.
1. To show the downstream FortiGate after it joins the Security Fabric, run the diagnose sys csf downstream
command in the root FortiGate (Edge) CLI. The output should resemble the following:
Edge # diagnose sys csf downstream
1: FG101ETK18002187 (192.168.7.3) Management-IP: 0.0.0.0 Management-port:0 parent:
FG201ETK18902514
path:FG201ETK18902514:FG101ETK18002187
data received: Y downstream intf:wan1 upstream intf:vlan70 admin-port:443
authorizer:FG201ETK18902514
2. To show the upstream FortiGate after the downstream FortiGate joins the Security Fabric, run the diagnose sys
csf upstream command in the downstream FortiGate (Marketing) CLI. The output should resemble the following:
This topic provides an example of deploying Security Fabric with three downstream FortiGates connecting to one root
FortiGate. To deploy Security Fabric, you need a FortiAnalyzer running firmware version 6.2 or later.
The following shows a sample network topology with three downstream FortiGates (Accounting, Marketing, and Sales)
connected to the root FortiGate (Edge).
1. Configure interfaces:
a. In the root FortiGate (Edge), go to Network > Interfaces.
b. Edit port16:
l Set Role to DMZ.
l For the interface connected to FortiAnalyzer, set the IP/Network Mask to 192.168.65.2/255.255.255.0
c. Edit port10:
l Set Role to LAN.
l For the interface connected to the downstream FortiGate (Accounting), set the IP/Network Mask to
192.168.10.2/255.255.255.0
d. Edit port11:
l Set Role to LAN.
l For the interface connected to the downstream FortiGate (Marketing), set the IP/Network Mask to
192.168.200.2/255.255.255.0
2. Configure Security Fabric:
a. In the root FortiGate (Edge), go to Security Fabric > Fabric Connectors and double-click the Security Fabric
Setup card.
b. For Status, click Enable.
c. Set the Security Fabric role to Serve as Fabric Root. The FortiAnalyzer settings can be configured.
d. Enter the FortiAnalyzer IP (192.168.65.10) and select and Upload option (the default is Real Time).
e. Click Test Connectivity.
A warning message indicates that the FortiGate is not authorized on the FortiAnalyzer. The authorization is
configured in a later step on the FortiAnalyzer.
f. Click OK. The FortiAnalyzer serial number is verified.
g. Enter a Fabric name, such as Office-Security-Fabric.
h. Ensure Allow other Security Fabric devices to join is enabled and add port10 and port11.
i. Click OK.
3. Create a policy to allow the downstream FortiGate (Accounting) to access the FortiAnalyzer:
a. In the root FortiGate (Edge), go to Policy & Objects > Addresses.
b. Click Create New.
l Set Name to FAZ-addr.
c. Click OK.
d. Click Create New.
l Set Name to Accounting.
e. Click OK.
f. In the root FortiGate (Edge), go to Policy & Objects > Firewall Policy and click Create New.
l Set Name to Accounting-to-FAZ.
l Enable NAT.
g. Click OK.
4. Create a policy to allow the two downstream FortiGates (Marketing and Sales) to access the FortiAnalyzer:
a. In the root FortiGate (Edge), go to Policy & Objects > Addresses and click Create New.
l Set Name to Marketing-addr.
b. Click OK.
c. In the root FortiGate (Edge), go to Policy & Objects > Firewall Policy and click Create New.
l Set Name to Marketing-to-FAZ.
l Enable NAT.
d. Click OK.
1. Configure interface:
a. In the downstream FortiGate (Accounting), go to Network > Interfaces.
b. Edit interface wan1:
l Set Role to WAN.
l For the interface connected to root, set the IP/Network Mask to 192.168.10.10/255.255.255.0
2. Configure the default static route to connect to the root FortiGate (Edge):
a. In the downstream FortiGate (Accounting), go to Network > Static Routes and click Create New or Create New
> IPv4 Static Route.
l Set Destination to 0.0.0.0/0.0.0.0.
b. Click OK.
3. Configure Security Fabric:
a. In the downstream FortiGate (Accounting), go to Security Fabric > Fabric Connectors and double-click the
Security Fabric Setup card.
b. For Status, click Enable.
FortiAnalyzer automatically enables logging. Settings for the FortiAnalyzer are retrieved from the root FortiGate
(Edge) when FortiGate (Accounting) connects to the root FortiGate (Edge).
c. Set the Security Fabric role to Join Existing Fabric.
d. Upstream FortiGate IP is filled in automatically with the default static route Gateway Address of 192.168.10.2
set in the previous step.
e. Disable Allow other FortiGates to join, because there is no downstream FortiGate connecting to it.
f. Click OK.
1. Configure interface:
a. In the downstream FortiGate (Marketing), go to Network > Interfaces.
b. Edit port12:
l Set Role to LAN.
l For the interface connected to the downstream FortiGate (Sales), set the IP/Network Mask to
192.168.135.11/255.255.255.0.
c. Edit wan1:
l Set Role to WAN.
l For the interface connected to the root FortiGate (Edge), set the IP/Network Mask to
192.168.200.10/255.255.255.0.
2. Configure the default static route to connect to the root FortiGate (Edge):
a. In the downstream FortiGate (Marketing), go to Network > Static Routes and click Create New or Create New >
IPv4 Static Route.
l Set Destination to 0.0.0.0/0.0.0.0.
b. Click OK.
3. Configure Security Fabric:
a. In the downstream FortiGate (Marketing), go to Security Fabric > Fabric Connectors and double-click the
Security Fabric Setup card.
b. For Status, click Enable.
FortiAnalyzer automatically enables logging. Settings for the FortiAnalyzer are retrieved from the root FortiGate
(Edge) when FortiGate (Marketing) connects to the root FortiGate (Edge).
c. Set the Security Fabric role to Join Existing Fabric.
d. Upstream FortiGate IP is filled in automatically with the default static route Gateway Address of 192.168.200.2
set in the previous step.
e. Enable Allow other FortiGates to join and add port12.
f. Click OK.
4. Create a policy to allow another downstream FortiGate (Sales) going through FortiGate (Marketing) to access the
FortiAnalyzer:
a. In the downstream FortiGate (Marketing), go to Policy & Objects > Addresses and click Create New.
l Set Name to FAZ-addr.
b. Click OK.
c. Click Create New.
l Set Name to Sales-addr.
d. Click OK.
e. In the downstream FortiGate (Marketing), go to Policy & Objects > Firewall Policy and click Create New.
l Set Name to Sales-to-FAZ.
l Enable NAT.
f. Click OK.
1. Configure interface:
a. In the downstream FortiGate (Accounting), go to Network > Interfaces.
b. Edit interface wan1:
l Set Role to WAN.
l For the interface connected to root, set the IP/Network Mask to 192.168.10.10/255.255.255.0
2. Configure the default static route to connect to the root FortiGate (Edge):
a. In the downstream FortiGate (Accounting), go to Network > Static Routes and click Create New or Create New
> IPv4 Static Route.
l Set Destination to 0.0.0.0/0.0.0.0.
b. Click OK.
3. Configure Security Fabric:
a. In the downstream FortiGate (Accounting), go to Security Fabric > Fabric Connectors and double-click the
Security Fabric Setup card.
b. For Status, click Enable.
FortiAnalyzer automatically enables logging. Settings for the FortiAnalyzer are retrieved from the root FortiGate
(Edge) when FortiGate (Accounting) connects to the root FortiGate (Edge).
c. Set the Security Fabric role to Join Existing Fabric.
d. Upstream FortiGate IP is filled in automatically with the default static route Gateway Address of 192.168.10.2
set in the previous step.
e. Disable Allow other FortiGates to join, because there is no downstream FortiGate connecting to it.
f. Click OK.
1. Configure interface:
a. In the downstream FortiGate (Sales), go to Network > Interfaces.
b. Edit wan2:
l Set Role to WAN.
l For the interface connected to the upstream FortiGate (Marketing), set the IP/Network Mask to
192.168.135.10/255.255.255.0.
2. Configure the default static route to connect to the upstream FortiGate (Marketing):
a. In the downstream FortiGate (Sales), go to Network > Static Routes and click Create New or Create New >
IPv4 Static Route.
l Set Destination to 0.0.0.0/0.0.0.0.
b. Click OK.
3. Configure Security Fabric:
a. In the downstream FortiGate (Sales), go to Security Fabric > Fabric Connectors and double-click the Security
Fabric Setup card.
b. For Status, click Enable.
FortiAnalyzer automatically enables logging. Settings for the FortiAnalyzer are retrieved from the root FortiGate
(Edge) when FortiGate (Sales) connects to the root FortiGate (Edge).
c. Set the Security Fabric role to Join Existing Fabric.
d. Upstream FortiGate IP is filled in automatically with the default static route Gateway Address of
192.168.135.11 set in the previous step.
e. Disable Allow other FortiGates to join, because there is no downstream FortiGate connecting to it.
f. Click OK.
To authorize downstream FortiGates (Accounting, Marketing, and Sales) on the root FortiGate (Edge):
1. In the root FortiGate (Edge), go to Security Fabric > Fabric Connectors and double-click the Security Fabric Setup
card.
The Topology tree highlights two connected FortiGates with their serial numbers and asks you to authorize the
highlighted devices.
2. Select the highlighted FortiGates and select Authorize.
After they are authorized, the two downstream FortiGates (Accounting and Marketing) appear in the Topology tree
in the Security Fabric > Fabric Connectors > Security Fabric Setup page. This means that the two downstream
FortiGates (Accounting and Marketing) have successfully joined the Security Fabric.
3. The Topology tree now highlights the FortiGate with the serial number that is connected to the downstream
FortiGate (Marketing) and asks you to authorize the highlighted device.
4. Select the highlighted FortiGates and select Authorize.
After it is authorized, the downstream FortiGate ( Sales) appears in the Topology tree in the Security Fabric > Fabric
Connectors > Security Fabric Setup page. This means that the downstream FortiGates (Sales) has successfully
joined the Security Fabric.
1. Run the diagnose sys csf authorization pending-list command in the root FortiGate to show the
downstream FortiGate pending for root FortiGate authorization:
Edge # diagnose sys csf authorization pending-list
Serial IP Address HA-Members Path
------------------------------------------------------------------------------------
FG201ETK18902514 0.0.0.0 FG3H1E5818900718:FG201ETK18902514
2. Run the diagnose sys csf downstream command in the root or middle FortiGate to show the downstream
FortiGates after they join Security Fabric:
Edge # diagnose sys csf downstream
1: FG201ETK18902514 (192.168.200.10) Management-IP: 0.0.0.0 Management-port:0
parent: FG3H1E5818900718
path:FG3H1E5818900718:FG201ETK18902514
data received: Y downstream intf:wan1 upstream intf:port11 admin-port:443
authorizer:FG3H1E5818900718
2: FGT81ETK18002246 (192.168.10.10) Management-IP: 0.0.0.0 Management-port:0 parent:
FG3H1E5818900718
path:FG3H1E5818900718:FGT81ETK18002246
data received: Y downstream intf:wan1 upstream intf:port10 admin-port:443
authorizer:FG3H1E5818900718
3: FG101ETK18002187 (192.168.135.10) Management-IP: 0.0.0.0 Management-port:0
parent: FG201ETK18902514
path:FG3H1E5818900718:FG201ETK18902514:FG101ETK18002187
data received: Y downstream intf:wan2 upstream intf:port12 admin-port:443
authorizer:FG3H1E5818900718
3. Run the diagnose sys csf upstream command in any downstream FortiGate to show the upstream FortiGate
after downstream FortiGate joins Security Fabric:
Marketing # diagnose sys csf upstream
Upstream Information:
Serial Number:FG3H1E5818900718
IP:192.168.200.2
Connecting interface:wan1
Connection status:Authorized
When the Security Fabric is enabled, various objects such as addresses, services, and schedules are synced from the
upstream FortiGate to all downstream devices by default. FortiOS has the following settings for object synchronization
across the Security Fabric:
l Set object synchronization (fabric-object-unification) to default or local on a downstream device.
l Set a per object option to toggle whether the specific Fabric object will be synchronized or not. After upgrading from
6.4.3, this option is disabled for supported Fabric objects. The synchronized Fabric objects are kept as locally
created objects on downstream FortiGates.
l Define the number of task workers to handle synchronizations.
The firewall object synchronization wizard helps identify objects that are not synchronized and resolves any conflicts. A
warning message appears in the topology tree if there is a conflict.
Parameter Description
fabric-object-unification default: Global CMDB objects will be synchronized in the Security Fabric.
local: Global CMDB objects will not be synchronized to and from this device.
This command is available on the root FortiGate. If set to local, the device does
not synchronize objects from the root, but will send the synchronized objects
downstream.
fabric-workers Define how many task worker process are created to handle synchronizations (1-
4, default = 2). The worker processes dies if there is no task to perform after 60
seconds.
The per object setting can be configured on the root FortiGate as follows:
config firewall <object>
edit <name>
set fabric-object {enable | disable}
...
next
end
Where:
l <object> is one of the following: address, address6, addrgrp, addrgrp6, service category, service
custom, service group, schedule group, schedule onetime, or schedule recurring.
l Enabling fabric-object sets the object as a Security Fabric-wide global object that is synchronized to
downstream FortiGates.
l Disabling fabric-object sets the object as local to this Security Fabric member.
Sample topology
In this Security Fabric, the root FortiGate (FGTA-1) has fabric-object-unification set to default so the Fabric
objects can be synchronized to the downstream FortiGate. The level 1 downstream FortiGate (FGTB-1) has
configuration-sync set to local, so it will not apply the synchronized objects locally. The level 2 downstream
FortiGate (FGTC) has configuration-sync set to default, so it will apply the synchronized objects locally.
In this example, firewall addresses and address groups are used. Other supported Fabric objects have the same
behaviors. The following use cases illustrate common synchronization scenarios:
l If no conflicts exist, firewall addresses and address groups can be synchronized to downstream FortiGates (see
example below).
l If a conflict exists between the root and downstream FortiGates, it can be resolved with the conflict resolution
wizard. After the conflict is resolved, the firewall addresses and address groups can be synchronized to
downstream FortiGates (see example below).
l If set fabric-object (Fabric synchronization option in the GUI) is disabled for firewall addresses and address
groups on the root FortiGate, they will not be synchronized to downstream FortiGates (see example below).
3. Check the firewall address and address group on the downstream FortiGates:
FGTB-1 # show firewall address add_subnet_1
entry is not found in table
FGTB-1 # show firewall addrgrp group_subnet_1
entry is not found in table
The synchronized objects are not applied locally on this FortiGate because configuration-sync is set to
local.
FGTC # show firewall address add_subnet_1
config firewall address
edit "add_subnet_1"
set uuid 378a8094-34cb-51eb-ce40-097f298fcfdc
set fabric-object enable
set subnet 22.22.22.0 255.255.255.0
next
end
FGTC # show firewall addrgrp group_subnet_1
config firewall addrgrp
edit "group_subnet_1"
set uuid 4d7a8a52-34cb-51eb-fce7-d93f76915319
set member "add_subnet_1"
set color 19
set fabric-object enable
next
end
The objects are synchronized on this FortiGate because configuration-sync is set to default.
To resolve a firewall address and address group conflict in the Security Fabric:
Name sync_add_1
c. Click OK.
2. On FGTA-1 (Fabric root), create the firewall address with same name but a different subnet:
a. Go to Policy & Objects > Addresses and click Create New > Address.
b. Configure the following:
Name sync_add_1
c. Click OK.
3. Add the address to a different address group than what is configured on FGTC:
a. Go to Policy & Objects > Addresses and click Create New > Address Group.
b. Configure the following:
Name sync_group4
Members sync_add_1
c. Click OK.
4. Go to Security Fabric > Fabric Connectors. In the topology tree, there is a message that Firewall objects are in
conflict with other FortiGates in the fabric.
c. The conflict is resolved. Click Close to exit the Firewall Object Synchronization pane.
Name add_subnet_3
c. Click OK.
2. Create the firewall address group and add the address:
a. Go to Policy & Objects > Addresses and click Create New > Address Group.
b. Configure the following:
Name group_subnet_3
Members add_subnet_3
c. Click OK.
3. On FGTB-1, go to Policy & Objects > Addresses and search for subnet_3. No results are found because Fabric
synchronization is disabled on the root FortiGate (FGTA-1).
4. On FGTC, go to Policy & Objects > Addresses and search for subnet_3. No results are found because Fabric
synchronization is disabled on the root FortiGate (FGTA-1).
next
end
3. Check the firewall address and address group on the downstream FortiGates:
FGTB-1 # show firewall address add_subnet_3
entry is not found in table
FGTB-1 # show firewall addrgrp group_subnet_3
entry is not found in table
FGTC # show firewall address add_subnet_3
entry is not found in table
FGTC # show firewall addrgrp group_subnet_3
entry is not found in table
The objects are not synchronized from the root FortiGate (FGTA-1) because the fabric-object setting is
disabled.
Sample topology
This sample topology shows a downstream FortiGate (HQ2) connected to the root FortiGate (HQ1) over IPsec VPN to
join Security Fabric.
Sample configuration
1. Configure interface:
a. In the root FortiGate (HQ1), go to Network > Interfaces.
b. Edit port2:
l Set Role to WAN.
l For the interface connected to the Internet, set the IP/Network Mask to 10.2.200.1/255.255.255.0
c. Edit port6:
l Set Role to DMZ.
l For the interface connected to FortiAnalyzer, set the IP/Network Mask to 192.168.8.250/255.255.255.0
b. Click OK.
3. Configure IPsec VPN:
a. Go to VPN > IPsec Wizard.
l Set Name to To-HQ2.
l Click Next.
b. Leave all other fields in their default values and click OK.
4. Configure the IPsec VPN interface IP address which will be used to form Security Fabric:
a. Go to Network > Interfaces.
b. Edit To-HQ2:
l Set Role to LAN.
c. Click OK.
d. Click Create New
l Set Name to To-HQ2_local_subnet_1.
e. Click OK.
f. Click Create New
l Set Name to To-HQ2_remote_subnet_1.
g. Click OK.
6. Configure IPsec VPN static routes:
a. Go to Network > Static Routes
b. Click Create New or Create New > IPv4 Static Route.
l For Named Address, select Type and select To-HQ2_remote_subnet_1.
Click OK.
c. Click Create New or Create New > IPv4 Static Route.
d. Click OK.
7. Configure IPsec VPN policies:
a. Go to Policy & Objects > Firewall Policy
b. Click Create New.
l Set Name to vpn_To-HQ2_local.
l Disable NAT.
c. Click OK.
d. Click Create New.
l Set Name to vpn_To-HQ2_remote.
l Enable NAT.
e. Click OK.
8. Configure Security Fabric:
a. Go to Security Fabric > Fabric Connectors and double-click the Security Fabric Setup card.
b. For Status, click Enable.
After FortiGate Telemetry is enabled, FortiAnalyzer automatically enables Logging and Upload is set to Real
Time.
c. Set the Security Fabric role to Serve as Fabric Root. The FortiAnalyzer settings can be configured.
d. Enter the FortiAnalyzer IP (192.168.8.250).
e. Click OK. The FortiAnalyzer serial number is verified.
f. Enter a Fabric name, such as Office-Security-Fabric.
g. Ensure Allow other Security Fabric devices to join is enabled and add VPN interface To-HQ2.
h. Click OK.
1. Configure interface:
a. Go to Network > Interfaces.
b. Edit interface wan1:
l Set Role to WAN.
l For the interface connected to the Internet, set the IP/Network Mask to 192.168.7.3/255.255.255.0.
l For the interface connected to local endpoint clients, set the IP/Network Mask to
10.1.100.3/255.255.255.0.
2. Configure the static route to connect to the Internet:
a. Go to Network > Static Routes and click Create New or Create New > IPv4 Static Route.
l Set Destination to 0.0.0.0/0.0.0.0.
b. Click OK.
3. Configure IPsec VPN:
a. Go to VPN > IPsec Wizard.
l Set VPN Name to To-HQ1.
l Click Next.
b. Leave all other fields in their default values and click OK.
4. Configure the IPsec VPN interface IP address which will be used to form Security Fabric:
a. Go to Network > Interfaces.
b. Edit To-HQ1:
l Set Role to WAN.
c. Click OK.
d. Click Create New
l Set Name to To-HQ1_remote_subnet_1.
e. Click OK.
6. Configure IPsec VPN static routes:
a. Go to Network > Static Routes and click Create New or Create New > IPv4 Static Route.
l For Named Address, select Type and select To-HQ1_remote_subnet_1.
b. Click OK.
d. Click OK.
7. Configure IPsec VPN policies:
a. Go to Policy & Objects > Firewall Policy and click Create New.
l Set Name to vpn_To-HQ1_local.
l Disable NAT.
b. Click OK.
c. Click Create New.
l Set Name to vpn_To-HQ1_remote.
l Disable NAT.
d. Click OK.
8. Configure Security Fabric:
a. Go to Security Fabric > Fabric Connectors and double-click the Security Fabric Setup card.
b. For Status, click Enable.
FortiAnalyzer automatically enables logging. FortiAnalyzer settings will be retrieved when the downstream
FortiGate connects to the root FortiGate.
c. Set the Security Fabric role to Join Existing Fabric.
d. Set the Upstream FortiGate IP to 10.10.10.1.
e. Click OK.
1. In the root FortiGate (HQ1), go to Security Fabric > Fabric Connectors and double-click the Security Fabric Setup
card.
The Topology tree highlights the connected FortiGate (HQ2) with the serial number and asks you to authorize the
highlighted device.
2. Select the highlighted FortiGates and select Authorize.
After authorization, the downstream FortiGate (HQ2) appears in the Topology tree in the Security Fabric > Fabric
Connectors > Security Fabric Setup page. This means the downstream FortiGate (HQ2) has successfully joined the
Security Fabric.
1. Run the diagnose sys csf authorization pending-list command in the root FortiGate (HQ1) to show
the downstream FortiGate pending for root FortiGate authorization:
HQ1 # diagnose sys csf authorization pending-list
Serial IP Address HA-Members
Path
------------------------------------------------------------------------------------
FG101ETK18002187 0.0.0.0
FG3H1E5818900718:FG101ETK18002187
2. Run the diagnose sys csf downstream command in the root FortiGate (HQ1) to show the downstream
FortiGate (HQ2) after it joins Security Fabric:
HQ1 # diagnose sys csf downstream
1: FG101ETK18002187 (10.10.10.3) Management-IP: 0.0.0.0 Management-port:0 parent:
FG3H1E5818900718
path:FG3H1E5818900718:FG101ETK18002187
data received: Y downstream intf:To-HQ1 upstream intf:To-HQ2 admin-port:443
authorizer:FG3H1E5818900718
3. Run the diagnose sys csf upstream command in the downstream FortiGate (HQ2) to show the root
FortiGate (HQ1) after the downstream FortiGate joins Security Fabric:
HQ2 # diagnose sys csf upstream
Upstream Information:
Serial Number:FG3H1E5818900718
IP:10.10.10.1
Connecting interface:To-HQ1
Connection status:Authorized
This feature enables LLDP reception on WAN interfaces, and prompts FortiGates that are joining the Security Fabric if
the upstream FortiGate asks.
l If an interface's role is undefined, LLDP reception and transmission inherit settings from the VDOM.
l If an interface's role is WAN, LLDP reception is enabled.
l If an interface's role is LAN, LLDP transmission is enabled.
When a FortiGate B's WAN interface detects that FortiGate A's LAN interface is immediately upstream (through the
default gateway), and FortiGate A has Security Fabric enabled, FortiGate B will show a notification on the GUI asking to
join the Security Fabric.
VDOM Setting.
l If the interface's role is WAN, under Administrative Access, set Receive LLDP to Enable and Transmit LLDP to
Use VDOM Setting.
l If the interface's role is LAN, under Administrative Access, set Receive LLDP to Use VDOM Setting and
Transmit LLDP to Enable.
3. Click the notification. The Core Network Security page with the Security Fabric settings opens. All the required
settings automatically configured.
4. Click OK to apply the settings, or use the following CLI commands:
config system csf
set status enable
set upstream-ip 10.2.200.1
end
Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data
between one Identity Provider (IdP) and one or more Service Providers (SP). Both parties exchange messages using the
XML protocol as transport. FortiGate firewall devices can be configured as IdPs or SPs.
When the Security Fabric is enabled, you can configure the root FortiGate as the IdP. You can also configure
downstream FortiGates to be automatically configured as SPs, with all links required for SAML communication, when
added to the Security Fabric. Administrators must still be authorized on each device. Credentials are verified by the root
FortiGate, and login credentials are shared between devices. Once authorized, an administrator can move between
fabric devices without logging in again.
Optionally, the downstream FortiGate can also be manually configured as an SP, and then linked to the root FortiGate.
The authentication service is provided by the root FortiGate using local system admin accounts for authentication. Any of
the administrator account types can be used for SAML log in. After successful authentication, the administrator logs in to
the first downstream FortiGate SP, and can then connect to other downstream FortiGates that have the SSO account
properly configured, without needing to provide credentials again, as long as admins use the same browser session. In
summary, the root FortiGate IdP performs SAML SSO authentication, and individual device administrators define
authorization on FortiGate SPs by using security profiles.
SAML SSO enables a single FortiGate device to act as the identify provider (IdP), while other FortiGate devices act as
service providers (SP) and redirect logins to the IdP.
Only the root FortiGate can be the identity provider (IdP). The downstream FortiGates can be
configured as service providers (SP).
Because communication between the root FortiGate IdP and FortiGate SPs is secured, you must select a local server
certificate in the IdP certificate option on the root FortiGate. When downstream SPs join the IdP (root FortiGate), the SP
automatically obtains the certificate.
In the following SP example, the IdP certificate displays REMOTE_Cert_2, which is the root server certificate for the IdP:
It is possible to manually import a certificate from an SP to the IdP so it can be used for authentication.
e. Click OK.
After you have logged in to a Security Fabric member using SSO, you can navigate between any Security Fabric
member with SSO configured.
You are now logged in to the Security Fabric member with SSO. The letters "SSO" also display beside the user
name in the top banner.
5. Go to System > Administrators > Single-Sign-On Administrator to view the list of SSO admins created.
To enter a question mark (?) or a tab, Ctrl + V must be entered first. Question marks and tabs cannot be typed or copied
into the CLI Console or some SSH clients.
next
end
end
To configure an SP:
You can set up SAML SSO authentication in a Security Fabric environment by starting with a root FortiGate that has one
or more pre-authorized FortiGates.
After the initial configuration, you can add more downstream FortiGates to the Security Fabric, and they are
automatically configured with default values for a service provider.
4. Configure the IdP (see Configuring the root FortiGate as the IdP on page 204).
5. Configure the SPs (see Configuring a downstream FortiGate as an SP on page 204).
After you have logged in to a Security Fabric member by using SSO, you can navigate between any Security Fabric
member with SSO configured. This can be done using the Security Fabric members dropdown menu or by logging in to a
FortiGate SP from the root FortiGate IdP.
The Security Fabric members dropdown menu allows you to easily switch between all FortiGate devices that are
connected to the Security Fabric. You can also use this menu to customize a FortiGate in the Security Fabric.
1. In the Security Fabric members dropdown menu, hover the cursor over a FortiGate so the tooltip is shown.
2. Click Configure. The Configure pane opens.
The following example describes how to log in to a root FortiGate IdP, and navigate to other FortiGate SPs in the
Security Fabric without further authentication. The local administrator account is named test3. The local administrator
account must also be available as an SSO administrator account on all downstream FortiGate SPs. Different tabs of the
same browser are used to log in to the various FortiGates.
1. Log in to the root FortiGate IdP by using the local administrator account.
In this example, the local administrator account is named test3.
2. Go to Security Fabric > Fabric Connectors and double-click the Security Fabric Setup card.
3. In the Topology tree, click one of the downstream FortiGate SPs, and select Login to <name of FortiGate>.
5. While still logged into the root FortiGate IdP in your browser, go to the browser tab for the root FortiGate IdP, and log
in to another FortiGate SP that is displayed on the Security Fabric pane in the GUI.
SAML SSO login uses SAML_IDP session cookies of already authenticated admin users in your local browser
cache to send to the root FortiGate IdP for authentication. If your browser cache is manually cleared, or you close
your browser, you must authenticate again.
It is possible to log in to one downstream FortiGate SP in a Security Fabric, and then open
another tab in your browser to connect to another FortiGate SP that is not a member of the
Security Fabric.
This is useful in cases where the SSO administrator and the local system administrator on the
FortiGate SP both have the same login name, but are two different entities.
When a FortiGate is configured as the SAML SSO IdP, FortiAnalyzer can register itself as the SP (FortiAnalyzer must be
running version 6.4.0). Once registered, FortiAnalyzer will be added automatically to the Security Fabric navigation in
FortiOS. A similar dropdown navigation is displayed in FortiAnalyzer where users can navigate to the FortiGate using
SAML SSO.
The following example assumes the root FortiGate (FGTA-1, server address 172.17.48.225:4431) has been configured
as the SAML SSO IdP, and FortiAnalyzer logging has been enabled in the Security Fabric settings.
3. Click Apply.
FortiAnalyzer will automatically register itself on the FortiGate as an appliance visible in the list of SPs. Go to
Security Fabric > Fabric Connectors, edit the Security Fabric Setup connector, then click Advanced Options to view
the list of SPs.
FortiAnalyzer will register itself on the FortiGate as an appliance. To view the configuration in FortiOS:
show system saml
config service-providers
edit "appliance_172.17.48.225:4253"
set prefix "csf_p0m9dvltwt28r3gt87runs2nb929mwz"
set sp-entity-id "http://172.17.48.225:4253/metadata/"
set sp-single-sign-on-url "https://172.17.48.225:4253/saml/?acs"
set sp-single-logout-url "https://172.17.48.225:4253/saml/?sls"
set sp-portal-url "https://172.17.48.225:4253/saml/login/"
config assertion-attributes
edit "username"
next
edit "profilename"
set type profile-name
next
end
next
end
When a FortiGate is configured as the SAML SSO IdP, FortiManager can be added as an SP.
1. On the root FortiGate, go to Security Fabric > Fabric Connectors, and edit the Security Fabric Setup connector.
2. In the Security Fabric Settings section, click Advanced Options.
3. In the Service Providers section, click Create New.
4. Enter a name and a prefix for the SP. FortiOS generates a unique prefix, but you can enter your own.
5. In SP address, enter the FortiManager address including the port number.
6. Click OK.
7. In FortiManager, go to System Settings > Admin > SAML SSO and in the Single Sign-On Mode section, click
Service Provider (SP).
8. Configure the IdP Settings:
a. For IdP Type, click Fortinet.
b. For IdP Address, enter the root FortiGate address including the port number.
c. Enter the Prefix of the SP.
d. For IdP Certificate, import the same certificate used on the root FortiGate.
e. Click Apply.
9. To verify that the configuration works, log out of FortiManager and log in using the Login via Single-Sign-On link.
From a root FortiGate IdP, you can edit each of the FortiGate SPs. For example, you can edit a FortiGate SP to generate
a new prefix, or you can add or modify SAML attributes. When you generate a new prefix value, it is propagated to the
respective downstream FortiGates.
1. Go to Security Fabric > Fabric Connectors and double-click the Security Fabric Setup card.
2. Click Advanced Options. The SAML SSO pane opens.
3. In the Service Providers table, select a device, and click Edit. The Edit Service Provider pane opens.
4. Edit the settings as needed.
5. Click OK.
The default SAML attribute type is username. When the attribute type is set to username, SSO administrator accounts
created on FortiGate SPs use the login username that is provided by the user for authentication on the root FortiGate
IdP.
Because user names might not be unique, cases can occur where the user name is the same for the SSO administrator
and the local administrator on the FortiGate SP. As a result, you might be unable to distinguish between actions taken by
the local administrator and the SSO administrator on the FortiGate SP when looking at the system log. By using a unique
SAML attribute type, such as an email address, you can create unique user names to better track what actions were
taken by each administrator.
1. On the root FortiGate (IdP), assign a unique email address to local administrator.
In this example, the local administrator name is test3.
a. Go to System > Administrators, and expand the list of local users.
b. Select the local user, and click Edit.
c. In the Type field, select Match a user on a remote server group.
d. In the Remote User Group field, select a group.
e. In the Email Address field, enter the email address.
f. Click OK.
After the administrator (test3) logs in to the FortiGate SP for the first time, SAML authentication occurs on FortiGate SP.
A new SSO administrator account is created, and the account name is now the email address instead of the login name
(test3).
1. In the SP, go to System > Administrators, and expand the list of SSO administrators.
The email address ([email protected]) is listed as the account name:
If the SAML attribute had been set to the default setting of username, the user name for the SSO administrator
account would have been (test3).
The csf_172.18.60.185 service provider was automatically added when the FortiGate SP 172.18.60.185 joined the
root FortiGate IdP in the Security Fabric.
All sp-* options, such as sp-portal-url, are set with default values when a service provider is created, but can be
modified using the CLI or GUI.
Security rating
The security rating uses real-time monitoring to analyze your Security Fabric deployment, identify potential
vulnerabilities, highlight best practices that can be used to improve the security and performance of your network, and
calculate Security Fabric scores.
To view the security rating, go to Security Fabric > Security Rating on the root FortiGate.
The Security Rating page is separated into three major scorecards: Security Posture, Fabric Coverage, and
Optimization, which 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. In the drill down report, hover the cursor over a score to view the
calculation breakdown.
The report includes the security controls that were tested against, linking to specific FSBP or PCI compliance policies.
Click the FSBP and PCI buttons to reference the corresponding standard. Users can search or filter the report results.
Certain remediations marked with an EZ symbol represent configuration recommendations that support Easy Apply. In
the panel on the right, in the Recommendations section, click Apply to apply the changes to resolve the failed security
control.
The report table can be customized by adding more columns, such as Category, to view, filter, or sort the results based
on scorecard categories. Click the gear icon to customize the table.
Users can also export the reports as CSV or JSON files by clicking the Export dropdown.
To exit the current view, click the icon beside the scorecard title to return to the summary view.
For more information about security ratings, and details about each of the checks that are performed, go to Security Best
Practices & Security Rating Feature.
Security rating licenses are required to run security rating checks across all the devices in the
Security Fabric. It also allows ratings scores to be submitted to and received from FortiGuard
for ranking networks by percentile.
See https://www.fortinet.com/support/support-services/fortiguard-security-
subscriptions/security-rating.html for information.
Security rating checks by default are scheduled to run automatically every four hours.
Security rating scores can be submitted to FortiGuard for comparison with other organizations' scores, allowing a
percentile score to be calculated. If you opt out of submitting your score, only an absolute score will be available.
The results of past security checks is available in Log & Report > Events by selecting Security Rating Events from the
event type dropdown list.
An event filter subtype can be created for the Security Fabric rating so that event logs are created on the root FortiGate
that summarize the results of a check, and show detailed information for the individual tests.
In multi VDOM mode, security rating reports can be generated in the Global VDOM for all of the VDOMs on the device.
Administrators with read/write access can run the security rating report in the Global VDOM. Administrators with read-
only access can only view the report.
On the report scorecards, the Scope column shows the VDOM or VDOMs that the check was run on. On checks that
support Easy Apply, the remediation can be run on all of the associated VDOMs.
The Security Fabric score is calculated when a security rating check is run, based on the severity level of the checks that
are passed or failed. A higher scores represents a more secure network. Points are added for passed checks and
removed for failed checks.
Critical 50
High 25
Medium 10
Low 5
To calculate the number of points awarded to a device for a passed check, the following equation is used:
The secure FortiGate multiplier is determined using logarithms and the number of FortiGate devices in the Security
Fabric.
For example, if there are four FortiGate devices in the Security Fabric that all pass the compatible firmware check, the
score for each FortiGate device is calculated with the following equation:
50
× 1.292 = 16.15 points
4
All of the FortiGate devices in the Security Fabric must pass the check in order to receive the points. If any one of the
FortiGate devices fails a check, the devices that passed are not awarded any points. For the device that failed the check,
the following equation is used to calculated the number of points that are lost:
For example, if the check finds two critical FortiClient vulnerabilities, the score is calculated with the following equation:
Scores are not affected by checks that do not apply to your network. For example, if there are no FortiAP devices in the
Security Fabric, no points will be added or subtracted for the FortiAP firmware version check.
Automation stitches
Automation stitches automate the activities between the different components in the Security Fabric, decreasing the
response times to security events. Events from any source in the Security Fabric can be monitored, and action
responses can be set up to any destination.
Automation stitches can also be used on FortiGate devices that are not part of a Security
Fabric.
Automation stitches that use cloud-based actions, such as AWS Lambda and Azure Function, have the option to delay
an action after the previous action is completed.
An automation stitch consists of two parts, the trigger and the actions. The trigger is the condition or event on the
FortiGate that activates the action, for example, a specific log, or a failed log in attempt. The action is what the FortiGate
does in response to the trigger.
Diagnose commands are available in the CLI to test, log, and display the history and settings of stitches.
Automation stitches can only be created on the root FortiGate in a Security Fabric.
To create an automation stitch, a trigger event and a response action or actions are selected. Automation stitches can be
tested after they are created.
FortiGate Select the FortiGate device to apply the automation stitch to, or select All
FortiGates to apply it to all of them.
Minimum interval (seconds) Enter a minimum time interval during which notifications for the same trigger
event will not be sent.
After the time interval elapses, an alert is sent that includes the last event since
the time interval elapsed.
4. Click OK.
The available options will vary depending on the selected event type.
2. Create an automation action:
config system automation-action
edit <name>
set action-type <option>
set email-to <names>
set email-from <string>
set email-subject <string>
set message <string>
set minimum-interval <integer>
set delay <integer>
set required {enable | disable}
set aws-api-id <string>
set aws-region <string>
set aws-domain <string>
set aws-api-stage <string>
set aws-api-path <string>
set aws-api-key <string>
set azure-app <string>
set azure-function <string>
set azure-domain <string>
set azure-function-authorization {anonymous | function | admin}
set azure-api-key <string>
set gcp-function-region <string>
set gcp-project <string>
set gcp-function-domain <string>
set gcp-function <string>
set alicloud-account-id <string>
set alicloud-region <string>
set alicloud-function-domain <string>
set alicloud-version <string>
set alicloud-service <string>
set alicloud-function <string>
set alicloud-function-authorization {anonymous | function}
set alicloud-access-key-id <string>
set alicloud-access-key-secret <string>
set protocol {http | https}
set method {post | put | get | patch | delete}
set uri <string>
set http-body <string>
set port <integer>
set headers <header>
set script <string>
set security-tag <string>
set sdn-connector <connector_name>
next
end
In the GUI, go to Security Fabric > Automation, right-click on the automation stitch and select Test Automation Stitch.
In the CLI, enter the following command:
diagnose automation test <stitch-name> <log>
The Automation menu contains eight webhook automation stitches, including an Incoming Webhook Quarantine trigger
for API calls to the FortiGate, as well as a predefined License Expired Notification that replaces the existing license
expiry alerts.
The automation stitches are available in new FortiGate installations and after upgrading from previous versions.
The following default stitches are included in the Automation menu:
l Compromised Host Quarantine
l Incoming Webhook quarantine
l HA Failover
l Network Down
l Reboot
l FortiAnalyzer Connection Down
l License Expired Notification
l Security rating Notification
To view the CLI configurations for the new automation stitches, see CLI configuration on page 232. To view the
automation stitches in the GUI, go to Security Fabric > Automation.
The automation rule Incoming Webhook Quarantine is triggered. The MAC address is quarantined in FortiGate and
an event log is created. The FortiClient UUID is quarantined by EMS on the server side.
"build":1545
The automation rule Incoming Webhook Quarantine is triggered. The MAC address is quarantined in FortiGate, and
an event log is created. The FortiClient UUID will be quarantined on the EMS server side.
config user quarantine
config targets
edit "0c:0a:00:0c:ce:b0"
config macs
edit 0c:0a:00:0c:ce:b0
set description "Quarantined by automation stitch: Incoming Webhook
Quarantine"
next
end
next
end
end
date=2020-02-14 time=15:37:48 logid="0100046600" type="event" subtype="system"
level="notice" vd="root" eventtime=1581723468644200712 tz="-0800"
logdesc="Automation stitch triggered" stitch="Incoming Webhook Quarantine"
trigger="Incoming Webhook Quarantine" stitchaction="Compromised Host Quarantine_
quarantine,Compromised Host Quarantine_quarantine-forticlient" from="log"
msg="stitch:Incoming Webhook Quarantine is triggered."
CLI configuration
Compromised host
Network down
HA failover
License expired
Reboot
next
end
Security rating
Automation stitches that use cloud-based or webhook actions have the option to delay an action after the previous action
is completed. The execution of the actions can be delayed by up to 3600 seconds (one hour).
To configure this option in the GUI, select a cloud-based action, then enter the required value, in seconds, in the action
configuration's Delay field.
To configure a delay in the CLI, use the following command:
config system automation-action
edit <name>
set action-type {aws-lambda | azure-function | google-cloud-function | alicloud-
function | webhook}
set required {enable | disable}
set delay <seconds>
next
end
Triggers
Trigger Description
l IP Ban
Security Rating Summary A summary is available for a recently run Security Rating.
l FortiGuard AntiSpam
l FortiGuard AntiVirus
l FortiGuard IPS
l FortiGate Cloud
FortiAnalyzer Event Handler The specified FortiAnalyzer event handler has occurred. See FortiAnalyzer event
handler trigger on page 238 for details.
Schedule A scheduled monthly, weekly, daily, or hourly trigger. Set to occur on a specific
minute of an specific hour on a specific day.
FortiGate Cloud-Based IOC IOC detection from the FortiGate Cloud IOC service.
This option requires an IOC license, a web filter license, and FortiCloud logging
must be enabled.
You can trigger automation stitches based on FortiAnalyzer event handlers. This allows you to define rules based on
complex correlations across devices, log types, frequencies, and other criteria.
To set up a FortiAnalyzer event handler trigger:
1. Configure a FortiGate event handler on the FortiAnalyzer
2. Configure FortiAnalyzer logging on the FortiGate on page 238
3. Configure an automation stitch that is triggered by a FortiAnalyzer event handler on page 239
On the FortiAnalyzer, configure an event handler for the automation stitch. In this example, the event handler is triggered
when an administrator logs in to the FortiGate.
3. Click OK.
1. Go to Security Fabric > Fabric Connectors and double-click the FortiAnalyzer Logging card.
2. Click Enabled and configure the settings as needed.
3. Click OK.
When a FortiAnalyzer event handler is triggered, it sends a notification to the FortiGate automation framework, which
generates a log and triggers the automation stitch.
To configure an automation stitch that is triggered by a FortiAnalyzer event handler in the GUI:
6. In the Action section, select Email and configure the email recipient and message.
7. Click OK.
To configure an automation stitch that is triggered by a FortiAnalyzer event handler in the CLI:
next
end
Sample email
The email sent by the action will look similar to the following:
Actions
The following table outlines the available automation stitch actions. Multiple actions can be added and reorganized as
needed by dragging and dropping.
Action Description
CLI Script Run one or more CLI scripts. See CLI script action on page 242 for details. See
Execute a CLI script based on CPU and memory thresholds on page 276 for an
example.
Email Send a custom email message to the selected recipients. At least one recipient
and an email subject must be specified.
The email body can use parameters from logs or previous action results.
Wrapping the parameter with %% will replace the expression with the JSON value
for the parameter, for example: %%results.source%% is the source property from
the previous action.
Access Layer Quarantine This option is only available for Compromised Host triggers.
Impose a dynamic quarantine on multiple endpoints based on the access layer.
Quarantine FortiClient via This option is only available for Compromised Host triggers.
EMS Use FortiClient EMS to block all traffic from the source addresses that are flagged
as compromised hosts.
Quarantined devices are flagged on the Security Fabric topology views. Go to the
Dashboard > Users & Devices > Quarantine widget to view and manage
quarantined IP addresses.
Quarantine via FortiNAC This option is only available for Compromised Host and Incoming Webhook
triggers.
Use FortiNAC to quarantine a client PC and disable its MAC address. See
Quarantine via FortiNAC action on page 244 for details.
Action Description
Assign VMware NSX Security This option is only available for Compromised Host triggers.
Tag If an endpoint instance in a VMware NSX environment is compromised, the
configured security tag is assigned to the compromised endpoint. See Assign
VMware NSX security tag action on page 248 and Assign VMware NSX-T
security tag action on page 251 for details.
AWS Lambda Send log data to an integrated AWS service. See AWS Lambda action on page
255 for details.
Azure Function Send log data to an Azure function. See Azure Function action on page 257 for
details.
Google Cloud Function Send log data to a Google Cloud function. See Google Cloud Function action on
page 259 for details.
AliCloud Function Send log data to an AliCloud function. See AliCloud Function action on page 261
for details.
Slack Notification Send a notification to a Slack channel. See Slack Notification action on page 264
for details.
Webhook Send an HTTP request using a REST callback. See Webhook action on page 267
for details, and Slack integration webhook on page 273 and Microsoft Teams
integration webhook on page 274 for examples.
CLI scripts can be run when an automation stitch is triggered. The scripts can be manually entered, uploaded as a file, or
recorded in the CLI console. The output of the script can be sent as an email action.
In this example, the script sets the idle timeout value to 479 minutes, and sends an email with the script output.
l To upload a script file, click Upload and locate the file on your management computer.
l To record the script in the CLI console, click >_Record in CLI console, then enter the CLI commands.
Email sample
The email sent by the action will look similar to the following:
Users can configure an automation stitch with the Quarantine via FortiNAC action with a Compromised Host or Incoming
Webhook trigger. When the automation is triggered, the client PC will be quarantined and its MAC address is disabled in
the configured FortiNAC.
In this example, the FortiNAC has been configured to join an enabled Security Fabric (see FortiNAC for more
information).
d. Click OK.
4. On a Linux PC accessible by the FortiGate, create a cURL request to trigger the automation stitch:
root@pc56:~# curl -k -X POST -H 'Authorization: Bearer ckx7d9xdzzx14Nztd1Ncr701dpwwy9' -
-data '{ "srcip": "1.1.1.1", "mac":"00:0C:29:0B:A6:16", "fctuid":
"A8BA0B12DA694E47BA4ADF24F8358E2F"}'
https://172.17.48.225:4431/api/v2/monitor/system/automation-stitch/webhook/auto_webhook
5. In FortiOS, verify the automation stitch is triggered and the action is executed:
a. Go to Log & Report > Events and select System Events to confirm that the stitch was activated.
b. Go to Security Fabric > Automation to see the last time that the stitch was triggered.
In FortiNAC, the Host View shows the status of the client PC. It is quarantined and its MAC address is disabled.
3. On a Linux PC accessible by the FortiGate, create a cURL request to trigger the automation stitch:
root@pc56:~# curl -k -X POST -H 'Authorization: Bearer ckx7d9xdzzx14Nztd1Ncr701dpwwy9' -
-data '{ "srcip": "1.1.1.1", "mac":"00:0C:29:0B:A6:16", "fctuid":
"A8BA0B12DA694E47BA4ADF24F8358E2F"}'
https://172.17.48.225:4431/api/v2/monitor/system/automation-stitch/webhook/auto_webhook
4. In FortiOS, verify the automation stitch is triggered and the action is executed:
# diagnose test application autod 2
csf: enabled root:yes
version:1592949233 sync time:Tue Jun 23 15:03:15 2020
stitch: auto_webhook
destinations: all
trigger: auto_webhook
(id:15)service=auto_webhook
If an endpoint instance in a VMware NSX environment is compromised, this action will assign the configured security tag
to the compromised endpoint.
This action is only available when the automation trigger is set to compromised host.
To set up the NSX quarantine action, you need to:
1. Configure a VMware NSX SDN connector
2. Configure an NSX security tag automation stitch
3. Configure FortiAnalyzer logging on the FortiGate
The FortiGate retrieves security tags from the VMware NSX server through the connector.
5. Click OK.
Security tags are retrieved from the VMware NSX server through the NSX SDN connector.
6. Click OK.
1. Go to Security Fabric > Fabric Connectors and double-click the FortiAnalyzer Logging card.
2. Click Enabled and configure the settings as needed.
3. Click Apply.
When an endpoint instance, such as pcui-ubuntu2, in the VMware NSX environment is compromised, the automation
stitch is triggered. The FortiGate then assigns the configured security tag, pcui-tag2 in this example, to the compromised
NSX endpoint instance.
VMware NSX SDN connectors' vCenter server and credentials can be configured so the FortiGate resolves NSX-T VMs.
The FortiGate uses the Assign VMWare NSX Security Tag automation action to assign a tag to the VM through an
automation stitch.
The FortiGate is notified of a compromised host on the NSX-T network by an incoming webhook or other means, such as
FortiGuard IOC. An automation stitch can be configured to process this trigger and action it by assigning a VMware NSX
security tag on the VM instance.
To configure an automation stitch to assign a security tag to NSX-T VMs in the GUI:
e. Click OK.
2. Configure the automation stitch:
a. Go to Security Fabric > Automation and click Create New.
b. In the Trigger section, select Incoming Webhook.
c. In the Action section, select Assign VMwareNSX Security Tag.
d. Enable Specify NSX server(s) and enter a server.
e. Enter a Security tag.
f. Click OK.
3. In NSX-T, create a cURL request to trigger the automation stitch on the FortiGate:
root@pc56:/home# curl -k -X POST -H 'Authorization: Bearer
3fdxNG08mgNg0fh4NQ51g1NQ1QHcxx' --data '{ "srcip": "10.1.30.242"}'
https://172.16.116.230/api/v2/monitor/system/automation-stitch/webhook/auto_webhook
{
"http_method":"POST",
"status":"success",
"http_status":200,
"serial":"FGVM08TM20000220",
"version":"v6.4.0",
"build":1608
}
The automation stitch is triggered and the configured tag is added to the NSX-T VM.
In FortiOS, the Security Fabric > Automation page shows the last trigger time.
To configure an automation stitch to assign a security tag to NSX-T VMs in the CLI:
3. In NSX-T, create a cURL request to trigger the automation stitch on the FortiGate:
root@pc56:/home# curl -k -X POST -H 'Authorization: Bearer
3fdxNG08mgNg0fh4NQ51g1NQ1QHcxx' --data '{ "srcip": "10.1.30.242"}'
https://172.16.116.230/api/v2/monitor/system/automation-stitch/webhook/auto_webhook
{
"http_method":"POST",
"status":"success",
"http_status":200,
"serial":"FGVM08TM20000220",
"version":"v6.4.0",
"build":1608
}
stitch: auto_webhook
destinations: all
trigger: auto_webhook
(id:15)service=auto_webhook
Delay The amount of time after the previous action before this action executes, in
seconds (0 - 3600, default = 0).
HTTP header The HTTP request header name and value. Multiple headers can be added.
Delay The amount of time after the previous action before this action executes, in
seconds (0 - 3600, default = 0).
6. Click OK.
When the automation stitch is triggered, the FortiGate shows the stitch trigger time:
In AWS, the log shows that the function was called, executed, and finished.
Delay The amount of time after the previous action before this action executes, in
seconds (0 - 3600, default = 0).
HTTP header The HTTP request header name and value. Multiple headers can be added.
6. Click OK.
When the automation stitch is triggered, the FortiGate shows the stitch trigger time:
In Azure, the function log shows that the function was called, executed, and finished:
Delay The amount of time after the previous action before this action executes, in
seconds (0 - 3600, default = 0).
HTTP header The HTTP request header name and value. Multiple headers can be added.
6. Click OK.
When the automation stitch is triggered, the FortiGate shows the stitch trigger time:
In Google Cloud, go to Logs to see the function log showing that the configured function was called, executed, and
finished:
Delay The amount of time after the previous action before this action executes, in
seconds (0 - 3600, default = 0).
HTTP header The HTTP request header name and value. Multiple headers can be added.
6. Click OK.
When the automation stitch is triggered, the FortiGate shows the stitch trigger time:
In AliCloud, the function log shows that the function was called, executed, and finished:
To configure an automation stitch with a Slack Notification action, you first need to configure an incoming webhook in
Slack. Then you can enter the webhook URL when you configure the Slack Notification action.
This example uses a Security Rating Summary trigger in the automation stitch with two Slack Notification actions with
different notification messages. One message is a custom message, and the other is for the Security Rating Summary
log with a 90 second delay.
3. Add an Incoming Webhook to a channel in the workspace (see Sending messages using Incoming Webhooks for
more details).
4. Activate the Incoming Webhook, and copy the Webhook URL to the clipboard.
Name slack1
Delay 0
Name slack2
Delay 90
Message %%log%%
5. Click OK.
6. Run the automation stitch to trigger the action.
end
3. Configure the automation stitch:
config system automation-stitch
edit "auto-rating"
set status enable
set trigger "auto-rating"
set action "slack1" "slack2"
next
end
4. Trigger the automation stitch.
The notification action is triggered in FortiGate.
The message you entered in the automation stitch is delivered to the Slack channel.
Webhook action
The webhook automation stitch action makes HTTP and HTTPS requests to a specified server, with custom headers,
bodies, ports, and methods. It can be used to leverage the ubiquity of HTML requests and APIs to integrate with many
other tools.
The URI and HTTP body can use parameters from logs or previous action results. Wrapping
the parameter with %% will replace the expression with the JSON value for the parameter, for
example: %%results.source%% is the source property from the previous action.
In this example, a specific log message (failed administrator log in attempt) triggers the FortiGate to send the contents of
the log to a server. The server responds with a generic reply. This example assumes that the server is already
configured and able to communicate with the FortiGate.
Delay The amount of time after the previous action before this action executes, in
seconds (0 - 3600, default = 0).
7. Click OK.
3. On the FortiGate, go to Log & Report > Events and select System Events to confirm that the stitch was activated.
4. Go to Security Fabric > Automation to see the last time that the stitch was triggered.
Diagnose commands
l Enable log dumping:
# diagnose test application autod 1
autod dumped total:1 logs, num of logids:1
autod log dumping is enabled
stitch: badLogin
destinations: all
trigger: badLogin
stitch: badLogin
actions:
Send Log To Server:
done: 1 relayed to: 1 relayed from: 1
last trigger:Wed Jul 10 12:14:14 2019
last relay:Wed Jul 10 12:14:14 2019
logid2stitch mapping:
id:32002 local hit: 3 relayed to: 3 relayed from: 3
badLogin
quarantine-forticlient:
flags:4
stats: total:0 cur:0 done:0 drop:0
quarantine-nsx:
flags:4
stats: total:0 cur:0 done:0 drop:0
ban-ip:
flags:7
stats: total:0 cur:0 done:0 drop:0
aws-lambda:
flags:11
stats: total:21 cur:0 done:21 drop:0
webhook:
flags:11
stats: total:6 cur:0 done:6 drop:0
cli-script:
flags:10
stats: total:4 cur:0 done:4 drop:0
azure-function:
flags:11
stats: total:0 cur:0 done:0 drop:0
google-cloud-function:
flags:11
stats: total:0 cur:0 done:0 drop:0
alicloud-function:
flags:11
stats: total:20 cur:0 done:20 drop:0
l Enable debug output and turn on automation debug messages for about 30 minutes:
# diagnose debug enable
# diagnose debug application autod -1
__auto_generate_generic_curl_request()-358: Generating generic automation CURL request
for action (Send Log To Server).
__auto_generate_generic_curl_request()-406: Generic automation CURL request POST data
for action (Send Log To Server):
date=2019-05-30 time=16:44:43 logid="0100032002" type="event" subtype="system"
level="alert" vd="root" eventtime=1559259884209355090 tz="-0700" logdesc="Admin login
failed" sn="0" user="admin" ui="http(10.6.30.254)" method="http" srcip=10.6.30.254
dstip=10.6.30.5 action="login" status="failed" reason="passwd_invalid"
msg="Administrator admin login failed from http(10.6.30.254) because of invalid
password"
A webhook can be created to post messages and notifications to Slack. For information about using incoming webhooks
in Slack, see https://api.slack.com/incoming-webhooks.
In this example, a configuration change triggers the FortiGate to post a message to Slack.
6. Click OK.
next
end
The URI is the URL from the incoming webhook created in Teams. The HTTP body can also contain log
parameters.
7. Click OK.
For information about more advanced messages that can be configured and sent to the
webhook, see https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-
connectors/how-to/connectors-using
Automation stitches can be created to run a CLI script and send an email message when CPU or memory usage
exceeds specified thresholds.
In this example, two automation stitches are created that run a CLI script to collect debug information, and then email the
results of the script to a specified email address when CPU usage threshold is exceeded or memory usage causes the
FortiGate to enter conserve mode.
Automation stitches that use High CPU and Conserve Mode triggers can only be created in the
CLI. Once create, they can be edited in the GUI.
Where:
cpu-use-threshold Threshold at which CPU usage is reported, in percent of total possible CPU
utilization (default = 90).
memory-use-threshold-extreme Threshold at which memory usage is considered extreme, and new sessions are
dropped, in percent of total RAM (default = 95).
memory-use-threshold-green Threshold at which memory usage forces the FortiGate to exit conserve mode, in
percent of total RAM (default = 82).
memory-use-threshold-red Threshold at which memory usage forces the FortiGate to enter conserve mode,
in percent of total RAM (default = 88).
Results
When FortiGate enters conserve mode due to the memory-use-threshold-red being exceeded, the GUI displays a
notice, and the auto_high_memory automation stitch is triggered, causing the CLI script to run and the results of the
script to be emailed to the specified address.
Cloud SDN connectors provide integration and orchestration of Fortinet products with public and private cloud solutions.
In a typical cloud environment, resources are dynamic and often provisioned and scaled on-demand. By using an SDN
connector, you can ensure that changes to cloud environment attributes are automatically updated in the Security
Fabric.
To protect the East-West or North-South traffic in these environments, the FortiGate uses the SDN connector to sync the
dynamic addresses that these volatile environments use. You can then configure the dynamic address objects as
sources or destinations for firewall policies. When you make changes to cloud environment resources, such as moving
them to a new location or assigning different IP addresses to them, you do not need to modify the policy in FortiOS, as
the SDN connector syncs changes to the cloud address objects.
These configurations consist of three primary steps:
1. Configure the cloud SDN connector to connect your FortiGate and public or private cloud account.
2. Create dynamic address objects to use the SDN connector. Use filters to sync only cloud address objects that you
require.
3. Apply the dynamic address objects to your firewall policy to protect your traffic.
This chapter explores the steps in detail and describes how to connect to each currently supported cloud platform. This
chapter does not discuss cloud account role-based or permission requirements. The respective cloud documents
contain this information.
The following external connector categories are available in the Security Fabric: Public SDN, Private SDN,
Endpoint/Identity, and Threat Feeds.
If VDOMs are enabled, SDN and Threat Feeds connectors are in the global settings, and
Endpoint/Identity connectors are per VDOM.
You can use SDN connectors to connect your FortiGate to public and private cloud solutions. By using an SDN
connector, you can ensure that changes to cloud environment attributes are automatically updated in the Security
Fabric. You can use SDN connector address objects to create policies that provide dynamic access control based on
cloud environment attribute changes. There is no need to manually reconfigure addresses and policies whenever
changes to the cloud environment occur.
There are four steps to creating and using an SDN connector:
1. Gather the required information. The required information depends on which public or private cloud solution
SDN connector you are configuring.
2. Creating the SDN connector on page 283
3. Creating an SDN connector address on page 283
4. Adding the address to a firewall policy on page 285
The following provides general instructions for creating an SDN connector and using the dynamic address object in a
firewall policy. For instructions for specific public and private cloud solutions, see the relevant topic in this guide. For
advanced scenarios regarding SDN connectors, see the appropriate FortiOS 6.4 cloud platform guide.
The available CLI commands vary depending on the selected SDN connector type.
You can set filtering conditions using multiple entries with AND ("&") or OR ("|"). When both AND and OR are
specified, AND is interpreted first, then OR.
e. Configure other settings as desired.
f. Click OK.
4. Ensure that the SDN connector resolves dynamic firewall IP addresses as configured:
a. Go to Policy & Objects > Addresses.
b. Hover over the address that you created to see a list of IP addresses for instances that satisfy the filter that you
configured. In this case, the IP addresses of instances that belong to the specified security group display:
2. Ensure that the SDN connector resolves dynamic firewall IP addresses as configured by running show. The
following shows example output:
config firewall address
edit "ali-address-security"
set type dynamic
config list
edit "10.0.0.16"
next
edit "10.0.0.17"
next
edit "10.0.20.20"
next
end
...
next
end
The available CLI commands vary depending on the selected SDN connector type.
You can use an SDN connector address as the source or destination address in a policy.
Connector tooltips
In Security Fabric > External Connectors, hover over an SDN connector to view a tooltip that shows basic configuration
information.
Button Information
View Connector Objects Connector's dynamic objects, such as filters and instances.
View Policies List of policies that use the dynamic addresses from the connector.
View Automation Rules List of automation actions that use the connector.
FortiOS automatically updates dynamic addresses for AliCloud using an AliCloud SDN connector, including mapping the
following attributes from AliCloud instances to dynamic address groups in FortiOS:
l ImageId
l InstanceId
l SecurityGroupId
l VpcId
l VSwitchId
l TagKey
l TagValue
interval is in seconds.
2. Create a dynamic firewall address for the configured AliCloud SDN connector:
a. Go to Policy & Objects > Addresses.
b. Click Create New, then select Address.
c. Configure the address as shown, selecting the desired filter in the Filter dropdown list. In this example, the
address will automatically populate and update IP addresses only for AliCloud instances that belong to the
specified security group:
3. Ensure that the AliCloud SDN connector resolves dynamic firewall IP addresses:
a. Go to Policy & Objects > Addresses.
b. Hover over the address created in step 2 to see a list of IP addresses for instances that belong to the security
group configured in step 2:
FortiOS automatically updates dynamic addresses for AWS using an AWS SDN connector, including mapping attributes
from AWS instances to dynamic address groups in FortiOS.
Configuring the SDN connector using the GUI, then checking the configuration using the CLI is recommended.
d. In the Secret access key field, enter the secret access key accompanying the above access key.
e. In the Region name field, enter the region name. Refer to AWS Regions and Endpoints for the desired region
name.
f. In the VPC ID field, enter the VPC ID within the specified region you desire to cover with the SDN connector.
g. Click OK.
2. Check the configuration using the CLI:
config system sdn-connector
edit "<connector-name>"
show
The output resembles the following:
config system sdn-connector
edit "<connector-name>"
set access-key "<example-access-key>"
set secret-key ENC <example-secret-key>
set region "us-west-2"
set vpc-id "vpc-e1e4b587"
set update-interval 1
next
end
If you see that the SDN connector is not enabled in Security Fabric > External Connectors in the GUI, run the
following commands to enable the SDN connector:
diagnose deb application awsd -1
diagnose debug enable
The output may display an error like the following:
FGT # awsd sdn connector AWS_SDN prepare to update
awsd sdn connector AWS_SDN start updating
aws curl response err, 403
<?xml version="1.0" encoding="UTF-8"?>
<Response><Errors><Error><Code>UnauthorizedOperation</Code><Message>You are not
authorized to perform this
operation.</Message></Error></Errors><RequestID>8403cc11-b185-41da-ad6d-
23bb4db7d00a</RequestID></Response>
awsd curl failed 403
awsd sdn connector AWS_SDN failed to get instance list
aws curl response err, 403
{"Message":"User: arn:aws:iam::956224459807:user/jcarcavallo is not authorized to
perform: eks:ListClusters on resource: arn:aws:eks:us-east-
1:956224459807:cluster/*"}
awsd sdn connector AWS_SDN get EKS cluster list failed
awsd sdn connector AWS_SDN list EKS cluster failed
awsd sdn connector AWS_SDN start updating IP addresses
awsd sdn connector AWS_SDN finish updating IP addresses
awsd reap child pid: 569
In this case, you must configure power user access for the current administrator in the AWS management console:
e. In the Filter field, add the desired filters. The following filters are supported:
AZ placement.availabilityzone us-east-1a
VPC ID VpcId
1. Assume that you want to boot up another instance with an IP address of 34.222.246.178, which is currently
stopped. This instance belongs to the security group that the aws-ec2 address is filtering for. In the AWS
management portal, start the instance.
2. Verify that the instance is running.
3. At this point, running show again shows the SDN connector has automatically populated and added the
34.222.246.178 instance.
config firewall address
edit "aws-ec2"
set type dynamic
set sdn "<connector-name>"
FortiOS automatically updates dynamic addresses for Azure using Azure SDN connector, including mapping attributes
from Azure instances to dynamic address groups in FortiOS.
d. Click OK.
2. Create a dynamic firewall address for the Azure connector.
a. Go to Policy & Objects > Addresses and click Create New > Address.
b. From the Type dropdown list, select Dynamic.
c. From the Sub Type dropdown list, select Fabric Connector Address.
d. From the SDN Connector dropdown list, select the Azure SDN connector.
e. In the Filter field, add filters as desired. The Azure SDN connector supports the following filters:
l vm=<VM name>
l securitygroup=<nsg id>
l vnet=<VNet id>
l subnet=<subnet id>
l tag.<key>=<value>
l servicetag=<value>
l tag.<key>=<value>
f. Click OK.
g. Hover the cursor over the address name to see the dynamic IP addresses that the connector resolves.
Cisco ACI (Application Centric Infrastructure) SDN connectors can be used in dynamic firewall addresses.
The Fortinet SDN Connector for Cisco ACI and Nuage Networks is a standalone connector that connects to SDN
controllers within Cisco ACI and Nuage Networks. You must configure a connection to the Fortinet SDN connector in
FortiOS to query the dynamic addresses.
To verify the dynamic firewall IPs are resolved by the SDN connector in the GUI:
To verify the dynamic firewall IPs are resolved by the SDN connector in the CLI:
ClearPass Policy Manager (CPPM) is a network access system that can send information about authenticated users to
third party systems, such as a FortiGate or FortiManager.
In this example, communications are established between CPPM and FortiManager, and then the FortiManager
forwards information to a managed FortiGate. On the FortiGate, the user information can be used in firewall policies and
added to FSSO dynamic addresses.
Establish communications between FortiManager and CPPM so that FortiManager can synchronize CPPM user groups.
See Creating a ClearPass connector in the FortiManager Administration Guide.
5. Click OK.
To add the local FSSO user group to a firewall policy in the GUI:
3. Click in the Source field and add the fsso-group user group.
To add the local FSSO user group to a firewall policy in the CLI:
Verification
To verify that a user was added to the FSSO list on the FortiGate:
2. On the FortiGate, go to Monitor > Firewall User Monitor to verify that the user was added.
The user group cp_test_FSSOROLE is listed separately because the user is a member of that group on the CPPM.
edit "CN=group1,OU=Testing,DC=Fortinet-FSSO,DC=COM"
set server-name "Local FSSO Agent" <----- !!!
next
end
FortiOS automatically updates dynamic addresses for GCP using a GCP SDN connector, including mapping attributes
from GCP instances to dynamic address groups in FortiOS.
Once the connector is successfully configured, a green indicator appears at the bottom right corner. If the indicator
is red, the connector is not working. See Troubleshooting GCP SDN Connector.
4. Create a dynamic firewall address for the configured GCP SDN connector:
a. Go to Policy & Objects > Addresses. Click Create New, then select Address.
b. Configure the address:
i. Name: Enter the desired name.
ii. Type: Select Dynamic.
iii. Fabric Connector Type: Select Google Cloud Platform (GCP).
iv. Filter: The SDN connector automatically populates and updates only instances that match this filtering
condition. Currently GCP supports the following filters:
l id=<instance id> : This matches an VM instance ID.
l label.<gcp label key>=<gcp label value> : This matches a free form GCP label key and
its value.
In the example, the filter is set as 'network=default & zone=us-central-1f’. This configuration
populates all IP addresses that belong to the default network in the zone us-central-1f.
You can set filtering conditions using multiple entries with AND ("&") or OR ("|"). When both AND and OR
are specified, AND is interpreted first, then OR.
Note that wildcards (such as the asterisk) are not allowed in filter values.
v. Click OK.
The address has been created. Wait for a few minutes before the setting takes effect. You will know that the
address is in effect when the exclamation mark disappears from the address entry. When you hover over the
address, you can see the list of populated IP addresses.
If the exclamation mark does not disappear, check the address settings.
FortiOS can automatically update dynamic addresses for IBM Cloud using an SDN connector.
d. Click OK.
e. Click Create New, then select IBM Cloud.
g. Click OK.
2. Create dynamic firewall addresses for the configured connectors:
a. Go to Policy & Objects > Addresses.
b. Click Create New > Address.
c. From the Type dropdown list, select Dynamic.
d. From the Sub Type dropdown list, select Fabric Connector Address.
e. From the SDN Connector dropdown list, select the IBM SDN connector.
f. In the Filter field, add the desired filters. The following filters are supported:
l <InstanceId>
l <InstanceName>
l <ImageId>
l <ImageName>
l <Architecture>
l <Profile>
l <Vpc>
l <Zone>
l <Subnet>
l <ResourceGroup>
g. Click OK.
h. Click Create New > Address.
j. Click OK.
3. Ensure that the connectors resolve dynamic firewall IP addresses:
a. Go to Policy & Objects > Addresses.
b. Hover over the addresses created in step 2 to see a list of IP addresses that the connector has resolved:
The following topics provide information about configuring Kubernetes SDN connectors:
l AWS Kubernetes (EKS) SDN connector using access key on page 307
l Azure Kubernetes (AKS) SDN connector using client secret on page 309
l GCP Kubernetes (GKE) SDN connector using service account on page 312
l Oracle Kubernetes (OKE) SDN connector using certificates on page 314
l Private cloud K8s SDN connector using secret token on page 318
AWS SDN connectors support dynamic address groups based on AWS Kubernetes (EKS) filters.
1. Go to Security Fabric > External Connectors. Click Create New, then select Amazon Web Services (AWS).
Configure the SDN connector as desired. See AWS SDN connector using certificates on page 288
2. Go to Policies & Objects > Addresses. Click Create New > Address to create a dynamic firewall address for the
configured SDN connector using the supported Kubernetes filter.
3. From the Type dropdown list, select Dynamic.
4. From the Sub Type dropdown list, select Fabric Connector Address.
5. From the SDN Connector dropdown list, select the desired SDN connector.
6. In the Filter field, add the desired filters. The following filters are supported:
Filter Description
Filter Description
Azure SDN connectors support dynamic address groups based on Azure Kubernetes (AKS) filters.
2. Create a dynamic firewall address for the configured K8s SDN connector:
a. Go to Policy & Objects > Addresses.
b. Click Create New, then select Address.
c. From the Type dropdown list, select Dynamic.
d. From the Sub Type dropdown list, select Fabric Connector Address.
e. From the SDN Connector dropdown list, select the desired SDN connector.
f. In the Filter field, add the desired filter. The following filters are supported:
Filter Description
In this example, the address is configured to automatically populate and update IP addresses only for
instances that belong to the zhmKC cluster:
next
end
Google Cloud Platform (GCP) SDN connectors support dynamic address groups based on GCP Kubernetes Engine
(GKE) filters.
c. Click OK.
2. Go to Policies & Objects > Addresses and create a dynamic firewall address for the configured SDN connector
using the supported Kubernetes filter.
3. To filter out the Kubernetes IP addresses, select the address filter or filters. The following filters are supported:
Filter Description
Filter Description
In this example, the GCP SDN connector will automatically populate and update IP addresses only for instances
that belong to the zhm-kc3 cluster:
OCI SDN connectors support dynamic address groups based on Oracle Kubernetes (OKE) filters.
2. Create dynamic firewall addresses for the configured SDN connector with supported Kubernetes filter:
a. Go to Policy & Objects > Addresses.
b. Click Create New, then select Address.
c. In the Filter field, select the desired filters. The following filters are supported:
Filter Description
FortiOS automatically updates dynamic and cluster IP addresses for Kubernetes (K8s) by using a K8s SDN connector,
enabling FortiOS to manage K8s pods as global address objects, as with other connectors. This includes mapping the
following attributes from K8s instances to dynamic address groups in FortiOS:
Filter Description
Label.XXX Filter service or node IP addresses with the given label XXX. For example: K8S_
Label.app=nginx.
FortiOS 6.2.3 and later collects cluster IP addresses in addition to external IP addresses for exposed K8s services.
There is no maximum limit for the number of IP addresses populated with the filters.
e. In the Secret token field, enter the token that you obtained in Obtaining the IP address, port, and secret token in
Kubernetes.
f. Configure the other fields as desired.
2. Create a dynamic firewall address for the configured K8S SDN connector:
a. Go to Policy & Objects > Addresses.
b. Click Create New, then select Address.
c. Configure the address as shown, selecting the desired filter in the Filter dropdown list. In this example, the
K8s SDN connector will automatically populate and update IP addresses only for node instances that match
the specified node name:
set server "<IP address obtained in Obtaining the IP address, port, and secret
token in Kubernetes>"
set server-port <Port obtained in Obtaining the IP address, port, and secret token
in Kubernetes>
set secret-token <Secret token obtained in Obtaining the IP address, port, and
secret token in Kubernetes>
set update-interval 30
next
end
2. Create a dynamic firewall address for the configured K8s SDN connector with the supported K8s filter. In this
example, the K8s SDN connector will automatically populate and update IP addresses only for node instances that
match the specified node name:
config firewall address
edit "k8s_nodename"
set type dynamic
set sdn "kubernetes1"
set filter "K8S_NodeName=van-201669-pc1"
next
end
3. Confirm that the K8s SDN connector resolves dynamic firewall IP addresses using the configured filter:
config firewall address
edit "k8s_nodename"
set type dynamic
set sdn "kubernetes1"
set filter "K8S_NodeName=van-201669-pc1"
config list
edit "172.16.65.227"
next
end
next
end
To verify the SDN connector resolves the dynamic firewall IP addresses in the GUI:
To verify the SDN connector resolves the dynamic firewall IP addresses in the CLI:
ADDR(192.168.20.92)
ADDR(192.168.20.240)
You can configure SDN connector integration with Oracle Cloud Infrastructure (OCI).
4. Click OK.
5. At this stage, you must register the certificate's fingerprint to the specified OCI user.
a. Go to the OCI user, then API Keys > Add Public Key.
b. If you selected the Fortinet_Factory certificate in step 2f, do the following:
i. In FortiOS, go to System > Certificate. Select Fortinet_Factory, then click Download.
ii. You now have the Fortinet_Factory.cer file. Create a public key file in PEM format from it, using a freely
available tool of your choice such as OpenSSL.
c. Copy and paste the content of the certificate PEM key file in the Add Public Key window in OCI. Click Add.
8. Click OK.
2. Create a dynamic firewall address for the SDN connector with a supported filter:
config firewall address
edit "oci-address-1"
set type dynamic
set sdn "oci1"
set filter "CompartmentName=DevelopmentEngineering"
next
end
To confirm that dynamic firewall addresses are resolved by the SDN connector:
2. In the GUI, go to Policy & Objects > Addresses and hover the cursor over the address name.
The next step is to create an address that will be used as an address group or single address that acts as the
source/destination for firewall policies. The address is based on IP addresses and contains VM instances' IP addresses.
No matter what changes occur to the instances, the SDN connector populates and updates the changes automatically
based on the specified filtering condition so that administrators do not need to reconfigure the address content manually.
Appropriate firewall policies using the address are applied to instances that are members of the address.
1. Go to Policy & Objects > Address. Click Create New, then select Address.
2. Configure the address as follows:
a. Name: Name the address as desired.
b. Type: Select Dynamic.
c. Sub Type: Select Fabric Connector Address.
d. SDN Connector: Select openstack.
e. Filter: The SDN connector automatically populates and updates only IP addresses belonging to the specified
filter that matches the condition. OpenStack Horizon connectors support the following filters:
i. id=<instance id>: This matches a VM instance ID.
ii. name=<instance name>: This matches a VM instance name.
iii. flavor=<instance flavor name>: This matches an instance flavor name.
iv. keypair=<key pair name>: This matches a key pair name.
v. network=<net name>: This matches a network name.
vi. project=<project name>: This matches a project name.
vii. availabilityzone=<zone name>: This matches an availability zone name.
viii. servergroup=<group name>: This matches a server group name.
ix. securitygroup=<security group name>: This matches a security group name.
x. metadata.<key>=<value>: This matches metadata with its key and value pair.
You can set filtering conditions using multiple entries with AND ("&") or OR ("|"). When both AND and OR are
specified, AND is interpreted first, then OR.
For example, you could enter flavor=m1.nano&project=admin. In this case, IP addresses of instances that
match both the flavor name and project name are populated. Wildcards (asterisks) are not allowed in values.
In this example, let's use project=admin, assuming the project name is admin.
5. After a few minutes, the new address takes effect. Hover your cursor on the address to see a list of IP addresses
and instances with the project name "admin".
Dynamic addresses for VMware ESXi and vCenter servers can be automatically updated by using a VMware ESXi
SDN connector, including mapping the following attributes from VMware ESXi and vCenter objects to dynamic address
groups in FortiOS:
l vmid
l host
l name
l uuid
l vmuuid
l vmnetwork
l guestid
l guestname
l annotation
2. Create a dynamic firewall address for the configured VMware ESXi SDN connector:
a. Go to Policy & Objects > Addresses.
b. Click Create New, then select Address.
c. Configure the address as shown, selecting the desired filter in the Filter dropdown list. In this example, the
VMware ESXi fabric connector will automatically populate and update IP addresses only for instances that
belong to VLAN80:
3. Ensure that the VMware ESXi SDN connector resolves dynamic firewall IP addresses:
a. Go to Policy & Objects > Addresses.
b. Hover over the address created in step 2 to see a list of IP addresses for instances that belong to VLAN80 as
configured in step 2:
edit "vmware-network"
set type dynamic
set sdn "vmware1"
set filter "vmnetwork=VLAN80"
next
end
3. Confirm that the VMware ESXi SDN connector resolves dynamic firewall IP addresses using the configured filter:
config firewall address
edit "vmware-network"
set type dynamic
set sdn "vmware1"
set filter "vmnetwork=VLAN80"
config list
edit "192.168.8.240"
next
end
next
end
This feature provides SDN connector configuration for VMware NSX-T manager. You can import specific groups, or all
groups from the NSX-T Manager.
Address:2.2.2.0
Address:4.4.4.0
Address:5.5.5.0
To view the dynamic firewall IP addresses that are resolved by the SDN connector in the GUI:
1. Go to Policy & Objects > Addresses to view the IP addresses resolved by an SDN connector.
To view the dynamic firewall IP addresses that are resolved by the SDN connector in the CLI:
end
next
end
You can configure multiple instances configured for every SDN connector. The specific connector instance must be
specified when creating a dynamic firewall address.
This topic provides examples of how to create two Microsoft Azure SDN connectors and use them in new dynamic
firewall addresses.
To create and use two new SDN connectors with the CLI:
2. Create new dynamic firewall addresses that use the new connectors:
config firewall address
edit "azure-address-location1"
set type dynamic
set color 2
set sdn azure1
set filter "location=WestUs"
next
edit "azure-address-location2"
set type dynamic
set color 2
set sdn azure2
set filter "location=NorthEurope"
next
end
To create and use two new SDN connectors with the GUI:
2. Create new dynamic firewall addresses that use the new connectors:
a. Go to Policy and Objects > Addresses and click Create New > Address in the toolbar.
b. Enter a name for the address, and select Fabric Connector Address for the Type.
c. Select one of the previously created SDN connectors from the SDN Connector drop down list.
d. Configure the rest of the required information, then click OK to create the address.
e. Repeat the above steps to create the second address, selecting the other Microsoft Azure SDN connector.
When configuring dynamic address mappings for filters in SDN connectors for Azure, GCP, OpenStack, Kubernetes,
and AliCloud, FortiGate can query the filters automatically.
Wildcards are supported for SDN connectors when configuring dynamic address filters.
The following SDN connector types are currently supported:
l AWS
l Azure
l Google Cloud Platform
l Kubernetes
l OpenStack
l Oracle Cloud Infrastructure
l VMware ESXi
d. Click OK.
3. In the address table, hover over the address to view what IPs it resolves to.
2. Create the dynamic firewall address and verify where the IP addresses resolve to:
config firewall address
edit "aws-address-1"
set type dynamic
set sdn "aws1"
Endpoint/Identity connectors
SSO fabric connectors integrate SSO authentication into the network. This allows users to enter their credentials only
once, and have those credentials reused when accessing other network resources through the FortiGate.
The following fabric connectors are available:
l Fortinet single sign-on agent on page 341
l Poll Active Directory server on page 342
l Symantec endpoint connector on page 342
l RADIUS single sign-on agent on page 348
l Exchange Server connector on page 351
4. Fill in the Name, and Primary FSSO Agent server IP address or name and Password.
then click Edit to select the Users, Groups, and Organizational Units. Optionally, enable Proactively retrieve
from LDAP server and configure the Search filter and Interval.
8. Click OK.
The FortiGate unit can authenticate users and allow them network access based on groups membership in Windows
Active Directory (AD).
4. Fill in the Server IP/Name, User, and Password for the AD server.
5. Select the LDAP server from the list.
6. If necessary, disable Enable Polling. This can be used to temporarily stop the FortiGate from polling security event
logs on the Windows logon server, for troubleshooting purposes.
7. Click OK.
With the Fabric connector for Symantec Endpoint Protection Manager (SEPM), you can use the client IP information
from SEPM to assign to dynamic IP addresses on FortiOS.
When communication between FortiGate and SEPM is established, FortiGate polls every minute for updates via TLS
over port 8446. You can use the CLI to change the default one minute polling interval.
For example, you can create a dynamic Fabric Connector IP address subtype and use it in firewall policies as the source
address. The dynamic IP address contains all IP addresses sent by SEPM.
This example shows a dynamic IP address with SEPM and one client PC managed by SEPM using FortiGate as the
default gateway.
1. In SEPM, create client packages for client hosts and group them into SEPM groups.
You can install packages locally on clients or download them directly from SEPM.
2. When a package is installed on the client host, the host is considered managed by SEPM.
Even if the host has multiple interfaces, only one IP per host is displayed.
e. To limit the domain or group that is monitored, enter them in the requisite fields.
f. Click OK.
When the connection is established, you can see a green up arrow in the bottom right of the card. You might
need to refresh your browser to see the established connection.
2. Go to Policy & Objects > Addresses and click Create New > Address:
a. Fill in the address Name.
b. Set Type to Dynamic.
c. Set Sub Type to Fabric Connector Address.
d. Set SDN Connector to the fabric connector that you just created.
e. Add Filters as needed.
f. Click OK.
Filter options are only available for active computers that are configured and registered
in SEPM. Free-form filters can be created manually by clicking Create and entering the
filter, in the format: filter_type=value.
Possible manual filter types are: GroupName, GroupID, ComputerName,
ComputerUUID, and OSName. For example: GroupName=MyGroup.
3. Go to Policy & Objects > Addresses and hover the cursor over the name of the new address to see the resolved IP
addresses of the host.
4. Go to Policy & Objects > Firewall Policy, click Create New, and add a policy that uses the dynamic IP address.
1. On the client PC, check that it is managed by SEPM to access the Internet.
2. On the FortiGate, you can check in Dashboard > FortiView Sources and Log & Report > Forward Traffic.
Because this traffic is not authenticated traffic but is based on source IP address only, it is
not shown in the GUI firewall monitor or in the diagnose firewall auth list CLI
command.
edit "172.16.200.187"
next
end
next
end
Output is sent every minute (default). All IPv4 learned from SEPM. IPv6 also sent but not
yet supported.
format
With RADIUS single sign-on (RSSO), a FortiGate can authenticate users who have authenticated on a remote RADIUS
server. Based on which user group the user belongs to, the security policy applies the appropriate UTM profiles.
The FortiGate does not interact with the remote RADIUS server; it only monitors RADIUS accounting records that the
server forwards (originating from the RADIUS client). These records include the user IP address and user group. The
remote RADIUS server sends the following accounting messages to the FortiGate:
Message Action
Start If the information in the start message matches the RSSO configuration on the
FortiGate, the user is added to the local list of authenticated firewall users.
Message Action
Stop The user is removed from the local list of authenticated firewall users because the
user session no longer exists on the RADIUS server.
You can configure an RSSO agent connector using the FortiOSGUI; however, in most cases, you will need to use the
CLI. There are some default options you may need to modify, which can only be done in the CLI.
The value entered in Use RADIUS Shared Secret must be identical to what the remote
RADIUS server uses to authenticate when it sends RADIUS accounting messages to
the FortiGate.
You should enable Send RADIUS Responses because some RADIUS servers
continue to send the same RADIUS accounting message several times if there is no
response.
g. Click OK.
2. Edit the network interface:
a. Go to Network > Interfaces.
b. Double-click the interface that will receive the RADIUS accounting messages. The Edit Interface pane opens.
c. In the Administrative Access section, select the RADIUS Accounting checkbox. This will open listening for port
1813 on this interface. The FortiGate will then be ready to receive RADIUS accounting messages.
d. Click OK.
3. Create a local RSSO user group:
a. Go to User & Authentication > User Groups.
b. Click Create New.
c. Enter the group name.
If your users are in multiple groups, you will need to add multiple local RSSO user
group.
If the RADIUS attribute value used to map users to a local RSSO group is different than
the RADIUS attribute in the RADIUS accounting messages forwarded by the server,
you must change it in the CLI.
f. Click OK.
4. Edit the local RSSO agent to modify default options using the CLI.
For example, the default value for rsso-endpoint-attribute might work in common remote access scenarios
where users are identified by their unique Calling-Station-Id, but in other scenarios the user name might be in
a different attribute.
config user radius
edit "Local RSSO Agent"
set rsso-endpoint-attribute <attribute>
set sso-attribute <attribute>
next
end
Verification requires a working remote RADIUS server configured for RADIUS accounting forwarding and wireless or
wired clients that use RADIUS for user authentication.
For a quick test, you can use one of the publicly available RADIUS test tools to send RADIUS accounting start and stop
messages to the FortiGate. You can also use radclient.
1. In radclient, enter the RADIUS attributes. These attributes are then executed with the FortiGate IP parameters
(sends accounting messages to port 1813) and shared password you configured. -x is used for verbose output:
2. Verify that the user is in the local firewall user list with the correct type (rsso) and local firewall group (rsso-
group1):
# diagnose firewall auth l
10.1.100.185, test2
type: rsso, id: 0, duration: 5, idled: 5
flag(10): radius
server: vdom1
packets: in 0 out 0, bytes: in 0 out 0
group_id: 3
group_name: rsso-group-1
FortiGate can collect additional information about authenticated users from corporate Microsoft Exchange Servers. After
a user logs in, the additional information can be viewed in various parts of the GUI.
The Exchange connector must be mapped to the LDAP server that is used for authentication.
The following attributes are retrieved:
Kerberos Key Distribution Center (KDC) automatic discovery is enabled by default. The FortiGate must be able to use
DNS to resolve the KDC IP addresses, otherwise the FortiGate will be unable to retrieve additional user information from
the Exchange Server.
KDC automatic discovery can be disabled, and one or more internal IP addresses that the FortiGate can reach can be
configured for KDC.
The Override server IP address is enabled when the IP address of the Exchange server cannot be resolved by DNS and
must be entered manually.
If Auto-discover KDC is disabled, one or more KDC IP addresses can be manually entered.
8. Click OK.
5. Click OK.
Verification
addr[3]: 2003::131
addr[4]: 2001::131
srv[1]: name(fsso-core-DC.Fortinet-FSSO.COM) port(88) priority(0) weight(100)
addr[0]: 10.6.30.16
addr[1]: 172.16.200.16
srv[2]: name(w2k12-serv1.Fortinet-FSSO.COM) port(88) priority(0) weight(100)
addr[0]: 10.1.100.131
addr[1]: 172.16.200.131
addr[2]: 10.6.30.131
addr[3]: 2001::131
addr[4]: 2003::131
wad_rpc_nspi_dns_on_discover_kdc_done(1787): Received response for DNS autodiscover req
(0x7f938dfe8050) query(_kerberos._udp.FORTINET-FSSO.COM) n_rsp(3)
To check the collected information after the user has been authenticated:
1. In the GUI, go to Dashboard > Users & Devices, expand the Firewall Users widget, and hover over the user name.
2. In the CLI, run the following diagnose command:
# diagnose wad user info 20 test1
'username' = 'test1'
'sourceip' = '10.1.100.185'
'vdom' = 'root'
'cn' = 'test1'
'givenName' = 'test1'
'sn' = 'test101'
'userPrincipalName' = '[email protected]'
'telephoneNumber' = '604-123456'
'mail' = '[email protected]'
'thumbnailPhoto' = '/tmp/wad/user_info/76665fff62ffffffffffffffffffff75ff68fffffffffa'
'company' = 'Fortinet'
'department' = 'Release QA'
'memberOf' = 'CN=group321,OU=Testing,DC=Fortinet-FSSO,DC=COM'
'memberOf' = 'CN=g1,OU=Testing,DC=Fortinet-FSSO,DC=COM'
'memberOf' = 'CN=group21,OU=Testing,DC=Fortinet-FSSO,DC=COM'
'memberOf' = 'CN=group1,OU=Testing,DC=Fortinet-FSSO,DC=COM'
'manager' = 'CN=test6,OU=Testing,DC=Fortinet-FSSO,DC=COM'
'streetAddress' = 'One Backend Street 1901'
'l' = 'Burnaby'
'st' = 'BC'
'postalCode' = '4711'
'co' = 'Canada'
'accountExpires' = '9223372036854
If the results are not as expected, verify what information FortiGate can collect from the Exchanger Server:
# diagnose test application wad 2500
# diagnose test application wad 162
Threat feeds
Threat feeds dynamically import an external block lists from an HTTP server in the form of a plain text file. Block lists can
be used to enforce special security requirements, such as long term policies to always block access to certain websites,
or short term requirements to block access to known compromised locations. The lists are dynamically imported, so that
any changes are immediately imported by FortiOS.
There are four types of threat feeds:
FortiGuard The file contains one URL per line. It is available as a Remote Category in Web Filter profiles,
Category SSL inspection exemptions, and proxy addresses. See Web rating override on page 1266 for
more information.
Example:
http://example/com.url
https://example.com/url
http://example.com:8080/url
IP Address The file contains one IP/IP range/subnet per line. It is available as an External IP Block List in
DNS Filter profiles, and as a Source/Destination in IPv4, IPv6, and proxy policies.
Example:
192.168.2.100
172.200.1.4/16
172.16.1.2/24
172.16.8.1-172.16.8.100
2001:0db8::eade:27ff:fe04:9a01/120
2001:0db8::eade:27ff:fe04:aa01-2001:0db8::eade:27ff:fe04:ab01
Domain Name The file contains one domain per line. Simple wildcards are supported. It is available as a
Remote Category in DNS Filter profiles. See External resources for DNS filter on page 361 for
more information.
Example:
mail.*.example.com
*-special.example.com
www.*example.com
example.com
Malware Hash The file contains one hash per line in the format <hex hash> [optional hash
description]. Each line supports MD5, SHA1, and SHA256 hex hashes. It is automatically
used for virus outbreak prevention on antivirus profiles with external-blocklist enabled.
Note: For optimal performance, do not mix different hashes in the list. Only use one of MD5,
SHA1, or SHA256.
Example:
292b2e6bb027cd4ff4d24e338f5c48de
dda37961870ce079defbf185eeeef905 Trojan-Ransom.Win32.Locky.abfl
3fa86717650a17d075d856a41b3874265f8e9eab Trojan-Ransom.Win32.Locky.abfl
c35f705df9e475305c0984b05991d444450809c35dd1d96106bb8e7128b9082f
Trojan-Ransom.Win32.Locky.abfl
See External malware block list on page 1113 for an example.
To determine the external resource table size limit for your device:
# print tablesize
...
system.external-resource: 0 256 512
...
For this device, a FortiGate 60E, the global limit is 512 and the limit per VDOM is 256.
URI of external resource Enter the link to the external resource file. The file should be a plain text file
with one entry on each line.
HTTP basic authentication Enable/disable basic HTTP authentication. When enabled, enter the
username and password in the requisite fields.
Refresh Rate The time interval to refresh the external resource, in minutes (1 - 43200,
default = 5).
The applicable threat feed will be triggered to refresh between 0 minutes and
the configured value. When the refresh is triggered, if another task is being
processed be the schedule worker, the refresh task will be added to the queue.
5. Click OK.
Parameters marked with an asterisk (*) are mandatory and must be filled in. Other parameters either have default values
or are optional.
Update history
To review the update history of a threat feed, go to Security Fabric > External Connectors, select a feed, and click Edit.
The Last Update field shows the date and time that the feed was last updated.
Click View Entries to view the current entries in the list.
You can use the external blocklist (threat feed) for web filtering, DNS, and in firewall policies.
Sample configuration
In this example, an IP address blocklist connector is created so that it can be used in a firewall policy.
6. Edit the connector, then click View Entries to view the IP addresses in the feed.
The blocklist can now be used in web filter and DNS profiles, and in firewall policies.
5. Click OK.
The malware hash threat feed connector supports a list of file hashes that can be used as part of virus outbreak
prevention.
This example retrieves a malware hash from an Amazon S3 bucket, and then enables malware block lists in a antivirus
profile.
5. Click OK.
6. Edit the connector, then click View Entries to view the hash list.
7. Go to Security Profiles > AntiVirus and create a new profile, or edit an existing one.
8. Enable Use External Malware Block List.
9. Click Apply.
Logs
The filehash and filehashsrc are included in outbreak prevention detection event logs.
This example shows the log generated when a file is detected by external malware hash list outbreak prevention:
1: date=2018-07-30 time=13:59:41 logid="0207008212" type="utm" subtype="virus"
eventtype="malware-list" level="warning" vd="root" eventtime=1532984381 msg="Blocked by
local malware list." action="blocked" service="HTTP" sessionid=174963 srcip=192.168.101.20
dstip=172.16.67.148 srcport=37045 dstport=80 srcintf="lan" srcintfrole="lan" dstintf="wan1"
dstintfrole="wan" policyid=1 proto=6 direction="incoming" filename="mhash_block.com"
checksum="90f0cb57" quarskip="No-skip" virus="mhash_block.com" dtype="File Hash"
filehash="93bdd30bd381b018b9d1b89e8e6d8753" filehashsrc="test_list"
url="http://172.16.67.148/mhash_block.com" profile="mhash_test" agent="Firefox/43.0"
analyticssubmit="false"
External resources provides the ability to dynamically import an external block list into an HTTP server. This feature
enables the FortiGate to retrieve a dynamic URL, domain name, IP address, or malware hash list from an external HTTP
server periodically. The FortiGate uses these external resources as the web filter's remote categories, DNS filter's
remote categories, policy address objects, or antivirus profile's malware definitions. If external resources are updated,
FortiGate objects are also updated dynamically.
External resource is divided into four types:
l URL list (type = category)
l Domain name list (type = domain)
l IP address list (type = address)
l Malware hash list (type = malware)
The DNS filter profile can use two types of external resources: domain type (domain name list) and address type (IP
address list).
When a domain type external resource is configured, it is treated as a remote category in the DNS filter profile. If the
domain name in DNS query matches the entry in this external resource file, it is treated as the remote category and
follows the action configured for this category in DNS filter profile.
When an address type external resource is configured, it can be enabled as external-ip-blocklist in DNS filter profile. If a
DNS resolved IP address in DNS response matches the entry in the external-ip-blocklist, this DNS query is blocked by
the DNS filter.
For external resources file format and limits, see External resources file format on page 356.
In the CLI, you can configure external resources files in an external HTTP server. Under global, configure the external
resources file location and specify the resource type.
next
end
In each VDOM, the domain type external resource can be used in the DNS filter as remote category. In this example, the
domain name list in the Ext-Resource-Type-as-Domain-1.txt file is treated as a remote category (category ID 194). The
IP address list in the Ext-Resource-Type-as-Address-1.txt file can be applied in the DNS filter as an external-ip-
blocklist. If the DNS resolved IP address matches any entry in the list in that file, the DNS query is blocked.
To configure, edit, or view the entries for external resources in the GUI:
5. Click OK.
6. Double-click the Threat Feeds Object you just configured to open the Edit page
7. Click View Entries to view the entry list in the external resources file.
8. Go to VDOM > Security Profiles > DNS Filter and open a DNS filter profile. The configured external resources
displays, and you can apply it in each DNS filter profile (remote category or external IP block lists).
Log sample
Remote categories
Go to VDOM > Log & Report > DNS Query. Some domains that match the remote category list are rated as remote
category, overriding their original domain rating.
Log example:
Go to VDOM > Log & Report > DNS Query. If the DNS query resolved IP address matches the entry in the external-
ip-blocklist, the DNS query is blocked.
Log example:
FortiExplorer for Apple TV allows you to use a TV screen to monitor your entire Security Fabric.
FortiExplorer for Apple TV is an analysis tool that provides easy to use NOC and SOC monitoring capabilities. The app
features real-time data traffic, visual alerts, as well as a general overview of hardware devices, operating systems, and
interfaces. The monitor also provides a wireless health summary of your entire network across multiple buildings. If an
access point goes offline, you will be notified about the network's health. After the issues are resolved, you will
immediately see the health update on your screen.
Download FortiExplorer for Apple TV from the app store on Apple TV. After the app is installed, add devices using the
Apple TV remote or by sharing a login profile with FortiExplorer. Once the devices are added, you can use FortiExplorer
for Apple TV to view real-time data in the Network Operations Center, Security Operations Center, and Software-Defined
Branch.
1. Download the app and add devices to FortiExplorer for Apple TV.
You can add devices by sharing a login profile with FortiExplorer or logging into the device directly on FortiExplorer
for Apple TV.
2. View the physical topology of the Fabric to identify risks
3. View the Fabric components as seen on the root FortiGate.
4. View an executive summary of the three largest areas of security focus in the Security Fabric.
5. View data collected by FortiAnalyzer on the endpoints on your network.
6. View vulnerability data collected by FortiClient EMS.
7. Use the Software-Defined Branch module to monitor interface SD-WAN usage and associated service level
agreements.
In this example, you have configured your FortiGates, FortiAnalyzer and other devices in your Security Fabric. Now you
want to use FortiExplorer for Apple TV to display the status of the devices on a TV in your Network Operation Center or
Security Operation Center.
Topology
This topology has a Headquarter and two Branches. Within the Headquarter is the Enterprise Core and two FortiGates
acting as ISFWs. In addition, an on-premise FortiAnalyzer collects all logging information from the fabric devices. The
FortiClient EMS manages all the endpoints within the topology.
The two branches are configured with SD-WAN with VPN overlays to the Enterprise Core. Traffic is steered towards the
overlays and underlays based on SD-WAN Rules.
Using FortiExplorer for Apple TV, you will be able to monitor the different components in this topology.
To take advantage of the views in the FortiExplorer for Apple TV, you should configure:
l Security Fabric on all FortiGates. See Configuring the root FortiGate and downstream FortiGates on page 132.
l FortiAnalyzer Logging. See Configuring FortiAnalyzer on page 139.
l FortiClient EMS. See FortiClient EMS on page 151
By adding the root FortiGate, you can view the entire topology and navigate to branch FortiGates in the SD-WAN view. If
you are already using FortiExplorer on a mobile device, you can connect the same FortiGate device to Apple TV by
sharing the login credentials on both devices. Alternatively, you can manually connect to your root FortiGate directly from
the app.
To share login credentials between FortiExplorer and FortiExplorer for Apple TV:
1. Connect the FortiExplorer and FortiExplorer for Apple TV devices to the same network.
2. On FortiExplorer for Apple TV, click New FortiGate.
3. In FortiExplorer, go to My Fabric.
4. Swipe right on the device you want to share, and tap Share Login Profile.
6. On Apple TV, click Accept. FortiExplorer for Apple TV confirms the request and proceeds to the device main menu.
1. In the Devices menu, click New FortiGate. The Login to FortiGate dialog box is displayed.
2. In the IP Address/Host Name field, take one of the following actions:
l Enter the device IP address and port, if not using the default admin port 443
l Enter the full host name including the domain. Enter port if not using the default admin port 443.
If the IP or hostname is not defined in the CN or SAN field of your certificate, you will
receive a prompt that "Your connection is not private". You may choose to continue with
your connection.
Use the Fabric Topology monitor to view the physical topology of the Fabric to identify risks. FortiGate devices with
version 6.4. and above can drilldown further to see additional information for devices such as FortiGates, FortiAPs, and
FortiSwitches.
To view the Fabric Topology monitor, go to Network Operations Center > Fabric Topology. This monitor displays the
same information as the Physical Topology on the FortiGate
Use your remote to navigate through the devices in the Fabric topology. Click a device to view the drilldown information.
To return to the default view, click the Menu button.
Use the Fabric Overview monitor to view the Fabric components as seen on the Dashboard of the Fabric Root FortiGate
in the example topology. Each device must be authorized and be part of the Fabric.
For information about configuring the Security Fabric, see Fortinet Security Fabric on page 129
To view the Fabric Overview monitor, go to Network Operations Center > Fabric Overview.
The Security Fabric monitor has multiple panes. To see data populated on the panes, ensure that proper configurations
are applied on the Fabric devices:
Fabric Connectors Displays external SDN connectors that are Configure Security Fabric > External
enabled. Connectors.
Security Fabric Displays the number of devices in the Configure Security Fabric > Fabric
Overview topology. Connectors.
Attack Surface Displays devices detected by the FortiGate Ensure Device Detection is configured on the
with a server tag. interfaces(s). Go to Network > Interfaces.
Device Inventory Displays devices based on Hardware Vendor Ensure Device Detection is configured on the
and detected OS interface(s). Go to Network > Interfaces.
Endpoint Coverage Displays the number of online devices and Ensure Device Detection is configured on the
the percentage of Unscanned, Vulnerable, interface(s). Vulnerability scan results come
and Secured devices. from FortiClient EMS. Go to Network >
Interfaces.
Device related information only corresponds to devices local to the FortiGate. Device
information from downstream FortiGates do not propagate to the Upstream FortiGate.
The Security Rating monitor is separated into three major scorecards: Security Posture, Fabric Coverage, and
Optimization, which provide an executive summary of the three largest areas of security focus in the Security Fabric.
To see the Security Rating summary, the root FortiGate and all FortiGates within the Fabric should have the proper
FortiGuard Security Rating license. Security rating is performed on the root FortiGate. Its reports are generated
periodically.
To view the Security Rating monitor, go to Network Operations Center > Security Rating.
The scorecards show an overall score of the performance and sub-categories. The point score represents the net score
for all passed and failed items in that area.
For more information about the Security Rating score, see Security Fabric score on page 224.
The Compromised Hosts monitor leverages the data collected by FortiAnalyzer on the endpoints on your network. To
see compromised hosts, the FortiAnalyzer must have a FortiGuard Indicators of Compromise license. The IOC service
helps identify compromised hosts based on infected websites that it may have visited.
This monitor captures the same information as seen on the Compromised Hosts monitor on the FortiGate.
l The Topology View pane displays the user's location in the topology.
l The Verdict View pane displays the Malware, Detected Method, and Security Action.
The Vulnerability Monitor obtains data from FortiClient EMS. It displays vulnerabilities detected by the FortiClient
endpoint, categorized into Critical, High, Medium and Low risk. In this example, an on-premise FortiClient EMS is
connected on the root FortiGate’s Fabric Connector.
This monitor captures the same information as seen on the Top Vulnerable Endpoint Devices monitor on the FortiGate.
1. Go to Security Operations Center > Vulnerability Monitor. The monitor displays a user list and their vulnerabilities.
2. Use your remote to scroll through the user list. The vulnerability details are displayed on the right side of the monitor.
l The User Information pane displays the user's contact details and IP address.
l The Vulnerability Summary pane displays the number of vulnerabilities categorized into Critical, High, Medium
and Low risk.
l The Topology View pane displays the user's location in the topology.
l The Top Vulnerabilities pane displays the top vulnerabilities by severity.
In the example topology, the branches are configured to use SD-WAN. You can use the top-right navigation menu in the
SD-WAN monitor to navigate to the Branch FortiGate to display information about the SD-WAN.
To view the SD-WAN monitor, go to Software-Defined Branch > SD-WAN Monitor.
The SD-WAN monitor summarizes the SD-WAN members, Zones, SD-WAN Rules and health checks deployed on the
FortiGate. It shows the interface member's SD-WAN usage and its associated service level agreements. The monitor
contains a chart that shows if the ports are meeting the SLA target for bandwidth, jitter and latency per the health check
in use in each SD-WAN Rule.
Some of the SD-WAN statistics are only available in FOS 6.4.1 and higher.
1. In the SD-WAN Overview area, Use your remote to select the SD-WAN Usage pane.
2. Scroll left and right to view Bandwidth, Volume and Sessions charts for the VIRTUAL-WAN-LINK and Underlay
interfaces in the SD-WAN Zones pane.
1. In the SD-WAN Rules area, use your remote to scroll the rules pane at the left-side of the monitor.
l The Destinations pane displays the destination details.
l The Performance SLA pane displays the SLA targets for the rule.
l The SD-WAN Active Interface pane displays a checkmark next to the active interface.
2. Use your remote to navigate between the Latency, Jitter, and Packet Loss charts.
1. Use your remote to swipe to the top navigation in the monitor. Wait for the topology to load.
2. At the top-right of the monitor, select the current device.
Troubleshooting
The following topics provide troubleshooting information for the Fortinet Security Fabric:
In downstream FortiGates, the diagnose sys csf global command shows a summary of all of the connected
FortiGates in the Security Fabric.
"upstream_intf":"Branch-HQ-A",
"upstream_serial":"FGVM01TM19000001",
"parent_serial":"FGVM01TM19000001",
"parent_hostname":"admin-root",
"upstream_status":"Authorized",
"upstream_ip":22569994,
"upstream_ip_str":"10.100.88.1",
"subtree_members":[
],
"is_discovered":true,
"ip_str":"10.0.10.2",
"downstream_intf":"To-HQ-A",
"idx":1
},
{
"path":"FGVM01TM19000001:FGVM01TM19000003",
"mgmt_ip_str":"104.196.102.183",
"mgmt_port":10407,
"sync_mode":1,
"saml_role":"service-provider",
"admin_port":443,
"serial":"FGVM01TM19000003",
"host_name":"Enterprise_Second_Floor",
"firmware_version_major":6,
"firmware_version_minor":2,
"firmware_version_patch":0,
"firmware_version_build":1010,
"upstream_intf":"port3",
"upstream_serial":"FGVM01TM19000001",
"parent_serial":"FGVM01TM19000001",
"parent_hostname":"admin-root",
"upstream_status":"Authorized",
"upstream_ip":22569994,
"upstream_ip_str":"10.100.88.1",
"subtree_members":[
],
"is_discovered":true,
"ip_str":"10.100.88.102",
"downstream_intf":"port1",
"idx":2
},
{
"path":"FGVM01TM19000001:FGVM01TM19000004",
"mgmt_ip_str":"104.196.102.183",
"mgmt_port":10424,
"sync_mode":1,
"saml_role":"service-provider",
"admin_port":443,
"serial":"FGVM01TM19000004",
"host_name":"Branch_Office_02",
"firmware_version_major":6,
"firmware_version_minor":2,
"firmware_version_patch":0,
"firmware_version_build":1010,
"upstream_intf":"HQ-MPLS",
"upstream_serial":"FGVM01TM19000001",
"parent_serial":"FGVM01TM19000001",
"parent_hostname":"admin-root",
"upstream_status":"Authorized",
"upstream_ip":22569994,
"upstream_ip_str":"10.100.88.1",
"subtree_members":[
],
"is_discovered":true,
"ip_str":"10.0.12.3",
"downstream_intf":"To-HQ-MPLS",
"idx":3
},
{
"path":"FGVM01TM19000001:FGVM01TM19000005",
"mgmt_ip_str":"104.196.102.183",
"mgmt_port":10404,
"sync_mode":1,
"saml_role":"service-provider",
"admin_port":443,
"serial":"FGVM01TM19000005",
"host_name":"Enterprise_First_Floor",
"firmware_version_major":6,
"firmware_version_minor":2,
"firmware_version_patch":0,
"firmware_version_build":1010,
"upstream_intf":"port3",
"upstream_serial":"FGVM01TM19000001",
"parent_serial":"FGVM01TM19000001",
"parent_hostname":"admin-root",
"upstream_status":"Authorized",
"upstream_ip":22569994,
"upstream_ip_str":"10.100.88.1",
"subtree_members":[
],
"is_discovered":true,
"ip_str":"10.100.88.101",
"downstream_intf":"port1",
"idx":4
}
]
Example:
Examples:
# diagnose test application autod 1
autod log dumping is enabled
# diagnose test application autod 1
autod log dumping is disabled
Example:
# diagnose test application autod 2
csf: enabled root:yes
total stitches activated: 3
stitch: Compromised-IP-Banned
destinations: all
trigger: Compromised-IP-Banned
stitch: HA-failover
destinations: HA-failover_ha-cluster_25;
trigger: HA-failover
stitch: rebooot
destinations: all
trigger: reboot
Example:
stitch: Compromised-IP-Banned
local hit: 0 relayed to: 0 relayed from: 0
last trigger:Wed Dec 31 20:00:00 1969
last relay:Wed Dec 31 20:00:00 1969
actions:
Compromised-IP-Banned_ban-ip:
done: 1 relayed to: 0 relayed from: 0
last trigger:Wed Dec 31 20:00:00 1969
last relay:
stitch: HA-failover
local hit: 0 relayed to: 0 relayed from: 0
last trigger:Thu May 24 11:35:22 2018
last relay:Thu May 24 11:35:22 2018
actions:
HA-failover_email:
done: 1 relayed to: 1 relayed from: 1
last trigger:Thu May 24 11:35:22 2018
last relay:Thu May 24 11:35:22 2018
stitch: rebooot
local hit: 2 relayed to: 1 relayed from: 1
last trigger:Fri May 3 13:30:56 2019
last relay:Fri May 3 13:30:23 2019
actions:
action1
done: 1 relayed to: 0 relayed from: 0
last trigger:Fri May 3 13:30:56 2019
last relay:
logid2stitch mapping:
id:20103 local hit: 0 relayed to: 0 relayed from: 0
License Expiry
lambada
Interfaces
Physical and virtual interfaces allow traffic to flow between internal networks, and between the internet and internal
networks. FortiGate has options for setting up interfaces and groups of subnetworks that can scale as your organization
grows. You can create and edit VLAN, EMAC-VLAN, switch interface, zones, and so on.
The following topics provide information about interfaces:
l Interface settings on page 386
l Aggregation and redundancy on page 389
l VLANs on page 391
l Enhanced MAC VLANs on page 397
l Inter-VDOM routing on page 400
l Software switch on page 405
l Hardware switch on page 407
l Zone on page 409
l Virtual Wire Pair on page 411
l Virtual switch support for FortiGate 300E series on page 412
l Failure detection for aggregate and redundant interfaces on page 414
l VLAN inside VXLAN on page 415
l Virtual Wire Pair with VXLAN on page 417
l QinQ on page 419
l Assign a subnet with the FortiIPAM service on page 420
Interface settings
Administrators can configure both physical and virtual FortiGate interfaces in Network > Interfaces. There are different
options for configuring interfaces when FortiGate is in NAT mode or transparent mode.
Alias Enter an alternate name for a physical interface on the FortiGate unit. This
field appears when you edit an existing physical interface. The alias does not
appear in logs.
The maximum length of the alias is 25 characters.
Type The configuration type for the interface, such as VLAN or Software Switch.
Link Status Indicates whether the interface is connected to a network or not (link status is
up or down). This field is available when you edit an existing physical interface.
Virtual Domain Select the virtual domain to add the interface to.
Only administrator accounts with the super_admin profile can change the
Virtual Domain.
Role Set the role setting for the interface. Different settings will be shown or hidden
when editing an interface depending on the role.
l LAN: Used to connected to a local network of endpoints. It is default role
Interface Members This section can has different formats depending on the Type:
Software Switch: This field is read-only, and shows the interfaces that belong
to the virtual interface of the software switch.
802.3ad Aggregate or Redundant Interface: This field includes the available
and selected interface lists.
DHCP server.
l PPPoE: Get the interface IP address and other network settings from a
detect attacks.
IP/Netmask If Addressing Mode is set to Manual, enter an IPv4 address and subnet mask
for the interface. FortiGate interfaces cannot have multiple IP addresses on
the same subnet.
IPv6 Address/Prefix If Addressing Mode is set to Manual and IPv6 support is enabled, enter an
IPv6 address and subnet mask for the interface. A single interface can have an
IPv4 address, IPv6 address, or both.
Create address object This option is available when Role is set to LAN or DMZ.
matching subnet Enable this option to automatically create an address object that matches the
interface subnet.
IPv4 Administrative Access Select the types of administrative access permitted for IPv4 connections to this
interface. See Configure administrative access to interfaces on page 388.
IPv6 Administrative Access Select the types of administrative access permitted for IPv6 connections to this
interface. See Configure administrative access to interfaces on page 388.
Device Detection Enable/disable passively gathering device identity information about the
devices on the network that are connected to this interface.
Security Mode Enable/disable captive portal authentication for this interface. After enabling
captive portal authentication, you can configure the authentication portal, user
and group access, custom portal messages, exempt sources and
destinations/services, and redirect after captive portal.
Outbound shaping profile Enable/disable traffic shaping on the interface. This allows you to enforce
bandwidth limits on individual interfaces. See Interface-based traffic shaping
profile on page 1090 for more information.
4. Click OK.
You can configure the protocols that administrators can use to access interfaces on the FortiGate. This helps secure
access to the FortiGate by restricting access to a limited number of protocols. It helps prevent users from accessing
interfaces that you don't want them to access, such as public-facing ports.
As a best practice, you should configure administrative access when you're setting the IP address for a port.
3. In the Administrative Access section, select which protocols to enable for IPv4 and IPv6 Administrative Access.
HTTPS Allow secure HTTPS connections to the FortiGate GUI through this interface. If
configured, this option is enabled automatically.
HTTP Allow HTTP connections to the FortiGate GUI through this interface. This option can
only be enabled if HTTPS is already enabled.
PING The interface responds to pings. Use this setting to verify your installation and for
testing.
SNMP Allow a remote SNMP manager to request SNMP information by connecting to this
interface.
Security Fabric Allow Security Fabric access. This enables FortiTelemetry and CAPWAP.
Connection
Link aggregation (IEEE 802.3ad) enables you to bind two or more physical interfaces together to form an aggregated
(combined) link. This new link has the bandwidth of all the links combined. If a link in the group fails, traffic is transferred
automatically to the remaining interfaces. The only noticeable effect is reduced bandwidth.
This feature is similar to redundant interfaces. The major difference is a redundant interface group only uses one link at a
time, where an aggregate link group uses the total bandwidth of the functioning links in the group, up to eight (or more).
An interface is available to be an aggregate interface if:
l It is a physical interface and not a VLAN interface or subinterface.
l It is not already part of an aggregate or redundant interface.
l It is in the same VDOM as the aggregated interface. Aggregate ports cannot span multiple VDOMs.
l It does not have an IP address and is not configured for DHCP or PPPoE.
l It is not referenced in any security policy, VIP, IP Pool, or multicast policy.
l It is not an HA heartbeat interface.
l It is not one of the FortiGate-5000 series backplane interfaces.
When an interface is included in an aggregate interface, it is not listed on the Network > Interfaces page. Interfaces still
appear in the CLI although configuration for those interfaces do not take affect. You cannot configure the interface
individually and it is not available for inclusion in security policies, VIPs, IP pools, or routing.
Sample configuration
This example creates an aggregate interface on a FortiGate-140D POE using ports 3-5 with an internal IP address of
10.1.1.123, as well as the administrative access to HTTPS and SSH.
Redundancy
In a redundant interface, traffic only goes over one interface at any time. This differs from an aggregated interface where
traffic goes over all interfaces for increased bandwidth. This difference means redundant interfaces can have more
robust configurations with fewer possible points of failure. This is important in a fully-meshed HA configuration.
An interface is available to be in a redundant interface if:
l It is a physical interface and not a VLAN interface.
l It is not already part of an aggregated or redundant interface.
l It is in the same VDOM as the redundant interface.
l It does not have an IP address and is not configured for DHCP or PPPoE.
l It has no DHCP server or relay configured on it.
l It does not have any VLAN subinterfaces.
l It is not referenced in any security policy, VIP, or multicast policy.
l It is not monitored by HA.
l It is not one of the FortiGate-5000 series backplane interfaces.
When an interface is included in a redundant interface, it is not listed on the Network > Interfaces page. You cannot
configure the interface individually and it is not available for inclusion in security policies, VIPs, or routing.
Sample configuration
VLANs
Virtual Local Area Networks (VLANs) multiply the capabilities of your FortiGate unit and can also provide added network
security. VLANs use ID tags to logically separate devices on a network into smaller broadcast domains. These smaller
domains forward packets only to devices that are part of that VLAN domain. This reduces traffic and increases network
security.
In NAT mode, the FortiGate unit functions as a layer-3 device. In this mode, the FortiGate unit controls the flow of
packets between VLANs and can also remove VLAN tags from incoming VLAN packets. The FortiGate unit can also
forward untagged packets to other networks such as the Internet.
In NAT mode, the FortiGate unit supports VLAN trunk links with IEEE 802.1Q-compliant switches or routers. The trunk
link transports VLAN-tagged packets between physical subnets or networks. When you add VLAN subinterfaces to the
FortiGate's physical interfaces, the VLANs have IDs that match the VLAN IDs of packets on the trunk link. The FortiGate
unit directs packets with VLAN IDs to subinterfaces with matching IDs.
You can define VLAN subinterfaces on all FortiGate physical interfaces. However, if multiple virtual domains are
configured on the FortiGate unit, you only have access to the physical interfaces on your virtual domain. The FortiGate
unit can tag packets leaving on a VLAN subinterface. It can also remove VLAN tags from incoming packets and add a
different VLAN tag to outgoing packets.
Normally in VLAN configurations, the FortiGate unit's internal interface is connected to a VLAN trunk, and the external
interface connects to an Internet router that is not configured for VLANs. In this configuration, the FortiGate unit can
apply different policies for traffic on each VLAN interface connected to the internal interface, which results in less
network traffic and better security.
Sample topology
In this example, two different internal VLAN networks share one interface on the FortiGate unit and share the connection
to the Internet. This example shows that two networks can have separate traffic streams while sharing a single interface.
This configuration can apply to two departments in a single company or to different companies.
There are two different internal network VLANs in this example. VLAN_100 is on the 10.1.1.0/255.255.255.0 subnet, and
VLAN_200 is on the 10.1.2.0/255.255.255.0 subnet. These VLANs are connected to the VLAN switch.
The FortiGate internal interface connects to the VLAN switch through an 802.1Q trunk. The internal interface has an IP
address of 192.168.110.126 and is configured with two VLAN subinterfaces (VLAN_100 and VLAN_200). The external
interface has an IP address of 172.16.21.2 and connects to the Internet. The external interface has no VLAN
subinterfaces.
When the VLAN switch receives packets from VLAN_100 and VLAN_200, it applies VLAN ID tags and forwards the
packets of each VLAN both to local ports and to the FortiGate unit across the trunk link. The FortiGate unit has policies
that allow traffic to flow between the VLANs, and from the VLANs to the external network.
Sample configuration
In this example, both the FortiGate unit and the Cisco 2950 switch are installed and connected and basic configuration
has been completed. On the switch, you need access to the CLI to enter commands. No VDOMs are enabled in this
example.
General configuration steps include:
1. Configure the external interface.
2. Add two VLAN subinterfaces to the internal network interface.
3. Add firewall addresses and address ranges for the internal and external networks.
4. Add security policies to allow:
l the VLAN networks to access each other.
Policies 1 and 2 do not need NAT enabled, but policies 3 and 4 do need NAT enabled.
config firewall policy
edit 1
set srcintf VLAN_100
set srcaddr VLAN_100_Net
In transparent mode, the FortiGate unit behaves like a layer-2 bridge but can still provide services such as antivirus
scanning, web filtering, spam filtering, and intrusion protection to traffic. Some limitations of transparent mode is that you
cannot use SSL VPN, PPTP/L2TP VPN, DHCP server, or easily perform NAT on traffic. The limits in transparent mode
apply to IEEE 802.1Q VLAN trunks passing through the unit.
You can insert the FortiGate unit operating in transparent mode into the VLAN trunk without making changes to your
network. In a typical configuration, the FortiGate unit internal interface accepts VLAN packets on a VLAN trunk from a
VLAN switch or router connected to internal network VLANs. The FortiGate external interface forwards VLAN-tagged
packets through another VLAN trunk to an external VLAN switch or router and on to external networks such as the
Internet. You can configure the unit to apply different policies for traffic on each VLAN in the trunk.
To pass VLAN traffic through the FortiGate unit, you add two VLAN subinterfaces with the same VLAN ID, one to the
internal interface and the other to the external interface. You then create a security policy to permit packets to flow from
the internal VLAN interface to the external VLAN interface. If required, create another security policy to permit packets to
flow from the external VLAN interface to the internal VLAN interface. Typically in transparent mode, you do not permit
packets to move between different VLANs. Network protection features such as spam filtering, web filtering, and anti-
virus scanning, are applied through the UTM profiles specified in each security policy, enabling very detailed control over
traffic.
When the FortiGate unit receives a VLAN-tagged packet on a physical interface, it directs the packet to the VLAN
subinterface with the matching VLAN ID. The VLAN tag is removed from the packet and the FortiGate unit then applies
security policies using the same method it uses for non-VLAN packets. If the packet exits the FortiGate unit through a
VLAN subinterface, the VLAN ID for that subinterface is added to the packet and the packet is sent to the corresponding
physical interface.
Sample topology
In this example, the FortiGate unit is operating in transparent mode and is configured with two VLANs: one with an ID of
100 and the other with ID 200. The internal and external physical interfaces each have two VLAN subinterfaces, one for
VLAN_100 and one for VLAN_200.
The IP range for the internal VLAN_100 network is 10.100.0.0/255.255.0.0, and for the internal VLAN_200 network is
10.200.0.0/255.255.0.0.
The internal networks are connected to a Cisco 2950 VLAN switch which combines traffic from the two VLANs onto one
in the FortiGate unit's internal interface. The VLAN traffic leaves the FortiGate unit on the external network interface,
goes on to the VLAN switch, and on to the Internet. When the FortiGate units receives a tagged packet, it directs it from
the incoming VLAN subinterface to the outgoing VLAN subinterface for that VLAN.
In this example, we create a VLAN subinterface on the internal interface and another one on the external interface, both
with the same VLAN ID. Then we create security policies that allow packets to travel between the VLAN_100_int
interface and the VLAN_100_ext interface. Two policies are required: one for each direction of traffic. The same is
required between the VLAN_200_int interface and the VLAN_200_ext interface, for a total of four security policies.
Sample configuration
There are two main steps to configure your FortiGate unit to work with VLANs in transparent mode:
1. Add VLAN subinterfaces.
2. Add security policies.
You can also configure the protection profiles that manage antivirus scanning, web filtering, and spam filtering.
The Media Access Control (MAC) Virtual Local Area Network (VLAN) feature in Linux allows you to configure multiple
virtual interfaces with different MAC addresses (and therefore different IP addresses) on a physical interface.
FortiGate implements an enhanced MAC VLAN consisting of a MAC VLAN with bridge functionality. Because each MAC
VLAN has a unique MAC address, virtual IP addresses (VIPs) and IP pools are supported, and you can disable Source
Network Address Translation (SNAT) in policies.
MAC VLAN cannot be used in a transparent mode virtual domain (VDOM). In a transparent mode VDOM, a packet
leaves an interface with the MAC address of the original source instead of the interface’s MAC address. FortiGate
implements an enhanced version of MAC VLAN where it adds a MAC table in the MAC VLAN which learns the MAC
addresses when traffic passes through.
If you configure a VLAN ID for an enhanced MAC VLAN, it won’t join the switch of the underlying interface. When a
packet is sent to this interface, a VLAN tag is inserted in the packet and the packet is sent to the driver of the underlying
interface. When the underlying interface receives a packet, if the VLAN ID doesn’t match, it won’t deliver the packet to
this enhanced MAC VLAN interface.
When using a VLAN ID, the ID and the underlying interface must be a unique pair, even if the
belong to different VDOMs. This is because the underlying, physical interface uses the VLAN
ID as the identifier to dispatch traffic among the VLAN and enhanced MAC VLAN interfaces.
If you use an interface in an enhanced MAC VLAN, do not use it for other purposes such as a management interface, HA
heartbeat interface, or in Transparent VDOMs.
If a physical interface is used by an EMAC VLAN interface, you cannot use it in a Virtual Wire Pair.
In high availability (HA) configurations, enhanced MAC VLAN is treated as a physical interface. It’s assigned a unique
physical interface ID and the MAC table is synchronized with the secondary devices in the same HA cluster.
Example 1: Enhanced MAC VLAN configuration for multiple VDOMs that use the same
interface or VLAN
In this example, a FortiGate is connected, through port 1 to a router that’s connected to the Internet. Three VDOMs share
the same interface (port 1) which connects to the same router that’s connected to the Internet. Three enhanced MAC
VLAN interfaces are configured on port 1 for the three VDOMs. The enhanced MAC VLAN interfaces are in the same IP
subnet segment and each have unique MAC addresses.
The underlying interface (port 1) can be a physical interface, an aggregate interface, or a VLAN interface on a physical or
aggregate interface.
Example 2: Enhanced MAC VLAN configuration for shared VDOM links among multiple
VDOMs
In this example, multiple VDOMs can connect to each other using enhanced MAC VLAN on network processing unit
(NPU) virtual link (Vlink) interfaces.
FortiGate VDOM links (NPU-Vlink) are designed to be peer-to-peer connections and VLAN interfaces on NPU Vlink
ports use the same MAC address. Connecting more than two VDOMs using NPU Vlinks and VLAN interfaces is not
recommended.
Example 3: Enhanced MAC VLAN configuration for unique MAC addresses for each
VLAN interface on the same physical port
Some networks require a unique MAC address for each VLAN interface when the VLAN interfaces share the same
physical port. In this case, the enhanced MAC VLAN interface is used the same way as normal VLAN interfaces.
To configure this, use the set vlanid command for the VLAN tag. The VLAN ID and interface must be a unique pair,
even if they belong to different VDOMs.
Inter-VDOM routing
VDOM links allow VDOMs to communicate internally without using additional physical interfaces.
Inter-VDOM routing is the communication between VDOMs. VDOM links are virtual interfaces that connect VDOMs. A
VDOM link contains a pair of interfaces, each one connected to a VDOM and forming either end of the inter-VDOM
connection.
When VDOMs are configured on your FortiGate unit, configuring inter-VDOM routing and VDOM links is like creating a
VLAN interface. VDOM links can be managed in either the CLI or in the network interface list in the GUI.
VDOM link does not support traffic offload. If you want to use traffic offload, use NPU-VDOM-
LINK.
By default, VDOM links are created as point-to-point (ppp) links. If required, the link type can
be changed in the CLI.
For example, when running OSPF in IPv6, a link-local address is required in order to
communicate with OSPF neighbors. For a VDOM link to obtain a link-local address its type
must be set to ethernet.
config global
config system vdom-link
edit "<vdom-link-name>"
set type {ppp | ethernet}
next
end
config system interface
edit "<vdom-link-name0>"
set vdom "<VDOM Name>"
set type vdom-link
next
edit "<vdom-link-name1>"
set vdom "<VDOM Name>"
set type vdom-link
next
end
end
config global
config system vdom-link
delete <VDOM-LINK-Name>
end
end
Example
This example shows how to configure a FortiGate unit to use inter-VDOM routing.
Two departments of a company, Accounting and Sales, are connected to one FortiGate. The company uses a single ISP
to connect to the Internet.
This example includes the following general steps. We recommend following the steps in the order below.
To enable VDOMs:
You will be logged out of the device when VDOM mode is enabled.
config global
config vdom
edit Accounting
next
edit Sales
next
end
end
Next, configure the physical interfaces. This example uses three interfaces on the FortiGate unit: port2 (internal), port3
(DMZ), and port1 (external). Port2 and port3 interfaces each have a department’s network connected. Port1 is for all
traffic to and from the Internet and uses DHCP to configure its IP address, which is common with many ISPs.
config global
config system interface
edit port2
set alias AccountingLocal
set vdom Accounting
set mode static
set ip 172.100.1.1 255.255.0.0
set allowaccess https ping ssh
set description "The accounting dept internal interface"
next
edit port3
set alias SalesLocal
set vdom Sales
set mode static
set ip 192.168.1.1 255.255.0.0
set allowaccess https ping ssh
set description "The sales dept. internal interface"
next
edit port1
set alias ManagementExternal
set vdom root
set mode dhcp
set allowaccess https ssh snmp
set description "The system wide management interface."
next
end
end
To complete the connection between each VDOM and the management VDOM, add the two VDOM links. One pair is the
Accounting – management link and the other is the Sales – management link.
When configuring inter-VDOM links, you do not have to assign IP addresses to the links unless you are using advanced
features such as dynamic routing that require them. Not assigning IP addresses results in faster configuration and more
available IP addresses on your networks.
config global
config system vdom-link
edit AccountVlnk
next
end
config system interface
edit AccountVlnk0
set vdom Accounting
set ip 11.11.11.2 255.255.255.0
set allowaccess https ping ssh
set description "Accounting side of the VDOM link"
next
edit AccountVlnk1
set vdom root
set ip 11.11.11.1 255.255.255.0
set allowaccess https ping ssh
set description "Management side of the VDOM link"
next
end
end
config global
config system vdom-link
edit SalesVlnk
next
end
config system interface
edit SalesVlnk0
set vdom Sales
set ip 12.12.12.2 255.255.255.0
set allowaccess https ping ssh
set description "Sales side of the VDOM link"
next
edit SalesVlnk1
set vdom root
set ip 12.12.12.1 255.255.255.0
set allowaccess https ping ssh
set description "Management side of the VDOM link"
next
end
end
With the VDOMs, physical interfaces, and VDOM links configured, the firewall must now be configured to allow the
proper traffic. Firewalls are configured per-VDOM, and firewall objects and routes must be created for each VDOM
separately.
config vdom
edit Accounting
config firewall policy
edit 1
set name "Accounting-Local-to-Management"
set srcintf port2
set dstintf AccountVlnk0
config vdom
edit Sales
config firewall policy
edit 3
set name "Sales-local-to-Management"
set srcintf port3
set dstintf SalesVlnk0
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ALL
set nat enable
next
end
next
edit root
config firewall policy
edit 4
set name "Sales-VDOM-to-Internet"
set srcintf SalesVlnk1
set dstintf port1
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ALL
set nat enable
next
end
next
end
When the inter-VDOM routing has been configured, test the configuration to confirm proper operation. Testing
connectivity ensures that physical networking connections, FortiGate unit interface configurations, and firewall policies
are properly configured.
The easiest way to test connectivity is to use the ping and traceroute commands to confirm the connectivity of
different routes on the network.
Test both from AccountingLocal to the internet and from SalesLocal to the internet.
Software switch
A software switch is a virtual switch that is implemented at the software or firmware level and not at the hardware level. A
software switch can be used to simplify communication between devices connected to different FortiGate interfaces. For
example, using a software switch, you can place the FortiGate interface connected to an internal network on the same
subnet as your wireless interfaces. Then devices on the internal network can communicate with devices on the wireless
network without any additional configuration on the FortiGate unit, such as additional security policies.
A software switch can also be useful if you require more hardware ports for the switch on a FortiGate unit. For example, if
your FortiGate unit has a 4-port switch, WAN1, WAN2, and DMZ interfaces, and you need one more port, you can create
a soft switch that can include the four-port switch and the DMZ interface, all on the same subnet. These types of
applications also apply to wireless interfaces, virtual wireless interfaces, and physical interfaces such as those in
FortiWiFi and FortiAP units.
Similar to a hardware switch, a software switch functions like a single interface. It has one IP address and all the
interfaces in the software switch are on the same subnet. Traffic between devices connected to each interface are not
regulated by security policies, and traffic passing in and out of the switch are controlled by the same policy.
When setting up a software switch, consider the following:
l Ensure that you have a back up of the configuration.
l Ensure that you have at least one port or connection, such as the console port, to connect to the FortiGate unit. If
you accidentally combine too many ports, you need a way to undo errors.
l The ports that you include must not have any link or relation to any other aspect of the FortiGate unit, such as DHCP
servers, security policies, and so on.
l For increased security, you can create a captive portal for the switch to allow only specific user groups access to the
resources connected to the switch.
Some of the difference between software and hardware switches are:
Processing Packets are processed in software by the Packets are processed in hardware by the
CPU. hardware switch controller, or SPU where
applicable.
To add an interface to a software switch, it cannot be referenced by an existing configuration and its IP address must be
set to 0.0.0.0/0.0.0.0.
Example
For this example, the wireless interface (WiFi) needs to be on the same subnet as the DMZ1 interface to facilitate
wireless synchronizing from an iPhone and a local computer. Because synchronizing between two subnets is
problematic, putting both interfaces on the same subnet allows the synchronizing will work. The software switch will
accomplish this.
1. Clear the interfaces and back up the configuration:
a. Ensure the interfaces are not used for other security policy or for other use on the FortiGate unit.
b. Check the WiFi and DMZ1 ports to ensure that DHCP is not enabled and that there are no other dependencies
on these interfaces.
c. Save the current configuration so that it can be recovered if something foes wrong.
2. Merge the WiFi port and DMZ1 port to create a software switch named synchro with an IP address of 10.10.21.12
and administrative access for HTTPS, SSH and PING:
After the switch is set up, you add security policies, DHCP servers, and any other settings that are required.
Hardware switch
A hardware switch is a virtual switch interface that groups different ports together so that the FortiGate can use the group
as a single interface. Supported FortiGate models have a default hardware switch called either internal or lan. The
hardware switch is supported by the chipset at the hardware level.
Ports that are connected to the same hardware switch behave like they are on the same physical switch in the same
broadcast domain. Ports can be removed from a hardware switch and assigned to another switch or used as standalone
interfaces.
Some of the difference between hardware and software switches are:
Processing Packets are processed in hardware by the Packets are processed in software by the
hardware switch controller, or SPU where CPU.
applicable.
3. Select interfaces to add or remove them from the hardware switch, then click Close.
To add an interface to a hardware switch, it cannot be referenced by an existing configuration and its IP address
must be set to 0.0.0.0/0.0.0.0.
4. Click OK.
Removed interfaces will now be listed as standalone interfaces in the Physical Interface section.
To add an interface to a hardware switch, it cannot be referenced by an existing configuration and its IP address must be
set to 0.0.0.0/0.0.0.0.
Zone
Zones are a group of one or more physical or virtual FortiGate interfaces that you can apply security policies to control
inbound and outbound traffic. Grouping interfaces and VLAN subinterfaces into zones simplifies the creation of security
policies where a number of network segments can use the same policy settings and protection profiles.
When you add a zone, you select the names of the interfaces and VLAN subinterfaces to add to the zone. Each interface
still has its own address. Routing is still done between interfaces, that is, routing is not affected by zones. You can use
security policies to control the flow of intra-zone traffic.
For example, in the sample configuration below, the network includes three separate groups of users representing
different entities on the company network. While each group has its own set of ports and VLANs in each area, they can
all use the same security policy and protection profiles to access the Internet. Rather than the administrator making nine
separate security policies, he can make administration simpler by adding the required interfaces to a zone and creating
three policies.
Sample configuration
You can configure policies for connections to and from a zone but not between interfaces in a zone. For this example,
you can create a security policy to go between zone 1 and zone 3, but not between WAN2 and WAN1, or WAN1 and
DMZ1.
To configure a zone to include the internal interface and a VLAN using the CLI:
To configure a firewall policy to allow any interface to access the Internet using the CLI:
Intra-zone traffic
In the zone configuration you can set intrazone deny to prohibit the different interfaces in the same zone to talk to
each other.
For example, if you have ten interfaces in your zone and the intrazone setting is deny. You now want to allow traffic
between a very small number of networks on different interfaces that are part of the zone but you do not want to disable
the intra-zone blocking.
In this example, the zone VLANs are defined as: 192.168.1.0/24, 192.168.2.0/24, ... 192.168.10.0/24.
This policy allows traffic from 192.168.1.x to 192.168.2.x even though they are in the same zone and intra-zone blocking
is enabled. The intra-zone blocking acts as a default deny rule and you have to specifically override it by creating a policy
within the zone.
A virtual wire pair consists of two interfaces that do not have IP addressing and are treated like a transparent mode
VDOM. All traffic received by one interface in the virtual wire pair can only be forwarded to the other interface, provided a
virtual wire pair firewall policy allows this traffic. Traffic from other interfaces cannot be routed to the interfaces in a virtual
wire pair. Redundant and 802.3ad aggregate (LACP) interfaces can be included in a virtual wire pair.
Virtual wire pairs are useful for a typical topology where MAC addresses do not behave normally. For example, port
pairing can be used in a Direct Server Return (DSR) topology where the response MAC address pair may not match the
request’s MAC address pair.
Example
In this example, a virtual wire pair (port3 and port4) makes it easier to protect a web server that is behind a FortiGate
operating as an Internal Segmentation Firewall (ISFW). Users on the internal network access the web server through the
ISFW over the virtual wire pair.
Interfaces used in a virtual wire pair cannot be used to access the ISFW FortiGate. Before
creating a virtual wire pair, make sure you have a different port configured to allow admin
access using your preferred protocol.
On the FortiGate 300E series, switch ports can be assigned to different VLANs.
2. Create the VLAN switch. Optionally, you can assign an ID to the VLAN:
The default ID is 0. You can use the default ID, or you can assign an ID to the VLAN (3900–3999).
When an aggregate or redundant interface goes down, the corresponding fail-alert interface changes to down. When an
aggregate or redundant interface comes up, the corresponding fail-alert interface changes to up.
Fail-detect for aggregate and redundant interfaces can be configured using the CLI.
VLANs can be assigned to VXLAN interfaces. In a data center network where VXLAN is used to create an L2 overlay
network and for multitenant environments, a customer VLAN tag can be assigned to VXLAN interface. This allows the
VLAN tag from VLAN traffic to be encapsulated within the VXLAN packet.
1. Configure VXLAN:
config system vxlan
edit "vxlan1"
set interface port1
set vni 1000
set remote-ip 173.1.1.1
next
end
3. Configure software-switch:
config system switch-interface
edit sw1
set vdom root
set member vlan100 vxlan100
set intra-switch-policy implicit
next
end
1. Configure VXLAN:
config system vxlan
edit "vxlan2"
set interface port25
set vni 1000
set remote-ip 173.1.1.2
next
end
2. Configure system interface:
config system interface
edit vlan100
set vdom root
set vlanid 100
set interface port20
next
edit vxlan100
set type vlan
set vlanid 100
set vdom root
set interface vxlan2
next
end
3. Configure software-switch:
config system switch-interface
edit sw1
set vdom root
set member vlan100 vxlan100
next
end
This captures the VXLAN traffic between 172.1.1.1 and 172.1.1.2 with the VLAN 100 tag inside.
next
end
next
end
QinQ
QinQ (802.1ad) allows multiple VLAN tags to be inserted into a single frame, and can be configured on supported
FortiGate devices.
In this example, the customer connects to a provider that uses 802.1ad double-tagging to separate their customer
VLANs. The FortiGate connecting to the provider double-tags its frames with an outer provider-tag (S-Tag) and an inner
customer-tag (C-Tag).
The customer identifies itself with the provider-tag (S-Tag) 232 and uses the customer-tag (C-Tag) 444 for traffic to its
VLAN.
1. Configure the interface to the provider that uses the outer tag (S-Tag):
config system interface
edit "vlan-8021ad"
set vdom "root"
set vlan-protocol 8021ad
set device-identification enable
set role lan
set snmp-index 47
set interface "PORT"
set vlanid 232
next
end
2. Configure a dynamic VLAN interface that uses the inner tag (C-Tag):
The FortiIPAM (IP Address Management) service automatically assigns subnets to FortiGate to prevent duplicate
IP addresses from overlapping within the same Security Fabric.
After the FortiIPAM registration is synced to FortiGuard from FortiCare, FortiGate can use FortiIPAM to automatically
assign IP addresses based on the configured network size for the FortiGate interface.
Requirements:
1. Go to System > FortiGuard to verify the FortiIPAM service is registered. If the service is registered, the FortiIPAM
area at the bottom of the page displays a check mark as well as the license expiry date.
Example
In this example, you will configure port5 on FortiGate Root to be managed by FortiIPAM and specify the network size.
Next you will enable DHCP on the interface to supply IP addresses to this network.
Once FortiIPAM is designated as the IP source, you will configure the port5 interface on FortiGate Downstream to obtain
an IP from DHCP to connect it to FortiGate Root and add it to the Security Fabric. Lastly, you will use FortiIPAM to
assign IP addresses to the Internal Network.
1. On FortiGate Root, edit port5 and configure the interface to be managed by FortiIPAM.
a. Go to Network > Interfaces, and double-click port5 to edit it. The Edit Interface window opens.
b. From the Role dropdown, select LAN.
c. In the Addressing mode area, select Auto-managed by FortiIPAM. An information icon appears next to
IP/Netmask and below the Network Size dropdown indicating FortiIPAM will allocate an IP subnet with the
selected size.
d. From the Network Size dropdown, select the size of the network segment for this interface.
e. Enable DHCP Server to allow the interface to supply IP addresses to this network.
You do not need to configure Address range and Netmask. These will be configured by FortiIPAM.
f. Click OK. Port5 gets an IP address from FortiIPAM corresponding to the network size. It will also start assigning
addresses through DHCP. Refresh this page if an IP has not been assigned.
c. Click Login. The FortiIPAM portal opens. The List View displays the assigned IP entries.
d. Double-click an IP entry and click the Source tab. The IP source appears in the Device column. The Interface
column displays the port. Assign Type displays Auto. Last Updated displays the assign time.
3. On FortiGate Root go to Network > Interfaces. The DHCP Server settings are configured automatically.
l Obtained IP/Netmask
l Expiry Date
l Acquired DNS
Use the diagnose command to view the FortiIPAM service information in FortiGate.
Root-E (global) # diagnose test update info
...
System contracts:
...
IPMC,Thu Apr 15 17:00:00 2021
You can also use the REST API to get the FortiIPAM service information.
https://172.16.116.xxx/api/v2/monitor/license/status
..."fortiipam_cloud":{
"type":"live_cloud_service",
"status":"licensed",
"expires":1618531200,
"entitlement":"IPMC"
}
1. On FortiGate Root , edit port5 and configure the interface to be managed by FortiIPAM. Use managed-
subnetwork-size to specify the network size of the network segment for this interface.
In this example, the network size 256.
config system interface
edit "port5"
set ip-managed-by-fortiipam enable
set managed-subnetwork-size 256
next
end
2. On the same interface, enable DHCP server on this interface to supply IP addresses to this network.
Changing the maximum transmission unit (MTU) on FortiGate interfaces changes the size of transmitted packets. Most
FortiGate device's physical interfaces support jumbo frames that are up to 9216 bytes, but some only support 9000 or
9204 bytes.
To avoid fragmentation, the MTU should be the same as the smallest MTU in all of the networks between the FortiGate
and the destination. If the packets sent by the FortiGate are larger than the smallest MTU, then they are fragmented,
slowing down the transmission. Packets with the DF flag set in the IPv4 header are dropped and not fragmented .
On many network and endpoint devices, the path MTU is used to determine the smallest MTU and to transmit packets
within that size.
l ASIC accelerated FortiGate interfaces, such as NP6, NP7, and SOC4 (np6xlite), support MTU sizes up to 9216
bytes.
l FortiGate VMs can have varying maximum MTU sizes, depending on the underlying interface and driver.
l Virtual interfaces, such as VLAN interfaces, inherit their MTU size from their parent interface.
next
end
To manually test the maximum MTU size on a path, you can use the ping command on a Windows computer.
For example, you can send ICMP packets of a specific size with a DF flag, and iterate through increasing sizes until the
ping fails.
l The -f option specifies the Do not Fragment (DF) flag.
l The -l option specifies the length, in bytes, of the Data field in the echo Request messages. This does not include
the 8 bytes for the ICMP header and 20 bytes for the IP header. Therefore, if the maximum MTU is 1500 bytes, then
the maximum supported data size is: 1500 - 8 - 20 = 1472 bytes.
The second test fails, so the maximum MTU size on the path is 1472 bytes + 8-byte ICMP header + 20-byte IP
header = 1500 bytes
The TCP maximum segment size (MSS) is the maximum amount of data that can be sent in a TCP segment. The MSS is
the MTU size of the interface minus the 20 byte IP header and 20 byte TCP header. By reducing the TCP MSS, you can
effectively reduce the MTU size of the packet.
The TCP MSS can be configured in a firewall policy, or directly on an interface.
One-arm sniffer
You can use a one-arm sniffer to configure a physical interface as a one-arm intrusion detection system (IDS). Traffic
sent to the interface is examined for matches to the configured security profile. The matches are logged, and then all
received traffic is dropped. Sniffing only reports on attacks; it does not deny or influence traffic.
You can also use the one-arm sniffer to configure the FortiGate to operate as an IDS appliance to sniff network traffic for
attacks without actually processing the packets. To configure a one-arm IDS, enable sniffer mode on a physical interface
and connect the interface to the SPAN port of a switch or a dedicated network tab that can replicate the traffic to the
FortiGate.
To assign an interface as a sniffer interface in the GUI, go to Network > Interfaces and edit the interface. For Addressing
mode, select One-Arm Sniffer.
If the option is not available, the interface is in use. Ensure that the interface is not selected in any firewall policies,
routes, virtual IPs, or other features where a physical interface is specified. The option does not appear it the role is set to
WAN. Ensure the role is set to LAN, DMZ, or undefined.
The following table lists some of the one-arm sniffer settings you can configure:
Field Description
Filters Enable this setting to include filters that define a more granular sniff of network
traffic. Select specific hosts, ports, VLANs, and protocols.
Field Description
In all cases, enter a number or range for the filter type. The standard protocols
are:
l UDP: 17
l TCP: 6
l ICMP: 1
Include IPv6 Packets If the network is running IPv4 and IPv6 addresses, enable this setting to sniff both
types; otherwise, the FortiGate will only sniff IPv4 traffic.
Include Non-IPv6 Packets Enable this setting for a more intense content scan of the traffic.
Security Profiles The following profiles are configurable in the GUI and CLI:
l Antivirus
l Web filter
l Application control
l IPS
l DLP
l IPS DoS
Traffic scanned on the one-arm sniffer interface is processed by the CPU, even if there is an SPU, such as NPU or CP,
present. The one-arm sniffer may cause higher CPU usage and perform at a lower level than traditional inline scanning,
which uses NTurbo or CP to accelerate traffic when present.
The absence of high CPU usage does not indicate the absence of packet loss. Packet loss may occur due to the
capacity of the TAP devices hitting maximum traffic volume during mirroring, or on the FortiGate when the kernel buffer
size is exceeded and it is unable to handle bursts of traffic.
DNS
Domain name system (DNS) is used by devices to locate websites by mapping a domain name to a website’s IP
address.
A FortiGate can serve different roles based on user requirements:
l A FortiGate can control what DNS server a network uses.
l A FortiGate can function as a DNS server.
FortiGuard Dynamic DNS (DDNS) allows a remote administrator to access a FortiGate's Internet-facing interface using a
domain name that remains constant even when its IP address changes.
FortiOS supports DNS configuration for both IPv4 and IPv6 addressing. When a user requests a website, the FortiGate
looks to the configured DNS servers to provide the IP address of the website in order to know which server to contact to
complete the transaction.
The FortiGate queries the DNS servers whenever it needs to resolve a domain name into an IP address, such as for NTP
or web servers defined by their domain names.
The following topics provide information about DNS:
l Important DNS CLI commands on page 431
l DNS domain list on page 432
l FortiGate DNS server on page 434
l DDNS on page 436
l DNS latency information on page 439
l DNS over TLS on page 441
l DNS troubleshooting on page 442
For a FortiGate with multiple logical CPUs, you can set the DNS process number from 1 to the number of logical CPUs.
The default DNS process number is 1.
config system global
set dnsproxy-worker-count <integer>
end
dns-over-tls
DNS over TLS (DoT) is a security protocol for encrypting and wrapping DNS queries and answers via the Transport
Layer Security (TLS) protocol. It can be enabled, disabled, or enforced:
l disable: Disable DNS over TLS (default).
l enable: Use TLS for DNS queries if TLS is available.
l enforce: Use only TLS for DNS queries. Does not fall back to unencrypted DNS queries if TLS is unavailable.
For more information, see DNS over TLS on page 441.
cache-notfound-responses
When enabled, any DNS requests that are returned with NOT FOUND can be stored in the cache. The DNS server is not
asked to resolve the host name for NOT FOUND entries. By default, this option is disabled.
dns-cache-limit
Set the number of DNS entries that are stored in the cache (0 to 4294967295, default = 5000). Entries that remain in the
cache provide a quicker response to requests than going out to the Internet to get the same information.
dns-cache-ttl
The duration that the DNS cache retains information, in seconds (60 to 86400 (1 day), default = 1800).
You can configure up to eight domains in the DNS settings using the GUI or the CLI.
When a client requests a URL that does not include an FQDN, FortiOS resolves the URL by traversing through the DNS
domain list and performing a query for each domain until the first match is found.
By default, FortiGate uses FortiGuard's DNS servers:
l Primary: 208.91.112.53
l Secondary: 208.91.112.52
You can also customize the DNS timeout time and the number of retry attempts.
In the following example, the local DNS server has the entry for host1 mapped to the FQDN of host1.sample.com, and
the entry for host2 is mapped to the FQDN of host2.example.com.
The DNS timeout and retry settings can be customized using the CLI.
Variable Description
timeout <integer> The DNS query timeout interval, in seconds (1 - 10, default = 5).
retry <integer> The number of times to retry the DNS query (0 - 5, default - 2).
You can create local DNS servers for your network. Depending on your requirements, you can either manually maintain
your entries (primary DNS server), or use it to refer to an outside source (secondary DNS server).
A local, primary DNS server requires that you to manually add all URL and IP address combinations. Using a primary
DNS server for local services can minimize inbound and outbound traffic, and access time. Making it authoritative is not
recommended, because IP addresses can change, and maintaining the list can become labor intensive.
A secondary DNS server refers to an alternate source to obtain URL and IP address combinations. This is useful when
there is a primary DNS server where the entry list is maintained.
FortiGate as a DNS server also supports TLS connections to a DNS client. See DNS over TLS on page 441 for details.
By default, DNS server options are not available in the FortiGate GUI.
Example configuration
This section describes how to create an unauthoritative primary DNS server. The interface mode is recursive so that, if
the request cannot be fulfilled, the external DNS servers will be queried.
9. Disable Authoritative.
d. Configure the remaining settings as needed. The options vary depending on the selected Type.
e. Click OK.
11. Add more DNS entries as needed.
12. Click OK.
13. Enable DNS services on an interface:
a. Go to Network > DNS Servers.
b. In the DNS Service on Interface table, click Create New.
c. Select the Interface for the DNS server, such as wan2.
d. Set the Mode to Recursive.
e. Click OK.
DDNS
If your external IP address changes regularly and you have a static domain name, you can configure the external
interface to use a dynamic DNS (DDNS) service. This ensures that external users and customers can always connect to
your company firewall. If you have a FortiGuard subscription, you can use FortiGuard as the DDNS server.
You can configure FortiGuard as the DDNS server using the GUI or CLI.
Sample topology
In this example, FortiGuard DDNS is enabled and the DDNS server is set to float-zone.com. Other DDNS server options
include fortiddns.com and fortidyndns.com.
6. Click Apply.
If you do not have a FortiGuard subscription, or want to use a different DDNS server, you can configure a DDNS server
for each interface. Only the first configure port appears in the GUI. The available commands vary depending on the
selected DDNS server.
You can configure FortiGate to refresh DDNS IP addresses. FortiGate periodically checks the DDNS server that is
configured.
Disable cleartext
When clear-text is disabled, FortiGate uses the SSL connection to send and receive (DDNS) updates.
To disable cleartext and set the SSL certificate using the CLI:
A DHCP server has an override command option that allows DHCP server communications to go through DDNS to
perform updates for the DHCP client. This enforces a DDNS update of the A field every time even if the DHCP client
does not request it. This allows support for the allow, ignore, and deny client-updates options.
Troubleshooting
To debug DDNS:
Not available:
FortiDDNS status:
ddns_ip=0.0.0.0 ddns_port=443 svr_num=0 domain_num=0
Available:
FortiDDNS status:
ddns_ip=208.91.113.230 ddns_port=443 svr_num=1 domain_num=3
svr[0]= 208.91.113.230
domain[0]= fortiddns.com
domain[1]= fortidyndns.com
domain[2]= float-zone.com
High latency in DNS traffic can result in an overall sluggish experience for end-users. In the DNS Settings pane, you can
quickly identify DNS latency issues in your configuration.
Go to Network > DNS to view DNS latency information in the right side bar. If you use FortiGuard DNS, latency
information for DNS, DNS filter, web filter, and outbreak prevention servers is also visible. Hover your pointer over a
latency value to see when it was last updated.
To view the latency from web filter and outbreak protection servers using the CLI:
Service : Web-filter
Status : Enable
License : Contract
Service : Antispam
Status : Disable
IP Weight RTT Flags TZ Packets Curr Lost Total Lost Updated Time
173.243.138.194 10 0 DI -8 700 0 2 Tue Jan 22 08:02:44
2019
173.243.138.195 10 0 -8 698 0 4 Tue Jan 22 08:02:44
2019
173.243.138.198 10 0 -8 698 0 4 Tue Jan 22 08:02:44
2019
173.243.138.196 10 0 -8 697 0 3 Tue Jan 22 08:02:44
2019
173.243.138.197 10 1 -8 694 0 0 Tue Jan 22 08:02:44
2019
96.45.33.64 10 22 D -8 701 0 6 Tue Jan 22 08:02:44
2019
64.26.151.36 40 62 -5 704 0 10 Tue Jan 22 08:02:44
2019
64.26.151.35 40 62 -5 703 0 9 Tue Jan 22 08:02:44
2019
209.222.147.43 40 70 D -5 696 0 1 Tue Jan 22 08:02:44
2019
66.117.56.42 40 70 -5 697 0 3 Tue Jan 22 08:02:44
2019
66.117.56.37 40 71 -5 702 0 9 Tue Jan 22 08:02:44
2019
65.210.95.239 40 74 -5 695 0 1 Tue Jan 22 08:02:44
2019
65.210.95.240 40 74 -5 695 0 1 Tue Jan 22 08:02:44
2019
45.75.200.88 90 142 0 706 0 12 Tue Jan 22 08:02:44
2019
45.75.200.87 90 155 0 714 0 20 Tue Jan 22 08:02:44
2019
45.75.200.85 90 156 0 711 0 17 Tue Jan 22 08:02:44
2019
45.75.200.86 90 159 0 704 0 10 Tue Jan 22 08:02:44
2019
62.209.40.72 100 157 1 701 0 7 Tue Jan 22 08:02:44
2019
62.209.40.74 100 173 1 705 0 11 Tue Jan 22 08:02:44
2019
62.209.40.73 100 173 1 699 0 5 Tue Jan 22 08:02:44
2019
121.111.236.179 180 138 9 706 0 12 Tue Jan 22 08:02:44
2019
121.111.236.180 180 138 9 704 0 10 Tue Jan 22 08:02:44
2019
DNS over TLS (DoT) is a security protocol for encrypting and wrapping DNS queries and answers via the TLS protocol.
The goal of DNS over TLS is to increase user privacy and security by preventing eavesdropping and manipulation of
DNS data via man-in-the-middle attacks. There is an option in the FortiOS DNS profile settings to enforce DoT for this
added security.
3. Click Apply.
DNS over TLS connections to the FortiGuard secure DNS server is supported. The CLI options are only available when
fortiguard-anycast is enabled. DNS filtering connects to the FortiGuard secure DNS server over anycast by
default.
DNS troubleshooting
The following diagnose command can be used to collect DNS debug information. If you do not specify worker ID, the
default worker ID is 0.
# diagnose test application dnsproxy
worker idx: 0
1. Clear DNS cache
2. Show stats
3. Dump DNS setting
4. Reload FQDN
5. Requery FQDN
6. Dump FQDN
7. Dump DNS cache
8. Dump DNS DB
9. Reload DNS DB
10. Dump secure DNS policy/profile
11. Dump Botnet domain
12. Reload Secure DNS setting
13. Show Hostname cache
14. Clear Hostname cache
15. Show SDNS rating cache
16. Clear SDNS rating cache
17. DNS debug bit mask
99. Restart dnsproxy worker
This section contains instructions for configuring explicit and transparent proxies.
l Explicit web proxy on page 443
l Transparent proxy on page 448
l FTP proxy on page 446
l Proxy policy addresses on page 451
l Proxy policy security profiles on page 459
l Explicit proxy authentication on page 465
l Transparent web proxy forwarding on page 471
l Upstream proxy authentication in transparent proxy mode on page 472
l Multiple dynamic header count on page 474
l Restricted SaaS access (Office 365, G Suite, Dropbox) on page 476
l Explicit proxy and FortiSandbox Cloud on page 479
l Proxy chaining (web proxy forwarding servers) on page 481
l Agentless NTLM authentication for web proxy on page 486
l Multiple LDAP servers in Kerberos keytabs and agentless NTLM domain controllers on page 489
l Learn client IP addresses on page 490
Explicit web proxy can be configured on FortiGate for proxying HTTP and HTTPS traffic.
To deploy explicit proxy, individual client browsers can be manually configured to send requests directly to the proxy, or
they can be configured to download proxy configuration instructions from a Proxy Auto-Configuration (PAC) file.
When explicit proxy is configured on an interface, the interface IP address can be used by client browsers to forward
requests directly to the FortiGate. FortiGate also supports PAC file configuration.
c. Select port2 as the Listen on Interfaces and set the HTTP Port to 8080.
d. Configure the remaining settings as needed.
e. Click Apply.
2. Create an explicit web proxy policy:
a. Go to Policy & Objects > Proxy Policy.
b. Click Create New.
c. Set Proxy Type to Explicit Web and Outgoing Interface to port1.
d. Also set Source and Destination to all, Schedule to always, Service to webproxy, and Action to ACCEPT.
This example creates a basic policy. If required, security profiles can be enabled, and deep
SSL inspection can be selected to inspect HTTPS traffic.
edit "port2"
set vdom "vdom1"
set ip 10.1.100.1 255.255.255.0
set allowaccess ping https ssh snmp http telnet
set type physical
set explicit-web-proxy enable
set snmp-index 12
end
next
end
This example creates a basic policy. If required, security profiles can be enabled, and deep
SSL inspection can be selected to inspect HTTPS traffic.
FTP proxy
FTP proxies can be configured on the FortiGate so that FTP traffic can be proxied. When the FortiGate is configured as
an FTP proxy, FTP client applications should be configured to send FTP requests to the FortiGate.
e. Click Apply.
2. Create an explicit FTP proxy policy:
a. Go to Policy & Objects > Proxy Policy.
b. Click Create New.
c. Set Proxy Type to FTP and Outgoing Interface to port1.
d. Also set Source and Destination to all, Schedule to always, and Action to ACCEPT.
This example creates a basic policy. If required, security profiles can be enabled.
This example creates a basic policy. If required, security profiles can be enabled.
Transparent proxy
In a transparent proxy deployment, the user's client software, such as a browser, is unaware that it is communicating
with a proxy.
Users request Internet content as usual, without any special client configuration, and the proxy serves their requests.
FortiGate also allows user to configure in transparent proxy mode.
By default, HTTP redirect can only be enabled in the CLI. Enable Policy Advanced
Options in Feature Visibility to configure it in the GUI. See Feature visibility on page
925 on page 1 for more information.
To redirect HTTPS traffic, SSL inspection is required.
This example creates a basic policy. If required, security profiles can be enabled, and deep
SSL inspection can be selected to inspect HTTPS traffic.
3. No special configure is required on the client to use FortiGate transparent proxy. As the client is using the FortiGate
as its default gateway, requests will first hit the regular firewall policy, and then be redirected to the transparent
proxy policy.
This example creates a basic policy. If required, security profiles can be enabled, and deep
SSL inspection can be selected to inspect HTTPS traffic.
3. No special configure is required on the client to use FortiGate transparent proxy. As the client is using the FortiGate
as its default gateway, requests will first hit the regular firewall policy, and then be redirected to the transparent
proxy policy.
Proxy addresses are designed to be used only by proxy policies. The following address types are available:
l Host regex match on page 451
l URL pattern on page 452
l URL category on page 453
l HTTP method on page 454
l HTTP header on page 455
l User agent on page 456
l Advanced (source) on page 457
l Advanced (destination) on page 458
The fast policy match function improves the performance of IPv4 explicit and transparent web proxies on FortiGate
devices.
When enabled, after the proxy policies are configured, the FortiGate builds a fast searching table based on the different
proxy policy matching criteria. When fast policy matching is disabled, web proxy traffic is compared to the policies one at
a time from the beginning of the policy list.
Fast policy matching is enabled by default, and can be configured with the following CLI command:
config web-proxy global
set fast-policy-match {enable | disable}
end
In this address type, a user can create a hostname as a regular expression. Once created, the hostname address can be
selected as a destination of a proxy policy. This means that a policy will only allow or block requests that match the
regular expression.
This example creates a host regex match address with the pattern qa.[a-z]*.com.
4. Click OK.
URL pattern
In this address type, a user can create a URL path as a regular expression. Once created, the path address can be
selected as a destination of a proxy policy. This means that a policy will only allow or block requests that match the
regular expression.
This example creates a URL pattern address with the pattern /filetypes/.
l Type to URL Pattern,
4. Click OK.
URL category
In this address type, a user can create a URL category based on a FortiGuard URL ID. Once created, the address can be
selected as a destination of a proxy policy. This means that a policy will only allow or block requests that match the URL
category.
The example creates a URL category address for URLs in the Education category. For more information about
categories, see https://fortiguard.com/webfilter/categories.
For information about creating and using custom local and remote categories, see Web rating override on page 1266
and Threat feeds on page 355.
l Name to url-category,
4. Click OK.
To see a list of all the categories and their numbers, when editing the address, enter set category ?.
HTTP method
In this address type, a user can create an address based on the HTTP request methods that are used. Multiple method
options are supported, including: CONNECT, DELETE, GET, HEAD, OPTIONS, POST, PUT, and TRACE. Once
created, the address can be selected as a source of a proxy policy. This means that a policy will only allow or block
requests that match the selected HTTP method.
The example creates a HTTP method address that uses the GET method.
l Name to method_get,
4. Click OK.
HTTP header
In this address type, a user can create a HTTP header as a regular expression. Once created, the header address can
be selected as a source of a proxy policy. This means that a policy will only allow or block requests where the HTTP
header matches the regular expression.
This example creates a HTTP header address with the pattern Q[A-B].
l Name to HTTP-header,
l Host to all,
4. Click OK.
User agent
In this address type, a user can create an address based on the names of the browsers that are used as user agents.
Multiple browsers are supported, such as Chrome, Firefox, Internet Explorer, and others. Once created, the address can
be selected as a source of a proxy policy. This means that a policy will only allow or block requests from the specified
user agent.
This example creates a user agent address for Google Chrome.
l Name to UA-Chrome,
4. Click OK.
Advanced (source)
In this address type, a user can create an address based on multiple parameters, including HTTP method, User Agent,
and HTTP header. Once created, the address can be selected as a source of a proxy policy. This means that a policy will
only allow or block requests that match the selected address.
This example creates an address that uses the get method, a user agent for Google Chrome, and an HTTP header with
the pattern Q[A-B].
l Name to advanced_src,
l Host to all,
4. Click OK.
Advanced (destination)
In this address type, a user can create an address based on URL pattern and URL category parameters. Once created,
the address can be selected as a destination of a proxy policy. This means that a policy will only allow or block requests
that match the selected address.
This example creates an address with the URL pattern /about that are in the Education category. For more information
about categories, see https://fortiguard.com/webfilter/categories.
l Name to Advanced-dst,
4. Click OK.
Security profiles must be created before they can be used in a policy, see Security Profiles on
page 1102 for information.
Source all
Destination all
Schedule always
Service webproxy
Action ACCEPT
AntiVirus av
IPS Sensor-1
ICAP default
Transparent proxy
Source all
Destination all
Schedule always
Service webproxy
Action ACCEPT
AntiVirus av
IPS Sensor-1
ICAP default
FTP proxy
Source all
Destination all
Schedule always
Action ACCEPT
AntiVirus av
IPS Sensor-1
FortiGate supports multiple authentication methods. This topic explains using an external authentication server with
Kerberos as the primary and NTLM as the fallback.
4. Create an explicit proxy policy and assign a user group to the policy on page 469.
5. Verify the configuration on page 470.
Since we are using an external authentication server with Kerberos authentication as the primary and NTLM as the
fallback, Kerberos authentication is configured first and then FSSO NTLM authentication is configured.
For successful authorization, the FortiGate checks if user belongs to one of the groups that is permitted in the security
policy.
Name ldap-kerberos
Server IP 172.18.62.220
d. Click OK
2. Define Kerberos as an authentication service. This option is only available in the CLI. For information on generating
a keytab, see Generating a keytab on a Windows server on page 470.
3. Configure FSSO NTLM authentication:
FSSO NTLM authentication is supported in a Windows AD network. FSSO can also provide NTLM authentication
service to the FortiGate unit. When a user makes a request that requires authentication, the FortiGate initiates
NTLM negotiation with the client browser, but does not process the NTLM packets itself. Instead, it forwards all the
NTLM packets to the FSSO service for processing.
a. Go to Security Fabric > External Connectors.
b. Click Create New and select Fortinet Single Sign-On Agent from the Endpoint/Identity category.
c. Set the Name to FSSO, Primary FSSO Agent to 172.16.200.220, and enter a password.
d. Click OK.
4. Create a user group for Kerberos authentication:
a. Go to User & Authentication > User Groups.
b. Click Create New.
c. Set the Name to Ldap-Group, and Type to Firewall.
d. In the Remote Groups table, click Add, and set the Remote Server to the previously created ldap-kerberos
server.
e. Click OK.
5. Create a user group for NTLM authentication:
a. Go to User & Authentication > User Groups.
b. Click Create New.
c. Set the Name to NTLM-FSSO-Group, Type to Fortinet Single Sign-On (FSSO), and add FORTINETQA/FSSO
as a member.
d. Click OK.
For information on generating a keytab, see Generating a keytab on a Windows server on page 470.
3. Configure FSSO NTLM authentication:
config user fsso
edit "1"
set server "172.18.62.220"
set password *********
next
end
Explicit proxy authentication is managed by authentication schemes and rules. An authentication scheme must be
created first, and then the authentication rule.
Create an explicit proxy policy and assign a user group to the policy
To create an explicit proxy policy and assign a user group to it in the GUI:
To create an explicit proxy policy and assign a user group to it in the CLI:
Log in using a domain and system that would be authenticated using the Kerberos server, then enter the diagnose
wad user list CLI command to verify:
# diagnose wad user list
ID: 8, IP: 10.1.100.71, VDOM: vdom1
user name : [email protected]
duration : 389
auth_type : IP
auth_method : Negotiate
pol_id : 1
g_id : 1
user_based : 0
expire : no
LAN:
bytes_in=4862 bytes_out=11893
WAN:
bytes_in=7844 bytes_out=1023
Log in using a system that is not part of the domain. The NTLM fallback server should be used:
# diagnose wad user list
ID: 2, IP: 10.1.100.202, VDOM: vdom1
user name : TEST31@FORTINETQA
duration : 7
auth_type : IP
auth_method : NTLM
pol_id : 1
g_id : 5
user_based : 0
expire : no
LAN:
bytes_in=6156 bytes_out=16149
WAN:
bytes_in=7618 bytes_out=1917
A keytab is used to allow services that are not running Windows to be configured with service instance accounts in the
Active Directory Domain Service (AD DS). This allows Kerberos clients to authenticate to the service through Windows
Key Distribution Centers (KDCs).
For an explanation of the process, see https://docs.microsoft.com/en-us/windows-server/administration/windows-
commands/ktpass.
For example:
ktpass -princ HTTP/[email protected] -mapuser FGT -pass ***********
-crypto all -ptype KRB5_NT_PRINCIPAL -out fgt.keytab
In FortiOS, there is an option to enable proxy forwarding for transparent web proxy policies and regular firewall policies
for HTTP and HTTPS.
In previous versions of FortiOS, you could forward proxy traffic to another proxy server (proxy chaining) with explicit
proxy. Now, you can forward web traffic to the upstream proxy without having to reconfigure your browsers or publish a
proxy auto-reconfiguration (PAC) file.
Once configured, the FortiGate forwards traffic generated by a client to the upstream proxy. The upstream proxy then
forwards it to the server.
next
end
A downstream proxy FortiGate that needs to be authenticated by the upstream web proxy can use the basic
authentication method to send its username and password, in the base64 format, to the upstream web proxy for
authentication. If the authentication succeeds, web traffic that is forwarded from the downstream proxy FortiGate to the
upstream proxy can be accepted and forwarded to its destinations.
In this example, a school has a FortiGate acting as a downstream proxy that is configured with firewall policies for each
user group (students and staff). In each policy, a forwarding server is configured to forward the web traffic to the
upstream web proxy.
The username and password that the upstream web proxy uses to authenticate the downstream proxy are configured on
the forwarding server, and are sent to the upstream web proxy with the forwarded HTTP requests.
Username Password
On the downstream FortiGate, configure forwarding servers with the usernames and passwords for authentication on
the upstream web proxy, then apply those servers to firewall policies for transparent proxy. For explicit web proxy, the
forwarding servers can be applied to proxy policies.
When the transparent proxy is configured, clients can access websites without configuring a web proxy in their browser.
The downstream proxy sends the username and password to the upstream proxy with forwarded HTTP requests to be
authenticated.
Multiple dynamic headers are supported for web proxy profiles, as well as Base64 encoding and the append/new
options.
Administrators only have to select the dynamic header in the profile. The FortiGate will automatically display the
corresponding static value. For example, if the administrator selects the $client-ip header, the FortiGate will display
the actual client IP address.
The supported headers are:
2. Configure FSSO:
config user fsso
edit "1"
set server "172.18.62.220"
set password *********
next
end
6. Create a web proxy profile that adds a new dynamic and custom Via header:
config web-proxy profile
edit "test"
set log-header-change enable
config headers
edit 1
set name "client-ip"
set content "$client-ip"
next
edit 2
set name "Proxy-Name"
set content "$proxy_name"
next
edit 3
set name "user"
set content "$user"
next
edit 4
set name "domain"
set content "$domain"
next
edit 5
set name "local_grp"
set content "$local_grp"
next
edit 6
set name "remote_grp"
set content "$remote_grp"
next
edit 7
set name "Via"
set content "Fortigate-Proxy"
next
end
next
end
7. In the proxy policy, append the web proxy profile created in the previous step:
config firewall proxy-policy
edit 1
8. Once traffic is being generated from the client, look at the web filter logs to verify that it is working.
The corresponding values for all the added header fields displays in the Change headers section at the bottom of
the Log Details pane.
1: date=2019-02-07 time=13:57:24 logid="0344013632" type="utm" subtype="webfilter"
eventtype="http_header_change" level="notice" vd="vdom1" eventtime=1549576642 policyid=1
transid=50331689 sessionid=1712788383 user="TEST21@FORTINETQA" group="NTLM-FSSO"
profile="test" srcip=10.1.100.116 srcport=53278 dstip=172.16.200.46 dstport=80
srcintf="port2" srcintfrole="undefined" dstintf="port1" dstintfrole="undefined" proto=6
service="HTTP" url="http://172.16.200.46/" agent="curl/7.22.0" chgheaders="Added=client-
ip: 10.1.100.116|Proxy-Name: 1.1 100D.qa|user: TEST21|domain: FORTINETQA|local_grp:
NTLM-FSSO|remote_grp: FORTINETQA/FSSO|Via: Fortigate-Proxy"
With the web proxy profile, you can specify access permissions for Microsoft Office 365, Google G Suite, and Dropbox.
You can insert vendor-defined headers that restrict access to the specific accounts. You can also insert custom headers
for any destination.
You can configure the web proxy profile with the required headers for the specific destinations, and then directly apply it
to a policy to control the header's insertion.
To implement Office 365 tenant restriction, G Suite account access control, and Dropbox network
access control:
Due to vendors' changing requirements, this example may no longer comply with the vendors'
official guidelines.
To create a web proxy profile for access control using the CLI:
edit 4
set name "X-Dropbox-allowed-Team-Ids" <----header defined by Dropbox
set dstaddr "wildcard.dropbox.com" <----build-in destination address
for Dropbox
set action add-to-request
set base64-encoding disable
set add-option new
set protocol https http
set content "dbmid:FDFSVF-DFSDF" <----your team-Id in Dropbox
next
end
next
end
References
l Office 365: Use tenant restrictions to manage access to SaaS cloud applications
l G Suite: Block access to consumer accounts
l Dropbox: Network control
Explicit proxy connections can leverage FortiSandbox Cloud for advanced threat scanning and updates. This allows
FortiGates behind isolated networks to connect to FortiCloud services.
ip=172.16.102.21
[268] fds_svr_default_on_established: server-Cloud-sandbox-controller handles cmd-23
[102] fds_pack_objects: number of objects: 1
[75] fds_print_msg: FCPC: len=109
[81] fds_print_msg: Protocol=2.0
[81] fds_print_msg: Command=RegionList
[81] fds_print_msg: Firmware=FG101E-FW-6.02-0917
[81] fds_print_msg: SerialNumber=FG101E4Q17002429
[81] fds_print_msg: TimeZone=-7
[75] fds_print_msg: http req: len=248
[81] fds_print_msg: POST https://172.16.102.21:443/FCPService HTTP/1.1
[81] fds_print_msg: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
[81] fds_print_msg: Host: 172.16.102.21:443
[81] fds_print_msg: Cache-Control: no-cache
[81] fds_print_msg: Connection: close
[81] fds_print_msg: Content-Type: application/octet-stream
[81] fds_print_msg: Content-Length: 301
[524] fds_https_connect: http request to 172.16.102.21: header=248, ext=301.
[257] fds_https_send: sent 248 bytes: pos=0, len=248
[265] fds_https_send: 172.16.102.21: sent 248 byte header, now send 301-byte body
[257] fds_https_send: sent 301 bytes: pos=0, len=301
[273] fds_https_send: sent the entire request to server: 172.16.102.21:443
[309] fds_https_recv: read 413 bytes: pos=413, buf_len=2048
[332] fds_https_recv: received the header from server: 172.16.102.21:443, [HTTP/1.1 200
Content-Type: application/octet-stream
Content-Length: 279
Date: Thu, 20 Jun 2019 16:41:11 GMT
Connection: close]
[396] fds_https_recv: Do memmove buf_len=279, pos=279
[406] fds_https_recv: server: 172.16.102.21:443, buf_len=279, pos=279
[453] fds_https_recv: received a packet from server-172.16.102.21:443: sz=279, objs=1
[194] __ssl_data_ctx_free: Done
[839] ssl_free: Done
[830] ssl_disconnect: Shutdown
[481] fds_https_recv: obj-0: type=FCPR, len=87
[294] fds_svr_default_on_response: server-Cloud-sandbox-controller handles cmd-23
[75] fds_print_msg: fcpr: len=83
[81] fds_print_msg: Protocol=2.0
[81] fds_print_msg: Response=202
[81] fds_print_msg: ResponseItem=Region:Europe,Global,Japan,US
[81] fds_print_msg: existing:Japan
[3220] aptctrl_region_res: Got rsp: Region:Europe,Global,Japan,US
[3222] aptctrl_region_res: Got rsp: Region existing:Japan
[439] fds_send_reply: Sending 28 bytes data.
[395] fds_free_tsk: cmd=23; req.noreply=1
# [136] fds_on_sys_fds_change: trace
[2942] fds_handle_request: Received cmd 22 from pid-170, len 0
[40] fds_queue_task: req-22 is added to Cloud-sandbox-controller
[587] fds_https_start_server: server: 172.16.102.21:443
[579] ssl_new: SSL object is created
[117] https_create: proxy server 172.16.200.44 port:3128
[519] fds_https_connect: https_connect(172.16.102.21) is established.
[261] fds_svr_default_on_established: Cloud-sandbox-controller has connected to
ip=172.16.102.21
[268] fds_svr_default_on_established: server-Cloud-sandbox-controller handles cmd-22
[102] fds_pack_objects: number of objects: 1
For the explicit web proxy you can configure web proxy forwarding servers to use proxy chaining to redirect web proxy
sessions to other proxy servers. Proxy chaining can be used to forward web proxy sessions from the FortiGate unit to
one or more other proxy servers on your network or on a remote network. You can use proxy chaining to integrate the
FortiGate explicit web proxy with a web proxy solution that you already have in place.
A FortiGate unit can forward sessions to most web proxy servers including a remote FortiGate unit with the explicit web
proxy enabled. No special configuration of the explicit web proxy on the remote FortiGate unit is required.
You can deploy the explicit web proxy with proxy chaining in an enterprise environment consisting of small satellite
offices and a main office. If each office has a FortiGate unit, users at each of the satellite offices can use their local
FortiGate unit as an explicit web proxy server. The satellite office FortiGate units can forward explicit web proxy sessions
to an explicit web proxy server at the central office. From here the sessions can connect to web servers on the Internet.
FortiGate proxy chaining does not support web proxies in the proxy chain authenticating each other.
The following examples assume explicit web proxy has been enabled.
Proxy Address Type Select the type of IP address of the forwarding server. A forwarding server can
have an FQDN or IP address.
Port Enter the port number on which the proxy receives connections. Traffic leaving
the FortiGate explicit web proxy for this server has its destination port number
changed to this number.
Server Down Action Select the action the explicit web proxy will take if the forwarding server is
down.
l Block: Blocks the traffic if the remote server is down.
l Use Original Server: Forwards the traffic from the FortiGate to its
Example
The following example adds a web proxy forwarding server named fwd-srv at address proxy.example.com and port
8080.
By default, a FortiGate unit monitors a web proxy forwarding server by forwarding a connection to the remote server
every 10 seconds. The remote server is assumed to be down if it does not respond to the connection. FortiGate
continues checking the server. The server is assumed to be back up when the server sends a response. If you enable
health checking, the FortiGate unit attempts to get a response from a web server every 10 seconds by connecting
through the remote forwarding server.
You can configure health checking for each remote server and specify a different website to check for each one.
If the remote server is found to be down you can configure the FortiGate unit to block sessions until the server comes
back up or to allow sessions to connect to their destination, bypassing the remote forwarding server. You cannot
configure the FortiGate unit to fail over to another remote forwarding server.
Server Down Action Select the action the explicit web proxy will take if the forwarding server is
down.
l Block: Blocks the traffic if the remote server is down.
l Use Original Server: Forwards the traffic from the FortiGate to its
4. Click OK.
Example
The following example enables health checking for a web proxy forwarding server and sets the server down option to
bypass the forwarding server if it is down.
You can add multiple web proxy forwarding servers to a forwarding server group and then add the server group to an
explicit web proxy policy instead of adding a single server. Forwarding server groups are created from the FortiGate CLI
but can be added to policies from the web-based manager (or from the CLI).
When you create a forwarding server group you can select a load balancing method to control how sessions are load
balanced to the forwarding servers in the server group. Two load balancing methods are available:
l Weighted load balancing sends more sessions to the servers with higher weights. You can configure the weight for
each server when you add it to the group.
l Least-session load balancing sends new sessions to the forwarding server that is processing the fewest sessions.
When you create a forwarding server group you can also enable affinity. Enable affinity to have requests from the same
client processed by the same server. This can reduce delays caused by using multiple servers for a single multi-step
client operation. Affinity takes precedence over load balancing.
You can also configure the behavior of the group if all of the servers in the group are down. You can select to block traffic
or you can select to have the traffic pass through the FortiGate explicit proxy directly to its destination instead of being
sent to one of the forwarding servers.
Example
The following example adds a forwarding server group that uses weighted load balancing to load balance traffic to three
forwarding servers. Server weights are configured to send most traffic to server2. The group has affinity enabled
and blocks traffic if all of the forward servers are down.
set weight 10
next
end
You can enable proxy chaining for web proxy sessions by adding a web proxy forwarding server or server group to an
explicit web proxy policy. In a policy you can select one web proxy forwarding server or server group. All explicit web
proxy traffic accepted by this security policy is forwarded to the specified web proxy forwarding server or server group.
1. Go to Policy & Objects > Proxy Policy and click Create New.
2. Configure the policy settings:
Source Internal_subnet
Destination all
Schedule always
Service webproxy
Action Accept
3. Enable Web Proxy Forwarding Server and select the forwarding server, (for example,fwd-srv).
4. Click OK.
Example
The following example adds a security policy that allows all users on the 10.31.101.0 subnet to use the explicit web
proxy for connections through the wan1 interface to the Internet. The policy forwards web proxy sessions to a remote
forwarding server named fwd-srv.
A FortiGate can handle TLS 1.3 traffic in both deep and certificate inspection modes.
Example
The following example demonstrates that the Squid server and the FortiGate can handle TLS 1.3 traffic.
The following output from the Squid server demonstrates that the FortiGate supports TLS 1.3 traffic and forwards the
hello retry request back to the client PC. The client PC then sends the client hello again, and the connection is
successfully established.
Agentless Windows NT LAN Manager (NTLM) authentication includes support for the following items:
l Multiple servers
l Individual users
You can use multiple domain controller servers for the agentless NTLM. They can be used for load balancing and high
service stability.
You can also use user-based matching in groups for Kerberos and agentless NTLM. In these scenarios, FortiOS
matches the user's group information from an LDAP server.
To support multiple domain controllers for agentless NTLM using the CLI:
Multiple LDAP servers in Kerberos keytabs and agentless NTLM domain controllers
Multiple LDAP servers can be configured in Kerberos keytabs and agentless NTLM domain controllers for multi-forest
deployments.
To use multiple LDAP servers in Kerberos keytabs and agentless NTLM domain controllers:
Learning the actual client IP addresses is imperative for authorization. This function identifies the real client IP address
when there is a NATing device between the FortiGate and the client.
config web-proxy global
set learn-client-ip {enable | disable}
set learn-client-ip-from-header {true-client-ip | x-real-ip | x-forwarded-for}
set learn-client-ip-srcaddr <address> ... <address>
end
Example
In this example, the real client IP address is used to match a policy for FSSO authentication.
DHCP server
A DHCP server provides an address from a defined address range to a client on the network, when requested.
You can configure one or more DHCP servers on any FortiGate interface. A DHCP server dynamically assigns IP
addresses to hosts on the network connected to the interface. The host computers must be configured to obtain their IP
addresses using DHCP.
You can configure a FortiGate interface as a DHCP relay. The interface forwards DHCP requests from DHCP clients to
an external DHCP server and returns the responses to the DHCP clients. The DHCP server must have appropriate
routing so that its response packets to the DHCP clients arrive at the unit.
For more information about options, see:
l DHCP options on page 492
l IP address assignment with relay agent information option on page 494
l DHCP client options on page 496
DHCP options
When adding a DHCP server, you can include DHCP codes and options. The DHCP options are BOOTP vendor
information fields that provide additional vendor-independent configuration parameters to manage the DHCP server. For
example, you might need to configure a FortiGate DHCP server that gives out a separate option as well as an IP
address, such as an environment that needs to support PXE boot with Windows images.
The option numbers and codes are specific to the application. The documentation for the application indicates the values
to use. Option codes are represented in a option value/HEX value pairs. The option is a value between 1 and 255.
You can add up to three DHCP code/option pairs per DHCP server.
For detailed information about DHCP options, see RFC 2132, DHCP Options and BOOTP Vendor Extensions.
Option 82
The DHCP relay agent information option (option 82 in RFC 3046) helps protect the FortiGate against attacks such as
spoofing (forging) of IP addresses and MAC addresses, and DHCP IP address starvation.
This option is disabled by default. However, when dhcp-relay-service is enabled, dhcp-relay-agent-option
becomes enabled.
See IP address assignment with relay agent information option on page 494 for an example.
Option 42
Option 82 (DHCP relay information option) helps protect the FortiGate against attacks such as spoofing (or forging) of IP
and MAC addresses, and DHCP IP address starvation.
The following CLI variables are included in the config system dhcp server > config reserved-address
command:
When an interface is in DHCP addressing mode, DHCP client options can be configured in the CLI. For example, a
vendor class identifier (usually DCHP client option 60) can be specified so that a request can be matched by a specific
DHCP offer.
Multiple options can be configured, but any options not recognized by the DHCP server are discarded.
Variable Description
code <integer> DHCP client option code (0 - 255, default = 0).
Variable Description
Static routing
Static routing is one of the foundations of firewall configuration. It is a form of routing in which a device uses manually-
configured routes. In the most basic setup, a firewall will have a default route to its gateway to provide network access. In
a more complex setup with dynamic routing, ADVPN, or SD-WAN involved, you would still likely find static routes being
deployed.
This section explores concepts in using static routing and provides examples in common use cases:
l Routing concepts on page 498
l Policy routes on page 507
l Equal cost multi-path on page 510
l Dual internet connections on page 514
The following topics include additional information about static routes:
l Deploying the Security Fabric on page 178
l Security Fabric over IPsec VPN on page 195
l Viewing and controlling network risks via topology view on page 177
l Adding a static route on page 584
l Configure VDOM-A on page 827
l Configure VDOM-A on page 836
l IPsec VPN in an HA environment on page 1415
l IPsec VPN to Azure with virtual network gateway on page 1339
l FortiGate as dialup client on page 1360
l ADVPN with BGP as the routing protocol on page 1479
l ADVPN with OSPF as the routing protocol on page 1488
l ADVPN with RIP as the routing protocol on page 1497
l Basic site-to-site VPN with pre-shared key on page 1301
l Site-to-site VPN with digital certificate on page 1306
l Site-to-site VPN with overlapping subnets on page 1313
l Tunneled Internet browsing on page 1390
l FortiGate multiple connector support on page 1806
l IPsec aggregate for redundancy and traffic load-balancing on page 1421
l Use MAC addresses in SD-WAN rules and policy routes on page 632
l Using BGP tags with SD-WAN rules on page 668
Routing concepts
Default route
The default route has a destination of 0.0.0.0/0.0.0.0, representing the least specific route in the routing table. It is
a catch all route in the routing table when traffic cannot match a more specific route. Typically this is configured with a
static route with an administrative distance of 10. In most instances, you will configure the next hop interface and the
gateway address pointing to your next hop. If your FortiGate is sitting at the edge of the network, your next hop will be
your ISP gateway. This provides internet access for your network.
Sometimes the default route is configured through DHCP. On some desktop models, the WAN interface is preconfigured
in DHCP mode. Once the WAN interface is plugged into the network modem, it will receive an IP address, default
gateway, and DNS server. FortiGate will add this default route to the routing table with a distance of 5, by default. This
will take precedence over any default static route with a distance of 10. Therefore, take caution when you are configuring
an interface in DHCP mode, where Retrieve default gateway from server is enabled. You may disable it and/or change
the distance from the Network > Interfaces page when you edit an interface.
Dynamic Gateway When enabled, a selected DHCP/PPPoE interface will automatically retrieve
its dynamic gateway.
Destination l Subnet
Enter the destination IP address and netmask. A value of
0.0.0.0/0.0.0.0 creates a default route.
l Named Address
Select an address or address group object. Only addresses with static
route configuration enabled will appear on the list. This means a
Interface Select the name of the interface that the static route will connect through.
Gateway Address Enter the gateway IP address. When selecting an IPsec VPN interface or SD-
WAN creating a blackhole route, the gateway cannot be specified.
Administrative Distance Enter the distance value, which will affect which routes are selected first by
different protocols for route management or load balancing. The default is 10.
Advanced Options Optionally, expand Advanced Options and enter a Priority. When two routes
have an equal distance, the route with a lower priority number will take
precedence. The default is 0.
3. Click OK.
You can configure FQDN firewall addresses as destination addresses in a static route, using either the GUI or the CLI.
In the GUI, to add an FQDN firewall address to a static route in the firewall address configuration, enable the Static
Route Configuration option. Then, when you configure the static route, set Destination to Named Address.
Routing table
A routing table consists of only the best routes learned from the different routing protocols. The most specific route
always takes precedence. If there is a tie, then the route with a lower administrative distance will be injected into the
routing table. If administrative distances are also equal, then all the routes are injected into the routing table, and Cost
and Priority become the deciding factors on which a route is preferred. If these are also equal, then FortiGate will use
Equal cost multi-path on page 510 to distribute traffic between these routes.
You can view routing tables in the FortiGate GUI under Dashboard > Network > Static & Dynamic Routing by default.
Expand the widget to see the full page. Additionally, if you want to convert the widget into a dashboard, click on the Save
To view more columns, right-click on the column header to select the columns to be displayed:
Field Description
Network The IP addresses and network masks of destination networks that the FortiGate can reach.
Interfaces The interface through which packets are forwarded to the gateway of the destination network.
Distance The administrative distance associated with the route. A lower value means the route is
preferable compared to other routes to the same destination.
Type The type values assigned to FortiGate routes (Static, Connected, RIP, OSPF, or BGP):
l Connected: All routes associated with direct connections to FortiGate interfaces
l Static: The static routes that have been added to the routing table manually
l RIPNG: All routes learned through RIP version 6 (which enables the sharing of routes
Field Description
Metric The metric associated with the route type. The metric of a route influences how the FortiGate
dynamically adds it to the routing table. The following are types of metrics and the protocols
they are applied to:
l Hop count: Routes learned through RIP
l Multi-Exit Discriminator (MED): Routes learned through BGP. By default, the MED value
associated with a BGP route is zero. However, the MED value can be modified
dynamically. If the value was changed from the default, the Metric column displays a non-
zero value.
Priority In static routes, priorities are 0 by default. When two routes have an equal distance, the route
with the lower priority number will take precedence.
VRF Virtual routing and forwarding (VRF) allows multiple routing table instances to co-exist. VRF
can be assigned to an Interface. Packets are only forwarded between interfaces with the
same VRF.
Up Since The total accumulated amount of time that a route learned through RIP, OSPF, or BGP has
been reachable.
Viewing the routing table using the CLI displays the same routes as you would see from the GUI.
If VDOMs are enabled on the FortiGate, all routing-related CLI commands must be run within a VDOM and not in the
global context.
Examining an entry:
Value Description
B BGP. The routing protocol used.
192.168.0.0/24 The destination of this route, including netmask.
[20/0] 20 indicates an administrative distance of 20 out of a range of 0 to 255. 0 is an additional
metric associated with this route, such as in OSPF.
172.31.0.1 The gateway or next hop.
MPLS The interface that the route uses.
The routing database consists of all learned routes from all routing protocols before they are injected into the routing
table. This likely lists more routes than the routing table as it consists of routes to the same destinations with different
distances. Only the best routes are injected into the routing table. However, it is useful to see all learned routes for
troubleshooting purposes.
Selected routes are marked by the > symbol. In the above example, the OSPF route to destination 172.31.0.0/30 is
not selected.
The kernel routing table makes up the actual Forwarding Information Base (FIB) that used to make forwarding decisions
for each packet. The routes here are often referred to as kernel routes. Parts of this table are derived from the routing
table that is generated by the routing daemon.
Value Description
tab Table number: It will either be 254 (unicast) or 255 (multicast).
vf Virtual domain of the firewall: It is the VDOM index number. If
VDOMs are not enabled, this number is 0.
type Type of routing connection. Valid values include:
l 0 - unspecific
l 1 - unicast
l 2 - local
l 3 - broadcast
l 4 - anycast
l 5 - multicast
l 6 - blackhole
Value Description
l 7 - unreachable
l 8 - prohibited
proto Type of installation that indicates where the route came from.
Valid values include:
l 0 - unspecific
l 2 - kernel
l 14 - FortiOS
l 15 - HA
l 16 - authentication based
l 17 - HA1
Route cache
The route cache contains recently used routing entries in a table. It is consulted before the routing table to speed up the
route look-up process.
The size of the route cache is calculated by the kernel. However, you can modify it.
Route look-up
Route look-up typically occurs twice in the life of a session. Once when the first packet is sent by the originator and once
more when the first reply packet is sent from the responder. When a route look-up occurs, the routing information is
written to the session table and the route cache. If routing changes occur during the life of a session, additional routing
look-ups may occur.
FortiGate performs a route look-up in the following order:
1. Policy-based routes: If a match occurs and the action is to forward, traffic is forwarded based on the policy route.
2. Route Cache: If there are no matches, FortiGate looks for the route in the route cache.
3. Forwarding Information Base, otherwise known as the kernel routing table.
4. If no match occurs, the packet is dropped.
When there are many routes in your routing table, you can perform a quick search by using the search bar to specify your
criteria, or apply filters on the column header to display only certain routes. For example, if you want to only display static
routes, you may use "static" as the search term, or filter by the Type field with value Static.
Route look-up on the other hand provides a utility for you to enter criteria such as Destination, Destination Port, Source,
Protocol and/or Source Interface, in order to determine the route that a packet will take. Once you click Search, the
corresponding route will be highlighted.
You can also use the CLI for a route look-up. The CLI provides a basic route look-up tool.
Blackhole routes
Sometimes upon routing table changes, it is not desirable for traffic to be routed to a different gateway. For example, you
may have traffic destined for a remote office routed through your IPsec VPN interface. When the VPN is down, traffic will
try to re-route to another interface. However, this may not be viable and traffic will instead be routed to your default route
through your WAN, which is not desirable. Traffic may also be routed to another VPN, which you do not want. For such
scenarios, it is good to define a blackhole route so that traffic is dropped when your desired route is down. Upon
reconnection, your desired route is once again added to the routing table and your traffic will resume routing to your
desired interface. For this reason, blackhole routes are created when you configure an IPsec VPN using the IPsec
wizard.
Route priority for a Blackhole route can only be configured from the CLI.
Whenever a packet arrives at one of the interfaces on a FortiGate, the FortiGate determines whether the packet was
received on a legitimate interface by doing a reverse look-up using the source IP address in the packet header. This
protects against IP spoofing attacks. If the FortiGate does not have a route to the source IP address through the interface
on which the packet was received, the FortiGate drops the packet as per Reverse Path Forwarding (RPF) check. There
are two modes of RPF – feasible path and strict. The default feasible RPF mode checks only for the existence of at least
one active route back to the source using the incoming interface. The strict RPF check ensures the best route back to the
source is used as the incoming interface.
You can remove RPF state checks without needing to enable asymmetric routing by disabling state checks for traffic
received on specific interfaces. Disabling state checks makes a FortiGate less secure and should only be done with
caution for troubleshooting purposes.
To remove Reverse Path Forwarding checks from the state evaluation process using the CLI:
Asymmetric routing
The firewall tries to ensure symmetry in its traffic by using the same source-destination combination in the original and
reverse path. Asymmetric routing occurs when traffic in the returning direction takes a different path than the original.
There may be various scenarios in which this happens. For example, traffic in the original direction hits the firewall on
port1, and is routed to port2. However, returning traffic is received on port3 instead. In this scenario, asymmetric
routing occurs and the returning traffic is blocked.
If for some specific reason it is required that a FortiGate unit should permit asymmetric routing, you can configure it by
using CLI commands per VDOM.
# config vdom
edit <vdom_name>
config system settings
set asymroute enable
end
next
end
Routing changes
When routing changes occur, routing look-up may occur on an existing session depending on certain configurations.
When a routing change occurs, FortiGate flushes all routing information from the session table and performs new routing
look-up for all new packets on arrival by default. You can modify the default behavior using the following commands:
# config system interface
edit <interface>
set preserve-session-route enable
next
end
By enabling preserve-session-route, the FortiGate marks existing session routing information as persistent.
Therefore, routing look-up only occurs on new sessions.
When SNAT is enabled, the default behavior is opposite to that of when SNAT is not enabled. After a routing change
occurs, sessions with SNAT keep using the same outbound interface as long as the old route is still active. This may be
the case if the priority of the static route was changed. You can modify this default behavior using the following
commands:
# config system global
set snat-route-change enable
end
By enabling snat-route-change, sessions with SNAT will require new route look-up when a routing change occurs.
This will apply a new SNAT to the session.
Policy routes
Policy routing allows you to specify an interface to route traffic. This is useful when you need to route certain types of
network traffic differently than you would if you were using the routing table. You can use the incoming traffic's protocol,
source or destination address, source interface, or port number to determine where to send the traffic.
When a packet arrives, the FortiGate starts at the top of the policy route list and attempts to match the packet with a
policy. For a match to be found, the policy must contain enough information to route the packet. At a minimum, this
requires the outgoing interface to forward the traffic, and the gateway to route the traffic to. If one or both of these are not
specified in the policy route, then the FortiGate searches the routing table to find the best active route that corresponds
to the policy route. If no routes are found in the routing table, then the policy route does not match the packet. The
FortiGate continues down the policy route list until it reaches the end. If no matches are found, then the FortiGate does a
route lookup using the routing table.
In this example, a policy route is configured to send all FTP traffic received at port1 out through port4 and to a next hop
router at 172.20.120.23. To route FTP traffic, the protocol is set to TCP (6) and the destination ports are set to 21 (the
FTP port).
Protocol TCP
Destination ports 21 - 21
4. Click OK.
A routing policy is added to the bottom of the table when it is created. Routing policies can be moved to a different
location in the table to change the order of preference. In this example, routing policy 3 will be moved before routing
policy 2.
If a policy route is configured to match return traffic, the policy route will not be checked.
For example: traffic from the client to the servers enters the FortiGate on either port1 or port2, and a policy route is
defined to match traffic that is sent from the servers' subnet to port2. The return traffic will not be checked against the
policy route.
If auxiliary session is enabled, the traffic will egress from an interface based on the best route. If auxiliary session is
disable, traffic will egress on the same interface where the incoming traffic arrived .
For more information, see Controlling return path with auxiliary session on page 811.
Equal cost multi-path (ECMP) is a mechanism that allows a FortiGate to load-balance routed traffic over multiple
gateways. Just like routes in a routing table, ECMP is considered after policy routing, so any matching policy routes will
take precedence over ECMP.
ECMP pre-requisites are as follows:
l Routes must have the same destination and costs. In the case of static routes, costs include distance and priority
l Routes are sourced from the same routing protocol. Supported protocols include static routing, OSPF, and BGP
ECMP and SD-WAN implicit rule are essentially similar in the sense that an SD-WAN implicit rule is processed after SD-
WAN service rules are processed. See Implicit rule on page 618 to learn more.
The following table summarizes the different load-balancing algorithms supported by each:
(GUI) (CLI)
source-ip-based Source IP source-ip-based Traffic is divided equally between the
interfaces. Sessions that start at the same
source IP address use the same path.
This is the default selection.
weight-based Sessions weight-based The workload is distributed based on the
number of sessions that are connected
through the interface.
The weight that you assign to each interface
is used to calculate the percentage of the
total sessions allowed to connect through an
interface, and the sessions are distributed to
the interfaces accordingly.
usage-based Spillover usage-based The interface is used until the traffic
bandwidth exceeds the ingress and egress
thresholds that you set for that interface.
Additional traffic is then sent through the next
interface member.
source-dest-ip- Source-Destination source-dest-ip- Traffic is divided equally between the
based IP based interfaces. Sessions that start at the same
source IP address and go to the same
destination IP address use the same path.
l At the VDOM-level:
config system settings
set v4-ecmp-mode {source-ip-based* | weight-based | usage-based | source-dest-ip-
based}
end
l If SD-WAN is enabled, the above option is not available and ECMP is configured under the SD-WAN settings:
config system sdwan
set sdwan enable
set load-balance-mode {source-ip-based* | weight-based | usage-based | source-dest-ip-
based | measured-volume-based}
end
For ECMP in IPv6, the mode must also be configured under SD-WAN.
# diagnose sys vd list
system fib version=63
list virtual firewall info:
name=root/root index=0 enabled fib_ver=40 use=168 rt_num=46 asym_rt=0 sip_helper=0, sip_nat_
trace=1, mc_fwd=0, mc_ttl_nc=0, tpmc_sk_pl=0
Result:
Both routes are added to the routing table and load-balanced based on the source IP.
Result:
Both routes are added to the routing table, but traffic is routed to port2 which has a lower priority value with a default of
0.
Result:
Both routes are added to the routing table, but 80% of the sessions to 10.10.30.0/24 are routed to vpn2HQ1, and
20% are routed to vpn2HQ2.
Result:
The network 192.168.80.0/24 is advertised by two BGP neighbors. Both routes are added to the routing table, and
traffic is load-balanced based on Source IP.
For multiple BGP paths to be added to the routing table, you must enable ebgp-multipath for eBGP or ibgp-
multipath for iBGP. These settings are disabled by default.
Dual internet connections, also referred to as dual WAN or redundant internet connections, refers to using two FortiGate
interfaces to connect to the Internet. This is generally accomplished with SD-WAN, but this legacy solution provides the
means to configure dual WAN without using SD-WAN. You can use dual internet connections in several ways:
l Link redundancy: If one interface goes down, the second interface automatically becomes the main connection.
l Load sharing: This ensures better throughput.
l Use a combination of link redundancy and load sharing.
Link redundancy ensures that if your Internet access is no longer available through a certain port, the FortiGate uses an
alternate port to connect to the Internet.
In this scenario, two interfaces, WAN1 and WAN2, are connected to the Internet using two different ISPs. WAN1 is the
primary connection. In the event of a failure of WAN1, WAN2 automatically becomes the connection to the Internet. For
this configuration to function correctly, you must configure the following settings:
l Link health monitor on page 515: To determine when the primary interface (WAN1) is down and when the
connection returns.
l Routing on page 516: Configure a default route for each interface.
l Security policies on page 517: Configure security policies to allow traffic through each interface to the internal
network.
Adding a link health monitor is required for routing failover traffic. A link health monitor confirms the device interface
connectivity by probing a gateway or server at regular intervals to ensure it is online and working. When the server is not
accessible, that interface is marked as down.
Set the interval (how often to send a ping) and failtime (how many lost pings are considered a failure). A smaller
interval value and smaller number of lost pings results in faster detection, but creates more traffic on your network.
The link health monitor supports both IPv4 and IPv6, and various other protocols including ping, tcp-echo, udp-echo,
http, and twamp.
Option Description
set update-cascade-interface {enable | This option is used in conjunction with fail-detect and fail-
disable} alert options in interface settings to cascade the link
failure down to another interface. See the Bring other
interfaces down when link monitor fails KB article for
details.
set update-static-route {enable | When the link fails, all static routes associated with the
disable} interface will be removed.
Routing
You must configure a default route for each interface and indicate your preferred route as follows:
l Specify different distances for the two routes. The lower of the two distance values is declared active and placed in
the routing table
OR
l Specify the same distance for the two routes, but give a higher priority to the route you prefer by defining a lower
value. Both routes will be added to the routing table, but the route with a higher priority will be chosen as the best
route
In the following example, we will use the first method to configure different distances for the two routes. You might not be
able to connect to the backup WAN interface because the FortiGate does not route traffic out of the backup interface.
The FortiGate performs a reverse path look-up to prevent spoofed traffic. If an entry cannot be found in the routing table
that sends the return traffic out through the same interface, the incoming traffic is dropped.
3. Click OK.
4. Repeat the above steps to set Interface to wan2 and Administrative Distance to 20.
Security policies
When you create security policies, you need to configure duplicate policies to ensure that after traffic fails over WAN1,
regular traffic is allowed to pass through WAN2, as it did with WAN1. This ensures that failover occurs with minimal effect
to users.
Load sharing may be accomplished in a few of the following ways of the many possible ways:
l By defining a preferred route with a lower distance, and specifying policy routes to route certain traffic to the
secondary interface.
l By defining routes with same distance values but different priorities, and specifying policy routes to route certain
traffic to the secondary interface.
l By defining routes with same distance values and priorities, and use equal-cost multi-path (ECMP) routing to
equally distribute traffic between the WAN interfaces.
In our example, we will use the first option for our configuration. In this scenario, because link redundancy is not required,
you do not have to configure a link monitor.
FortiGate will continue to route traffic to the primary WAN. This results in traffic
interruptions.
l If the primary WAN interface of a FortiGate is down due to physical link issues, the
FortiGate will remove routes to it and the secondary WAN routes will become active.
Traffic will failover to the secondary WAN.
Routing
Configure routing as you did in Scenario 1: Link redundancy and no load-sharing on page 515 above.
Policy routes
By configuring policy routes, you can redirect specific traffic to the secondary WAN interface. This works in this case
because policy routes are checked before static routes. Therefore, even though the static route for the secondary WAN
is not in the routing table, traffic can still be routed using the policy route.
In this example, we will create a policy route to route traffic from one address group to the secondary WAN interface.
Incoming interface Define the source of the traffic. For example, internal.
Source Address If we prefer to route traffic only from a group of addresses, define an address or
address group, and add here.
Destination Address Because we want to route all traffic from the address group here, we do not specify a
destination address.
Outgoing interface Select the secondary WAN as the outbound interface. For example, wan2.
Gateway address Input the gateway address for your secondary WAN.
Because its default route has a higher distance value and is not added to the routing
table, the gateway address must be added here.
3. Click OK.
Security policies
Your security policies should allow all traffic from internal to WAN1. Because link redundancy is not needed, you do
not need to duplicate all WAN1 policies to WAN2. You will only need to define policies used in your policy route.
In this scenario, both the links are available to distribute Internet traffic with the primary WAN being preferred more.
Should one of the interfaces fail, the FortiGate will continue to send traffic over the other active interface. The
configuration is a combination of both the link redundancy and the load-sharing scenarios. The main difference is that
the configured routes have equal distance values, with the route with a higher priority being preferred more. This ensures
both routes are active in the routing table, but the route with a higher priority will be the best route.
Link monitor must be configured for both the primary and the secondary WAN interfaces. This ensures that if the primary
or the secondary WAN fails, the corresponding route is removed from the routing table and traffic re-routed to the other
WAN interface.
For configuration details, see sample configurations in Scenario 1: Link redundancy and no load-sharing on page 515.
Routing
Both WAN interfaces must have default routes with the same distance. However, preference is given to the primary
WAN by giving it a higher priority.
Policy routes
The policy routes configuration is very similar to that of the policy routes in Scenario 2: Load-sharing and no link
redundancy on page 517, except that the gateway address should not be specified. When a policy route is matched and
the gateway address is not specified, the FortiGate looks at the routing table to obtain the gateway. In case the
secondary WAN fails, traffic may hit the policy route. Because there is no gateway specified and the route to the
secondary WAN is removed by the link monitor, the policy route will by bypassed and traffic will continue through the
primary WAN. This ensures that the policy route is not active when the link is down.
Security policies
When you create security policies, you need to configure duplicate policies to ensure that after traffic fails over WAN1,
regular traffic is allowed to pass through WAN2, as it was with WAN1. This ensures that failover occurs with minimal
effect to users.
RIP
The following topics include information about Routing Information Protocol (RIP):
OSPF
The following topics include information about Open Shortest Path First (OSPF):
BGP
The following topics include information about Border Gateway Protocol (BGP):
Multicast
Multicasting (also called IP multicasting) consists of using a single multicast source to send data to many receivers.
Multicasting can be used to send data to many receivers simultaneously while conserving bandwidth and reducing
network traffic. Multicasting can be used for one-way delivery of media streams to multiple receivers and for one-way
data transmission for news feeds, financial information, and so on. Many dynamic routing protocols such as RIPv2,
OSPF, and EIGRP use multicasting to share hello packets and routing information.
A FortiGate can operate as a Protocol Independent Multicast (PIM) version 2 router. FortiGates support PIM sparse
mode (RFC 4601) and PIM dense mode (RFC 3973), and can service multicast servers or receivers on the network
segment to which a FortiGate interface is connected. Multicast routing is not supported in transparent mode.
To support PIM communications, the sending and receiving applications, and all connecting PIM routers in between,
must be enabled with PIM version 2. PIM can use static routes, RIP, OSPF, or BGP to forward multicast packets to their
destinations. To enable source-to-destination packet delivery, sparse mode or dense mode must be enabled on the PIM
router interfaces. Sparse mode routers cannot send multicast messages to dense mode routers. If the FortiGate is
located between a source and a PIM router, between two PIM routers, or is connected directly to a receiver, you must
manually create a multicast policy to pass encapsulated (multicast) packets or decapsulated data (IP traffic) between the
source and destination.
PIM domains
A PIM domain is a logical area comprising a number of contiguous networks. The domain contains at least one bootstrap
router (BSR), and if sparse mode is enabled, a number of rendezvous points (RPs) and designated routers (DRs). When
PIM is enabled, the FortiGate can perform any of these functions at any time as configured.
A PIM domain can be configured in the GUI by going to Network > Multicast, or in the CLI using config router
multicast. Note that PIM version 2 must be enabled on all participating routers between the source and receivers. Use
config router multicast to set the global operating parameters.
When PIM is enabled, the FortiGate allocates memory to manage mapping information. The FortiGate communicates
with neighboring PIM routers to acquire mapping information and, if required, processes the multicast traffic associated
with specific multicast groups.
Instead of sending multiple copies of generated IP traffic to more than one specific IP destination address, PIM-enabled
routers encapsulate the data and use a Class D multicast group address (224.0.0.0 to 239.255.255.255) to forward
multicast packets to multiple destinations. A single stream of data can be sent because one destination address is used.
Client applications receive multicast data by requesting that the traffic destined for a certain multicast group address be
delivered to them.
There is sometimes confusion between the terms forwarding and routing. These two functions should not take place at
the same time. Multicast forwarding should be enabled when the FortiGate is in NAT mode and you want to forward
multicast packets between multicast routers and receivers. However, this function should not be enabled when the
FortiGate itself is operating as a multicast router, or has an applicable routing protocol that uses multicast.
Multicast forwarding is not supported on enhanced MAC VLAN interfaces. To use multicast with enhanced MAC VLAN
interfaces, use PIM (Multicast routing and PIM support on page 521).
There are two steps to configure multicast forwarding:
1. Enable multicast forwarding
2. Configure multicast policies
Multicast forwarding is enabled by default. If a FortiGate is operating in transparent mode, adding a multicast policy
enables multicast forwarding. In NAT mode you must use the multicast-forward setting to enable or disable
multicast forwarding.
When multicast-forward is enabled, the FortiGate forwards any multicast IP packets in which the TTL is 2 or higher
to all interfaces and VLAN interfaces, except the receiving interface. The TTL in the IP header will be reduced by 1. Even
though the multicast packets are forwarded to all interfaces, you must add multicast policies to allow multicast packets
through the FortiGate.
You can use the multicast-ttl-notchange option so that the FortiGate does not increase the TTL value for
forwarded multicast packets. Use this option only if packets are expiring before reaching the multicast router.
Disable multicast traffic from passing through the FortiGate without a policy check in
transparent mode
In transparent mode, the FortiGate does not forward frames with multicast destination addresses. The FortiGate should
not interfere with the multicast traffic used by routing protocols, streaming media, or other multicast communication. To
avoid any issues during transmission, you can disable multicast-skip-policy and configure multicast security
policies.
To disable multicast traffic from passing through the FortiGate without a policy check in transparent
mode:
end
Multicast packets require multicast policies to allow packets to pass from one interface to another. Similar to firewall
policies, in a multicast policy you specify the source and destination interfaces, and the allowed address ranges for the
source and destination addresses of the packets. You can also use multicast policies to configure source NAT and
destination NAT for multicast packets.
Keep the following in mind when configuring multicast policies:
l The matched forwarded (outgoing) IP multicast source IP address is changed to the configured IP address.
l The snat setting is optional. Use it when SNAT is needed.
In this basic policy, multicast packets received on an interface are flooded unconditionally to all interfaces on the
forwarding domain, except the incoming interface.
config firewall multicast-policy
edit 1
set srcintf "any"
set dstintf "any"
set srcaddr "all"
set dstaddr "all"
next
end
The destination address (dstaddr) is a multicast address object. The all option corresponds to all multicast addresses
in the range 224.0.0.0-239.255.255.255.
This multicast policy only applies to the source port wan1 and the destination port internal.
config firewall multicast-policy
edit 1
set srcintf "wan1"
set dstintf "internal"
set srcaddr "all"
set dstaddr "all"
next
end
In this policy, packets are allowed to flow from wan1 to internal, and sourced by the address 172.20.120.129, which is
represented by the example_addr-1 address object.
config firewall multicast-policy
edit 1
set srcintf "wan1"
set dstintf "internal"
set srcaddr "example_addr-1"
set dstaddr "all"
next
end
This policy accepts multicast packets that are sent from a PC with IP address 192.168.5.18 to destination address range
239.168.4.0-255. The policy allows the multicast packets to enter the internal interface and then exit the external
interface. When the packets leave the external interface, their source address is translated to 192.168.18.10.
config firewall address
edit "192.168.5.18"
set subnet 192.168.5.18 255.255.255.255
next
end
config firewall multicast-address
edit "239.168.4.0"
set start-ip 239.168.4.0
set end-ip 239.168.4.255
next
end
config firewall multicast-policy
edit 1
set srcintf "internal"
set dstintf "external"
set srcaddr "192.168.5.18"
set dstaddr "239.168.4.0"
set snat enable
set snat-ip 192.168.18.10
next
end
To configure multicast policies in the GUI, enable Multicast Policy in System > Feature
Visibility.
FortiExtender
Adding a FortiExtender
To add a FortiExtender to the FortiGate, create a virtual FortiExtender interface, then add a FortiExtender and assign the
interface to the modem. Like other interface types, the FortiExtender interface can be used in static routes, SD-WAN
(see Manage dual FortiExtender devices), policies, and other functions.
4. Click OK.
3. Click OK.
4. In the extenders list, right-click on the FortiExtender and select Diagnostics and Tools to review the modem and SIM
status, and other details about the FortiExtender.
The data plan profile allows users to configure connectivity settings based on modem, carrier, slot, SIM ID, or cost. Users
can also specify billing details related to the data plan, as well as smart switch thresholds to define when to switch over to
a different SIM.
A FortiExtender has multiple SIM card slots. Certain models also have multiple modems. Essentially, each modem can
make one connection with one of the two SIMs associated with the modem. The data plan profile allows users to create
general configurations that work across multiple SIMs, or specific profiles that work on a specific SIM. First, the data plan
matches the criteria based on the modem ID and type.
Syntax
config extender-controller dataplan
edit <name>
set modem-id {modem1 | modem2 | all}
set type {carrier | slot | iccid | generic}
next
end
Variable Description
set modem-id (Available on in the Select the match criterion based on the modem:
GUI) l modem1: Use modem 1.
Variable Description
set type (Type in the GUI) Select the match criterion based on the type:
carrier: Assign by SIM carrier.
slot: Assign to SIM slot 1 or 2.
iccid: Assign to a specific SIM by ICCID.
generic: Compatible with any SIM (default). Assigned if no other data plan
matches the chosen SIM.
When a modem connects to the network through a SIM, it will read the SIM information and try to match a data plan
based on the modem ID and type. It then uses the data plan connectivity settings to connect (authentication, PDN type,
preferred subnet, APN, private network). The billing details (such as the monthly data limit) and smart switch threshold
settings define how the SIMs will be switched.
Multiple data plans can be configured:
Once the FortiExtender is controlled by the FortiGate, the data plan is sent to the FortiExtender. The format is identical
between devices.
7. Click OK.
Direct IP is a public IP address that is assigned to a computing device, which allows the device to directly access the
internet.
When an LTE modem is enabled in FortiOS, a DHCP interface is created. As a result, the FortiGate can acquire direct IP
(which includes IP, DNS, and gateway) from the LTE network carrier.
Since some LTE modems require users to input the access point name (APN) for the LTE network, the LTE modem
configuration allows you to set the APN.
Shortly after the LTE modem joins its carrier network, wwan is enabled and granted direct IP:
# config system interface
(interface) # edit wwan
(wwan) # get
name : wwan
....
ip : 100.112.75.43 255.255.255.248
....
status : up
....
defaultgw : enable
DHCP Gateway : 100.112.75.41
Lease Expires : Thu Feb 21 19:33:27 2019
dns-server-override : enable
Acquired DNS1 : 184.151.118.254
Acquired DNS2 : 70.28.245.227
....
PCs can reach the internet via the following firewall policy:
config firewall policy
....
edit 5
set name "LTE"
set srcintf "port9"
set dstintf "wwan"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set fsso disable
set nat enable
next
end
When an LTE modem is enabled, you can view the LTE interface in the GUI and check the acquired IP, DNS, and
gateway.
5. Click OK.
Limitations
l Most LTE modems have a preset APN in their SIM card. Therefore, the APN does not need to be set in the FortiOS
configuration. In cases where the internet cannot be accessed, consult with your carrier and set the APN in the LTE
modem configuration (for example, inet.bell.ca):
config system lte-modem
set status enable
set apn "inet.bell.ca"
end
l Some models, such as the FortiGate 30E-3G4G, have built-in LTE modems. In this scenario, the LTE modem is
enabled by default. The firewall policy via the LTE interface is also created by default. Once you plug in a SIM card,
your network devices can connect to the internet.
LLDP reception
Natively, device detection can scan LLDP as a source for device identification. However, the FortiGate does not read or
store the full information. Enabling LLDP reception allows the FortiGate to receive and store LLDP messages, learn
about active neighbors, and makes the LLDP information available via the CLI, REST API, and SNMP.
You will need to enable device-identification at the interface level, and then lldp-reception can be enabled
on three levels: globally, per VDOM, or per interface.
Note that the port index in the output corresponds to the port index from the following command:
# diagnose netlink interface list port2 port3 | grep index
if=port2 family=00 type=1 index=4 mtu=1500 link=0 master=0
if=port3 family=00 type=1 index=5 mtu=1500 link=0 master=0
{
"http_method":"GET",
"results":[
{
"mac":"90:9c:9c:c9:c9:90",
"chassis_id":"90:9C:9C:C9:C9:90",
"port":19,
"port_id":"port12",
"port_desc":"port12",
"system_name":"S124DN3W00000000",
"system_desc":"FortiSwitch-124D v3.6.6,build0416,180515 (GA)",
"ttl":120,
"addresses":[
{
"type":"ipv4",
"address":"192.168.1.99"
}
]
}
],
"vdom":"root",
"path":"network",
"name":"lldp",
"action":"neighbors",
"status":"success",
"serial":"FG201E4Q00000000",
"version":"v6.2.0",
"build":866
}
{
"http_method":"GET",
"results":[
{
"name":"port1",
"rx":320,
"neighbors":1
}
],
"vdom":"root",
"path":"network",
"name":"lldp",
"action":"ports",
"mkey":"port1",
"status":"success",
"serial":"FG201E4Q00000000",
"version":"v6.2.0",
"build":866
}
Virtual Routing and Forwarding (VRF) is used to divide the FortiGate's routing functionality (layer 3), including interfaces,
routes, and forwarding tables, into separate units. Packets are only forwarded between interfaces that have the same
VRF.
VDOMs divide the FortiGate into two or more complete and independent virtual units that include all FortiGate functions.
VDOMs can be used for routing segmentation, but that should not be the only reason to implement them when a less
complex solution (VRFs) can be used. VDOMs also support administration boundaries, but VRFs do not.
Up to 32 VRFs can be configured in each VDOM, but only ten VDOMs can be configured by default on a FortiGate (more
VDOMs can be configured on larger devices with additional licenses).
l Implementing VRF on page 534
l VRF routing support on page 536
l Route leaking between VRFs on page 555
l Route leaking between multiple VRFs on page 557
l IBGP and EBGP support in VRF on page 552
Implementing VRF
VRFs are always enabled and, by default, all routing is done in VRF 0. To use additional VRFs, assign a VRF ID to an
interface. All routes relating to that interface are isolated to that VRF specific routing table. Interfaces in one VRF cannot
reach interfaces in a different VRF.
If some traffic does have to pass between VRFs, route leaking can be used. See Route leaking between VRFs on page
555.
4. Click OK.
5. To add the VRF column in the interface table, click the gear icon, select VRF, and click Apply.
VRF supports static routing, OSPF, and BGP. Other routing protocols require using VDOMs.
BGP
In this example, BGP is used to update the VRF that it is neighbors with.
The hub is configured with two neighbors connected to two interfaces. The branches are configured to match the hub,
with branch networks configured to redistribute into BGP.
Policies must be created on the hub and branches to allow traffic between them.
end
config redistribute connected
set status enable
end
end
To verify the BGP neighbors and check the routing table on the hub:
set vrf 20
next
end
OSPF
OSPF routes in VRFs work the same as BGP: the interface that OSPF is using is added to the VRF.
1. Configure OSPF:
config router ospf
set router-id 1.1.1.1
config area
edit 0.0.0.0
next
end
config ospf-interface
edit Branch101
set interface “port2”
set dead-interval 40
set hello-interval 10
next
edit Branch102
set dead-interval 40
set hello-interval 10
next
end
config network
edit 0
set prefix 10.101.101.0 255.255.255.0
next
edit 0
set prefix 10.102.102.0 255.255.255.0
next
edit 0
set prefix 192.168.1.0 255.255.255.0
next
end
end
set hello-interval 10
next
end
config network
edit 0
set prefix 10.101.101.0 255.255.255.0
next
edit 0
set prefix 192.168.101.0 255.255.255.0
next
end
end
Route leaking allows you to configure communication between VRFs. If route leaking is not configured, then the VRFs
are isolated. This example shows route leaking with BGP using virtual inter-VDOM links.
In this example, a hub FortiGate forms BGP neighbors with two branches. It learns the networks 192.168.101.0/24 and
192.168.102.0/24 from the neighbors and separates them into VRF 10 and VRF 20.
To leak the learned routes to each other, an inter-VDOM link (IVL) is formed. An IVL normally bridges two VDOMs, but in
this case the links reside on the same VDOM and are used to bridge the two VRFs. NPU links could also be used on
models that support it to deliver better performance.
VRF 10 has a leaked route to 192.168.102.0/24 on IVL link-10-20-0, and VRF 20 has a leaked route to 192.168.101.0/24
on IVL link-10-20-1,
4. Configure the VRF leak in BGP, specifying a source VRF, destination VRF, an the route map to use:
config router bgp
config vrf-leak
edit "10"
config target
edit "20"
set route-map "Leak_from_VRF10_to_VRF20"
set interface "link-10-20-0"
next
end
next
edit "20"
config target
edit "10"
set route-map "Leak_from_VRF20_to_VRF10"
set interface "link-10-20-1"
next
end
next
end
end
In this example, routing leaking between three VRFs in a star topology is configured. This allows the solution to be
scaled to more VRFs without building full mesh, one-to-one connections between each pair of VRFs. VLAN
subinterfaces are created on VDOM links to connect each VRF to the central VRF, allowing routes to be leaked from a
VRF to the central VRF, and then to the other VRFs. Static routes are used for route leaking in this example.
For instructions on creating route leaking between two VRFs, see Route leaking between VRFs on page 555.
Physical topology:
Logical topology:
In this example, a specific route is leaked from each of the VRFs to each of the other VRFs. VLAN subinterfaces are
created based on VDOM links to connect each VRF to the core VRF router.
Multi VDOM mode is enabled so that NP VDOM links can be used. The setup could be configured without enabling multi
VDOM mode by manually creating non-NP VDOM links, but this is not recommended as the links are not offloaded to the
NPU.
After VDOMs are enabled, all of the configuration is done in the root VDOM.
If multi VDOM mode is not used, the VDOM links can be manually created:
4. Configure a zone to allow intrazone traffic between VLANs in the central VRF:
config system zone
edit "Core-VRF-Router"
set intrazone allow
set interface "vlink1_Vlan_10" "vlink1_Vlan_11" "vlink1_Vlan_12"
next
end
6. Configure VRF10, VRF11, and VRF12 on the Internal and WAN VLAN sub-interfaces:
7. Configure static routing and route leaking between each VRF and Core-VRF-Router:
config router static
edit 1
set dst 172.16.10.0 255.255.255.0
set gateway 10.1.1.1
set device "vlink1_Vlan_10"
set comment "VRF31_Core_Router"
next
edit 2
set dst 172.16.11.0 255.255.255.0
set gateway 11.1.1.1
set device "vlink1_Vlan_11"
set comment "VRF31_Core_Router"
next
edit 3
set dst 172.16.12.0 255.255.255.0
set gateway 12.1.1.1
set device "vlink1_Vlan_12"
set comment "VRF31_Core_Router"
next
edit 4
set dst 172.16.11.0 255.255.255.0
set gateway 10.1.1.2
set device "vlink0_Vlan_10"
set comment "VRF10_Route_Leaking"
next
edit 5
set dst 172.16.12.0 255.255.255.0
set gateway 10.1.1.2
set device "vlink0_Vlan_10"
set comment "VRF10_Route_Leaking"
next
edit 6
set dst 172.16.10.0 255.255.255.0
set gateway 11.1.1.2
set device "vlink0_Vlan_11"
set comment "VRF11_Route_Leaking"
next
edit 7
set dst 172.16.12.0 255.255.255.0
set gateway 11.1.1.2
set device "vlink0_Vlan_11"
set comment "VRF11_Route_Leaking"
next
edit 8
set dst 172.16.10.0 255.255.255.0
set gateway 12.1.1.2
set device "vlink0_Vlan_12"
In the GUI, go to Network > Static Routes to view the static routes.
8. Configure firewall policies for VRF10, VRF11, and VRF12
config firewall policy
edit 6
set name "VRF10_to_Internet_Policy"
set srcintf "Internal_VRF10"
set dstintf "wan1_VRF10"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
set nat enable
next
edit 7
set name "VRF10_to_VRF_Leaking_Route"
set srcintf "Internal_VRF10"
set dstintf "vlink0_Vlan_10"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 8
set name "VRF_Leaking_Route_to_VRF10"
set srcintf "vlink0_Vlan_10"
set dstintf "Internal_VRF10"
In the GUI, go to Policy & Objects > Firewall Policy to view the policies.
Support is included for internal and external border gateway protocols (IBGP and EBGP) in virtual routing and forwarding
(VRF).
FortiGate can establish neighbor connections with other FortiGates or routers, and the learned routes are put into
different VRF tables according to the neighbor's settings.
This example uses the following topology:
l BGP routes learned from the Router1 neighbor are put into vrf10.
l BGP routes learned from the Router2 neighbor are put into vrf20.
Results
After VRF is set for BGP, BGP routes are added to the VRF tables along with OSPF and connected routes:
# get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
This feature is also supported in the BGP neighbor groups. For example:
config router bgp
config neighbor-group
edit "FGT"
set update-source "port1"
next
end
config neighbor-range
edit 1
set prefix 172.16.201.0 255.255.255.0
set neighbor-group "FGT"
next
end
end
Route leaking allows you to configure communication between VRFs. If route leaking is not configured, then the VRFs
are isolated. This example shows route leaking with BGP using virtual inter-VDOM links.
In this example, a hub FortiGate forms BGP neighbors with two branches. It learns the networks 192.168.101.0/24 and
192.168.102.0/24 from the neighbors and separates them into VRF 10 and VRF 20.
To leak the learned routes to each other, an inter-VDOM link (IVL) is formed. An IVL normally bridges two VDOMs, but in
this case the links reside on the same VDOM and are used to bridge the two VRFs. NPU links could also be used on
models that support it to deliver better performance.
VRF 10 has a leaked route to 192.168.102.0/24 on IVL link-10-20-0, and VRF 20 has a leaked route to 192.168.101.0/24
on IVL link-10-20-1,
These object define the subnet and mask that are leaked.
config router prefix-list
edit VRF10_Route
config rule
edit 1
set prefix 192.168.101.0 255.255.255.0
next
end
next
edit VRF20_Route
config rule
edit 1
set prefix 192.168.102.0 255.255.255.0
next
end
next
end
4. Configure the VRF leak in BGP, specifying a source VRF, destination VRF, an the route map to use:
config router bgp
config vrf-leak
edit "10"
config target
edit "20"
set route-map "Leak_from_VRF10_to_VRF20"
set interface "link-10-20-0"
next
end
next
edit "20"
config target
edit "10"
set route-map "Leak_from_VRF20_to_VRF10"
set interface "link-10-20-1"
next
end
next
end
end
In this example, routing leaking between three VRFs in a star topology is configured. This allows the solution to be
scaled to more VRFs without building full mesh, one-to-one connections between each pair of VRFs. VLAN
subinterfaces are created on VDOM links to connect each VRF to the central VRF, allowing routes to be leaked from a
VRF to the central VRF, and then to the other VRFs. Static routes are used for route leaking in this example.
For instructions on creating route leaking between two VRFs, see Route leaking between VRFs on page 555.
Physical topology:
Logical topology:
In this example, a specific route is leaked from each of the VRFs to each of the other VRFs. VLAN subinterfaces are
created based on VDOM links to connect each VRF to the core VRF router.
Multi VDOM mode is enabled so that NP VDOM links can be used. The setup could be configured without enabling multi
VDOM mode by manually creating non-NP VDOM links, but this is not recommended as the links are not offloaded to the
NPU.
After VDOMs are enabled, all of the configuration is done in the root VDOM.
If multi VDOM mode is not used, the VDOM links can be manually created:
4. Configure a zone to allow intrazone traffic between VLANs in the central VRF:
config system zone
edit "Core-VRF-Router"
set intrazone allow
set interface "vlink1_Vlan_10" "vlink1_Vlan_11" "vlink1_Vlan_12"
next
end
6. Configure VRF10, VRF11, and VRF12 on the Internal and WAN VLAN sub-interfaces:
7. Configure static routing and route leaking between each VRF and Core-VRF-Router:
config router static
edit 1
set dst 172.16.10.0 255.255.255.0
set gateway 10.1.1.1
set device "vlink1_Vlan_10"
set comment "VRF31_Core_Router"
next
edit 2
set dst 172.16.11.0 255.255.255.0
set gateway 11.1.1.1
set device "vlink1_Vlan_11"
set comment "VRF31_Core_Router"
next
edit 3
set dst 172.16.12.0 255.255.255.0
set gateway 12.1.1.1
set device "vlink1_Vlan_12"
set comment "VRF31_Core_Router"
next
edit 4
set dst 172.16.11.0 255.255.255.0
set gateway 10.1.1.2
set device "vlink0_Vlan_10"
set comment "VRF10_Route_Leaking"
next
edit 5
set dst 172.16.12.0 255.255.255.0
set gateway 10.1.1.2
set device "vlink0_Vlan_10"
set comment "VRF10_Route_Leaking"
next
edit 6
set dst 172.16.10.0 255.255.255.0
set gateway 11.1.1.2
set device "vlink0_Vlan_11"
set comment "VRF11_Route_Leaking"
next
edit 7
set dst 172.16.12.0 255.255.255.0
set gateway 11.1.1.2
set device "vlink0_Vlan_11"
set comment "VRF11_Route_Leaking"
next
edit 8
set dst 172.16.10.0 255.255.255.0
set gateway 12.1.1.2
set device "vlink0_Vlan_12"
In the GUI, go to Network > Static Routes to view the static routes.
8. Configure firewall policies for VRF10, VRF11, and VRF12
config firewall policy
edit 6
set name "VRF10_to_Internet_Policy"
set srcintf "Internal_VRF10"
set dstintf "wan1_VRF10"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
set nat enable
next
edit 7
set name "VRF10_to_VRF_Leaking_Route"
set srcintf "Internal_VRF10"
set dstintf "vlink0_Vlan_10"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 8
set name "VRF_Leaking_Route_to_VRF10"
set srcintf "vlink0_Vlan_10"
set dstintf "Internal_VRF10"
In the GUI, go to Policy & Objects > Firewall Policy to view the policies.
NetFlow
NetFlow allows you to collect IP network traffic statistics for an interface, and then export those statistics for analysis.
NetFlow samplers, that sample every packet, are configured per interface. Full NetFlow is supported through the
information maintained in the firewall session.
To configure NetFlow:
config vdom
edit <vdom>
config system vdom-netflow
set vdom-netflow enable
set collector-ip <ip>
set collector-port <port>
set source-ip <ip>
end
next
end
If data are not seen on the NetFlow collector after it has been configured, use the following sniffer commands to verify if
the FortiGate and the collector are communicating:
l By collector port:
# diagnose sniffer packet 'port <collector-port>' 6 0 a
l By collector IP address:
# diagnose sniffer packet 'host <collector-ip>' 6 0 a
NetFlow uses the sflow daemon. The current NetFlow configuration can be viewed using test level 3 or 4:
# diagnose test application sflowd 3
# diagnose test application sflowd 4
Netflow Cache Stats:
vdoms=1 Collectors=1 Cached_intf=2 Netflow_enabled_intf=1 Live_sessions=0 Session cache max
count:71950
NetFlow templates
Netflow uses templates to capture and categorize the data that it collects. FortiOS supports the following Netflow
templates:
256 - STAT_OPTIONS
Option Length 28
Padding 0000
Scope fields
Data fields
257 - APP_ID_OPTIONS
Option Length 16
Padding 0000
Scope fields
Data fields
258 - IPV4
Data fields
259 - IPV6
Data fields
260 - ICMP4
Data fields
16 IP_DST_ADDR IP_DST_ADDR(12) 4
261 - ICMP6
Data fields
262 - IPV4_NAT
Data fields
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
263 - IPV4_AF_NAT
Data fields
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
264 - IPV6_NAT
Data fields
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
265 - IPV6_AF_NAT
Data fields
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
266 - ICMPV4_NAT
Data fields
20 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
267 - ICMPV4_AF_NAT
Data fields
20 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
268 - ICMPV6_NAT
Data fields
20 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
269 - ICMPV6_AF_NAT
Data fields
20 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
SD-WAN is a software-defined approach to managing Wide-Area Networks (WAN). It allows you to offload internet-
bound traffic, meaning that private WAN services remain available for real-time and mission critical applications. This
added flexibility improves traffic flow and reduces pressure on the network.
SD-WAN platforms create hybrid networks that integrate broadband and other network services into the corporate WAN
while maintaining the performance and security of real-time and sensitive applications.
SD-WAN with Application Aware Routing can measure and monitor the performance of multiple services in a hybrid
network. It uses application routing to offer more granular control of where and when an application uses a specific
service, allowing better use of the overall network.
Some of the key benefits of SD-WAN include:
l Reduced cost with transport independence across MPLS, 3G/4G LTE, and others.
l Improve business application performance thanks to increased availability and agility.
l Optimized user experience and efficiency with SaaS and public cloud applications.
SD-WAN has 4 objects:
l SD-WAN zones
SD-WAN is divided into zones. SD-WAN member interfaces are assigned to zones, and zones are used in policies
as source and destination interfaces. You can define multiple zones to group SD-WAN interfaces together, allowing
logical groupings for overlay and underlay interfaces. See SD-WAN zones on page 593.
l SD-WAN members
Also called interfaces, SD-WAN members are the ports and interfaces that are used to run traffic. At least one
interface must be configured for SD-WAN to function; up to 255 member interfaces can be configured. See
Configuring the SD-WAN interface on page 583.
l Performance SLAs
Also called health-checks, performance SLAs are used to monitor member interface link quality, and to detect link
failures. They can be used to remove routes, and to reroute traffic when an SD-WAN member cannot detect the
server. They can also be used in SD-WAN rules to select the preferred member interface for forwarding traffic. See
Performance SLA on page 598.
l SD-WAN rules
Also called services, SD-WAN rules are used to control path selection. Specific traffic can be dynamically sent to the
best link, or use a specific route. There are five modes:
l auto: Assign interfaces a priority based on quality.
l manual: Assign interfaces a priority manually.
l priority: Assign interfaces a priority based on the link-cost-factor quality of the interface.
l load-balance: Distribute traffic among all available links based on the load balance algorithm.
This section provides an example of how to start using SD-WAN for load balancing and redundancy.
In this example, two ISP internet connections, wan1 (DHCP) and wan2 (static), use SD-WAN to balance traffic between
them at 50% each.
First, SD-WAN must be enabled and member interfaces must be selected and added to a zone. The selected FortiGate
interfaces can be of any type (physical, aggregate, VLAN, IPsec, and others), but must be removed from any other
configurations on the FortiGate.
In this step, two interfaces are configured and added to the default SD-WAN zone (virtual-wan-link) as SD-WAN member
interfaces. This example uses a mix of static and dynamic IP addresses; your deployment could also use only one or the
other.
Once the SD-WAN members are created and added to a zone, the zone can be used in firewall policies, and the whole
SD-WAN can be used in static routes.
1. Configure the wan1 and wan2 interfaces. See Interface settings on page 386 for details.
a. Set the wan1 interface Addressing mode to DHCP and Distance to 10.
By default, a DHCP interface has a distance of 5, and a static route has a distance of
10. It is important to account for this when configuring your SD-WAN for 50/50 load
balancing by setting the DHCP interface's distance to 10.
You must configure a default route for the SD-WAN. The default gateways for each SD-WAN member interface do not
need to be defined in the static routes table. FortiGate will decide what route or routes are preferred using Equal Cost
Multi-Path (ECMP) based on distance and priority.
SD-WAN rules define specific routing options to route traffic to an SD-WAN member.
If no routing rules are defined, the default Implicit rule is used. It can be configured to use one of five different load
balancing algorithms. See Implicit rule on page 618 for more details and examples.
This example shows four methods to equally balance traffic between the two WAN connections. Go to Network > SD-
WAN Rules and edit the sd-wan rule to select the method that is appropriate for your requirements.
l Source IP (CLI command: source-ip-based):
Select this option to balance traffic equally between the SD-WAN members according to a hash algorithm based on
the source IP addresses.
l Session (weight-based):
Select this option to balance traffic equally between the SD-WAN members by the session numbers ratio among its
members. Use weight 50 for each of the 2 members.
l Source-Destination IP (source-dest-ip-based):
Select this option to balance traffic equally between the SD-WAN members according to a hash algorithm based on
the source and destination IP addresses.
l Volume (measured-volume-based):
Select this option to balance traffic equally between the SD-WAN members according to the bandwidth ratio among
its members.
SD-WAN zones can be used in policies as source and destination interfaces. Individual SD-WAN members cannot be
used in policies.
You must configure a policy that allows traffic from your organization's internal network to the SD-WAN zone. Policies
configured with the SD-WAN zone apply to all SD-WAN interface members in that zone.
Source all
Destination all
Schedule always
Service ALL
Action ACCEPT
Firewall / Network Options Enable NAT and set IP Pool Configuration to Use Outgoing Interface Address.
Logging Options Enable Log Allowed Traffic and select All Sessions. This allows you to verify
results later.
Performance SLA link monitoring measures the health of links that are connected to SD-WAN member interfaces by
sending probing signals through each link to a server, and then measuring the link quality based on latency, jitter, and
packet loss. If a link is broken, the routes on that link are removed and traffic is routed through other links. When the link
is working again, the routes are re-enabled. This prevents traffic being sent to a broken link and lost.
In this example, the detection server IP address is 208.91.112.53. A performance SLA is created so that, if ping fails per
the metrics defined, the routes to that interface are removed and traffic is detoured to the other interface. The ping
protocol is used, but other protocols could also be selected as required.
Results
The following GUI pages show the function of the SD-WAN and can be used to confirm that it is setup and running
correctly:
l Interface usage on page 587
l Performance SLA on page 589
l Routing table on page 590
l Firewall policy on page 591
Interface usage
Bandwidth
Select Bandwidth to view the amount of downloaded and uploaded data for each interface.
Volume
Select Volume to see donut charts of the received and sent bytes on the interfaces.
Sessions
Select Sessions to see a donut chart of the number of active sessions on each interface.
Performance SLA
Go to Network > Performance SLA and select the SLA from the table (server in this example) to view the packet loss,
latency, and jitter on each SD-WAN member in the health check server.
Packet loss
Select Packet Loss to see the percentage of packets lost for each member.
Latency
Select Latency to see the current latency, in milliseconds, for each member.
Jitter
Routing table
Go to Dashboard > Network and expand the Static & Dynamic Routing widget to review all static and dynamic routes.
For more information about the widget, see Static & Dynamic Routing Monitor on page 72.
Firewall policy
Go to Policy & Objects > Firewall Policy to review the SD-WAN policy.
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
Results
SD-WAN zones
SD-WAN is divided into zones. SD-WAN member interfaces are assigned to zones, and zones are used in policies as
source and destination interfaces.
You can define multiple zones to group SD-WAN interfaces together, allowing logical groupings for overlay and underlay
interfaces. The zones are used in firewall policies to allow for more granular control. SD-WAN members cannot be used
directly in policies.
Static routes use the entire SD-WAN, not just individual zones or members.
In the CLI:
l config system sdwan has replaced config system virtual-wan-link.
l When configuring a static route, the sdwan variable has replaced the virtual-wan-
link variable.
When the Security Fabric is configured, SD-WAN zones are included in the Security Fabric topology views.
5. Click OK.
1. Go to Policy & Objects > Firewall Policy, Policy & Objects > Proxy Policy, or Policy & Objects > Security Policy.
2. Click Create New .
3. Configure the policy settings as needed, selecting an SD-WAN zone or zones for the incoming and/or outgoing
interface.
4. Click OK.
1. Go to Security Fabric > Physical Topology or Security Fabric > Logical Topology. The SD-WAN zones and their
members are shown.
Performance SLA
Performance SLA link health monitoring measures the health of links that are connected to SD-WAN member interfaces
by sending probing signals through each link to a server and measuring the link quality based on latency, jitter, and
packet loss. If a link fails all of the health checks, the routes on that link are removed from the SD-WAN link load
balancing group, and traffic is routed through other links. When the link is working again the routes are reestablished.
This prevents traffic being sent to a broken link and lost.
When an SD-WAN member has multiple health checks configured, all of the checks must fail for the routes on that link to
be removed from the SD-WAN link load balancing group.
Two health check servers can be configured to ensure that, if there is a connectivity issue, the interface is at fault and not
the server. A server can only be used in one health check.
The FortiGate uses the first server configured in the health check server list to perform the health check. If the first server
is unavailable, then the second server is used. The second server continues to be used until it becomes unavailable, and
then the FortiGate returns to the first server, if it is available. If both servers are unavailable, then the health check fails.
You can configure the protocol that is used for status checks, including: Ping, HTTP, DNS, TCP echo, UDP echo, two-
way active measurement protocol (TWAMP), TCP connect, and FTP. In the GUI, only Ping, HTTP, and DNS are
available.
You can view link quality measurements at Network > Performance SLA. The table shows the default health checks, the
health checks that you configured, and information about each health check. The values shown in the Packet Loss,
Latency, and Jitter columns are for the health check server that the FortiGate is currently using. The green up arrows
indicate that the server is responding, and does not indicate if the health checks are being met. See Results on page 587
for more information.
= 500).
l Failures before inactive: The number of failed status checks before the interface shows as inactive (1 - 3600,
default =5). This setting helps prevent flapping, where the system continuously transfers traffic back and forth
between links
l Restore link after: The number of successful status checks before the interface shows as active (1 - 3600,
default = 5). This setting helps prevent flapping, where the system continuously transfers traffic back and forth
between links
9. In the Actions when Inactive section, enable Update static route to disable static routes for inactive interfaces and
restore routes when interfaces recover.
There are six predefined performance SLA profiles for newly created VDOMs or factory reset FortiGate devices:
l AWS
l System DNS
l FortiGuard
l Gmail
l Google Search
l Office 365
You can view and configure the SLA profiles in Network > Performance SLA.
After configuring a health check, you will be able to view packet loss, latency, and jitter data for the SLA profiles. If a
value is colored red, it means that it failed to meet the SLA requirements.
config health-check
edit "Default_AWS"
set server "aws.amazon.com"
set protocol http
set interval 1000
set probe-timeout 1000
set recoverytime 10
config sla
edit 1
set latency-threshold 250
set jitter-threshold 50
set packetloss-threshold 5
next
end
next
edit "Default_DNS"
set system-dns enable
set interval 1000
set probe-timeout 1000
set recoverytime 10
config sla
edit 1
set latency-threshold 250
set jitter-threshold 50
set packetloss-threshold 5
next
end
next
edit "Default_FortiGuard"
set server "fortiguard.com"
set protocol http
set interval 1000
set probe-timeout 1000
set recoverytime 10
config sla
edit 1
set latency-threshold 250
set jitter-threshold 50
set packetloss-threshold 5
next
end
next
edit "Default_Gmail"
set server "gmail.com"
set interval 1000
set probe-timeout 1000
set recoverytime 10
config sla
edit 1
set latency-threshold 250
set jitter-threshold 50
set packetloss-threshold 2
next
end
next
edit "Default_Google Search"
set server "www.google.com"
set protocol http
set interval 1000
set probe-timeout 1000
set recoverytime 10
config sla
edit 1
set latency-threshold 250
set jitter-threshold 50
set packetloss-threshold 5
next
end
next
edit "Default_Office_365"
set server "www.office.com"
set protocol http
set interval 1000
set probe-timeout 1000
set recoverytime 10
config sla
edit 1
set latency-threshold 250
set jitter-threshold 50
set packetloss-threshold 5
next
end
next
end
tcp-echo Use TCP echo to test the link with the server.
udp-echo Use UDP echo to test the link with the server.
dns Use DNS query to test the link with the server.
The FortiGate sends a DNS query for an A Record and the response matches the expected IP
address.
tcp-connect Use a full TCP connection to test the link with the server.
The method to measure the quality of the TCP connection can be:
l half-open: FortiGate sends SYN and gets SYN-ACK. The latency is based on the
l port: The FTP server initiates and establishes the data connection.
To use DNS as a health check, and define the IP address that the response must match:
To use TCP Open (SYN/SYN-ACK) and TCP Close (FIN/FIN-ACK) to verify connections:
Performance SLA link monitoring measures the health of links that are connected to SD-WAN member interfaces by
sending probing signals through each link to a server and measuring the link quality based on latency, jitter, and packet
loss. If a link is broken, the routes on that link are removed, and traffic is routed through other links. When the link is
working again, the routes are reenabbled. This prevents traffic being sent to a broken link and lost.
In this example:
l Interfaces wan1 and wan2 connect to the internet through separate ISPs
l The detection server IP address is 208.91.114.182
A performance SLA is created so that, if one link fails, its routes are removed and traffic is detoured to the other link.
1. On the FortiGate, add wan1 and wan2 as SD-WAN members, then add a policy and static route. See SD-WAN
quick start on page 582 for details.
2. Go to Network > Performance SLA.
3. Click Create New. The Performance SLA page opens.
4. Enter a name for the SLA and select a protocol.
5. In the Server field, enter the detection server IP address (208.91.114.182 in this example).
SLA targets are a set of constraints that are used in SD-WAN rules to control the paths that traffic take.
The available constraints are:
l Latency threshold: Latency for SLA to make decision, in milliseconds (0 - 10000000, default = 5).
l Jitter threshold: Jitter for SLA to make decision, in milliseconds (0 - 10000000, default = 5).
l Packet loss threshold: Packet loss for SLA to make decision, in percentage (0 - 100, default = 0).
1. On the FortiGate, add wan1 and wan2 as SD-WAN members, then add a policy and static route. See SD-WAN
quick start on page 582 for details.
2. Go to Network > Performance SLA.
3. Create a new Performance SLA or edit an existing one. See Link monitoring example on page 606.
4. Enable SLA Targetsand configure the constraints. To add multiple SLA targets, use the CLI.
next
end
next
end
end
SD-WAN health check probe packets support Differentiated Services Code Point (DSCP) markers for accurate
evaluation of the link performance for high priority applications by upstream devices.
When the SD-WAN health check packet is sent out, the DSCP can be set with a CLI command.
Interface speedtest
An interface speedtest can be performed on WAN interfaces in the GUI. The results of the test can be added to the
interface's Estimated bandwidth. The estimated upstream and downstream bandwidths can be used in SD-WAN service
rules to determine the best link to use when either Maximize Bandwidth or Best Quality strategies are selected.
An SD-WAN Network Monitor license is required to use the speedtest. The License widget and the System > FortiGuard
page show license status.
The speedtest results are used to populate the Estimated bandwidth fields.
5. Click OK.
The FortiGate must be connected to FortiGuard, and able to reach either the AWS or Google
speedtest servers.
Link quality plays a significant role in link selection for SD-WAN. Investigate any prolonged issues with packet loss,
latency, or jitter to ensure that your network does not experience degraded performance or an outage.
You can monitor the link quality status of SD-WAN interface members at Network > Performance SLA.
The live charts show the packet loss, latency, or jitter for the selected health check. Hover the cursor over a line in the
chart to see the specific value for that interface at that specific time.
The table shows information about each health check, including the configured servers, link quality data, and thresholds.
The colored arrow indicates the status of the interface when the last status check was performed: green means that the
interface was active, and red means that the interface was inactive. Hover the cursor over the arrow for additional
information.
The features adds an SD-WAN daemon function to keep a short, 10 minute history of SLA that can be viewed in the CLI.
Performance SLA results related to interface selection, session failover, and other information, can be logged. These
logs can then be used for long-term monitoring of traffic issues at remote sites, and for reports and views in
FortiAnalyzer.
The time intervals that Performance SLA fail and pass logs are generated in can be configured.
The FortiGate generates Performance SLA logs at the specified pass log interval (sla-pass-log-period) when SLA
passes.
3: date=2019-02-28 time=11:53:26 logid="0100022925" type="event" subtype="system"
level="information" vd="root" eventtime=1551383604 logdesc="Link monitor SLA information"
name="ping" interface="R160" status="up" msg="Latency: 0.013, jitter: 0.001, packet loss:
0.000%, inbandwidth: 0Mbps, outbandwidth: 0Mbps, bibandwidth: 0Mbps, sla_map: 0x1"
7: date=2019-02-28 time=11:52:26 logid="0100022925" type="event" subtype="system"
level="information" vd="root" eventtime=1551383545 logdesc="Link monitor SLA information"
The FortiGate generates Performance SLA logs at the specified fail log interval (sla-fail-log-period) when SLA
fails.
6: date=2019-02-28 time=11:52:32 logid="0100022925" type="event" subtype="system"
level="notice" vd="root" eventtime=1551383552 logdesc="Link monitor SLA information"
name="ping" interface="R150" status="down" msg="Latency: 0.000, jitter: 0.000, packet loss:
100.000%, inbandwidth: 0Mbps, outbandwidth: 200Mbps, bibandwidth: 200Mbps, sla_map: 0x0"
8: date=2019-02-28 time=11:52:02 logid="0100022925" type="event" subtype="system"
level="notice" vd="root" eventtime=1551383522 logdesc="Link monitor SLA information"
name="ping" interface="R150" status="down" msg="Latency: 0.000, jitter: 0.000, packet loss:
100.000%, inbandwidth: 0Mbps, outbandwidth: 200Mbps, bibandwidth: 200Mbps, sla_map: 0x0"
SLA log information and interface SLA information can be monitored using the REST API. This feature is also be used by
FortiManager as part of its detailed SLA monitoring and drill-down features.
https://172.172.172.9/api/v2/monitor/virtual-wan/interface-log
{
"http_method":"GET",
"results":[
{
"interface":"port13",
"logs":[
{
"timestamp":1547087168,
"tx_bandwidth":3447,
"rx_bandwidth":3457,
"bi_bandwidth":6904,
"tx_bytes":748875,
"rx_bytes":708799,
"egress_queue":[
]
},
{
"timestamp":1547087178,
"tx_bandwidth":3364,
"rx_bandwidth":3400,
"bi_bandwidth":6764,
"tx_bytes":753789,
"rx_bytes":712835,
"egress_queue":[
]
},
....
....
https://172.172.172.9/api/v2/monitor/virtual-wan/sla-log
{
"http_method":"GET",
"results":[
{
"name":"ping",
"interface":"spoke11-p1",
"logs":[
{
"timestamp":1614813142,
"link":"up",
"latency":0.13763333857059479,
"jitter":0.02996666356921196,
"packetloss":0
},
"child_intfs":{
"spoke11-p1_0":[
{
"timestamp":1614813142,
"link":"up",
"latency":0.12413334846496582,
"jitter":0.028366668149828911,
"packetloss":0
},
{
"name":"ping",
"interface":"spoke12-p1",
"logs":[
{
"timestamp":1614813143,
"link":"up",
"latency":0.11373332887887955,
"jitter":0.023099998012185097,
"packetloss":0
},
"child_intfs":{
"spoke12-p1_0":[
{
"timestamp":1614813143,
"link":"up",
"latency":0.0930333212018013,
"jitter":0.011033335700631142,
"packetloss":0
},
....
....
https://172.172.172.9/api/v2/monitor/virtual-wan/health-check
{
"http_method":"GET",
"results":{
"ping":{
"spoke11-p1":{
"status":"up",
"latency":0.13406667113304138,
"jitter":0.023000005632638931,
"packet_loss":0,
"packet_sent":29722,
"packet_received":29718,
"sla_targets_met":[
1
],
"session":2,
"tx_bandwidth":1353,
"rx_bandwidth":1536,
"state_changed":1614798274,
"child_intfs":{
"spoke11-p1_0":{
"status":"up",
"latency":0.12929999828338623,
"jitter":0.028200000524520874,
"packet_loss":0,
"packet_sent":29626,
"packet_received":29625,
"sla_targets_met":[
1
],
"session":0,
"tx_bandwidth":2608,
"rx_bandwidth":1491,
"state_changed":0
}
}
},
"spoke12-p1":{
"status":"up",
"latency":0.11356667429208755,
"jitter":0.015699999406933784,
"packet_loss":0,
"packet_sent":29722,
"packet_received":29717,
"sla_targets_met":[
1
],
"session":2,
"tx_bandwidth":1353,
"rx_bandwidth":1536,
"state_changed":1614798274,
"child_intfs":{
"spoke12-p1_0":{
"status":"up",
"latency":0.095466658473014832,
"jitter":0.0092999991029500961,
"packet_loss":0,
"packet_sent":29687,
"packet_received":29686,
"sla_targets_met":[
1
],
"session":0,
"tx_bandwidth":1309,
"rx_bandwidth":2553,
"state_changed":0
}
}
}
}
},
....
....
SD-WAN rules
Implicit rule
SD-WAN rules define specific policy routing options to route traffic to an SD-WAN member. When no explicit SD-WAN
rules are defined, or if none of the rules are matched, then the default implicit rule is used.
In an SD-WAN configuration, the default route usually points to the SD-WAN interface, so each active member's
gateway is added to the routing table's default route. FortiOS uses equal-cost multipath (ECMP) to balance traffic
between the interfaces. One of five load balancing algorithms can be selected:
Source IP (source-ip-based) Traffic is divided equally between the interfaces, including the SD-WAN interface.
Sessions that start at the same source IP address use the same path.
This is the default selection.
Sessions (weight-based) The workload is distributing based on the number of sessions that are connected
through the interface.
The weight that you assign to each interface is used to calculate the percentage of
the total sessions that are allowed to connect through an interface, and the
sessions are distributed to the interfaces accordingly.
Sessions with the same source and destination IP addresses (src-ip and dst-
ip) are forwarded to the same path, but are still considered in later session ratio
calculations.
An interface's weight value cannot be zero.
Spillover (usage-based) The interface is used until the traffic bandwidth exceeds the ingress and egress
thresholds that you set for that interface. Additional traffic is then sent through the
next SD-WAN interface member.
Source-Destination IP (source- Traffic is divided equally between the interfaces. Sessions that start at the same
dest-ip-based) source IP address and go to the same destination IP address use the same path.
Volume (measured-volume- The workload is distributing based on the number of packets that are going
based) through the interface.
The volume weight that you assign to each interface is used to calculate the
percentage of the total bandwidth that is allowed to go through an interface, and
the bandwidth is distributed to the interfaces accordingly.
An interface's volume value cannot be zero.
You cannot exclude an interface from participating in load balancing using the implicit rule. If
the weight or volume were set to zero in a previous FortiOS version, the value is treated as a
one.
Interfaces with static routes can be excluded from ECMP if they are configured with a lower
priority than other static routes.
Examples
The following four examples demonstrate how to use the implicit rules (load-balance mode).
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
Example 1
Outgoing traffic is equally balanced between wan1 and wan2, using source-ip-based or source-dest-ip-based mode.
1. On the FortiGate, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route. See SD-WAN quick start on page 582 for details.
2. Go to Network > SD-WAN Rules.
3. Edit the sd-wan rule (the last default rule).
4. For the Load Balancing Algorithm, select either Source IP or Source-Destination IP.
5. Click OK.
1. Enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static route. See SD-WAN
quick start on page 582 for details.
2. Set the load balancing algorithm:
Source IP based:
config system sdwan
set load-balance-mode source-ip-based
end
Source-Destination IP based:
Example 2
Outgoing traffic is balanced between wan1 and wan2 with a customized ratio, using weight-based mode: wan1 runs 80%
of the sessions, and wan2 runs 20% of the sessions.
Sessions with the same source and destination IP addresses (src-ip and dst-ip) will be forwarded to the same
path, but will still be considered in later session ratio calculations.
5. Click OK.
Example 3
Outgoing traffic is balanced between wan1 and wan2 with a customized ratio, using measured-volume-based mode:
wan1 runs 80% of the volume, and wan2 runs 20% of the volume.
Example 4
Load balancing can be used to reduce costs when internet connections are charged at different rates. For example, if
wan2 charges based on volume usage and wan1 charges a fixed monthly fee, we can use wan1 at its maximum
bandwidth, and use wan2 for overflow.
In this example, wan1's bandwidth is 10Mbps down and 2Mbps up. Traffic will use wan1 until it reaches its spillover limit,
then it will start to use wan2. Note that auto-asic-offload must be disabled in the firewall policy.
1. On the FortiGate, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route. See SD-WAN quick start on page 582 for details.
2. Go to Network > SD-WAN Rules.
3. Edit the sd-wan rule (the last default rule).
4. For the Load Balancing Algorithm, select Spillover.
5. Enter 10000 in the wan1 Ingress Spillover Threshold field, and 2000 in the wan1 Egress Spillover Threshold field.
6. Click OK.
SD-WAN rules are used to control how sessions are distributed to SD-WAN members. Rules can be configured in one of
five modes:
l auto: Interfaces are assigned a priority based on quality.
l Manual (manual): Interfaces are manually assigned a priority.
l Best Quality (priority): Interface are assigned a priority based on the link-cost-factor of the interface.
l Lowest Cost (SLA) (sla): Interfaces are assigned a priority based on selected SLA settings. See Lowest cost (SLA)
strategy on page 625.
l Maximize Bandwith (SLA) (load-balance): Traffic is distributed among all available links based on the selected
load balancing algorithm. See Maximize bandwidth (SLA) strategy on page 628.
When using Best Quality mode, SD-WAN will choose the best link to forward traffic by comparing the link-cost-factor,
selected from one of the following:
Customized profile custom-profile-1 Select link based on customized profile. If selected, set the
following weights:
l packet-loss-weight: Coefficient of packet-loss.
bidirectional bandwidth.
If the Downstream (inbandwidth), Upstream (outbandwidth), or Bandwidth (bibandwidth) quality criteria is used,
the FortiGate will compare the bandwidth based on the configured upstream and downstream bandwidth values.
The interface speedtest can be used to populate the bandwidth values based on the speedtest results. See Interface
speedtest on page 609 for details.
Example
In this example, your wan1 and wan2 SD-WAN interfaces connect to two ISPs that both go to the public internet, and you
want Gmail services to use the link with the least latency.
1. On the FortiGate, add wan1 and wan2 as SD-WAN members, then add a policy and static route. See SD-WAN
quick start on page 582 for details.
2. Create a new Performance SLA named google. See Link monitoring example on page 606.
3. Go to Network > SD-WAN Rules.
4. Click Create New. The Priority Rule page opens.
5. Enter a name for the rule, such as gmail.
Field Setting
end
end
As wan2 has a smaller latency, SD-WAN will put Seq_num(2) on top of Seq_num(1) and wan2 will be used to forward
Gmail traffic.
SD-WAN rules are used to control how sessions are distributed to SD-WAN members. Rules can be configured in one of
five modes:
l auto: Interfaces are assigned a priority based on quality.
l Manual (manual): Interfaces are manually assigned a priority.
l Best Quality (priority): Interface are assigned a priority based on the link-cost-factor of the interface. See Best
quality strategy on page 622.
l Lowest Cost (SLA) (sla): Interfaces are assigned a priority based on selected SLA settings.
l Maximize Bandwidth (SLA) (load-balance): Traffic is distributed among all available links based on the selected
load balancing algorithm. See Maximize bandwidth (SLA) strategy on page 628.
When using Lowest Cost (SLA) mode (sla in the CLI), SD-WAN will choose the lowest cost link that satisfies SLA to
forward traffic. The lowest possible cost is 0. If multiple eligible links have the same cost, the Interface preference order
will be used to select a link.
In this example, your wan1 and wan2 SD-WAN interfaces connect to two ISPs that both go to the public internet. The
cost of wan2 is less than that of wan1. You want to configure Gmail services to use the lowest cost interface, but the link
quality must meet a standard of latency: 10ms, and jitter: 5ms.
1. On the FortiGate, add wan1 and wan2 as SD-WAN members, then add a policy and static route. See SD-WAN
quick start on page 582 for details.
2. Create a new Performance SLA named google that includes an SLA Target with Latency threshold = 10ms and
Jitter threshold = 5ms. See Link monitoring example on page 606.
3. Go to Network > SD-WAN Rules.
4. Click Create New. The Priority Rule page opens.
5. Enter a name for the rule, such as gmail.
6. Configure the following settings:
Field Setting
Field Setting
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
When both wan1 and wan2 meet the SLA requirements, Gmail traffic will only use wan2. If only wan1 meets the SLA
requirements, Gmail traffic will only use wan1, even though it has a higher cost. If neither interface meets the
requirements, wan2 will be used.
If both interface had the same cost and both met the SLA requirements, the first link configured in set priority-
members would be used.
SD-WAN rules are used to control how sessions are distributed to SD-WAN members. Rules can be configured in one of
five modes:
l auto: Interfaces are assigned a priority based on quality.
l Manual (manual): Interfaces are manually assigned a priority.
l Best Quality (priority): Interface are assigned a priority based on the link-cost-factor of the interface. See Best
quality strategy on page 622.
l Lowest Cost (SLA) (sla): Interfaces are assigned a priority based on selected SLA settings. See Lowest cost (SLA)
strategy on page 625.
l Maximize Bandwidth (SLA) (load-balance): Traffic is distributed among all available links based on the selected
load balancing algorithm.
When using Maximize Bandwidth mode (load-balance in the CLI), SD-WAN will choose all of the links that satisfies
SLA to forward traffic based on a load balancing algorithm. The load balancing algorithm, or hash method, can be one of
the following:
round-robin All traffic are distributed to selected interfaces in equal portions and circular order.
This is the default method, and the only option available when using the GUI.
source-dest-ip- All traffic from a source IP to a destination IP is sent to the same interface.
based
inbandwidth All traffic are distributed to a selected interface with most available bandwidth for incoming traffic.
outbandwidth All traffic are distributed to a selected interface with most available bandwidth for outgoing traffic.
bibandwidth All traffic are distributed to a selected interface with most available bandwidth for both incoming
and outgoing traffic.
When the inbandwidth, outbandwidth), or bibandwidth load balancing algorithm is used, the FortiGate will
compare the bandwidth based on the configured upstream and downstream bandwidth values.
The interface speedtest can be used to populate the bandwidth values based on the speedtest results. See Interface
speedtest on page 609 for details.
In this example, your wan1 and wan2 SD-WAN interfaces connect to two ISPs that both go to the public internet. You
want to configure Gmail services to use both of the interface, but the link quality must meet a standard of latency: 10ms,
and jitter: 5ms. This can maximize the bandwidth usage.
1. On the FortiGate, add wan1 and wan2 as SD-WAN members, then add a policy and static route. See SD-WAN
quick start on page 582 for details.
2. Create a new Performance SLA named google that includes an SLA Target 1 with Latency threshold = 10ms and
Jitter threshold = 5ms. See Link monitoring example on page 606.
3. Go to Network > SD-WAN Rules.
4. Click Create New. The Priority Rule page opens.
5. Enter a name for the rule, such as gmail.
Field Setting
When both wan1 and wan2 meet the SLA requirements, Gmail traffic will use both wan1 and wan2. If only one of the
interfaces meets the SLA requirements, Gmail traffic will only use that interface.
If neither interface meets the requirements but health-check is still alive, then wan1 and wan2 tie. The traffic will try to
balance between wan1 and wan2, using both interfaces to forward traffic.
In sla and load-balance modes, you can specify the number of links that must be up for the rule to take effect.
Example
In this example, ports 1 to 4 each have 10Mbps of bandwidth, and port 5 has 50Mbps. An application requires 35Mbps of
bandwidth, so the SD-WAN rule balances the traffic between ports 1 to 4. If one of the links goes down, all of the traffic
must be passed to port 5, so the minimum required number of links is 4.
edit <sla>
set id <id>
next
end
set priority-members 1 2 3 4
next
end
end
You can use MAC addresses as the source in SD-WAN rules and policy routes.
The FABRIC_DEVICE address object (a dynamic object that includes the IPs of Security Fabric devices) can be used as
a source or destination in SD-WAN rules and policy routes.
The diagnose ip proute match command accepts either the IP or MAC address format for the source:
diagnose ip proute match <destination> <source> <interface> <protocol> <port>
Use a traffic shaper in a firewall shaping policy to control traffic flow. You can use it to control maximum and guaranteed
bandwidth, or put certain traffic to one of the three different traffic priorities: high, medium, or low.
An advanced shaping policy can classify traffic into 30 groups. Use a shaping profile to define the percentage of the
interface bandwidth that is allocated to each group. Each group of traffic is shaped to the assigned speed limit based on
the outgoing bandwidth limit configured on the interface.
For more information, see Traffic shaping on page 1068.
Sample topology
Sample configuration
This example shows a typical customer usage where the customer's SD-WAN uses the default zone, and has two
member: wan1 and wan2, each set to 10Mb/s.
An overview of the procedures to configure SD-WAN traffic shaping and QoS with SD-WAN includes:
1. Give HTTP/HTTPS traffic high priority and give FTP low priority so that if there are conflicts, FortiGate will forward
HTTP/HTTPS traffic first.
2. Even though FTP has low priority, configure FortiGate to give it a 1Mb/s guaranteed bandwidth on each SD-WAN
member so that if there is no FTP traffic, other traffic can use all the bandwidth. If there is heavy FTP traffic, it can
still be guaranteed a 1Mb/s bandwidth.
3. Traffic going to specific destinations such as a VOIP server uses wan1 to forward, and SD-WAN forwards with an
Expedited Forwarding (EF) DSCP tag 101110.
To configure SD-WAN traffic shaping and QoS with SD-WAN in the GUI:
1. On the FortiGate, add wan1 and wan2 as SD-WAN members, then add a policy and static route.
See SD-WAN quick start on page 582.
2. Add a firewall policy with Application Control enabled. See Configuring firewall policies for SD-WAN on page 585.
3. Go to Policy & Objects > Traffic Shapers and edit low-priority.
a. Enable Guaranteed Bandwidth and set it to 1000 kbps.
4. Go to Policy & Objects > Traffic Shaping Policy and click Create New.
a. Name the traffic shaping policy, for example, HTTP-HTTPS.
b. Set the following:
Source all
Destination all
Outgoing virtual-wan-link
c. Click OK.
5. Go to Policy & Objects > Traffic Shaping Policy and click Create New.
a. Name the traffic shaping policy, for example, FTP.
b. Set the following:
Source all
Destination all
Outgoing virtual-wan-link
c. Click OK
6. Go to Network > SD-WAN Rules and click Create New.
a. Enter a name for the rule, such as Internet.
b. In the Destination section, click Address and select the VoIP server that you created in the firewall address.
c. Under Outgoing Interfaces select Manual.
d. For Interface preference select wan1.
e. Click OK.
7. Use CLI commands to modify DSCP settings. See the DSCP CLI commands below.
To configure SD-WAN traffic shaping and QoS with SD-WAN in the CLI:
config members
edit 1
set interface "wan1"
set gateway 172.16.20.2
next
edit 2
set interface "wan2"
set gateway 10.100.20.2
next
end
config service
edit 1
set name "SIP"
set priority-members 1
set dst "voip-server"
set dscp-forward enable
set dscp-forward-tag 101110
next
end
end
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
To use the diagnose command to check if specific traffic is attached to the correct traffic shaper:
[6:0x0:0/(1,65535)->(21,21)] helper:auto
[6:0x0:0/(1,65535)->(21,21)] helper:auto
To use the diagnose command to check if the correct traffic shaper is applied to the session:
To use the diagnose command to check the status of a shared traffic shaper:
name high-priority
maximum-bandwidth 131072 KB/sec
guaranteed-bandwidth 0 KB/sec
current-bandwidth 0 B/sec
priority 2
tos ff
packets dropped 0
bytes dropped 0
name low-priority
maximum-bandwidth 131072 KB/sec
guaranteed-bandwidth 125 KB/sec
current-bandwidth 0 B/sec
priority 4
tos ff
packets dropped 0
bytes dropped 0
name high-priority
maximum-bandwidth 131072 KB/sec
guaranteed-bandwidth 0 KB/sec
current-bandwidth 0 B/sec
priority 2
policy 1
tos ff
packets dropped 0
bytes dropped 0
name low-priority
maximum-bandwidth 131072 KB/sec
guaranteed-bandwidth 125 KB/sec
current-bandwidth 0 B/sec
priority 4
policy 2
tos ff
packets dropped 0
bytes dropped 0
SDN dynamic connector addresses can be used in SD-WAN rules. FortiGate supports both public (AWS, Azure, GCP,
OCI, AliCloud) and private (Kubernetes, VMware ESXi and NSX, OpenStack, ACI, Nuage) SDN connectors.
The configuration procedure for all of the supported SDN connector types is the same. This example uses an Azure
public SDN connector.
There are four steps to create and use an SDN connector address in an SD-WAN rule:
1. Configure the FortiGate IP address and network gateway so that it can reach the Internet.
2. Create an Azure SDN connector.
3. Create a firewall address to associate with the configured SDN connector.
4. Use the firewall address in an SD-WAN service rule.
Name azure1
Status Enabled
Directory ID 942b80cd-1b14-42a1-8dcf-4b21dece61ba
Application ID 14dbd5c5-307e-4ea4-8133-68738141feb1
5. Click OK.
Category Address
Name azure-address
Type Dynamic
Filter SecurityGroup=edsouza-centos
Interface Any
4. Click OK.
Diagnostics
Use the following CLI commands to check the status of and troubleshoot the connector.
...
azd sdn connector azure1 start updating IP addresses
azd checking firewall address object azure-address-1, vd 0
IP address change, new list:
10.18.0.4
10.18.0.12
...
...
# diagnose sys sdwan service
This topic covers how to use application steering in a topology with multiple WAN links. The following examples illustrate
how to use different strategies to perform application steering to accommodate different business needs:
l Static application steering with a manual strategy on page 641
l Dynamic application steering with lowest cost and best quality strategies on page 644
This example covers a typical usage scenario where the SD-WAN has two members: MPLS and DIA. DIA is primarily
used for direct internet access to internet applications, such as Office365, Google applications, Amazon, and Dropbox.
MPLS is primarily used for SIP, and works as a backup when DIA is not working.
This example configures all SIP traffic to use MPLS while all other traffic uses DIA. If DIA is not working, the traffic will
use MPLS.
1. Add port1 (DIA) and port2 (MPLS) as SD-WAN members, and configure a static route. See Configuring the SD-
WAN interface on page 583 for details.
2. Create a firewall policy with an Application Control profile configured. See Configuring firewall policies for SD-WAN
on page 585 for details.
3. Go to Network > SD-WAN Rules.
4. Click Create New. The Priority Rule page opens.
5. Enter a name for the rule, such as SIP.
6. Click the Application field and select the applicable SIP applications from the Select Entries panel.
7. Under Outgoing Interfaces, select Manual.
8. For Interface preference, select MPLS.
9. Click OK.
10. Click Create New to create another rule.
11. Enter a name for the rule, such as Internet.
12. Click the Address field and select all from the panel.
13. Under Outgoing Interfaces, select Manual.
To configure an SD-WAN rule to use SIP and DIA using the CLI:
end
config service
edit 1
set name "SIP"
set internet-service enable
set internet-service-app-ctrl 34640 152305677 38938 26180 26179 30251
set priority-members 2
next
edit 2
set name "Internet"
set dst "all"
set priority-members 1
next
end
end
All SIP traffic uses MPLS. All other traffic goes to DIA. If DIA is broken, the traffic uses MPLS. If you use VPN instead of
MPLS to run SIP traffic, you must configure a VPN interface, for example vpn1, and then replace member 1 from MPLS
to vpn1 for SD-WAN member.
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
To use the diagnose command to check performance SLA status using the CLI:
Dynamic application steering with lowest cost and best quality strategies
In this example, the SD-WAN has three members: two ISPs (DIA_1 and DIA_2) that are used for access to internet
applications, and an MPLS link that is used exclusively as a backup for business critical applications.
Business applications, such as Office365, Google, Dropbox, and SIP, use the Lowest Cost (SLA) strategy to provide
application steering, and traffic falls back to MPLS only if both ISP1 and ISP2 are down. Non-business applications, such
as Facebook and Youtube, use the Best Quality strategy to choose between the ISPs.
To configure the SD-WAN members, static route, and firewall policy in the GUI:
1. Add port1 (DIA_1), port2 (DIA_2), and port3 (MPLS) as SD-WAN members. Set the cost of DIA_1 and DIA_2 to 0,
and MPLS to 20. See Configuring the SD-WAN interface on page 583 for details.
2. Configure a static route. See Adding a static route on page 584 for details.
3. Create a firewall policy to allow traffic out on SD-WAN, with an Application Control profile configured. See
Configuring firewall policies for SD-WAN on page 585 for details.
To configure the SD-WAN rule and performance SLA checks for business critical application in the GUI:
4. Under Destination, set Application to your required applications. In this example: Microsoft.Office.365,
Microsoft.Office.Online, Google.Docs, Dropbox, and SIP.
5. Under Outgoing Interfaces, select Lowest Cost (SLA).
The lowest cost is defined in the SD-WAN member interface settings (see Configuring the SD-WAN interface on
page 583). The lowest possible cost is 0, which represents the most preferred link. In this example, DIA_1 and DIA_
2 both have a cost of 0, while MPLS has a cost of 20 because it is used for backup.
6. In Interface preference, add the interfaces in order of preference when the cost of the links is tied. In this example,
DIA_1, DIA_2, then MPLS.
MPLS will always be chosen last, because it has the highest cost. DIA_1 and DIA_2 have the same cost, so an
interface is selected based on their order in the Interface preference list.
7. Set Required SLA target to ensure that only links that pass your SLA target are chosen in this SD-WAN rule:
a. Click in the Required SLA target field.
b. In the Select Entries pane, click Create. The New Performace SLA pane opens.
c. Set Name to BusinessCritical_HC.
This health check is used for business critical applications in your SD-WAN rule.
d. Leave Protocol set to Ping, and add up to two servers, such as office.com and google.com.
e. Set Participants to Specify, and add all three interfaces: DIA_1, DIA_2, and MPLS.
f. Enable SLA Target.
The attributes in your target determine the quality of your link. The SLA target of each link is compared when
determining which link to use based on the lowest cost. Links that meet the SLA target are preferred over links
that fail, and move to the next step of selection based on cost. If no links meet the SLA target, then they all
move to the next step.
In this example, disable Latency threshold and Jitter threshold, and set Packet loss threshold to 1.
g. Click OK.
h. Select the new performance SLA to set it as the Required SLA target.
When multiple SLA targets are added, you can choose which target to use in the SD-WAN rule.
To configure the SD-WAN rule and performance SLA checks for non-business critical application in the
GUI:
The preferred link advantage can be customized in the CLI when the mode is priority
(Best Quality) or auto:
config system sdwan
config service
edit <id>
set link-cost-threshold <integer>
next
end
end
To configure the SD-WAN members, static route, and firewall policy in the CLI:
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
3. Configure a static route. See Adding a static route on page 584 for details.
4. Create a firewall policy to allow traffic out on SD-WAN, with an Application Control profile configured. See
Configuring firewall policies for SD-WAN on page 585 for details.
To configure the SD-WAN rule and performance SLA checks for business critical application in the CLI:
end
end
To configure the SD-WAN rule and performance SLA checks for non-business critical application in the
CLI:
Verification
Check the following GUI pages, and run the following CLI commands to confirm that your traffic is being steered by the
SD-WAN rules.
Health checks
1. Go to Network > Performance SLA and select each of the health checks from the list.
To verify the active members and hit count of the SD-WAN rule in the GUI:
The interface that is currently selected by the rule has a checkmark next to its name in the Members column. Hover
the cursor over the checkmark to open a tooltip that gives the reason why that member is selected. If multiple
members are selected, only the highest ranked member is highlighted (unless the mode is Maximize Bandwidth
(SLA)).
To verify the active members and hit count of the SD-WAN rule in the CLI:
1. Go to a dashboard and add the Top Cloud Applications by Bytes widget. See Cloud application view on page 116
for details.
2. Drill down on an application, such as YouTube, then select the Sessions tab.
This document demonstrates the Differentiated Services Code Point (DSCP) tag-based traffic steering in Fortinet secure
SD-WAN. You can use this guide as an example to deploy DSCP tag-based traffic steering in Fortinet secure SD-WAN.
DSCP tags are often used to categorize traffic to provide quality of service (QoS). Based on DSCP tags, you can provide
SD-WAN traffic steering on an edge device.
In this example, we have two different departments at the Headquarters site - Customer Service and Marketing. Traffic
from each of these departments is marked with separate DSCP tags by the core switch, and passes through the core
switch to the edge FortiGate. The edge FortiGate reads the DSCP tags and steers traffic to the preferred interface based
on the defined SD-WAN rules.
In our example, we consider two types of traffic - social media traffic and VoIP traffic. VoIP traffic from Customer Service
is considered to be more important than social media traffic. Each of these traffic types is marked with a DSCP tag by the
core switch - VoIP traffic is marked with the DSCP tag of 011100, and social media traffic is marked with the DSCP tag
of 001100. The DSCP tagged traffic is then passed on to the edge FortiGate. The edge FortiGate identifies the DSCP
tagged traffic and based on the defined SD-WAN rules, the edge FortiGate steers:
l VoIP traffic to the preferred VPN overlay with the least jitter in order to provide the best quality of voice
communication with the remote VoIP server (PBX)
l Social media traffic to the preferred Internet link with a lower cost (less expensive and less reliable)
If you are familiar with SD-WAN configurations in FortiOS, you can directly jump to the Configuring SD-WAN rules on
page 656 section to learn how to configure the SD-WAN rules to perform traffic steering. Otherwise, you can proceed
with all of the following topics to configure the edge FortiGate:
l Configuring IPsec tunnels on page 654
l Configuring SD-WAN zones on page 654
l Configuring firewall policies on page 655
l Configuring Performance SLA test on page 655
l Configuring SD-WAN rules on page 656
l Results on page 660
In our example, we have two interfaces Internet_A (port1) and Internet_B(port5) on which we have
configured IPsec tunnels Branch-HQ-A and Branch-HQ-B respectively. To learn how to configure IPsec tunnels, refer
to the IPsec VPNs on page 1276 section.
After you have configured the IPsec tunnels as required, verify your IPsec tunnels by navigating to VPN > IPsec Tunnels
from the tree menu on the left side of the GUI.
In order for us to steer traffic based on SD-WAN rules, first we need to configure SD-WAN interface members and assign
them to SD-WAN zones. To know more about SD-WAN zones, refer to theSD-WAN zones on page 593 section.
In our example, we created two SD-WAN zones. The virtual-wan-link SD-WAN zone for the underlay traffic
passing through the Internet_A(port1) and Internet_B(port5) interfaces, and the Overlay SD-WAN zone for
the overlay traffic passing through the Branch-HQ-A and Branch-HQ-B interfaces.
Verify the configurations on the Network > SD-WAN Zones screen:
We also need to configure a static route that points to the SD-WAN interface. To know more about static routes, refer to
the Adding a static route on page 584 section.
Configure firewall policies for both the overlay and underlay traffic. To know more about firewall policies, refer to the
Policies on page 945 section.
In this example, the Overlay-out policy governs the overlay traffic and the SD-WAN-Out policy governs the underlay
traffic. The firewall policies are configured accordingly.
Once created, verify the firewall policies by navigating to Policy & Objects > Firewall Policy:
The Security Profiles column indicates that the Overlay-out firewall policy for the overlay traffic is set up to not scan any
traffic, while the SD-WAN-Out firewall policy is set to scan all web traffic to identify and govern social media traffic as
Application Control profile is active.
Configure a performance SLA test that will be tied to the SD-WAN interface members we created and assigned to SD-
WAN zones. To know more about Performance SLA, refer to the SLA targets example on page 607 section.
In this example, we created a Performance SLA test Default_DNS with Internet_A(port1) and Internet_B
(port5) interface members as participants. We will use the created Performance SLA test to steer all web traffic
passing through the underlays other than social media traffic based on the Lowest Cost (SLA) strategy.
Configure SD-WAN rules to govern the steering of DSCP tag-based traffic to the appropriate interfaces. Traffic will be
steered based on the Criteria configured as part of the SD-WAN rules configuration.
In our example, we configured three different SD-WAN rules to govern DSCP tagged traffic. We have one SD-WAN rule
each for VoIP traffic, social media traffic (Facebook in this case), and all other web traffic. VoIP traffic is always steered
to either of the two overlay SD-WAN zones - VPN_A_tunnel(Branch-HQ-A) or VPN_B_tunnel(Branch-HQ-B).
Similarly, social media traffic and other web traffic is always steered to either of the two underlay SD-WAN zones -
Internet_A(port1) or Internet_B(port5). The interface that is preferred by the system over another depends
upon the Criteria configured in the SD-WAN rule definition.
We configured the following SD-WAN rules:
l SD-WAN rule for VoIP traffic on page 656
l SD-WAN rule for social media traffic on page 657
l SD-WAN rule for other web traffic on page 658
To configure SD-WAN rule for DSCP tagged VoIP traffic using the CLI:
The VoIP-Steer SD-WAN rule configured above governs the DSCP tagged VoIP traffic.
DSCP values commonly are 6-bit binary numbers that are padded with zeros at the end. Therefore, in this example,
VoIP traffic with DSCP tag 011100 will become 01110000. This 8-bit binary number 01110000 is represented in its
hexadecimal form 0x70 as the tos (Type of Service bit pattern) value. The tos-mask (Type of Service evaluated bits)
hexadecimal value of 0xf0 (binary 11110000) is used to check the four most significant bits from the tos value in this
case. Hence, the first four bits of the tos (0111) will be used to match the first four bits of the DSCP tag in our policy
above. Only the non-zero bit positions are used for comparison and the zero bit positions are ignored from the tos-
mask.
We used the Best Quality strategy to define the Criteria to select the preferred interface from the overlay SD-WAN zone.
With the Best Quality strategy selected, the interface with the best measured performance is selected. The system
prefers the interface with the least Jitter.
To know more about configuring SD-WAN rules with the Best Quality strategy, refer to the Best quality strategy on page
622 section.
To configure SD-WAN rule for DSCP tagged social media traffic using the CLI:
The Facebook-DSCP-steer SD-WAN rule configured above governs the DSCP tagged social media traffic.
DSCP values commonly are 6-bit binary numbers that are padded with zeros at the end. Therefore, in this example,
social media traffic with DSCP tag 001100 will become 00110000. This 8-bit binary number 00110000 is represented
in its hexadecimal form 0x30 as the tos (Type of Service bit pattern) value. The tos-mask (Type of Service evaluated
bits) hexadecimal value of 0xf0 (binary 11110000) is used to check the four most significant bits from the tos value in
this case. Hence, the first four bits of the tos (0011) will be used to match the first four bits of the DSCP tag in our policy
above. Only the non-zero bit positions are used for comparison and the zero bit positions are ignored from the tos-
mask.
We used a manual strategy to select the preferred interface from the underlay SD-WAN zone. We manually select the
preferred interface as Internet_B(port5) to steer all social media traffic to.
To know more about configuring SD-WAN rules with static application steering with a manual strategy, refer to the Static
application steering with a manual strategy on page 641 section.
To configure SD-WAN rule for all other web traffic using the CLI:
end
The All-traffic SD-WAN rule configured above governs all other web traffic.
We used the Lowest Cost (SLA) strategy to define the Criteria to select the preferred interface from the underlay SD-
WAN zone. With the Lowest Cost (SLA) strategy selected, the interface that meets the defined Performance SLA targets
(Default_DNS in our case) is selected. When there is a tie, the interface with the lowest assigned Cost (Internet_A
(port1) in our case) is selected.
To know more about configuring SD-WAN rules with the Lowest Cost (SLA) strategy, refer to the Lowest cost (SLA)
strategy on page 625 section.
Once configured, verify your SD-WAN rules by navigating to Network > SD-WAN Rules:
Results
The following sections show the function of the FortiGate and specifically of secure SD-WAN with respect to DSCP
tagged traffic steering, and can be used to confirm that it is setup and running correctly:
l Verifying the DSCP tagged traffic on FortiGate on page 660
l Verifying service rules on page 661
l Verifying traffic steering as per the defined SD-WAN rules on page 662
l Verifying steered traffic leaving the required interface on page 662
To verify the incoming DSCP tagged traffic, we used packet sniffing and converting the sniffed traffic to a desired format.
To know more about packet sniffing, refer to the Using the FortiOS built-in packet sniffer guide on the Fortinet
Knowledge Base.
FortiGate # diagnose sniffer packet any '(ip and ip[1] & 0xfc == 0x70)' 6 0 l
We used the open-source packet analyzer Wireshark to verify that VoIP traffic is tagged with the 0x70 DSCP tag.
FortiGate # diagnose sniffer packet any '(ip and ip[1] & 0xfc == 0x30)' 6 0 l
We used the open-source packet analyzer Wireshark to verify that web traffic is tagged with the 0x30 DSCP tag.
The following CLI commands show the appropriate DSCP tags and the corresponding interfaces selected by the SD-
WAN rules to steer traffic:
FortiGate # diagnose sys sdwan service
Go to Network > SD-WAN Rules to review the Hit Count on the appropriate SD-WAN interfaces.
Go to Dashboard > Top Policies to confirm that web traffic (port 443) flows through the right underlay interface members,
and VoIP traffic flows through the right overlay interface member.
Web traffic leaves either Interface_A(port1) or Interface_B(port5).
Advanced routing
Self-originating traffic
This topic applies to FortiOS 6.4.4 and later. In other versions, self-originating (local-out) traffic
behaves differently.
By default, self-originating traffic, such as Syslog, FortiAnalyzer logging, FortiGuard services, remote authentication, and
others, relies on routing table lookups to determine the egress interface that is used to initiate the connection. Policy
routes generated by SD-WAN rules do not apply to this traffic.
Explicit proxy traffic uses policy routes and SD-WAN rules to select an egress interface. Self-originating VXLAN traffic
uses SD-WAN rules to select an egress interface.
For the following features, self-originating traffic can be configured to use SD-WAN rules or a specific interface:
PING
DNS
DNS and non-management VDOM DNS traffic can use SD-WAN rules or a specific interface:
config system {dns | vdom-dns}
set interface-select-method {auto | sdwan | specify}
set interface <interface>
end
interface <interface> Specify the outgoing interface. This option is only available and must be
configured when interface-select-method is specify.
FortiGuard
RADIUS
RADIUS, and individual accounting servers, traffic can use SD-WAN rules or a specific interface:
config user radius
edit <name>
set interface-select-method {auto | sdwan | specify}
set interface <interface>
config accounting-server
edit <name>
set interface-select-method {auto | sdwan | specify}
set interface <interface>
next
end
next
end
LDAP
TACACS+
Central management
FortiAnalyzer
FortiAnalyzer and FortiAnalyzer Cloud log traffic can use SD-WAN rules or a specific interface:
config log {fortianalyzer | fortianalyzer2 | fortianalyzer3 | fortianalyzer-cloud} {setting
| override-setting}
set interface-select-method {auto | sdwan | specify}
set interface <interface>
end
FortiGate Cloud log traffic can use SD-WAN rules or a specific interface:
config log fortiguard setting
set interface-select-method {auto | sdwan | specify}
set interface <interface>
end
Syslog
Log disk upload traffic can use SD-WAN rules or a specific interface:
config log disk setting
set interface-select-method {auto | sdwan | specify}
set interface <interface>
end
FortiSandbox
FSSO
NTP server
External resources
DHCP proxy
dhcp-proxy-interface Specify the outgoing interface. This option is only available and must be
<interface> configured when interface-select-method is specify.
DHCP relay
dhcp-relay-interface Specify the outgoing interface. This option is only available and must be
<interface> configured when interface-select-method is specify.
Certificate renewal with SCEP traffic can use SD-WAN rules or a specific interface:
config vpn certificate setting
set interface-select-method {auto | sdwan | specify}
set interface <interface>
end
interface <interface> Specify the outgoing interface. This option is only available and must be
configured when interface-select-method is specify.
vdom <VDOM> Specify the VDOM. This option is only available and must be configured when
interface-select-method is sdwan or specify.
source-ip <IPv4 address> Specify the source IPv4 address. This option is only available and must be
configured when interface-select-method is sdwan or specify.
source-ip6 <IPv6 address> Specify the source IPv6 address. This option is only available and must be
configured when interface-select-method is sdwan or specify.
SD-WAN rules can use Border Gateway Protocol (BGP) learned routes as dynamic destinations.
In this example, a customer has two ISP connections, wan1 and wan2. wan1 is used primarily for direct access to
internet applications, and wan2 is used primarily for traffic to the customer's data center.
The customer could create an SD-WAN rule using the data center's IP address range as the destination to force that
traffic to use wan2, but the data center's IP range is not static. Instead, a BGP tag can be used.
For this example, wan2's BGP neighbor advertises the data center's network range with a community number of 30:5.
This example assumes that SD-WAN is enabled on the FortiGate, wan1 and wan2 are added as SD-WAN members in
the virtual-wan-link SD-WAN zone, and a policy and static route have been created. See SD-WAN quick start on page
582 for details.
end
next
end
3. Configure BGP:
config router bgp
set as xxxxx
set router-id xxxx
config neighbor
edit "10.100.20.2"
set soft-reconfiguration enable
set remote-as xxxxx
set route-map-in "comm1"
next
end
end
end
config service
edit 1
set name "DataCenter"
set mode manual
set route-tag 15
set priority-members 2
next
end
end
Use the get router info bgp network command to check the network community:
# get router info bgp network
BGP table version is 5, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Use the get router info route-map-address command to check dynamic BGP addresses:
# get router info route-map-address
Extend-tag: 15, interface(wan2:16)
10.100.11.0/255.255.255.0
Use the diagnose firewall proute list command to check dynamic BGP addresses used in policy routes:
# diagnose firewall proute list
list route policy info(vf=root):
BGP supports multiple paths, allowing an ADVPN to advertise multiple paths. This allows BGP to extend and keep
additional network paths according to RFC 7911.
In this example, Spoke1 and Spoke2 each have four VPN tunnels that are connected to the Hub with ADVPN. The
Spoke-Hub has established four BGP neighbors on all four tunnels.
Spoke 1 and Spoke 2 can learn four different routes from each other.
To configure a spoke:
SD-WAN allows you to select different outbound WAN links based on performance SLAs. It is important that BGP
neighbors are aware of these settings, and changes to them.
BGP can adapt to changes in SD-WAN link SLAs in the following ways:
l Applying different route-maps based on the SD-WAN's health checks. For example, different BGP community
strings can be advertised to BGP neighbors when SLAs are not met.
l Traffic can be selectively forwarded based on the active BGP neighbor. If the SD-WAN service's role matches the
active SD-WAN neighbor, the service is enabled. If there is no match, then the service is disabled.
Example
In this topology, a branch FortiGate has two SD-WAN gateways serving as the primary and secondary gateways. The
gateways reside in different datacenters, but have a full mesh network between them.
This example shows how route-maps and service rules are selected based on performance SLAs and the member that
is currently active. Traffic flows through the primary gateway unless the neighbor's health check is outside of its SLA. If
that happens, traffic routes to the secondary gateway.
BGP NBR1 is the primary neighbor and BGP NBR2 is the secondary neighbor.
The branch FortiGate's wan1 and wan2 interfaces are members of the SD-WAN. When the SD-WAN neighbor status is
primary, it will advertise community 20:1 to BGP NBR1 and 20:5 to BGP NBR2. When the SD-WAN neighbor status is
secondary, it will advertise 20:5 to BGP NBR1 and 20:2 to BGP NBR2.
Only one of the primary or secondary neighbors can be active at one time. The SD-WAN neighbor status is used to
decide which neighbor is selected:
l Primary: The primary neighbor takes precedence if its SLAs are met.
l Secondary: If the primary neighbor's SLAs are not met, the secondary neighbor becomes active if its SLAs are met.
l Standalone: If neither the primary or secondary neighbor's SLAs are met, the SD-WAN neighbor status becomes
standalone.
Route map
SD-WAN is configured to let BGP advertise different communities when the SLA status changes. When the SLA is
missed, it triggers BGP to advertise a different community to its BGP neighbor based on its route-map. The BGP
neighbors can use the received community string to select the best path to reach the branch.
When SLAs are met, route-map-out-preferable is used. When SLAs are missed, route-map-out is used.
To configure SD-WAN:
3. Configure the SD-WAN neighbors and assign them a role and the health checks used to determine if the neighbor
meets the SLA:
SD-WAN neighbors can only be configured in the CLI.
config system sdwan
config neighbor
edit "10.100.1.1"
set member 1
set role primary
set health-check "ping"
set sla-id 1
next
edit "10.100.1.5"
set member 2
set role secondary
set health-check "ping2"
set sla-id 1
next
end
end
Service rules
Create SD-WAN service rules to direct traffic to the primary neighbor when its SLAs are met, and to the secondary
neighbor when the primary neighbor's SLAs are missed.
If neither the primary nor secondary neighbors are active, the SD-WAN neighbor status
becomes standalone. Only service rules with standalone-action enabled will continue to
pass traffic. This option is disabled by default.
Verification
Dst address:
0.0.0.0-255.255.255.255
Dst address:
0.0.0.0-255.255.255.255
Dst address:
0.0.0.0-255.255.255.255
Dst address:
0.0.0.0-255.255.255.255
Controlling traffic with BGP route mapping and service rules explained how BGP can apply different route-maps to the
primary and secondary SD-WAN neighbors based on SLA health checks.
In this example, SD-WAN neighbors that are not bound to primary and secondary roles are configured.
The FortiGate has multiple SD-WAN links and has formed BGP neighbors with both ISPs.
ISP1 is used primarily for outbound traffic, and has an SD-WAN service rule using the lowest cost algorithm applied to it.
When SLAs for ISP1 are not met, it will fail over to the MPLS line.
Inbound traffic is allowed by both WAN links, with each WAN advertising a community string when SLAs are met. When
SLAs are not met, the WAN links advertise a different community string.
This example uses two SD-WAN links. The topology can be expanded to include more links as needed.
end
next
end
When SLAs are met, route-map-out-preferable is used. When SLAs are missed, route-map-out is used.
To configure SD-WAN:
3. Configure the SD-WAN neighbors and assign them a role and the health checks used to determine if the neighbor
meets the SLA:
When no role is defined, the default role, standalone, is used.
config system sdwan
config neighbor
edit "192.168.2.1"
set member 1
set health-check "pingserver"
set sla-id 1
next
edit "172.31.0.1"
set member 2
set health-check "pingserver"
set sla-id 1
next
end
end
Service rules
Create SD-WAN service rules to direct traffic to the SD-WAN links based on the lowest cost algorithm The same SLA
health check and criteria that are used for the SD-WAN neighbor are used for this SD-WAN service rule.
When no roles are defined in the service rule, the default role, standalone, is used.
Verification
To verify that when both SLAs are met, port1 is selected due to its lower cost:
Dst address:
0.0.0.0-255.255.255.255
To verify that when neighbor ISP1 misses SLAs, MPLS is selected and BGP advertises a different
community string for ISP1:
Dst address:
0.0.0.0-255.255.255.255
VPN overlay
This topic provides an example of how to use SD-WAN and ADVPN together.
ADVPN (Auto Discovery VPN) is an IPsec technology that allows a traditional hub-and-spoke VPN’s spokes to establish
dynamic, on-demand, direct tunnels between each other to avoid routing through the topology's hub device. The primary
advantage is that it provides full meshing capabilities to a standard hub-and-spoke topology. This greatly reduces the
provisioning effort for full spoke-to-spoke low delay reachability, and addresses the scalability issues associated with
very large fully meshed VPN networks.
If a customer's head office and branch offices all have two or more internet connections, they can build a dual-hub
ADVPN network. Combined with SD-WAN technology, the customer can load-balance traffic to other offices on multiple
dynamic tunnels, control specific traffic using specific connections, or choose better performance connections
dynamically.
SD-WAN load-balance mode rules (or services) do not support ADVPN members. Other
modes' rules, such as SLA and priority, support ADVPN members.
Configuration example
A typical ADVPN configuration with SD-WAN usually has two hubs, and each spoke connects to two ISPs and
establishes VPN tunnels with both hubs.
This example shows a hub-and-spoke configuration using two hubs and one spoke:
l Hub1 and Hub2 both use wan1 to connect to the ISPs and port10 to connect to internal network.
l Spoke1 uses wan1 to connect to ISP1 and wan2 to connect to ISP2.
l wan1 sets up VPN to hub1.
l wan2 sets up VPN to hub2.
The SD-WAN is configured on the spoke. It uses the two VPN interfaces as members and two rules to control traffic to
headquarters or other spokes using ADVPN VPN interfaces. You can create more rules if required.
For this example:
l Use SD-WAN member 1 (via ISP1) and its dynamic shortcuts for financial department traffic if member 1 meets SLA
requirements. If it doesn't meet SLA requirements, it will use SD-WAN member 2 (via ISP2).
l Use SD-WAN member 2 (via ISP2) and its dynamic shortcuts for engineering department traffic.
l Load balance other traffic going to hubs and other spokes between these two members.
l Set up all other traffic to go with their original ISP connection. All other traffic does not go through SD-WAN.
l Set up basic network configuration to let all hubs and spokes connect to their ISPs and the Internet.
Firewall addresses Configure hub_subnets and spoke_subnets before using in policies. These can
be customized.
The GUI does not support some ADVPN related options, such as auto-discovery-sender, auto-discovery-receiver, auto-
discovery-forwarder, and IBGP neighbor-group setting, so this example only provides CLI configuration commands.
next
end
Hub2 configuration is the same as hub1 except the wan1 IP address, VPN interface IP address, and BGP neighbor-
range prefix.
next
end
config router bgp
set as 65505
config neighbor-group
edit "advpn"
set link-down-failover enable
set remote-as 65505
set route-reflector-client enable
next
end
config neighbor-range
edit 1
set prefix 10.10.200.0 255.255.255.0
set neighbor-group "advpn"
next
end
config network
edit 1
set prefix 172.16.101.0 255.255.255.0
next
edit 2
set prefix 11.11.11.0 255.255.255.0
next
end
end
To configure SD-WAN:
next
end
config service
edit 1
set mode sla
set dst "finacial-department"
config sla
edit "ping"
set id 1
next
end
set priority-member 1 2
next
edit 2
set member 2
set dst "engineering-department"
next
end
end
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
Use the following CLI commands to check status before spoke vs spoke shortcut VPN is established.
# get router info bgp summary
BGP router identifier 2.2.2.2, local AS number 65505
BGP table version is 13
3 BGP AS-PATH entries
0 BGP community entries
Use the following CLI commands to check status after spoke vs spoke shortcut VPN is established.
# get router info routing-table bgp
------------------------------------------------------
name=spoke1-2-phase1 ver=1 serial=6 112.1.1.2:0->11.1.2.11:0 dst_mtu=15324
bound_if=90 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/536 options[0218]=npu create_dev
frag-rfc accept_traffic=1
parent=vd2-1 index=0
proxyid_num=1 child_num=0 refcnt=18 ilast=8 olast=8 ad=r/2
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=vd2-1 proto=0 sa=1 ref=2 serial=1 auto-negotiate adr
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=3 options=1a227 type=00 soft=0 mtu=15262 expire=42893/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000000 itn=0 qat=0
life: type=01 bytes=0/0 timeout=42901/43200
dec: spi=03e01a44 esp=aes key=16 c3b77a98e3002220e2373b73af14df6e
ah=sha1 key=20 d18d107c248564933874f60999d6082fd7a78948
enc: spi=864f6dba esp=aes key=16 eb6181806ccb9bac37931f9eadd4d5eb
ah=sha1 key=20 ab788f7a372877a5603c4ede1be89a592fc21873
dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
npu_flag=00 npu_rgwy=13.1.1.3 npu_lgwy=12.1.1.2 npu_selid=51 dec_npuid=0 enc_npuid=0
------------------------------------------------------
name=spoke1-2-phase1_0 ver=1 serial=57 112.1.1.2:0->113.1.1.3:0 dst_mtu=15324
bound_if=90 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/728 options[02d8]=npu
create_dev no-sysctl rgwy-chg frag-rfc accept_traffic=1
parent=vd2-2 index=0
proxyid_num=1 child_num=0 refcnt=17 ilast=5 olast=5 ad=r/2
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=vd2-2 proto=0 sa=1 ref=3 serial=1 auto-negotiate adr
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SD-WAN monitors ADVPN shortcut link quality by dynamically creating link monitors for each ADVPN link. The dynamic
link monitor on the spoke will use ICMP probes and the IP address of the gateway as the monitored server. These ICMP
probes will not be counted as actual user traffic that keeps the spoke-to-spoke tunnel alive.
OCVPN has the capability to enable SD-WAN in order to dynamically add its tunnel interfaces as SD-WAN members.
Users can configure SD-WAN health checks and service rules to direct traffic over the OCVPN tunnels.
The following example uses a dual hub and spoke topology. Each hub and spoke has two WAN link connections to the
ISP. The spokes generate two IPsec tunnels to each hub (four tunnels in total). BGP neighbors are established over
each tunnel and routes from the hubs and other spokes learned from all neighbors, which forms an ECMP scenario. All
tunnels are placed as SD-WAN members, so traffic can be distributed across tunnels based on the configured SD-WAN
service rules.
The WAN interface is position sensitive, meaning a tunnel will be created with the first
position interface on the hub to the first position interface on the spoke, and so on. In
this example, FGT_A (primary hub) will create two tunnels with FGT_C (spoke):
l FGT_A port15 <==> FGT_C internal1
d. Click Apply.
3. Configure the secondary hub with the same settings as the primary hub.
4. Configure the spoke:
a. Go to VPN > Overlay Controller VPN and set the Status to Enable.
b. For Role, select Spoke.
c. Enter the WAN interfaces (internal1 and internal2).
d. Enable Auto-discovery shortcuts.
e. Enable Add OCVPN tunnels to SD-WAN. The IPsec tunnels will be added automatically to the SD-WAN
members if SD-WAN is enabled.
The overlay names on the spokes must match the hub for the traffic to be allowed
through the same overlay.
g. Click Apply.
Firewall policies will be automatically generated by OCVPN between the local interfaces and the SD-WAN interface.
Each policy will define the proper local and remote networks for its source and destination addresses.
edit 1
set type interface
set interface "loop1"
next
end
next
end
end
2. Configure the secondary hub with the same settings as the primary hub.
3. Configure the spoke:
config vpn ocvpn
set status enable
set sdwan enable
set wan-interface "internal1" "internal2"
config overlays
edit "overlay1"
config subnets
edit 1
set type interface
set interface "wan2"
next
end
next
edit "overlay2"
config subnets
edit 1
set type interface
set interface "loop1"
next
end
next
end
end
Firewall policies will be automatically generated by OCVPN between the local interfaces and the SD-WAN interface.
Each policy will define the proper local and remote networks for its source and destination addresses.
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
parent=_OCVPN2-1b index=0
proxyid_num=1 child_num=0 refcnt=15 ilast=0 olast=0 ad=r/2
stat: rxp=641 txp=1025 rxb=16436 txb=16446
dpd: mode=on-idle on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=_OCVPN2-1b proto=0 sa=1 ref=3 serial=1 auto-negotiate adr
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=6 options=1a227 type=00 soft=0 mtu=1438 expire=42650/0B replaywin=1024
seqno=407 esn=0 replaywin_lastseq=00000280 itn=0 qat=0 hash_search_len=1
life: type=01 bytes=0/0 timeout=43186/43200
dec: spi=90f03d9d esp=aes key=16 6cb33685bbc67d5c85488e0176ecf7b0
ah=sha1 key=20 7d11b3babe62c840bf444b7b1f637b4324722a71
enc: spi=7bc94bda esp=aes key=16 b4d8fc731d411eb24448b4077a5872ca
ah=sha1 key=20 b724064d827304a6d80385ed4914461108b7312f
dec:pkts/bytes=641/16368, enc:pkts/bytes=2053/123426
npu_flag=03 npu_rgwy=172.16.15.4 npu_lgwy=172.16.18.3 npu_selid=1f dec_npuid=1 enc_
npuid=1
------------------------------------------------------
name=_OCVPN2-0a ver=2 serial=18 172.16.17.3:0->172.16.13.1:0 dst_mtu=1500
bound_if=8 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/536 options[0218]=npu create_
dev frag-rfc accept_traffic=1 overlay_id=1
This topic shows an SD-WAN with forward error correction (FEC) on VPN overlay networks. FEC is a technique used to
control and correct errors in data transmission by sending redundant data across the VPN. It uses six parameters in
IPsec phase1/phase1-interface settings:
fec-ingress Enable/disable Forward Error Correction for ingress IPsec traffic (default = disable).
fec-egress Enable/disable Forward Error Correction for egress IPsec traffic (default = disable).
fec-base The number of base Forward Error Correction packets (1 - 100, default = 20).
fec-redundant The number of redundant Forward Error Correction packets (1 - 100, default = 10).
fec-send-timeout The time before sending Forward Error Correction packets, in milliseconds (1 - 1000, default =
8).
fec-receive- The time before dropping Forward Error Correction packets, in milliseconds (1 - 1000, default
timeout = 5000).
For every fec-base number of sent packets, the tunnel will send fec-redundant number of redundant packets.
Example
For example, a customer has two ISP connections, wan1 and wan2. Using these two connections, create two IPsec VPN
interfaces as SD-WAN members. Configure FEC on each VPN interface to lower packet loss ratio by re-transmitting the
packets using its backend algorithm.
To configure SD-WAN:
edit 1
set interface "vd1-p1"
set gateway 172.16.211.2
next
edit 1
set interface "vd2-p2"
set gateway 172.16.212.2
next
end
end
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
This wizard is used to automatically set up multiple VPN tunnels to the same destination over multiple outgoing
interfaces. This includes automatically configuring IPsec, routing, and firewall settings, avoiding cumbersome and error-
prone configuration steps.
1. Go to Network > SD-WAN Zones and click Create New > SD-WAN Member.
2. In the Interface drop-down, click +VPN. The Create IPsec VPN for SD-WAN members pane opens.
5. Select the VPN interface to add it as an SD-WAN member, then click OK.
SD-WAN duplication rules can specify SD-WAN service rules to trigger packet duplication. This allows the duplication to
occur based on an SD-WAN rule instead of the source, destination, and service parameters in the duplication rule.
1. Packets can be forced to duplicate to all members of the same SD-WAN zone. See Duplicate packets on other zone
members on page 714 for details.
For example, in Spoke 1 set packet-duplication to force so that when a client sends a packet to the server, it
is duplicated to all members of the same zone as long as its health check is alive. If a members health check is
dead, then the member is removed from the SD-WAN duplication zone.
2. Packets can be duplicated to other members of the SD-WAN zone only when the condition of the link is not good
enough.
Set packet-duplication to on-demand so that, when the SLA of the member does not match (sla_map=0) the
packet is duplicated, but when the SLA does match (sla_map!=0) the packet is not duplicated.
3. Packets can be duplicated to all members of the same SD-WAN zone when the traffic matches one or more regular
SD-WAN service rules.
The following example shows the third type of packet duplication.
In this example, SD-WAN is configured with three members: vpn1, vpn2, and vpn3. Service rule 1 controls all traffic from
10.100.20.0/24 to 172.16.100.0/24 using member 1.
To send a duplicate of the traffic that matches service rule 1 using member 2, members 1 and 2 are added to the same
SD-WAN zone, and a duplicate rule is configured with service-id set to 1.
To send a duplicate of the traffic that matches service rule 1 using member 2:
edit 3
set interface "vpn3"
set zone "zone2"
next
end
config service
edit 1
set dst "172.16.100.0"
set src "10.100.20.0"
set priority-members 1
next
end
config duplication
edit 1
set service-id 1
set packet-duplication force
next
end
end
When duplication rules are used, packets are duplicated on other good links within the SD-WAN zone and de-duplicated
on the destination FortiGate. Use force mode to force duplication on other links within the SD-WAN zone, or use on-
demand mode to trigger duplication only when SLA fails on the selected member.
The duplication rule is configured in the CLI by using the config duplication command. The following options can
be configured:
Parameter Description
l force: Duplicate packets across all interface members of the SD-WAN zone.
The duplication-max-num <integer> option under config system sdwan is the maximum number of
interface members that a packet is duplicated on in the SD-WAN zone (2 - 4, default = 2). If this value is set to 3, the
original packet plus two more copies are created. If there are three member interfaces in the SD-WAN zone and the
duplication-max-num is set to 2, the packet duplication follows the configuration order, so the packets are
duplicated on the second member.
Example
The packet duplication feature works best in a spoke-spoke or hub-and-spoke topology. In this example, a hub-and-
spoke ADVPN topology is used. Before shortcuts are established, Hub 1 forwards the duplicate packets from Spoke 1 to
Spoke 2. Once shortcuts are established, Hub 1 is transparent, and duplicate packets are exchanged directly between
the spokes.
1. Configure Spoke 1:
config system sdwan
set status enable
config zone
edit "virtual-wan-link"
next
edit "sdwanzone_v4"
next
end
config members
edit 1
set interface "t1"
set zone "sdwanzone_v4"
next
edit 4
set interface "t21"
set zone "sdwanzone_v4"
next
edit 2
set interface "t2"
set zone "sdwanzone_v4"
next
end
config health-check
edit "h1"
set server "10.34.1.1"
set interval 1000
set failtime 10
set members 1 2
config sla
edit 1
set packetloss-threshold 40
next
end
next
end
config duplication
edit 1
set srcaddr "all"
set dstaddr "all"
set srcintf "port1"
set dstintf "sdwanzone_v4"
set service "ALL"
set packet-duplication force
set packet-de-duplication enable
next
end
end
Advanced configuration
This example shows how to convert a standalone FortiGate SD-WAN solution to a FGCP HA cluster with full-mesh WAN
set up. This configuration allows you to load balance your internet traffic between multiple ISP links. It also provides
redundancy for your internet connection if your primary ISP in unavailable, or if one of the FortiGates in the HA cluster
fails.
This example assumes that a standalone FortiGate has already been configured for SD-WAN by following the SD-WAN
quick start on page 582.
Standalone FortiGate:
FGCP HA cluster:
Enabling HA and re-cabling the WAN interfaces will cause network interruptions.
This procedure should be performed during a maintenance window.
After running the following commands, the FortiGate negotiates to establish an HA cluster. You might temporarily lose
connectivity with the FortiGate as FGCP negotiations take place and the MAC addresses of the FortiGate interfaces are
changed to HA virtual MAC addresses.
This configurations sets the HA mode to active-passive.
The ha1 and ha2 interfaces are configured as the heartbeat interfaces, with priorities set to 200 and 100 respectively.
Setting different priorities for the heartbeat interfaces is a best practice, but is not required.
If you have more than one cluster on the same network, each cluster should have a different group ID. Changing the
group ID changes the cluster interface's virtual MAC addresses. If the group IP causes a MAC address conflict on your
network, select a different group ID.
Enabling override and increasing the device priority means that this FortiGate always becomes the primary unit.
1. Go to System > Settings and change the Host name so that the FortiGate can be easily identified as the primary
unit.
2. Go to System > HA and configure the following options:
Mode Active-Passive
Password <password>
Override and the group ID can only be configured from the CLI.
3. Click OK.
Connectivity with the FortiGate will temporarily be lost.
1. Change the host name so that the FortiGate can be easily identified:
config system global
set hostname primary_FG
end
2. Configure HA:
config system ha
set mode a-p
set group-id 100
set group-name My-cluster
set password <password>
set priority 250
set override enable
set hbdev ha1 200 ha2 100
end
If HA mode does not start after running the above steps, ensure that none of the FortiGate's
interfaces use DHCP or PPPoE addressing.
The secondary FortiGate must be the same model and running the same firmware version as the primary FortiGate. The
HA settings are the same as the for the primary unit, except the secondary device has a lower priority and override is not
enabled.
It is best practice to reset the FortiGate to factory default settings prior to configuring HA. This
reduces the chance of synchronization problems.
# execute factoryreset
This operation will reset the system to factory default!
Do you want to continue? (y/n) y
1. Go to System > Settings and change the Host name so that the FortiGate can be easily identified as the backup unit.
2. Go to System > HA and configure the options the same as for the primary FortiGate, except with a lower priority:
Mode Active-Passive
Password <password>
3. Click OK.
1. Change the host name so that the secondary FortiGate can be easily identified:
config system global
set hostname secondary_FG
end
2. Configure HA:
config system ha
set mode a-p
set group-id 100
set group-name My-cluster
set password <password>
set priority 128
set hbdev ha1 200 ha2 100
end
1. Connect the heartbeat interfaces ha1 and ha2 between the primary and secondary FortiGate.
a. An HA primary device is selected. Because the primary FortiGate has a higher priority and override enabled, it
assumes the role of HA primary.
b. The secondary FortiGate synchronizes its configuration from the primary device.
2. Verify that the checksums match between the primary and secondary FortiGates:
# diagnose sys ha checksum cluster
is_manage_primary()=1, is_root_primary()=1
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
root: af a6 48 c5 c2 9a 8b 81 a5 53 fb 27 e9 ae 01 6a
all: 89 1f 63 77 48 8a 30 ee 57 06 ca eb 71 e6 8e ad
checksum
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
root: af a6 48 c5 c2 9a 8b 81 a5 53 fb 27 e9 ae 01 6a
all: 89 1f 63 77 48 8a 30 ee 57 06 ca eb 71 e6 8e ad
is_manage_primary()=0, is_root_primary()=0
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
root: af a6 48 c5 c2 9a 8b 81 a5 53 fb 27 e9 ae 01 6a
all: 89 1f 63 77 48 8a 30 ee 57 06 ca eb 71 e6 8e ad
checksum
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
root: af a6 48 c5 c2 9a 8b 81 a5 53 fb 27 e9 ae 01 6a
all: 89 1f 63 77 48 8a 30 ee 57 06 ca eb 71 e6 8e ad
If all of the cluster members have identical checksums, then their configurations are synchronized. If the checksums
are not the same, wait for a few minutes, then repeat the command. Some parts of the configuration might take a
significant amount of time to synchronize (tens of minutes).
After the device configurations are synchronized, you can connect the rest of the traffic interfaces. Making these
connections will disrupt traffic as cables are disconnected and reconnected.
Switches must be used between the cluster and the ISPs, and between the cluster and the internal network, as shown in
the topology diagram.
The HA Status dashboard widget shows the synchronization status. Hover over the host names of each FortiGate in the
widget to verify that they are synchronized and have the same checksum.
To view more information about the cluster status, including the number of sessions passing through the cluster
members, go to System > HA.
See Check HA sync status on page 850 for more information.
Results
Testing HA failover
All traffic should currently be flowing through the primary FortiGate. If it becomes unavailable, traffic fails over to the
secondary FortiGate. When the primary FortiGate rejoins the cluster, the secondary FortiGate continues to operate as
the primary FortiGate.
To test this, ping a reliable IP address from a computer in the internal network, and then power off the primary FortiGate.
There will be a momentary pause in the ping results until traffic diverts to the backup FortiGate, allowing the ping traffic to
continue:
64 bytes from 184.25.76.114: icmp_seq=69 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=70 ttl=52 time=8.822 ms\
64 bytes from 184.25.76.114: icmp_seq=74 ttl=52 time=8.901 ms\
Request timeout for icmp_seq 75\
64 bytes from 184.25.76.114: icmp_seq=76 ttl=52 time=8.860 ms\
64 bytes from 184.25.76.114: icmp_seq=77 ttl=52 time=9.174 ms\
64 bytes from 184.25.76.114: icmp_seq=83 ttl=52 time=8.639 ms}
If you are using port monitoring, you can also unplug the primary FortiGate's internet facing
interface to test failover.
After the secondary FortiGate becomes the primary, you can log into the cluster using the same IP address as before the
fail over. If the primary FortiGate is powered off, you will be logged into the backup FortiGate. Check the host name to
verify what device you have logged into. The FortiGate continues to operate in HA mode, and if you restart the primary
FortiGate, it will rejoin the cluster and act as the backup FortiGate. Traffic is not disrupted when the restarted FortiGate
rejoins the cluster.
You can also use the CLI to force an HA failover. See Force HA failover for testing and demonstrations on page 874 for
information.
To test a failover of the redundant internet configuration, you need to simulate a failed internet connection to one of the
ports. You can do this by disconnecting power from the wan1 switch, or by disconnecting the wan1 interfaces of both
FortiGates from ISP1.
After disconnecting, verify that users still have internet access
l Go to Dashboard > Network, and expand the SD-WAN widget. The Upload and Download columns for wan1 show
that traffic is not going through that interface.
l Go to Network > SD-WAN Zones. The Bandwidth, Volume, and Sessions tabs show that traffic is entirely diverted to
wan2.
Users on the network should not notice the wan1 failure. If you are using the wan1 gateway IP address to connect to the
administrator dashboard, it will appear as though you are still connecting through wan1.
After verifying a successful failover, reestablish the connection to ISP1.
In this SD-WAN configuration, two FortiGates in an active-passive (A-P) HA pair are used to provide hardware
redundancy. Instead of using external switches to provide a mesh network connection to the ISP routers, the FortiGates
use their built-in hardware switches to connect to the ISP routers.
Only FortiGate models that have hardware switches can be used for this solution. Ports in a
software switch are not in a forwarding state when a FortiGate is acting as a secondary device
in a A-P cluster.
In this topology:
l Two hardware switches are created, HD_SW1 and HD_SW2.
l HD_SW1 is used to connect to ISP 1 Router and includes the internal1 and internal2 ports.
l HD_SW2 is used to connect to ISP 2 Router and includes the internal3 and internal4 ports.
l Another interface on each device is used as the HA heartbeat interface, connecting the two FortiGates in HA.
The FortiGates create two hardware switches to connect to ISP 1 and ISP2. When FGT_A is the primary device, it
reaches ISP 1 on internal1 in HD_SW1 and ISP 2 on internal4 in HD_SW2. When FGT_B is the primary device, it
reaches ISP 1 on internal2 in HD_SW1 and ISP 2 on internal3 on HD_SW2.
HA failover
This is not a standard HA configuration with external switches. In the case of a device failure, one of the ISPs will no
longer be available because the switch that is connected to it will be down.
For example, If FGT_A loses power, HA failover will occur and FGT_B will become the primary unit. Its connection to
internal2 on HD_SW1 will also be down, so it will be unable to connect to ISP 1. Its SD-WAN SLAs will be broken, and
traffic will only be routed through ISP 2.
If a hardware switch or switch interface is down, or the ISP router is down, the SD-WAN can detect the broken SLA and
continue routing to the other ISP.
For example, if FGT_A is the primary unit, and ISP 2 Router becomes unreachable, the SLA health checks on SD-WAN
will detect the broken SLA and cause traffic to stop routing to ISP 2.
Configuration
1. Configure two FortiGates with internal switches in an A-P HA cluster (follow the steps in HA active-passive cluster
setup on page 844), starting by connecting the heartbeat interface.
2. When the HA cluster is up, connect to the primary FortiGate's GUI.
3. Remove the existing interface members from the default hardware switch:
a. Go to Network > Interfaces.
b. In the LAN section, double-click the internal interface to edit it.
c. In Interface Members, remove all of the interfaces.
d. Click OK.
4. Configure the hardware switch interfaces for the two ISPs:
a. Go to Network > Interfaces and click Create New > Interface.
b. Enter a name (HD_SW1).
c. Set Type to Hardware Switch.
d. In Interface Members, add two interfaces (internal1 and internal2).
e. Set IP/Netmask to 192.168.1.2/24.
g. Click OK.
h. Repeat these steps to create a second hardware switch interface (HD_SW2) with two interface members
(internal3 and internal4) and IP/Netmask set to 192.168.3.2/24.
To configure SD-WAN:
1. On the primary FortiGate, go to Network > SD-WAN Zones and click Create New > SD-WAN Member.
2. In the Interface dropdown, select HD_SW1.
3. Leave SD-WAN Zone set to virtual-wan-link.
4. Enter the Gateway address 192.168.1.1.
5. Click OK.
6. Repeat these steps to add the second interface (HD_SW2) with the gateway 192.168.3.1.
7. Click Apply.
Example 1
In this example, we create a template with two SD-WAN members configured without assigned interfaces that are used
in a performance SLA and SD-WAN rule. The template can be used to configure new devices, as in Example 2 on page
730. Interfaces are then assigned to the members, and the configuration becomes active.
The members are disabled until interfaces are configured, but can still be used in performance SLAs and SD-WAN
rules.
4. Click OK.
4. Click OK.
4. Click OK.
5. Repeat the above steps to assign an interface to the second member.
The SD-WAN configuration can now be used in as a template for new spokes, as in Example 2 on page 730.
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
Example 2
In this example, the configuration from Example 1 is copied onto a new FortiGate.
1. Optionally, change the console screen paging setting. See Screen paging on page 31 for details.
2. Open the CLI console.
3. If necessary, click Clear console to empty the console.
4. Enter the following command:
show system sdwan
5. Either click Download and open the file in a text editor, or click Copy to clipboard and paste the content into a text
editor.
6. Edit the CLI configuration as necessary. For example, the first line that shows the show command should be
deleted, and the default health checks can be removed.
7. If required, save the CLI configuration as a text file.
4. Click OK.
5. Repeat the above steps to assign an interface to the second member.
The following instructions use PuTTy. The steps may vary in other terminal emulators.
1. Connect to the FortiGate. See Connecting to the CLI on page 23 for details.
2. Enter the following command:
show system sdwan
3. Select the output, press Ctrl + c to copy it, and then paste it into a text editor.
4. Edit the CLI configuration as necessary. For example, the default health checks can be removed.
5. If required, save the CLI configuration as a text file.
If no SD-WAN zone is specified, members are added to the default virtual-wan-link zone.
In this example, you configure a connection to a new cloud deployment that has some remote servers. SD-WAN is used
to steer traffic through the required overlay tunnel.
The on-premise FortiGate has two internet connections, each with a single VPN connection. The two VPN gateways are
configured on the cloud for redundancy, one terminating at the FortiGate-VM, and the other at the native AWS VPN
Gateway.
This example uses AWS as the Infrastructure as a Service (IaaS) provider, but the same configuration can also apply to
other services. A full mesh VPN setup is not shown, but can be added later if required.
To connect to the servers that are behind the cloud FortiGate-VM, virtual IP addresses (VIPs) are configured on port2 to
map to the servers:
l VPN traffic terminating on port1 is routed to the VIP on port2 to access the web servers.
l VPN traffic terminating on the VPN gateway accesses the VIPs on port2 directly.
There are four major steps to configure this setup:
1. Configuring the VPN overlay between the HQ FortiGate and cloud FortiGate-VM on page 733
2. Configuring the VPN overlay between the HQ FortiGate and AWS native VPN gateway on page 738
3. Configuring the VIP to access the remote servers on page 741
4. Configuring the SD-WAN to steer traffic between the overlays on page 744
After the configuration is complete, verify the traffic to ensure that the configuration is working as expected, see Verifying
the traffic on page 749.
Configuring the VPN overlay between the HQ FortiGate and cloud FortiGate-VM
1. Go to Policy & Objects > Addresses and click Create New > Address.
2. Set Name to local_subnet_10_0_2_0.
3. Set IP/Netmask to 10.0.2.0/24.
4. Click OK.
4. Click Next.
5. Configure Network settings:
Interface port1
Version 1
Mode Aggressive
This setting allows the peer ID to be specified.
Peer ID IaaS
The other end of the tunnel needs to have its local ID set to IaaS.
Name Ent_Core
9. Click OK.
1. Go to Network > Interfaces and edit the Core_Dialup interface under port1.
2. Set IP to 172.16.200.1.
3. Set Remote IP/Netmask to 172.16.200.2 255.255.255.0. This is where remote health check traffic will come from.
4. Enable Administrative access for HTTPS, PING, and SSH.
5. Click OK.
4. Click OK.
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. Configure the following:
Name Core_Dialup-to-port2
Source all
Destination local_subnet_10_0_2_0
Schedule always
Service ALL
Action ACCEPT
1. Go to Policy & Objects > Addresses and click Create New > Address.
2. Set Name to remote_subnet_10_0_2_0.
3. Set IP/Netmask to 10.0.2.0/24.
4. Click OK.
IP Address 100.21.29.17
Interface port5
Version 1
Mode Aggressive
This setting allows the peer ID to be specified.
7. Leave the default Phase 1 Proposal settings, except set Local ID to IaaS.
8. Disable XAUTH.
9. Configure the Phase 2 Selector settings:
Name FGT_AWS_Tun
1. Go to Network > Interfaces and edit the FGT_AWS_Tun interface under port5.
2. Set IP to 172.16.200.2.
3. Set Remote IP/Netmask to 172.16.200.1 255.255.255.0.
4. Enable Administrative access for HTTPS, PING, and SSH.
5. Click OK.
Routing is defined when creating the SD-WAN interface. The firewall policy is created after the
SD-WAN interface is defined.
Configuring the VPN overlay between the HQ FortiGate and AWS native VPN
gateway
This example uses static routing. It is assumed that the AWS VPN Gateway is already configured, and that proper
routing is applied on the corresponding subnet.
See Creating routing tables and associate subnets in the AWS Administration Guide for configuration details.
1. Go to Virtual Private Network (VPN) > Customer Gateways to confirm that the customer gateway defines the
FortiGate IP address as its Gateway IP address, in this case 34.66.121.231.
2. Go to Virtual Private Network (VPN) > Virtual Private Gateways to confirm that a virtual private gateway (VPG) has
been created. In this case it is attached to the Cloud_onRamp VPC that contains the FortiGate and servers.
3. Go to Virtual Private Network (VPN) > Site-to-Site VPN Connections to confirm that site-to-site VPN connections
have been created and attached to the customer gateway and virtual private gateway.
If Routing Options is Static, the IP prefix of the remote subnet on the HQ FortiGate (10.100.88.0) is entered here.
AWS site-to-site VPN always creates two VPN tunnels for redundancy. In this example, only Tunnel 1 is used.
4. Click Download Configuration to download the FortiGate's tunnel configurations. The configuration can be referred
to when configuring the FortiGate VPN.
5. The new VPG is attached to your VPC, but to successfully route traffic to the VPG, proper routing must be defined.
Go to Virtual Private Cloud > Subnets, select the Cloud-OnRamp-VPN, and select the Route Table tab to verify that
there are at least two routes to send traffic over the VPG.
l 169.254.0.0/24 defines the tunnel IP address. Health check traffic originating from the FortiGate will come from
this IP range.
l 10.100.0.0/16 defines the remote subnet from the HQ FortiGate.
6. On the cloud FortiGate-VM EC2 instances, ensure that port1 and port2 both have Source/Dest. Check set to false.
This allows the FortiGate to accept and route traffic to and from a different network.
If you launched the instance from the AWS marketplace, this setting defaults to true.
The new route must have the same Administrative Distance as the route that was created for traffic through the
Core_Dialup tunnel to ensure that both routes are added to the routing table (see To configure a route to the remote
subnet through the tunnel).
The Gateway Address is arbitrarily set to 10.0.2.1. The VPG does not have an IP address, but the address defined
here allows the FortiGate to route traffic out of port2, while AWS routes the traffic based on its routing table.
5. Click OK.
6. Go to Network > Static Routes to view the configured static routes:
7. If Optimal dashboards is selected, go to Dashboard > Network and expand the Routing widget to view the routing
table.
If Comprehensive dashboards is selected, go to Dashboard > Routing Monitor and select Static & Dynamic in the
widget toolbar to view the routing table:
IP Address 34.210.19.225
This address is taken from the downloaded AWS configuration file.
Interface port1
Version 1
Mode Main
7. Configure the Phase 1 Proposal settings using information from the downloaded AWS configuration file.
8. Disable XAUTH.
9. Configure the Phase 2 Selector settings:
Name AWS_VPG
1. Go to Network > Interfaces and edit the AWS_VPG interface under port1.
2. Set IP to 169.254.55.154.
3. Set Remote IP/Netmask to 169.254.55.153 255.255.255.0.
4. Enable Administrative access for HTTPS and PING.
5. Click OK.
Routing is defined when creating the SD-WAN interface. The firewall policy is created after the
SD-WAN interface is defined.
VIPs, interface IP addresses, and policies are created on the cloud FortiGate-VM to allow access to the remote servers.
1. On the FortiGate EC2 instance, edit the Elastic Network Interface that corresponds to port2. In this example,
Network Interface eth1.
2. Go to Actions > Manage IP Addresses.
3. Add two private IP address in the 10.0.2.0/24 subnet.
These address will be used in the VIPs on the FortiGate. This ensures that traffic to these IP addresses is routed to
the FortiGate by AWS.
1. Go to Policy & Objects > Virtual IPs and click Create New > Virtual IP.
2. Configure the following:
Name VIP-HTTP
Interface port2
3. Click OK.
4. Create a second VIP for the FTP server with the following settings:
Name VIP-FTP
Interface port2
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. Configure the following:
Name To-WebServer
Source all
Destination VIP-HTTP
Schedule always
Service ALL
Action ACCEPT
NAT Enabled
5. Create a second policy for the FTP VIP with the following settings:
Name To-FTP
Source all
Destination VIP-FTP
Schedule always
Service ALL
Action ACCEPT
NAT Enabled
6. Click OK.
Configure the HQ FortiGate to use two overlay tunnels for SD-WAN, steering HTTPS and HTTP traffic through the FGT_
AWS_Tun tunnel, and SSH and FTP throguh the AWS_VPG tunnel.
1. Add SD-WAN member interfaces
2. Configure a route to the remote network
3. Configure firewall policies
4. Configure a health check
5. Configure SD-WAN rules
1. Go to Network > SD-WAN Zones and click Create New > SD-WAN Member.
2. Set Interface to AWS_VPG then click OK.
4. Click OK.
Individual routes to each tunnel are automatically added to the routing table with the same distance:
To configure firewall policies to allow traffic from the internal subnet to SD-WAN:
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. Configure the following:
Name ISFW-to-IaaS
Source all
Destination all
Schedule always
Service ALL
Action ACCEPT
NAT Enabled
As you are accessing the servers on the 10.0.2.0/24 subnet, it is preferable to use the FortiGate port2 interface as the
ping server for detection. This ensures that, if the gateway is not reachable in either tunnel, its routes are brought down
and traffic continues on the other tunnel.
1. Go to Network > Performance SLA and click Create New.
2. Configure the following:
Name ping_AWS_Gateway
Protocol Ping
Server 10.0.2.10
Participants Specify
Add AWS_VPG and FGT_AWS_Tun as participants.
3. Click OK.
Health check probes originate from the VPN interface's IP address. This is why the phase2 selectors are configured
with Local Address set to all.
HTTPS and HTTP traffic is steered to the FGT_AWS_Tun tunnel, and SSH and FTP traffic is steered to the AWS_VPG
tunnel. The Manual algorithm is used in this example.
1. Go to Network > SD-WAN Rules and click Create New.
2. Configure the following:
Name http-to-FGT_AWS_Tun
Address remote_subnet_10_0_2_0
Protocol TCP
Port range 80 - 80
3. Click OK.
4. Create other SD-WAN rules as required:
To verify that pings are sent across the IPsec VPN tunnels
1. Go to Network > Performance SLA and select Packet Loss and the ping_AWS_Gateway SLA:
1. Run the following CLI command to verify that HTTPS and HTTP traffic destined for the Web server at 10.0.2.20
uses FGT_AWS_Tun:
# diagnose sys session filter dst 10.0.2.20
# diagnose sys session list
2. Run the following CLI command to verify that SSH and FTP traffic destined for the FTP server at 10.0.2.21 uses
AWS_VPG:
# diagnose sys session filter dst 10.0.2.20
# diagnose sys session list
On the cloud FortiGate-VM, disable the firewall policy allowing Core_Dialup to port2.
1. Health-checks through the FGT_AWS_Tun tunnel fail:
a. Go to Network > Performance SLA and select Packet Loss and the ping_AWS_Gateway SLA:
This topology diagram shows an overview of the network that is configured in this example:
Datacenter configuration
Dial-up, or dynamic, VPNs are used to facilitate zero touch provisioning of new spokes to establish VPN connections to
the hub FortiGate.
The exchange-interface-ip option is enabled to allow the exchange of IPsec interface IP addresses. This allows a
point to multipoint connection to the hub FortiGate.
The add-route option is disabled to allow multiple dial-up tunnels to be established to the same host that is advertising
the same network. This dynamic network discovery is facilitated by the BGP configuration; see Configure BGP on page
759 for details.
Wildcard security associations are defined for the phase2 interface because routing is used to determine if traffic is
subject to encryption and transmission through the IPsec VPN tunnel. The phase1 interface name must be 11 characters
or less.
A dynamic VPN configuration must be defined for each interface that connects to the internet.
To establish the BGP session, IP addresses must be assigned to the tunnel interfaces that BGP will use to peer.
The hub IP address is set to the address that the tunnels connect to. The remote IP address is set to highest unused IP
address that is part of the tunnel network. This establishes two connected routes directly back to the branch FortiGate in
the hub FortiGate's routing table.
Ping is allowed on the virtual interface to confirm that a point to point tunnel has been established between the hub and
branch FortiGates.
A loopback interface must be defined on the hub FortiGate to be used as a common probe point for the FortiGates that
are using SD-WAN. The FortiGates send a probe packet from each of their SD-WAN member interfaces so that they can
determine the best route according to their policies. Ping is allowed so that it can be used for measurements.
Configure BGP
Firewall policies
Centralized access is controlled from the hub FortiGate using Firewall policies. In addition to layer three and four
inspection, security policies can be used in the policies for layer seven traffic inspection.
It is best practice to only allow the networks and services that are required for communication through the firewall. The
following rules are the minimum that must be configured to allow SD-WAN to function:
For this example, a simple policy that allows all traffic is configured.
If there is a temporary loss of connectivity to the branch routes, it is best practice to send the traffic that is destined for
those networks into a black hole until connectivity is restored.
Branch configuration
The branch must define its local tunnel interface IP address, and the remote tunnel interface IP address of the
datacenter FortiGate, to establish the point to multipoint VPN.
Configure BGP
BGP enables learning dynamic routes from the datacenter. The BGP configuration is normal, with the definition of the
datacenter FortiGate tunnel IP addresses set as BGP peers.
Routes that have the same network mask, administrative distance, priority, and AS length are automatically considered
for SD-WAN when the interfaces that those routes are on are added to the SD-WAN interface group.
In order to facilitate the fastest route failovers, configure the following timers to their lowest levels: scan-time,
advertisement-interval, keep-alive-timer, and holdtime-timer.
The distance-external option might need to be configured if you need routes that are learned from BGP to take
precedence over static routes.
Configure SD-WAN
SD-WAN configuration is required to load balance based on the quality of the links. It can be configured to select the best
link based on characteristics such as jitter, packet loss, and latency. A policy route is created by the FortiGate to select
the best link based on the defined criteria.
For SD-WAN interfaces, or members, the peer is defined to reference the BGP neighbor that is tied to that specific
interface.
The health check is the ping server that gathers the link characteristics used for link selection. It is recommended that the
minimum failtime be set to 2.
The service definition defines the criteria for the policy routes. It can match based on the following characteristics:
l Protocol
l Destination Address
l Source Address
l Identity Based Group
Firewall configuration
Centralized access is controlled from the hub FortiGate using Firewall policies. In addition to layer three and four
inspection, security policies can be used in the policies for layer seven traffic inspection.
It is best practice to only allow the networks and services that are required for communication through the firewall. The
following rules are the minimum that must be configured to allow SD-WAN to function:
<internal <virtual wan <branch <datacenter Accept Always <allowed Allow traffic
interface> link> networks> networks> services> from branch
to datacenter
For this example, a simple policy that allows all traffic is configured.
Validation
The following commands can be used to validate the connections on the datacenter and branches.
Datacenter
Routing table:
VPN establishment:
Branch
SD-WAN validation:
Routing table:
VPN establishment:
Troubleshooting
If VoIP calls are not failing over properly, try removing the SIP Application Layer Gateway.
Dynamic definitions of SD-WAN routes alleviate administrators from needing to know the destination of the traffic that is
being load balanced, which, in an environment where routes are constantly added and removed, required a significant
amount of administrative overhead.
The FortiGate can be configured to apply a route map to a BGP neighbor, and tag the routes that are learned from that
neighbor with the set-route-tag command. After those routes are assigned a tag ID in the route map, the ID can be
referenced in the SD-WAN rule.
edit 1
set match-origin igp
set set-route-tag 12
next
edit 2
set match-ip-address "pf-all-in"
set set-route-tag 11
next
end
next
end
Datacenter FortiGates should be configured to establish an OSPF neighbor relationship with the internal core router.
This allows the dynamic redistribution of routes to the branches that are receiving updates from the datacenter
FortiGates.
To ensure the fastest failover with OSPF, the following timers are set to their minimum levels: spf-timers, hello-
interval, dead-interval.
Bi-directional forwarding is enabled to allow the fastest convergence time if there is a failure with a peering neighbor.
To configure OSPF:
edit 10.10.10.10
next
end
config ospf-interface
edit "port5"
set interface "port5"
set dead-interval 3
set hello-interval 1
set bfd enable
next
end
config network
edit 1
set prefix 192.168.100.0 255.255.255.252
set area 10.10.10.10
next
end
config redistribute "connected"
set status enable
set routemap "redistribute-branch-tunnel"
end
config redistribute "static"
end
config redistribute "rip"
end
config redistribute "bgp"
set status enable
set routemap "redistribute-branch-networks"
end
config redistribute "isis"
end
end
Troubleshooting SD-WAN
You can check the destination interface in Dashboard > FortiView Sessions in order to see which port the traffic is being
forwarded to.
The example below demonstrates a source-based load-balance between two SD-WAN members:
This topic lists the SD-WAN related logs and explains when the logs will be triggered.
l When health-check has an SLA target and detects SLA changes, and changes to fail:
5: date=2019-04-11 time=11:48:39 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1555008519816639290 logdesc="Virtual WAN Link status"
msg="SD-WAN Health Check(ping) SLA(1): number of pass members changes from 2 to 1."
l When health-check has an SLA target and detects SLA changes, and changes to pass:
2: date=2019-04-11 time=11:49:46 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1555008586149038471 logdesc="Virtual WAN Link status"
msg="SD-WAN Health Check(ping) SLA(1): number of pass members changes from 1 to 2."
SD-WAN calculates a link's session/bandwidth over/under its ratio and stops/resumes traffic:
l When SD-WAN calculates a link's session/bandwidth over its configured ratio and stops forwarding traffic:
3: date=2019-04-10 time=17:15:40 logid="0100022924" type="event" subtype="system"
level="notice" vd="root" eventtime=1554941740185866628 logdesc="Virtual WAN Link volume
status" interface="R160" msg="The member(3) enters into conservative status with limited
ablity to receive new sessions for too much traffic."
l When SD-WAN calculates a link's session/bandwidth according to its ratio and resumes forwarding traffic:
1: date=2019-04-10 time=17:20:39 logid="0100022924" type="event" subtype="system"
level="notice" vd="root" eventtime=1554942040196041728 logdesc="Virtual WAN Link volume
status" interface="R160" msg="The member(3) resume normal status to receive new sessions
for internal adjustment."
l When the SLA mode service rule's SLA qualified member changes. In this example R150 fails the SLA check, but is
still alive:
14: date=2019-03-23 time=17:44:12 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553388252 logdesc="Virtual WAN Link status"
msg="Service2() prioritized by SLA will be redirected in seq-num order 2(R160) 1(R150)."
15: date=2019-03-23 time=17:44:12 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553388252 logdesc="Virtual WAN Link status"
interface="R150" msg="The member1(R150) SLA order changed from 1 to 2. "
16: date=2019-03-23 time=17:44:12 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553388252 logdesc="Virtual WAN Link status"
interface="R160" msg="The member2(R160) SLA order changed from 2 to 1. "
l When the SLA mode service rule's SLA qualified member changes. In this example R150 changes from fail to pass:
1: date=2019-03-23 time=17:46:05 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553388365 logdesc="Virtual WAN Link status"
msg="Service2() prioritized by SLA will be redirected in seq-num order 1(R150) 2(R160)."
2: date=2019-03-23 time=17:46:05 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553388365 logdesc="Virtual WAN Link status"
interface="R160" msg="The member2(R160) SLA order changed from 1 to 2. "
3: date=2019-03-23 time=17:46:05 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553388365 logdesc="Virtual WAN Link status"
interface="R150" msg="The member1(R150) SLA order changed from 2 to 1. "
l When priority mode service rule member's link status changes. In this example R150 changes to better than R160,
and both are still alive:
1: date=2019-03-23 time=17:33:23 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553387603 logdesc="Virtual WAN Link status"
msg="Service2() prioritized by packet-loss will be redirected in seq-num order 1(R150) 2
(R160)."
2: date=2019-03-23 time=17:33:23 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553387603 logdesc="Virtual WAN Link status"
interface="R160" msg="The member2(R160) link quality packet-loss order changed from 1 to
2. "
3: date=2019-03-23 time=17:33:23 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553387603 logdesc="Virtual WAN Link status"
interface="R150" msg="The member1(R150) link quality packet-loss order changed from 2 to
1. "
l When priority mode service rule member's link status changes. In this example R160 changes to better than R150,
and both are still alive:
l When SD-WAN member passes the health-check again, it will resume forwarding logs:
2: date=2019-04-11 time=13:33:36 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1555014815914643626 logdesc="Virtual WAN Link status"
interface="R160" msg="The member2(R160) link is available. Start forwarding traffic. "
l When load-balance mode service rule's SLA qualified member changes. In this example R150 changes to not meet
SLA:
2: date=2019-04-11 time=14:11:16 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1555017075926510687 logdesc="Virtual WAN Link status"
msg="Service1(rule2) will be load balanced among members 2(R160) with available
routing."
3: date=2019-04-11 time=14:11:16 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1555017075926508676 logdesc="Virtual WAN Link status"
interface="R150" msg="The member1(R150) SLA order changed from 1 to 2. "
4: date=2019-04-11 time=14:11:16 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1555017075926507182 logdesc="Virtual WAN Link status"
interface="R160" msg="The member2(R160) SLA order changed from 2 to 1. "
l When load-balance mode service rule's SLA qualified member changes. In this example R150 changes to meet
SLA:
1: date=2019-04-11 time=14:33:23 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1555017075926510668 logdesc="Virtual WAN Link status"
msg="Service1(rule2) will be load balanced among members 1(R150) 2(R160) with available
routing."
2: date=2019-03-23 time=14:33:23 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553387603592651068 logdesc="Virtual WAN Link status"
interface="R160" msg="The member2(R160) link quality packet-loss order changed from 1 to
2. "
3: date=2019-03-23 time=14:33:23 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553387603592651068 logdesc="Virtual WAN Link status"
l When SLA fails, SLA link status logs will be generated with interval sla-fail-log-period:
7: date=2019-03-23 time=17:45:54 logid="0100022925" type="event" subtype="system"
level="notice" vd="root" eventtime=1553388352 logdesc="Link monitor SLA information"
name="test" interface="R150" status="up" msg="Latency: 0.016, jitter: 0.002, packet
loss: 21.000%, inbandwidth: 0Mbps, outbandwidth: 200Mbps, bibandwidth: 200Mbps, sla_map:
0x0"
l When SLA passes, SLA link status logs will be generated with interval sla-pass-log-period:
5: date=2019-03-23 time=17:46:05 logid="0100022925" type="event" subtype="system"
level="information" vd="root" eventtime=1553388363 logdesc="Link monitor SLA
information" name="test" interface="R150" status="up" msg="Latency: 0.017, jitter:
0.003, packet loss: 0.000%, inbandwidth: 0Mbps, outbandwidth: 200Mbps, bibandwidth:
200Mbps, sla_map: 0x1"
This topic lists the SD-WAN related diagnose commands and related output.
33
Member(2): interface: port15, gateway: 10.100.1.5 2004:10:100:1::5, priority: 0, weight:
66
l You can also use the diagnose netlink dstmac list command to check if you are over the limit.
FGT # diagnose netlink dstmac list port13
dev=port13 mac=08:5b:0e:ca:94:9d rx_tcp_mss=0 tx_tcp_mss=0 egress_overspill_
threshold=51200 egress_bytes=103710 egress_over_bps=1 ingress_overspill_
threshold=38400 ingress_bytes=76816 ingress_over_bps=1 sampler_rate=0
To check IPsec aggregate interface when SD-WAN uses the per-packet distribution feature:
To check BGP learned routes and determine if they are used in SD-WAN service:
The bandwidth measuring tool is used to detect true upload and download speeds. Bandwidth tests can be run on
demand or automated using a script, and can be useful when configuring SD-WAN SLA and rules to balance SD-WAN
traffic.
The speed test tool requires a valid license, either with the 360 Protection Bundle in 6.2, or an SD-WAN Bandwidth
Monitoring Service license.
The speed test tool is compatible with iperf3.6 with SSL support. It can test the upload bandwidth to the FortiGate Cloud
speed test service. It can initiate the server connection and send download requests to the server. The tool can be run up
to 10 times a day .
FortiGate downloads the speed test server list. The list expires after 24 hours. One of the speed test servers is selected,
based on user input. The speed test runs, testing upload and download speeds. The test results are shown in the
command terminal.
You can run the speed test without specifying a server. The system will automatically choose one server from the list and
run the speed test.
# execute speed-test auto
The license is valid to run speed test.
Speed test quota for 2/1 is 9
current vdom=root
Run in uploading mode.
Connecting to host 35.230.2.124, port 5206
[ 16] local 172.16.78.185 port 2475 connected to 35.230.2.124 port 5206
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 16] 0.00-1.01 sec 11.0 MBytes 91.4 Mbits/sec 0 486 KBytes
[ 16] 1.01-2.00 sec 11.6 MBytes 98.4 Mbits/sec 0 790 KBytes
[ 16] 2.00-3.01 sec 11.0 MBytes 91.6 Mbits/sec 15 543 KBytes
[ 16] 3.01-4.01 sec 11.2 MBytes 94.2 Mbits/sec 1 421 KBytes
[ 16] 4.01-5.01 sec 11.2 MBytes 93.5 Mbits/sec 0 461 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 16] 0.00-5.01 sec 56.1 MBytes 93.8 Mbits/sec 16 sender
[ 16] 0.00-5.06 sec 55.8 MBytes 92.6 Mbits/sec receiver
current vdom=root
Run in uploading mode.
Connecting to host 34.210.67.183, port 5205
To run the speed test on a local interface when there are multiple valid routes:
next
end
You can monitor SD-WAN health check related statistics using SNMP. The MIB file can be downloaded by going to
System > SNMP and clicking Download FortiGate MIB File.
The following OIDs can be monitored:
Example
This example shows a SD-WAN health check configuration and its collected statistics.
next
edit 2
set interface "MPLS"
set zone "SD-Zone2"
set cost 20
next
edit 3
set interface "port2"
next
end
config health-check
edit "pingserver"
set server "8.8.8.8"
set sla-fail-log-period 10
set sla-pass-log-period 20
set members 2 1 3
config sla
edit 1
set link-cost-factor jitter packet-loss
set packetloss-threshold 2
next
end
next
end
end
fgVWLHealthCheckLinkID .1.3.6.1.4.1.12356.101.4.9.2.1.1 1 2 3
fgVWLHealthCheckLinkSeq .1.3.6.1.4.1.12356.101.4.9.2.1.3 2 1 3
fgVWLHealthCheckLinkState .1.3.6.1.4.1.12356.101.4.9.2.1.4 0 0 0
fgVWLHealthCheckLinkPacketLoss .1.3.6.1.4.1.12356.101.4.9.2.1.9 0 0 0
This topic contains information about FortiGate administration and system configuration that you can do after installing
the FortiGate in your network.
Administrators
By default, FortiGate has an administrator account with the username admin and no password. See Administrators on
page 786 for more information.
Administrator profiles
An administrator profile defines what the administrator can see and do on the FortiGate. See Administrator profiles on
page 786 for more information.
Password policy
Set up a password policy to enforce password criteria and change frequency. See Password policy on page 791 for
more information.
Interfaces
Physical and virtual interface allow traffic to flow between internal networks, and between the internet and internal
networks. See Interfaces on page 385 for more information.
SNMP
The simple network management protocol (SNMP) allows you to monitor hardware on your network. See SNMP on page
894 for more information.
DHCP server
You can configure one or more DHCP servers on any FortiGate interface. See DHCP server on page 491 for more
information.
VDOM
You can use virtual domains (VDOMs) to divide a FortiGate into multiple virtual devices that function independently. See
Virtual Domains on page 818 for more information.
High availability
You can configure multiple FortiGate devices, including private and public cloud VMs, in HA mode. See High Availability
on page 840 for more information.
Certificates
You can manage certificates on the FortiGate. See Certificates on page 926 for more information.
Operating modes
A FortiGate or VDOM (in multi-vdom mode) can operate in either NAT/route mode or transparent mode.
NAT/route mode
The FortiGate or VDOM is installed as a gateway or router between multiple networks, such as a private network and the
internet. One function of NAT/route mode is to allow the FortiGate to hide the IP addresses on the private network using
NAT. NAT/route mode can also be used to connect to multiple ISPs in an SD-WAN setup, and to route traffic between
different networks. .
By default, new VDOMs are set to NAT/route operation mode.
See Configure VDOM-A on page 827 for more information.
Transparent mode
The FortiGate or VDOM operates in layer 2 to forward traffic between network devices such as routers, firewalls, and
switches. For example. it can be installed inline between a router and a switch to perform security scanning without
changing the network topology or modifying the IP addresses. When you add a FortiGate that is in transparent mode to a
network, it only needs to be provided with a management IP address in order to access the device. It is recommended
that a dedicated interface is used to connect to the management network in transparent mode.
The following topology is an example of a transparent mode FortiGate inserted inline between a router and a switch:
Using transparent mode VDOMs is recommended when multiple VLANs pass through the
FortiGate. Otherwise, they must be separated into different forwarding domains within the
same VDOM.
Changing modes
The following is a sample configuration for changing from NAT/route operation mode to transparent operation mode in
the CLI:
config system settings
set opmode transparent
set manageip <IP_address>
set gateway <gateway_address>
end
The gateway setting is optional. However, once the operation mode is changed from
NAT/route to transparent, the gateway configuration is found under the static router settings:
config router static
edit <seq-num>
set gateway <IP_address>
next
end
The following is a sample configuration for changing from transparent operation to NAT/route operation mode in the CLI:
config system settings
set opmode nat
set ip <IP_address>
set device <interface>
set gateway <gateway_address>
end
The IP and device settings are mandatory. Once the operation mode is changed from
transparent to NAT/route, the IP address configuration is found under the corresponding
interface settings:
config system interface
edit <interface>
set ip <IP_address>
next
end
The gateway setting is optional. However, once the operation mode is changed, the gateway
configuration is found under the static router settings:
config router static
edit <seq-num>
set gateway <IP_address>
device <interface>
next
end
Administrators
By default, FortiGate has an administrator account with the username admin and no password. To prevent unauthorized
access to the FortiGate, this account must be protected with a password. Additional administrators can be added for
various functions, each with a unique username, password, and set of access privileges.
The following topics provide information about administrators:
l Administrator profiles on page 786
l Add a local administrator on page 788
l Remote authentication for administrators on page 789
l Password policy on page 791
l Admin profile option for diagnose access on page 792
l SSO administrators on page 793
Administrator profiles
Administrator profiles define what the administrator can do when logged into the FortiGate. When you set up an
administrator account, you also assign an administrator profile which dictates what the administrator sees. Depending
on the nature of the administrator’s work, access level or seniority, you can allow them to view and configure as much or
as little as is required.
By default, the FortiGate has an admin administrator account that uses the super_admin profile.
super_admin profile
This profile has access to all components of FortiOS, including the ability to add and remove other system
administrators. For certain administrative functions, such as backing up and restoring the configuration, super_admin
access is required. To ensure that there is always a method to administer the FortiGate, the super_admin profile can't be
deleted or modified.
The super_admin profile is used by the default admin account. It is recommended that you add a password and rename
this account once you have set up your FortiGate. In order to rename the default account, a second admin account is
required.
l Access permissions.
4. Select OK.
Edit profiles
Delete profiles
By default, FortiGate has one super admin named admin. You can create more administrator accounts with different
privileges.
Do not use the characters < > ( ) # " ' in the administrator username.
Using these characters in an administrator username might have a cross site scripting
(XSS) vulnerability.
Administrators can use remote authentication, such as LDAP, to connect to the FortiGate.
Setting up remote authentication for administrators includes the following steps:
1. Configure the LDAP server on page 789
2. Add the LDAP server to a user group on page 789
3. Configure the administrator account on page 790
1. Go to User & Authentication > LDAP Servers and select Create New.
2. Enter the server Name, Server IP address or Name.
3. Enter the Common Name Identifier and Distinguished Name.
4. Set the Bind Type to Regular and enter the Username and Password.
5. Click OK.
After configuring the LDAP server, create a user group that includes that LDAP server.
1. Go to User & Authentication > User Groups and select Create New.
2. Enter a Name for the group.
After configuring the LDAP server and adding it to a user group, create a new administrator. For this administrator,
instead of entering a password, use the new user group and the wildcard option for authentication.
Administrator accounts can use different methods for authentication, including RADIUS, TACACS+, and PKI.
Password policy
Brute force password software can launch more than just dictionary attacks. It can discover common passwords where a
letter is replaced by a number. For example, if p4ssw0rd is used as a password, it can be cracked.
Using secure passwords is vital for preventing unauthorized access to your FortiGate. When changing the password,
consider the following to ensure better security:
l Do not use passwords that are obvious, such as the company name, administrator names, or other obvious words
or phrases.
l Use numbers in place of letters, for example: passw0rd.
l Administrator passwords can be up to 64 characters.
l Include a mixture of numbers, symbols, and upper and lower case letters.
l Use multiple words together, or possibly even a sentence, for example: correcthorsebatterystaple.
l Use a password generator.
l Change the password regularly and always make the new password unique and not a variation of the existing
password. for example, do not change from password to password1.
l Make note of the password and store it in a safe place away from the management computer, in case you forget it;
or ensure at least two people know the password in the event one person becomes unavailable. Alternatively, have
two different admin logins.
FortiGate allows you to create a password policy for administrators and IPsec pre-shared keys. With this policy, you can
enforce regular changes and specific criteria for a password policy, including:
l Minimum length between 8 and 64 characters.
l If the password must contain uppercase (A, B, C) and/or lowercase (a, b, c) characters.
l If the password must contain numbers (1, 2, 3).
l If the password must contain special or non-alphanumeric characters (!, @, #, $, %, ^, &, *, (, and )).
l Where the password applies (admin or IPsec or both).
l The duration of the password before a new one must be specified.
If you add a password policy or change the requirements on an existing policy, the next time that administrator logs into
the FortiGate, the administrator is prompted to update the password to meet the new requirements before proceeding to
log in.
For information about setting passwords, see Default administrator password on page 803.
The system-diagnostics command in an administrator profile can be used to control access to diagnose commands
for global and VDOM level administrators.
3. Log in as that administrator and confirm that they cannot access diagnose commands:
$ ?
config Configure object.
get Get dynamic and system information.
show Show configuration.
1. Ensure that you have successfully added your FortiToken serial number to FortiOS and that its status is Available.
2. Go to System > Administrators. Edit the admin account. This example assumes that the account is fully configured
except for two-factor authentication.
3. Enable Two-factor Authentication.
4. From the Token dropdown list, select the desired FortiToken serial number.
5. In the Email Address field, enter the administrator's email address.
6. Click OK.
For a mobile token, click Send Activation Code to send the activation code to the configured
email address. The admin uses this code to activate their mobile token. You must have
configured an email service in System > Settings to send the activation code.
The fortitoken keyword is not visible until you select fortitoken for the two-factor option.
Before you can use a new FortiToken, you may need to synchronize it due to clock drift.
SSO administrators
SSO administrators are automatically created when the FortiGate acts as a SAML service provider (SP) with SAML
Single Sign-On enabled in the Security Fabric settings.
On the system login page, an administrator can log in with their username and password against the root FortiGate
acting as the identity provider (IdP) in the Security Fabric. After the first successful login, this user is added to the
administrators table (System > Administrators under Single Sign-On Administrator). The default profile selected is based
on the SP settings (Default admin profile). See Configuring a downstream FortiGate as an SP on page 204 for more
information.
Firmware
Fortinet periodically updates the FortiGate firmware to include new features and resolve important issues. After you have
registered your FortiGate unit, firmware updates can be downloaded from the Fortinet Customer Service & Support
website.
Always back up the current configuration before installing new firmware. See Configuration
backups on page 54.
Before you install any new firmware, follow the below steps:
1. Review the Release Notes for a new firmware release.
2. Review the Supported Upgrade Paths.
3. Download a copy of the currently installed firmware, in case you need to revert to it. See Downloading a firmware
image on page 796 and Downgrading to a previous firmware version on page 799 for details.
4. Have a plan in place in case there is a critical failure, such as the FortiGate not coming back online after the update.
This could include having console access to the device (Connecting to the CLI on page 23), ensuring that you TFTP
server is working (Installing firmware from system reboot on page 800), and preparing a USB drive (Restoring from
a USB drive on page 801).
5. Backup the current configuration, including local certificates. See Configuration backups on page 54 for details.
6. Test the new firmware until you are satisfied that it applies to your configuration. See Testing a firmware version on
page 797 and Controlled upgrade on page 802 for details.
Installing new firmware without reviewing release notes or testing the firmware may result in changes to settings and
unexpected issues.
Only FortiGate admin users and administrators whose access profiles contain system read
and write privileges can change the FortiGate firmware.
FortiGates with a firmware upgrade license that are connected to FortiGuard display upgrade notifications in the setup
window, banner, and FortiGuard menu. The firmware notifications are enabled by default.
1. When you log in to FortiGate, the FortiGate Setup window includes an Upgrade firmware step. Click Begin.
2. Follow the steps in the Setup Progress, then click Review Firmware Upgrade.
Firmware images for all FortiGate units are available on the Fortinet Customer Service & Support website.
To download firmware:
1. Log into the support site with your user name and password.
2. Go to Download > Firmware Images.
A list of Release Notes is shown. If you have not already done so, download and review the Release Notes for the
firmware version that you are upgrading your FortiGate unit to.
3. Select the Download tab.
4. Navigate to the folder for the firmware version that you are upgrading to.
5. Find your device model from the list. FortiWiFi devices have file names that start with FWF.
6. Click HTTPS in the far right column to download the firmware image to your computer.
Firmware can also be downloaded using FTP, but as FTP is not an encrypted file transferring
protocol, HTTPS downloading is recommended.
Official FortiOS firmware images are signed by the Fortinet CA. The BIOS checks the validity of an image when it is
uploaded to the device. If the image is not signed by the Fortinet CA, a warning message is shown in the GUI.
Unsigned image:
Signed image:
This feature is implemented on all FortiGate F-series models and E-series models released in 2019 and later.
The integrity of firmware images downloaded from Fortinet's support portal can be verified using a file checksum. A file
checksum that does not match the expected value indicates a corrupt file. The corruption could be caused by errors in
transfer or by file modification. A list of expected checksum values for each build of released code is available on
Fortinet’s support portal.
Image integrity is also verified when the FortiGate is booting up. This integrity check is done through a cyclic redundancy
check (CRC). If the CRC fails, the FortiGate unit will encounter an error during the boot process.
Firmware images are signed and the signature is attached to the code as it is built. When upgrading an image, the
running OS will generate a signature and compare it with the signature attached to the image. If the signatures do not
match, the new OS will not load.
FortiOS lets you test a new firmware image by installing the firmware image from a system reboot and saving it to system
memory. After completing this procedure, the FortiGate unit operates using the new firmware image with the current
configuration. The new firmware image is not permanently installed. The next time the FortiGate unit restarts, it operates
with the originally installed firmware image using the current configuration. If the new firmware image operates
successfully, you can install it permanently using the procedure explained in Upgrading the firmware.
For this procedure, you must install a TFTP server that you can connect to from the FortiGate internal interface. The
TFTP server should be on the same subnet as the internal interface.
1. Connect to the CLI using an RJ-45 to USB (or DB-9) or null modem cable.
2. Ensure that the TFTP server is running.
3. Copy the new firmware image file to the root directory on the TFTP server.
4. Ensure that the FortiGate unit can connect to the TFTP server using the execute ping command.
5. Restart the FortiGate unit: execute reboot. The following message is shown:
This operation will reboot the system!
Do you want to continue? (y/n)
6. Type y. As the FortiGate unit starts, a series of system startup messages appears.
7. When the following messages appears:
Press any key to display configuration menu..........
Immediately press any key to interrupt the system startup.
You have only three seconds to press any key. If you do not press a key during this time, the FortiGate will reboot,
and you will have to log in and repeat the execute reboot command.
If you successfully interrupt the startup process, the following messages appears:
[G]: Get firmware image from TFTP server.
[F]: Format boot device.
[B]: Boot with backup firmware and set as default
[C]: Configuration and information
[Q]: Quit menu and continue to boot with default firmware.
[H]: Display this list of options.
Enter G, F, Q, or H:
8. Type G to get the new firmware image from the TFTP server. The following message appears: Enter TFTP
server address [192.168.1.168]:
9. Type the address of the TFTP server, then press Enter. The following message appears: Enter Local Address
[192.168.1.188]:
10. Type the IP address of the FortiGate unit to connect to the TFTP server.
Installing a new firmware image replaces the current antivirus and attack definitions, along with the definitions included
with the firmware release that is being installing. After you install new firmware, make sure that the antivirus and attack
definitions are up to date.
This procedure downgrades the FortiGate to a previous firmware version. The backup configuration might not be able to
be restored after downgrading.
In the event that the firmware upgrade does not load properly and the FortiGate unit will not boot, or continuously
reboots, it is best to perform a fresh install of the firmware from a reboot using the CLI. If configured, the firmware can
also be automatically installed from a USB drive; see Restoring from a USB drive on page 801 for details.
This procedure installs a firmware image and resets the FortiGate unit to factory default settings. You can use this
procedure to upgrade to a new firmware version, revert to an older firmware version, or re-install the current firmware.
To use this procedure, you must connect to the CLI using the FortiGate console port and a RJ-45 to USB (or DB-9), or
null modem cable. You must also install a TFTP server that you can connect to from the FortiGate internal interface. The
TFTP server should be on the same subnet as the internal interface.
Before beginning this procedure, ensure that you backup the FortiGate unit configuration. See Configuration backups on
page 54 for details. If you are reverting to a previous FortiOS version, you might not be able to restore the previous
configuration from the backup configuration file.
Installing firmware replaces your current antivirus and attack definitions, along with the definitions included with the
firmware release you are installing. After you install new firmware, make sure that antivirus and attack definitions are up
to date.
1. Connect to the CLI using the RJ-45 to USB (or DB-9) or null modem cable.
2. Ensure that the TFTP server is running.
3. Copy the new firmware image file to the root directory of the TFTP server.
4. Ensure that the FortiGate unit can connect to the TFTP server using the execute ping command.
5. Restart the FortiGate unit: execute reboot. The following message is shown:
This operation will reboot the system!
Enter C,R,T,F,I,B,Q,or H:
8. If necessary, type C to configure the TFTP parameters, then type Q to return to the previous menu:
[P]: Set firmware download port.
[D]: Set DHCP mode.
[I]: Set local IP address.
[S]: Set local subnet mask.
[G]: Set local gateway.
[V]: Set local VLAN ID.
[T]: Set remote TFTP server IP address.
[F]: Set firmware file name.
[E]: Reset TFTP parameters to factory defaults.
[R]: Review TFTP parameters.
[N]: Diagnose networking(ping).
[Q]: Quit this menu.
[H]: Display this list of options.
Enter P,D,I,S,G,V,T,F,E,R,N,Q,or H:
9. Type T get the new firmware image from the TFTP server.
The FortiGate unit loads the firmware.
10. Save the firmware as the default (D) or backup (B) firmware image, or run the image without saving it (R).
The FortiGate unit installs the new firmware image and restarts. The installation might take a few minutes to
complete.
The FortiGate firmware can be manually restored from a USB drive, or installed automatically from a USB drive after a
reboot.
1. Copy the firmware file to the root directory on the USB drive.
2. Connect the USB drive to the USB port of the FortiGate device.
3. Connect to the FortiGate CLI using the RJ-45 to USB (or DB-9) or null modem cable.
4. Enter the following command:
execute restore image usb <filename>
The FortiGate unit responds with the following message:
This operation will replace the current firmware version! Do you want to continue?
(y/n)
5. Type y. The FortiGate unit restores the firmware and restarts. This process takes a few minutes.
6. Update the antivirus and attack definitions:
execute update-now
Controlled upgrade
Using a controlled upgrade, you can upload a new version of the FortiOS firmware to a separate partition in the FortiGate
memory for later upgrade. The FortiGate unit can be configured so that when it is rebooted, it will automatically load the
new firmware. Using this option, you can stage multiple FortiGate units to upgrade simultaneously using FortiManager or
a script.
To set the FortiGate unit so that when it reboots, the new firmware is loaded:
Settings
The default administrator password should be configured immediately after the FortiGate is installed, see Default
administrator password on page 803.
After that, there are several system settings that should also be configured in System > Settings:
l Changing the host name on page 803
l Setting the system time on page 804
By default, your FortiGate has an administrator account set up with the username admin and no password. In order to
prevent unauthorized access to the FortiGate, it is highly recommended that you add a password to this account.
In FortiOS 6.2.1 and later, adding a password to the admin administrator is mandatory. You
will be prompted to configured it the first time you log in to the FortiGate using that account,
after a factory reset, and after a new image installation.
It is also recommended that you change the user name of this account; however, since you
cannot change the user name of an account that is currently in use, a second administrator
account must be created in order to do this.
The FortiGate host name is shown in the Hostname field in the System Information widget on a dashboard, as the
command prompt in the CLI, as the SNMP system name, as the device name on FortiGate Cloud, and other places. If
the FortiGate is in an HA cluster, use a unique host name to distinguish it from the other devices in the cluster.
An administrator requires System > Configuration read/write access to edit the host name. See Administrator profiles on
page 786 for details.
You can either manually set the FortiOS system time, or configure the device to automatically keep its system time
correct by synchronizing with a Network Time Protocol (NTP) server.
Daylight savings time is enabled by default, and can only be configured in the CLI.
For many features to work, including scheduling, logging, and SSL-dependent features, the
FortiOS system time must be accurate.
Time Zone Select a time zone from the list. This should be the time zone that the
FortiGate is in.
Set Time Select to either Synchronize with an NTP Server, or use Manual settings.
Synchronize with To use an NTP server other than FortiGuard, the CLI must be used.
an NTP Server In the Sync interval field, enter how often, in minutes, that the device
synchronizes its time with the NTP server.
Manual settings Manually enter the Date, Hour (in 24-hour format), Minute, and Second in their
fields.
Setup device as local NTP Enable to configure the FortiGate as a local NTP server.
server In the Listen on Interfaces field, set the interface or interfaces that the
FortiGate will listen for NTP requests on.
3. Click Apply.
2. Either manually configure the date and time, or configure an NTP server:
Manual:
execute date <yyyy-mm-dd>
execute time <hh:mm:ss>
NTP server:
config system ntp
set ntpsync enable
set type {fortiguard | custom}
set syncinterval <integer>
set source-ip <ip_address>
set source-ip6 <ip6_address>
set server-mode {enable | disable}
set interface <interface>
set authentication {enable | disable}
set key-type {MD5 | SHA1}
set key <password>
set key-id <integer>
config ntpserver
edit <server_id>
set server <ip_address or hostname>
set ntpv3 {enable | disable}
set authentication {enable | disable}
set key <password>
set key-id <integer>
next
end
end
SHA-1 authentication support allows the NTP client to verify that severs are known and trusted and not intruders
masquerading (accidentally or intentionally) as legitimate servers. In cryptography, SHA-1 is a cryptographic hash
algorithmic function.
SHA-1 authentication support is only available for NTP clients, not NTP servers.
set syncinterval 1
config ntpserver
edit "883502"
set server "10.1.100.11"
set authentication enable
set key
ENCi9NmcqsV3xBJvOkgIL3lFxA8mnNs2XKfB7spOQoUw4cm8FOOP0nrCbqx6rJ+om95+hVUHpaVZmepdd4KznPlAHNiu
liPgPOk
set key-id 1
next
end
end
Command Description
authentication <enable | Enable/disable MD5/SHA1 authentication (default = disable).
disable>
key <passwd> Key for MD5/SHA1 authentication. Enter a password value.
key-id <integer> Key ID for authentication. Enter an integer value from 0 to 4294967295.
PTPv2
Precision time protocol (PTP) is used to synchronize network clocks. It is best suited to situations where time accuracy is
of the utmost importance, as it supports accuracy in the sub-microsecond range. Conversely, NTP accuracy is in the
range of milliseconds or tens of milliseconds.
The following CLI commands are available:
config system ptp
set status {enable | disable}
set mode {multicast | hybrid}
set delay-mechanism {E2E | P2P}
set request-interval <integer>
set interface <interface>
end
Command Description
status {enable | disable} Enable or disable the FortiGate system time by synchronizing with a PTP server
(default = disable).
delay-mechanism {E2E | P2P} Use end-to-end (E2E) or peer-to-peer (P2P) delay detection (default = E2E).
Command Description
request-interval <integer> The logarithmic mean interval between the delay request messages sent by the
client to the server in seconds (default = 1).
interface <interface> The interface that the PTP client will reply through.
Sample configuration
To configure a FortiGate to act as a PTP client that synchronizes itself with a Linux PTP server:
Configuring ports
To improve security, the default ports for administrative connections to the FortiGate can be changed. Port numbers
must be unique. If a conflict exists with a particular port, a warning message is shown.
When connecting to the FortiGate after a port has been changed, the port number be included, for example:
https://192.168.1.99:100.
The default service port range can be customized using the following CLI command:
config system global
set default-service-source-port <port range>
end
Where <port range> is the new default service port range, that can have a minimum value of 0 and a maximum value
up to 65535. The default value is 1 to 65535.
The idle timeout period is the amount of time that an administrator will stay logged in to the GUI without any activity. This
is to prevent someone from accessing the FortiGate if the management PC is left unattended. By default, it is set to five
minutes.
A setting of higher than 15 minutes will have a negative effect on a security rating score. See
Security rating on page 220 for more information.
A password policy can be created for administrators and IPsec pre-shared keys. See Password policy on page 791 for
information.
The view settings change the look and language of the FortiOS GUI.
Language Set the GUI language: English, French, Spanish, Portuguese, Japanese,
Traditional Chinese, Simplifies Chinese, Korean.
Lines per page Set the number of lines per page, from 20 to 100.
Theme Set the theme color: Green, Red, Blue, Melongene, or Mariner.
Date/Time Display Set the date and time to display using the FortiGate's or the browser's
timezone.
NGFW Mode Set the NGFW mode to either Profile-based (default) or Policy-based.
If Policy-based is selected, the SSL/SSH Inspection profile must be selected.
3. Click Apply.
By default, the number password retry attempts is set to three, allowing the administrator a maximum of three attempts
at logging in to their account before they are locked out for a set amount of time (by default, 60 seconds).
The number of attempts and the default wait time before the administrator can try to enter a password again can be
configured using the CLI.
A maximum of ten retry attempts can be configured, and the lockout period can be 1 to 2147483647 seconds (over 68
years). The higher the retry attempts, the higher the risk that someone might be able to guess the password.
For example, to set the number of retry attempts to 1, and the lockout time to 5 minutes:
config system global
set admin-lockout-threshold 1
set admin-lockout-duration 300
end
If the time span between the first failed log in attempt and the lockout threshold failed attempt
is less than lockout time, the lockout will be triggered.
TLS configuration
The minimum TLS version that is used for local out connections from the FortiGate can be configured in the CLI:
config system global
set ssl-min-proto-version {SSLv3 | TLSv1 | TLSv1-1 | TLSv1-2 | TLSv1-3}
end
By default, the minimum version is TLSv1.2. The FortiGate will try to negotiate a connection using the configured version
or higher. If the server that FortiGate is connecting to does not support the version, then the connection will not be made.
Some FortiCloud and FortiGuard services do not support TLSv1.3.
Minimum SSL/TLS versions can also be configured individually for the following settings, not all of which support
TLSv1.3:
Setting CLI
Setting CLI
A minimum (ssl-min-proto-ver) and a maximum (ssl-max-proto-ver) version can be configured for SSL VPN.
See TLS 1.3 support on page 1661
When multiple incoming or outgoing interfaces are used in SD-WAN or for load balancing, changes to routing or
incoming or return traffic interfaces impacts how an existing sessions handles the traffic. In FortiOS 6.2.3 and later,
auxiliary sessions can be used to handle these changes to traffic patterns.
l In FortiOS 6.0 and earlier, the auxiliary session feature is not supported.
l In FortiOS 6.2.0 to 6.2.2, the auxiliary session feature is permanently enabled.
l In FortiOS 6.2.3 and later, the auxiliary session feature is disabled by default, and can be enabled if required.
Scenarios
Incoming traffic is from the client to the server. Return traffic is from the server to the client.
In this scenario, a session is established between port1 and port3. When the return traffic hits port3:
The reply to the client egresses on the original incoming interface, port1. If policy routes or SD-WAN rules are
configured, they are not checked.
The reply to the client egresses on the best route in the routing table:
Scenario 2 - Return traffic returns on an interfaces other than the original outgoing interfaces
In this scenario, a session is established between port1 and port3. When the return traffic hits port4:
l The session is dirtied and then gets refreshed, and interfaces on the session are updated.
l If there is a high traffic volume or flapping between the interfaces, the CPU usage increases.
An auxiliary session is created for the existing session, and traffic returns to the client as normal on the auxiliary session.
Scenario 3 - Incoming traffic enters on an interfaces other than the original incoming interfaces
In this scenario, a session is established between port1 and port3. When the incoming traffic hits port2:
The session is dirtied and then gets refreshed, and interfaces on the session are updated.
An auxiliary session is created for the existing session, and traffic is forwarded to the server as normal on the auxiliary
session.
In this scenario, a session has been established between port1 and port3, when a new route on port4 is updated as the
route to the server.
As long as there is a route to the destination, the session will not be dirtied or refreshed. Even though there is a better
route, traffic continues on the original path between port1 and port3.
The session is dirtied and then gets refreshed, and interfaces on the session are updated.
When the auxiliary session feature is disabled, there is always one session. If the incoming or return interface changes,
the FortiGate marks the session as dirty and updates the session's interfaces. This cannot be done by the NPU, so the
session is not offloaded to the NPU, and is processed by the CPU instead. If Equal-Cost Multi-Path (ECMP) causes the
interface to keep changing, then it will use significant CPU resources.
When the auxiliary session feature is enabled and the incoming or return interface changes, it creates an auxiliary
session, and all traffic can continue to be processed by the NPU.
Verification
When an auxiliary, or reflect, session is created, it will appear as a reflect session below the existing session:
# diagnose sys session list
session info: proto=17 proto_state=00 duration=111 expire=175 timeout=0 flags=00000000
socktype=0 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=may_dirty npu
statistic(bytes/packets/allow_err): org=131/4/1 reply=0/0/0 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=36->38/38->36 gwy=10.1.2.3/0.0.0.0
hook=pre dir=org act=noop 10.1.100.22:51926->172.16.204.44:5001(0.0.0.0:0)
hook=post dir=reply act=noop 172.16.204.44:5001->10.1.100.22:51926(0.0.0.0:0)
src_mac=90:6c:ac:19:19:58
misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=2
serial=00002b11 tos=ff/ff app_list=0 app=0 url_cat=0
sdwan_mbr_seq=0 sdwan_service_id=0
rpdb_link_id=00000000 rpdb_svc_id=0 ngfwid=n/a
npu_state=0x000400
npu info: flag=0x91/0x00, offload=8/0, ips_offload=0/0, epid=129/0, ipid=142/0,
vlan=0x0016/0x0000
vlifid=142/0, vtag_in=0x0016/0x0000 in_npu=1/0, out_npu=1/0, fwd_en=0/0, qid=4/0
no_ofld_reason:
reflect info 0:
dev=37->38/38->37
npu_state=0x000400
npu info: flag=0x91/0x00, offload=8/0, ips_offload=0/0, epid=129/0, ipid=142/0,
vlan=0x0017/0x0000
vlifid=142/0, vtag_in=0x0017/0x0000 in_npu=1/0, out_npu=1/0, fwd_en=0/0, qid=4/0
total reflect session num: 1
total session 1
When an auxiliary session is created, NPU offloading will continue in the reflect session:
# diagnose sys session list
session info: proto=17 proto_state=01 duration=169 expire=129 timeout=0 flags=00000000
socktype=0 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=may_dirty npu
statistic(bytes/packets/allow_err): org=131/4/1 reply=66/2/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=36->38/38->36 gwy=10.1.2.3/172.17.2.1
hook=pre dir=org act=noop 10.1.100.22:51926->172.16.204.44:5001(0.0.0.0:0)
hook=post dir=reply act=noop 172.16.204.44:5001->10.1.100.22:51926(0.0.0.0:0)
src_mac=90:6c:ac:19:19:58
misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=2
serial=00002b11 tos=ff/ff app_list=0 app=0 url_cat=0
sdwan_mbr_seq=0 sdwan_service_id=0
rpdb_link_id=00000000 rpdb_svc_id=0 ngfwid=n/a
npu_state=0x000c00
npu info: flag=0x91/0x81, offload=8/8, ips_offload=0/0, epid=129/142, ipid=142/128,
vlan=0x0016/0x0016
vlifid=142/128, vtag_in=0x0016/0x0016 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=4/4
reflect info 0:
dev=37->38/38->37
npu_state=0x000400
npu info: flag=0x91/0x00, offload=8/0, ips_offload=0/0, epid=129/0, ipid=142/0,
vlan=0x0017/0x0000
vlifid=142/0, vtag_in=0x0017/0x0000 in_npu=1/0, out_npu=1/0, fwd_en=0/0, qid=4/0
total reflect session num: 1
total session 1
Email alerts
Alert emails are used to notify administrators about events on the FortiGate device, allowing a quick response to any
issues.
There are two methods that can be used to configure email alerts:
l Automation stitches on page 815
l Alert emails on page 817
The FortiGate has a default SMTP server, notification.fortinet.com, that provides secure mail service with SMTPS. It is
used for all emails that are sent by the FortiGate, including alert emails, automation stitch emails, and FortiToken Mobile
activations. You can also configure a custom email service.
SMTP Server Enter the address or name of the SMTP server, such as smtp.example.com.
Port If required, select Specify and enter a specific port number. The default is port
465.
Default Reply To Optionally, enter the reply to email address, such as [email protected].
This address will override the from address that is configured for an alert
email.
4. Click Apply.
Automation stitches
Automation stitches can be configured to send emails based on a variety of triggers, giving you control over the events
that cause an alert, and who gets alerted. For more information, see Automation stitches on page 225.
In this example, the default mail service sends an email to two recipients when there is a configuration change or an
Admin login failed event occurs.
1. On the root FortiGate, go to Security Fabric > Automation and click Create New.
2. Enter a name for the stitch, such as Admin Fail.
3. In the Trigger section, select FortiOS Event Log.
4. Click in the Event field, and in the slide out pane, search for and select Admin login failed.
5. In the Action section, select Email.
6. Configure the Email settings:
a. In the To field, click the plus icon, then enter the two email recipients' addresses, such as [email protected]
and [email protected].
b. Enter the Email subject, such as Admin log in failed.
c. Edit the Email body as required. By default, the email body will include all the fields from the log event that
triggered the stitch.
7. Click OK.
8. Create a second stitch, selecting Configuration Change as the trigger.
Alert emails
When configuring an alert email, you can define the threshold when an issue becomes critical and requires attention.
When the threshold is reached, an email is sent to up to three recipients on the configured schedule to notify them of the
issue.
Alert email messages can be configured in the CLI. For more information on the available CLI commands, see Configure
alert email settings.
In this example, the FortiGate is configured to send email messages to two addresses, [email protected] and
[email protected], every two minutes when multiple intrusions, administrator log in or out events, or configuration
changes occur.
Virtual Domains
Virtual Domains (VDOMs) are used to divide a FortiGate into two or more virtual units that function independently.
VDOMs can provide separate security policies and, in NAT mode, completely separate configurations for routing and
VPN services for each connected network.
There are two VDOM modes:
l Split-task VDOM mode: One VDOM is used only for management, and the other is used to manage traffic. See
Split-task VDOM mode on page 820.
l Multi VDOM mode: Multiple VDOMs can be created and managed as independent units. See Multi VDOM mode on
page 824.
By default, most FortiGate units support 10 VDOMs, and many FortiGate models support purchasing a license key to
increase the maximum number.
Global settings are configured outside of a VDOM. They effect the entire FortiGate, and include settings such as
interfaces, firmware, DNS, some logging and sandboxing options, and others. Global settings should only be changed
by top level administrators.
Split-task VDOM Multi VDOM Allowed only if the FortiGate is not a member
of a Security Fabric. See Configuring the root
FortiGate and downstream FortiGates on
page 132 for more information.
Multi VDOM Split-task VDOM Not Allowed. User must first switch to No
VDOM
Global and per-VDOM resources can be configured when the FortiGate is in Split-Task or Multi VDOM mode. Global
resources apply to resources that are shared by the whole FortiGate, while per-VDOM resources are specific to each
VDOM.
By default, all per-VDOM resource settings are set to have no limits. This means that any single VDOM can use all of the
FortiGate device's resources. This could deprive other VDOMs of the resources that they require, to the point that could
be unable to function. We recommend settings maximum values on the resources that are vital to you.
3. Click Apply.
To reset the all of the override values, click Reset All.
5. Click OK.
To reset the all of the override values, click Reset All.
In split-task VDOM mode, the FortiGate has two VDOMs: the management VDOM (root) and the traffic VDOM (FG-
traffic).
The management VDOM is used to manage the FortiGate, and cannot be used to process traffic.
The following GUI sections are available when in the management VDOM:
l The Status dashboard
l Security Fabric topology and settings (read-only, except for HTTP Service settings)
l Interface and static route configuration
l FortiClient configuration
l Replacement messages
l Certificates
l System events
l Log and email alert settings
l Threat weight definitions
The traffic VDOM provides separate security policies, and is used to process all network traffic.
The following GUI sections are available when in the traffic VDOM:
l The Status, Top Usage LAN/DMZ, and Security dashboards
l Security Fabric topology, settings (read-only, except for HTTP Service settings), and External Connectors
(Endpoint/Identity connectors only)
l FortiView
l Interface configuration
l Packet capture
l SD-WAN, SD-WAN Rules, and Performance SLA
Split-task VDOM mode can be enabled in the GUI or CLI. Enabling it does not require a reboot, but does log you out of
the FortiGate.
When split-task VDOM mode is enabled, all current management configuration is assigned to
the root VDOM, and all non-management settings, such as firewall policies and security
profiles, are deleted.
On VMs and FortiGate 60 series models and lower, VDOMs can only be enabled using the
CLI.
An interface can only be assigned to one of the VDOMs. When split-task VDOM mode is enabled, all interfaces are
assigned to the root VDOM. To use an interface in a policy, it must first be assigned to the traffic VDOM.
An interface cannot be moved if it is referenced in an existing configuration.
In the GUI, the interface list Ref. column shows if the interface is referenced in an existing
configuration, and allows you to quickly access and edit those references.
3. Select the VDOM that the interface will be assigned to from the Virtual Domain list.
4. Click OK.
config global
config system interface
edit <interface>
set vdom <VDOM_name>
next
end
end
Per-VDOM administrators can be created that can access only the management or traffic VDOM. These administrators
must use either the prof_admin administrator profile, or a custom profile.
A per-VDOM administrator can only access the FortiGate through a network interface that is assigned to the VDOM that
they are assigned to. The interface must also be configured to allow management access. They can also connect to the
FortiGate using the console port.
To assign an administrator to multiple VDOMs, they must be created at the global level. When creating an administrator
at the VDOM level, the super_admin administrator profile cannot be used.
5. Click OK.
config global
config system admin
edit <name>
set vdom <VDOM_name>
set password <password>
set accprofile <admin_profile>
...
next
end
end
In multi VDOM mode, the FortiGate can have multiple VDOMs that function as independent units. One VDOM is used to
manage global settings. The root VDOM cannot be deleted, and remains in the configuration even if it is not processing
any traffic.
Multi VDOM mode isn't available on all FortiGate models. The Fortinet Security Fabric does not support multi VDOM
mode.
There are three main configuration types in multi VDOM mode:
Independent VDOMs:
Multiple, completely separate VDOMs are created. Any VDOM can be the management VDOM, as long as it has Internet
access. There are no inter-VDOM links, and each VDOM is independently managed.
Management VDOM:
A management VDOM is located between the other VDOMs and the Internet, and the other VDOMs connect to the
management VDOM with inter-VDOM links. The management VDOM has complete control over Internet access,
including the types of traffic that are allowed in both directions. This can improve security, as there is only one point of
ingress and egress.
There is no communication between the other VDOMs.
Meshed VDOMs:
VDOMs can communicate with inter-VDOM links. In full-mesh configurations, all the VDOMs are interconnected. In
partial-mesh configurations, only some of the VDOMs are interconnected.
In this configuration, proper security must be achieved by using firewall policies and ensuring secure account access for
administrators and users.
The following examples show how to configure per-VDOM settings, such as operation mode, routing, and security
policies, in a network that includes the following VDOMs:
l VDOM-A: allows the internal network to access the Internet.
l VDOM-B: allows external connections to an FTP server.
l root: the management VDOM.
You can use VDOMs in either NAT or transparent mode on the same FortiGate. By default, VDOMs operate in NAT
mode.
For both examples, multi VDOM mode must be enabled, and VDOM-A and VDOM-B must be created.
Multi VDOM mode can be enabled in the GUI or CLI. Enabling it does not require a reboot, but does log you out of the
device. The current configuration is assigned to the root VDOM.
On VMs and FortiGate 60 series models and lower, VDOMs can only be enabled using the
CLI.
1. In the Global VDOM, go to System > VDOM, and click Create New. The New Virtual Domain page opens.
3. If required, set the NGFW Mode. If the NGFW Mode is Policy-based, select an SSL/SSH Inspection from the list.
4. Optionally, enter a comment.
5. Click OK to create the VDOM.
6. Repeat the above steps for VDOM-B.
config vdom
edit <VDOM-A>
next
edit <VDOM-B>
next
end
end
NAT mode
In this example, both VDOM-A and VDOM-B use NAT mode. A VDOM link is created that allows users on the internal
network to access the FTP server.
This configuration requires the following steps:
1. Configure VDOM-A on page 827
2. Configure VDOM-B on page 829
3. Configure the VDOM link on page 832
Configure VDOM-A
VDOM-A allows connections from devices on the internal network to the Internet. WAN 1 and port 1 are assigned to this
VDOM.
The per-VDOM configuration for VDOM-A includes the following:
l A firewall address for the internal network
l A static route to the ISP gateway
l A security policy allowing the internal network to access the Internet
All procedures in this section require you to connect to VDOM-A, either using a global or per-VDOM administrator
account.
Name internal-network
Type Subnet
Interface port1
config vdom
edit VDOM-A
config firewall address
edit internal-network
set associated-interface port1
set subnet 192.168.10.0 255.255.255.0
next
end
next
end
Destination Subnet
IP address 0.0.0.0/0.0.0.0
Gateway 172.20.201.7
Interface wan1
Distance 10
config vdom
edit VDOM-A
config router static
edit 0
set gateway 172.20.201.7
set device wan1
next
end
next
end
1. Connect to VDOM-A.
2. Go to Policy & Objects > Firewall Policy and create a new policy.
3. Enter the following information:
Name VDOM-A-Internet
Source internal-network
Destination all
Schedule always
Service ALL
Action ACCEPT
NAT enabled
config vdom
edit VDOM-A
config firewall policy
edit 0
set name VDOM-A-Internet
set srcintf port1
set dstintf wan1
set srcaddr internal-network
set dstaddr all
set action accept
set schedule always
set service ALL
set nat enable
next
end
next
end
Configure VDOM-B
VDOM-B allows external connections to reach an internal FTP server. WAN 2 and port 2 are assigned to this VDOM.
The per-VDOM configuration for VDOM-B includes the following:
l A firewall address for the FTP server
l A virtual IP address for the FTP server
l A static route to the ISP gateway
l A security policy allowing external traffic to reach the FTP server
All procedures in this section require you to connect to VDOM-B, either using a global or per-VDOM administrator
account.
Type Subnet
Interface port2
config vdom
edit VDOM-B
config firewall address
edit FTP-server
set associated-interface port2
set subnet 192.168.20.10 255.255.255.255
next
end
next
end
Name FTP-server-VIP
Interface wan2
Destination Subnet
IP address 0.0.0.0/0.0.0.0
Gateway 172.20.10.10
Interface wan2
Distance 10
config vdom
edit VDOM-B
config router static
edit 0
set device wan2
set gateway 172.20.10.10
next
end
next
end
Name Access-server
Source all
Destination FTP-server-VIP
Schedule always
Service FTP
Action ACCEPT
NAT enabled
config vdom
edit VDOM-B
config firewall policy
edit 0
set name Access-server
set srcintf wan2
set dstintf port2
set srcaddr all
set dstaddr FTP-server-VIP
set action accept
set schedule always
set service FTP
set nat enable
next
end
next
end
The VDOM link allows connections from VDOM-A to VDOM-B. This allows users on the internal network to access the
FTP server through the FortiGate.
The configuration for the VDOM link includes the following:
l The VDOM link interface
l Firewall addresses for the FTP server on VDOM-A and for the internal network on VDOM-B
l Static routes for the FTP server on VDOM-A and for the internal network on VDOM-B
l Policies allowing traffic using the VDOM link
All procedures in this section require you to connect to the global VDOM using a global administrator account.
1. Connect to root.
2. Go to Global > Network > Interfaces and select Create New > VDOM link.
3. Enter the following information:
Name VDOM-link
Interface 0
IP/Netmask 0.0.0.0/0.0.0.0
Interface 1
IP/Netmask 0.0.0.0/0.0.0.0
config global
config system vdom-link
edit vlink
end
config system interface
edit VDOM-link0
set vdom VDOM-A
set ip 0.0.0.0 0.0.0.0
next
edit VDOM-link1
set vdom VDOM-B
set ip 0.0.0.0 0.0.0.0
next
end
end
1. Connect to VDOM-A.
2. Go to Policy & Objects > Addresses and create a new address.
Type Subnet
Interface VDOM-link0
config vdom
edit VDOM-B
config firewall address
edit FTP-server
set associated-interface VDOM-link0
set allow-routing enable
set subnet 192.168.20.10 255.255.255.255
next
end
next
end
1. Connect to VDOM-A.
2. Go to Network > Static Routes and create a new route.
3. Enter the following information:
Gateway 0.0.0.0
Interface VDOM-link0
config vdom
edit VDOM-A
config router static
edit 0
set device VDOM-link0
set dstaddr FTP-server
next
end
next
end
1. Connect to VDOM-A.
2. Go to Policy & Objects > Firewall Policy and create a new policy.
3. Enter the following information:
Name Access-FTP-server
Source internal-network
Destination FTP-server
Schedule always
Service FTP
Action ACCEPT
NAT disabled
config vdom
edit VDOM-A
config firewall policy
edit 0
set name Access-FTP-server
set srcintf port1
set dstintf VDOM-link0
set srcaddr internal-network
set dstaddr FTP-server
set action accept
set schedule always
set service FTP
next
end
next
end
1. Connect to VDOM-B.
2. Go to Policy & Objects > Addresses and create a new address.
3. Enter the following information:
Type Subnet
Interface VDOM-link1
config vdom
edit VDOM-B
config firewall address
edit internal-network
set associated-interface VDOM-link1
set allow-routing enable
set subnet 192.168.10.0 255.255.255.0
next
end
next
end
1. Connect to VDOM-B.
2. Go to Network > Static Routes and create a new route.
3. Enter the following information:
Gateway 0.0.0.0
Interface VDOM-link1
config vdom
edit VDOM-B
config router static
edit 0
set device VDOM-link1
set dstaddr internal-network
next
end
next
end
1. Connect to VDOM-B.
2. Go to Policy & Objects > Firewall Policy and create a new policy.
3. Enter the following information:
Name Internal-server-access
Source internal-network
Destination FTP-server
Schedule always
Service FTP
Action ACCEPT
NAT disabled
config vdom
edit VDOM-B
config firewall policy
edit 0
set name Internal-server-access
set srcintf VDOM-link1
set dstintf port2
set srcaddr internal-network
set dstaddr FTP-server
set action accept
set schedule always
set service FTP
next
end
next
end
In this example, VDOM-A uses NAT mode and VDOM-B uses transparent mode.
This configuration requires the following steps:
1. Configure VDOM-A on page 836
2. Configure VDOM-B on page 838
Configure VDOM-A
VDOM-A allows connections from devices on the internal network to the Internet. WAN 1 and port 1 are assigned to this
VDOM.
The per-VDOM configuration for VDOM-A includes the following:
l A firewall address for the internal network
l A static route to the ISP gateway
l A security policy allowing the internal network to access the Internet
All procedures in this section require you to connect to VDOM-A, either using a global or per-VDOM administrator
account.
Name internal-network
Type Subnet
Interface port1
config vdom
edit VDOM-A
config firewall address
edit internal-network
set associated-interface port1
set subnet 192.168.10.0 255.255.255.0
next
end
next
end
Destination Subnet
IP address 0.0.0.0/0.0.0.0
Gateway 172.20.201.7
Interface wan1
Distance 10
config vdom
edit VDOM-A
config router static
edit 0
set gateway 172.20.201.7
set device wan1
next
end
next
end
1. Connect to VDOM-A.
2. Go to Policy & Objects > Firewall Policy and create a new policy.
3. Enter the following information:
Name VDOM-A-Internet
Source internal-network
Destination all
Schedule always
Service ALL
Action ACCEPT
NAT enabled
config vdom
edit VDOM-A
config firewall policy
edit 0
set name VDOM-A-Internet
set srcintf port1
set dstintf wan1
set srcaddr internal-network
set dstaddr all
set action accept
set schedule always
set service ALL
set nat enable
next
end
next
end
Configure VDOM-B
VDOM-B allows external connections to reach an internal FTP server. WAN 2 and port 2 are assigned to this VDOM.
The per-VDOM configuration for VDOM-B includes the following:
l A firewall address for the FTP server
l A static route to the ISP gateway
l A security policy allowing external traffic to reach the FTP server
All procedures in this section require you to connect to VDOM-B, either using a global or per-VDOM administrator
account.
Type Subnet
Interface port2
config vdom
edit VDOM-B
config firewall address
edit FTP-server
set associated-interface port2
set subnet 172.25.177.42 255.255.255.255
next
end
next
end
Destination Subnet
IP address 0.0.0.0/0.0.0.0
Gateway 172.20.10.10
config vdom
edit VDOM-B
config router static
edit 0
set gateway 172.20.10.10
next
end
next
end
1. Connect to VDOM-B.
2. Go to Policy & Objects > Firewall Policy and create a new policy.
3. Enter the following information:
Name Access-server
Source all
Destination FTP-server
Schedule always
Service FTP
Action ACCEPT
config vdom
edit VDOM-B
config firewall policy
edit 0
set name Access-server
set srcintf wan2
set dstintf port2
set srcaddr all
set dstaddr FTP-server-VIP
set action accept
set schedule always
set service FTP
next
end
next
end
High Availability
Whether your FortiGate is used as a security gateway, an internal segmentation firewall, in the cloud, or in an MSSP
environment, as long as there is critical traffic passing through it, there is risk of it being a single point of failure. Physical
outages can occur due to power failures, physical link failures, transceiver failures, or power supply failures. Non-
physical outages can be caused by routing, resource issues, or kernel panic.
Network outages cause disruptions to business operations, downtime, and frustration for users and in some situations
may have financial setbacks. In designing your network and architecture, it is important to weigh the risks and
consequences associated with unexpected outages.
There are many ways to build redundancy and resiliency. In a switching network, you can accomplish this by adding
redundant links and switches in partial or full mesh topologies. Using redundant and aggregate links, you can avoid a
single link failure causing a network to go down. Using SD-WAN, you can build redundant and intelligent WAN load
balancing and failover architectures.
FortiGate HA offers several solutions for adding redundancy in the case where a failure occurs on the FortiGate, or is
detected by the FortiGate through monitored links, routes, and other health checks. These solutions support fast failover
to avoid lengthy network outages and disruptions to your traffic.
FGCP provides a solution for two key requirements of critical enterprise networking components: enhanced reliability
and increased performance. Enhanced reliability is achieved through device failover protection, link failover protection,
and remote link failover protection. Session failover protection for most IPv4 and IPv6 sessions also contributes to
enhanced reliability. Increased performance is achieved though active-active HA load balancing.
In a network that already includes load balancing (either with load balancers or routers) for traffic redundancy, two
entities (either standalone FortiGates or FGCP clusters) can be integrated into the load balancing configuration using the
FortiGate Session Life Support Protocol (FGSP). The external load balancers or routers can distribute sessions among
the FortiGates and the FGSP performs session synchronization of IPv4 and IPv6 TCP, SCTP, UDP, ICMP, expectation,
and NAT sessions to keep the session tables of both entities synchronized. In the event of a failure, the load balancer
can detect the failed unit and failover the sessions to other active members to continue processing the traffic.
The following topics provide more information about each HA solution and other HA related topics:
l FGCP on page 841
l FGSP on page 879
l Using standalone configuration synchronization on page 892
FGCP
High availability (HA) is usually required in a system where there is high demand for little downtime. There are usually
hot-swaps, backup routes, or standby backup units and as soon as the active entity fails, backup entities will start
functioning. This results in minimal interruption for the users.
The FortiGate Clustering Protocol (FGCP) is a proprietary HA solution whereby FortiGates can find other member
FortiGates to negotiate and create a cluster. A FortiGate HA cluster consists of at least two FortiGates (members)
configured for HA operation. All FortiGates in the cluster must be the same model and have the same firmware installed.
Cluster members must also have the same hardware configuration (such as the same number of hard disks). All cluster
members share the same configurations except for their host name and priority in the HA settings. The cluster works like
a device but always has a hot backup device.
General operation
Failover
FGCP uses a combination of incremental and periodic synchronization to make sure that the configuration of all cluster
units is synchronized to that of the primary unit.
The following settings are not synchronized between cluster units:
l The FortiGate host name
l GUI Dashboard widgets
l HA override
l HA device priority
l The virtual cluster priority
l The HA priority setting for a ping server (or dead gateway detection) configuration
l The system interface settings of the HA reserved management interface
l The HA default route for the reserved management interface, set using the ha-mgmt-interface-gateway
option of the config system ha command
Most subscriptions and licenses are not synchronized, as each FortiGate must be licensed individually. FortiToken
Mobile is an exception; they are registered to the primary unit and synchronized to the secondary units.
The primary unit synchronizes all other configuration settings, including the other HA configuration settings.
All synchronization activity takes place over the HA heartbeat link using TCP/703 and UDP/703 packets.
The following topics provide more information about FGCP:
l Failover protection on page 843
l HA active-passive cluster setup on page 844
l HA active-active cluster setup on page 846
l HA virtual cluster setup on page 847
l Check HA sync status on page 850
l Out-of-band management with reserved management interfaces on page 852
l In-band management on page 857
l Upgrading FortiGates in an HA cluster on page 858
l HA between remote sites over managed FortiSwitches on page 858
l HA using a hardware switch to replace a physical switch on page 863
l VDOM exceptions on page 866
l Override FortiAnalyzer and syslog server settings on page 868
l Routing NetFlow data over the HA management interface on page 872
l Force HA failover for testing and demonstrations on page 874
l Disabling stateful SCTP inspection on page 876
l Querying autoscale clusters for FortiGate VM on page 877
l Troubleshoot an HA formation on page 878
Failover protection
The FortiGate Clustering Protocol (FGCP) provides failover protection, meaning that a cluster can provide FortiGate
services even when one of the devices in the cluster encounters a problem that would result in the complete loss of
connectivity for a stand-alone FortiGate unit. Failover protection provides a backup mechanism that can be used to
reduce the risk of unexpected downtime, especially in mission-critical environments.
FGCP supports failover protection in three ways:
1. Link failover maintains traffic flow if a link fails.
2. If a device loses power, it automatically fails over to a backup unit with minimal impact on the network.
3. Optionally, if an SSD fails, it can automatically fail over to a backup unit.
When session-pickup is enabled in the HA settings, existing TCP session are kept, and users on the network are not
impacted by downtime as the traffic can be passed without reestablishing the sessions.
1. Link fails
Before triggering a failover when a link fails, the administrator must ensure that monitor interfaces are configured.
Normally, the internal interface that connects to the internal network, and an outgoing interface for traffic to the internet or
outside the network, should be monitored. Any of those links going down will trigger a failover.
When an active (primary) unit loses power, a backup (secondary) unit automatically becomes the active, and the impact
on traffic is minimal. There are no settings for this kind of fail over.
3. SSD failure
config system ha
set ssd-failover enable
end
Mode Active-Passive
Except for the device priority, these settings must be the same on all FortiGates in the cluster.
4. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
5. Click OK.
The FortiGate negotiates to establish an HA cluster. Connectivity with the FortiGate may be temporarily lost as the
HA cluster negotiates and the FGCP changes the MAC addresses of the FortiGate's interfaces.
6. Factory reset the other FortiGate that will be in the cluster, configure GUI access, then repeat steps 1 to 5, omitting
setting the device priority, to join the cluster.
Changing the host name makes it easier to identify individual cluster units in the cluster operations.
4. Enable HA:
config system ha
set mode a-p
set group-name Example_cluster
set hbdev ha1 10 ha2 20
end
5. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
6. Repeat steps 1 to 5 on the other FortiGate devices to join the cluster.
Mode Active-Active
Except for the device priority, these settings must be the same on all FortiGates in the cluster.
4. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
5. Click OK.
The FortiGate negotiates to establish an HA cluster. Connectivity with the FortiGate may be temporarily lost as the
HA cluster negotiates and the FGCP changes the MAC addresses of the FortiGate's interfaces.
6. Factory reset the other FortiGate that will be in the cluster, configure GUI access, then repeat steps 1 to 5, omitting
setting the device priority, to join the cluster.
Changing the host name makes it easier to identify individual cluster units in the cluster operations.
4. Enable HA:
config system ha
set mode a-a
set group-name Example_cluster
set hbdev ha1 10 ha2 20
end
5. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
6. Repeat steps 1 to 5 on the other FortiGate devices to join the cluster.
HA virtual clusters are based on VDOMs and are more complicated than regular clusters.
Mode Active-Passive
Except for the device priority, these settings must be the same on all FortiGates in the cluster.
4. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
5. Click OK.
The FortiGate negotiates to establish an HA cluster. Connectivity with the FortiGate may be temporarily lost as the
HA cluster negotiates and the FGCP changes the MAC addresses of the FortiGate's interfaces.
6. Factory reset the other FortiGate that will be in the cluster, configure GUI access, then repeat steps 1 to 5, omitting
setting the device priority, to join the cluster.
7. Go to System > Settings and enable Virtual Domains.
8. Click Apply. You will be logged out of the FortiGate.
9. Log back into the FortiGate, ensure that you are in the global VDOM, and go to System > VDOM.
10. Create two new VDOMs, such as VD1 and VD2:
a. Click Create New. The New Virtual Domain page opens.
b. Enter a name for the VDOM in the Virtual Domain field, then click OK to create the VDOM.
c. Repeat these steps to create a second new VDOM.
11. Implement a virtual cluster by moving the new VDOMs to Virtual cluster 2:
a. Go to System > HA.
b. Enable VDOM Partitioning.
c. Click on the Virtual cluster 2 field and select the new VDOMs.
d. Click OK.
next
end
The HA sync status can be viewed in the GUI through either a widget on the Dashboard or on the System > HA page. It
can also be confirmed through the CLI. When a cluster is out of sync, administrators should correct the issue as soon as
possible as it affects the configuration integrity and can cause issues to occur.
l Dashboard widget:
l Following HA setup, the HA Status widget can be added to the Dashboard. The widget shows the HA sync
status by displaying a green checkmark next to each member in sync. A red mark indicates the member is out
of sync.
In the CLI, run the get system ha status command to see if the cluster is in sync. The sync status is reported under
Configuration Status. In the following example, both members are in sync:
# get system ha status
HA Health Status: OK
Model: FortiGate-VM64
Mode: HA A-P
Group: 0
Debug: 0
Cluster Uptime: 0 days 0:29:2
Cluster state change time: 2020-09-25 08:23:09
Primary selected using:
<2020/09/25 08:23:09> FGVME000000JUG0E is selected as the primary because it has the
largest value of override priority.
<2020/09/25 08:23:09> FGVMEV00000M6S87 is selected as the primary because it's the only
member in the cluster.
ses_pickup: disable
override: disable
Configuration Status:
FGVME000000JUG0E(updated 2 seconds ago): in-sync
FGVMEV00000M6S87(updated 4 seconds ago): in-sync
System Usage stats:
FGVME000000JUG0E(updated 2 seconds ago):
sessions=11, average-cpu-user/nice/system/idle=1%/0%/1%/98%, memory=69%
FGVMEV00000M6S87(updated 4 seconds ago):
sessions=1, average-cpu-user/nice/system/idle=0%/0%/1%/99%, memory=69%
HBDEV stats:
FGVME000000JUG0E(updated 2 seconds ago):
port1: physical/1000auto, up, rx-bytes/packets/dropped/errors=60578029/155605/0/0,
tx=13360110/25218/0/0
FGVMEV00000M6S87(updated 4 seconds ago):
port1: physical/1000auto, up, rx-bytes/packets/dropped/errors=7006310/19328/0/0,
tx=6220835/13974/0/0
MONDEV stats:
FGVME000000JUG0E(updated 2 seconds ago):
port1: physical/1000auto, up, rx-bytes/packets/dropped/errors=60578029/155605/0/0,
tx=13360110/25218/0/0
port2: physical/1000auto, up, rx-bytes/packets/dropped/errors=70459776/175970/0/0,
tx=36854/226/0/0
FGVMEV00000M6S87(updated 4 seconds ago):
port1: physical/1000auto, up, rx-bytes/packets/dropped/errors=7006310/19328/0/0,
tx=6220835/13974/0/0
port2: physical/1000auto, up, rx-bytes/packets/dropped/errors=7197677/20580/0/0,
tx=29200/83/0/0
Primary : HA1 , FGVME000000JUG0E, HA cluster index = 0
Secondary : HA2 , FGVMEV00000M6S87, HA cluster index = 1
number of vcluster: 1
vcluster 1: work 169.254.0.1
Primary: FGVME000000JUG0E, HA operating index = 0
Secondary: FGVMEV00000M6S87, HA operating index = 1
As part of an HA configuration, you can reserve up to four management interfaces to provide direct management access
to all cluster units. For each reserved management interface, you can configure a different IP address, administrative
access, and other interface settings, for each cluster unit. By connecting these interfaces to your network, you can
separately manage each cluster unit from different IP addresses.
l Reserved management interfaces provide direct management access to each cluster unit, and give each cluster
unit a different identity on your network. This simplifies using external services, such as SNMP, to monitor and
managed separate cluster units.
l Reserved management interfaces are not assigned HA virtual MAC addresses. They retain the permanent
hardware address of the physical interface, unless you manually change it using the config system
interface command.
l Reserved management interfaces and their IP addresses should not be used for managing a cluster using
FortiManager. To manage a FortiGate HA cluster with FortiManager, use the IP address of one of the cluster unit
interfaces.
l Configuration changes to a reserved management interface are not synchronized to other cluster units. Other
configuration changes are automatically synchronized to all cluster units.
You can configure an in-band management interface for a cluster unit. See In-band
management on page 857 for information. In-band management does not reserve the
interface exclusively for HA management.
Management interface
Enable HTTPS or HTTP administrative access on the reserved management interfaces to connect to the GUI of each
cluster unit. On secondary units, the GUI has the same features as the primary unit, except for unit specific information,
for example:
l The System Information widget on the Status dashboard shows the secondary units serial number.
l In the cluster members list at System > HA, you can change the HA configuration of the unit that you are logged into.
You can only change the host name and device priority of the primary and other secondary units.
l The system events logs shows logs for the device that you are logged into. Use the HA device drop down to view the
log messages for other cluster units, including the primary unit.
Enable SSH administrative access on the reserved management interfaces to connect to the CLI of each cluster unit.
The CLI prompt includes the host of the cluster unit that you are connected to. Use the execute ha manage command
to connect to other cluster unit CLIs.
Enable SNMP administrative access on a reserved management interface to use SNMP to monitor each cluster unit
using the interface's IP address. Direct management of cluster members must also be enabled, see Configuring SNMP
remote management of individual cluster units example on page 853.
Reserved management interfaces are available in both NAT and transparent mode, and when the cluster is operating
with multiple VDOMs.
By default, management services such as FortiCloud, FortiSandbox, SNMP, remote logging, and remote authentication,
use a cluster interface. This means that communication from each cluster unit will come from a cluster interface, and not
config system ha
set ha-direct enable
end
In this example, two FortiGate units are already operating in a cluster. On each unit, port8 is connected to the internal
network through a switch and configured as a reserved management interface with SNMP remote management.
Configuration changes to the reserved management interface are not synchronized to other
cluster units.
5. Optionally, enter a Destination subnet to indicate the destinations that should use the defined gateway. By default,
0.0.0.0/0 is used.
6. Click OK.
config system ha
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface "port8"
set gateway 10.11.101.2
next
end
end
The reserved management interface default route is not synchronized to other cluster units.
GUI access
To configure the primary unit's reserved management interface, configure an IP address and management access on
port8. Then, to configure the secondary unit's reserved management interface, access the unit's CLI through the primary
unit, and configure an IP address and management access on port8. Configuration changes to the reserved
management interface are not synchronized to other cluster units.
To configure the primary unit reserved management interface to allow GUI access in the CLI:
next
end
You can now log into the primary unit's GUI by browsing to https://10.11.101.101. You can also log into the primary
unit's CLI by using an SSH client to connect to 10.11.101.101.
1. From a computer on the internal network, connect to the primary unit's CLI.
2. Connect to the secondary unit with the following command:
execute ha manage <unit id> <username> <password>
You can now log into the secondary unit's GUI by browsing to https://10.11.101.102. You can also log into the
secondary unit's CLI by using an SSH client to connect to 10.11.101.102.
SNMP management
The SNMP server can get status information from the cluster members. To use the reserved management interfaces,
you must add at least one HA direct management host to an SNMP community. If the SNMP configuration includes
SNMP users with user names and passwords, HA direct management must be enabled for the users.
To configure the cluster for SNMP management using the reserved management interfaces in the CLI:
1. Add an SNMP community with a host for the reserved management interface of each cluster member. The host
includes the IP address of the SNMP server.
config system snmp community
edit 1
set name "Community"
config hosts
edit 1
set ip 10.11.101.20 255.255.255.255
set ha-direct enable
next
end
next
end
To get CPU, memory, and network usage information from the SNMP manager for each cluster unit
using the reserved management IP addresses:
3. Get resource usage information for the primary unit using the OIDs:
snmpget -v2c -c Community 10.11.101.101 1.3.6.1.4.1.12356.101.13.2.1.1.3.1
snmpget -v2c -c Community 10.11.101.101 1.3.6.1.4.1.12356.101.13.2.1.1.4.1
snmpget -v2c -c Community 10.11.101.101 1.3.6.1.4.1.12356.101.13.2.1.1.5.1
4. Get resource usage information for the secondary unit using the MIB fields:
snmpget -v2c -c Community 10.11.101.102 fgHaStatsCpuUsage
snmpget -v2c -c Community 10.11.101.102 fgHaStatsMemUsage
snmpget -v2c -c Community 10.11.101.102 fgHaStatsNetUsage
5. Get resource usage information for the primary unit using the OIDs:
snmpget -v2c -c Community 10.11.101.102 1.3.6.1.4.1.12356.101.13.2.1.1.3.1
snmpget -v2c -c Community 10.11.101.102 1.3.6.1.4.1.12356.101.13.2.1.1.4.1
snmpget -v2c -c Community 10.11.101.102 1.3.6.1.4.1.12356.101.13.2.1.1.5.1
Enabling ha-mgmt-intf-only applies the local-in policy only to the VDOM that contains the reserved management
interface. The incoming interface is set to match any interface in the VDOM..
next
end
If reserved management interfaces are configured for each cluster member, and NTP is enabled, then the primary unit
will contact the NTP server using the reserved management interface. The system time is then synchronized to the
secondary units over the HA heartbeat interface.
config system interface
edit port5
set ip 172.16.79.46 255.255.255.0
next
end
config system ha
set group-name FGT-HA
set mode a-p
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface port5
set gateway 172.16.79.1
next
end
set ha-direct enable
end
config system ntp
set ntpsync enable
set syncinterval 5
end
In-band management
In-band management IP addresses are an alternative to reserved HA management interfaces, and do not require
reserving an interface exclusively for management access. They can be added to multiple interfaces on each cluster
unit.
The in-band management IP address is accessible from the network that the cluster interface is connected to. It should
be in the same subnet as the interface that you are adding it to. It cannot be in the same subnet as other interface
IP addresses.
In-band management interfaces support ping, HTTP, HTTPS, and SNMP administrative access options.
Primary and secondary units send packets differently from an interface with a management IP address configured:
l On the primary unit, packets are sent to destinations based on routing information.
l On secondary units, packets can only be sent to destinations with the same management IP address segment.
To add an in-band management IP address to port23 with HTTPS, SSH, and SNMP access:
You can upgrade the firmware on an HA cluster in the same way as on a standalone FortiGate. During a firmware
upgrade, the cluster upgrades the primary unit and all of the subordinate units to the new firmware image.
Before upgrading a cluster, back up your configuration (Configuration backups on page 54),
schedule a maintenance window, and make sure that you are using a supported upgrade path
(https://docs.fortinet.com/upgrade-tool).
Uninterrupted upgrade
Interrupted upgrade
An interrupted upgrade upgrades all cluster members at the same time. This takes less time than an uninterrupted
upgrade, but it interrupts communication in the cluster. Interrupted upgrade is disabled by default.
config system ha
set uninterruptible-upgrade disable
end
In a multi-site FortiGate HA topology that uses managed FortiSwitches in a multi-chassis link aggregation group
(MCLAG) to connect between sites, HA heartbeat signals can be sent through the switch layer of the FortiSwitches,
instead of through back-to-back links between the heartbeat interfaces. This means that two fiber connections can be
used, instead of four. The FortiSwitches can be different models, but must all support MCLAG and be running version
6.4.2 or later.
This example shows how to configure heartbeat VLANs to assign to the access ports that the heartbeat interfaces
connect to, passing over the trunk between the FortiSwitches on the two sites.
FortiGate HA is with two FortiGates in separate locations and the switch layer connection between the FortiSwitches is
used for the heartbeat signal.
2. Configure Site 1:
a. On the FortiGate, go to WiFi & Switch Controller > FortiLink Interface and configure FortiLink:
c. Go to WiFi & Switch Controller > FortiSwitch VLANs and create a switch VLAN that is dedicated to the
FortiGate HA heartbeats between the two FortiGates.
d. Assign the native VLAN of the switch ports that are connected to the heartbeat ports to the created VLAN:
i. Go to WiFi & Switch Controller > FortiSwitch Ports.
ii. In the Native VLAN column for the port, click the edit icon and select the Heartbeat VLAN.
3. Configure Site 2 the same as Site 1, except set the HA priority so that the FortiGate becomes the secondary.
4. Disconnect the physical connections for FortiGate HA and FortiLink interfaces on Site 2:
l Disconnect the cable on Site 2 FSW-1 ports 47 and 48.
l Connect a cable from Site 1 FSW-2 port 10 to Site 2 FSW-2 port 20.
6. On all of the FortiSwitches, configure the auto-isl-port-group. The group must match on both sides.
a. Site 1 FSW-1:
Set members to the port that is connected to Site 2 FSW-1:
config switch auto-isl-port-group
edit 1
set members port12
next
end
b. Site 1 FSW-2:
Set members to the port that is connected to Site 1 FSW-1:
config switch auto-isl-port-group
edit 1
set members port22
next
end
c. Site 2 FSW-1:
Set members to the port that is connected to Site 2 FSW-2:
config switch auto-isl-port-group
edit 1
set members port10
next
end
d. Site 2 FSW-2:
Set members to the port that is connected to Site 1 FSW-2:
config switch auto-isl-port-group
edit 1
set members port20
next
end
1. On both PC-1 and PC-2, access the internet and monitor traffic. The traffic should be going through the primary
FortiGate.
2. Perform a continuous ping to an outside IP address, then reboot any one of the FortiSwitches.
Traffic from both Site 1 and Site 2 to the internet should be recovered in approximately five seconds.
3. Perform a continuous ping to an outside IP address, then force an HA failover (see Force HA failover for testing and
demonstrations on page 874).
Traffic from both Site 1 and Site 2 to the internet should be recovered in approximately five seconds.
4. After an HA failover, on the new primary FortiGate, go to WiFi & Switch Controller > Managed FortiSwitch.
The switch layer tiering will be changed so that the directly connected FortiSwitches are at the top of the topology.
Using a hardware switch to replace a physical switch is not recommended, as it offers no redundancy or interface
monitoring.
l If one FortiGate loses power, all of the clients connected to that FortiGate device cannot go to another device until
that FortiGate recovers.
l A hardware switch cannot be used as a monitor interface in HA. Any incoming or outgoing link failures on hardware
member interfaces will not trigger failover; this can affect traffic.
Examples
When using Hardware switch in HA environment, a client device connected to the hardware switch on the primary
FortiGate can communicate with client devices connected to the hardware switch on secondary FortiGates as long as
there is a direct connection between the two switches.
No configuration is required after setting up the hardware switches. If a client connected to both of the hardware switches
needs to reach destinations outside of the cluster, the firewall must be configured for it.
After configuring the hardware switches, PC1 and PC2 can now communicate with each other.
If client device needs to send traffic through the FortiGate, additional firewall configuration on the FortiGate is required.
All traffic from the hardware switches on either the primary or secondary FortiGate reaches the primary FortiGate first.
The traffic is then directed according to the HA mode and firewall configuration.
Traffic from PC1 and PC2 can now reach destinations outside of the FortiGate cluster.
VDOM exceptions
VDOM exceptions are settings that can be selected for specific VDOMs or all VDOMs that are not synchronized to other
HA members. This can be required when cluster members are not in the same physical location, subnets, or availability
zones in a cloud environment.
Some examples of possible use cases include:
l You use different source IP addresses for FortiAnalyzer logging from each cluster member. See Override
FortiAnalyzer and syslog server settings on page 868 for more information.
l You need to keep management interfaces that have specific VIPs or local subnets that cannot transfer from being
synchronized.
l In a unicast HA cluster in the cloud, you use NAT with different IP pools in different subnets, so IP pools must be
exempt.
When a VDOM exception is configured, the object will not be synchronized between the primary and secondary devices
when the HA forms. Different options can be configured for every object.
When VDOM mode is disabled, the configured object is excluded for the entire device. To define a scope, VDOM mode
must be enabled and the object must be configurable in a VDOM.
VDOM exceptions are synchronized to other HA cluster members.
To configure VDOM exceptions:
config global
config system vdom-exception
edit 1
set object <object name>
set scope {all* | inclusive | exclusive}
set vdom <vdom name>
next
end
end
object The name of the configuration object that can be configured independently for
some or all of the VDOMs.
See Objects on page 867 for a list of available settings and resources.
scope Determine if the specified object is configured independently for all VDOMs or a
subset of VDOMs.
l all: Configure the object independently on all VDOMs.
Objects
The following settings and resources can be exempt from synchronization in an HA cluster:
log.fortianalyzer.setting system.interface
log.fortianalyzer.override-setting vpn.ipsec.phase1-interface
log.fortianalyzer2.setting vpn.ipsec.phase2-interface
log.fortianalyzer2.override-setting router.bgp
log.fortianalyzer3.setting router.route-map
log.fortianalyzer3.override-setting router.prefix-list
log.fortianalyzer-cloud.setting firewall.ippool
log.fortianalyzer-cloud.override-setting firewall.ippool6
log.syslogd.setting router.static
log.syslogd.override-setting router.static6
log.syslogd2.setting firewall.vip
log.syslogd2.override-setting firewall.vip6
log.syslogd3.setting firewall.vip46
log.syslogd3.override-setting firewall.vip64
log.syslogd4.setting system.sdwan
log.syslogd4.override-setting system.saml
system.central-management router.policy
system.csf router.policy6
user.radius
In an HA cluster, secondary devices can be configured to use different FortiAnalyzer devices and syslog servers than the
primary device. VDOMs can also override global syslog server settings.
2. Set up a VDOM exception to enable setting the global syslog server on the secondary HA device:
config global
config system vdom-exception
edit 1
set object log.syslogd.setting
next
end
end
2. After the primary and secondary device synchronize, generate logs on the secondary device.
To confirm that logs are been sent to the syslog server configured on the secondary device:
1. On the primary device, retrieve the following packet capture from the secondary device's syslog server:
# diagnose sniffer packet any "host 172.16.200.55" 6
interfaces=[any]
filters=[host 172.16.200.55]
2. Set up a VDOM exception to enable syslog-override in the secondary HA device root VDOM:
config global
config system vdom-exception
edit 1
set object log.syslogd.override-setting
set scope inclusive
set vdom root
next
end
end
3. In the VDOM, enable syslog-override in the log settings, and set up the override syslog server:
config root
config log setting
set syslog-override enable
end
config log syslog override-setting
set status enable
set server 172.16.200.44
set facility local6
set format default
end
end
After syslog-override is enabled, an override syslog server must be configured, as logs will not be sent to the global
syslog server.
2. After the primary and secondary device synchronize, generate logs in the root VDOM on the secondary device.
To confirm that logs are been sent to the syslog server configured for the root VDOM on the secondary
device:
1. On the primary device, retrieve the following packet capture from the syslog server configured in the root VDOM on
the secondary device:
# diagnose sniffer packet any "host 172.16.200.55" 6
interfaces=[any]
filters=[host 172.16.200.55]
In an HA environment, the ha-direct option allows data from services such as syslog, FortiAnalyzer, SNMP, and
NetFlow to be routed over the outgoing interface.
The following example shows how NetFlow data can be routed over the HA management interface mgmt1.
1. On the primary unit (FortiGate A), configure the HA and mgmt1 interface settings:
(global) # config system ha
set group-name "test-ha"
set mode a-p
set password *********
set hbdev "port6" 50
set hb-interval 4
set hb-lost-threshold 10
set session-pickup enable
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface "mgmt1"
next
end
set override enable
set priority 200
set ha-direct enable
end
(global) # config system interface
edit "mgmt1"
set ip 10.6.30.111 255.255.255.0
set allowaccess ping https ssh http telnet fgfm
set type physical
set dedicated-to management
set role lan
set snmp-index 1
next
end
2. On the secondary unit (FortiGate B), configure the HA and mgmt1 interface settings:
(global) # config system ha
set group-name "test-ha"
set mode a-p
set password *********
set hbdev "port6" 50
set hb-interval 4
set hb-lost-threshold 10
set session-pickup enable
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface "mgmt1"
next
end
5. Verify that the NetFlow packets are being sent by the mgmt1 IP:
(vdom1) # diagnose test application sflowd 3
interfaces=[any]
filters=[udp and port 2055]
8.397265 mgmt1 out 10.6.30.111.1992 -> 10.6.30.59.2055: udp 60
23.392175 mgmt1 out 10.6.30.111.1992 -> 10.6.30.59.2055: udp 188
23.392189 mgmt1 out 10.6.30.111.1992 -> 10.6.30.59.2055: udp 60
...
3 packets received by filter
0 packets dropped by kernel
6. On the secondary device (FortiGate B), change the priority so that it becomes the primary:
(global) # config system ha
set priority 250
end
7. Verify the NetFlow status on FortiGate A, which is using the new primary's mgmt1 IP:
(global) # diagnose test application sflowd 3
8. Verify that the NetFlow packets use the new source IP on FortiGate B:
(vdom1) # diagnose sniffer packet any 'udp and port 2055' 4
interfaces=[any]
filters=[udp and port 2055]
7.579574 mgmt1 out 10.6.30.112.3579 -> 10.6.30.59.2055: udp 60
22.581830 mgmt1 out 10.6.30.112.3579 -> 10.6.30.59.2055: udp 60
29.038336 mgmt1 out 10.6.30.112.3579 -> 10.6.30.59.2055: udp 1140
^C
3 packets received by filter
0 packets dropped by kernel
This command should only be used for testing, troubleshooting, maintenance, and
demonstrations.
Do not use it in a live production environment outside of an active maintenance window.
HA failover can be forced on an HA primary device. The device will stay in a failover state regardless of the conditions.
The only way to remove the failover status is by manually turning it off.
Syntax
Variable Description
<cluster_id> The cluster ID is 1 for any cluster that is not in virtual cluster mode, and can be 1
or 2 if virtual cluster mode is enabled.
Example
There is an option in FortiOS to disable stateful SCTP inspection. This option is useful when FortiGates are deployed in a
high availability (HA) cluster that uses the FortiGate Clustering Protocol (FGCP) and virtual clustering in a multihoming
topology. In this configuration, the primary stream control transmission protocol (SCTP) path traverses the primary
FortiGate node by using its active VDOM (for example, VDOM1), and the backup SCTP path traverses the other passive
FortiGate node by using its active VDOM (for example, VDOM2).
When stateful SCTP inspection is enabled, SCTP heartbeat traffic fails by means of the backup path because the
primary path goes through a different platform and VDOM. Since there is no state sharing between VDOMs, the passive
FortiGate is unaware of the original SCTP session and drops the heartbeats because of no associated sessions. When
stateful SCTP inspection is disabled, the passive node permits the SCTP heartbeats to pass.
When set to enable, SCTP session creation without SCTP INIT is enabled. When set to disable, SCTP session
creation without SCTP INIT is disabled (this is the default setting):
config system settings
set sctp-session-without-init {enable | disable}
end
In this example, FGT_A and FGT_B are in HA a-p mode with two virtual clusters. Two primaries exist on different
FortiGate units. PC1 eth1 can access PC5 eth1 through VDOM1, and PC1 eth2 can access PC5 eth2 through VDOM2.
On PC5, to listen for an SCTP connection:
sctp_darn -H 172.16.200.55 -B 172.17.200.55 -P 2500 -l
An SCTP four-way handshake is on one VDOM, and a session is created on that VDOM. With the default configuration,
there is no session on any other VDOM, and the heartbeat on another path (another VDOM) is dropped. After enabling
sctp-session-without-init, the other VDOM creates the session when it receives the heartbeat, and the
heartbeat is forwarded:
config system settings
set sctp-session-without-init enable
end
When a FortiGate VM secondary device is added to a cluster, the new secondary member can query the cluster about its
autoscale environment. FortiManager can then run this query on the new secondary member to update its autoscale
record.
From the secondary device, you can see cluster checksums and the primary device:
# diagnose sys ha checksum autoscale-cluster
================== FGTAZ000000000CD ==================
is_autoscale_master()=0
debugzone
global: 56 49 b3 02 f2 b7 5b 82 ec 2d c2 1a ff 80 8c 79
root: bf 18 cf 83 1e 04 c3 04 4c e4 66 bc 38 fe 3a dc
all: 77 06 d0 89 6e 06 c0 86 17 98 53 72 33 85 ae ff
checksum
global: 56 49 b3 02 f2 b7 5b 82 ec 2d c2 1a ff 80 8c 79
root: bf 18 cf 83 1e 04 c3 04 4c e4 66 bc 38 fe 3a dc
all: 77 06 d0 89 6e 06 c0 86 17 98 53 72 33 85 ae ff
================== FGVM04TM00000066 ==================
is_autoscale_master()=1
debugzone
global: 56 49 b3 02 f2 b7 5b 82 ec 2d c2 1a ff 80 8c 79
root: bf 18 cf 83 1e 04 c3 04 4c e4 66 bc 38 fe 3a dc
all: 77 06 d0 89 6e 06 c0 86 17 98 53 72 33 85 ae ff
checksum
global: 56 49 b3 02 f2 b7 5b 82 ec 2d c2 1a ff 80 8c 79
root: bf 18 cf 83 1e 04 c3 04 4c e4 66 bc 38 fe 3a dc
all: 77 06 d0 89 6e 06 c0 86 17 98 53 72 33 85 ae ff
================== FGVM00000000056 ==================
is_autoscale_master()=0
debugzone
global: 56 49 b3 02 f2 b7 5b 82 ec 2d c2 1a ff 80 8c 79
root: bf 18 cf 83 1e 04 c3 04 4c e4 66 bc 38 fe 3a dc
all: 77 06 d0 89 6e 06 c0 86 17 98 53 72 33 85 ae ff
checksum
global: 56 49 b3 02 f2 b7 5b 82 ec 2d c2 1a ff 80 8c 79
root: bf 18 cf 83 1e 04 c3 04 4c e4 66 bc 38 fe 3a dc
all: 77 06 d0 89 6e 06 c0 86 17 98 53 72 33 85 ae ff
================== FGTAZ0000000003D ==================
is_autoscale_master()=0
debugzone
global: 56 49 b3 02 f2 b7 5b 82 ec 2d c2 1a ff 80 8c 79
root: bf 18 cf 83 1e 04 c3 04 4c e4 66 bc 38 fe 3a dc
all: 77 06 d0 89 6e 06 c0 86 17 98 53 72 33 85 ae ff
checksum
global: 56 49 b3 02 f2 b7 5b 82 ec 2d c2 1a ff 80 8c 79
root: bf 18 cf 83 1e 04 c3 04 4c e4 66 bc 38 fe 3a dc
all: 77 06 d0 89 6e 06 c0 86 17 98 53 72 33 85 ae ff
Troubleshoot an HA formation
The requirement to have the same generation is done as a best practice as it avoids issues
that can occur later on. If you are unsure if the FortiGates are from the same generation,
please contact customer service.
One member keeps shutting down during HA setup (hard drive failure):
If one member has a hard drive failure but the other does not, the one with the hard drive failure will be shut down during
HA setup. In this case, RMA the member to resolve the issue.
All members are primaries and members cannot see other members:
Typically, this is a heartbeat issue. It is recommended that for a two-member cluster, you use a back-to-back connection
for heartbeat communication. If there are more than three members in the cluster, a separate switch should be used to
connect all heartbeat interfaces.
FGSP
Standalone FortiGates or FGCP clusters can be integrated into the load balancing configuration using the FortiGate
Session Life Support Protocol (FGSP) in a network where traffic is load balanced by an upstream load balancer and
scanned by downstream FortiGates. FGSP can perform session synchronization of IPv4 and IPv6 TCP, SCTP, UDP,
ICMP, expectation, and NAT sessions to keep the session tables synchronized on all entities. If one of the FortiGates
fails, the upstream load balancer should detect the failed member and stop distributing sessions to it. Session failover
occurs and active sessions fail over to the peers that are still operating. Traffic continues to flow on the new peer without
data loss because the sessions are synchronized.
The FortiGates in FGSP operate as peers that process traffic and synchronize sessions. An FGSP deployment can
include two to four standalone FortiGates, or two to four FortiGate FGCP clusters of two members each. Adding more
FortiGates increases the CPU and memory required to keep all of the FortiGates synchronized, and it increases network
synchronization traffic. Exceeding the numbers of members is not recommended and may reduce overall performance.
By default, FGSP synchronizes all IPv4 and IPv6 TCP sessions, and IPsec tunnels. You can optionally add filters to
control which sessions are synchronized, such as synchronizing packets from specific source and destination
addresses, source and destination interfaces, or services.
All FortiGates in the FGSP deployment must be the same model and be running the same
firmware version. FGSP is also compatible with FortiGate VRRP.
FGSP is primarily used instead of FGCP when external load balancers are part of the topology, and they are responsible
for distributing traffic amongst the downstream FortiGates. FGSP provides the means to synchronize sessions between
the FortiGate peers without needing a primary member to distribute the sessions like in FGCP active-active mode. If the
external load balancers direct all sessions to one peer, the effect is similar to active-passive FGCP HA. If external load
balancers balance traffic to both peers, the effect is similar to active-active FGCP HA. The load balancers should be
configured so that all packets for any given session are processed by the same peer, including return packets whenever
possible.
Session pickup
Session pickup is an optional setting that can be enabled to synchronize connectionless (UDP and ICMP) sessions,
expectation sessions, and NAT sessions. If session pickup is not enabled, the FGSP does not share session tables for
the particular session type, and sessions do not resume after a failover. All sessions are interrupted by the failover and
must be re-established at the application level. Many protocols can successfully restart sessions with little, or no, loss of
data. Others may not recover as easily. Enable session pickup for sessions that may be difficult to reestablish. Since
session pickup requires FortiGate memory and CPU resources, only enable this feature for sessions that need to
synchronize.
The session synchronization link is an optional configuration that allows peers to synchronize sessions over a dedicated
interface instead of the interface in which the peer IP is routed. In this configuration, communications occur over L2
instead of L3. Configuring session synchronization links is recommended when you want to minimize traffic over the
peering interface when there are many sessions that need to be synchronized.
Expectation sessions
FortiOS session helpers keep track of the communication of layer 7 protocols, such as FTP and SIP, that have control
sessions and expectation sessions. The control sessions establish the link between the server and client, and negotiate
the ports and protocols that will be used for data communications. The session helpers then create expectation sessions
through the FortiGate for the ports and protocols negotiated by the control session.
The expectation sessions are the sessions that actually communicate data. For FTP, the expectation sessions transmit
files being uploaded or downloaded. For SIP, the expectation sessions transmit voice and video data. Expectation
sessions usually have a timeout value of 30 seconds. If the communication from the server is not initiated within 30
seconds, the expectation session times out and traffic will be denied.
By default, FGSP does not synchronize expectation sessions; if a failover occurs, the sessions will have to be restarted.
config system ha
set session-pickup enable
set session-pickup-expectation enable
end
The FortiGate Session Life Support Protocol (FGSP) is a proprietary HA solution for only sharing sessions between two
entities and is based on a peer-to-peer structure. The entities could be standalone FortiGates or an FGCP cluster.
Connect all necessary interfaces as per the topology diagram below. Interfaces may be changed depending on the
models in use. Interface names in the topology diagram are for example purposes only.
These instructions assume that the device has been connected to the console, the CLI is accessible, and that all
FortiGates have been factory reset.
1. Connect all necessary interfaces as per the topology diagram.
2. Enter the following command to change the FortiGate unit host name:
config system global
set hostname Example1_host(Example2_host, etc)
end
Synchronizing sessions between FGCP clusters is useful when data centers in different locations are used for load-
balancing, and traffic must be shared and flow freely based on demand.
There are some limitations when synchronizing sessions between FGCP clusters:
l All FortiGates must have the same model and generation, hardware configuration, and FortiOS version.
l Currently, a total of 16 clusters can share sessions.
1. Configure the two clusters (see HA active-passive cluster setup on page 844 or HA active-active cluster setup on
page 846).
2. On cluster A, configure the peer IP for the interface:
config system interface
edit "port5"
set vdom "root"
set ip 10.10.10.1 255.255.255.0
set allowaccess ping https ssh snmp http telnet
next
end
In this example, cluster A uses port5 and its IP address, 10.10.10.1, is reachable from another cluster.
3. On cluster A, configure cluster and session synchronization:
config system cluster-sync
edit 1
set peerip 10.10.10.2
next
end
The standalone-group-id must match between FGSP members. The group-member-id is unique for each
FGCP cluster. session-sync-dev is an optional command to specify the interfaces to sync sessions.
5. On cluster B, configure the peer IP for the interface:
config system interface
edit "port5"
set vdom "root"
set ip 10.10.10.2 255.255.255.0
set allowaccess ping https ssh snmp http telnet
next
end
In this example, cluster B uses port5 and its IP address, 10.10.10.2, is reachable from another cluster.
6. On cluster B, configure cluster and session synchronization:
config system cluster-sync
edit 1
set peerip 10.10.10.1
next
end
When peering over FGSP, by default, the FortiGates or FGCP clusters share information over L3 between the interfaces
that are configured with Peer IP addresses. When a session synchronization interface is configured and FGSP peers are
directly connected on this interface, then session synchronization is done over L2, only falling back to L3 if the session
synchronization interface becomes unavailable.
When using a session synchronization interface, the synchronization process is offloaded to the kernel. A fast,
dedicated, and stable L2 connection should be used for the session synchronization interface between the FGSP peers.
For redundancy, multiple synchronization interfaces can be configured.
To provide full redundancy, FGCP clusters can be used in FGSP peering. This is called FGCP over FGSP.
The layer2-connection setting is for forwarded traffic between FGSP peers. Set it to available if the peer
interface user for traffic forwarding is directly connected and supports L2 forwarding. See UTM inspection on asymmetric
traffic in FGSP on page 887 for more information.
The following topology uses multiple session synchronization interfaces with a full mesh backbone to prevent any single
point of failure.
The state diagram summarizes the session synchronization of a TCP session. It assumes that the session is connected
over FGCP Cluster 1 and processed entirely by the primary unit, Cluster-1A.
In the previous topology, if any single session synchronization link fails on the primary member of each cluster, session
synchronization will continue on the second link from the pair of session of session synchronization interfaces.
If the second link on the primary member of the same cluster then fails, L2 session synchronization over the session
synchronization interface stops, and synchronization fails over to L3 between the peer IP links.
If the Peer IP link then fails, the FGSP peers are effectively disconnected, and no session synchronization will occur.
When traffic passes asymmetrically through FGSP peers, UTM inspection can be supported by always forwarding traffic
back to the session owner for processing. The session owner is the FortiGate that receives the first packet of the
session.
In this example, traffic from the internal network first hits FGT_1, but the return traffic is routed to FGT_2. Consequently,
traffic bounces from FGT_2 port1 to FGT_1 port1 using FGT_1’s MAC address. Traffic is then inspected by FGT_1.
This example requires the following settings:
l The internal and outgoing interfaces of both FortiGates in the FGSP pair are in the same subnet.
l Both peers have layer 2 access with each other.
To configure FTG_1:
next
end
To configure FTG_2:
Results
Capture packets on FGT_2 to see that traffic bounced from FGT_2 to FGT_1 over the traffic interface.
FGT_2 # diagnose sniffer packet any 'host 10.1.100.15 and host 172.6.200.55' 4
interfaces=[any]
filters=[host 10.1.100.15 and host 172.16.200.55]
91.803816 port1 in 172.16.200.55.80 -> 10.1.100.15.40008: syn 2572073713 ack 261949279
92.800480 port1 in 172.16.200.55.80 -> 10.1.100.15.40008: syn 2572073713 ack 261949279
92.800486 port1 out 172.16.200.55.80 -> 10.1.100.15.40008: syn 2572073713 ack 261949279
92.800816 port1 in 172.16.200.55.80 -> 10.1.100.15.40008: syn 2572073713 ack 261949279
92.800818 port1 out 172.16.200.55.80 -> 10.1.100.15.40008: syn 2572073713 ack 261949279
When traffic passes asymmetrically through FGSP peers, UTM inspection can be supported by always forwarding traffic
back to the session owner for processing. The session owner is the FortiGate that receives the first packet of the
session.
For networks where L2 connectivity is not available, such as cloud environments, traffic bound for the session owner are
forwarded through the peer interface using a UDP connection.
In this example, traffic from the internal network first hits FGT_1, but the return traffic is routed to FGT_2. Consequently,
return traffic is packed and sent from FGT_2 to FGT_1 using UDP encapsulation between two peer interfaces (port 3).
Traffic is then inspected by FGT_1.
To configure FTG_1:
To configure FTG_2:
In scenarios where asymmetric routing between FGSP members occurs, the return traffic can be encrypted and routed
back to the session owner on Layer 3 (L3).
The following steps are recommended to upgrade the firmware of FortiGates in an FGSP deployment. Follow these
steps whether or not you have enabled standalone configuration synchronization.
This example FGSP deployment has two FortiGates, FGT-1 and FGT-2.
6. Upgrade the firmware on FGT-1 (while heartbeat and synchronization communication with FGT-2 remains
disconnected).
7. Reconnect the FGT-2 interfaces that allow heartbeat and synchronization communication between FGT-1 and
FGT-2.
8. Restore the original traffic distribution between FGT-1 and FGT-2:
a. Configure the load balancer or router to distribute traffic to both FortiGates in the FGSP deployment.
You can configure synchronization from one standalone FortiGate to another standalone FortiGate (standalone-
config-sync). With the exception of some configurations that do not sync (settings that identify the FortiGate to the
network), the rest of the configurations are synced, such as firewall policies, firewall addresses, and UTM profiles.
This option is useful in situations when you need to set up FGSP peers, or when you want to quickly deploy several
FortiGates with the same configurations. You can set up standalone-config-sync for multiple members.
Limitations
When standalone configuration synchronization is enabled, there are some limitations, including but not limited to the
following:
l Network interruptions occur during firmware upgrades: when upgrading the firmware, all members in the
standalone-config-sync group are upgraded simultaneously. This creates downtime if the FortiGates are the
only outgoing gateway in the network. We recommend disabling the option before upgrading firmware.
l Some unwanted configurations might be synced: the current design and implementation of standalone-config-
sync is based on requirements from specific customers. Thus, some users may find that unwanted parts of the
configurations are synced. Should this occur, we recommend disabling the option and modifying those
configurations manually.
l The wrong primary device might be selected accidentally: standalone-config-sync is derived from the HA
primary unit selection mechanism. All members in the group will join the selection process in the same way as a the
HA cluster selection process. It is important to select the correct device as the primary, otherwise the wrong device
could be selected and existing configurations could be overwritten.
l Layer 2 heartbeat connections must be present: similar to HA heartbeat requirements, one or more layer 2
heartbeat connections are needed to sync configurations between the primary and secondary devices.
Two or more standalone FortiGates should be connected to each other with one or more heartbeat interfaces, either
back-to-back or via a switch. In the following example, the device supplying the configurations is called "conf-prim," and
the devices receiving the configurations are called "conf-secos."
If all members are in-sync, this means all members share the same configurations, except those that should not
be synced. If any members are out-of-sync, this means the member failed to sync with the primary device.
SNMP
SNMP enables you to monitor hardware on your network. You can configure the hardware, such as the FortiGate SNMP
agent, to report system information and send traps (alarms or event messages) to SNMP managers. SNMP traps alert
you to events that happen, such as when a log disk is full or a virus is detected.
The FortiGate SNMP implementation is read-only. SNMP v1/v2c, and v3 compliant SNMP managers have read-only
access to FortiGate system information through queries, and can receive trap messages from the FortiGate unit.
l Interface access on page 894
l MIB files on page 895
l FortiGate Rugged 30D SNMP bridge MIB module support on page 895
l SNMP agent on page 897
l SNMP v1/v2c communities on page 897
l SNMP v3 users on page 899
l Important SNMP traps on page 900
l SNMP traps and query for monitoring DHCP pool on page 902
Interface access
Before a remote SNMP manager can connect to the FortiGate SNMP agent, you must configure one or more FortiGate
interfaces to accept SNMP connections.
config ipv6
append ip6-allowaccess snmp
end
next
end
MIB files
The FortiGate SNMP agent supports Fortinet proprietary MIBs, as well as the parts of RFC 2665 and RFC 1213 that
apply to FortiGate unit configuration.
Your SNMP manager may already include standard and private MIBs in a compiled database that is ready to use. You
must add the Fortinet proprietary MIBs to this database to have access to Fortinet specific information.
FORTINET-CORE-MIB.mib The Fortinet core MIB includes all system configuration and trap information that
is common to all Fortinet products.
Your SNMP manager requires this information to monitor Fortinet device settings
and receive traps from the FortiGate SNMP agent.
FORTINET-FORTIGATE- The FortiGate MIB includes all system configuration information and trap
MIB.mib information that is specific to FortiGate units.
Your SNMP manager requires this information to monitor FortiGate settings and
receive traps from the FortiGate SNMP agent.
RFC-1213 (MIB II) The FortiGate SNMP agent supports MIB II groups with the following exceptions:
l No support for the EGP group from MIB II (RFC 1213, section 3.11 and 6.10).
accurately capture all Fortinet traffic activity. More accurate information can
be obtained from the information reported by the Fortinet MIB.
RFC-2665 (Ethernet-like MIB) The FortiGate SNMP agent supports Ethernet-like MIB information.
FortiGate SNMP does not support for the dot3Tests and dot3Errors groups.
SNMP bridge MIB module support is available on FortiGates with 802.1p to monitor STP activity.
dot1dBridge.dot1dBase.dot1dBaseBridgeAddress 1.3.6.1.2.1.17.1.1
dot1dBridge.dot1dBase.dot1dBaseNumPorts 1.3.6.1.2.1.17.1.2
dot1dBridge.dot1dBase.Type 1.3.6.1.2.1.17.1.3
dot1dBridge.dot1dBase.dot1dBasePortEntry.dot1dBasePortIfIndex 1.3.6.1.2.1.17.1.4.1.2
dot1dBridge.dot1dBase.dot1dBasePortEntry.dot1dBasePortCircuit 1.3.6.1.2.1.17.1.4.1.3
dot1dBridge.dot1dBase.dot1dBasePortEntry.dot1dBasePortDelayExceededDiscards 1.3.6.1.2.1.17.1.4.1.5
dot1dBridge.dot1dBase.dot1dBasePortEntry.dot1dBasePortMtuExceededDiscards 1.3.6.1.2.1.17.1.4.1.5
dot1dBridge.dot1dStp.dot1dStpProtocolSpecification 1.3.6.1.2.1.17.2.1
dot1dBridge.dot1dStp.dot1dStpPriority 1.3.6.1.2.1.17.2.2
dot1dBridge.dot1dStp.dot1dStpDesignatedRoot 1.3.6.1.2.1.17.2.5
dot1dBridge.dot1dStp.dot1dStpRootCost 1.3.6.1.2.1.17.2.6
dot1dBridge.dot1dStp.dot1dStpRootPort 1.3.6.1.2.1.17.2.7
dot1dBridge.dot1dStp.dot1dStpMaxAge 1.3.6.1.2.1.17.2.8
dot1dBridge.dot1dStp.dot1dStpHelloTime 1.3.6.1.2.1.17.2.9
dot1dBridge.dot1dStp.dot1dStpForwardDelay 1.3.6.1.2.1.17.2.11
dot1dBridge.dot1dStp.dot1dStpBridgeMaxAge 1.3.6.1.2.1.17.2.12
dot1dBridge.dot1dStp.dot1dStpBridgeHelloTime 1.3.6.1.2.1.17.2.13
dot1dBridge.dot1dStp.dot1dStpBridgeForwardDelay 1.3.6.1.2.1.17.2.14
dot1dBridge.dot1dStp.dot1dStpPortEntry.dot1dStpPortPriority 1.3.6.1.2.1.17.2.15.1.2
dot1dBridge.dot1dStp.dot1dStpPortEntry.dot1dStpPortState 1.3.6.1.2.1.17.2.15.1.3
dot1dBridge.dot1dStp.dot1dStpPortEntry.dot1dStpPortEnable 1.3.6.1.2.1.17.2.15.1.4
dot1dBridge.dot1dStp.dot1dStpPortEntry.dot1dStpPortPathCost 1.3.6.1.2.1.17.2.15.1.5
next
edit 2
set ip 172.18.60.149 255.255.255.255
next
end
set events cpu-high mem-low log-full intf-ip vpn-tun-up vpn-tun-down ha-switch
ha-hb-failure ips-anomaly av-oversize av-fragmented fm-conf-change ha-member-up ha-
member-down av-conserve av-bypass av-oversize-blocked ips-pkg-update ips-fail-open faz-
disconnect
next
end
2. On the SNMP server, run snmpwalk on the OID from the newly added bridge MIB.
The OID is for the bridge hello time. The SNMP server is able to query the bridge hello time from the FortiGate:
root@ControlPC:~# snmpwalk -v1 -c REGR-SWITCH 172.16.200.2 1.3.6.1.2.1.17.2.13
BRIDGE-MIB::dot1dStpBridgeHelloTime.0 = INTEGER: 200 centi-seconds
SNMP agent
The SNMP agent sends SNMP traps originating on the FortiGate to an external monitoring SNMP manager defined in a
SNMP community. The SNMP manager can monitor the FortiGate system to determine if it is operating properly, or if
any critical events occurring.
The description, location, and contact information for this FortiGate system will be part of the information that the SNMP
manager receives. This information is useful if the SNMP manager is monitoring many devices, and enables faster
responses when the FortiGate system requires attention.
An SNMP community is a grouping of equipment for network administration purposes. A single device can belong to
multiple communities.
You must add an SNMP community to the FortiGate so that the SNMP manager can receive traps and system
information. Up to three communities can be added.
SNMP v3 users
Authentication is used to ensure the identity of users. Privacy allows for encryption of SNMP v3 messages to ensure
confidentiality of data. These protocols provide a higher level of security than is available in SNMP v1 and v2c, which use
community strings for security. Both authentication and privacy are optional.
l Authentication and Private: Select both the authentication and encryption algorithms and password.
7. In the Traps section, enable or disable traps, then enter the local and remote port numbers that the SNMP
managers use for them.
8. In the SNMP Events section, enable or disable the events that activate traps.
9. Click OK.
Important SNMP traps
This trap is sent when a FortiGate port either goes down or is brought up.
For example, the following traps are generated when the state of port34 is set to down using set status down, and
then brought up using set status up:
NET-SNMP version 5.7.3 2019-01-31 14:11:48 10.1.100.1(via UDP: [10.1.100.1]:162->
[10.1.100.11]:162) TRAP, SNMP v1, community REGR-SYS SNMPv2-MIB::snmpTraps Link Down Trap
(0) Uptime: 0:14:44.95 IF-MIB::ifIndex.42 = INTEGER: 42 IF-MIB::ifAdminStatus.42 = INTEGER:
down(2) IF-MIB::ifOperStatus.42 = INTEGER: down(2) FORTINET-CORE-MIB::fnSysSerial.0 =
STRING: FG140P3G15800330 SNMPv2-MIB::sysName.0 = STRING: FortiGate-140D-POE
2019-01-31 14:11:48 <UNKNOWN> [UDP: [10.1.100.1]:162->[10.1.100.11]:162]: DISMAN-EVENT-
MIB::sysUpTimeInstance = Timeticks: (88495) 0:14:44.95 SNMPv2-MIB::snmpTrapOID.0 = OID: IF-
MIB::linkDown IF-MIB::ifIndex.42 = INTEGER: 42 IF-MIB::ifAdminStatus.42 = INTEGER: down(2)
IF-MIB::ifOperStatus.42 = INTEGER: down(2) FORTINET-CORE-MIB::fnSysSerial.0 = STRING:
FG140P3G15800330 SNMPv2-MIB::sysName.0 = STRING: FortiGate-140D-POE 2019-01-31 14:12:01
10.1.100.1(via UDP: [10.1.100.1]:162->[10.1.100.11]:162) TRAP, SNMP v1, community REGR-SYS
SNMPv2-MIB::snmpTraps Link Up Trap (0) Uptime: 0:14:57.98 IF-MIB::ifIndex.42 = INTEGER: 42
IF-MIB::ifAdminStatus.42 = INTEGER: up(1) IF-MIB::ifOperStatus.42 = INTEGER: up(1) FORTINET-
CORE-MIB::fnSysSerial.0 = STRING: FG140P3G15800330 SNMPv2-MIB::sysName.0 = STRING:
FortiGate-140D-POE
fgFmTrapIfChange trap
This trap is sent when any changes are detected on the interface. The change can be very simple, such as giving an
IPV4 address.
For example, the user has given the IP address of 1.2.3.4/24 to port 1 and the EMS Manager has detected the following
trap:
DISMAN-EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (7975058) 22:09:10.58 SNMPv2-
MIB::snmpTrapOID.0 = OID: FORTINET-FORTIGATE-MIB::fgFmTrapIfChange FORTINET-CORE-
MIB::fnSysSerial.0 = STRING: FG140P3G15800330 IF-MIB::ifName.45 = STRING: port1 FORTINET-
FORTIGATE-MIB::fgManIfIp.0 = IpAddress: 1.2.3.4 FORTINET-FORTIGATE-MIB::fgManIfMask.0 =
IpAddress: 255.255.255.0 FORTINET-FORTIGATE-MIB::fgManIfIp6.0 = STRING: 0:0:0:0:0:0:0:0
entConfigChange trap
The change to the interface in the previous example has also triggered the ConfChange Trap which is sent along with
the fgFmTrapIfChange trap:
2018-11-15 09:30:23 FGT_A [UDP: [172.16.200.1]:162->[172.16.200.55]:162]: DISMAN-EXPRESSION-
MIB::sysUpTimeInstance = Timeticks: (8035097) 22:19:10.97 SNMPv2-MIB::snmpTrapOID.0 = OID:
ENTITY-MIB::entConfigChange
fgTrapDeviceNew trap
This trap is triggered when a new device, like a FortiSwitch, is connected to the FortiGate.
For example, the following scenario has given the device a new trap for adding FortiAP on a PoE interface a FortiGate
140D-POE. The trap has important information about the device name, device MAC address, and when it was last seen.
2018-11-15 11:17:43 UDP/IPv6: [2000:172:16:200::1]:162 [UDP/IPv6: [2000:172:16:200::1]:162]:
DISMAN-EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (520817) 1:26:48.17 SNMPv2-
MIB::snmpTrapOID.0 = OID: FORTINET-FORTIGATE-MIB::fgTrapDeviceNew FORTINET-CORE-
MIB::fnSysSerial.0 = STRING: FG140P3G15800330 SNMPv2-MIB::sysName.0 = STRING: FGT_A IF-
MIB::ifIndex.0 = INTEGER: 0 FORTINET-FORTIGATE-MIB::fgVdEntIndex.0 = INTEGER: 0 FORTINET-
FORTIGATE-MIB::fgDeviceCreated.0 = Gauge32: 5 FORTINET-FORTIGATE-MIB::fgDeviceLastSeen.0 =
Gauge32: 5 FORTINET-FORTIGATE-MIB::fgDeviceMacAddress.0 = STRING: 90:6c:ac:f9:97:a0
2018-11-15 11:17:43 FGT_A [UDP: [172.16.200.1]:162->[172.16.200.55]:162]: DISMAN-EXPRESSION-
MIB::sysUpTimeInstance = Timeticks: (520817) 1:26:48.17 SNMPv2-MIB::snmpTrapOID.0 = OID:
FORTINET-FORTIGATE-MIB::fgTrapDeviceNew FORTINET-CORE-MIB::fnSysSerial.0 = STRING:
FG140P3G15800330 SNMPv2-MIB::sysName.0 = STRING: FGT_A IF-MIB::ifIndex.0 = INTEGER: 0
FORTINET-FORTIGATE-MIB::fgVdEntIndex.0 = INTEGER: 0 FORTINET-FORTIGATE-
MIB::fgDeviceCreated.0 = Gauge32: 5 FORTINET-FORTIGATE-MIB::fgDeviceLastSeen.0 = Gauge32: 5
FORTINET-FORTIGATE-MIB::fgDeviceMacAddress.0 = STRING: 90:6c:ac:f9:97:a0
fgTrapAvOversize trap
The fgTrapAvOversize trap is generated when the antivirus scanner detects an oversized file:
019-01-31 13:22:04 10.1.100.1(via UDP: [10.1.100.1]:162->[10.1.100.11]:162) TRAP, SNMP v1,
community REGR-SYS FORTINET-FORTIGATE-MIB::fgt140P Enterprise Specific Trap (602) Uptime: 1
day, 3:41:10.31 FORTINET-CORE-MIB::fnSysSerial.0 = STRING: FG140P3G15800330 SNMPv2-
MIB::sysName.0 = STRING: FortiGate-140D-POE 2019-01-31 13:22:29 <UNKNOWN> [UDP:
[10.1.100.1]:162->[10.1.100.11]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:
(9967031) 1 day, 3:41:10.31 SNMPv2-MIB::snmpTrapOID.0 = OID: FORTINET-FORTIGATE-
MIB::fgTrapAvOversize FORTINET-CORE-MIB::fnSysSerial.0 = STRING: FG140P3G15800330 SNMPv2-
MIB::sysName.0 = STRING: FortiGate-140D-POE
The SNMP DHCP event contains three traps and one query.
Traps are sent when:
l DHCP server IP pool usage reaches 90%
l DHCP server detect an IP address that is already in use
l DHCP client receives DHCP NAK
SNMP queries are accepted for DHCP lease usage information (OID = 1.3.6.1.4.1.12356.101.23). The query result is
based on the leased out percentage.
5. Click OK.
config hosts
edit 1
set ip 10.1.100.11 255.255.255.255
next
edit 2
set ip 172.16.200.55 255.255.255.255
next
end
set events dhcp
next
end
config system snmp user
edit "1"
set notify-hosts 172.10.1.0 172.20.1.0
set events dhcp
set security-level auth-priv
set auth-proto sha384
set auth-pwd ********************
set priv-proto aes256
set priv-pwd *********************
next
end
Replacement messages
FortiOS has replacement messages that are HTML and text files. These messages can be customized to meet user
requirements. The content can be modified, and images can be added.
The Replacement Messages page has two views. Simple View (the default view) shows the most commonly used
replacement messages. Extended View shows the entire list and all replacement message categories.
4. Click Save.
Click Restore Defaults to return to the original message and code base.
For example, to modify the Traffic Quota Limit Exceeded Page message:
config system replacemsg traffic-quota "per-ip-shaper-block"
set buffer "<html>
<head>
<title>
Traffic Quota Control
</title>
</head>
<body>
<font size=2>
<table width=\"100%\">
<tr>
<td bgcolor=#3300cc align=\"center\" colspan=2>
<font color=#ffffff>
<b>
Traffic blocked because exceeded session quota
</b>
</font>
</td>
</tr>
</table>
<br>
<br>
Traffic blocked because it exceeded the per IP shaper session quota. Please contact
The supported image formats are GIF, JPEG, TIFF, and PNG. The maximum file size
supported is 24 KB.
6. Click OK.
The file is now visible in the list.
2. Edit the replacement message, and include %%IMAGE:<image name>%% in the code to add the image.
Replacement message groups allow users to customize replacement messages for individual policies and profiles.
There are two types of replacement message groups:
The messages added to a group do not need to be customized. The message body content, header type, and format will
use the default values if not customized.
In the following example, two replacement message groups are created. The UTM message group includes custom
mail-related messages and is assigned to an email filter profile. The authentication message group has a custom
authentication success message that is applied to a proxy-based firewall policy that has an assigned email filter profile.
f. Click OK.
2. Customize the replacement messages in the newutm group:
a. Go to System > Replacement Message Groups.
b. Edit the newutm group.
c. Select the AV Engine Load Error Email Block Message.
f. Click OK.
4. Apply the newutm replacement message group to an email filter profile in the CLI:
config emailfilter profile
edit "newmsgs"
set replacemsg-group "newutm"
next
end
5. Apply the newauth replacement message group and the email filter profile to a firewall policy in the CLI:
config firewall policy
edit 1
...
set replacemsg-override-group "newauth"
set inspection-mode proxy
set emailfilter-profile "newmsgs"
...
next
end
FortiGuard
FortiGuard services can be purchased and registered to your FortiGate unit. The FortiGate must be connected to the
Internet in order to automatically connect to the FortiGuard Distribution Network (FDN) to validate the license and
download FDN updates.
The FortiGuard subscription update services include:
l Antivirus (AV)
l Intrusion Protection Service (IPS)
l Application Control
l Antispam
l Web Filtering
l Web Application Firewall (WAF)
To view FDN support contract information, go to System > FortiGuard. The License Information table shows the status of
your FortiGate’s support contract.
l IPv6 FortiGuard connections on page 910
l Configuring FortiGuard updates on page 911
l Manual updates on page 912
l Automatic updates on page 912
l Sending malware statistics to FortiGuard on page 914
l Update server location on page 915
l Filtering on page 915
l Override FortiGuard servers on page 917
l Online security tools on page 917
l FortiGuard anycast and third-party SSL validation on page 918
l Using FortiManager as a local FortiGuard server on page 920
l Cloud service communication statistics on page 921
l IoT detection service on page 922
l FortiAP query to FortiGuard IoT service to determine device details on page 924
The Fortinet DNS can resolve FortiGuard related servers to both IPv4 and IPv6 addresses. FortiOS daemons (update,
forticldd, url) connect using either IPv4 or IPv6 addresses. The first available connection will be used for updates or the
rating service.
1. Go to System > FortiGuard
2. Scroll down to the FortiGuard Updates section.
3. Configure the antivirus and IPS options for connecting and downloading definition files:
Accept push updates Enable to allow updates to be sent automatically to your FortiGate. New
definitions will be added as soon as they are released by FortiGuard. See
Push updates on page 913.
Use override push Only available if Accept push updates is enabled. See Override push on page
913.
Scheduled Updates Enable to schedule updates to be sent to the FortiGate at the specified time.
See Scheduled updates on page 912.
Improve IPS quality Enable to send information to the FortiGuard servers when an attack occurs.
This can help keep the FortiGuard database current as attacks evolve, and
improve IPS signatures.
Use extended IPS signature Enable to use the extended IPS database, that includes protection from legacy
package attacks, along with the regular IPS database that protects against the latest
common and in-the-wild attacks.
Update server location The FortiGuard update server location. See Update server location on page
915 for details.
4. Click Apply.
Manual updates
When needed, FortiGuard Distribution Network (FDN) updates can be manually uploaded.
8. Click OK.
Automatic updates
The FortiGate can be configured to request updates from FDN on a schedule, or via push notification.
Scheduled updates
Scheduling updates ensures that the virus and IPS definitions are downloaded to your FortiGate on a regular basis.
Updating definitions can cause a brief disruption in traffic that is currently being scanned while the FortiGate unit applies
the new signature database. Updates should be scheduled during off-peak hours when network usage is at a minimum
to ensure that network activity will not be affected by downloading the definitions files.
A schedule of once a week means any urgent updates will not be pushed until the scheduled
time. If an urgent update is required, click the Update Licenses & Definitions Now button to
manually update the definitions.
1. Go to System > FortiGuard
2. In the FortiGuard Updates section, enable Scheduled Updates.
4. Click Apply.
Push updates
Push updates enable you to get immediate updates when new viruses or intrusions are discovered and new signatures
are created. This ensures that the latest signature are sent to the FortiGate as soon as possible.
When a push notification occurs, the FortiGuard server sends a notice to the FortiGate that a new signature definition file
available. The FortiGate then initiates a download of the definition file. For maximum security, both scheduled and push
updates should be enabled.
1. Go to System > FortiGuard
2. In the FortiGuard Updates section, enable Accept push updates.
3. Click Apply.
Override push
If the FortiGate is behind a NAT device (or another FortiGate), or if your organization provides updates using their own
FortiGuard server, an override server must be used to ensure that the FortiGate receives push update notifications. The
FDS will connect to the NAT device when attempting to reach the FortiGate, and the NAT device must be configured to
forward FDS traffic to the FortiGate on UDP port 9443.
Push updates must be enabled to configure a push update override.
For example, if the NAT device is another FortiGate:
1. On the FortiGate NAT device, add a port forwarding virtual IP address in Policy & Objects > Virtual IPs. See for
details.
2. On the FortiGate NAT device, add a security policy that connects to the internet and includes the port forwarding
VIP.
3. On the internal FortiGate device, configure Push update override.
1. Go to System > FortiGuard
2. In the FortiGuard Updates section, enable Accept push updates.
3. Enable Use override push, and enter the IP address and port number configured on the NAT device.
4. Click Apply.
FortiGate devices periodically send encrypted antivirus, IPS, botnet IP list, and application control statistics to
FortiGuard. Included with these data is the IP address and serial number of the FortiGate, and the country that it is in.
This information is never shared with external parties, Fortinet Privacy Policy.
The malware statistics are used to improve various aspects of FortiGate malware protection. For example, antivirus data
allow FortiGuard to determine what viruses are currently active. Signatures for those viruses are kept in the Active AV
Signature Database that is used by multiple Fortinet products.Inactive virus signatures are moved to the Extended AV
Signature Database (see Configuring FortiGuard updates on page 911). When events for inactive viruses start
appearing in the malware data, the signatures are moved back into the AV Signature Database.
The FortiGate and FortiGuard servers go through a 2-way SSL/TLS 1.2 authentication before any data is transmitted.
The certificates used in this process must be trusted by each other and signed by the Fortinet CA server.
The FortiGate only accepts data from authorized FortiGuard severs. Fortinet products use DNS to find FortiGuard
servers and periodically update their FortiGate server list. All other servers are provided by a list that is updated through
the encrypted channel.
Malware statistics are accumulated and sent every 60 minutes by default.
To configure sharing this information, use the following CLI command:
config system global
set fds-statistics {enable | disable}
set fds-statistics-period <minutes>
end
The submission of malware data is in accordance with the Fortinet Privacy Policy.
There is no sensitive or personal information included in these submissions. Only malware
statistics are sent.
Fortinet uses the malware statistics collected in this manner to improve the performance of the
FortiGate services and to display statistics on the Fortinet Support website for customers
registered FortiGate devices.
Fortinet may also publish or share statistics or results derived from this malware data with
various audiences. The malware statistics shared in this way do not include any customer
data.
The location of the FortiGuard update server that the FortiGate connects to can be set to either only servers in the USA
only, or to the servers with the lowest latency.
On hardware FortiGate devices, the default is Lowest latency locations. On VM devices, the default is US only.
1. Go to System > FortiGuard
2. In the FortiGuard Updates section, set Update server location to US only or Lowest latency locations.
3. Click Apply.
Filtering
Web filtering is used to block access to harmful, inappropriate, and dangerous web sites (see FortiGuard filter on page
1142).
Email filtering is used to detect and block spam messages (see FortiGuard-based filters on page 1218).
1. Go to System > FortiGuard
2. Scroll down to the Filtering section.
Web Filter Cache Enable/disable web filter cache, and set the amount of time that the FortiGate
will store a blocked IP address or URL locally. After the time expires, the
FortiGate contacts the FDN to verify the address.
Email Filter Cache Enable/disable email filter cache, and set the amount of time that the FortiGate
will store an email address locally.
FortiGuard filtering services The protocol and port used to contact the FortiGuard servers. These options
can be changed in the CLI.
Filtering Service Availability The status of the filtering service. Click Test Connectivity if the filtering service
is not available.
Request re-evaluation of a Click to re-evaluate a URL category rating on the FortiGuard web filter service.
URL's category
4. Click Apply.
When anycast is enabled (by default) the protocol is HTTPS and the port is 443.
By default, FortiOS will update signature packages and query rating servers using public FortiGuard servers. This list
can be overridden by adding servers to the override server list. Communication with public FortiGuard servers can also
be disabled.
1. Go to System > FortiGuard
2. In the Override FortiGuard Servers table, click Create New. The Create New Override FortiGuard Server pane
opens.
FortiGuard Labs provides a number of online security tools, including but not limited to:
l URL lookup
Enter a website address to see if it has been rated and what category and classification it is filed as. If you find a site
that has been wrongly categorized, use this page to request that the site be re-evaluated:
https://www.fortiguard.com/webfilter
l Threat Encyclopedia
Browse FortiGuard Labs extensive encyclopedia of threats. Search for viruses, botnet C&C, IPS, endpoint
vulnerabilities, and mobile malware: https://www.fortiguard.com/encyclopedia
l Application Control
Browse FortiGuard Labs extensive encyclopedia of applications: https://www.fortiguard.com/appcontrol
Anycast optimizes routing performance to FortiGuard servers. It is the default FortiGuard access mode.
Using Fortinet DNS servers, the FortiGate receives a single IP address for the domain name of each FortiGuard service.
BGP routing optimization is transparent to the FortiGate. The domain name of each FortiGuard service is the common
name in that service's certificate, which is signed by a third-party intermediate CA. The FortiGuard server uses third-
party certificate verification and the Online Certificate Status Protocol (OCSP) stapling check, so that the FortiGate can
always validate the FortiGuard server certificate efficiently.
FortiGate will only complete the TLS handshake with an anycast server that has a good OCSP status for its certificate.
Any other status will result in a failed SSL connection. OCSP stapling is reflected on the signature interval so that good
means that the certificate is not revoked at that timestamp. The FortiGuard servers query the CA's OCSP responder
every four hours and update its OCSP status. If the FortiGuard is unable to reach the OCSP responder, it will keep the
last known OCSP status for up to seven days. This cached OCSP status will be sent out immediately when a client
connection request is made, optimizing the response time.
FortiGuard represents all cloud based servers; see Anycast and unicast services for details.
The anycast server has one IP address to match its domain name. The FortiGate connects with a single server address,
using HTTPS and port 443, regardless of where the FortiGate is located.
Connection process
1. The FortiGate embeds the CA_bundle certificate, which includes the root CA with CRL list and third-party
intermediate CA, in the root CA level.
2. The FortiGate finds the FortiGuard IP address from its domain name from DNS.
3. The FortiGate starts a TLS handshake with the FortiGuard IP address. The client hello includes an extension of the
status request.
4. The FortiGuard servers provide a certificate with its OCSP status: good, revoked, or unknown.
5. The FortiGate verifies the CA chain against the root CA in the CA_bundle.
6. The FortiGate verifies the intermediate CA's revoke status against the root CA's CRL.
7. The FortiGate verifies the FortiGuard certificate's OCSP status:
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: 3DD350A5D6A0ADEEF34A600A65D321D4F8F8D60F
Produced At: Aug 20 07:50:58 2019 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 49F4BD8A18BF760698C5DE402D683B716AE4E686
Issuer Key Hash: 3DD350A5D6A0ADEEF34A600A65D321D4F8F8D60F
Serial Number: 02555C9F3901B799DF1873402FA9392D
Cert Status: good
This Update: Aug 20 07:50:58 2019 GMT
Next Update: Aug 27 07:05:58 2019 GMT
8. Once the SSL handshake is established, the FortiGate can engage the server.
FortiManager can provide a local FortiGuard server with port 443 access.
Anycast FortiGuard settings force the rating process to use port 443, even with an override server. Using a unique
address in the same subnet as the FortiManager access IP address, the FortiManager can provide local FortiGuard
updates and rating access with a dedicated IP address and port 443.
When fmg-update-port is set to 443, the update process will use port 443 to connect to the override update server,
which is the local FortiGuard server in the FortiManager. If this is not set, the update process will use port 8890, and the
server address setting has to be the FortiManager access IP address. Override FortiGuard services come from the
server list that is the local FortiGuard server in the FortiManager, and use the traditional, non-OCSP TLS handshake. If
override servers in the FortiManager are not available, the default FortiGuard servers are connected, and the anycast
OCSP TLS handshake is used.
Fortinet service communications statistics are displayed on the FortiGuard page. The statistics correspond with the
output from diagnose sys service-communication. The traffic volume values in the GUI are the sums of data
from the last 24 hours.
1. Go to System > FortiGuard.
The Fortinet Service Communications statistics are displayed on the right side of the screen:
Internet of Things (IoT) detection is a subscription service that allows FortiGate to detect unknown devices in FortiGuard
that are not detected by the local Device Database (CIDB). When the service is activated, FortiGate can send device
information to the FortiGuard collection server. When a new device is detected, FortiGate queries the results from the
FortiGuard query for more information about the device.
This feature requires an IoT Detection Service license, which is part of the Enterprise and 360 Protection bundle, or can
be purchased on its own.
1. Disable the local device database in order to force all queries to go to FortiGuard.
# diagnose src-vis local-sig disable
2. Enable iotd debugs.
# diagnose debug application iotd -1
# diagnose debug enable
FortiGate sends the device data to the FortiGuard collection server.
FortiWiFi-60E # [iotd] recv request from caller size:61
[iotd] service:collect hostname: ip: fd:-1 request tlv_len:41
[iotd] txt(.....y...w.....Jasons-iPhone6....579=23..)
[iotd] hex
(02010007017903060f77fc0203000e4a61736f6e732d6950686f6e6536020400083537393d32330cf
f)
[iotd] service:collect hostname:qadevcollect.fortinet.net ip: fd:-1 got server hostname
[iotd] service:collect hostname:qadevcollect.fortinet.net ip:192.168.100.133 fd:-1 got
server ip
[iotd] service:collect hostname:qadevcollect.fortinet.net ip:192.168.100.133 fd:13
socket created
[iotd] service:collect hostname:qadevcollect.fortinet.net ip:192.168.100.133 fd:13
connecting
[iotd] fd:13 monitor event:pollout
[iotd] service:collect hostname:qadevcollect.fortinet.net ip:192.168.100.133 fd:13 build
req packet
[iotd] service:collect hostname:qadevcollect.fortinet.net ip:192.168.100.133 fd:13
collect resp:1(pending)
The FortiGuard collection server returns new device data to the FortiGuard query server.
[iotd] service:query hostname:qadevquery.fortinet.net ip:192.168.100.248 fd:17 got query
resp
[iotd] service:query hostname:qadevquery.fortinet.net ip:192.168.100.248 fd:17 id:0
total_len:48 header_len:16 tlv_len:32 confidence:100 mac:f8:87:f1:1f:ab:95
[iotd] service:query hostname:qadevquery.fortinet.net ip:192.168.100.248 fd:17
remaining_len:32 type:1 len:6
[iotd] service:query hostname:qadevquery.fortinet.net ip:192.168.100.248 fd:17 got tlv
category:'Mobile'
[iotd] service:query hostname:qadevquery.fortinet.net ip:192.168.100.248 fd:17
remaining_len:24 type:2 len:6
A FortiAP collects packets from devices and queries FortiGuard with the help of the FortiGate. Device detection results
are reported back to the FortiGate where this information is displayed. Querying the FortiGuard service requires an IoT
Detection Service license.
The following attributes can be configured in wireless-controller setting:
Attribute Description
device-weight <integer> Set the device upper limit of confidence (0 - 255, default = 1, 0 = disable).
device-holdoff <integer> Set the device lower limit of creation time, in minutes (0 - 60, default = 5).
device-idle <integer> Set the device upper limit of idle time, in minutes (0 - 14400, default = 1440).
Feature visibility
Feature visibility is used to control which features are visible in the GUI. This allows features that are not in use to be
hidden. Some features are also invisible by default and must be made visible before they can be configure in the GUI.
The visibility of a feature does not affect its functionality or configuration. Invisible features can still be configured using
the CLI.
Certificates
In most production environments, you want to use a certificate issued be your own PKI for deep packet inspection (DPI).
An existing Microsoft root CA can be used to issue a subordinate CA (sub CA) certificate that is installed as a DPI
certificate on the FortiGate.
Complete the following steps to create your own sub CA certificate and use it for DPI:
1. Create a Microsoft sub CA certificate
2. Export the certificate and private key
3. Import the certificate and private key into the FortiGate
4. Configure a firewall policy for DPI
5. Verify that the sub CA certificate is being used for DPI
The FortiGate firewall uses information in the original web server certificate, then issues a new certificate signed by the
Microsoft DPI certificate. The FortiGate then sends this certificate with the issuing DPI certificate to the client's web
browser when the SSL session is being established.
The browser verifies that the certificate was issued by a valid CA, then looks for the issuing CA of the Microsoft DPI
certificate in its loca trusted root CA store to complete the path to trusted root CA.
The Microsoft CA root certificate is normally deployed to all client PCs in the Windows domain, so the client can
complete the certificate path up to a trusted root CA. The FortiGate now controlsand can inspect the two HTTPS
sessions: one with the external web server, and one with the client PC.
A Microsoft sub CA certificate can be created on a Microsoft CA server, or remotely using a web browser.
Creating a certificate remotely requires that the web enrollment option is configured on the Microsoft CA server. Remote
certificate requests require HTTPS; requests are not allowed with HTTP.
l https://<IP-CA-server>/CertSrv.
5. Click Create and submit a request to this CA, then click Yes in the Web Access Confirmation warning.
6. For the Certificate Template, select Subordinate Certification Authority.
7. Enable Mark keys as exportable.
8. Fill out the remaining information according to your security policy.
1. Open the Microsoft Management Console (MMC) and add the Certificate Snap-in.
2. Go to the user's certificate store to locate the sub CA certificate that you just installed.
l Only the PKCS #12 (.PFX) format is available, and it requires a password.
l When selecting the encryption type, select TripleDES-SHA1 if you are using an older version of FortiOS (5.6.9
6. Complete the wizard, and save the DPI certificate to a local folder.
The certificate can be imported from the local computer using the GUI, or from a TFTP server using the CLI.
After importing the certificate, you can view it in the GUI to verify that it was successfully imported.
To import the certificate and private key into the FortiGate in the GUI:
7. Click OK.
To import the certificate and private key into the FortiGate in the CLI:
execute vpn certificate local import <certificate file name> <tftp ip address> <password>
1. Go to System > Certificates. By default, the Certificate option is not visible, see Feature visibility on page 925 for
information.
2. Locate the newly imported certificate in the table.
3. Select the certificate and click View Details to view the certificate details.
The certificate is used in an SSL/SSH inspection profile that is then used in a firewall policy.
4. Click Apply.
5. Go to Policy & Objects > Firewall Policy.
6. Create a new policy, or edit an existing policy.
7. In the SSL Inspection field, select the new SSL inspection profile.
You can verify that the certificate is being used for resigning web server certificates when a user connects to an external
HTTPS website.
A signed SSL certificate can be used when configuring SSL VPN, for administrator GUI access, and for other functions
that require a certificate.
Before creating a certificate, you must have a registered domain. With a valid FortiGuard
subscription, FortiDDNS can be used to register a domain; see DDNS on page 436 for more
information.
Follow these instructions to purchase, import, and use a signed SSL certificate:
l Obtain, setup, and download an SSL certificate package from a certificate authority
l Generate a CSR
l Import the signed certificate into your FortiGate
l Configure your FortiGate to use the signed certificate
Obtain, setup, and download an SSL certificate package from a certificate authority
SSL certificate packages can be purchased from any Certificate Authority (CA), such as DigiCert, GoDaddy, or
GlobalSign.
Let's Encrypt can be used to generate a free, trusted SSL certificate. See Provision a trusted
certificate with Let's Encrypt on page 934 for details.
A third party CA might not sign a certificate with an intranet name or IP address. For details,
see Can I request a certificate for an intranet name or IP address?
The process for purchasing, setting up, and downloading a certificate will vary depending on the CA that is used, and if a
CSR must be generated on the FortiGate.
1. Create an account with your chosen vendor, or use the account that you used to purchase your domain.
2. Locate the SSL Certificates page.
3. Purchase a basic SSL certificate for domain validation only. If required, a more secure SSL certificate can be
purchased.
4. If required, load the CSR, either by uploaded the text file or copying and pasting the contents into the requisite text
box. See Generate a CSR on page 932 for information on generating the CSR on the FortiGate.
5. If required, set the server type to Other.
6. Verify the certificate per the requirements of the CA.
7. Download the signed certificate to your computer.
8. Import the signed certificate into your FortiGate; see Import the signed certificate into your FortiGate on page 933.
Generate a CSR
Some CAs can auto-generate the CSR during the signing process, or provide tools for creating CSRs. If necessary, a
CSR can be created in your FortiGate device’s GUI.
1. Go to System > Certificates. By default, the Certificates option is not visible, see Feature visibility on page 925 for
information.
2. Click Generate. The Generate Certificate Signing Request page opens.
4. Click OK.
The CSR will be added to the certificate list with a status of PENDING.
5. In the certificate list, select the new CSR then click Download to save the CSR to your computer.
The CSR file can be opened in any text editor, and will resemble the following:
-----BEGIN CERTIFICATE REQUEST-----
MIICuTCCAaECAQAwSzEcMBoGA1UEAxMTZm9ydGlzc2x2cG5kZW1vLmNvbTErMCkG
CSqGSIb3DQEJARYcZm9ydGlzc2x2cG5kZW1vQGZvcnRpbmV0LmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtnpNoR20NH2+UEX/NsyCmZhQqc4af3
Be1u9iOoNbo9Fk42gw47r71moAN+1jTL/Tcp3hRhXtpgoI7Zh3vjZnBbD2wwU8Ow
U7d1h5MULyMehR9r4T6OAJl4KbKPt5u90r5SpIb6mM1OIKvzMncuRS66rW1St0KP
mp/f6QjpjMrthnyJkCejgyTA1YwWNuT9BcO6PTkxBqVMLaRP6TUH6He9uhOx1Cj/
5tzvSdAozZIr2moMieQy0lNd6oQcgpdzaB9QN41+cZOlUXRCMPoH7E4KUe3/Gnis
+NMdQ8rIBijvWCXrKj20wb6sUEjAGJkcXlqVHWYCKWXl6Owejmc4ipkCAwEAAaAp
MCcGCSqGSIb3DQEJDjEaMBgwCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwDQYJKoZI
hvcNAQELBQADggEBAJKhtz2BPIKeHH9HcJKnfBKL+a6vu1l+1sW+YqnyD+3oR9ec
0eCmLnPxyyxsVel/tRsUg4DTfmooLNDhOjgfMsWxAGUQgrDH2k87cw6kiDAPCqv1
b+hFPNKZQSd09+HXAvOpXrMlrw5YdSaoRnau6Q02yUIYennKTIzFIscgh1mk4FSe
mb12DhPF+QydDCGDgtqnQbfxlDC0WmDcmxwa/0ZktoQhhhEbYgJ2O7l4TMqOxs/q
AZgwJlSNGBALLA2AxkIRUMKUteDdXz0QE8xNrvZpLTbWCNIpYJdRRqSd5C1w2VF4
CFgugTjFaJ13kYmBimeMRQsFtjLV5AxN+bUUsnQ=
-----END CERTIFICATE REQUEST-----
After the signed certificates have been imported, you can use it when configuring SSL VPN, for administrator GUI
access, and for other functions that require a certificate.
To configure your FortiGate to use the signed certificate for SSL VPN:
To configure using the certificate for administrator GUI access in the CLI:
To change the certificate that is used for administrator GUI access in the GUI:
Let's Encrypt can be used to generate a free, trusted certificate that can be used by FortiGate to establish valid SSL
connections that do not generate certificate warnings. See the Let's Encrypt documentation for more information and
different methods of generating a trusted certificate.
Let's Encrypt certificates have 90 day lifespans. They recommend replacing the certificate
every 60 days.
Fortinet has a dynamic DNS service that you can use if you do not have your own domain. See
DDNS on page 436 for more information.
This example uses Certbot to satisfy proof of ownership and generation of the certificate. It is an ACME client with a built-
in, temporary webserver used for proof of domain ownership. Follow the instructions on the Certbot website to install the
correct version in your Linux environment; this example uses Debian.
The Certbot application must be reachable by Let's Encrypt on TCP port 80 on the IP address that your FQDN resolves
to.
You can use a VIP to forward requests to your Linux environment on port 80. In this example, the Linux environment has
the IP address 10.100.80.200.
To create a VIP to forward requests to your Linux environment on port 80 in the GUI:
1. Go to Policy & Objects > Virtual IPs and click Create New.
2. Enter a name for the VIP and set the interface.
3. Set the Mapped IP address/range to the IP address of the Linux environment, in this case 10.100.80.20.
4. Enable Port Forwarding, set Protocol to TCP, and set External service port and Map to port to 80.
5. Click OK.
To add the VIP to a policy to allow traffic to reach your Linux environment in the GUI:
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. Set Incoming Interface to the interface used in the VIP.
3. Set Destination to the VIP, in this example: Linux VM.
5. Click OK.
To import the certificate and private key into the FortiGate in the GUI:
1. Go to System > Certificates. By default, the Certificates option is not visible, see Feature visibility on page 925 for
information.
2. Click Import > Local Certificate.
3. Set Type to Certificate.
4. For Certificate File, upload the fullchain.pem file.
5. For Key File, upload the privkey.pem file.
6. Enter a password.
7. Optionally, change the Certificate Name.
8. Click OK.
After the signed certificates have been imported, you can use it when configuring SSL VPN, for administrator GUI
access, and for other functions that require a certificate.
To configure your FortiGate to use the signed certificate for SSL VPN:
To configure using the certificate for administrator GUI access in the CLI:
To change the certificate that is used for administrator GUI access in the GUI:
Configuration scripts
Configuration scripts are text files that contain CLI command sequences. They can be created using a text editor or
copied from a CLI console, either manually or using the Record CLI Script function.
Scripts can be used to run the same task on multiple devices. For example, if your devices use the same security
policies, you can enter or record the commands to create those policies in a script, and then run the script on each
device. You could also create the policies in the GUI, and then copy and paste the CLI commands from the CLI Console
using the show command.
If the FortiGate is managed by FortiManager, scripts can be uploaded to FortiManager and then run on any other
FortiGates that are managed by that FortiManager. See Scripts in the FortiManager Administration Guide.
A comment line in a script starts with the number sign (#). Comments are not executed.
Workspace mode
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
transaction.
All administrators can use workspace mode; their permissions in workspace mode are the same as defined in their
account profile.
A workspace mode transaction times out after 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:
config transaction id=1 will expire in 30 seconds
config transaction id=1 will expire in 20 seconds
config transaction id=1 will expire in 10 seconds
config transaction id=1 has expired
Diagnose commands
Custom languages
Custom languages can be uploaded and used for SSL VPN web portals. Custom languages must be enabled before
they can be added in the GUI.
RAID
Most FortiGate devices with multiple disk drives (SSD or HHD) can be configured to use RAID.
Enabling or disabling RAID, and changing the RAID level, erases all data on the log disk and
reboots the device.
Disk SSD1 ref: 255 223.6GiB type: SSD [ATA INTEL SSDSC2KB24] dev: /dev/sda
partition ref: 1 220.1GiB, 219.0GiB free mounted: Y label: LOGUSEDXA707476A dev:
/dev/sda1 start: 2048
Disk SSD2 ref: 16 223.6GiB type: SSD [ATA INTEL SSDSC2KB24] dev: /dev/sdb
partition ref: 17 62.7GiB, 62.4GiB free mounted: Y label: WANOPTXX1FEBBFA1 dev:
/dev/sdb1 start: 2048
partition ref: 18 63.7GiB, 63.7GiB free mounted: N label: dev: /dev/sdb2 start:
133625856
partition ref: 19 85.0GiB, 85.0GiB free mounted: N label: dev: /dev/sdb3 start:
267249664
Disk SSD1 ref: 255 223.6GiB type: SSD [ATA INTEL SSDSC2KB24] dev: /dev/sda
partition ref: 1 220.1GiB, 219.0GiB free mounted: Y label: LOGUSEDXA707476A dev:
/dev/sda1 start: 2048
Disk SSD2 ref: 16 223.6GiB type: SSD [ATA INTEL SSDSC2KB24] dev: /dev/sdb
partition ref: 17 62.7GiB, 62.4GiB free mounted: Y label: WANOPTXX1FEBBFA1 dev:
/dev/sdb1 start: 2048
partition ref: 18 63.7GiB, 63.7GiB free mounted: N label: dev: /dev/sdb2 start:
133625856
partition ref: 19 85.0GiB, 85.0GiB free mounted: N label: dev: /dev/sdb3 start:
267249664
Disk SYSTEM(boot) 14.9GiB type: SSD [ATA 16GB SATA Flash] dev: /dev/sdc
partition 247.0MiB, 155.0MiB free mounted: N label: dev: /dev/sdc1(boot) start: 1
partition 247.0MiB, 154.0MiB free mounted: Y label: dev: /dev/sdc2(boot) start: 524289
partition ref: 35 14.2GiB, 14.0GiB free mounted: Y label: dev: /dev/sdc3 start:
1048577
Disk USB-6(user-usb) ref: 48 28.6GiB type: USB [SanDisk Ultra] dev: /dev/sdd
<<<<<<===this info for usb disk because i have usb disk on FGT301E
partition ref: 49 28.6GiB, 28.6GiB free mounted: Y label: dev: /dev/sdd1 start: 0
l RAID enabled:
# execute disk raid status
RAID Level: Raid-1
RAID Status: OK (Background-Synchronizing) (9%)
RAID Size: 239GB
l RAID disabled:
# execute disk raid status
RAID Level: Unavailable
RAID Status: Unavailable
RAID Size: 0GB
To enable RAID:
Configuring raid...
- unmounting /data2 : ok
- unmounting /var/log : ok
- unmounting /usb : ok
- unmounting /var/storage/SSD2-WANOPTXX0EA0EF17 : ok
Configuring raid...
- unmounting /data2 : ok
- unmounting /var/log : ok
- unmounting /usb : ok
To disable RAID:
Configuring raid...
- unmounting /data2 : ok
- unmounting /var/log : ok
- unmounting /usb : ok
Policies
The firewall policy is the axis around which most features of the FortiGate revolve. Many firewall settings end up relating
to or being associated with the firewall policies and the traffic they govern. Any traffic going through a FortiGate has to be
associated with a policy. These policies are essentially discrete compartmentalized sets of instructions that control the
traffic flow going through the firewall. These instructions control where the traffic goes, how it is processed, if it is
processed, and whether or not it is allowed to pass through the FortiGate.
When the firewall receives a connection packet, it analyzes the source address, destination address, and service (by
port number). It also registers the incoming interface, the outgoing interface it needs to use, and the time of day. Using
this information, the FortiGate firewall attempts to locate a security policy that matches the packet. If a policy matches
the parameters, then the FortiGate takes the required action for that policy. If it is Accept, the traffic is allowed to proceed
to the next step. If the action is Deny or a match cannot be found, the traffic is not allowed to proceed.
The two basic actions at the initial connection are either Accept or Deny:
l If the action is Accept, the policy permits communication sessions. There may be other packet processing
instructions, such as requiring authentication to use the policy or restrictions on the source and destination of the
traffic.
l If the action is Deny, the policy blocks communication sessions, and you can optionally log the denied traffic. If no
security policy matches the traffic, the packets are dropped. A Deny security policy is needed when it is required to
log the denied traffic, also called violation traffic.
One other action can be associated with the policy:
l IPsec: this is an Accept action that is specifically for IPsec VPNs.
The following topics provide instructions on configuring policies:
l Firewall policy parameters on page 946
l Profile-based NGFW vs policy-based NGFW on page 947
l NGFW policy mode application default service on page 951
l Application logging in NGFW policy mode on page 953
l Policy views and policy lookup on page 954
l Policy with source NAT on page 956
l Policy with destination NAT on page 970
l Policy with Internet Service on page 984
l NAT64 policy and DNS64 (DNS proxy) on page 1001
l NAT46 policy on page 1004
For traffic to flow through the FortiGate firewall, there must be a policy that matches its parameters:
l Incoming interface(s)
l Outgoing interface(s)
l Source address(es)
l User(s) identity
l Destination address(es)
l Internet service(s)
l Schedule
l Service
Without all six (possibly eight) of these things matching, the traffic is declined.
Traffic flow initiated from each direction requires a policy, that is, if sessions can be initiated from both directions, each
direction requires a policy.
Just because packets can go from point A to point B on port X does not mean that the traffic can flow from point B to point
A on port X. A policy must be configured for each direction.
When designing a policy, there is often reference to the traffic flow, but most communication is two-way so trying to
determine the direction of the flow might be confusing. If traffic is HTTP web traffic, the user sends a request to the
website, but most of the traffic flow will be coming from the website to the user or in both directions? For the purposes of
determining the direction for a policy, the important factor is the direction of the initiating communication. The user is
sending a request to the website, so this is the initial communication; the website is responding so the traffic is from the
user's network to the Internet.
FortiOS does not perform a reverse-path check on reply traffic that matches an allowed
session based on the IP tuple. The request traffic can be sent on one interface and the reply
traffic could return on another interface.
Profile-based next-generation firewall (NGFW) mode is the traditional mode where you create a profile (antivirus, web
filter, and so on) and then apply the profile to a policy.
In policy-based NGFW mode, you allow applications and URL categories to be used directly in security policies, without
requiring web filter or application control profiles.
In policy-based mode:
l Central NAT is always enabled. If no Central SNAT policy exists, you must create one. See Central SNAT on page
963 for more information.
l Pre-match rules are defined separately from security policies, and define broader rules, such as SSL inspection and
user authentication.
If your FortiGate operates in NAT mode, rather than enabling source NAT in individual NGFW policies, go to Policy &
Objects > Central SNAT and add source NAT policies that apply to all matching traffic. In many cases, you may only
need one SNAT policy for each interface pair.
The NGFW mode is set per VDOM, and it is only available when the VDOM inspection mode is flow-based. You can
operate your entire FortiGate or individual VDOMs in NGFW policy mode.
config vdom
edit <vdom>
config system settings
set ngfw-mode policy-based
end
next
end
Security policies work with SSL Inspection & Authentication policies to inspect traffic. To allow traffic from a specific user
or user group, both Security and SSL Inspection & Authentication policies must be configured. A default SSL Inspection
& Authentication policy with the certificate-inspection SSL Inspection profile is preconfigured. Traffic will match the SSL
Inspection & Authentication policy first. If the traffic is allowed, packets are sent to the IPS engine for application, URL
category, user, and user group match, and then, if enabled, UTM inspection (antivirus, IPS, DLP, and email filter) is
performed.
SSL Inspection & Authentication policies are used to pre-match traffic before sending the packets to the IPS engine:
l There are no schedule or action options; traffic matching the policy is always redirected to the IPS engine.
l SSL inspection, formerly configured in the VDOM settings, is configured in an SSL Inspection & Authentication
policy.
l Users and user groups that require authentication must be configured in an SSL Inspection & Authentication policy.
Security policies work with SSL Inspection & Authentication policies to inspect traffic:
l Applications and URL categories can be configured directly in the policy.
l Users and user groups that require authentication must also be configured in a security policy.
l The available actions are Accept or Deny.
l The Service option can be used to enforce the standard port for the selected applications. See NGFW policy mode
application default service on page 951 for details.
l UTM inspection is configured in a security policy.
Logs
In the application control and web filter logs, securityid maps to the security policy ID.
Application control log:
date=2019-06-17 time=16:35:47 logid="1059028704" type="utm" subtype="app-ctrl"
eventtype="signature" level="information" vd="vd1" eventtime=1560814547702405829 tz="-0700"
appid=15832 user="Jack" group="QA" srcip=10.1.100.102 dstip=157.240.3.29 srcport=56572
dstport=443 srcintf="port18" srcintfrole="undefined" dstintf="port17"
dstintfrole="undefined" proto=6 service="P2P" direction="incoming" policyid=1
sessionid=42445 appcat="Social.Media" app="Facebook" action="pass" hostname="external-sea1-
1.xx.fbcdn.net" incidentserialno=1419629662 url="/" securityid=2 msg="Social.Media:
Facebook," apprisk="medium" scertcname="*.facebook.com" scertissuer="DigiCert SHA2 High
Assurance Server CA"
Traffic logs:
date=2019-06-17 time=16:35:53 logid="0000000013" type="traffic" subtype="forward"
level="notice" vd="vd1" eventtime=1560814553778525154 tz="-0700" srcip=10.1.100.102
srcport=56572 srcintf="port18" srcintfrole="undefined" dstip=157.240.3.29 dstport=443
dstintf="port17" dstintfrole="undefined" poluuid="b740d418-8ed3-51e9-5a7b-114e99ab6370"
sessionid=42445 proto=6 action="server-rst" user="Jack" group="QA" policyid=1
policytype="consolidated" centralnatid=1 service="HTTPS" dstcountry="United States"
srccountry="Reserved" trandisp="snat" transip=172.16.200.2 transport=56572 duration=6
sentbyte=276 rcvdbyte=745 sentpkt=5 rcvdpkt=11 appid=15832 app="Facebook"
appcat="Social.Media" apprisk="medium" utmaction="allow" countapp=1 utmref=65531-294
You can combine Application Control and Web Filter in the same NGFW mode policy.
The following security profiles can be used in NGFW policy-based mode:
l AntiVirus
l Web Filter
l Intrusion Prevention
l File Filter
l Email Filter
Logging can also be enabled in security policies.
In NGFW policy-based mode, the application default service enforces applications running only on their default service
port. The applications specified in the policy are monitored, and if traffic is detected from a nonstandard port, it is
blocked, and a log entry is recorded with a port-violation event type.
If you are not using the default ports, and need to pick specific services, select Specify to select the required services.
Example
In this example, the standard port is enforced for HTTPS traffic using the HTTP.Audio application.
First, an SSL Inspection & Authentication policy is created do to traffic pre-match, and then a security policy is created to
allow the HTTP.Audio application when using the default port. Fetching an MP3 file from an HTTP server using port 443
is allowed, but is blocked when using a nonstandard port, such as 8443.
To enforce the HTTP.Audio application using the default port in the GUI:
1. Create a new SSL Inspection & Authentication policy, or use the default policy.
2. Go to Policy & Objects > Security Policy, and click Create New.
3. Enter a name for the policy, such as allow_HTTP.Audio.
4. Configure the ports as needed.
5. Set Service to App Default.
6. In the Application field, select HTTP.Audio.
8. Click OK.
To enforce the HTTP.Audio application using the default port in the CLI:
Logs
The application logs show logs with an event type of port-violation for traffic on port 8443 that is blocked, and an
event type of signature for traffic on port 443 that is allowed.
Blocked:
2: date=2019-06-18 time=16:15:40 logid="1060028736" type="utm" subtype="app-ctrl"
eventtype="port-violation" level="warning" vd="vd1" eventtime=1560899740218875746 tz="-0700"
appid=15879 srcip=10.1.100.22 dstip=172.16.200.216 srcport=52680 dstport=8443
srcintf="port13" srcintfrole="undefined" dstintf="port14" dstintfrole="undefined" proto=6
service="HTTPS" direction="incoming" policyid=1 sessionid=5041 appcat="Video/Audio"
app="HTTP.Audio" action="block" hostname="172.16.200.216" incidentserialno=1906780850
url="/app_data/story.mp3" securityid=2 msg="Video/Audio: HTTP.Audio," apprisk="elevated"
Allowed:
1: date=2019-06-18 time=16:15:49 logid="1059028704" type="utm" subtype="app-ctrl"
eventtype="signature" level="information" vd="vd1" eventtime=1560899749258579372 tz="-0700"
appid=15879 srcip=10.1.100.22 dstip=172.16.200.216 srcport=54527 dstport=443
srcintf="port13" srcintfrole="undefined" dstintf="port14" dstintfrole="undefined" proto=6
service="HTTPS" direction="incoming" policyid=1 sessionid=5064 appcat="Video/Audio"
app="HTTP.Audio" action="pass" hostname="172.16.200.216" incidentserialno=1139663486
url="/app_data/story.mp3" securityid=2 msg="Video/Audio: HTTP.Audio," apprisk="elevated"
In NGFW policy mode, if an application, application category, or application group is selected on a security policy, and
traffic logging is set to UTM or All, then application control logs will be generated. In addition, when a signature is set to
the ACCEPT action under a security policy, all corresponding child signatures will be assessed and logged as well.
1. Go to Policy & Objects > Security Policy and configure a new policy for YouTube.
2. Set Action to ACCEPT and Log Allowed Traffic to Security Events.
This topic provides a sample of firewall policy views and firewall policy lookup.
Policy views
In Policy & Objects policy list page, there are two policy views: Interface Pair View and By Sequence view.
Interface Pair View displays the policies in the order that they are checked for matching traffic, grouped by the pairs of
Incoming and Outgoing interfaces. For example, all policies referencing traffic from WAN1 to DMZ are in one section.
The policies referencing traffic from DMZ to WAN1 are in another section. The sections are collapsible so that you only
need to look at the sections you want.
By Sequence displays policies in the order that they are checked for matching traffic without any grouping.
The default display is Interface Pair View. You can switch between the two views except if any or multiple-interfaces are
applied in the policy.
How Any or multiple-interfaces policy can change the Interface Pair View
The FortiGate unit automatically changes the view on the policy list page to By Sequence whenever there is a policy
containing any or multiple-interfaces as the Source or Destination interface. If the Interface Pair View is grayed out, it is
likely that one or more policies have used the any or multiple-interfaces.
When you use the any or multiple-interfaces, the policy goes into multiple sections because it might be any one of a
number of interface pairings. Policies are divided into sectioned using the interface pairings, for example, port1 to port2.
Each section has its own policy order. The order in which a policy is checked for matching criteria to a packet’s
information is based solely on the position of the policy within its section or within the entire list of policies. If the policy is
in multiple sections, FortiGate cannot place the policy in order in multiple sections. Therefore the view can only be By
Sequence.
Policy lookup
Sample configuration
This example uses the TCP protocol to show how policy lookup works:
1. In Policy & Objects policy list page, click Policy Lookup and enter the traffic parameters.
The following topics provide instructions on configuring policies with source NAT:
Static SNAT
Network Address Translation (NAT) is the process that enables a single device such as a router or firewall to act as an
agent between the Internet or Public Network and a local or private network. This agent acts in real time to translate the
source or destination IP address of a client or server on the network interface. For the source IP translation, this enables
a single public address to represent a significantly larger number of private addresses. For the destination IP translation,
the firewall can translate a public destination address to a private address. So we don't have to configure a real public IP
address for the server deployed in a private network.
We can subdivide NAT into two types: source NAT (SNAT) and destination NAT (DNAT). This topic is about SNAT, We
support three NAT working modes: static SNAT, dynamic SNAT, and central SNAT.
In static SNAT all internal IP addresses are always mapped to the same public IP address. This is a port address
translation, Since we have 60416 available port numbers, this one public IP address can handle the conversion of
60,416 internal IP addresses. See example below.
Sample configuration
The following example of static SNAT uses an internal network with subnet 10.1.100.0/24 (vlan20) and an external/ISP
network with subnet 172.16.200.0/24 (vlan30).
When the clients in internal network need to access the servers in external network, We need to translate IP addresses
from 10.1.100.0/24 to an IP address 172.16.200.0/24, In this example, we implement static SNAT by creating a firewall
policy.
For packets that match this policy, its source IP address is translated to the IP address of the outgoing interface.
Dynamic SNAT
Dynamic SNAT maps the private IP addresses to the first available public address from a pool of addresses. In the
FortiGate firewall, this can be done by using IP pools. IP pools is a mechanism that allows sessions leaving the FortiGate
firewall to use NAT. An IP pool defines a single IP address or a range of IP addresses to be used as the source address
for the duration of the session. These assigned addresses are used instead of the IP address assigned to that FortiGate
interface.
IP pool types
FortiGate uses four types of IPv4 IP pools. This topic focuses on some of the differences between them.
Overload
This type of IP pool is similar to static SNAT mode. We need to define an external IP range that contains one or more IP
addresses. When there is only one IP address it is almost the same as static SNAT, the outgoing interface address is
used. When it contains multiple IP addresses, it is equivalent to an extended mode of static SNAT.
For instance, if we define an overload type IP pool with two external IP addresses (172.16.200.1—172.16.200.2), since
there are 60,416 available port numbers per IP, this IP pool can handle 60,416*2 internal IP addresses.
The mapped IP address can be calculated from the source IP address. The index number of the address in the pool is
the remainder of the source IP address, in decimal, divided by the number addresses in the pool.
To calculate the decimal value of the source IP address, either use an online calculator, or use
the following equation:
a.b.c.d = a * (256)3 + b * (256)2 + c * (256) + d
For example:
192.168.0.1 = 192 * (256)3 + 168 * (256)2 + 0 * (256) + 1 = 3232235521
One-to-one
This type of IP pool means that the internal IP address and the external (translated) IP address match one-to-one. The
port address translation (PAT) is disabled when using this type of IP pool. For example, if we define a one-to-one type IP
pool with two external IP addresses (172.16.200.1 - 172.16.200.2), this IP pool only can handle two internal IP
addresses.
For the overload and one-to-one IP pool types, we do not need to define the internal IP range. For the fixed port range
type of IP pool, we can define both internal IP range and external IP range. Since each external IP address and the
number of available port numbers is a specific number, if the number of internal IP addresses is also determined, we can
calculate the port range for each address translation combination. So we call this type fixed port range. This type of IP
pool is a type of port address translation (PAT).
For instance, if we define one external IP address (172.16.200.1) and ten internal IP addresses (10.1.100.1-
10.1.100.10), we have translation IP+Port combination like following table:
This type of IP pool is also a type of port address translation (PAT). It gives users a more flexible way to control the way
external IPs and ports are allocated. Users need to define Block Size/Block Per User and external IP range. Block Size
means how many ports each Block contains. Block per User means how many blocks each user (internal IP) can use.
The following is a simple example:
l External IP Range: 172.16.200.1—172.16.200.1
l Block Size: 128
l Block Per User: 8
Result:
l Total-PBAs: 472 (60416/128)
l Maximum ports can be used per User (Internal IP Address): 1024 (128*8)
l How many Internal IP can be handled: 59 (60416/1024 or 472/8)
Sample configuration
Central SNAT
The central SNAT table enables you to define and control (with more granularity) the address translation performed by
FortiGate. With the NAT table, you can define the rules for the source address or address group, and which IP pool the
destination address uses.
While similar in functionality to IP pools where a single address is translated to an alternate address from a range of IP
addresses, with IP pools there is no control over the translated port. When using the IP pool for source NAT, you can
define a fixed port to ensure the source port number is unchanged. If no fixed port is defined, the port translation is
randomly chosen by FortiGate. With the central NAT table, you have full control over both the IP address and port
translation.
FortiGate reads the NAT rules from the top down until it hits a matching rule for the incoming address. This enables you
to create multiple NAT policies that dictate which IP pool is used based on the source address. NAT policies can be
rearranged within the policy list. NAT policies are applied to network traffic after a security policy.
The central SNAT table allows you to create, edit, delete, and clone central SNAT entries.
l The option to toggle NAT in central-snat-map policies has been added. Previously it was only shown in NGFW
policy-based mode.
l In the central SNAT policy dialog box, the port mapping fields for the original port have been updated to accept
ranges.
l If per VDOM NAT is enabled, NAT is skipped in firewall policy.
l The central SNAT window contains a table of all the central SNAT policies.
Sample configuration
When central NAT is enabled, Policy & Objects displays the Central SNAT section.
l Specify. You can specify the traffic filter protocol by setting the protocol number.
13. If you use the Overload type of IP pool, you can enable Explicit Port Mapping.
a. If you enable Explicit Port Mapping, set the Original Source Port to the start number of the source port range.
b. Set the Translated Port to the start number of the translated port range.
14. Click OK.
IPv4 and IPv6 central SNAT maps are displayed in the same table.
d. Click OK.
The matching SNAT traffic will be handled by the IPv6 central SNAT map.
Source NAT (SNAT) can be configured in IPv4 and IPv6 policies with virtual wire pair (VWP) interfaces, and between
VWP interfaces when central NAT is enabled.
To configure a policy using SNAT and a VWP interface when central NAT is disabled:
2. Create the IP pool. The IP pool must have a different subnet than the VWP peers.
config firewall ippool
edit "vwp-pool-1"
set startip 172.16.222.99
set endip 172.16.222.100
next
end
3. Create the IP pool. The IP pool must have a different subnet than the VWP peers.
config firewall ippool
edit "vwp-pool-1"
set startip 172.16.222.99
set endip 172.16.222.100
next
end
The following topics provide instructions on configuring policies with destination NAT:
l Static virtual IPs on page 970
l Virtual IP with services on page 972
l Virtual IPs with port forwarding on page 974
l Virtual server on page 976
Static Virtual IPs (VIP) are used to map external IP addresses to internal IP addresses. This is also called destination
NAT, where a packet's destination is being NAT'd, or mapped, to a different address.
Static VIPs are commonly used to map public IP addresses to resources behind the FortiGate that use private
IP addresses. A static on-to-one VIP is when the entire port range is mapped. A port forwarding VIP is when the mapping
is configured on a specific port or port range.
Some of the VIP configuration options are:
Setting Description
VIP Type l IPv4 (config firewall vip) - The source and destination are both IPv4.
l IPv6 (config firewall vip6) - The source and destination are both
IPv6.
l NAT46 (config firewall vip46) - The source if IPv4 and the
destination is IPv6.
l NAT64 (config firewall vip64) - The source if IPv6 and the
destination is IPv4.
Note: IPv6 is only available when IPv6 is enabled in the Feature Visibility. NAT46
and NAT64 are only available when IPv6 and NAT46 & NAT64 are enabled in the
Feature Visibility. IPv6 must be enabled so that the NAT46 & NAT64 option is
available.
Interface (extintf) The external interface that the firewall policy source interface must match.
For example, if the external interface is port1, then the VIP can be used in a policy
from port1 to port3, but not in a policy from port2 to port3.
If the external interface is any, then the VIP can be used in any firewall policy.
Setting Description
l load-balance (CLI only) - Load balance traffic.
l server-load-balance - Load balance traffic across multiple servers. SSL
processing can be offloaded to the FortiGate. This type of VIP is configure
from Policy & Objects > Virtual Servers.
l dns-translation (CLI only) - DNS translation.
External IP address/range In a static NAT VIP, the external IP address is the IP address that the FortiGate
(extip) listens for traffic on.
When the external interface in not any, 0.0.0.0 can be used to make the external
IP address equivalent to the external interface's IP address.
The external IP address is also used to perform SNAT fro the mapped server
when the server outbound traffic with a destination interface that matches the
external interface. The firewall policy must also have NAT enabled.
Mapped IP address/range The address or range that the internal resource is being mapped to.
(mappedip)
srcintf-filter (CLI only) Listen for traffic to the external IP address only on the specified interface.
While the external interface restricts the policies where the VIP can be used, it
does not restrict listening to only the external interface. To restrict listening to only
a specific interface, srcint-filter must be configured.
nat-source-vip (CLI only) Force all of the traffic from the mapped server to perform SNAT with the external
IP address, regardless of the destination interface.
If srcint-filter is defined, then nat-source-vip only forces SNAT to be
performed when the destination matches the srcintf-filter interface.
In both cases, the firewall policy must have NAT enabled.
arp-reply (CLI only) Enable/disable responding to ARP requests on the external IP address (default =
enable).
Source address (src-filter) Restrict the source IP address, address range, or subnet that is allowed to access
the VIP.
Port Forwarding (portforward) Enable port forwarding to specify the port (mappedport) to map to
If no services are configured, you can configure the protocol (protocol) to use
when forwarding packets, the external service port range (extport) to be
mapped to a port range on the destination network, and the mapped port range
(mappedport) on the destination network.
Sample configuration
1. Go to Policy & Objects > Virtual IPs and click Create New > Virtual IP.
2. Select a VIP Type based on the IP versions used.
3. Enter a unique name for the virtual IP and fill in the other fields:
4. Click OK.
Virtual IP with services is a more flexible virtual IP mode. This mode allows users to define services to a single port
number mapping.
This topic shows how to use virtual IP with services enabled. This example has one public external IP address. We map
TCP ports 8080, 8081, and 8082 to an internal WebServer TCP port 80. This allows remote connections to communicate
with a server behind the firewall.
Sample configuration
l Access 10.1.100.199:8081 from external network and FortiGate maps to 172.16.200.55:80 in internal network.
l Access 10.1.100.199:8082 from external network and FortiGate maps to 172.16.200.55:80 in internal network.
If you need to hide the internal server port number or need to map several internal servers to the same public IP address,
enable port-forwarding for Virtual IP.
This topic shows how to use virtual IPs to configure port forwarding on a FortiGate unit. This example has one public
external IP address. We map TCP ports 8080, 8081, and 8082 to different internal WebServers' TCP port 80. This allows
remote connections to communicate with a server behind the firewall.
Sample configuration
9. Click OK.
10. Follow the above steps to create two additional virtual IPs.
a. For one virtual IP:
l Use a different Mapped IP Address/Range, for example, 172.16.200.56.
11. Create a Virtual IP Group and put the above three virtual IPs into that group.
l Access 10.1.100.199:8081 from external network and FortiGate maps to 172.16.200.56:80 in internal network.
l Access 10.1.100.199:8082 from external network and FortiGate maps to 172.16.200.57:80 in internal network
Virtual server
This topic shows a special virtual IP type: virtual server. Use this type of VIP to implement server load balancing.
The FortiOS server load balancing contains all the features of a server load balancing solution. You can balance traffic
across multiple backend servers based on multiple load balancing schedules including:
l Static (failover)
l Round robin
l Weighted (to account for different sized servers or based on the health and performance of the server including
round trip time and number of connections)
The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL/TLS, and generic TCP/UDP and IP protocols.
Session persistence is supported based on the SSL session ID based on an injected HTTP cookie, or based on the
HTTP or HTTPS host. SSL/TLS load balancing includes protection from protocol downgrade attacks. Server load
balancing is supported on most FortiGate devices and includes up to 10,000 virtual servers on high end systems.
Sample topology
SSL/TLS offloading
FortiGate SSL/TLS offloading is designed for the proliferation of SSL/TLS applications. The key exchange and
encryption/decryption tasks are offloaded to the FortiGate unit where they are accelerated using FortiASIC technology
which provides significantly more performance than a standard server or load balancer. This frees up valuable resources
on the server farm to give better response to business operations. Server load balancing offloads most SSL/TLS
versions including SSL 3.0, TLS 1.0, and TLS 1.2, and supports full mode or half mode SSL offloading with DH key sizes
up to 4096 bits.
FortiGate SSL offloading allows the application payload to be inspected before it reaches your servers. This prevents
intrusion attempts, blocks viruses, stops unwanted applications, and prevents data leakage. SSL/TLS content inspection
supports TLS versions 1.0, 1.1, and 1.2 and SSL versions 1.0, 1.1, 1.2, and 3.0.
When creating a new virtual server, you must configure the following options:
l Virtual Server Type.
l Load Balancing Methods.
Select the protocol to be load balanced by the virtual server. If you select a general protocol such as IP, TCP, or UDP,
the virtual server load balances all IP, TCP, or UDP sessions. If you select specific protocols such as HTTP, HTTPS, or
SSL, you can apply additional server load balancing features such as Persistence and HTTP Multiplexing.
HTTP Select HTTP to load balance only HTTP sessions with the destination port number that matches the
Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions
to be load balanced (usually port 80 for HTTP sessions). You can enable HTTP Multiplexing. You
can also set Persistence to HTTP Cookie to enable cookie-based persistence.
HTTPS Select HTTPS to load balance only HTTPS sessions with the destination port number that matches
the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the
sessions to be load balanced (usually port 443 for HTTPS sessions). You can enable HTTP
Multiplexing. You can also set Persistence to HTTP Cookie to enable cookie-based persistence, or
you can set Persistence to SSL Session ID.
IMAPS Select IMAPS to load balance only IMAPS sessions with the destination port number that matches
the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the
sessions to be load balanced (usually port 993 for IMAPS sessions). You can also set Persistence
to SSL Session ID.
POP3S Select POP3S to load balance only POP3S sessions with the destination port number that matches
the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the
sessions to be load balanced (usually port 995 for POP3S sessions). You can also set Persistence
to SSL Session ID.
SMTPS Select SMTPS to load balance only SMTPS sessions with the destination port number that matches
the Virtual Server Port setting. Change Virtual Server Port to match the destination port of the
sessions to be load balanced (usually port 465 for SMTPS sessions). You can also set Persistence
to SSL Session ID.
SSL Select SSL to load balance only SSL sessions with the destination port number that matches the
Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions
to be load balanced. You can also set Persistence to SSL Session ID.
TCP Select TCP to load balance only TCP sessions with the destination port number that matches the
Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions
to be load balanced.
UDP Select UDP to load balance only UDP sessions with the destination port number that matches the
Virtual Server Port setting. Change Virtual Server Port to match the destination port of the sessions
to be load balanced.
IP Select IP to load balance all sessions accepted by the security policy that contains this virtual
server.
The load balancing method defines how sessions are load balanced to real servers.
All load balancing methods do not send traffic to real servers that are down or not responding. FortiGate can only
determine if a real server is not responding by using a health check monitor. You should always add at least one health
check monitor to a virtual server or to real servers; otherwise load balancing might try to distribute sessions to real
servers that are not functioning.
Static The traffic load is statically spread evenly across all real servers. Sessions are not assigned
according to how busy individual real servers are. This load balancing method provides some
persistence because all sessions from the same source address always go to the same real server.
Because the distribution is stateless, so if a real server is added, removed, or goes up or down, the
distribution is changed and persistence might be lost.
Round Robin Directs new requests to the next real server. This method treats all real servers as equals
regardless of response time or the number of connections. This method does not direct requests to
real servers that down or non responsive.
Weighted Real servers with a higher weight value receive a larger percentage of connections. Set the real
server weight when adding a real server.
Least Session Directs requests to the real server that has the least number of current connections. This method
works best in environments where the real servers or other equipment you are load balancing all
have similar capabilities. This load balancing method uses the FortiGate session table to track the
number of sessions being processed by each real server. The FortiGate unit cannot detect the
number of sessions actually being processed by a real server.
Least RTT Directs sessions to the real server with the lowest round trip time. The round trip time is determined
by a ping health check monitor. The default is 0 if no ping health check monitors are added to the
virtual server.
First Alive Directs sessions to the first live real server. This load balancing schedule provides real server
failover protection by sending all sessions to the first live real server. If a real server fails, all
sessions are sent to the next live real server. Sessions are not distributed to all real servers so all
sessions are processed by the first real server only.
HTTP Host Load balances HTTP host connections across multiple real servers using the host’s HTTP header
to guide the connection to the correct real server.
In the FortiGate GUI, you can configure health check monitoring so that the FortiGate unit can verify that real servers are
able respond to network connection attempts. If a real server responds to connection attempts, the load balancer
continues to send sessions to it. If a real server stops responding to connection attempts, the load balancer assumes
that the server is down and does not send sessions to it. The health check monitor configuration determines how the
load balancer tests real servers. You can use a single health check monitor for multiple load balancing configurations.
You can configure TCP, HTTP, and Ping health check monitors. You usually set the health check monitor to use the
same protocol as the traffic being load balanced to it. For example, for an HTTP load balancing configuration, you would
normally use an HTTP health check monitor.
Session persistence
Use persistence to ensure a user is connected to the same real server every time the user makes an HTTP, HTTPS, or
SSL request that is part of the same user session. For example, if you are load balancing HTTP and HTTPS sessions to
a collection of eCommerce web servers, when users make a purchase, they will be starting multiple sessions as they
navigate the eCommerce site. In most cases, all the sessions started by this user during one eCommerce session
should be processed by the same real server. Typically, the HTTP protocol keeps track of these related sessions using
cookies. HTTP cookie persistence ensure all sessions that are part of the same user session are processed by the same
real server.
When you configure persistence, the FortiGate unit load balances a new session to a real server according to the load
balance method. If the session has an HTTP cookie or an SSL session ID, the FortiGate unit sends all subsequent
sessions with the same HTTP cookie or SSL session ID to the same real server.
Real servers
Add real servers to a load balancing virtual server to provide information the virtual server requires to send sessions to
the server. A real server configuration includes the IP address of the real server and port number the real server receives
sessions on. The FortiGate unit sends sessions to the real server’s IP address using the destination port number in the
real server configuration.
When configuring a real server, you can also specify the weight (if the load balance method is set to Weighted) and you
can limit the maximum number of open connections between the FortiGate unit and the real server. If the maximum
number of connections is reached for the real server, the FortiGate unit automatically switches all further connection
requests to other real servers until the connection number drops below the limit. Setting Maximum Connections to 0
means that the FortiGate unit does not limit the number of connections to the real server.
This example describes the steps to configure the load balancing configuration below. In this configuration, a FortiGate
unit is load balancing HTTP traffic from the Internet to three HTTP servers on the internal network. HTTP sessions are
accepted at the wan1 interface with destination IP address 172.20.120.121 on TCP port 8080, and forwarded from the
internal interface to the web servers. When forwarded, the destination address of the session is translated to the IP
address of one of the web servers.
This load balancing configuration also includes session persistence using HTTP cookies, round-robin load balancing,
and TCP health monitoring for the real servers. Ping health monitoring consists of the FortiGate unit using ICMP ping to
ensure the web servers can respond to network traffic.
General steps:
To see the virtual servers and health check monitors options in the GUI, Load Balance must be
selected in Feature Visibility > Additional Features. See Feature visibility on page 925 on page
1 for details.
l Type to Ping
l Interval to 10 seconds
l Timeout to 2 seconds
l Retry to 3 attempt(s)
4. Click OK.
l Type to HTTP
l Interface to wan1
l IP Address to 10.31.101.30
l Port to 80
l Max Connections to 0
l Mode to Active
6. Configure two more real servers with IP addresses 10.31.101.40 and 10.31.101.50, and the remaining settings the
same as the first real server.
7. Click OK.
To create a security policy that includes the load balance virtual server as the destination address:
l Source to all
l Destination to Vserver-HTTP-1
l Schedule to always
l Service to ALL
l Action to ACCEPT
5. Enable NAT and set IP Pool Configuration to Use Outgoing Interface Address.
6. Enable AntiVirus and select an antivirus profile.
7. Click OK.
To configure HTTP load balancing to three real web servers in the CLI:
3. Add the load balancing virtual server to a policy as the destination address:
config firewall policy
edit 2
set name "LB-policy"
set inspection-mode proxy
set srcintf "wan1"
set dstintf "internal"
set srcaddr "all"
set dstaddr "Vserver-HTTP-1"
set action accept
Results
The following topics provide instructions on configuring policies with Internet Service:
l Using Internet Service in policy on page 984
l Using custom Internet Service in policy on page 986
l Using extension Internet Service in policy on page 988
l Global IP address information database on page 991
l IP reputation filtering on page 993
l Internet service groups in policies on page 994
l Allow creation of ISDB objects with regional information on page 998
l Internet service customization on page 1000
This topic shows how to apply a predefined Internet Service entry into a policy.
The Internet Service Database is a comprehensive public IP address database that combines IP address range, IP
owner, service port number, and IP security credibility. The data comes from the FortiGuard service system. Information
is regularly added to this database, for example, geographic location, IP reputation, popularity & DNS, and so on. All this
information helps users define Internet security more effectively. You can use the contents of the database as criteria for
inclusion or exclusion in a policy.
From FortiOS version 5.6, Internet Service is included in the firewall policy. It can be applied to a policy only as a
destination object. From version 6.0, Internet Service can be applied both as source and destination objects in a policy.
You can also apply Internet Services to shaping policy.
There are three types of Internet Services you can apply to a firewall policy:
l Predefined Internet Services
l Custom Internet Services
l Extension Internet Services
Sample configuration
In the CLI, enable the internet-service first and then use its ID to apply the policy.
This example uses Google Gmail and its ID is 65646. Each Internet Service has a unique ID.
config firewall policy
edit 9
set name "Internet Service in Policy"
set srcintf "wan2"
set dstintf "wan1"
set srcaddr "all"
set internet-service enable
set internet-service-id 65646
set action accept
set schedule "always"
set utm-status enable
Result
Because the IP and services related to Google Gmail on the Internet are included in this Internet Service (65646), all
traffic to Google Gmail is forwarded by this policy.
CLI syntax
config firewall internet-service-custom
edit <name>
set comment <comment>
set reputation {1 | 2 | 3 | 4 | 5}
config entry
edit <ID>
set protocol <protocol #>
set dst <object_name>
config port-range
edit <ID>
set start-port <port #>
set end-port <port #>
next
end
next
end
end
end
Sample configuration
Result
In addition to the IP address, IP address ranges, and services allowed by Google.Gmail, this policy also allows the traffic
which access to 10.1.100.0/24 and TCP/80-443 and 172.16.200.0/24 and TCP/80.
Extension Internet Service lets you add custom or remove existing IP address and port ranges to an existing predefined
Internet Service entries. Using an extension type Internet Service is actually editing a predefined type Internet Service
entry and adding IP address and port ranges to it.
When creating an extension Internet Service and adding custom ranges, you must set following elements:
l IP or IP ranges
l Protocol number
l Port or port ranges
You must use CLI to add custom IP address and port entries into a predefined Internet Service.
You must use GUI to remove entries from a predefined Internet Service.
Sample configuration
5. Click Return.
6. When you complete the actions in the GUI, the CLI automatically generates the configuration from your GUI actions:
config firewall internet-service-extension
edit 65646
Result
In addition to the IP addresses, IP address ranges, and services allowed by Google.Gmail, this policy also allows the
traffic which accesses 10.1.100.0/24 and UDP/53 and 172.16.200.0/24 and TCP/80-443. At the same time, the traffic
that accesses 2.20.183.160 is dropped because this IP address and port is disabled from Google.Gmail.
The Internet Service and IP Reputation databases download details about public IP address, including: ownership,
known services, geographic location, blocklisting information, and more. The details are available in drilldown
information, tooltips, and other mechanisms in the FortiView and other pages.
The global IP address database is an integrated database containing all public IP addresses, and is implemented in the
Internet Service Database.
Number of Groups: 7
Group(0), Singularity(20), Number of IP ranges(142740)
Group(1), Singularity(19), Number of IP ranges(1210)
Group(2), Singularity(16), Number of IP ranges(241)
Group(3), Singularity(15), Number of IP ranges(38723)
Group(4), Singularity(10), Number of IP ranges(142586)
Group(5), Singularity(8), Number of IP ranges(5336)
Group(6), Singularity(6), Number of IP ranges(113891)
Internet Service: 2818238(Tor.Relay.Node)
Number of IP range: 13718
Number of IP numbers: 13718
Singularity: 20
Reputation: 2(Sites providing high risk services such as TOR, proxy, P2P, etc.)
Icon Id: 43
Second Level Domain: 1(other)
Direction: dst
Data source: irdb
IP reputation filtering
There are currently five reputation levels in the Internet Service Database (ISDB), and custom reputation levels can be
defined in a custom internet service. You can configure firewall policies to filter traffic according to the desired reputation
level. If the reputation level of either the source or destination IP address is equal to or greater than the level set in the
policy, then the packet is forwarded, otherwise, the packet is dropped.
The five default reputation levels are:
1 Known malicious sites, such as phishing sites or sites related to botnet servers
3 Unverified sites
5 Known and verified safe sites, such as Gmail, Amazon, and eBay
The default minimum reputation level in a policy is zero, meaning that the reputation filter is disabled.
For IP addresses that are not included in the ISDB, the default reputation level is three.
The default reputation direction is destination.
To set the reputation level and direction in a policy using the CLI:
Packets from the source IP address with reputation levels three, four, or five will be forwarded by this policy.
This feature provides support for Internet Service Groups in traffic shaping and firewall policies. Service groups can be
used as the source and destination of the policy. Internet Service Groups are used as criteria to match traffic; the shaper
will be applied when the traffic matches.
To use a group as a destination, internet-service must be enabled. To use a group as a source, internet-
service-src must be enabled.
The following CLI variables are available in the firewall policy and firewall shaping-policy commands:
Variable Description
Variable Description
Examples
Example 1
In this example, the PC is allowed to access Google, so all Google services are put into an Internet Service Group.
To configure access to Google services using an Internet Service Group using the CLI:
2. Create a firewall policy to allow access to all Google Services from the PC:
config firewall policy
edit 1
set name "PC to Google"
set srcintf "port2"
set dstintf "port1"
set srcaddr "PC"
set internet-service enable
set internet-service-group "Google_Group"
set action accept
set schedule "always"
set fsso disable
set nat enable
next
end
To configure access to Google services using an Internet Service Group in the GUI:
Example 2
In this example, two office FTP servers are put into an Internet Custom Service Group, and the PC connection to the FTP
servers is limited to 1Mbps.
To put two FTP servers into a custom service group and limit the PC connection speed to them using
the CLI:
edit 1
config port-range
edit 1
set start-port 21
set end-port 21
next
end
set dst "PM_Server"
next
end
next
edit "FTP_QA"
config entry
edit 1
config port-range
edit 1
set start-port 21
set end-port 21
next
end
set dst "QA_Server"
next
end
next
end
2. Create a custom internet server group and add the just created custom internet services to it:
config firewall internet-service-custom-group
edit "Internal_FTP"
set member "FTP_QA" "FTP_PM"
next
end
4. Create a firewall shaping policy to limit the speed from the PC to the internal FTP servers:
config firewall shaping-policy
edit 1
set name "For Internal FTP"
set internet-service enable
set internet-service-custom-group "Internal_FTP"
set dstintf "port1"
set traffic-shaper "Internal_FTP_Limit_1Mbps"
set traffic-shaper-reverse "Internal_FTP_Limit_1Mbps"
set srcaddr "PC"
next
end
To put two FTP servers into a custom service group and limit the PC connection speed to the using the
GUI:
1. Create custom internet services for the internal FTP servers using the CLI.
2. Create a custom internet server group and add the just created custom internet services to it using the CLI.
3. Create a traffic shaper to limit the maximum bandwidth:
a. Go to Policy & Objects > Traffic Shapers, and click Create New.
b. Enter a Name for the shaper, such as Internal_FTP_Limit_1Mbps.
c. Set the Traffic Priority to Medium.
d. Enable Max Bandwidth and set it to 1000.
e. Enable Guaranteed Bandwidth and set it to 500.
f. Click OK.
4. Create a firewall shaping policy to limit the speed from the PC to the internal FTP servers:
a. Go to Policy & Objects > Traffic Shaping Policy, and click Create New.
b. Set the Destination as the just created Custom Internet Service Group, and apply the just create traffic shaper.
Geographic-based Internet Service Database (ISDB) objects allow users to define a country, region, and city. These
objects can be used in firewall policies for more granular control over the location of the parent ISDB object. ISDB
objects are now referenced in policies by name instead of ID.
c. Click OK.
2. View the IP ranges in the location-based internet service:
a. Go to Policy & Objects > Internet Service Database .
b. In the table, hover over the object created in step 1 and click View/Edit Entries. The list of IPs is displayed:
c. Click Return.
3. Add the ISDB object to a policy:
a. Go to Policy & Objects > Firewall Policy. Create a new policy or edit an existing policy.
b. For Destination, click Internet Service and select the ISDB object created in step 1.
c. Configure the other settings as needed.
d. Click OK.
Internet Service Database (ISDB) entries can be tuned for their environments by adding custom ports and port ranges,
as well as port mapping.
NAT64 policy translates IPv6 addresses to IPv4 addresses so that a client on an IPv6 network can communicate
transparently with a server on an IPv4 network.
NAT64 policy is usually implemented in combination with the DNS proxy called DNS64. DNS64 synthesizes AAAA
records from A records and is used to synthesize IPv6 addresses for hosts that only have IPv4 addresses. DNS proxy
and DNS64 are interchangeable terms.
Sample topology
In this example, a host on the internal IPv6 network communicates with ControlPC.qa.fortinet.com that only has
IPv4 address on the Internet.
1. The host on the internal network does a DNS lookup for ControlPC.qa.fortinet.com by sending a DNS query
for an AAAA record for ControlPC.qa.fortinet.com.
2. The DNS query is intercepted by the FortiGate DNS proxy. The DNS proxy performs an A-record query for
ControlPC.qa.fortinet.com and gets back an RRSet containing a single A record with the IPv4 address
172.16.200.55.
3. The DNS proxy then synthesizes an AAAA record. The IPv6 address in the AAAA record begins with the configured
NAT64 prefix in the upper 96 bits and the received IPv4 address in the lower 32 bits. By default, the resulting IPv6
address is 64:ff9b::172.16.200.55.
4. The host on the internal network receives the synthetic AAAA record and sends a packet to the destination address
64:ff9b::172.16.200.55.
5. The packet is routed to the FortiGate internal interface (port10) where it is accepted by the NAT64 security policy.
6. The FortiGate unit translates the destination address of the packets from IPv6 address
64:ff9b::172.16.200.55 to IPv4 address 172.16.200.55 and translates the source address of the packets
to 172.16.200.200 (or another address in the IP pool range) and forwards the packets out the port9 interface to
the Internet.
Sample configuration
To enable display for IPv6, NAT46/NAT64, and DNS Database using the GUI:
l DNS Database
4. Click Apply.
To enable display for IPv6, NAT46/NAT64, and DNS Database using the CLI:
Enabling NAT64 with the config system nat64 command means that all IPv6 traffic received by the current VDOM
can be subject to NAT64 if the source and destination address matches an NAT64 security policy.
By default, the setting always-synthesize-aaaa-record is enabled. If you disable this setting, the DNS proxy
(DNS64) will attempt to find an AAAA records for queries to domain names and therefore resolve the host names to IPv6
addresses. If the DNS proxy cannot find an AAAA record, it synthesizes one by adding the NAT64 prefix to the A record.
nat64-prefix setting is the nat64 prefix. By default, it is 64:ff9b::/96.
config system nat64
set status enable
end
NAT46 policy
NAT46 refers to the mechanism that allows IPv4 addressed hosts to communicate with IPv6 hosts. Without such a
mechanism, IPv4 environments cannot connect to IPv6 networks.
Sample topology
In this example, an IPv4 client tries to connect to an IPv6 server. A VIP is configured on FortiGate to map the server IPv6
IP address 2000:172:16:200:55 to an IPv4 address 10.1.100.55. On the other side, an IPv6 IP pool is configured
and the source address of packets from client are changed to the defined IPv6 address. In this setup, the client PC can
access the server by using IP address 10.1.100.55.
Sample configuration
Sample troubleshooting
Local-in policies
While security profiles control traffic flowing through the FortiGate, local-in policies control inbound traffic that is going to
a FortiGate interface.
Administrative access traffic (HTTPS, PING, SSH, and others) can be controlled by allowing or denying the service in the
interface settings. Trusted hosts can be configured under an administrator to restrict the hosts that can access the
administrative service.
Local-in policies allow administrators to granularly define the source and destination addresses, interface, and services.
Traffic destined for the FortiGate interface specified in the policy that meets the other criteria is subject to the policies
action.
Local-in policies can be used to restrict administrative access or other services, such as VPN, that can be specified as
services. You can define source addresses or address groups to restrict access from. For example, by using a
geographic type address you can restrict a certain geographic set of IP addresses from accessing the FortiGate.
By default, no local-in policies are defined, so there are no restrictions on local-in traffic.
Local-in policies can only be created or edited in the CLI. You can view the existing local-in
policies in the GUI by enabling it in System > Feature Visibility under the Additional Features
section. This page does not list the custom local-in policies.
For example, to prevent the source subnet 10.10.10.0/24 from pinging port1, but allow administrative access for PING
on port1:
config firewall address
edit "10.10.10.0"
set subnet 10.10.10.0 255.255.255.0
next
end
config firewall local-in-policy
edit 1
set intf "port1"
set srcaddr "10.10.10.0"
set dstaddr "all"
set service "PING"
set schedule "always"
next
end
3. The output of the debug flow shows that traffic is dropped by local-in policy 1:
# id=20085 trace_id=1 func=print_pkt_detail line=5746 msg="vd-root:0 received a packet
(proto=1, 10.10.10.12:1->192.168.2.5:2048) from port1. type=8, code=0, id=1, seq=128."
id=20085 trace_id=1 func=init_ip_session_common line=5918 msg="allocate a new session-
0017c5ad"
id=20085 trace_id=1 func=vf_ip_route_input_common line=2615 msg="find a route:
flag=80000000 gw-192.168.2.5 via root"
id=20085 trace_id=1 func=fw_local_in_handler line=474 msg="iprope_in_check() check
failed on policy 1, drop"
Additional options
To disable or re-enable the local-in policy, use the set status {enable | disable} command.
To dedicate the interface as an HA management interface, use the set ha-mgmt-intf-only enable command.
DoS protection
A Denial of Service (DoS) policy examines network traffic arriving at a FortiGate interface for anomalous patterns, which
usually indicates an attack.
A denial of service occurs when an attacking system starts an abnormally large number of sessions with a target system.
The large number of sessions slows down or disables the target system, preventing legitimate users from using it.
DoS policies are checked before security policies, preventing attacks from triggering more resource intensive security
protection and slowing down the FortiGate.
DoS anomalies
Predefined sensors are setup for specific anomalous traffic patterns. New DoS anomalies cannot be added by the user.
The predefined anomalies that can be used in DoS policies are:
tcp_syn_flood If the SYN packet rate of new TCP connections, including 2000 packets per second.
retransmission, to one destination IP address exceeds the
configured threshold value, the action is executed.
tcp_port_scan If the SYN packet rate of new TCP connections, including 1000 packets per second.
tcp_src_session If the number of concurrent TCP connections from one source 5000 concurrent sessions.
IP address exceeds the configured threshold value, the action
is executed.
tcp_dst_session If the number of concurrent TCP connections to one destination 5000 concurrent sessions.
IP address exceeds the configured threshold value, the action
is executed.
udp_flood If the UDP traffic to one destination IP address exceeds the 2000 packets per second.
configured threshold value, the action is executed.
udp_scan If the number of UDP sessions originating from one source IP 2000 packets per second.
address exceeds the configured threshold value, the action is
executed.
udp_src_session If the number of concurrent UDP connections from one source 5000 concurrent sessions.
IP address exceeds the configured threshold value, the action
is executed.
udp_dst_session If the number of concurrent UDP connections to one destination 5000 concurrent sessions.
IP address exceeds the configured threshold value, the action
is executed.
icmp_flood If the number of ICMP packets sent to one destination IP 250 packets per second.
address exceeds the configured threshold value, the action is
executed.
icmp_sweep If the number of ICMP packets originating from one source IP 100 packets per second.
address exceeds the configured threshold value, the action is
executed.
icmp_src_session If the number of concurrent ICMP connections from one source 300 concurrent sessions
IP address exceeds the configured threshold value, the action
is executed.
icmp_dst_session If the number of concurrent ICMP connections to one 1000 concurrent sessions
destination IP address exceeds the configured threshold value,
the action is executed.
ip_src_session If the number of concurrent IP connections from one source IP 5000 concurrent sessions.
address exceeds the configured threshold value, the action is
executed.
ip_dst_session If the number of concurrent IP connections to one destination IP 5000 concurrent sessions.
address exceeds the configured threshold value, the action is
executed.
sctp_flood If the number of SCTP packets sent to one destination IP 2000 packets per second
address exceeds the configured threshold value, the action is
executed.
sctp_scan If the number of SCTP sessions originating from one source IP 1000 packets per second
address exceeds the configured threshold value, the action is
executed.
sctp_src_session If the number of concurrent SCTP connections from one source 5000 concurrent sessions
IP address exceeds the configured threshold value, the action
is executed.
sctp_dst_session If the number of concurrent SCTP connections to one 5000 concurrent sessions
destination IP address exceeds the configured threshold value,
the action is executed.
For thresholds based on the number of concurrent sessions, blocking the anomaly will not allow more than the number of
concurrent sessions to be set as the threshold.
For example, if the period for a particular anomaly is 60 seconds, such as those where the threshold is measured in
concurrent sessions, after the 60 second timer has expired the number of allowed sessions that match the anomaly
criteria is reset to zero. This means that, if you allow 10 sessions through before blocking, after the 60 seconds has
elapsed, another 10 sessions will be allowed. The attrition of sessions from expiration should keep the allowed sessions
from reaching the maximum.
For rate based thresholds, where the threshold is measured in packets per second, the Block action prevents anomalous
traffic from overwhelming the firewall in two ways:
l continuous: Block packets once an anomaly is detected, and continue to block packets while the rate is above the
threshold. This is the default setting.
l periodical: After an anomaly is detected, allow the configured number of packets per second.
For example, if a DoS policy is configured to block icmp_flood with a threshold of 10pps, and a continuous ping is started
at a rate of 20pps for 1000 packets:
l In continuous mode, the first 10 packets are passed before the DoS sensor if triggered, and then the remaining 990
packets are blocked.
l In periodical mode, 10 packets are allowed to pass per second, so 500 packets are blocked in the 50 seconds
during which the ping is occuring.
The actual numbers of passed and blocked packets may not be exact, as fluctuations in the
rates can occur, but the numbers should be close to the defined threshold.
DoS policies
1. Go to Policy & Objects > IPv4 DoS Policy or Policy & Objects > IPv6 DoS Policy and click Create New.
If the option is not visible, enable DoS Policy in Feature Visibility. See Feature visibility on page 925 for details.
2. Configure the following:
Incoming Interface Enter the interface that the policy applies to.
The quarantine option is only available in the CLI. See Quarantine on page 1014 for
information.
l attacker: Block all traffic from the attacker's IP address, and add the
attacker's IP address to the banned user list.
quarantine-expiry Set the duration of the quarantine, in days, hours, and minutes (###d##h##m)
<###d##h##m> (1m - 364d23h59m, default = 5m). This option is available if quarantine is set
attacker.
quarantine-log {enable | Enable/disable quarantine logging (default = disable). This option is available if
disable} quarantine is set attacker.
threshold <integer> The number of detected instances per minute that triggers the anomaly action.
The default value varies depending on the anomaly.
Quarantine
Quarantine is used to block any further traffic from a source IP address that is considered a malicious actor or a source of
traffic that is dangerous to the network. Traffic from the source IP address is blocked for the duration of the quarantine,
and the source IP address is added to the banned user list.
The banned user list is kept in the kernel, and used by Antivirus, Data Leak Prevention (DLP), DoS, and Intrusion
Prevention System (IPS). Any policies that use any of these features will block traffic from the attacker's IP address.
The best way to troubleshoot DoS attacks is with Anomaly logs and IPS anomaly debug messages.
1. From the Attacker, launch an icmp_flood with 50pps lasting for 3000 packets.
2. On the FortiGate, configure continuous mode and create a DoS policy with an icmp_flood threshold of 30pps:
config firewall DoS-policy
edit 1
set name icmpFlood
set interface "port1"
set srcaddr "all"
set dstaddr "all"
set service "ALL"
config anomaly
edit "icmp_flood"
set status enable
set log enable
set action block
set threshold 30
next
end
next
end
4. Launch the icmp_flood from a Linux machine. This example uses Nmap:
$ sudo nping --icmp --rate 50 -c 3000 192.168.2.50
SENT (0.0522s) ICMP [192.168.2.205 > 192.168.2.50 Echo request (type=8/code=0) id=8597
seq=1] IP [ttl=64 id=47459 iplen=28 ]
...
Max rtt: 11.096ms | Min rtt: 0.028ms | Avg rtt: 1.665ms
Raw packets sent: 3000 (84.000KB) | Rcvd: 30 (840B) | Lost: 2970 (99.00%)
Nping done: 1 IP address pinged in 60.35 seconds
ip=192.168.2.50 The IP address of the host that triggered the anomaly. It can be either the
client or the server.
For icmp_flood, the IP address is the destination IP address. For icmp_sweep,
it would be the source IP address.
pps=46 The number of packets that had been received when the diagnose command
was executed.
Analysis
msg="anomaly: icmp_flood, At the beginning of the attack, a log is recorded when the threshold of 30pps is
31 > threshold 30 broken.
repeats 28 times The number of packets that has exceeded the threshold since the last time a
log was recorded.
msg="anomaly: icmp_flood, In the second before the log was recorded, 50 packets were detected,
50 > threshold 30 exceeding the configured threshold.
repeats 1497 times The number of packets that has exceeded the threshold since the last time a
log was recorded
An access control list (ACL) is a granular, targeted blocklist that is used to block IPv4 and IPv6 packets on a specified
interface based on the criteria configured in the ACL policy.
On FortiGate models with ports that are connected through an internal switch fabric with TCAM capabilities, ACL
processing is offloaded to the switch fabric and does not use CPU resources. VLAN interfaces that are based on
physical switch fabric interfaces are also supported. Interfaces that are connected through an internal switch fabric
usually have names prefixed with port or lan, such as port1 or lan2; other interfaces are not supported.
The packets will be processed by the CPU when offloading is disabled or not possible, such as when a port on a
supported model does not connect to the internal fabric switch.
ACL is supported on the following FortiGate models:
l 100D, 100E, 100EF, 101E
l 140D, 140D-POE, 140E, 140E-POE
l 1200D, 1500D, 1500DT
l 3000D, 3100D, 3200D, 3700D, 3800D, 3810D, 3815D
l All 300E and larger E-series models
l All 100F and larger F-series models
Example
To block all IPv4 and IPv6 telnet traffic from port2 to Company_Servers:
Diagnose commands
SSL mirroring allows the FortiGate to decrypt and mirror traffic to a designated port. A new decrypted traffic mirror profile
can be applied to IPv4, IPv6, and explicit proxy firewall policies in both flow and proxy mode. Full SSL inspection must be
used in the policy for the traffic mirroring to occur.
SSL inspection is automatically enabled when you enable a security profile on the policy configuration page.
THIS IS A LEGALLY BINDING AGREEMENT BETWEEN YOU, THE USER AND ITS ORGANIZATION
("CUSTOMER"), AND FORTINET. BEFORE YOU CONTINUE WITH THE TERMS AND CONDITIONS OF THIS
CONTRACT (THE "FEATURE ENABLEMENT") CAREFULLY READ THE TERMS AND CONDITIONS OF THIS
AGREEMENT. BY ENTERING YES, YOU, AS AN AUTHORIZED REPRESENTATIVE ON BEHALF OF CUSTOMER,
CONSENT TO BE BOUND BY AND BECOME A PARTY TO THIS AGREEMENT ("AGREEMENT") AND YOU
REPRESENT THAT YOU HAVE READ AND UNDERSTAND THIS AGREEMENT AND HAVE HAD SUFFICIENT
OPPORTUNITY TO CONSULT WITH COUNSEL, PRIOR TO AGREEING TO THE TERMS HEREIN AND ENABLING
THIS FEATURE. IF YOU HAVE ANY QUESTIONS OR CONCERNS, OR DESIRE TO SUGGEST ANY
MODIFICATIONS TO THIS AGREEMENT, PLEASE CONTACT YOUR FORTINET SUPPORT REPRESENTATIVE TO
BE REFERRED TO FORTINET LEGAL. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS
AGREEMENT, DO NOT CONTINUE WITH THE ACCEPTANCE PROCESS. BY ACCEPTING THE TERMS AND
CONDITIONS HEREIN, CUSTOMER HEREBY AGREES THAT:
1. Customer represents and warrants that Customer, not Fortinet, is engaging this
feature.
2. Customer represents and warrants that Customer has provided the requisite notice(s)
and obtained the required consent(s) to utilize this feature.
3. Customer represents and warrants that Customer will only access data as necessary in
a good faith manner to detect malicious traffic and will put in place processes and
controls to ensure this occurs.
4. Customer represents and warrants that Customer has the right to enable and utilize
this feature, and Customer is fully in compliance with all applicable laws in so doing.
5. Customer shall indemnify Fortinet in full for any of the above certifications being
untrue.
6. Customer shall promptly notify Fortinet Legal in writing of any breach of these Terms
and Conditions and shall indemnify Fortinet in full for any failure by Customer or any
of its employees or representatives to abide in full by the Terms and Conditions above.
7. Customer agrees that these Terms and Conditions shall be governed by the laws of the
State of California, without regards to the choice of laws provisions thereof and
Customer hereby agrees that any dispute related to these Terms and Conditions shall be
resolved in Santa Clara County, California, USA, and Customer hereby consents to
personal jurisdiction in Santa Clara County, California, USA.
Inspection mode is configured on a per-policy basis in NGFW mode. This gives you more flexibility when setting up
different policies.
When configuring a firewall policy, you can select a Flow-based or Proxy-basedInspection Mode. The default setting is
Flow-based.
b. In the Security Profiles section, if no security profiles are enabled, the default SSL Inspection is no-inspection.
c. In the Security Profiles section, if you enable any security profile, the SSL Inspection changes to certificate-
inspection.
To see the HTTP and SSH policy redirect settings when inspection mode is set to proxy using the CLI:
To see the default SSL-SSH policy set to no inspection using the CLI:
end
next
end
end
Command Description
l SHA1: 20 bytes
l SHA256: 32 bytes
l SHA384:48 bytes
l SHA512:84 bytes
If the key is shorter than the required length, it will be padded with zeroes.
Command Description
l 3DES: 24 bytes
l AES128: 16 bytes
l AES192: 24 bytes
l AES256: 32 bytes
If the key is shorter than the required length, it will be padded with zeroes.
When the global anti-replay option is disabled, the FortiGate does not check TCP flags in packets. The per policy anti-
replay option overrides the global setting. This allows you to control whether or not TCP flags are checked per policy.
To enable the anti-replay option so TCP flags are checked using the CLI:
Advanced policy options can be enabled so you can configure the options in the GUI.
Advanced policy options are now available when creating or editing a policy in the GUI:
TCP sessions without SYN can now be configured when creating or editing a policy in the GUI:
An anycast IP can be advertised from multiple locations and the router selects a path based on latency, distance, cost,
number of hops, and so on. This technique is widely used by providers to route users to the closest server. Since the IP
is hosted in multiple geographic locations, there is no way to specify one single location to that IP.
In FortiOS 6.4.7, there is an option to bypass anycast IP ranges in geo-IP blocking. The ISDB contains a list of confirmed
anycast IP ranges that can be used for this purpose.
When the source or destination is set to geoip, you can enable the geoip-anycast option. Once enabled, IPs where
the anycast option is set to 1 in geoip_db are bypassed in country matching and blocking.
IP addresses have both a physical and registered location in the geography IP database. Sometimes these two locations
are different. The geoip-match command allows users to match an IPv4 address in an firewall policy to its physical or
registered location when a GeoIP is used as a source or destination address. IPv6 policies currently support geography
address objects but do not support geoip-match.
In the following example, the physical location of 220.243.219.10 is CA (Canada), the registered location is CN (China),
and it is not an anycast IP.
Since CA is applied as a destination address and registered location IP matching is enabled, if the destination IP of
the traffic is 220.243.219.10, then the traffic will be blocked because the registered location is CN.
2. Verify that the policy is blocking traffic from the IP address:
# diagnose sniffer packet any icmp 4
interfaces=[any]
filters=[icmp]
5.383798 wan2 in 10.1.100.41 -> 220.243.219.10: icmp: echo request
6.381982 wan2 in 10.1.100.41 -> 220.243.219.10: icmp: echo request
7.382608 wan2 in 10.1.100.41 -> 220.243.219.10: icmp: echo request
^C
3 packets received by filter
0 packets dropped by kernel
Since CA is applied as a destination address and physical location IP matching is enabled, if the destination IP of
the traffic is 220.243.219.10, then the traffic will pass through.
2. Verify that the policy is allowing traffic from the IP address:
# diagnose sniffer packet any icmp 4
interfaces=[any]
filters=[icmp]
5.273985 wan2 in 10.1.100.41 -> 220.243.219.10: icmp: echo request
5.274176 wan1 out 172.16.200.10 -> 220.243.219.10: icmp: echo request
6.274426 wan2 in 10.1.100.41 -> 220.243.219.10: icmp: echo request
6.274438 wan1 out 172.16.200.10 -> 220.243.219.10: icmp: echo request
By default, unauthenticated traffic is permitted to fall to the next policy. This means that unauthenticated users are only
forced to authenticate against a policy when there are no other matching policies. To avoid this, you can force
authentication to always take place.
Where:
implicitly (default) Implicitly trigger firewall authentication on demand. This is the default setting (and
the behavior in FortiOS 6.0 and earlier).
In the following example, authentication is required; traffic that would otherwise be allowed by the second policy is
instead blocked by the first policy.
You can configure a virtual server with HTTP to HTTPS redirect enabled. When enabled, a virtual server can convert a
client's HTTP requests to HTTPS requests. Through this mandatory conversion, HTTP traffic is converted to
HTTPS traffic. This conversion improves the security of the user network.
You can only enable this feature by using the CLI. After you enable this feature, traffic flows as follows:
l When FortiGate receives an HTTP request for an external IP, such as 10.1.100.201 in the following example,
FortiGate sends an HTTP 303 response back to the original client and redirects HTTP to HTTPS, instead of
forwarding the HTTP request to the real backend servers.
l The client browser restarts the TCP session to HTTPS.
l The HTTPS session comes to the FortiGate where a matching firewall policy allows the HTTPS traffic and
establishes a secure SSL connection, and then forwards the request to the real backend servers.
Active Directory (AD) groups can be used directly in identity-based firewall policies. You do not need to add remote AD
groups to local FSSO groups before using them in policies.
FortiGate administrators can define how often group information is updated from AD LDAP servers.
To use this feature, you must set FSSO Collector Agent to Advanced AD access mode. If the FSSO Collector Agent is
running in the default mode, FortiGate cannot correctly match user group memberships.
Create the FSSO collector that updates the AD user groups list
12. To view the AD user groups that are retrieved by the FSSO agent, hover the cursor over the group icon on the fabric
connector listing.
You view the retrieved AD user groups with the show user adgrp command.
The AD user groups retrieved by the FortiGate can be used directly in firewall policies.
Explicit proxy communication to FortiGate Cloud and FortiGuard servers from FortiGate is enabled. A proxy server can
be configured in the FortiGuard settings so that all FortiGuard connections under the forticldd process can be
established through the proxy server.
Not all FortiGuard services are supported by these proxy settings. For example, web filter
service traffic to FortiGuard will not be directed to the configured proxy.
To configure a proxy server and communicate with FortiGate Cloud though it:
5. On FortiGate A, view the forticldd debug message to see the connection to the log controller through the proxy
server:
# diagnose test application forticldd 1
No session timeout
To allow clients to permanently connect with legacy medical applications and systems that do not have keepalive or
auto-reconnect features, the session timeout can be set to never for firewall services, policies, and VDOMs.
The options to disable session timeout are hidden in the CLI.
MAP-E support
On a customer edge (CE) FortiGate, an IPv4-over-IPv6 (MAP-E) tunnel can be created between the FortiGate and the
border relay (BR) operating in an IPv6 network. A tunnel interface is created between the FortiGate and BR, which can
be applied to firewall policies and IPsec VPN.
The interface-identifier is an IPv6 address. Its last 64-bit will be kept and the rest will be cleared
automatically. It will combine with the IPv6 prefix it gets from the IPv6 router to generate the IPv6 address of the
interface.
By default, unique-autoconf-addr is disabled. It must be enabled so it can handle IPv6 prefix changing.
b. Configure the VNE tunnel:
config system vne-tunnel
set status enable
set interface "wan1"
set mode fixed-ip
set ipv4-address 10.10.81.81 255.255.255.0
set br 2001:160::82
set update-url "http://qa.forosqa.com/update?user=xxxx&pass=yyyy"
end
Once the IPv6 address of the FortiGate changes, the tunnel will be down because the BR does not know the
FortiGate's new IPv6 address. The FortiGate uses update-url to update the new IPv6 address to the provisioning
server. The provisioning server updates the FortiGate’s IPv6 address to the BR so the VNE tunnel can be re-
established.
Communication sequence overview of re-establishing VNE tunnel:
The FortiGate sends a MAP rule request to the MAP distribution server once the IPv6 address is configured on the
FortiGate by RS/RA. Next, the FortiGate will send an AAAA query to get the IPv6 address of the MAP distribution
server. After sending the BMR request to the MAP distribution server, the FortiGate will get the IPv4 address, port
set, BR IPv6 address, and hostname of the address resolution server from the BMR reply. The VNE tunnel between
the FortiGate and BR is now established.
The address resolution server is actually a dynamic DNS. The hostname is used for the FortiGate to maintain an
IPv6 address when it changes.
The FortiGate updates the DDNS server with its IPv6 address whenever it updates, which in turn provides the
update to the MAP distribution server and BR so they know how to resolve the FortiGate by hostname.
Once the VNE tunnel is established, a tunnel interface is created (vne.root), and an IPv4-over-IPv6 tunnel is set
up between the FortiGate and BR. The route, firewall policy, and DNS server can now be configured to let the traffic
go through the VNE tunnel and the and protect the end-user. The VNE tunnel can also be used in IPsec phase 1.
Objects
Specific IP addresses or ranges can be subtracted from the address group with the Exclude Members setting in IPv4
address groups.
This feature is only supported for IPv4 address groups, and only for addresses with a Type of
IP Range or Subnet.
e. Click OK.
2. Go to Policy & Objects > Firewall Policy to apply the address type to a policy in NAT mode VDOM:
a. For Source, select the MAC address you just configured.
b. For Destination, select an address.
In NAT mode VDOM, this address type cannot be used as destination address.
c. Click OK.
2. Apply the address type to a policy. In transparent mode or the virtual wire pair interface, this address type can be
mixed with other address types in the policy:
config firewall address
edit "test-mac-addr1"
set type mac
set start-mac 00:0c:29:41:98:88
set end-mac 00:0c:29:41:98:88
next
end
config firewall policy
edit 1
set srcintf "port2"
set dstintf "port1"
set srcaddr "test-mac-addr1" "10-1-100-42"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
set nat enable
next
end
The Internet Service Database (ISDB) includes well-known vendor MAC address range lists. The lists can only be used
for source MAC addresses in IPv4 policies, and include the vendor name and the MAC address ranges that the vendor
belongs to.
# diagnose vendor-mac id
Please input Vendor MAC ID.
ID: 1 name: "Asus"
ID: 2 name: "Acer"
ID: 3 name: "Amazon"
ID: 4 name: "Apple"
ID: 5 name: "Xiaomi"
ID: 6 name: "BlackBerry"
ID: 7 name: "Canon"
ID: 8 name: "Cisco"
ID: 9 name: "Linksys"
ID: 10 name: "D-Link"
ID: 11 name: "Dell"
ID: 12 name: "Ericsson"
ID: 13 name: "LG"
ID: 14 name: "Fujitsu"
ID: 15 name: "Fitbit"
ID: 16 name: "Fortinet"
# diagnose vendor-mac id 16
Vendor MAC: 16(Fortinet)
Version: 0000700021
Timestamp: 201908081432
Number of MAC ranges: 6
00:09:0f:00:00:00 - 00:09:0f:ff:ff:ff
04:d5:90:00:00:00 - 04:d5:90:ff:ff:ff
08:5b:0e:00:00:00 - 08:5b:0e:ff:ff:ff
70:4c:a5:00:00:00 - 70:4c:a5:ff:ff:ff
90:6c:ac:00:00:00 - 90:6c:ac:ff:ff:ff
e8:1c:ba:00:00:00 - e8:1c:ba:ff:ff:ff
Only packets whose source MAC address belong to Fortinet or VMware are passed by the policy.
The dynamic address group represents the configured IP addresses of all Fortinet devices connected to the Security
Fabric. It currently includes FortiManager, FortiAnalyzer, FortiClient EMS, FortiMail, FortiAP(s), and FortiSwitch(es).
Like other dynamic address groups for fabric connectors, it can be used as an IPv4 address in firewall policies and
objects.
The list of firewall addresses includes a default address object called FABRIC_DEVICE. You can apply the FABRIC_
DEVICE object to the following types of policies:
l Firewall policy (including virtual wire pairs)
l IPv4 shaping policy
l IPv4 ACL policy
l policy64 and policy46 (IPv4 only)
You cannot apply the FABRIC_DEVICE object to the following types of policies:
l IPv4 explicit proxy policy
You also cannot use the FABRIC_DEVICE object with the following settings:
l Custom extension on internet-service
l Exclusion of addrgrp
Initially the FABRIC_DEVICE object does not have an address value. The address value is populated dynamically as
things change. As a result, you cannot edit the FABRIC_DEVICE object, add any addresses to the object, or remove any
addresses from the object. The Edit Address pane in the GUI only has a Return button because the object is read-only:
Diagnose command
You can use the diagnose command to list IP addresses of Fortinet devices that are configured in the Security Fabric.
FabricDevices: 172.18.64.48
FortiAnalyzer: 172.18.60.25
FortiSandbox: 172.18.52.154
FortiManager: 172.18.28.31
FortiClientEMS: 172.18.62.6
FortiAP:
FortiSwitch:
FortiAP/SW-DHCP:
The Fortinet Single Sign-ON (FSSO) dynamic firewall address subtype can be used in policies that support dynamic
address types. The FortiGate will update the dynamic address used in firewall policies based on the source IP
information for the authenticated FSSO users.
It can also be used with FSSO group information that is forwarded by ClearPass Policy Manager (CPPM) via
FortiManager, and other FSSO groups provided by the FSSO collector agent or FortiNAC.
To configure FSSO dynamic addresses with CPPM and FortiManager in the GUI:
In the address table, there will be an error message for the address you just created (Unresolved dynamic
address: fsso). This is expected because there are currently no authenticated FSSO users (based on source
IP) in the local FSSO user list.
2. Add the dynamic address object to a firewall policy:
a. Go to Policy & Objects > Firewall Policy.
b. Create a new policy or edit an existing policy.
c. For Source, add the dynamic FSSO address object you just created.
d. Configure the rest of the policy as needed.
3. Test the authentication to add a source IP address to the FSSO user list:
a. Log in as user and use CPPM for user authentication to connect to an external web server. After successful
authentication, CPPM forwards the user name, source IP address, and group membership to the FortiGate via
FortiManager.
b. Go to Monitor > Firewall User Monitor to view the user name (fsso1) and IP address.
c. Go to Policy & Objects > Addresses to view the updated address table. The error message no longer appears.
d. Hover over the dynamic FSSO address to view the IP address (fsso resolves to: 10.1.100.185).
l If another user is authenticated by CPPM, then the dynamic address fsso entry in the address table will be
updated. The IP address for user fsso2 (10.1.100.188) is now visible:
2. Go to FortiView > Sources to verify that the users were able to successfully pass the firewall policy.
If a user logs off and CPPM receives log off confirmation, then CPPS updates the FortiGate
FSSO user list via FortiManager. The user IP address is deleted from the dynamic FSSO
address, and the user is no longer be able to pass the firewall policy.
To configure FSSO dynamic addresses with CPPM and FortiManager in the CLI:
ClearPass Policy Manager (CPPM) can gather information about the statuses of network hosts, for example, the latest
patches or virus infections. Based on this information, CPPM send the IP addresses and current states, such as Healthy
or Infected, to the FortiGate.
On the FortiGate, the IP addresses received from CPPM are added to a dynamic firewall address with the clearpass-spt
subtype. This address can be used in any policy that supports dynamic addresses, such as Firewall or SSL-VPN
policies.
In this example, you create two dynamic IP addresses that are used in two firewall policies (deny and allow). One policy
allows traffic (host state = Healthy), and the other denies traffic (host state = Infected). When CPPM sends the
information, the IP addresses are assigned according to their host state: Healthy or Infected.
You can then verify that traffic from the Infected host is denied access by the deny policy, and traffic from the Healthy
host is allowed access by the allow policy.
A RESET API administrator is required to generate an authorization token for REST API messages, and to limit hosts
that can send REST API messages to the FortiGate.
For this example, an administrator profile called clearpass was created with full read/write access. See
Administrator profiles on page 786 for details.
6. Click OK.
The New API key pane opens.
The API key is the REST API authorization token that is used in REST API messages sent by CPPM to the
FortiGate.
7. Copy the API key to a secure location. A new key can be generated if this one is lost or compromised.
8. Click Close.
Two dynamic IP addresses are required, one for the allow policy, and the other for the deny policy.
Two firewall policies are required, one to accept traffic (cppm-allow), and the other to deny traffic (cppm-deny).
f. Click OK.
3. Configure the deny policy:
a. Click Create New.
b. Enter a name for the policy.
c. Set Source set to cppm-deny.
d. Set Action to DENY.
f. Click OK.
Verification
Go to Log & Report > Forward Traffic to review traffic logs and ensure that traffic is allowed or denied as expected.
To verify that FortiGate addresses are assigned correctly, enter the following CLI command:
diagnose firewall dynamic list
List all dynamic addresses:
cppm-deny: ID(141)
ADDR(10.1.100.188)
cppm: ID(176)
ADDR(10.1.100.185)
ADDR(10.1.100.186)
Address objects from external connectors that are learned by FortiManager are synchronized to FortiGate. These
objects can be grouped together with the FortiGate CLI to simplify selecting connector objects in the FortiGate GUI.
Multiple groups can be created.
This option is only available for objects that are synchronized from FortiManager.
Example
In this example, objects learned by the FortiManager from an Aruba ClearPass device are synchronized to the FortiGate.
Some of the objects are then added to a group called ClearPass to make them easier to find in the object list when
creating a firewall policy.
Prior to being grouped, the synchronized objects are listed under the FortiManager heading in the object lists.
Since FortiGate must analyze the DNS response, it does not work with DNS over HTTPS.
When the wildcard FQDN gets the resolved IP addresses, FortiOS loads the addresses into the firewall policy for traffic
matching.
The FortiGate will keep the IP addresses in the FQDN object table as long as the DNS entry itself has not expired. Once
it expires, the IP address is removed from the wildcard FQDN object until another query is made. At any given time, a
single wildcard FQDN object may have up to 1000 IP addresses.
The DNS expiry TTL value is set by the authoritative name server for that DNS record. If the
TTL for a specific DNS record is very short and you would like to cache the IP address longer,
then you can extend it with the CLI. See To extend the TTL for a DNS record in the CLI: on
page 1061
For more information, see FQDN address firewall object type.
1. Go to Policy & Objects > Addresses and click Create New > Address.
2. Specify a Name.
3. For Type, select FQDN.
4. For FQDN, enter a wildcard FQDN address, for example, *.fortinet.com.
5. Click OK.
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. For Destination, select the wildcard FQDN.
3. Configure the rest of the policy as needed.
4. Click OK.
In this example, policy ID 2 uses the wildcard FQDN:
To use the diagnose command to list resolved IP addresses of wildcard FQDN objects:
Alternatively:
diagnose test application dnsproxy 6
worker idx: 0
vfid=0 name=*.fortinet.com ver=IPv4 min_ttl=3266:0, cache_ttl=0 , slot=-1, num=3,
wildcard=1
To use the diagnose command for firewall policies which use wildcard FQDN:
In this the example the set cache-ttl value has been extended to 3600 seconds.
config firewall address
edit "fortinet.com"
set type fqdn
set fqdn "www.fortinet.com”
set cache-ttl 3600
next
end
1. Go to Policy & Objects > Virtual IPs and click Create New > Virtual IP.
2. Enter a name for the VIP.
3. Select an interface.
4. For Type, select FQDN.
5. Enter the external IP address.
7. Click OK.
In the virtual IP list, hover over the address to view more information.
Geography-based IPv6 addresses can be created and applied to IPv6 firewall policies.
8. Click OK.
Some address objects logically belong to the same device, such as two IPs from the same computer. These address
objects can be grouped into an address folder, which is an exclusive list of address objects that do not appear in other
address groups or folders.
In the CLI, the folder type can be set after the member list is already populated. If the member list contains an
incompatible entry, then the setting will be discarded when the next/end command is issued. If the folder type is set
before the member list is populated, then the possible member entry list will be filtered according to the selected type.
5. Click OK.
6. In the address table, expand the Address Group section to view the folder (dev1-addr-comb). The expandable
folder view shows the address folder's child objects:
notes
config firewall addrgrp
edit "safe-network1-devices"
set type folder
set member "dev1-addr-comb" "dev2-addr-comb"
set comment ''
set exclude disable
set color 13
next
end
config firewall addrgrp
edit "dev1-addr-comb"
set type folder
Users can define IPv6 MAC addresses that can be applied to the following policies:
l Firewall
l Virtual wire pair
l ACL/DoS
l Central NAT
l NAT64
l Local-in
In this example, a firewall policy is configured in a NAT mode VDOM with the IPv6 MAC address range as a source
address.
IPv6 MAC addresses cannot be used as destination addresses in VDOMs when in NAT
operation mode.
g. Click OK.
Traffic shaping
QoS (quality of service) is the capability to adjust quality aspects of your overall network traffic, including techniques
such as priority-based queuing and traffic policing. Because bandwidth is finite and some types of traffic are slow, jitter or
packet loss sensitive, bandwidth intensive, or critical for operations, QoS is a useful tool to optimize the performance of
various applications in your network. QoS is especially important for managing voice and streaming multimedia traffic
because these types of traffic can rapidly consume bandwidth and are sensitive to latency. You can implement QoS on
FortiGate devices using the following techniques:
Technique Description
Traffic policing The FortiGate drops packets that do not conform to the configured bandwidth
limitations.
Note that excessive traffic policing can degrade network performance rather than
improve it.
Traffic shaping The FortiGate ensures that traffic consumes bandwidth at least at the guaranteed
rate by assigning a greater priority queue to the traffic if the guaranteed rate is not
being met.
The FortiGate ensures that traffic does not consume more than the maximum
configured bandwidth. Traffic that exceeds the maximum rate is subject to traffic
policing.
Queuing The FortiGate transmits packets in the order of their assigned priority queue for
that physical interface. All traffic in a higher priority traffic queue must be
completely transmitted before traffic in lower priority queues is transmitted.
When determining how to configure QoS, it is helpful to know when a FortiGate uses each technique in the overall traffic
processing flow and the considerations for each technique. After the FortiGate accepts packets, it classifies the traffic
and may apply traffic policing at additional points during traffic processing. The FortiGate may also apply QoS
techniques, such as prioritization and traffic shaping. Traffic shaping consists of both traffic policing to enforce bandwidth
limits and adjusting priority queues to help packets achieve the guaranteed rate.
Traffic shaping accuracy is optimal for security policies without a protection profile where no FortiGate content inspection
is processed.
You can enable traffic shaping in System > Feature Visibility under the Additional Features
section.
You can use the weighted random early detection (WRED) queuing function within traffic shaping.
This topic includes two parts:
l Traffic shaping with queuing on page 1069
l Burst control in queuing mode on page 1070
You cannot configure or view WRED in the GUI; you must use the CLI.
Traffic shaping has a queuing option. Use this option to fine-tune the queue by setting the profile queue size or
performing random early drop (RED) according to queue usage.
This example shows setting the profile queue size limit to 5 so that the queue can contain a maximum of five packets and
more packets are dropped.
next
end
This example shows performing RED according to queue usage by setting red-probability, min, and max. Setting
red-probability to 10 means start to drop packets when queue usage reaches the min setting. When queue usage
reaches the max setting, drop 10% of the packets.
l Level 1: when queue is less than min packets, drop 0% of packets.
l Level 2: when queue reaches min packets, start to drop packets.
l Level 3: when queue usage is between min and max packets, drop 0–10% of packets by proportion.
l Level 4: when queue (average queue size) is more than max packets, drop 100% of packets.
In a hierarchical token bucket (HTB) algorithm, each traffic class has buckets to allow a burst of traffic. The maximum
burst is determined by the bucket size burst (for guaranteed bandwidth) and cburst (for maximum bandwidth). The
shaping profile has burst-in-msec and cburst-in-msec parameters for each shaping entry (class id) to control
the bucket size.
This example uses the outbandwidth of the interface as 1 Mbps and the maximum bandwidth of class is 50%.
burst = burst-in-msec * guaranteed bandwidth = 100 ms × 1 Mbps x 50% = 50000 b = 6250 B
cburst = cburst-in-msec * maximum bandwidth = 200 ms × 1 Mbps x 50% = 100000 b = 12500 B
The following example sets burst-in-msec to 100 and cburst-in-msec to 200.
Example
This example shows how to enable RED for FTP traffic from QA. This example sets a maximum of 10% of the packets to
be dropped when queue usage reaches the maximum value.
To set the shaping policy to classify traffic into different class IDs:
To set the shaping policy to define the speed of each class ID:
config shaping-entries
edit 1
set class-id 10
set guaranteed-bandwidth-percentage 50
set maximum-bandwidth-percentage 100
next
edit 2
set class-id 20
set guaranteed-bandwidth-percentage 30
set maximum-bandwidth-percentage 60
set red-probability 10
next
edit 3
set class-id 30
set guaranteed-bandwidth-percentage 20
set maximum-bandwidth-percentage 50
next
end
next
end
Traffic shapers
Shared traffic shaper is used in a firewall shaping policy to indicate the priority and guaranteed and maximum bandwidth
for a specified type of traffic use.
The maximum bandwidth indicates the largest amount of traffic allowed when using the policy. You can set the maximum
bandwidth to a value between 1 and 16776000 Kbps. The GUI displays an error if any value outside this range is used. If
you want to allow unlimited bandwidth, use the CLI to enter a value of 0.
The guaranteed bandwidth ensures that there is a consistent reserved bandwidth available. When setting the
guaranteed bandwidth, ensure that the value is significantly less than the interface's bandwidth capacity. Otherwise, the
interface will allow very little or no other traffic to pass through, potentially causing unwanted latency.
In a shared traffic shaper, the administrator can prioritize certain traffic as high, medium, or low. FortiOS provides
bandwidth to low priority connections only when high priority connections do not need the bandwidth. For example, you
should assign a high traffic priority to a policy for connecting a secure web server that needs to support e-commerce
traffic. You should assign less important services a low priority.
When you configure a shared traffic shaper, you can apply bandwidth shaping per policy or for all policies. By default, a
shared traffic shaper applies traffic shaping evenly to all policies that use the shared traffic shaper.
When configuring a per-policy traffic shaper, FortiOS applies the traffic shaping rules defined for each security policy
individually. For example, if a per-policy traffic shaper is configured with a maximum bandwidth of 1000 Kbps, any
security policies that have that traffic shaper enabled get 1000 Kbps of bandwidth each.
If a traffic shaper for all policies is configured with a maximum bandwidth of 1000 Kbps, all policies share the 1000 Kbps
on a first-come, first-served basis.
The configuration is as follows:
config firewall shaper traffic-shaper
edit "traffic_shaper_name"
set per-policy enable
next
end
The shared traffic shaper selected in the traffic shaping policy affects traffic in the direction defined in the policy. For
example, if the source port is LAN and the destination is WAN1, the traffic shaping affects the flow in this direction only,
affecting the outbound traffic's upload speed. You can define the traffic shaper for the policy in the opposite direction
(reverse shaper) to affect the inbound traffic's download speed. In this example, that would be from WAN1 to LAN.
Only traffic through forward traffic shapers will be included in FortiView; reverse and per-IP shapers are not included.
The following example shows how to apply different speeds to different types of service. The example configures two
shared traffic shapers to use in two firewall shaping policies. One policy guarantees a speed of 10 Mbps for VoIP traffic.
The other policy guarantees a speed of 1 Mbps for other traffic. In the example, FortiOS communicates with a PC using
port10 and the Internet using port9.
f. Click OK.
g. Repeat the above steps to create another traffic shaper named 1Mbps with the Traffic Priority set to Low, the
Max Bandwidth set to 10000, and the Guaranteed Bandwidth set to 1000.
3. Create a firewall shaping policy:
a. Go to Policy & Objects > Traffic Shaping Policy and click Create New.
b. Set the Name to VoIP_10Mbps_High. This policy is for VoIP traffic.
c. Set the Source and Destination to all.
d. Set the Service to all VoIP services.
e. Set the Outgoing Interface to port9.
f. Enable Shared shaper and select 10Mbps.
g. Enable Reverse shaper and select 10Mbps.
h. Click OK.
i. Repeat the above steps to create anpther firewall shaping policy named Other_1Mbps_Low for other traffic,
with the Source and Destination set to all, Service set to ALL, Outgoing Interface set to port9, and Shared
shaper and Reverse shaper set to 1Mbps.
1. To check if specific traffic is attached to the correct traffic shaper, run the diagnose firewall iprope list
100015 command. The example output shows the traffic attached to the 10Mbps and 1Mbps shapers:
# diagnose firewall iprope list 100015
[17:0x0:0/(1,65535)->(5060,5060)] helper:auto
[6:0x0:0/(1,65535)->(1863,1863)] helper:auto
name 10Mbps
maximum-bandwidth 2500 KB/sec
guaranteed-bandwidth 1250 KB/sec
current-bandwidth 0 B/sec
priority 2
tos ff
packets dropped 0
bytes dropped 0
name 1Mbps
With per-IP traffic shaping, you can limit each IP address's behavior to avoid a situation where one user uses all of the
available bandwidth. In addition to controlling the maximum bandwidth used per IP address, you can also define the
maximum number of concurrent sessions for an IP address. For example, if you apply a per-IP shaper of 1 Mbps to your
entire network, FortiOS allocates each user/IP address 1 Mbps of bandwidth. Even if the network consists of a single
user, FortiOS allocates them 1 Mbps. If there are ten users, each user gets 1 Mbps of bandwidth, totaling 10 Mbps of
outgoing traffic.
For shared shapers, all users share the set guaranteed and maximum bandwidths. For example, if you set a shared
shaper for all PCs using an FTP service to 10 Mbps, all users uploading to the FTP server share the 10 Mbps.
Shared shapers affect upload speed. If you want to limit the download speed from the FTP server in the example, you
must configure the shared shaper as a reverse shaper. Per-IP shapers apply the speed limit on both upload and
download operations. Only traffic through forward traffic shapers will be included in FortiView; reverse and per-IP
shapers are not included.
The following example shows how to apply a per-IP shaper to a traffic shaping policy. This shaper assigns each user a
maximum bandwidth of 1 Mbps and allows each user to have a maximum of ten concurrent connections to the FTP
server. In the example, FortiOS communicates with users using port10 and the FTP server using port9.
f. Click OK.
3. Create a firewall shaping policy:
a. Go to Policy & Objects > Traffic Shaping Policy and click Create New.
b. Set the Name to FTP speed 1M.
c. Set the Source to the addresses and users that require access to the FTP server.
d. Set the Destination to FTP_Server.
e. Set the Service to ALL.
f. Set the Outgoing Interface to port9.
g. Enable Per-IP shaper and select FTP_Max_1M.
h. Click OK.
1. To check if specific traffic is attached to the correct traffic shaper, run the diagnose firewall iprope list
100015 command. The example output shows the traffic attached to the FTP_Max_1M shaper:
# diagnose firewall iprope list 100015
name FTP_Max_1M
maximum-bandwidth 125 KB/sec
maximum-concurrent-session 10
tos ff/ff
packets dropped 0
bytes dropped 0
addr=10.1.100.11 status: bps=0 ses=3
Bandwidth speeds are measured in kilobits per second (Kbps), and bytes that are sent and received are measured in
megabytes (MB). In some cases, this can cause confusion depending on whether your ISP uses kilobits per second
(Kbps), kilobytes per second (KBps), megabits per second (Mbps), or gigabits per second (Gbps).
You can change the unit of measurement for traffic shapers in the CLI.
Traffic shapers have a multi-stage method so that packets are marked with a different differentiated services code point
(DSCP) and class id at different traffic speeds. Marking packets with a different DSCP code is for the next hop to
classify the packets. The FortiGate benefits by marking packets with a different class id. Combined with the egress
interface shaping profile, the FortiGate can handle the traffic differently according to its class id.
Traffic shapers also have an overhead option that defines the per-packet size overhead used in rate computation.
Example
This example shows how to mark QA traffic with a different DSCP according to real-time traffic speed.
Global traffic prioritization allows your traffic to be prioritized as high (2), medium (3), or low (4) based on ToS (type of
service) or DSCP. When using ToS-based priority, integers 0 to 15 can be used, which correspond to the definitions of
the ToS field values in RFC 1349. When using DSCP, values 0 to 63 can be used, which correspond to the six bits in the
DSCP value.
The outbandwidth must be defined in order for global prioritization to take effect. When the outbandwidth is defined on an
interface without an applied egress-shaping-profile, the interface has a total of five priority levels:
0 Top
1 Critical
2 High
3 Medium
4 Low
Priority level 0 is reserved for administrative and local out traffic. Priority level 1 is used for traffic that is below
guaranteed bandwidth when using a traffic shaper.
Traffic shaper and traffic shaping profile configurations take precedence over global traffic
prioritization.
CLI commands
The following commands are used to configure the prioritization either by ToS or DSCP.
Example
In the following configuration, packets with DSCP markings of 1 are prioritized as high, and packets with DSCP markings
of 2 are prioritized as medium. All the other traffic is prioritized as low. The outbandwidth on interface port3 is set to 1000
kbps.
next
edit 2
set ds 2
set priority medium
next
end
When traffic exceeds the outbandwidth of 1000 kbps, traffic prioritization will take effect. Since the form of traffic shaping
applied here is policing, excess packets above the outbandwidth are dropped.
In scenario 1, approximately 300 kbps of high priority traffic and 300 kbps of medium priority traffic passes through the
FortiGate on port3.
High priority (2) traffic is allocated 354 kbps of bandwidth. Medium priority (3) traffic is also allocated 354 kbps of
bandwidth. The remaining bandwidth is allocated to low priority (4) traffic.
In scenario 2, approximately 400 kbps of high priority traffic and 800 kbps of medium priority traffic passes through the
FortiGate on port3.
High priority (2) traffic is allocated 425 kbps of bandwidth. Medium priority (3) traffic is allocated 567 kbps of bandwidth.
Since the total bandwidth required exceeds 1000 kbps, the remaining medium priority (3) traffic is dropped. In comparing
the successive debug outputs, the drop_bytes counter for medium priority (3) traffic gets bigger.
Traffic is allowed or blocked according to the Differentiated Services Code Point (DSCP) values in the incoming packets.
The following CLI variables are available in the config firewall policy command:
tos-mask <mask_value> Non-zero bit positions are used for comparison. Zero bit positions are ignored
(default = 0x00).
This variable replaces the dscp-match variable.
tos <tos_value> Type of Service (ToC) value that is used for comparison (default = 0x00). This
variable is only available when tos-mask is not zero.
This variable replaces the dscp-value variable.
tos-negate {enable | Enable/disable negated ToS match (default = disable). This variable is only
disable} available when tos-mask is not zero.
This variable replaces the dscp-negate variable.
Shaping is applied to the session or not according to the DSCP values in the incoming packets. The same logic and
commands as in firewall policies are used.
Traffic is allowed or blocked according to the DSCP values in the incoming packets. DSCP marking in firewall shaping
policies uses the same logic and commands as in firewall policy and traffic-shaper.
When DSCP marking on firewall shaper traffic-shaper, firewall shaping-policy, and firewall
policy all apply to the same session, shaping-policy overrides policy, and shaper traffic-shaper
overrides both shaping-policy and policy.
The following CLI variables in config firewall policy are used to mark the packets:
diffserv-forward {enable Enable/disable changing a packet's DiffServ values to the value specified in
| disable} diffservcode-forward (default = disable).
diffservcode-forward The value that packet's DiffServ is set to (default = 000000). This variable is only
<dscp_value> available when diffserv-forward is enabled.
diffserv-reverse {enable Enable/disable changing a packet's reverse (reply) DiffServ values to the value
| disable} specified in diffservcode-rev (default = disable).
diffservcode-rev <dscp_ The value that packet's reverse (reply) DiffServ is set to (default = 000000). This
value> variable is only available when diffserv-rev is enabled.
Examples
Example 1
FortiGate A marks traffic from the sales and QA teams with different DSCP values. FortiGate B does DSCP matching,
allowing only the sales team to access the database.
1. Configure FortiGate A:
config firewall policy
edit 1
set srcintf "port2"
set dstintf "port3"
set srcaddr "QA"
set dstaddr "all"
set action accept
set schedule "always"
2. Configure FortiGate B:
config firewall policy
edit 2
set srcintf "port3"
set dstintf "port1"
set srcaddr "all"
set dstaddr "Database"
set action accept
set schedule "always"
set service "ALL"
set tos-mask 0xf0
set tos 0xe0
set fsso disable
set nat enable
next
end
Example 2
FortiGate A marks traffic from the sales and QA teams with different DSCP values. FortiGate B uses a firewall shaping
policy to do the DSCP matching, limiting the connection speed of the sales team to the database to 10MB/s.
1. Configure FortiGate A:
config firewall policy
edit 1
set srcintf "port2"
set dstintf "port3"
set srcaddr "QA"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set diffserv-forward enable
set diffservcode-forward 110000
set nat enable
next
edit 5
set srcintf "port2"
set dstintf "port3"
set srcaddr "Sales"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set diffserv-forward enable
set diffservcode-forward 111011
set nat enable
next
end
2. Configure FortiGate B:
config firewall policy
edit 2
set srcintf "port3"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
config firewall shaper traffic-shaper
edit "10MB/s"
set guaranteed-bandwidth 60000
set maximum-bandwidth 80000
next
end
config firewall shaping-policy
edit 1
set service "ALL"
set dstintf "port1"
set tos-mask 0xf0
set tos 0xe0
set traffic-shaper "10MB/s"
set srcaddr "all"
set dstaddr "all"
next
end
Example 3
FortiGate A has a traffic shaping policy to mark traffic from the QA team with a DSCP value of 100000, while reverse
traffic is marked with 000011.
1. Configure FortiGate A:
config firewall shaping-policy
edit 1
set name "QA Team 50MB"
set service "ALL"
Examples
A traffic shaping policy can be used for interface-based traffic shaping by organizing traffic into 30 class IDs. The shaping
profile defines the percentage of the interface bandwidth that is allocated to each class. Each traffic class ID is shaped to
the assigned speed according to the outgoing bandwidth limit configured to the interface.
Traffic classification
A shaping policy classifies traffic and organizes it into different class IDs, based on matching criteria. For traffic matching
a criteria, you can choose to put it into 30 different shaping classes, identified by class ID 2 to 31.
You must select an outgoing interface for the traffic. The shaping policy is only applied when the traffic goes to one of the
selected outgoing interfaces.
Criterion Description
Source l Address: match the source address of the traffic to the selected address or
address group.
l User: use the user credentials of the traffic to match the selected user or user
group. At least one address, address group, or internet service must also be
selected.
l Internet service: match the traffic to the selected internet service. Internet
services cannot be used if addresses or address or groups are used.
Destination l Address: match the destination address of the traffic to the selected address
or address group.
l Internet service: match the traffic to the selected internet service. Internet
services cannot be used if addresses or address or groups are used.
Criterion Description
Schedule Match the current date and time to the selected schedule. You can select a one-
time schedule, recurring schedule, or schedule group. This setting is optional.
Service Match the service of the traffic to the selected service or service group.
Application Match the application of the traffic to the selected application, application
category, or application group.
Application control must be enabled in the related firewall policy to know the
application of the traffic. See Application control on page 1187 for more
information.
URL category Match the URL of the traffic to the selected URL category.
Web filter must be enabled in the related firewall policy to know the URL of the
traffic. See Web filter on page 1135 for more information.
When multiple items are selected in one criterion, it is considered a match when traffic
matches any one of them.
Traffic prioritization
Shaping profiles define how different shaping classes of traffic are prioritized. For each class, you can define three
prioritization strategies: guaranteed bandwidth, maximum bandwidth, and priority.
For each shaping profile, a default shaping class must be defined. Traffic is prioritized based on the default shaping
group in the following two circumstances:
l All traffic to the outgoing interface that does not match to any shaping policy
l Traffic with a shaping group that is not defined in a shaping profile
Guaranteed bandwidth The percentage of the link speed that is reserved for the shaping group.
The total guaranteed bandwidth for all shaping groups cannot exceed 100%.
Maximum bandwidth The maximum percentage of the link speed that the shaping group can use.
Priority The shaping class priority: top, critical, high, medium, or low. When groups are
competing for bandwidth on the interface, the group with the higher priority wins.
Traffic shaping is accomplished by configuring the outgoing bandwidth and outgoing shaping profile on an interface. The
shaping profile uses the outgoing bandwidth of the interface as the maximum link speed, and it only works when the
outgoing bandwidth is configured.
This example shows how to apply interface-based traffic shaping to web and file accessing traffic according to a
schedule:
l The link speed of the wan1 interface is 10 Mb/s.
l File access can use up to 2 Mb/s from 8:00 AM to 6:00 PM.
To create a traffic shaping policy and class ID for the web accessing traffic in the GUI:
1. Go to Policy & Objects > Traffic Shaping Policy and click Create New.
2. Enter a name for the policy, such as web_access_day_hours.
3. Enable Schedule and select the schedule you just created.
4. Set Service to web accessing services, such as HTTP and HTTPS.
5. Set Action to Assign Shaping Class ID, and Outgoing interface to wan1
6. Click the Traffic shapping class ID drop down then click Create.
7. Enter a value for the ID (integer) and a description for the Name, such as Web Access.
8. Click OK.
To create a traffic shaping policy and class ID for the file accessing traffic in the GUI:
1. Go to Policy & Objects > Traffic Shaping Policy and click Create New.
2. Enter a name for the policy, such as file_access_day_hours.
3. Enable Schedule and select the schedule you just created.
4. Set Service to file accessing services, such as ASF3, FTP and SMB.
5. Set Action to Assign Shaping Class ID, and Outgoing interface to wan1
6. Click the Traffic shapping class ID drop down then click Create.
7. Enter a value for the ID (integer) and a description for the Name, such as File Access.
8. Click OK.
A traffic shaping profile defines the guaranteed and maximum bandwidths each class receives. In this example, file
access can use up to 2 Mb/s and web access can use 8 Mb/s from 8:00 AM to 6:00 PM.
1. Go to Policy & Objects > Traffic Shaping Profile and click Create New.
2. Enter a name for the profile, such as Day_Hours_Profile.
3. Configure a default traffic shaping class:
This class has a high priority, meaning that when the other classes have reached their guaranteed bandwidths, this
default class will use the rest of the available bandwidth.
a. In the Traffic Shaping Classes table click Create New.
b. Click the Traffic shapping class ID drop down then click Create.
c. Enter a name for the class, such as Default Access.
d. Click OK.
e. Set Traffic shaping class ID to the just created class ID.
Guaranteed bandwidth 30
Priority High
Guaranteed bandwidth 60
Maximum bandwidth 80
Priority High
Guaranteed bandwidth 10
Maximum bandwidth 20
Priority High
6. Click OK.
next
end
5. Click OK.
Diagnose commands
To check that the specific traffic is put into the correct shaping group or class ID:
1. Enable NPU offloading when doing interface-based traffic shaping according to the egress-shaping-profile:
config system npu
set intf-shaping-offload enable
end
When devices are quarantined, they are isolated from the rest of the network. However, they can still impact the network
if not controlled beyond isolation. A quarantined host, which offers heavy traffic, could congest the network and create a
DOS-style reduction in service to authorized hosts.
Within the quarantined VLAN, two restrictions are available within the network:
l Traffic policing (also known as rate limiting)
l QoS (Quality of Service) assignment (also known as priority assignment)
Each quarantined host's traffic can be subject to rate limiting and priority adjustment. This reduces the impact that any
quarantined host can have on authorized traffic on the network.
2. Configure an interface:
config system interface
edit "qtn.aggr1"
set vdom "root"
set ip 10.254.254.254 255.255.255.0
set description "Quarantine VLAN"
set security-mode captive-portal
set replacemsg-override-group "auth-intf-qtn.aggr1"
set device-identification enable
set snmp-index 30
set switch-controller-access-vlan enable
set switch-controller-traffic-policy "quarantine"
set color 6
set interface "aggr1"
set vlanid 4093
next
end
By default, switch-controller-traffic-policy is empty. You need to apply the necessary traffic policy (not
only limited to "quarantine").
This section contains information about configuring FortiGate security features, including:
l Inspection modes on page 1102
l Antivirus on page 1107
l Web filter on page 1135
l DNS filter on page 1166
l Application control on page 1187
l Intrusion prevention on page 1199
l File filter on page 1208
l Email filter on page 1214
l Data leak prevention on page 1221
l VoIP solutions on page 1229
l ICAP on page 1241
l Web application firewall on page 1246
l SSL & SSH Inspection on page 1251
l Custom signatures on page 1261
l Overrides on page 1266
If you are unable to view a security profile feature, go to System > Feature Visibility to enable
it.
Inspection modes
FortiOS supports flow-based and proxy-based inspection in firewall policies. You can select the inspection mode when
configuring a policy.
Flow-based inspection takes a snapshot of content packets and uses pattern matching to identify security threats in the
content.
Proxy-based inspection reconstructs content that passes through the FortiGate and inspects the content for security
threats.
Certain security profiles allows users to display flow-based or proxy-based feature sets.
This following topics provide information about inspection modes for various security profile features:
l Flow mode inspection (default mode) on page 1103
l Proxy mode inspection on page 1103
l Inspection mode feature comparison on page 1105
When a firewall policy's inspection mode is set to flow, traffic flowing through the policy will not be buffered by the
FortiGate. Unlike proxy mode, the content payload passing through the policy will be inspected on a packet by packet
basis with the very last packet held by the FortiGate until the scan returns a verdict. If a violation is detected in the traffic,
a reset packet is issued to the receiver, which terminates the connection, and prevents the payload from being sent
successfully.
Flow-based inspection identifies and blocks security threats in real time as they are identified. All applicable flow-based
security modules are applied simultaneously in one single pass, using Direct Filter Approach (DFA) pattern matching to
identify possible attacks or threats. Pattern matching is offloaded and accelerated by CP8 or CP9 processors.
Flow-based inspection typically requires lower processing resources than proxy-based inspection and does not change
packets, unless a threat is found and packets are blocked.
Use case
It is recommended to apply flow inspection to policies that prioritize traffic throughput, such as allowing connections to a
streaming or file server.
For example, you have an application server that accepts connections from users for a daily quiz show app, HQ. Each
HQ session sees 500,000+ participants, and speed is very important because participants have less than 10 seconds to
answer the quiz show questions.
In this scenario, a flow inspection policy is recommended to prioritize throughput. The success of the application
depends on providing reliable service for large numbers of concurrent users. The policy would include an IPS sensor to
protect the server from external DOS attacks.
When a firewall policy’s inspection mode is set to proxy, traffic flowing through the policy will be buffered by the FortiGate
for inspection. This means that the packets for a file, email message, or web page will be held by the FortiGate until the
entire payload is inspected for violations (virus, spam, or malicious web links). After FortiOS finishes the inspection, the
payload is either released to the destination (if the traffic is clean) or dropped and replaced with a replacement message
(if the traffic contains violations).
To optimize inspection, the policy can be configured to block or ignore files or messages that exceed a certain size. To
prevent the receiving end user from timing out, you can apply client comforting. This allows small portions of the payload
to be sent while it is undergoing inspection.
Proxy mode provides the most thorough inspection of the traffic; however, its thoroughness sacrifices performance,
making its throughput slower than that of a flow mode policy. Under normal traffic circumstances, the throughput
difference between a proxy-based and flow-based policy is not significant.
Use case 1
Your organization deals with sensitive data on a regular basis and a data leak would significantly harm your business. At
the same time, you wish to protect your employees from malicious content, such as viruses and phishing emails, which
could be used to gain access to your network and the sensitive data on your systems.
In this scenario, a proxy inspection policy is recommended to prioritize network security. You want traffic inspection to be
as thorough as possible to avoid any data leaks from exiting the LAN and any malicious content from entering it. The
policy would include antivirus, DLP, web, and email filters all operating in proxy mode.
Use case 2
You have a corporate mail server in your domain that is used by your employees for everyday business activities. You
want to protect your employees from phishing emails and viruses. At the same time, you want to also protect your web
servers from external attacks.
In this scenario, a proxy inspection policy is recommended to prioritize the safety of employee emails. Applying the
antivirus and email filter in this mode allows you to filter out any malware and spam emails received by the mail servers
via SMTP or MAPI. An IPS sensor would be used to prevent DOS attacks on the mail servers.
The following table shows which UTM profile can be configured on a flow mode or proxy mode inspection policy.
Some UTM profiles are hidden in the GUI and can only be configured using the CLI. To configure profiles in a firewall
policy in CLI, enable the utm-status setting.
Some profiles might have feature differences between flow-based and proxy-based Inspection. From the GUI and CLI,
you can set the Feature set option to be Flow-based or Proxy-based to display only the settings for that mode.
The following sections outline differences between flow-based and proxy-based inspection for a security profile.
The following table indicates which Antivirus features are supported by their designated scan modes.
*IPS Engine caches the URL and a replacement message is presented after the second attempt.
1. Only available on FortiGate models with HDD or when FortiAnalyzer or FortiGate Cloud is connected and enabled.
2. Only applies to inspection on IMAP, POP3, SMTP, and MAPI protocols.
The following table indicates which Web Filter features are supported by their designated inspection modes.
1. Local Category and Remote Category filters do not support the warning and authenticate actions.
2. Local Category and Remote Category filters cannot be overridden.
3. Only HTTP POST Action is supported.
The following tables indicate which Email Filters are supported by the specified inspection modes for local filtering and
FortiGuard-assisted filtering.
Flow No No No No No
The following table indicates which DLP filters are supported by their designated inspection modes.
Proxy Yes Yes Yes Yes Yes Yes Yes Yes Yes
*File-size filtering only works if file size is present in the protocol exchange.
Antivirus
FortiOS offers the unique ability to implement both flow-based and proxy-based antivirus concurrently, depending on the
traffic type, users, and locations. Flow-based antivirus offers higher throughput performance.
FortiOS includes two preloaded antivirus profiles:
l default
l wifi-default
You can customize these profiles, or you can create your own to inspect certain protocols, remove viruses, analyze
suspicious files with FortiSandbox, and apply botnet protection to network traffic. Once configured, you can add the
antivirus profile to a firewall policy.
The following table indicates which protocols can be inspected by the designated antivirus scan modes.
Proxy Yes Yes Yes Yes Yes Yes Yes Yes* Yes
* Proxy mode antivirus inspection on CIFS protocol has the following limitations:
l Cannot detect infections within some archive files.
l Cannot detect oversized files.
Starting from 6.4.0, the scan mode option is no longer available for flow-based AV.
This means that AV no longer exclusively uses the default or legacy scan modes when handling traffic on flow-based
firewall policies. Instead, AV in flow-based policies uses a hybrid of the two scan modes. Flow AV may use a pre-filtering
database for malware detection in some circumstances as opposed to the full AV signature database in others. The scan
method is determined by the IPS engine algorithm that is based on the type of file being scanned.
In contrast, proxy mode maintains the scan mode option, which can be toggled between default or legacy mode. In
default mode, the WAD daemon uses a stream-based approach, while legacy mode disables this stream-based
approach. Proxy default scan-mode uses pre-scanning and stream-based scanning for HTTP traffic.
Stream-based scanning provides the following AV improvements:
l Archive files (ZIP, GZIP, BZIP2, TAR, ISO) that exceed the oversize limit are uncompressed and scanned for
infections.
l The contents of large archive files are scanned without having to buffer the entire file.
l Small files are scanned locally by the WAD daemon if only AV scanning is needed in the policy.
l File filtering on HTTP/HTTPS is handled locally by the WAD daemon.
This means that the overall memory usage is optimized when an archive file is scanned, and better security is achieved
by scanning archives that would otherwise be bypassed.
However, stream-based scanning has limitations on the more complex features that it can scan. For the following
features, traffic will be automatically handed off to the scanunit daemon for scanning (as in the case of legacy mode):
l Heuristic AV scan
l DLP
l Quarantine
l FortiGuard outbreak prevention and external block list
l Content disarm
Databases
The antivirus scanning engine uses a virus signatures database to record the unique attributes of each infection. The
antivirus scan searches for these signatures and when one is discovered, the FortiGate determines if the file is infected
and takes action.
All FortiGates have the normal antivirus signature database. Some models have additional databases that you can use.
The database you use depends on your network and security needs, and on your FortiGate model.
The extended virus definitions database is the default setting and provides comprehensive antivirus protection. Low-end
FortiGate models cannot support the extreme database. The FortiGate 300D is the lowest model that supports the
extreme database. All VMs support the extreme database. The use-extreme-db setting is only available on models
that support the extreme database.
Extended This is the default setting. This database includes currently spreading viruses, as
determined by the FortiGuard Global Security Research Team, plus recent
viruses that are no longer active. These viruses may have been spreading within
the last year but have since nearly or completely disappeared.
Extreme This includes the extended database, plus a large collection of zoo viruses. These
are viruses that have not spread in a long time and are largely dormant. Some zoo
viruses might rely on operating systems and hardware that are no longer widely
used.
Content disarm and reconstruction (CDR) allows the FortiGate to sanitize Microsoft Office documents and PDF files
(including those that are in ZIP archives) by removing active content, such as hyperlinks, embedded media, JavaScript,
macros, and so on from the files (disarm) without affecting the integrity of its textual content (reconstruction). It allows
network administrators to protect their users from malicious document files.
Files processed by CDR can be stored locally for quarantine on FortiAnalyzer, FortiSandbox, or FortiGate models with a
hard disk. The original copies can also be obtained in the event of a false positive.
CDR is supported on HTTP, SMTP, POP3, and IMAP. Note that SMTP splice and client-comfort mode are not
supported. CDR does not support flow-based inspection modes.
Sample topology
In this example, the a Microsoft Office document with an embedded hyperlink (that redirects to an external website) is
sent to the receiver. When the user receives the file, the hyperlink in the document is deactivated.
To configure CDR:
File Quarantine Saves the original document file to disk (if possible) or a connected
FortiAnalyzer based on the FortiGate log settings (config log
fortianalyzer setting).
Discard The default setting, which discards the original document file.
5. Click OK.
By default, stripping of all active Microsoft Office and PDF content types are enabled. In this example, stripping macros
in Microsoft Office documents will be disabled.
config antivirus profile
edit av
config content-disarm
set office-macro disable
set detect-only {enable | disable}
set cover-page {enable | disable}
end
next
end
Where:
detect-only Only detect disarmable files, do not alter content. Disabled by default.
cover-page Attach a cover page to the file's content when the file has been processed by
CDR. Enabled by default.
FortiGuard Virus Outbreak Protection Service (VOS) allows the FortiGate antivirus database to be subsidized with third-
party malware hash signatures curated by FortiGuard. The hash signatures are obtained from FortiGuard's Global
Threat Intelligence database. The antivirus database queries FortiGuard with the hash of a scanned file. If FortiGuard
returns a match, the scanned file is deemed to be malicious.
FortiGuard VOS can be used in both proxy-based and flow-based policy inspections across all supported protocols.
However, there is limited support in flow-based AV.
The FortiGate must be registered with a valid FortiGuard outbreak prevention license.
1. Go to System > FortiGuard and locate the Outbreak Prevention section in the table.
2. See the instructions in the video, How to Purchase or Renew FortiGuard Services, if required.
Service : Web-filter
Status : Enable
License : Contract
Service : Antispam
Status : Disable
The external malware block list allows users to add their own malware signatures in the form of MD5, SHA1, and
SHA256 hashes. The FortiGate's antivirus database retrieves an external malware hash list from a remote server and
polls the hash list every n minutes for updates.
The external malware block list can be used in both proxy-based and flow-based policy inspections, but it is not
supported in AV quick scan mode.
Note that using different types of hashes simultaneously may slow down the performance of malware scanning. It is
recommended to use one type of hash.
# Invalid entries
7688499dc71b932feb126347289c0b8a_md5_sample2
7614e98badca10b5e2d08f8664c519b7a906fbd5180ea5d04a82fce9796a4b87sha256_sample3
d. Click OK.
3. To view entries inside the malware block list on the External Connectors page, hover over the malware hash card
and click View Entries.
To verify the scanunit daemon updated itself with the external hashes:
3. On the client PC, download the EICAR Standard Anti-Virus Test File via HTTP.
4. Check the antivirus statistics on the FortiGate. Since the action is set to monitor for HTTP, HTTP virus
detected increases by 1:
# diagnose ips av stats show
AV stats:
HTTP virus detected: 1
HTTP virus blocked: 0
SMTP virus detected: 0
SMTP virus blocked: 0
POP3 virus detected: 0
POP3 virus blocked: 0
IMAP virus detected: 0
IMAP virus blocked: 0
NNTP virus detected: 0
NNTP virus blocked: 0
FTP virus detected: 0
FTP virus blocked: 0
SMB virus detected: 0
SMB virus blocked: 0
CIFS support
Antivirus scanning on Common Internet File System (CIFS) traffic is supported in flow-based and proxy-based
inspection. The file filter profile handles the configuration of file filtering on CIFS. The antivirus profile handles the
antivirus configuration for CIFS scanning.
File filtering for CIFS is performed by inspecting the first 4 KB of the file to identify the file's magic number. If a match
occurs, CIFS file filtering prevents the CIFS command that contains that file from running. The file filter functions
differently for un-encrypted and encrypted CIFS traffic:
l For un-encrypted CIFS traffic, the standalone file filter works in flow and proxy mode.
l For encrypted CIFS traffic, the CIFS profile must be enabled in the firewall policy because the SMB server’s
credential settings are still be configured in CIFS profile. Using the standalone file filter only works in proxy mode.
For a CIFS profile to be available for assignment in a policy, the policy must use proxy inspection mode. See Proxy mode
inspection on page 1103 for details. Note that in proxy inspection mode, special condition archive files (encrypted,
corrupted, mailbomb, and so on) marked by the antivirus engine are blocked automatically.
Messages that are compressed with LZNT1, LZ77, and LZ77+Huffman algorithms can be scanned in proxy mode.
The domain controller must be configured when CIFS traffic is encrypted. The configuration tells the FortiGate the
network location of the domain controller and the superuser credentials.
To create a CIFS profile, configure the server credential type and create a file filter profile.
none
The CIFS profile assumes the CIFS traffic is unencrypted. This is the default value.
config firewall profile-protocol-options
edit "cifs"
config cifs
set server-credential-type none
end
next
end
credential-replication
To decrypt CIFS traffic, FortiOS obtains the session key from the domain controller by logging in to the superuser
account. The domain controller must be configured.
config firewall profile-protocol-options
edit "cifs"
config cifs
set server-credential-type credential-replication
set domain-controller "SERVER_NAME"
end
next
end
Variable Description
domain-controller <string> The previously configured domain to decrypt CIFS traffic for.
credential-keytab
To decrypt CIFS traffic, FortiOS uses a series of keytab values. This method is used when the SMB connection is
authenticated by Kerberos. Keytab entries must be configured, and are stored in FortiOS in plaintext.
config firewall profile-protocol-options
edit "cifs"
config cifs
set server-credential-type credential-keytab
config server-keytab
edit "keytab1"
set keytab
"BQIAAABFAAEAC0VYQU1QTEUuQ09NAAdleGFtcGxlAAAAAVUmAlwBABIAILdV5P6NXT8RrTvapcMJQxDYCjRQiD0Bzxh
wS9h0VgyM"
next
end
end
next
end
Variable Description
keytab <keytab> Base64 encoded keytab file containing the credentials of the server.
Multiple rules can be added to a file filter profile. See File filter on page 1208.
Variable Description
feature-set {flow | proxy} Flow or proxy mode feature set (default = flow).
protocol {http ftp smtp imap pop3 Filter based on the specified protocol(s).
mapi cifs ssh}
direction {incoming | outgoing | Match files transmitted in the session's originating (incoming) and/or reply
any} (outgoing) direction (default = any).
password-protected [yes | any] Match only password-protected files (yes) or any file (default = any).
file-type <file_type> The file types to be matched. See Supported file types on page 1211 for details.
The antivirus profile handles the antivirus configuration for CIFS scanning.
Variable Description
options {scan avmonitor Enable/disable CIFS antivirus scanning, monitoring, and quarantine.
quarantine}
Log samples
File-type detection events generated by CIFS profiles are logged in the utm-cifs log category. Antivirus detection over
the CIFS protocol generates logs in the utm-virus category. See the FortiOS Log Message Reference for more
information.
Antivirus profiles can submit potential zero-day viruses to FortiSandbox for inspection. Based on FortiSandbox's
analysis, the FortiGate can supplement its own antivirus database with FortiSandbox's database to detect files
determined as malicious or risky by FortiSandbox. This helps the FortiGate antivirus detect zero-day viruses and
malware whose signatures are not found in the antivirus database.
FortiSandbox can be used with antivirus in both proxy-based and flow-based inspection modes. When FortiSandbox is
enabled, full scan mode antivirus can submit the following for inspection: only suspicious files, all supported file, or no
files. Quick scan mode antivirus cannot submit suspicious files to FortiSandbox, so either all files or no files are
submitted for inspection.
For more information, see FortiSandbox on page 149.
Configuring FortiSandbox
1. Go to Security Fabric > Fabric Connectors and double-click the FortiSandbox card.
2. For status, click Enable.
3. For Type, click On-Premise.
4. Enter the IP address of the FortiSandbox, and enter an optional Notifier email.
At this point, clicking Test connectivity returns an unreachable status. This is expected, because the FortiGate is not
yet authorized by FortiSandbox.
5. Click OK.
The link icon changes from an open to a closed link, which indicates that the FortiGate is authorized.
4. In the FortiGate GUI, go to Security Fabric > Fabric Connectors and double-click the FortiSandbox card.
5. Click Test connectivity. The FortiGate is now authorized and the status displays as Connected.
FortiGate diagnostics
upd_cfg_extract_ibdb_botnet_db_version[523]-version=06002000IBDB00101-00004.00401-1901281000
upd_cfg_extract_av_db_version[378]-version=06002000AVDB00201-00066.01026-1901301530
upd_cfg_extract_ids_db_version[437]-version=06002000NIDS02403-00014.00537-1901300043
upd_cfg_extract_ids_db_version[437]-version=06002000APDB00103-00006.00741-1512010230
upd_cfg_extract_ids_db_version[437]-version=06002000ISDB00103-00014.00537-1901300043
upd_cfg_extract_ibdb_botnet_db_version[523]-version=06002000IBDB00101-00004.00401-1901281000
upd_cfg_extract_av_db_version[378]-version=06002000AVDB00201-00066.01026-1901301530
upd_cfg_extract_ids_db_version[437]-version=06002000NIDS02403-00014.00537-1901300043
upd_cfg_extract_ids_db_version[437]-version=06002000APDB00103-00006.00741-1512010230
upd_cfg_extract_ids_db_version[437]-version=06002000ISDB00103-00014.00537-1901300043
upd_cfg_extract_ibdb_botnet_db_version[523]-version=06002000IBDB00101-00004.00401-1901281000
upd_cfg_extract_av_db_version[378]-version=06002000AVDB00201-00066.01026-1901301530
upd_cfg_extract_ids_db_version[437]-version=06002000NIDS02403-00014.00537-1901300043
upd_cfg_extract_ids_db_version[437]-version=06002000APDB00103-00006.00741-1512010230
upd_cfg_extract_ids_db_version[437]-version=06002000ISDB00103-00014.00537-1901300043
upd_cfg_extract_ibdb_botnet_db_version[523]-version=06002000IBDB00101-00004.00401-1901281000
quar_remote_recv_send()-731: dev=fortisandbox-fsb2 xfer-status=0
__quar_build_pkt()-408: build req(id=337, type=4) for vdom-vdom1, len=99, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=99
quar_remote_send()-520: req(id=337, type=4) read response, dev=fortisandbox-fsb2, xfer_
status=1, buflen=12
quar_remote_recv_send()-770: dev-fortisandbox-fsb2, oevent=4, nevent=1, xfer-status=1
quar_remote_recv_send()-731: dev=fortisandbox-fsb3 xfer-status=0
__quar_build_pkt()-408: build req(id=338, type=6) for vdom-vdom1, len=93, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=93
quar_remote_send()-520: req(id=338, type=6) read response, dev=fortisandbox-fsb3, xfer_
status=1, buflen=12
quar_remote_recv_send()-770: dev-fortisandbox-fsb3, oevent=4, nevent=1, xfer-status=1
quar_remote_recv_send()-731: dev=fortisandbox-fsb5 xfer-status=0
__quar_build_pkt()-408: build req(id=340, type=6) for vdom-vdom1, len=93, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=93
quar_remote_send()-520: req(id=340, type=6) read response, dev=fortisandbox-fsb5, xfer_
status=1, buflen=12
quar_remote_recv_send()-770: dev-fortisandbox-fsb5, oevent=4, nevent=1, xfer-status=1
quar_remote_recv_send()-731: dev=fortisandbox-fsb2 xfer-status=1
quar_remote_recv()-662: dev(fortisandbox-fsb2) received a packet: len=69, type=1
quar_remote_recv()-718: file-[337] is accepted by server(fortisandbox-fsb2).
quar_put_job_req()-332: Job 337 deleted
quar_remote_recv_send()-731: dev=fortisandbox-fsb4 xfer-status=0
__quar_build_pkt()-408: build req(id=339, type=6) for vdom-vdom1, len=93, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=93
quar_remote_send()-520: req(id=339, type=6) read response, dev=fortisandbox-fsb4, xfer_
status=1, buflen=12
quar_remote_recv_send()-770: dev-fortisandbox-fsb4, oevent=4, nevent=1, xfer-status=1
quar_remote_recv_send()-731: dev=fortisandbox-fsb1 xfer-status=0
__quar_build_pkt()-408: build req(id=336, type=4) for vdom-root, len=98, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=98
...
__get_analytics_stats()-19: Received an ANALYTICS_STATS request, vfid: 0
__quar_req_handler()-127: Request 0 was handled successfully
__get_analytics_stats()-19: Received an ANALYTICS_STATS request, vfid: 0
__quar_req_handler()-127: Request 0 was handled successfully
__get_analytics_stats()-19: Received an ANALYTICS_STATS request, vfid: 0
__quar_req_handler()-127: Request 0 was handled successfully
__get_analytics_stats()-19: Received an ANALYTICS_STATS request, vfid: 0
__quar_req_handler()-127: Request 0 was handled successfully
global-fas is disabled.
forticloud-fsb is disabled.
fortisandbox-fsb1 is enabled: analytics, realtime=yes, taskfull=no
addr=172.18.52.154/514, source-ip=0.0.0.0, keep-alive=no.
ssl_opt=3, hmac_alg=0
fortisandbox-fsb2 is enabled: analytics, realtime=yes, taskfull=no
Statistics:
vfid: 0, detected: 0, clean: 0, risk_low: 0, risk_med: 0, risk_high: 0, limit_
reached:0
vfid: 3, detected: 0, clean: 0, risk_low: 0, risk_med: 0, risk_high: 0, limit_
reached:0
vfid: 4, detected: 0, clean: 0, risk_low: 0, risk_med: 0, risk_high: 0, limit_
reached:0
FortiSandbox diagnostics
FortiSandbox Cloud allows users to take advantage of FortiSandbox features without having to purchase, operate, and
maintain a physical appliance. It works the same way as the physical FortiSandbox appliance.
FortiSandbox Cloud allows you to control the region where your traffic is sent to for analysis. This allows you to meet
your country's compliance needs regarding data storage locations.
FortiSandbox can be used with antivirus in both proxy-based and flow-based inspection modes. When FortiSandbox is
enabled, full scan mode antivirus can submit the following for inspection: only suspicious files, all supported file, or no
files. Quick scan mode antivirus cannot submit suspicious files to FortiSandbox, so either all files or no files are
submitted for inspection.
In FortiOS 6.2 and later, users do not require a FortiGate Cloud account to use FortiSandbox Cloud. Without a valid
FortiGuard antivirus (AVDB) license, FortiGate devices are limited to 100 FortiGate Cloud submissions per day.
Unlimited FortiGate Cloud submissions are allowed if the FortiGate has a valid AVDB license; however, there is a per-
minute submission rate is based on the FortiGate model.
For more information, see FortiSandbox on page 149.
There are three steps to configure FortiSandbox Cloud inspection in an antivirus profile:
1. Through FortiCare, register the FortiGate device and purchase a FortiGuard antivirus license.
2. Enable FortiSandbox Cloud on the FortiGate.
3. Enable FortiSandbox inspection options in the antivirus profile.
1. See the How to Purchase or Renew FortiGuard Services video for FortiGuard antivirus license purchase
instructions.
2. Once a FortiGuard license is purchased and activated, users are provided with a paid FortiSandbox Cloud license.
a. Go to Dashboard > Status to view the FortiSandbox Cloud license indicator.
b. Alternatively, go to System > FortiGuard to view the FortiSandbox Cloud license indicator.
FortiGate diagnostics
global-fas is disabled.
forticloud-fsb is enabled: analytics, realtime=yes, taskfull=no
addr=172.16.102.51/514, source-ip=0.0.0.0, keep-alive=no.
ssl_opt=1, hmac_alg=0
fortisandbox-fsb1 is disabled.
fortisandbox-fsb2 is disabled.
fortisandbox-fsb3 is disabled.
fortisandbox-fsb4 is disabled.
fortisandbox-fsb5 is disabled.
fortisandbox-fsb6 is disabled.
global-faz is disabled.
global-faz2 is disabled.
global-faz3 is disabled.
Statistics:
vfid: 0, detected: 0, clean: 0, risk_low: 0, risk_med: 0, risk_high: 0, limit_
reached:0
vfid: 3, detected: 0, clean: 0, risk_low: 0, risk_med: 0, risk_high: 0, limit_
reached:0
vfid: 4, detected: 0, clean: 0, risk_low: 0, risk_med: 0, risk_high: 0, limit_
reached:0
FGT_FL_FULL (global) #
upd_cfg_extract_ids_db_version[437]-version=06002000ISDB00103-00014.00537-1901300043
upd_cfg_extract_ibdb_botnet_db_version[523]-version=06002000IBDB00101-00004.00401-1901281000
upd_cfg_extract_av_db_version[378]-version=06002000AVDB00201-00066.01026-1901301530
upd_cfg_extract_ids_db_version[437]-version=06002000NIDS02403-00014.00537-1901300043
upd_cfg_extract_ids_db_version[437]-version=06002000APDB00103-00006.00741-1512010230
upd_cfg_extract_ids_db_version[437]-version=06002000ISDB00103-00014.00537-1901300043
upd_cfg_extract_ibdb_botnet_db_version[523]-version=06002000IBDB00101-00004.00401-1901281000
upd_cfg_extract_av_db_version[378]-version=06002000AVDB00201-00066.01026-1901301530
upd_cfg_extract_ids_db_version[437]-version=06002000NIDS02403-00014.00537-1901300043
upd_cfg_extract_ids_db_version[437]-version=06002000APDB00103-00006.00741-1512010230
upd_cfg_extract_ids_db_version[437]-version=06002000ISDB00103-00014.00537-1901300043
upd_cfg_extract_ibdb_botnet_db_version[523]-version=06002000IBDB00101-00004.00401-1901281000
upd_cfg_extract_av_db_version[378]-version=06002000AVDB00201-00066.01026-1901301530
upd_cfg_extract_ids_db_version[437]-version=06002000NIDS02403-00014.00537-1901300043
upd_cfg_extract_ids_db_version[437]-version=06002000APDB00103-00006.00741-1512010230
upd_cfg_extract_ids_db_version[437]-version=06002000ISDB00103-00014.00537-1901300043
upd_cfg_extract_ibdb_botnet_db_version[523]-version=06002000IBDB00101-00004.00401-1901281000
quar_remote_recv_send()-731: dev=fortisandbox-fsb2 xfer-status=0
__quar_build_pkt()-408: build req(id=337, type=4) for vdom-vdom1, len=99, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=99
quar_remote_send()-520: req(id=337, type=4) read response, dev=fortisandbox-fsb2, xfer_
status=1, buflen=12
quar_remote_recv_send()-770: dev-fortisandbox-fsb2, oevent=4, nevent=1, xfer-status=1
quar_remote_recv_send()-731: dev=fortisandbox-fsb3 xfer-status=0
__quar_build_pkt()-408: build req(id=338, type=6) for vdom-vdom1, len=93, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=93
quar_remote_send()-520: req(id=338, type=6) read response, dev=fortisandbox-fsb3, xfer_
status=1, buflen=12
quar_remote_recv_send()-770: dev-fortisandbox-fsb3, oevent=4, nevent=1, xfer-status=1
quar_remote_recv_send()-731: dev=fortisandbox-fsb5 xfer-status=0
__quar_build_pkt()-408: build req(id=340, type=6) for vdom-vdom1, len=93, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=93
quar_remote_send()-520: req(id=340, type=6) read response, dev=fortisandbox-fsb5, xfer_
status=1, buflen=12
quar_remote_recv_send()-770: dev-fortisandbox-fsb5, oevent=4, nevent=1, xfer-status=1
quar_remote_recv_send()-731: dev=fortisandbox-fsb2 xfer-status=1
quar_remote_recv()-662: dev(fortisandbox-fsb2) received a packet: len=69, type=1
quar_remote_recv()-718: file-[337] is accepted by server(fortisandbox-fsb2).
quar_put_job_req()-332: Job 337 deleted
quar_remote_recv_send()-731: dev=fortisandbox-fsb4 xfer-status=0
__quar_build_pkt()-408: build req(id=339, type=6) for vdom-vdom1, len=93, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=93
quar_remote_send()-520: req(id=339, type=6) read response, dev=fortisandbox-fsb4, xfer_
status=1, buflen=12
quar_remote_recv_send()-770: dev-fortisandbox-fsb4, oevent=4, nevent=1, xfer-status=1
quar_remote_recv_send()-731: dev=fortisandbox-fsb1 xfer-status=0
__quar_build_pkt()-408: build req(id=336, type=4) for vdom-root, len=98, oftp_name=
__quar_send()-470: dev buffer -- pos=0, len=98
...
__get_analytics_stats()-19: Received an ANALYTICS_STATS request, vfid: 0
__quar_req_handler()-127: Request 0 was handled successfully
__get_analytics_stats()-19: Received an ANALYTICS_STATS request, vfid: 0
__quar_req_handler()-127: Request 0 was handled successfully
__get_analytics_stats()-19: Received an ANALYTICS_STATS request, vfid: 0
__quar_req_handler()-127: Request 0 was handled successfully
__get_analytics_stats()-19: Received an ANALYTICS_STATS request, vfid: 0
Web filter
Web filtering restricts or controls user access to web resources and can be applied to firewall policies using either policy-
based or profile-based NGFW mode.
In FortiOS, there are three main components of web filtering:
l Web content filter: blocks web pages containing words or patterns that you specify.
l URL filter: uses URLs and URL patterns to block or exempt web pages from specific sources, or block malicious
URLs discovered by FortiSandbox.
l FortiGuard Web Filtering service: provides many additional categories you can use to filter web traffic.
These components interact with each other to provide maximum control over what users on your network can view and
protect your network from many internet content threats.
Web filters are applied in the following order:
1. URL filter
2. FortiGuard Web Filtering
3. Web content filter
4. Web script filter
5. Antivirus scanning
FortiOS includes three preloaded web filter profiles:
l default
l monitor-all (monitors and logs all URLs visited, flow-based)
l wifi-default (default configuration for offloading WiFi traffic)
You can customize these profiles, or you can create your own to manage network user access.
URL filter
The URL filter uses specific URLs with patterns containing text and regular expressions so the FortiGate can process the
traffic based on the filter action (exempt, block, allow, monitor) and web pages that match the criteria. Once a URL filter
is configured, it can be applied to a firewall policy.
The following filter types are available:
Simple The FortiGate tries to strictly match the full context. For example, if you enter
www.facebook.com in the URL field, it only matches traffic with www.facebook.com. It won't
match facebook.com or message.facebook.com.
When the FortiGate finds a match, it performs the selected URL action.
Regular The FortiGate tries to match the pattern based on the rules of regular expressions or
expression/ wildcards. For example, if you enter *fa* in the URL field, it matches all the content that has fa
wildcard such as www.facebook.com, message.facebook.com, fast.com, and so on.
When the FortiGate finds a match, it performs the selected URL action.
For more information, see the URL Filter expressions technical note in the Knowledge Base.
The following actions are available:
Exempt The traffic is allowed to bypass the remaining FortiGuard web filters, web content filters, web
script filters, antivirus scanning, and DLP proxy operations.
Block The FortiGate denies or blocks attempts to access any URL that matches the URL pattern. A
replacement message is displayed.
Allow The traffic is passed to the remaining FortiGuard web filters, web content filters, web script
filters, antivirus proxy operations, and DLP proxy operations. If the URL does not appear in
the URL list, the traffic is permitted.
Monitor The traffic is processed the same way as the Allow action. For the Monitor action, a log
message is generated each time a matching traffic pattern is established.
In the following example, a URL filter will be created to block the facebook.com URL using a wildcard.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Static URL Filter section, enable URL Filter.
3. Click Create New. The New URL Filter pane opens.
4. For URL, enter *facebook.com, for Type, select Wildcard, and for Action, select Block.
Verify the URL filter results by going to a blocked website. For example, when you go to the Facebook website, the
replacement message appears:
FortiGuard filter
The FortiGuard filter enhances the web filter features by sorting billions of web pages into a wide range of categories that
users can allow or block.
The FortiGuard Web Filtering service includes over 45 million individual website ratings that apply to more than two
billion pages. When the FortiGuard filter is enabled in a web filter profile and applied to firewall policies, if a request for a
web page appears in traffic controlled by one of the firewall policies, the URL is sent to the nearest FortiGuard server.
The URL category or rating is returned. If the category is blocked, the FortiGate shows a replacement message in place
of the requested page. If the category is not blocked, the page request is sent to the requested URL as normal.
To use this service, you must have a valid FortiGuard license.
The following actions are available:
Monitor Permit and log access to sites in the category. User quotas can be enabled for this option (see
Usage quota on page 1151).
Block Prevent access to the sites in the category. Users trying to access a blocked site see a
replacement message indicating the site is blocked.
Warning Display a message to the user allowing them to continue if they choose.
Authenticate Require the user to authenticate with the FortiGate before allowing access to the category or
category group.
Disable Remove the category from the from the web filter profile.
This option is only available for local or remote categories from the right-click menu.
FortiGuard has many web filter categories, including two local categories and a special remote category. Refer to the
following table for more information:
The priority of categories is local category > external category > FortiGuard built-in category. If a URL is configured as a
local category, it only follows the behavior of the local category and not the external or FortiGuard built-in category.
The following example shows how to block a website based on its category. The information and computer security
category (category 52) will be blocked.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the FortiGuard category based filter section, select Information and Computer Security, then click Block.
set category 52
set action block
next
end
end
next
end
3.
There is an option to allow users with valid credentials to override blocked categories.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. Enable Allow users to override blocked categories.
3. Enter information in the following fields:
l Groups that can override
l Profile name
l Switch applies to
l Switch Duration
5. Click OK.
The following example shows how to issue a warning when a user visits a website in a specific category (information and
computer security, category 52).
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the FortiGuard category based filter section, select Information and Computer Security, then click Warning.
3. Set the Warning Interval, then click OK.
The warning interval is the amount of time until the warning appears again after the user proceeds past it.
The following example shows how to authenticate a website based on its category (information and computer security,
category 52).
1. Go to Security Profiles > Web Filter and edit or create a new web filter profile.
2. In the FortiGuard category based filter section, select Information and Computer Security, then click Authenticate.
3. Set the Warning Interval and select one or more user groups, then click OK.
4. Configure the remaining settings as needed.
5. Click OK.
3. Enter the username and password for the configured user group, then click Continue.
When the category action is Block, Warning, or Authenticate, you can customize the replacement message page that a
user sees.
1. Go to Security Profiles > Web Filter and edit or create a new web filter profile.
2. In the FortiGuard category based filter section, right-click on a category and select Customize.
3. Select a Replacement Message Group. See Replacement message groups on page 906 for details.
4. Optionally, click Edit FortiGuard Block Page or Edit FortiGuard Warning Page to make modifications.
5. Click Save.
6. Configure the remaining settings as needed.
7. Click OK.
When credential phishing prevention is enabled, the FortiGate scans for corporate credentials submitted to external
websites and compares them to sensitive credentials stored in the corporate domain controller. Based on the configured
antiphishing rules in proxy mode web filter profiles, the FortiGate will block the URL or alert the user if the credentials
match ones that are stored on the corporate domain controller.
l The corporate domain controller must be configured in the credential-store.
l Credentials can be matched based on sAMAccountName, user principal name (UPN), or down-level logon name.
l The antiphishing profile defines the corporate domain controller, antiphishing check option, default action if no rules
match, antiphishing status, and so on.
l Inspection entries in the profile define what action occurs when the submission request matches the specified
FortiGuard categories.
l The profile scans for pre-defined and custom username and password fields in the HTTP request, such as
username, auth, and password. You can evaluate custom fields by configuring custom patterns.
l The URL filter defines individual URLs that the antiphish action (block or log) is applied to when the URL submission
request matches.
l DC Authentication through Active Directory Device Registration Service (AD DRS) is supported. Active Directory
Lightweight Directory Services (AD LDS) support is available in FortiOS 7.0.
Web-based URL filter actions and FortiGuard category-based filtering have higher priority than
antiphishing URL filter actions and FortiGuard filtering:
l If a request is blocked by the web-based URL filter or FortiGuard filter, there is no further
antiphishing scanning. Antiphishing scanning only happens after the web-based URL
filtes and FortiGuard filters allow the traffic.
l If a submission matches an entry in the URL filter table that has an antiphishing action,
the defined action is taken. No further FortiGuard category-based rules are applied.
l Like firewall rules, the URL filter table and Fortiguard category-based antiphishing rules
use a top-down priority. The rule that matches first is the one that is used.
In this example, URLs that match FortiGuard category 37 (social networking) will be blocked and other categories will be
logged.
2. Configure the antiphishing profile, which includes the FortiGuard category rule:
config webfilter profile
edit <profile-name>
set feature-set proxy
...
config web
...
end
config antiphish
check-basic-auth enables support for scanning the HTTP basic authentication field.
l
next
end
4. Optionally, define custom patterns to scan fields other than the built-in username and password keywords:
config webfilter profile
edit "<profile-name>"
config custom-patterns
edit "customer-name"
set category username
next
edit "customer-passwd"
set category password
next
end
end
next
end
Usage quota
In addition to using category and classification blocks and overrides to limit user access to URLs, you can set a daily
quota by category, category group, or classification. Quotas allow access for a specified length of time or a specific
bandwidth, and are calculated separately for each user. Quotas are reset daily at midnight.
Quotas can be set for the Monitor, Warning, or Authenticate actions. Once the quota is reached, the traffic is blocked and
the replacement message page displays.
Configuring a quota
The following example shows how to set a time quota for the education category (category 30).
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. For Feature set, select Proxy-based.
3. In the FortiGuard category based filter section, scroll to the General Interest - Personal and click the + to expand the
section.
edit 1
set category 30
next
end
config quota
edit 1
set category 30
set type time
set duration 5m
next
end
end
next
end
1. Go to a website that belongs to the education category, such https://www.harvard.edu/. You can view websites in
that category at the moment.
2. In FortiOS, go to Dashboard > FortiGuard Quota Monitor to check the used and remaining time .
3. When the quota reaches its limit, traffic is blocked and the replacement page displays.
You can control access to web content by blocking webpages containing specific words or patterns. This helps to
prevent access to pages with questionable material. You can specify words, phrases, patterns, wildcards, and regular
expressions to match content on webpages. You can use multiple web content filter lists and select the best one for each
web filter profile. The maximum number of web content patterns in a list is 5000.
When configuring a web content filter list, the following patterns are available:
Wildcard Use this setting to block or exempt one word or text strings of up to 80 characters. You can
also use wildcard symbols such as ? or * to represent one or more characters. For example, a
wildcard expression forti*.com matches fortinet.com and fortiguard.com. The * represents any
character appearing any number of times.
Regular expression Use this setting to block or exempt patterns of regular expressions that use some of the same
symbols as wildcard expressions, but for different purposes. In regular expressions, *
represents the character before the symbol. For example, forti*.com matches fortiii.com but
not fortinet.com or fortiice.com. In this case, the symbol * represents i appearing any number
of times.
Content evaluation
The web content filter scans the content of every webpage that is accepted by a firewall policy. The system administrator
can specify banned words and phrases and attach a numerical value (or score) to the importance of those words and
phrases. When the web content filter scan detects banned content, it adds the scores of banned words and phrases
found on that page. If the sum is higher than a threshold set in the web filter profile, the FortiGate blocks the page.
The default score for web content filter is 10 and the default threshold is 10. This means that by default, a webpage is
blocked by a single match. These settings can only be configured in the CLI.
Banned words or phrases are evaluated according to the following rules:
l The score for each word or phrase is counted only once, even if that word or phrase appears many times in the
webpage.
l The score for any word in a phrase without quotation marks is counted.
l The score for a phrase in quotation marks is counted only if it appears exactly as written.
The following table is an example of how rules are applied to the webpage contents . For example, a webpage contains
only this sentence:
The score for each word or phrase is counted only once, even if that word or phrase appears many times in the
webpage.
word phrase 20 40 20 Each word appears twice but is only counted once,
giving a total score of 40. The webpage is blocked.
word sentence 20 20 20 word appears twice and sentence does not appear, but
since any word in a phrase without quotation marks is
counted, the score for this pattern is 20. The webpage
is blocked.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Static URL Filter section, enable Content Filter.
3. Click Create New. The New Web Content Filter pane opens.
4. Configure the following settings:
Pattern fortinet
Language Western
Action Block
Status Enable
Advanced filters 1
This setting blocks malicious URLs that FortiSandbox finds. Your FortiGate must be connected to a registered
FortiSandbox.
For information on configuring FortiSandbox, see Using FortiSandbox with antivirus on page 1122 and Using
FortiSandbox Cloud with antivirus on page 1129.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Static URL Filter section, enable Block malicious URLs discovered by FortiSandbox.
3. Click OK.
If you do not have a FortiGuard license, but you have enabled services that need a FortiGuard license (such as
FortiGuard filter), then you will get a rating error message.
Use this setting to allow access to websites that return a rating error from the FortiGuard Web Filter service.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Rating Options section, enable Allow websites when a rating error occurs.
3. Click OK.
If you enable this setting, in addition to only sending domain information to FortiGuard for rating, the FortiGate always
sends both the URL domain name and the TCP/IP packet's IP address (except for private IP addresses) to FortiGuard
for the rating.
The FortiGuard server might return a different category of IP address and URL domain. If they are different, the
FortiGate uses the rating weight of the IP address or domain name to determine the rating result and decision. This
rating weight is hard-coded in FortiOS.
For example, if we use a spoof IP of Google as www.irs.gov, the FortiGate will send both the IP address and domain
name to FortiGuard to get the rating. We get two different ratings: one is the search engine and portals that belong to the
Google IP, the second is the government and legal organizations that belongs to www.irs.gov. Because the search
engine and portals rating has a higher weight than government and legal organizations, the traffic is rated as search
engine and portals.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Rating Options section, enable Rate URLs by domain and IP address.
3. Click OK.
Use this setting to block websites when their SSL certificate CN field does not contain a valid domain name.
This option also blocks URLs that contains spaces. If there is a space in the URL, it must be written as %20 in the URL
path.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Static URL Filter section, enable Block invalid URLs .
3. Click OK.
Advanced filters 2
Safe search
This setting applies to popular search sites and prevents explicit websites and images from appearing in search results.
The supported search sites are:
l Google
l Yahoo
l Bing
l Yandex
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Search Engines section, enable Enforce 'Safe Search' on Google, Yahoo!, Bing, Yandex.
3. Click OK.
Use these features to limit users' access to YouTube channels. For example, in an education environment where you
want students and users to be able to access YouTube education videos but not other YouTube videos.
The Restrict YouTube Access setting adds the HTTP header YouTube-Restrict: Strict or YouTube-
Restrict: Moderate into the HTTP request when enabled. When YouTube reads this header, it applies the
appropriate content restriction based on the selected mode. YouTube Restricted Mode is an optional setting that filters
out potentially mature videos while leaving a large number of videos still available (see Restrict YouTube content
available to users and Manage your organization's YouTube settings for more information). Google defines the restricted
YouTube access modes as follows:
l Strict Restricted YouTube access: this setting is the most restrictive. Strict Restricted Mode does not block all
videos, but works as a filter to screen out many videos based on an automated system, while leaving some videos
still available for viewing.
l Moderate Restricted YouTube access: this setting is similar to Strict Restricted Mode but makes a much larger
collection of videos available.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Search Engines section, enable Restrict YouTube Access and select Strict or Moderate.
3. Click OK.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Proxy Options section, enable Restrict YouTube access to specific channels.
3. Click Create New. The New YouTube Channel Filter pane opens.
4. Enter the Channel ID, for example, UCGzuiiLdQZu9wxDNJHO_JnA.
5. Click OK. The entry appears in the table with its link.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Search Engines section, enable Log all search keywords.
3. Click OK.
Use this setting to block access to certain Google accounts and services, while allowing access to accounts with
domains in the exception list.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Proxy Options section, enable Restrict Google account usage to specific domains.
3. Click the + and enter the domains that Google can access, such as www.fortinet.com.
4. Click OK.
When you try to use Google services like Gmail, only traffic from the domain of www.fortinet.com can go through. Traffic
from other domains is blocked.
Use this setting to select the action to take with HTTP POST traffic. HTTP POST is the command used by the browser
when you send information, such as a completed form or a file you are uploading to a web server. The action options are
allow or block. The default is allow.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile.
2. In the Proxy Options section, for HTTP POST Action, select Allow or Block.
3. Click OK.
Web filter profiles have settings to filter Java applets, ActiveX, and cookies from web traffic. Note that if these filters are
enabled, websites using Java applets, ActiveX, and cookies might not function properly.
1. Go to Security Profiles > Web Filter and click Create New, or edit an existing profile. and go to the Proxy Options
section.
2. In the Proxy Options section, enabled the filters you want to use: Remove Java Applets, Remove ActiveX, or
Remove Cookies.
FortiOS provides diagnostics commands to view web filter statistics reports, which are either proxy-based or flow-based.
The commands are available in both VDOM and global command lines.
Use the diagnose wad filter vd {<VDOM> | global} command to filter for per-VDOM or global statistics
reports.
In the following example, there are two VDOMs (root and vdom1) using proxy-based policies that have web filter profiles
enabled.
content-type = 0
urls:
examined = 13
allowed = 2
blocked = 9
logged = 8
overridden = 0
(global) # diagnose wad filter vd ALL
(global) # diagnose wad stats filter list
filtering of all accessible vdoms
dlp = 0
content-type = 0
urls:
examined = 19
allowed = 5
blocked = 9
logged = 8
overridden = 0
Use the diagnose webfilter stats list {<VDOM> | global} command to check the flow-based web filter
statistics.
In the following example, the VDOM is using flow-based policies that have web filter profiles enabled.
As increasing numbers of malware have started to use SSL to attempt to bypass IPS, maintaining a fingerprint-based
certificate blocklist is useful to block botnet communication that relies on SSL.
This feature adds a dynamic package that is distributed by FortiGuard and is part of the Web Filtering service. It is
enabled by default for SSL/SSH profiles, and can be configured using the following CLI commands:
config vdom
edit <vdom>
config firewall ssl-ssh-profile
edit "certificate-inspection"
set block-blacklisted-certificates enable
next
edit "deep-inspection"
set block-blacklisted-certificates enable
next
end
next
end
DNS filter
You can apply DNS category filtering to control user access to web resources. You can customize the default profile, or
create your own to manage network user access and apply it to a firewall policy, or you can add it to a DNS server on a
FortiGate interface. For more information about configuring DNS, see DNS on page 430. In FortiOS 6.4, the DNS proxy
daemon handles the DNS filter in flow and proxy mode policies.
DNS filtering has the following features:
l FortiGuard Filtering: filters the DNS request based on the FortiGuard domain rating.
l Botnet C&C domain blocking: blocks the DNS request for the known botnet C&C domains.
l External dynamic category domain filtering: allows you to define your own domain category.
l DNS safe search: enforces Google, Bing, and YouTube safe addresses for parental controls.
l Local domain filter: allows you to define your own domain list to block or allow.
l External IP block list: allows you to define an IP block list to block resolved IPs that match this list.
l DNS translation: maps the resolved result to another IP that you define.
DNS filtering connects to the FortiGuard secure DNS server over anycast by default. For more information about this
configuration, see DNS over TLS on page 441.
DNS filter profiles cannot be used in firewall policies with NGFW policy-based mode; see
Profile-based NGFW vs policy-based NGFW on page 947 for more information. They can be
used in the DNS server; see FortiGate DNS server on page 434 for more information.
1. Go to Security Profiles > DNS Filter and click Create New, or edit an existing profile.
2. Configure the settings as needed.
3. Click OK.
end
end
set log-all-domain enable
set sdns-ftgd-err-log enable
set sdns-domain-log enable
set block-action redirect
set block-botnet enable
set safe-search enable
set redirect-portal 93.184.216.34
set youtube-restrict strict
next
end
1. Go to Policy & Objects > Firewall Policy and click Create New, or edit an existing policy.
2. In the Security Profiles section, enable DNS Filter and select the DNS filter.
next
end
You can use the FortiGuard category-based DNS domain filter to inspect DNS traffic. This makes use of FortiGuard's
continuously updated domain rating database for more reliable protection.
The FortiGate must have a FortiGuard Web Filter license to use the FortiGuard category-
based filter.
1. Go to Security Profiles > DNS Filter and click Create New, or edit an existing profile.
2. Enable FortiGuard Category Based Filter.
3. Select the category and then select Allow, Monitor, or Redirect to Block Portal for that category.
4. In the Options section, select a setting for Redirect Portal IP. Select either Use FortiGuard Default (208.91.112.55)
or click Specify and enter another portal IP. The FortiGate will use the portal IP to replace the resolved IP in the DNS
response packet.
5. Click OK.
config ftgd-dns
set options error-allow
config filters
edit 2
set category 2
set action monitor
next
edit 7
set category 7
set action monitor
next
...
edit 22
set category 0
set action monitor
next
end
end
set log-all-domain enable
set sdns-ftgd-err-log enable
set sdns-domain-log enable
set block-action {redirect | block}
set block-botnet enable
set safe-search enable
set redirect-portal 93.184.216.34
set youtube-restrict strict
next
end
From your internal network PC, use a command line tool, such as dig or nslookup, to do a DNS query for some domains.
For example:
#dig www.example.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 61252
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 13; ADDITIONAL: 11
;; QUESTION SECTION:
;; www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 17164 IN A 93.184.216.34
;; AUTHORITY SECTION:
com. 20027 IN NS h.gtld-servers.net.
com. 20027 IN NS i.gtld-servers.net.
com. 20027 IN NS f.gtld-servers.net.
com. 20027 IN NS d.gtld-servers.net.
com. 20027 IN NS j.gtld-servers.net.
com. 20027 IN NS l.gtld-servers.net.
com. 20027 IN NS e.gtld-servers.net.
com. 20027 IN NS a.gtld-servers.net.
com. 20027 IN NS k.gtld-servers.net.
com. 20027 IN NS g.gtld-servers.net.
com. 20027 IN NS m.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 21999 IN A 192.5.6.30
a.gtld-servers.net. 21999 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 21997 IN A 192.33.14.30
b.gtld-servers.net. 21997 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 21987 IN A 192.26.92.30
c.gtld-servers.net. 20929 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 3340 IN A 192.31.80.30
d.gtld-servers.net. 3340 IN AAAA 2001:500:856e::30
e.gtld-servers.net. 19334 IN A 192.12.94.30
e.gtld-servers.net. 19334 IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 3340 IN A 192.35.51.30
;; Received 509 B
;; Time 2019-04-05 09:39:33 PDT
;; From 172.16.95.16@53(UDP) in 3.8 ms
1. Go to Log & Report > DNS Query. There are logs for the DNS traffic that just passed through the FortiGate with the
FortiGuard rating for the domain name.
FortiGuard Service continually updates the botnet C&C domain list. The botnet C&C domain blocking feature can block
the botnet website access at the DNS name resolving stage. This provides additional protection for your network.
1. Go to Security Profiles > DNS Filter and click Create New, or edit an existing profile.
2. Enable Redirect botnet C&C requests to Block Portal.
3. Optionally, click the botnet package link. The Botnet C&C Domain Definitions pane opens, which displays the latest
list.
Select a botnet domain from that list. From your internal network PC, use a command line tool, such as dig or nslookup,
to send a DNS query to traverse the FortiGate. For example:
#dig canind.co
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 997
;; Flags: qr rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; canind.co. IN A
;; ANSWER SECTION:
canind.co. 60 IN A 208.91.112.55
;; Received 43 B
;; Time 2019-04-05 09:55:21 PDT
;; From 172.16.95.16@53(UDP) in 0.3 ms
The botnet domain query was blocked and redirected to the portal IP (208.91.112.55) .
1. Go to Log & Report > DNS Query to view the DNS query blocked as a botnet domain.
FortiOS also maintains a botnet C&C IP address database (IPDB). If a DNS query response IP address (resolved IP
address) matches an entry inside the botnet IPDB, this DNS query is blocked by the DNS filter botnet C&C.
Select an IP address from the IPDB list and use a reverse lookup service to find its corresponding domain name. From
your internal network PC, use a command line tool, such as dig or nslookup, to query this domain and verify that it is
blocked by the DNS filter botnet C&C. For example:
# dig cpe-98-25-53-166.sc.res.rr.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 35135
;; Flags: qr rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; cpe-98-25-53-166.sc.res.rr.com. IN A
;; ANSWER SECTION:
cpe-98-25-53-166.sc.res.rr.com. 60 IN A 208.91.112.55
;; Received 64 B
;; Time 2019-04-05 11:06:47 PDT
;; From 172.16.95.16@53(UDP) in 0.6 ms
Since the resolved IP address matches the botnet IPDB, the query was blocked and redirected to the portal IP
(208.91.112.55) .
1. Go to Log & Report > DNS Query to view the DNS query blocked by botnet C&C IPDB.
botnetip=98.25.53.166
2. If you do not see the widget, click Add Widget, and add the Botnet Activity widget.
The DNS safe search option helps avoid explicit and inappropriate results in the Google, Bing, and YouTube search
engines. The FortiGate responds with content filtered by the search engine.
For individual search engine safe search specifications, refer to the documentation for Google,
Bing, and YouTube.
1. Go to Security Profiles > DNS Filter and click Create New, or edit an existing profile.
2. Enable Enforce 'Safe search' on Google, Bing, YouTube.
3. For Restrict YouTube Access, click Strict or Moderate.
config ftgd-dns
set options error-allow
config filters
edit 2
set category 2
next
...
end
end
set log-all-domain enable
set block-botnet enable
set safe-search enable
set youtube-restrict strict
next
end
From your internal network PC, use a command line tool, such as dig or nslookup, and perform a DNS query on
www.bing.com. For example:
# dig www.bing.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 46568
;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.bing.com. IN A
;; ANSWER SECTION:
www.bing.com. 103 IN CNAME strict.bing.com
strict.bing.com. 103 IN A 204.79.197.220
;; Received 67 B
;; Time 2019-04-05 14:34:52 PDT
;; From 172.16.95.16@53(UDP) in 196.0 ms
The DNS query for www.bing.com returns with a CNAME strict.bing.com, and an A record for the CNAME. The user's
web browser then connects to this address with the same search engine UI, but any explicit content search is filtered out.
The DNS filter log in FortiOS shows a message of DNS Safe Search enforced.
In addition to the FortiGuard category-based domain filter, you can define a local static domain filter to allow or block
specific domains.
In a DNS filter profile, the local domain filter has a higher priority than FortiGuard category-based domain filter. DNS
queries are scanned and matched first with the local domain filter. If an entry matches and the local filter action is set to
block, then that DNS query is blocked and redirected.
If the local domain filter list has no match, then the FortiGuard category-based domain filter is used. If a DNS query
domain name rating belongs to the block category, the query is blocked and redirected. If the FortiGuard category-based
filter has no match, then the original resolved IP address is returned to the client DNS resolver.
If the local domain filter action is set to allow and an entry matches, it will skip the FortiGuard category-based domain
filter and directly return to the client DNS resolver. If the local domain filter action is set to monitor and an entry matches,
it will go to the FortiGuard category-based domain filter for scanning and matching.
1. Go to Security Profiles > DNS Filter and click Create New, or edit an existing profile.
2. In the Static Domain Filter section, enable Domain Filter.
3. Click Create New. The Create Domain Filter pane opens.
4. Enter a domain, and select a Type and Action. This example has three filters:
Wildcard entries are converted to regular expressions by FortiOS. As a result, wildcards will
match any suffix, as long as there is a word boundary following the search term.
For example:
config entries
edit 1
set domain "*.host"
set type wildcard
next
end
Since the local domain filter for google is set to monitor, it is blocked by the FortiGuard category-based domain filter
because the policy action is deny.
DNS translation
This setting allows you to translate a DNS resolved IP address to another IP address you specify on a per-policy basis.
For example, website A has a public address of 1.2.3.4. However, when your internal network users visit this website,
you want them to connect to the internal host 192.168.3.4. You can use DNS translation to translate the DNS resolved
address 1.2.3.4 to 192.168.3.4. Reverse use of DNS translation is also applicable. For example, if you want a public
DNS query of your internal server to get a public IP address, then you can translate a DNS resolved private IP to a public
IP address.
Sample configuration
This configuration forces the DNS filter profile to translate 93.184.216.34 (www.example.com) to 192.168.3.4. When
internal network users perform a DNS query for www.example.com, they do not get the original www.example.com IP
address of 93.184.216.34. Instead, it is replaced with 192.168.3.4.
1. Go to Security Profiles > DNS Filter and click Create New, or edit an existing profile.
2. In the Static Domain Filter section, enable DNS Translation.
3. Click Create New. The New DNS Translation pane opens.
4. Enter the Original Destination (the domain's original IP address), the Translated Destination IP address, and the
Network Mask.
To check DNS translation using a command line tool before DNS translation:
# dig www.example.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 27030
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 2; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 33946 IN A 93.184.216.34
;; AUTHORITY SECTION:
example.com. 18578 IN NS b.iana-servers.net.
example.com. 18578 IN NS a.iana-servers.net.
;; Received 97 B
;; Time 2019-04-08 10:47:26 PDT
;; From 172.16.95.16@53(UDP) in 0.5 ms
To check DNS translation using a command line tool after DNS translation:
# dig www.example.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 62060
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 2; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 32491 IN A 192.168.3.4
;; AUTHORITY SECTION:
example.com. 17123 IN NS b.iana-servers.net.
example.com. 17123 IN NS a.iana-servers.net.
;; Received 97 B
;; Time 2019-04-08 11:11:41 PDT
;; From 172.16.95.16@53(UDP) in 0.5 ms
config dns-translation
edit 1
set src 93.184.216.34
set dst 1.2.3.4
set netmask 255.255.224.0
next
end
To check DNS translation using a command line tool after DNS translation:
# dig www.example.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 6736
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 2; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 29322 IN A 1.2.24.34
;; AUTHORITY SECTION:
example.com. 13954 IN NS a.iana-servers.net.
example.com. 13954 IN NS b.iana-servers.net.
;; Received 97 B
;; Time 2019-04-08 12:04:30 PDT
;; From 172.16.95.16@53(UDP) in 2.0 ms
The binary arithmetic to convert 93.184.216.34 to 1.2.3.4 with the subnet mask is as follows:
1. AND src(Original IP) with negative netmask (93.184.216.34 & ~255.255.224.0):
01011101.10111000.11011000.00100010 93.184.216.34
00000000.00000000.00011111.11111111 ~255.255.224.0
-------------------------------------------------------- &
00000000.00000000.00011000.00100010 0.0.24.34
You can configure a FortiGate as a DNS server in your network. When you enable DNS service on a specific interface,
the FortiGate will listen for DNS service on that interface.
Depending on the configuration, DNS service works in three modes: Recursive, Non-Recursive, or Forward to System
DNS (server). For details on how to configure the FortiGate as a DNS server and configure the DNS database, see
FortiGate DNS server on page 434.
You can apply a DNS filter profile to Recursive and Forward to System DNS mode. This is the same as the FortiGate
working as a transparent DNS proxy for DNS relay traffic.
1. Go to Network > DNS Servers (if this option is not available, go to System > Feature Visibility and enable
DNS Database).
2. In the DNS Service on Interface section, click Create New and select an Interface from the dropdown.
3. For Mode, select Forward to System DNS.
5. Click OK.
To check DNS service with a DNS filter profile using a command line tool:
In this example, port10 is enabled as a DNS service with the DNS filter profile demo. The IP address of port10 is
10.1.100.5 , and the DNS filter profile is configured to block category 52 (information technology). From your internal
network PC, use a command line tool, such as dig or nslookup, to perform a DNS query. For example:
# dig @10.1.100.5 www.fortinet.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 52809
;; Flags: qr rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.fortinet.com. IN A
;; ANSWER SECTION:
www.fortinet.com. 60 IN A 208.91.112.55
;; Received 50 B
;; Time 2019-04-08 14:36:34 PDT
;; From 10.1.100.5@53(UDP) in 13.6 ms
The relay DNS traffic was filtered based on the DNS filter profile configuration. It was blocked and redirected to the portal
IP (208.91.112.55).
If you have trouble with the DNS filter profile in your policy, start with the following troubleshooting steps:
l Check the connection between the FortiGate and FortiGuard DNS rating server (SDNS server).
l Check that the FortiGate has a valid FortiGuard web filter license.
l Check the FortiGate DNS filter configuration.
Checking the connection between the FortiGate and FortiGuard SDNS server
You need to ensure the FortiGate can connect to the FortiGuard SDNS server. By default, the FortiGate uses UDP port
53 to connect to the SDNS server.
The SDNS server IP address might be different depending on location (in this example, it is 208.91.112.220:53).
2. In the management VDOM, check the communication between the FortiGate and the SDNS server:
#execute ping 208.91.112.220
3. Optionally, you can check the communication using a PC on the internal network (this example uses dig).
a. Disable the DNS filter profile so that it does not affect your connection check.
b. Ping your ISP or a public DNS service provider's DNS server, for example, Google's public DNS server of
8.8.8.8:
#dig @8.8.8.8 www.fortinet.com
c. Verify that you can get a domain www.fortinet.com A record from the DNS server. This shows that the UDP port
53 connection path is not blocked.
#dig @8.8.8.8 www.fortinet.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 35121
;; Flags: qr rd ra; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.fortinet.com. IN A
;; ANSWER SECTION:
www.fortinet.com. 289 IN CNAME fortinet-prod4-858839915.us-west-
1.elb.amazonaws.com.
fortinet-prod4-858839915.us-west-1.elb.amazonaws.com. 51 IN A
52.8.142.247
fortinet-prod4-858839915.us-west-1.elb.amazonaws.com. 51 IN A
13.56.55.78
;; Received 129 B
;; Time 2019-04-29 14:13:18 PDT
;; From 8.8.8.8@53(UDP) in 13.2 ms
The FortiGuard DNS rating service shares the license with the FortiGuard web filter, so you must have a valid web filter
license for the DNS rating service to work. While the license is shared, the DNS rating service uses a separate
connection mechanism from the web filter rating.
2. Look for the FGD_DNS_SERVICE_LICENSE line and check that the license has not expired:
FGD_DNS_SERVICE_LICENSE:
server=208.91.112.220:53, expiry=2022-10-03, expired=0, type=2
1. In FortiOS, create a local domain filter and set the Action to Redirect to Block Portal (see Local domain filter on page
1177).
2. Apply this DNS filter profile to the policy.
3. From the client PC, perform a DNS query on this domain. If you get the profile's redirected portal address, this
means that the DNS filter profile works as expected.
Additional troubleshooting
Use diagnose test application dnsproxy <test level> to troubleshoot further DNS proxy information,
where:
2 Show statistics
4 Reload FQDN
5 Requery FQDN
6 Dump FQDN
Application control
FortiGates can recognize network traffic generated by a large number of applications. Application control sensors
specify what action to take with the application traffic. Application control uses IPS protocol decoders that can analyze
network traffic to detect application traffic, even if the traffic uses non-standard ports or protocols. Application control
supports traffic detection using the HTTP protocol (versions 1.0, 1.1, and 2.0).
Once you have created an application sensor, you can define the applications that you want to control. You can add
applications and filters using categories, application overrides, and/or filter overrides with designated actions (monitor,
allow, block, or quarantine).
Categories allow you to choose groups of signatures based on a category type. Applications belonging to the category
trigger the action that is set for the category. For a list of application control categories, refer to the FortiGuard Labs
website.
1. Go to Security Profiles > Application Control and click Create New, or edit an existing sensor.
2. Under Categories, click the icon next to the category name to set the action or view the application signatures.
3. Click OK.
Multiple application signatures can be added for one sensor with a designated action. Filters can be added based on
behavior, application category, popularity, protocol, risk, technology, or vendor subtypes.
1. Go to Security Profiles > Application Control and click Create New, or edit an existing sensor.
2. In the Application and Filter Overrides table, click Create New.
3. Add an application:
a. For Type, select Application.
b. Select an Action from the dropdown.
c. In the Search box, enter an application name and press Enter.
d. In the search results, select desired the applications (you can select multiple applications) and click Add
Selected.
e. Click OK.
4. Add a filter:
a. In the Application and Filter Overrides table, click Create New.
b. For Type, select Filter.
c. Select an Action from the dropdown.
d. In the Filter field, click the + . The Select Entries pane opens, and you can search based on filter subtypes. This
example has excessive bandwidth (under behavior) and game (under application category).
e. Click OK.
5. Click OK.
l 0 (network-protocol)
l 1 (browser-based)
l 2 (client-server)
l 4 (peer-to-peer)
behavior <id> Application behavior filter:
l all
l 2 (botnet)
l 3 (evasive)
l 5 (excessive bandwidth)
l 6 (tunneling)
l 9 (cloud)
popularity <integer> Application popularity filter (1 - 5, from least to most popular).
action {pass | block | Pass/block traffic or reset the connection for traffic from this application (default =
reset} block).
log {enable | disable} Enable/disable logging for this application list (default = enable).
In an application control list, the exclusion option allows users to specify a list of applications they wish to exclude from
an entry filtered by category, technology, or others. By excluding the signature, the application is no longer processed on
the entry in which it is excluded, but may match subsequent entries that exist.
Sample configurations
In the following example, category 23 (social media) is blocked in the entries, and signature 34527 (Instagram) is
excluded from this entry. Traffic to Instagram will pass because the signature is removed from entry 1 and the action of
other-application-action is set to pass.
In the following example, entry 1 is configured so that category 23 (social media) is set to pass and signature 34527
(Instagram) is excluded. In entry 2, application 34527 (Instagram) is blocked, so the traffic to Instagram will be blocked,
even though it is excluded in entry 1. Traffic to other signatures in category 23, such as Facebook, will still pass.
In the following example, an explicit proxy is behind the FortiGate with an excluded signature for 107347980
(Proxy.HTTP) and category 6 (proxy) is set to block. The client will allow normal proxy traffic to pass, but it will discard all
proxy application traffic (such as KProxy, Tor, and so on).
config entries
edit 1
set category 6
set exclusion 107347980
set action block
next
end
next
end
Most networking applications run on specific ports. For example, SSH runs on port 22, and Facebook runs on ports 80
and 443.
If the default network service is enabled in the application control profile, a port enforcement check is done at the
application profile level, and any detected application signatures running on the non-standard TCP/IP port are blocked.
This means that each allowed application runs on its default port.
For example, when applying this application control sensor, FTP traffic (application 15896) with the standard port (port
21) is allowed, while the non-standard port (port 2121) is blocked.
Protocol enforcement
Protocol enforcement allows you to configure networking services (e.g. FTP, HTTP, HTTPS) on known ports (e.g. 21,
80, 443). For protocols that are not allowlisted under select ports, the IPS engine performs the violation action to block,
allow, or monitor that traffic.
This feature can be used in the following scenarios::
l When one protocol dissector confirms the service of network traffic, protocol enforcement can check whether the
confirmed service is allowlisted under the server port. If it is not allowlisted, the traffic is considered a violation and
IPS can take the action specified in the configuration (block or monitor it).
l When there is no confirmed service for the network traffic, the traffic is considered a service violation if
IPS dissectors rule out all of the services enforced under its server port.
In an applicable profile, a default-network-service list can be created to associate well known ports with accepted
services.
When a FortiGate is sandwiched between SSL encryption and decryption devices, the FortiGate can process the
decrypted traffic that passes between those devices. This feature adds support for decrypted traffic in application
control. In some pre-defined signatures, the signature is pre-marked with the require_ssl_di tag. The force-
inclusion-ssl-di-sigs option under application list allows users to control the inspection of dissected
traffic. When this option is enabled, the IPS engine forces the pre-marked SSL-based signatures to be applied to the
decrypted traffic of the respective applications. In the following topology, SSL Proxy 1 handles the client connection and
SSL Proxy 2 handles the server connection, leaving the content unencrypted as traffic passes through the FortiGate.
next
end
F-SBID( --vuln_id 15722; --attack_id 42985; --name "Facebook_Chat"; --group im; --protocol tcp; --default_action pass; -
-revision 4446; --app_cat 23; --vendor 3; --technology 1; --behavior 9; --pop 4; --risk 2; --language "Multiple"; --weight 20;
--depend-on 15832; --depend-on 38468; --require_ssl_di "Yes"; --casi 1; --casi 8; --parent 15832; --app_port
"TCP/443"; --severity info; --status hidden; --service http; --flow from_client; --pattern "/pull?"; --context uri; --no_case; --
pattern ".facebook.com"; --context host; --no_case; --tag set,Tag.Facebook.Pull; --tag quiet; --scan-range 10m,all; --date
20190301; )
All signatures that include the require_ssl_di tag are pre-defined and cannot be customized.
Application control signatures that support parameters (such as SCADA protocols) can have multiple parameters
grouped together and matched at the same time. Multiple application parameter groups can be added to an override.
Traffic will be flagged if it matches at least one parameter group.
This example uses the Modbus_Func05.Write.Single.Coil.Validation signature. This is an industrial signature, so ensure
that no signatures are excluded:
config ips global
set exclude-signatures none
end
1. Go to Security Profiles > Application Control and click Create New, or edit an existing sensor.
2. In the Application and Filter Overrides table, click Create New.
3. Search for Modbus_Func05.Write.Single.Coil.Validation and press Enter. A gear icon beside the signature name
indicates it has configurable application parameters.
5. Click the Selected tab. In the Application Parameters section, click Create New.
7. Click OK.
8. Add more signatures if needed.
9. Click OK.
set category 2 6
next
end
next
end
Intrusion prevention
With the FortiOS intrusion prevention system (IPS), you can detect and block network-based attacks. You can configure
IPS sensors based on IPS signatures, IPS filters, outgoing connections to botnet sites, and rate-based signatures.
FortiOS includes eight preloaded IPS sensors:
l all_default
l all_default_pass
l default
l high_security
l protect_client
l protect_email_server
l protect_http_server
l wifi-default
You can customize these sensors, or you can create your own and apply it to a firewall policy.
The Botnet C&C section consolidates multiple botnet options in the IPS profile. This allows you to enable botnet blocking
across all traffic that matches the policy by configuring one setting in the GUI, or by the scan-botnet-connections
option in the CLI.
1. Go to Security Profiles > Intrusion Prevention and click Create New, or edit an existing sensor.
2. Navigate to the Botnet C&C section.
1. Go to System > FortiGuard. Botnet IPs and Botnet Domains are visible in the Intrusion Prevention section.
2. Click View List for more details.
1. Go to Security Profiles > DNS Filter and click Create New, or edit an existing filter.
2. Enable Redirect botnet C&C requests to Block Portal.
1. Go to Security Profiles > Intrusion Prevention and click Create New, or edit an existing sensor.
2. Enable Block malicious URLs.
1. Go to Security Profiles > Intrusion Prevention and click Create New, or edit an existing sensor.
2. In the IPS Signatures and Filters section, click Create New. A list of available signatures appears.
3. For Type, select Signature. Select the signatures you want to include from the list.
4. Configure the other settings as needed.
6. Click OK.
7. Add the sensor to a firewall policy to detect or block attacks that match the IPS signatures.
IEC 61850 is a SCADA protocol whose services are mapped to a number of protocols, including MMS services.
MMS/ICCP detection is supported in IPS. The purpose of the MMS dissectors is to identify every IEC 61850 service to
distinguish different MMS/ICCP messages. IPS engine 6.0.12 and later support MMS dissectors.
The following scenarios are also supported:
l Multiple MMS PDUs are transferred in one TCP payload, and the IPS engine identifies individuals.
l An MMS message is split over multiple TCP segments, where MMS runs over COTP segments.
l ICCP/TASE.2 that also uses MMS transport (ISO transport over TCP for ICCP) is detected.
Industrial signatures must be enabled in the global IPS settings to receive MMS/ICCP signatures. By default, industrial
signatures are excluded.
config ips global
set exclude-signatures none
end
Below are some industrial signatures for MMS/ICCP messages that can be detected by the IPS engine. This is not an
exhaustive list.
l MMS_GetNameList.Request
l MMS_GetNamedVariableListAttributes.Request
l MMS_GetVariableAccessAttributes.Request
l MMS_Identify.Request
l MMS_Initiate.Request
l MMS_Read.Request
l MMS_Reset.Request
l ICCP_Transfer.Reporting
l ICCP_Create.Dataset
l ICCP_Abort
l ICCP_Start.Transfer.DSTransferSet
l ICCP_Get.Dataset.Element.Values
l ICCP_Get.Next.DSTransfer.Set.Value
l ICCP_Delete.Dataset
l ICCP_Start.Transfer.IMTransferSet
Diagnose command
The COTP dissector adds support for identifying every MMS PDU, and let the IPS engine separate them, like the
Modbus and IEC-104 services for example.
# diagnose ips debug enable all
# diagnose debug enable
Log samples
MMS dissectors can be triggered, and MMS/ICCP signatures can be monitored and logged.
Log samples:
hold-time
The hold-time option allows you to set the amount of time that signatures are held after a FortiGuard IPS signature
update per VDOM. During the holding period, the signature's mode is monitor. The new signatures are enabled after the
hold-time, to avoid false positives.
The hold-time can be from 0 days and 0 hours (default) up to 7 days, in the format ##d##h.
When a signature that is on hold is matched, the log will include the message signature is on hold:
date=2010-07-06 time=00:00:57 logid="0419016384" type="utm" subtype="ips"
eventtype="signature" level="alert" vd="vd1" eventtime=1278399657778481842 tz="-0700"
severity="info" srcip=10.1.100.22 srccountry="Reserved" dstip=172.16.200.55 srcintf="port13"
srcintfrole="undefined" dstintf="port14" dstintfrole="undefined" sessionid=3620
action="detected" proto=6 service="HTTP" policyid=1 attack="Eicar.Virus.Test.File"
srcport=52170 dstport=80 hostname="172.16.200.55" url="/virus/eicar" direction="incoming"
CVE pattern
The CVE pattern option allows you to filter IPS signatures based on CVE IDs or with a CVE wildcard, ensuring that any
signatures tagged with that CVE are automatically included.
File filter
The file filter can be applied directly to firewall policies and supports various traffic protocols in proxy or flow mode.
MAPI Yes No
SSH Yes No
Prior to FortiOS 6.4.1, file filter was embedded in the web filter, email filter, SSH inspection, and CIFS profiles.
Logs
Go to Log & Report > File Filter to view the file filter logs.
Log samples
File filter allows the FortiGate to block files passing through based on file type based on the file's meta data only, and not
on file size or file content. A DLP sensor must be configured to block files based on size or content, such as SSN
numbers, credit card numbers or regexp.
The following file types are supported:
Type Description
Type Description
msoffice Match MS-Office files. For example, DOC, XLS, PPT, and so on.
msofficex Match MS-Office XML files. For example, DOCX, XLSX, PPTX, and so on.
rm Match RM files
xz Match XZ files
Email filter
Email filters can be configured to perform spam detection and filtering. You can customize the default profile, or create
your own and apply it to a firewall policy.
Two kinds of filtering can be defined in a single profile, and they will act independent of one
another.
The following table indicates which email filters are supported by their designated inspection modes.
Local-based filters
You can make block/allowlists from emails or IP subnets to forbid or allow them to send or receive emails. With the
spamhelodns (HELO DNS Lookup) and spamraddrdns (Return Email DNS Check) options, the FortiGate performs a
standard DNS check on the machine name used in the HELO SMTP message, and/or the return to field to determine if
these names belong to a registered domain. The FortiGate does not check the FortiGuard service during these
operations.
You can also define a list of banned words. Emails that contain any of these banned words are considered spam.
By default, HELO/DNS and Return-to/DNS checls are done before the block/allow list check.
In some situations, such as when configuring a block/allow list to clear an email from
performing further filtering, use the following command to give precedence to the block/allow
list:
config emailfilter profile
edit <filter>
config smtp
set local-override enable
next
end
end
c. Enable the Email Filter option and select the previously created profile.
d. Set SSL Inspection to a profile that has deep SSL inspection enabled.
Deep inspection is required if you intend to filter SMTP, POP3, IMAP, or any SSL/TLS encapsulated protocol.
e. Configure the other settings as needed.
f. Click OK.
.....
set inspection-mode proxy
set emailfilter-profile "myLocalEmailFilter"
next
end
FortiGuard-based filters
The FortiGate consults FortiGuard servers to help identify spammer IP address or emails, known phishing URLs, known
spam URLs, known spam email checksums, and others.
FortiGuard servers have maintained databases that contain blocklists, which are fed from Fortinet sensors and labs
distributed all over the world.
3. In the FortiGuard Spam Filtering Spam Filtering section, you can enable or disable the following filters:
l IP Address Check
l URL Check
l Spam Submission
4. Click OK.
In an email filter profile, there are options to configure settings for SMTP, POP3, IMAP, and MAPI protocols. For each
protocol, you can set an action to either discard (block), tag, or pass the log for that protocol. The action options vary per
protocol. For the tag action, the spam email can be tagged with configured text in the subject or header.
MAPI is only configurable in the CLI and with the proxy feature set.
hdrip {enable | disable} Enable/disable SMTP email header IP checks for spamfsip, spamrbl, and
spambwl filters.
local-override {enable | Enable/disable local filter to override SMTP remote check result.
disable}
You can configure an email filter to detect and log emails sent by Gmail and Hotmail. These interfaces do not use
standard email protocols (SMTP, POP3, or IMAP) and use HTTPS instead. However, you can still configure the email
filter to detect emails that pass through the FortiGate.
The FortiGate only detects and logs the emails, it does not discard or tag them.
The FortiGate data leak prevention (DLP) system prevents sensitive data from leaving or entering your network. You can
customize the default sensor or create your own by adding individual filters based on file type, file size, a regular
expression, an advanced rule, or a compound rule. Once configured, you can apply the DLP sensor to a firewall policy.
Data matching defined sensitive data patterns is blocked, logged, or allowed when it passes through the FortiGate.
DLP can only be configured in the CLI.
The filters in a DLP sensor can examine traffic for the following:
l Known files using DLP fingerprinting
l Known files using DLP watermarking
l Particular file types
l Particular file names
l Files larger than a specified size
l Data matching a specified regular expression
l Credit card and social security numbers
Filters are ordered, but there is no precedence between the possible actions.
DLP is primarily used to stop sensitive data from leaving your network. DLP can also be used to prevent unwanted data
from entering your network and to archive some or all of the content that passes through the FortiGate. DLP archiving is
configured per filter, which allows a single sensor to archive only the required data. You can configure the DLP archiving
protocol in the CLI (see Configure DLP sensors).
There are two forms of DLP archiving:
l Summary only: a summary of all the activity detected by the sensor is recorded. For example, when an email
message is detected, the sender, recipient, message subject, and total size are recorded. When a user accesses
the web, every URL that they visit is recorded.
l Full: detailed records of all the activity detected by the sensor is recorded. For example, when an email message is
detected, the message itself, including any attachments, is recorded. When a user accesses the web, every page
that they visit is archived.
The following topics provide information about DLP:
l Basic DLP filter types on page 1223
l DLP fingerprinting on page 1225
The following table indicates which protocols can be inspected by DLP based on the specified inspection modes.
Sometimes, file names are not accurately recorded in DLP logs, even though the files are blocked correctly based on the
DLP sensor. This is particularly apparent on cloud-based services, such as Google Drive or SharePoint.
For HTTP file uploads, some cloud services use proprietary encodings and APIs to transfer files and exchange
metadata, instead of standard HTTP mechanisms, requiring custom handling of the proprietary API. If a cloud service
changes the API without notice, the custom handling becomes outdated and file names might not be logged properly.
Due to this, special consideration must be taken when using DLP to block files by file pattern. To block a specific file type,
it is better to block by file type, and not by file name pattern.
A file type filter allows you to block, allow, log, or quarantine based on the file type specified in the file filter list.
config dlp filepattern
edit <id>
set name <string>
config entries
edit <pattern>
set filter-type {type | pattern}
set file-type <file type>
next
end
next
end
1. Create a file pattern to filter files based on the file name patter or file type.
For example, to filter for GIFs and PDFs:
config dlp filepattern
edit 11
set name "sample_config"
config entries
edit "*.gif"
set filter-type pattern
next
edit "pdf"
set filter-type type
set file-type pdf
next
end
next
end
File size
A file size filter checks for files that exceed the specific size, and performs the DLP sensor's configured action on them.
Regular expression
A regular expression filter is used to filter files or messages based on the configured regular expression pattern.
The credit card sensor can match the credit card number formats used by American Express, Mastercard, and Visa. It
can be used to filter files or messages.
The SSN sensor can be used to filter files or messages for Social Security Numbers.
DLP fingerprinting
DLP fingerprinting can be used to detect sensitive data. The file that the DLP sensor will filter for is uploaded and the
FortiGate generates and stores a checksum fingerprint. The FortiGate unit generates a fingerprint for all of the files that
are detected in network traffic, and compares all of the checksums stored in its database. If a match is found, the
configured action is taken.
Any type of file can be detected by DLP fingerprinting, and fingerprints can be saved for each revision of a file as it is
updated.
To use fingerprinting:
l Select the files to be fingerprinted by targeting a document source.
l Add fingerprinting filters to DLP sensors.
l Add the sensors to firewall policies that accept traffic that the fingerprinting will be applied on.
The document fingerprint feature requires a FortiGate device that has internal storage.
Command Description
server-type smb The protocol used to communicate with document server. Only
Samba (SMB) servers are supported.
period {none | daily | weekly | monthly} The frequency that the FortiGate checks the server for new or
changed files.
vdom {mgmt | current} The VDOM that can communicate with the file server.
remove-deleted {enable | disable} Enable/disable keeping the fingerprint database up to date when a file
is deleted from the server.
keep-modified {enable | disable} Enable/disable keeping the old fingerprint and adding a new one
when a file is changed on the server.
username <string> The user name required to log into the file server.
password <password> The password required to log into the file server.
file-pattern <string> Files matching this pattern on the server are fingerprinted.
sensitivity <Critical | Private | Warning> The sensitivity or threat level for matches with this fingerprint
database.
tod-hour <integer> Set the hour of the day. This option is only available when period is
not none.
Command Description
tod-min <integer> Set the minute of the hour. This option is only available when period
is not none.
weekday {sunday | monday | tuesday | Set the day of the week. This option is only available when period is
wednesday | thursday | friday | saturday} weekly.
date <integer> Set the day of the month. This option is only available when period
is monthly.
Command Description
sensitivity {Critical | Private | Warning} Select a DLP file pattern sensitivity to match.
match-percentage <integer> The percentage of the checksum required to match before the sensor
is triggered.
action {allow | log-only | block | ban | The action to take with content that this DLP sensor matches.
quarantine-ip}
The CLI debug command diagnose test application dlpfingerprint can be used to display the fingerprint
information that is on the FortiGate.
Fingerprint Daemon Test Usage;
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
1 : This menu
2 : Dump database
3 : Dump all files
5 : Dump all chunk
6 : Refresh all doc sources in all VDOMs
7 : Show the db file size and the limit
9 : Display stats
10 : Clear stats
99 : Restart this daemon
VoIP solutions
You can configure VoIP profiles to allow SIP and SCCP traffic and to protect your network from SIP- and SCCP-based
attacks.
FortiOS includes two preloaded VoIP profiles:
l default
l strict
You can customize these profiles, or you can create your own and add them to firewall policies that allow VoIP.
VoIP profiles cannot be used NGFW policy-based mode. See Profile-based NGFW vs policy-
based NGFW on page 947 for more information.
There are three scenarios in which the FortiOS session initiation protocol (SIP) solution is usually deployed:
1. The SIP server is in a private network, protected from the internet by a FortiOS device.
2. The SIP clients are in a private network, protected from the internet by a FortiOS device.
3. The SIP server is in a private network, such as a corporation's internal network or an ISP’s network, protected from
the Internet by a FortiOS device. The SIP clients are in a remote private network, such as a SOHO network, and
behind a NAT device that is not aware of SIP applications.
The following VIP, NAT, and HNT examples show configurations for each of the three common scenarios.
VIP
A FortiGate with SIP Application Layer Gateway (ALG) or SIP Session Helper protects the SIP server from the internet,
while SIP phones from the internet need to register to the SIP server and establish calls through it.
A VIP needs to be configured for the SIP server, and the VIP must be applied in a firewall policy for the phones to send
REGISTER messages through the FortiGate from port1 to port2.
Only one firewall policy needs to be configured for all SIP phones on both the internet and private network to register to
the SIP server through Port1 and set up SIP calls.
Assuming either SIP ALG or SIP Session Helper is enabled, configure the FortiGate with the following CLI commands:
config firewall vip
edit "VIP_for_SIP_Server"
set extip 172.20.120.50
set extintf "port1"
set mappedip "10.11.101.50"
next
end
Setting service to SIP and not All in the firewall policy can improve protection by restricting
the data traffic passing through the FortiGate to the SIP call traffic only.
NAT
A FortiGate with SIP ALG or SIP Session Helper protects the SIP phones and the internal network from the internet,
while SIP phones in the internal network need to register to the SIP server installed on the internet and establish calls
through it.
One firewall policy needs to be configured with NAT enabled for SIP phones to send REGISTER messages through the
FortiGate from port2 to port1.
Assuming either SIP ALG or SIP Session Helper is enabled, configure the FortiGate with the following CLI commands:
config firewall policy
edit 1
set srcintf "port2"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
HNT
A FortiGate with SIP ALG or SIP Session Helper protects the SIP server from the internet, while SIP phones are in
remote private networks behind NAT devices that are not aware of the SIP application.
For example, the SIP server is located in an ISP's service cloud that is protected by the FortiGate SIP ALG, and the
SIP phones are installed in the home networks of the ISP's customers.
The SIP messages traversing the remote NAT devices might have their IP addresses translated by the NAT device at
the network layer, but untranslated at the SIP application layer because those NAT devices are not aware of the
SIP applications. This causes problems in a SIP session initiated process. Special configurations for the Hosted NAT
Traversal (HNT) are required to resolve this issue.
To configure the FortiGate with HNT support for SIP phones A and B to set up calls with each other:
4. Apply the VoIP profile and VIP in a firewall policy for phone A and B to register and set up SIP calls through the
FortiGate and SIP server:
config firewall policy
edit 1
set srcintf "port1"
set dstintf "port2"
set srcaddr "all"
set dstaddr "VIP_for_SIP_Server"
set action accept
set schedule "always"
set service "SIP"
set utm-status enable
set voip-profile “hnt”
set nat enable
next
end
SIP ALG provides users with security features to inspect and control SIP messages that are transported through FortiOS
devices, including:
l Verifying the SIP message syntax.
l Blocking particular types of SIP requests.
l Restricting the rate of particular SIP requests.
These features are configured in the VoIP profile:
config voip profile
edit <voip_profile_name>
config sip set ...
The VoIP profile can then be applied to a firewall policy to process the SIP call traffic.
For syntax verification, the following attributes are available for configuration in the VoIP profile to determine what action
is taken when a specific syntax error or attack based on invalid syntax is detected. For example, the action can be set to
pass or discard it.
malformed-request-line
malformed-header-via
malformed-header-from
malformed-header-to
malformed-header-call-id
malformed-header-cseq
malformed-header-rack
malformed-header-rseq
malformed-header-contact
malformed-header-record-route
malformed-header-route
malformed-header-expires
malformed-header-content-type
malformed-header-content-length
malformed-header-max-forwards
malformed-header-allow
malformed-header-p-asserted-identity
malformed-header-sdp-v
malformed-header-sdp-o
malformed-header-sdp-s
malformed-header-sdp-i
malformed-header-sdp-c
malformed-header-sdp-b
malformed-header-sdp-z
malformed-header-sdp-k
malformed-header-sdp-a
malformed-header-sdp-t
malformed-header-sdp-r
malformed-header-sdp-m
The following options are available in the VoIP profile to block SIP messages:
block-long-lines
block-unknown
block-ack
block-bye
block-cancel
block-info
block-invite
block-message
block-notify
block-options
block-prack
block-publish
block-refer
block-register
block-subscribe
block-update
block-geo-red-options
The rate of certain types of SIP requests that are passing through the SIP ALG can be restricted :
register-rate
invite-rate
subscribe-rate
message-rate
notify-rate
refer-rate
update-rate
options-rate
ack-rate
prack-rate
info-rate
publish-rate
bye-rate
cancel-rate
SIP pinholes
When SIP ALG processes a SIP call, it usually opens pinholes for SIP signaling and RTP/RTCP packets. NAT usually
takes place during the process at both the network and SIP application layers. SIP ALG ensures that, with NAT
happening, corresponding SIP and RTP/RTCP pinholes are created during the process when it is necessary for call
sessions to be established through FortiOS devices.
By default, SIP ALG manages pinholes automatically, but some special configurations can be used to restrict the
pinholes if required.
By default, the strict-register attribute is enabled. When enabled, after a SIP endpoint registers to the SIP server through
a firewall policy on the FortiOS device, only the SIP messages sent from the same IP address as the SIP server are
allowed to pass through the SIP pinhole that is created in the FortiOS device to reach the SIP endpoints. If the attribute is
disabled, SIP messages from any IP addresses can pass through the pinhole created after the registration.
config voip profile
edit "voip-profile-name"
config sip
set strict-register [enable|disable]
...
end
next
end
In a SIP call through SIP ALG, the NATed RTP/RTCP port range is 5117 to 65533 by default. If required, the port range
can be restricted.
config voip profile
edit "voip-profile-name"
config sip
set nat-port-range <start_port_number>-<end_port_number>
...
end
next
end
In a SIP call session, the RTP port number is usually an even number and the RTCP port number is an odd number that
is one more than the RTP port number. It is best practice to configure start_port_number to an even number, and
end_port_number to an odd number, for example:
config voip profile
edit "voip-profile-name"
conf sip
set nat-port-range 30000-39999
end
next
end
Some SIP phones and servers can communicate using TLS to encrypt the SIP signaling traffic. To allow SIP over TLS
calls to pass through the FortiGate, the encrypted signaling traffic must be unencrypted and inspected. The FortiGate
SIP ALG intercepts, unencrypts , and inspects the SIP packets, which are then re-encrypted and forwarded to their
destination.
The SIP ALG only supports full mode TLS. This means that the SIP traffic between SIP phones and the FortiGate, and
between the FortiGate and the SIP server, is always encrypted. The highest TLS version supported by SIP ALG is TLS
1.2.
To enable SIP over TLS support, the SSL mode in the VoIP profile must be set to full. The SSL server and client
certificates can be provisioned so that the FortiGate can use them to establish connections to SIP phones and servers,
respectively.
The ssl_server_cert, ssl_client_cert, and key files can be generated using a certification tool, such as
OpenSLL, and imported to the local certificate store of the FortiGate from System > Certificates in the GUI. Existing
local certificates in the certificate store can also be used. As always for TLS connections, the certificates used must
be verified and trusted at the other end of the connection when required.
For example, the CA certificate of the SIP server's certificate should be imported to the FortiGate as an external CA
certification, such that the FortiGate can use it to verify the SIP server's certificate when setting up the TLS
connection. The CA certificate configured as the ssl_server_cert should be installed as the trusted certificate
on the SIP phones. The deployment of the certificates across the network depends on the SIP client and server
devices that are used in the system.
2. Apply the profile to the firewall policy:
config firewall policy
edit 1
set srcintf "port1"
set dstintf "port2"
set srcaddr "all"
set dstaddr "vip_sip_server"
set action accept
set schedule "always"
set service "SIP"
set utm-status enable
set voip-profile "tls"
next
end
The nat-port-range variable is used to specify a port range in the VoIP profile to restrict the NAT port range for real-
time transport protocol/real-time transport control protocol (RTP/RTCP) packets in a session initiation protocol (SIP) call
session that is handled by the SIP application layer gateway (ALG) in a FortiGate device.
When NAT is enabled, or VIP is used in a firewall policy for SIP ALG to handle a SIP call session established through a
FortiGate device, the SIP ALG can perform NAT to translate the ports used for the RTP/RTCP packets when they are
flowing through the device between the external and internal networks.
You can control the translated port range for RTP/RTCP packets using the CLI:
config voip profile
edit <profile-name>
config sip
set nat-port-range <port range>
end
next
end
Command Description
nat-port-range <port range> The NAT port range (minimum port number = 5117, default = 5117-65535).
Example
In this example, Phone1 is in subnet_1, and the SIP server and phone are in subnet_2. All SIP signaling messages and
RTP/RTCP packets go through the SIP Server. The RTP/RTCP ports on Phone1 are configured as 17078/17079.
The FortiGate administrator wants to use NAT for the port 17078/17079 to 30000/30001. As a result, all RTP/RTCP
packets going out of port2 have source ports of 30000/30001, and all RTP/RTCP packets going into port2 also have
destination ports of 30000/30001, which is specified in nat-port-range.
edit 1
set srcintf port1
set dstintf port2
set srcaddr all
set dstaddr all
set service SIP
set action accept
set schedule always
set voip-profile natPortRange
set nat enable
end
If phone1 and phone2 are registered to the SIP server, and they establish a call session between them through the
FortiGate and the SIP server, then the RTP/RTCP ports 17078/17079 of phone1 will be translated to ports 30000/30001
at the FortiGate unit based on the NAT port range setting. That is, the RTP/RTCP packets egressing port2 of the
Fortigate will have source ports of 30000/30001, and the RTP/RTCP packets ingressing port2 will have destination ports
of 30000/30001.
Voice VLAN auto-assignment
You can leverage LLDP-MED to assign voice traffic to the desired voice VLAN. After detection and setup, the IP phone
on the network is segmented to its own VLAN for policy, prioritization, and reporting. The LLDP reception capabilities in
FortiOS have been extended to support LLDP-MED assignment for voice, voice signaling, guest, guest voice signaling,
softphone, video conferencing, streaming video, and video signaling.
You can configure this feature using the following steps:
1. Setting up the VLAN for the voice device
2. Setting up the DHCP server for the voice VLAN
3. Setting up the LLDP network policy
4. Enabling LLDP on the physical interface that the VLAN belongs to
5. Applying the LLDP network policy on the physical interface
6. Confirming that the VLAN was assigned
To enable LLDP on the physical interface that the VLAN belongs to:
ICAP
Internet Content Adaptation Protocol (ICAP) is an application layer protocol that is used to offload tasks from the firewall
to separate, specialized servers. For more information see RFC 3507.
ICAP profiles can only be applied to policies that use proxy-based inspection. If you enable ICAP in a policy, HTTP and
HTTPS (if HTTPS inspection is supported) traffic that is intercepted by the policy is transferred to the ICAP server
specified by the selected ICAP profile. Responses from the ICAP server are returned to the FortiGate, and then
forwarded to their destination.
By default, ICAP is not visible in the GUI. See Feature visibility on page 925 for instructions on
making it visible.
ICAP filter profiles cannot be used in NGFW policy-based mode. See Profile-based NGFW vs
policy-based NGFW on page 947 for more information.
To configure ICAP:
In this example, the ICAP server performs proprietary content filtering on HTTP and HTTPS requests. If the content filter
is unable to process a request, then the request is blocked. Streaming media is not considered by the filter, so it is
allowed through and is not processed.
6. In the Port field, enter a new port number if required. The default value is 1344.
7. Click OK.
The maximum number of concurrent connections to ICAP server can be configured in the CLI.
The default setting is 100 connections.
l Path - The path to the processing component on the server, such as /proprietary_code/content-filter/.
l On Failure - Select Error to block the request. If the message cannot be processed, it will not be blocked.
l Path - The path to the processing component on the server, such as /proprietary_code/content-filter/.
l On Failure - Select Error to block the request. If the message cannot be processed, it will not be blocked.
6. Enable Streaming Media Bypass to not offload streaming media to the ICAP server.
7. Click OK.
6. Click OK.
ICAP HTTP responses can be forwarded or bypassed based on the HTTP header value and status code.
When configuring the ICAP profile, if response is enabled, the respmod-default-action option can be configured:
l If respmod-default-action is set to forward, FortiGate will treat every HTTP response, and send ICAP
requests to the ICAP server.
l If respmod-default-action is set to bypass, FortiGate will only send ICAP requests if the HTTP response
matches the defined rules, and the rule's action is set to forward.
When configuring a response rule:
l The http-resp-status-code option is configured to specific HTTP response codes. If the HTTP response has
any one of the configured values, then the rule takes effect.
l Multiple header value matching groups can be configured. If the header value matches one of the groups, then the
rule takes effect.
l If both status codes and header values are specified in a rule, the response must match at least one of each.
The UTM ICAP log category is used for logging actions when FortiGate encounters errors with the ICAP server, such as
no service, unreachable, error response code, or timeout. If an error occurs, a traffic log and an associated UTM ICAP
log will be created.
Example
The FortiGate acts as a gateway for the client PC and connects to a reachable ICAP server. The ICAP server can be in
NAT, transparent, or proxy mode.
In this example, client request HTTP responses will be forwarded to the ICAP server from all hosts if they have an HTTP
status code of 200, 301, or 302, and have content-type: image/jpeg in the their header.
The logs show that, in this case, the ICAP services stopped before the access. When the client tried to access HTTP and
ICAP took effect, the FortiGate sent the ICAP request to the ICAP server and received an error. The client sees a 502
Bad Gateway message, and FortiGate writes the two logs. In the GUI, the logged traffic is displayed as
Result: Deny: UTM Blocked.
Web application firewall (WAF) profiles can detect and block known web application attacks. You can configure WAF
profiles to use signatures and constraints to examine web traffic. You can also enforce an HTTP method policy, which
controls the HTTP method that matches the specified pattern.
You can customize the default profile, or you can create your own profile to apply access rules and HTTP protocol
constraints to traffic. You can apply WAF profiles to firewall policies when the inspection mode is set to proxy-based.
Web application firewall profiles cannot be used NGFW policy-based mode. See Profile-based
NGFW vs policy-based NGFW on page 947 for more information.
You can use a web application firewall profile to protect a server that is running a web application, such as webmail.
Web application firewall profiles are created with a variety of options called signatures and constraints. Once these
options are enabled, the action can be set to allow, monitor, or block. The severity can be set to high, medium, or low.
In the following example, the default profile will be targeted to block SQL injection attempts and generic attacks.
The web application firewall feature is only available when the policy inspection mode is proxy-
based.
c. Under Additional Features, click Show More and enable Multiple Security Profiles.
d. Click Apply.
2. Edit the default web application firewall profile:
Trojans and Known Exploits are blocked by default.
Offloading to a FortiWeb
If you have a FortiWeb, you may be able to offload the functions of the web application control to your FortiWeb. To find
out if this option is available, refer to the FortiOS or FortiWeb Release Notes for information about device compatibility.
To offload to a FortiWeb:
Secure sockets layer (SSL) content scanning and inspection allows you to apply antivirus scanning, web filtering, and
email filtering to encrypted traffic. You can apply SSL inspection profiles to firewall policies.
FortiOS includes four preloaded SSL/SSH inspection profiles, three of which are read-only and can be cloned:
l certificate-inspection
l deep-inspection
l no-inspection
The custom-deep-inspection profile can be edited, or you can create your own SSL/SSH inspection profiles.
Deep inspection (also known as SSL/SSH inspection) is typically applied to outbound policies where destinations are
unknown. Depending on your policy requirements, you can configure the following:
l Which CA certificate will be used to decrypt the SSL encrypted traffic
l Which SSL protocols will be inspected
l Which ports will be associated with which SSL protocols for inspection
l Whether or not to allow invalid SSL certificates
l Whether or not SSH traffic will be inspected
l Which addresses or web category allowlists can bypass SSL inspection
The following topics provide information about SSL & SSH Inspection:
l Certificate inspection on page 1251
l Deep inspection on page 1253
l Protecting an SSL server on page 1255
l Handling SSL offloaded traffic from an external decryption device on page 1256
l SSH traffic file scanning on page 1258
l Redirect to WAD after handshake completion on page 1260
Certificate inspection
FortiGate supports certificate inspection. The default configuration has a built-in certificate-inspection profile which you
can use directly. When you use certificate inspection, the FortiGate only inspects the headers up to the SSL/TLS layer.
If you do not want to deep scan for privacy reasons but you want to control web site access, you can use certificate-
inspection.
The following options are available when configuring an SSL inspection profile:
Blocked certificates The FortiGate receives Botnet C&C SSL connections from FortiGuard that
contain SHA1 fingerprints of malicious certificates. By default, these certificates
are blocked.
Click View Blocked Certificates to see a detailed list.
Untrusted SSL certificates Configure the action to take when a server certificate is not issued by a trusted
CA.
l Allow: Allow the untrusted server certificate. This is the default value.
Server certificate SNI check Check the SNI in the hellp message with the CN or SAN field in the returned
server certificate.
l Enable: If mismatched, use the CN in the server certificate to do URL
filtering.
l Strict: If mismatched, close the connection.
l Disable: Server certificate SNI check is disabled.
The built-in certificate-inspection profile is read-only and only listens on port 443. If you want to make changes, you must
create a new certificate inspection profile.
If you know the non-standard port that the web server uses, such as port 8443, you can add this port to the HTTPS field.
Common options
Invalid SSL certificates can be blocked, allowed, or a different actions can be configured for the different invalid
certificates types:
Expired certificates Action to take when the server certificate is expired. The default action is block.
Revoked certificates Action to take when the server certificate is revoked. The default action is block.
Validation timed-out Action to take when the server certificate validation times out. The default action is
certificates allow.
Validation failed certificates Action to take when the server certificate validation fails. The default action is
block.
By default, SSL anomalies logging is enabled. Logs are generated in the UTM log type under the SSL subtype when
invalid certificates are detected.
Deep inspection
You can configure address and web category allowlists to bypass SSL deep inspection.
While Hypertext Transfer Protocol Secure (HTTPS) offers protection on the Internet by applying Secure Sockets Layer
(SSL) encryption to web traffic, encrypted traffic can be used to get around your network's normal defenses.
For example, you might download a file containing a virus during an e-commerce session, or you might receive a
phishing email containing a seemingly harmless download that, when launched, creates an encrypted session to a
command and control (C&C) server and downloads malware onto your computer. Because the sessions in these attacks
are encrypted, they might get past your network's security measures.
When you use deep inspection, the FortiGate impersonates the recipient of the originating SSL session, then decrypts
and inspects the content to find threats and block them. It then re-encrypts the content and sends it to the real recipient.
Deep inspection not only protects you from attacks that use HTTPS, it also protects you from other commonly-used SSL-
encrypted protocols such as SMTPS, POP3S, IMAPS, and FTPS.
When FortiGate re-encrypts the content, it uses a certificate stored on the FortiGate such as Fortinet_CA_SSL, Fortinet_
CA_Untrusted, or your own CA certificate that you uploaded.
Because there is no Fortinet_CA_SSL in the browser trusted CA list, the browser displays an untrusted certificate
warning when it receives a FortiGate re-signed server certificate. To stop the warning messages, trust the FortiGate-
trusted CA Fortinet_CA_SSL and import it into your browser.
After importing Fortinet_CA_SSL into your browser, if you still get messages about untrusted certificate, it must be due to
Fortinet_CA_Untrusted. Never import the Fortinet_CA_Untrusted certificate into your browser.
1. On the FortiGate, go to Security Profiles > SSL/SSH Inspection and edit the deep-inspection profile.
The default CA Certificate is Fortinet_CA_SSL.
2. Click Download and save the certificate to the management computer.
3. On the client PC, use the Certificate Import Wizard to install the certificate into the Trusted Root Certificate
Authorities store.
If a security warning appears, select Yes to install the certificate.
If you do not want to apply deep inspection for privacy or other reasons, you can exempt the session by address,
category, or allowlist.
If you know the address of the server you want to exempt, you can exempt that address. You can exempt specific
address type including IP address, IP address range, IP subnet, FQDN, wildcard-FQDN, and geography.
If you want to exempt all bank web sites, an easy way is to exempt the Finance and Banking category which includes all
finance and bank web sites identified in FortiGuard. For information about creating and using custom local and remote
categories, see Web rating override on page 1266 and Threat feeds on page 355.
If you want to exempt commonly trusted web sites, you can bypass the SSL allowlist in the SSL/SSH profile by enabling
Reputable Websites. The allowlist includes common web sites trusted by FortiGuard.
You typically use the FortiGate Protecting SSL Server profile as an inbound policy for clients on the internet that access
the server through the internal side of the FortiGate.
Protecting SSL Server uses a server certificate to protect a single server.
You can use Protecting SSL Server if you do not want a client on the internet to directly access your internal server, and
you want the FortiGate to simulate your real server.
To upload a server certificate into FortiGate and use that certificate in the SSL/SSH inspection profile:
6. Click Apply.
When you apply the Protecting SSL Server profile in a policy, the FortiGate will send the server certificate to the client as
your server does.
In scenarios where the FortiGate is sandwiched between load-balancers and SSL processing is offloaded on the
external load-balancers, the FortiGate can perform scanning on the unencrypted traffic by specifying the ssl-
offloaded option in firewall profile-protocol-options. This option is supported in proxy and flow mode
(previous versions only supported proxy mode).
If the FortiGate receives an AUTH TLS, PBSZ, or PROT command before receiving plain text traffic from a decrypted
device, by default, it will expect encrypted traffic, determine that the traffic belongs to an abnormal protocol, and bypass
the traffic.
When the ssl-offloaded command is enabled, the AUTH TLS command is ignored, and the traffic is treated as plain
text rather than encrypted data. SSL decryption and encryption are performed by the external device.
Sample topology
In this example, the FortiGate is between two FortiADCs and in SSL offload sandwich mode. The FortiGate receives
plain text from ADC1 and forwards plain text to ADC2. There is no encrypted traffic passing through the FortiGate.
The client sends HTTPS traffic to ADC1, which then decrypts the traffic and sends HTTP to the FortiGate. The FortiGate
forwards HTTP to ADC2, and the ADC2 re-encrypts the traffic to HTTPS.
The ADC1 incoming port capture shows that ADC1 receives HTTPS traffic:
The ADC1 outgoing port capture shows that ADC1 decrypts traffic and forwards HTTP traffic to the FortiGate:
The FortiGate's incoming and outgoing port captures show that HTTP traffic passes through the FortiGate:
The ADC2 incoming port capture shows that the ADC2 receives HTTP traffic:
The ADC2 outgoing port capture shows that ADC2 forwards HTTPS traffic to the server:
FortiGates can buffer, scan, log, or block files sent over SSH traffic (SCP and SFTP) depending on the file size, type, or
contents (such as viruses or sensitive content).
This feature is supported in proxy-based inspection mode. It is currently not supported in flow-
based inspection mode.
You can configure the following SSH traffic settings in the CLI:
l Protocol options
l DLP sensor
l Antivirus (profile and quarantine options)
In a proxy-based policy, the TCP connection is proxied by the FortiGate. A TCP 3-way handshake can be established
with the client even though the server did not complete the handshake.
This option uses IPS to handle the initial TCP 3-way handshake. It rebuilds the sockets and redirects the session back to
proxy only when the handshake with the server is established.
Custom signatures
You can create the following custom signatures and apply them to firewall policies:
l IPS signature
l Application signature
l Application group
The following topic provides information about custom signatures:
l Application groups in policies on page 1261
l Blocking applications with custom signatures on page 1263
This feature provides an application group command for firewall shaping policies.
The following CLI command is used:
config firewall shaping-policy
edit 1
set app-group <application group>...
......
next
end
Example
c. Enter a name for the group, select the type, and then add the group the members.
d. Click OK.
2. Create the shaping policy for the high priority cloud application traffic:
a. Go to Policy & Objects > Traffic Shaping Policy.
b. Click Create New. The New Shaping Policy page opens.
c. Configure the shaping policy, selecting the previously created cloud application group, and setting both the
Shared shaper and Reverse shaper to high-priority.
d. Click OK.
At least one firewall policy must have application control enabled for the applications to
match any policy traffic.
3. Create the shaping policy for all other traffic, setting both the Shared shaper and Reverse shaper to low-priority.
next
end
2. Create the shaping policies for the high priority cloud application traffic and the other, low priority traffic:
config firewall shaping-policy
edit 1
set name "For Cloud Traffic"
set service "ALL"
set app-category 30
set app-group "cloud app group"
set dstintf "port1"
set traffic-shaper "high-priority"
set traffic-shaper-reverse "high-priority"
set srcaddr "all"
set dstaddr "all"
next
edit 2
set name "For Other Traffic"
set service "ALL"
set dstintf "port1"
set traffic-shaper "low-priority"
set traffic-shaper-reverse "low-priority"
set srcaddr "all"
set dstaddr "all"
next
end
Custom signatures can be used in application control profiles to block web traffic from specific applications, such as out
of support operating systems.
In this example, you create a custom signature to detect PCs running Windows NT 6.1 operating systems, including
Windows 7 and Windows Server 2008 R2. The signature is added to an application control profile and the action is set to
block. The profile is then used in a firewall policy so that web traffic matching the signature is blocked. The logs
generated by this example can be used to help identify other computers that you need to block.
1. Go to Security Profiles > Application Signatures and click Create New > Custom Application Signature.
2. Enter a name for the custom signature, such as block_nt_6.1.
3. Enter the Signature. In this example:
F-SBID( --attack_id 6483; --name "Windows.NT.6.1.Web.Surfing"; --default_action drop_
session; --service HTTP; --protocol tcp; --app_cat 25; --flow from_client; --pattern
!"FCT"; --pattern "Windows NT 6.1"; --no_case; --context header; --weight 40; )
This signature scans HTTP and HTTPS traffic that matches the pattern Windows NT 6.1 in its header. For blocking
older versions of Windows, such as Windows XP, you would use the pattern Windows NT 5.1. An attack ID is
automatically generated when the signature is created.
4. Click OK.
The signature is included in the Custom Application Signature section of the signature list.
6. Click OK.
The signature is added to the table.
7. Click OK.
3. In the Security Profiles section, enable Application Control and select the profile.
If deep inspection is not enabled, then only HTTP traffic will be scanned. To scan HTTPS traffic, set SSL Inspection
to a profile that includes deep inspection. See SSL & SSH Inspection on page 1251 for more information.
4. Click OK.
Results
When a PC that is running one of the affected operating systems tries to connect to the internet using a web browser, a
replacement message is shown. For information on customizing replacement messages, see Replacement messages
on page 903.
Go to Log & Report > Application Control to view the web traffic that is logged for the PC that is blocked by the application
signature.
Overrides
Web filter configuration can be separated into profile configuration and profile overrides.
You can also override web filter behavior based on the FortiGuard website categorization:
l Use alternate categories (web rating overrides): this method manually assigns a specific website to a different
Fortinet category or a locally-created category.
l Use alternate profiles: configured users or IP addresses can use an alternative web filter profile when attempting to
access blocked websites.
Web rating overrides allow you to add specific URLs to both FortiGuard and custom web ratings categories.
In a web filter profile, the action for each category can be configured. See FortiGuard filter on page 1142 for details. A
web rating override in a custom category will not impact any web filters until the category's action is changed to Allow,
Monitor (default), Block, Warning, or Authenticate in the specific web filter profile's settings. If a URL is in multiple
enabled categories, the order of precedence is local categories, then remote categories, and then FortiGuard
categories.
In SSL/SSH inspection profiles, custom categories must be explicitly selected to be exempt from SSL inspection. In
proxy addresses, custom categories must be explicitly selected as URL categories for them to apply. In both settings, if a
URL is in multiple selected categories, the order of precedence is local categories, then remote categories, and then
FortiGuard categories.
In this example, www.fortinet.com is added to both a custom, or local, category (Seriously) and an external threat feed,
or remote, category (OnAworkComputer). The local category action is set to Monitor, while the remote category action is
set to Block. When a user browses to www.fortinet.com, the local category action takes precedence over both the
remote category and the FortiGuard category (Information Technology), so the Monitor action is taken.
4. Click OK.
1. Go to Security Profiles > Web Rating Overrides and click Create New.
2. Enter the URL to override.
3. Optionally, click Lookup rating to see what its current rating is, if it has one.
4. Select the new Category and Sub-Category for the override.
5. Click OK.
1. Go to Security Profiles > Web Filter and create or edit a web filter profile. See FortiGuard filter on page 1142 for
more information.
2. Enable FortiGuard category based filter
3. Set the action for the Seriously category in the Local Categories group to Monitor.
4. Set the action for the OnAworkComputer category in the Remote Categories group to Block.
Setting the custom category action to Allow is equivalent to setting the CLI action
variable to monitor and log variable to disable.
To use local and remote categories in a web filter profile in the CLI:
2. Create a FortiGuard Category Threat Feed external connector to import an external blocklist.
config global
config system external-resource
edit "OnAworkComputer"
3. Enable the new category in a web filter profile. See FortiGuard filter on page 1142 for details.
Custom local categories have an ID range of 140 to 191. Remote categories have an ID range of 192 to 221.
config vdom
edit root
config webfilter profile
edit "WebFilter-1"
set feature-set proxy
config ftgd-wf
unset options
config filters
edit 12
set category 12
set action warning
next
...
edit 23
set action warning
next
edit 140
set category 140
next
edit 192
set category 192
set action block
next
end
end
next
end
next
end
When a filter is added for the local and remote categories (140 and 192 in this example), the default action is
monitor with logging enabled.
To use local and remote categories in an SSL/SSH inspection profile to exempt them from SSL
inspection in the GUI:
4. In the Exempt from SSL Inspection section, add the local and remote categories to the Web categories list .
To use local and remote categories in an SSL/SSH inspection profile to exempt them from SSL
inspection in the CLI:
config vdom
edit root
config firewall ssl-ssh-profile
edit "SSL_Inspection"
config https
set ports 443
set status deep-inspection
end
...
config ssl-exempt
edit 1
set fortiguard-category 140
next
edit 2
set fortiguard-category 192
next
end
next
end
next
end
Proxy addresses
1. Go to Policy & Objects > Addresses and click Create New > Address, or edit an existing proxy address.
2. Set Category to Proxy Address.
3. Set Type to URL Category.
config vdom
edit root
config firewall proxy-address
edit "proxy_override"
set type category
set host "all"
set category 140 192
set color 23
next
end
next
end
Administrative override
Administrators can grant temporary access to sites that are otherwise blocked by a web filter profile. You can grant
temporary access to a user, user group, or source IP address. You can set the time limit by selecting a date and time.
The default is 15 minutes.
When the administrative web profile override is enabled, a blocked access page or replacement message does not
appear, and authentication is not required.
Scope range
l User: authentication for permission to override is based on whether or not the user is using a specific user account.
l User group: authentication for permission to override is based on whether or not the user account supplied as a
credential is a member of the specified user group.
l Source IP: authentication for permission to override is based on the IP address of the computer that was used to
authenticate. This would be used for computers that have multiple users. For example, if a user logs on to the
computer, engages the override by using their credentials, and then logs off, anyone who logs on with an account
on that computer would be using the alternate override web filter profile.
When you enter an IP address in the administrative override method, only individual IP
addresses are allowed.
This example describes how to override the webfilter profile with the webfilter_new profile.
1. Go to Security Profiles > Web Profile Overrides and click Create New.
The New Administrative Override pane opens.
2. Configure the administrative override:
a. For Scope Range, click Source IP.
b. In the Source IP field, enter the IP address for the client computer (10.1.100.11 in this example).
c. In the Original profile dropdown, select webfilter.
d. In the New profile dropdown, select webfilter_new.
In the Expires field, the default 15 minutes appears, which is the desired duration for this example.
3. Click OK.
edit 1
set status enable
set scope ip
set old-profile "webfilter"
set new-profile "webfilter_new"
set expires 2020/08/12 12:00:00
set initiator "admin"
set ip 10.1.100.11
next
end
For both override methods, the scope ranges (for specified users, user groups, or IP addresses) allow sites blocked by
web filtering profiles to be overridden for a specified length of time.
But there is a difference between the override methods when the users or user group scope ranges are selected. In both
cases, you would need to apply the user or user group as source in the firewall policy. With administrative override, if you
do not apply the source in the firewall policy, the traffic will not match the override and will be blocked by the original
profile. With Allow users to override blocked categories, the traffic will also be blocked, but instead of displaying a
blocking page, the following message appears:
When you choose the user group scope, once one user overrides, it will affect the other users in the group when they
attempt to override. For example, user1 and user2 both belong to the local_user group. Once user1 successfully
overrides, this will generate an override entry for the local_user group instead of one specific user. This means that if
user2 logs in from another PC, they can override transparently.
Other features
Besides the scope, there are some other features in Allow users to override blocked categories.
Apply to group(s)
Individual users can not be selected. You can select one or more of the user groups recognized by the FortiGate. They
can be local to the system or from a third party authentication device, such as an AD server through FSSO.
Switch duration
Administrative override sets a specified time frame that is always used for that override. The available options in Allow
users to override blocked categories are:
l Predefined: the value entered is the set duration (length of time in days, hours, or minutes) that the override will be
in effect. If the duration variable is set to 15 minutes, the length of the override will always be 15 minutes. The option
will be visible in the override message page, but the setting will be grayed out.
l Ask: the user has the option to set the override duration once it is engaged. The user can set the duration in terms of
days, hours, or minutes.
This example describes how to allow users in the local_group to override the webfilter_new profile.
5. Click OK.
This option is only available in the Allow users to override blocked categories method. It configures the message page to
have the user choose which scope they want to use. Normally on the message page, the scope options are grayed out
and not editable. In the following example, the Scope is predefined with IP.
When the ask option is enabled (through the Switch applies to field in the GUI), the Scope dropdown is editable. Users
can choose one of the following:
l User
l User group
l IP
User and User Group are only available when there is a user group in the firewall policy. You
must specify a user group as a source in the firewall policy so the scope includes User and
User Group; otherwise, only the IP option will be available.
Virtual Private Network (VPN) technology lets remote users connect to private computer networks to gain access to their
resources in a secure way. For example, an employee traveling or working at home can use a VPN to securely access
the office network through the Internet.
Instead of remotely logging into a private network using an unencrypted and unsecured Internet connection, using a
VPN ensures that unauthorized parties cannot access the office network and cannot intercept information going
between the employee and the office. Another common use of a VPN is to connect the private networks of multiple
offices.
Fortinet offers VPN capabilities in the FortiGate Unified Threat Management (UTM) appliance and in the FortiClient
Endpoint Security suite of applications. You can install a FortiGate unit on a private network and install FortiClient
software on the user’s computer. You can also use a FortiGate unit to connect to the private network instead of using
FortiClient software.
The following sections provide information about VPN:
l IPsec VPNs on page 1276
l SSL VPN on page 1547
IPsec VPNs
The following sections provide instructions on configuring IPsec VPN connections in FortiOS 6.4.7.
l General IPsec VPN configuration on page 1276
l Site-to-site VPN on page 1301
l Remote access on page 1359
l Aggregate and redundant VPN on page 1404
l Overlay Controller VPN (OCVPN) on page 1444
l ADVPN on page 1475
l Other VPN topics on page 1509
l VPN IPsec troubleshooting on page 1540
Network topologies
The topology of your network will determine how remote peers and clients connect to the VPN and how VPN traffic is
routed.
Topology Description
Site-to-Site Standard one-to-one VPN between two FortiGates. See Site-to-site VPN on page
1301.
Hub and spoke/ADVPN One central FortiGate (hub) has multiple VPNs to other remote FortiGates
(spokes). In ADVPN, shortcuts can be created between spokes for direct
communication. See ADVPN on page 1475.
OCVPN Fortinet's cloud based solution for automating VPN setup between devices
registered to the same account. See Overlay Controller VPN (OCVPN) on page
1444.
FortiClient dialup Typically remote FortiClient dialup clients use dynamic IP addresses through NAT
devices. The FortiGate acts as a dialup server allowing dialup VPN connections
from multiple sources. See FortiClient as dialup client on page 1366.
FortiGate dialup Similar to site-to-site except one end is a dialup server and the other end is a
dialup client. This facilitates scenarios in which the remote dialup end has a
dynamic address, or does not have a public IP, possibly because it is behind NAT.
See FortiGate as dialup client on page 1360.
Aggregate VPN Natively support aggregating multiple VPN tunnels to increase performance and
provide redundancy over multiple links. See IPsec aggregate for redundancy and
traffic load-balancing on page 1421.
Redundant VPN Options for supporting redundant and partially redundant IPsec VPNs, using
route-based approaches. See Redundant hub and spoke VPN on page 1436.
L2TP over IPsec Configure VPN for Microsoft Windows dialup clients using the built in L2TP
software. Users do not have to install any Fortinet software. See L2TP over IPsec
on page 1386.
GRE over IPsec Legacy support for routers requiring point-to-point GRE over IPsec for tunneling.
See GRE over IPsec on page 1321.
Phase 1 configuration
Phase 1 configuration primarily defines the parameters used in IKE (Internet Key Exchange) negotiation between the
ends of the IPsec tunnel. The local end is the FortiGate interface that initiates the IKE negotiations. The remote end is
the remote gateway that responds and exchanges messages with the initiator. Hence, they are sometimes referred to as
the initiator and responder. The purpose of phase 1 is to secure a tunnel with one bi-directional IKE SA (security
association) for negotiating IKE phase 2 parameters.
The auto-negotiate and negotiation-timeout commands control how the IKE negotiation is processed when
there is no traffic, and the length of time that the FortiGate waits for negotiations to occur.
IPsec tunnels can be configured in the GUI using the VPN Creation Wizard. Go to VPN > IPsec Wizard. The wizard
includes several templates (site-to-site, hub and spoke, remote access), but a custom tunnel can be configured with the
following settings:
Network
IP Address The IP address of the remote peer. This option is only available when the
Remote Gateway is Static IP Address.
Dynamic DNS The domain name of the remote peer. This option is only available when the
Remote Gateway is Dynamic DNS.
Interface The interface through which remote peers or dialup clients connect to the
FortiGate. This option is only available in NAT mode.
By default, the local VPN gateway IP address is the IP address of the
interface that was selected (Primary IP in the Local Gateway field).
Local Gateway IP address for the local end of the VPN tunnel (Primary IP is used by default):
l Secondary IP: secondary address of the interface selected in the
Interface field.
l Specify: manually enter an address.
Mode Config This option is only available when the Remote Gateway is Dialup User.
Configure the client IP address range, subnet mask/prefix length,
DNS server, and split tunnel capability to automate remote client addressing.
NAT Traversal This option is only available when the Remote Gateway is Static IP Address
or Dynamic DNS.
ESP (encapsulating security payload), the protocol for encrypting data in the
VPN session, uses IP protocol 50 by default. However, it does not use any
port numbers so when traversing a NAT device, the packets cannot be
demultiplexed. Enabling NAT traversal encapsulates the ESP packet inside a
UDP packet, thereby adding a unique source port to the packet. This allows
the NAT device to map the packets to the correct session.
l Enable: a NAT device exists between the local FortiGate and the VPN
Dead Peer Reestablishes VPN tunnels on idle connections and cleans up dead IKE
Detection peers if required. This feature minimizes the traffic required to check if a VPN
peer is available or unavailable (dead). The available options are:
l Disable: disable dead peer detection (DPD).
triggers DPD when IPsec outbound packets are sent, but no reply is
received from the peer. When there is no traffic and the last DPD-ACK
has been received, IKE will not send DPDs periodically.
Notifications are received whenever a tunnel goes up or down, or to keep the
tunnel connection open when no traffic is being generated inside the tunnel.
For example, in scenarios where a dialup client or dynamic DNS peer
connects from an IP address that changes periodically, traffic may be
suspended while the IP address changes.
When Dead Peer Detection is selected, optionally specify a retry count and a
retry interval using dpd-retrycount and dpd-retryinterval. See
Dead peer detection on page 1283.
Forward Error Enable on both ends of the tunnel to correct errors in data transmission by
Correction sending redundant data across the VPN.
Device creation Advanced option. When enabled, a dynamic interface (network device) is
created for each dialup tunnel. See Dynamic tunnel interface creation on
page 1290.
Aggregate member Advanced option. When enabled, the tunnel can be used as an aggregate
member candidate.
Authentication
Pre-shared Key The pre-shared key that the FortiGate will use to authenticate itself to the
remote peer or dialup client during phase 1 negotiations. The same key must
be defined at the remote peer or client. See Pre-shared key.
Certificate Name The server certificate that the FortiGate will use to authenticate itself to the
remote peer or dialup client during phase 1 negotiations. See Digital
certificates.
Mode This option is only available when IKEv1 is selected. The two available
options are:
l Aggressive: the phase 1 parameters are exchanged in a single message
Peer Options Options to authenticate VPN peers or clients depending on the Remote
Gateway and Authentication Method settings.
Any peer ID Accepts the local ID of any remote VPN peer or client. The FortiGate does
not check identifiers (local IDs). Mode can be set to Aggressive or Main.
This option can be used with digital certificate authentication, but for higher
security, use Peer certificate.
Specific peer ID This option is only available when Aggressive Mode is enabled. Enter the
identifier that is used to authenticate the remote peer. The identifier must
match the local ID configured by the remote peer’s administrator.
If the remote peer is a FortiGate, the identifier is specified in the Local ID field
of the Phase 1 Proposal settings.
If the remote peer is a FortiClient user, the identifier is specified in the Local
ID field.
In circumstances where multiple remote dialup VPN tunnels exist, each
tunnel must have a peer ID set.
Peer certificate Define the CA certificate used to authenticate the remote peer when the
authentication mode is Signature.
If the FortiGate will act as a VPN client, and you are using security certificates
for authentication, set the Local ID to the distinguished name (DN) of the
local server certificate that the FortiGate unit will use for authentication
purposes.
Peer ID from dialup Authenticate multiple FortiGate or FortiClient dialup clients that use unique
group identifiers and unique pre-shared keys (or unique pre-shared keys only)
through the same VPN tunnel.
You must create a dialup user group for authentication purposes. Select the
group from the list next to the Peer ID from dialup group option.
You must set Mode to Aggressive when the dialup clients use unique
identifiers and unique pre-shared keys. If the dialup clients use unique pre-
shared keys only, you can set Mode to Main if there is only one dialup Phase
1 configuration for this interface IP address.
Phase 1 Proposal The encryption and authentication algorithms used to generate keys for the
IKE SA.
There must be a minimum of one combination. The remote peer or client
must be configured to use at least one of the proposals that you define.
56-bit key.
l 3DES: triple-DES; plain text is encrypted three times by three keys.
and a symmetric cipher. Only available for IKEv2. See also HMAC
settings.
Authentication The following message digests that check the message authenticity during
an encrypted session are available:
l MD5: message digest 5.
Key Lifetime The time (in seconds) that must pass before the IKE encryption key expires.
When the key expires, a new key is generated without interrupting service.
The keylife can be from 120 to 172 800 seconds.
Local ID Optional setting. This value must match the peer ID value given for the
remote VPN peer’s Peer Options.
l If the FortiGate will act as a VPN client and you are using peer IDs for
XAUTH This option supports the authentication of dialup clients. It is only available for
IKE version 1.
l Disable: do not use XAuth.
or Dynamic DNS. If the FortiGate is a dialup client, enter the user name
and password for the FortiGate to authenticate itself to the remote XAuth
server.
l PAP Server, CHAP Server, Auto Server: available only if Remote
Additional CLI configurations
VXLAN over IPsec Packets with a VXLAN header are encapsulated within IPsec tunnel mode.
IPsec tunnel idle timer Define an idle timer for IPsec tunnels. When no traffic has passed through the
tunnel for the configured idle-timeout value, the IPsec tunnel will be flushed.
Monitor tunnel for failover Monitor a site-to-site tunnel to guarantee operational continuity if the primary
tunnel fails. Configure the secondary phase 1 interface to monitor the primary
interface.
Passive mode Passive mode turns one side of the tunnel to be a responder only. It does not
initiate VPN tunnels either by auto-negotiation, rekey, or traffic initiated behind the
FortiGate.
By default, dead peer detection (DPD) sends probe messages every five seconds. If you are experiencing high network
traffic, you can experiment with increasing the ping interval. However, longer intervals will require more traffic to detect
dead peers, which will result in more traffic.
In a dynamic (dialup) connection, the On Idle option encourages dialup server configurations
to more proactively delete tunnels if the peer is unavailable.
In the GUI, the dead peer detection option can be configured in the GUI when defining phase 1 options. The following
CLI commands support additional options for specifying a retry count and a retry interval.
For example, enter the following to configure DPD on the existing IPsec phase 1 configuration to use 15-second intervals
and to wait for three missed attempts before declaring the peer dead and taking action.
To configure DPD:
DPD scalability
On a dialup server, if many VPN connections are idle, the increased DPD exchange could negatively impact the
performance/load of the daemon. The on-demand option in the CLI triggers DPD when IPsec traffic is sent, but no reply
is received from the peer.
When there is no traffic and the last DPD-ACK had been received, IKE will not send DPDs periodically. IKE will only send
out DPDs if there are outgoing packets to send, but no inbound packets have since been received.
HMAC settings
The FortiGate uses the HMAC based on the authentication proposal that is chosen in phase 1 or phase 2 of the IPsec
configuration. Each proposal consists of the encryption-hash pair (such as 3des-sha256). The FortiGate matches the
most secure proposal to negotiate with the peer.
vd: root/0
name: MPLS
version: 1
interface: port1 3
addr: 192.168.2.5:500 -> 10.10.10.1:500
virtual-interface-addr: 172.31.0.2 -> 172.31.0.1
created: 1015820s ago
IKE SA: created 1/13 established 1/13 time 10/1626/21010 ms
IPsec SA: created 1/24 established 1/24 time 0/11/30 ms
key: e0fa6ab8dc509b33-aa2cc549999b1823-c3cb9c337432646e
lifetime/rekey: 86400/17436
DPD sent/recv: 000001e1/00000000
If you create a route-based VPN, you have the option of selecting IKE version 2. Otherwise, IKE version 1 is used.
IKEv2, defined in RFC 4306, simplifies the negotiation process that creates the security association (SA).
If you select IKEv2:
l There is no choice in phase 1 of aggressive or main mode.
l Extended authentication (XAUTH) is not available.
l You can utilize EAP and MOBIKE.
This feature provides the option to control whether a device requires its peer to re-authenticate or whether re-key is
sufficient. It does not influence the re-authentication or re-key behavior of the device itself, which is controlled by the peer
(the default being to re-key). This solution is in response to RFC 4478. As described by the IETF, "the purpose of this is
to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer".
To configure IKE SA re-authentication:
config vpn ipsec phase1-interface
edit p1
set reauth [enable | disable]
next
end
There is support for IKEv2 quick crash detection (QCD) as described in RFC 6290.
RFC 6290 describes a method in which an IKE peer can quickly detect that the gateway peer it has and established an
IKE session with has rebooted, crashed, or otherwise lost IKE state. When the gateway receives IKE messages or ESP
packets with unknown IKE or IPsec SPIs, the IKEv2 protocol allows the gateway to send the peer an unprotected IKE
message containing INVALID_IKE_SPI or INVALID_SPI notification payloads.
RFC 6290 introduces the concept of a QCD token, which is generated from the IKE SPIs and a private QCD secret, and
exchanged between peers during the protected IKE AUTH exchange.
To configure QCD:
Based on the IKEv2 QCD feature previously described, IKEv1 QCD is implemented using a new IKE vendor ID (Fortinet
Quick Crash Detection) so both endpoints must be FortiGates. The QCD token is sent in the phase 1 exchange and must
be encrypted, so this is only implemented for IKEv1 in main mode (aggressive mode is not supported as there is no
available AUTH message to include the token). Otherwise, the feature works the same as in IKEv2 (RFC 6290).
IKEv1 fragmentation
UDP fragmentation can cause issues in IPsec when either the ISP or perimeter firewall(s) cannot pass or fragment the
oversized UDP packets that occur when using a very large public security key (PSK). The result is that IPsec tunnels do
not come up. The solution is IKE fragmentation.
For most configurations, enabling IKE fragmentation allows connections to automatically establish when they otherwise
might have failed due to intermediate nodes dropping IKE messages containing large certificates, which typically push
the packet size over 1500 bytes.
FortiOS will fragment a packet on sending if only all the following are true:
l Phase 1 contains set fragmentation enable.
l The packet is larger than the minimum MTU (576 for IPv4, 1280 for IPv6).
l The packet is being re-transmitted.
By default, IKE fragmentation is enabled.
IKEv2 fragmentation
RFC 7383 requires each fragment to be individually encrypted and authenticated. With IKEv2, a copy of the unencrypted
payloads around for each outgoing packet would need to be kept in case the original single packet was never answered
and would retry with fragments. With the following implementation, if the IKE payloads are greater than a configured
threshold, the IKE packets are preemptively fragmented and encrypted.
A FortiGate can authenticate itself to remote peers or dialup clients using either a pre-shared key or a digital certificate.
Pre-shared key
Using a pre-shared key is less secure than using certificates, especially if it is used alone, without requiring peer IDs or
extended authentication (XAuth). There also needs to be a secure way to distribute the pre-shared key to the peers.
If you use pre-shared key authentication alone, all remote peers and dialup clients must be configured with the same
pre-shared key. Optionally, you can configure remote peers and dialup clients with unique pre-shared keys. On the
FortiGate, these are configured in user accounts, not in the phase 1 settings.
The pre-shared key must contain at least six printable characters and should be known by network administrators. For
optimum protection against currently known attacks, the key must consist of a minimum of 16 randomly chosen
alphanumeric characters. The limit is 128 characters.
If you authenticate the FortiGate using a pre-shared key, you can require remote peers or dialup clients to authenticate
using peer IDs, but not client certificates.
1. Go to VPN > IPsec Tunnels and create a new tunnel, or edit an existing one.
2. Configure or edit the Network section as needed.
3. Configure or edit the Authentication settings as follows:
IKE Version 1 or 2
Peer Options Select an Accept Type and the corresponding peer. Options vary based on the
Remote Gateway and Authentication Method settings in the Network section.
Peer Options are only available in Aggressive mode.
4. For the Phase 1 Proposal section, keep the default settings unless changes are needed to meet your requirements.
5. Optionally, for authentication parameters for a dialup user group, define XAUTH parameters.
6. Click OK.
Digital certificates
To authenticate the FortiGate using digital certificates, you must have the required certificates installed on the remote
peer and on the FortiGate. The signed server certificate on one peer is validated by the presence of the root certificate
installed on the other peer. If you use certificates to authenticate the FortiGate, you can also require the remote peers or
dialup clients to authenticate using certificates. See Site-to-site VPN with digital certificate on page 1306 for a detailed
example.
1. Go to VPN > IPsec Tunnels and create a new tunnel, or edit an existing one.
2. Configure or edit the Network section as needed.
3. Configure or edit the Authentication settings as follows:
Method Signature
Certificate Name Select the certificate used to identify this FortiGate. If there are no imported
certificates, use Fortinet_Factory.
IKE Version 1 or 2
Peer Options For Accept Type, select Peer certificate and select the peer and the CA
certificate used to authenticate the peer. If the other end is using the Fortinet_
Factory certificate, then use the Fortinet_CA certificate here.
4. For the Phase 1 Proposal section, keep the default settings unless changes are needed to meet your requirements.
5. Optionally, for authentication parameters for a dialup user group, define XAUTH parameters.
6. Click OK.
Extended authentication (XAuth) increases security by requiring remote dialup client users to authenticate in a separate
exchange at the end of phase 1. XAuth draws on existing FortiGate user group definitions and uses established
authentication mechanisms such as PAP, CHAP, RADIUS, and LDAP to authenticate dialup clients. You can configure a
FortiGate to function either as an XAuth server or client. If the server or client is attempting a connection using XAuth and
the other end is not using XAuth, the failed connection attempts that are logged will not specify XAuth as the reason.
XAuth server
A FortiGate can act as an XAuth server for dialup clients. When the phase 1 negotiation completes, the FortiGate
challenges the user for a user name and password. It then forwards the user’s credentials to an external RADIUS or
LDAP server for verification.
If the user records on the RADIUS server have suitably configured Framed-IP-Address fields, you can assign client
virtual IP addresses by XAuth instead of from a DHCP address range.
The authentication protocol you use for XAuth depends on the capabilities of the authentication server and the XAuth
client:
l Select PAP Server whenever possible.
l You must select PAP Server for all implementations of LDAP and some implementations of Microsoft RADIUS.
l Select Auto Server when the authentication server supports CHAP Server but the XAuth client does not. The
FortiGate will use PAP to communicate with the XAuth client and CHAP to communicate with the authentication
server. You can also use Auto Server to allow multiple source interfaces to be defined in an IPsec/IKE policy.
Before you begin, create user accounts and user groups to identify the dialup clients that need to access the network
behind the FortiGate dialup server. If password protection will be provided through an external RADIUS or LDAP server,
you must configure the FortiGate dialup server to forward authentication requests to the authentication server.
1. On the FortiGate dialup server, go to VPN > IPsec Tunnels and create a new tunnel, or edit an existing one.
2. Configure or edit the Network, Authentication, and Phase 1 Proposal sections as needed.
3. In the XAUTH section, select the encryption method Type to use between the XAuth client, the FortiGate, and the
authentication server.
4. For User Group:
a. Click Inherit from policy for multiple user groups defined in the IPsec/IKE policy, or
b. Click Choose and in the dropdown, select the user group that needs to access the private network behind the
FortiGate.
5. Click OK.
6. Create as many policies as needed, specifying the source user(s) and destination address.
XAuth client
If the FortiGate acts as a dialup client, the remote peer, acting as an XAuth server, might require a username and
password. You can configure the FortiGate as an XAuth client with its own username and password, which it provides
when challenged.
1. On the FortiGate dialup client, go to VPN > IPsec Tunnels and create a new tunnel, or edit an existing one.
2. Configure or edit the Network, Authentication, and Phase 1 Proposal sections as needed.
3. In the XAUTH section, for Type, select Client.
4. For Username, enter the FortiGate PAP, CHAP, RADIUS, or LDAP user name that the FortiGate XAuth server will
compare to its records when the FortiGate XAuth client attempts to connect.
5. Enter the Password for the user name.
6. Click OK.
You can add a route to a peer destination selector by using the add-route option, which is available for all dynamic
IPsec phases 1 and 2, for both policy-based and route-based IPsec VPNs.
The add-route option adds a route to the FortiGate routing information base when the dynamic tunnel is negotiated.
You can use the distance and priority options to set the distance and priority of this route. If this results in a route with the
lowest distance, it is added to the FortiGate forwarding information base.
You can also enable add-route in any policy-based or route-based phase 2 configuration that is associated with a
dynamic (dialup) phase 1. In phase 2, add-route can be enabled, disabled, or set to use the same route as phase 1.
The add-route option is enabled by default.
next
end
For interface-based IPsec, IPsec SA negotiation blocking can only be removed if the peer offers a wildcard selector. If a
wildcard selector is offered, then the wildcard route will be added to the routing table with the distance/priority value
configured in phase 1. If that is the route with the lowest distance, it will be installed into the forwarding information base.
In this scenario, it is important to ensure that the distance value configured for phase 1 is set appropriately.
When configuring route-based IPsec dialup tunnels, the net-device setting controls how traffic is routed on the hub:
config vpn ipsec phase1-interface
edit "Spoke"
set type dynamic
set net-device {disable | enable}
set tunnel-search {selectors | nexthop}
next
end
The key settings are net-device and tunnel-search. When net-device is disabled, all dialup tunnels share an
interface on the hub. The tunnel selection process is based on the tunnel search method. Using a shared interface
eliminates the time needed for dynamic interface creation and tear-down. When net-device is enabled, dynamic
interfaces are created on the hub for each dialup tunnel. This means that potentially many dynamic interfaces could be
created at start-up in a large scale deployment.
4. The networks accessible over dialup tunnels are bound to the corresponding tunnel interface.
a. To view the routing table:
Hub # get router info routing-table bgp
Routing table for VRF=0
B 192.168.2.0/24 [200/0] via 10.10.10.2, Spoke_0, 01:04:49
B 192.168.3.0/24 [200/0] via 10.10.10.3, Spoke_1, 01:04:47
B 192.168.4.0/24 [200/0] via 10.10.10.4, Spoke_3, 00:35:01
B 192.168.5.0/24 [200/0] via 10.10.10.5, Spoke_2, 01:04:51
Phase 2 configuration
After phase 1 negotiations end successfully, phase 2 begins. In Phase 2, the VPN peer or client and the FortiGate
exchange keys again to establish a secure communication channel. The phase 2 proposal parameters select the
encryption and authentication algorithms needed to generate keys for protecting the implementation details of security
associations (SAs). The keys are generated automatically using a Diffie-Hellman algorithm.
The basic phase 2 settings associate IPsec phase 2 parameters with the phase 1 configuration that specifies the remote
end point of the VPN tunnel. In most cases, you need to configure only basic Phase 2 settings.
Some settings can be configured in the CLI. The following options are available in the VPN Creation Wizard after the
tunnel is created:
New Phase 2
Local Address A value of 0.0.0.0/0 means all IP addresses behind the local VPN peer.
Add a specific address or range to allow traffic from and to only this local
address.
See Quick mode selectors on page 1294.
Remote Address Enter the destination IP address that corresponds to the recipients or network
behind the remote VPN peer. A value of 0.0.0.0/0 means all IP addresses
behind the remote VPN peer.
See Quick mode selectors on page 1294.
Advanced Select the encryption and authentication algorithms that will be proposed to
the remote VPN peer. To establish a VPN connection, at least one of the
proposals specified must match the configuration on the remote peer.
56-bit key.
l 3DES: triple-DES; plain text is encrypted three times by three keys.
Authentication The following message digests that check the message authenticity during an
encrypted session are available:
l NULL: do not use a message digest.
Enable Replay Replay attacks occur when an unauthorized party intercepts a series of IPsec
Detection packets and replays them back into the tunnel.
Replay detection allows the FortiGate to check all IPsec packets to see if they
have been received before. If any encrypted packets arrive out of order, the
FortiGate discards them.
Note that 64-bit extended sequence numbers (as described in RFC 4303,
RFC 4304 as an addition to IKEv1, and RFC 5996 for IKEv2) are supported
for IPsec when replay detection is enabled.
Enable Perfect Perfect forward secrecy (PFS) improves security by forcing a new
Forward Secrecy Diffie-Hellman exchange whenever keylife expires.
(PFS)
Select one or more from groups 1, 2, 5, and 14 through 32. At least one of the
Diffie-Hellman Groups (DH) settings on the remote peer or client must match
one the selections on the FortiGate. Failure to match one or more DH groups
will result in failed negotiations.
Local Port Enter the port number that the local VPN peer uses to transport traffic related
to the specified service (protocol number). The range is from 0 to 65535. To
specify all ports, select All, or enter 0.
Remote Port Enter the port number that the remote VPN peer uses to transport traffic
related to the specified service (protocol number). To specify all ports, select
All, or enter 0.
Protocol Enter the IP protocol number of the service. To specify all services, select All,
or enter 0.
Auto-negotiate Select this option for the tunnel to be automatically renegotiated when the it
expires. See Auto-negotiate on page 1295.
Autokey Keep Select this option for the tunnel to remain active when no data is being
Alive processed.
Key Lifetime Select the method for determining when the phase 2 key expires:
l Seconds
l Kilobytes
l Both
Enter a corresponding value for Seconds and/or Kilobytes in the text boxes.
If Both is selected, the key expires when either the time has passed or the
number of kilobytes have been processed.
Quick mode selectors determine which IP addresses can perform IKE negotiations to establish a tunnel. By only allowing
authorized IP addresses access to the VPN tunnel, the network is more secure.
The default settings are as broad as possible: any IP address or configured address object using any protocol on any
port.
While the dropdown menus for specifying an address also show address groups, the use of
address groups may not be supported on a remote endpoint device that is not a FortiGate.
When configuring a quick mode selector for Local Address and Remote Address, valid options include IPv4 and IPv6
single addresses, subnets, or ranges.
There are some configurations that require specific selectors:
l The VPN peer is a third-party device that uses specific phase2 selectors.
l The FortiGate connects as a dialup client to another FortiGate, in which case (usually) you must specify a local IP
address, IP address range, or subnet. However, this is not required if you are using dynamic routing and mode-cfg.
With FortiOS VPNs, your network has multiple layers of security, with quick mode selectors being an important line of
defense:
FortiOS is limited with IKEv2 selector matching. When using IKEv2 with a named traffic
selector, no more than 32 subnets per traffic selector are added, since FortiOS does not fully
implement the IKEv2 selector matching rules.
The workaround is to use multiple phase 2s. If the configuration is FortiGate <--> FortiGate,
then the better alternative is to just use 0.0.0.0 <-> 0.0.0.0 and use the firewall policy
for enforcement.
If you are editing an existing phase 2 configuration, the local address and remote address fields are unavailable if the
tunnel has been configured to use firewall addresses as selectors. This option exists only in the CLI.
Consider using the add-route option to add a route to a peer destination selector in phase 2 to automatically match the
settings in phase 1.
To configure add-route:
Auto-negotiate
By default, the phase 2 security association (SA) is not negotiated until a peer attempts to send data. The triggering
packet and some subsequent packets are dropped until the SA is established. Applications normally resend this data, so
there is no loss, but there might be a noticeable delay in response to the user.
If the tunnel goes down, the auto-negotiate feature (when enabled) attempts to re-establish the tunnel. Auto-negotiate
initiates the phase 2 SA negotiation automatically, repeating every five seconds until the SA is established.
Automatically establishing the SA can be important for a dialup peer. It ensures that the VPN tunnel is available for peers
at the server end to initiate traffic to the dialup peer. Otherwise, the VPN tunnel does not exist until the dialup peer
initiates traffic.
To configure auto-negotiate:
The IPsec SA connect message generated is used to install dynamic selectors. These selectors can be installed via the
auto-negotiate mechanism. When phase 2 has auto-negotiate enabled, and phase 1 has mesh-selector-type
set to subnet, a new dynamic selector will be installed for each combination of source and destination subnets. Each
dynamic selector will inherit the auto-negotiate option from the template selector and begin SA negotiation. Phase 2
selector sources from dialup clients will all establish SAs without traffic being initiated from the client subnets to the hub.
DHCP
The dhcp-ipsec option lets the FortiGate assign VIP addresses to FortiClient dialup clients through a DHCP server or
relay. This option is only available if the remote gateway in the phase 1 configuration is set to dialup user, and it only
works in policy-based VPNs.
With dhcp-ipsec, the FortiGate dialup server acts as a proxy for FortiClient dialup clients that have VIP addresses on
the subnet of the private network behind the FortiGate. In this case, the FortiGate dialup server acts as a proxy on the
local private network for the FortiClient dialup client. A host on the network behind the dialup server issues an ARP
request, corresponding to the device MAC address of the FortiClient host (when a remote server sends an ARP to the
local FortiClient dialup client). The FortiGate then answers the ARP request on behalf of the FortiClient host, and then
forwards the associated traffic to the FortiClient host through the tunnel.
Acting as a proxy prevents the VIP address assigned to the FortiClient dialup client from causing possible ARP
broadcast problems—the normal and VIP addresses can confuse some network switches when two addresses have the
same MAC address.
In IKEv2 to support RFC 7634, the ChaCha20 and Poly1305 crypto algorithms can be used together as a combined
mode AEAD cipher (like AES-GCM) in the crypto_ftnt cipher in cipher_chacha20poly1305.c:
config vpn ipsec phase2-interface
edit <name>
set phase1name <name>
set proposal chacha20poly1305
next
end
In IKEv2 to support RFC 5282, the AEAD algorithm AES-GCM supports 128- and 256-bit variants:
config vpn ipsec phase2-interface
edit <name>
set phase1name <name>
set proposal [aes128gcm | aes256gcm]
next
end
This section explains how to specify the source and destination IP addresses of traffic transmitted through an IPsec
VPN, and how to define appropriate security policies.
Topology
In a gateway-to-gateway, hub-and-spoke, dynamic DNS, redundant tunnel, or transparent configuration, you need to
define a policy address for the private IP address of the network behind the remote VPN peer (for example,
192.168.10.0/255.255.255.0 or 192.168.10.0/24).
In a peer-to-peer configuration, you need to define a policy address for the private IP address of a server or host behind
the remote VPN peer (for example, 172.16.5.1/255.255.255.255, 172.16.5.1/32, or 172.16.5.1).
For a FortiGate dialup server in a dialup-client or internet-browsing configuration, the source IP should reflect the IP
addresses of the dialup clients:
l A policy-based VPN requires an IPsec policy. You specify the interface to the private network, the interface to the
remote peer and the VPN tunnel. A single policy can enable traffic inbound, outbound, or in both directions.
l A route-based VPN requires an accept policy for each direction. For the source and destination interfaces, you
specify the interface to the private network and the virtual IPsec interface (phase 1 configuration) of the VPN. The
IPsec interface is the destination interface for the outbound policy and the source interface for the inbound policy.
One security policy must be configured for each direction of each VPN interface.
If the policy that grants the VPN connection is limited to certain services, DHCP must be
included, otherwise the client will not be able to retrieve a lease from the FortiGate’s (IPsec)
DHCP server because the DHCP request (coming out of the tunnel) will be blocked.
Policy-based VPN
An IPsec policy enables the transmission and reception of encrypted packets, specifies the permitted direction of VPN
traffic, and selects the VPN tunnel. In most cases, a single policy is needed to control both inbound and outbound IP
traffic through a VPN tunnel. For a detailed example, see Policy-based IPsec tunnel on page 1326. Be aware of the
following before creating an IPsec policy.
Policies specify which IP addresses can initiate a tunnel. By default, traffic from the local private network initiates the
tunnel. When the Allow traffic to be initiated form the remote site option is selected, traffic from a dialup client, or a
computer on a remote network, initiates the tunnel. Both can be enabled at the same time for bi-directional initiation of
the tunnel.
When a FortiGate operates in NAT mode, you can enable inbound or outbound NAT. Outbound NAT may be performed
on outbound encrypted packets or IP packets in order to change their source address before they are sent through the
tunnel. Inbound NAT is performed to intercept and decrypt emerging IP packets from the tunnel.
By default, these options are not selected in security policies and can only be set through the CLI.
You must define at least one IPsec policy for each VPN tunnel. If the same remote server or client requires access to
more than one network behind a local FortiGate, the FortiGate must be configured with an IPsec policy for each network.
Multiple policies may be required to configure redundant connections to a remote destination or control access to
different services at different times.
To ensure a secure connection, the FortiGate must evaluate policies with Action set to IPsec before ACCEPT and
DENY. Because the FortiGate unit reads policies starting at the top of the list, you must move all IPsec policies to the top
of the list, and be sure to reorder your multiple IPsec policies that apply to the tunnel so that specific constraints can be
evaluated before general constraints. If you create two equivalent IPsec policies for two different tunnels, the system will
select the correct policy based on the specified source and destination addresses.
Adding multiple IPsec policies for the same VPN tunnel can cause conflicts if the policies
specify similar source and destination addresses, but have different settings for the same
service. When policies overlap in this manner, the system may apply the wrong IPsec policy or
the tunnel may fail.
Route-based VPN
When you define a route-based VPN, you create a virtual IPsec interface on the physical interface that connects to the
remote peer. You create ordinary accept policies to enable traffic between the IPsec interface and the interface that
connects to the private network. This makes configuration simpler than for policy-based VPNs.
Incoming Interface Select the interface that connects to the private network behind this FortiGate.
Source Select the address name you defined for the private network behind this
FortiGate.
Destination Select the address name you defined for the private network behind the
remote peer.
3. Click OK.
To permit the remote client to initiate communication, you need to define a security policy for communication in that
direction.
4. Click Create New and enter these settings in particular:
Outgoing Interface Select the interface that connects to the private network behind this FortiGate.
Source Select the address name you defined for the private network behind the
remote peer.
Destination Select the address name you defined for the private network behind this
FortiGate.
5. Click OK.
Blocking unwanted IKE negotiations and ESP packets with a local-in policy
It is not unusual to receive IPsec connection attempts or malicious IKE packets from all over the internet. Malicious
parties use these probes to try to establish an IPsec tunnel in order to gain access to your private network. A good way to
prevent this is to use local-in policies to deny such traffic.
Sometimes there are malicious attempts using crafted invalid ESP packets. These invalid attempts are automatically
blocked by the FOS IPsec local-in handler when it checks the SPI value against the SAs of existing tunnels. The IPsec
local-in handler processes the packet instead of the firewall's local-in handler. So when these attempts are blocked, you
will notice an unknown SPI message in your VPN logs instead of being silently blocked by your local-in policy. These
log messages are rate limited.
Note that invalid SPIs may not always indicate malicious activity. For example, the SPI may not match during rekey, or
when one unit flushes its tunnel SAs. Administrators should collect as much information as possible before making a
conclusion.
To block undesirable IPsec connection attempts and IKE packets using a local-in policy:
2. Create a local-in policy that blocks IKE traffic from the address group:
config firewall local-in-policy
edit 1
set intf "wan1"
set srcaddr "All_exceptions"
set dstaddr "all"
set service "IKE"
set schedule "always"
next
end
Site-to-site VPN
A site-to-site VPN connection lets branch offices use the Internet to access the main office's intranet. A site-to-site VPN
allows offices in multiple, fixed locations to establish secure connections with each other over a public network such as
the Internet.
The following sections provide instructions for configuring site-to-site VPNs:
l FortiGate-to-FortiGate on page 1301
l FortiGate-to-third-party on page 1332
FortiGate-to-FortiGate
This section contains the following topics about FortiGate-to-FortiGate VPN configurations:
l Basic site-to-site VPN with pre-shared key on page 1301
l Site-to-site VPN with digital certificate on page 1306
l Site-to-site VPN with overlapping subnets on page 1313
l GRE over IPsec on page 1321
l Policy-based IPsec tunnel on page 1326
This is a sample configuration of IPsec VPN authenticating a remote FortiGate peer with a pre-shared key.
To configure IPsec VPN authenticating a remote FortiGate peer with a pre-shared key in the GUI:
To configure IPsec VPN authenticating a remote FortiGate peer with a pre-shared key using the CLI:
1. Configure the WAN interface and default route. The WAN interface is the interface connected to the ISP. The IPsec
tunnel is established over the WAN interface.
a. Configure HQ1.
config system interface
edit "port1"
set vdom "root"
set ip 172.16.200.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.200.3
set device "port1"
next
end
b. Configure HQ2.
config system interface
edit "port25"
set vdom "root"
set ip 172.16.202.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.202.2
set device "port25"
next
end
2. Configure the internal (protected subnet) interface. The internal interface connects to the corporate internal
network. Traffic from this interface routes out the IPsec VPN tunnel.
a. Configure HQ1.
config system interface
edit "dmz"
set vdom "root"
set ip 10.1.100.1 255.255.255.0
next
end
b. Configure HQ2.
config system interface
edit "port9"
set vdom "root"
set ip 172.16.101.1 255.255.255.0
next
end
b. Configure HQ2.
config vpn ipsec phase1-interface
edit "to_HQ1"
set interface "port25"
set peertype any
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.16.200.1
set psksecret sample
next
end
b. Configure HQ2.
config vpn ipsec phase2-interface
edit "to_HQ2"
set phase1name "to_HQ1"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
next
end
5. Configure the static routes. Two static routes are added to reach the remote protected subnet. The blackhole route
is important to ensure that IPsec traffic does not match the default route when the IPsec tunnel is down.
a. Configure HQ1.
config router static
edit 2
set dst 172.16.101.0 255.255.255.0
set device "to_HQ2"
next
edit 3
set dst 172.16.101.0 255.255.255.0
set blackhole enable
set distance 254
next
end
b. Configure HQ2.
config router static
edit 2
set dst 10.1.100.0 255.255.255.0
set device "to_HQ1"
next
edit 3
set dst 10.1.100.0 255.255.255.0
set blackhole enable
set distance 254
next
end
6. Configure two firewall policies to allow bidirectional IPsec traffic flow over the IPsec VPN tunnel.
a. Configure HQ1.
config firewall policy
edit 1
set name "inbound"
set srcintf "to_HQ2"
set dstintf "dmz"
set srcaddr "172.16.101.0"
set dstaddr "10.1.100.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "outbound"
set srcintf "dmz"
set dstintf "to_HQ2"
set srcaddr "10.1.100.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
end
b. Configure HQ2.
config firewall policy
edit 1
set name "inbound"
set srcintf "to_HQ1"
set dstintf "port9"
set srcaddr "10.1.100.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "outbound"
set srcintf "port9"
set dstintf "to_HQ1"
set srcaddr "172.16.101.0"
7. Run diagnose commands. The diagnose debug application ike -1 command is the key to troubleshoot
why the IPsec tunnel failed to establish. If the PSK failed to match, the following error shows up in the debug output:
ike 0:to_HQ2:15037: parse error
ike 0:to_HQ2:15037: probable pre-shared secret mismatch'
The following commands are useful to check IPsec phase1/phase2 interface status.
a. Run the diagnose vpn ike gateway list command on HQ1. The system should return the following:
vd: root/0
name: to_HQ2
version: 1
interface: port1 11
addr: 172.16.200.1:500 -> 172.16.202.1:500
created: 5s ago
IKE SA: created 1/1 established 1/1 time 0/0/0 ms
IPsec SA: created 2/2 established 2/2 time 0/0/0 ms
id/spi: 12 6e8d0532e7fe8d84/3694ac323138a024
direction: responder
status: established 5-5s ago = 0ms
proposal: aes128-sha256
key: b3efb46d0d385aff-7bb9ee241362ee8d
lifetime/rekey: 86400/86124
DPD sent/recv: 00000000/00000000
b. Run the diagnose vpn tunnel list command on HQ1. The system should return the following:
list all ipsec tunnel in vd 0
name=to_HQ2 ver=1 serial=1 172.16.200.1:0->172.16.202.1:0
bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_
dev frag-rfcaccept_traffic=1
proxyid_num=1 child_num=0 refcnt=11 ilast=7 olast=87 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=to_HQ2 proto=0 sa=1 ref=2 serial=1 auto-negotiate
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=3 options=18227 type=00 soft=0 mtu=1438 expire=42927/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000000 itn=0
life: type=01 bytes=0/0 timeout=42930/43200
dec: spi=ef9ca700 esp=aes key=16 a2c6584bf654d4f956497b3436f1cfc7
ah=sha1 key=20 82c5e734bce81e6f18418328e2a11aeb7baa021b
enc: spi=791e898e esp=aes key=16 0dbb4588ba2665c6962491e85a4a8d5a
ah=sha1 key=20 2054b318d2568a8b12119120f20ecac97ab730b3
dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
This is a sample configuration of IPsec VPN authenticating a remote FortiGate peer with a certificate. The certificate on
one peer is validated by the presence of the CA certificate installed on the other peer.
To configure IPsec VPN authenticating a remote FortiGate peer with a digital certificate in the GUI:
vi. From the Peer Certificate CA dropdown list, select the peer CA certificate.
vii. Click Next.
c. Configure the following settings for Policy & Routing:
i. From the Local Interface dropdown menu, select the local interface.
ii. Configure Local Subnets as 172.16.101.0.
iii. Configure the Remote Subnets as 10.1.100.0.
iv. Click Create.
To configure IPsec VPN authenticating a remote FortiGate peer with a digital certificate using the CLI:
1. Configure the WAN interface and default route. The WAN interface is the interface connected to the ISP. The IPsec
tunnel is established over the WAN interface.
a. Configure HQ1.
config system interface
edit "port1"
set vdom "root"
set ip 172.16.200.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.200.3
set device "port1"
next
end
b. Configure HQ2.
config system interface
edit "port25"
set vdom "root"
set ip 172.16.202.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.202.2
set device "port25"
next
end
2. Configure the internal (protected subnet) interface. The internal interface connects to the corporate internal
network. Traffic from this interface routes out the IPsec VPN tunnel.
a. Configure HQ1.
config system interface
edit "dmz"
set vdom "root"
set ip 10.1.100.1 255.255.255.0
next
end
b. Configure HQ2.
config system interface
edit "port9"
set vdom "root"
set ip 172.16.101.1 255.255.255.0
next
end
3. Configure the import certificate and its CA certificate information. The certificate and its CA certificate must be
imported on the remote peer FortiGate and on the primary FortiGate before configuring IPsec VPN tunnels. If the
built-in Fortinet_Factory certificate and the Fortinet_CA CA certificate are used for authentication, you can skip this
step.
a. Configure HQ1.
config vpn certificate local
edit "test1"
...
set range global
next
end
config vpn certificate ca
edit "CA_Cert_1"
...
set range global
next
end
b. Configure HQ2.
config vpn certificate local
edit "test2"
...
set range global
next
end
config vpn certificate ca
edit "CA_Cert_1"
...
set range global
next
end
4. Configure the peer user. The peer user is used in the IPsec VPN tunnel peer setting to authenticate the remote peer
FortiGate.
a. If not using the built-in Fortinet_Factory certificate and Fortinet_CA CA certificate, do the following:
i. Configure HQ1.
config user peer
edit "peer1"
set ca "CA_Cert_1"
next
end
next
end
b. If the built-in Fortinet_Factory certificate and Fortinet_CA CA certificate are used for authentication, the peer
user must be configured based on Fortinet_CA.
i. Configure HQ1.
config user peer
edit "peer1"
set ca "Fortinet_CA"
next
end
b. Configure HQ2.
config vpn ipsec phase1-interface
edit "to_HQ1"
set interface "port25"
set authmethod signature
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.16.200.1
set certificate "test2"
set peer "peer2"
next
end
next
end
b. Configure HQ2.
config vpn ipsec phase2-interface
edit "to_HQ2"
set phase1name "to_HQ1"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
next
end
7. Configure the static routes. Two static routes are added to reach the remote protected subnet. The blackhole route
is important to ensure that IPsec traffic does not match the default route when the IPsec tunnel is down.
a. Configure HQ1.
config router static
edit 2
set dst 172.16.101.0 255.255.255.0
set device "to_HQ2"
next
edit 3
set dst 172.16.101.0 255.255.255.0
set blackhole enable
set distance 254
next
end
b. Configure HQ2.
config router static
edit 2
set dst 10.1.100.0 255.255.255.0
set device "to_HQ1"
next
edit 3
set dst 10.1.100.0 255.255.255.0
set blackhole enable
set distance 254
next
end
8. Configure two firewall policies to allow bidirectional IPsec traffic flow over the IPsec VPN tunnel.
a. Configure HQ1.
config firewall policy
edit 1
set name "inbound"
set srcintf "to_HQ2"
set dstintf "dmz"
set srcaddr "172.16.101.0"
set dstaddr "10.1.100.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "outbound"
set srcintf "dmz"
set dstintf "to_HQ2"
set srcaddr "10.1.100.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
end
b. Configure HQ2.
config firewall policy
edit 1
set name "inbound"
set srcintf "to_HQ1"
set dstintf "port9"
set srcaddr "10.1.100.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "outbound"
set srcintf "port9"
set dstintf "to_HQ1"
set srcaddr "172.16.101.0"
set dstaddr "10.1.100.0"
set action accept
set schedule "always"
set service "ALL"
next
end
9. Run diagnose commands. The diagnose debug application ike -1 command is the key to troubleshoot
why the IPsec tunnel failed to establish. If the remote FortiGate certificate cannot be validated, the following error
shows up in the debug output:
ike 0: to_HQ2:15314: certificate validation failed
The following commands are useful to check IPsec phase1/phase2 interface status.
a. Run the diagnose vpn ike gateway list command on HQ1. The system should return the following:
vd: root/0
name: to_HQ2
version: 1
interface: port1 11
addr: 172.16.200.1:500 -> 172.16.202.1:500
created: 7s ago
peer-id: C = CA, ST = BC, L = Burnaby, O = Fortinet, OU = QA, CN = test2
peer-id-auth: yes
IKE SA: created 1/1 established 1/1 time 70/70/70 ms
IPsec SA: created 1/1 established 1/1 time 80/80/80 ms
id/spi: 15326 295be407fbddfc13/7a5a52afa56adf14 direction: initiator status:
b. Run the diagnose vpn tunnel list command on HQ1. The system should return the following:
list all ipsec tunnel in vd 0
name=to_HQ2 ver=1 serial=1 172.16.200.1:0->172.16.202.1:0
bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_
dev frag-rfcaccept_traffic=1
proxyid_num=1 child_num=0 refcnt=14 ilast=19 olast=179 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=vpn-f proto=0 sa=1 ref=2 serial=1 auto-negotiate
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=3 options=18227 type=00 soft=0 mtu=1438 expire=42717/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000000 itn=0
life: type=01 bytes=0/0 timeout=42897/43200
dec: spi=72e87de7 esp=aes key=16 8b2b93e0c149d6f22b1c0b96ea450e6c
ah=sha1 key=20 facc655e5f33beb7c2b12e718a6d55413ce3efa2
enc: spi=5c52c865 esp=aes key=16 8d0c4e4adbf2338beed569b2b3205ece
ah=sha1 key=20 553331628612480ab6d7d563a00e2a967ebabcdd
dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
This is a sample configuration of IPsec VPN to allow transparent communication between two overlapping networks that
are located behind different FortiGates using a route-based tunnel with source and destination NAT.
In the following topology, both FortiGates (HQ and Branch) use 192.168.1.0/24 as their internal network, but both
networks need to be able to communicate to each other through the IPsec tunnel.
New virtual subnets of equal size must be configured and used for all communication between the two overlapping
subnets. The devices on both local networks do not need to change their IP addresses. However, the devices and users
must use the new subnet range of the remote network to communicate across the tunnel.
4. For Pre-shared Key, enter a secure key. You will use the same key when configuring IPsec VPN on the Branch
FortiGate.
5. In the Phase 2 Selectors section, enter the subnets for the Local Address (10.1.1.0/24) and Remote Address
(10.2.2.0/24).
7. Click OK.
4. Click OK.
5. Create another route with the same Destination, but change the Administrative Distance to 200 and for Interface,
select Blackhole. This is a best practice for route-based IPsec VPN tunnels because it ensures traffic for the remote
FortiGate's subnet is not sent using the default route in the event that the IPsec tunnel goes down.
1. Go to Policy & Objects > Addresses and click Create New > Address.
2. For Name, enter HQ-original.
3. For IP/Netmask, enter the original LAN subnet of HQ (192.168.1.0/24).
4. For Interface, select the LAN-side interface (internal).
5. Click OK
6. Create another address object named Branch-new, but for IP/Netmask, enter the new LAN subnet of Branch
(10.2.2.0/24), and select the VPN interface (VPN-to-Branch).
5. Click OK.
1. Go to Policy & Objects > Virtual IPs and click Create New > Virtual IP.
2. For Name, enter HQ-new-to-original.
3. For Interface, select the VPN interface (VPN-to-Branch).
4. Enter the External IP address/range (10.1.1.1 – 10.1.1.254, the new HQ subnet) and Mapped IP address/range
(192.168.1.1 – 192.168.1.254, the original HQ subnet).
5. Click OK.
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. For Name, enter From-HQ-to-Branch.
3. For Incoming Interface, select the LAN-side interface (internal).
4. For Outgoing Interface, select the VPN tunnel interface (VPN-to-Branch).
5. For Source, select HQ-original.
6. For Destination, select Branch-new.
7. For Service, select ALL.
8. Enable NAT.
9. Select Use Dynamic IP Pool and select the HQ-new IP pool.
7. Disable NAT.
8. Click OK.
4. For Pre-shared Key, enter the matching secure key used in the VPN-to-Branch tunnel.
5. In the Phase 2 Selectors section, enter the subnets for the Local Address (10.2.2.0/24) and Remote Address
(10.1.1.0/24).
7. Click OK.
4. Click OK.
5. Create another route with the same Destination, but change the Administrative Distance to 200 and for Interface,
select Blackhole.
1. Go to Policy & Objects > Addresses and click Create New > Address.
2. For Name, enter Branch-original.
3. For IP/Netmask, enter the original LAN subnet of Branch (192.168.1.0/24).
4. For Interface, select the LAN-side interface (lan).
5. Click OK
6. Create another address object named HQ-new, but for IP/Netmask, enter the new LAN subnet of HQ (10.1.1.0/24),
and select the VPN interface (VPN-to-HQ).
5. Click OK.
1. Go to Policy & Objects > Virtual IPs and click Create New > Virtual IP.
2. For Name, enter Branch-new-to-original.
3. For Interface, select the VPN interface (VPN-to-HQ).
4. Enter the External IP address/range (10.2.2.1 – 10.2.2.254, the new Branch subnet) and Mapped IP address/range
(192.168.1.1 – 192.168.1.254, the original Branch subnet).
5. Click OK.
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. For Name, enter From-Branch-to-HQ.
3. For Incoming Interface, select the LAN-side interface (lan).
4. For Outgoing Interface, select the VPN tunnel interface (VPN-to-HQ).
5. For Source, select Branch-original.
6. For Destination, select HQ-new.
7. For Service, select ALL.
8. Enable NAT.
9. Select Use Dynamic IP Pool and select the Branch-new IP pool.
8. Click OK.
1. Go to Dashboard > Network and click the IPsec widget to expand to full screen view. The tunnels should be up on
both FortiGates. If you did not enable Auto-negotiate in the IPsec VPN settings, you may have to select the tunnel
and click Bring Up.
2. From a PC on the HQ network, ping a PC on the Branch network using the new IP for the Branch PC. The ping
should be successful.
3. From a PC on the Branch network, ping a PC on the HQ network using the new IP for the HQ PC. The ping should
be successful.
This is an example of GRE over an IPsec tunnel using a static route over GRE tunnel and tunnel-mode in the
phase2-interface settings.
b. HQ2.
config system interface
edit "port25"
set ip 172.16.202.1 255.255.255.0
next
edit "port9"
set ip 172.16.101.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.202.2
set device "port25"
next
end
b. HQ2.
config vpn ipsec phase1-interface
edit "greipsec"
set interface "port25"
set peertype any
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.16.200.1
set psksecret sample
next
end
config vpn ipsec phase2-interface
edit "greipsec"
set phase1name "greipsec"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set protocol 47
next
end
b. HQ2.
config system interface
edit "greipsec"
set ip 10.10.10.2 255.255.255.255
set remote-ip 10.10.10.1 255.255.255.255
next
end
b. HQ2.
config system gre-tunnel
edit "gre_to_HQ1"
set interface "greipsec"
set remote-gw 10.10.10.1
set local-gw 10.10.10.2
next
end
b. HQ2.
config firewall policy
edit 1
set srcintf "port9"
set dstintf "gre_to_HQ1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set srcintf "gre_to_HQ1"
set dstintf "port9"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
edit 3
set srcintf "greipsec"
set dstintf "greipsec"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
end
b. HQ2.
config router static
edit 2
set dst 10.1.100.0 255.255.255.0
set device "gre_to_HQ1"
next
end
This is an example of policy-based IPsec tunnel using site-to-site VPN between branch and HQ. HQ is the IPsec
concentrator.
Sample topology
Sample configuration
b. For branch 2.
config system interface
edit "wan1"
set alias "primary_WAN"
set ip 13.1.1.2 255.255.255.0
next
edit "internal"
set ip 192.168.4.1 255.255.255.0
next
end
config router static
edit 1
set gateway 13.1.1.1
set device "wan1"
next
end
b. For branch 2.
config vpn ipsec phase1
edit "to_HQ"
set interface "wan1"
set peertype any
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 22.1.1.1
set psksecret sample
next
end
config vpn ipsec phase2
edit "to_HQ"
set phase1name "to_HQ"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
next
end
b. For branch 2.
config firewall policy
edit 1
set srcintf "internal"
set dstintf "wan1"
set srcaddr "192.168.4.0"
set dstaddr "all"
set action ipsec
set schedule "always"
set service "ALL"
set inbound enable
set vpntunnel "to_HQ"
next
end
FortiGate-to-third-party
This section contains the following topics about FortiGate-to-third-party VPN configurations:
l IKEv2 IPsec site-to-site VPN to an AWS VPN gateway on page 1333
l IPsec VPN to Azure with virtual network gateway on page 1339
l IPsec VPN to an Azure with virtual WAN on page 1349
l IPSec VPN between a FortiGate and a Cisco ASA with multiple subnets on page 1353
l Cisco GRE-over-IPsec VPN on page 1354
This is a sample configuration of an IPsec site-to-site VPN connection between an on-premise FortiGate and an AWS
virtual private cloud (VPC).
AWS uses unique identifiers to manipulate a VPN connection's configuration. Each VPN connection is assigned an
identifier and is associated with two other identifiers: the customer gateway ID for the FortiGate and virtual private
gateway ID.
This example includes the following IDs:
l VPN connection ID: vpn-07e988ccc1d46f749
l Customer gateway ID: cgw-0440c1aebed2f418a
l Virtual private gateway ID
This example assumes that you have configured VPC-related settings in the AWS management portal as described in
Create a Secure Connection using AWS VPC.
This example includes creating and configuring two tunnels. You must configure both tunnels on your FortiGate.
A policy is established for the supported ISAKMP encryption, authentication, Diffie-Hellman (DH), lifetime, and key
parameters. These sample configurations fulfill the minimum requirements for AES128, SHA1, and DH Group 2.
Category VPN connections in the GovCloud AWS region have a minimum requirement of AES128, SHA2, and
DH Group 14. To take advantage of AES256, SHA256, or other DH groups such as 14-18, 22, 23, and 24, you must
modify these sample configuration files. Higher parameters are only available for VPNs of category "VPN", not for "VPN-
Classic".
Your FortiGate's external interface's address must be static. Your FortiGate may reside behind a device performing NAT.
To ensure NAT traversal can function, you must adjust your firewall rules to unblock UDP port 4500. If not behind NAT, it
is recommended to disable NAT traversal.
Begin configuration in the root VDOM. The interface name must be shorter than 15 characters. It is best if the name is
shorter than 12 characters. IPsec dead peer detection (DPD) causes periodic messages to be sent to ensure a security
association remains operational.
config vpn ipsec phase1-interface
edit vpn-07e988ccc1d46f749-0
The IPsec transform set defines the encryption, authentication, and IPsec mode parameters.
config vpn ipsec phase2-interface
edit "vpn-07e988ccc1d46f749-0"
set phase1name "vpn-07e988ccc1d46f749-0"
set proposal aes128-sha1
set dhgrp 2
set pfs enable
set keylifeseconds 3600
next
end
You must configure a tunnel interface as the logical interface associated with the tunnel. All traffic routed to the tunnel
interface must be encrypted and transmitted to the VPC. Similarly, traffic from the VPC will be logically received on this
interface.
You must configure the interface's address with your FortiGate's address. If the address changes, you must recreate the
FortiGate and VPN connection with Amazon VPC.
The tcp-mss option causes the router to reduce the TCP packets' maximum segment size to prevent packet
fragmentation.
config system interface
edit "vpn-07e988ccc1d46f749-0"
set vdom "root"
set ip 169.254.45.90 255.255.255.255
set allowaccess ping
set type tunnel
set tcp-mss 1379
set remote-ip 169.254.45.89
set mtu 1427
set interface "wan1"
next
end
BGP is used within the tunnel to exchange prefixes between the virtual private gateway and your FortiGate. The virtual
private gateway announces the prefix according to your VPC.
The local BGP autonomous system number (ASN) (65000) is configured as part of your FortiGate. If you must change
the ASN, you must recreate the FortiGate and VPN connection with AWS.
Your FortiGate may announce a default route (0.0.0.0/0) to AWS. This is done using a prefix list and route map in
FortiOS.
config router bgp
set as 65000
config neighbor
edit 169.254.45.89
set remote-as 64512
end
end
end
config router bgp
config neighbor
edit 169.254.45.89
set capability-default-originate enable
end
end
end
config router prefix-list
edit "default_route"
config rule
edit 1
set prefix 0.0.0.0 0.0.0.0
next
end
end
end
config router route-map
edit "routemap1"
config rule
edit 1
set match-ip-address "default_route"
next
end
next
end
To advertise additional prefixes to the Amazon VPC, add these prefixes to the network statement and identify the prefix
you want to advertise. Ensure that the prefix is present in the routing table of the device with a valid next-hop. If you want
to advertise 192.168.0.0/16 to Amazon, you would do the following:
config router bgp
config network
edit 1
set prefix 192.168.0.0 255.255.0.0
next
end
Create a firewall policy permitting traffic from your local subnet to the VPC subnet, and vice-versa.
This example policy permits all traffic from the local subnet to the VPC. First, view all existing policies using the show
firewall policy command. Then, create a new firewall policy starting with the next available policy ID. In this
example, running show firewall policy displayed policies 1, 2, 3, and 4, so you would proceed to create policy 5.
config firewall policy
edit 5
set srcintf "vpn-07e988ccc1d46f749-0"
set dstintf internal
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
end
config firewall policy
edit 5
set srcintf internal
set dstintf "vpn-07e988ccc1d46f749-0"
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
end
A policy is established for the supported ISAKMP encryption, authentication, DH, lifetime, and key parameters. These
sample configurations fulfill the minimum requirements for AES128, SHA1, and DH Group 2. Category VPN connections
in the GovCloud AWS region have a minimum requirement of AES128, SHA2, and DH Group 14. To take advantage of
AES256, SHA256, or other DH groups such as 14-18, 22, 23, and 24, you must modify these sample configuration files.
Higher parameters are only available for VPNs of category "VPN", not for "VPN-Classic".
Your FortiGate's external interface's address must be static. Your FortiGate may reside behind a device performing NAT.
To ensure NAT traversal can function, you must adjust your firewall rules to unblock UDP port 4500. If not behind NAT, it
is recommended to disable NAT traversal.
Begin configuration in the root VDOM. The interface name must be shorter than 15 characters. It is best if the name is
shorter than 12 characters. IPsec DPD causes periodic messages to be sent to ensure a security association remains
operational.
config vpn ipsec phase1-interface
edit vpn-07e988ccc1d46f749-1
set interface "wan1"
set dpd enable
set local-gw 35.170.66.108
set dhgrp 2
set proposal aes128-sha1
set keylife 28800
set remote-gw 100.25.187.58
set psksecret IjFzyDneUtDdAT4RNmQ85apUG3y4Akre
set dpd-retryinterval 10
next
end
The IPsec transform set defines the encryption, authentication, and IPsec mode parameters.
config vpn ipsec phase2-interface
edit "vpn-07e988ccc1d46f749-1"
set phase1name "vpn-07e988ccc1d46f749-1"
set proposal aes128-sha1
set dhgrp 2
set pfs enable
set keylifeseconds 3600
next
end
You must configure a tunnel interface as the logical interface associated with the tunnel. All traffic routed to the tunnel
interface must be encrypted and transmitted to the VPC. Similarly, traffic from the VPC will be logically received on this
interface.
You must configure the interface's address with your FortiGate's address. If the address changes, you must recreate the
FortiGate and VPN connection with Amazon VPC.
The tcp-mss option causes the router to reduce the TCP packets' maximum segment size to prevent packet
fragmentation.
config system interface
edit "vpn-07e988ccc1d46f749-1"
set vdom "root"
set ip 169.254.44.162 255.255.255.255
set allowaccess ping
set type tunnel
set tcp-mss 1379
set remote-ip 169.254.44.161
set mtu 1427
set interface "wan1"
next
end
BGP is used within the tunnel to exchange prefixes between the virtual private gateway and your FortiGate. The virtual
private gateway announces the prefix according to your VPC.
The local BGP ASN (65000) is configured as part of your FortiGate. If you must change the ASN, you must recreate the
FortiGate and VPN connection with AWS.
Your FortiGate may announce a default route (0.0.0.0/0) to AWS. This is done using a prefix list and route map in
FortiOS.
config router bgp
set as 65000
config neighbor
edit 169.254.44.161
set remote-as 64512
end
config router bgp
config neighbor
edit 169.254.44.161
set capability-default-originate enable
end
end
config router prefix-list
edit "default_route"
config rule
edit 1
set prefix 0.0.0.0 0.0.0.0
next
end
end
end
config router route-map
edit "routemap1"
config rule
edit 1
set match-ip-address "default_route"
next
end
next
end
To advertise additional prefixes to the Amazon VPC, add these prefixes to the network statement and identify the prefix
you want to advertise. Ensure that the prefix is present in the routing table of the device with a valid next-hop. If you want
to advertise 192.168.0.0/16 to Amazon, you would do the following:
config router bgp
config network
edit 1
set prefix 192.168.0.0 255.255.0.0
next
end
Create a firewall policy permitting traffic from your local subnet to the VPC subnet, and vice-versa.
This example policy permits all traffic from the local subnet to the VPC. First, view all existing policies using the show
firewall policy command. Then, create a new firewall policy starting with the next available policy ID. In this
example, running show firewall policy displayed policies 1, 2, 3, 4, and 5, so you would proceed to create policy
6.
config firewall policy
edit 6
set srcintf "vpn-07e988ccc1d46f749-1"
set dstintf internal
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
end
config firewall policy
edit 6
set srcintf internal
set dstintf "vpn-07e988ccc1d46f749-1"
This example shows how to configure a site-to-site IPsec VPN tunnel to Microsoft Azure. It shows how to configure a
tunnel between each site, avoiding overlapping subnets, so that a secure tunnel can be established.
Prerequisites
Sample topology
Sample configuration
4. At the bottom of the Virtual network pane, click the Select a deployment model dropdown list and select Resource
Manager.
5. Click Create.
6. On the Create virtual network pane, enter you virtual network settings, and click Create.
3. Click Create Virtual network gateways and enter the settings for your virtual network gateway.
5. Click Create.
Creating the virtual network gateway might take some time. When the provisioning is done, you'll receive a
notification.
3. In the Everything pane, search for Local network gateway and then click Create local network gateway.
4. For the IP address, enter the local network gateway IP address, that is, the FortiGate's external IP address.
5. Set the remaining values for your local network gateway and click Create.
accepted by Azure.
l AES256 and SHA1
6. In Phase 2 Selectors, expand the Advanced section to configure the Phase 2 Proposal settings.
l Set the Encryption and Authentication combinations.
7. Click OK.
l Disable NAT.
4. We recommend limiting the TCP maximum segment size (MSS) being sent and received so as to avoid packet
drops and fragmentation.
1. In the Azure portal, locate and select your virtual network gateway.
2. In the Settings pane, click Connections and then click Add.
3. Enter the settings for your connection. Ensure the Shared Key (PSK) matches the Pre-shared Key for the FortiGate
tunnel.
l If the tunnel is down, right-click the tunnel and select Bring Up.
3. In the Azure portal dashboard, click All resources and locate your virtual network gateway.
a. In your virtual network gateway pane, click Connections to see the status of each connection.
b. Click a connection to open the Essentials pane to view more information about that connection.
l If the connection is successful, the Status shows Connected.
l See the ingress and egress bytes to confirm traffic flowing through the tunnel.
This is a sample configuration of an IPsec site-to-site VPN connection between an on-premise FortiGate and an Azure
virtual network (VNet). This example uses Azure virtual WAN (vWAN) to establish the VPN connection.
1. In the Azure management portal, configure vWAN-related settings as described in Tutorial: Create a Site-to-Site
connection using Azure Virtual WAN.
If a custom BGP IP address is configured on Azure's vWAN, such as 169.254.21.6 and 169.254.21.7, you must
configure the FortiGate remote-IP to the corresponding Custom BGP IP Address value. If a custom BGP IP
address is not configured, FortiGate remote-IPs should point to the Default BGP IP Address value.
2. Download the VPN configuration. The following shows an example VPN configuration:
[
{
"configurationVersion":{"LastUpdatedTime":"2019-07-
16T22:16:28.0409002Z","Version":"be5c5787-b903-43b1-a237-
49eae1b373e4"},"vpnSiteConfiguration":
{"Name":"toaws","IPAddress":"3.220.252.93","BgpSetting":
{"Asn":7225,"BgpPeeringAddress":"169.254.24.25","PeerWeight":32768},"LinkName":"toa
ws"},"vpnSiteConnections":[{"hubConfiguration":
{"AddressSpace":"10.1.0.0/16","Region":"West US","ConnectedSubnets":
["10.2.0.0/16"]},"gatewayConfiguration":{"IpAddresses":
{"Instance0":"52.180.90.47","Instance1":"52.180.89.94"},"BgpSetting":
{"Asn":65515,"BgpPeeringAddresses":
{"Instance0":"10.1.0.7","Instance1":"10.1.0.6"},"PeerWeight":0}},"connectionConfigu
ration":{"IsBgpEnabled":true,"PSK":"Fortinet123#","IPsecParameters":
{"SADataSizeInKilobytes":102400000,"SALifeTimeInSeconds":3600}}}]} ]
3. Configure the following on the FortiGate. Note for set proposal, you can select from several proposals.
config vpn ipsec phase1-interface
edit "toazure1"
set interface "port1"
set ike-version 2
set keylife 28800
set peertype any
set proposal aes256-sha1
set dhgrp 2
set remote-gw 52.180.90.47
set psksecret **********
next
edit "toazure2"
set interface "port1"
set ike-version 2
set keylife 28800
set peertype any
set proposal aes256-sha1
set dhgrp 2
set remote-gw 52.180.89.94
set psksecret **********
next
end
config vpn ipsec phase2-interface
edit "toazure1"
set phase1name "toazure1"
set proposal aes256-sha1
set dhgrp 2
set keylifeseconds 3600
next
edit "toazure2"
set phase1name "toazure2"
set proposal aes256-sha1
set dhgrp 2
set keylifeseconds 3600
next
end
config system settings
set allow-subnet-overlap enable
end
config system interface
edit "toazure1"
set vdom "root"
set ip 169.254.24.25 255.255.255.255
set type tunnel
set remote-ip 10.1.0.7 255.255.255.255
set snmp-index 4
set interface "port1"
next
edit "toazure2"
set vdom "root"
set ip 169.254.24.25 255.255.255.255
set type tunnel
set remote-ip 10.1.0.6 255.255.255.255
set snmp-index 5
set interface "port1"
next
end
config router bgp
set as 7225
set router-id 169.254.24.25
config neighbor
edit "10.1.0.7"
set remote-as 65515
next
edit "10.1.0.6"
set remote-as 65515
next
end
config network
edit 1
set prefix 172.30.101.0 255.255.255.0
next
end
config redistribute "connected"
set status enable
end
config redistribute "rip"
end
config redistribute "ospf"
end
config redistribute "static"
end
config redistribute "isis"
end
config redistribute6 "connected"
end
config redistribute6 "rip"
end
config redistribute6 "ospf"
end
config redistribute6 "static"
end
config redistribute6 "isis"
end
end
4. Run diagnose vpn tunnel list. If the configuration was successful, the output should resemble the following:
IPSec VPN between a FortiGate and a Cisco ASA with multiple subnets
When a Cisco ASA unit has multiple subnets configured, multiple phase 2 tunnels must be created on the FortiGate to
allocate to each subnet (rather than having multiple subnets on one phase 2 tunnel).
The FortiGate uses the same SPI value to bring up the phase 2 negotiation for all of the subnets, while the Cisco ASA
expects different SPI values for each of its configured subnets. Using multiple phase 2 tunnels on the FortiGate creates
different SPI values for each subnet.
This is a sample configuration of a FortiGate VPN that is compatible with Cisco-style VPNs that use GRE in an IPsec
tunnel. Cisco products with VPN support often use the GRE protocol tunnel over IPsec encryption. Cisco VPNs can use
either transport mode or tunnel mode IPsec.
Topology
There are five steps to configure GRE-over-IPsec with a FortiGate and Cisco router:
1. Enable overlapping subnets.
2. Configure a route-based IPsec VPN on the external interface.
3. Configure a GRE tunnel on the virtual IPsec interface.
4. Configure security policies.
5. Configure the static route.
Overlapping subnets are required because the IPsec and GRE tunnels will use the same addresses. By default, each
FortiGate network interface must be on a separate network. This configuration assigns an IPsec tunnel endpoint and the
external interface to the same network.
A route-based VPN that use encryption and authentication algorithms compatible with the Cisco router is required. Pre-
shared key authentication is used in this configuration.
Pre-shared Key Entry must match the pre-shared key on the Cisco router
Phase 1 Proposal 3DES-SHA1, AES128-SHA1 (at least one proposal must match the settings
on the Cisco router)
Phase 2 Proposal 3DES-MD5 (at least one proposal must match the settings on the Cisco router)
Local Port 0
Remote Port 0
Protocol 47
4. Click OK.
5. If the Cisco router is configured to use transport mode IPsec, configure transport mode on the FortiGate:
config vpn phase2-interface
edit tocisco_p2
set encapsulation transport-mode
next
end
The local gateway and remote gateway addresses must match the local and remote gateways of the IPsec tunnel. The
GRE tunnel runs between the virtual IPsec public interface on the FortiGate unit and the Cisco router.
The Cisco router configuration requires an address for its end of the GRE tunnel, so you need to add the tunnel end
addresses.
next
end
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. Enter the following to allow traffic between the protected network and the GRE tunnel:
Name LANtoGRE
Incoming Interface Interface that connects to the private network behind the FortiGate (port2)
Source All
Destination All
Action ACCEPT
NAT Disable
3. Click OK.
4. Create a new policy and enter the following to allow traffic between the GRE tunnel and the protected network:
Name GREtoLAN
Outgoing Interface Interface that connects to the private network behind the FortiGate (port2)
Source All
Destination All
Action ACCEPT
NAT Disable
5. Click OK.
6. Create a new policy and enter the following to allow traffic between the GRE virtual interface and the IPsec virtual
interface:
Name GREtoIPsec
Source All
Destination All
Action ACCEPT
NAT Disable
7. Click OK.
8. Create a new policy and enter the following to allow traffic between the IPsec virtual interface and the GRE virtual
interface:
Name IPsectoGRE
Source All
Destination All
Action ACCEPT
NAT Disable
9. Click OK.
next
edit 4
set name IPsectoGRE
set srcintf tocisco
set dstintf gre1
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ALL
next
end
Configuring routing
to direct traffic destined for the network behind the Cisco router into the GRE-over-IPsec tunnelTraffic destined for the
network behind the Cisco router must be routed to the GRE tunnel. To do this, create a static route
Destination IP and netmask for the network behind the Cisco router (10.21.101.0
255.255.255.0)
3. Click OK.
For more information, refer to Configuring and verifying a GRE over IPsec tunnel in the Fortinet Knowledge Base.
Remote access
Remote access lets users connect to the Internet using a dialup connection over traditional POTS or ISDN telephone
lines. Virtual private network (VPN) protocols are used to secure these private connections.
The following topics provide instructions on configuring remote access:
l FortiGate as dialup client on page 1360
l FortiClient as dialup client on page 1366
This is a sample configuration of dialup IPsec VPN and the dialup client. In this example, a branch office FortiGate
connects via dialup IPsec VPN to the HQ FortiGate.
You can configure dialup IPsec VPN with FortiGate as the dialup client using the GUI or CLI.
To configure IPsec VPN with FortiGate as the dialup client in the GUI:
To configure IPsec VPN with FortiGate as the dialup client in the CLI:
1. In the CLI, configure the user, user group, and firewall address. Only the HQ dialup server FortiGate needs this
configuration. The address is an IP pool to assign an IP address for the dialup client FortiGate.
config user local
edit "vpnuser1"
set type password
set passwd your-password
next
end
config user group
edit "vpngroup"
set member "vpnuser1"
next
end
config firewall address
edit "client_range"
set type iprange
set start-ip 10.10.10.1
set end-ip 10.10.10.200
next
end
2. Configure the WAN interface and default route. The WAN interface is the interface connected to the ISP. It can work
in static mode (as shown in this example), DHCP, or PPPoE mode. The IPsec tunnel is established over the
WAN interface.
a. Configure the HQ FortiGate.
config system interface
edit "wan1"
set vdom "root"
set ip 11.101.1 255.255.255.0
next
end
config router static
edit 1
set gateway 11.101.1.2
set device "wan1"
next
end
3. Configure the internal interface and protected subnet. The internal interface connects to the internal network. Traffic
from this interface will route out the IPsec VPN tunnel.
a. Configure the HQ FortiGate.
config system interface
edit "dmz"
set vdom "root"
set ip 10.1.100.1 255.255.255.0
next
end
config firewall address
edit "10.1.100.0"
set subnet 10.1.100.0 255.255.255.0
next
end
4. Configure the IPsec phase1-interface. In this example, PSK is used as the authentication method. Signature
authentication is also an option.
6. Configure the static routes on the branch office FortiGate. The blackhole route is important to ensure that IPsec
traffic does not match the default route when the IPsec tunnel is down.
config router static
edit 2
set dst 10.1.100.0 255.255.255.0
set device "to_HQ"
next
edit 3
set dst 10.1.100.0 255.255.255.0
set blackhole enable
set distance 254
next
end
7. Configure the firewall policy to allow the branch office to HQ network flow over the IPsec tunnel. This configuration
only supports traffic from the branch office FortiGate to the HQ FortiGate. Traffic is dropped from the HQ FortiGate
to the branch office FortiGate.
a. Configure the HQ FortiGate.
config firewall policy
edit 1
set name "inbound"
set srcintf "for_Branch"
set dstintf "dmz"
set srcaddr "172.16.101.0"
set dstaddr "10.1.100.0"
set action accept
set schedule "always"
set service "ALL"
next
end
8. Run diagnose commands to check the IPsec phase1/phase2 interface status. The diagnose debug
application ike -1 command is the key to troubleshoot why the IPsec tunnel failed to establish.
a. Run the diagnose vpn ike gateway list command on the HQ FortiGate. The system should return the
following:
vd: root/0
name: for_Branch_0
version: 1
interface: wan1 5
addr: 11.101.1.1:500 -> 173.1.1.1:500
created: 1972s ago
xauth-user: vpnuser1
assigned IPv4 address: 10.10.10.1/255.255.255.252
IKE SA: created 1/1 established 1/1 time 10/10/10 ms
IPsec SA: created 1/1 established 1/1 time 0/0/0 ms
id/spi: 184 5b1c59fab2029e43/bf517e686d3943d2
direction: responder
status: established 1972-1972s ago = 10ms
proposal: aes128-sha256
key: 8046488e92499247-fbbb4f6dfa4952d0
lifetime/rekey: 86400/84157
DPD sent/recv: 00000020/00000000
b. Run the diagnose vpn tunnel list command on the HQ FortiGate. The system should return the
following:
list all ipsec tunnel in vd 0
name=for_Branch_0 ver=1 serial=9 11.101.1.1:0->173.1.1.1:0
bound_if=5 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/208 options
[00d0]=create_dev no-sysctlrgwy-chg
parent=for_Branch index=0
proxyid_num=1 child_num=0 refcnt=12 ilast=8 olast=8 ad=/0
stat: rxp=8 txp=8 rxb=1216 txb=672
dpd: mode=on-idle on=1 idle=60000ms retry=3 count=0 seqno=31
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=for_Branch_p2 proto=0 sa=1 ref=2 serial=1
src: 0:0.0.0.0-255.255.255.255:0
dst: 0:0.0.0.0-255.255.255.255:0
SA: ref=3 options=226 type=00 soft=0 mtu=1438 expire=41297/0B replaywin=2048 seqno=9
esn=0 replaywin_lastseq=00000009 itn=0
life: type=01 bytes=0/0 timeout=43190/43200
dec: spi=747c10c6 esp=aes key=16 278c2430e09e74f1e229108f906603b0
ah=sha1 key=20 21dad76b008d1e8b8e53148a2fcbd013a277974a
enc: spi=ca646448 esp=aes key=16 b7801d125804e3610a556da7caefd765
ah=sha1 key=20 a70164c3094327058bd84c1a0c954ca439709206
dec:pkts/bytes=8/672, enc:pkts/bytes=8/1216
c. Run the diagnose vpn ike gateway list command on the branch office FortiGate. The system should
return the following:
vd: root/0
name: to_HQ
version: 1
interface: port13 42
d. Run the diagnose vpn tunnel list command on the branch office FortiGate. The system should return
the following:
list all ipsec tunnel in vd 0
name=to_HQver=1 serial=7 173.1.1.1:0->11.101.1.1:0
bound_if=42 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=13 ilast=18 olast=58 ad=/0
stat: rxp=1 txp=2 rxb=152 txb=168
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=to_HQ proto=0 sa=1 ref=2 serial=1
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=6 options=10226 type=00 soft=0 mtu=1438 expire=41015/0B replaywin=2048
seqno=3 esn=0 replaywin_lastseq=00000002 itn=0
life: type=01 bytes=0/0 timeout=42898/43200
dec: spi=ca646448 esp=aes key=16 b7801d125804e3610a556da7caefd765
ah=sha1 key=20 a70164c3094327058bd84c1a0c954ca439709206
enc: spi=747c10c6 esp=aes key=16 278c2430e09e74f1e229108f906603b0
ah=sha1 key=20 21dad76b008d1e8b8e53148a2fcbd013a277974a
dec:pkts/bytes=1/84, enc:pkts/bytes=2/304
npu_flag=03 npu_rgwy=11.101.1.1 npu_lgwy=173.1.1.1 npu_selid=5 dec_npuid=2 enc_
npuid=2
This is a sample configuration of dialup IPsec VPN with FortiClient as the dialup client.
You can configure dialup IPsec VPN with FortiClient as the dialup client using the GUI or CLI.
If multiple dialup IPsec VPNs are defined for the same dialup server interface, each phase1 configuration must define a
unique peer ID to distinguish the tunnel that the remote client is connecting to. When a client connects, the first IKE
message that is in aggressive mode contains the client's local ID. FortiGate matches the local ID to the dialup tunnel
referencing the same Peer ID, and the connection continues with that tunnel.
To configure IPsec VPN with FortiClient as the dialup client on the GUI:
To configure IPsec VPN with FortiClient as the dialup client using the CLI:
2. Configure the internal interface. The LAN interface connects to the corporate internal network. Traffic from this
interface routes out the IPsec VPN tunnel. Creating an address group for the protected network behind this
FortiGate causes traffic to this network group to go through the IPsec tunnel.
config system interface
edit "lan"
set vdom "root"
set ip 10.10.111.1 255.255.255.0
next
end
config firewall address
edit "local_subnet_1"
set subnet 10.10.111.0 255.255.255.0
next
edit "local_subnet_2"
set subnet 10.10.112.0 255.255.255.0
next
end
config firewall addrgrp
edit "local_network"
set member "local_subnet_1" "local_subnet_2"
next
end
3. Configure the WAN interface. The WAN interface is the interface connected to the ISP. It can work in static mode
(as shown in this example), DHCP, or PPPoE mode. The IPsec tunnel is established over the WAN interface.
config system interface
edit "wan1"
set vdom "root"
set ip 172.20.120.123 255.255.255.0
next
end
4. Configure the client address pool. You must create a firewall address to assign an IP address to a client from the
address pool.
config firewall address
edit "client_range"
set type iprange
set comment "VPN client range"
set start-ip 10.10.2.1
set end-ip 10.10.2.200
next
end
5. Configure the IPsec phase1-interface. In this example, PSK is used as the authentication method. Signature
authentication is also an option.
config vpn ipsec phase1-interface
edit "for_client"
set type dynamic
set interface "wan1"
set mode aggressive
set peertype one
set peerid "dialup1"
set net-device enable
set mode-cfg enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set dpd on-idle
set xauthtype auto
set authusrgrp "vpngroup"
set assign-ip-from name
set ipv4-name "client_range"
set dns-mode auto
set ipv4-split-include "local_network"
set save-password enable
set psksecret your-psk
set dpd-retryinterval 60
next
end
7. Configure the firewall policy to allow client traffic flow over the IPsec VPN tunnel.
config firewall policy
edit 1
set name "inbound"
set srcintf "for_client"
set dstintf "lan"
set srcaddr "client_range"
To configure FortiClient:
Run diagnose commands to check the IPsec phase1/phase2 interface status. The diagnose debug application
ike -1 command is the key to troubleshoot why the IPsec tunnel failed to establish.
1. Run the diagnose vpn ike gateway list command. The system should return the following:
vd: root/0
name: for_client_0
version: 1
interface: port1 15
addr: 172.20.120.123:4500 ->172.20.120.254:64916
created: 37s ago
xauth-user: vpnuser1
assigned IPv4 address: 10.10.1.1/255.255.255.255
nat: me peer
IKE SA: created 1/1 established 1/1 time 10/10/10 ms
IPsec SA: created 1/1 established 1/1 time 0/0/0 ms
id/spi: 1 b40a32d878d5e262/8bba553563a498f4
direction: responder
status: established 37-37s ago = 10ms
proposal: aes256-sha256
key: f4ad7ec3a4fcfd09-787e2e9b7bceb9a7-0dfa183240d838ba-41539863e5378381
lifetime/rekey: 86400/86092
DPD sent/recv: 00000000/00000a0e
2. Run the diagnose vpn tunnel list command. The system should return the following:
list all ipsec tunnel in vd 0
=
=
name=for_client_0 ver=1 serial=3 172.20.120.123:4500->172.20.120.254:64916
bound_if=15 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/984 options
[03d8]=npucreate_dev no-sysctlrgwy-chgrport-chg frag-rfcaccept_traffic=1
parent=for_client index=0
proxyid_num=1 child_num=0 refcnt=12 ilast=3 olast=3 ad=/0
stat: rxp=1 txp=0 rxb=16402 txb=0
dpd: mode=on-idle on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=keepalive draft=32 interval=10 remote_port=64916
This configuration adds multi-factor authentication (MFA) to the FortiClient dialup VPN configuration (FortiClient as
dialup client on page 1366). It uses one of the two free mobile FortiTokens that is already installed on the FortiGate.
This configuration adds LDAP user authentication to the FortiClient dialup VPN configuration (FortiClient as dialup client
on page 1366). You must have already generated and exported a CA certificate from your AD server.
set dn "cn=Users,dc=qa,dc=fortinet,dc=com"
set type regular
set username "CN=Administrator,cn=users,DC=qa,DC=fortinet,DC=com"
set password **********
set group-member-check group-object
set secure ldaps
set ca-cert "LDAPS-CA"
set port 636
next
end
This is a sample configuration of dialup IPsec VPN with an iPhone or iPad as the dialup client.
You can configure dialup IPsec VPN with an iOS device as the dialup client using the GUI or CLI.
To configure IPsec VPN with an iOS device as the dialup client on the GUI:
1. Go to VPN > IPsec Wizard and configure the following settings for VPN Setup:
a. Enter a VPN name.
b. For Template Type, select Remote Access.
c. For Remote Device Type, select Native > iOS Native.
d. For NAT Configuration, set No NAT Between Sites.
e. Click Next.
2. Configure the following settings for Authentication:
a. For Incoming Interface, select wan1.
b. For Authentication Method, select Pre-shared Key.
To configure IPsec VPN with an iOS device as the dialup client using the CLI:
2. Configure the internal interface. The LAN interface connects to the corporate internal network. Traffic from this
interface routes out the IPsec VPN tunnel. Creating an address group for the protected network behind this
FortiGate causes traffic to this network group to go through the IPsec tunnel.
config system interface
edit "lan"
set vdom "root"
set ip 10.10.111.1 255.255.255.0
next
end
next
end
3. Configure the WAN interface. The WAN interface is the interface connected to the ISP. It can work in static mode
(as shown in this example), DHCP, or PPPoE mode. The IPsec tunnel is established over the WAN interface.
config system interface
edit "wan1"
set vdom "root"
set ip 172.20.120.123 255.255.255.0
next
end
4. Configure the client address pool. You must create a firewall address to assign an IP address to a client from the
address pool.
config firewall address
edit "client_range"
set type iprange
set comment "VPN client range"
set start-ip 10.10.2.1
set end-ip 10.10.2.200
next
end
5. Configure the IPsec phase1-interface. In this example, PSK is used as the authentication method. Signature
authentication is also an option.
config vpn ipsec phase1-interface
edit "for_ios_p1"
set type dynamic
set interface "wan1"
set peertype any
set net-device enable
set mode-cfg enable
set proposal aes256-sha256 aes256-md5 aes256-sha1
set dpd on-idle
set dhgrp 14 5 2
set xauthtype auto
set authusrgrp "vpngroup"
set assign-ip-from name
set ipv4-name "client_range"
set dns-mode auto
set ipv4-split-include "local_network"
set psksecret your-psk
set dpd-retryinterval 60
next
end
next
end
7. Configure the firewall policy to allow client traffic flow over the IPsec VPN tunnel.
config firewall policy
edit 1
set name "ios_vpn"
set srcintf "for_ios_p1"
set dstintf "lan"
set srcaddr "ios_range"
set dstaddr "local_network"
set action accept
set schedule "always"
set service "ALL"
next
end
b. Run the diagnose vpn tunnel list command. The system should return the following:
list all ipsec tunnel in vd 0
=
=
name=for_ios_p1_0 ver=1 serial=172.20.120.123:4500->172.20.120.254:64916
bound_if=15 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/984 options
[03d8]=npu create_dev no-sysctl rgwy-chg rport-chg frag-rfc accept_traffic=1
parent=for_ios_p1 index=0
proxyid_num=1 child_num=0 refcnt=12 ilast=23 olast=23 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-idle on=1 idle=60000ms retry=3 count=0 seqno=0
IKE Mode Config is an alternative to DHCP over IPsec. It allows dialup VPN clients to obtain virtual IP address, network,
and DNS configurations amongst others from the VPN server. A FortiGate can be configured as either an IKE Mode
Config server or client.
IKE Mode Config can configure the host IP address, domain, DNS addresses ,and WINS addresses. IPsec parameters
such as gateway address, encryption, and authentication algorithms must be configured. Several network equipment
vendors support IKE Mode Config.
An IKE Mode Config server or client is configured using config vpn ipsec phase1-interface and involves the
following parameters:
Parameter Description
ike-version {1 | 2} IKE v1 is the default for FortiGate IPsec VPNs. IKE Mode Config is also
compatible with IKE v2.
type {static | dynamic | ddns} If you set type to dynamic, an IKE Mode Config server is created. The other
settings create an IKE Mode Config client.
assign-ip {enable | disable} Enable to request an IP address from the server. This configuration is for IKE
Mode Config clients only.
interface <interface_name> Specify the physical, aggregate, or VLAN interface to which the IPsec tunnel will
be bound.
proposal <encryption_ The encryption and authentication settings that the client will accept.
combination>
ipv4-split-exclude <string> Specify the subnets that should not be sent over the IPsec tunnel. This
ipv6-split-exclude <string> configuration is for IKE Mode Config clients only (see Split-exclude in IKEv1).
In this example, the FortiGate connects to a VPN gateway with a static IP address that can be reached through port 1.
Only the port, gateway, and proposal information needs to be configured. All other configuration information will come
Split-exclude in IKEv1
The split-exclude option specifies that default traffic flows over the IPsec tunnel except for specified subnets. This is
the opposite of split-include, which specifies that default traffic should not flow over the IPsec tunnel except for
specified subnets. The split-include and split-exclude options can be specified at the same time.
To configure split-exclude:
In this example, the FortiGate assigns IKE Mode Config clients addresses in the range of 10.11.101.160 -
10.11.101.180. DNS and WINS server addresses are also provided. The public interface of the FortiGate unit is port1.
When IKE Mode-Configuration is enabled, multiple server IPs can be defined in IPsec phase 1.
The ipv4-split-include parameter specifies a firewall address (OfficeLAN), which represents the networks that
the clients will have access to. This destination IP address information is sent to the clients.
Assigning IP addresses
Once the basic configuration is enabled, you can configure IP address assignment for clients, as well as DNS and WINS
server assignments. Usually you will want to assign IP addresses to clients. The easiest way is to assign addresses from
a specific range, similar to a DHCP server.
RADIUS server
If the client is authenticated by a RADIUS server, you can obtain the user’s IP address assignment from the Framed-IP-
Address attribute. The user must be authenticated using XAuth.
The users must be authenticated by a RADIUS server and assigned to the FortiGate user group <grp_name>. Since the
IP address is not static, type is set to dynamic and mode-cfg is enabled. With IKE Mode Config, compatible clients can
configure themselves with settings provided by the FortiGate.
DHCP server
IKE Mode Config can use a remote DHCP server to assign the client IP addresses. Up to eight server addresses can be
selected for either IPv4 or IPv6. The DHCP proxy must be enabled first.
Certificate groups
IKE certificate groups consisting of up to four RSA certificates can be used in IKE phase 1. Since CA and local
certificates are global, the IKE daemon loads them once for all VDOMs and indexes them into trees based on subject
and public key hash (for CA certificates), or certificate name (for local certificates). Certificates are linked together based
on the issuer, and certificate chains are built by traversing these links. This reduces the need to keep multiple copies of
certificates that could exist in multiple chains.
You can use an external DHCP server to assign IP addresses to your IPsec VPN clients. This is a common scenario
found in enterprises where all DHCP leases need to be managed centrally.
In this example, the DHCP server assigns IP addresses in the range of 172.16.6.100 to 172.16.6.120. The server is
attached to internal2 on the FortiGate and has an IP address of 192.168.3.70.
g. Click OK.
2. Add a firewall address for the local network and IPsec VPN client range:
a. Go to Policy & Objects > Addresses.
b. Create a new Subnet address for the LAN, including the IP mask and local interface (internal2).
c. Click OK.
d. Create a new IP Range address for the IPsec VPN client range (172.16.6.100–172.16.6.120).
e. Click OK.
6. Configure FortiClient:
a. In FortiClient, go to REMOTE ACCESS > Add a new connection.
v. Expand the Advanced Settings > VPN Settings and for Options, select DHCP over IPsec.
vi. Click Save.
c. Select the new connection, and enter the user name and password.
d. Click Connect.
Once the connection is established, the external DHCP server assigns the user an IP address and FortiClient
displays the connection status, including the IP address, connection duration, and bytes sent and received.
Verification
1. In FortiOS, go to Monitor > IPsec Monitor and verify that the tunnel Status is Up.
2. Go to Log & Report > Forward Traffic and verify the Sent / Received column displays the traffic flow through the
tunnel.
5. Configure a firewall address that is applied in L2TP settings to assign IP addresses to clients once the L2TP tunnel
is established.
config firewall address
edit "L2TPclients"
set type iprange
set start-ip 10.10.10.1
set end-ip 10.10.10.100
next
end
HQ # Num of tunnels: 2
----
Tunnel ID = 1 (local id), 42 (remote id) to 10.1.100.15:1701
control_seq_num = 2, control_rec_seq_num = 4,
last recv pkt = 2
Call ID = 1 (local id), 1 (remote id), serno = 0, dev=ppp1,
assigned ip = 10.10.10.2
data_seq_num = 0,
tx = 152 bytes (2), rx= 21179 bytes (205)
Tunnel ID = 3 (local id), 34183 (remote id) to 22.1.1.2:58825
control_seq_num = 2, control_rec_seq_num = 4,
last recv pkt = 2
Call ID = 3 (local id), 18820 (remote id), serno = 2032472593, dev=ppp2,
assigned ip = 10.10.10.3
data_seq_num = 0,
tx = 152 bytes (2), rx= 0 bytes (0)
----
--VD 0: Startip = 10.10.10.1, Endip = 10.10.10.100
enforece-ipsec = false
----
This is a sample configuration of tunneled internet browsing using a dialup VPN. To centralize network management and
control, all branch office traffic is tunneled to HQ, including Internet browsing.
1. Configure the WAN interface and static route on the FortiGate at HQ.
config system interface
edit "port9"
set alias "WAN"
set ip 22.1.1.1 255.255.255.0
next
edit "port10"
set alias "Internal"
set ip 172.16.101.1 255.255.255.0
next
end
config router static
edit 1
set gateway 22.1.1.2
set device "port9"
next
end
4. Configure the WAN interface and static route on the FortiGate at the branches.
a. Branch1.
config system interface
edit "wan1"
set ip 15.1.1.2 255.255.255.0
next
edit "internal"
set ip 10.1.100.1 255.255.255.0
next
end
config router static
edit 1
set gateway 15.1.1.1
set device "wan1"
next
end
b. Branch2.
config system interface
edit "wan1"
set ip 13.1.1.2 255.255.255.0
next
edit "internal"
set ip 192.168.4.1 255.255.255.0
next
end
config router static
edit 1
set gateway 13.1.1.1
set device "wan1"
next
end
b. Branch2.
config vpn ipsec phase1-interface
edit "branch2"
set interface "wan1"
set peertype any
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set dpd on-idle
set remote-gw 22.1.1.1
set psksecret sample
set dpd-retryinterval 5
next
end
config vpn ipsec phase2-interface
edit "branch2"
set phase1name "branch2"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
set src-subnet 192.168.4.0 255.255.255.0
next
end
b. Branch2.
config firewall policy
edit 1
set name "outbound"
set srcintf "internal"
set dstintf "branch2"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "inbound"
set srcintf "branch2"
set dstintf "internal"
set srcaddr "all"
set dstaddr "all"
set action accept
b. Branch2.
config router static
edit 2
set dst 22.1.1.1/32
set gateway 13.1.1.1
set device "wan1"
set distance 1
next
edit 3
set device "branch2"
set distance 5
next
end
8. Optionally, view the VPN tunnel list on a branch with the diagnose vpn tunnel list command:
list all ipsec tunnel in vd 0
----
name=branch1 ver=1 serial=2 15.1.1.2:0->22.1.1.1:0
bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/536 options[0218]=npu create_
dev frag-rfc accept_traffic=1
dec:pkts/bytes=0/16348, enc:pkts/bytes=313/55962
npu_flag=03 npu_rgwy=22.1.1.1 npu_lgwy=15.1.1.2 npu_selid=1 dec_npuid=1 enc_npuid=1
9. Optionally, view static routing table on a branch with the get router info routing-table static
command:
Routing table for VRF=0
S* 0.0.0.0/0 [5/0] is directly connected, branch1
S* 22.1.1.1/32 [1/0] via 15.1.1.1, wan1
In a dialup IPsec VPN setup, a company may choose to use X.509 certificates as their authentication solution for remote
users. This method includes the option to verify the remote user using a user certificate, instead of a username and
password. This method can be simpler for end users.
Administrators need to issue unique user certificates to each user for remote access management. The user certificate
can be verified by the subject field, common name, or the principal name in the Subject Alternative Name (SAN) field.
This is the basic method that verifies the subject string defined in the PKI user setting matches a substring in the subject
field of the user certificate. For example:
config user peer
edit "tgerber"
set ca "CA_Cert_2"
set subject "CN=tgerber"
next
end
In this method, administrators can define the CN string to match the common name (CN) in the subject field of the
certificate. For example:
config user peer
edit "tgerber"
set ca "CA_Cert_2"
set cn "tgerber"
next
end
A PKI user must be created on the FortiGate for each remote user that connects to the VPN with a unique user
certificate.
In this method, the PKI user setting references an LDAP server. When ldap-mode is set to principal-name, the
UPN in the user certificate’s SAN field is used to look up the user in the LDAP directory. If a match is found, then
authentication succeeds. For example:
config user peer
edit "ldap-peer"
set ca "CA_Cert_2"
set ldap-server "WIN2K16-KLHOME-LDAPS"
set ldap-mode principal-name
next
end
This method is more scalable because only one PKI user needs to be created on the FortiGate. Remote users connect
with their unique user certificate that are matched against users in the LDAP server.
Certificate management
Dialup IPsec VPN with certificate authentication requires careful certificate management planning. Assuming that a
company’s private certificate authority (CA) is used to generate and sign all the certificates, the following certificates are
needed:
Server certificate The server certificate is used to identify the FortiGate IPsec dialup gateway. A
CSR can be generated on the FortiGate and signed by the CA, or the CA can
generate the private and public keys and export the certificate package to the
FortiGate.
User certificate The user certificate is generated and signed by the CA with unique CNs in the
subject field and/or unique Principal Names in the SAN field. They are used to
identify the user that is connecting to the VPN. User certificates must be installed
on client machines.
CA certificate The root CA certificate, and any subordinate CA that signed the actual user and
server certificates, must be imported into the FortiGate and client machines. The
CA certificate is used to verify the certificate chain of the server and user
certificates.
Example
In this example, a dialup IPsec VPN tunnel is configured with certificate authentication using the subject field verification
method and the LDAP integration method.
The company CA, named root CA, signs all the server and user certificates. The user, [email protected], has a user
certificate signed by root CA installed on their endpoint. The corresponding user account is also present under the
company’s Active Directory.
There are five major steps to configure this example:
1. Importing the certificates
2. Configuring user authentication
3. Configuring the VPN
4. Configuring FortiClient and the endpoints
5. Testing and verifying the certificate authentication
The server certificate and CA certificate need to be imported into the FortiGate.
If any subordinate CA is involved in signing the certificates, you need to import its certificate.
FortiGate PKI users do not appear in the GUI until at least one PKI user has been created in the CLI. The following
instructions create the PKI users in the CLI.
1. Create the PKI user and choose the CA certificate that was imported (if the certificate was signed by a subordinate
CA, choose the subordinate CA’s certificate):
config user peer
edit "tgerber"
set ca "CA_Cert_2"
set subject "CN=tgerber"
next
end
2. Configure the PKI user to reference the LDAP server using the CA certificate that was imported:
config user peer
edit "ldap-peer"
set ca "CA_Cert_2"
set ldap-server "WIN2K16-KLHOME-LDAPS"
set ldap-mode principal-name
next
end
To configure the VPN, the address objects must be defined first so they can be used in the VPN and policy
configurations. In this example, the VPN is configured in custom mode to define the authentication settings.
1. Go to VPN > IPsec Tunnels and click Create New > IPsec Tunnel.
2. Enter a name for the tunnel, Dialup-cert_0.
3. For Template type, select Custom then click Next.
Interface port1
Method Signature
Mode Aggressive
Peer Options > Peer Select the group based on the preferred method:
certificate group l For subject verification, select pki-users.
When IKEv1 is used, aggressive mode should be selected so that the connecting endpoint will provide its peer ID in
the first message of the IKE exchange. The peer identifier allows the FortiGate to match the correct tunnel when
multiple dialup tunnels are defined.
6. For Phase 2 Selectors, leave the local and remote selectors as 0.0.0.0/0.0.0.0.
7. Click OK.
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. Configure the following:
Source remote-user-range
Destination 192.168.20.0
Schedule always
Service ALL
Action ACCEPT
The following example is configured on a Windows PC with FortiClient 7.0.0. Other configurations may differ slightly.
The user certificate and CA certificate must be installed on the endpoint device. They may be pushed by the
administrator through group policies or another method. This example assumes that the user certificate and CA
certificate are already installed on the endpoint.
3. Go to Trusted Root Certification Authorities > Certificates. The company CA certificate should be listed.
1. In FortiClient, click the Remote Access tab and add a new connection:
a. If there are no existing connections, click Configure VPN.
b. If there are existing connections, click the menu icon and select Add a new connection.
2. Configure the following:
3. Click Save.
1. On the client PC, open FortiClient and click the Remote Access tab.
2. Select the VPN tunnel, Dialup-cert_0, and click Connect.
If the connection is successful, a FortiClient pop-up will appear briefly indicating that the IKE negotiation succeeded.
The Remote Access window now displays VPN Connected and the associated VPN tunnel details.
3. On the FortiGate, go to Dashboard > Network and locate the IPsec widget to view the VPN tunnel monitor. Click the
widget to expand to full view.
The widget displays tunnel information, including the Peer ID containing the subject field of the user certificate.
4. Go to Log & Report > Events > VPN Events. Several tunnel related logs are recorded.
5. The same logs can be viewed in the CLI:
# execute log filter category 1
# execute log filter field subtype vpn
# execute log display
7: date=2021-08-23 time=15:53:08 eventtime=1629759188862005740 tz="-0700"
logid="0101037138" type="event" subtype="vpn" level="notice" vd="root" logdesc="IPsec
connection status changed" msg="IPsec connection status change" action="tunnel-up"
remip=192.168.2.1 locip=192.168.2.5 remport=64916 locport=4500 outintf="port1"
cookies="19f05ebc8c2f7a0d/7716190005538db5" user="C = CA, ST = British Columbia, L =
Burnaby, O = FortiKeith, OU = TAC, CN = tgerber" group="pki-ldap" useralt="C = CA, ST =
British Columbia, L = Burnaby, O = FortiKeith, OU = TAC, CN = tgerber" xauthuser="N/A"
xauthgroup="N/A" assignip=172.18.200.10 vpntunnel="Dialup-cert_0" tunnelip=172.18.200.10
tunnelid=3418215253 tunneltype="ipsec" duration=0 sentbyte=0 rcvdbyte=0 nextstat=0
6. If any issues arise during the connection, run the following debug commands to troubleshoot the issue:
# diagnose debug application ike -1
# diagnose debug application fnbamd -1
# diagnose debug enable
The following topics provide instructions on configuring aggregate and redundant VPNs:
A FortiGate with two interfaces connected to the internet can be configured to support redundant VPNs to the same
remote peer. Four distinct paths are possible for VPN traffic from end to end. If the primary connection fails, the FortiGate
can establish a VPN using the other connection.
Topology
The redundant configuration in this example uses route-based VPNs. The FortiGates must operate in NAT mode and
use auto-keying.
This example assumes the redundant VPNs are essentially equal in cost and capability. When the original VPN returns
to service, traffic continues to use the replacement VPN until the replacement VPN fails. If the redundant VPN uses more
expensive facilities, only use it as a backup while the main VPN is down.
A redundant configuration for each VPN peer includes:
l One phase 1 configuration for each path between the two peers with dead peer detection enabled
l One phase 2 definition for each phase 1 configuration
l One static route for each IPsec interface with different distance values to prioritize the routes
l Two firewall policies per IPsec interface, one for each direction of traffic
IP Address Enter the IP address of the primary interface of the remote peer.
IP Address Enter the IP address of the secondary interface of the remote peer.
b. Path 3:
IP Address Enter the IP address of the primary interface of the remote peer.
c. Path 4:
IP Address Enter the IP address of the secondary interface of the remote peer.
Incoming Interface Select the local interface to the internal (private) network.
Source All
Destination All
Schedule Always
Service All
Action ACCEPT
c. Click OK.
d. Click Create New and configure the policy for the other direction of traffic:
Outgoing Interface Select the local interface to the internal (private) network.
Source All
Destination All
Schedule Always
Service All
Action ACCEPT
e. In the policy list, drag the VPN policies above any other policies with similar source and destination addresses.
2. Repeat these steps to create the policies for the three remaining paths.
A route-based VPN can be configured to act as a backup IPsec interface when the main VPN is out of service. This can
only be configured in the CLI.
The backup feature works on interfaces with static addresses that have dead peer detection enabled. The monitor
option creates a backup VPN for the specified phase 1 configuration.
This is a sample configuration of using OSPF with IPsec VPN to set up network redundancy. Route selection is based on
OSPF cost calculation. You can configure ECMP or primary/secondary routes by adjusting OSPF path cost.
Because the GUI can only complete part of the configuration, we recommend using the CLI.
To configure OSPF with IPsec VPN to achieve network redundancy using the CLI:
end
b. Configure HQ2.
config system interface
edit "port9"
set ip 172.16.101.1 255.255.255.0
next
end
3. Configure IPsec phase1-interface and phase-2 interface. On each FortiGate, configure two IPsec tunnels: a primary
and a secondary.
a. Configure HQ1.
config vpn ipsec phase1-interface
edit "pri_HQ2"
set interface "port1"
set peertype any
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.16.202.1
set psksecret sample1
next
edit "sec_HQ2"
set interface "port2"
set peertype any
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.17.202.1
set psksecret sample2
next
end
config vpn ipsec phase2-interface
edit "pri_HQ2"
set phase1name "pri_HQ2"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
next
edit "sec_HQ2"
set phase1name "sec_HQ2"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
next
end
b. Configure HQ2.
config vpn ipsec phase1-interface
edit "pri_HQ1"
set interface "port25"
set peertype any
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.16.200.1
set psksecret sample1
next
edit "sec_HQ1"
set interface "port26"
set peertype any
set net-device enable
next
edit "sec_HQ2"
set ip 10.10.11.1 255.255.255.255
set remote-ip 10.10.11.2 255.255.255.255
next
end
b. Configure HQ2.
config system interface
edit "pri_HQ1"
set ip 10.10.10.2 255.255.255.255
set remote-ip 10.10.10.1 255.255.255.255
next
edit "sec_HQ1"
set ip 10.10.11.2 255.255.255.255
set remote-ip 10.10.11.1 255.255.255.255
next
end
6. Configure OSPF.
a. Configure HQ1.
config router ospf
set router-id 1.1.1.1
config area
edit 0.0.0.0
next
end
config ospf-interface
edit "pri_HQ2"
set interface "pri_HQ2"
set cost 10
set network-type point-to-point
next
edit "sec_HQ2"
set interface "sec_HQ2"
set cost 20
set network-type point-to-point
next
end
config network
edit 1
set prefix 10.10.10.0 255.255.255.0
next
edit 2
set prefix 10.10.11.0 255.255.255.0
next
edit 3
set prefix 10.1.100.0 255.255.255.0
next
end
end
b. Configure HQ2.
config router ospf
set router-id 2.2.2.2
config area
edit 0.0.0.0
next
end
config ospf-interface
edit "pri_HQ1"
set interface "pri_HQ1"
set cost 10
set network-type point-to-point
next
edit "sec_HQ1"
set interface "sec_HQ1"
set cost 20
set network-type point-to-point
next
end
config network
edit 1
set prefix 10.10.10.0 255.255.255.0
next
edit 2
set prefix 10.10.11.0 255.255.255.0
next
edit 3
set prefix 172.16.101.0 255.255.255.0
next
end
end
To check VPN and OSPF states using diagnose and get commands:
1. Run the HQ1 # diagnose vpn ike gateway list command. The system should return the following:
vd: root/0
name: pri_HQ2
version: 1
interface: port1 11
addr: 172.16.200.1:500 -> 172.16.202.1:500
virtual-interface-addr: 10.10.10.1 -> 10.10.10.2
created: 1024s ago
IKE SA: created 1/1 established 1/1 time 0/0/0 ms
IPsec SA: created 1/3 established 1/2 time 0/5/10 ms
id/spi: 45 d184777257b4e692/e2432f834aaf5658 direction: responder status: established
1024-1024s ago = 0ms proposal: aes128-sha256 key: 9ed41fb06c983344-
189538046f5ad204 lifetime/rekey: 86400/85105 DPD sent/recv: 00000003/00000000
vd: root/0
name: sec_HQ2
version: 1
interface: port2 12
addr: 172.17.200.1:500 -> 172.17.202.1:500
virtual-interface-addr: 10.10.11.1 -> 10.10.11.2
created: 346s ago
IKE SA: created 1/1 established 1/1 time 0/0/0 ms
IPsec SA: created 1/1 established 1/1 time 0/10/15 ms
id/spi: 48 d909ed68636b1ea5/163015e73ea050b8 direction: initiator status: established
0-0s ago = 0ms proposal: aes128-sha256 key: b9e93c156bdf4562-29db9fbafa256152
lifetime/rekey: 86400/86099 DPD sent/recv: 00000000/00000000
2. Run the HQ1 # diagnose vpn tunnel list command. The system should return the following:
list all ipsec tunnel in vd 0
name=pri_HQ2 ver=1 serial=1 172.16.200.1:0->172.16.202.1:0
You can configure IPsec VPN in an HA environment using the GUI or CLI.
In this example, the VPN name for HQ1 is "to_HQ2", and the VPN name for HQ2 is "to_HQ1".
1. Configure HA. In this example, two FortiGates work in active-passive mode. The HA heartbeat interfaces are WAN1
and WAN2:
config system ha
set group-name "FGT-HA"
set mode a-p
set password sample
set hbdev "wan1" 50 "wan2" 50
set session-pickup enable
set priority 200
set override-wait-time 10
end
2. Configure the WAN interface and default route. The WAN interface is the interface connected to the ISP. It can work
in static mode (as shown in this example), DHCP, or PPPoE mode. The IPsec tunnel is established over the
WAN interface.
a. Configure HQ1:
config system interface
edit "port1"
set vdom "root"
set ip 172.16.200.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.200.3
set device "port1"
next
end
b. Configure HQ2:
config system interface
edit "port25"
set vdom "root"
set ip 172.16.202.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.202.2
set device "port25"
next
end
3. Configure the internal (protected subnet) interface. The internal interface connects to the corporate internal
network. Traffic from this interface routes out the IPsec VPN tunnel.
a. Configure HQ1:
config system interface
edit "dmz"
set vdom "root"
6. Configure static routes. Two static routes are added to reach the remote protected subnet. The blackhole route is
important to ensure IPsec traffic does not match the default route when the IPsec tunnel is down.
a. Configure HQ1:
config router static
edit 2
set dst 172.16.101.0 255.255.255.0
set device "to_HQ2"
next
edit 3
set dst 172.16.101.0 255.255.255.0
set blackhole enable
set distance 254
next
end
b. Configure HQ2:
config router static
edit 2
set dst 10.1.100.0 255.255.255.0
set device "to_HQ1"
next
edit 3
set dst 10.1.100.0 255.255.255.0
set blackhole enable
set distance 254
next
end
7. Configure two firewall policies to allow bi-directional IPsec traffic flow over the IPsec tunnel:
a. Configure HQ1:
config firewall policy
edit 1
set name "inbound"
set srcintf "to_HQ2"
set dstintf "dmz"
set srcaddr "172.16.101.0"
set dstaddr "10.1.100.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "outbound"
set srcintf "dmz"
set dstintf "to_HQ2"
set srcaddr "10.1.100.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
end
b. Configure HQ2:
config firewall policy
edit 1
set name "inbound"
set srcintf "to_HQ1"
This is a sample configuration of a multiple site-to-site IPsec VPN that uses an IPsec aggregate interface to set up
redundancy and traffic load-balancing. The VPN tunnel interfaces must have net-device disabled in order to be
members of the IPsec aggregate.
Each FortiGate has two WAN interfaces connected to different ISPs. OSPF runs over the IPsec aggregate in this
configuration.
The supported load balancing algorithms are: L3, L4, round-robin (default), weighted round-robin, and redundant. The
first four options allow traffic to be load-balanced, while the last option (redundant) uses the first tunnel that is up for all
traffic.
Dynamic routing can run on the aggregate interface, and it can be a member interface in SD-WAN (not shown in this
configuration).
Phase 1
IP Address 172.16.202.1
Interface port1
IKE Mode Aggressive
Phase 2
Auto-negotiate Enable
Phase 1
IP Address 172.17.202.1
Interface port2
IKE Mode Aggressive
Phase 2
Auto-negotiate Enable
1. Go to VPN > IPsec Tunnels and click Create New > IPsec Aggregate.
2. For Name, enter agg_HQ2.
3. Select a load balancing algorithm.
4. From the Tunnel dropdown, select the tunnels that you created previously (pri_HQ2 and sec_HQ2). If required,
enter weights for each tunnel.
5. Click OK.
Name inbound
Source 172.16.101.0
Destination 10.1.100.0
Schedule always
Action ACCEPT
Service ALL
3. Click OK.
4. Create an outbound traffic policy with the following settings:
Name outbound
Source 10.1.100.0
Destination 172.16.101.0
Schedule always
Action ACCEPT
Service ALL
To configure OSPF:
1. Go to Network > OSPF.
2. For Router ID, enter 1.1.1.1.
3. In the Areas table, click Create New.
a. For Area ID, enter 0.0.0.0.
b. Click OK.
4. In the Networks table, click Create New.
a. Set the Area to 0.0.0.0.
b. For IP/Netmask, enter 10.1.100.0/24.
c. Click OK.
d. Click Create New.
e. For IP/Netmask, enter 10.10.10.0/24.
f. Click OK.
5. Click Apply.
Phase 1
IP Address 172.16.200.1
Interface port25
IKE Mode Aggressive
Phase 2
Auto-negotiate Enable
Phase 1
IP Address 172.17.200.1
Interface port26
IKE Mode Aggressive
Phase 2
Auto-negotiate Enable
1. Go to VPN > IPsec Tunnels and click Create New > IPsec Aggregate.
2. For Name, enter agg_HQ1.
3. Select a load balancing algorithm.
4. From the Tunnel dropdown, select the tunnels that you created previously (pri_HQ1 and sec_HQ1). If required,
enter weights for each tunnel.
5. Click OK.
Name inbound
Source 10.1.100.0
Destination 172.16.101.0
Schedule always
Action ACCEPT
Service ALL
3. Click OK.
4. Create an outbound traffic policy with the following settings:
Name outbound
Source 172.16.101.0
Destination 10.1.100.0
Schedule always
Action ACCEPT
Service ALL
To configure OSPF:
1. Go to Network > OSPF.
2. For Router ID, enter 2.2.2.2.
3. In the Areas table, click Create New.
a. For Area ID, enter 0.0.0.0.
b. Click OK.
4. In the Networks table, click Create New.
a. Set the Area to 0.0.0.0.
b. For IP/Netmask, enter 172.16.101.0/24.
c. Click OK.
d. Click Create New.
e. For IP/Netmask, enter 10.10.10.0/24.
f. Click OK.
5. Click Apply.
1. Go to Dashboard > Network , hover over the IPsec widget, then click Expand to Full Screen.
2. Expand the aggregate tunnel in the table to view statistics for each aggregate member.
To configure OSPF:
To configure OSPF:
For example, a customer has two ISP connections, wan1 and wan2. On each FortiGate, two IPsec VPN interfaces are
created. Next, an ipsec-aggregate interface is created and added as an SD-WAN member.
Configuring FortiGate 1
To configure SD-WAN:
Configuring FortiGate 2
next
edit "vd2-p2"
set phase1name "vd2-p2"
next
end
To configure SD-WAN:
A redundant hub and spoke configuration allows VPN connections to radiate from a central FortiGate unit (the hub) to
multiple remote peers (the spokes). Traffic can pass between private networks behind the hub and private networks
behind the remote peers. Traffic can also pass between remote peer private networks through the hub.
This is a sample configuration of hub and spoke IPsec VPN. The following applies for this scenario:
l The spokes have two WAN interfaces and two IPsec VPN tunnels for redundancy.
l The secondary VPN tunnel is up only when the primary tunnel is down by dead peer detection.
Because the GUI can only complete part of the configuration, we recommend using the CLI.
To configure redundant hub and spoke VPN using the FortiOS CLI:
end
config vpn ipsec phase2-interface
edit "hub"
set phase1name "hub"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
next
end
c. Configure the firewall policy.
config firewall policy
edit 1
set name "spoke-hub"
set srcintf "hub"
set dstintf "port9"
set srcaddr "all"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "spoke-spoke"
set srcintf "hub"
set dstintf "hub"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
end
2. Configure the spokes.
a. Configure the WAN, internal interface, and static route.
i. Configure Spoke1.
config system interface
edit "port1"
set ip 172.16.200.1 255.255.255.0
next
edit "wan1"
set mode dhcp
set distance 10
set priority 100
next
edit "dmz"
set ip 10.1.100.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.200.2
set device "port1"
next
end
ii. Configure Spoke2.
config system interface
edit "wan1"
edit "primary"
set interface "wan1"
set peertype any
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.16.202.1
set psksecret sample
next
edit "secondary"
set interface "wan2"
set peertype any
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.16.202.1
set monitor "primary"
set psksecret sample
next
end
config vpn ipsec phase2-interface
edit "primary"
set phase1name "primary"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
set src-subnet 192.168.4.0 255.255.255.0
next
edit "secondary"
set phase1name "secondary"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
set src-subnet 192.168.4.0 255.255.255.0
next
end
c. Configure the firewall policy.
i. Configure Spoke1.
config firewall policy
edit 1
set srcintf "dmz"
set dstintf "primary" "secondary"
set srcaddr "10.1.100.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
end
ii. Configure Spoke2.
config firewall policy
edit 1
set srcintf "lan1"
set dstintf "primary" "secondary"
set srcaddr "192.168.4.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
A weighted round robin algorithm can be used for IPsec aggregate tunnels to distribute traffic by the weight of each
member tunnel.
In this example, the FortiGate has two IPsec tunnels put into IPsec aggregate. Traffic is distributed among the members,
with one third over tunnel1, and two thirds over tunnel2. To achieve this, the weighted round robin algorithm is selected,
tunnel1 is assigned a weight of 10, and tunnel2 is assigned a weight of 20.
1. Create the tunnel1 and tunnel2 custom IPsec tunnels. Ensure that Aggregate member is Enabled for each tunnel.
2. Go to VPN > IPsec Tunnels and click Create New > IPsec Aggregate.
3. Enter a name for the aggregate, such as agg1, and ensure that Algorithm is Weighted Round Robin.
4. Add tunnel1 as an aggregate members, and set Weight to 10.
5. Add tunnel2 as a second aggregate members, and set its Weight to 20.
6. Click OK.
7. To view and monitor the aggregate tunnel statistics, go to the IPsec widget on the Network dashboard.
1. Create the tunnel1 and tunnel2 custom IPsec tunnels with aggregate-member enabled and aggregate-weight set
for both tunnels:
config vpn ipsec phase1-interface
edit "tunnel1"
...
set aggregate-member enable
set aggregate-weight 10
...
next
edit "tunnel2"
...
set aggregate-member enable
set aggregate-weight 20
...
next
end
Overlay Controller VPN (OCVPN) is a cloud based solution to simplify IPsec VPN setup. When OCVPN is enabled,
IPsec phase1-interfaces, phase2-interfaces, static routes, and firewall policies are generated automatically on all
FortiGates that belong to the same community network. A community network is defined as all FortiGates registered to
FortiCare using the same FortiCare account.
If the network topology changes on any FortiGates in the community (such as changing a public IP address in DHCP
mode, adding or removing protected subnets, failing over in dual WAN), the IPsec-related configuration for all devices is
updated with Cloud assistance in self-learning mode. No intervention is required.
The following topics provide instructions on configuring OCVPN:
l Full mesh OCVPN on page 1444
l Hub-spoke OCVPN with ADVPN shortcut on page 1449
l Hub-spoke OCVPN with inter-overlay source NAT on page 1453
l OCVPN portal on page 1457
l SD-WAN integration with OCVPN on page 701
l Allow FortiClient to join OCVPN on page 1458
l Troubleshooting OCVPN on page 1462
This example shows how to configure a full mesh Overlay Controller VPN (OCVPN), establishing full mesh IPsec tunnels
between all of the FortiGates.
License
l Free license: Three devices full mesh, 10 overlays, 16 subnets per overlay.
l Full License: Maximum of 16 devices, 10 overlays, 16 subnets per overlay.
Prerequisites
l All FortiGates must be running FortiOS 6.2.0 or later.
l All FortiGates must have Internet access.
l All FortiGates must be registered on FortiCare using the same FortiCare account.
Restrictions
l Non-root VDOMs do not support OCVPN.
l FortiOS 6.2.x is not compatible with FortiOS 6.0.x.
Terminology
Poll-interval How often FortiGate tries to fetch OCVPN-related data from OCVPN Cloud.
Subnet Internal network subnet (IPsec protected subnet). Traffic to or from this subnet enters the
IPsec tunnel encrypted by IPsec SA.
Sample topology
The following example shows three FortiGate units registered on FortiCare using the same FortiCare account. Each
FortiGate unit has one internal subnet, and no NAT exists between the units.
Sample configuration
l Branch2:
l Overlay name: QA. Local interfaces: lan1
l Branch3:
l Overlay name: QA. Local subnets: 172.16.101.0/24
The overlay names on each device must be the same for local and remote selector pairs to be
negotiated.
4. Click OK.
1. Configure Branch1:
config vpn ocvpn
set status enable
set multipath disable
config overlays
edit 1
set name "QA"
config subnets
edit 1
set subnet 10.1.100.0 255.255.255.0
next
end
next
edit 2
set name "PM"
config subnets
edit 1
set subnet 10.2.100.0 255.255.255.0
next
end
next
end
end
2. Configure Branch2:
config vpn ocvpn
set status enable
set multipath disable
config overlays
edit 1
set name "QA"
config subnets
edit 1
set type interface
set interface "lan1"
next
end
next
edit 2
set name "PM"
config subnets
edit 1
set type interface
set interface "lan2"
next
end
next
end
end
3. Configure Branch3:
config vpn ocvpn
set status enable
set multipath disable
config overlays
edit 1
set name "QA"
config subnets
edit 1
set subnet 172.16.101.0 255.255.255.0
next
end
next
edit 1
set name "PM"
config subnets
edit 1
set subnet 172.16.102.0 255.255.255.0
next
end
next
end
end
This topic shows a sample configuration of a hub-spoke One-Click VPN (OCVPN) with an Auto Discovery VPN (ADVPN)
shortcut. OCVPN automatically detects the network topology based on members' information. To form a hub-spoke
OCVPN, at least one device must announce its role as the primary hub, another device can work as the secondary hub
(for redundancy), while others function as spokes.
License
l Free license: Hub-spoke network topology not supported.
l Full license: Maximum of 2 hubs, 10 overlays, 64 subnets per overlay; 1024 spokes, 10 overlays, 16 subnets per
overlay.
Prerequisites
l All FortiGates must be running FortiOS 6.2.0 or later.
l All FortiGates must have Internet access.
l All FortiGates must be registered on FortiCare using the same FortiCare account.
Restrictions
l Non-root VDOMs do not support OCVPN.
l FortiOS 6.2.x is not compatible with FortiOS 6.0.x.
Sample topology
Sample configuration
The steps below use the following overlays and subnets for the sample configuration:
l Primary hub:
l Overlay name: QA. Local subnets: 172.16.101.0/24
l Secondary hub:
l Overlays are synced from primary hub.
l Spoke1:
l Overlay name: QA. Local subnets: 10.1.100.0/24
l Spoke2:
l Overlay name: QA. Local interfaces: lan1
The overlay names on each device must be the same for local and remote selector pairs to be
negotiated.
d. Specify the Name, Local subnets, and/or Local interfaces. Then click OK.
config overlays
edit 1
set name "QA"
config subnets
edit 1
set subnet 10.1.100.0 255.255.255.0
next
end
next
edit 2
set name "PM"
config subnets
edit 1
set subnet 10.2.100.0 255.255.255.0
next
end
next
end
end
This topic shows a sample configuration of hub-spoke OCVPN with inter-overlay source NAT. OCVPN isolates traffic
between overlays by default. With NAT enabled on spokes and assign-ip enabled on hub, you can have inter-overlay
communication.
Inter-overlay communication means devices from any source addresses and any source interfaces can communicate
with any devices in overlays' subnets when the overlay option assign-ip is enabled.
You must first disable auto-discovery before you can enable NAT.
License
l Free license: Hub-spoke network topology not supported.
l Full License: Maximum of 2 hubs, 10 overlays, 64 subnets per overlay; 1024 spokes, 10 overlays, 16 subnets per
overlay.
Prerequisites
l All FortiGates must be running FortiOS 6.2.0 or later.
l All FortiGates must have Internet access.
l All FortiGates must be registered on FortiCare using the same FortiCare account.
Restrictions
l Non-root VDOMs do not support OCVPN.
l FortiOS 6.2.x is not compatible with FortiOS 6.0.x.
Sample topology
Sample configuration
The overlay names on each device must be the same for local and remote selector pairs to be
negotiated.
1. Configure the primary hub, enable overlay QA, and configure assign-ip and IP range:
config vpn ocvpn
set status enable
set role primary-hub
config overlays
edit 1
set name "QA"
set assign-ip enable
set ipv4-start-ip 172.16.101.100
set ipv4-end-ip 172.16.101.200
config subnets
edit 1
set subnet 172.16.101.0 255.255.255.0
next
end
next
edit 2
set name "PM"
set assign-ip enable
config subnets
edit 1
set subnet 172.16.102.0 255.255.255.0
next
end
next
end
end
next
end
next
end
end
OCVPN portal
When you log into the OCVPN portal, the OCVPN license type and device information display. The device information
includes the device serial number, OCVPN role, hostname, public IP address, port number, and overlays.
You can unregister an OCVPN device from the OCVPN portal under Device on the right pane.
Administrators can configure remote access for FortiClient within an OCVPN hub. This provides simple configurations to
allow a user group access to an overlay network.
1. On the primary hub, configure the users and user groups required for the FortiClient dialup user authentication and
authorization. In this example, there are two user groups (dev_grp and qa_grp).
2. Go to VPN > Overlay Controller VPN and in the Overlays section, click Create New.
3. Enter a name and the local subnet (174.16.101.0/24 for dev and 22.202.2.0/24 for qa).
4. Enable FortiClient Access.
5. In the Access Rules section, click Create New.
6. Enter a name, and select the authentication groups and overlays.
The authentication groups will be used by the IPsec phase 1 interface for authentication, and by firewall policies for
authorization. The overlay allows access to the resource.
7. Click OK.
8. Create more rules if needed.
9. Click Apply.
config subnets
edit 1
set subnet 174.16.101.0 255.255.255.0
next
end
next
edit "qa"
config subnets
edit 1
set subnet 22.202.2.0 255.255.255.0
next
end
next
end
config forticlient-access
set status enable
set psksecret xxxxxxxxxxxx
config auth-groups
edit "dev"
set auth-group "dev_grp"
set overlays "dev"
next
edit "qa"
set auth-group "qa_grp"
set overlays "qa"
next
end
end
end
vd: root/0
name: _OCVPN_FCT0_0
version: 1
interface: mgmt1 4
addr: 172.16.200.4:4500 -> 172.16.200.15:64916
created: 110s ago
xauth-user: usera
groups:
dev_grp 1
assigned IPv4 address: 10.254.128.1/255.255.255.255
nat: peer
IKE SA: created 1/1 established 1/1 time 20/20/20 ms
IPsec SA: created 1/1 established 1/1 time 0/0/0 ms
id/spi: 72 1ccd2abf2d981123/fd8da107f9e4d312
direction: responder
status: established 110-110s ago = 20ms
proposal: aes256-sha256
key: 105a0291b0c05219-3decdf78938a7bea-78943651e1720536-625114d66e46f668
lifetime/rekey: 86400/86019
DPD sent/recv: 00000000/00000af3
The PC can access the dev resource overlay, but not qa:
C:\Users\tester>ping 174.16.101.44
C:\Users\tester>ping 22.202.2.2
Troubleshooting OCVPN
This document includes troubleshooting steps for the following OCVPN network topologies:
l Full mesh OCVPN.
l Hub-spoke OCVPN with ADVPN shortcut.
l Hub-spoke OCVPN with inter-overlay source NAT.
For OCVPN configurations in other network topologies, see the other OCVPN topics.
l Generate traffic from spoke1 to spoke2 to trigger the ADVPN shortcut and check the VPN tunnel and routing-table
again on spoke1.
branch1 # diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=_OCVPN2-0.0_0 ver=2 serial=a 172.16.200.1:0->172.16.200.3:0 dst_mtu=1500
bound_if=11 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/720 options
[02d0]=create_dev no-sysctl rgwy-chg frag-rfc accept_traffic=1
parent=_OCVPN2-0.0 index=0
proxyid_num=1 child_num=0 refcnt=14 ilast=0 olast=0 ad=r/2
stat: rxp=7 txp=7 rxb=1064 txb=588
dpd: mode=on-idle on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=_OCVPN2-0.0 proto=0 sa=1 ref=2 serial=1 auto-negotiate add-route adr
src: 0:10.1.100.0-10.1.100.255:0
dst: 0:192.168.4.0-192.168.4.255:0
SA: ref=3 options=1a227 type=00 soft=0 mtu=1438 expire=43180/0B replaywin=2048
seqno=8 esn=0 replaywin_lastseq=00000008 itn=0 qat=0
life: type=01 bytes=0/0 timeout=43187/43200
dec: spi=048477c9 esp=aes key=16 27c35d53793013ef24cf887561e9f313
ah=sha1 key=20 2c8cfd328c3b29104db0ca74a00c6063f46cafe4
enc: spi=fb9e13fd esp=aes key=16 9d0d3bf6c84b7ddaf9d9196fe74002ed
ah=sha1 key=20 d1f541db787dea384c6a4df16fc228abeb7ae334
dec:pkts/bytes=7/588, enc:pkts/bytes=7/1064
------------------------------------------------------
name=_OCVPN2-0.0 ver=2 serial=6 172.16.200.1:0->172.16.200.4:0 dst_mtu=1500
bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_dev
frag-rfc accept_traffic=1
frag-rfc accept_traffic=0
l Simulate the primary hub being unavailable where all spokes' dialup VPN tunnels will switch to the secondary hub,
to check VPN tunnel status and routing-table.
list all ipsec tunnel in vd 0
------------------------------------------------------
name=_OCVPN2-0.0 ver=2 serial=6 172.16.200.1:0->172.16.200.4:0 dst_mtu=1500
bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_dev
frag-rfc accept_traffic=0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=3 options=1a227 type=00 soft=0 mtu=1438 expire=42723/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000000 itn=0 qat=0
life: type=01 bytes=0/0 timeout=42898/43200
dec: spi=048477cd esp=aes key=16 9bb363a32378b5897cd42890c92df811
ah=sha1 key=20 2ed40583b9544e37867349b4adc7c013024d7e17
enc: spi=f345fb42 esp=aes key=16 3ea31dff3310b245700a131db4565851
ah=sha1 key=20 522862dfb232514b845e436133b148da0e67b7c4
dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
------------------------------------------------------
name=_OCVPN2-0.1 ver=2 serial=5 172.16.200.1:0->172.16.200.4:0 dst_mtu=1500
bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_dev
frag-rfc accept_traffic=0
------------------------------------------------------
name=_OCVPN2-0.1 ver=2 serial=b 172.16.200.1:0->172.16.200.4:0 dst_mtu=1500
bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_dev
frag-rfc accept_traffic=1
edit 9
set name "_OCVPN2-1.1_nat"
set uuid 3f7a84b8-3d36-51e9-ee97-8f418c91e666
set srcintf "any"
set dstintf "_OCVPN2-1.1"
set srcaddr "all"
set dstaddr "_OCVPN2-1.1_remote_networks"
set action accept
set schedule "always"
set service "ALL"
set comments "Generated by OCVPN Cloud Service."
set nat enable
next
edit 12
set name "_OCVPN2-1.0_nat"
set uuid 3fafec98-3d36-51e9-80c0-5d99325bad83
set srcintf "any"
set dstintf "_OCVPN2-1.0"
set srcaddr "all"
set dstaddr "_OCVPN2-1.0_remote_networks"
set action accept
set schedule "always"
set service "ALL"
set comments "Generated by OCVPN Cloud Service."
set nat enable
next
.................................
ADVPN
Auto-Discovery VPN (ADVPN) allows the central hub to dynamically inform spokes about a better path for traffic
between two spokes.
The following topics provide instructions on configuring ADVPN:
l IPsec VPN wizard hub-and-spoke ADVPN support on page 1475
l ADVPN with BGP as the routing protocol on page 1479
l ADVPN with OSPF as the routing protocol on page 1488
l ADVPN with RIP as the routing protocol on page 1497
l UDP hole punching for spokes behind NAT on page 1506
When using the IPsec VPN wizard to create a hub and spoke VPN, multiple local interfaces can be selected. At the end
of the wizard, changes can be reviewed, real-time updates can be made to the local address group and tunnel interface,
and easy configuration keys can be copied for configuring the spokes.
When editing a VPN tunnel, the Hub & Spoke Topology section provides access to the easy configuration keys for the
spokes, and allows you to add more spokes.
This example shows the configuration of a hub with two spokes.
Name hub
Role Hub
b. Authentication:
c. Tunnel Interface:
Tunnel IP 10.10.1.1
Local AS 65400
e. Review Settings:
Confirm that the settings look correct, then click Create.
3. The summary shows details about the set up hub:
l The Local address group and Tunnel interface can be edited directly on this page.
l Spoke easy configuration keys can be used to quickly configure the spokes.
Name spoke1
Role Spoke
3. In the Easy configuration key field, paste the Spoke #1 key from the hub FortiGate, click Apply, then click Next.
4. Adjust the Authentication settings as required, enter the Pre-shared key, then click Next.
5. Adjust the Tunnel Interface settings as required, then click Next.
6. Configure the Policy & Routing settings, then click Next:
1. On the hub FortiGate, go to Dashboard > Network and expand the IPsec widget.
The tunnels to the spokes are established.
This is a sample configuration of ADVPN with BGP as the routing protocol. The following options must be enabled for
this configuration:
l On the hub FortiGate, IPsec phase1-interface net-device disable must be run.
l IBGP must be used between the hub and spoke FortiGates.
l bgp neighbor-group/neighbor-range must be reused.
Because the GUI can only complete part of the configuration, we recommend using the CLI.
To configure ADVPN with BGP as the routing protocol using the CLI:
next
end
end
config network
edit 1
set prefix 192.168.4.0 255.255.255.0
next
end
end
4. Run diagnose and get commands run on Spoke1 to check VPN and BGP states.
a. Run the diagnose vpn tunnel list command on Spoke1. The system should return the following:
list all ipsec tunnel in vd 0
----
name=spoke1 ver=1 serial=2 15.1.1.2:0->22.1.1.1:0
bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/536 options[0218]=npu
create_dev frag-rfc accept_traffic=1
b. Run the get router info bgp summary command on Spoke1. The system should return the following:
BGP router identifier 7.7.7.7, local AS number 65412
BGP table version is 2
1 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS [[QualityAssurance62/MsgRcvd]]
[[QualityAssurance62/MsgSent]] [[QualityAssurance62/TblVer]] InQ OutQ Up/Down
State/PfxRcd
10.10.10.254 1. 65412 143 142 1. 1. 1.
00:24:45 2
c. Run the get router info routing-table bgp command on Spoke1. The system should return the
following:
Routing table for VRF=0
B 172.16.101.0/24 [200/0] via 10.10.10.254, spoke1, 00:23:57
B 192.168.4.0/24 [200/0] via 10.10.10.254, spoke1, 00:22:03
d. Generate traffic between the spokes and check the shortcut tunnel and routing table. Run the diagnose vpn
tunnel list command on Spoke1. The system should return the following:
list all ipsec tunnel in vd 0
----
name=spoke1 ver=1 serial=2 15.1.1.2:0->22.1.1.1:0
bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/536 options[0218]=npu
create_dev frag-rfc accept_traffic=1
parent=spoke1 index=0
proxyid_num=1 child_num=0 refcnt=17 ilast=4 olast=4 ad=r/2
stat: rxp=1 txp=100 rxb=112 txb=4686
dpd: mode=on-idle on=1 idle=5000ms retry=3 count=0 seqno=231
natt: mode=keepalive draft=32 interval=10 remote_port=4500
e. Run the get router info routing-tale bgp command. The system should return the following:
Routing table for VRF=0
B 172.16.101.0/24 [200/0] via 10.10.10.254, spoke1, 00:23:57
B 192.168.4.0/24 [200/0] via 10.10.10.3, spoke1_0 , 00:22:03
This is a sample configuration of ADVPN with OSPF as the routing protocol. The following options must be enabled for
this configuration:
l On the hub FortiGate, IPsec phase1-interface net-device enable must be run.
l OSPF must be used between the hub and spoke FortiGates.
Because the GUI can only complete part of the configuration, we recommend using the CLI.
To configure ADVPN with OSPF as the routing protocol using the CLI:
set dpd-retryinterval 5
next
end
config vpn ipsec phase2-interface
edit "spoke1"
set phase1name "spoke1"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256
aes128gcm aes256gcm chacha20poly1305
set auto-negotiate enable
next
edit "spoke1_backup"
set phase1name "spoke1_backup"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256
aes128gcm aes256gcm chacha20poly1305
set auto-negotiate enable
next
end
4. Run diagnose and get commands on Spoke1 to check VPN and OSPF states.
a. Run the diagnose vpn tunnel list command on Spoke1. The system should return the following:
list all ipsec tunnel in vd 0
----
name=spoke1 ver=1 serial=2 15.1.1.2:0->22.1.1.1:0
bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/536 options[0218]=npu
create_dev frag-rfc accept_traffic=1
b. Run the get router info ospf neighbor command on Spoke1. The system should return the following:
OSPF process 0, VRF 0: Neighbor ID Pri State Dead Time Address Interface 8.8.8.8 1.
Full/ - 00:00:35 10.10.10.254 spoke1 1.1.1.1 1. Full/ - 00:00:35 10.10.10.254 spoke1
c. Run the get router info routing-table ospf command on Spoke1. The system should return the
following:
Routing table for VRF=0
O 172.16.101.0/24 [110/110] via 10.10.10.254, spoke1, 00:23:23
O 192.168.4.0/24 [110/110] via 10.10.10.254, spoke1, 00:22:35
d. Generate traffic between the spokes, then check the shortcut tunnel and routing table. Run the diagnose
vpn tunnel list command on Spoke1. The system should return the following:
parent=spoke1 index=0
proxyid_num=1 child_num=0 refcnt=19 ilast=4 olast=2 ad=r/2
stat: rxp=641 txp=1254 rxb=278648 txb=161536
dpd: mode=on-idle on=1 idle=5000ms retry=3 count=0 seqno=184
natt: mode=keepalive draft=32 interval=10 remote_port=4500
proxyid=spoke1_backup proto=0 sa=1 ref=10 serial=1 auto-negotiate adr
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=6 options=1a227 type=00 soft=0 mtu=1422 expire=922/0B replaywin=1024
seqno=452 esn=0 replaywin_lastseq=00000280 itn=0
life: type=01 bytes=0/0 timeout=2370/2400
dec: spi=c53a8f79 esp=aes key=16 324f8cf840ba6722cc7abbba46b34e0e
ah=sha1 key=20 a40e9aac596b95c4cd83a7f6372916a5ef5aa505
enc: spi=ef3327b5 esp=aes key=16 5909d6066b303de4520d2b5ae2db1b61
ah=sha1 key=20 1a42f5625b5a335d8d5282fe83b5d6c6ff26b2a4
dec:pkts/bytes=641/278568, enc:pkts/bytes=1254/178586
npu_flag=03 npu_rgwy=13.1.1.2 npu_lgwy=15.1.1.2 npu_selid=a dec_npuid=1 enc_npuid=1
e. Run the get router info routing-tale ospf command. The system should return the following:
Routing table for VRF=0
O 172.16.101.0/24 [110/110] via 10.10.10.254, spoke1, 00:27:14
O 192.168.4.0/24 [110/110] via 10.10.10.3, spoke1_0, 00:26:26
This is a sample configuration of ADVPN with RIP as routing protocol. The following options must be enabled for this
configuration:
l On the hub FortiGate, IPsec phase1-interface net-device disable must be run.
l RIP must be used between the hub and spoke FortiGates.
l split-horizon-status enable must be run on the hub FortiGate.
Because the GUI can only complete part of the configuration, we recommend using the CLI.
To configure ADVPN with RIP as the routing protocol using the CLI:
1. In the CLI, configure hub FortiGate's WAN, internal interface, and static route.
config system interface
edit "port9"
set alias "WAN"
set ip 22.1.1.1 255.255.255.0
next
edit "port10"
set alias "Internal"
set ip 172.16.101.1 255.255.255.0
next
end
config router static
edit 1
set gateway 22.1.1.2
set device "port9"
next
end
next
end
b. Run the get router info rip database command on Spoke1. The system should return the following:
Codes: R - RIP, Rc - RIP connected, Rs - RIP static, K - Kernel,
C - Connected, S - Static, O - OSPF, I - IS-IS, B - BGP
c. Run the get router info routing-table rip command on Spoke1. The system should return the
following:
Routing table for VRF=0
R 172.16.101.0/24 [120/2] via 10.10.10.254, spoke1, 00:08:38
R 192.168.4.0/24 [120/3] via 10.10.10.254, spoke1, 00:08:38
d. Generate traffic between the spokes, then check the shortcut tunnel and routing table. Run the diagnose
vpn tunnel list command on Spoke1. The system should return the following:
list all ipsec tunnel in vd 0
----
name=spoke1 ver=1 serial=2 15.1.1.2:0->22.1.1.1:0
bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/536 options[0218]=npu
parent=spoke1 index=0
proxyid_num=1 child_num=0 refcnt=20 ilast=2 olast=0 ad=r/2
stat: rxp=1 txp=7 rxb=112 txb=480
dpd: mode=on-idle on=1 idle=5000ms retry=3 count=0 seqno=0
natt: mode=keepalive draft=32 interval=10 remote_port=4500
proxyid=spoke1 proto=0 sa=1 ref=8 serial=1 auto-negotiate adr
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=6 options=1a227 type=00 soft=0 mtu=1422 expire=2358/0B replaywin=1024
seqno=8 esn=0 replaywin_lastseq=00000002 itn=0
life: type=01 bytes=0/0 timeout=2367/2400
dec: spi=c53a8f61 esp=aes key=16 c66aa7ae9657068108ed47c048ff56b6
ah=sha1 key=20 60661c68e20bbc913c2564ade85e01ea3769e703
enc: spi=79cb0f30 esp=aes key=16 bf6c898c2e1c64baaa679ed5d79c3b58
ah=sha1 key=20 146ca78be6c34eedb9cd66cc328216e08682ecb1
dec:pkts/bytes=1/46, enc:pkts/bytes=7/992
npu_flag=03 npu_rgwy=13.1.1.2 npu_lgwy=15.1.1.2 npu_selid=6 dec_npuid=1 enc_npuid=1
e. Run the get router info routing-tale rip command. The system should return the following:
UDP hole punching allows ADVPN shortcuts to be established through a UDP hole on a NAT device. The NAT device
must support RFC 4787 Endpoint-Independent Mapping.
In the following example, device 10.1.100.11 behind Spoke1 needs to reach device 192.168.4.33 behind Spoke2.
Spoke1 and Spoke2 are behind NAT devices and have established IPsec tunnels to the Hub. The hole punching creates
a shortcut between Spoke1 and Spoke2 that bypasses the Hub.
To verify the ADVPN shortcut is established between both spokes behind NAT:
id/spi: 35 3c10fb6a76f1e264/6c7b397100dffc63
direction: initiator
status: established 503-503s ago = 0ms
proposal: aes128-sha256
key: 7fca86063ea2e72f-4efea6f1bec23948
lifetime/rekey: 86400/85596
DPD sent/recv: 00000000/00000000
vd: root/0
name: toHub1_0
version: 1
interface: wan2 6
addr: 12.1.1.2:4500 -> 55.1.1.2:64916
created: 208s ago
nat: me peer
auto-discovery: 2 receiver
IKE SA: created 1/1 established 1/1 time 20/20/20 ms
IPsec SA: created 1/1 established 1/1 time 10/10/10 ms
id/spi: 48 d3fdd1bfbc94caee/16a1eb5b0f37ee23
direction: initiator
status: established 208-208s ago = 20ms
proposal: aes128-sha256
key: 9bcac400d8e14e11-fffde33eaa3a8263
lifetime/rekey: 86400/85891
DPD sent/recv: 0000000a/00000000
1. Check the device ASIC information. For example, a FortiGate 900D has an NP6 and a CP8.
# get hardware status
Model name: [[QualityAssurance62/FortiGate]]-900D
ASIC version: CP8
ASIC SRAM: 64M
CPU: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz
Number of CPUs: 4
RAM: 16065 MB
Compact Flash: 1925 MB /dev/sda
Hard disk: 244198 MB /dev/sdb
USB Flash: not available
Network Card chipset: [[QualityAssurance62/FortiASIC]] NP6 Adapter (rev.)
1. port24 1G Yes
1. port27 1G Yes
1. port28 1G Yes
1. port25 1G Yes
1. port26 1G Yes
1. port31 1G Yes
1. port32 1G Yes
1. port29 1G Yes
1. port30 1G Yes
1. portB 10G Yes
1.
----
np6_1 0
1. port1 1G Yes
1. port2 1G Yes
1. port3 1G Yes
1. port4 1G Yes
1. port5 1G Yes
1. port6 1G Yes
1. port7 1G Yes
1. port8 1G Yes
1. port11 1G Yes
1. port12 1G Yes
1. port9 1G Yes
1. port10 1G Yes
1. port15 1G Yes
1. port16 1G Yes
1. port13 1G Yes
1. port14 1G Yes
1. portA 10G Yes
1.
----
3. Configure the option in IPsec phase1 settings to control NPU encrypt/decrypt IPsec packets (enabled by default).
config vpn ipsec phase1/phase1-interface
edit "vpn_name"
set npu-offload enable/disable
next
end
4. Check NPU offloading. The NPU encrypted/decrypted counter should tick. The npu_flag 03 flag means that the
traffic processed by the NPU is bi-directional.
# diagnose vpn tunnel list
list all ipsec tunnel in vd 0
----
name=test ver=2 serial=1 173.1.1.1:0->11.101.1.1:0
bound_if=42 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=14 ilast=2 olast=2 ad=/0
stat: rxp=12231 txp=12617 rxb=1316052 txb=674314
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=test proto=0 sa=1 ref=4 serial=7
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=6 options=10626 type=00 soft=0 mtu=1438 expire=42921/0B replaywin=2048
NP6_1:
Encryption (encrypted/decrypted)
null : 14976 15357
des : 0 1.
3des : 0 1.
aes : 1664 2047
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 1664 2047
sha1 : 14976 15357
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 3 1.
sha1 : 3 1.
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
CP8:
Encryption (encrypted/decrypted)
null : 1 1.
des : 0 1.
3des : 0 1.
aes : 1 1.
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 1 1.
sha1 : 1 1.
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
SOFTWARE:
Encryption (encrypted/decrypted)
null : 0 1.
des : 0 1.
3des : 0 1.
aes : 0 1.
aes-gcm : 29882 29882
aria : 21688 21688
seed : 153774 153774
chacha20poly1305 : 29521 29521
Integrity (generated/validated)
null : 59403 59403
md5 : 0 1.
sha1 : 175462 175462
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
5. If traffic cannot be offloaded by the NPU, the CP will try to encrypt/decrypt the IPsec packets.
NP6_1:
Encryption (encrypted/decrypted)
null : 14976 15357
des : 0 1.
3des : 0 1.
aes : 1664 2047
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 1664 2047
sha1 : 14976 15357
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
null : 3 1.
des : 0 1.
3des : 0 1.
aes : 3 1.
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 3 1.
sha1 : 3 1.
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
CP8:
Encryption (encrypted/decrypted)
null : 1 1.
des : 0 1.
3des : 0 1.
aes : 8499 8499
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 8499 8499
sha1 : 1 1.
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
SOFTWARE:
Encryption (encrypted/decrypted)
null : 0 1.
des : 0 1.
3des : 0 1.
aes : 0 1.
aes-gcm : 29882 29882
aria : 21688 21688
seed : 153774 153774
chacha20poly1305 : 29521 29521
Integrity (generated/validated)
null : 59403 59403
md5 : 0 1.
sha1 : 175462 175462
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
2. Two options are used to control if the CP processes packets. If disabled, packets are processed by the CPU.
config system global
set ipsec-asic-offload disable
IPsec traffic might be processed by the CPU for the following reasons:
l Some low end models do not have NPUs.
l NPU offloading and CP IPsec traffic processing manually disabled.
l Some types of proposals - SEED, ARIA, chacha20poly1305 - are not supported by the NPU or CP.
l NPU flag set to 00 and software encrypt/decrypt counter ticked.
# diagnose vpn tunnel list
list all ipsec tunnel in vd 0
----
name=test ver=2 serial=1 173.1.1.1:0->11.101.1.1:0
bound_if=42 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/0
proxyid_num=1 child_num=0 refcnt=14 ilast=0 olast=0 ad=/0
stat: rxp=12162 txp=12162 rxb=1691412 txb=1008216
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=test proto=0 sa=1 ref=4 serial=8
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
SA: ref=3 options=10602 type=00 soft=0 mtu=1453 expire=42903/0B replaywin=2048
seqno=2d70 esn=0 replaywin_lastseq=00002d70 itn=0
life: type=01 bytes=0/0 timeout=42931/43200
dec: spi=e313ac4d esp=chacha20poly1305 key=36
812d1178784c1130d1586606e44e1b9ab157e31a09edbed583be1e9cc82e8c9f2655a2cf
ah=null key=0
enc: spi=706ffe0a esp=chacha20poly1305 key=36
f2727e001e2243549b140f1614ae3df82243adb070e60c33911f461b389b05a7a642e11a
ah=null key=0
dec:pkts/bytes=11631/976356, enc:pkts/bytes=11631/1627692
npu_flag=00 npu_rgwy=11.101.1.1 npu_lgwy=173.1.1.1 npu_selid=7 dec_npuid=0 enc_npuid=0
NP6_1:
Encryption (encrypted/decrypted)
null : 14976 15357
des : 0 1.
3des : 0 1.
aes : 1664 2047
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 1664 2047
sha1 : 14976 15357
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
CP8:
Encryption (encrypted/decrypted)
null : 1 1.
des : 0 1.
3des : 0 1.
aes : 8865 8865
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 8865 8865
sha1 : 1 1.
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
SOFTWARE:
Encryption (encrypted/decrypted)
null : 0 1.
des : 0 1.
3des : 0 1.
aes : 531 531
aes-gcm : 29882 29882
aria : 21688 21688
seed : 153774 153774
chacha20poly1305 : 41156 41156
Integrity (generated/validated)
null : 71038 71038
md5 : 531 531
sha1 : 175462 175462
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
When auto-asic-offload is set to disable in the firewall policy, traffic is not offloaded and the NPU hosting counter
is ticked.
# diagnose vpn ipsec status
All ipsec crypto devices in use:
NP6_0:
Encryption (encrypted/decrypted)
null : 0 1.
des : 0 1.
3des : 0 1.
aes : 0 1.
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 0 1.
sha1 : 0 1.
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
NP6_1:
Encryption (encrypted/decrypted)
null : 14976 15357
des : 0 1.
3des : 0 1.
aes : 110080 2175
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 110080 2175
sha1 : 14976 15357
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
CP8:
Encryption (encrypted/decrypted)
null : 1 1.
des : 0 1.
3des : 0 1.
aes : 8865 8865
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 8865 8865
sha1 : 1 1.
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
SOFTWARE:
Encryption (encrypted/decrypted)
null : 0 1.
des : 0 1.
3des : 0 1.
aes : 539 539
aes-gcm : 29882 29882
aria : 21688 21688
seed : 153774 153774
chacha20poly1305 : 41259 41259
Integrity (generated/validated)
null : 71141 71141
md5 : 539 539
sha1 : 175462 175462
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
Encryption algorithms
This topic provides a brief introduction to IPsec phase 1 and phase 2 encryption algorithms and includes the following
sections:
l IKEv1 phase 1 encryption algorithm
l IKEv1 phase 2 encryption algorithm
l IKEv2 phase 1 encryption algorithm
l IKEv2 phase 2 encryption algorithm
l HMAC settings
DES is a symmetric-key algorithm, which means the same key is used for encrypting and decrypting data. FortiOS
supports:
l des-md5
l des-sha1
l des-sha256
l des-sha384
l des-sha512
3DES applies the DES algorithm three times to each data. FortiOS supports:
l 3des-md5
l 3des-sha1
l 3des-sha256
l 3des-sha384
l 3des-sha512
AES is a symmetric-key algorithm with different key lengths (128, 192, and 256 bits). FortiOS supports:
l aes128-md5
l aes128-sha1
l aes128-sha256
l aes128-sha384
l aes128-sha512
l aes192-md5
l aes192-sha1
l aes192-sha256
l aes192-sha384
l aes192-sha512
l aes256-md5
l aes256-sha1
l aes256-sha256
l aes256-sha384
l aes256-sha512
The ARIA algorithm is based on AES with different key lengths (128, 192, and 256 bits). FortiOS supports:
l aria128-md5
l aria128-sha1
l aria128-sha256
l aria128-sha384
l aria128-sha512
l aria192-md5
l aria192-sha1
l aria192-sha256
l aria192-sha384
l aria192-sha512
l aria256-md5
l aria256-sha1
l aria256-sha256
l aria256-sha384
l aria256-sha512
SEED is a symmetric-key algorithm. FortiOS supports:
l seed128-md5
l seed128-sha1
l seed128-sha256
l seed128-sha384
l seed128-sha512
Suite-B is a set of AES encryption with ICV in GCM mode. FortiOS supports Suite-B on new kernel platforms only. IPsec
traffic cannot offload to NPU. CP9 supports Suite-B offloading, otherwise packets are encrypted and decrypted by
software. FortiOS supports:
l suite-b-gcm-128
l suite-b-gcm-256
With null encryption, IPsec traffic can offload NPU/CP. FortiOS supports:
l null-md5
l null-sha1
l null-sha256
l null-sha384
l null-sha512
With the DES encryption algorithm, IPsec traffic can offload NPU/CP. FortiOS supports:
l des-null
l des-md5
l des-sha1
l des-sha256
l des-sha384
l des-sha512
With the 3DES encryption algorithm, IPsec traffic can offload NPU/CP. FortiOS supports:
l 3des-null
l 3des-md5
l 3des-sha1
l 3des-sha256
l 3des-sha384
l 3des-sha512
With the AES encryption algorithm, IPsec traffic can offload NPU/CP. FortiOS supports:
l aes128-null
l aes128-md5
l aes128-sha1
l aes128-sha256
l aes128-sha384
l aes128-sha512
l aes192-null
l aes192-md5
l aes192-sha1
l aes192-sha256
l aes192-sha384
l aes192-sha512
l aes256-null
l aes256-md5
l aes256-sha1
l aes256-sha256
l aes256-sha384
l aes256-sha512
With the AESGCM encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiOS supports:
l aes128gcm
l aes256gcm
With the chacha20poly1305 encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiOS supports:
l chacha20poly1305
With the ARIA encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiOS supports:
l aria128-null
l aria128-md5
l aria128-sha1
l aria128-sha256
l aria128-sha384
l aria128-sha512
l aria192-null
l aria192-md5
l aria192-sha1
l aria192-sha256
l aria192-sha384
l aria192-sha512
l aria256-null
l aria256-md5
l aria256-sha1
l aria256-sha256
l aria256-sha384
l aria256-sha512
With the SEED encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiOS supports:
l seed-null
l seed-md5
l seed-sha1
l seed-sha256
l seed-sha384
l seed-sha512
DES is a symmetric-key algorithm, which means the same key is used for encrypting and decrypting data. FortiOS
supports:
l des-md5
l des-sha1
l des-sha256
l des-sha384
l des-sha512
3DES applies the DES algorithm three times to each data. FortiOS supports:
l 3des-md5
l 3des-sha1
l 3des-sha256
l 3des-sha384
l 3des-sha512
AES is a symmetric-key algorithm with different key lengths (128, 192, and 256 bits). FortiOS supports:
l aes128-md5
l aes128-sha1
l aes128-sha256
l aes128-sha384
l aes128-sha512
l aes128gcm-prfsha1
l aes128gcm-prfsha256
l aes128gcm-prfsha384
l aes128gcm-prfsha512
l aes192-md5
l aes192-sha1
l aes192-sha256
l aes192-sha384
l aes192-sha512
l aes256-md5
l aes256-sha1
l aes256-sha256
l aes256-sha384
l aes256-sha512
l aes256gcm-prfsha1
l aes256gcm-prfsha256
l aes256gcm-prfsha384
l aes256gcm-prfsha512
The ARIA algorithm is based on AES with different key lengths (128, 192, and 256 bits). FortiOS supports:
l aria128-md5
l aria128-sha1
l aria128-sha256
l aria128-sha384
l aria128-sha512
l aria192-md5
l aria192-sha1
l aria192-sha256
l aria192-sha384
l aria192-sha512
l aria256-md5
l aria256-sha1
l aria256-sha256
l aria256-sha384
l aria256-sha512
With the chacha20poly1305 encryption algorithm, FortiOS supports:
l chacha20poly1305-prfsha1
l chacha20poly1305-prfsha256
l chacha20poly1305-prfsha384
l chacha20poly1305-prfsha512
SEED is a symmetric-key algorithm. FortiOS supports:
l seed128-md5
l seed128-sha1
l seed128-sha256
l seed128-sha384
l seed128-sha512
Suite-B is a set of AES encryption with ICV in GCM mode. FortiOS supports Suite-B on new kernel platforms only. IPsec
traffic cannot offload to NPU. CP9 supports Suite-B offloading, otherwise packets are encrypted and decrypted by
software. FortiOS supports:
l suite-b-gcm-128
l suite-b-gcm-256
With null encryption, IPsec traffic can offload NPU/CP. FortiOS supports:
l null-md5
l null-sha1
l null-sha256
l null-sha384
l null-sha512
With the DES encryption algorithm, IPsec traffic can offload NPU/CP. FortiOS supports:
l des-null
l des-md5
l des-sha1
l des-sha256
l des-sha384
l des-sha512
With the 3DES encryption algorithm, IPsec traffic can offload NPU/CP. FortiOS supports:
l 3des-null
l 3des-md5
l 3des-sha1
l 3des-sha256
l 3des-sha384
l 3des-sha512
With the AES encryption algorithm, IPsec traffic can offload NPU/CP. FortiOS supports:
l aes128-null
l aes128-md5
l aes128-sha1
l aes128-sha256
l aes128-sha384
l aes128-sha512
l aes192-null
l aes192-md5
l aes192-sha1
l aes192-sha256
l aes192-sha384
l aes192-sha512
l aes256-null
l aes256-md5
l aes256-sha1
l aes256-sha256
l aes256-sha384
l aes256-sha512
With the AESGCM encryption algorithm, IPsec traffic cannot offload NPU. CP9 supports AESGCM offloading. FortiOS
supports:
l aes128gcm
l aes256gcm
With the chacha20poly1305 encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiOS supports:
l chacha20poly1305
With the ARIA encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiOS supports:
l aria128-null
l aria128-md5
l aria128-sha1
l aria128-sha256
l aria128-sha384
l aria128-sha512
l aria192-null
l aria192-md5
l aria192-sha1
l aria192-sha256
l aria192-sha384
l aria192-sha512
l aria256-null
l aria256-md5
l aria256-sha1
l aria256-sha256
l aria256-sha384
l aria256-sha512
With the SEED encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiOS supports:
l seed-null
l seed-md5
l seed-sha1
l seed-sha256
l seed-sha384
l seed-sha512
HMAC settings
The FortiGate uses the HMAC based on the authentication proposal that is chosen in phase 1 or phase 2 of the IPsec
configuration. Each proposal consists of the encryption-hash pair (such as 3des-sha256). The FortiGate matches the
most secure proposal to negotiate with the peer.
vd: root/0
name: MPLS
version: 1
interface: port1 3
addr: 192.168.2.5:500 -> 10.10.10.1:500
virtual-interface-addr: 172.31.0.2 -> 172.31.0.1
created: 1015820s ago
IKE SA: created 1/13 established 1/13 time 10/1626/21010 ms
IPsec SA: created 1/24 established 1/24 time 0/11/30 ms
The ip-fragmentation command controls packet fragmentation before IPsec encapsulation, which can benefit
packet loss in some environments.
The following options are available for the ip-fragmentation variable.
Option Description
Configuring the differentiated services (DiffServ) code in phase2 of an IPsec tunnel allows the tag to be applied to the
Encapsulating Security Payload (ESP) packet.
l If diffserv is disabled in the IPsec phase2 configuration, then the ESP packets' DSCP value is copied from the
inner IP packet DSCP.
l If diffserv is enabled in the IPsec phase2 configuration, then ESP packets' DSCP value is set to the configured
value.
In this example, NPU offloading is disabled, diffserv is enabled, and the diffserv code is set to 000111 on FGT-A. Only
one side of the tunnel needs to have diffserv enabled.
In this example, a site-to-site VPN tunnel is formed between two FortiGates. Multiple VLANs are configured that match
on each FortiGate. Host1 and Host2 are connected to VLAN10 on the switches.
2. Configure a static route to send all traffic out the WAN interface:
config router static
edit 1
set gateway 11.11.11.1
set device "wan1"
next
end
The interfaces added to the virtual wire pair cannot be part of a switch, such as the default internal interface.
By enabling wildcard VLANs on the virtual wire pair, all VLAN tagged traffic that is allowed by the virtual wire pair
firewall policies passes through the pair.
6. Configure a firewall policy to allow traffic between the LAN and VXLAN interfaces:
config firewall policy
edit 4
set name "vwp-pol"
set srcintf "port1" "vxlan"
set dstintf "port1" "vxlan"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
end
2. Configure a static route to send all traffic out the WAN interface:
6. Configure a firewall policy to allow traffic between the LAN and VXLAN interfaces:
config firewall policy
edit 4
set name "vwp-pol"
set srcintf "port1" "vxlan"
set dstintf "port1" "vxlan"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
end
To test the configuration, ping Host2 (VLAN10: 192.168.10.2/24) from Host1 (VLAN10: 192.168.10.1/24):
C:\>ping 192.168.10.2
This example describes how to implement VXLAN over IPsec VPN using a VXLAN tunnel endpoint (VTEP).
This example shows a specific configuration that uses a hub-and-spoke topology. However, the same logic can be
applied to a static VPN with or without XAuth. In this hub-and-spoke topology, dialup VPN is convenient because it uses
a single phase 1 dialup definition on the hub FortiGate. Additional spoke tunnels are added without any changes to the
hub, other than adding a user account for each additional spoke. Spoke-to-spoke communication is established through
the hub. This example assumes the authentication users and user groups have already been created.
IPsec tunnel interfaces are used to support VXLAN tunnel termination. An IP address is set for each tunnel interface.
Ping access is allowed for troubleshooting purposes.
VTEPs are created on each of the hub and spokes in order to forward VXLAN traffic through the IPsec tunnels. VXLAN
encapsulates OSI layer 2 Ethernet frames within layer 3 IP packets. You will need to either combine the internal port and
VXLAN interface into a soft switch, or create a virtual wire pair so that devices behind port1 have direct layer 2 access to
remote peers over the VXLAN tunnel. This example uses a switch interface on the hub and a virtual wire pair on the
spokes to demonstrate the two different methods.
Finally, in order to apply an IPsec VPN interface on the VXLAN interface setting, net-device must be disabled in the
IPsec VPN phase 1 settings. All VXLAN interfaces in this example share the same VXLAN network ID (vni).
2. Configure the IPsec VPN policy that allows VXLAN traffic between spokes:
config firewall policy
edit 1
set name "VXLAN_SPOKE_to_SPOKE"
set srcintf "SPOKES"
set dstintf "SPOKES"
set srcaddr "NET_192.168.255.0"
set dstaddr "NET_192.168.255.0"
set action accept
set schedule "always"
set service "UDP_4789"
set logtraffic all
set fsso disable
next
end
3. Configure the IPsec tunnel interfaces (the remote IP address is not used, but it is necessary for this configuration):
config system interface
edit "SPOKES"
set vdom "root"
set ip 192.168.255.1 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.255.254 255.255.255.0
set snmp-index 12
set interface "port2"
next
end
4. Configure the VXLAN interface (the remote IP is the tunnel interfaces IPs of the spokes):
config system VXLAN
edit "SPOKES_VXLAN"
set interface "SPOKES"
set vni 1
set remote-ip "192.168.255.2" "192.168.255.3"
next
end
The hub FortiGate inserts a reverse route pointing to newly established tunnel interfaces
for any of the subnets that the spoke FortiGate's source quick mode selectors provides.
This is why you should set the tunnel IP address here.
4. Configure the VXLAN interface (the remote IP is the tunnel interface IP of the hub):
config system VXLAN
edit "HUB_VXLAN"
set interface "HUB"
set vni 1
set remote-ip "192.168.255.1"
next
end
To establish a VXLAN tunnel between spokes, you can add a spoke's tunnel IP address in remote-ip.
To add more remote IP addresses to a VXLAN interface, the interface cannot be in use.
You may want to provision future spokes' remote IP addresses at this point to avoid traffic
disruption. Otherwise, you must delete the reference (the policy in this example) before
adding remote IP addresses.
next
end
The virtual wire pair requires an explicit policy to allow traffic between interfaces.
For an IPsec tunnel, the gateway IP address (giaddr) can be defined on a DHCP relay agent. Both IPv4 and IPv6
addresses are supported. An IPsec tunnel with mode-config and DHCP relay cannot specify a DHCP subnet range to
the DHCP server.
The DHCP server assigns an IP address based on the giaddr set on the IPSec phase1 interface and sends an offer to
this subnet. The DHCP server must have a route to the specified subnet giaddr.
Example
set dhgrp 5
set assign-ip-from dhcp
set dhcp6-ra-linkaddr 2000:11:11:11::1
set psksecret **********
set dpd-retryinterval 60
next
end
FortiGate supports FQDN when defining an IPsec remote gateway with a dynamically assigned IPv6 address. When
FortiGate attempts to connect to the IPv6 device, FQDN will resolve the IPv6 address even when the address changes.
Using FQDN to configure the remote gateway is useful when the remote end has a dynamic IPv6 address assigned by
their ISP or DHCPv6 server.
The tunnel can still connect to the FQDN address when the IPv6 address changes
............................................................................................
.........................
ike 0:ddns6:46933:ddn6:47779: add IPsec SA: SPIs=ac7a5719/7ab888ed
ike 0:ddns6:46933:ddn6:47779: IPsec SA dec spi ac7a5719 key
16:0F27F1D1D02496F90D15A30E2C032678 auth 20:46564E0E86A054374B31E58F95E4458340121BCE
ike 0:ddns6:46933:ddn6:47779: IPsec SA enc spi 7ab888ed key
16:926B12908EE670E1A5DDA6AD8E96607B auth 20:42BF438DC90867B837B0490EAB08E329AB62CBE3
ike 0:ddns6:46933:ddn6:47779: added IPsec SA: SPIs=ac7a5719/7ab888ed
ike 0:ddns6:46933:ddn6:47779: sending SNMP tunnel UP trap
ike 0:ddns6: carrier up
id/spi: 92 5639f7f8a5dc54c0/809a6c9bbd266a4b
direction: initiator
status: established 4313-4313s ago = 10ms
proposal: aes128-sha256
key: 74aa3d63d88e10ea-8a1c73b296b06578
lifetime/rekey: 86400/81786
DPD sent/recv: 00000000/00000000
vd: root/0
name: to_HQ
version: 1
interface: port13 42
addr: 173.1.1.1:500 -> 11.101.1.1:500
created: 1013s ago
assigned IPv4 address: 11.11.11.1/255.255.255.252
IKE SA: created 1/1 established 1/1 time 0/0/0 ms
IPsec SA: created 1/1 established 1/1 time 0/0/0 ms
id/spi: 95 255791bd30c749f4/c2505db65210258b
direction: initiator
status: established 1013-1013s ago = 0ms
proposal: aes128-sha256
key: bb101b9127ed5844-1582fd614d5a8a33
lifetime/rekey: 86400/85086
DPD sent/recv: 00000000/00000010
NP6_1:
Encryption (encrypted/decrypted)
null : 0 1.
des : 0 1.
3des : 0 1.
aes : 337152 46069
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 0 1.
sha1 : 337152 46069
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
CP8:
Encryption (encrypted/decrypted)
null : 0 1.
des : 0 1.
3des : 1337 1582
aes : 71 11426
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 48 28
sha1 : 1360 12980
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
SOFTWARE:
Encryption (encrypted/decrypted)
null : 0 1.
des : 0 1.
3des : 0 1.
aes : 0 1.
aes-gcm : 0 1.
aria : 0 1.
seed : 0 1.
chacha20poly1305 : 0 1.
Integrity (generated/validated)
null : 0 1.
md5 : 0 1.
sha1 : 0 1.
sha256 : 0 1.
sha384 : 0 1.
sha512 : 0 1.
SSL VPN
The following topics provide information about SSL VPN in FortiOS 6.4.7.
l SSL VPN best practices on page 1548
l SSL VPN quick start on page 1550
l SSL VPN tunnel mode on page 1557
l SSL VPN web mode for remote user on page 1564
l SSL VPN authentication on page 1568
l SSL VPN to IPsec VPN on page 1651
Securing remote access to network resources is a critical part of security operations. SSL VPN allows administrators to
configure, administer, and deploy a remote access strategy for their remote workers.
Choosing the correct mode of operation and applying the proper levels of security are integral to providing optimal
performance and user experience, and keeping your user data safe.
The below guidelines outline selecting the correct SSL VPN mode for your deployment and employing best practices to
ensure that your data are protected.
Information about SSL VPN throughput and maximum concurrent users is available on your device's datasheet; see
Next-Generation Firewalls Models and Specifications.
Tunnel mode
In tunnel mode, the SSL VPN client encrypts all traffic from the remote client computer and sends it to the FortiGate
through an SSL VPN tunnel over the HTTPS link between the user and the FortiGate.
The FortiGate establishes a tunnel with the client, and assigns a virtual IP (VIP) address to the client from a range
reserved addresses. While the underlying protocols are different, the outcome is very similar to a IPsec VPN tunnel. All
client traffic is encrypted, allowing the users and networks to exchange a wide range of traffic, regardless of the
application or protocols.
Use this mode if you require:
l A wide range of applications and protocols to be accessed by the remote client.
l No proxying is done by the FortiGate.
l Straightforward configuration and administration, as traffic is controlled by firewall policies.
l A transparent experience for the end user. For example, a user that needs to RDP to their server only requires a
tunnel connection; they can then use the usual client application, like Windows Remote Desktop, to connect.
Full tunneling forces all traffic to pass through the FortiGate (see SSL VPN full tunnel for remote user on page 1557).
Split tunneling only routes traffic to the designated network through the FortiGate (see SSL VPN split tunnel for remote
user on page 1550).
Limitations
Tunnel mode requires that the FortiClient VPN client be installed on the remote end. The standalone FortiClient VPN
client is free to use, and can accommodate SSL VPN and IPsec VPN tunnels. For supported operating systems, see the
FortiClient Technical Specifications.
Web mode
Web-only mode provides clientless network access using a web browser with built-in SSL encryption. Users
authenticate to FortiGate's SSL VPN Web Portal, which provides access to network services and resources, including
HTTP/HTTPS, Telnet, FTP, SMB/CIFS, VNC, RDP, and SSH. When a user starts a connection to a server from the web
portal, FortiOS proxies this communication with the server. All communication between the FortiGate and the user
continues to be over HTTPS, regardless of the service that is being accesssed.
Use this mode if you require:
l A clientless solution in which all remote services are access through a web portal.
l Tight control over the contents of the web portal.
l Limited services provided to the remote users.
Limitations
For networks with many users, integrate your user configuration with existing authentication servers through LDAP,
RADIUS, or FortiAuthenticator.
By integrating with existing authentication servers, such as Windows AD, there is a lower change of making mistakes
when configuring local users and user groups. Your administration effort is also reduces.
See SSL VPN with LDAP user authentication on page 1568 for more information.
Your certificate should identify your domain so that a remote user can recognize the identity of the server or portal that
they are accessing through a trusted CA.
The default Fortinet factory self-signed certificates are provided to simplify initial installation and testing. If you use these
certificates you are vulnerable to man-in-the-middle attacks, where an attacker spoofs your certificate, compromises
your connection, and steals your personal information. It is highly recommended that you purchase a server certificate
from a trusted CA to allow remote users to connect to SSL VPN with confidence. See Procure and import a signed SSL
certificate on page 931 for more information.
Enabling the Do not Warn Invalid Server Certificate option on the client disables the certificate warning message,
potentially allowing users to accidentally connect to untrusted servers. Disabling invalid server certificate warnings is not
recommended.
Multi-factor authentication (MFA) ensures that the end-user is who they claim to be by requiring at least two factors - a
piece of information that the user knows (password), and an asset that the user has (OTP). A third factor, something a
user is (fingerprint or face), may be enabled as well. FortiToken Mobile is typically used for MFA.
FortiGate comes with two free FortiTokens, and more can be purchased from the FortiToken Mobile iOS app or through
Fortinet partners.
See SSL VPN with FortiToken mobile push authentication on page 1597 for more information.
2FA, a subset of MFA, can also be set up with email tokens. See Email Two-Factor Authentication on FortiGate for
information.
This method of 2FA uses a user certificate as the second authentication factor. This is more secure, as it identifies the
end user using a certificate. The configuration and administration of this solution is significantly more complicated, and
requires administrators with advanced knowledge of the FortiGate and certificate deployment.
See SSL VPN with certificate authentication on page 1579 for more information.
Minimum and maximum supported TLS version can be configured in the FortiGate CLI. The cipher algorithm can also be
customized.
See How to control the SSL version and cipher suite for SSL VPN for more information.
Properly administer firewall policies and profiles against only the access level required for the remote
user
Users do not all require the same access. Access should only be granted after careful considerations. Typically, users
are placed in groups, and each group is allowed access to limited resources.
Using SSL VPN realms simplifies defining the control structure for mapping users and groups to the appropriate
resources.
See SSL VPN multi-realm on page 1644 for more information.
This is a sample configuration of remote users accessing the corporate network and internet through an SSL VPN by
tunnel mode using FortiClient but accessing the Internet without going through the SSL VPN tunnel.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
The split tunneling routing address cannot explicitly use an FQDN or an address group that
includes an FQDN. To use an FQDN, leave the routing address blank and apply the FQDN as
the destination address of the firewall policy.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internal subnet 192.168.1.0.
2. Configure user and user group.
a. Go to User & Authentication > User Definition to create a local user sslvpnuser1.
b. Go to User & Authentication > User Groups to create a group sslvpngroup with the member sslvpnuser1.
3. Configure SSL VPN web portal.
a. Go to VPN > SSL-VPN Portals to create a tunnel mode only portal my-split-tunnel-portal.
b. Enable Split Tunneling.
c. Select Routing Address to define the destination network that will be routed through the tunnel. Leave
undefined to use the destination in the respective firewall policies.
4. Configure SSL VPN settings.
a. Go to VPN > SSL-VPN Settings.
b. For Listen on Interface(s), select wan1.
c. Set Listen on Port to 10443.
d. Choose a certificate for Server Certificate. The default is Fortinet_Factory.
e. In Authentication/Portal Mapping All Other Users/Groups, set the Portal to tunnel-access.
f. Create new Authentication/Portal Mapping for group sslvpngroup mapping portal my-split-tunnel-portal.
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
6. Configure one SSL VPN firewall policy to allow remote user to access the internal network. Traffic is dropped from
internal to remote client.
config firewall policy
edit 1
set name "sslvpn split tunnel access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
next
end
For FortiGate administrators, a free version of FortiClient VPN is available which supports basic IPsec and SSL VPN and
does not require registration with EMS. This version does not include central management, technical support, or some
advanced features.
You can download the free VPN client from FNDN or FortiClient.com.
When the free VPN client is run for the first time, it displays a disclaimer. You cannot configure or create a VPN
connection until you accept the disclaimer and click I accept:
1. On the Remote Access tab, click on the settings icon and then Add a New Connection.
Description (Optional)
Client Certificate Select Prompt on connect or the certificate from the dropdown list.
1. On the Remote Access tab, select the VPN connection from the dropdown list.
Optionally, you can right-click the FortiTray icon in the system tray and select a VPN configuration to connect.
2. Enter your username and password.
3. Click the Connect button.
4. After connecting, you can now browse your remote network. Traffic to 192.168.1.0 goes through the tunnel, while
other traffic goes through the local gateway. FortiClient displays the connection status, duration, and other relevant
information.
5. Click the Disconnect button when you are ready to terminate the VPN session.
1. On the FortiGate, go to VPN > Monitor > SSL-VPN Monitor to verify the list of SSL users.
2. On the FortiGate, go to Log & Report > Forward Traffic to view the details of the SSL entry.
This configuration adds multi-factor authentication (MFA) to the split tunnel configuration (SSL VPN split tunnel for
remote user on page 1550). It uses one of the two free mobile FortiTokens that is already installed on the FortiGate.
1. On your device, open FortiToken Mobile. If this is your first time opening the application, it may prompt you to create
a PIN for secure access to the application and tokens.
2. You should have received your notification via email, select + and use the device camera to scan the token QR code
in your email.
3. FortiToken Mobile provisions and activates your token and generates token codes immediately. To view the OTP's
digits, select the eye icon. After you open the application, FortiToken Mobile generates a new six-digit OTP every 30
seconds.
1. On the Remote Access tab, select the VPN connection from the dropdown list.
Optionally, you can right-click the FortiTray icon in the system tray and select a VPN configuration to connect.
2. Enter your username and password.
3. Click the Connect button.
4. A Token field will appear, prompting you for the FortiToken code. Enter the FortiToken code from your Mobile
device.
5. After connecting, you can now browse your remote network. Traffic to 192.168.1.0 goes through the tunnel, while
other traffic goes through the local gateway. FortiClient displays the connection status, duration, and other relevant
information.
6. Click the Disconnect button when you are ready to terminate the VPN session.
The following topics provide instructions on configuring SSL VPN tunnel mode:
l SSL VPN full tunnel for remote user
l SSL VPN tunnel mode host check
This is a sample configuration of remote users accessing the corporate network and internet through an SSL VPN by
tunnel mode using FortiClient.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
2. Configure the internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
4. Configure SSL VPN web portal and predefine RDP bookmark for windows server.
config vpn ssl web portal
edit "my-full-tunnel-portal"
set tunnel-mode enable
set split-tunneling disable
set ip-pools "SSLVPN_TUNNEL_ADDR1"
next
end
6. Configure SSL VPN firewall policies to allow remote user to access the internal network. Traffic is dropped from
internal to remote client.
config firewall policy
edit 1
set name "sslvpn tunnel mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set groups "sslvpngroup"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "sslvpn tunnel mode outgoing"
set srcintf "ssl.root"
set dstintf "wan1"
set srcaddr "all"
l Set Remote Gateway to the IP of the listening FortiGate interface, in this example, 172.20.120.123.
This is a sample configuration of remote users accessing the corporate network through an SSL VPN by tunnel mode
using FortiClient with AV host check.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
The split tunneling routing address cannot explicitly use an FQDN or an address group that
includes an FQDN. To use an FQDN, leave the routing address blank and apply the FQDN as
the destination address of the firewall policy.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Configure user and user group.
a. Go to User & Authentication > User Definition to create a local user sslvpnuser1.
b. Go to User & Authentication > User Groups to create a group sslvpngroup with the member sslvpnuser1.
3. Configure SSL VPN web portal.
a. Go to VPN > SSL-VPN Portals to create a tunnel mode only portal my-split-tunnel-portal.
b. Enable Tunnel Mode and Enable Split Tunneling.
c. Select Routing Address.
4. Configure SSL VPN settings.
a. Go to VPN > SSL-VPN Settings.
b. For Listen on Interface(s), select wan1.
c. Set Listen on Port to 10443.
d. Choose a certificate for Server Certificate.
It is HIGHLY recommended that you acquire a signed certificate for your installation.
Please review the SSL VPN best practices on page 1548 and learn how to Procure and
import a signed SSL certificate on page 931.
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
6. Configure one SSL VPN firewall policy to allow remote user to access the internal network. Traffic is dropped from
internal to remote client.
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
next
end
7. Configure SSL VPN web portal to enable the host to check for compliant antivirus software on the user’s computer:
config vpn ssl web portal
edit my-split-tunnel-access
set host-check av
next
end
l Set Remote Gateway to the IP of the listening FortiGate interface, in this example, 172.20.120.123.
This is a sample configuration of remote users accessing the corporate network through an SSL VPN by web mode
using a web browser.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Configure user and user group.
a. Go to User & Authentication > User Definition to create a local user sslvpnuser1.
b. Go to User & Authentication > User Groups to create a group sslvpngroup with the member sslvpnuser1.
3. Configure SSL VPN web portal.
a. Go to VPN > SSL-VPN Portals to create a web mode only portal my-web-portal.
b. Set Predefined Bookmarks for Windows server to type RDP.
4. Configure SSL VPN settings.
a. Go to VPN > SSL-VPN Settings.
b. For Listen on Interface(s), select wan1.
c. Set Listen on Port to 10443.
It is HIGHLY recommended that you acquire a signed certificate for your installation.
Please review the SSL VPN best practices on page 1548 and learn how to Procure and
import a signed SSL certificate on page 931.
2. Configure the internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
4. Configure SSL VPN web portal and predefine RDP bookmark for windows server.
config vpn ssl web portal
edit "my-web-portal"
set web-mode enable
config bookmark-group
edit "gui-bookmarks"
config bookmarks
edit "Windows Server"
set apptype rdp
set host "192.168.1.114"
set port 3389
set logon-user "your-windows-server-user-name"
set logon-password your-windows-server-password
next
end
next
end
next
end
6. Configure one SSL VPN firewall policy to allow remote user to access the internal network. Traffic is dropped from
internal to remote client
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
next
end
1. In a web browser, log into the portal https://172.20.120.123:10443 using the credentials you've set up.
2. In the portal with the predefined bookmark, select the bookmark to begin an RDP session. If there are no predefined
bookmarks, the Quick Connection tool can be used; see Quick Connection tool on page 1567 for more information.
3. Go to VPN > Monitor > SSL-VPN Monitor to verify the list of SSL users.
4. Go to Log & Report > Forward Traffic to view the details for the SSL entry.
The Quick Connection tool allows a user to connect to a resource when it is not a predefined bookmark. The tool allows
the user to specify the type of server and the URL or IP address of the host.
To connect to a resource:
RDP sessions
Some Windows servers require that a specific security be set for RDP sessions, as opposed to
the standard RDP encryption security. For example, Windows 10 requires that TLS be used.
You can specify a location option if the remote computer does not use the same keyboard layout as your computer by
appending it to the Host field using the following format: <IP address> -m <locale>
The available options are:
fr French mk Macedonian
This is a sample configuration of SSL VPN for LDAP users. In this example, the LDAP server is a Windows 2012 AD
server. A user ldu1 is configured on Windows 2012 AD server.
You must have generated and exported a CA certificate from the AD server and then have imported it as an external CA
certificate into the FortiGate.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
1. Configure the interface and firewall address. The port1 interface connects to the internal network:
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Import CA certificate into FortiGate:
a. Go to System > Features Visibility and ensure Certificates is enabled.
b. Go to System > Certificates and select Import > CA Certificate.
c. Select Local PC and then select the certificate file.
The CA certificate now appears in the list of External CA Certificates. In this example, it is called CA_Cert_1.
d. If you want, you can use CLI commands to rename the system-generated CA_Cert_1 to be more descriptive:
config vpn certificate ca
rename CA_Cert_1 to LDAPS-CA
end
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network:
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
next
end
8. Configure one SSL VPN firewall policy to allow remote user to access the internal network:
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “ldaps-group”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
1. From a remote device, use a web browser to log into the SSL VPN web portal http://172.20.120.123:10443.
2. Enter the ldu1 user credentials, then click Login.
3. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > Events and select VPN Events from the event type dropdown list to view the details of the SSL
VPN connection event log.
3. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
This is a sample configuration of SSL VPN for LDAP users with Force Password Change on next logon. In this example,
the LDAP server is a Windows 2012 AD server. A user ldu1 is configured on Windows 2012 AD server with Force
password change on next logon.
You must have generated and exported a CA certificate from the AD server and then have imported it as an external CA
certificate into the FortiGate.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Import CA certificate into FortiGate:
a. Go to System > Features Visibility and ensure Certificates is enabled.
b. Go to System > Certificates and select Import > CA Certificate.
c. Select Local PC and then select the certificate file.
The CA certificate now appears in the list of External CA Certificates. In this example, it is called CA_Cert_1.
d. If you want, you can use CLI commands to rename the system-generated CA_Cert_1 to be more descriptive:
config vpn certificate ca
rename CA_Cert_1 to LDAPS-CA
end
The LDAP user must either be an administrator, or have the proper permissions delegated
to it, to be able to change passwords of other registered users on the LDAP server.
a. Go to User & Authentication > LDAP Servers and click Create New.
b. Specify Name and Server IP/Name.
c. Specify Common Name Identifier and Distinguished Name.
d. Set Bind Type to Regular.
e. Specify Username and Password.
f. Enable Secure Connection and set Protocol to LDAPS.
g. For Certificate, select LDAP server CA LDAPS-CA from the list.
h. To enable the password-renew option, use these CLI commands.
config user ldap
edit "ldaps-server"
set password-expiry-warning enable
set password-renewal enable
next
end
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network:
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
The LDAP user must either be an administrator, or have the proper permissions delegated
to it, to be able to change passwords of other registered users on the LDAP server.
8. Configure one SSL VPN firewall policy to allow remote user to access the internal network:
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “ldaps-group”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
1. From a remote device, use a web browser to log into the SSL VPN web portal http://172.20.120.123:10443.
2. Log in using the ldu1 credentials.
Use a user that is configured on FortiAuthenticator with Force password change on next logon.
3. Click Login. You are prompted to enter a new password. The prompt will timeout after 90 seconds.
4. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > Events and select VPN Events from the event type dropdown list to view the details of the SSL
VPN connection event log.
3. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
This is an example configuration of SSL VPN that requires users to authenticate using a client certificate. The client
certificate is issued by the company Certificate Authority (CA). Each user is issued a certificate with their username in the
subject.
There are two ways to configure certificate authentication:
1. Using PKI users
2. Configuring the SSL VPN settings to require a client certificate
In this example, the server and client certificates are signed by the same Certificate Authority (CA).
Self-signed certificates are provided by default to simplify initial installation and testing. It is
HIGHLY recommended that you acquire a signed certificate for your installation.
Continuing to use these certificates can result in your connection being compromised, allowing
attackers to steal your information, such as credit card details.
For more information, please review the Use a non-factory SSL certificate for the SSL VPN
portal on page 1549 and learn how to Procure and import a signed SSL certificate on page
931.
When using PKI users, the FortiGate authenticates the user based on there identity in the subject or the common name
on the certificate. The certificate must be signed by a CA that is known by the FortiGate, either through the default CA
certificates or through importing a CA certificate.
The user can either match a static subject or common name defined in the PKI user settings, or match an LDAP user in
the LDAP server defined in the PKI user settings. Multi-factor authentication can also be enabled with the password as
the second factor.
Using this method, the user is authenticated based on their regular username and password, but SSL VPN will still
require an additional certificate check. The client certificate only needs to be signed by a known CA in order to pass
authentication.
This method can be configured by enabling Require Client Certificate (reqclientcert) in the SSL-VPN settings.
Configuration
In the following example, SSL VPN users are authenticated using the first method. A PKI user is configured with multi-
factor authentication
Pre-requisites:
1. Install the server certificate. The server certificate allows the clients to authenticate the server and to encrypt the
SSL VPN traffic.
a. Go to System > Feature Visibility and ensure Certificates is enabled.
b. Go to System > Certificates and select Import > Local Certificate.
l Set Type to Certificate.
l Choose the Certificate file and the Key file for your certificate, and enter the Password.
l If required, you can change the Certificate Name.
The server certificate now appears in the list of Certificates.
2. Install the CA certificate.
The CA certificate is the certificate that signed both the server certificate and the user certificate. In this example, it
is used to authenticate SSL VPN users.
a. Go to System > Certificates and select Import > CA Certificate.
b. Select Local PC and then select the certificate file.
The CA certificate now appears in the list of External CA Certificates. In this example, it is called CA_Cert_1.
3. Configure PKI users and a user group.
To use certificate authentication, use the CLI to create PKI users.
config user peer
edit pki01
set ca CA_Cert_1
set subject User01
next
end
Ensure that the subject matches the name of the user certificate. In this example, User01.
4. After you have create a PKI user, a new menu is added to the GUI:
a. Go to User & Authentication > PKI to see the new user.
b. Edit the user account.
c. Enable Two-factor authentication and set a password for the account.
d. Go to User & Authentication > User Groups and create a group called sslvpngroup.
e. Add the PKI user pki01 to the group.
5. Configure SSL VPN web portal.
a. Go to VPN > SSL-VPN Portals to edit the full-access portal.
This portal supports both web and tunnel mode.
b. Disable Enable Split Tunneling so that all SSL VPN traffic goes through the FortiGate.
6. Configure SSL VPN settings.
a. Go to VPN > SSL-VPN Settings and enable SSL-VPN.
b. Set the Listen on Interface(s) to wan1.
c. Set Listen on Port to 10443.
d. Set Server Certificate to the local certificate that was imported.
e. Under Authentication/Portal Mapping, set default Portal web-access for All Other Users/Groups.
f. Create new Authentication/Portal Mapping for group sslvpngroup mapping portal full-access.
7. Configure SSL VPN firewall policy.
a. Go to Policy & Objects > Firewall Policy.
b. Fill in the firewall policy name. In this example, sslvpn certificate auth.
c. Incoming interface must be SSL-VPN tunnel interface(ssl.root).
d. Set the Source Address to all and Source User to sslvpngroup.
e. Set the Outgoing Interface to the local network interface so that the remote user can access the internal
network. In this example, port1.
f. Set Destination Address to the internal protected subnet 192.168.1.0.
g. Set Schedule to always, Service to ALL, and Action to Accept.
h. Enable NAT.
i. Configure any remaining firewall and security options as needed.
j. Click OK.
7. Configure one SSL VPN firewall policy to allow remote user to access the internal network:
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
Installation
To use the user certificate, you must first install it on the user’s PC. When the user tries to authenticate, the user
certificate is checked against the CA certificate to verify that they match.
Every user should have a unique user certificate. This allows you to distinguish each user and revoke a specific user’s
certificate, such as if a user no longer has VPN access.
l Set Remote Gateway to the IP of the listening FortiGate interface, in this example, 172.20.120.123.
1. Go to VPN > Monitor > SSL-VPN Monitor to verify the list of SSL users.
2. Go to Log & Report > Events and select VPN Events from the event type dropdown list to view the details for the
SSL connection log.
Index User Auth Type Timeout From HTTP in/out HTTPS in/out
0 pki01,cn=User01 1(1) 229 10.1.100.254 0/0 0/0
1 pki01,cn=User01 1(1) 291 10.1.100.254 0/0 0/0
This is a sample configuration of SSL VPN that requires users to authenticate using a certificate with LDAP
UserPrincipalName checking.
This sample uses Windows 2012R2 Active Directory acting as both the user certificate issuer, the certificate authority,
and the LDAP server.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
In this sample, the User Principal Name is included in the subject name of the issued certificate. This is the user field we
use to search LDAP in the connection attempt.
To use the user certificate, you must first install it on the user’s PC. When the user tries to authenticate, the user
certificate is checked against the CA certificate to verify that they match.
Every user should have a unique user certificate. This allows you to distinguish each user and revoke a specific user’s
certificate, such as if a user no longer has VPN access.
The server certificate is used for authentication and for encrypting SSL VPN traffic.
1. Go to System > Feature Visibility and ensure Certificates is enabled.
2. Go to System > Certificates and select Import > Local Certificate.
3. Set Type to Certificate.
4. Choose the Certificate file and the Key file for your certificate, and enter the Password.
5. If required, change the Certificate Name.
The server certificate now appears in the list of Certificates.
The CA certificate is the certificate that signed both the server certificate and the user certificate. In this example, it is
used to authenticate SSL VPN users.
1. Go to System > Certificates and select Import > CA Certificate.
2. Select Local PC and then select the certificate file.
The CA certificate now appears in the list of External CA Certificates. In this example, it is called CA_Cert_1.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Configure the LDAP server:
a. Go to User & Authentication > LDAP Servers and click Create New.
b. Specify Name and Server IP/Name.
c. Set Distinguished Name to dc=fortinet-fsso,dc=com.
d. Set Bind Type to Regular.
e. Set Username to cn=admin,ou=testing,dc=fortinet-fsso,dc=com.
f. Set Password.
g. Click OK.
3. Configure PKI users and a user group:
To use certificate authentication, use the CLI to create PKI users.
config user peer
edit user1
set ca CA_Cert_1
set ldap-server "ldap-AD"
set ldap-mode principal-name
next
end
When you have create a PKI user, a new menu is added to the GUI:
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network:
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
7. Configure one SSL VPN firewall policy to allow remote user to access the internal network:
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpn-group”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > VPN Events to view the details of the SSL VPN connection event log.
3. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
Below is a sample output of diagnose debug application fnbamd -1 while the user connects. This is a
shortened output sample of a few locations to show the important parts. This sample shows lookups to find the group
memberships (three groups total) of the user and that the correct group being found results in a match.
[1148] fnbamd_ldap_recv-Response len: 16, svr: 172.18.60.206
[829] fnbamd_ldap_parse_response-Got one MESSAGE. ID:4, type:search-result
[864] fnbamd_ldap_parse_response-ret=0
[1386] __fnbamd_ldap_primary_grp_next-Auth accepted
[910] __ldap_rxtx-Change state to 'Done'
[843] __ldap_rxtx-state 23(Done)
[925] fnbamd_ldap_send-sending 7 bytes to 172.18.60.206
[937] fnbamd_ldap_send-Request is sent. ID 5
[753] __ldap_stop-svr 'ldap-AD'
[53] ldap_dn_list_del_all-Del CN=test3,OU=Testing,DC=Fortinet-FSSO,DC=COM
[399] ldap_copy_grp_list-copied CN=group3,OU=Testing,DC=Fortinet-FSSO,DC=COM
[399] ldap_copy_grp_list-copied CN=Domain Users,CN=Users,DC=Fortinet-FSSO,DC=COM
[2088] fnbamd_auth_cert_check-Matching group 'sslvpn-group'
[2007] __match_ldap_group-Matching server 'ldap-AD' - 'ldap-AD'
[2015] __match_ldap_group-Matching group 'CN=group3,OU=Testing,DC=Fortinet-FSSO,DC=COM' -
'CN=group3,OU=Testing,DC=Fortinet-FSSO,DC=COM'
[2091] fnbamd_auth_cert_check-Group 'sslvpn-group' matched
[2120] fnbamd_auth_cert_result-Result for ldap svr[0] 'ldap-AD' is SUCCESS
[2126] fnbamd_auth_cert_result-matched user 'test3', matched group 'sslvpn-group'
You can also use diagnose firewall auth list to validate that a firewall user entry exists for the SSL VPN user
and is part of the right groups.
SSL VPN for remote users with MFA and user case sensitivity
By default, remote LDAP and RADIUS user names are case sensitive. When a remote user object is applied to SSL VPN
authentication, the user must type the exact case that is used in the user definition on the FortiGate.
Case sensitivity can be disabled by disabling the username-case-sensitivity CLI command, allowing the remote
user object to match any case that the end user types in.
In this example, a remote user is configured with multi-factor authentication (MFA). The user group includes the LDAP
user and server, and is applied to SSL VPN authentication and the policy.
Topology
Example configuration
Name WIN2K16-KLHOME
Username KLHOME\\Administrator
Password *********
Protocol LDAPS
Certificate CA_Cert_1
This is the CA certificate that you imported in step 2.
c. Click OK.
1. Go to User & Authentication > User Definition and click Create New.
2. Select Remote LDAP User, then click Next.
3. Select the just created LDAP server, then click Next.
To configure a user group with the remote user and the LDAP server:
1. Go to User & Authentication > User Groups and click Create New.
2. Set the Name to LDAP-USERGRP.
3. Set Members to the just created remote user.
4. In the Remote Groups table, click Add:
a. Set Remote Server to the LDAP server.
b. Set the group or groups that apply, and right click to add them.
c. Click OK.
5. Click OK.
3. Click Apply.
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. Configure the following:
Name SSLVPNtoInteral
Schedule always
Service ALL
Action ACCEPT
NAT Enabled
4. Configure a user group with the remote user and the LDAP server:
config user group
edit "LDAP-USERGRP"
set member "fgdocs" "WIN2K16-KLHOME"
next
end
Verification
In both cases, the remote user is matched against the remote LDAP user object and prompted for multi-factor
authentication.
In this case, the user is allowed to log in without a FortiToken code because the entered user name did not match the
name defined on the remote LDAP user object. Authentication continues to be evaluated against the LDAP server
though, which is not case sensitive.
This is a sample configuration of SSL VPN that uses FortiToken mobile push two-factor authentication. If you enable
push notifications, users can accept or deny the authentication request.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Register FortiGate for FortiCare Support:
To add or download a mobile token on FortiGate, FortiGate must be registered for FortiCare Support. If your
FortiGate is registered, skip this step.
a. Go to Dashboard > Licenses.
b. Hover the pointer on FortiCare Support to check if FortiCare registered. If not, click it and select Register.
3. Add FortiToken mobile to FortiGate:
If your FortiGate has FortiToken installed, skip this step.
a. Go to User & Authentication > FortiTokens and click Create New.
b. Select Mobile Token and type in Activation Code.
c. Every FortiGate has two free mobile tokens. Go to User & Authentication > FortiTokens and click Import Free
Trial Tokens.
4. Enable FortiToken mobile push:
To use FTM-push authentication, use CLI to enable FTM-Push on the FortiGate.
a. Ensure server-ip is reachable from the Internet and enter the following CLI commands:
config system ftm-push
set server-ip 172.20.120.123
set status enable
end
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
10. Configure one SSL VPN firewall policy to allow remote user to access the internal network:
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpngroup”
set action accept
1. From a remote device, use a web browser to log into the SSL VPN web portal http://172.20.120.123:10443.
2. Log in using the sslvpnuser1 credentials.
The FortiGate pushes a login request notification through the FortiToken mobile application.
3. Check your mobile device and select Approve.
When the authentication is approved, sslvpnuser1 is logged into the SSL VPN portal.
4. On the FortiGate, go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
This is a sample configuration of SSL VPN that uses FortiAuthenticator as a RADIUS authentication server.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Addresses and create an address for internal subnet 192.168.1.0.
2. Create a RADIUS user and user group .
a. On the FortiGate, go to User & Authentication > RADIUS Servers to create a user to connect to the RADIUS
server (FortiAuthenticator).
b. For Name, use FAC-RADIUS.
c. Enter the IP address of the FortiAuthenticator, and enter the Secret created above.
d. Click Test Connectivity to ensure you can connect to the RADIUS server.
e. Select Test User Credentials and enter the credentials for sslvpnuser1.
The FortiGate can now connect to the FortiAuthenticator as the RADIUS client.
f. Go to User & Authentication > User Groups and click Create New to map authenticated remote users to a user
group on the FortiGate.
g. For Name, use SSLVPNGroup.
h. In Remote Groups, click Add.
i. In the Remote Server dropdown list, select FAC-RADIUS.
j. Leave the Groups field blank.
3. Configure SSL VPN web portal.
a. Go to VPN > SSL-VPN Portals to edit the full-access portal.
This portal supports both web and tunnel mode.
b. Disable Enable Split Tunneling so that all SSL VPN traffic goes through the FortiGate.
4. Configure SSL VPN settings.
a. Go to VPN > SSL-VPN Settings.
b. Select the Listen on Interface(s), in this example, wan1.
c. Set Listen on Port to 10443.
d. Set Server Certificate to the authentication certificate.
e. Under Authentication/Portal Mapping, set default Portal web-access for All Other Users/Groups.
f. Create new Authentication/Portal Mapping for group sslvpngroup mapping portal full-access.
5. Configure SSL VPN firewall policy.
a. Go to Policy & Objects > Firewall Policy.
b. Fill in the firewall policy name. In this example, sslvpn certificate auth.
c. Incoming Interface must be SSL-VPN tunnel interface(ssl.root).
d. Set the Outgoing Interface to the local network interface so that the remote user can access the internal
network. In this example: port1.
e. Set the Source > Address to all and Source > User to sslvpngroup.
f. Set Destination > Address to the internal protected subnet 192.168.1.0.
g. Set Schedule to always, Service to ALL, and Action to Accept.
h. Enable NAT.
i. Configure the remaining options as required.
j. Click OK.
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
config authentication-rule
edit 1
set groups "sslvpngroup"
set portal "full-access"
next
end
end
6. Configure one SSL VPN firewall policy to allow remote user to access the internal network.
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
1. From a remote device, use a web browser to log into the SSL VPN web portal http://172.20.120.123:10443.
2. Log in using the sslvpnuser1 credentials.
3. On the FortiGate, go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
This is a sample configuration of SSL VPN that uses FortiAuthenticator as a RADIUS authentication server and
FortiToken mobile push two-factor authentication. If you enable push notifications, users can accept or deny the
authentication request.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
1. On the FortiAuthenticator, go to System > Administration > System Access and configure a Public IP/FQDN for
FortiToken Mobile. If the FortiAuthenticator is behind a firewall, the public IP/FQDN will be an IP/port forwarding rule
directed to one of the FortiAuthenticator interfaces. The interface that receives the approve/deny FTM push
responses must have the FortiToken Mobile API service enabled.
2. Add a FortiToken mobile license on the FortiAuthenticator:
a. Go to Authentication > User Management > FortiTokens.
b. Click Create New.
c. Set Token type to FortiToken Mobile and enter the FortiToken Activation codes.
3. Create the RADIUS client (FortiGate) on the FortiAuthenticator:
a. Go to Authentication > RADIUS Service > Clients to add the FortiGate as a RADIUS client OfficeServer).
b. Enter the FortiGate IP address and set a Secret.
The secret is a pre-shared secure password that the FortiGate uses to authenticate to the FortiAuthenticator.
c. Set Authentication method to Enforce two-factor authentication.
d. Select Enable FortiToken Mobile push notifications authentication.
e. Set Realms to local | Local users.
4. Create a user and assign FortiToken mobile to the user on the FortiAuthenticator:
a. Go to Authentication > User Management > Local Users to create a user sslvpnuser1.
b. Enable Allow RADIUS authentication and click OK to access additional settings.
c. Enable Token-based authentication and select to deliver the token code by FortiToken.
d. Select the FortiToken added from the FortiToken Mobile dropdown menu.
e. Set Delivery method to Email and fill in the User Information section.
f. Go to Authentication > User Management > User Groups to create a group sslvpngroup.
g. Add sslvpnuser1 to the group by moving the user from Available users to Selected users.
5. Install the FortiToken mobile application on your Android or iOS smartphone.
The FortiAuthenticator sends the FortiToken mobile activation to the user’s email address.
6. Activate the FortiToken mobile through the FortiToken mobile application by entering the activation code or
scanning the QR code.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Create a RADIUS user and user group:
a. On the FortiGate, go to User & Authentication > RADIUS Servers to create a user to connect to the RADIUS
server (FortiAuthenticator).
b. For Name, use FAC-RADIUS.
c. Enter the IP address of the FortiAuthenticator, and enter the Secret created above.
d. Click Test Connectivity to ensure you can connect to the RADIUS server.
e. Select Test User Credentials and enter the credentials for sslvpnuser1.
The FortiGate can now connect to the FortiAuthenticator as the RADIUS client.
f. Go to User & Authentication > User Groups and click Create New to map authenticated remote users to a user
group on the FortiGate.
g. For Name, use SSLVPNGroup.
h. In Remote Groups, click Add.
i. In the Remote Server dropdown list, select FAC-RADIUS.
j. Leave the Groups field blank.
3. Configure SSL VPN web portal:
a. Go to VPN > SSL-VPN Portals to edit the full-access portal.
This portal supports both web and tunnel mode.
b. Disable Enable Split Tunneling so that all SSL VPN traffic goes through the FortiGate.
4. Configure SSL VPN settings:
a. Go to VPN > SSL-VPN Settings.
b. Select the Listen on Interface(s), in this example, wan1.
c. Set Listen on Port to 10443.
d. Set Server Certificate to the authentication certificate.
e. Under Authentication/Portal Mapping, set default Portal web-access for All Other Users/Groups.
f. Create new Authentication/Portal Mapping for group sslvpngroup mapping portal full-access.
5. Configure SSL VPN firewall policy:
a. Go to Policy & Objects > Firewall Policy.
b. Fill in the firewall policy name. In this example, sslvpn certificate auth.
c. Incoming interface must be SSL-VPN tunnel interface(ssl.root).
d. Set the Source Address to all and Source User to sslvpngroup.
e. Set the Outgoing Interface to the local network interface so that the remote user can access the internal
network. In this example: port1.
f. Set Destination Address to the internal protected subnet 192.168.1.0.
g. Set Schedule to always, Service to ALL, and Action to Accept.
h. Enable NAT.
i. Configure any remaining firewall and security options as desired.
j. Click OK.
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network:
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
6. Configure one SSL VPN firewall policy to allow remote user to access the internal network:
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpngroup”
set action accept
1. From a remote device, use a web browser to log into the SSL VPN web portal http://172.20.120.123:10443.
2. Log in using the sslvpnuser1 credentials.
The FortiAuthenticator pushes a login request notification through the FortiToken Mobile application.
3. Check your mobile device and select Approve.
When the authentication is approved, sslvpnuser1 is logged into the SSL VPN portal.
4. On the FortiGate, go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
This is a sample configuration of SSL VPN for RADIUS users with Force Password Change on next logon. In this
example, the RADIUS server is a FortiAuthenticator. A user test1 is configured on FortiAuthenticator with Force
password change on next logon.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
7. Configure one SSL VPN firewall policy to allow remote user to access the internal network.
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “fac-group”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
1. From a remote device, use a web browser to log into the SSL VPN web portal http://172.20.120.123:10443.
2. Log in using the test1 credentials.
Use a user which is configured on FortiAuthenticator with Force password change on next logon.
3. Click Login. You are prompted to enter a new password.
4. On the FortiGate, go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
l Set Remote Gateway to the IP of the listening FortiGate interface, in this example, 172.20.120.123.
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > Events and select VPN Events from the event type dropdown list to view the details of the SSL
This is an example configuration of SSL VPN that uses Windows Network Policy Server (NPS) as a RADIUS
authentication server.
The NPS must already be configured to accept the FortiGate as a RADIUS client and the choice of authentication
method, such as MS-CHAPv2. A shared key must also have been created.
Example
The user is connecting from their PC to the FortiGate's port1 interface. RADIUS authentication occurs between the
FortiGate and the Windows NPS, and the SSL-VPN connection is established once the authentication is successful.
1. Go to Policy & Objects > Addresses and click Create New > Address.
2. Set Name to 192.168.20.0.
3. Leave Type as Subnet
4. Set IP/Netmask to 192.168.20.0/24.
5. Click OK.
1. Go to User & Authentication > RADIUS Servers and click Create New.
2. Set Name to rad-server.
3. Leave Authentication method set to Default. The PAP, MS-CHAPv2, and CHAP methods will be tried in order.
4. Under Primary Server, set IP/Name to 192.168.20.6 and Secret to the shared secret configured on the RADIUS
server.
5. Click Test Connectivity to test the connection to the server, and ensure that Connection status is Successful.
6. Optionally, click Test User Credentials to test user credentials. Testing from the GUI is limited to PAP.
7. Click OK.
1. Go to User & Authentication > User Groups and click Create New.
2. Set Name to rad-group.
4. Click OK.
c. Click OK.
6. Click Apply.
1. Go to Policy & Objects > Firewall Policy and click Create New.
2. Set the policy name, in this example, sslvpn-radius.
3. Set Incoming Interface to SSL-VPN tunnel interface(ssl.root).
4. Set Outgoing Interface to the local network interface so that the remote user can access the internal network. In this
example, port2.
5. Set the Source > Address to all and Source > User to rad-group.
6. Set Destination > Address to the internal protected subnet 192.168.20.0.
7. Set Schedule to always, Service to ALL, and Action to Accept.
8. Enable NAT.
6. Configure an SSL VPN firewall policy to allow remote user to access the internal network.
config firewall policy
edit 1
set name "sslvpn-radius"
set srcintf "ssl.root"
set dstintf "port2"
set srcaddr "all"
set dstaddr "192.168.20.0"
set groups “rad-group”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
Results
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > Events and select VPN Events from the event type drop-down list to view the details of the
SSL VPN connection event log.
3. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
When configuring two or more RADIUS servers, you can configure a Primary and Secondary server within the same
RADIUS server configurations for backup purposes. You can also configure multiple RADIUS servers within the same
User Group to service the access request at the same time.
Sample topology
Sample configurations
l Configure a Primary and Secondary server for backup on page 1621
l Authenticating to two RADIUS servers concurrently on page 1625
When you define a Primary and Secondary RADIUS server, the access request will always be sent to the Primary server
first. If the request is denied with an Access-Reject, then the user authentication fails. However, if there is no response
from the Primary server after another attempt, the access request will be sent to the Secondary server.
In this example, you will use a Windows NPS server as the Primary server and a FortiAuthenticator as the Secondary
server. It is assumed that users are synchronized between the two servers.
1. Go to Policy & Objects > Addresses and click Create New > Address.
2. Set Name to 192.168.20.0.
3. Leave Type as Subnet
4. Set IP/Netmask to 192.168.20.0/24.
5. Click OK.
1. Go to User & Authentication > RADIUS Servers and click Create New.
2. Set Name to PrimarySecondary.
3. Leave Authentication method set to Default. The PAP, MS-CHAPv2, and CHAP methods will be tried in order.
4. Under Primary Server, set IP/Name to 192.168.20.6 and Secret to the shared secret configured on the RADIUS
server.
5. Click Test Connectivity to test the connection to the server, and ensure that Connection status is Successful.
6. Under Secondary Server, set IP/Name to 192.168.2.71 and Secret to the shared secret configured on the RADIUS
server.
7. Click Test Connectivity to test the connection to the server, and ensure that Connection status is Successful.
8. Click OK.
1. Go to User & Authentication > User Groups and click Create New.
2. In the Name field, enter PrimarySecondaryGroup.
3. In the Remote Groups area, click Add, and from the Remote Server dropdown, select PrimarySecondary.
4. Click OK, and then click OK again.
c. Click OK.
6. Create a web portal for PrimarySecondaryGroup.
a. Under Authentication/Portal Mapping, click Create New.
b. Click Users/Groups and select PrimarySecondaryGroup.
c. From the Portal dropdown, select full-access.
d. Click OK.
Outgoing interface Set to the local network interface so that the remote user can access the internal
network.
For this example, select port3.
Schedule always
Service All
Action Accept
NAT Enable
edit "PrimarySecondary"
set server "192.168.20.6"
set secret <secret>
set secondary-server "192.168.2.71"
set secondary-secret <secret>
next
end
3. Add the RADIUS user to the user group:
config user group
edit "PrimarySecondaryGroup"
set member "PrimarySecondary "
next
end
4. Configure SSL VPN settings:
config vpn ssl settings
set servercert "server_certificate"
set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
set source-interface "port1"
set source-address "all"
set default-portal "web-access"
config authentication-rule
edit 1
set groups "PrimarySecondaryGroup "
set portal "full-access"
next
end
end
5. Configure one SSL VPN firewall policy to allow remote users to access the internal network:
config firewall policy
edit 1
set name "sslvpn-radius"
set srcintf "ssl.root"
set dstintf "port3"
set srcaddr "all"
set dstaddr "192.168.20.0"
set groups “PrimarySecondaryGroup”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
User radkeith is a member of both the NPS server and the FAC server.
When the Primary server is up, it will connect to the SSL VPN tunnel using FortiClient.
# diagnose sniffer packet any 'port 1812' 4 0 l
interfaces=[any]
filters=[port 1812]
2020-05-15 16:26:50.838453 port3 out 192.168.20.5.2374 -> 192.168.20.6.1812: udp 118
2020-05-15 16:26:50.883166 port3 in 192.168.20.6.1812 -> 192.168.20.5.2374: udp 20
2020-05-15 16:26:50.883374 port3 out 192.168.20.5.2374 -> 192.168.20.6.1812: udp 182
2020-05-15 16:26:50.884683 port3 in 192.168.20.6.1812 -> 192.168.20.5.2374: udp 228
The access request is sent to the Primary NPS server 192.168.20.6, and the connection is successful.
# get vpn ssl monitor
SSL VPN Login Users:
Index User Group Auth Type Timeout From HTTP
in/out HTTPS in/out
0 radkeith PrimarySecondaryGroup 2(1) 285 192.168.2.202
0/0 0/0
SSL VPN sessions:
Index User Group Source IP Duration I/O Bytes
Tunnel/Dest IP
0 radkeith PrimarySecondaryGroup 192.168.2.202 62 132477/4966
10.212.134.200
When the Primary server is down, and the Secondary server is up, the connection is made to the SSLVPN tunnel again:
# diagnose sniffer packet any 'port 1812' 4 0 l
interfaces=[any]
filters=[port 1812]
2020-05-15 16:31:23.016875 port3 out 192.168.20.5.7989 -> 192.168.20.6.1812: udp 118
2020-05-15 16:31:28.019470 port3 out 192.168.20.5.7989 -> 192.168.20.6.1812: udp 118
2020-05-15 16:31:30.011874 port1 out 192.168.2.5.23848 -> 192.168.2.71.1812: udp 118
2020-05-15 16:31:30.087564 port1 in 192.168.2.71.1812 -> 192.168.2.5.23848: udp 20
Access request is sent to the Primary NPS server 192.168.20.6, but there was no response. RADIUS authentication falls
through to the Secondary FortiAuthenticator 192.168.2.71, and the authentication was accepted. The VPN connection is
established.
# get vpn ssl monitor
SSL VPN Login Users:
Index User Group Auth Type Timeout From HTTP
in/out HTTPS in/out
0 radkeith PrimarySecondaryGroup 2(1) 287 192.168.2.202
0/0 0/0
SSL VPN sessions:
Index User Group Source IP Duration I/O Bytes
Tunnel/Dest IP
0 radkeith PrimarySecondaryGroup 192.168.2.202 48 53544/4966
10.212.134.200
There are times where users are located on separate RADIUS servers. This may be the case when migrating from an old
server to a new one for example. In this scenario, a Windows NPS server and a FortiAuthenticator are configured in the
same User Group. The access-request is sent to both servers concurrently. If FortiGate receives an access-accept from
either server, authentication is successful.
1. Go to Policy & Objects > Addresses and click Create New > Address.
2. Set Name to 192.168.20.0.
3. Leave Type as Subnet
4. Set IP/Netmask to 192.168.20.0/24.
5. Click OK.
1. Go to User & Authentication > RADIUS Servers and click Create New.
2. Set Name to win2k16.
3. Leave Authentication method set to Default. The PAP, MS-CHAPv2, and CHAP methods will be tried in order.
4. Under Primary Server, set IP/Name to 192.168.20.6 and Secret to the shared secret configured on the RADIUS
server.
5. Click Test Connectivity to test the connection to the server, and ensure that Connection status is Successful.
6. Click OK.
1. Go to User & Authentication > RADIUS Servers and click Create New.
2. Set Name to fac.
3. Leave Authentication method set to Default. The PAP, MS-CHAPv2, and CHAP methods will be tried in order.
4. Under Primary Server, set IP/Name to 192.168.2.71 and Secret to the shared secret configured on the RADIUS
server.
5. Click Test Connectivity to test the connection to the server, and ensure that Connection status is Successful.
6. Click OK.
1. Go to User & Authentication > User Groups and click Create New.
2. In the Name field, enter dualPrimaryGroup..
3. In the Remote Groups area, click Add, and from the Remote Server dropdown, select fac.
4. Click Add again. From the Remote Server dropdown select win2k16 and click OK.
5. Click OK, and then click OK again.
Outgoing interface Set to the local network interface so that the remote user can access the internal
network.
For this example, select port3.
Schedule always
Service All
Action Accept
NAT Enable
Case 1: Connect to the SSLVPN tunnel using FortiClient with user FacAdmin:
# diagnose sniffer packet any 'port 1812' 4 0 l
interfaces=[any]
filters=[port 1812]
2020-05-15 17:21:31.217985 port3 out 192.168.20.5.11490 -> 192.168.20.6.1812: udp 118
2020-05-15 17:21:31.218091 port1 out 192.168.2.5.11490 -> 192.168.2.71.1812: udp 118
2020-05-15 17:21:31.219314 port3 in 192.168.20.6.1812 -> 192.168.20.5.11490: udp 20 <--
access-reject
2020-05-15 17:21:31.219519 port3 out 192.168.20.5.11490 -> 192.168.20.6.1812: udp 182
2020-05-15 17:21:31.220219 port3 in 192.168.20.6.1812 -> 192.168.20.5.11490: udp 42
2020-05-15 17:21:31.220325 port3 out 192.168.20.5.11490 -> 192.168.20.6.1812: udp 119
2020-05-15 17:21:31.220801 port3 in 192.168.20.6.1812 -> 192.168.20.5.11490: udp 20
2020-05-15 17:21:31.236009 port1 in 192.168.2.71.1812 -> 192.168.2.5.11490: udp 20 <--
access-accept
Access is denied by the NPS server because the user does not exist. However, access is accepted by
FortiAuthenticator. The end result is the authentication is successful.
# get vpn ssl monitor
SSL VPN Login Users:
Index User Group Auth Type Timeout From HTTP
in/out HTTPS in/out
0 fackeith dualPrimaryGroup 2(1) 292 192.168.2.202 0/0
0/0
SSL VPN sessions:
Index User Group Source IP Duration I/O Bytes
Tunnel/Dest IP
0 fackeith dualPrimaryGroup 192.168.2.202 149 70236/4966
10.212.134.200
Case 2: Connect to the SSLVPN tunnel using FortiClient with user radkeith:
# diagnose sniffer packet any 'port 1812' 4 0 l
interfaces=[any]
filters=[port 1812]
2020-05-15 17:26:07.335791 port1 out 192.168.2.5.17988 -> 192.168.2.71.1812: udp 118
2020-05-15 17:26:07.335911 port3 out 192.168.20.5.17988 -> 192.168.20.6.1812: udp 118
2020-05-15 17:26:07.337659 port3 in 192.168.20.6.1812 -> 192.168.20.5.17988: udp 20 <--
access-accept
2020-05-15 17:26:07.337914 port3 out 192.168.20.5.17988 -> 192.168.20.6.1812: udp 182
2020-05-15 17:26:07.339451 port3 in 192.168.20.6.1812 -> 192.168.20.5.17988: udp 228
2020-05-15 17:26:08.352597 port1 in 192.168.2.71.1812 -> 192.168.2.5.17988: udp 20 <--
access-reject
There is a password mismatch for this user on the Secondary RADIUS server. However, even though the
authentication was rejected by FortiAuthenticator, it was accepted by Windows NPS. Therefore, the end result is
authentication successful.
# get vpn ssl monitor
SSL VPN Login Users:
Index User Group Auth Type Timeout From HTTP
in/out HTTPS in/out
0 radkeith dualPrimaryGroup 2(1) 290 192.168.2.202 0/0
0/0
This is a sample configuration of SSL VPN for users with passwords that expire after two days. Users are warned after
one day about the password expiring. The password policy can be applied to any local user password. The password
policy cannot be applied to a user group or a local remote user such as LDAP/RADIUS/TACACS+.
In FortiOS 6.2, users are warned after one day about the password expiring and have one day to renew it. If the
password expires, the user cannot renew the password and must contact the administrator for assistance.
In FortiOS 6.0/5.6, users are warned after one day about the password expiring and have to renew it. If the password
expires, the user can still renew the password.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Configure user and user group.
a. Go to User & Authentication > User Definition to create a local user.
b. Go to User & Authentication > User Groups to create a user group and add that local user to it.
3. Configure and assign the password policy using the CLI.
a. Configure a password policy that includes an expiry date and warning time. The default start time for the
password is the time the user was created.
config user password-policy
edit "pwpolicy1"
set expire-days 2
set warn-days 1
next
end
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "192.168.1.0"
set subnet 192.168.1.0 255.255.255.0
next
end
next
end
7. Configure one SSL VPN firewall policy to allow remote user to access the internal network.
config firewall policy
edit 1
set name "sslvpn web mode access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "192.168.1.0"
set groups “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
1. From a remote device, use a web browser to log into the SSL VPN web portal http://172.20.120.123:10443.
2. Log in using the sslvpnuser1 credentials.
When the warning time is reached, the user is prompted to enter a new password.
In FortiOS 6.2, when the password expires, the user cannot renew the password and must contact the
administrator.
In FortiOS 6.0/5.6, when the password expires, the user can still renew the password.
3. On the FortiGate, go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
l Set Remote Gateway to the IP of the listening FortiGate interface, in this example, 172.20.120.123.
1. Go to Dashboard > Network and expand the SSL-VPN widget to verify the user’s connection.
2. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
1. Go to Log & Report > Events and select VPN Events from the event type dropdown list to see the SSL VPN alert
labeled ssl-login-fail.
2. Click Details to see the log details about the Reason sslvpn_login_password_expired.
Dynamic SSO user groups can be used in place of address objects when configuring SSL VPN policies. This allows
dynamic IP addresses to be used in SSL VPN policies. A remote user group can be used for authentication while an
FSSO group is separately used for authorization. Using a dummy policy for remote user authentication and a policy for
FSSO group authorization, FSSO can be used with SSL VPN tunnels
This image shows the authentication and authorization flow:
In this example, FortiAuthenticator is used as a RADIUS server. It uses a remote AD/LDAP server for authentication,
then returns the authentication results to the FortiGate. This allows the client to have a dynamic IP address after
successful authentication.
First, on the LDAP server, create two users each in their own group, user142 in group pc_group1, and user143 in group
pc_group2.
l Username: cn=administrator,cn=User
4. Click OK.
5. Edit the new LDAP server.
6. Import the remote LDAP users.
7. Edit each user to confirm that they have the RADIUS attribute Acct-Interim-Interval. This attribute is used by
4. In the Realms table, set the realm to the LDAP server that was just added: ad_ldap_60.
5. Click OK.
FortiAuthenticator can now be used as a RADIUS server, and the authentication credentials all come from the
DC/LDAP server.
4. Select Enable RADIUS accounting server and set the Shared secret.
5. Create an SSL VPN portal and assign the RADIUS user group to it:
config vpn ssl web portal
edit "testportal"
set tunnel-mode enable
set ipv6-tunnel-mode enable
set web-mode enable
...
next
end
config vpn ssl settings
...
set default-portal "full-access"
config authentication-rule
edit 1
set groups "rad_group"
set portal "testportal"
next
end
end
7. Create one dummy policy for authentication only, and two normal policies for authorization:
config firewall policy
edit 1
set name "sslvpn_authentication"
set srcintf "ssl.vdom1"
set dstintf "port1"
set srcaddr "all"
set dstaddr "none"
set action accept
set schedule "always"
6. Click OK.
7. Configure an accounting server with the following CLI command:
config user radius
edit rad150
set acct-interim-interval 600
config accounting-server
edit 1
set status enable
set server 172.16.200.60
set secret *********
next
end
next
end
5. Click OK.
To create user groups for each of the FSSO groups in the GUI:
5. Click OK.
6. Add a second user group with PC_GROUP2 as a member:
CN=PC_GROUP1,OU=TESTING,DC=FSSO-QA,DC=COM
7. Click OK.
To create an SSL VPN portal and assign the RADIUS user group to it in the GUI:
Confirmation
On Client 1, log in to FortiClient using user142. Traffic can go to pc4 (172.16.200.44), but cannot go to pc5
(172.16.200.55).
On Client 2, log in to FortiClient using user143. Traffic can go to pc5 (172.16.200.55), but cannot go to pc4
(172.16.200.44).
On the FortiGate, check the authenticated users list and the SSL VPN status:
# diagnose firewall auth list
10.212.134.200, USER142
type: fsso, id: 0, duration: 173, idled: 173
server: AD_CollectAgent
packets: in 0 out 0, bytes: in 0 out 0
user_id: 16777229
group_id: 3 33554434
group_name: fsso_group1 CN=PC_GROUP1,OU=TESTING,DC=FSSO-QA,DC=COM
10.212.134.200, user142
type: fw, id: 0, duration: 174, idled: 174
expire: 259026, allow-idle: 259200
flag(80): sslvpn
server: rad150
packets: in 0 out 0, bytes: in 0 out 0
group_id: 4
group_name: rad_group
10.212.134.201, USER143
type: fsso, id: 0, duration: 78, idled: 78
server: AD_CollectAgent
packets: in 0 out 0, bytes: in 0 out 0
group_id: 1 33554435
group_name: fsso_group2 CN=PC_GROUP2,OU=TESTING,DC=FSSO-QA,DC=COM
10.212.134.201, user143
type: fw, id: 0, duration: 79, idled: 79
expire: 259121, allow-idle: 259200
flag(80): sslvpn
server: rad150
packets: in 0 out 0, bytes: in 0 out 0
group_id: 4
group_name: rad_group
This sample shows how to create a multi-realm SSL VPN that provides different portals for different user groups.
Sample topology
Sample configuration
WAN interface is the interface connected to ISP. This example shows static mode. You can also use DHCP or PPPoE
mode. The SSL VPN connection is established over the WAN interface.
The split tunneling routing address cannot explicitly use an FQDN or an address group that
includes an FQDN. To use an FQDN, leave the routing address blank and apply the FQDN as
the destination address of the firewall policy.
1. Configure the interface and firewall address. The port1 interface connects to the internal network.
a. Go to Network > Interfaces and edit the wan1 interface.
b. Set IP/Network Mask to 172.20.120.123/255.255.255.0.
c. Edit port1 interface and set IP/Network Mask to 192.168.1.99/255.255.255.0.
d. Click OK.
e. Go to Policy & Objects > Address and create an address for internet QA_subnet with subnet 192.168.1.0/24
and HR_subnet with subnet 10.1.100.0/24.
2. Configure user and user group.
a. Go to User & Authentication > User Definition to create local users qa-user1 and hr-user1.
b. Go to User & Authentication > User Groups to create separate user groups for web-only and full-access
portals:
l QA_group with member qa-user1.
2. Configure internal interface and protected subnet, then connect the port1 interface to the internal network.
config system interface
edit "port1"
set vdom "root"
set ip 192.168.1.99 255.255.255.0
next
end
config firewall address
edit "QA_subnet"
set subnet 192.168.1.0 255.255.255.0
next
edit "HR_subnet"
set subnet 10.1.100.0 255.255.255.0
next
end
edit qa
next
end
6. Configure SSL VPN settings.
config vpn ssl settings
set servercert "Fortinet_Factory"
set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1"
set source-interface "wan1"
set source-address "all"
set source-address6 "all"
set default-portal "full-access"
config authentication-rule
edit 1
set groups "QA_group"
set portal "qa-tunnel"
set realm qa
next
edit 2
set groups "HR_group"
set portal "hr-web"
set realm hr
next
end
end
7. Configure two SSL VPN firewall policies to allow remote QA user to access internal QA network and HR user to
access HR network.
config firewall policy
edit 1
set name "QA sslvnpn tunnel access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "QA_subnet"
set groups “QA_group”
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set name "HR sslvpn web access"
set srcintf "ssl.root"
set dstintf "port1"
set srcaddr "all"
set dstaddr "HR_subnet"
set groups “HR_group”
set action accept
set schedule "always"
set service "ALL"
next
end
l If a virtual-host is specified, use the FQDN defined for the realm (qa.mydomain.com).
4. Select Customize Port and set it to 10443.
5. Save your settings.
6. Use the credentials you've set up to connect to the SSL VPN tunnel.
If the user's computer has antivirus software, a connection is established; otherwise FortiClient shows a compliance
warning.
7. After connection, traffic to subnet 192.168.1.0 goes through the tunnel.
8. On the FortiGate, go to Dashboard > Network and expand the SSL-VPN widget to verify the list of SSL users.
9. On the FortiGate, go to VPN > Monitor > SSL-VPN Monitor to verify the list of SSL users.
10. On the FortiGate, go to Log & Report > Forward Traffic and view the details of the traffic.
1. In a web browser, log into the portal https://172.20.120.123:10443/hr using the credentials you've set up.
2. Alternatively, if a virtual-host is specified, use the FQDN defined for the realm (hr.mydomain.com).
3. On the FortiGate, go to Dashboard > Network and expand the SSL-VPN widget to verify the list of SSL users.
4. Go to Log & Report > Forward Traffic and view the details of the traffic.
For RADIUS authentication and authorization, the RADIUS client (the FortiGate) passes the username, password, and
NAS-IP to the RADIUS server in its access request. The RADIUS server authenticates and authorizes based on this
information. Each RADIUS server can be configured with multiple NAS-IPs for authenticating different groups and NAS
clients.
On the FortiGate, configuring the NAS-IP in the realm settings overrides the RADIUS server setting, allowing multiple
NAS-IPs to be mapped to the same RADIUS server.
In this example, the user wants to present one FortiGate VDOM with different NAS-IPs to a single RADIUS server based
on specific rules.
3. Configure SSL-VPN with an authentication rule that includes the user group and the realm:
config vpn ssl settings
...
config authentication-rule
edit 1
set groupd "radgrp"
set portal "testportal1"
set realm "realm1"
next
end
end
Because the RADIUS server and NAS-IP are specified in realm1, its NAS-IP is used for authentication.
This is a sample configuration of site-to-site IPsec VPN that allows access to the remote endpoint via SSL VPN.
This example uses a pre-existing user group, a tunnel mode SSL VPN with split tunneling, and a route-based IPsec VPN
between two FortiGates. All sessions must start from the SSL VPN interface.
If you want sessions to start from the FGT_2 subnet, you need more policies. Also, if the remote subnet is beyond FGT_
2 (if there are multiple hops), you need to include the SSL VPN subnet in those routers as well.
Sample topology
Sample configuration
d. Click Create.
A confirmation screen shows a summary of the configuration including the firewall address groups for both the local and
remote subnets, static routes, and security policies.
It is HIGHLY recommended that you acquire a signed certificate for your installation.
Please review the SSL VPN best practices on page 1548 and learn how to Procure and
import a signed SSL certificate on page 931.
7. Click Apply.
5. For Source IP Pools, add the SSL VPN subnet range created by the IPsec Wizard.
6. Click OK.
c. Click Next.
A confirmation screen shows a summary of the configuration including the firewall address groups for both the local and
remote subnets, static routes, and security policies.
4. Configure the SSL VPN connection on the user's FortiClient and connect to the tunnel.
5. On the user's computer, use CLI to send a ping though the tunnel to the remote endpoint to confirm access.
6. Go to Monitor > Routing Monitor and verify that the routes for the IPsec and SSL VPNs are added.
8. Go to Log & Report > Events, select VPN Events from the event type dropdown list, and view the IPsec and SSL
tunnel statistics.
9. Go to VPN > VPN Location Map and view VPN connection activity.
Troubleshooting
1. Send a ping through the SSL VPN tunnel to 172.16.200.55 and analyze the output of the debug.
2. Disable the debug output with this command: diagnose debug disable.
If traffic is entering the correct VPN tunnel on FGT_1, then run the same commands on FGT_2 to check whether the
traffic is reaching the correct tunnel. If it is reaching the correct tunnel, confirm that the SSL VPN tunnel range is
configured in the remote side quick mode selectors.
To troubleshoot IPsec VPN issues, use the following commands on either FortiGate:
TLS 1.3 support requires IPS engine 4.205 or later and endpoints running FortiClient 6.2.0 or
later.
To establish a client SSL VPN connection with TLS 1.3 to the FortiGate:
FortiOS supports TLS 1.3 for policies that have the following security profiles applied:
l Web filter profile with flow-based inspection mode enabled.
l Deep inspection SSL/SSH inspection profile.
For example, when a client attempts to access a website that supports TLS 1.3, FortiOS sends the traffic to the IPS
engine. The IPS engine then decodes TLS 1.3 and the client is able to access the website.
SMBv2 support
On all FortiGate models, SMBv2 is enabled by default for SSL VPN. Client PCs can access the SMBv2 server using SSL
VPN web-only mode.
To configure SMBv2:
Debug commands
Use the following diagnose commands to identify SSL VPN issues. These commands enable debugging of SSL VPN
with a debug level of -1 for detailed results.
diagnose debug application sslvpn -1
diagnose debug enable
Use the following diagnose commands to identify remote user authentication issues.
diagnose debug application fnbamd -1
diagnose debug reset
c. Check that you are using the correct port number in the URL. Ensure FortiGate is reachable from the computer.
ping <FortiGate IP>
d. Check the browser has TLS 1.1, TLS 1.2, and TLS 1.3 enabled.
1. Check the Release Notes to ensure that the FortiClient version is compatible with your version of FortiOS.
2. FortiClient uses IE security setting, In IE Internet options > Advanced > Security, check that Use TLS 1.1 and Use
TLS 1.2 are enabled.
3. Check that SSL VPN ip-pools has free IPs to sign out. The default ip-poolsSSLVPN_TUNNEL_ADDR1 has 10 IP
addresses.
4. Export and check FortiClient debug logs.
a. Go to File > Settings.
b. In the Logging section, enable Export logs.
c. Set the Log Level to Debug and select Clear logs.
1. A new SSL VPN driver was added to FortiClient 5.6.0 and later to resolve SSL VPN connection issues. If your
FortiOS version is compatible, upgrade to use one of these versions.
2. Latency or poor network connectivity can cause the login timeout on the FortiGate. In FortiOS 5.6.0 and later, use
the following commands to allow a user to increase the SSL VPN login timeout setting.
config vpn ssl settings
set login-timeout 180 (default is 30)
set dtls-hello-timeout 60 (default is 10)
end
This might occur if there are multiple interfaces connected to the Internet, for example, SD-WAN. This can cause the
session to become “dirty”. To allow multiple interfaces to connect, use the following CLI commands.
If you are using a FortiOS 6.0.1 or later:
config system interface
edit <name>
set preserve-session-route enable
next
end
1. Go to VPN > SSL-VPN Portals and VPN > SSL-VPN Settings and ensure the same IP Pool is used in both places.
Using the same IP Pool prevents conflicts. If there is a conflict, the portal settings are used.
In User & Authentication, you can control network access for different users and devices in your network. FortiGate
authentication controls system access by user group. By assigning individual users to the appropriate user groups you
can control each user’s access to network resources. You can define local users and peer users on the FortiGate unit.
You can also define user accounts on remote authentication servers and connect them to FortiOS.
You can control network access for different device types in your network by doing the following:
l Identifying and monitoring the types of devices connecting to your network
l Using MAC address based access control to allow or deny individual devices
l Using Telemetry data received from FortiClient endpoints to construct a policy to deny access to endpoints with
known vulnerabilities or to quarantine compromised endpoints
The following sections provide information about users and devices:
l Endpoint control and compliance on page 1666
l User Definition on page 1674
l User Groups on page 1676
l Guest Management on page 1677
l LDAP Servers on page 1680
l RADIUS Servers on page 1690
l TACACS+ servers on page 1711
l SAML on page 1712
l Authentication Settings on page 1716
l FortiTokens on page 1718
l PKI on page 1739
l Configuring the maximum log in attempts and lockout period on page 1739
l Configuring firewall authentication on page 1740
FortiOS supports a customizable captive portal to direct users to install or enable required software.
Per-policy custom disclaimers in each VDOM are supported. For example, you may want to configure three firewall
policies, each of which matches traffic from endpoints with different FortiClient statuses:
Endpoint does not have FortiClient installed. Traffic matches a firewall policy that displays an in-browser warning
to install FortiClient from the provided link.
Endpoint has FortiClient installed, registered Traffic matches a dynamic firewall policy which allows the endpoint to
to EMS, and connected to the FortiGate. reach its destination via this policy.
Endpoint is deregistered from EMS and Traffic matches another dynamic firewall policy that displays warning
disconnected from the FortiGate. to register FortiClient to EMS.
7. Click Save.
8. Repeat the above steps for each policy that requires a custom disclaimer message.
Compliance
In FortiOS, FortiSandbox Cloud services are decoupled from the FortiGate Cloud license. This allows you to specify a
FortiSandbox Cloud region and take advantage of FortiSandbox features without a FortiGate Cloud account.
The following topology demonstrates how FortiGate Cloud Logs and FortiSandbox Cloud are separated in FortiOS:
1. Go to Dashboard > Status.
2. The FortiGate Cloud widget shows separate license statuses for Log Retention and FortiSandbox Cloud.
In the following example, the FortiGate Cloud account is using a free license, and FortiSandbox Cloud is using a
paid license:
1. Go to System > FortiGuard.
2. In the License Information table, find FortiSandbox Cloud and click Activate.
3. Complete the prompts to obtain your license.
The FortiSandbox Cloud license is linked to your antivirus license, so they will expire at the
same time.
If the FortiGate is not registered with a paid antivirus license, the FortiGate will use the free FortiGate Cloud license.
This license limits the FortiGate to 100 FortiSandbox Cloud submissions per day.
3. Click OK.
The separation of the FortiGate Cloud Log and FortiSandbox services are visible in the following example:
FGT_PROXY (global) # diagnose test application forticldd 3
Debug zone info:
Domain:FortiCloud ReleaseQA Global - 172.16.95.16
Home log server: 172.16.95.93:514
Alt log server: 172.16.95.27:514
Active Server IP: 172.16.95.93
Active Server status: up
Log quota: 102400MB
Log used: 0MB
Daily volume: 20480MB
fams archive pause: 0
APTContract : 1
APT server: 172.16.102.52:514
APT Altserver: 172.16.102.51:514
Active APTServer IP: 172.16.102.52
Active APTServer status: up
To safeguard against certificate compromise, FortiGate VM and FortiAnalyzer VM use the same deployment model as
FortiManager VM where the license file contains a unique certificate tied to the serial number of the virtual device.
A hardware appliance usually comes with a BIOS certificate with a unique serial number that identifies the hardware
appliance. This built-in BIOS certificate is different from a firmware certificate. A firmware certificate is distributed in all
appliances with the same firmware version.
Using a BIOS certificate with a built-in serial number provides a high trust level for the other side in X.509 authentication.
Since a VM appliance has no BIOS certificate, a signed VM license can provide an equivalent of a BIOS certificate. The
VM license assigns a serial number in the BIOS equivalent certificate. This gives the certificate an abstract access
ability, which is similar to a BIOS certificate with the same high trust level.
Sample configurations
Depending on the firmware version and VM license, the common name (CN) on the certificate will be configured
differently.
l Fortinet_Factory_Backup
The Certificate Detail Information window displays.
l If you are using new firmware (6.2.0 and later) with a new VM license, the CN becomes the FortiGate VM serial
number.
l If you are using new firmware (6.2.0) with an old VM license, the CN remains as FortiGate. It does not change
to the VM serial number.
l If you are using old firmware (6.0.2) with a new VM license, the CN remains as FortiGate.
There is an option in FortiOS to enable automatic file system checks if the FortiGate shuts down ungracefully.
By default, the automatic file system check is disabled. When an administrator logs in after an ungraceful shutdown, a
warning message appears advising them to manually run a file system check.
GUI warning:
CLI warning:
WARNING: File System Check Recommended! Unsafe reboot may have caused inconsistency in disk
drive.
It is strongly recommended that you check file system consistency before proceeding.
Please run 'execute disk scan 17'
Note: The device will reboot and scan during startup. This may take up to an hour
You can enable automatic file system checks in both the GUI and CLI.
Push notifications for iPhone (for the purpose of two-factor authentication) require a TLS server certificate to
authenticate to Apple. As this certificate is only valid for one year, a service extension allows FortiGuard to distribute
updated TLS server certificates to FortiGate when needed.
FortiGuard update service updates local Apple push notification TLS server certificates when the local certificate is
expired. FortiGuard update service also reinstalls certificates when the certificates are lost.
You can verify that the feature is working on the FortiGate by using the CLI shell.
1. Using FortiOS CLI shell, verify that all certificates are installed:
/data/etc/apns # ls -al
drwxr-xr-x 2 0 0 Tue Jan 15 08:42:39 2019 1024 .
drwxr-xr-x 12 0 0 Tue Jan 15 08:45:00 2019 2048 ..
-rw-r--r-- 1 0 0 Sat Jan 12 00:06:30 2019 2377 apn-dev-cert.pem
-rw-r--r-- 1 0 0 Sat Jan 12 00:06:30 2019 1859 apn-dev-key.pem
-rw-r--r-- 1 0 0 Sat Jan 12 00:06:30 2019 8964 apn-dis-cert.pem
-rw-r--r-- 1 0 0 Sat Jan 12 00:06:30 2019 4482 apn-dis-key.pem
3. Run a FortiGuard update, and verify that all certificates are installed again:
/data/etc/apns # ls -al
drwxr-xr-x 2 0 0 Tue Jan 15 08:56:20 2019 1024 .
drwxr-xr-x 12 0 0 Tue Jan 15 08:56:15 2019 2048 ..
-rw-r--r-- 1 0 0 Sat Jan 12 00:06:30 2019 2377 apn-dev-cert.pem.save
-rw-r--r-- 1 0 0 Sat Jan 12 00:06:30 2019 1859 apn-dev-key.pem.save
-rw-r--r-- 1 0 0 Tue Jan 15 08:56:20 2019 2167 apn-dis-cert.pem <-- downloaded
from FortiGuard
-rw-r--r-- 1 0 0 Sat Jan 12 00:06:30 2019 8964 apn-dis-cert.pem.save
-rw-r--r-- 1 0 0 Tue Jan 15 08:56:20 2019 1704 apn-dis-key.pem <-- downloaded
from FortiGuard
-rw-r--r-- 1 0 0 Sat Jan 12 00:06:30 2019 4482 apn-dis-key.pem.save
-rw-r--r-- 1 0 0 Tue Jan 15 08:56:20 2019 41 apn-version.dat <-- downloaded
from FortiGuard
/data/etc/apns #
User Definition
User types
You can configure FortiOS users in FortiOS or on an external authentication server. The following summarizes user
account types and authentication in FortiOS:
Local Username and password must match a user account stored in FortiOS.
Authentication by FortiOS security policy.
Remote Username and password must match a user account stored in FortiOS and on the
remote authentication server. FortiOS supports LDAP, RADIUS, and TACACS+
servers.
Authentication server A FortiOS user group can include user accounts or groups that exist on a remote
authentication server.
FSSO Microsoft Windows or Novell network users can use their network credentials to
access resources through FortiOS. You can control access using FSSO user
groups that contain Windows or Novell user groups as members.
PKI/peer Digital certificate holder who authenticates using a client certificate. No password
is required unless two-factor authentication is enabled.
IM FortiOS does not authenticate IM users. FortiOS allows or blocks each IM user
from accessing IM protocols. A global policy for each IM protocol governs
unknown users' access to these protocols.
Guest Guest user accounts are temporary. The account expires after a selected period
of time. See Guest Management on page 1677.
Removing a user
When a user account is no longer in use, you should delete it. If any configuration objects, such as a user group,
reference the user account, you must remove the references before deleting the user.
end
User Groups
A user group is a list of users. Security policies and some VPN configurations only allow access to specified user groups.
This restricted access enforces role-based access control (RBAC) to your organization's network and resources. Users
must be in a group and that group must be part of the security policy.
In most cases, FortiOS authenticates a user by requesting their username and password. FortiOS checks local user
accounts first. Then, if it does not find a match, FortiOS checks the RADIUS, LDAP, and TACACS+ servers that belong
to the user group. Authentication succeeds when FortiOS finds a matching username and password. If the user belongs
to multiple groups on a server, FortiOS matches those groups as well.
FortiOS does not allow username overlap between RADIUS, LDAP, and TACACS+ servers.
FortiOS can authenticate users who have accounts on POP3 or POP3s email servers.
Guest Management
A visitor to your premises may need a user account on your network during their stay. If you are hosting a large event,
such as a conference, you may need to create many temporary accounts for the attendees. You can create many guest
accounts simultaneously using randomly generated user IDs and passwords to reduce your workload for these large
events.
The following describes managing guest access:
1. Create one or more guest user groups. All members of a group have the same user ID type, password type,
information fields used, and type and time of expiry.
2. Create guest accounts.
3. Use captive portal authentication and select the appropriate guest group.
4. The guest receives an email, SMS message, or printout containing their user ID and password from the FortiOS
administrator.
5. The guest logs onto the network using the provided credentials.
6. After the configured expiry time, the credentials are no longer valid.
This configuration consists of the following steps:
1. Add an SMS service.
2. Create a guest management administrator.
3. Create a guest user group.
4. Create guest user accounts.
To add an SMS service:
To send SMS notifications to guest users, add an email to SMS service to your FortiGate using the following commands:
config system sms-server
edit <server-name>
set mail-server <server-name>
next
end
The guest group configuration determines the provided fields when you create a guest user account.
1. Go to User & Authentication > User Groups.
2. Click Create New.
3. For Type, select Guest.
4. If desired, enable Batch Guest Account Creation. When this is enabled, the following is true:
l User IDs and passwords are auto-generated.
l User accounts only have the User ID, Password, and Expiration fields. You can only edit the Expiration field. If
the expiry time is a duration, such as eight hours, the countdown starts at initial login.
l You can print the account information to provide to the guest. Guests do not receive email or SMS notifications.
Option Description
Option Description
Disable No password.
Option Description
On Account Creation FortiOS counts expiry time from time of account creation.
After First Login FortiOS counts expiry time from the guest's first login.
8. For Time, configure the expiry time. You can change this for individual users.
9. Configure any other field as required, then click OK.
Businesses such as coffee shops provide free Internet access for customers. In this scenario, you do not need to
configure guest management, as customers can access the WiFi access point without logon credentials.
However, consider that the business wants to contact customers with promotional offers to encourage future patronage.
You can configure an email collection portal to collect customer email addresses for this purpose. You can configure a
security policy to grant network access only to users who provide a valid email address. The first time a customer’s
device attempts WiFi connection, FortiOS requests an email address, which it validates. The customers' subsequent
connections go directly to the Internet without interruption.
This configuration consists of the following steps:
1. Creating an email collection portal on page 1679
2. Creating a security policy on page 1679
3. Checking for harvested emails on page 1680
The customer’s first contact with your network is a captive portal that presents a webpage requesting an email address.
When FortiOS has validated the email address, the customer’s device MAC address is added to the Collected Emails
device group.
This example modifies the freewifi WiFi interface to present an email collection captive portal.
You must configure a security policy that allows traffic to flow from the WiFi SSID to the internet interface only for
members of the Collected Emails device group. This policy must be listed first. Unknown devices are not members of the
Collected Emails device group, so they do not match the policy.
next
end
LDAP Servers
This topic gives an example of configuring a local FSSO agent on the FortiGate. The agent actively pools Windows
Security Event log entries on Windows Domain Controller (DC) for user log in information. The FSSO user groups can
then be used in a firewall policy.
This method does not require any additional software components, and all the configuration can be done on the
FortiGate.
l Common Name Identifier must be changed from the default value because, in a Windows environment,
sAMAccountName must be unique, and cn must not be unique.
l Distinguished Name is the location in the LDAP tree where the FortiGate will start searching for user and group
objects.
l Active Directory requires authentication by default, so the Bind Type is Regular, and the user account log in
information is entered in the requisite fields. Optionally, click Test User Credentials to ensure that the account
has sufficient access rights.
4. Click OK.
The FortiGate checks the connection, and updates the Connection Status. The connection must be successful
before configuring the FSSO polling connector.
5. Select the just created LDAP server from the LDAP Server dropdown list.
The structure of the LDAP tree will be shown in the Users/Groups section.
6. Go to the Groups tab.
7. Select the required groups, right click on them, and select Add Selected. Multiple groups can be selected at one
time by holding the CTRL or SHIFT keys. The groups list can be filtered or searched to limit the number of groups
that are displayed.
8. Go to the Selected tab and verify that all the required groups are listed. Unneeded groups can be removed by right
clicking and selecting Remove Selected.
9. Click OK.
10. Go back to Security Fabric > External Connectors.
11. There should be two new connectors:
l The Local FSSO Agent is the backend process that is automatically created when the first FSSO polling
connector is created.
l The Active Directory Connector is the front end connector that can be configured by FortiGate administrators.
To verify the configuration, hover the cursor over the top right corner of the connector; a popup window will show the
currently selected groups. A successful connection is also shown by a green up arrow in the lower right corner of the
connector.
If you need to get log in information from multiple DCs, then you must configure other Active Directory connectors
for each additional DC to be monitored.
FSSO groups can be used in a policy by either adding them to the policy directly, or by adding them to a local user group
and then adding the group to a policy.
6. Click OK.
7. Add the local FSSO group to a policy.
Troubleshooting
If an authenticated AD user cannot access the internet or pass the firewall policy, verify the local FSSO
user list:
l The user's workstation is unable to connect to the DC, and is currently logged in with cached credentials, so
If the polling frequency shows successes and failures, that indicates sporadic network problems or a very busy
DC. If it indicates no successes or failures, then incorrect credentials could be the issue.
If the LDAP status is connected, then the FortiGate can access the configured LDAP server. This is required for
AD group membership lookup of authenticated users because the Windows Security Event log does not
include group membership information. The FortiGate sends an LDAP search for group membership of
authenticated users to the configure LDAP server.
FortiGate adds authenticated users to the local FSSO user list only if the group membership is one of the
groups in Group Filter.
4. If necessary, capture the output of the local FortiGate daemon that polls Windows Security Event logs:
# diagnose debug application fssod -1
This output contains a lot of detailed information which can be captured to a text file.
Limitations
By default, nested groups (groups that are members or other groups) are not searched in Windows Active Directory (AD)
LDAP servers because this can slow down the group membership search. There is an option in FortiOS to enable the
searching of nested groups for user group memberships on AD LDAP servers.
This option is not available for other LDAP servers, such as OpenLDAP-based servers.
The default search results only show groups that have the user as member, and no groups that have groups as
members:
diagnose test authserver ldap ldap-ad nuser nuser
authenticate 'nuser' against 'ldap-ad' succeeded!
Group membership(s) - CN=nested3,OU=Testing,DC=Fortinet-FSSO,DC=COM
CN=Domain Users,CN=Users,DC=Fortinet-FSSO,DC=COM
next
end
The search results now include groups that have other groups as members:
diagnose test authserver ldap ldap-ad nuser nuser
authenticate 'nuser' against 'ldap-ad' succeeded!
Group membership(s) - CN=nested3,OU=Testing,DC=Fortinet-FSSO,DC=COM
CN=Domain Users,CN=Users,DC=Fortinet-FSSO,DC=COM
CN=nested2,OU=Testing,DC=Fortinet-FSSO,DC=COM
CN=nested1,OU=Testing,DC=Fortinet-FSSO,DC=COM
The group nested3 is a member of the group nested2, which is a member of the group nested1.
In this configuration, users defined in Microsoft AD can set up a VPN connection based on an attribute that is set to
TRUE, instead of their user group. You can activate the Allow Dialin property in AD user properties, which sets the
msNPAllowDialin attribute to TRUE. You can use this procedure for other member attributes as your system requires.
This configuration consists of the following steps:
1. Ensure that the AD server has the msNPAllowDialin attribute set to TRUE for the desired users.
2. Configure user LDAP member attribute settings.
3. Configure LDAP group settings.
4. Ensure that you configured the settings correctly.
Users that are members of the ldap_grp user group should be able to authenticate. The following shows sample
diagnose debug output when the Allow Dial-in attribute is set to TRUE:
get_member_of_groups-Get the memberOf groups.
get_member_of_groups- attr='msNPAllowDialin', found 1 values
get_member_of_groups-val[0]='TRUE'
fnbamd_ldap_get_result-Auth accepted
fnbamd_ldap_get_result-Going to DONE state res=0
fnbamd_auth_poll_ldap-Result for ldap svr 192.168.201.3 is SUCCESS
fnbamd_auth_poll_ldap-Passed group matching
If the attribute is not set to TRUE but is expected, you may see the following output:
get_member_of_groups-Get the memberOf groups.
get_member_of_groups- attr='msNPAllowDialin', found 1 values
get_member_of_groups-val[0]='FALSE'
fnbamd_ldap_get_result-Auth accepted
fnbamd_ldap_get_result-Going to DONE state res=0
fnbamd_auth_poll_ldap-Result for ldap svr 192.168.201.3 is SUCCESS
fnbamd_auth_poll_ldap-Failed group matching
The difference between the two outputs is the last line, which shows passed or failed depending on whether the member
attribute is set to the expected value.
To avoid setting up individual admin accounts in FortiOS, you can configure an admin account with the wildcard option
enabled, allowing multiple remote admin accounts to match one local admin account. This way, multiple LDAP admin
accounts can use one FortiOS admin account.
Benefits include:
l Fast configuration of the FortiOS admin account to work with your LDAP network, saving effort and avoiding
potential errors incurred when setting up multiple admin accounts
l Reduced ongoing maintenance. As long as LDAP users belong to the same group and you do not modify the
wildcard admin account in FortiOS, you do not need to configure changes on the LDAP accounts. If you add or
remove a user from the LDAP group, you do not need to perform changes in FortiOS.
Potential issues include:
l Multiple users may be logged in to the same account simultaneously. This may cause issues if both users make
changes simultaneously.
l Security is reduced since multiple users have login access to the same account, as opposed to an account for each
user.
Wildcard admin configuration also applies to RADIUS. If configuring for RADIUS, configure the RADIUS server and
RADIUS user group instead of LDAP. When using the GUI, wildcard admin is the only remote admin account that does
not require you to enter a password on account creation. That password is normally used when the remote
authentication server is unavailable during authentication.
This example uses default values where possible. If a specific value is not mentioned, the example sets it to its default
value.
You can configure an admin account in Active Directory for LDAP authentication to allow an
admin to perform lookups and reset passwords without being a member of the Account
Operators or Domain Administrators built-in groups. See Configuring least privileges for LDAP
admin account authentication in Active Directory on page 1690.
The important parts of this configuration are the username and group lines. The username is the domain administrator
account. The group binding allows only the GRP group access.
This example uses an example domain name. Configure as appropriate for your own network.
config user ldap
edit "ldap_server"
set server "192.168.201.3"
set cnid "sAMAccountName"
set dn "DC=example,DC=com,DC=au"
set type regular
set username "CN=Administrator,CN=Users,DC=example,DC=COM”
set password *
set group-member-check group-object
set group-object-filter (&
(objectcategory=group)member="CN=GRP,OU=training,DC=example,DC=COM"))
next
end
An administrator should only have sufficient privileges for their role. In the case of LDAP admin bind, you can configure
an admin account in Active Directory for LDAP authentication to allow an admin to perform lookups and reset passwords
without being a member of the Account Operators or Domain Administrators built-in groups.
For information about Active Directory, see the product documentation.
1. In the Active Directory Users and Computers administrative console, right-click the Organizational Unit (OU) or the
top-level domain you want to configure and select Delegate Control.
2. In the Delegation of Control Wizard dialog, click Next.
3. In the Users or Groups dialog, click Add... and search Active Directory for the users or groups.
4. Click OK and then click Next.
5. In the Tasks to Delegate dialog, select Create a custom task to delegate and click Next.
6. Select Only the following objects in the folder and scroll to the bottom of the list. Select User objects and click Next.
7. In the Permissions dialog, select General.
8. From the Permissions list, select the following:
l Change password
l Reset password
l Read lockoutTime
l Write pwdLastSet
l Read pwdLastSet
l Write UserAccountControl
l Read UserAccountControl
RADIUS Servers
A common RADIUS SSO (RSSO) topology involves a medium-sized company network of users connecting to the
Internet through the FortiGate and authenticating with a RADIUS server. The following describes how to configure
FortiOS for this scenario. The example makes the following assumptions:
l VDOMs are not enabled.
l The super_admin account is used for all FortiGate configuration.
l A RADIUS server is installed on a server or FortiAuthenticator and uses default attributes.
l BGP is used for any dynamic routing.
l You have configured authentication event logging under Log & Report.
Example.com has an office with 20 users on the internal network who need access to the Internet. The office network is
protected by a FortiGate-60C with access to the Internet through the wan1 interface, the user network on the internal
interface, and all servers are on the DMZ interface. This includes an Ubuntu sever running FreeRADIUS. This example
configures two users:
User Account
To configure RADIUS:
Configuring RADIUS includes configuring a RADIUS server such as FreeRADIUS on user's computers and configuring
users in the system. In this example, Pat and Kelly belong to the exampledotcom_employees group. After completing
the configuration, you must start the RADIUS daemon. The users have a RADIUS client installed on their PCs that allow
them to authenticate through the RADIUS server.
For any problems installing FreeRADIUS, see the FreeRADIUS documentation.
You must define a DHCP server for the internal network, as this network type typically uses DHCP. The wan1 and dmz
interfaces are assigned static IP addresses and do not need a DHCP server. The following table shows the FortiGate
interfaces used in this example:
Alias Internet
Comments Internet
Administrative Status Up
3. Click OK.
4. Edit dmz:
Alias Servers
Comments Servers
Administrative Status Up
5. Click OK.
6. Edit internal:
Netmask 255.255.255.0
Administrative Status Up
You must place the RADIUS SSO policy at the top of the policy list so that it is matched first. The only exception to this is
if you have a policy to deny access to a list of banned users. In this case, you must put that policy at the top so that the
RADIUS SSO does not mistakenly match a banned user or IP address.
You must configure lists before creating security policies.
Schedule
You must configure a business_hours schedule. You can configure a standard Monday to Friday 8 AM to 5 PM
schedule, or whatever days and hours covers standard work hours at the company.
Address groups
Service groups
You must configure the service groups. The services listed are suggestions and you may include more or less as
required:
The following security policy configurations are basic and only include logging and default AV and IPS. These policies
allow or deny access to non-RADIUS SSO traffic. These are essential as network services including DNS, NTP, and
FortiGuard require access to the Internet.
Schedule always
Service essential_network_services
Action ACCEPT
NAT ON
4. Click Create New, and configure the new policy as follows, then click OK:
Schedule always
Service essential_server_services
Action ACCEPT
NAT ON
5. Click Create New, and configure the new policy as follows, then click OK:
Schedule always
Service all
Action ACCEPT
NAT ON
6. Click Create New, and configure the RADIUS SSO policy as follows, then click OK. This policy allows access for
members of specific RADIUS groups.
Source User(s) Select the user groups that you created for RSSO.
Schedule business_hours
Service ALL
Action ACCEPT
NAT ON
Security Profiles ON: AntiVirus, Web Filter, IPS, and Email Filter. In each case, select the
default profile.
7. Place the RSSO policy higher in the security policy list than more general policies for the same interfaces. Click OK.
Once configured, a user only needs to log in to their PC using their RADIUS account. After that, when they attempt to
access the Internet, the FortiGate uses their session information to get their RADIUS information. Once the user is
verified, they can access the website.
1. The user logs on to their PC and tries to access the Internet.
2. The FortiGate contacts the RADIUS server for the user's information. Once confirmed, the user can access the
Internet. Each step generates logs that enable you to verify that each step succeeded.
3. If a step does not succeed, confirm that your configuration is correct.
SecurID is a two-factor system produced by the company RSA that uses one-time password (OTP) authentication. This
system consists of the following:
l Portable tokens that users carry
l RSA ACE/Server
l Agent host (the FortiGate)
When using SecurID, users carry a small device or "token" that generates and displays a pseudo-random password.
According to RSA, each SecurID authenticator token has a unique 64-bit symmetric key that is combined with a powerful
algorithm to generate a new code every 60 seconds. The token is time-synchronized with the SecurID RSA ACE/Server.
The RSA ACE/Server is the SecurID system's management component. It stores and validates the information about the
SecurID tokens allowed on your network. Alternately, the server can be an RSA SecurID 130 appliance.
The agent host is the server on your network. In this case, this is the FortiGate, which intercepts user logon attempts.
The agent host gathers the user ID and password entered from the SecurID token and sends the information to the RSA
ACE/Server for validation. If valid, the RSA ACE/Server returns a reply indicating that it is a valid logon and FortiOS
allows the user access to the network resources specified in the associated security policy.
Configuring SecurID with FortiOS consists of the following:
1. Configure the RSA and RADIUS servers to work with each other. See RSA server documentation.
2. Do one of the following:
a. Configure the RSA SecurID 130 appliance.
b. Configure the FortiGate as an agent host on the RSA ACE/Server.
3. Configure the RADIUS server in FortiOS.
4. Create a SecurID user group.
5. Create a SecurID user.
6. Configure authentication with SecurID.
The following instructions are based on RSA ACE/Server 5.1 and RSA SecurID 130 appliance. They assume that you
have successfully completed all external RSA and RADIUS server configuration.
In this example, the RSA server is on the internal network and has an IP address of 192.128.100.000. The FortiOS
internal interface address is 192.168.100.3. The RADIUS shared secret is fortinet123, and the RADIUS server is at IP
address 192.168.100.202.
Setting Description
Shared Secret Enter the RADIUS shared secret. In this example, it is fortinet123.
1. On the RSA ACE/Server, go to Start > Programs > RSA ACE/Server, then Database Administration - Host Mode.
2. From the Agent Host menu, select Add Agent Host.
3. Configure the following:
Setting Description
Name FortiGate
Network Address Enter the FortiOS internal interface. In this example, it is 192.168.100.3.
Secondary Nodes You can optionally enter other IP addresses that resolve to the FortiGate.
Setting Description
Name RSA
Primary Server
IP/Name 192.168.100.102. You can click Test to ensure the IP address is correct and
that FortiOS can contact the RADIUS server.
Secret fortinet123
3. Click OK.
Setting Description
Name RSA_group
Type Firewall
To create a SecurID user:
Setting Description
Type wloman
RADIUS Server RSA
3. Click Create.
You can test the configuration by entering the diagnose test authserver radius RSA auto wloman
111111111 command. The series of 1s is the OTP that your RSA SecurID token generates that you enter for access.
You can use the SecurID user group in several FortiOS features that authenticate by user group:
l Security policy on page 1700
l IPsec VPN XAuth on page 1700
l PPTP VPN on page 1701
l SSL VPN
Unless stated otherwise, the following examples use default values.
Security policy
The example creates a security policy that allows HTTP, FTP, and POP3 traffic from the internal interface to WAN1. If
these interfaces are not available in FortiOS, substitute other similar interfaces.
Setting Description
Schedule always
Action ACCEPT
NAT On
Shared Shaper If you want to limit traffic or guarantee minimum bandwidth for traffic that uses
the SecurID security policy, enable and use the default shaper, guarantee-
100kbps.
Log Allowed Traffic Enable if you want to generate usage reports on traffic that this policy has
authenticated.
4. Click OK.
In VPN > IPsec Wizard, select the SecurID user group on the Authentication page. The SecurID user group members
must enter their SecurID code to authenticate.
PPTP VPN
When configuring PPTP in the CLI, set usrgrp to the SecurID user group.
SSL VPN
You must map the SecurID user group to the portal that will serve SecurID users and include the SecurID user group in
the security policy's Source User(s) field.
Setting Description
Users/Groups RSA_group
4. Click OK.
RADIUS user group membership information can be returned in the filter-Id (11) and class (25) attributes in RADIUS
Access-Accept messages. The group membership information can be used for group matching in FortiGate user groups
in firewall policies and for FortiGate wildcard administrators with remote RADIUS authentication.
In this example, a FortiAuthenticator is used as the RADIUS server. A local RADIUS user on the FortiAuthenticator is
configure with two groups in the filter-Id attribute: okta-group1 and okta-group2.
To create the RADIUS user and set the attribute type to override group information:
next
end
FortiOS will only use the configured filter-Id attribute, even if the RADIUS server sends group names in both class and
filter-id attributes. To return group membership information from the class attribute instead, set group-override-
attr-type to class.
7. Click OK.
The remote server is added to the Remote Groups table.
8. Click OK.
9. Add the new user group to a firewall policy and generate traffic on the client PC that requires firewall authentication,
such as connecting to an external web server.
10. After authentication, on the FortiGate, verify that traffic is authorized in the traffic log:
a. Go to Log & Report > Forward Traffic.
b. Verify that the traffic was authorized.
To use the remote user group with group match in a system wildcard administrator configuration:
A managed FortiSwitch can be configured to send multiple RADIUS attribute values in a single RADIUS Access-
Request. This option is configured per RADIUS user, and is set to none by default.
The available service type options are:
callback-nas-prompt User disconnected and called back, then provided a command prompt.
callback-administrative User disconnected and called back, granted access to the admin unsigned
interface.
To configure a managed FortiSwitch to the RADIUS attributes login, framed, and authenticate-only all at
the same time:
A FortiGate can use the WISPr-Bandwidth-Max-Down and WISPr-Bandwidth-Max-Up dynamic RADIUS VSAs (vendor-
specific attributes) to control the traffic rates permitted for a certain device. The FortiGate can apply different traffic
shaping to different users who authenticate with RADIUS based on the returned RADIUS VSA values. When the same
user logs in from an additional device, the RADIUS server will send a CoA (change of authorization) message to update
the bandwidth values to 1/N of the total values, where N is the number of logged in devices from the same user.
When a user logs in to two devices through RADIUS authentication. The authentication and authorization flow is as
follows:
1. The user logs in to a device and the authentication is sent to the FortiGate.
2. The FortiGate sends the Access-Request message to the RADIUS server.
3. The RADIUS server sends the Access-Accept message to the FortiGate. The server also returns the WISPr-
Bandwidth-Max-Up and WISPr-Bandwidth-Max-Down VSAs.
4. Based on the VSA values, the FortiGate applies traffic shaping for the upload and download speeds based on its IP.
5. The user logs in to a second device and the authentication is sent to the FortiGate.
6. The FortiGate sends the Access-Request message to the RADIUS server.
7. The RADIUS server sends the Access-Accept message to the FortiGate. The server also returns the WISPr-
Bandwidth-Max-Up and WISPr-Bandwidth-Max-Down VSAs at half the value from the first device.
8. Based on the VSA values, the FortiGate applies traffic shaping for the upload and download speeds on the second
device based on its IP.
9. The RADIUS server sends a CoA message and returns WISPr-Bandwidth-Max-Up and WISPr-Bandwidth-Max-
Down VSAs for the first device at half the value.
10. Based on the VSA values, the FortiGate updates traffic shaping for the upload and download speeds on the first
device based on its IP.
Example
In this example, the FortiGate is configured to dynamically shape user traffic based on the WISPr-Bandwidth-Max-Up
and WISPr-Bandwidth-Max-Down VSAs returned by the RADIUS server when the user logs in through firewall
authentication.
1. Configure the RADIUS server users file to identify WISPr-Bandwidth-Max-Up and WISPr-Bandwidth-Max-Down:
The WISPr-Bandwidth is measured in bps, and the FortiOS dynamic shaper is measured
in Bps.
WISPr-Bandwidth-Max-Up = 1004857,
WISPr-Bandwidth-Max-Down = 504857,
4. Configure the firewall policy with dynamic shaping and the RADIUS group:
config firewall policy
edit 2
set srcintf "port2"
set dstintf "wan1"
set srcaddr "all"
set dstaddr "all"
set srcaddr6 "all6"
set dstaddr6 "all6"
set action accept
set schedule "always"
set service "ALL"
set dynamic-shaping enable
set groups "group_radius"
set nat enable
next
end
Verification
After a client PC is authenticated by the RADIUS server, dynamic shaping is applied to the client based on the IP
address.
Use the following commands to monitor the dynamic shaper:
# diagnose firewall shaper dynamic-shaper stats
# diagnose firewall shaper dynamic-shaper list {ip | ipv6 | user} <address or username>
Use case 1
User1 is paying for rate plan A that limits their maximum bandwidth to 10 Mbps download and 5 Mbps upload. User2 is
paying for rate plan B that limits their maximum bandwidth to 5 Mbps download and 5 Mbps upload. The speeds in both
plans are provided by best effort, so there is no guaranteed minimum bandwidth.
User1 logs in to pc1 with RADIUS authentication and IP-based dynamic shaping is applied. User2 logs in to pc2 with
RADIUS authentication and IP-based dynamic shaping is applied.
addr: 10.1.100.22
bandwidth(original/reply): 625000 Bps/625000 Bps
current bandwidth(original/reply): 622909 Bps/0 Bps
allow packets(original/reply): 3232/3
allow bytes(original/reply): 4841536/243
drop packets(original/reply): 2753/0
Use case 2
A user logs in to a device (pc1, 10.1.100.11 ) and has a maximum bandwidth of 10 Mbps download and 5 Mbps upload.
The same user logs in to a second device (pc2, 10.1.100.22) and the RADIUS server sends a CoA request with the
WISPr-Bandwidth-Max to pc1. The maximum bandwidth on pc1 changes to 5 Mbps download and 2.5Mbps upload. On
pc2, the maximum bandwidth is also 5 Mbps download and 2.5Mbps upload.
When the user logs out from pc1, the RADIUS server sends CoA request with the new WISPr-Bandwidth-Max for pc2.
The FortiGate updates the authentication user list and dynamic shaper for pc2. The maximum bandwidth on pc2
changes to 10 Mbps download and 5 Mbps upload.
1. Check the dynamic shaper list after the user logs in to pc1:
# diagnose firewall shaper dynamic-shaper list
addr: 10.1.100.11
bandwidth(original/reply): 1250000 Bps/625000 Bps
current bandwidth(original/reply): 0 Bps/0 Bps
allow packets(original/reply): 0/3
allow bytes(original/reply): 0/243
drop packets(original/reply): 0/0
drop bytes(original/reply): 0/0
life: 491
idle: 4/4
idle time limit: 86400 s
2. Check the dynamic shaper list after the user logs in to pc2:
# diagnose firewall shaper dynamic-shaper list
addr: 10.1.100.11
bandwidth(original/reply): 625000 Bps/312500 Bps
current bandwidth(original/reply): 0 Bps/0 Bps
allow packets(original/reply): 0/0
allow bytes(original/reply): 0/0
drop packets(original/reply): 0/0
drop bytes(original/reply): 0/0
life: 652
idle: 5/5
idle time limit: 600 s
addr: 10.1.100.22
bandwidth(original/reply): 625000 Bps/312500 Bps
4. Check the dynamic shaper list after the user logs out from pc1:
# diagnose firewall shaper dynamic-shaper list
addr: 10.1.100.22
bandwidth(original/reply): 1250000 Bps/625000 Bps
current bandwidth(original/reply): 0 Bps/0 Bps
allow packets(original/reply): 0/0
allow bytes(original/reply): 0/0
drop packets(original/reply): 0/0
drop bytes(original/reply): 0/0
life: 414
idle: 9/9
idle time limit: 600 s
group_name: group_radius
----- 1 listed, 0 filtered ------
TACACS+ servers
TACACS+ is a remote authentication protocol that provides access control for routers, network access servers, and
other network devices through one or more centralized servers.
FortiOS sends the following proprietary TACACS+ attributes to the TACACS+ server during authorization requests:
Attribute Description
service=<name> User must be authorized to access the specified service.
memberof Group that the user belongs to.
admin_prof Administrator profile (admin access only).
You can configure up to ten remote TACACS+ servers in FortiOS. You must configure at least one server before you can
configure remote users.
A TACACS+ server must first be added in the CLI to make the option visible in the GUI.
Authentication Type Select the authentication type used for the TACACS+ server.
Selecting Auto tries PAP, MSCHAP, and CHAP, in that order.
Server IP/Name Enter the domain name or IP address for the primary server.
4. Click OK.
SAML
When you configure a FortiGate as a service provider (SP), you can create an authentication profile that uses SAML for
firewall authentication.
You must use the identity provider's (IdP) remote certificate on the SPs.
The following example uses a FortiGate as an SP and FortiAuthenticator as the IdP server:
2. Add the SAML user to the user group (optionally, you can configure group matching):
config user group
edit "saml_firewall"
set member "fac-firewall"
config match
edit 1
set server-name "fac-firewall"
set group-name "user_group1"
next
end
next
end
When you configure a FortiGate as a service provider (SP), you can create an authentication profile that uses SAML for
SSL VPN web portal authentication.
You can use SAML with FortiClient for SSL VPN tunnel authentication. The following licensed versions are required for
this functionality:
l FortiClient (Windows) 6.4.0
l FortiClient (macOS) 6.4.1
l FortiClient (Linux) 6.4.1
The following example uses a FortiGate as an SP and FortiAuthenticator as the IdP server:
2. Add the SAML user to the user group (group matching may also be configured):
config user group
edit "saml_sslvpn"
set member "fac-sslvpn"
next
end
1. In a web browser, enter the portal address. The SAML login page appears:
1. In FortiClient, click the Remote Access tab, and from the VPN Name dropdown, select the desired VPN tunnel.
2. Click SAML Login.
3. FortiClient displays an IdP authorization page in an embedded browser window. Enter the user name and
password.
4. Click Login.
Authentication Settings
You can configure general authentication settings, including timeout, protocol support, and certificates.
Setting Description
Authentication Timeout Enter the desired timeout in minutes. You can enter a number between 1 and
1440 (24 hours). The authentication timeout controls how long an
authenticated connection can be idle before the user must reauthenticate. The
default value is 5.
Protocol Support Select the protocols to challenge during firewall user authentication.
When you enable user authentication within a security policy, the
authentication challenge is normally issued for any of four protocols,
depending on the connection protocol:
l HTTP (you can set this to redirect to HTTPS)
l HTTPS
l FTP
l Telnet
The protocols selected here control which protocols support the authentication
challenge. Users must connect with a supported protocol first so they can
subsequently connect with other protocols. If HTTPS is selected as a protocol
support method, it allows the user to authenticate with a customized local
certificate.
When you enable user authentication within a security policy, FortiOS
challenges the security policy user to authenticate. For user ID and password
authentication, the user must provide their username and password. For
certificate authentication (HTTPS or HTTP redirected to HTTPS only), you can
install customized certificates on the unit and the user can also install
customized certificates on their browser. Otherwise, users see a warning
message and must accept a default Fortinet certificate. The network user's
web browser may deem the default certificate invalid.
Certificate If using HTTPS protocol support, select the local certificate to use for
authentication. This is available only if HTTPS and/or Redirect HTTP
Challenge to a Secure Channel (HTTPS) are selected.
FortiTokens
FortiTokens are security tokens used as part of a multi-factor authentication (MFA) system on FortiGate and
FortiAuthenticator. A security token is a 6-digit or 8-digit (configurable) one-time password (OTP) that is used to
authenticate one's identity electronically as a prerequisite for accessing network resources. FortiToken is available as
either a mobile or a physical (hard) token. Mobile tokens can be purchased as a license, or consumed with points as part
of the FortiToken Cloud service.
FortiToken Mobile and physical FortiTokens store their encryption seeds on the cloud. FortiToken Mobile seeds are
generated dynamically when the token is provisioned. They are always encrypted whether in motion or at rest.
You can only register FortiTokens to a single FortiGate or FortiAuthenticator for security purposes. This prevents
malicious third parties from making fraudulent requests to hijack your FortiTokens by registering them on another
FortiGate or FortiAuthenticator. If re-registering a FortiToken Mobile or Hard Token on another FortiGate is required, you
must contact Fortinet Customer Support.
Common usage for FortiTokens includes:
l Applying MFA to a VPN dialup user connecting to the corporate network
l Applying MFA to FortiGate administrators
l Applying MFA to firewall authentication and captive portal authentication
To enable the third factor, refer to the Activating FortiToken Mobile on a mobile phone on page
1722 section.
If the FortiToken has drifted, the following must take place for the FortiToken to resynchronize with
FortiOS:
This section includes the following topics to quickly get started with FortiTokens:
l FortiToken Mobile quick start on page 1719
l FortiToken Cloud quick start on page 1727
l Registering hard tokens on page 1730
l Managing FortiTokens on page 1733
l FortiToken Mobile Push on page 1734
l Troubleshooting and diagnosis on page 1736
FortiToken Mobile is an OATH compliant, event- and time-based one-time password (OTP) generator for mobile
devices. It provides an easy and flexible way to deploy and provision FortiTokens to your end users through mobile
devices. FortiToken Mobile produces its OTP codes in an application that you can download onto your Android or iOS
mobile device without the need for a physical token.
You can download the free FortiToken Mobile application for Android from the Google Play Store, and for iOS from the
Apple App Store.
This section focuses on quickly getting started and setting up FortiToken Mobile for use on a FortiGate:
l Registering FortiToken Mobile on page 1719
l Provisioning FortiToken Mobile on page 1720
l Activating FortiToken Mobile on a mobile phone on page 1722
l Applying multi-factor authentication on page 1726
To deploy FortiToken Mobile for your end users, you must first register the tokens on your FortiGate. After registering the
tokens, you can assign them to your end users.
Each FortiGate comes with two free FortiToken Mobile tokens. These tokens should appear under User & Authentication
> FortiTokens. If no tokens appear, you may import them. Ensure that your FortiGate is registered and has internet
access to connect to the FortiToken servers to import the tokens.
If only one free token appears, you can first delete that token and then follow the procedure to
import the two free tokens from either the GUI or the CLI.
If you have the FortiToken Mobile redemption certificate, you can register FortiToken Mobile on a FortiGate.
1. Go to User & Authentication > FortiTokens and click Create New. The New FortiToken dialog appears.
2. For the Type field, select Mobile Token.
3. Locate the 20-digit code on the redemption certificate and type it in the Activation Code field.
4. Click OK. The token is successfully registered.
If you attempt to add invalid FortiToken serial numbers, there is no error message. FortiOS
does not add invalid serial numbers to the list.
FortiToken Mobile stores its encryption seeds on the cloud. You can only register it to a single
FortiGate or FortiAuthenticator.
Once registered, FortiTokens need to be provisioned for users before they can be activated. In this example, you will
provision a Mobile token for a local user. Similar steps can be taken to assign FortiTokens to other types of users.
1. Go to User & Authentication > User Definition, and click Create New. The Users/Groups Creation Wizard appears.
2. In the User Type tab, select Local User, and click Next.
3. In the Login Credentials tab, enter a Username and Password for the user, and click Next.
5. In the Extra Info tab, make sure the User Account Status field is set to Enabled. You can also optionally assign the
user to a user group by enabling the User Group toggle.
6. Click Submit. An activation code should be sent to the created user by email or SMS, depending upon the delivery
method configured above.
FortiGate has the Email Service setting configured using the server notifications.fortinet.net by
default. To see configuration, go to System > Settings > Email Service.
The activation code expires if not activated within the 3-day time period by default. However, the expiry time period is
configurable.
To configure the time period (in hours) for FortiToken Mobile, using the CLI:
To resend the email or SMS with the activation code, refer to the Managing FortiTokens on
page 1733 section.
After your system administrator provisions your token, you receive a notification with an activation code and expiry date
via SMS or email. If you do not activate your token by the expiry date, you must contact your system administrator so that
they can reassign your token for activation.
Platforms that support FortiToken Mobile:
iOS iPhone, iPad, and iPod Touch with iOS 6.0 and later.
Android Phones and tablets with Android Jellybean 4.1 and later.
Windows Windows 10 (desktop and mobile), Windows Phone 8.1, and Windows Phone 8.
The following instructions describe procedures when using FortiToken Mobile for iOS on an iPhone. Procedures may
vary depending on your device and firmware.
1. On your iOS device, tap on the FortiToken application icon to open the application. If this is your first time opening
the application, it may prompt you to create a PIN for secure access to the application and tokens.
3. If you received the QR code via email, locate and scan the QR code in your email.
OR
If you received the activation key via SMS, tap on Enter Manually at the bottom of the screen, and tap on Fortinet.
Enter your email address in the Name field, the activation key in the Key field, and tap Done.
4. FortiToken Mobile activates your token, and starts generating OTP digits immediately. To view or hide the OTP
digits, tap the eye icon.
After you open the application, FortiToken Mobile generates a new 6-digit OTP every 30 seconds. All configured tokens
display on the application homescreen.
The FortiToken Mobile activation process described above caters to the MFA process that involves two factors
(password and OTP) of the authentication process. A third factor (fingerprint or face) can be enabled as well.
3. Enable and set up a 4-digit PIN for the application. The PIN is required to be enabled before you can enable
Touch/Face ID.
You cannot enable Touch/Face ID for FortiToken if Touch/Face ID is not set up and
enabled for device unlock (iPhone Unlock in this case) on iOS. You must first set up and
enable Touch/Face ID from Settings on your iOS device.
5. When prompted by iOS, allow the FortiToken application to use Touch/Face ID by tapping on OK in the prompt.
Multi-factor authentication (MFA) may also be set up for SSL VPN users, administrators, firewall policy, wireless users,
and so on. The following topics explain more about how you may use the newly created user in such scenarios:
l MFA for SSL VPN: Set up FortiToken multi-factor authentication on page 1555
l MFA for IPsec VPN: Add FortiToken multi-factor authentication on page 1371
l MFA for Administrators: Associating a FortiToken to an administrator account on page 793
l MFA with Captive Portal
FortiToken Cloud is an Identity and Access Management as a Service (IDaaS) cloud service offering by Fortinet. It
enables FortiGate and FortiAuthenticator customers to add MFA for their respective users, through the use of Mobile
tokens or Hard tokens. It protects local and remote administrators as well as firewall and VPN users.
To simplify FortiToken management and provisioning, centralized token authentication is available in the cloud, as
opposed to built into FortiGate or FortiAuthenticator. FortiToken Cloud uses a flexible SKU-based subscription
mechanism that enables you to subscribe and scale your FortiToken Cloud MFA service using a points-based system.
For more details, refer to the How to Add Licenses/Points and the FortiToken Cloud Admin Guide documents on the
Docs Library.
This section focuses on quickly getting started and setting up FortiToken Cloud:
l Managing FortiToken Cloud trial and licenses on page 1727
l Provisioning FortiToken Cloud on page 1728
l FortiToken Mobile token activation and verifying token status on page 1730
The FortiToken Cloud trial provides 24 points and allows up to 120 users. Points are consumed daily, and each point is
one user per month.
Once your trial has started and you need to add more points to your FortiToken Cloud service, you can purchase the
FortiToken Cloud SKU from our reseller and register the license on our support portal. To know more about how to
register for and add FortiToken Cloud licenses, refer to the How to Add Licenses/Points document.
To assign a FortiToken Cloud to a local or remote user using a FortiGate or FortiAuthenticator, the device must be
registered on the same account as the FortiToken Cloud contracts. This guide focuses on provisioning FortiToken Cloud
on FortiGate. To know more about provisioning FortiToken Cloud on FortiAuthenticator, refer to the Getting Started—
FAC-FTC users document.
7. Click OK.
To configure centralized token authentication in the cloud on the FortiGate using the CLI:
2. Assign the token to local users or administrators using the fortitoken-cloud option:
config user local
edit "guest"
set type password
set two-factor fortitoken-cloud
set email-to .........
...
next
end
Command Description
diagnose ftk-cloud show Show all current users on the FortiToken Cloud server.
users
diagnose ftk-cloud sync Update the information on the FortiToken Cloud server after changing an email
address or phone number on the FortiGate.
diagnose ftk-cloud Change the current FortiToken Cloud server. All FortiToken Cloud related
server <server_ip> operations on the FortiGate will be synchronized with the new server.
Once the FortiToken Cloud user is created, the FortiToken Cloud service will send an activation email to the end user. At
this point, if you go to the FortiToken Cloud > Users page, the newly provisioned user will be displayed with a pending
activation icon in the Status column.
To activate FortiToken Mobile on your mobile phone, follow the instructions as described in the Activating FortiToken
Mobile on a mobile phone on page 1722 section of the FortiToken Mobile Quick Start Guide.
Once FortiToken Mobile is activated for a user, FortiToken Cloud displays the user with an active status, and the pending
activation icon disappears from the Status column on the FortiToken Cloud > Users page.
You can see more details about FortiToken Mobile activated for a user from the FortiToken Cloud > Mobile page.
Seed files are only used with FortiToken-200CD. These are special hardware tokens that
come with FortiToken seeds on a CD. See the FortiToken Comprehensive Guide for
details.
6. Click Upload.
7. Browse to the file's location on your local machine, select the file, then click OK.
8. Click OK.
Activating FortiTokens
You must activate the FortiTokens before starting to use them. FortiOS requires connection to FortiGuard servers for
FortiToken activation. During activation, FortiOS queries FortiGuard servers about each token's validity. Each token can
only be used on a single FortiGate or FortiAuthenticator. If tokens are already registered, they are deemed invalid for re-
activation on another device. FortiOS encrypts the serial number and information before sending for added security.
1. Ensure that you have successfully added your FortiToken serial number to FortiOS and that its status is Available.
2. Go to User & Authentication > User Definition. Edit the desired user account.
3. Enable Two-factor Authentication.
4. From the Token dropdown list, select the desired FortiToken serial number.
5. In the Email Address field, enter the user's email address.
6. Click OK.
Before you can use a new FortiToken, you may need to synchronize it due to clock drift.
To associate a FortiToken to an administrator account, refer to the Associating a FortiToken to an administrator account
on page 793 section.
Managing FortiTokens
1. Go to User & Authentication > User Definition and edit the user.
2. Click Send Activation Code Email from the Two-factor Authentication section.
Locking/unlocking FortiTokens
If the FortiToken has drifted, the following must take place for the FortiToken to resynchronize with
FortiOS:
This command lists the serial number and drift for each configured FortiToken. You can check if it is necessary to
synchronize the FortiGate and any particular FortiTokens.
Deactivating FortiTokens
FortiTokens can only be activated on a single FortiGate or FortiAuthenticator. To move FortiTokens to another device,
you would first have to reset the registered FortiTokens on a device and then reactivate them on another device.
To reset Hard tokens registered to a FortiGate appliance (non-VM model), you can reset all hardware FTK200 tokens
from the Support Portal, or during RMA transfer. See the Migrating users and FortiTokens to another FortiGate KB
article, for more information.
The above process will reset all Hard tokens and you cannot select individual tokens to reset.
To reset FortiToken Mobile, a single Hard token, a Hard token registered to a VM, and so on, an administrator must
contact Customer Support and/or open a ticket on the Support Portal.
Once reset, the FortiTokens can be activated on another FortiGate or FortiAuthenticator.
FortiToken Mobile Push allows authentication requests to be sent as push notifications to the end user's FortiToken
Mobile application.
The FortiToken Mobile push service operates as follows:
1. FortiGate sends a DNS query to the FortiToken Mobile Push proxy server (push.fortinet.com).
2. FortiGate connects to the proxy server via an encrypted connection over TCP/443.
3. The proxy server handles the notification request by making a TLS connection with either Apple (for iOS) or Google
(for Android) notification servers. Notification data may include the recipient, session, FortiGate callback IP and
port, and so on.
4. The notification service from either Apple or Google notifies the user's mobile device of the push request.
5. The FortiToken Mobile application on the user's mobile displays a prompt for the user to either Approve or Deny the
request.
This section contains some common scenarios for FortiTokens troubleshooting and diagnosis:
l FortiToken Statuses on page 1736
l Recovering trial FortiTokens on page 1737
l Recovering lost Administrator FortiTokens on page 1737
l SSL VPN with multi-factor authentication expiry timers on page 1738
FortiToken Statuses
When troubleshooting FortiToken issues, it is important to understand different FortiToken statuses. FortiToken status
may be retrieved either from the CLI or the GUI, with a slightly different naming convention.
Before you begin, verify that the FortiGate has Internet connectivity and is also connected to both the FortiGuard and
registration servers:
# execute ping fds1.fortinet.com
# execute ping directregistration.fortinet.com
# execute ping globalftm.fortinet.net
If there are connectivity issues, retrieving FortiToken statuses or performing FortiToken activation could fail. Therefore,
troubleshoot connectivity issues before continuing.
l In the CLI:
# diagnose fortitoken info
l In the GUI:
Go to User & Authentication > FortiTokens.
Various FortiToken statuses in either the CLI or the GUI may be described as follows:
You can recover trial FortiTokens if deleted from a FortiGate, or if stuck in a state where it is not possible to provision to a
user.
When a token is stuck in an unusual state or with errors, delete the FortiTokens from the unit and proceed to recover trial
FortiTokens.
l Before attempting to recover the trial tokens, both the tokens should be deleted from the
unit first.
l If VDOMs are enabled, trial tokens are in the management VDOM (root by default).
If an Administrator loses their FortiToken or the FortiToken is not working, they will not be able to log into the admin
console through the GUI or the CLI. If there is another Administrator that can log into the device, they may be able to
reset the two-factor settings configured for the first Administrator, or create a new Admin user for them. Note that a
super_admin user will be able to edit other admin user settings, but a prof_admin user will not be able to edit super_
admin settings.
In the case where there are no other administrators configured, the only option is to flash format the device and reload a
backup config file. You must have console access to the device in order to format and flash the device. It is
recommended to be physically on site to perform this operation.
The process of resetting an Admin user password using the maintainer account cannot be
used to reset or disable two-factor authentication.
Before formatting the device, verify that you have a backup config file. You may or may not have the latest config file
backed up, though you should consider using a backed up config file, and reconfigure the rest of the recent changes
manually. Otherwise, you may need to configure your device starting from the default factory settings.
When SSL VPN is configured with multi-factor authentication (MFA), sometimes you may require a longer token expiry
time than the default 60 seconds.
These timers apply to the tokens themselves and remain valid for as long as configured above. However, SSL VPN does
not necessarily accept tokens for the entire duration they are valid. To ensure SSLVPN accepts the token for longer
durations, you need to configure the remote authentication timeout setting accordingly.
SSL VPN waits for a maximum of five minutes for a valid token code to be provided before closing down the connection,
even if the token code is valid for longer.
The remoteauthtimout setting shows how long SSL VPN waits not only for a valid token to
be provided before closing down the connection, but also for other remote authentication like
LDAP, RADIUS, and so on.
Failed log in attempts can indicate malicious attempts to gain access to your network. To prevent this security risk, you
can limit the number of failed log in attempts. After the configured maximum number of failed log in attempts is reached,
access to the account is blocked for the configured lockout period.
This example sets the lockout period to five minutes (300 seconds).
config user setting
set auth-lockout-duration 300
end
PKI
The following topics include information about public key infrastructure (PKI):
l Creating a PKI/peer user on page 1740
l SSL VPN with certificate authentication on page 1579
A PKI/peer user is a digital certificate holder. A FortiOS PKI user account contains the information required to determine
which CA certificate to use to validate the user's certificate. You can include a peer user in a firewall user group or peer
certificate group used in IPsec VPN.
To define a peer user, you need the following:
l Peer username
l Text from the user's certificate's subject field, or the name of the CA certificate used to validate the user's certificate
You can add or modify other configuration settings for PKI authentication, including configuring using an LDAP server to
check client certificate access rights. See the FortiOS CLI Reference.
In this example, a Windows network is connected to the FortiGate on port 2, and another LAN, Network_1, is connected
on port 3.
All Windows network users authenticate when they log on to their network. Engineering and Sales groups members can
access the Internet without reentering their authentication credentials. The example assumes that you have already
installed and configured FSSO on the domain controller.
LAN users who belong to the Internet_users group can access the Internet after entering their username and password.
The example shows two users: User1, authenticated by a password stored in FortiOS; and User 2, authenticated on an
external authentication server. Both users are local users since you create the user accounts in FortiOS.
1. Go to User & Authentication > User Definition and click Create New.
2. Configure the following settings:
Password hardtoguess1@@1
3. Click Submit.
You must first configure FortiOS to access the external authentication server, then create the user account.
1. Go to User & Authentication > RADIUS Servers and click Create New.
2. Configure the following settings:
Name OurRADIUSsrv
Primary Server
IP/Name 10.11.101.15
Secret OurSecret
3. Click OK.
4. Go to User & Authentication > User Definition and click Create New.
5. Configure the following settings:
6. Click Submit.
This example assumes that you have already set up FSSO on the Windows network and that it used advanced mode,
meaning that it uses LDAP to access user group information. You must do the following:
l Configure LDAP access to the Windows AD global catalog
l Specify the collector agent that sends user log in information to FortiOS
l Select Windows user groups to monitor
l Select and add the Engineering and Sales groups to an FSSO user group
Name ADserver
Username cn=FSSO_Admin,cn=users,dc=office,dc=example,dc=com
Name Enter the Windows AD server name. This name appears in the Windows
AD server list when you create user groups. In this example, the name is
WinGroups.
Server IP/Name Enter the IP address or name of the server where the agent is installed.
The maximum name length is 63 characters. In this example, the IP
address is 10.11.101.160.
Password Enter the password of the server where the agent is installed. You only
need to enter a password for the collector agent if you configured the agent
to require authenticated access.
If the TCP port used for FSSO is not the default, 8000, you can run the
config user fsso command to change the setting in the CLI.
LDAP Server Select the previously configured LDAP server. In this example, it is
ADserver.
d. Click OK.
3. Create the FSSO_Internet_users user group:
a. Go to User & Authentication > User Groups and click Create New.
b. Configure the following settings:
Name FSSO_Internet_users
c. Click OK.
This example shows a firewall user group with only two users. You can add additional members.
1. Go to User & Authentication > User Groups and click Create New.
2. Configure the following settings:
Name Internet_users
Type Firewall
3. Click OK.
Name Internal_net
Type Subnet
IP/Netmask 10.11.102.0/24
Interface Port 3
4. Click OK.
5. Create another new address by repeating steps 2-4 using the following settings:
Name Windows_net
Type Subnet
IP/Netmask 10.11.101.0/24
Interface Port 2
You must create two security policies: one for the firewall group connecting through port 3, and one for the FSSO group
connecting through port 2.
Schedule always
Service ALL
NAT Enabled.
4. Click OK.
5. Create another new policy by repeating steps 2-4 using the following settings:
Schedule always
Service ALL
NAT Enabled.
6. Click OK.
Use the Switch Controller function, also known as FortiLink, to remotely manage FortiSwitch units. In the commonly-
used layer 2 scenario, the FortiGate that is acting as a switch controller is connected to distribution FortiSwitch units. The
distribution FortiSwitch units are in the top tier of stacks of FortiSwitch units and connected downwards with Convergent
or Access layer FortiSwitch units. To leverage CAPWAP and the Fortinet proprietary FortiLink protocol, set up data and
control planes between the FortiGate and FortiSwitch units.
FortiLink allows administrators to create and manage different VLANs, and apply the full-fledged security functions of
FortiOS to them, such as 802.1X authentication and firewall policies. Most of the security control capabilities on the
FortiGate are extended to the edge of the entire network, combining FortiGate, FortiSwitch, and FortiAP devices, and
providing secure, seamless, and unified access control to users.
See FortiSwitch devices managed by FortiOS.
Logging and reporting are useful components to help you understand what is happening on your network, and to inform
you about certain network activities, such as the detection of a virus, a visit to an invalid website, an intrusion, a failed log
in attempt, and myriad others.
Logging records the traffic that passes through, starts from, or ends on the FortiGate, and records the actions the
FortiGate took during the traffic scanning process. After this information is recorded in a log message, it is stored in a log
file that is stored on a log device (a central storage location for log messages). FortiGates support several log devices,
such as FortiAnalyzer, FortiGate Cloud, and syslog servers. Approximately 5% of memory is used for buffering logs sent
to FortiAnalyzer. The FortiGate system memory and local disk can also be configured to store logs, so it is also
considered a log device.
Reports show the recorded activity in a more readable format. A report gathers all the log information that it needs, then
presents it in a graphical format with a customizable design and automatically generated charts showing what is
happening on the network. Reports can be generated on FortiGate devices with disk logging and on FortiAnalyzer
devices.
Performance statistics are not logged to disk. Performance statistics can be received by a
syslog server or by FortiAnalyzer.
All event log subtypes are available from the introductory screen and the event log subtype dropdown list on the Log &
Report > Events page. Not all of the event log subtypes are available by default.
VPN Events Available when VPN is enabled in System > Feature Visibility.
Endpoint Events Available when Endpoint Control is enabled in System > Feature Visibility.
Security Rating Events Always available, but logs are only generated when a Security Rating License is
registered.
WAN Opt. & Cache Events Available on devices with two hard disks by default. On devices with one hard
disk, the disk usage must be set to wanopt and then WAN Opt. & Cache must be
enabled in System > Feature Visibility.
WiFi Events Available on hardware devices when WiFi Controller is enabled in System >
Feature Visibility.
FortiExtender Events Available when FortiExtender is enabled in System > Feature Visibility.
This topic provides a sample raw log for each subtype and the configuration requirements.
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
Sample log
next
end
next
end
config firewall policy
edit 1
set name "to_Internet"
set srcintf "port10"
set dstintf "port9"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set logtraffic utm
set application-list "block-social.media"
set ssl-ssh-profile "deep-inspection"
set nat enable
next
end
Sample log
Sample log
Sample log
set file-type 1
set archive enable
set action block
next
end
set dlp-log enable
next
end
config firewall policy
edit 1
set name "to_Internet"
set srcintf "port10"
set dstintf "port9"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set inspection-mode proxy
set logtraffic utm
set dlp-sensor "dlp-file-type-test"
set ssl-ssh-profile "deep-inspection"
set nat enable
next
end
Sample log
For SSL-UTM-log
#EVENTTYPE="SSL-ANOMALIES"
For SSL-Traffic-log
For SSL-UTM-log
#EVENTTYPE="SSL-ANOMALIES"
date=2019-03-28 time=10:44:53 logid="1700062002" type="utm" subtype="ssl" eventtype="ssl-
anomalies" level="warning" vd="vdom1" eventtime=1553795092 policyid=1 sessionid=10796
service="HTTPS" srcip=10.1.100.66 srcport=43602 dstip=104.154.89.105 dstport=443
srcintf="port2" srcintfrole="undefined" dstintf="port3" dstintfrole="undefined" proto=6
action="blocked" msg="Server certificate blocked" reason="block-cert-invalid"
date=2019-03-28 time=10:51:17 logid="1700062002" type="utm" subtype="ssl" eventtype="ssl-
anomalies" level="warning" vd="vdom1" eventtime=1553795476 policyid=1 sessionid=11110
service="HTTPS" srcip=10.1.100.66 srcport=49076 dstip=172.16.200.99 dstport=443
srcintf="port2" srcintfrole="undefined" dstintf="port3" dstintfrole="undefined" proto=6
action="blocked" msg="Server certificate blocked" reason="block-cert-untrusted"
date=2019-03-28 time=10:55:43 logid="1700062002" type="utm" subtype="ssl" eventtype="ssl-
anomalies" level="warning" vd="vdom1" eventtime=1553795742 policyid=1 sessionid=11334
service="HTTPS" srcip=10.1.100.66 srcport=49082 dstip=172.16.200.99 dstport=443
srcintf="port2" srcintfrole="undefined" dstintf="port3" dstintfrole="undefined" proto=6
action="blocked" msg="Server certificate blocked" reason="block-cert-req"
date=2019-03-28 time=10:57:42 logid="1700062053" type="utm" subtype="ssl" eventtype="ssl-
anomalies" level="warning" vd="vdom1" eventtime=1553795861 policyid=1 sessionid=11424
service="SMTPS" profile="block-unsupported-ssl" srcip=10.1.100.66 srcport=41296
dstip=172.16.200.99 dstport=8080 srcintf="port2" srcintfrole="undefined" dstintf=unknown-0
dstintfrole="undefined" proto=6 action="blocked" msg="Connection is blocked due to
unsupported SSL traffic" reason="malformed input"
date=2019-03-28 time=11:00:17 logid="1700062002" type="utm" subtype="ssl" eventtype="ssl-
anomalies" level="warning" vd="vdom1" eventtime=1553796016 policyid=1 sessionid=11554
FortiGates with an SSD disk have a configurable log buffer. When the connection to FortiAnalyzer is unreachable, the
FortiGate is able to buffer logs on disk if the memory log buffer is full. The logs queued on the disk buffer can be sent
successfully once the connection to FortiAnalyzer is restored.
The number of logs queued on the disk buffer is visible in the Log & Report > Log Settings page:
The queued logs are buffered to the memory first and then disk. Main miglogd handles the disk buffering job, while
miglogd-children handles the memory buffering. Disk buffer statistics only appear under Main miglogd, and
memory buffer statistics only appears under miglogd-children. If the total buffer is full, new logs will overwrite the old
logs.
2. Check the Main miglogd and miglogd-children statistics. The 200 MB disk buffer has been set, and there
are currently no logs buffered in memory or on disk when FortiAnalyzer is reachable:
# diagnose test application miglogd 41 0
cache maximum: 106100940(101MB) objects: 0 used: 0(0MB) allocated: 0(0MB)
VDOM:root
Queue for: global-faz
memory queue:
num:0 size:0(0MB) max:101906636(97MB) logs:0
memory queue:
num:0 size:0(0MB) max:101906636(97MB) logs:0
3. Disable the connection between the FortiGate and FortiAnalyzer. For example, delete the FortiGate from the
FortiAnalyzer authorized device list.
Assuming a massive number of logs (~ 300000) are recorded during this downtime, the logs will be queued in the
memory buffer first. If the memory buffer is full, then the remaining logs will be queued on the disk buffer.
4. Check the Main miglogd and miglogd-children statistics again. All 97 MB of the memory buffer is occupied,
and 76 of the 200 MB has been taken from the disk buffer:
# diagnose test application miglogd 41 0
cache maximum: 106100940(101MB) objects: 0 used: 0(0MB) allocated: 0(0MB)
VDOM:root
Queue for: global-faz
memory queue:
num:0 size:0(0MB) max:101906636(97MB) logs:0
memory queue:
num:165718 size:101906500(97MB) max:101906636(97MB) logs:165718
The overall miglogd statistics shows the total cached logs is the sum of the logs buffered in memory and on disk:
# diagnose test application miglogd 6
mem=0, disk=11, alert=0, alarm=0, sys=0, faz=300053, faz-cloud=0, webt=0, fds=0
interface-missed=44
Queues in all miglogds: cur:165718 total-so-far:165718
global log dev statistics:
faz 0: sent=0, failed=0, cached=300053, dropped=0 , relayed=0
Num of REST URLs: 0
memory queue:
num:0 size:0(0MB) max:101906636(97MB) logs:0
memory queue:
num:0 size:0(0MB) max:101906636(97MB) logs:0
This topic describes which log messages are supported by each logging destination:
FortiGates with a FortiCloud Premium subscription (AFAC) for Cloud-based Central Logging & Analytics, can send traffic
logs to FortiAnalyzer Cloud in addition to UTM logs and event logs. After the Premium subscription is registered through
FortiCare, FortiGuard will verify the purchase and authorize the AFAC contract. Once the contract is verified, FortiGuard
will deliver the contract to FortiGate.
FortiGates with a Standard FortiAnalyzer Cloud subscription (FAZC) can only send UTM and event logs. FortiGates with
a Premium subscription will send the UTM and event logs even if the Standard subscription has expired.
Example
In the following example, you will configure a FortiGate with a valid Premium subscription (AFAC) and expired Standard
subscription (FAZC) to send traffic logs to FortiAnalyzer Cloud.
1. Configure the log delivery.
config log fortianalyzer-cloud setting
set status enable
set ips-archive disable
set access-config enable
set enc-algorithm high
set ssl-min-proto-version default
set conn-timeout 10
set monitor-keepalive-period 5
set monitor-failure-retry-period 5
set certificate ''
set source-ip ''
set interface-select-method auto
set upload-option realtime
set priority default
set max-log-rate 0
end
2. Verify the status of the FortiCloud Premium subscription (AFAC) and standard FortiAnalyzer Cloud subscription
(FAZC).
The FAZC and AFAC fields display the subscription expiration date. The Support contract field displays the
FortiCare account information. The User ID field displays the ID for FortiAnalyzer-Cloud instance.
# diagnose test update info
...
FAZC,Tue Sep 24 16:00:00 2030
AFAC,Mon Nov 29 16:00:00 2021
...
Support contract: pending_registration=255 got_contract_info=1
account_id=[****@fortinet.com] company=[Fortinet] industry=[Technology]
User ID: 979090
The FAZC and AFAC subscriptions are valid (date of verification is November 29, 2020).
3. Check the status of FortiAnalyzer Cloud.
# execute log fortianalyzer-cloud test-connectivity
FortiAnalyzer Host Name: FAZVM64-VIO-CLOUD
FortiAnalyzer Adom Name: root
FortiGate Device ID: FG101FTK19000000
Registration: registered
Connection: allow
Adom Disk Space (Used/Allocated): 50351453B/53687091200B
Analytics Usage (Used/Allocated): 41368925B/37580963840B
Analytics Usage (Data Policy Days Actual/Configured): 60/60 Days
Archive Usage (Used/Allocated): 8982528B/16106127360B
Archive Usage (Data Policy Days Actual/Configured): 235/365 Days
Log: Tx & Rx (log not received)
IPS Packet Log: Tx & Rx
Content Archive: Tx & Rx
Quarantine: Tx & Rx
Certificate of Fortianalyzer valid and serial number is:FAZVCLTM20000000
4. When the FortiCloud Premium (AFAC) and standard FortiAnalyzer Cloud (FAZC) subscriptions are valid, the
FortiGate sends the traffic, event, and UTM logs to the remote FortiAnalyzer Cloud.
Traffic:
# execute log filter device fortianalyzer-cloud
# execute log filter category traffic
# execute log filter dump
category: traffic
device: fortianalyzer-cloud
start-line: 1
view-lines: 10
max-checklines: 0
HA member:
Oftp search string:
# execute log display
6512 logs found.
10 logs returned.
1: date=2020-11-29 time=13:57:33 id=6900668351836585985 itime="2020-11-29 13:57:34"
euid=3 epid=1027 dsteuid=3 dstepid=101 logflag=1 logver=604041797 type="traffic"
subtype="forward" level="notice" action="accept" policyid=1 sessionid=46536
srcip=10.1.100.72 dstip=172.16.100.55 transip=172.16.200.7 srcport=40797 dstport=53
transport=40797 trandisp="snat" duration=190 proto=17 sentbyte=268 rcvdbyte=0
sentpkt=4 rcvdpkt=0 logid=0000000013 service="DNS" app="DNS" appcat="unscanned"
srcintfrole="undefined" dstintfrole="undefined" srcserver=0 dstserver=0
policytype="policy" eventtime=1606687054554969021 poluuid="c041939c-2930-51eb-1448-
34c44a663331" srcmac="00:0c:29:eb:86:d6" mastersrcmac="00:0c:29:eb:86:d6"
dstmac="e8:1c:ba:c2:86:63" masterdstmac="e8:1c:ba:c2:86:63" srchwvendor="VMware"
osname="Linux" srccountry="Reserved" dstcountry="Reserved" srcintf="dmz"
dstintf="wan1" policyname="to_WAN" tz="-0800" devid="FG101FTK19000000" vd="root"
dtime="2020-11-29 13:57:33" itime_t=1606687054 devname="FortiGate-101F_F"
Event:
# execute log filter device fortianalyzer-cloud
# execute log filter category event
# execute log filter dump
category: event
device: fortianalyzer-cloud
start-line: 1
view-lines: 10
max-checklines: 0
HA member:
Oftp search string:
# execute log display
1067 logs found.
10 logs returned.
1: date=2020-11-29 time=14:12:16 id=6900672144292708352 itime="2020-11-29 14:12:17"
euid=3 epid=3 dsteuid=3 dstepid=3 logver=604041797 logid=0100038404 type="event"
subtype="system" level="error" msg="unable to resolve FortiGuard hostname"
logdesc="FortiGuard hostname unresolvable" hostname="service.fortiguard.net"
eventtime=1606687936888734117 tz="-0800" devid="FG101FTK19000000" vd="root"
dtime="2020-11-29 14:12:16" itime_t=1606687937 devname="FortiGate-101F_F"
UTM:
# execute log filter device fortianalyzer-cloud
# execute log filter category utm-virus
# execute log filter dump
category: virus
device: fortianalyzer-cloud
start-line: 1
view-lines: 10
max-checklines: 0
HA member:
l VDOM1
l VDOM2
l FAZ4: 192.168.1.254
queue: qlen=0.
filter: severity=6, sz_exclude_list=0
voip dns ssh ssl
subcategory:
traffic: forward local multicast sniffer
anomaly: anomaly
queue: qlen=0.
filter: severity=6, sz_exclude_list=0
voip dns ssh ssl
subcategory:
traffic: forward local multicast sniffer
anomaly: anomaly
oftp-state=5
faz3: vdom, disabled, override
When faz-override and/or syslog-override is enabled, the following CLI commands are available for configuring
VDOM override:
The log-uuid setting in system global is split into two settings: log-uuid-address and log-uuid policy.
The traffic log includes two internet-service name fields: Source Internet Service (srcinetsvc) and Destination
Internet Service (dstinetsvc).
Log UUIDs
UUIDs can be matched for each source and destination that match a policy that is added to the traffic log. This allows the
address objects to be referenced in log analysis and reporting.
As this may consume a significant amount of storage space, this feature is optional. By default, policy UUID insertion is
enabled and address UUID insertion is disabled.
To enable address and policy UUID insertion in traffic logs using the GUI:
3. Click Apply.
To enable address and policy UUID insertion in traffic logs using the CLI:
Traffic logs for internet-service include two fields: Source Internet Service and Destination Internet Service.
The signal-to-noise ratio (snr) and signal strength (signal) are logged per client in the WiFi event and traffic logs.
When a WiFi client connects to a tunnel or local-bridge mode SSID on an FortiAP that is managed by a FortiGate, signal-
to-noise ratio and signal strength details are included in WiFi event logs for local-bridge traffic statistics and
authentication, and in forward traffic logs for tunnel traffic. This allows you to store and view clients' historical signal
strength and signal-to-noise ratio information.
1. Go to Log & Report > Events and select WiFi Events from the events drop-down list.
The Signal and Signal/Noise columns show the signal strength and signal-to-noise ratio for each applicable client.
2. WiFi event log messages include the signal and snr values:
date=2020-05-27 time=11:26:28 logid="0104043579" type="event" subtype="wireless"
level="notice" vd="vdom1" eventtime=1590603988877156921 tz="-0700" logdesc="Wireless
client IP assigned" sn="FP231ETF20000455" ap="FP231ETF20000455" vap="stability3"
ssid="FOS_QA_Starr_140E_Guest-11" radioid=1 user="N/A" group="N/A"
stamac="1c:87:2c:b6:a8:49" srcip=11.10.80.2 channel=6 radioband="802.11n,g-only"
signal=-45 snr=50 security="WPA2 Personal" encryption="AES" action="client-ip-detected"
reason="Reserved 0" mpsk="N/A" msg="Client 1c:87:2c:b6:a8:49 had an IP address detected
(by DHCP packets)."
date=2020-05-27 time=11:26:11 logid="0104043573" type="event" subtype="wireless"
level="notice" vd="vdom1" eventtime=1590603970962702892 tz="-0700" logdesc="Wireless
client authenticated" sn="FP231ETF20000455" ap="FP231ETF20000455" vap="stability3"
ssid="FOS_QA_Starr_140E_Guest-11" radioid=1 user="N/A" group="N/A"
stamac="1c:87:2c:b6:a8:49" srcip=0.0.0.0 channel=6 radioband="802.11n,g-only" signal=-45
snr=50 security="WPA2 Personal" encryption="AES" action="client-authentication"
reason="Reserved 0" mpsk="N/A" msg="Client 1c:87:2c:b6:a8:49 authenticated."
2. Forward traffic log messages include the signal and snr values:
date=2020-05-27 time=11:30:26 logid="0000000013" type="traffic" subtype="forward"
level="notice" vd="vdom1" eventtime=1590604226533016978 tz="-0700" srcip=11.10.80.2
srcname="WIFI23" srcport=53926 srcintf="stability3" srcintfrole="lan" srcssid="FOS_QA_
Starr_140E_Guest-11" apsn="FP231ETF20000455" ap="FP231ETF20000455" channel=6
radioband="802.11n,g-only" signal=-31 snr=64 dstip=91.189.91.157 dstport=123
dstintf="wan1" dstintfrole="wan" srccountry="United States" dstcountry="United States"
sessionid=322069 proto=17 action="accept" policyid=13 policytype="policy"
poluuid="7c14770c-1456-51e9-4c57-806e9c499782" policyname="wmm" service="NTP"
trandisp="snat" transip=172.16.200.111 transport=53926 appid=16270 app="NTP"
appcat="Network.Service" apprisk="elevated" applist="g-default" duration=180 sentbyte=76
rcvdbyte=76 sentpkt=1 rcvdpkt=1 utmaction="allow" countapp=1 osname="Linux"
mastersrcmac="1c:87:2c:b6:a8:49" srcmac="1c:87:2c:b6:a8:49" srcserver=0 utmref=65534-66
To verify local-bridge traffic statistics when a client is connecting to a local-bridge mode SSID:
1. Go to Log & Report > Events and select WiFi Events from the events drop-down list.
The Signal and Signal/Noise columns show the signal strength and signal-to-noise ratio for each applicable client.
2. WiFi event log messages include the signal and snr values:
date=2020-05-26 time=17:48:57 logid="0104043687" type="event" subtype="wireless"
level="information" vd="vdom1" eventtime=1590540537841497433 tz="-0700" logdesc="Traffic
stats for station with bridge wlan" sn="FP231ETF20000455" ap="FP231ETF20000455"
vap="wifi.fap.01" ssid="FOS_QA_Starr-140E-LB-cap-2" srcip=10.128.100.4 user="N/A"
stamac="00:1e:e5:df:b1:63" signal=-53 snr=52 sentbyte=8970016 rcvdbyte=985910
nextstat=300 action="sta-wl-bridge-traffic-stats" msg="Traffic stats for bridge ssid
client 00:1e:e5:df:b1:63"
FortiGate can use RSSO accounting information from authenticated RSSO users to populate destination users and
groups, along with source users and groups.
RSSO user login information can be forwarded by the RADIUS server to the FortiGate that is listening for incoming
RADIUS accounting start messages on the RADIUS accounting port. Accounting start messages usually contain the
IP address, user name, and user group information. FortiGate uses this information in traffic logs, which include dstuser
and dstgroup fields for user and group destination information .
For instructions on configuring RSSO, see RADIUS single sign-on agent on page 348.
The three following scenarios show traffic between pc1 and the internet, and pc1 and pc2.
Scenario 1
In this scenario, RSSO user test2 in group rsso-grp1 is authenticated on pc1. Traffic flows from pc1 to the internet.
Expected result:
In the logs, user test2 is shown as the source user in the rsso-grp1 group.
1. In the GUI, go to Log & Report > Forward Traffic and view the details of an entry with test2 as the source.
2. In the Source section, User is test2 and Group is the rsso-grp1.
Scenario 2
In this scenario, RSSO user test2 is authenticated on pc1. Traffic is initialized on pc2 (172.16.200.185) going to pc1
(10.1.100.188).
Expected result:
In the logs, user test2 is shown as the destination user (dstuser). No destination group (dstgroup) is logged because
no RSSO user is logged in on pc2, so the traffic from pc2 is unauthenticated.
1. In the GUI, go to Log & Report > Forward Traffic and view the details of an entry with 172.16.200.185 (pc2) as the
source.
2. In the Other section, Destination User is test2 and no destination group is shown.
Scenario 3
In this scenario, RSSO user test2 in group rsso-grp1 is authenticated on pc1, and user test3 in group rsso-grp2 is
authenticated on pc2. Traffic flows from pc2 to pc1.
Expected result:
In the logs, user test3 is shown as the source user in the rsso-grp1 group. User test2 is shown as destination user
(dstuser) in the rsso-grp1 destination group (dstgroup). The destination group is logged because an RSSO user is
logged in to pc2.
1. In the GUI, go to Log & Report > Forward Traffic and view the details of an entry with 172.16.200.185 (pc2) as the
source.
2. In the Source section, User is test3 and Group is the rsso-grp2. In the Other section, Destination User is test2 and
Destination Group is rsso-grp1.
3. The log message shows both the source and the destination users and groups:
8: date=2020-05-25 time=14:23:07 logid="0000000013" type="traffic" subtype="forward"
level="notice" vd="vdom1" eventtime=1590441786958007914 tz="-0700" srcip=172.16.200.185
srcport=64096 srcintf="port9" srcintfrole="undefined" dstip=10.1.100.188 dstport=80
dstintf="port10" dstintfrole="undefined" srccountry="Reserved" dstcountry="Reserved"
sessionid=112445 proto=6 action="close" policyid=3 policytype="policy"
poluuid="5894c368-9eca-51ea-fb4c-ec5a6c1d5043" policyname="pol2" user="test3"
group="rsso-grp2" authserver="vdom1" dstuser="test2" dstgroup="rsso-grp1"
dstauthserver="vdom1" service="HTTP" trandisp="snat" transip=10.1.100.1 transport=64096
duration=1 sentbyte=328 rcvdbyte=563 sentpkt=6 rcvdpkt=5 appcat="unscanned"
dsthwvendor="VMware" dstosname="Windows" dstswversion="7"
masterdstmac="00:0c:29:44:be:b9" dstmac="00:0c:29:44:be:b9" dstserver=0
Threat weight
Threat weight helps aggregate and score threats based on user-defined severity levels. It adds several fields such as
threat level (crlevel), threat score (crscore), and threat type (craction) to traffic logs. Threat weight logging is
enabled by default and the settings can be customized. Threats can be viewed from the Top Threats FortiView
dashboard.
1. In the tree menu, click Dashboard and in the FortiView section, click the + sign. The Add Monitor pane opens.
2. In the Security section, enable Show More and click Top Threats.
3. Configure the settings as needed.
4. Click Add Monitor.
5. Go to Dashboard > Top Threats. The Top Threats monitor displays threats based on the scores in the traffic logs.
Troubleshooting
The following topics provide information about troubleshooting logging and reporting:
l Log-related diagnose commands on page 1790
l Backing up log files or dumping log messages on page 1796
l SNMP OID for logs that failed to send on page 1798
l The following commands enable debugging log daemon (miglogd) at the proper debug level:
diagnose debug application miglogd x
diagnose debug enable
l The following commands display different status/statistics of miglogd at the proper level:
diagnose test application miglogd x
diagnose debug enable
To get the list of available levels, press Enter after diagnose test/debug application miglogd. The following
are some examples of commonly use levels.
If the debug log display does not return correct entries when log filter is set:
diagnose debug application miglogd 0x1000
For example, use the following command to display all login system event logs:
execute log filter device disk
execute log filter category event
execute log filter field action login
Files to be searched:
file_no=65523, start line=0, end_line=237
file_no=65524, start line=0, end_line=429
file_no=65525, start line=0, end_line=411
file_no=65526, start line=0, end_line=381
file_no=65527, start line=0, end_line=395
file_no=65528, start line=0, end_line=458
file_no=65529, start line=0, end_line=604
file_no=65530, start line=0, end_line=389
file_no=65531, start line=0, end_line=384
session ID=1, total logs=3697
back ground search. process ID=26240, session_id=1
start line=1 view line=10
( action "login" )
ID=1, total=3697, checked=238, found=5
ID=1, total=3697, checked=668, found=13
ID=1, total=3697, checked=1080, found=23
ID=1, total=3697, checked=1462, found=23
ID=1, total=3697, checked=1858, found=23
ID=1, total=3697, checked=2317, found=54
ID=1, total=3697, checked=2922, found=106
ID=1, total=3697, checked=3312, found=111
ID=1, total=3697, checked=3697, found=114
You can check and/or debug the FortiGate to FortiAnalyzer connection status.
......
<16208> _send_queue_item()-523: type=3, cat=1, logcount=1, len=301
<16206> _oftp_recv()-1348: opt=78, opt_len=55
......
<16206> _build_ack()-784: xfer_status changed from 1 to 2 for global-faz
<16206> _process_response()-960: checking opt code=81
......
<16206> _send_queue_item()-523: type=1, cat=0, logcount=0, len=0
<16206> _oftp_send()-487: dev=global-faz type=1 pkt_len=24
......
To check real-time log statistics by log type since the miglogd daemon start:
report
event: logs=1244 len=225453, Sun=246 Mon=247 Tue=197 Wed=0 Thu=61 Fri=246 Sat=247
faz
event: logs=6 len=1548, Sun=0 Mon=0 Tue=6 Wed=0 Thu=0 Fri=0 Sat=0 compressed=5446
disk
traffic: logs=462 len=389648, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75
compressed=134638
event: logs=2262 len=550957, Sun=382 Mon=412 Tue=307 Wed=0 Thu=306 Fri=459 Sat=396
compressed=244606
app-ctrl: logs=16 len=9613, Sun=3 Mon=3 Tue=3 Wed=0 Thu=0 Fri=5 Sat=2 compressed=3966
dns: logs=71 len=29833, Sun=0 Mon=0 Tue=0 Wed=0 Thu=71 Fri=0 Sat=0 compressed=1499
report
traffic: logs=462 len=375326, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75
event: logs=3733 len=1057123, Sun=670 Mon=700 Tue=531 Wed=0 Thu=401 Fri=747 Sat=684
app-ctrl: logs=16 len=9117, Sun=3 Mon=3 Tue=3 Wed=0 Thu=0 Fri=5 Sat=2
faz
traffic: logs=462 len=411362, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75
compressed=307610
event: logs=3733 len=1348297, Sun=670 Mon=700 Tue=531 Wed=0 Thu=401 Fri=747 Sat=684
compressed=816636
app-ctrl: logs=16 len=10365, Sun=3 Mon=3 Tue=3 Wed=0 Thu=0 Fri=5 Sat=2 compressed=8193
dns: logs=71 len=33170, Sun=0 Mon=0 Tue=0 Wed=0 Thu=71 Fri=0 Sat=0 compressed=0
To check log statistics to the local/remote log device since the miglogd daemon start:
To check the remote queue and see the maximum buffered memory size:
VDOM:root
Queue for: global-faz
memory queue:
num:0 size:0(0MB) max:105405644(100MB) logs:0
memory queue:
num:0 size:0(0MB) max:97852620(93MB) logs:0
When a log issue is caused by a particular log message, it is very help to get logs from that FortiGate. This topic provides
steps for using execute log backup or dumping log messages to a USB drive.
This command backs up all disk log files and is only available on FortiGates with an SSD disk.
Before running execute log backup, we recommend temporarily stopping miglogd and reportd.
Or
1. Determine the process, or thread, ID (PID) of miglogd and reportd:
# diagnose sys top 10 99
When a syslog server encounters low-performance conditions and slows down to respond, the buffered syslog
messages in the kernel might overflow after a certain number of retransmissions, causing the overflowed messages to
be lost. OIDs track the lost messages or failed logs.
SNMP query OIDs include log statistics for global log devices:
l FORTINET-FORTIGATE-MIB:fortinet.fnFortiGateMib.fgLog.fgLogDeviceNumber 1.3.6.1.4.1.12356.101.21.1.1
l FORTINET-FORTIGATE-
MIB:fortinet.fnFortiGateMib.fgLog.fgLogDevices.fgLogDeviceTable.fgLogDeviceEntry.fgLogDeviceEntryIndex
1.3.6.1.4.1.12356.101.21.2.1.1.1
l FORTINET-FORTIGATE-
MIB:fortinet.fnFortiGateMib.fgLog.fgLogDevices.fgLogDeviceTable.fgLogDeviceEntry.fgLogDeviceEnabled
1.3.6.1.4.1.12356.101.21.2.1.1.2
l FORTINET-FORTIGATE-
MIB:fortinet.fnFortiGateMib.fgLog.fgLogDevices.fgLogDeviceTable.fgLogDeviceEntry.fgLogDeviceName
1.3.6.1.4.1.12356.101.21.2.1.1.3
l FORTINET-FORTIGATE-
MIB:fortinet.fnFortiGateMib.fgLog.fgLogDevices.fgLogDeviceTable.fgLogDeviceEntry.fgLogDeviceSentCount
1.3.6.1.4.1.12356.101.21.2.1.1.4
l FORTINET-FORTIGATE-
MIB:fortinet.fnFortiGateMib.fgLog.fgLogDevices.fgLogDeviceTable.fgLogDeviceEntry.fgLogDeviceRelayedCount
1.3.6.1.4.1.12356.101.21.2.1.1.5
l FORTINET-FORTIGATE-
MIB:fortinet.fnFortiGateMib.fgLog.fgLogDevices.fgLogDeviceTable.fgLogDeviceEntry.fgLogDeviceCachedCount
1.3.6.1.4.1.12356.101.21.2.1.1.6
l FORTINET-FORTIGATE-
MIB:fortinet.fnFortiGateMib.fgLog.fgLogDevices.fgLogDeviceTable.fgLogDeviceEntry.fgLogDeviceFailedCount
1.3.6.1.4.1.12356.101.21.2.1.1.7
l FORTINET-FORTIGATE-
MIB:fortinet.fnFortiGateMib.fgLog.fgLogDevices.fgLogDeviceTable.fgLogDeviceEntry.fgLogDeviceDroppedCount
1.3.6.1.4.1.12356.101.21.2.1.1.8
Where:
l fgLogDeviceNumber is the number of devices in the table.
l fgLogDeviceEnabled is either 1 or 0, indicating whether the device is enabled.
l fgLogDeviceName is the name of the device.
A FortiGate connected to a syslog server or FortiAnalyzer generates statistics that can be seen using the diagnose
test application miglogd command:
(global) # diagnose test application miglogd 6
mem=404, disk=657, alert=0, alarm=0, sys=920, faz=555, webt=0, fds=0
interface-missed=460
Queues in all miglogds: cur:0 total-so-far:526
global log dev statistics:
syslog 0: sent=254, failed=139, relayed=0
syslog 1: sent=220, failed=139, relayed=0
syslog 2: sent=95, failed=73, relayed=0
faz 0: sent=282, failed=0, cached=0, dropped=0 , relayed=0
Num of REST URLs: 3
/api/v2/monitor/system/csf/ : 0 : 300
/api/v2/cmdb/system/interface/ : 394.0.673.15877729363538323653.1547149763 : 1200
/api/v2/monitor/system/ha-checksums/ : 0 : 1200
faz 1: sent=272, failed=0, cached=0, dropped=0 , relayed=0
Num of REST URLs: 2
/api/v2/monitor/system/csf/ : 0 : 300
/api/v2/cmdb/system/interface/ : 394.0.673.15877729363538323653.1547149763 : 1200
The same statistics are also available in snmpwalk/snmpget on the OID 1.3.6.1.4.1.12356.101.21.
snmpwalk -v2c -c REGR-SYS 172.16.200.1 1.3.6.1.4.1.12356.101.21
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.1.1.0 = INTEGER: 9
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.0 = INTEGER: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.1 = INTEGER: 1
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.2 = INTEGER: 2
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.3 = INTEGER: 3
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.4 = INTEGER: 4
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.5 = INTEGER: 5
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.6 = INTEGER: 6
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.7 = INTEGER: 7
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.1.8 = INTEGER: 8
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.0 = INTEGER: 1
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.1 = INTEGER: 1
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.2 = INTEGER: 1
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.3 = INTEGER: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.4 = INTEGER: 1
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.5 = INTEGER: 1
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.6 = INTEGER: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.7 = INTEGER: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.2.8 = INTEGER: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.0 = STRING: "syslog"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.1 = STRING: "syslog2"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.2 = STRING: "syslog3"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.3 = STRING: "syslog4"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.4 = STRING: "faz"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.5 = STRING: "faz2"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.6 = STRING: "faz3"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.7 = STRING: "webtrends"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.3.8 = STRING: "fds"
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.0 = Counter32: 254
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.1 = Counter32: 220
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.2 = Counter32: 95
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.3 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.4 = Counter32: 282
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.5 = Counter32: 272
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.6 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.7 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.4.8 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.0 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.1 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.2 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.3 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.4 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.5 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.6 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.7 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.5.8 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.0 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.1 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.2 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.3 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.4 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.5 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.6 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.7 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.6.8 = Gauge32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.0 = Counter32: 139
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.1 = Counter32: 139
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.2 = Counter32: 73
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.3 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.4 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.5 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.6 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.7 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.7.8 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.0 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.1 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.2 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.3 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.4 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.5 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.6 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.7 = Counter32: 0
FORTINET-FORTIGATE-MIB::fnFortiGateMib.21.2.1.1.8.8 = Counter32: 0
To get the present state of the logging device that is attached to the FortiGate:
Microsoft Azure
Oracle OCI
AliCloud
Private cloud
VM license
The FortiGate VM License page is accessible from the Dashboard > Status page in the Virtual Machine widget. Click the
device license and select FortiGate VM License.
Field Description
FortiGuard server. A check is made against how many days the warning
status is continuous. If the number is less than 30 days, the status does not
change.
l Invalid: the VM cannot connect and validate against a FortiManager or
FortiGuard server. A check is made against how many days the warning
status is continuous. If the number is 30 days or more, the status changes to
invalid. GUI access is restricted until a valid license is uploaded. Firewall
policies will not work. FortiGuard downloads are not available.
l Pending: a temporary state where the VM is attempting to validate its license.
FortiGuard server.
l The license might be expired. Check the expiration date for evaluation or
term-based licenses.
l Another VM has been already validated with FortiGuard using the same
Allocated RAM Amount of allocated RAM (in FortiOS 6.2.2 and later, there are no RAM
restrictions)
This information is visible in the CLI by running get system status (see CLI troubleshooting).
After you submit an order for a FortiGate-VM, Fortinet sends a license registration code to the email address that you
entered in the order form. Use this code on the FortiCloud portal to register the FortiGate-VM.
Once the VM is registered, you can download the license file in .LIC format. On the FortiGate VM License page, click
Upload. The system will prompt you to reboot and validate the license with the FortiGuard server. Once validated, your
FortiGate-VM is fully functional.
The VM license window may also appear immediately after logging in if you are running a VM with an evaluation license
that has expired.
In cases where the GUI is not accessible, you can upload the license using secure copy (SCP).
For information about injecting Flex-VM license tokens, see Injecting tokens into FortiGate-VM
in the Flex VM Deployment Guide.
1. Enable SCP:
config system global
set admin-scp enable
end
2. Enable SSH in the administrative access for the interface where the transfer will take place:
config system interface
edit <interface>
append allowaccess ssh
next
end
Types of VM licenses
FortiGate-VM offers perpetual licensing (normal series and V-series) and annual subscription licensing (S-series). SKUs
are based on the number of vCPUs (1, 2, 4, 8, 16, 32, or unlimited).
The Flex-VM program allows qualified enterprise and MSSP customers to create as many VM entitlements as required.
Resource consumption is based upon predefined points that are calculated on a daily basis. For information, see the
Flex-VM Program Guide in the Fortinet document library.
l UTM
l Enterprise
l 360 Protection
vCPU number Not supported. Supported. You can Supported. You can
upgrade during also upgrade the apply different VM
contracted term support service entitlement
bundle. configurations in the
Contact a Fortinet Flex-VM portal. API
sales representative is not supported at
to upgrade. this time.
VDOM support By default, each CPU By default, all CPU levels do not support
level supports up to a adding VDOMs.
certain number of
VDOMs.
Refer to the
FortiGate-VM data
sheet for default
limits.
CLI troubleshooting
In some cases, more information can be viewed from the CLI to diagnose issues with VM licensing. This is also useful
when the GUI is inaccessible due to an invalid contract.
Before you begin, ensure your FortiGate has the proper routes to connect to the internet.
Cert2: yes
Model: 08 (11)
CPU: 8
MEM: 2147483647
This combination indicates the license is valid but may be running a duplicate instance:
valid: 1
status: 4
code: 401
This guide shows how to configure Fabric connectors and resolve dynamic firewall addresses through the configured
Fabric connector in FortiOS.
FortiOS supports multiple Fabric connectors including public connectors (AWS, Azure, GCP, OCI, AliCloud) and private
connectors (Kubernetes, VMware ESXi, VMware NSX, OpenStack, Cisco ACI, Nuage). FortiOS also supports multiple
instances for each type of Fabric connector.
This guide uses an Azure Fabric connector as an example. The configuration procedure for all supported Fabric
connectors is the same. In the following topology, the FortiGate accesses the Azure public cloud through the Internet:
This process creates two Fabric connector firewall addresses to associate with the configured Fabric connectors.
1. Go to Policy & Objects > Addresses.
2. Click Create New > Address. Configure the first Fabric connector firewall address:
a. In the Name field, enter azure-address-1.
b. From the Type dropdown list, select Fabric Connector address.
c. From the SDN Connector dropdown list, select azure1.
d. For SDN address type, select Private.
e. From the Filter dropdown list, select the desired filter.
f. For Interface, select any.
g. Click OK.
3. Click Create New > Address. Configure the second Fabric connector firewall address:
a. In the Name field, enter azure-address-1.
b. From the Type dropdown list, select Fabric Connector address.
c. From the SDN Connector dropdown list, select azure2.
d. For SDN address type, select Private.
e. From the Filter dropdown list, select the desired filter.
f. For Interface, select any.
g. Click OK.
Run the show sdn connector status command. Both Fabric connectors should appear with a status of connected.
Run the diagnose debug application azd -1 command. The output should look like the following:
Level2-downstream-D # diagnose debug application azd -1
...
azd sdn connector azure1 start updating IP addresses
azd checking firewall address object azure-address-1, vd 0
IP address change, new list:
10.18.0.4
...
To restart the Azure Fabric connector daemon, run the diagnose test application azd 99 command.
Each FortiGate-VM base license type allows a default number of VDOMs. This topic provides sample procedures to add
VDOMs beyond the default number using separately purchased VDOM licenses.
This topic consists of the following steps:
1. Activate the FortiGate-VM with the base license.
2. Add more VDOMs to the FortiGate-VM.
You can repeat this procedure multiple times to stack multiple VDOM licenses on the same FortiGate-VM.
1. Purchase and register the FortiGate-VM upgrade license in FortiCare. This example adds 15 VDOMs:
a. Purchase the FortiGate-VM upgrade license from Fortinet or a Fortinet reseller.
b. You receive a license certification with a registration code. Open the certification.
c. Log in to Fortinet Customer Service & Support.
d. Go to Asset > Register/Activate and enter the provided registration code.
e. On the Specify License Confirmation Information screen, enter the FortiGate-VM serial number to apply the
VDOM upgrade license to the FortiGate-VM. In this example, the FortiGate-VM serial number is
FGVM4VTM19000476.
FortiGate-VM had the default VDOM configuration, then you add 15 VDOMs, FortiOS displays the maximum
VDOM number as 15, not 16.
# get system status
Version: FortiGate-VM64-KVM v6.4.4,build1803,201209 (GA)
Virus-DB: 82.00644(2020-12-18 12:20)
Extended DB: 82.00644(2020-12-18 12:20)
Extreme DB: 1.00000(2018-04-09 18:07)
IPS-DB: 16.00982(2020-12-17 01:04)
IPS-ETDB: 0.00000(2001-01-01 00:00)
APP-DB: 16.00982(2020-12-17 01:04)
INDUSTRIAL-DB: 6.00741(2015-12-01 02:30)
Serial-Number: FGVM02TM20000000
IPS Malicious URL Database: 2.00862(2020-12-18 06:12)
License Status: Invalid Copy
License Expiration Date: 2021-10-02
VM Resources: 2 CPU/2 allowed, 2010 MB RAM
Log hard disk: Available
Hostname: FGDocs
Private Encryption: Disable
Operation Mode: NAT
Current virtual domain: root
Max number of virtual domains: 1
Virtual domains status: 1 in NAT mode, 0 in TP mode
Virtual domain configuration: disable
FIPS-CC mode: disable
Current HA mode: standalone
Branch point: 1803
Release Version Information: GA
FortiOS x86-64: Yes
System time: Fri Dec 25 13:24:20 2020
Fortinet's Terraform support provides customers with more ways to efficiently deploy, manage, and automate security
across physical FortiGate appliances and virtual environments. You can use Terraform to automate various IT
infrastructure needs, thereby diminishing mistakes from repetitive manual configurations.
For example, if Fortinet is releasing a new FortiOS version, your organization may require you to test a new functionality
to determine how it may impact the environment before globally deploying the new version. In this case, the ability to
rapidly stand up environments and test these functions prior to production environment integration provides a resource-
efficient and fault-tolerant approach.
The following example demonstrates how to use the Terraform FortiOS provider to perform simple configuration
changes on a FortiGate unit. It requires the following:
l FortiOS 6.0 or later
l FortiOS Provider: This example uses terraform-provider-fortios 1.0.0.
l Terraform: This example uses Terraform 0.11.14.
l REST API administrator created on the FortiGate with the API key
For more information, see the Terraform FortiOS Provider at https://www.terraform.io/docs/providers/fortios/index.html.
1. On the FortiGate, go to System > Administrators and click Create New > REST API Admin.
2. Enter the Username and, optionally, enter Comments.
3. Select an Administrator Profile.
4. We recommend that you create a new profile with minimal privileges for this terraform script:
a. In the Administrator Profile drop down click Create New.
b. Enter a name for the profile.
c. Configure the Access Permissions:
l None: The REST API is not permitted access to the resource.
l Read: The REST API can send read requests (HTTP GET) to the resource.
l Read/Write: The REST API can send read and write requests (HTTP GET/POST/PUT/DELETE) to the
resource.
d. Click OK.
5. Enter Trusted Hosts to specify the devices that are allowed to access this FortiGate.
6. Click OK.
An API key is displayed. This key is only shown once, so you must copy and store it securely.
4. Create the resources for configuring your DNS object and adding a static route:
resource "fortios_system_setting_dns" "test1" {
primary = "172.16.95.16"
secondary = "8.8.8.8"
}
resource "fortios_networking_route_static" "test1" {
dst = "110.2.2.122/32"
gateway = "2.2.2.2"
blackhole = "disable"
distance = "22"
weight = "3"
priority = "3"
device = "port2"
comment = "Terraform test"
}
8. Enter terraform plan to parse the configuration file and read from the FortiGate configuration to see what
Terraform changes:
This example create a static route and updates the DNS address. You can see that Terraform reads the DNS
addresses from the FortiGate and then lists them.
root@mail:/home/terraform# terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
fortios_networking_route_static.test1: Refreshing state... (ID: 2)
fortios_system_setting_dns.test1: Refreshing state... (ID: 208.91.112.53)
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
~ update in-place
Terraform will perform the following actions:
+ fortios_networking_route_static.test1
id: <computed>
blackhole: "disable"
comment: "Terraform test"
device: "port2"
distance: "22"
dst: "110.2.2.122/32"
gateway: "2.2.2.2"
priority: "3"
weight: "3"
~ fortios_system_setting_dns.test1
primary: "208.91.112.53" => "172.16.95.16"
secondary: "208.91.112.22" => "8.8.8.8"
Plan: 1 to add, 1 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
If you are running terraform-provider-fortios 1.1.0, you may see the following error:
Error: Error getting CA Bundle, CA Bundle should be set when
insecure is false.
In this case, add the following line to the FortiOS provider configuration in the test.tf file:
insecure = "true"
b. Entering terraform apply deletes the static route that is commented out of the configuration file, and
reverts the DNS address to the old address:
root@mail:/home/terraform# terraform apply
fortios_system_setting_dns.test1: Refreshing state... (ID: 172.16.95.16)
fortios_networking_route_static.test1: Refreshing state... (ID: 2)
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
- destroy
Terraform will perform the following actions:
- fortios_networking_route_static.test1
~ fortios_system_setting_dns.test1
primary: "172.16.95.16" => "208.91.112.53"
secondary: "8.8.8.8" => "208.91.112.22"
Plan: 0 to add, 1 to change, 1 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
fortios_networking_route_static.test1: Destroying... (ID: 2)
fortios_system_setting_dns.test1: Modifying... (ID: 172.16.95.16)
primary: "172.16.95.16" => "208.91.112.53"
secondary: "8.8.8.8" => "208.91.112.22"
fortios_networking_route_static.test1: Destruction complete after 0s
fortios_system_setting_dns.test1: Modifications complete after 0s (ID: 208.91.112.53)
Apply complete! Resources: 0 added, 1 changed, 1 destroyed.
Troubleshooting
Use the HTTPS daemon debug to begin troubleshooting why a configuration was not accepted:
# diagnose debug enable
# diagnose debug application httpsd -1
The REST API 403 error means that your administrator profile does not have sufficient
permissions.
The REST API 401 error means that you do not have the correct token or trusted host.
FortiGate guest VM supports Physical function (PF) and virtual function (VF) PCI passthrough and SR-IOV drivers.
PF provides the ability for PCI passthrough, but requires an entire Network Interface Card (NIC) for a VM. It can usually
achieve greater performance than a VF-based SR-IOV. PF is also expensive. While VF allows multiple guests VMs to
share one NIC, PF is allocated to one port on a VM.
The supported driver versions are:
Other hypervisors, such as Xen or Microsoft Hyper-V, may work with vSPU, although they are
unverified.
All tools and software utilities for UEFI 1.X have been removed from 6.2.0 and later releases.
Update to UEFI 2.x to use the UEFI tools or software utilities.
You perform the configuration to use PF or VF on the hypervisor, and do not configure it on the FortiGate.
OCI IMDSv2 offers increased security for accessing instance metadata compared to IMDSv1. IMDSv2 is used in OCI
SDN connectors and on instance deployments with bootstrap metadata. When upgrading from previous FortiOS builds
with legacy IMDSv1 endpoints, the endpoints will be updated to IMDSv2, and the same calls can be made.
The following use cases illustrate IMDSv2 support on the FortiGate-VM.
1. In OCI, deploy an instance using IMDSv2 with bootstrap metadata. There are two methods to enable IMDSv2 :
l Use the OCI command line to deploy an instance using user-data. This example uses a MIME file that
contains the license and configuration, as well as a JSON file that specifies to disable V1 metadata.
oci compute instance launch
--availability-domain wwwl:US-ASHBURN-AD-1
--compartment-id
ocid1.tenancy.oc1..aaaaaaaaaaa3aaaaaaaaaaaaaaaaa7xxxxxxx54aaaaaa4xxxxxxxx55xxxa
--display-name fos-byol-v6.4.6-b2290-emulated
--image-id
ocid1.image.oc1.iad.aaaaaaaa6xxx43xxxxxxxxx7aaaaaaaaaaaaaaaaaaaa3xxxxxxxxxxxxxxx
--subnet-id
ocid1.subnet.oc1.iad.aaaaaaaaxxxxxxxxx2xxxxxxxxxxxxxxxxxxxx5aaa4xxxxxxxxxxxx42aaa
--shape VM.Standard1.4
--assign-public-ip true
--user-data-file /home/oci/userdata/mime.txt
--ssh-authorized-keys-file /home/oci/userdata/myfirstkeypair.pub
--instance-options file://home/oci/scripts/metadatav2.json
root@mail:/home/oci/scripts# cat metadatav2.json
{
"areLegacyImdsEndpointsDisabled": true
}
l While the instance is running, edit the instance metadata service version in the GUI ,and change the allowed
IMDS version to VERSION 2 ONLY (see Getting Instance Metadata in the OCI documentation).
2. The FortiGate will use the metadata v2 endpoints to get the metadata bootstrap information. In FortiOS, verify this
by running the following after bootup:
# diagnose debug cloudinit show
To configure an SDN connector with meta-IAM enabled and firewall addresses to obtain dynamic
addresses:
1. Configure an IAM policy and dynamic group (see How Policies Work and Managing Dynamic Groups in the OCI
documentation).
2. In FortiOS, configure the OCI Fabric connector (see OCI SDN connector using certificates on page 323 for detailed
instructions):
a. Create the SDN connector.
b. Verify that the OCI connector comes up (Security Fabric > External Connectors page indicates the status is
up).
c. Configure a dynamic firewall address with a filter.
d. Verify the dynamic firewall address is resolved by the SDN connector.
# execute update-eip
instance: fos-byol-v6.4.6-b2290-emulated
vnic0: fos-byol-v6.4.6-b2290-emulated
10.0.0.58 (129.213.138.192)
port1: 10.0.0.58, eip: 129.213.138.192
EIP is updated successfully
FIPS cipher mode for AWS, Azure, OCI, and GCP FortiGate-VMs
AWS, Azure, OCI, and GCP FortiGate-VMs support FIPS cipher mode. You must remove all VPN configurations before
you can enable FIPS CC mode.
FIPS cipher mode only allows a restricted set of ciphers for features that require encryption, such as SSH, IPsec and
SSL VPN, and HTTPS. You cannot use insecure protocols such as Telnet, TFTP, and HTTP to access the FortiGate-
VM.
You must perform a factory reset to disable fips-ciphers mode.
The following behavior occurs when you enable FIPS cipher mode:
l You can restore a license, image, configuration, and so on from an FTP server.
l The following options are available:
l aes256gcm-prfsha384
l aes256gcm-prfsha384
l aes256gcm-prfsha512
l aes256gcm-prfsha512
l secp384r1
l secp521r1
DH group:
l RFC3526/Oakley group 14 (2048 bits)
l secp384r1
l secp521r1
Troubleshooting
This section is intended for administrators with super_admin permissions who require assistance with basic and
advanced troubleshooting. Admins with other types of permissions may not be able to perform all of the tasks in this
section.
This section contains the following troubleshooting topics:
l Troubleshooting methodologies on page 1823
l Troubleshooting scenarios on page 1827
l Checking the system date and time on page 1828
l Identifying the XAUI link used for a specific traffic stream on page 1861
Troubleshooting methodologies
The sections in this topic provide an overview of how to prepare to troubleshoot problems in FortiGate. They include
verifiying your user permissions, establishing a baseline, defining the problem, and creating a plan.
If you are using a FortiGate that has virtual domains (VDOMs) enabled, you can often
troubleshoot within your own VDOM. However, you should inform the super_admin for the
FortiGate that you willl be performing troubleshooting tasks.
You may also need access to other networking equipment, such as switches, routers, and
servers to carry out tests. If you do not have access to this equipment, contact your network
administrator for assistance.
Establish a baseline
FortiGate operates at all layers of the OSI model. For this reason, troubleshooting can be complex. Establishing baseline
parameters for your system before a problem occurs helps to reduce the complexity when you need to troubleshoot.
A best practice is to establish and record the normal operating status. Regular operation data shows trends, and allows
you to see where changes occur when problems arise. You can gather this data by using logs and SNMP tools to
monitor the system performance or by regularly running information gathering commands and saving the output.
You should back up your FortiOS configuration on a regular basis even when you are not
troubleshooting. You can restore the backed up configuration as needed to save time
recreating it from the factory default settings.
Use the following CLI commands to obtain normal operating data for a FortiGate:
get system status Displays firmware versions and FortiGuard engine versions, and
other system information.
get system performance status Displays CPU and memory states, average network usage, average
sessions and session setup rate, viruses caught, IPS attacks blocked,
and uptime.
get hardware memory Displays information about memory.
get system session status Displays total number of sessions.
get router info routing-table all Displays all the routes in the routing table, including their type,
source, and other useful data.
get ips session Displays memory used and maximum amount available to IPS as well
as counts
get webfilter ftgd-statistics Displays a list of FortiGuard related counts of status, errors, and other
data.
diagnose sys session list Displays the list of current detailed sessions.
show sys dns Displays the configured DNS servers.
diagnose sys ntp status Displays information about NTP servers.
You can run any commands that apply to your system for information gathering. For example, if you have active VPN
connections, use the get vpn series of commands to get more information about them.
Use execute tac report to get an extensive snapshot of your system. This command runs many diagnostic
commands for specific configurations. It also records the current state of each feature regardless of the features
deployed on your FortiGate. If you need to troubleshoot later, you can run the same command again and compare the
differences to identify any suspicious output.
The following questions are intended to compare the current behavior of the FortiGate with normal operations to help
you define the problem. Be specific with your answers. After you define the problem, search for a solution in the
troubleshooting scenarios section, and then create a plan to resolve it.
What is the problem? The problem being observed may not be the actual problem. You should
determine where the problem lies before starting to troubleshoot the FortiGate.
Was the device working If the device never worked, it might be defective. For more information, see
before? Troubleshooting your installation on page 58.
Can the problem be If the problem is intermittent, it may be dependent on system load.
reproduced? Intermittent problems are challenging to troubleshoot because they are difficult to
reproduce.
What has changed? Use the FortiGate event log to identify possible configuration changes.
There may be changes in the operating environment. For example, there might be
a gradual increase in load as more sites are forwarded through the firewall.
If something has changed, roll back the change and assess the impact.
What is the scope of the After you isolate the problem, determine what applications, users, devices, and
problem? operating systems the problem affects.
The following questions are intended to narrow the scope of the problem and
identify what to check during troubleshooting. The more factors you can eliminate,
the less you need to check. For this reason, be as specific and accurate as
possible when gathering information.
l What is not working?
l When did the problem occur and to which users or groups of users?
After you define the problem and its scope, develop a troubleshooting plan.
Create checklist Make a list all the possible causes of the problem and how you can test for each
cause.
Create a checklist to keep track of what has been tried and what is left to test.
Checklists are useful when more than one person is performing troubleshooting
tasks.
Obtain the required equipment Testing your solution may require additional networking equipment, computers, or
other devices.
Network administrators usually have additional networking equipment available to
loan you, or a lab where you can bring the FortiGate unit to test.
If you do not have access to equipment, check for shareware applications that can
perform the same tasks. Often, there are software solutions you can use when
hardware is too expensive.
Consult Fortinet After the checklist is created, refer to the troubleshooting scenarios sections to
troubleshooting resources assist with implementing your plan. See Troubleshooting scenarios on page
1827.
Gather information for If you still require technical assistance after the plan is implemented, be prepared
technical support to provide Fortinet technical support with following information:
l Firmware build version (use the get system status command)
Do not provide the output from the execute tac report unless
the support team requests it. The output from this command is
very large and is not required in many cases.
Contact technical support Before contacting technical support, ensure you have login access (preferably
with full read/write privileges) to all networking devices that could be relevant to
troubleshooting.
If you are using VMs, be prepared to have someone who can log in to the virtual
hosting platform in case it is necessary to check and possibly modify resource
allocation.
Troubleshooting scenarios
The following table is intended to help you diagnose common problems and provides links to the corresponding
troubleshooting topics:
Hardware l Are all of the cables and interfaces Checking the hardware connections on page
connections connected properly? 1829
l Is the LED for the interface green?
FortiOS network l If you are having problems connecting to Checking FortiOS network settings on page
settings the management interface, is your 1830
protocol enabled on the interface for
administrative access?
l Does the interface have an IP address?
CPU and memory l Is the CPU running at almost 100 Troubleshooting CPU and network resources
resources percent usage? on page 1833
l Is your FortiGate running low on
memory?
Modem status l Is the modem connected? Checking the modem status on page 1838
l Are there PPP issues?
Ping and traceroute Is the FortiGate experiencing complete Running ping and traceroute on page 1839
packet loss?
Logs Do you need to identify a problem? Checking the logs on page 1842
Contents of the l Are there routes in the routing table for Verifying routing table contents in NAT mode
routing table (in default and static routes? on page 1843
NAT mode) l Do all connected subnets have a route in
the routing table?
l Does a route have a higher priority than
it should?
Traffic routes Is the traffic routed correctly? Verifying the correct route is being used on
page 1844
Firewall policies Is the correct firewall policy applied to the Verifying the correct firewall policy is being
expected traffic? used on page 1844
Bridging Are you having problems in transparent Checking the bridging information in
information in mode? transparent mode on page 1845
transparent mode
Firewall session l Are there active firewall sessions? Using a session table on page 1856
list
Wireless Network Is the wireless network working properly? Checking wireless information on page 1846
FortiGuard Is the FortiGate communicating properly with Verifying connectivity to FortiGuard on page
connectivity FortiGuard? 1866
Sniffer trace l Is traffic entering the FortiGate? Does Performing a sniffer trace (CLI and packet
the traffic arrive on the expected capture) on page 1847
interface?
l Is the ARP resolution correct for the
next-hop destination?
l Is the traffic exiting the FortiGate to the
destination as expected?
l Is the FortiGate sending traffic back to
the originator?
Packet flow Is traffic entering or leaving the FortiGate as Debugging the packet flow on page 1850
expected?
The system date and time are important for FortiGuard services, logging events, and sending alerts. The wrong time
makes the log entries confusing and difficult to use.
When possible, use Network Time Protocol (NTP) to set the date and time. This is an automatic method that does not
require manual intervention. However, you must ensure that the port is allowed through the firewalls on your network.
FortiToken synchronization requires NTP in many situations.
For information about setting the system date and time, see Setting the system time on page 804.
1. Go to Dashboard > Status. The date and time are displayed in the System Information widget, next to System Time.
2. Go to System > Settings.
3. In the System Time section, select NTP, and then configure the Time Zone, and Set Time settings as required.
execute date
execute time
Use the set timezone ? command to display a list of timezones and the integers that represent them.
config system global
set timezone <integer>
end
config system ntp
set type custom
config ntpserver
edit 1
set server “ntp1.fortinet.net”
next
edit 2
set server “ntp2.fortinet.net”
next
end
set ntpsync enable
set syncinterval 60
end
If traffic is not flowing from the FortiGate, there may be a problem with the hardware connection.
l You are unsure of the type or quality of the cable, such as straight through or crossover.
You should still perform basic software connectivity tests to ensure complete connectivity even if there was a problem
with the hardware connection. The interface might also be disabled, or its Status might be set to Down. See Interfaces on
page 385.
1. Go to Network > Interfaces.
2. Select an interface, such as Port1, and click Edit.
3. In the Miscellaneous area, next to Status, click Enabled.
4. Click OK.
Check the FortiOS network settings if you have problems connecting to the management interface. FortiOS network
settings include, interface settings, DNS Settings, and DHCP settings.
Interface settings
If you can access the FortiGate with the management cable only, you can view the interface settings in the GUI.
Setting Description
Link Status The status is Up when a valid cable is plugged in. The status is Down when an
invalid cable is plugged in.
The Link Status is shown physically by the connection LED for the interface. If the
LED is green, the connection is good. If Link Status is Down, the interface does not
work.
Link status also appears in the Network > Interfaces page by default.
Addressing mode Do not use DHCP if you do not have a DHCP server. You will not be able to log into
an interface in DHCP mode as it will not have an IP address.
IP/Network Mask An interface requires an IP address to connect to other devices. Ensure there is a
valid IP address in this field. The one exception is when DHCP is enabled for this
interface to get its IP address from an external DHCP server.
IPv6 address The same protocol must be used by both ends to complete the connection. Ensure
this interface and the remote connection are both using IPv4 or both are using IPv6
addresses.
Administrative access If no protocols are selected, you will have to use the local management cable to
connect to the unit. If you are using IPv6, configure the IPv6 administrative access
protocols.
Status Ensure the status is set to Up or the interface will not work.
DNS settings
DHCP servers are common on internal and wireless networks. The DHCP server will cause problems if it is not
configured correctly.
There are some situations, such as a new wireless interface, or during the initial FortiGate
configuration, where interfaces override the system DNS entries. When this happens, it often
shows up as intermittent Internet connectivity.
To fix the problem, go to Network > DNS, and enable Use FortiGuard Servers.
Check the CPU and memory resources when the FortiGate is not working, the network is slow, or there is a reduced
firewall session setup rate. All processes share the system resources in FortiOS, including CPU and memory.
Sample output:
The first line of the output shows the CPU usage by category:
CPU states: 0% user 0% system 0% nice 100% idle 0% iowait 0% irq 0% softirq
Memory usage should not exceed 90%. Using too much memory prevents some processes from functioning properly.
For example, if the system is running low on memory, antivirus scanning enters into failopen mode where it drops
connections or bypasses the antivirus system.
Other lines of output, such as average network usage, average session setup rate, viruses caught,
and IPS attacks blocked, help determine why system resource usage is high.
For example:
l A high average network usage may indicate high traffic processing on the FortiGate,
l A very low or zero, average session setup rate may indicate the proxy is overloaded and unable to do its
job.
If the FortiGate has stopped working, the first line of the output will look similar to this:
CPU states: 0% user 0% system 0% nice 100% idle
Network is slow
If your network is running slow, the first line of the output will look similar to this:
CPU states: 1% user 98% system 0% nice 1% idle
This example shows that all of the CPU is being used by system processes, and the FortiGate is overloaded. When
overloading occurs, it is possible a process such as scanunitid is using all the resources to scan traffic. In this case
you need to reduce the amount of traffic being scanned by blocking unwanted protocols, configuring more security
policies to limit scanning to certain protocols, or similar actions.
It is also possible a hacker has accessed your network and is overloading it with malicious activity, such as running a
spam server or using zombie PCs to attack other networks on the Internet.
You can use the following command to investigate the problem with the CPU:
get system performance top
This command shows all of the top processes that are running on the FortiGate and their CPU usage. The process
names are on the left. If a process is using most of the CPU cycles, investigate it to determine whether the activity is
normal.
A reduced firewall session setup rate can be caused by a lack of system resources on the FortiGate, or reaching the
session count limit for a VDOM.
As a best practice, administrators should record the session setup rate during normal
operation to establish a baseline to help define a problem when your are troubleshooting.
The session setup rate appears in the average sessions section of the output.
A reduced firewall session setup rate will look similar to this:
Average sessions: 80 sessions in 1 minute, 30 sessions in 10 minutes, 42 sessions in 30
minutes
Average session setup rate: 3 sessions per second in last 1 minute, 0 sessions per second in
last 10 minutes, 0 sessions per second in last 30 minutes
In the example above, there were 80 sessions in 1 minute, or an average of 3 sessions per second.
The values for 10 minutes and 30 minutes allow you to take a longer average for a more reliable value if your
FortiGate is working at maximum capacity. The smallest FortiGate can have 1,000 sessions established per second
across the unit.
The session setup rate is a global command. If you have multiple VDOMs configured with
many sessions in each VDOM, the session setup rate per VDOM will be slower than if there
are no VDOMs configured.
As with any system, a FortiGate has limited hardware resources, such as memory, and all processes running on the
FortiGate share the memory. Each process uses more or less memory, depending on its workload. For example, a
process usually uses more memory in high traffic situations. If some processes use all of the available memory, other
processes will not be able to run.
When high memory usage occurs, the services may freeze up, connections may be lost, or new connections may be
refused.
If you see high memory usage in the Memory widget, the FotiGate may be handling high traffic volumes. Alternatively,
the FortiGate may have problems with connection pool limits that are affecting a single proxy. If the FortiGate receives
large volumes of traffic on a specific proxy, the unit may exceed the connection pool limit. If the number of free
connections within a proxy connection pool reaches zero, issues may occur.
Sample output:
Connection-related problems may occur when FortiGate's CPU resources are over extended. This occurs when you
deploy too many FortiOS features at the same time.
You can view CPU usage levels in the GUI or CLI. For precise usage values for both overall usage and specific
processes, use the CLI.
Go to Dashboard > Status. Real-time CPU usage information is located in the CPU widget.
Sample output:
The following table explains the codes in the second line of the output:
Code Description
U Percentage of user space applications that are currently using the CPU
N Percentage of time that the CPU spent on low priority processes since the last shutdown
S Percentage of system processes (or kernel processes) that are using the CPU
I Percentage of idle CPU resources
WA Percentage of time that the CPU spent waiting on IO peripherals since the last shutdown
HI Percentage of time that the CPU spent handling hardware interrupt routines since the last shutdown
SI Percentage of time that the CPU spent handling software interrupt routines since the last shutdown
ST Steal time: Percentage of time a virtual CPU waits for the physical CPU when the hypervisor is
servicing another virtual processor
T Total FortiOS system memory in MB
F Free memory in MB
Each additional line of the command output displays information specific to processes or threads that are running on the
FortiGate unit. For example, the sixth line of the output is: newcli 20195 R 0.1 0.1
The following table describes the data in the sixth line of the output:
Item Description
newcli The process (or thread) name.
Duplicate process or thread names indicate that separate instances of that process or thread are
running.
20195 The process or thread ID, which can be any number.
R Current state of the process or thread. The process or thread state can be:
l R - running
l S - sleep
l Z - zombie
l D- disk sleep
0.1 The percentage of CPU capacity that the process or thread is using.
CPU usage can range from 0.0 for a process or thread that is sleeping to higher values for a process
or thread that's taking a lot of CPU time.
0.1 The amount of memory that the process or thread is using.
Memory usage can range from 0.1 to 5.5 and higher.
You can use the following single-key commands when running diagnose sys top or diagnose sys top-all:
l q to quit and return to the normal CLI prompt.
l p to sort the processes by the amount of CPU that the processes are using.
l m to sort the processes by the amount of memory that the processes are using.
The output only displays the top processes or threads that are running. For example, if 20 are listed, they are the top 20
currently running, sorted by either CPU or memory usage. You can configure the number of processes or threads
displayed, using the following CLI commands:
diagnose sys top <integer_seconds> <integer_maximum_lines>
diagnose sys top-all <integer_seconds> <integer_maximum_lines>
Where:
l <integer_seconds> is the delay in seconds (default is 5)
l <integer_maximum_lines> is the maximum number of lines (or processes) to list (default is 20)
You can use the CLI to view the top few processes that are currently running and using the most CPU resources.
The entries at the top are using the most CPU resources. The second column from the right shows CPU usage by
percentage. Note which processes are using the most resources and try to reduce their CPU load.
Processes you will see include:
l ipsengine: the IPS engine that scans traffic for intrusions
l scanunitd: antivirus scanner
l httpsd: secure HTTP
l iked: internet key exchange (IKE) in use with IPsec VPN tunnels
l newcli: active whenever you're accessing the CLI
l sshd: there are active secure socket connections
l cmdbsrv: the command database server application
Go to the features that are at the top of the list and look for evidence of CPU overuse. Generally, the monitor for a feature
is a good place to start.
These are some best practices that will reduce your CPU usage, even if the FortiGate is not experiencing high CPU
usage. Note that if the following information instructs you to turn off a feature that you require, disregard that part of the
instructions.
l Use hardware acceleration wherever possible to offload tasks from the CPU. Offloading tasks, such as encryption,
frees up the CPU for other tasks.
l Avoid the use of GUI widgets that require computing cycles, such as the Top Sessions widget. These widgets
constantly pol the system for information, which uses CPU and other resources.
l Schedule antivirus, IPS, and firmware updates during off-peak hours. These updates do not usually consume CPU
resources but they can disrupt normal operation.
l Check the log levels and which events are being logged. This is the severity of the messages that are recorded.
Consider going up one level to reduce the amount of logging. Also, if there are events you do not need to monitor,
remove them from the list.
l Log to FortiCloud instead of logging to memory or disk. Logging to memory quickly uses up resources and logging
to local disk impacts overall performance and reduces the lifetime of the unit.
Fortinet recommends logging to FortiCloud to avoid using too much CPU.
l If the disk is almost full, transfer the logs or data off the disk to free up space. When a disk is almost full it consumes
a lot of resources to find free space and organize the files.
l If packet logging is enabled on the FortiGate, consider disabling it. When packet logging is enabled, it records every
packet that comes through that policy.
l Halt all sniffers and traces.
l Ensure the FortiGate isn't scanning traffic twice. Traffic does not need to be rescanned if it enters the FortiGate on
one interface, goes out another, and then comes back in again. Doing so is a waste of resources. However, ensure
that traffic truly is being scanned once.
l Reduce the session timers to close unused sessions faster. Enter the following CLI commands, which reduce the
default values. Note that, by default, the system adds 10 seconds to tcp-timewait.
config system global
set tcp-halfclose-timer 30
set tcp-halfopen-timer 30
set tcp-timewait-timer 0
set udp-idle-timer 60
end
l Go to System > Feature Visibility, and enable only features that you need.
SNMP monitoring
When CPU usage is under control, use SNMP to monitor CPU usage. Alternatively, use logging to record CPU and
memory usage every 5 minutes.
Once the system is back to normal, you should set up a warning system that sends alerts when CPU resources are used
excessively. A common method to do this is using SNMP. SNMP monitors many values in FortiOS and allows you to set
high water marks that generate events. You can run an application on your computer to watch for and record these
events.
To enable SNMP:
You can use the System Resources widget to record CPU usage if SNMP is too complicated.
However, the widget only records problems as they happen and will not send you alerts for
problems.
You can use the CLI to troubleshoot a modem that is not working properly, or troubleshoot a FortiGate that does not
detect the modem.
diagnose sys modem {cmd | com | detect | history | external-modem | query| reset}
You should always run the following command after you connect a USB modem to FortiGate:
diagnose sys modem detect
Use the following command to view the modem's configuration, vendor and custom product identification number:
get system modem
Ping and traceroute are useful tools in network troubleshooting. Alone, either tool can determine network connectivity
between two points. However, ping can be used to generate simple network traffic that you can view using diagnose
commands in FortiGate. This combination can be very powerful when you are trying to locate network problems.
Ping and traceroute can also tell you if your computer or network device has access to a domain name server (DNS).
Both tools can use IP addresses or device domain names to determine why particular services, such as email or web
browsing, may not work properly.
If ping does not work, it may be disabled on at least one of the interface settings and security
policies for that interface.
Both ping and traceroute require particular ports to be open on firewalls to function. Since you typically use these tools to
troubleshoot, you can allow them in the security policies and on interfaces only when you need them. Otherwise, keep
the ports disabled for added security.
Ping
The ping command sends a very small packet to a destination, and waits for a response. The response has a timer that
expires when the destination is unreachable.
Ping is part of layer 3 on the OSI Networking Model. Ping sends Internet Control Message Protocol (ICMP) “echo
request” packets to the destination, and listens for “echo response” packets in reply. However, many public networks
block ICMP packets because ping can be used in a denial of service (DoS) attack (such as Ping of Death or a smurf
attack), or by an attacker to find active locations on the network. By default, FortiGate units have ping enabled while
broadcast-forward is disabled on the external interface.
Beyond the basic connectivity information, ping can tell you the amount of packet loss (if any), how long it takes the
packet to make the round trip, and the variation in that time from packet to packet.
If packet loss is detected, you should investigate the following:
Ping syntax is the same for nearly every type of system on a network.
1. Go to Dashboad, and connect to the CLI through either telnet or the CLI widget.
2. Enter execute ping 10.11.101.101 to send 5 ping packets to the destination IP address. There are no
options for this command.
Head_Office_620b # execute ping 10.11.101.101
PING 10.11.101.101 (10.11.101.101): 56 data bytes
64 bytes from 10.11.101.101: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 10.11.101.101: icmp_seq=1 ttl=255 time=0.2 ms
64 bytes from 10.11.101.101: icmp_seq=2 ttl=255 time=0.2 ms
64 bytes from 10.11.101.101: icmp_seq=3 ttl=255 time=0.2 ms
64 bytes from 10.11.101.101: icmp_seq=4 ttl=255 time=0.2 ms
1. Go to a shell prompt.
2. Enter “ping 10.11.101.101”.
Traceroute
Where ping will only tell you if it reached its destination and returned successfully, traceroute shows each step of the
journey to its destination and how long each step takes. If ping finds an outage between two points, you can use
traceroute to locate exactly where the problem is.
Traceroute works by sending ICMP packets to test each hop along the route. It sends three packets, and then increases
the time to live (TTL) setting by one each time. This effectively allows the packets to go one hop farther along the route.
This is why most traceroute commands display their maximum hop count before they start tracing the route, which is the
maximum number of steps it takes before it declares the destination unreachable. Also, the TTL setting may result in
steps along the route timing out due to slow responses. There are many possible reasons for this to occur.
By default, traceroute uses UDP datagrams with destination ports numbered from 33434 to 33534. The traceroute utility
may also offer the option to select use of ICMP echo request (type 8) instead, which the Windows tracert utility uses. If
you must, allow both protocols inbound through the FortiGate security policies (UDP with ports from 33434 to 33534 and
ICMP type 8).
Go to Policy & Objects > Firewall Policy and view the packet count column.
This allows you to verify the connection and confirm which security policy the traceroute packets are using.
Both ping and traceroute verify connectivity between two points. However, only traceroute shows you each step in the
connection path. Also, ping and traceroute use different protocols and ports, so one may succeed where the other fails.
You can verify your DNS connection using traceroute. If you enter an FQDN instead of an IP address for the traceroute,
DNS tries to resolve that domain name. If the name isn't resolved, you have DNS issues.
Using traceroute
The traceroute command varies slightly between operating systems. In Microsoft Windows, the command name is
shortened to “tracert”. Also, your output lists different domain names and IP addresses along your route.
6 25 ms 45 ms 53 ms te8-7.mpd01.cogentco.com [154.54.27.249]
7 89 ms 70 ms 36 ms te3-x.mpd01.cogentco.com [154.54.6.206]
8 55 ms 77 ms 58 ms sl-st30-chi-.sprintlink.net [144.232.9.69]
9 53 ms 58 ms 46 ms sl-0-3-3-x.sprintlink.net [144.232.19.181]
10 82 ms 90 ms 75 ms sl-x-12-0-1.sprintlink.net [144.232.20.61]
11 122 ms 123 ms 132 ms sl-0-x-0-3.sprintlink.net [144.232.18.150]
12 129 ms 119 ms 139 ms 144.232.20.7
13 172 ms 164 ms 243 ms sl-321313-0.sprintlink.net [144.223.243.58]
14 99 ms 94 ms 93 ms 203.78.181.18
15 108 ms 102 ms 89 ms 203.78.176.2
16 98 ms 95 ms 97 ms 208.70.202.225
The first column on the left is the hop count, which can't exceed 30 hops. When that number is reached, the
traceroute ends.
The second, third, and fourth columns display how much time each of the three packets takes to reach this stage of
the route. These values are in milliseconds and normally vary quite a bit. Typically a value of <1ms indicates a local
connection.
The fifth column (farthest to the right) shows the domain name of the device and its IP address, or possibly only the
IP address.
A log message records the traffic passing through FortiGate to your network and the action FortiGate takes when it
scans the traffic. You should log as much information as possible when you first configure FortiOS. If FortiGate logs are
too large, you can turn off or scale back the logging for features that are not in use.
It is difficult to troubleshoot logs without a baseline. Before you can determine if the logs indicate a problem, you need to
know what logs result from normal operation.
Verify the contents of the routing table when a FortiGate has limited or no connectivity.
The routing table stores the routes currently in use for both static and dynamic protocols. Storing a route in the routing
table saves time and resources performing a lookup. To ensure the most recently used routes remain in the table, old
routes are bumped to make room for new ones. You cannot perform this task when FortiGate is in transparent mode.
If FortiGate is running in NAT mode, verify that all desired routes are in the routing table, including local subnets, default
routes, specific static routes, and dynamic routing protocols.
Sample output:
Run a trace route from a machine in the local area network (LAN) to ensure traffic is flowing as expected through the
correct route when there is more than one default route.
In the following example output:
l The first hop contains the IP address 10.10.1.99, which is the internal interface of the FortiGate.
l The second hop contains the IP address 172.20.120.2, to which the wan1 interface of the FortiGate is
connected.
This means the route through the wan1 interface is being used for this traffic.
C:\>tracert www.fortinet.com
Tracing route to www.fortinet.com [66.171.121.34]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.10.1.99
2 1 ms <1 ms <1 ms 172.20.120.2
3 3 ms 3 ms 3 ms static-209-87-254-221.storm.ca [209.87.254.221]
4 3 ms 3 ms 3 ms core-2-g0-2.storm.ca [209.87.239.129]
5 13 ms 13 ms 13 ms core-3-bdi1739.storm.ca [209.87.239.199]
6 12 ms 19 ms 11 ms v502.core1.tor1.he.net [216.66.41.113]
7 22 ms 22 ms 21 ms 100ge1-2.core1.nyc4.he.net [184.105.80.9]
8 84 ms 84 ms 84 ms ny-paix-gni.twgate.net [198.32.118.41]
9 82 ms 84 ms 82 ms 217-228-160-203.TWGATE-IP.twgate.net [203.160.22
8.217]
10 82 ms 81 ms 82 ms 229-228-160-203.TWGATE-IP.twgate.net [203.160.22
8.229]
11 82 ms 82 ms 82 ms 203.78.181.2
12 84 ms 83 ms 83 ms 203.78.186.70
13 84 ms * 85 ms 66.171.127.177
14 84 ms 84 ms 84 ms fortinet.com [66.171.121.34]
15 84 ms 84 ms 83 ms fortinet.com [66.171.121.34]
You can also see the route taken for each session by debugging the packet flow in the CLI. For more information, see
Debugging the packet flow on page 1850.
If you have more than one firewall policy, you can check which policy is being used in the Policy & Objects module in the
GUI.
Checking the bridging information is useful when you are experiencing connectivity problems. When FortiGate is set to
transparent mode, it acts like a bridge and sends all incoming traffic out on the other interfaces. Each bridge is a link
between interfaces.
When traffic is flowing between the interfaces, you can see the bridges listed in the CLI. If no bridges are listed, this is the
likely cause of the connectivity issue. When investigating bridging information, check for the MAC address of the
interface or device in question.
Sample output:
You can use forwarding domains, or collision domains, in routing to limit where packets are forwarded on the network.
Layer 2 broadcasts are limited to the same group. By default, all interfaces are in group 0. For example, if the FortiGate
has 12 interfaces, only two may be in the same forwarding domain, which limits packets that are broadcast to those two
interfaces. This reduces traffic on the rest of the network.
Collision domains prevent the forwarding of ARP packets to all VLANs on an interface. Without collision domains,
duplicate MAC addresses on VLANs may cause ARP packets to be duplicated. Duplicate ARP packets can cause some
switches to reset. It's important to know what interfaces are part of which forwarding domains because this determines
which interfaces can communicate with each other.
Where <name> is the name of the forwarding domain to display and <id> is the domain ID.
Sample output:
id=101 dev=trunk_1 6
Sample output:
Sample output:
Check wireless connections, stations, and interfaces when the problem is not caused by a physical interface.
This example uses the station MAC address to find where it is failing:
When you troubleshoot networks and routing in particular, it helps to look inside the headers of packets to determine if
they are traveling the route that you expect them to take. Packet sniffing is also known as network tap, packet capture, or
logic analyzing.
For FortiGates with NP2, NP4, or NP6 interfaces that are offloading traffic, disable offloading
on these interfaces before you perform a trace or it will change the sniffer trace.
Sniffing packets
Before you start sniffing packets, you should prepare to capture the output to a file. A large amount of data may scroll by
and you will not be able to see it without saving it first. One method is to use a terminal program like puTTY to connect to
the FortiGate CLI. Once the packet sniffing count is reached, you can end the session and analyze the output in the file.
The general form of the internal FortiOS packet sniffer command is:
# diagnose sniffer packet <interface_name> <‘filter’> <verbose> <count> <tsformat>
<interface_name> The name of the interface to sniff, such as port1 or internal. This can also be
any to sniff all interfaces.
<‘filter’> What to look for in the information the sniffer reads. none indicates no filtering,
and all packets are displayed as the other arguments indicate.
The filter must be inside single quotes (‘).
<verbose> The level of verbosity as one of:
l 1 - print header of packets
This displays the next three packets on the port1 interface using no filtering, and verbose level 1. At this verbosity level,
you can see the source IP and port, the destination IP and port, action (such as ack), and sequence numbers.
In the output below, port 443 indicates these are HTTPS packets and that 172.20.120.17 is both sending and receiving
traffic.
Head_Office_620b # diagnose sniffer packet port1 none 1 3
interfaces=[port1]
filters=[none]
0.545306 172.20.120.17.52989 -> 172.20.120.141.443: psh 3177924955 ack 1854307757
0.545963 172.20.120.141.443 -> 172.20.120.17.52989: psh 1854307757 ack 3177925808
0.562409 172.20.120.17.52988 -> 172.20.120.141.443: psh 4225311614 ack 3314279933
The following commands will report packets on any interface that are traveling between a computer with the host name
of “PC1” and a computer with the host name of “PC2”. With verbosity 4 and above, the sniffer trace displays the interface
names where traffic enters or leaves the FortiGate unit. To stop the sniffer, type CTRL+C.
FGT# diagnose sniffer packet any "host <PC1> or host <PC2>" 4
or
FGT# diagnose sniffer packet any "(host <PC1> or host <PC2>) and icmp" 4
The following CLI command for a sniffer includes the ARP protocol in the filter which may be useful to troubleshoot a
failure in the ARP resolution. For example, PC2 may be down and not responding to the FortiGate ARP requests.
FGT# diagnose sniffer packet any "host <PC1> or host <PC2> or arp" 4
To use packet capture, the FortiGate must have a disk. You can enable the capture-packet in the firewall policy.
Max Packets to Save Enter the number of packets to capture before the filter stops.
This number cannot be zero. You can halt the capturing before this number is
reached.
VLAN(s) Enter one or more VLANs (if any). Separate multiple VLANs with commas.
Protocol Enter one or more protocols. Separate multiple protocols with commas. To enter a
range, use a dash without spaces. For example, 1-6, 17, 21-25.
Include IPv6 Packets Select this option if you are troubleshooting IPv6 networking, or if your network
uses IPv6. Otherwise, leave it disabled.
Include Non-IP Packets The protocols in the list are all IP based except for ICMP (ping).
Use this feature to capture non-IP based packets. Examples of non-IP packets
include IPsec, IGMP, ARP, and ICMP.
Managing filters
If you select a filter, you have the option to start and stop packet capture in the edit window, or download the captured
packets. You can also see the filter status and the number of packets captured.
You can select the filter and start capturing packets. When the filter is running, the number of captured packets increases
until it reaches the Max Packet Count or you stop it. You cannot download the output file while the filter is running.
To start, stop, or resume packet capture, use the symbols on the screen. These symbols are the same as those used for
audio or video playback. Hover over the symbol to reveal explanatory text. Similarly, to download the *.pcap file, use the
download symbol on the screen.
You can download the *.pcap file when the packet capture is complete. You must use a third party application, such as
Wireshark, to read *,pcap files. This tool provides you with extensive analytics and the full contents of the packets that
were captured.
Debug the packet flow when network traffic is not entering and leaving the FortiGate as expected. Debugging the packet
flow can only be done in the CLI. Each command configures a part of the debug action. The final commands starts the
debug.
Variable Description
addr IPv4 or IPv6 address
clear clear filter
daddr destination IPv4 or IPv6 address
dport destination port
negate inverse IPv4 or IPv6 filter
port port
proto protocol number
saddr source address
sport source port
vd index of virtual domain; -1 matches all
If FortiGate is connected to FortiAnalyzer or FortiCloud, the diagnose debug flow output will be
recorded as event log messages and then sent to the devices. Do not run this command
longer than necessary, as it generates a significant amount of data.
FortiASIC NP4 or NP6 interface pairs that offload traffic will change the packet flow. Before
debugging any NP4 or NP6 interfaces, disable offloading on those interfaces.
To do this, enter diagnose npu <interface pair> fastpath disable, where
interface pair is np4, np6, np4lite, or np6lite.
The following example shows the flow trace for a device with an IP address of 203.160.224.97:
# diagnose debug enable
# diagnose debug flow filter addr 203.160.224.97
# diagnose debug flow show function-name enable
# diagnose debug flow trace start 100
To observe the debug flow trace, connect to the website at the following address:
https://www.fortinet.com
Matched security policy. Check to see which policy this session matches:
id=20085 trace_id=209 func=fw_forward_handler line=317
msg="Allowed by Policy-3: SNAT"
ACK received:
id=20085 trace_id=211 func=resolve_ip_tuple_fast line=2700
msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
The <option> value will depend on the application value used in the command.
For example, if the application is http, the CLI command that displays the <option> values is:
diagnose test application http ?
Monitoring the hardware NIC is important because interface errors indicate data link or physical layer issues which may
impact the performance of the FortiGate.
Sample output:
Tx_Bytes=1269751248
Rx_Errors=0
Tx_Errors=0
Rx_Dropped=0
Tx_Dropped=0
[……]
Error descriptions
The diagnose hardware deviceinfo nic command displays a list of error names and values that are related to
hardware.
The following table describes possible hardware errors:
Field Description
Rx_Missed_Errors Equals Rx_FIFO_Errors + CEXTERR (Carrier Extension Error Count); only valid in 1000M
mode, which is marked by PHY
Tx_Errors = Tx_ ECOL (Excessive Collisions Count); only valid in half-duplex mode
Aborted_Errors
Collisions Total number of collisions experienced by the transmitter; valid in half-duplex mode
Field Description
Tx_Carrier_Errors The PHY should assert the internal carrier sense signal during every transmission. Failure to
do so may indicate that the link has failed or the PHY has an incorrect link configuration. This
register only increments if transmits are enabled. This register isn't valid in internal SerDes 1
mode (TBI mode for the 82544GC/EI) and is valid only when the Ethernet controller is
operating at full duplex.
Tx_Single_Collision_ Counts the number of times that a successfully transmitted packet encountered a single
Frames collision
The value increments only if transmits are enabled and the Ethernet controller is in half-duplex
mode.
Tx_Multiple_ A Multiple Collision Count which indicates the number of times that a transmit encountered
Collision_Frames more than one collision, but less than 16. The value increments only if transmits are enabled
and the Ethernet controller is in half-duplex mode.
This register only increments if transmits are enabled. This counter does not increment for
streaming transmits that are deferred due to TX IPG.
Symbol Error Count Counts the number of symbol errors between reads - SYMERRS.
The count increases for every bad symbol that's received, whether or not a packet is currently
being received and whether or not the link is up. This register increments only in internal
SerDes mode.
Traffic tracing allows you to follow a specific packet stream. This is useful when you want to confirm that packets are
using the route you expect them to take on your network.
Use this command to view the characteristics of a traffic session though specific security policies.
diagnose sys session
A session is a communication channel between two devices or applications across the network. Sessions allow FortiOS
to inspect and act on a sequential group of packets in a session all at once instead of inspecting each packet individually.
Each session has an entry in the session table that includes important information about the session.
You can view FortiGate session tables from the FortiGate GUI or CLI. The most useful troubleshooting data comes from
the CLI. The session table in the GUI also provides useful summary information, particularly the current policy number
that the session is using.
Session tables are useful when verifying open connections. For example, if you have a web browser open to browse the
Fortinet website, you would expect a session entry from your computer on port 80 to the IP address for the Fortinet
website.
You can also use a session table to investigate why there are too many sessions for FortiOS to process.
GUI
Every program and device on your network must have an open communication channel or session to pass information.
FortiGate manages these sessions with features such as traffic shaping, antivirus scanning, and blocking known bad
websites. Each session will have an entry in the session table.
If a secure web browser session is not working properly, you can check the session table to ensure the session is still
active and going to the proper address. The session table can also tell you the security policy number it matches, so you
can check what is happening in that policy.
You need to be able to identify the session you want. To do this, you will need:
l The source IP address (usually your computer)
l The destination IP address (if you have it)
l The port number which is determined by the program you are using. Common ports are:
l Port 80 (HTTP for web browsing)
Go to Security Fabric > Physical Topology. From the Metrics dropdown, select Sessions.
To find your session, search for your source IP address, destination IP address (if you have it), and port number. The
policy ID is listed after the destination information.
If there are multiple pages of sessions, you can use a filter to hide the sessions you do not need. To filter the sessions in
the table, click Add Filter, and select an option from the list. You can filter the table by Destination IP, Source IP, or
Source Port.
CLI
The session table output in the CLI is very large. The CLI command supports filters to show only the data you need.
An entry is placed in the session table for each traffic session passing through a security policy
Value Definition
clear Clear session filter
dintf Destination interface
dport Destination port
dst Destination IP address
duration Duration of the session
expire Expire
negate Inverse filter
nport NAT'd source port
nsrc NAT'd source ip address
policy Policy ID
proto Protocol number
proto-state Protocol state
session-state1 Session state1
session-state2 Session state2
sintf Source interface
sport Source port
src Source IP address
vd Index of virtual domain, -1 matches all
Even though UDP is a sessionless protocol, FortiGate keeps track of the following states:
l When UDP reply does not have a value of 0
l When UDP reply has a value of 1
The following table displays firewall session states from the session table:
State Description
State Description
For example, the session for ftp control channel will have this state but ftp data
channel won't. This is also seen when NAT is enabled.
The firewall session list displays all open sessions in FortiGate. Examine the list for strange patterns, such as no
sessions apart from the internal network, or all sessions are only to one IP address.
When you examine the firewall session list in the CLI, you can use filters to reduce the output.
You can use a filter to limit the sessions displayed by source, destination address, port, or NAT'd address. To use more
than one filter, enter a separate line for each value.
The following example filters the session list based on a source address of 10.11.101.112:
FGT# diagnose sys session filter src 10.11.101.112
FGT# diagnose sys session list
The following example filters the session list based on a destination address of 172.20.120.222.
FGT# diagnose sys session filter dst 172.20.120.222
FGT# diagnose sys session list
Checking source NAT is important when you are troubleshooting from the remote end of the connection outside the
firewall.
When you display the session list in the CLI, you can match the NAT'd source address (nsrc) and port (nport). This is
useful when multiple internal IP addresses are NAT'd to a common external-facing source IP address.
FGT# diagnose sys session filter nsrc 172.20.120.122
FGT# diagnose sys session filter nport 8888
FGT# diagnose sys session list
You may be prevented from deleting a configuration object when other configuration objects depend on it. You can use
the GUI or CLI to identify objects which depend on, or make reference to the configuration you are trying to delete.
Additionally, if you have a virtual interface with dependent objects, you will need to find and remove those dependencies
before deleting the interface.
1. Go to Network > Interfaces. The Ref. column displays the number of objects that reference this interface.
2. Select the number in the Ref . column for the interface. A window listing the dependencies appears.
3. Use these detailed entries to locate and remove object references to this interface. The trash can icon is enabled
after all the object dependencies are removed.
4. Remove the interface by selecting the check box for the interface, and select Delete.
When running multiple VDOMs, use the following command in the global configuration only.
diagnose sys checkused <path.object.mkey>
The command searches for the named object in both the most recently used global and VDOM configurations.
Examples
Sample output:
In this example , the interface has dependent objects, including four address objects, one VIP, and three security
policies.
entry used by table firewall.address:name '10.98.23.23_host’
entry used by table firewall.address:name 'NAS'
entry used by table firewall.address:name 'all'
entry used by table firewall.address:name 'fortinet.com'
entry used by table firewall.vip:name 'TORRENT_10.0.0.70:6883'
entry used by table firewall.policy:policyid '21'
entry used by table firewall.policy:policyid '14'
entry used by table firewall.policy:policyid '19'
Some Fortinet products contain network processors, such as NP4, NP6Lite, or NP6. Offloading requirements will vary
depending on the model.
The diagnose npu np6 xaui-hash command takes a 6-tuple input of the traffic stream to identify the NP6 XAUI link
that the traffic passes through.
This command is only available on the 38xxD, 39xxD, 34xxE, 36xxE, and 5001E series devices.
Syntax
diagnose npu np6 xaui-hash <interface> <proto> <src_ip> <dst_ip> <src_port> <dst_port>
Variable Description
<interface> The network interface that the packets are coming from.
<proto> The proto number, 6 for TCP or 17 for UDP.
<src_ip> The source IP address.
<dst_ip> The destination IP address.
<src_port> The source port.
<dst_port> The destination port.
Examples
The NP6_ID is the NP index of the model that is being used. It can be found with the diagnose npu np6 port-list
command.
Fortinet support may ask you to check the date and time settings for log message timestamp synchronization and for
certificates that have a time requirement to check for validity.
execute time
execute date
If all devices have the same time, it helps to correlate log entries from different devices.
execute time
current time is: 12:40:48
last ntp sync:Thu Mar 16 12:00:21 2006
execute date
current date is: 2006-03-16
If all devices have the same time, it helps to correlate log entries from different devices.
The Technical Assistance Center (TAC) report runs an exhaustive series of diagnostic commands. Some of the
commands are only needed if you are using features, such as HA, VPN tunnels, or a modem. Fortinet support my ask
you to use the report output to provide information about the current state of your FortiGate.
Due the amount of output generated, the report may take a few minutes to run. If you are logging CLI output to a file, you
can run this command to familiarize yourself with the diagnostic commands.
Other commands
You may be asked to provide the following information when you contact Fortinet support.
l ARP table on page 1863
l IP address on page 1865
ARP table
The ARP table is used to determine the destination MAC addresses of the network nodes, as well as the VLANs and
ports from where the nodes are reached.
update=614 ref=26
index=14 ifname=internal7 10.10.1.11 state=00000020 use=172 confirm=1037790 update=78 ref=2
ARP cache
The default ARP timeout value is 5 minutes (300 seconds), and can vary depending on the state of the ARP entry and
the objects that are using it, as highlighted in the following output sample:
index=5 ifname=wan1 224.0.1.140 01:00:5e:00:01:8c state=00000040 use=924202
confirm=930202 update=924202 ref=1
There are multiple possible states for an ARP entry, and the state-transition mechanism can be complex. Common
states include the following:
000000020 or 0x20 FAILED Did not manage to resolve within the maximum
configured number of probes
000000040 or 0x40 NOARP Device does not support ARP, e.g. IPsec interface
An entry that is in the STALE (0x04) or FAILED (0x20) states with no references to it (ref=0) can be deleted. Many factors
affect the state-transmit mechanism and if an entry is used by other subsystems. For example, ARP creation, ARP
request/reply, neighbor lookup, routing, and others can cause an ARP entry to be in use or referenced.
The garbage collection mechanism runs every 30 seconds, and checks and removes stale and unreferenced entries if
they have been stale for longer than 60 seconds. Garbage collection will also be triggered when the number of ARP
entries exceeds the configured threshold. If the threshold is exceeded, no entries can be added to the ARP table.
arp-max-entry <integer> The maximum number of dynamically learned MAC addresses that can be added
to the ARP table (131072 - 2147483647, default = 131072
IP address
You may want to verify the IP addresses assigned to the FortiGate interfaces are what you expect them to be.
To verify IP addresses:
Sample output:
FortiGuard troubleshooting
The FortiGuard service provides updates to AntiVirus (AV), Antispam (AS), Intrusion Protection Services (IPS),
Webfiltering (WF), and more. The FortiGuard Distribution System (FDS) consists of a number of servers across the
world that provide updates to your FortiGate unit. Problems can occur with the connection to FDS and its configuration
on your local FortiGate unit.
Some of the more common troubleshooting methods are listed here, including:
l Troubleshooting process for FortiGuard updates on page 1867
l FortiGuard server settings on page 1867
l FortiGuard server settings on page 1867
Sample output:
The following process shows the logical steps you should take when troubleshooting problems with FortiGuard updates:
1. Does the device have a valid license that includes these services?
Each device requires a valid FortiGuard license to access updates for some or all of these services. You can verify
the status of the support contract for your devices at the Fortinet Support website.
2. If the device is part of a high availability (HA) cluster, do all members of the cluster have the same level of
support?
You can verify the status of the support contract for all of the devices in your HA cluster at the Fortinet Support
website.
3. Are services enabled on the device?
To see the FortiGuard information and status for a device in the GUI, go to System > FortiGuard.
Use this page to verify the status of each component, and enable each service.
4. Can the device communicate with FortiGuard servers?
Go to System > FortiGuard in the GUI, and try to update AntiVirus and IPS, or test the availability of Web Filtering
and AS default and alternate ports.
5. Is there proper routing to reach the FortiGuard servers?
Ensure there is a static or dynamic route that allows your FortiGate to reach the FortiGuard servers. Usually a
generic default route to the internet is enough, but you may need to verify this if your network is complex.
6. Are there issues with DNS?
An easy way to test this is to attempt a traceroute from behind the FortiGate to an external network using the Fully
Qualified Domain Name (FQDN) for a location. If the traceroute FQDN name doesn't resolve, you have general
DNS problems.
7. Is there anything upstream that might be blocking FortiGuard traffic, either on the network or ISP side?
Many firewalls block all ports, by default, and ISPs often block ports that are low. There may be a firewall between
the FortiGate and the FortiGuard servers that's blocking the traffic. By default, FortiGuard uses port 53. If that port is
blocked you need to either open a hole for it or change the port it is using.
8. Is there an issue with source ports?
It is possible that ports that FortiGate uses to contact FortiGuard are being changed before they reach FortiGuard or
on the return trip before they reach FortiGate. A possible solution for this is to use a fixed-port at NAT'd firewalls to
ensure the port remains the same. You can use packet sniffing to find more information about what's happening with
ports.
9. Are there security policies that include antivirus?
If none of the security policies include antivirus, the antivirus database will not be updated. If antivirus is included,
only the database type that's used will be updated.
Your local FortiGate connects to remote FortiGuard servers to get updates to FortiGuard information, such as new
viruses that may have been found or other new threats.
This section provides methods to display FortiGuard server information on your FortiGate, and how to use that
information and update it to fix potential problems.
To get a list of FDS servers FortiGate uses to send web filtering requests:
or
diagnose debug rating
Rating requests are only sent to the server at the top of the list in normal operation. Each server is probed for Round Trip
Time (RTT) every two minutes. Rating may not be enabled on your FortiGate.
Optionally, you can add a refresh rate to the end of the command to determine how often the server list is refreshed.
Sample output:
Locale : english
License : Contract
Expiration : Thu Oct 9 02:00:00 2011
-=- Server List (Mon Feb 18 12:55:48 2008) -=-
IP Weight RTT Flags TZ Packets CurrLost TotalLost
a.b.c.d 0 1 DI 2 1926879 0 11176
10.1.101.1 10 329 1 10263 0 633
10.2.102.2 20 169 0 16105 0 80
10.3.103.3 20 182 0 6741 0 776
10.4.104.4 20 184 0 5249 0 987
10.5.105.5 25 181 0 12072 0 178
Output details
The server list includes the IP addresses of alternate servers if the first entry cannot be reached. In this example, the IP
addresses are not public addresses.
The following flags in get webfilter status indicate the server status:
Flag Description
D The server was found through the DNS lookup of the hostname.
If the hostname returns more than one IP address, all of them are flagged with D and are used first
for INIT requests before falling back to the other servers.
I The server to which the last INIT request was sent
F The server hasn't responded to requests and is considered to have failed
T The server is currently being timed
S Rating requests can be sent to the server.
The flag is set for a server only in two cases:
l The server exists in the servers list received from the (Undefined variable:
empty so the (Undefined variable: FortinetVariables.ProductName1) is the only server that the
(Undefined variable: FortinetVariables.ProductName6) knows and it should be used as the
rating server.
The server list is sorted first by weight. The server with the smallest RTT appears at the top of the list, regardless of
weight. When a packet is lost (there has been no response in 2 seconds), it is re-sent to the next server in the list.
Therefore, the top position in the list is selected based on RTT, while the other positions are based on weight.
Calculating weight
The weight for each server increases with failed packets and decreases with successful packets. To lower the possibility
of using a remote server, the weight isn't allowed to dip below a base weight. The base weight is calculated as the
difference in hours between the FortiGate and the server multiplied by 10. The farther away the server is, the higher its
base weight is and the lower it appears in the list.
Additional resources
To learn more about FortiGate and FortiOS, as well information about technical issues, please refer to the following
resources:
Technical documentation
Installation, Administration, and Quick Start Guides, as well as other technical documents, are available online at the
Fortinet Document Library
The Fortinet Video Library hosts a collection of video which provide valuable information about Fortinet products.
Release notes
Issues that arise after the technical documentation has been published will often be listed in the Release Notes. To find
these, go to the Fortinet Document Library.
Knowledge base
The Fortinet Knowledge Base provides access to a variety of articles, white papers, and other documentation that
provides technical insight into a range of Fortinet products. The Knowledge Base is available online at:
http://kb.fortinet.com
An online technical forum allows administrators to contribute to discussions about issues that relate to their Fortinet
products. Searching the forum can help an administrator identify if an issue has been experienced by another user. You
The Fortinet Training Services Online Campus hosts a collection of tutorials and training materials which you can use to
increase your knowledge of Fortinet products. https://www.fortinet.com/training.html
Fortinet Support
You defined your problem, researched a solution, put together a plan to find the solution, and executed that plan. At this
point, if the problem hasn't been solved, it's time to contact Fortinet Support for assistance.