FortiOS-6 2 0-Cookbook
FortiOS-6 2 0-Cookbook
FortiOS-6 2 0-Cookbook
Version 6.2.0
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com
FORTINET BLOG
https://blog.fortinet.com
NSE INSTITUTE
https://training.fortinet.com
FORTIGUARD CENTER
https://fortiguard.com/
FEEDBACK
Email: [email protected]
Change Log 14
What's New 17
Getting Started 18
Differences between models 18
Using the GUI 18
Connecting using a web browser 18
Menus 19
Dashboard 20
Feature visibility 24
Tables 25
Entering values 27
Using the CLI 28
Connecting to the CLI 29
CLI basics 31
Command syntax 37
Subcommands 40
Permissions 42
FortiExplorer for iOS 42
Getting started with FortiExplorer 43
Connecting FortiExplorer to a FortiGate via WiFi 45
Running a security rating 45
Upgrading to FortiExplorer Pro 45
Basic administration 45
Registration 45
System settings 47
Configuration backups 52
Firmware 56
Downloading a firmware image 57
Testing a firmware version 57
Upgrading the firmware 59
Downgrading to a previous firmware version 59
Installing firmware from system reboot 60
Restoring from a USB drive 62
Controlled upgrade 62
FortiGuard 62
Configuring antivirus and IPS options 63
Manual updates 63
Automatic updates 64
Sending malware statistics to FortiGuard 66
Update server location 67
Filtering 67
Override FortiGuard servers 68
Online security tools 69
FortiGate Cloud 69
Troubleshooting your installation 71
Change Log
2019-04-03 Added Supported log types to FortiAnalyzer, Syslog, and FortiAnalyzer Cloud on page
1010.
Added Multiple FortiSwitches in tiers via aggregate interface with MCLAG enabled only
on distribution on page 982.
2019-06-25 Added Self-originating traffic on page 288 and SDN dynamic connector addresses in
SD-WAN rules on page 289.
2019-07-10 Added Supported views for different log sources on page 247.
2019-07-12 Added Data channel security: clear-text, DTLS, and IPsec VPN on page 898.
For details about new features, see the FortiOS 6.2.0 New Features Guide. New features are organized into the
following sections:
l Expanding fabric family
l Fabric connectors
l SD-WAN
l Multi-Cloud
l Automation and dev-ops
l Advanced threats
l IOT & OT
l SOC adoption
l Compliance
l UX / Usability
l Other
This section explains how to get started with a FortiGate and examines basic configuration tasks and best practices.
Not all FortiGates have the same features, particularly entry-level models (models 30 to 90). A number of features on
this 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 24.
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 Dashboard
l Feature visibility
l Tables
l Entering values
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.
1. Go to Network > Interfaces and edit the interface you wish to use for access. Take note of its assigned IP address.
2. Beside 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 24.
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 Dashboard on page 20.
Security Fabric Access the physical topology, logical topology, audit, and settings features of the
Fortinet Security Fabric.
For more information, see Fortinet Security Fabric on page 74.
FortiView A collection of dashboards and logs that give insight into network traffic, showing
which users are creating the most traffic, what sort of traffic it is, when the traffic
occurs, and what kind of threat the traffic may pose to the network.
For more information, seeFortiView on page 225.
Network Options for networking, including configuring system interfaces and routing
options.
For more information, see Network Configurations on page 249.
Policy & Objects Configure firewall policies, protocol options, and supporting content for policies,
including schedules, firewall addresses, and traffic shapers.
For more information, see Policies and Objects on page 409.
Security Profiles Configure your FortiGate's security features, including Antivirus, Web Filter, and
Application Control.
For more information, see Security Profiles on page 493.
VPN Configure options for IPsec and SSL virtual private networks (VPNs).
For more information, see IPsec VPNs on page 657 and SSL VPN on page 819.
User & Device 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 WiFi on page 887.
Monitor View a variety of monitors, including the Routing Monitor, VPN monitors for both
IPsec and SSL, monitors relating to wireless networking, and more.
Dashboard
FortiOS dashboards can have a Network Operations Center (NOC) or responsive layout.
l On a responsive dashboard, the number of columns is determined by the size of the screen. Widgets can only be
resized horizontally, but the dashboard will fit on all screen sizes.
l On a NOC dashboard, the number of columns is explicitly set. Widgets can be resized both vertically and
horizontally, but the dashboard will look best on the screen size that it is configured for.
Multiple dashboards of both types can be created, for both individual VDOMs and globally. Widgets are interactive;
clicking or hovering over most widgets shows additional information or links to relevant pages. Widgets can be
reorganized by clicking and dragging them around the screen.
Three dashboards are available by default: Status, Top Usage LAN/DMZ, and Security.
The Status dashboard includes the following widgets by default:
Widget Description
System Information The System Information widget lists information relevant to the FortiGate system,
including hostname, serial number, and firmware.
Clicking in the widget provides links to configure system settings and update the device
firmware.
Licenses The Licenses widget lists the status of various licenses, such as FortiCare Support and
IPS. The number of used and available FortiTokens is also shown.
Clicking in the widget provides a link to the FortiGuard settings page.
Virtual Machine The VM widget (shown by default in the dashboard of a FortiOS VM device) includes:
l License status and type
l vCPU allocation and usage
l RAM allocation and usage
l VMX license information (if the VM supports VMX)
Clicking on an item in the widget provides a link to the FortiGate VM License page, where
license files can be uploaded.
FortiGate Cloud This widget displays the FortiGate Cloud and FortiSandbox Cloud status.
Widget Description
Security Fabric The Security Fabric widget displays a visual summary of the devices in the Fortinet
Security Fabric.
Clicking on a product icon provides a link to a page relevancy to that product. For
example, clicking the FortiAnalyzer shows a link to log settings.
See Security Fabric status on page 89 for more information.
Security Rating The Security Rating widget shows the security rating for your Security Fabric. It can show
the current rating percentile, or historical security rating score or percentile charts.
See Security Rating on page 89 for more information.
Administrators This widget allows you to see logged in administrators, connected administrators, and the
protocols used by each
Clicking in the widget provides links to view active administrator sessions, and to open the
FortiExplorer page on the App Store.
CPU This widget shows real-time CPU usage over the selected time frame. Hovering over any
point on the graph displays the percentage of CPU power used at that specific time.
It can be expanded to occupy the entire dashboard.
Memory This widget shows real-time memory usage over the selected time frame. Hovering over
any point on the graph displays the percentage of the memory used at that specific time.
It can be expanded to occupy the entire dashboard.
Sessions This widget shows the current number of sessions over the selected time frame. Hovering
over any point on the graph displays the number of sessions at that specific time.
It can be expanded to occupy the entire dashboard.
The Top Usage LAN/DMZ dashboard includes the following widgets by default:
Widget Description
Top Sources by Bytes This widget lists the top sources by the number of bytes used.
Top Destinations by This widget lists the top destinations by the number of sessions.
Sessions
Top Applications by This widget lists the top applications by the number of bytes used.
Bytes
Top Web Site by This widget lists the top websites by the number of sessions.
Sessions
Widget Description
Top Compromised This widgets lists the compromised hosts by verdict. A FortiAnalyzer is required.
Hosts by Verdict It can be expanded to occupy the entire dashboard.
Widget Description
Top Threats by Threat This widget lists the top threats by threat leve,l from FortiView.
Level It can be expanded to occupy the entire dashboard.
FortiClient Detected This widget shows the number of vulnerabilities detected by FortiClient. FortiClient must
Vulnerabilities be enabled.
Clicking in the widget provides a link to view the information in FortiView.
Host Scan Summary This widget lists the total number of hosts.
Clicking in the widget provides links to view vulnerable device in FortiView, FortiClient
monitor, and the device inventory.
Top Vulnerable This widget lists the top vulnerable endpoints by the detected vulnerabilities, from
Endpoint Devices by FortiView.
Detected It can be expanded to occupy the entire dashboard.
Vulnerabilities
Widget Description
FortiView Top N This widget shows the top items from the selected FortiView category. The widget's title,
time period, visualization (table or bubble chart), and what the data is sorted by can all be
customized.
Disk Usage This widget shows real-time disk usage over the selected time frame. Hovering over any
point on the graph displays the percentage of the disk used at that specific time.
It can be expanded to occupy the entire dashboard.
Log Rate This widget shows the real-time log rate over the selected time frame. Hovering over any
point on the graph displays the log rate at that specific time.
Clicking in the widget provides a link to log settings.
It can be expanded to occupy the entire dashboard.
Session Rate This widget shows the real-time session rate over the selected time frame. Hovering over
any point on the graph displays the session rate at that specific time.
It can be expanded to occupy the entire dashboard.
Fabric Device This widget shows statistics and system information about the selected fabric device.
See Fabric Device on page 90 for more information.
Advanced Threat This widget shows threat protection statistics, including the number of scanned files and
Protection Statistics how many scanned files there are for each threat level.
Widget Description
Interface Bandwidth This widget shows the real-time incoming and outgoing traffic bandwidth of the selected
interface over the selected time frame. Hovering over any point on the graph displays the
bandwidth at that specific time.
Clicking and dragging over a porting of the graph provides a link to view the data from the
highlighted time frame in FortiView.
Dashboard CLI
Dashboards and widgets can be managed using the CLI. The options available when creating a widget will vary
depending on the widget type.
To create a dashboard:
sessions Sessions
admins Administrators
ha-status HA Status
fortiview FortiView
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.
For information about what settings each options affects, click on the + icon to the right of the feature name.
Changes are listed on the right of the screen.
3. Click Apply.
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 27
l Numbers on page 28
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 & - ampersand
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 29
l CLI basics on page 31
l Command syntax on page 37
l Subcommands on page 40
l Permissions on page 42
You can connect to the CLI using a direct console connection, SSH, the CLI console in the GUI, or the FortiExplorer app
on your iOS device.
You can access the CLI 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 iOS to to the FortiExplorer app on your iOS device to configure, manage, and monitor
your FortiGate. See FortiExplorer for iOS on page 42 for details.
Console connection
A direct console connections to the CLI is created by directly connecting your management computer or console to the
FortiGate unit, 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 computer with an available communications port
l A console cable to connect the console port on the FortiGate to a communications port on the computer (a USB
adapter may also be required)
l Terminal emulation software
1. Using the null modem or RJ-45-to-DB-9 cable, connect the FortiGate unit’s console port to the serial
communications (COM) port on your management computer. A DB-9-to-USB adapter may be required is your
computer does not have a DB-9 port.
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
4. Log in to the CLI using your username and password (default: admin and no password).
5. You can now enter CLI commands, including configuring access to the CLI through SSH.
SSH access
SSH access to the CLI is accomplished by connecting your computer to the FortiGate unit 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.
The CLI console can be accessed from the upper-right hand corner of the screen and appears
as a slide-out window. For policies and objects, the CLI can be also be accessed by right
clicking on the element and selecting Edit in CLI.
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 The RJ-45-to-DB-9 or null modem cable included in your FortiGate package
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 unit.
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 unit 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 must be entered first.
Character Keys
? Ctrl + V then ?
" \"
(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:
next
end
config firewall policy
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 disable, 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 52 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.
Vertical bar | A vertical bar separates alternative, mutually exclusive options.
For example:
set protocol {ftp | sftp}
You can enter either set protocol ftp or set protocol sftp.
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 are of FortiOS. For information, see Administrator profiles on page 335.
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 9.3 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 the ability to download firmware images from FortiCare.
Up to six members can use this app with 'Family Sharing' enabled in the App Store.
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 management port. If prompted on your iOS device, Trust this
computer.
2. Open FortiExplorer and select your FortiGate from the USB Attached Device list .
3. On the Login screen, select USB.
4. Enter the default Username (admin) and leave the Password field blank.
5. Optionally, select Remember Password.
6. Tap Done when you are ready.
FortiExplorer opens the FortiGate management interface to the Device Status page:
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. Enter the Host information, Username, and Password.
3. If required, change the default Port number, and optionally enable Remember Password.
4. 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 security score. See Security rating on
page 96 for more information.
FortiExplorer Pro includes the option to add more than two devices, and download firmware images from FortiCare.
1. In FortiExplorer, go to Settings.
2. Tap Upgrade to FortiExplorer Pro.
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 Registration on page 45
l System settings on page 47
l Configuration backups on page 52
Registration
The FortiGate must be registered to have full access to Fortinet Customer Service and Support, and FortiGuard
services.
1. Connect to the FortiGate GUI. A message is shown stating that FortiCare registration is required.
If you need to create an account, set Action to Create Account, and enter the required information.
4. Click OK.
5. Go to System > FortiGuard.
6. In the License Information table, the FortiCare Support status is Registered. There may be a delay before the
status is updated on your FortiGate.
System settings
The default administrator password should be configured immediately after the FortiGate is installed, see Default
administrator password on page 48.
After that, there are several system settings that should also be configured in System > Settings:
l Changing the host name on page 48
l Setting the system time on page 49
l Configuring ports on page 50
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.
Starting in FortiOS 6.2.1, 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.
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 335 for details.
3. Click Apply.
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:
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
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 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 affect on a security rating score. See
Security rating on page 96 for more information.
A password policy can be created for administrators and IPsec pre-shared keys. See Password policy on page 340 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.
Example:
To set the number of retry attempts to 1, and the lockout time to 5 minutes, enter the following commands:
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.
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 PCor 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:
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 PCor 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
Alternatively, in the CLI you can reset the factory defaults but retain the interface and VDOM configuration with the
following command:
execute factoryreset2
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 52.
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 57 and Downgrading to a previous firmware version on page 59 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 29), ensuring that you TFTP
server is working (Installing firmware from system reboot on page 60), and preparing a USB drive (Restoring from a
USB drive on page 62).
5. Backup the current configuration, including local certificates. See Configuration backups on page 52 for details.
6. Test the new firmware until you are satisfied that it applies to your configuration. See Testing a firmware version on
page 57 and Controlled upgrade on page 62 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.
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.
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.
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.
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 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 52 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 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!
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.
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 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:
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.
1. Go to System > FortiGuard
2. Scroll down to the AntiVirus & IPS 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 65.
Use override push Only available if Accept push updates is enabled. See Override push on page
66.
Scheduled Updates Enable to schedule updates to be sent to the FortiGate at the specified time.
See Scheduled updates on page 64.
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
package legacy attacks, along with the regular IPS database that protects against the
latest common and in-the-wild attacks.
4. Click Apply.
Manual updates
7. In the pane that opens, click Upload, locate the downloaded definitions file on your computer, then click Open.
The download may take a few minutes to complete.
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 AV & IPS Definitions button to
manually update the definitions.
1. Go to System > FortiGuard
2. Scroll down to the AntiVirus & IPS Updates section.
3. Enable Scheduled Updates.
5. 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. Scroll down to the AntiVirus & IPS Updates section.
3. Enable Accept push updates.
4. 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
Virtual IPs with port forwarding on page 425 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. Scroll down to the AntiVirus & IPS Updates section.
3. Enable Accept push updates.
4. Enable Use override push.
5. Enter the IP address and port number configured on the NAT device.
6. 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 antivirus and IPS options on page 63). 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.
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. Scroll down to the Update Server Location section.
3. Select US only or Lowest latency locations.
4. Click Apply.
Filtering
Web filtering is used to block access to harmful, inappropriate, and dangerous web sites. See Web Filter on page 515
for details.
Email filtering is used to detect and block spam messages. See Email filter on page 594 for details.
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.
Anti-Spam Cache Enable/disable email filter cache, and set the amount of time that the
FortiGate will store an email address locally.
FortiGuard Filtering Select the protocol for contacting the FortiGuard servers.
Protocol
FortiGuard Filtering Port Select the port assignments for contacting the FortiGuard servers.
Filtering Service Availability The status of the filtering service. Click Check Again if the filtering service is
not available.
Request re-evaluation of a Click to re-evaluate a URL’s category rating on the FortiGuard web filter
URL's category service.
4. Click Apply.
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 publish FortiGuard servers can also
be disabled.
1. Go to System > FortiGuard
2. Scroll down to the Override FortiGuard Servers section.
3. In the table, click Create New. The Create New Override FortiGuard Server pane opens.
4. Select the server address type: IPv4, IPv6, or FQDN.
5. Enter the server address of the selected type in the Address field.
6. Select the type of server: AntiVirus & IPS Updates, Filtering, or Both.
7. Click Apply.
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
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.
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.
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://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.
By default, the FortiSandbox Cloud FortiSandbox type is not visible. See Feature
visibility on page 24 for instructions on making it visible.
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 > IPv4 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. Scroll down to Filtering Services Availability and select Check
Again. 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)
l TZ: Server time zone
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 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.
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.
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.
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.
FortiAnalyzer documentation: https://docs.fortinet.com/product/fortianalyzer
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.
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.
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.
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.
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.
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.
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.
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 that uses
FortiTelemetry. 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.
FortiSwitch documentation: https://docs.fortinet.com/product/fortiswitch
Device Description
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.
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.
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.
This section contains information about how to configure the following devices as part of the Fortinet Security Fabric:
l FortiGate
l FortiAnalyzer
l FortiManager
l FortiSandbox
l FortiClient EMS
l FortiAP and FortiSwitch
l Additional devices
System requirements
To set up the Security Fabric in FortiOS 6.2, 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 Either disable VDOMs on all FortiGate devices that you want to add to the Security Fabric or make sure devices are
in split-task VDOM mode. See Virtual Domains on page 365.
l Configure all FortiGate devices to operate in NAT mode.
FortiGate
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.
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.
3. Enter the Group name and select the FortiTelemetry enabled interfaces.
4. In the FortiAnalyzer Logging section, in the IP address field, enter the IP address of the FortiAnalyzer.
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 FortiAnalyzer on page 81.
5. If you need log transmissions to be encrypted, enable SSL encrypt log transmission.
6. If required, enable Allow access to FortiGate REST API and, optionally, Trust FortiAnalyzer by serial number.
The FortiGate will verify the FortiAnalyzer by retrieving its serial number and checking it against the FortiAnalyzer
certificate. 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. For more information,
see Simplify FortiAnalyzer Pairing, in the FortiOS 6.2.0 New Features Guide.
7. Click Apply.
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.
When a downstream Fortinet device's serial number 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.
To pre-authorize a FortiGate:
7. Enter the IP address of the upstream or root FortiGate in the FortiGate IP field.
8. Add the FortiTelemetry enabled interfaces.
9. Click Apply.
10. On the root FortiGate, go to Security Fabric > Settings and verify that the downstream FortiGate that you added
appears in the Security Fabric topology.
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.
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 FortiTelemetry enabled on the interface that the device connects to.
1. Connect to the unauthorized FortiGate or FortiWiFi device, and go to Security Fabric > Settings.
2. Enable FortiGate Telemetry.
3. To connect, enable Connect to upstream FortiGate.
4. Set FortiGate IP to the IP address of the upstream FortiGate.
5. Connect to the root FortiGate and go to Security Fabric > Settings. The new FortiGate appears in the Topology as
unauthorized.
6. Click on 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:
FortiAnalyzer
FortiAnalyzer is a required component for the Security Fabric. It 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 77.
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.
On the FortiGate devices, the FortiAnalyzer Logging section on the Security Fabric > Settings page will now show
the ADOM on the FortiAnalyzer that the FortiGate is in, and the storage, analytics, and archive usage.
FortiSandbox
The Security Fabric supports FortiSandbox appliances and FortiSandbox Cloud. A FortiGate Cloud account is not
required (see Decouple FortiSandbox Cloud from FortiGate Cloud, in the FortiOS 6.2.0 New Features Guide).
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.
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.
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 central management 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 allow 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.
FortiClient EMS
You can configure endpoint control for your Security Fabric using FortiClient Endpoint Management System (EMS). Up
to three EMS servers can be added on the global Security Fabric settings page. EMS settings are synchronized between
all fabric members.
If you disable FortiClient Endpoint Management System (EMS) on the Security Fabric >
Settings page, all previously configured EMS server entries will be deleted.
To add a FortiClient EMS server to the Security Fabric using 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 server to the Security Fabric using the GUI:
1. To enable endpoint control, on the root FortiGate, go to System > Feature Visibility and enable Endpoint Control.
2. Go to Security Fabric > Settings.
3. Enable FortiClient Endpoint Management System (EMS).
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.
Additional devices
To add one or more of the devices to the Security Fabric in the GUI:
6. Click Apply.
The added devices are shown in the FortiGate Telemetry section Topology list.
To add one or more of the devices to the Security Fabric in the CLI:
For more information, see Telemetry Integration - New FTNT Products, in the FortiOS 6.2.0 New Features Guide.
The Security Fabric includes multiple features that can improve your network security.
l Dashboard widgets on page 89
l Topology on page 91
l Security rating on page 96
l Automation stitches on page 99
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.
Security Rating
The Security Rating widget shows the security rating for your Security Fabric. It can show the current rating percentile,
or historical security rating score or percentile charts.
The widget can be configured to show how your organization's security rating compares to the ratings of either all
organizations, or only organizations that are in the same industry and/or geographic region as you (determined from
your FortiCare account settings).
To receive a security rating score, all FortiGate devices that are in the Security Fabric must have a valid Security Rating
License.
Fabric Device
The Fabric Device widget show 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 FortiCare Registration pane opens.
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. The size of the bubbles in the topology vary based on traffic volume. Only Fortinet devices are shown in
the topologies.
In both views, filtering and sorting options allow you 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 on it will open the Security Rating page. See Security rating on page 96 for more information.
Servers and server clusters are represented by squares with rounded corners, and are grouped separately from circular
endpoints. Devices are grouped by device type, and colored based on their risk level.
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.
WAN cloud
The WAN cloud icon includes a drop-down 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
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 see more
details, right-click on the chart and select Destination Owner Details to go to the FortiView > Destinations page.
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.
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 Bubble Option drop-down list, select one of the following views:
l Device Traffic: Organize devices by traffic.
l Device Count: Organize devices by the number of devices connected to it.
l Risk: Only include devices that have endpoints with medium, high, or critical risk values of the specified type: All,
Compromised Host, Vulnerability, Threat Score.
l No Devices: Don't show endpoints.
The time period drop-down list filters the view by time. Options include: now (real time), 5 minutes, 1 hour, 24 hours, 7
days.
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 drop-down menu also provides options to drill down to more information on compromised hosts or endpoint
vulnerabilities.
Clicking Drill Down to Compromised Hosts will open the FortiView > Compromised Hosts page showing 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.
Clicking Drill Down to Endpoint Vulnerability will open the vulnerabilities page showing 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.
Security rating
The security rating analyzes your Security Fabric deployment, identifies potential vulnerabilities, highlights best
practices that can be used to improve the security and performance of your network, and calculates Security Fabric
scores.
To view the security rating and run a security rating check, go to Security Fabric > Security Rating on the root
FortiGate. Click Run Now to run a security rating check. Checks can also be run automatically every four hours.
The security rating check uses real-time monitoring to analyze the network based on the current network configuration.
When the check is complete, the results table shows a list of the checks that where performed, including:
l The name and a description of the check.
l The device or devices that the check was performed on.
l The impact of the check on the overall security score.
l The check results - whether it passed or failed.
The list can be searched, filtered to show all results or only failed checks, and exported to a CSV or JSON file. Clicking
on a color or legend name in the donut charts will also filter the results.
Hovering the cursor over a check result score will show the breakdown of how that score was calculated.
Selecting a specific check from the list shows details about that check in the Security Control Details pane, including
recommendations and compliance information. For failed checks, this includes a description of what remediation
actions could be taken. For recommendations that support Easy Apply, the device will have an EZ symbol next to its
name, and the remediation action can be taken automatically by clicking Apply under the recommendations.
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 can be 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 > Security Rating Events.
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.
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
x 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 affect 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 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
also 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.
Trigger Select a trigger.
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 collated alert is sent that includes all the
events that occurred during the interval.
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 email-body <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>
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>
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
Security Rating Summary A summary is available for a recently run Security Rating.
FortiAnalyzer Event Handler The specified FortiAnalyzer event handler has occurred. See FortiAnalyzer event
handler trigger on page 103 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.
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:
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.
3. Click Apply.
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:
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 Email sample on page 110 for details.
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
Monitor > Quarantine Monitor to view and manage quarantined IP addresses.
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 NSX
Quarantine action on page 110 for details.
Action Description
AWS Lambda Send log data to an integrated AWS service. See AWS Lambda action on page
113 for details.
Azure Function Send log data to an Azure function. See Azure Function action on page 115 for
details.
Google Cloud Function Send log data to a Google Cloud function. See Google Cloud Function action on
page 117 for details.
AliCloud Function Send log data to an AliCloud function. See AliCloud Function action on page 119
for details.
Webhook Send an HTTP request using a REST callback. See Webhook action on page 122
for details.
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:
If an endpoint instance in a VMware NSX environment is compromised, this action will assign the configured security
tag is 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.
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.
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:
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
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"
Diagnostics
Example:
# diagnose automation test HA-failover
automation test is done. stitch:HA-failover
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
This recipe 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.
The following shows a sample network topology of three downstream FortiGates (Accounting, Marketing, and Sales)
connected to the root FortiGate (Edge).
1. Configure interface:
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 > Settings.
l Enable FortiGate Telemetry.
l Set a Group name, such as Office-Security-Fabric.
l Add port10 and port11 to FortiTelemetry enabled interfaces.
After FortiGate Telemetry is enabled, FortiAnalyzer automatically enables Logging and Upload Option is set
to Real Time.
b. Set IP address to the FortiAnalyzer IP 192.168.65.10.
c. Select 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.
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.
l Click Create New.
l Set Name to FAZ-addr.
l Set Type to Subnet.
l Set Subnet/IP Range to 192.168.65.10/32.
l Set Interface to any.
l Click Create New.
l Set Name to Accounting.
l Set Type to Subnet.
l Set Subnet/IP Range to 192.168.10.10/32.
l Set Interface to any.
b. In the root FortiGate (Edge), go to Policy & Objects > IPv4 Policy.
l Set Name to Accounting-to-FAZ.
l Set srcintf to port10.
l Set dstintf to port16.
l Set srcaddr to Accounting-addr.
l Set dstaddr to FAZ-addr.
l Set Action to Accept.
l Set Schedule to Always.
l Set Service to All.
l Enable NAT.
l Set IP Pool Configuration to Use Outgoing Interface Address.
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.
l Set Type to Subnet.
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:
l Set Destination to 0.0.0.0/0.0.0.0.
l Set Interface to wan1.
l Set Gateway Address to 192.168.10.2.
3. Configure Security Fabric:
a. In the downstream FortiGate (Accounting), go to Security Fabric > Settings.
l Enable FortiGate Telemetry.
l Enable Connect to upstream FortiGate.
l FortiGate IP is filled in automatically with the default static route Gateway Address of 192.168.10.2 set
in the previous step.
l Leave FortiTelemetry enabled interfaces empty since there is no downstream FortiGate connecting to it.
After FortiGate Telemetry is enabled, FortiAnalyzer automatically enables Logging. Settings for the
FortiAnalyzer are retrieved from the root FortiGate (Edge) when FortiGate (Accounting) connects to the root
FortiGate (Edge).
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:
l Set Destination to 0.0.0.0/0.0.0.0.
l Set Interface to wan1.
l Set Gateway Address to 192.168.200.2.
3. Configure Security Fabric:
a. In the downstream FortiGate (Marketing), go to Security Fabric > Settings.
l Enable FortiGate Telemetry.
l Enable Connect to upstream FortiGate.
l FortiGate IP is filled in automatically with the default static route Gateway Address of 192.168.200.2 set
in the previous step.
l In FortiTelemetry enabled interfaces, add port12.
After FortiGate Telemetry is enabled, FortiAnalyzer automatically enables Logging. Settings for the
FortiAnalyzer are retrieved from the root FortiGate (Edge) when FortiGate (Marketing) connects to the root
FortiGate (Edge).
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.
l Set Type to Subnet.
l Set Subnet/IP Range to 192.168.65.10/32.
l Set Interface to any.
b. Click Create New.
l Set Name to Sales-addr.
l Set Type to Subnet.
l Set Subnet/IP Range to 192.168.135.10/32.
l Set Interface to any.
c. In the downstream FortiGate (Marketing), go to Policy & Objects > IPv4 Policy.
l Set Name to Sales-to-FAZ.
l Set srcintf to port12.
l Set dstintf to wan1.
l Set srcaddr to Sales-addr.
l Set dstaddr to FAZ-addr.
l Set Action to Accept.
l Set Schedule to Always.
l Set Service to All.
l Enable NAT.
l Set IP Pool Configuration to Use Outgoing Interface Address.
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:
l Set Destination to 0.0.0.0/0.0.0.0.
l Set Interface to wan1.
l Set Gateway Address to 192.168.10.2.
3. Configure Security Fabric:
a. In the downstream FortiGate (Accounting), go to Security Fabric > Settings.
l Enable FortiGate Telemetry.
l Enable Connect to upstream FortiGate.
l FortiGate IP is filled in automatically with the default static route Gateway Address of 192.168.10.2 set
in the previous step.
l Leave FortiTelemetry enabled interfaces empty since there is no downstream FortiGate connecting to it.
After FortiGate Telemetry is enabled, FortiAnalyzer automatically enables Logging. Settings for the
FortiAnalyzer are retrieved from the root FortiGate (Edge) when FortiGate (Accounting) connects to the root
FortiGate (Edge).
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:
l Set Destination to 0.0.0.0/0.0.0.0.
l Set Interface to wan2.
l Set Gateway Address to 192.168.135.11.
3. Configure Security Fabric:
a. In the downstream FortiGate (Sales), go to Security Fabric > Settings.
l Enable FortiGate Telemetry.
l Enable Connect to upstream FortiGate.
l FortiGate IP is filled in automatically with the default static route Gateway Address of 192.168.135.11
set in the previous step.
l Leave FortiTelemetry enabled interfaces empty since there is no downstream FortiGate connecting to it.
After FortiGate Telemetry is enabled, FortiAnalyzer automatically enables Logging. Settings for the
FortiAnalyzer are retrieved from the root FortiGate (Edge) when FortiGate (Sales) connects to the root
FortiGate (Edge).
To authorize downstream FortiGates (Accounting, Marketing, and Sales) on the root FortiGate (Edge):
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
This recipe provides an example of configuring Security Fabric over IPsec VPN.
The following sample topology shows a downstream FortiGate (HQ2) connected to the root FortiGate (HQ1) over IPsec
VPN to join Security Fabric.
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
2. Configure the static route to connect to the Internet:
a. Go to Network > Static Routes and click Create New.
l Set Destination to 0.0.0.0/0.0.0.0.
l Set Interface to port2.
l Set Gateway Address to 10.2.200.2.
3. Configure IPsec VPN:
a. Go to VPN > IPsec Wizard.
l Set VPN Name to To-HQ2.
l Set Template Type to Custom.
l Click Next.
l Set Authentication to Method.
l Set Pre-shared Key to 123456.
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.
l Set the IP/Network Mask to 10.10.10.1/255.255.255.255.
l Set Remote IP/Network Mask to 10.10.10.3/255.255.255.0.
5. Configure IPsec VPN local and remote subnet:
a. Go to Policy & Objects > Addresses.
l Click Create New
l Set Name to To-HQ2_local_subnet_1.
l Set Type to Subnet.
l Set IP/Network Mask to 192.168.8.0/24.
l Click OK.
l Click Create New
l Set Name to To-HQ2_remote_subnet_1.
l Set Type to Subnet.
l Set IP/Network Mask to 10.1.100.0/24.
l 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.
c. Edit interface vlan20:
l Set Role to LAN.
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.
l Set Destination to 0.0.0.0/0.0.0.0.
l Set Interface to wan1.
l Set Gateway Address to 192.168.7.2.
3. Configure IPsec VPN:
a. Go to VPN > IPsec Wizard.
l Set VPN Name to To-HQ1.
l Set Template Type to Custom.
l Click Next.
l In the Network IP Address, enter 10.2.200.1.
l Set Interface to wan1.
l Set Authentication to Method.
l Set Pre-shared Key to 123456.
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 .
l Set the IP/Network Mask to 10.10.10.3/255.255.255.255.
l Set Remote IP/Network Mask to 10.10.10.1/255.255.255.0.0.
5. Configure IPsec VPN local and remote subnet:
a. Go to Policy & Objects > Addresses.
l Click Create New
l Set Name to To-HQ1_local_subnet_1.
l Set Type to Subnet.
l Set IP/Network Mask to 10.1.100.0/24.
l Click OK.
l Click Create New
l Set Name to To-HQ1_remote_subnet_1.
l Set Type to Subnet.
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:
This recipe 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).
3. Configure the default static route to connect to the root FortiGate. Go to Network > Static Routes. Set the
Destination to 0.0.0.0/0.0.0.0, select port4 as the Interface, and set the Gateway Address as 192.168.5.254.
4. Configure the Security Fabric:
a. Go to Security Fabric > Settings.
b. Enable FortiGate Telemetry.
c. Configure a group name.
d. In FortiTelemetry enabled interfaces, add vlan70.
e. FortiAnalyzer logging is enabled and the Upload option is set to Real Time after FortiGate Telemetry is
enabled. Set the IP address to the FortiAnalyzer IP address, which in this example is 192.168.8.250.
FortiAnalyzer settings will be retrieved when the downstream FortiGate connects to the root FortiGate.
5. Create a policy to access the Internet. Go to Policy & Objects > IPv4 Policy. Click Create New, and configure the
policy as follows:
a. Set the Name to Access-internet1.
b. Set the Source Interface to vlan70 and the Destination Interface to port4.
c. Set the Source Address to all and the Destination Address to all.
d. Set the Action to ACCEPT.
e. Set the Schedule to Always.
f. Set the Service to ALL.
g. Enable NAT.
h. Set the IP Pool Configuration to Use Outgoing Interface Address.
6. Create an address for the FortiAnalyzer:
a. Go to Policy & Objects > Addresses. Click Create New, then Address.
b. Set the Name to FAZ-addr.
c. Set the Type to Subnet.
d. Set the Subnet/IP Range to 192.168.8.250/32.
e. Set the Interface to Any.
7. Create a policy for the downstream FortiGate to access the FortiAnalyzer. Go to Policy & Objects > IPv4 Policy.
Click Create New, and configure the policy as follows:
a. Set the Name to Access-Resources.
b. Set the Source Interface to vlan70 and the Destination Interface to port6.
c. Set the Source Address to all and the Destination Address to FAZ-addr.
d. Set the Action to ACCEPT.
e. Set the Schedule to Always.
f. Set the Service to ALL.
g. Enable NAT.
h. Set the IP Pool Configuration to Use Outgoing Interface Address.
d. Return to Network > Interfaces and click Create New. For the new interface, set the name to vlan20, Type to
VLAN, Interface to wan2, VLAN ID to 20, Role to LAN, and IP/Network Mask to 10.1.100.3/255.255.255.0.
2. Authorize the Access FortiSwitch:
a. Go to WiFi & Switch Controller > Managed FortiSwitch.
b. Click the FortiGate icon, then click Edit. Set the Name to Access-Switch, enable the Authorized option, then
click OK.
c. Click the FortiSwitch port2 icon. For port2's Native VLAN, select vlan20.
3. Configure the default static route to connect to the root FortiGate. Go to Network > Static Routes. Set the
Destination to 0.0.0.0/0.0.0.0, select wan1 as the Interface, and set the Gateway Address as 192.168.7.2.
4. Configure the Security Fabric:
a. Go to Security Fabric > Settings.
b. Enable FortiGate Telemetry.
c. Under FortiGate Telemetry, enable Connect to upstream FortiGate.
d. Configure the FortiGate IP to 192.168.7.2.
e. In FortiTelemetry enabled interfaces, add vlan20.
f. FortiAnalyzer logging is enabled after FortiGate Telemetry is enabled. FortiAnalyzer settings will be retrieved
when the downstream FortiGate connects to the root FortiGate.
5. Create a policy to access the Internet. Go to Policy & Objects > IPv4 Policy. Click Create New, and configure the
policy as follows:
a. Set the Name to Access-internet2.
b. Set the Source Interface to vlan20 and the Destination Interface to wan1..
c. Set the Source Address to all and the Destination Address to all.
d. Set the Action to ACCEPT.
e. Set the Schedule to Always.
f. Set the Service to ALL.
g. Enable NAT.
h. Set the IP Pool Configuration to Use Outgoing Interface Address.
i. Choose the default Web Filter profile.
1. In FortiOS on the root FortiGate, go to Security Fabric > Settings. In the Topology field, a highlighted FortiGate
with a serial number is connecting to the root FortiGate, and a highlighted warning asks for authorization of the
highlighted device.
2. Click the highlighted FortiGate, then select Authorize. After authorization, the downstream FortiGate appears in
the Topology field in Security Fabric > Settings, meaning that the downstream FortiGate joined the Security
Fabric successfully.
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.
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:
Marketing # diagnose sys csf upstream
Upstream Information:
Serial Number:FG201ETK18902514
IP:192.168.7.2
Connecting interface:wan1
Connection status:Authorized
3. To show the quarantined endpoint host in the connected FortiGate, run the following commands in the
downstream FortiGate (Marketing) CLI:
Marketing # show user quarantine
config user quarantine
config targets
edit "PC2"
set description "Manually quarantined"
config macs
edit 00:0c:29:3d:89:39
set description "manual-qtn Hostname: PC2"
next
end
next
end
end
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.
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 Security Fabric Settings page opens with all the required settings automatically
configured.
4. Click Apply 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 both IdP or SP.
When 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. Administrator 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.
All administrators must be actively added to each SP. When an administrator first logs in to an SP, a temporary account
is created with the no access profile assigned, and the device administrator must enable access for each account on
each device.
6. Click Apply.
Configuring FGT_B as an SP
6. Click Apply.
6. Click OK.
When the administrator logs in to the FortiGate for the first time by using the SSO option, a local SAML SSO account is
automatically created on the FortiGate SP.
3. Click Login.
A GUI warning opens.
As the account is using a restricted access profile, additional permissions must be granted by the device
administrator.
4. Click Logout.
By default, the SAML SSO account is assigned the no_access administrator profile. Device administrators must assign
a security profile to the SAML SSO account that allows access to the FortiGate SP.
The new Single Sign-On Administrator was automatically created when it logged in the first time.
3. Edit the new SSO admin, and change their Administrator Profile.
4. Click OK.
1. At the FGT_B login prompt, click or via Single Sign-On. The SSO login prompt opens.
2. Enter the login information for the SSO administrator.
3. Click Login.
FGT_B is successfully logged into.
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.
9. Go to User & Device > SAML SSO, and select Identify Provider (IdP) to verify the new SAML SSO configuration
on the root FortiGate IdP for downstream FortiGate SPs.
10. Select Service Provider (SP) to verify the configuration for downstream FortiGates.
The Default login page option is set to Normal by default, which means that admin login screen on this FortiGate
offers options for local system admin login and SAML SSO login.
In the Default admin profile option, you can select one of the preconfigured profiles that gives access to FortiGate.
Alternately you can create a custom profile and select it. The default profile admin_no_access must be changed
later for every SSO admin.
In the IdP Settings area, the IdP certificate option uses the REMOTE_CERT_1 as the server certificate for the
root FortiGate.
In the SP certificate option, you can optionally select a server certificate to be used by downstream FortiGates as
client certificates when connecting to the root FortiGate. For the root FortiGate, you can select a default Fortinet
server certificate or a custom certificate.
After you have logged in to a Security Fabric member by using SSO, you can navigate between any Security Fabric
member with SSO configured.
You can log in to a FortiGate SP from a FortiGate IdP. This topic describes how to log in to a root FortiGate IdP, and
navigate to other FortiGate SPs in the Security Fabric without further authentication.
In this example, 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.
3. In the Topology area, 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 root FGT IdP for authentication. If your browser cache is manually cleared, or you close your
browser, you must authenticate again.
This example describes how 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.
1. Open a tab in a browser, and log in to a downstream FortiGate SP using your SSO administrator account.
In this example, the SSO administrator account is named test3.
2. Open a new tab in the browser, and log in to a FortiGate SP that is not a member of the Security Fabric, but uses
the root FortiGate IdP in the Security Fabric as the Identity Provider.
Although the administrator named test3 on the root FortiGate IdP was used for authentication on both systems,
SSO administrator names on different FortiGate SPs can vary, depending on what was configured as the SAML
attribute type for the specific FortiGate SP on the root FortiGate IdP. 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.
You can manually configure SAML SSO on FortiGate IdP and FortiGate SPs. It requires the following tasks:
1. Manually configure SAML SSO on the root FortiGate IdP.
2. Manually configure SAML SSO on FortiGate SPs.
In this case the FortiGate SP is not a member of the Security Fabric. Although the FortiGate SP is not part of the
Security Fabric, it will use the root FortiGate IdP for SAML SSO authentication.
On the root FortiGate IdP, you can see the difference between a FortiGate SP that joined the Security Fabric and
another FortiGate SP (FGT-184) that is not part of the Security Fabric:
The SP certificate toggle is optional. When enabled, the FortiGate SP requires a server certificate that is trusted by
the root FortiGate IdP.
6. Toggle on SAML Attribute.
7. Beside Type, select Username.
8. Click OK.
You can select Custom when you want to change the default settings for IdP single-sign-on URL and IdP single
logout URL, for example:
4. In the Prefix option paste the value from the Prefix option on the root FortiGate IdP.
5. In IdP certificate option, select the server certificate from the FortiGate IdP.
If the certificate is not available locally on the FortiGate SP, you must click + Import the FortiGate IdP server
certificate as REMOTE_CERT from local file system.
6. Click OK.
Because communication between the root FortiGate IdP and FortiGate SPs is secured, you must select a local server
certificate for FortiGate IdP in the IdP certificate option. When a downstream FortiGate SP joins a root FortiGate IdP,
the FortiGate SP automatically obtains the certificate. In the following example, the IdP certificate displays REMOTE_
CERT_1, which is the root server certificate for the FortiGate IdP.
If you are manually configuring FortiGate SPs, you can download the certificate from the FortiGate IdP, and then import
it for use with the manual configuration of FortiGate SPs.
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 usernames might not be unique, cases can occur where the username 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 usernames to better track what actions
were taken by each administrator.
After the administrator (test3) logs in to FortiGate SP for the first time, SAML authentication occurs on FortiGate
SP. A new SSO administrator account is created, and the account name is the email address instead of the login
name (test3).
If the SAML attribute had been set to the default setting of username, the username for the SSO administrator
account would have been test3, which is the same username as the local administrator account. With the
SAML attribute set to custom, the SSO administrator account [email protected] is used as the username on
the FortiGate SP, and it appears in the log files.
The csf_172.18.60.185 service provider was automatically added when FortiGate SP 172.18.60.185 joined 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 by using the CLI or GUI.
A FortiGate SP that is not a member of the Security Fabric can also be configured for SAML SSO services provided by
root FortiGate IdP in a Security Fabric. However, this scenario requires manual configuration on root FortiGate IdP and
on the FortiGate SP.
FortiGate SP changes
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.
Fabric connectors allow you to connect your network to external services. Following are the categories of connectors:
Public SDN, Private SDN, SSO/Identity, and Threat Feeds.
If VDOMs are enabled, SDN and Threat Feeds connectors are in the global settings, and
SSO/Identity connectors are per VDOM.
SDN connectors
Fabric connectors to SDNs provide integration and orchestration of Fortinet products with SDN solutions. Fabric
Connectors ensure that any changes in the SDN environment are automatically updated in your network.
There are four steps to creating and using an SDN connector:
1. Gather the required information
2. Create the fabric connector on page 177
Required information
AliCloud l AccessKey ID
l AccessKey Secret
l Region ID
Kubernetes l IP address
l Port
l Secret token
The available CLI commands will vary depending on the selected SDN connector type.
The available CLI commands will vary depending on the selected SDN connector type.
A fabric connector address can be used as either the source or destination address.
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
AliCloud SDN connector will automatically populate and update IP addresses only for 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
For instances running in AWS (on demand or BYOL), you can now set up the AWS SDN connector by using AWS
Identify and Access Management (IAM) credentials.
IAM authentication is available only for FGT-AWS and FGT-AWSONDEMAND platforms.
edit "aws-ec2"
set type dynamic
set sdn "aws1"
set filter "SecurityGroupId=sg-05f4749cf84267548"
set sdn-addr-type public
next
edit "aws-eks1"
set type dynamic
set sdn "aws1"
set filter "K8S_Region=us-west-2"
next
end
3. Confirm that the AWS SDN connector resolves dynamic firewall IP addresses using the configured filter:
config firewall address
edit "aws-ec2"
set uuid e756e786-3a2e-51e9-9d40-9492098de42d
set type dynamic
set sdn "aws1"
set filter "SecurityGroupId=sg-05f4749cf84267548"
set sdn-addr-type public
config list
edit "34.222.246.198"
next
edit "54.188.139.177"
next
edit "54.218.229.229"
next
end
next
edit "aws-eks1"
set uuid d84589aa-3a10-51e9-b1ac-08145abce4d6
set type dynamic
set sdn "aws1"
set filter "K8S_Region=us-west-2"
config list
edit "192.168.114.197"
next
edit "192.168.167.20"
next
edit "192.168.180.72"
next
edit "192.168.181.186"
next
edit "192.168.210.107"
next
end
next
end
FortiOS automatically updates dynamic addresses for Azure Stack on-premise environments using an Azure Stack
SDN connector, including mapping the following attributes from Azure Stack instances to dynamic address groups in
FortiOS:
l vm
l tag
l size
l securitygroup
l vnet
l subnet
l resourcegroup
l vmss
2. Create a dynamic firewall address for the configured Azure Stack 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
Azure Stack SDN connector will automatically populate and update IP addresses only for instances that are
named tfgta:
3. Ensure that the Azure Stack 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 are named tftgta as
configured in step 2:
You can create an endpoint connector to Cisco pxGrid by using FortiManager. FortiManager dynamically collects
updates from pxGrid and forwards them to FortiGate by using the Fortinet Single Sign On (FSSO) protocol.
4. On FortiManager, synchronize the policy package to the firewall for the managed FortiGate.
5. On FortiGate, verify that the synced firewall policy contains the correct FSSO group and that all FSSO-related
information in user adgrp is correct.
6. After successful user authentication on Cisco ISE, verify that information is forwarded to FortiManager.
On FortiManager, the icon next to the authenticated user in pxGrid Monitor should be green.
FortiGate should have two entries: one in the firewall-authenticated user list and one in the FSSO logged-on user
list.
In the FSSO logged-on user list, you can view both groups. You view the group that the user belongs to on Cisco
ISE and the Fortinet FSSO group.
You can select a domain attribute when configuring an OpenStack SDN connector in FortiOS. When a domain is
configured for the OpenStack SDN connector, FortiOS resolves OpenStack dynamic firewall addresses from the
specified OpenStack domain. If a domain is not specified, FortiOS resolves the dynamic firewall addresses using the
default OpenStack domain.
To configure OpenStack SDN connector with a domain filter using the GUI:
2. Create a dynamic firewall address for the configured OpenStack 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. The OpenStack
SDN connector will automatically populate and update IP addresses only for instances that belong to the
specified domain and network:
3. Ensure that the OpenStack 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 specified
1. Configure the OpenStack SDN connector. The SDN connector will only resolve IP addresses for instances that
belong to the specified domain:
config system sdn-connector
edit "openstack-domain"
set type openstack
set server "http://172.16.165.86:5000"
set username "example_username"
set password xxxxx
set domain "example_domain"
set update-interval 30
next
end
2. Create a dynamic firewall address for the configured OpenStack SDN connector with the supported OpenStack
filter. The OpenStack SDN connector will automatically populate and update IP addresses only for instances that
belong to the specified domain and the specified network:
config firewall address
edit "openstack-domain-network"
set type dynamic
set sdn "openstack-domain"
set filter "Network=example-net1"
next
end
3. Confirm that the OpenStack SDN connector resolves dynamic firewall IP addresses using the configured domain
and filter:
config firewall address
edit "openstack-domain-network"
set uuid 02837298-234d-51e9-efda-559c6001438a
set type dynamic
set sdn "openstack-domain"
set filter "Network=example-net1"
config list
edit "10.0.0.13"
next
edit "10.0.0.16"
next
edit "10.0.0.3"
next
edit "172.24.4.18"
next
edit "172.24.4.24"
next
edit "172.24.4.3"
next
end
next
end
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:
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.
Multiple concurrent SDN/Cloud connectors are not supported yet for Cisco ACI or Nuage.
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.
The following recipes provide information about configuring Kubernetes SDN connectors:
l Private Cloud K8s SDN connector on page 202
l AWS Kubernetes (EKS) SDN connector on page 205
l Azure Kubernetes (AKS) SDN connector on page 210
l GCP Kubernetes (GKE) SDN connector on page 207
l Oracle Kubernetes (OKE) SDN connector on page 212
FortiOS automatically updates dynamic 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.
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:
AWS SDN connectors support dynamic address groups based on AWS Kubernetes (EKS) filters.
To filter out the Kubernetes IP addresses, the following address filters have been introduced:
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.
end
The dynamic firewall address IP is resolved by the SDN connector:
config firewall address
edit "aws-pod"
set uuid a7a37298-19e6-51e9-851a-2c551ffc174d
set type dynamic
set sdn "aws1"
set filter "K8S_PodName=aws-node-g6zhx"
config list
edit "192.168.114.197"
next
end
next
end
Google Cloud Platform (GCP) SDN connectors support dynamic address groups based on GCP Kubernetes Engine
(GKE) filters.
To filter out the Kubernetes IP addresses, the following address filters have been introduced:
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. In this example, the GCP SDN
connector will automatically populate and update IP addresses only for instances that belong to the zhm-
kc3 cluster:
end
next
end
Azure SDN connectors support dynamic address groups based on Azure Kubernetes (AKS) filters.
To filter out the Kubernetes IP addresses, the following address filters have been introduced:
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
Azure SDN connector will automatically populate and update IP addresses only for instances that belong to the
zhmKC cluster:
OCI SDN connectors support dynamic address groups based on Oracle Kubernetes (OKE) filters.
To filter out the Kubernetes IP addresses, the following address filters have been introduced:
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. Configure the addresses.
Threat feeds
Threat feeds dynamically import an external block lists from an HTTP server in the form of a 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 and SSL inspection exemptions.
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.
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 Use External
Malware Block List enabled.
Note: For optimal performance, do not mix different hashes in the list. Only use one of MD5,
SHA1, or SHA26.
Example:
292b2e6bb027cd4ff4d24e338f5c48de
dda37961870ce079defbf185eeeef905 Trojan-Ransom.Win32.Locky.abfl
3fa86717650a17d075d856a41b3874265f8e9eab Trojan-Ransom.Win32.Locky.abfl
c35f705df9e475305c0984b05991d444450809c35dd1d96106bb8e7128b9082f
Trojan-Ransom.Win32.Locky.abfl
See External malware blocklist for Antivirus on page 500 for an example.
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).
5. Click OK.
Parameters marked with a * 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 > Fabric 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 Block List (Threat Feed) for web filtering and DNS. You can also use External Block List
(Threat Feed) in firewall policies.
Sample configuration
In Security Fabric > Fabric Connectors > Threat Feeds > IP Address, create or edit an external IP list object.
To apply an external iplist object to the firewall policy using the CLI:
The external Threat Feed connector (block list retrieved by HTTPS) supports username and password authentication.
The Malware Hash type of Threat Feed connector supports a list of file hashes that can be used as part of Virus
Outbreak Prevention.
1. Navigate to Security Fabric > Fabric Connectors and click Create New.
2. In the Threat Feeds section, click Malware Hash.
4. Beside the Last Update field, click View Entries to display the external Malware Hash list contents.
config global
end
In Security Profiles > AntiVirus, the Virus Outbreak Prevention section allows you to enable the following options:
l Use Fortinet outbreak Prevention Database.
l Use External Malware Block List.
You must first enable outbreak-prevention in the protocol and then enable external-blocklist under
outbreak-prevention.
config antivirus profile
edit "av"
set analytics-db enable
config http
set options scan
set outbreak-prevention full-archive
end
config ftp
set options scan
set outbreak-prevention files
end
config imap
set options scan
set outbreak-prevention full-archive
end
config pop3
set options scan
set outbreak-prevention full-archive
end
config smtp
set options scan
set outbreak-prevention files
end
config mapi
set options scan
set outbreak-prevention full-archive
end
config nntp
set options scan
set outbreak-prevention full-archive
end
config smb
set options scan
set outbreak-prevention full-archive
end
config outbreak-prevention
set ftgd-service enable
set external-blocklist enable
end
next
end
This feature adds the fields filehash and filehashsrc to outbreak prevention detection events.
Example of the utm-virus log generated when a file is detected by FortiGuard queried outbreak prevention:
2: date=2018-07-30 time=13:57:59 logid="0204008202" type="utm" subtype="virus" event-
type="outbreak-prevention" level="warning" vd="root" evnttime=1532984279 msg="Blocked by Virus
Outbreak Prevention service." action="blocked" service="HTTP" sessionid=174777 srcip-
p=192.168.101.20 dstip=172.16.67.148 srcport=37044 dstport=80 srcintf="lan" srcintfrole="lan"
dstintf="wan1" dstintfrole="wan" policyid=1 proto=6 direction="incoming" filename="zhvo_test.-
com" checksum="583369a5" quarskip="No-skip" virus="503e99fe40ee120c45bc9a30835e7256fff3e46a"
dtype="File Hash" filehash="503e99fe40ee120c45bc9a30835e7256fff3e46a" file-
hashsrc="fortiguard" url="http://172.16.67.148/zhvo_test.com" profile="mhash_test" agent-
t="Firefox/43.0" analyticssubmit="false" crscore=30 crlevel="high“
Example of the utm-virus 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" event-
type="malware-list" level="warning" vd="root" eventtime=1532984381 msg="Blocked by local mal-
ware 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" check-
sum="90f0cb57" quarskip="No-skip" virus="mhash_block.com" dtype="File Hash" file-
hash="93bdd30bd381b018b9d1b89e8e6d8753" filehashsrc="test_list"
url="http://172.16.67.148/mhash_block.com" profile="mhash_test" agent="Firefox/43.0" ana-
lyticssubmit="false"
FortiView is the FortiOS log view tool which is a 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, filter
data on multiple levels, keep track of administration activities, and more.
You can use multiple filters in the consoles to narrow your view to a specific time range, by user ID or local IP address,
by application, and many more.
Use FortiView to investigate traffic activity such as user uploads/downloads or videos watched on YouTube. You 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.
Logging range and depth depends on the FortiGate model.
The following are just some of the FortiView categories:
l Source
l Destination
l Application
l Cloud Application
l Country
l Website
l Threat
l All Sessions
l Failed Authentication Attempt
l System Events
l Admin Login
l VPN Login
l FortiSandbox
l Policy
l Interface
l WiFi Clients
l Threat Map
l Traffic Shaping
l Endpoint Vulnerability
FortiOS has widgets that you can use to further customize these categories. You can place widgets where you want on
dashboards. 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.
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.
Prerequisites
Restrictions
l Desktop models (for example: under 100D) with SSD only supports five minutes and one hour view.
l Medium models (for example: 200D, 500D) with SSD supports up to 24 hours view.
l Large models (for example: 1500D and above) with SSD supports up to seven days view.
l Confirm that the setting is enabled:
config log setting
set fortiview-weekly-data enable
end
Configuration
A firewall policy needs to be in place with traffic logging enabled. For best 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:
end
Source View
Top Level
Sample entry:
Time l Realtime or Now entries are determined by the FortiGate's system session list.
l Historical or 5 minutes and 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. Realtime does not include a
chart.
l Users can customize the time frame by selecting a time period within the graph.
Bubble Chart l Bubble chart shows the same information as the table, but in a different graphical
manner.
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 User & Device > Device Inventory.
Device detection should be enabled on the applicable interfaces for best function.
l Threat Score is the threat score of the source based on UTM features such as Web Filter
and antivirus. It shows threat scores allowed and threat scores blocked.
l Bytes is the accumulated bytes sent/received. In realtime, this is calculated from the
session list, and in historical it is from logs.
l Sessions is the total sessions blocked/allowed. In realtime, this is calculated from the
session list, and in historical it is from logs.
l Source is a simplified version of the first column, including only the IP address without
extra information.
l Source Interface is the interface from which the traffic originates. In realtime, this is
calculated from the session list, and in historical it is from the logs.
l More information can be shown in a tooltip while hovering over these entries.
l For realtime, two more columns are available, Bandwidth and Packets, both of which
come from the session list.
Drilldown Level
Sample entry:
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 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 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 More information can be shown in a tooltip while hovering over these entries.
Troubleshooting
l Use diagnose debug application httpsd -1 to check which filters were passed through httpsd.
For example:
[httpsd 3163 - 1546543360 info] api_store_parameter[227] -- add API parameter 'filter':
'{ "source": "10.1.100.30", "application": "TCP\/5228", "srcintfrole": [ "lan",
"dmz", "undefined" ] }' (type=object)
l Use diagnose debug application miglogd 0x70000 to check what the SQL command is that is
passed to the underlying SQL database.
For example:
fortiview_request_data()-898: total:31 start:1546559580 end:1546563179
_dump_sql()-799: dataset=fv.general.chart, sql:select a.timestamp1,ses_al,ses_
bk,r,s,ifnull(sc_l,0),ifnull(sc_m,0),ifnull(sc_h,0),ifnull(sc_c,0) from (select
timestamp-(timestamp%60) timestamp1 ,sum(case when passthrough<>'block' then
sessioncount else 0 end) ses_al,sum(case when passthrough='block' then sessioncount
else 0 end) ses_bk,sum(rcvdbyte) r,sum(sentbyte) s from grp_traffic_all_src where
timestamp BETWEEN 1546559580 and 1546563179 and 1=1 AND srcip in ('10.1.100.11')
AND srcintfrole in ('lan','dmz','undefined') group by timestamp1 ) a left join
(select timestamp-(timestamp%60) timestamp1 ,sum(case when threat_level=1 then
crscore else 0 end) sc_l,sum(case when threat_level=2 then crscore else 0 end) sc_
m,sum(case when threat_level=3 then crscore else 0 end) sc_h,sum(case when threat_
level=4 then crscore else 0 end) sc_c from grp_threat where timestamp BETWEEN
1546559580 and 1546563179 and 1=1 AND srcip in ('10.1.100.11') AND srcintfrole in
('lan','dmz','undefined') group by timestamp1 ) b on a.timestamp1 = b.timestamp1;
takes 40(ms), agggr:0(ms)
l Use exe report flush-cache and exe report recreate-db to clear up any irregularities that may be
caused by upgrading or cache issues.
Attaching a FortiAnalyzer to the FortiGate increases the functionality of FortiView . For example, it adds the
Compromised Hosts view.
The following devices are required:
l A FortiGate or FortiOS
l A compatible FortiAnalyzer (see https://docs.fortinet.com/document/fortianalyzer/6.2.0/compatibility-with-
fortios)
5. In the device list, right click the just added FortiGate, then click Authorize.
6. On the FortiGate, go to Security Fabric > Settings and click Test Connectivity to confirm that the device is now
authorized.
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.
4. On the top right of the Application Signature page, click Cloud to display all cloud signature based applications.
Cloud applications have a cloud icon beside them.
The lock icon indicates that that application requires SSL deep inspection.
1. In the Application Signature page, ensure the Behavior column is displayed. If necessary, add the Behavior
column.
a. Hover over the left 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 icon besides a category means that category is
monitored and logged.
4. In the FortiView dropdown list, select the LAN/DMZ tab and then select Cloud Applications.
6. If SSL deep inspection is enabled on the relative firewall, then the widget shows the additional details that are
logged, such as Files (Up/Down) and Videos Played.
For YouTube, the Videos Played column is triggered by the YouTube_Video.Play cloud application sensor. This
shows the number of local network users who logged into YouTube and played YouTube videos.
For Dropbox, the Files (Up/Down) column is triggered by Dropbox_File.Download and Dropbox_File.Upload
cloud application sensors. This shows the number of local network users who logged into Dropbox and uploaded or
downloaded files.
1. In the top right of the widget, click the Expand to full screen icon to see additional information.
2. For details about a specific entry, double-click the entry or right-click the entry and select Drill Down to Details.
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. In the top right, click the Standalone FortiView page icon to see the page in standalone view.
6. To display a specific time period, select and drag in the timeline graph to display only the data for that time period.
This is an example of monitoring network traffic for YouTube via FortiView cloud application 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.
l SSL Inspection is set to deep-inspection.
l Log Allowed Traffic is set to All Sessions.
4. Because YouTube cloud applications are categorized into Video/Audio, ensure the Video/Audio category is
monitored.
5. Click View Application Signatures and hover over YouTube cloud applications to view detailed information about
YouTube application sensors.
6. On the test PC, log into YouTube and play some videos.
7. 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.
10. Select the Sessions tab to see all the entries for the videos played. Check the sessions for YouTube_Video.Play
with the ID 38569.
This is an example of monitoring network traffic for YouTube via 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.
l SSL Inspection is set to certificate-inspection.
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.
4. Go to Dashboard > Top Usage LAN/DMZ and check the Top Cloud Application by Bytes widget.
The Top Cloud Application by Bytes widget shows the YouTube cloud application without the video played
information that requires SSL deep inspection.
5. Double-click YouTube and select the Sessions tab.
These sessions were triggered by the application sensor YouTube with the ID 31077. This is the application sensor
with cloud behavior which does not rely on SSL deep inspection.
This function requires a FortiGate that is registered and logged into a compatible FortiGate Cloud.
If the FortiGate is logged out from FortiGate Cloud, click Activate and log in, and ensure Send logs to FortiGate
Cloud is selected.
5. In the top right dropdown menu, select FortiGate Cloud as the source.
You can select FortiGate Cloud as the data source for all available FortiView pages and widgets.
The following chart identifies what log sources support which views:
Cloud Applications No No No
DNS
Introduction
DNS (Domain Name System) is used by devices connecting to the Internet to locate websites by mapping a domain
name to a website’s IP address. For example, a DNS server maps the domain name www.fortinet.com to the IP address
66.171.121.34.
A FortiGate can serve different roles based on user requirements:
l A FortiGate can control which DNS serves network uses.
l A FortiGate can function as a DNS server.
l FortiGuard Dynamic Domain Name Service (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.
FGT_A (dns) # set
*primary Primary DNS server IP address.
secondary Secondary DNS server IP address.
dns-over-tls Enable/disable/enforce DNS over TLS.
ssl-certificate Name of local certificate for SSL connections.
domain Search suffix list for hostname lookup.
ip6-primary Primary DNS server IPv6 address.
ip6-secondary Secondary DNS server IPv6 address.
timeout DNS query timeout interval in seconds (1 - 10).
retry Number of times to retry (0 - 5).
dns-cache-limit Maximum number of records in the DNS cache.
dns-cache-ttl Duration in seconds that the DNS cache retains information.
cache-notfound-responses Enable/disable response from the DNS server when a record is not
in cache.
source-ip IP address used by the DNS server as its source IP.
dns-over-tls
FortiGate version 6.2 adds DNS over TLS (DoT) support. DoT is a security protocol for encrypting and wrapping DNS
queries and answers via the Transport Layer Security (TLS) protocol.
cache-notfound-responses
When you enable DNS cache not found responses, any DNS requests that are returned with NOT FOUND can be stored
in the cache. When enabled, the DNS server is not asked to resolve the host name for NOT FOUND entries.
config system dns
set cache-notfound-responses enable
end
dns-cache-limit
This command enables you to set how many DNS entries are stored in the cache. Entries that remain in the cache
provide a quicker response to requests than going out to the Internet to get the same information.
config system dns
set dns-cache-limit 2
end
dns-cache-ttl
This command enables you to set how long entries remain in the cache.
FGT_A (dns) # set dns-cache-limit
dns-cache-limit Enter an integer value from <0> to <4294967295> (default = <5000>).
DNS troubleshooting
The FortiGate CLI can collect the following list of DNS debug information.
FGT_A (global) # 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
The example below shows useful information about the ongoing DNS connection.
Important fields include:
For a FortiGate with multiple CPUs, version 6.2 adds a new CLI command to allow the customer to set the DNS process
number from 1 to the number of CPUs. The default DNS process number is 1.
config system global
set dnsproxy-worker-count 4
end
Note: The range of dnsproxy-worker-count is 1 to the number of CPUs that the FortiGate has.
To debug DNS proxy on the worker ID, use the following command. The following example runs test commands on the
second dnsproxy worker. If you do not specify worker ID, the default worker ID is 0.
#diagnose test application dnsproxy 7 1
For debugging, you can also enable it on all workers by specifying -1 as worker ID.
#diagnose debug application dnsproxy -1 -1
End-users who commonly use incomplete URLs without a domain (for example: http://host1) rely on the proxy to locate
the domain and resolve the address. If the configured domain is company.com and the URL is http://host1, the DNS
feature will send a request for host1.company.com to a DNS server for the IP address. If you have local Microsoft
domains on the network, you can enter a domain name in the Local Domain Name field. In situations where all three
fields are configured, the FortiGate first looks to the local domain, and if no match is found, sends a request to the
external DNS servers.
Whenever a client requests a URL which does not include a fully qualified domain name (FQDN), FortiGate resolves the
URL by traversing through the DNS suffix list and doing a DNS query for each entry until the first match.
Sample configuration
1. By default, FortiGate is configured to use FortiGuard's DNS servers which are primary (208.91.112.53) and
secondary (208.91.112.52).
2. To configure the DNS server addresses, go to Network > DNS and select Specify, then enter the preferred DNS
server addresses.
For example: 172.16.200.1 as the primary DNS server and 172.16.200.2 as the secondary.
3. FortiGate supports a total of eight local domain lists.
Additional DNS configuration options are available in the CLI using the config system dns command.
New CLI commands added in 6.2 allow users to set up to eight domains. Retry Time and Timeout values can be
configured to define how many attempts the FortiGate makes to search a particular domain and when FortiGate gives
up on the domain.
FGT_B (dns) # set domain
*domain DNS search domain list separated by space (maximum 8 domains)
In the example below, the local domain resolves host1 to 1.1.1.1 and host2 to 2.2.2.2. The local DNS server has
an entry for host1 mapped to the FQDN of host1.sample.com and a second entry for host2 mapped to the FQDN of
host2.example.com.
ping host1
PING host1.sample.com (1.1.1.1): 56 data bytes
ping host2
PING host2.example.com (2.2.2.2): 56 data bytes
This section describes how to set up a FortiGate to use a DNS server for resolving internal and external requests.
Run dig to query the FortiGate DNS server. Dig (Domain Information Grouper) is a Unix-like network administration
command line tool for querying DNS servers.
root@PC05:~# dig @172.16.200.1 example.fortinet.com
;; QUESTION SECTION:
;example.fortinet.com. IN A
;; ANSWER SECTION:
example.fortinet.com. 86400 IN A 2.3.3.4
This section describes how to set up a FortiGate to use an internal DNS server for resolving internal requests and a
public DNS server for resolving external requests.
Technical information
The Type of the DNS Database Zone can be one of the following:
The View of the DNS Database Zone can be one of the following:
l An Authoritative zone claims to hold all existing entries concerning this zone. A DNS server holding an authoritative
zone serves requests to this zone only from its local zone file, that is, it does not perform additional recursive
requests such as matching this zone to other defined DNS servers for zone records which do not exist in this zone
file.
l An Unauthoritative zone serves the records it holds itself from the local zone file and performs recursive request to
other defined DNS servers for requests that match the zone but are not listed in the local zone file.
l Recursive DNS servers performs DNS lookups to other defined DNS servers for any zone requests they cannot
fulfill from local files.
l Non-recursive DNS servers only serve from local zone files.
l Forward to system DNS forwards the query to the FortiGate's configured system DNS.
FortiGuard DDNS
If your ISP changes your external IP address 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
Sample configuration
If you don't have a FortiGuard subscription or want to use a different DDNS server, you can configure DDNS in the CLI.
You can configure a DDNS for each interface. Only the first configured port appears in the FortiGate GUI. Additional
commands vary depending on the DDNS server you select. Use the following CLI commands:
config system ddns
edit <DDNS_ID>
set monitor-interface <external_interface>
set ddns-server <ddns_server_selection>
next
end
You can configure FortiGate to refresh DDNS IP addresses. FortiGate periodically checks the DDNS server that is
configured.
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 DDS update of the AA field every time even if the DHCP client
does not request it. This allows supporting the allow/ignore/deny client-updates options.
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.
You can customize the DNS timeout and retry settings in the CLI.
5. Click Apply.
The following example shows the CLI commands for setting the primary DNS server IP address to 172.16.200.1 and
configuring multiple domains: sample.com, example.com, and domainname.com:
config system dns
set primary 172.16.200.1
set domain "sample.com" "example.com" "domainname.com"
end
You might want to customize the DNS timeout and retry settings. For example, if you have eight domains configured,
you may want to decrease the DNS timeout value to avoid delays. The following table defines the timeout and retry
settings:
timeout DNS query timeout interval in seconds. Enter an integer value between 1 and 10.
The default value is 5 seconds.
retry Number of times to retry the DNS query. Enter an integer value between 0 and 5.
The default value is 2 tries.
To configure the DNS timeout and retry settings using the CLI:
The following example changes the timeout to 7 seconds and number of retries to 3:
config system dns
set timeout 7
set retry 3
end
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:
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 3 objects:
l SD-WAN interface
Also called members, SD-WAN interfaces 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
Creating the SD-WAN interface on page 261.
l Performance-SLA
Also called health-check, 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
Performace SLA - link monitoring on page 270.
l SD-WAN rule
Also called service, 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 sla: Assign interfaces a priority based on selected SLA settings.
l load-balance: Distribute traffic among all available links based on the load balance algorithm.
See SD-WAN rules - best quality on page 273, SD-WAN rules - lowest cost (SLA) on page 275, and SD-WAN rules -
maximize bandwidth (SLA) on page 278.
This recipe provides an example of how to start using SD-WAN for load balancing and redundancy.
In this example, two ISP internet connections (wan1 and wan2) use SD-WAN to balance traffic between them at 50%
each.
1. On the FortiGate, enable SD-WAN and add interfaces wan1 and wan2 as members:
a. Go to Network > SD-WAN.
b. Set the Status to Enable.
c. Click the plus icon to add members, using the ISPs' proper gateways for each member.
If IPv6 visibility is enabled in the GUI, an IPv6 gateway can also be added for each member. See Feature
visibility on page 24 for details.
d. Click Apply to save your settings.
This recipe provides a sample configuration for customer using the DHCP interface as SD-WAN members. SD-WAN
members can be all static IP interfaces, all DHCP interfaces, or a mix of both IP and DHCP interfaces.
In this example, a customer who has two ISP internet connections: wan1 and wan2. wan1 is a DHCP interface and
wan2 is a static IP address interface.
Sample topology
Implicit rule
Examples
The following four examples demonstrate how to use the implicit rules (load-balance mode).
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 Creating the SD-WAN interface on page 261 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 Creating
the SD-WAN interface on page 261 for details.
2. Set the load balancing algorithm:
Source IP based:
config system virtual-wan-link
set load-balance-mode source-ip-based
end
Source-Destination IP based:
config system virtual-wan-link
set load-balance-mode source-dest-ip-based
end
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.
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 Creating the SD-WAN interface on page 261 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.
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, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route. See Creating the SD-WAN interface on page 261 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, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route. See Creating the SD-WAN interface on page 261 for details.
2. Go to Network > Performance SLA.
3. Create a new Performance SLA or edit an existing one. See Performace SLA - link monitoring on page 270.
4. Under SLA Targets, click the plus icon to add a target.
5. Turn on or off the required constraints, and set their values.
next
end
next
end
end
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 SD-WAN rules -
lowest cost (SLA) on page 275.
l Maximize Bandwith (SLA) (load-balance): Traffic is distributed among all available links based on the selected
load balancing algorithm. See SD-WAN rules - maximize bandwidth (SLA) on page 278.
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:
custom-profile-1 custom-profile-1 Select link based on customized profile. If selected, set the following
weights:
l packet-loss-weight: Coefficient of packet-loss.
l latency-weight: Coefficient of latency.
l jitter-weight: Coefficient of jitter.
l bandwidth-weight: Coefficient of reciprocal of available
bidirectional bandwidth.
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, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route. See Creating the SD-WAN interface on page 261 for details.
2. Create a new Performance SLA named google. See Performace SLA - link monitoring on page 270.
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
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 SD-
WAN rules - best quality on page 273.
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 SD-WAN rules - maximize bandwidth (SLA) on page 278.
When using Lowest Cost (SLA) mode (sla in the CLI), SD-WAN will choose the lowest cost link that satisfies SLA to
forward traffic.
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, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route. See Creating the SD-WAN interface on page 261 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 Performace SLA - link monitoring on page 270.
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
config health-check
edit "google"
set server "google.com"
set members 1 2
config sla
edit 1
set latency-threshold 10
set jitter-threshold 5
next
end
next
end
config service
edit 1
set name "gmail"
set mode sla
set internet-service enable
set internet-service-id 65646
config sla
edit "google"
set id 1
next
end
set priority-members 1 2
next
end
end
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 SD-
WAN rules - best quality on page 273.
l Lowest Cost (SLA) (sla): Interfaces are assigned a priority based on selected SLA settings. See SD-WAN rules -
lowest cost (SLA) on page 275.
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 all of the links that satisfies SLA to
forward traffic based on a round-robin load balancing algorithm.
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, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route. See Creating the SD-WAN interface on page 261 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 Performace SLA - link monitoring on page 270.
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
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.
This topic covers a typical customer usage scenario where the customer's SD-WAN has two members: MPLS and DIA.
DIA is mostly used for direct Internet access to Internet applications, for example, Office365, Google applications,
Amazon, Dropbox, etc. MPLS is mostly used for SIP and works as a backup when DIA is not working.
Sample topology
Sample configuration
This sample configures all SIP traffic to use MPLS while all other traffic uses DIA. If DIA is not working, the traffic will
use MPLS.
To configure an SD-WAN rule to use SIP and DIA using the GUI:
1. On the FortiGate, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route.
See Creating the SD-WAN interface on page 261.
2. When you add a firewall policy, enable Application Control.
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 box to display the popup dialog box; then select the applicable SIP applications.
7. For Strategy, 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 box to display the popup dialog box and select all.
13. For Strategy, select Manual.
14. For Interface preference, select DIA.
15. Click OK.
To configure an SD-WAN rule to use SIP and DIA using the CLI:
edit 1
set interface "MPLS"
set gateway x.x.x.x
next
edit 2
set interface "DIA"
set gateway x.x.x.x
next
end
config service
edit 1
set name "SIP"
set member 1
set internet-service enable
set internet-service-app-ctrl 34640 152305677 38938 26180 26179 30251
next
edit 2
set name "Internet"
set input-device "dmz"
set member 2
set dst "all"
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.
To use the diagnose command to check performance SLA status using the CLI:
FGT_A (root) #
FGT_A (root) #
Use 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 the online help on shared policy traffic shaping and interface-based traffic shaping.
Sample topology
Sample configuration
This example shows a typical customer usage where the customer's SD-WAN has two member: wan1 and wan2 and
each is 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, enable SD-WAN and add wan1 and wan2 as SD-WAN members, then add a policy and static
route.
To configure SD-WAN traffic shaping and QoS with SD-WAN in the CLI:
To use the diagnose command to check if specific traffic is attached to the correct traffic shaper:
FGT_A (root) #
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
Advanced configuration
Self-originating traffic
By default, the policy route generated by SD-WAN rules applies on both forwarded and self-generated traffic. This
means that some dynamic routing protocols that are managing traffic, such as OSPF and BGP, can have SD-WAN rules
applied. It can also affect locally-originating traffic, such as syslog. This can cause traffic that is destined for a locally
connected subnet to egress from an undesired interface.
There are four methods that can be used to avoid SD-WAN rules affecting policy routes for local-out traffic:
1. Do not set the Source address to all in SD-WAN rules.
3. Create a policy route with Destination address set to a locally connected subnet, and Action set to Stop Policy
Routing to jump directly to forwarding information base (FIB) lookup and avoid the SD-WAN rules.
The Advanced Routing feature visibility must be enabled for the Policy Routes page to be visible; see Feature
visibility on page 24 for information.
4. Enable negating the destination address match (dst-negate) to filter out specific destinations:
config system virtual-wan-link
config service
edit 1
set dst "bgp-neighbor-address"
set dst-negate enable
...
next
...
end
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
Tenant ID 942b80cd-1b14-42a1-8dcf-4b21dece61ba
Client ID 14dbd5c5-307e-4ea4-8133-68738141feb1
5. Click OK.
Category Address
Name azure-address
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
...
...
This topic shows an example of how to aggregate IPSec tunnels. This example shows how to make per-packet load-
balancing among IPSec tunnels.
For example, a customer has two ISP connections, wan1 and wan2. Using these two connections, we create two VPN
interfaces and configure traffic for per-packet load-balancing among IPSec tunnels.
Sample topology
Sample configuration
On the FortiGate, first create two IPsec VPN interfaces. Then create an ipsec-aggregate interface and add this
interface as an SD-WAN member.
FortiGate 1 configuration
next
end
FortiGate 2 configuration
end
config system interface
edit "agg2"
set vdom "root"
set ip 172.16.11.2 255.255.255.255
set allowaccess ping
set remote-ip 172.16.11.1 255.255.255.255
next
end
This topic shows an SD-WAN with forward error correction (FEC) on VPN overlay networks. FEC can be used to lower
packet loss ratio by consuming more bandwidth. 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 example, a customer has tow 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.
Sample topology
To configure SD-WAN:
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 enable on the FortiGate, wan1 and wan2 are added as SD-WAN members, and
a policy and static route have been created. See Creating the SD-WAN interface on page 261 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 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:
Traffic is allowed or blocked according to the 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"
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"
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
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
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"
set dstintf "port3"
set traffic-shaper "50MB/s"
set traffic-shaper-reverse "50MB/s"
set diffserv-forward enable
set diffserv-reverse enable
set srcaddr "QA"
set dstaddr "all"
In a shaping policy, there are many matching criteria available for administrators to match a specific traffic and apply a
traffic shaper or shaping group to the traffic, including using schedules. This feature gives shaping policy the ability to
apply different shaping profiles at different times. Administrators can select a one-time schedule, recurring schedule, or
schedule group.
Schedule is not a mandatory setting. If it is not set, then the current date and time are not used to match the traffic.
next
end
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.
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
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
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"
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:
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.
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.
3. In the Interface drop-down, click +VPN. The Create IPsec VPN for SD-WAN members pane opens.
Internet Service Database (ISDB) entries can be tunes for their environments by adding custom ports and port ranges
with the config firewall internet-servce-addition CLI command.
Troubleshooting SD-WAN
You can check the destination interface in FortiView 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.
l If the source IP address is an even number, it will go to port13.
l If the source IP address is an odd number, it will go to port12.
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"
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:
6: date=2019-03-23 time=17:32:01 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553387520 logdesc="Virtual WAN Link status"
msg="Service2() prioritized by packet-loss will be redirected in seq-num order 2(R160) 1
(R150)."
7: date=2019-03-23 time=17:32:01 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553387520 logdesc="Virtual WAN Link status"
interface="R150" msg="The member1(R150) link quality packet-loss order changed from 1 to 2.
"
8: date=2019-03-23 time=17:32:01 logid="0100022923" type="event" subtype="system"
level="notice" vd="root" eventtime=1553387520 logdesc="Virtual WAN Link status"
interface="R160" msg="The member2(R160) link quality packet-loss order changed from 2 to 1.
"
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:
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"
interface="R150" msg="The member1(R150) link quality packet-loss order changed from 2 to 1.
"
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.
Egress-overbps=1, ingress-overbps=1
Member(2): interface: port15, gateway: 10.100.1.5 2004:10:100:1::5, priority: 0,
weight: 254
Egress-spillover-threshold: 0kbit/s, ingress-spillover-threshold: 0kbit/s
Egress-overbps=0, ingress-overbps=0
l You can also use the diagnose netlink dstmac list command to check if you are over the limit.
FGT # diag 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:
SLA logging
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-
l="information" vd="root" eventtime=1551383604 logdesc="Link monitor SLA information" name-
e="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-
l="information" vd="root" eventtime=1551383545 logdesc="Link monitor SLA information" name-
e="ping" interface="R160" status="up" msg="Latency: 0.013, jitter: 0.002, packet loss: 0.000%,
inbandwidth: 0Mbps, outbandwidth: 0Mbps, bibandwidth: 0Mbps, sla_map: 0x1"
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-
l="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-
l="notice" vd="root" eventtime=1551383522 logdesc="Link monitor SLA information" name="ping"
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":"port13",
"logs":[
{
"timestamp":1547087204,
"link":"up",
"latency":0.686433,
"jitter":0.063400,
"packetloss":0.000000
},
{
"timestamp":1547087205,
"link":"up",
"latency":0.688433,
"jitter":0.063133,
"packetloss":0.000000
},
{
"timestamp":1547087206,
"link":"up",
"latency":0.688300,
"jitter":0.065267,
"packetloss":0.000000
},
....
....
Timestamp: Wed Jan 9 18:33:49 2019, used inbandwidth: 3208bps, used outbandwidth: 3453bps,
used bibandwidth: 6661bps, tx bytes: 947234bytes, rx bytes: 898622bytes.
Timestamp: Wed Jan 9 18:33:59 2019, used inbandwidth: 3317bps, used outbandwidth: 3450bps,
used bibandwidth: 6767bps, tx bytes: 951284bytes, rx bytes: 902937bytes.
Timestamp: Wed Jan 9 18:34:09 2019, used inbandwidth: 3302bps, used outbandwidth: 3389bps,
used bibandwidth: 6691bps, tx bytes: 956268bytes, rx bytes: 907114bytes.
Timestamp: Wed Jan 9 18:34:19 2019, used inbandwidth: 3279bps, used outbandwidth: 3352bps,
used bibandwidth: 6631bps, tx bytes: 958920bytes, rx bytes: 910793bytes.
Timestamp: Wed Jan 9 18:34:29 2019, used inbandwidth: 3233bps, used outbandwidth: 3371bps,
used bibandwidth: 6604bps, tx bytes: 964374bytes, rx bytes: 914854bytes.
Timestamp: Wed Jan 9 18:34:39 2019, used inbandwidth: 3235bps, used outbandwidth: 3362bps,
used bibandwidth: 6597bps, tx bytes: 968250bytes, rx bytes: 918846bytes.
Timestamp: Wed Jan 9 18:34:49 2019, used inbandwidth: 3165bps, used outbandwidth: 3362bps,
used bibandwidth: 6527bps, tx bytes: 972298bytes, rx bytes: 922724bytes.
Timestamp: Wed Jan 9 18:34:59 2019, used inbandwidth: 3184bps, used outbandwidth: 3362bps,
used bibandwidth: 6546bps, tx bytes: 977282bytes, rx bytes: 927019bytes.
The bandwidth measuring tool detects true upload and download speeds. Bandwidth tests can be run on demand or on
schedule, and can be used with the SD-WAN SLA and rules to balance SD-WAN traffic.
This feature requires a license that is part of 360 Protection Bundle in 6.2, or an SD-WAN Bandwidth Monitoring Service
license.
The speed test tool compatible with iperf3.6 with SSL support. The tool can send traffic to test uploading bandwidth to
the FortiGate Cloud speed test service. It can initiate the connection with the server and initiate downloading requests
to the server.
The tool's daily running quota is limited to avoid abusing the usage for valid customers. The current daily quota is 10.
FortiGate first downloads the speed test server list. The server list expires after 24 hours. Based on customer's input, it
selects one of the servers to do the speed test. The speed test includes uploading speed test and downloading speed
test. After the test is done, the results are printed on the 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.
FG3H0E5818904285 (root) # 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
To run the speed test on a local interface when there are multiple valid routes:
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 335 for more information.
Administrator profiles
An administrator profile defines what the administrator can see and do on the FortiGate. See Administrator profiles on
page 335 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 341 for more information.
Password policy
Set up a password policy to enforce password criteria and change frequency. See Password policy on page 340 for more
information.
SNMP
The simple network management protocol (SNMP) allows you to monitor hardware on your network. See SNMP on
page 387 for more information.
DHCP server
You can configure one or more DHCP servers on any FortiGate interface. See DHCP server on page 391 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 365 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 between two networks, such as a private network and the internet.
This allows the FortiGate to hide the IP addresses on the private network using NAT. NAT/Route mode can also be
used when several ISPs are used for redundant internet connections.
By default, new VDOMs are set to NAT/Route operation mode.
See Configure VDOM-A on page 373 for more information.
Transparent mode
The FortiGate or VDOM is installed between the internal network and the router. The FortiGate does not changes any
IP addresses, and only applies security scanning to traffic. When you add a FortiGate that is in transparent mode to a
network, it only needs to be provided with a management IP address.
Transparent mode is primarily used when increased network protection is needed without changing the network
configuration.
See Configure VDOM-A on page 383 for more information.
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.
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.
Edit profiles
Delete profiles
By default, FortiGate has one super admin named admin. You can create more administrator accounts with difference
privileges.
Don't use the characters < > ( ) # " ' in the administrator username.
Using these characters in an administrator username might have a cross site scripting
(XSS) vulnerability.
end
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 338
2. Add the LDAP server to a user group on page 338
3. Configure the administrator account on page 339
1. Go to User & Device > 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 include the LDAP server you configured.
1. Go to User & Device > User Groups and select Create New.
2. Enter a Name for the group.
3. In the Remote groups section, select Create New.
4. Select the Remote Server from the dropdown list.
5. Click OK.
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.
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 sub-networks that can scale as your organization
grows. You can create and edit VLAN, EMAC-VLAN, switch interface, zones, and so on.
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.
Link Status Indicates whether the interface is connected to a network or not (link status is up or down). This
field appears when you edit an existing physical interface.
Interface This section can have two different formats depending on the interface type:
Members Software Switch: This section is a display-only field showing the interfaces that belong to the
virtual interface of the software switch.
802.3ad Aggregate or Redundant Interface: This section includes the available interface list
and the selected interface list.
IP/Netmask If Addressing Mode is set to Manual, enter an IPv4 address and subnet mask for the interface.
FortiGate interfaces cannot have IP addresses on the same subnet.
IPv6 Address 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.
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.
HTTPS Allow secure HTTPS connections to the FortiGate GUI through this interface. If configured, this
option is enabled automatically.
PING The interface responds to pings. Use this setting to verify your installation and for testing.
HTTP Allow HTTP connections to the FortiGate GUI through this interface. If configured, this option
also enables the HTTPS option.
SNMP Allow a remote SNMP manager to request SNMP information by connecting to this interface.
FMG-Access Allow FortiManager authorization automatically during the communication exchanges between
FortiManager and FortiGate devices.
CAPWAP Allow the FortiGate wireless controller to manage a wireless access point such as a FortiAP
device.
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).
Some models support the IEEE standard 802.3ad for link aggregation.
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.
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.
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
set dstintf VLAN_200
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.
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 slaves 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.
Inter-VDOM routing
In the past, virtual domains (VDOMs) were separate from each other and there was no internal communication. Any
communication between VDOMs involved traffic leaving on a physical interface belonging to one VDOM and re-entering
the FortiGate unit on another physical interface belonging to another VDOM to be inspected by firewall policies in both
directions.
Inter-VDOM routing changes this. With VDOM links, VDOMs can 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 very much like
creating a VLAN interface. VDOM-links are managed through the web-based manager or CLI. In the web-based
manager, VDOM link interfaces are managed in the network interface list.
VDOM link does not support traffic offload. If you want to use traffic offload, use NPU-VDOM-
LINK.
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.
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 distance 5
set gwdetect enable
set dns-server-override enable
set allowaccess https ssh snmp
set description “The systemwide management interface.”
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“
end
end
config global
config system vdom-link
edit SalesVlnk
end
config system interface
edit SalesVlnk0
set vdom Accounting
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"
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 AccountVlnk
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ALL
set nat enable
end
end
config vdom
edit root
config firewall policy
edit 2
set name "Accounting-VDOM-to-Internet"
set srcintf AccountVlnk
set dstintf port1
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ALL
set nat enable
end
end
config vdom
edit root
config firewall policy
edit 6
set name "Sales-local-to-Management"
set srcintf port2
set srcaddr all
set dstintf SalesVlnk
set dstaddr all
set schedule always
set service ALL
set action accept
set logtraffic enable
end
end
config vdom
edit Sales
config firewall policy
edit 7
set name "Sales-VDOM-to-Internet"
set srcintf SalesVlnk
set srcaddr SalesManagement
set dstintf external
set dstaddr all
set schedule always
set service OfficeServices
set action accept
set logtraffic enable
end
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 command to confirm the connectivity of
different routes on the network.
Test both from AccountingLocal to Internet and from SalesLocal to Internet.
Software switch
A software switch, or soft 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. A soft switch 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 you have a back up of the configuration.
l Ensure 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.
For this example, the wireless interface (WiFi) needs to be on the same subnet as the DMZ1 interface to facilitate
wireless syncing from an iPhone and a local computer. Because synching between two subnets is problematic, putting
both interfaces on the same subnet the synching 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 DHCP is not enabled on the interface and that there are no other
dependencies on these interfaces.
c. Save the current configuration so that if something doesn’t work, recovery can be quick.
2. Merge the interfaces.
Merge the WiFi port and DMZ1 port to create a software switch named synchro with an IP address of
10.10.21.12.
Use the following CLI commands to create the switch, add the IP, and then set the administrative access for
HTTPS, SSH and Ping.
config system switch-interface
edit synchro
set type switch
set member dmz1 wifi
end
config system interface
edit synchro
set ip 10.10.21.12
set allowaccess https ssh ping
end
When the soft switch is set up, you now add security policies, DHCP servers, and any other configuration you
normally do to configure interfaces on the FortiGate unit.
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.
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.
Sample topology
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.
Virtual switch
A virtual switch provides a container for physical ports to be loaned to other VDOMs, allowing local management of the
resource.
The following example shows how to export managed FortiSwitch ports to multi-tenant VDOMs. In this example, the
owner VDOM is root, and the tenant VDOM is vdom2.
next
end
2. In the tenant VDOM, designate the default-virtual-switch-vlan, which is used to set the native VLAN of
ports leased from the owner VDOM:
(vdom2) # config switch-controller global
set default-virtual-switch-vlan "tenant-vlan1"
end
Alternatively, export managed FortiSwitch ports to shared virtual-switch pools for the tenant VDOM to choose from,
for example:
(root) # config switch-controller virtual-port-pool
edit "pool1"
next
end
(root) # config switch-controller managed-switch
edit S248EPTF18001384
config ports
edit port8
set export-to-pool pool1
next
edit port9
set export-to-pool pool1
next
end
next
end
4. In vdom2, configure the ports of the leased managed FortiSwitch, or lease or release ports from the virtual switch
pool. Then, in each tenant VDOM, the administrator can configure and leverage the FortiSwitch ports locally, with a
limited range of operations based on the available CLI commands:
login: vdom2
Password: *****
Welcome !
$ show switch-controller managed-switch
config switch-controller managed-switch
edit "S248EPTF1800XXXX"
set type virtual
set owner-vdom "root"
config ports
edit "port1"
set poe-capable 1
set vlan "tenant-vlan1"
next
edit "port6"
set poe-capable 1
set vlan "tenant-vlan1"
next
end
next
end
config switch-controller managed-switch
edit S248EPTF1800XXXX
config ports
edit port1
set ?
port-ownerSwitch port name.
speed Switch port speed; default and available settings depend on
hardware.
status Switch port admin status: up or down.
poe-status Enable/disable PoE status.
poe-pre-standard-detection Enable/disable PoE pre-standard
detection.
poe-capable PoE capable.
vlan Assign switch ports to a VLAN.
allowed-vlans Configure switch port tagged vlans
untagged-vlans Configure switch port untagged vlans
type Interface type: physical or trunk port.
qos-policySwitch controller QoS policy from available options.
storm-control-policy Switch controller storm control policy from
available options.
port-security-policy Switch controller authentication policy to
apply to this managed switch from available options.
learning-limit Limit the number of dynamic MAC addresses on this
Port (1 - 128, 0 = no limit, default).
next
edit trunk1
set type trunk
next
end
next
end
execute switch-controller virtual-port-pool request S248EPTF1800XXXX port8
execute switch-controller virtual-port-pool show
Switch Port Properties Tags
----------------------------------------------------------------
pool1(vdom.root)
S248EPTF1800XXXX port8 (vdom2) POE,10M/100M/1G/
S248EPTF1800XXXX port9 POE,10M/100M/1G/
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 366.
l Multi VDOM mode: Multiple VDOMs can be created and managed as independent units. See Multi VDOM mode
on page 370.
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.
Multi VDOM Split-task VDOM Not Allowed. User must first switch to No
VDOM
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 Advanced system settings
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 Fabric Connectors
(SSO/Identity connectors only)
l FortiView
l Interface configuration
l Packet capture
l SD-WAN, SD-WAN Rules, and Performance SLA
l Static and policy routes
l RIP, OSPF, BGP, and Multicast
l Replacement messages
l Advanced system settings
l Feature visibility
l Tags
l Certificates
l Policies and objects
l Security profiles
l VPNs
l User and device authentication
l Wifi and switch controller
l Logging
l Monitoring
Split-task VDOM mode is not available on all FortiGate models. The Fortinet Security Fabric supports split-task VDOM
mode.
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 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.
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 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 373
2. Configure VDOM-B on page 375
3. Configure the VDOM link on page 378
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 > IPv4 Policy and create a new policy.
3. Enter the following information:
Name VDOM-A-Internet
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
Schedule always
Service FTP
Action ACCEPT
NAT enabled
config vdom
edit VDOM-B
config firewall policy
edit 0
set name Access-server
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
1. Connect to VDOM-A.
2. Go to Policy & Objects > Addresses and create a new address.
3. Enter the following information:
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 > IPv4 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 > IPv4 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 383
2. Configure VDOM-B on page 385
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 > IPv4 Policy and create a new policy.
3. Enter the following information:
Name VDOM-A-Internet
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
1. Connect to VDOM-B.
2. Go to Policy & Objects > IPv4 Policy and create a new policy.
3. Enter the following information:
Name Access-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
Advanced configurations
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.
SNMP v1/v2c
SNMPWALK is a Simple Network Management Protocol (SNMP) application present on the Security Management
System (SMS) CLI that uses SNMP GETNEXT requests to query a network device for information. An object identifier
(OID) may be given on the command line. This OID specifies which portion of the object identifier space will be
searched using GETNEXT requests. All variables in the subtree below the given OID are queried and their values
presented to the user.
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.4 = INTEGER: 4
IF-MIB::ifIndex.5 = INTEGER: 5
IF-MIB::ifIndex.6 = INTEGER: 6
IF-MIB::ifIndex.7 = INTEGER: 7
IF-MIB::ifIndex.8 = INTEGER: 8
IF-MIB::ifIndex.9 = INTEGER: 9
IF-MIB::ifIndex.10 = INTEGER: 10
IF-MIB::ifIndex.11 = INTEGER: 11
IF-MIB::ifIndex.12 = INTEGER: 12
IF-MIB::ifIndex.13 = INTEGER: 13
IF-MIB::ifIndex.14 = INTEGER: 14
IF-MIB::ifIndex.15 = INTEGER: 15
---------------truncated-----------------------
SNMP v3
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.
=====================Truncated=========================
Important SNMP traps
This trap is sent when a FortiGate port goes down or is brought up. For example, the below 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
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 below trap.
DISMAN-EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (7975058) 22:09:10.58 SNMPv2-MIB::s-
nmpTrapOID.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 example above 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 FortiAP/FortiSwitch is connected to the FortiGate. For example, the below
scenario has given the device a new trap for adding FortiAP on a POE interface of FGT140D-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::s-
nmpTrapOID.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 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, com-
munity 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
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.
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
DHCP option 82, also known as the DHCP relay agent information option, helps protect FortiGate against attacks such
as spoofing (forging) of IP addresses and MAC addresses, and DHCP IP address starvation.
FG3H1E5818900749 (1) # show
config reserved-address
edit 1
set type option82
set ip 100.100.100.12
set circuit-id-type hex
Option-42
The replacement message list in System > Replacement Messages enables you to view and customize replacement
messages. Highlight the replacement messages you want to edit and customize the message content to your
requirements. Hit Save when done. If you do not see the message you want to edit, select the Extended View option in
the upper right-hand corner of the screen.
If you make a mistake, select Restore Default to return to the original message and code base.
Supported image formats are GIF, JPEG, TIFF, and PNG. The maximum file size
supported is 24KB.
Replacement messages can be modified to include an HTML message or content that suits your organization. A list of
common replacement messages appear in the main window. Select Extended View to see the entire list and all
categories for replacement messages.
Replacement message groups enable you to view common messages in groups for large carriers. Message groups can
be configured by going to Config > Replacement Message Group.
Using the defined groups, you can manage specific replacement messages from a single location, rather than searching
through the entire replacement message list.
If you enable virtual domains (VDOMs) on the FortiGate unit, replacement message groups are configured separately
for each virtual domain. Each VDOM has its own default replacement message group, configured from System
> Replacement Message Group.
When you modify a message in a replacement message group, a reset icon appears beside the message in the group.
Select the reset icon to reset the message in the replacement message group to the default version.
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
Cluster setup
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.
Fail 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. Fail 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 two 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 (master) unit loses power, a backup (slave) unit automatically becomes the master, 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
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 and the CLI is accessible, and that all
boxes 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
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 boxes you have are from the same generation,
please contact customer service.
One box keeps shutting down during HA setup (hard drive failure):
If one box 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 box to resolve the issue.
When all members join together as a cluster, a process called a negotiation begins in order to decide which box will
become the Master. It is decided by the following criteria:
The first factor is the amount of connected good interfaces. If Box A has two monitored interfaces up and Box B has only
one, then Box A will become the Master. Ensure all monitored connections to members are good.
All members are Masters and members can't 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.
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.
l In the CLI, run the command get sys ha status 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:
FGT_A # get sys ha status
HA Health Status: OK Model: FortiGate-300D Mode: HA A-P Group: 146 Debug: 0 Cluster Uptime:
0 days 21:42:53 Cluster state change time: 2019-03-09 11:40:51 Master selected using:
Policies
Policy introduction
Firewall policies
The firewall policy is the axis around which most features of the FortiGate firewall revolve. Many settings in the firewall
end up relating to or being associated with the firewall policies and the traffic that they govern. Any traffic going through
a FortiGate unit 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’s processed, if it’s processed, and even whether or not it’s allowed to pass through the FortiGate.
When the firewall receives a connection packet, it analyzes the packet’s 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 it finds
a policy that matches the parameters, it then looks at the 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 action 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 action 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.
In addition to the Accept or Deny actions, there can be a number of instructions associated with a FortiGate firewall,
some of which are optional. Instructions on how to process the traffic can include such things as:
l Logging traffic.
l Authentication.
l Network Address Translation or Port Address Translation.
l Use Virtual IPs or IP Pools.
l Caching.
l Whether the source of the traffic is based on address, user, device, or a combination.
l Whether to treat as regular traffic or IPsec traffic.
l What certificates to use.
l Security profiles to apply.
l Proxy Options.
l Traffic Shaping.
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.
From version 5.6, we added a new policy mode called Next Generation Firewall (NGFW). This mode is only available
when the VDOM inspection-mode is flow. This model is divided into two working modes — profile-based and policy-
based. Profile-based NGFW is the traditional mode where a user needs to create an AV/web/IPS profile which is applied
to the policy.
Policy-based mode is new. In this mode, users can add applications and web filtering categories directly to a policy
without having to first create and configure Application Control or Web Filter profiles. If a URL category is set, the
applications that are added to the policy must be within the browser-based technology category. NGFW is per VDOM
setting. This means users can operate their FortiGate or individual VDOMs on their FortiGate in NGFW policy-based
mode when they select flow-based inspection.
Switching NGFW mode from profile-based to policy-based converts your profile-based security policies to policy-based
security policies. If you don’t want this to happen or you just want to experiment with policy-based NGFW mode,
consider creating a new VDOM for policy-based NGFW mode. You can also backup your configuration before switching
modes.
NGFW policy-based firewall policies might have unintended consequences to the passing or blocking of traffic. For
example, if you add new firewall policies that are designed to DENY social media traffic based on applications or URLs,
having a traditional “catch all” firewall policy to DENY all other traffic at the bottom of the firewall policy list may have the
unintended consequence of blocking legitimate traffic. Also note that NGFW policy-based mode applies the NAT
settings from matching Central SNAT policies. If you don’t already have a Central SNAT policy in place, you must create
one.
After version 6.2, we removed the inspection-mode from VDOM to firewall policy, and the default inspection-mode is
flow so we can change NGFW mode from profile-based (default) to policy-based directly in the VDOM's System >
Settings.
You can operate your FortiGate or individual VDOMs in Next Generation Firewall (NGFW) policy mode.
1. Go to System > Settings.
2. In NGFW Mode, select Policy-based.
3. In SSL/SSH Inspection, select the SSL/SSH inspection mode to be applied to all policies.
If your FortiGate is operating 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. For example, if you allow users on the internal network (connected to
LAN) to browse the Internet (connected to wan1), you can add a LAN to wan1 Central SNAT policy similar to the
following.
Configure Application Control by adding individual applications to security policies. You can set the action to ACCEPT
or DENY to allow or block applications.
In the above example, if you browse to www.facebook.com, your connection will time out.
You can combine both Application Control and Web Filter in the same NGFW policy mode policy. If the policy accepts
applications or URL categories, you can apply Antivirus, DNS Filter, and IPS profiles in NGFW mode policies as well as
logging and policy learning mode.
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
matches specific traffic from a number of policies. After completing the lookup, the matching firewall policy is
highlighted on the policy list page.
The Policy Lookup tool has the following requirements:
l Transparent mode does not support Policy lookup function.
l When executing the policy lookup, you need to confirm whether the relevant route required for the policy work
already exists.
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.
Static SNAT
NAT or Network Address Translation 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 recipe focuses on some of the differences between them.
Overload
This type of IP pool is similar to static SNAT mode. We just need to define an external IP range, This range can contain
one or multiple IP addresses, When there is only one IP address, it almost as same as static SNAT – use Outgoing
Interface address. 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. See example
below.
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.
Following is a simple example:
External IP Range: 172.16.200.1—172.16.200.1
Block Size: 128
Block Per User: 8
Result:
Total-PBAs: 472 (60416/128)
Maximum ports can be used per User (Internal IP Address): 1024 (128*8)
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.
Sample configuration
When central NAT is enabled, Policy & Objects displays the Central SNAT section.
Usually we use VIP to implement Destination Address Translation. Mapping a specific IP address to another specific IP
address is usually referred to as Destination NAT. When the Central NAT Table is not used, FortiOS calls this a Virtual
IP Address (VIP). FortiOS uses a DNAT or Virtual IP address to map an external IP address to an IP address. This
address does not have to be an individual host, it can also be an address range. This mapping can include all TCP/UDP
ports or, if Port Forwarding is enabled, it only refers to the configured ports. Because, the Central NAT table is disabled
by default, the term Virtual IP address or VIP is predominantly used.
Virtual IP addresses are typically used to NAT external or public IP addresses to internal or private IP addresses. Using a
Virtual IP address between two internal interfaces made up of private IP addresses is possible but there is rarely a
reason to do so as the two networks can just use the IP addresses of the networks without the need for any address
translation. Using a Virtual IP address for traffic going from the inside to the Internet is even less likely to be a
requirement, but it is supported.
Sample configuration
4. Enter a unique name for the virtual IP and fill in the other fields.
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 recipe 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: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 recipe 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.
l Set External Service Port to 8081 - 8081.
l Use the same Map to Port numbers: 80 - 80.
b. For the other virtual IP:
l Use a different Mapped IP Address/Range, for example, 172.16.200.57.
l Set External Service Port to 8082 - 8082.
l Use the same Map to Port numbers: 80 - 80.
11. Create a Virtual IP Group and put the above three virtual IPs into that group.
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.
l Health check monitoring (optional).
l Session persistence (optional).
l Virtual Server IP (External IP Address).
l Virtual Server Port (External Port).
l Real Servers (Mapped IP Address & Port).
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.
6. Add a security policy that includes the load balance virtual server as the destination address.
This recipe 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.
From FortiOS version 5.6 on, the 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 Services can be applied both as Source and Destination objects in policy.
You can also apply Internet Services to shaping policy.
There are three types of Internet Services we can apply to firewall policy:
l Predefined Internet Services.
l Custom Internet Services.
l Extension Internet Services.
Sample configuration
To apply a predefined Internet Service entry into a policy using the GUI:
To apply a predefined Internet Service entry into a policy using the CLI:
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
set av-profile "g-default"
set ssl-ssh-profile "certificate-inspection"
set nat enable
next
end
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.
Even though there are about 1,395 predefined Internet Services entries and a total of 444,727 IP ranges, we sometimes
still need to create our own Internet Service entries. FortiOS supports custom Internet Service in a firewall policy.
When creating a custom Internet Service, you must set following elements:
l IP or IP Ranges
l Protocol number
l Port or Port Ranges
l Reputation
You must use CLI to create a custom Internet Service.
Sample configuration
Result
In addition to the IP/IP-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 IP_Range(s)+Port_Range(s) to an existing prpedefined Internet Servic,
or remove IP_Range(s)+Port_Range(s) from an existing predefined Internet Service entry.
Using an extension type Internet Service is actually editing a predefined type Internet Service entry and add IP_Range
(s)+ Port_Range(s) to it.
When creating an extension Internet Service and adding custom IP_Range(s)+Port_Range(s), 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(s)+Port(s) 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:
next
edit 8
set start-port 993
set end-port 993
next
edit 9
set start-port 995
set end-port 995
next
edit 10
set start-port 2525
set end-port 2525
next
end
config ip-range
edit 1
set start-ip 2.20.183.160
set end-ip 2.20.183.160
next
end
next
end
next
end
Result
In addition to the IP(s)/IP-Range(s) 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 which
accesses 2.20.183.160 is dropped because this IP+Port(s) is disabled from Google.Gmail.
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:
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
next
end
end
Sample troubleshooting
You need to add firewall policies to allow packets to pass from one interface to another. Multicast packets require
multicast security policies. Similar to firewall policies, in a multicast policy, the administrator specifies the source
interface, destination interfaces, the allowed source address ranges, and destination addresses of the multicast traffic.
You can also use multicast policies to configure source NAT and destination NAT for multicast packets.
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 is 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.
If multicast-forward is disabled, then FortiGate unit drops packets that have multicast source or destination
addresses.
In NAT mode, there is a per-VDOM configuration to disable forwarding any multicast traffic. This command is only
available in NAT mode.
config system settings
set multicast-forward <disable|enable(default)>
end
You can also use the multicast-ttl-notchange option so that FortiGate doesn't increase the TTL value for
forwarded multicast packets. Use this option only if packets are expiring before reaching the multicast router.
When multicast-skip-policy is enabled, no check is performed based on multicast policy. A multicast packet
received on an interface is flooded unconditionally to all interfaces (except the incoming interface) belonging to the
same forwarding domain. Multicast packets are forwarded even when there is no multicast policy or the multicast policy
is set to deny. To forward multicast traffic based on multicast policy, multicast-skip-policy must be disabled.
In transparent mode, there is a per-VDOM configuration to skip policy check and forward all multicast traffics. This
command is only available in transparent mode.
config system settings
set multicast-skip-policy <disable(default)|enable>
end
Sample configuration
Access control lists (ACL) in the FortiOS firmware is a granular or more specifically targeted blacklist. ACL drop IPv4 and
IPv6 packets at the physical network interface before the packets are analyzed by the CPU. On a busy appliance, this
can really improve performance.
ACL is available on FortiGates with NP6-accelerated interfaces. ACL checking is one of the first things that happens to
the packet and checking is done by the NP6 processor. The result is very efficient protection that does not use CPU or
memory resources.
The following platforms support ACL:
l FGT_100D, FGT_100E, FGT_100EF, FGT_101E.
l FGT_140D, FGT_140D_POE, FGT_140E, FGT_140E_POE.
l FGT_301E, FGT_500E, FGT_501E.
l FGT_1200D, FGT_1500D, FGT_1500DT.
l FGT_2000E, FGT_2500E.
l FGT_3000D, FGT_3100D, FGT_3200D, FGT_3700D.
l FGT_3800D, FGT_3810D, FGT_3815D.
l FGT_3960E, FGT_3980E.
Limitation
The configuration of ACL allows you to specify which interface the ACL is applied to. You should be aware of a hardware
limitation. The ACL is a Layer 2 function and is offloaded to the ISF hardware. Therefore, no CPU resources are used in
the processing of the ACL. It is handled by the inside switch chip which can do hardware acceleration, which increases
the performance of the FortiGate. The drawback is that the ACL function is only supported on switch fabric driven
interfaces. It also cannot be applied to hardware switch interfaces or their members. Ports such as WAN1 or WAN2 on
some models that use network cards that connect to the CPU through a PCIe bus do support ACL.
Sample configuration
To block all IPv4 and IPv6 Telnet traffic from port2 to Company_Servers using the CLI:
Sample troubleshooting
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.
3. Click the toggle enable Exclude Members. The Select Entries pane opens.
4. Select the addresses you want to exclude from the group.
5. Click OK.
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.
Inspection mode is configured on a per-policy basis in NGFW mode. This gives you more flexibility when setting up
different policies.
When configuring an IPv4 or IPv6 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.
(policy) # edit 1
(1) # end
To see the HTTP and SSH policy redirect settings when inspection mode is set to proxy using the CLI:
(policy) # end
(policy) # edit 1
(1) # end
To see the default SSL-SSH policy set to no inspection using the CLI:
(policy) # edit 1
(1) # sh
config firewall policy
edit 1
set uuid 05d88354-4817-51e9-7494-06cb70accbf0
set srcintf "wan2"
set dstintf "wan1"
(1) # end
In consolidated policy mode, IPv4 and IPv6 policies are combined into a single policy instead of defining separate
policies.
There is a single policy table for the GUI. The same source interface, destination interface, service, user, and schedule
are shared for IPv4 and IPv6, while there are different IP addresses and IP pool settings.
Enabling consolidated policy mode will delete all existing IPv4 and IPv6 policies.
Limitations
The following features are not currently supported by consolidated policy mode:
l Policy learning mode
l Internet Services entries
l address-negate and service-negate
l DSCP and ToS matching
l Traffic shapers
l Packet capture
l External IP lists
l schedule-timeout, block-notification, disclaimer, custom-log-fields, or reputation
l timeout-send-rst, tcp-session-without-syn, or anti-replay
l Interface Pair View function in the pane toolbar
l Policy Lookup function in the pane toolbar
The session/iprope tables for IPv4 and IPv6 still display separately.
You can add DNS filter profile inspection to IPv6 policies. This includes FortiGuard DNS filtering (with a web filtering
license) and portal replacement message redirect.
A new CLI variable is added to the DNS filter profile for the IPv6 address of the SDNS redirect portal, redirect-
portal6:
config dnsfilter profile
edit "default"
set comment "Default dns filtering."
config domain-filter
unset domain-filter-table
end
config ftgd-dns
unset options
config filters
edit 1
set category 2
set action monitor
next
edit 2
set category 7
set action monitor
next
......
end
set log-all-domain disable
set sdns-ftgd-err-log enable
set sdns-domain-log enable
After the FortiGate successfully initializes communication with the SDNS server (for the domain rating service), the
following CLI command shows the default redirect portal IPv6 address:
(global) # diag test app dnsproxy 3
......
FGD_REDIR_V4:208.91.112.55 FGD_REDIR_V6:[2001:cdba::3257:9652]
e. Click OK.
2. Go to Policy & Objects > IPv4 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
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:
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.2.0, 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.
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 in IPv4 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 IPv4 firewall policy (including virtual wire pairs)
l IPv4 shaping policy
3. For the Destination field, select FABRIC_DEVICE from the list of address entries.
Diagnose command
You can use the diagnose command to list which IP addresses are included in the FABRIC_DEVICE. This is currently
the only method to list content in the FABRIC_DEVICE object.
Traffic shaping
About QoS
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.
Packet rates
The formula for packet rates specified for maximum bandwidth or guaranteed bandwidth is:
rate = amount / time
where rate is in Kbps
Burst size cannot exceed the configured maximum bandwidth. The FortiGate drops packets that exceed the configured
maximum bandwidth. Packets deduct from the amount of bandwidth available to subsequent packets, and available
bandwidth regenerates at a fixed rate. As a result, the available bandwidth for a packet may be less than the configured
rate, down to a minimum of 0 Kbps.
Alternatively, rate calculation and behavior can be described using the token bucket metaphor. A traffic flow has an
associated bucket, which represents burst size bounds and is the size of the configured bandwidth limit. The bucket
receives tokens, which represent available bandwidth at the fixed configured rate. As time passes, tokens are added to
the bucket up to capacity, and excess tokens are discarded. When a packet arrives at the FortiGate, the packet must
deduct bandwidth tokens from the bucket equal to its size in order to leave the FortiGate. If there are not enough
tokens, the packet cannot leave the FortiGate and is dropped.
Bursts are not redistributed over a longer interval, so bursts are propagated rather than smoothed. However, peak size is
limited. The maximum burst size is the capacity of the bucket, which is the configured bandwidth limit. The actual size
varies depending on the current number of tokens in the bucket, which may be less than the capacity of the bucket due
to deductions made by previous packets and the fixed rate at which tokens accumulate. A depleted bucket refills at the
rate of the configured bandwidth limit. Bursts cannot borrow tokens from other time intervals.
By limiting traffic peaks and token regeneration, the available bandwidth may be less than the capacity of the bucket,
but the limit of the total amount per time interval is ensured. Total bandwidth use during each interval of one second is,
at most, the integral of the configured rate.
Rate discrepancy
You may observe that external clients, such as FTP or BitTorrent, initially report rates between the maximum bandwidth
and twice the amount of the maximum bandwidth depending on the size of their initial burst. For example, when a
connection is initiated following a period of no network activity. The apparent discrepancy in rates is caused by a
difference in perspective when delimiting time intervals. A burst from the client may initially consume all tokens in the
bucket, and before the end of one second as the bucket regenerates, is allowed to consume almost another bucket
worth of bandwidth. From the perspective of the client, this equals one time interval. However, from the perspective of
the FortiGate, the bucket cannot accumulate tokens when it is full. Therefore, the time interval for token regeneration
begins after the initial burst and does not contain the burst. These different points of reference result in an initial
discrepancy equal to the size of the burst. The client's rate contains it, but the FortiGate's rate does not. However, if the
connection is sustained to its limit and time progresses over an increasing number of intervals, this discrepancy
decreases in importance relative to the bandwidth total. The client reported rate will eventually approach the configured
rate limit for the FortiGate.
Example
The maximum bandwidth is 50 Kbps, there has been no network activity for one or more seconds, and the bucket is full.
A burst from an FTP client immediately consumes 50 kilobits. Because the bucket completely regenerates over one
second, by the time another second elapses from the initial burst, traffic can consume another 49.999 kilobits, for a total
of 99.999 kilobits between the two points in time. From the vantage point of an external FTP client regulated by this
bandwidth limit, it initially appears that the bandwidth limit is 99.999 Kbps. This is almost twice the configured limit of
50 Kbps. However, bucket capacity only regenerates at the configured rate of 50 Kbps, and the connection can only
consume a maximum of 50 kilobits during each subsequent second. The result is that as bandwidth consumption is
averaged over an increasing number of time intervals, each of which are limited to 50 Kbps, the effect of the first
interval's doubled bandwidth size diminishes proportionately, and the client's reported rate eventually approaches the
configured rate limit. The following table shows the effects of a 50 Kbps limit on client reported rates:
149.999 2 74.999
199.999 3 66.666
249.999 4 62.499
299.999 5 59.998
349.999 6 58.333
Guaranteed bandwidth can also be described using a token bucket metaphor. However, because this feature attempts
to achieve or exceed a rate rather than limit it, the FortiGate does not discard non-conforming packets, as it does for
maximum bandwidth. Instead, when the flow does not achieve the rate, the FortiGate increases the packet priority
queue, in an effort to increase the rate.
Guaranteed and maximum bandwidth rates apply to the bidirectional total for all sessions controlled by the security
policy. For example, an FTP connection may entail two separate connections for the data and control portion of the
session. Some packets may be reply traffic rather than initiating traffic. All packets for both connections are counted
when calculating the packet rate for comparison with the guaranteed and maximum bandwidth rate.
Before implementing QoS, you should identify the types of traffic that:
l Are important to your organization
l Use high amounts of bandwidth
l Are sensitive to latency or packet loss
Discovering the needs and relative importance of each traffic type on your network will help you design an appropriate
overall approach, including how you configure each available QoS component technique. Some organizations discover
they only need to configure bandwidth limits for some services. Other organizations determine they need to fully
configure interface and security policy bandwidth limits for all services, and prioritize the queuing of critical services
relative to traffic rate.
For example, your organization wants to guarantee sufficient bandwidth for revenue-producing e-commerce traffic. You
need to ensure that customers complete transactions and do not experience service delays. At the same time, you need
to ensure low latency for voice over IP (VoIP) traffic that sales and customer support teams use, while traffic latency and
bursts may be less critical to the success of other network applications, such as long term, resumable file transfers.
Best practices
The following list includes recommendations and considerations when configuring QoS in your network:
l Ensure maximum bandwidth limits at the source interface and security policy are not too low. This can cause the
FortiGate to discard an excessive number of packets.
l Consider the ratios of how packets are distributed between the available queues, and which queues are used by
which types of services. Assigning most packets to the same priority queue can reduce the effects of configuring
prioritization. Assigning a lot of high bandwidth services to high priority queues may take too much bandwidth away
from lower priority queues and cause increased or indefinite latency. For example, you may want to prioritize a
latency-sensitive service, such as SIP, over a bandwidth-intensive service, such as FTP. Also consider that
bandwidth guarantees can affect queue distribution, and assign packets to queue 0 instead of their regular queue
in high-volume situations.
l Decide whether or not to guarantee bandwidth because it causes the FortiGate to assign packets to queue 0 if the
guaranteed packet rate is not being met. When you compare queuing behavior for low and high bandwidth
situations, this means the effect of prioritization only becomes visible as traffic volumes rise and exceed their
guarantees. Because of this, you might want only some services to use bandwidth guarantees. This way, you can
avoid the possibility that all traffic uses the same queue in high-volume situations, which negates the effects of
configuring prioritization.
l Configure prioritization for all through traffic by either ToS (type of service)-based priority or security policy priority,
not both, to simplify analysis and troubleshooting. Traffic subject to both ToS-based and security policy priorities
use a combined priority from both parts of the configuration. Traffic subject to only one of the prioritization methods
will use only that priority. If you configure both methods, or if you configure either method for only a subset of
traffic, packets that apply to the combined configuration may receive a lower priority queue than packets that apply
to only one of the priority methods, as well as packets that do not apply to the configured prioritization. For
example, if both the ToS-based priority and security policy priority dictate that a packet should receive a medium
priority, in the absence of bandwidth guarantees, a packet will use queue 3. If only ToS-based priority is configured,
the packet will use queue 1. If only security policy priority is configured, the packet will use queue 2. If no
prioritization is configured, the packet will use queue 0.
l Because you can configure QoS using a combination of security policies and ToS-based priorities, and to
distribute traffic over the six possible queues for each physical interface, the results of those configurations can
be more difficult to analyze because of their complexity. In those cases, prioritization behavior can vary by
several factors, including: traffic volume, ToS or differentiated services (DiffServ) markings, and correlation of
session to a security policy.
The FortiGate does not prioritize traffic based on the differentiated services code point
(DSCP) marking configured in the security policy. However, ToS-based prioritization
can be used for ingress traffic.
l Use the UDP protocol to obtain more accurate testing results. Packets that are discarded by traffic shapers impact
flow-control mechanisms, such as TCP.
l Do not oversubscribe outbandwidth throughput. For example, sum [guaranteed bandwidth] < outbandwidth. For
accurate bandwidth calculations, you must set the outbandwidth parameter on interfaces.
You can limit interface bandwidth for arriving and departing traffic. In some cases, the traffic received on an interfaces
could exceed the maximum bandwidth limit defined in the security policy. Rather than waste processing power on
packets that will get dropped later in the process, you can configure FortiGate to preemptively drop excess packets
when they're received at the source interface. A similar command is available to the outgoing interface.
The following diagram shows how excess packets going from LAN to WAN1 can be intercepted and dropped at the
source interface.
1. Go to Interface.
2. Click interface port1, and click Edit on top menu bar.
3. Go to the Traffic Shaping section, and set the following options:
a. Enable Inbound Bandwidth and type 200.
The default bandwidth unit is kbps.
b. Enable Outbound Bandwidth and type 400.
The default bandwidth unit is kbps.
4. Click OK.
This traffic prioritization method puts packets into the following queues based on its Type of Service (ToS) value:
l High
l Medium
l Low
ToS-based traffic prioritization cannot be used to apply bandwidth limits and guarantees, but it can be used to prioritize
traffic at per-packet levels.
You can use the following command to configure the default system-wide level of priority:
config system global
set traffic-priority-level {high | low | medium}
end
You can also prioritize packets according to the ToS bit value in the packet’s IP header by using the following command:
config system tos-based-priority
edit <id_int>
set tos [0-15]
set priority {high | low | medium}
next
end
Example
The following configuration shows that packets with ToS bit values of 10 are prioritized as medium and packets with
ToS bit values of 20 are prioritized as high. All the other traffic is prioritized as low.
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.
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.
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
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
maximum-bandwidth 1250 KB/sec
guaranteed-bandwidth 125 KB/sec
current-bandwidth 0 B/sec
priority 4
tos ff
packets dropped 0
bytes dropped 0
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.
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.
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
Priority queues
After packet acceptance, FortiOS classifies traffic and may apply Quality of Service (QoS) techniques such as
prioritization and traffic shaping. Traffic shaping consists of a mixture of traffic policing to enforce bandwidth limits and
priority queue adjustment to assist packets in achieving the guaranteed rate.
If you have configured prioritization, FortiOS prioritizes egressing packets by distributing them among first in first out
(FIFO) queues associated with each possible priority number. Each physical interface has six priority queues. Virtual
interfaces use the priority queues of the physical interface to which they are bound.
The physical interface's six queues are queue 0 to queue 5, where queue 0 is the highest priority queue. However, you
might observe that your traffic uses only a subset of those six queues. For example, some traffic may always use a
certain queue number. Queuing may also vary by the packet rate or mixture of services. Some queue numbers may only
be used by through traffic for which you have configured traffic shaping in the security policy that applies to that traffic
session.
Priority types
ToS priority
The first and second types, ingress priority and priority for generated packets, are controlled by two different CLI
settings:
config system global
set traffic-priority-level {high|medium|low}
end
config system tos-based-priority
edit 1
set tos [0-15] -> type of service bit in the IP datagram header with a value between 0
and 15
set priority (high|medium|low)-> priority of this type of service
next
end
High 0
Medium 1
Low 2
In a firewall shaping policy, you can enable traffic shaping. In the shared traffic shaper, you can set the firewall priority to
high, medium, or low, as shown below:
config firewall shaper traffic-shaper
edit 1
set priority {high | medium | low}
next
end
As the priority in a traffic shaper is set to high by default, you must set some traffic at a lower priority to see results. Each
priority level is mapped to a value as follows:
High (default) 1
Medium 2
Low 3
To combine the two priority types, the global or ingress ToS-based priority value is combined with the firewall policy
priority value:
ToS priority (0, 1, 2) + policy priority (1, 2, 3) = total priority (queue number)
Consider the following scenarios:
l If the current packet rate is less than the guaranteed bandwidth, packets use priority queue 0. Packet priority is 0.
l If the current packet rate exceeds the maximum bandwidth, excess packets are dropped.
l If the current packet rate is greater than the guaranteed bandwidth but less than the maximum bandwidth, FortiOS
assigns a priority queue by adding the ToS-based priority and the firewall priority.
For example, if you have enabled traffic shaping in the security policy and the security policy's traffic priority is low
(value 3), and the priority normally applied to packets with that ToS bit is medium (value 1), the packets have a total
packet priority of 4, and use priority queue 4.
A traffic shaping policy can be used for interface-based traffic shaping by organizing traffic into 30 groups. The shaping
profile defines the percentage of the interface’s bandwidth that is allocated to each group. Each traffic group is shaped
to the assigned speed according to the outgoing bandwidth limit configured on the interface.
To configure this feature following these steps:
1. Traffic classification on page 480
2. Traffic prioritization on page 481
3. Shaping profile on an interface on page 481
Traffic classification
A shaping policy is used to classify traffic and organize it into different groups, or class IDs, based on matching criteria.
For traffic matching a criteria, you can choose to put it into 30 different shaping groups, identified by group ID 2 to 31.
You must select an outgoing interface for the traffic. The shaping policy is only applied when the traffic is going to one of
the selected outgoing interfaces.
Criteria 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.
l Internet service: Match the traffic to the selected internet service. This
method cannot be used in conjunction with address or user matching.
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. This
method cannot be used in conjunction with address matching.
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.
Criteria Description
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 505 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 515 for more information.
When multiple items are selected in one criteria, it is considered a match when traffic
matches any one of them.
Traffic prioritization
Shaping profiles define how different shaping groups or classes of traffic are prioritized. For each group or class, you can
define three prioritization strategies: guaranteed bandwidth, maximum bandwidth, and priority.
For each shaping profile, a default shaping group 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 group's priority: 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 interface's outgoing bandwidth as the maximum link speed, and only works when the
outgoing bandwidth is configured.
Example
This example shows applying interface-based traffic shaping on web and file accessing traffic according to a schedule.
l The link speed of the wan1 interface is 10Mb/s.
l File access can use up to 2Mb/s from 8am to 6pm.
To put the web accessing traffic into a shaping group using the GUI:
To put the file accessing traffic into a shaping group using the GUI:
2. Put the web and file accessing traffic into shaping groups:
config firewall shaping-policy
edit 2
set name "web_access_day_hours"
set comment "To limit web accessing traffic to 8Mb/s on day time"
set service "HTTP" "HTTPS"
set schedule "Day_Hours"
set dstintf "wan1"
set class-id 10
set srcaddr "all"
set dstaddr "all"
next
edit 3
set name "File_access_day_hours"
set comment "To limit file accessing traffic to 2Mb/s on day time"
set service "AFS3" "FTP" "FTP_GET" "FTP_PUT" "NFS" "SAMBA" "SMB" "TFTP"
set schedule "Day_Hours"
set dstintf "wan1"
set class-id 20
set srcaddr "all"
set dstaddr "all"
next
end
A traffic shaping profile defines the guaranteed and maximum bandwidths each group receives. File access can use up
to 2Mb/s, and web access can use 8Mb/s from 8am to 6pm.
7. Click OK.
5. Click OK.
Diagnose commands
To check that the specific traffic is put into the correct shaping group or class ID:
max-bandwidth=2000(kbps) current-bandwidth=0(kbps)
priority=medium total_bytes=0 drop_bytes=0
class-id=10 allocated-bandwidth=6000(kbps) guaranteed-bandwidth=6000(kbps)
max-bandwidth=8000(kbps) current-bandwidth=0(kbps)
priority=medium total_bytes=0 drop_bytes=0
class-id=30 allocated-bandwidth=3000(kbps) guaranteed-bandwidth=3000(kbps)
max-bandwidth=10000(kbps) current-bandwidth=5(kbps)
priority=high total_bytes=136K drop_bytes=0
stat: rxp=9492 txp=8116 rxb=2761067 txb=4702526 rxe=0 txe=0 rxd=0 txd=0 mc=960 collision=0
re: rxl=0 rxo=0 rxc=0 rxf=0 rxfi=0 rxm=0
te: txa=0 txc=0 txfi=0 txh=0 txw=0
misc rxc=0 txc=0
input_type=0 state=3 arp_entry=0 refcnt=32
You can configure interface-based traffic shaping in FortiOS through the GUI or CLI.
In this example, QA traffic to the database is put into shaping group 10 and is guaranteed to have 60% of the interface
bandwidth, which is 6 Mbps. Other QA traffic is put into shaping group 20 and is guaranteed to have 40% of the
interface bandwidth, which is 4 Mbps.
d. Click OK.
2. Create shaping policies for QA to access the database and the internet:
config firewall shaping-policy
edit 1
set name "To_Database"
set service "ALL"
set dstintf "port9"
set class-id 10
set srcaddr "QA_subnet"
set dstaddr "Database"
next
edit 2
set name "To_Internet"
set service "ALL"
set dstintf "port9"
set class-id 20
set srcaddr "QA_subnet"
set dstaddr "all"
next
end
next
end
Antivirus
Introduction
Content Disarm and Reconstruction (CDR) allows the FortiGate to sanitize Microsoft documents and PDF (disarm) by
removing active content such as hyperlinks, embedded media, javascript, macros, etc. from the office document files
without affecting the integrity of it's textual content (reconstruction).
This feature allows network admins to protect their users from malicious office document files.
Files processed by CDR can have the original copy quarantined on the FortiGate, allowing admins to observe them.
These original copies can also be obtained in the event of a false positive.
l CDR can only be performed on Microsoft Office Document and PDF files.
l Local Disk CDR quarantine is only possible on FortiGate models that contain a hard disk.
l CDR is only supported on HTTP, SMTP, POP3, IMAP.
l SMTP splice and client-comfort mode is not supported.
l CDR does not work on flow based inspection modes.
l CDR can only work on files in .ZIP type archives.
In order to configure antivirus to work with CDR, you must enable CDR on your antivirus profile, set the quarantine
location, and then fine tune the CDR detection parameters.
Discard The default setting which discards the original document file.
File Quarantine Saves the original document file to disk (if possible) or a connected
FortiAnalyzer based on the FortiGate's log settings, visible through Config
Global > Config Log FortiAnalyzer Setting.
FortiSandbox Saves the original document file to a connected FortiSandbox.
FGT_PROXY (content-disarm) #
Introduction
FortiGuard Outbreak Prevention was introduced in FortiOS 6.0.0 and allows the FortiGate antivirus database to be
subsidized with third-party malware hash signatures curated by the FortiGuard.
Those hash signatures are obtained from external sources such as VirusTotal, Symantec, Kaspersky, and other third-
party websites and services.
This feature provides the mechanism for antivirus to query the FortiGuard with the hash of a scanned file. If the
FortiGuard returns a match from its many curated signature sources, the scanned file is deemed to be malicious.
The concept of FortiGuard Outbreak Prevention is to detect zero-day malware in a collaborative approach.
l FortiGuard Outbreak Prevention can be used in both proxy-based and flow-based policy inspections across all
supported protocols.
l FortiGuard Outbreak Prevention does not support AV in quick scan mode.
l FortiGate must be registered with a valid FortiGuard Outbreak Prevention license before this feature can be used.
In order for antivirus to work with an external block list, you must register the FortiGate with a FortiGuard Outbreak
Prevention license and enable FortiGuard Outbreak Prevention in the antivirus profile.
1. See the following link for instructions on how to purchase or renew a FortiGuard Outbreak Prevention license:
https://video.fortinet.com/products/fortigate/6.0/how-to-purchase-or-renew-fortiguard-services-6-0
2. Once the license has been activated, you can verify its status by going to Global > System > FortiGuard.
1. Go to Security Profiles > AntiVirus.
2. Select the toggle to enable Use FortiGuard Outbreak Prevention Database.
3. Click Apply.
Service : Web-filter
Status : Enable
License : Contract
Service : Antispam
Status : Disable
Introduction
External Malware Blocklist is a new feature introduced in FortiOS 6.2.0 which falls under the umbrella Outbreak
Prevention.
This feature provides another means of supporting the AV Database by allowing users to add their own malware
signatures in the form of MD5, SHA1, and SHA256 hashes.
This feature provides a mechanism for Antivirus to retrieve an external malware hash list from a remote server and polls
the hash list every n minutes for updates.
Malware detection using External Malware Blocklist can be used in both proxy-based and flow-based policy inspections.
Just like FortiGuard Outbreak Prevention, External Dynamic Block List is not supported in AV quick scan mode.
Using different types of hash simultaneously may slow down the performance of malware scanning. For this reason,
users are recommended to only using one type of hash (either MD5, SHA1, or SHA256), not all three simultaneously.
# Invalid entries
7688499dc71b932feb126347289c0b8a_md5_sample2
7614e98badca10b5e2d08f8664c519b7a906fbd5180ea5d04a82fce9796a4b87sha256_sample3
l Create new external source on Global > Security Fabric > Fabric Connectors page:
l Fill out the fields as shown below. URI should point to the malware hashlist on the remote server:
l User can view entries inside the malware blocklist by clicking the View Entries button:
l Enable External Malware Blocklist on the antivirus profile and apply the change:
Check if the scanunit daemon has updated itself with the external hashes:
FGT_PROXY # config global
FGT_PROXY (global) # diagnose sys scanunit malware-list list
md5 'aa67243f746e5d76f68ec809355ec234' profile 'hash_list' description 'md5_sample1'
sha1 'a57983cb39e25ab80d7d3dc05695dd0ee0e49766' profile 'hash_list' description 'sha1_sample2'
sha256 '0289b0d967cb7b1fb1451339c7b9818a621903090e0020366ab415c549212521' profile 'hash_list'
description ''
sha256 'ae9bc0b4c5639d977d720e4271da06b50f7c60d1e2070e9c75cc59ab30e49379' profile 'hash_list'
description 'sha256_sample1'
Application Control
FortiGate units can detect and take action against network traffic depending on the application generating the traffic.
Based on FortiGate Intrusion Protection protocol decoders, Application Control is a user-friendly and powerful way to
use Intrusion Protection features to log and manage the behavior of application traffic passing through the FortiGate
unit. 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 detection for traffic using the HTTP
protocol (version 1.0, 1.1, and 2.0).
The FortiGate unit can recognize the network traffic generated by a large number of applications. You can create
Application Control sensors that specify the action to take with the traffic of the applications you need to manage and
the network on which they are active, and then add Application Control sensors to the firewall policies that control the
network traffic you need to monitor.
An Application Control sensor has one or more options/entries configured which examines the app traffic for:
l Application category
l Application signature ID
l Filters overrides
l Custom signature
l Default port service
l Default network service
When selecting the app category, signature, or filter that you intend to work with, the following actions can be set to the
specific entry:
l Allow: App traffic will be allowed and no logs are recorded.
l Monitor: The entry match is allowed and logged.
l Block: Traffic matching the entry will be blocked.
l Reset: The session will be dropped and a new session will be started.
l Quarantine IP address: Traffic matching the entry will be blocked. The client initiating the traffic will be source-ip
banned.
l Shaper/Per-ip-shaper: Max-bandwidth and quaratined-bandwidth values can be set to limit the link speed.
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.
l Categories: Choose groups of signatures based on a category type.
l Application overrides: Choose individual applications.
l Filter overrides: Select groups of applications and override the application signature settings for them.
Categories
2 P2P
3 VoIP
5 Video/Audio
6 Proxy
7 Remote.Access
8 Game
12 General.Interest
15 Network.Service
17 Update
21 Email
22 Storage.Backup
23 Social.Media
25 Web.Client
26 Industrial
28 Collaboration
29 Business
30 Cloud.IT
31 Mobile
set action {pass | block | reset}
pass Pass or allow matching traffic.
block Block or drop matching traffic.
reset Reset sessions for matching traffic.
set log {enable | disable}
next
end
next
end
1 Browser-Based
2 Client-Server
4 Peer-to-Peer
set behavior {id}
All All
2 Botnet
3 Evasive
5 Excessive-Bandwidth
6 Tunneling
9 Cloud
set popularity {1-5} #Popularity level 1-5
set action {pass | block | reset}
pass Pass or allow matching traffic.
block Block or drop matching traffic.
reset Reset sessions for matching traffic.
set log {enable | disable}
next
end
next
end
c. Select Cloud under the behavior section from the Select Entries list.
Matched signatures are shown along the bottom.
d. Select OK.
Most networking applications run on specific ports. For example, SSH runs on port 22, and Facebook runs on port 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 application allowed by the app control sensor is only run on its default port.
For example, when applying the above appctrl sensor, FTP traffic with the standard port (port 21) is allowed, while the
non-standard port (port 2121) is blocked.
Protocol enforcement allows you to configure networking services (e.g. FTP, HTTP, HTTPS) on known ports (e.g. 21,
80, 443). For protocols which are not whitelisted under select ports, the IPS engine performs the violation action to
block, allow, or monitor that traffic.
This feature acts upon the following two scenarios:
l When one protocol dissector confirms the service of network traffic, protocol enforcement can check whether the
confirmed service is whitelisted under the server port. If it is not, then the traffic is considered a violation and IPS
can take the action specified by config (e.g. block).
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.
CLI configuration
In an applicable profile, a default-network-service list can be created to associate well known ports with accepted
services.
GUI Configuration
A new table is displayed when the Network Protocol Enforcement toggle is set to the On position. Enforced entries can
be created, edited, or deleted to configure network services on certain ports and determine the violation action.
Application control profiles include protocol enforcement. This allows you to configure network services (such as FTP,
HTTP, and HTTPS) on known ports (such as 21, 80, and 443), while blocking those services on other ports.
The functionality 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 whitelisted under the server port. If it is not whitelisted, the traffic is considered a violation and
IPS can take action as specified in the configuration (block or monitor it).
l There is no confirmed service for the network traffic. It would be considered a service violation if IPS dissectors rule
out all the services enforced under its server port.
The network service is visible in the Network Protocol Enforcement section. In the following example, another
network service was configured for port 53:
To configure the application profile default network service list using the CLI:
Web Filter
Web Filter is a means of controlling the content that an internet user is able to view. With the increased popularity of
web applications, the need to monitor and control web access is becoming a key component of secure content
management systems that employ antivirus, Web Filter, and messaging security.
This topic provides a general introduction to the Web Filter security profile. Additional information, such as the GUI and
CLI configurations, can be found in subsequent topics.
Web Filter configuration can be separated into the following parts: Web Filter profile configuration and Web Filter
profile overrides.
There are five components to Web Filter configuration:
l URL filter: Block, allow, exempt, or monitor traffic by URL.
l FortiGuard filter: With a FortiGuard license, you can get the rating of a URL. Action can be taken against the
packet based on its rating.
l Content filter: Block or exempt traffic by checking its content.
l File filter: Log or block a file based on its file type (e.g. ZIP, MP3, PNG).
l Advanced filter
There are two different ways to override Web Filter behavior based on FortiGuard categorization of websites:
l Using alternate categories: Web rating overrides. This method manually assigns a specific website to a different
Fortinet category or a locally created category.
l Using alternate profiles: The traffic going through the FortiGate unit using identity based policies and a Web
Filter profile have the option where configured users or IP addresses can use an alternative Web Filter profile when
attempting to access blocked websites.
URL filter is also called static URL filter. By adding specific URLs with patterns containing text and regular expressions,
FortiGate can allow, block, exempt, and monitor web pages matching any specified URLs or patterns, and can display a
replacement message instead.
Sample topology
You can create a URL filter using the GUI or CLI. After creating the URL filter, attach it to a webfilter profile.
1. Go to Security Profiles > Web Filter and go to the Static URL Filter section.
2. Enable URL Filter.
3. Under URL Filter, select Create New to display the New URL Filter pane.
Simple 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 FortiGate finds a match, it performs the selected URL Action.
Regular FortiGate tries to match the pattern based on the rules of regular expressions or
Expression or wildcards. For example, if you enter *fa* in the URL field, it matches all the content that
Wildcard has fa such as www.facebook.com, message.facebook.com, fast.com, etc.
When FortiGate finds a match, it performs the selected URL Action.
For more information, see the URL Filter expressions technical note in
https://kb.fortinet.com/kb/documentLink.do?externalID=FD37057.
Block Denies or blocks attempts to access any URL matching the URL pattern. FortiGate
displays a replacement message.
Allow The traffic is passed to the remaining FortiGuard webfilters, 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.
Exempt The traffic is allowed to bypass the remaining FortiGuard webfilters, web content filters,
web script filters, antivirus scanning, and DLP proxy operations
4. For example, enter *facebook.com and select Wildcard and Block; and select OK.
To create and enable a URL filter using the CLI, create the URL filter and then attach it to a webfilter profile. The CLI
commands below show the full configuration of creating a URL filter.
config webfilter urlfilter
edit {id}
# Configure URL filter lists.
set name {string} Name of URL filter list. size[35]
config entries
edit {id}
# URL filter entries.
set url {string} URL to be filtered. size[511]
set type {simple | regex | wildcard} Filter type (simple, regex, or wildcard).
simple Simple URL string.
regex Regular expression URL string.
wildcard Wildcard URL string.
set action {exempt | block | allow | monitor} Action to take for URL filter
matches.
exempt Exempt matches.
block Block matches.
allow Allow matches (no log).
monitor Allow matches (with log).
set status {enable | disable} Enable/disable this URL filter.
set exempt {option} If action is set to exempt, select the security profile oper-
ations that exempt URLs skip. Separate multiple options with a space.
av AntiVirus scanning.
web-content Web Filter content matching.
activex-java-cookie ActiveX, Java, and cookie filtering.
dlp DLP scanning.
fortiguard FortiGuard web filter.
range-block Range block feature.
pass Pass single connection from all.
After you have created the URL filter and attached it to a webfilter profile, you must attach the profile to a firewall policy.
3. In the Security Profiles section, enable Web Filter and select the profile you created.
Validate the URL filter results by going to a blocked website. For example, when you go to the Facebook website, you
see the replacement message.
2. If there are too many log entries, click Add Filter and select Event Type > urlfilter to display logs generated by the
URL filter.
To use this service, you must have a valid subscription on your FortiGate.
FortiGuard filter enhances the Web Filter features supplied with your FortiGate unit by sorting billions of web pages into
a wide range of categories that users can allow or block.
FortiGuard Web Filter services includes over 45 million individual website rating that applies to more than two billion
pages. When FortiGuard filter is enabled in a Web Filter and is 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.
You can select one of the following FortiGuard Web Filter actions:
Block Prevent access to the sites in the category. Users trying to access a blocked site sees a
replacement message indicating the site is blocked.
Monitor Permits and logs access to sites in the category. You can enable user quotas when you
enable this action.
Warning Displays a message to the user allowing them to continue if they choose.
Authenticate Requires the user to authenticate with the FortiGate before allowing access to the category
or category group.
FortiGuard has many Web Filter categories including two local categories and a special remote category. For more
information on the different categories, see the table below.
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 local category and not external or FortiGuard built-in category.
This example shows blocking a website based on its category (rating), for example, information technology.
1. Go to Security Profiles > Web Filter and go to the FortiGuard category based filter section.
2. Open the General Interest - Business section by clicking the + icon beside it.
1. Go to a website belonging to the blocked category, for example, www.fortinet.com, and you see a blocked page
and the category that is blocked.
This example shows issuing a warning when a user visits a website based on its category (rating), for example,
information technology.
1. Go to Security Profiles > Web Filter and go to the FortiGuard category based filter section.
2. Open the General Interest - Business section by clicking the + icon beside it.
3. Select Information Technology and then select Warning.
4. Set the Warning Interval which is the interval when the warning page appears again after the user chooses to
continue.
1. Go to a website belonging to the selected category, for example, www.fortinet.com, and you see a warning page
where you can choose to Proceed or Go Back.
This example shows authenticating a website based on its category (rating), for example, information technology.
1. Go to Security Profiles > Web Filter and go to the FortiGuard category based filter section.
2. Open the General Interest - Business section by clicking the + icon beside it.
3. Select Information Technology and then select Authenticate.
4. Set the Warning Interval which is the interval when the authentication page appears again after authentication.
5. Click the + icon beside Selected User Group and select a user group. You must have a valid user group to use this
feature.
1. Go to a website belonging to the selected category, for example, www.fortinet.com. First, you see a warning page
where you can choose to Proceed or Go Back.
3. Enter the username and password of the user group you selected, and click Continue.
If the credentials are correct, the traffic is allowed through.
When the FortiGuard Web Filter action is Block, Warning, or Authenticate, there is a Customize option for you to
customize the replace page.
1. Go to Security Profiles > Web Filter and go to the FortiGuard category based filter section.
2. Right-click the item and select Customize.
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 is calculated separately for each user. Quotas are reset everyday at midnight.
Quotas can be set only for the actions of Monitor, Warning, or Authenticate. When the quota is reached, the traffic is
blocked and the replacement page displays.
Sample topology
This example shows setting a time quota for a category, for example, the Education category.
1. Go to Security Profiles > Web Filter and go to the FortiGuard category based filter section.
2. Open the General Interest - Personal section by selecting the + icon beside it.
3. Select Education and then select Monitor.
4. In the Category Usage Quota section, select Create New.
5. In the right pane, select the Category field and then select Education.
6. For the Quota Type, select Time and set the Total quota to 5 minute(s).
7. Select OK and the Category Usage Quota section displays the quota.
8. Validate the configuration by visiting a website in the education category, for example https://www.harvard.edu/.
You can view websites in the education category.
9. Check the used and remaining quota in Monitor > FortiGuard Quota.
10. When the quota reaches its limit, traffic is blocked and the replacement page displays.
You can control access to web content by blocking web pages containing specific words or patterns. This helps to
prevent access to pages with questionable material. You can specify words, phrases, patterns, wildcards and Perl
regular expressions to match content on web pages. You can use multiple web content filter lists and select the best
web content filter list for each Web Filter profile.
Pattern type
When you have created the Web Filter content list, you need to add web content patterns to it. There are two types of
patterns: wildcard and regular expression.
Wildcard
Use the wildcard 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 forticare.com. The * represents any character appearing any number of times.
Regular expression
Use the regular expression setting to block or exempt patterns of Perl expressions which 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.
The maximum number of web content patterns in a list is 5000.
Content evaluation
The web content filter feature scans the content of every web page that is accepted by a security 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, 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 web page is
blocked by a single match.
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 web
page.
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 contents of a web page. For example, a web page
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 web
page.
word phrase 20 40 20 Each word appears twice but only counted once giving a
total score of 40. Web page is blocked.
word sentence 20 20 20 “word” appears twice, “sentence” does not appear, but
since any word in a phrase without quotation marks is
counted, the score for this pattern is 20. Web page is
blocked.
"word 20 0 20 This phrase does not appear exactly as written. Web page
sentence" is allowed.
"word or 20 20 20 This phrase appears twice but is counted only once. Web
phrase" page is blocked.
Sample configuration
1. Go to Security Profiles > Web Filter and go to the Static URL Filter section.
2. Enable Content Filter to display its options.
4. For Pattern Type, select Regular Expression and enter fortinet in the Pattern field.
l Leave Language as Western.
l Set Action to Block.
l Set Status to Enable.
6. Validate the configuration by visiting a website with the word fortinet, for example, www.fortinet.com. The website
is blocked and a replacement page displays.
next
end
Advanced Filters 1
To use this feature, you must be registered to a FortiSandbox and be connected to it.
This feature blocks malicious URLs that FortiSandbox finds.
1. Go to Security Profiles > Web Filter and go to the Static URL Filter section.
2. Enable Block malicious URLs discovered by FortiSandbox.
If you don't have a FortiGuard license but you have enabled services that need a FortiGuard license, such as FortiGuard
filter, then you'll 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 go to the Rating Options section.
2. Enable Allow websites when a rating error occurs.
If you enable this feature, in addition to only sending domain information to FortiGuard for rating, 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.
FortiGuard server might return a different category of IP address and URL domain. If they are different, 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 FortiGate.
For example, if we use a spoof IP of Google as www.irs.gov, FortiGate will send both the IP address and domain name
to FortiGuard to get the rating. In this example, we get two different ratings, one is search engine and portals which
belongs to the IP of Google, another is government and legal organizations which belongs to www.irs.gov. As
the search engine and portals has a higher weight than government and legal organizations, this traffic will be rated
as search engine and portals and not rated as government and legal organizations.
1. Go to Security Profiles > Web Filter and go to the Rating Options section.
2. Enable Rate URLs by domain and IP address.
Use this feature to block websites when their SSL certificate CN field does not contain a valid domain name.
For example, this option blocks URLs which contains spaces. If there is a space in the URL, it must be written
as: http://www.example.com/space%20here.html.
1. Go to Security Profiles > Web Filter and go to the Static URL Filter section.
2. Enable Block invalid URLs .
This feature enable FortiGate to retrieve ratings for individual images in addition to websites. Images in a blocked
category are not displayed even if they are part of a site in an allowed category. Blocked images are replaced with blank
placeholders. These image file types are rated: GIF, JPEG, PNG, BMP, and TIFF.
This feature requires a valid FortiGuard license, otherwise rating errors will occur. By default, this feature is enabled.
For example, if the Other Adult Materials category is blocked, before enabling Rate images by URL, the image is not
blocked:
After enabling Rate images by URL, images in the Other Adult Materials category are blocked. For example:
1. Go to Security Profiles > Web Filter and go to the Rating Options section.
2. Enable Rate images by URL.
Advanced Filters 2
These advanced filters are only available when inspection mode is Proxy.
Safe search
This feature applies to popular search sites and prevents explicit websites and images from appearing in search results.
Supported search sites are:
l Google
l Yahoo
l Bing
l Yandex
1. Go to Security Profiles > Web Filter and go to the Search Engines section.
2. Enable Enforce 'Safe Search' on Google, Yahoo!, Bing, Yandex.
Use these features to limit users' access to YouTube channels, such as in an education environment where you want
students and users to be able to access YouTube education videos but not other YouTube videos.
Formerly, YouTube for Schools was a way to access educational videos inside a school network. This YouTube feature
lets schools access educational videos on YouTube EDU and to specify the videos accessible within the school network.
When Google stopped supporting YouTube for Schools on July 1, 2016, YouTube safe search also stopped working.
Google provides information on restricting YouTube content such as Restrict YouTube content available to G Suite
users. At this time, the options Google offers to restrict inappropriate content includes: DNS, HTTP headers, and
Chromebooks..
1. Go to Security Profiles > Web Filter and go to the Search Engines section.
2. Enable Restrict YouTube Access and select Strict or Moderate.
This Web Filter feature is also called Restrict YouTube access to specific channels. Use this feature to block or only
allow matching YouTube channels.
The following identifiers are used:
given <channel-id>, affect on:
www.youtube.com/channel/<channel-id>
www.youtube.com/user/<user-id>
1. Go to Security Profiles > Web Filter and go to the Proxy Options section.
2. Enable Restrict YouTube access to specific channels.
3. Select Create New and specify the Channel ID, for example, UCGzuiiLdQZu9wxDNJHO_JnA.
4. Select OK and the option shows the Channel ID and its Link.
set youtube-channel-status whitelist <-- whitlist: only allow the traffic belongs to
this channel id and relative identifiers
1. Go to Security Profiles > Web Filter and go to the Search Engines section.
2. Enable Log all search keywords.
Use this feature to block access to some Google accounts and services while allowing access to accounts in the
domains in the exception list.
1. Go to Security Profiles > Web Filter and go to the Proxy Options section.
2. Enable Restrict Google account usage to specific domains.
3. Select the + button and enter the domains that Google can access, for example, www.fortinet.com.
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.
HTTP POST Action
Select the action to take with HTTP POST traffic. HTTP POST is the command used by your browser when you send
information, such as a form you have filled-out 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 go to the Proxy Options section.
2. For HTTP POST Action, select Allow or Block.
The Remove Java Applets feature filters java applets from web traffic. Websites using java applets might not function
properly if you enable this filter.
The Remove ActiveX feature filters ActiveX scripts from web traffic. Websites using ActiveX might not function properly
with if you enable this filter.
The Remove Cookies feature filters cookies from web traffic. Websites using cookies might not function properly if you
enable this filter.
1. Go to Security Profiles > Web Filter and go to the Proxy Options section.
2. Select the filters you want to use: Remove Java Applets, Remove ActiveX, and/or Remove Cookies.
For example, a website called example.com is in the subcategory of pornography and the organization uses FortiGuard
Web Filter to block access to sites in the category of pornography. However, in this example, example.com is a client
and that website is for artists that specialize in nudes and erotic images. In this example, there are two approaches. The
first is to use the web rating override function to assign example.com to the nudity and risque category instead of
pornography category to match the criteria that the organization goes by. The second approach is to assign the website
to a custom category that is not blocked because the website belongs to a client and staff need to access that website.
Another example from the reverse perspective is a school decides that a website specializing in selling books online
should not be accessible because it sells books with violent subject matter. Fortinet categorizes this website,
example2.com, as General Interest - Business with the subcategory of Shopping and Auction, which is a category that is
allowed. In this example, the school can reassign this website to the category Adult Material which is a blocked
category.
You can assign a website to a built-in category or a custom category.
You can create a custom or local category and assign a URL to it.
1. Go to Security Profiles > Web Rating Overrides and click Custom Categories.
2. In the Custom Categories pane, click Create New.
4. Click OK.
The custom category appears in Web Filter under Local Categories where you can change the Action for that
category.
next
end
You can override a URL to another category or to a custom category. This example shows overriding www.fortinet.com
to the custom category: mylocalcategory.
1. Go to Security Profiles > Web Rating Overrides and click Create New.
2. In the New Web Rating Overrides pane, enter the URL you want to re-categorize.
3. To view the URL's current rating, click Lookup Rating.
4. In the Override to section:
a. For Category, select Custom Categories.
b. For Sub-Category, select mylocalcategory.
5. Click OK.
The URL www.fortinet.com now belongs to the mylocalcategory category.
External Resources is a new feature introduced in FortiOS 6.0, which provides a capability to import an external blacklist
which sits on an HTTP server. This feature helps FortiGate retrieve a dynamic URL/Domain Name/IP Address/Malware
hash list from an external HTTP server periodically. FortiGate uses these external resources as Web Filter's remote
categories, DNS Filter's remote categories, policy address objects or antivirus profile's malware definitions. If the
external resource is updated, FortiGate objects will update dynamically.
IDN (International Domain Name) and UTF encoding URL is supported (from 6.2).
IPv4,IPv6 format URL is supported. IPv6 in URL list must in [ ] form.
We can use CLI to configure the external resources files that is located on external HTTP Server. Under Global,
configure the external resource file location and specify the resource type.
Web Filter will use category type external resources as Remote Categories. In the following example, it is configured a
file Ext-Resource-Type-as-Category-1.txt as type as category, it will be treated in Web Filter as Remote Category, the
category name configured as Ext-Resource-Type-as-Category-1 and category-id as 192:
config system external-resource
edit "Ext-Resource-Type-as-Category-1"
set type category <----
Now in each VDOM, category type external resource can be used in Web Filter as Remote Cateogry. In the example
above, URL list in "Ext-Resource-Type-as-Category-1.txt" file will be treated as remote category (category-id 192).
Configure the action for this remote category in Web Filter profile and apply it in the policy:
config webfilter profile
edit "webfilter"
config ftgd-wf
unset options
config filters
edit 1
set category 2
set action warning
next
......
edit 24
set category 192 <----
set action block
next
edit 25
set category 221
set action warning
next
edit 26
set category 193
next
end
end
set log-all-url enable
next
end
To configure, edit, or view the Entries for external resources from GUI:
4. Enter the resource name, URI location of the resource file, resource authentication credential, and Refresh Rate.
5. Click OK.
6. After a few minutes, double-click the Threat Feeds Object you just configured. It is shown in the Edit page.
7. Click View Entries to view the entry list in the external resources file:
8. Go to VDOM > Security Profiles > Web Filter. The configured external resources is shown and configured in each
Web Filter Profile:
Log Example
If an HTTP/HTTPS request URL is matched in remote category's entry list, it will override its original FortiGuard URL
rating and be treated as a remote category.
Go to VDOM > Log & Report > Web Filter:
CLI Example:
HTTPS request URLs matched in this remote category will be exempted from SSL deep inspection.
Log example:
Web Filter can have both local category and remote category at the same time. There's no duplication check between
local category URL override and remote category resource file. For example, a URL like www.example.com may be
shown both in remote category entry list and in FortiGate's local category URL override configuration. We recommend
avoiding this scenario since FortiGate does not check for duplicates. However, if a URL is duplicated in both local
category and remote category, it is rated as local category.
Introduction
File Filter is a new feature introduced in FortiOS 6.2, and provides the Web Filter profile with the capability to block files
passing through a FortiGate based on file type. In addition, the configuration for file type filtering has been greatly
simplified. In previous FortiOS versions, File Filtering could only be achieved by configuring a DLP (Data Leak
Prevention) sensor.
In FortiOS 6.2, HTTP and FTP File Filtering is configurable in Web Filter profile, and SMTP, POP3, IMAP file-filtering is
configurable in Email filter profile. Currently, File Filtering in Web Filter profile is based on file type (file's meta data)
only, and not on file size or file content. Users will still need to configure a DLP sensor to block files based on size or
content such as SSN numbers, credit card numbers or regexp.
FTP inspection and GUI configuration have yet to be implemented. In addition, Web Filter File Filtering will only work
on proxy mode policies.
File Filter in Web Filter profile supports the following file types:
xz Match xz files
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
Using CLI, configuration for File Filtering is nested inside Web Filter profile's configuration.
In File filtering configuration, file filtering functionality and logging is independent of the Web Filter profile.
To block or log a file type, configure file filter entries. Within each entry, specify a file-type, action (log|block), protocol to
inspect (http|ftp), direction we want to inspect traffic (incoming|outgoing|any), and match only encrypted files. In
addition, in each file filter entry we can specify multiple file types. File filter entries are ordered, however, blocked will
take precedence over log.
In the CLI example below, we want to file filter the following using Web Filter profile:
1. Block PDFs from entering our leaving our network (filter1).
2. Log the download of some graphics file-types via HTTP (filter2).
3. Block EXE files from leaving to our network via FTP (filter3).
config webfilter profile
edit "webfilter-file-filter"
config file-filter
set status enable <-- Allow user to disable/enable file
filtering
set log enable <-- Allow user to disable/enable logging for
file filtering
set scan-archive-contents enable <-- Allow scanning of files inside archives
such as ZIP, RAR etc.
config entries
edit "filter1"
set comment "Block PDF files"
set protocol http ftp <-- Inspect HTTP and FTP traffic
set action block <-- Block file once file type is matched
set direction any <-- Inspect both incoming and outgoing traffic
set encryption any <-- Inspect both encrypted and un-encrypted
files
set file-type "pdf" <-- Choosing the file type to match
next
edit "filter2"
set comment "Log graphics files"
set protocol http <-- Inspect only HTTP traffic
set action log <-- Log file once file type is matched
set direction incoming <-- Only inspect incoming traffic
set encryption any
set file-type "jpeg" "png" "gif" <-- Multiple file types can be configured
in a single entry
next
edit "filter3"
set comment "Block upload of EXE files"
set protocol ftp <-- Inspect only FTP traffic
set action log
set direction outgoing <-- Inspect only outgoing traffic
set encryption any
set file-type "exe"
next
end
end
end
After configuring File Filter in Web Filter profile we must apply it to a firewall policy using the following command:
config firewall policy
edit 1
set name "client-to-internet"
set srcintf "dmz"
set dstintf "wan1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set utm-inspection-mode proxy
set logtraffic all
set webfilter profile "webfilter-filefilter"
set profile-protocol-options "protocol"
set ssl-ssh-profile "protocols"
set nat enable
next
end
Log Example
FortiOS 6.2 provides command line tools to view the Web Filter statistics report. These command line tools currently fall
into either proxy-based or flow-based Web Filter statistics commands.
l The proxy-based Web Filter statistics command line tools are as follows. These commands are available in both
global or per-VDOM command lines.
#diagnose wad filter <----define the interested objects for output
(global) # diag wad ?
console-log Send WAD log messages to the console.
debug Debug setting.
stats Show statistics.
filter Filter for listing sessions or tunnels. <----use filter to filter-out
interested object and output
kxp SSL KXP diagnostics.
user User diagnostics.
memory WAD memory diagnostics.
restore Restore configuration defaults.
history Statistics history.
session Session diagnostics.
tunnel Tunnel diagnostics.
webcache Web cache statistics.
worker Worker diagnostics.
csvc Cache service diagnostics.
#diagnose wad stat filter list/clear <----list/clear Web Filter/DLP statistics report
l In the example below, there are two VDOMs using proxy-based policies which have Web Filter profiles enabled.
The command line can be used to view the proxy-based Web Filter statistics report.
(global) # diag wad filter ?
list Display current filter.
clear Erase current filter settings.
src Source address range to filter by.
dst Destination address range to filter by.
sport Source port range to filter by.
dport Destination port range to filter by.
vd Virtual Domain Name. <----filter for per-vdom or global
statistics report
explicit-policy Index of explicit-policy. -1 matches all.
firewall-policy Index of firewall-policy. -1 matches all.
drop-unknown-session Enable drop message unknown sessions.
negate Negate the specified filter parameter.
protocol Select protocols to filter by.
l The flow-based Web Filter statistics command line tools are as follows. These commands are available in global
command lines only.
(global) # diag test app ipsmonitor
l In the example below, there are two VDOMs using flow-based policies which have Web Filter profiles enabled. The
command line can be used to view the flow-based Web Filter statistics report.
(global) # diag test app ipsmonitor 29
Global URLF states:
Profile override
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 for days, hours, or minutes. 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
When you enter an IP address in the administrative override method, only individual IP
addresses are allowed.
This example describes how to override a webfilter profile with a webfilter_new profile.
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.
Ask feature
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 greyed
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.
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 greyed 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.
3. Under the Category Usage Quota section, toggle on Allow users to override blocked categories.
5. Click OK.
DNS Filter
Most people who use the Internet use domain names. For example, people who access the Fortinet website type
www.fortinet.com into their web browser. However, on the Internet, all websites, computers, or devices actually use IP
addresses to locate the destination.
Internet uses DNS (Domain Name System) to translate domain names into IP addresses. For example, when you type
www.fortinet.com into your web browser, DNS maps this domain name to Fortinet's IP address to locate the Fortinet
website on the Internet.
If you cannot see DNS Filter under Security Profiles, go to System > Feature Visibility > Security Features section
and enable DNS Filter.
DNS primarily uses the UDP protocol on port 53 to serve the address resolve requests.
The FortiGate DNS Filter inspects the UDP protocol on port 53 traffic that traverse FortiGate, and based on the DNS
Filter profile configuration, makes the Allow/Monitor/Block or Redirect decision for the inspected traffic.
FortiGate DNS Filter has the following features:
l FortiGuard Filtering: filtering the DNS request based on the domain's FortiGuard rating.
l Botnet C&C Domain Blocking: block the DNS request for the known Botnet C&C domains.
l External Dynamic Category Domain Filtering: define your own domain category.
l DNS Safe Search: Enforce Google, Bing, and YouTube safe addresses for parental controls.
l Local Domain Filter: define your own domain list to block or allow.
l External IP Block List: define your IP block list to block resolved IPs that match this list.
l DNS Translation: map the resolved result to another IP you define.
Sample topology
The topics in this section use the following sample topology to explain how these DNS Filter features work and how to
configure it. In this sample topology, there is an internal network and a FortiGate used as a gateway device, with all
DNS traffic traversing the FortiGate.
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 redirect-portal6 ::
set youtube-restrict strict
next
end
After you have created the DNS Filter profile, you can apply it to the policy. DNS filters also support IPv6 policies.
The FortiGate must have a FortiGuard Web Filter license to use FortiGuard Category Based
Filter.
You can use the FortiGuard category-based DNS Domain Filter to inspect DNS traffic. This makes use of FortiGuard's
continually updated domain rating database for more reliable protection.
1. Go to Security Profiles > DNS Filter and edit or create a DNS Filter.
2. Enable FortiGuard Category Based Filter.
3. Select the category and then select Allow, Monitor, or Block for that category.
Sample
To see an example of how this works, from your internal network PC, use a command line tool such as dig or nslookup
to do 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.
com. 20027 IN NS c.gtld-servers.net.
com. 20027 IN NS b.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 to view the DNS traffic that just traverse the FortiGate and the FortiGuard rating
for this domain name.
FortiGuard Service continually updates the Botnet C&C domain list (Domain DB). 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 edit or create a DNS Filter.
2. Enable Redirect botnet C&C requests to Block Portal.
3. Click the botnet package link to see the latest botnet C&C domain list.
Sample
To see an example of how this works, select a botnet domain from that list. Then from your internal network PC, use a
command line tool such as dig or nslookup to send a DNS query to traverse the FortiGate to see the query blocked as a
botnet domain. 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 <<<==== botnet domain query
blocked, redirect with portal-IP.
;; Received 43 B
;; Time 2019-04-05 09:55:21 PDT
;; From 172.16.95.16@53(UDP) in 0.3 ms
1. Go to Log & Report > DNS Query to view the DNS query blocked as a botnet domain.
FortiGate also maintains a botnet C&C IP address database (botnet IPDB). If a DNS query response IP address
(resolved IP address) matches an entry inside the botnet IPDB, this DNS query is also blocked by DNS Filter botnet C&C
blocking.
To see an example of how DNS Filter botnet C&C IPDB blocking works, select an IP address from the IPDB list and use
Internet reverse lookup service to find its corresponding domain name. Then from your internal network PC, use a
command line tool such as dig or nslookup to query this domain and see that it's blocked by DNS Filter botnet C&C
blocking. 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 <<<==== Since resolved
IP address match the botnet IPDB, dns query blocked with redirect portal IP.
;; Received 64 B
;; Time 2019-04-05 11:06:47 PDT
;; From 172.16.95.16@53(UDP) in 0.6 ms
1. Go to Log & Report > DNS Query to view the DNS query blocked by botnet C&C IPDB blocking.
Introduction
External Resources is a new feature introduced in FortiOS 6.0. It provides a capability to dynamically import an external
blacklist into an HTTP server. This feature enables FortiGate to retrieve a dynamic URL/Domain Name/IP
Address/Malware hash list from an external HTTP server periodically. FortiGate uses these external resources as 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 and address type. Domain type resources
file is a domain name list and address type resources file is an IP address list.
When a domain type external resource is configured, it is treated as a Remote Category in 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
DNS resolved IP address in DNS response matches the entry in the external-ip-blocklist, this DNS Query is blocked by
DNS Filter.
You can use CLI to configure External Resources files in an external HTTP server. Under Global, configure the External
Resources file location and specify the resource type. DNS Filter can use domain type and address type external
resources.
In the following example, configure a file "Ext-Resource-Type-as-Domain-1.txt" as type domain and it will be treated in
DNS Filter as Remote Category name as "Ext-Resource-Type-as-Domain-1" and category-id 194. Configure another
external resource file "Ext-Resource-Type-as-Address-1.txt" as type address, and this address object name is "Ext-
Resource-Type-as-Address-1":
config system external-resource
edit "Ext-Resource-Type-as-Domain-1"
set type domain <<<====
set category 194 <<<====
set resource "http://172.16.200.66/external-resources/Ext-Resource-Type-as-Domain-1.txt"
set refresh-rate 1
next
edit "Ext-Resource-Type-as-Address-1"
set status enable
set type address <<<====
set username ''
set password
set comments ''
set resource "http://172.16.200.66/external-resources/Ext-Resource-Type-as-Address-
1.txt"
set refresh-rate 1
next
end
In each VDOM, domain type external resource can be used in DNS Filter as Remote Category. In the above example,
Domain Name list in "Ext-Resource-Type-as-Domain-1.txt" file is treated as remote category (category-id 194). IP
address list in "Ext-Resource-Type-as-Address-1.txt" file can be applied in DNS Filter as external-ip-blocklist. If DNS
resolved IP address matches any entry in the list in that file, the DNS query is blocked. You should configure the action
for this remote category and enable "external-ip-block-list" in a DNS Filter profile and apply it in the policy:
config dnsfilter profile
edit "default"
set comment "Default dns filtering."
config ftgd-dns
config filters
edit 1
set category 194 <<<==== domain list in Ext-Resource-Type-as-Domain-1.txt
To configure, edit, or view the entries for external resources from GUI:
2. Click Create New and in the Threat Feeds section, select Domain Name or IP Address.
3. Enter the Resource Name, URL, location of the resource file, resource authentication credentials, and Refresh
Rate; and click OK to finish the Threat Feeds configuration.
4. When the configuration is complete, double-click the Threat Feeds Object you just configured to open the Edit
page; then click View Entries to view the entry list in the external resources file.
5. Go to VDOM > 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 Example
Remote categories
In VDOM > Log & Report > DNS Query, some domains that match the Remote Category list are rated as Remote
Category, overriding their original domain rating.
CLI Example:
External-IP-Block-Lists
You can use Address Type external resources as external-ip-blocklist in DNS Filter Profile. If DNS Query resolved IP
Address matches the entry in the external-ip-blocklist, this DNS query is blocked.
CLI Example:
Enable DNS Filter safe search so that FortiGate responds with the search engine's children and school safe domain or
IP address. Users might not be aware of this filter. Explicit contents are filtered by the search engine itself. This feature
isn’t 100% accurate but it can help you avoid explicit and inappropriate search results.
This feature currently supports Google, Bing, and YouTube.
1. Go to Security Profiles > DNS Filter and edit or create a DNS Filter.
2. Enable Enforce 'Safe search' on Google, Bing, YouTube.
3. For Restrict YouTube Access, select Strict or Moderate.
Sample
To see an example of how this works, enable this option. Then from your internal network PC, use a command line tool
such as dig or nslookup to do 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 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.
Check the DNS Filter log for the message DNS Safe Search enforced.
Additional information
For each search engine's safe search specifications, see its specification page:
l https://help.bing.microsoft.com/#apex/18/en-US/10003/0
l https://support.google.com/websearch/answer/510?co=GENIE.Platform%3DDesktop&hl=en
l https://support.google.com/youtube/answer/174084?co=GENIE.Platform%3DDesktop&hl=en
In addition to FortiGuard's category-based domain filter, you can also can define your own local static domain filter to
allow or block specific domains.
1. Go to Security Profiles > DNS Filter and edit or create a DNS Filter.
2. In the Static Domain Filter section, enable Domain Filter.
1. Go to Log & Report > DNS Query to view the DNS query log.
Since the local domain list "google" action is Monitor, it's blocked by FortiGuard category-based domain filter.
In DNS Filter, local domain filter has a higher priority than FortiGuard category-based domain filter.
A DNS query is scanned and matched with local domain filter first. If an entry matches and the local filter entry's action
is block, then that DNS query is blocked or redirected.
If 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, this query is blocked or redirected. If the FortiGuard category-based filter has
no match, then the original resolved IP address is returned to the client DNS resolver.
The local domain filter action can be Block, Allow, or Monitor. If the local domain filter action is Allow and an entry
matches, it will skip the FortiGuard category-based domain filter and directly return to client DNS resolver. If the local
domain filter action is Monitor and an entry matches, it will go to FortiGuard category-based domain filter scanning and
matching.
DNS translation
Using this feature, you can 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 1.2.3.4. However, when your internal network users visit this website, you
want them to connect to an internal host, say, 192.168.3.4. In this case, 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 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.
Example
This example configuration forces the DNS Filter profile to translate 93.184.216.34 (www.example.com) to
192.168.3.4. When internal network users do 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 edit or create a DNS Filter profile.
2. Enable DNS Translation and click Create New.
3. Enter the Original Destination (the domain's original IP address), the Translated Destination IP address, and the
Network Mask, and set Status to Enable.
4. Click OK.
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 <<<==== resolved IP translated
into 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
;; 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
1) AND src(Orginal IP) with negative netmask (93.184.216.34 & ~255.255.224.0)
01011101.10111000.11011000.00100010 93.184.216.34 <-- ip
00000000.00000000.00011111.11111111 ~255.255.224.0 <-- ~netmask
-------------------------------------------------------- &
00000000.00000000.00011000.00100010 0.0.24.34 <- right bits
You can configure and use FortiGate as a DNS server in your network. When you enable DNS Service on a specific
interface, FortiGate will listen for DNS Service on that interface.
Depending on the configuration, DNS Service on FortiGate can work in three modes: Recursive, Non-Recursive, or
Forward to System DNS (server). For details on how to configure DNS Service on FortiGate, see the FortiGate System
Configuration Guide.
You can apply a DNS Filter profile to Recursive Mode and Forward to System DNS Mode. This is the same as FortiGate
working as a transparent DNS Proxy for DNS relay traffic.
The Recursive and Non-Recursive Mode is available only after you configure the DNS database.
Sample configuration
In this example, FortiGate port 10 is enabled as a DNS Service with the DNS Filter profile "demo". Suppose port 10 has
an IP address 10.1.100.5 and DNS Filter profile "demo" is set to block category 52 (Information Technology), then from
your internal network PC, use a command line tool such as dig or nslookup to do a DNS query. For example:
# dig @10.1.100.5 www.fortinet.com <<<====Specify FortiGate interface address as DNS Server
;; ->>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 <<<==== DNS Filter profile
will filter the relay DNS traffic based on profile configuration. It blocked with redirect
portal IP
;; Received 50 B
;; Time 2019-04-08 14:36:34 PDT
;; From 10.1.100.5@53(UDP) in 13.6 ms
If you have trouble with the DNS Filter profile in your policy, start with the following troubleshooting steps:
l Check the connection between FortiGate and FortiGuard DNS rating server (SDNS server).
l Check that FortiGate has a valid FortiGuard Web Filter license.
l Check the FortiGate DNS Filter configuration.
Ensure FortiGate can connect to the FortiGuard SDNS server. By default, FortiGate uses UDP port 53 to connect to the
SDNS server.
To check the connection between FortiGate and the SDNS server in the CLI:
1. In the CLI Console, run the command diagnose test application dnsproxy 3 to find the FortiGuard
SDNS server.
worker idx: 0
vdom: root, index=0, is master, vdom dns is disabled, mip-169.254.0.1 dns_log=1
dns64 is disabled
2. Check the FDG_SERVER line. The SDNS server IP address might be different depending on location. For this
example, it is:
FDG_SERVER:208.91.112.220:53
3. In the CLI Console under the management VDOM, run the command execute ping 208.91.112.220 to
check the communication between the FortiGate and the SDNS server.
4. Optionally, you can also check the communication using a PC on the internal network.
a. Disable the DNS Filter profile so that it does not affect your connection check.
b. Ping your ISP or a public DNS service provides's DNS server, for example, Google's public DNS server of
8.8.8.8:
#dig @8.8.8.8 www.fortinet.com
c. Check that you can get domain www.fortinet.com A record from the DNS server which shows that 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 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.
1. In the CLI Console, run the command diagnose test application dnsproxy 3.
2. Look for the LICENSE line and check that the license has not expired, for example:
LICENSE: expiry=2029-08-21, expired=0, type=2
3. Check the dns-server lines. Some dns-server lines show secure=1 ready=1. These lines show the
functioning SDNS servers. For example:
dns-server:208.91.112.220:53 tz=-480 req=7 to=0 res=7 rt=1 secure=1 ready=1 timer=0 probe=0
failure=0 last_failed=0
1. Create a local domain filter and set the Action to Redirect to Block Portal.
See Local domain filter on page 584.
2. Apply this DNS Filter profile to the policy.
3. From the client PC, DNS query this domain.
If you get the profile's redirected portal address, that shows that the DNS Filter profile works as expected.
Use the following diagnose test application dnsproxy command line options to check DNS proxy status
and help with troubleshooting.
(global) # 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
Email filter
Email filtering
The FortiGate Email Filter can be configured to do antispam and file-type based filtering. To enable email filtering,
create a profile using either the CLI or GUI, then use this profile in the firewall policy.
l Local options: The FortiGate qualifies the email based on local conditions like BWL, bannedwords, or DNS checks
(with the use of FortiGuard service).
bannedword Content block.
spambwl Black/white list.
spamhelodns Email helo/ehlo domain DNS check.
spamraddrdns Email return address DNS check.
spamhdrcheck Email mime header check.
l FortiGuard-based options: The FortiGate qualifies the email based on score or verdict returned from the
FortiGuard service.
spamfsip Email IP address FortiGuard AntiSpam black list check.
spamfssubmit Add FortiGuard AntiSpam spam submission text.
spamfschksum Email checksum FortiGuard AntiSpam check.
spamfsurl Email content URL FortiGuard AntiSpam check.
spamfsphish Email content phishing URL FortiGuard AntiSpam check.
l Third-party options: The FortiGate qualifies the email based on information from a third-party source (like ORB
list).
spamrbl Email DNSBL & ORBL check.
Local and FortiGuard black/white lists can be enabled and combined in a single profile. When
combined, the Local black/white list has a higher priority than the FortiGuard's black list during
a decision making process.
For example: If a client's IP address is black listed in FortiGuard servers, but the admin wants
to override this decision and allow the IP to pass through the filter, they can define the
IP address or subnet in a BWL with the clear action. Because the information coming from the
Local BWL has a higher priority than the FortiGuard service, the email will be considered
clean.
Filtering types
Local-based:
l BWL, black or white list: These lists can be made from emails or IP subnets to forbid OR allow them to
sending/receiving emails.
When referring to the IP address or email listed under a black or white list, email refers to
the "From:" address, and IP refers to the IP address of the source of the email. In an
SMTP case, the IP refers to the client's IP address, while in a POP3 and IMAP case, it
refers to the server's IP address.
l Bannedwords: The admin can define a list of banned words. Emails that contain any of these banned words are
considered as spam.
l DNS check: With spamhelodns and spamraddrdns, 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.
FortiGuard-based:
l FortiGuard based options: FortiGate consults FortiGuard servers to help identify the spammers IP address or
emails, known phishing URLs, known spam URLs, known spam email checksums, etc.
Protocol tuning:
lProtocol tuning: In a profile, there are sections for SMTP, POP3, and IMAP. In each section, you can set an action
to either discard, tag, or pass the log for that protocol.
Webmail:
l Webmail detector: The email filter can also be configured to detect and log emails sent via Gmail and MSN-
Hotmail. Although these two interfaces do not use the standard email protocols (SMTP, POP3, or IMAP) and
instead use HTTPS, the email filter can still be configured to detect the emails sent and passed through the
FortiGate.
File-type:
l File-type based filtering: This can include emails which are undesired due to a file-type attachment that the
network admin qualifies as non-compatible with their business environment. The admin can define the undesired
file-types within the email filter profile and can associate an action to be taken for each file-type (for example: block
or log).
Both AntiSpam and file-type based filtering can be defined in a single profile, and will act
independent of one another.
Local-based filters
edit 1
.....
5. Enable the Email Filter option and select the profile previously created.
6. Set SSL Inspection to a profile that has deep SSL inspection enabled.
l Deep inspection is required if you intend to filter SMTP, POP3, IMAP, or any SSL/TLS encapsulated protocol.
end
set spam-filtering enable
set options bannedword
set spam-bword-table 1
next
end
FortiGuard-based filters
FortiGate consults FortiGuard servers to help identify the spammers IP address or emails, known phishing URLs, known
spam URLs, known spam email checksums, etc. FortiGuard servers have maintained databases that contain black lists
which are fed from Fortinet sensors and labs distributed all over the world.
l Spam Submission
File-type based email filters can be used to filter out emails which are undesired due to a file-type attachment that the
network admin qualifies as non-compatible with their business environment. The admin can define the undesired file-
types within the email filter profile and can associate an action to be taken for each file-type (for example: block or log).
3. Customize which files are scanned (Log/Scan Archived Contents) or click Create New to add a new entry.
In an email filtering profile, there are sections for SMTP, POP3, and IMAP protocols. In each section, you can set an
action to either discard, tag, or pass the log for that protocol.
CLI Example:
config smtp
set log enable
set action tag
end
MAPI is a proprietary protocol from Microsoft. It uses HTTPS to encapsulate email requests and responses between
Microsoft Outlook clients and Microsoft Exchange servers. The configuration of MAPI email filters are only possible
through the CLI.
Webmail
The FortiGate email filter is intended to filter standard email protocols including SMTP, POP3, IMAP, and MAPI,
however, it can also be configured to detect and log emails sent through some webmail interfaces. The supported
webmail interfaces include Gmail and MSN-Hotmail.
FortiGate can only detect and log webmail emails. It does not discard or tag these emails.
Introduction
File Filter is a new feature introduced in FortiOS 6.2, and provides the Email filter profile with the capability to block files
passing through a FortiGate based on file type. In addition, the configuration for file type filtering has been greatly
simplified. In previous FortiOS versions, File Filtering could only be achieved by configuring a DLP (Data Leak
Prevention) sensor.
In FortiOS 6.2, HTTP and FTP File Filtering is configurable in Web Filter profile, and SMTP, POP3, IMAP file-filtering is
configurable in Email filter profile. In this article we will discuss Email filter File Filtering.
Currently, File Filtering in Email filter profile is based on file type (file's meta data) only, and not on file size or file
content. Users will still need to configure a DLP sensor to block files based on size or content such as SSN numbers,
credit card numbers or regexp.
GUI configuration have yet to be implemented. In addition, Email filter File Filtering will only work on proxy mode
policies.
File Filter in Email filter profile supports the following file types:
xz Match xz files
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
Using CLI, configuration for File Filtering is nested inside Email filter profile's configuration.
In File filtering configuration, file filtering functionality and logging is independent of the Email filter profile.
To block or log a file type, we must configure file filter entries. Within each entry we can specify a file-type, action
(log|block), protocol to inspect (http|ftp), direction we want to inspect traffic (incoming|outgoing|any), and if we should
match only encrypted files. In addition, in each file filter entry we can specify multiple file types. File filter entries are
ordered, however, blocked will take precedence over log.
In the example CLI below we want to file filter the following using Email filter profile:
1. Block EXE files from received or sent out (filter1).
2. Log the sending of document files (filter2).
config emailfilter profile
edit "emailfilter-file-filter"
config file-filter
set status enable <--- Allow user to disable/enable file fil-
tering
set log enable <--- Allow user to disable/enable logging for
file filtering
set scan-archive-contents enable <--- Allow scanning of files inside archives
such as ZIP, RAR
config entries
edit "filter1"
set comment "Block executable files"
set protocol smtp imap pop3 <--- Inspect all email traffic
set action block <--- Block file once file type is matched
set encryption any <--- Inspect both encrypted and un-encrypted
files
set file-type "exe" <--- Choosing the file type to match
next
edit "filter2"
set comment "Log document files"
set protocol smtp <--- Inspect only SMTP traffic
set action log <--- Log file once file type is matched
set encryption any
set file-type "pdf" "msoffice" "msofficex" <--- Multiple file types can be con-
figured in a single entry
next
end
end
end
After configuring File Filter in Email filter profile, we must apply it to a firewall policy.
config firewall policy
edit 1
set name "client-to-internet"
set srcintf "port2"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
CLI Example:
The FortiGate Data Leak Prevention (DLP) system prevents sensitive data from leaving your network. Data matching
defined sensitive data patterns are blocked, logged, or allowed when passing through the FortiGate unit.
The DLP system is configured by creating individual filters based on file type, file size, a regular expression, an
advanced rule, or a compound rule in a DLP sensor, and assigning the sensor to a security policy.
A DLP sensor is made of filters that are configured within it. The filters examine traffic for:
l Known files used DLP Fingerprints
l Known files using DLP Watermark
l Files of a particular type
Filters are ordered, but there is no precedence between the possible actions
The primary use of the DLP feature is to stop sensitive data from the leaving the network. It can also be used to prevent
unwanted data from entering the network, and to archive some or all of the content that is passing through the
FortiGate device. DLP archiving is configured per filter, allowing for a single sensor that archives only the required data.
There are two forms of DLP archiving:
l Summary Only
A summary of all the activity that the sensor detected 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 that the sensor detects 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.
Basic filter types can be configured using the GUI or CLI and include:
l File type and name
l File size
l Regular expression
l Credit card and SSN
A file type filter allows you to block, allow, log, or quarantine based on the file type specified in the file filter list.
1. Create a file pattern to filter files based on the file name patter or file type:
config dlp filepattern
edit <filepatern_entry_integer>
set name <string>
config entries
edit <file pattern>
set filter-type <type | pattern>
set file-type <file type>
next
end
next
end
2. Attach the file pattern to a DLP sensor, and specify the protocols and actions:
config dlp sensor
edit <string>
config filter
edit <integer>
set name <string>
set proto <smtp | pop3 | imap | http-get | http-post | ftp | nntp | mapi>
set filter-by file-type
set file-type 11 <-- Previously configured filepattern
set action <allow | log-only| block | quarantine-ip>
next
end
next
end
3. Click Add Filter in the filter table. The New Filter pane opens.
4. Set Type to Files and select Specify File Types.
5. Add file types by clicking in the File Types field and select file types from the side pane.
6. Add file name patterns by clicking in the File Name Patterns field:
a. In the side pane that opens, enter the pattern in the search bar.
b. Click Create.
c. Select the newly created pattern.
File size
A file size filter checks for files that exceed the specific size, and performs the DLP sensor's configured action on them.
5. Enter the maximum file size, in kilobytes, in the File size over field, then click OK.
Regular expression
A regular expression filter is used to filter files or messages based on the configured regular expression pattern.
6. Enter the regular expression string in the Regular Expression field, then click OK.
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.
next
end
next
end
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.
Command Description
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.
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
wednesday | thursday | friday | saturday} is 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
Command Description
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
37, 0,
15, /fingerprint/upload/fingerprint90.txt, vdom1, 0, 0, 1498582679, 1, 2,
37, 0,
16, /fingerprint/upload/fo2.pdf, vdom1, 0, 0, 1450488049, 1, 2,
1, 0,
17, /fingerprint/upload/foo.doc, vdom1, 0, 0, 1388538131, 1, 2,
9, 0,
18, /fingerprint/upload/fortiauto.pdf, vdom1, 0, 0, 1356118251, 1, 2,
146, 0,
19, /fingerprint/upload/image.out, vdom1, 0, 0, 1531802940, 1, 2,
5410, 0,
20, /fingerprint/upload/jon_file.txt, vdom1, 0, 0, 1536596091, 1, 2,
1, 0,
21, /fingerprint/upload/machotest, vdom1, 0, 0, 1528751955, 1, 2,
19, 0,
22, /fingerprint/upload/nntp-server.doc, vdom1, 0, 0, 1356118250, 1, 2,
17, 0,
23, /fingerprint/upload/notepad++.exe, vdom1, 0, 0, 1456090734, 1, 2,
1061, 0,
24, /fingerprint/upload/nppIExplorerShell.exe, vdom1, 0, 0, 1438559930, 1,
2, 5, 0,
25, /fingerprint/upload/NppShell_06.dll, vdom1, 0, 0, 1456090736, 1, 2,
111, 0,
26, /fingerprint/upload/PowerCollections.chm, vdom1, 0, 0, 1533336889, 1,
2, 728, 0,
27, /fingerprint/upload/reflector.dmg, vdom1, 0, 0, 1533336857, 1, 2,
21117, 0,
28, /fingerprint/upload/roxio.iso, vdom1, 0, 0, 1517531765, 1, 2,
49251,0,
29, /fingerprint/upload/SciLexer.dll, vdom1, 0, 0, 1456090736, 1, 2,
541, 0,
30, /fingerprint/upload/screen.jpg, vdom1, 0, 0, 1356118250, 1, 2,
55, 0,
31, /fingerprint/upload/Spec to integrate FASE into FortiOS.doc, vdom1, 0, 0,
1356118251, 1, 2, 31, 0,
32, /fingerprint/upload/subdirectory1/subdirectory2/subdirectory3/hibun.aea, vdom1, 0,
0, 1529019743, 1, 2, 1, 0,
33, /fingerprint/upload/test.pdf, vdom1, 0, 0, 1356118250, 1, 2,
5, 0,
34, /fingerprint/upload/test.tar, vdom1, 0, 0, 1356118251, 1, 2,
3, 0,
35, /fingerprint/upload/test.tar.gz, vdom1, 0, 0, 1356118250, 1, 2,
1, 0,
36, /fingerprint/upload/test1.txt, vdom1, 0, 0, 1540317547, 1, 2,
1, 0,
37, /fingerprint/upload/thousand-files.zip, vdom1, 0, 0, 1536611774, 1, 2,
241, 0,
38, /fingerprint/upload/Thumbs.db, vdom1, 0, 0, 1445878135, 1, 2,
3, 0,
39, /fingerprint/upload/widget.pdf, vdom1, 0, 0, 1356118251, 1, 2,
18, 0,
40, /fingerprint/upload/xx00-xx01.tar, vdom1, 0, 0, 1356118250, 1, 2,
5, 0,
41, /fingerprint/upload/xx02-xx03.tar.gz, vdom1, 0, 0, 1356118251, 1, 2,
1, 0,
DLP watermarking
Watermarking marks files with a digital pattern to designate them as proprietary to a specific company. A small pattern
is added to the file that is recognized by the DLP watermark filter, but is invisible to the end user (except for text files).
FortiExplorer client, or a Linux-based command line tool, can be used to add a watermark to the following file types:
l .txt
l .doc and .docx
l .pdf
l .ppt and .pptx
l .xls and .xlsx
The following information is covered in this section:
l Watermarking a file with FortiExplorer.
l Watermarking a file with the Linux tool.
l Configuring a DLP sensor to detect watermarked files.
FortiExplorer
In this example, a watermark will be added to small text file. The content of the file is:
This is to show how DLP watermarking is done using FortiExplorer.
The watermark pattern is visible in text files. For all other supported file types, it is
invisible.
A Linux-based command line tool can be used to watermark files. The tool can be executed is a Linux environment by
passing in files or directories of files.
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.
Because of this method, flow mode inspection cannot be as thorough as proxy mode inspection and will have some
feature limitations. For example, flow mode inspection determines a file’s size by identifying the file size information in
the protocol exchange. If a file’s size is not present in the protocol exchange, the file’s size cannot be identified. The
flow-based policy will automatically block or pass the file (based on the configuration) despite the file meeting the file
size requirements.
The objective of flow-based policy is to optimize performance and increase throughput. Although it is not as thorough as
a proxy-based policy, flow mode inspection is still very reliable.
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 has
finished the inspection, the payload is either released to the destination (if traffic is clean) or dropped and replaced with
a replacement message (if 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, client comforting can be applied, which 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.
The following table shows which UTM profile can be configured on a flow mode or proxy mode inspection policy.
Remember that some UTM profiles are hidden in the GUI, but can be configured by using the FortiOS CLI.
4. Some Email filter features are not supported in Flow mode inspection. See Inspection mode differences for Email
Filter on page 627.
5. Some Web Filter features are not supported in Flow mode inspection. See Inspection mode differences for Web
Filter on page 628.
This section identifies the behavioral differences between Antivirus operating in flow and proxy inspection.
The following table indicates which Antivirus features are supported by their designated scan modes.
*IPS Engine caches the URL and a replacement message will be presented after the second attempt.
Flow Full Mode Yes Yes No Yes (1) Yes Yes (2)
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 protocols can be inspected by the designated antivirus scan modes.
* Proxy mode antivirus inspection on CIFS protocol has the following limitations:
Flow Quick mode uses a separate pre-filtering database for malware detection as opposed to the full AV signature
database that Flow Full and Proxy mode inspection use.
Proxy mode uses pre-scanning and stream-based scanning for HTTP traffic. This allows archive files that exceed the
oversize limit to be uncompressed and scanned for infections.
This section identifies the behavioral differences between Data Leak Prevention (DLP) operating in flow and proxy
inspection.
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 will only work if file size is present in the protocol exchange.
The following table indicates which protocols can be inspected by DLP based on the specified inspection modes.
This section identifies the behavioral differences between Email Filter operating in flow and proxy inspection.
The following table indicates which Email Filters are supported by their designated inspection modes.
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
This section identifies the behavioral differences between Web Filter operating in flow and proxy inspection.
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.
Because proxy mode provides the most thorough inspection, it is recommended that you apply proxy inspection to
policies where preventing a data leak or malicious content is critical.
The following scenarios demonstrate common use cases for proxy inspection.
Scenario 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. We 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. On this
policy, we will apply the virus filter, DLP filter, Web Filter, and email filter all operating in proxy mode.
Scenario 2
You have a corporate mail server in your domain, which 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 us to most reliably filter out any malware and spam emails received by the
mail servers via SMTP or MAPI. The IPS sensor can be used to prevent DOS attacks on the mail servers.
It is recommended that flow inspection is applied to policies that prioritize traffic throughput, such as allowing
connections to be made towards a streaming or file server.
You have an application server which accepts connections from users for the 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. We will apply an IPS sensor to this policy to
protect the server from external DOS attacks.
SSL Inspection
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 header information of the packets.
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 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.
If you do not know which port is used in the HTTPS web server, you can select Inspect All Ports.
The default setting in the certificate-inspection profile is to block invalid certificates and allow untrusted certificates.
For example, the server certificate has expired but you still want to access this server until you have a new server
certificate. But because certificate inspection cannot do an exemption, you have to allow the invalid certificate in your
SSL profile. This means you need to create a new certificate inspection profile using the built-in read-only certificate-
inspection.
Deep inspection
You typically apply deep inspection to outbound policies where destinations are unknown. You can configure address
and web category white lists 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.
If you do not want to apply deep inspection for privacy or other reasons, you can exempt the session by address,
category, or white list.
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.
If you want to exempt commonly trusted web sites, you can bypass the SSL white list in the SSL/SSH profile. The white
list includes common web sites trusted by FortiGuard. Simply enable Reputable Websites.
You typically use the FortiGate Protecting SSL Server profile as an inbound policy for clients on the Internet accessing
the server on the internal side of the FortiGate.
Protecting SSL Server uses a server certificate to protect a single server.
If you do not want a client in the Internet accessing your internal server directly and you want FortiGate to simulate your
real server, you can use Protecting SSL Server.
To upload a server certificate into FortiGate and use that certificate in the SSL/SSH Inspection Profile:
When you apply this Protecting SSL Server profile in a policy, FortiGate will send the server certificate to the client as
your server does.
The FortiClient EMS FSSO connector allows objects to be defined in FortiOS that map to tags and groups on EMS.
EMS dynamically updates these endpoint groups when host compliance or other events occur, causing FortiOS to
dynamically adjust its security policies based on the group definitions.
EMS supports creating compliance verification rules based on various criteria (see Provisioning on EMS on page 645).
When a FortiClient endpoint registers to EMS, EMS dynamically groups them based on these rules. FortiOS can receive
the dynamic endpoint groups from EMS as tags via the FSSO protocol using an FSSO agent that supports SSL and
imports trusted certificates.
After FortiOS pulls the tags from EMS, they can be used as members in user groups that can have dynamic firewall
policies applied to them. When an event occur, EMS sends an update to FortiOS, and the dynamic policies are updated.
The following instructions assume EMS is installed, configured, and has endpoints connected. For information on
configuring EMS, see the FortiClient EMS Administration Guide.
The following steps provide an example of configuring a dynamic policy:
1. Add a compliance verification rule in EMS on page 637
2. Configure an EMS FSSO agent on page 638
3. Configure user groups on page 639
4. Create a dynamic firewall policy on page 640
This example creates a compliance verification rule that applies to endpoints that have Windows 10 installed.
For more information see Compliance verification in the FortiClient EMS Administration Guide.
8. In the Tag endpoint as dropdown list, select an existing tag or enter a new tag. In this example, a new tag, WIN10_
EMS134, is created. EMS uses this tag to dynamically group together endpoints that satisfy the rule, as well as any
other rules that are configured to use this tag.
9. Click Save.
10. Go to Compliance Verification > Host Tag Monitor. All endpoints that have Windows 10 installed are shown
grouped by the WIN10_EMS134 tag.
In this example, the FSSO agent name is EMS_FSSO_connector, and the EMS server is located at 172.18.64.7.
4. Fill in the Name, and Primary FSSO Agent server IP address or name and Password.
5. Set the User Group Source to Collector Agent.
User groups will be pushed to the FortiGate from the collector agent. Click Apply & Refresh to fetch group filters
from the collector agent.
6. Click OK.
In this example, the user group is named ems_QA_group, and includes six dynamic endpoint groups that were pulled
from EMS as members.
7. Click OK.
You can now create a dynamic firewall policy for the user group. In this example, an IPv4 policy is created for the user
group.
To create a dynamic firewall policy for the user group in the GUI:
5. Click OK.
6. Go to Policy & Objects > IPv4 Policy to ensure the policy was created and applied to the desired user group.
FortiOS will update this policy when it receives updates from EMS.
To create a dynamic firewall policy for the user group in the CLI:
Diagnostics
2.2.2.1, JONATHANWONG
type: fsso, id: 0, duration: 18955, idled: 18955
server: ems_QA_connector
packets: in 0 out 0, bytes: in 0 out 0
10.1.100.111, FRANK111
type: fsso, id: 0, duration: 18955, idled: 18955
server: ems_QA_connector
packets: in 0 out 0, bytes: in 0 out 0
group_id: 5
group_name: ems_QA_group
10.1.100.120, FRANK
type: fsso, id: 0, duration: 18955, idled: 4
server: ems_QA_connector
packets: in 10643 out 11379, bytes: in 6014568 out 3224342
group_id: 5
group_name: ems_QA_group
10.1.100.141, ADMINISTRATOR
type: fsso, id: 0, duration: 18955, idled: 1
server: ems_QA_connector
packets: in 9669 out 10433, bytes: in 5043948 out 2823319
group_id: 5
group_name: ems_QA_group
...
...
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 Traffic matches a firewall policy that displays an in-browser warning to install
FortiClient installed. FortiClient from the provided link.
Endpoint has FortiClient Traffic matches a dynamic firewall policy which allows the endpoint to reach its
installed, registered to EMS, and destination via this policy.
connected to the FortiGate.
Endpoint is deregistered from Traffic matches another dynamic firewall policy that displays warning to register
EMS and disconnected from the FortiClient to EMS.
FortiGate.
7. Click Save.
8. Repeat steps 2-6 for each policy that requires a custom disclaimer message.
next
edit 4
set name "44"
set uuid 686ea2ca-348d-51e9-9dca-b2b4b4aabbe2
set srcintf "port12"
set dstintf "port11"
set srcaddr "all"
set dstaddr "pc5-address"
set action accept
set schedule "always"
set service "ALL"
set wsso disable
set groups "ems_03_group"
set disclaimer enable
set replacemsg-override-group "test2"
set nat enable
next
edit 6
set name "66"
set uuid f1034e52-36d5-51e9-fbae-da21922ccd10
set srcintf "port12"
set dstintf "port11"
set srcaddr "all"
set dstaddr "all"
set status disable
set schedule "always"
set service "ALL"
set logtraffic all
set fsso disable
set block-notification enable
set replacemsg-override-group "endpoint-override"
next
end
Provisioning on EMS
The rules are pulled by the FortiGate as TAGs, using the FSSO protocol. The FortiGate uses the TAGs as members in
user groups, and applies them to dynamic firewall policies to perform authentication.
For information about FortiClient EMS, see the FortiClient EMS Administration Guide.
3. Configure telemetry gateway lists, which are also used in endpoint policies.
4. Configure endpoint policies, which assign endpoint profiles, gateways, and groups.
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. Look in the FortiGate Cloud widget. This widget displays 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. Under License Information > FortiSandbox Cloud, click Activate.
The FortiSandbox Cloud license is linked to your antivirus license, so they will expire at the
same time.
l 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.
1. Go to Security Fabric > Settings.
2. In the Sandbox Inspection section, click FortiSandbox Cloud.
3. Select a region from the FortiSandbox cloud region dropdown.
The following regions are available:
l Europe
l Global
l Japan
l US
4. Click Apply.
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 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.
This recipe provides sample configuration of site-to-site IPsec VPN in an HA environment. You must enable two options
to ensure IPsec VPN traffic does not interrupt during an HA failover:
l session-pickup under HA settings
l ha-sync-esp-seqno under IPsec phase1-interface settings
The following shows the sample network topology for this recipe:
You can configure IPsec VPN in an HA environment using the FortiOS GUI or CLI.
In this examples below, 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 the 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
8. Run diagnose commands. These diagnose commands are useful to check IPsec phase1/phase2 interface
statuses, including the sequence number on the secondary FortiGate. The diagnose debug application
ike -1 command is the key to figure out why the IPsec tunnel failed to establish.
a. Run the HQ1 # diagnose vpn ike gateway list command. 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
This recipe provides sample configuration of using OSPF with IPsec VPN to achieve network redundancy. Route
selection is based on OSPF cost calculation. It is easy to achieve ECMP or primary/secondary routes by adjusting OSPF
path cost.
The following shows the sample network topology for this recipe:
As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the
CLI commands as shown below.
To configure OSPF with IPsec VPN to achieve network redundancy using the CLI:
1. Configure the WAN interface and static route. Each FortiGate has two WAN interfaces connected to different ISPs.
The ISP1 link is for the primary FortiGate and the IPS2 link is for the secondary FortiGate:
a. Configure HQ1:
config system interface
edit "port1"
set alias to_ISP1
set ip 172.16.200.1 255.255.255.0
next
edit "port2"
set alias to_ISP2
set ip 172.17.200.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.200.3
set device "port1"
next
edit 2
set gateway 172.17.200.3
set device "port2"
set priority 100
next
end
b. Configure HQ2:
config system interface
edit "port25"
set alias to_ISP1
set ip 172.16.202.1 255.255.255.0
next
edit "port26"
set alias to_ISP2
set ip 172.17.202.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.202.2
set device "port25"
next
edit 2
set gateway 172.17.202.2
set device "port26"
set priority 100
next
end
2. Configure the internal (protected subnet) interface:
a. Configure HQ1:
config system interface
edit "dmz"
set ip 10.1.100.1 255.255.255.0
next
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
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 172.17.200.1
set psksecret sample2
next
end
config vpn ipsec phase2-interface
edit "pri_HQ1"
set phase1name "pri_HQ1"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
next
edit "sec_HQ1"
set phase1name "sec_HQ1"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
set auto-negotiate enable
next
end
4. Configure an inbound and outbound firewall policy for each IPsec tunnel:
a. Configure HQ1:
config firewall policy
edit 1
set name "pri_inbound"
set srcintf "pri_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 "pri_outbound"
set srcintf "dmz"
set dstintf "pri_HQ2"
set srcaddr "10.1.100.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 3
set name "sec_inbound"
set srcintf "sec_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 4
set name "sec_outbound"
set srcintf "dmz"
set dstintf "sec_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 "pri_inbound"
set srcintf "pri_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 "pri_outbound"
set srcintf "port9"
set dstintf "pri_HQ1"
set srcaddr "10.1.100.0"
set dstaddr "172.16.101.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 3
set name "sec_inbound"
set srcintf "sec_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 4
set name "sec_outbound"
set srcintf "port9"
set dstintf "sec_HQ1"
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
7. Run diagnose/get commands to check VPN and OSPF states:
a. 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
e. Run the HQ1 # get router info routing-table ospf command. The system should return the
following:
Routing table for VRF=0
O 172.16.101.0/24 [110/110] via 10.10.11.2, sec_HQ2 , 00:00:01
The recipe gives a sample configuration of using IPsec aggregate to achieve redundancy and traffic load-balancing:
l Multiple site-to-site IPsec VPN (net-device disable) tunnel interfaces as member of ipsec-aggregate
l Four load-balancing algorithms: round-robin (default), L3, L4, redundant
The following shows the sample network topology for this recipe:
As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the
CLI commands as shown below.
To configure IPsec aggregate to achieve redundancy and traffic load-balancing using the CLI:
1. Configure the WAN interface and static route. Each FortiGate has two WAN interfaces connected to different ISPs.
The ISP1 link is for the primary FortiGate and the IPS2 link is for the secondary FortiGate:
a. Configure HQ1:
config system interface
edit "port1"
set alias to_ISP1
set ip 172.16.200.1 255.255.255.0
next
edit "port2"
set alias to_ISP2
set ip 172.17.200.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.200.3
set device "port1"
next
edit 2
set gateway 172.17.200.3
set device "port2"
set priority 100
next
end
b. Configure HQ2:
config system interface
edit "port25"
next
end
5. Configure the firewall policy:
a. Configure HQ1:
config firewall policy
edit 1
set name "inbound"
set srcintf "agg_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 "agg_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 "agg_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 "agg_HQ1"
set srcaddr "172.16.101.0"
set dstaddr "10.1.100.0"
set action accept
set schedule "always"
set service "ALL"
next
end
6. Assign an IP address to the ipsec-aggregate interface. In this example, OSPF runs over the ipsec-
aggregate interface. No IP address is required for the static route HQ1:
a. Configure HQ1:
config system interface
edit "agg_HQ2"
set ip 10.10.10.1 255.255.255.255
This recipe provides 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.
The following shows the sample network topology for this recipe:
As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the
CLI commands as shown below.
To configure redundant hub and spoke VPN using the FortiOS CLI:
edit "hub"
set type dynamic
set interface "port13"
set peertype any
set net-device enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set dpd on-idle
set psksecret sample
set dpd-retryinterval 60
next
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"
set ip 172.16.200.3 255.255.255.0
next
edit "wan2"
set mode dhcp
set distance 10
set priority 100
next
edit "lan1"
set ip 192.168.4.1 255.255.255.0
next
end
config router static
edit 1
set gateway 172.16.200.2
set device "wan1"
next
end
b. Configure IPsec phase1-interface and phase2-interface:
i. Configure Spoke1:
config vpn ipsec phase1-interface
edit "primary"
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 sample
next
edit "secondary"
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 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 10.1.100.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 10.1.100.0 255.255.255.0
next
end
ii. Configure Spoke2:
config vpn ipsec phase1-interface
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"
set service "ALL"
next
end
d. Configure the static route:
i. Configure Spoke1:
config router static
edit 3
set dst 172.16.101.0 255.255.255.0
set distance 1
set device "primary"
next
edit 4
set dst 172.16.101.0 255.255.255.0
set distance 3
set device "secondary"
next
end
ii. Configure Spoke2:
config router static
edit 3
set dst 172.16.101.0 255.255.255.0
set distance 1
set device "primary"
next
edit 4
set dst 172.16.101.0 255.255.255.0
set distance 3
set device "secondary"
next
end
3. Run diagnose and get commands:
a. Run the Spoke1 # diagnose vpn tunnel list command. The system should return the following:
name=primary 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-rfc accept_traffic=1
proxyid_num=1 child_num=0 refcnt=15 ilast=0 olast=0 ad=/0
stat: rxp=1879 txp=1881 rxb=225480 txb=112860
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=1
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=primary proto=0 sa=1 ref=2 serial=2 auto-negotiate
src: 0:10.1.100.0/255.255.255.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=41002/0B replaywin=2048
seqno=758 esn=0 replaywin_lastseq=00000758 itn=0
life: type=01 bytes=0/0 timeout=42901/43200 dec: spi=0908732f esp=aes key=16
20770dfe67ea22dd8ec32c44d84ef4d5
With this feature, you can create a static aggregate interface using IPsec tunnels as members, with traffic load balanced
between the members. An IP address can be assigned to the aggregate interface, dynamic routing can run on the
interface, and the interface can be a member interface in SD-WAN.
The supported load balancing algorithms are: L3, L4, round-robin (default), and redundant.
Dialup VPN
This recipe provides 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.
The following shows the sample network topology for this recipe:
You can configure dialup IPsec VPN with FortiGate as the dialup client using the GUI or CLI.
To configure IPsec VPN with FortiClient as the dialup client in the GUI:
To configure IPsec VPN with FortiClient as the dialup client using the CLI:
1. In the CLI, configure the user, user group, and firewall address by running the following commands. Only the
HQ dialup server FortiGate needs this configuration. The address is an IP pool to assign an IP address for the
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 the 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:
4. Configure the IPsec phase1-interface. In this example, PSK is used as the authentication method. Signature
authentication is also an option:
a. Configure the HQ FortiGate:
config vpn ipsec phase1-interface
edit "for_Branch"
set type dynamic
set interface "wan1"
set mode aggressive
set peertype any
set mode-cfg enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set add-route disable
set dpd on-idle
set xauthtype auto
set authusrgrp "vpngroup"
set net-device enable
set assign-ip-from name
set dns-mode auto
set ipv4-split-include "10.1.100.0"
set ipv4-name "client_range"
set save-password enable
set psksecret sample
set dpd-retryinterval 60
next
end
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"
8. Run diagnose commands. These diagnose commands are useful to check the IPsec phase1/phase2 interface
status. The diagnose debug application ike -1 command is the key to figure out 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
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
addr: 173.1.1.1:500 -> 11.101.1.1:500
created: 2016s ago
assigned IPv4 address: 10.10.10.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: 93 5b1c59fab2029e43/bf517e686d3943d2
direction: initiator
status: established 2016-2016s ago = 0ms
proposal: aes128-sha256
key: 8046488e92499247-fbbb4f6dfa4952d0
lifetime/rekey: 86400/84083
DPD sent/recv: 00000000/00000020
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
This recipe provides sample configuration of dialup IPsec VPN with FortiClient as the dialup client.
The following shows the sample network topology for this recipe:
You can configure dialup IPsec VPN with FortiClient as the dialup client using the GUI or CLI.
To configure IPsec VPN with FortiClient as the dialup client on the GUI:
1. Go to VPN > IPsec Wizard and configure the following settings for VPN Setup:
a. Enter a proper VPN name.
b. For Template Type, choose Remote Access.
c. For Remote Device Type, select Client-based > FortiClient.
d. Click Next.
2. Configure the following settings for Authentication:
a. For Incoming Interface, select wan1.
b. For Authentication Method, select Pre-shared Key.
c. In the Pre-shared Key field, enter your-psk as the key.
d. From the User Group dropdown list, select vpngroup.
e. Click Next.
3. Configure the following settings for Policy & Routing:
a. From the Local Interface dropdown menu, select lan.
b. Configure the Local Address as local_network.
c. Configure the Client Address Range as 10.10.2.1-10.10.2.200.
d. Keep the default values for the Subnet Mask, DNS Server, Enable IPv4 Split tunnel, and Allow Endpoint
Registration options.
e. Click Create.
To configure IPsec VPN with FortiClient as the dialup client using the CLI:
1. In the CLI, configure the user and group by running the following commands:
config user local
edit "vpnuser1"
set type password
set passwd your-password
next
end
config user group
edit "vpngroup"
set member "vpnuser1"
next
end
2. Configure the internal interface. The LAN interface connects to the corporate internal network. Traffic from this
interface will route out the IPsec VPN tunnel. Creating an address group for the protected network behind this
FortiGate will cause 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
3. Configure the WAN interface. The WAN interface is the interface connected to the ISP. It can work in static mode
(as shown in the 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.
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 any
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"
set dstaddr "local_network"
set action accept
set schedule "always"
set service "ALL"
next
end
8. Configure FortiClient. In this example, FortiClient (Windows) 6.0.3 build 0155 is used:
a. In FortiClient, go to Remote Access and select Add a new connection.
b. Set the Type to IPsec VPN and the Remote Gateway to the FortiGate IP address.
c. Set the Authentication Method to Pre-Shared Key and enter the key. Click Save.
d. Select the VPN, enter the username and password, then select Connect.
9. Run diagnose commands. These diagnose commands are useful to check the IPsec phase1/phase2 interface
status. The diagnose debug application ike -1 command is the key to figure out why the IPsec tunnel
failed to establish.
a. 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
b. 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
proxyid=for_client proto=0 sa=1 ref=2 serial=1 add-route
src: 0:0.0.0.0-255.255.255.255:0
dst: 0:10.10.1.1-10.10.1.1:0
SA: ref=4 options=2a6 type=00 soft=0 mtu=1422 expire=42867/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000001 itn=0
life: type=01 bytes=0/0 timeout=43189/43200
dec: spi=36274d14 esp=aes key=16 e518b84b3c3b667b79f2e61c64a225a6
ah=sha1 key=20 9cceaa544ed042fda800c4fe5d3fd9d8b811984a
enc: spi=8b154deb esp=aes key=16 9d50f004b45c122e4e9fb7af085c457c
ah=sha1 key=20 f1d90b2a311049e23be34967008239637b50a328
dec:pkts/bytes=1/16330, enc:pkts/bytes=0/0
npu_flag=02 npu_rgwy=172.20.120.254 npu_lgwy=172.20.120.123npu_selid=0 dec_npuid=2 enc_
npuid=0
This recipe provides sample configuration of dialup IPsec VPN with an iPhone or iPad as the dialup client.
The following shows the sample network topology for this recipe:
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 proper VPN name.
b. For Template Type, choose 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.
c. In the Pre-shared Key field, enter your-psk as the key.
d. From the User Group dropdown list, select vpngroup.
e. Deselect Require 'Group Name' on VPN client.
f. Click Next.
3. Configure the following settings for Policy & Routing:
a. From the Local Interface dropdown menu, select lan.
b. Configure the Local Address as local_network.
c. Configure the Client Address Range as 10.10.2.1-10.10.2.200.
d. Keep the default values for the Subnet Mask, DNS Server, and Enable IPv4 Split tunnel options.
e. Click Create.
To configure IPsec VPN with an iOS device as the dialup client using the CLI:
1. In the CLI, configure the user and group by running the following commands:
config user local
edit "vpnuser1"
set type password
set passwd your-password
next
end
config user group
edit "vpngroup"
set member "vpnuser1"
next
end
2. Configure the internal interface. The LAN interface connects to the corporate internal network. Traffic from this
interface will route out the IPsec VPN tunnel. Creating an address group for the protected network behind this
FortiGate will cause 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
3. Configure the WAN interface. The WAN interface is the interface connected to the ISP. It can work in static mode
(as shown in the 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.
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
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
natt: mode=keepalive draft=32 interval=10 remote_port=64916
proxyid=for_ios_p1 proto=0 sa=1 ref=2 serial=1 add-route
src: 0:10.10.111.0-10.10.111.255:0 dst: 0:10.10.2.1-10.10.2.1:0 SA: ref=3 options=a7
type=00 soft=0 mtu=1422 expire=3564/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000000 itn=0
life: type=01 bytes=0/0 timeout=3587/3600 dec: spi=36274d15 esp=aes key=32
5a599d796f8114c83d6589284f036fc33bdf4456541e2154b4ac2217b6aec869
ah=sha1 key=20 f1efdeb77d6f856a8dd3a30cbc23cb0f8a3e0340
enc: spi=00b0d9ab esp=aes key=32
e9232d7a1c4f390fd09f8409c2d85f80362d940c08c73f245908ab1ac3af322f
ah=sha1 key=20 a3890d6c5320756291cad85026d3a78fd42a1b42
ADVPN
This recipe provides 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.
The following shows the sample network topology for this recipe:
As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the
CLI commands as shown below.
To configure ADVPN with BGP 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
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
aes256gcm chacha20poly1305
set auto-negotiate enable
next
end
4. Run diagnose and get commands to check VPN and BGP states. All following commands should be run on
Spoke1:
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:
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, 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
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
proxyid=spoke1 proto=0 sa=1 ref=5 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=447/0B replaywin=1024
seqno=65 esn=0 replaywin_lastseq=00000002 itn=0
life: type=01 bytes=0/0 timeout=2368/2400
dec: spi=c53a8f5c esp=aes key=16 73fd9869547475db78851e6c057ad9b7
ah=sha1 key=20 6ad3a5b1028f6b33c82ba494a370f13c7f462635
enc: spi=79cb0f2b esp=aes key=16 52ab0acdc830d58c00e5956a6484654a
ah=sha1 key=20 baa82aba4106dc60618f6fe95570728656799239
dec:pkts/bytes=1/46, enc:pkts/bytes=100/11568
npu_flag=03 npu_rgwy=13.1.1.2 npu_lgwy=15.1.1.2 npu_selid=5 dec_npuid=1 enc_npuid=1
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 recipe provides 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.
The following shows the sample network topology for this recipe:
As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the
CLI commands as shown below.
To configure ADVPN with OSPF 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 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
aes256gcm chacha20poly1305
set auto-negotiate enable
next
end
4. Run diagnose and get commands to check VPN and OSPF states. All following commands should be run on
Spoke1:
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:
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=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
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 recipe provides 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.
The following shows the sample network topology for this recipe:
As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the
CLI commands as shown below.
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
next
end
4. Run diagnose and get commands. All following commands should be run on Spoke1:
a. Run the diagnose vpn tunnel list command on Spoke1. The system should return the following:
list all ipsec tunnel in vd 0
----
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
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:
Routing table for VRF=0
R 172.16.101.0/24 [120/2] via 10.10.10.254, spoke1, 00:09:04
R 192.168.4.0/24 [120/2] via 10.10.10.3, spoke1_0, 00:00:02
This topic provides an example configuration of full mesh Overlay Controller VPN (OCVPN).
OCVPN is a cloud based solution to simplify IPsec VPN setup. When Overlay Controller VPN 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 by
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.
Full mesh IPsec tunnels are established between all 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
Restrictions
Terminology
Poll-interval Used to define how often FortiGate tries to fetch OCVPN-related data from
OCVPN Cloud.
Role Used to specify the device OCVPN role of spoke, primary-hub, or secondary-hub.
Subnet Internal network subnet (IPsec protected subnet). Traffic source from or
destination to this subnet will enter IPsec tunnel encrypted by IPsec SA.
Sample Topology
The following shows an example of three FortiGate units registered on FortiCare by using the same FortiCare account.
Each FortiGate unit has one internal subnet, and no NAT exists between these three FortiGate units.
Sample configuration
The steps below use the following overlays and subnets for the sample configuration:
l Branch1:
l Overlay name: QA. Local subnets: 10.1.100.0/24
l Overlay name: PM. Local subnets: 10.2.100.0/24
l Branch2:
l Overlay name: QA. Local interfaces: lan1
l Overlay name: PM. Local interfaces: lan2
l Branch3:
l Overlay name: QA. Local subnets: 172.16.101.0/24
l Overlay name: PM. Local subnets: 172.16.102.0/24
Before you begin, ensure all FortiGates are registered on FortiCare.
2. Create the first overlay by setting the following options and clicking OK:
a. Beside Status, click Enabled.
b. Beside Role, click Spoke.
c. In the Overlays section, click Create New to create a network overlay.
d. In the Name box, type a name, and input the subnets and/or choose internal interfaces.
The local subnet must be routable, and interfaces must have assigned IP addresses. Otherwise an error
message displays.
3. Repeat this procedure until you create all the needed overlays.
3. Configure Branch2:
config vpn ocvpn
set status enable
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
4. Configure Branch3:
config vpn ocvpn
set status enable
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 "OM"
config subnets
edit 1
set subnet 172.16.102.0 255.255.255.0
next
end
next
end
end
This topic provides 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
Prerequisites
Restrictions
l Primary hub
l Secondary hub
l Spoke (OCVPN default role)
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 Overlay name: PM. Local subnets: 172.16.102.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 Overlay name: PM. Local subnets: 10.2.100.0/24
l Spoke2:
l Overlay name: QA. Local interfaces lan1
l Overlay name: PM. Local interfaces lan2
Before you begin, ensure all FortiGates are registered on FortiCare.
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 provides 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.
License
Prerequisites
Restrictions
l Primary-hub
l Secondary-hub
l Spoke (OCVPN default role)
Sample configuration
1. Configure the Primary-Hub, enable overlay QA, and configure assign-ip and IP range:
config vpn ocvpn
set status enable
OCVPN portal
After 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.
OCVPN troubleshooting
This document includes troubleshooting steps for the following OCVPN network topologies:
l Full mesh.
l Hub-spoke with ADVPN shortcut.
l Hub-spoke with inter-overlay source NAT.
For OCVPN configurations in different network topologies, please refer to 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
l Simulate the primary hub being unavailable where all spoke's 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
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
.................................
Authentication in VPN
This recipe provides sample configuration of IPsec VPN authenticating a remote FortiGate peer with a pre-shared key.
The following shows the sample network topology for this recipe:
You can configure IPsec VPN authenticating a remote FortiGate peer with a pre-shared key using the GUI or CLI.
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"
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"
7. Run diagnose commands. The diagnose debug application ike -1 command is the key to figure out
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 recipe provides 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.
The following shows the sample network topology for this recipe:
You can configure IPsec VPN authenticating a remote FortiGate peer with a pre-shared key using the GUI or CLI.
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"
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
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
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
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.1.00.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 figure out
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:
established 7-7s ago = 70ms proposal: aes128-sha256 key: 4aa06dbee359a4c7-
43570710864bcf7b lifetime/rekey: 86400/86092 DPD sent/recv: 00000000/00000000 peer-id:
C = CA, ST = BC, L = Burnaby, O = Fortinet, OU = QA, CN = test2
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 recipe provides an example configuration of VXLAN over IPsec tunnel. VXLAN encapsulation is used in the
phase1-interface setting and virtual-switch is used to bridge the internal with VXLAN over IPsec tunnel.
The following shows the network topology for this example:
b. HQ2:
config system interface
edit "port25"
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
b. HQ2:
config vpn ipsec phase1-interface
edit "to_HQ1"
set interface "port25"
set peertype any
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set encapsulation VXLAN
set encapsulation-address ipv4
set encap-local-gw4 172.16.202.1
set encap-remote-gw4 172.16.200.1
set remote-gw 172.16.200.1
set psksecret sample
next
end
config vpn ipsec phase2-interface
edit "to_HQ1"
set phase1name "to_HQ1"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
next
end
b. HQ2:
config firewall policy
edit 1
set srcintf "port9"
set dstintf "to_HQ1"
set srcaddr "10.1.100.0"
set dstaddr "10.1.100.0"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set srcintf "to_HQ1"
set dstintf "port9"
set srcaddr "10.1.100.0"
set dstaddr "10.1.100.0"
set action accept
set schedule "always"
set service "ALL"
next
end
b. HQ2:
config system switch-interface
edit "VXLAN-HQ1"
set member "port9" "to_HQ1"
set intra-switch-policy explicit
next
end
5. Optionally, view the VPN tunnel list on HQ1 with the diagnose vpn tunnel list command:
list all ipsec tunnel in vd 0
----
name=to_HQ2 ver=1 serial=2 172.16.200.1:0->172.16.202.1:0
bound_if=5 lgwy=static/1 tun=intf/0 mode=auto/1 encap=VXLAN/2 options[0002]=
encap-addr: 172.16.200.1->172.16.202.1
proxyid_num=1 child_num=0 refcnt=11 ilast=8 olast=0 ad=/0
stat: rxp=13 txp=3693 rxb=5512 txb=224900
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=45
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=to_HQ2 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=3 options=10226 type=00 soft=0 mtu=1390 expire=41944/0B replaywin=2048
seqno=e6e esn=0 replaywin_lastseq=0000000e itn=0
life: type=01 bytes=0/0 timeout=42901/43200
dec: spi=635e9bb1 esp=aes key=16 c8a374905ef9156e66504195f46a650c
ah=sha1 key=20 a09265de7d3b0620b45441fb5af44dab125f2afe
enc: spi=a4d0cd1e esp=aes key=16 e9d0f3f0bb7e15a833f80c42615a3b91
ah=sha1 key=20 609a315c385471b8909b771c76e4fa7214996e50
dec:pkts/bytes=13/4640, enc:pkts/bytes=3693/623240
6. Optionally, view the bridge control interface on HQ1 with the diagnose netlink brctl name host
VXLAN-HQ1 command:
show bridge control interface VXLAN-HQ1 host.
fdb: size=2048, used=17, num=17, depth=1
Bridge VXLAN-a host table
port no device devname mac addr ttl attributes
1 1. dmz 00:0c:29:4e:33:c9 1. Hit(1)
1 1. dmz 00:0c:29:a8:c3:ea 105 Hit(105)
1 1. dmz 90:6c:ac:53:76:29 18 Hit(18)
1 1. dmz 08:5b:0e:dd:69:cb 1. Local Static
1 1. dmz 90:6c:ac:84:3e:5d 1. Hit(5)
1 1. dmz 00:0b:fd:eb:21:d6 1. Hit(0)
2 38 to_HQ2 56:45:c3:3f:57:b4 1. Local Static
1 1. dmz 00:0c:29:d2:66:40 78 Hit(78)
2 38 to_HQ2 90:6c:ac:5b:a6:eb 124 Hit(124)
1 1. dmz 00:0c:29:a6:bc:e6 19 Hit(19)
1 1. dmz 00:0c:29:f0:a2:e7 1. Hit(0)
1 1. dmz 00:0c:29:d6:c4:66 164 Hit(164)
1 1. dmz 00:0c:29:e7:68:19 1. Hit(0)
1 1. dmz 00:0c:29:bf:79:30 19 Hit(19)
1 1. dmz 00:0c:29:e0:64:7d 1. Hit(0)
1 1. dmz 36:ea:c7:30:c0:f1 25 Hit(25)
1 1. dmz 36:ea:c7:30:cc:71 1. Hit(0)
This example is intended for network engineers who are familiar with the FortiGate platform. It does not include all of
the required configuration steps. The intention is to provide the information that you need to implement VXLAN over
IPsec VPN using a VXLAN Tunnel Endpoint (VTEP).
This example covers a VXLAN over IPsec VPN configuration using the FortiGate as the VTEP. There is also an
alternative configuration method that directly encapsulates traffic in IPsec VPN without creating a VXLAN interface.
This example shows a specific configuration that uses a hub-and-spoke topology. However, the same logic can be
applied to a static VPN. In this example's hub-and-spoke topology, dialup VPN is convenient as it uses a single phase 1
dialup definition on the hub FortiGate, with additional spoke tunnels being added without any changes to the hub other
than adding a user account for each additional spoke.
This example consists of the following steps:
1. Configure IPsec VPN
2. Configure a VXLAN interface
3. Bind the VXLAN interface to the Ethernet port
4. Test the configuration
1. Configure the phase 1 and phase 2 interfaces on the hub and spoke FortiGates:
a. Run the following CLI commands on the hub FortiGate:
config vpn ipsec phase1-interface
edit "SPOKES"
set type dynamic
set interface "port2"
set mode aggressive
set peertype one
set proposal aes256-sha256
set xauthtype auto
set authusrgrp "SPOKES"
set peerid "SPOKES"
set psksecret <SECRET>
next
end
config vpn ipsec phase2-interface
edit "SPOKES"
set phase1name "SPOKES"
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm
aes256gcm chacha20poly1305
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.
2. Configure the IPsec VPN policies on the hub and spoke FortiGates:
a. Run the following CLI commands on the hub FortiGate. This policy allows VXLAN traffic between spokes,
since spoke-to-spoke traffic is done through the hub:
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
b. Run the following commands on the spoke FortiGates. Usually, a tunnel interface is required for the IPsec
VPN to establish a policy. In this example, the FortiGate issues the VXLAN tunnel, which ends at the remote
FortiGate's tunnel interface. This explicitly removes the requirement for allowing VXLAN traffic. This explains
how such a policy can be created:
config firewall policy
edit 1
set name "FICTIVE_IPSEC_POLICY"
set srcintf "HUB"
set dstintf "HUB"
set srcaddr "none"
set dstaddr "none"
set action accept
set schedule "always"
set service "PING"
set logtraffic disable
set fsso disable
next
end
3. Configure the IPsec tunnel interfaces. IPsec tunnel interfaces are used to support VXLAN tunnel termination.
Therefore, you must set an IP address for each tunnel interface. You should also allow ping access for
troubleshooting purposes:
a. Run the following CLI commands on the hub FortiGate. The remote IP address is not used, but 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
You must create a VXLAN interface and bind it to IPsec tunnel 1. All VXLAN interfaces share the same VXLAN Network
ID (VNI).
1. Run the following CLI commands on the hub FortiGate. The remote IP address is the spokes' tunnel interfaces' IP
addresses.
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
2. Run the following CLI commands on the spoke FortiGates. The remote IP address is the hub's tunnel interface's IP
address.
config system VXLAN
edit "HUB_VXLAN"
set interface "HUB"
set vni 1
set remote-ip "192.168.255.1"
next
end
You can add another spoke's tunnel IP address to establish a VXLAN tunnel between spokes. For example, to add
another spoke's tunnel IP address to the above example, the set remote-ip command would be set
remote-ip "192.168.255.1" "192.168.255.3".
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 in the future. Otherwise, you must delete the reference (the policy in this case)
before adding remote IP addresses.
VXLAN encapsulates OSI layer 2 Ethernet frames within layer 3 IP packets. This is why you must bind the internal port
and VXLAN interface so that devices behind port1 have direct layer 2 access to remote peers over the VXLAN tunnel.
You can accomplish this using one of the following methods:
l Using a switch interface
l Using a virtual wire pair
Both methods are explained below.
To use a switch interface, run the following commands on the hub FortiGate:
config system switch-interface
edit "SW"
set vdom "root"
set member "port1" "SPOKES_VXLAN"
next
end
To use a virtual wire pair, run the following command on the spoke FortiGates:
The virtual wire pair needs an explicit policy to allow traffic between interfaces:
1. Ping the hub FortiGate from the spoke FortiGate. The output should look as follows:
user@pc-spoke1:~$ ping 192.168.1.1 -c 3PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.24 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.672 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.855 ms
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.672/0.923/1.243/0.239 ms
<<<<1
15:00:01.438256 SPOKES_VXLAN in 192.168.1.2 -> 192.168.1.1: icmp: echo request
<<<<2
15:00:01.438260 port1 out 192.168.1.2 -> 192.168.1.1: icmp: echo request
<<<<3
15:00:01.438532 port1 in 192.168.1.1 -> 192.168.1.2: icmp: echo reply
15:00:01.438536 SPOKES_VXLAN out 192.168.1.1 -> 192.168.1.2: icmp: echo reply
15:00:01.438546 SPOKES out 192.168.255.1.4851 -> 192.168.255.2.4789: udp 106
Troubleshooting
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
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 : 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.
This recipe provides an example configuration of tunneled internet browsing using a dialup VPN. To centralize network
management and control, all branch office traffic is tunneling to HQ, including Internet browsing.
The following shows the sample network topology for this example:
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
set schedule "always"
set service "ALL"
next
end
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
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
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. 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
seqno=802 esn=0 replaywin_lastseq=00000680 itn=0
life: type=01 bytes=0/0 timeout=42930/43200
dec: spi=e313ac46 esp=aes key=16 0dcb52642eed18b852b5c65a7dc62958
ah=md5 key=16 c61d9fe60242b9a30e60b1d01da77660
enc: spi=706ffe03 esp=aes key=16 6ad98c204fa70545dbf3d2e33fb7b529
ah=md5 key=16 dcc3b866da155ef73c0aba15ec530e2e
dec:pkts/bytes=1665/16352, enc:pkts/bytes=2051/16826
npu_flag=03 npu_rgwy=11.101.1.1 npu_lgwy=173.1.1.1 npu_selid=6 dec_npuid=2 enc_npuid=2
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 : 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 : 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.
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 : 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 : 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
set ipsec-hmac-offload disable
end
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 812d1178784c1130d1586606e44e1b9ab157e31a09ed-
bed583be1e9cc82e8c9f2655a2cf
ah=null key=0
enc: spi=706ffe0a esp=chacha20poly1305 key=36 f2727e001e2243549b140f1614ae3d-
f82243adb070e60c33911f461b389b05a7a642e11a
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.
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 : 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 nt 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.
This recipe provides an example configuration of GRE over an IPsec tunnel. A static route over GRE tunnel is used, and
tunnel-mode is used in the phase2-interface settings.
The following shows the network topology for this example:
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"
b. HQ2:
config router static
edit 2
set dst 10.1.100.0 255.255.255.0
set device "gre_to_HQ1"
next
end
8. Optionally, view the VPN tunnel list on HQ1 with the diagnose vpn tunnel list command:
list all ipsec tunnel in vd 0
----
name=greipsec ver=1 serial=1 172.16.200.1:0->172.16.202.1:0
bound_if=5 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/16 options[0010]=create_dev
proxyid_num=1 child_num=0 refcnt=12 ilast=19 olast=861 ad=/0
stat: rxp=347 txp=476 rxb=58296 txb=51408
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=8
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=greipsec proto=47 sa=1 ref=2 serial=2
src: 47:0.0.0.0/0.0.0.0:0
dst: 47:0.0.0.0/0.0.0.0:0
SA: ref=3 options=10226 type=00 soft=0 mtu=1438 expire=41689/0B replaywin=2048
seqno=15c esn=0 replaywin_lastseq=0000015c itn=0
life: type=01 bytes=0/0 timeout=42898/43200
dec: spi=9897bd09 esp=aes key=16 5a60e67bf68379309715bd83931680bf
ah=sha1 key=20 ff35a329056d0d506c0bfc17ef269978a4a57dd3
enc: spi=e362f336 esp=aes key=16 5574acd8587c5751a88950e1bf8fbf57
ah=sha1 key=20 d57ec76ac3c543ac89b2e4d0545518aa2d06669b
dec:pkts/bytes=347/37476, enc:pkts/bytes=347/58296
9. Optionally, view static routing table on HQ1 with the get router info routing-table static
command:
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 172.16.200.3, port1
S 172.16.101.0/24 [10/0] is directly connected, gre_to_HQ2
This recipe provides an example configuration of LT2P over IPsec. A locally defined user is used for authentication, a
Windows PC or Android tablet is acting as the client, and net-device is set to enable in the phase1-interface
settings. If net-device is set to disable, only one device can establish an L2TP over IPsec tunnel behind the same
NAT device.
The following shows the network topology for this example:
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
7. Optionally, view the VPN tunnel list on HQ with the diagnose vpn tunnel list command:
list all ipsec tunnel in vd 0
----
name=L2tpoIPsec_0 ver=1 serial=8 22.1.1.1:0->10.1.100.15:0
bound_if=4 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/216 options[00d8]=npu
create_dev no-sysctl rgwy-chg
parent=L2tpoIPsec index=0
proxyid_num=1 child_num=0 refcnt=13 ilast=0 olast=0 ad=/0
stat: rxp=470 txp=267 rxb=57192 txb=12679
dpd: mode=on-idle on=1 idle=60000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=L2tpoIPsec proto=17 sa=1 ref=3 serial=1 transport-mode add-route
src: 17:22.1.1.1-22.1.1.1:1701
dst: 17:10.1.100.15-10.1.100.15:0
SA: ref=3 options=1a6 type=00 soft=0 mtu=1470 expire=2339/0B replaywin=2048
seqno=10c esn=0 replaywin_lastseq=000001d6 itn=0
life: type=01 bytes=0/0 timeout=3585/3600
dec: spi=ca646443 esp=3des key=24 af62a0fffe85d3d534b5bfba29307aafc8bfda5c3f4650dc
ah=sha1 key=20 89b4b67688bed9be49fb86449bb83f8c8d8d7432
enc: spi=700d28a0 esp=3des key=24 5f68906eca8d37d853814188b9e29ac4913420a9c87362c9
ah=sha1 key=20 d37f901ffd0e6ee1e4fdccebc7fdcc7ad44f0a0a
dec:pkts/bytes=470/31698, enc:pkts/bytes=267/21744
npu_flag=00 npu_rgwy=10.1.100.15 npu_lgwy=22.1.1.1 npu_selid=6 dec_npuid=0 enc_npuid=0
----
name=L2tpoIPsec_1 ver=1 serial=a 22.1.1.1:4500->22.1.1.2:64916
bound_if=4 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/472 options[01d8]=npu
create_dev no-sysctl rgwy-chg rport-chg
parent=L2tpoIPsec index=1
proxyid_num=1 child_num=0 refcnt=17 ilast=2 olast=2 ad=/0
stat: rxp=5 txp=4 rxb=592 txb=249
dpd: mode=on-idle on=1 idle=60000ms retry=3 count=0 seqno=0
8. Optionally, view the L2TP VPN status, by enabling debug (diagnose debug enable), then using the
diagnose vpn l2tp status command:
----
----
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
----
2. Enter a name for the VPN in the Name field. In this example L2tpoIPsec is used.
3. Set the following, then click Next:
l Template Type to Remote Access
l Remote Device Type to Native and Windows Native
4. Set the following, then click Next:
l Incoming Interface to port9
l Authentication Method to Pre-shared Key
l Pre-shared Key to your-psk
l User Group to L2tpusergroup
5. Set the following, then click Create:
l Local Interface as port10
l Local Address as 172.16.101.0
l Client Address Range as 10.10.10.1-10.10.10.100
l Subnet Mask is left as its default value.
Encryption algorithms
This recipe provides a brief introduction to IPsec phase1 and phase2 encryption algorithms and includes the following
sections:
l IKEv1 phase1 encryption algorithm on page 804
l IKEv1 phase2 encryption algorithm on page 806
l IKEv2 phase1 encryption algorithm on page 808
l IKEv2 phase2 encryption algorithm on page 809
DES is a symmetric-key algorithm which means the same key is used for encrypting and decrypting data. FortiGate
supports:
l des-md5
l des-sha1
l des-sha256
l des-sha384
l des-sha512
3DES apply DES algorithm three times to each data. FortiGate 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 length: 128, 192, and 256 bits. FortiGate 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 length: 128, 192, and 256 bits. FortiGate 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. FortiGate supports:
l seed128-md5
l seed128-sha1
l seed128-sha256
l seed128-sha384
l seed128-sha512
Suite-B is a set of encryption algorithm, AES encryption with ICV in GCM mode. FortiGate 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. FortiGate supports:
l suite-b-gcm-128
l suite-b-gcm-256
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
In AESGCM encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiGate supports:
l aes128gcm
l aes256gcm
In chacha20poly1305 encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiGate supports:
l chacha20poly1305
In ARIA encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiGate 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
In SEED encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiGate 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. FortiGate
supports:
l des-md5
l des-sha1
l des-sha256
l des-sha384
l des-sha512
3DES apply DES algorithm three times to each data. FortiGate 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 length: 128, 192, and 256 bits. FortiGate 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 length: 128, 192, and 256 bits. FortiGate 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
In chacha20poly1305 encryption algorithm, FortiGate supports:
l chacha20poly1305-prfsha1
l chacha20poly1305-prfsha256
l chacha20poly1305-prfsha384
l chacha20poly1305-prfsha512
SEED is a symmetric-key algorithm. FortiGate supports:
l seed128-md5
l seed128-sha1
l seed128-sha256
l seed128-sha384
l seed128-sha512
Suite-B is a set of encryption algorithm, AES encryption with ICV in GCM mode. FortiGate 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. FortiGate supports:
l suite-b-gcm-128
l suite-b-gcm-256
l null-sha384
l null-sha512
In DES encryption algorithm, IPsec traffic can offload NPU/CP. FortiGate supports:
l des-null
l des-md5
l des-sha1
l des-sha256
l des-sha384
l des-sha512
In 3DES encryption algorithm, IPsec traffic can offload NPU/CP. FortiGate supports:
l 3des-null
l 3des-md5
l 3des-sha1
l 3des-sha256
l 3des-sha384
l 3des-sha512
In AES encryption algorithm, IPsec traffic can offload NPU/CP. FortiGate 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
In AESGCM encryption algorithm, IPsec traffic cannot offload NPU. CP9 supports AESGCM offloading. FortiGate
supports:
l aes128gcm
l aes256gcm
In chacha20poly1305 encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiGate supports:
l chacha20poly1305
In ARIA encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiGate 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
In SEED encryption algorithm, IPsec traffic cannot offload NPU/CP. FortiGate supports:
l seed-null
l seed-md5
l seed-sha1
l seed-sha256
l seed-sha384
l seed-sha512
This recipe provides an example configuration of policy-based IPsec tunnel. Site-to-site VPN between branch and HQ is
used and HQ is the IPsec concentrator.
c. Select the Source, Destination, Schedule, Service, and set Action to IPsec.
d. Select the VPN Tunnel, in this example, Branch1/Branch2.
e. In this example, turn on Allow traffic to be initiated from the remote site.
f. Click OK.
4. Configure IPsec VPN at branch 1:
a. Go to VPN > IPsec Wizard, enter a VPN name, (to_HQ in this example) choose Custom and then click Next.
l Uncheck Enable IPsec Interface Mode.
l Choose Static IP Address as Remote Gateway.
l Enter IP address, in this example, 22.1.1.1.
l Choose wan1 as interface.
l In this example, set Authentication Method to Pre-shared Key. In other cases, use the default.
l Click OK.
5. Configure the firewall policy:
a. Choose the Incoming Interface, in this example, internal.
b. Choose the Outgoing Interface, in this example, wan1.
c. Select the Source, Destination, Schedule, Service, and set Action to IPsec.
d. Select the VPN Tunnel, in this example, to_HQ.
e. In this example, turn on Allow traffic to be initiated from the remote site.
f. Click OK.
6. Configure IPsec VPN at branch 2:
a. Go to VPN > IPsec Wizard, enter a VPN name, (to_HQ in this example) choose Custom and then click Next.
l Uncheck Enable IPsec Interface Mode.
l Choose Static IP Address as Remote Gateway.
l Enter IP address, in this example, 22.1.1.1.
l Choose wan1 as interface.
l In this example, set Authentication Method to Pre-shared Key and the Pre-shared Key is sample. In
other cases, use the default.
l Click OK.
7. Configure the firewall policy:
a. Choose the Incoming Interface, in this example, internal.
b. Choose the Outgoing Interface, in this example, wan1.
c. Select the Source, Destination, Schedule, Service, and set Action to IPsec.
d. Select the VPN Tunnel, in this example, to_HQ.
e. In this example, turn on Allow traffic to be initiated from the remote site.
f. Click OK.
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
edit 2
set srcintf "port10"
set dstintf "port9"
set srcaddr "all"
set dstaddr "192.168.4.0"
set action ipsec
set schedule "always"
set service "ALL"
set inbound enable
set vpntunnel "to_branch2"
next
end
b. Branch2:
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. Branch2:
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. Branch2:
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
8. Optionally, view the IPsec VPN tunnel list at HQ with the diagnose vpn tunnel list command:
list all ipsec tunnel in vd 0
----
name=to_branch1 ver=1 serial=4 22.1.1.1:0->15.1.1.2:0
bound_if=42 lgwy=static/1 tun=tunnel/1 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=8 ilast=0 olast=0 ad=/0
stat: rxp=305409 txp=41985 rxb=47218630 txb=2130108
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_branch1 proto=0 sa=1 ref=3 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=42604/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000680 itn=0
life: type=01 bytes=0/0 timeout=42932/43200
dec: spi=ca646442 esp=aes key=16 58c91d4463968dddccc4fd97de90a4b8
ah=sha1 key=20 c9176fe2fbc82ef7e726be9ad4af83eb1b55580a
enc: spi=747c10c4 esp=aes key=16 7cf0f75b784f697bc7f6d8b4bb8a83c1
ah=sha1 key=20 cdddc376a86f5ca0149346604a59af07a33b11c5
dec:pkts/bytes=1664/16310, enc:pkts/bytes=0/16354
npu_flag=03 npu_rgwy=15.1.1.2 npu_lgwy=22.1.1.1 npu_selid=3 dec_npuid=2 enc_npuid=2
----
name=to_branch2 ver=1 serial=5 22.1.1.1:0->13.1.1.2:0
bound_if=42 lgwy=static/1 tun=tunnel/1 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=7 ilast=2 olast=43228 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_branch2 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=3 options=10226 type=00 soft=0 mtu=1280 expire=40489/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000000 itn=0
life: type=01 bytes=0/0 timeout=42931/43200
dec: spi=ca646441 esp=aes key=16 57ab680d29d4aad4e373579fb50e9909
ah=sha1 key=20 12a2bc703d2615d917ff544eaff75a6d2c17f1fe
enc: spi=f9cffb61 esp=aes key=16 3d64da9feb893874e007babce0229259
ah=sha1 key=20 f92a3ad5e56cb8e89c47af4dac10bf4b4bebff16
dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
npu_flag=00 npu_rgwy=13.1.1.2 npu_lgwy=22.1.1.1 npu_selid=4 dec_npuid=0 enc_npuid=0
9. Optionally, view the IPsec VPN concentrator at HQ with the diagnose vpn concentrator list command:
list all ipsec concentrator in vd 0
name=branch ref=3 tuns=2 flags=0
This topic provides a sample configuration of remote users accessing the corporate network through an SSL VPN by
web mode using a web browser.
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.
3. 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
1. Open browser and 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.
3. Go to VPN > Monitor > SSL-VPN Monitor to verify the list of SSL users.
4. Go to Log & Report > Traffic Log > Forward Traffic to view the details for the SSL entry.
This topic provides a sample configuration of remote users accessing the corporate network and internet through an
SSL VPN by tunnel mode using FortiClient.
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 internal interface and protected subnet, and connect port1 interface to 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 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 "all"
set groups “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
next
end
This topic provides 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 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.
d. Click OK.
e. Go to Firewall & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Configure user and user group.
a. Go to User & Device > User Definition to create a local user sslvpnuser1.
b. Go to User & Device > 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.
4. Configure SSL VPN settings.
a. Go to VPN > SSL-VPN Settings.
b. Choose proper Listen on Interface, in this example, wan1.
c. Listen on Port 10443.
d. Choose a certificate for Server Certificate. The default is Fortinet_Factory.
e. Under Authentication/Portal Mapping, set default Portal tunnel-access for All Other Users/Groups.
f. Create new Authentication/Portal Mapping for group sslvpngroup mapping portal my-split-tunnel-portal.
5. Configure SSL VPN firewall policy.
a. Go to Policy & Objects > IPv4 Policy.
b. Fill in the firewall policy name. In this example: sslvpn split tunnel access.
c. Incoming interface must be SSL-VPN tunnel interface(ssl.root).
d. Choose an Outgoing Interface. In this example: port1.
e. Set the source to all and group to sslvpngroup.
f. In this example, the destination is all.
g. Set schedule to always, service to ALL, and Action to Accept.
h. Click OK.
2. Configure internal interface and protected subnet. Then connect port1 interface to 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
This topic provides a sample configuration of remote users accessing the corporate network through an SSL VPN by
tunnel mode using FortiClient with AV host check.
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.
d. Click OK.
e. Go to Firewall & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Configure user and user group.
a. Go to User & Device > User Definition to create a local user sslvpnuser1.
b. Go to User & Device > User Groups to create a group sslvpngroup with the member sslvpnuser1.
3. SSL VPN web portal configuration.
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.
4. SSL VPN settings configuration.
a. Go to VPN > SSL-VPN Settings.
b. Choose proper Listen on Interface, in this example, wan1.
c. Listen on Port 10443.
d. Choose a certificate for Server Certificate. The default is Fortinet_Factory.
e. Under Authentication/Portal Mapping, set default Portal tunnel-access for All Other Users/Groups.
f. Create new Authentication/Portal Mapping for group sslvpngroup mapping portal my-split-tunnel-portal.
5. SSL VPN firewall policy configuration.
a. Go to Policy & Objects > IPv4 Policy.
b. Fill in the firewall policy name. In this example: sslvpn tunnel access with av check.
c. Incoming interface must be SSL-VPN tunnel interface(ssl.root).
d. Choose an Outgoing Interface. In this example: port1.
e. Set the source to all and group to sslvpngroup.
f. In this example, the destination is all.
g. Set schedule to always, service to ALL, and Action to Accept.
h. Click OK.
6. Configure SSL VPN web portal to enable AV host-check.
a. Open the CLI Console at the top right of the screen.
b. Enter the following commands 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
end
2. Configure internal interface and protected subnet. Then connect port1 interface to 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.
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
end
This sample recipe shows how to create a multi-realm SSL VPN that provides different portals for different user groups.
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.
f. Create new Authentication/Portal Mapping for group QA_group mapping portal qa-tunnel.
g. Specify realm with qa.
h. Add another entry for group HR_group mapping portal hr-web.
i. Specify realm with hr.
6. SSL VPN firewall policy configuration.
a. Go to Policy & Objects > IPv4 Policy.
b. Create a firewall policy for QA access.
c. Fill in the firewall policy name. In this example: QA sslvpn tunnel mode access.
d. Incoming interface must be SSL-VPN tunnel interface(ssl.root).
e. Choose an Outgoing Interface. In this example: port1.
f. Set the source to all and group to QA_group.
g. In this example, the destination is the internal protected subnet QA_subnet.
h. Set schedule to always, service to ALL, and Action to Accept.
i. Click OK.
j. Create a firewall policy for HR access.
k. Fill in the firewall policy name. In this example: HR sslvpn web mode access.
l. Incoming interface must be SSL-VPN tunnel interface(ssl.root).
m. Choose an Outgoing Interface. In this example: port1.
n. Set the source to all and group to HR_group.
o. In this example, the destination is the internal protected subnet HR_subnet.
p. Set schedule to always, service to ALL, and Action to Accept.
q. Click OK.
2. Configure internal interface and protected subnet, then connect port1 interface to 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
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
1. In a web browser, log into the portal https://172.20.120.123:10443/hr using the credentials you've set up to
connect to the SSL VPN tunnel.
2. Go to VPN > Monitor > SSL-VPN Monitor to verify the list of SSL users.
3. Go to Log & Report > Traffic Log > Forward Traffic and view the details of the traffic.
This topic provides a sample configuration of SSL VPN that requires users to authenticate using a certificate.
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.
l Ensure the subject matches the name of the user certificate. In this example, User01.
Now that you have created a PKI user, a new menu is added to the GUI.
a. Go to User & Device > PKI to see the new user.
b. Edit the user account and expand Two-factor authentication.
c. Enable Require two-factor authentication and set a Password for the account.
d. Go to User & Device > User > User Groups and create a group 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.
b. Choose proper Listen on Interface, in this example, wan1.
c. Listen on Port 10443.
d. Set Server Certificate to the authentication certificate.
e. Enable Require Client Certificate.
f. Under Authentication/Portal Mapping, set default Portal web-access for All Other Users/Groups.
g. Create new Authentication/Portal Mapping for group sslvpngroup mapping portal full-access.
7. Configure SSL VPN firewall policy.
a. Go to Policy & Objects > IPv4 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.
2. Configure internal interface and protected subnet., then connect port1 interface to 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 subnet192.168.1.0 255.255.255.0
next
end
set ca CA_Cert_1
set subject User01
set two-factor enable
set passwd <your-password>
end
config user group
edit "sslvpngroup"
set member "pki01"
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 “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
Sample 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.
1. Go to VPN > Monitor > SSL-VPN Monitor to verify the list of SSL users.
2. Go to Log & Report > VPN Events and view the details for the SSL connection log.
This topic provides 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 configuration
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 encrypting SSL VPN traffic and will be used for authentication.
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 the example, it is called CA_Cert_1.
Now that you have created a PKI user, a new menu is added to the GUI.
a. Go to User & Device > PKI to see the new user.
b. Go to User & Device > User > User Groups and create a group sslvpn-group.
c. Add the PKI peer object you created as a local member of the group.
d. Add a remote group on the LDAP server and select the group of interest.
You need these users to be members using the LDAP browser window.
4. 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.
5. Configure SSL VPN settings.
a. Go to VPN > SSL-VPN Settings.
b. Choose proper Listen on Interface, in this example, wan1.
c. Listen on Port 10443.
d. Set Server Certificate to the authentication certificate.
e. Enable Require Client Certificate.
f. Under Authentication/Portal Mapping, set default Portal web-access for All Other Users/Groups.
g. Create new Authentication/Portal Mapping for group sslvpn-group mapping portal full-access.
6. Configure SSL VPN firewall policy.
a. Go to Policy & Objects > IPv4 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 sslvpn-group.
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 port1 interface to 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"
edit 1
set groups "sslvpn-group"
set portal "full-access"
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 VPN > Monitor > SSL-VPN Monitor to verify the list of SSL users.
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 diag debug app 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 diag firewall auth list to validate that a firewall user entry exists for the SSL VPN user and
is part of the right groups.
This topic provides a sample configuration of SSL VPN that uses FortiToken Mobile Push two-factor authentication. If
you enable push notifications, the user can easily accept or deny the authentication request.
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 internal interface and protected subnet, then connect port1 interface to 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 subnet192.168.1.0 255.255.255.0
next
end
b. Every FortiGate has two free Mobile Tokens. You can download the free token.
execute fortitoken-mobile import 0000-0000-0000-0000-0000
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
set schedule "always"
set service "ALL"
set nat enable
next
end
1. From a remote device, open a web browser and 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 Monitor > SSL-VPN Monitor to confirm the user connection.
1. Go to VPN > Monitor > SSL-VPN Monitor to verify the user’s connection.
2. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
This topic provides a sample configuration of SSL VPN that uses FortiAuthenticator as a RADIUS authentication server.
Sample configuration
2. Configure internal interface and protected subnet, then connect port1 interface to 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 subnet192.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.
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, open a web browser and 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 Monitor > SSL-VPN Monitor to confirm the user connection.
1. Go to VPN > Monitor > SSL-VPN Monitor to verify the user’s connection.
2. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
This topic provides 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, the user can easily accept or
deny the authentication request.
Sample configuration
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 & Device > 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. Choose proper Listen on Interface, in this example, wan1.
c. Listen on Port 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 > IPv4 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 port1 interface to 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 subnet192.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.
config firewall policy
edit 1
set name "sslvpn web mode access"
1. From a remote device, open a web browser and 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 Monitor > SSL-VPN Monitor to confirm the user connection.
1. Go to VPN > Monitor > SSL-VPN Monitor to verify the user’s connection.
2. Go to Log & Report > Forward Traffic to view the details of the SSL VPN traffic.
This topic provides 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. When the
expiration time is reached, 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. When the
expiration time is reached, the user can still renew the password.
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.
d. Click OK.
e. Go to Firewall & Objects > Address and create an address for internet subnet 192.168.1.0.
2. Configure user and user group.
a. Go to User & Device > User Definition to create a local user.
b. Enter the user's Email Address.
c. If you want, enable Two-factor Authentication,
d. Click Next and click Submit.
e. Go to User & Device > 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 expiration 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 port1 interface to 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 subnet192.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, open a web browser and 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 expiration time is reached, the user cannot renew the password and must contact the
administrator.
In FortiOS 6.0/5.6, when the expiration time is reached, the user can still renew the password.
3. On the FortiGate, go to Monitor > SSL-VPN Monitor to confirm the user connection.
1. Go to VPN > Monitor > SSL-VPN Monitor 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 > VPN Events 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.
This topic provides 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 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 internal interface and protected subnet, then connect port1 interface to 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 subnet192.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
2. Configure internal interface and protected subnet, then connect port1 interface to 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 subnet192.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 “sslvpngroup”
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end
1. From a remote device, open a web browser and 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. Go to VPN > Monitor > SSL-VPN Monitor to verify the user’s connection.
1. Go to VPN > Monitor > SSL-VPN Monitor 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.
This topic provides 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 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 internal interface and protected subnet, then connect port1 interface to 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 subnet192.168.1.0 255.255.255.0
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, open a web browser and log into the SSL VPN web portal http://172.20.120.123:10443.
2. Log in using the ldu1 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. Go to VPN > Monitor > SSL-VPN Monitor to verify the user’s connection.
1. Go to VPN > Monitor > SSL-VPN Monitor 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.
Diagnose commands
Use the following diagnose commands to identify SSL VPN issues. These commands enable debugging of SSL VPN
with a debug level of -1. The -1 debug level produces 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
Common issues
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 Option > 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-pools SSLVPN_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.
d. Try to connect to the VPN.
e. When you get a connection error, select Export 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 default login timeout limit to be reached on the FortiGate. In
FortiOS 5.6.0 and later, use the following commands to allow a user to increase timers related to SSL VPN login.
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.
SSL VPN
To establish a client SSL VPN connection with TLS 1.3 to the FortiGate:
This feature can only be used with endpoints that have FortiClient 6.2.0 or a later version
installed. Earlier FortiClient versions do not support TLS 1.3.
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, consider that a policy with the above-mentioned web filter and SSL/SSH inspection profiles is enabled.
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.
TLS 1.3 support is only available for IPS engine 4.205 and later versions.
Microsoft Azure
Oracle OCI
AliCloud
Private cloud
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 recipe provides sample procedures to
add VDOMs beyond the default number using separately purchased VDOM licenses.
This recipe consists of the following steps:
1. Activate the FortiGate-VM with the base license.
2. Add more VDOMs to the FortiGate-VM.
d. Select the FortiGate-VM base license file, then click OK. The FortiGate-VM reboots after applying the base
license.
3. Verify the FortiGate-VM base license status and VDOM information:
a. Log in to the FortiGate-VM GUI.
b. In Dashboard > Status, in the Virtual Machine widget, ensure that there is a checkmark in front of the
FortiGate-VM base license name. The checkmark indicates that the base license is valid.
c. You can check VDOM information using the CLI. The following output shows that the maximum number of
VDOMs is currently one. This is correct since the FortiGate-VM base license only supports the default root
VDOM that the system uses.
FGVM4VTM19000476 # get system status
Version: FortiGate-VM64 v6.2.0,build0866,190328 (GA)
Virus-DB: 69.00091(2019-06-07 12:19)
Extended DB: 1.00000(2018-04-09 18:07)
Extreme DB: 1.00000(2018-04-09 18:07)
IPS-DB: 14.00610(2019-05-09 00:14)
IPS-ETDB: 0.00000(2001-01-01 00:00)
APP-DB: 14.00610(2019-05-09 00:14)
INDUSTRIAL-DB: 14.00610(2019-05-09 00:14)
Serial-Number: FGVM4VTM19000476
IPS Malicious URL Database: 2.00325(2019-06-07 03:56)
Botnet DB: 4.00490(2019-05-30 10:00)
License Status: Valid
License Expires: 2020-04-30
VM Resources: 2 CPU/4 allowed, 3022 MB RAM/6144 MB allowed
Log hard disk: Available
Hostname: FGVM4VTM19000476
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: 0866
Release Version Information: GA
FortiOS x86-64: Yes
System time: Fri Jun 7 14:04:55 2019
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.
WiFi
FortiAP management
Based on the above topology, this example uses port16 as the interface used to manage connection to FortiAPs.
1. You must enable a DHCP server on port16:
a. In FortiOS, go to Network > Interfaces.
b. Double-click port16.
c. In the IP/Network Mask field, enter an IP address for port16.
d. Enable DHCP Server, keeping the default settings.
2. If desired, you can enable the VCI-match feature using the CLI. When VCI-match is enabled, only devices with a
VCI name that matches the preconfigured string can acquire an IP address from the DHCP server. To configure
VCI-match, run the following commands:
config system dhcp server
edit 1
set interface port16
set vci-match enable
set vci-string "FortiAP"
next
end
3. As it is a minimum management requirement that FortiAP establish a CAPWAP tunnel with the FortiGate, you
must enable CAPWAP access on port16 to allow it to manage FortiAPs:
a. Go to Network > Interfaces.
b. Double-click port16.
c. Under Administrative Access, select CAPWAP.
d. Click OK.
4. To create a new FortiAP entry automatically when a new FortiAP unit is discovered, run the following command. By
default, this option is enabled.
config system interface
edit port16
set allow-access capwap
set ap-discover enable|disable
next
end
5. To allow FortiGate to authorize a newly discovered FortiAP to be controlled by the FortiGate, run the following
command. By default, this option is disabled.
For a FortiGate acting as an AP controller (AC) to discover a FortiAP unit, the FortiAP must be able to reach the AC. A
FortiAP with the factory default configuration has various ways of acquiring an AC's IP address to reach it.
Auto The FortiAP attempts to be discovered in the below ways sequentially within an endless loop.
Static The FortiAP sends discover requests to a preconfigured IP address that an AC owns.
DHCP The FortiAP acquires the IP address of an AC in DHCP option 138 (the factory default) of a
DHCP offer, which the FortiAP acquires its own IP address from.
DNS The FortiAP acquires the AC's IP address by resolving a preconfigured FQDN.
The ap-discover command allows the AC to create an entry in the managed FortiAPs table when it receives the
FortiAP's discovery request. The ap-discover command is enabled by default. When the FortiAP entry is created
automatically, it is marked as discovered status, and is pending for an administrator's authorization, unless the
following setting is present:
config system interface
edit "lan"
set auto-auth-extension-device enable
next
end
The auto-auth-extension-device command will allow AC authorize an new discovered FortiAP automatically
without an administrator's manual authorization operation. The auto-auth-extension-device command is
disabled by default.
Once the FortiAP discovery request is received by AC, an FortiAP entry will be added to the managed FortiAP table, and
shown on GUI > Managed FortiAP list page.
To authorize the specific AP, click to select the FortiAP entry, then click Authorize button on the top of the table or
Authorize entry in the pop-out menu.
Through GUI, authorization can also be done in FortiAP detail panel, under Action menu.
The authorization can also be done through CLI with follow commands.
config wireless-controller wtp
edit "FP423E3X16000320"
set admin enable
next
end
To de-authorize a managed FortiAP, click to select the FortiAP entry, then click Deauthorize button on the top of the
table or Deauthorize entry in the pop-out menu.
Through GUI, de-authorization can also be done in the FortiAP detail panel, under the Action menu.
The de-authorization can also be done through CLI with follow commands.
config wireless-controller wtp
edit "FP423E3X16000320"
set admin discovered
next
end
This function provides extended details of a FortiAP. On the Managed FortiAPs page, you can drill down to view all
available details of a FortiAP, including:
l FortiAP system information.
l Dynamic health and performance information.
l Dynamic radio and client details.
l Relevant links such as location of the FortiAP in the location map.
Sample topology
Sample configuration
In WiFi & Switch Controller > Managed FortiAPs, right-click a FortiAP and select Drill Down to Details.
If a FortiAP is on a WiFi Map, click the Locate button and that FortiAP is highlighted with a flashing yellow circle on the
WiFi Map.
Click Edit to open the Managed FortiAP page to show the FortiAP's operation information and a summary of its health
status. Click View More Details to open the details pane.
On the WiFi Map, click a FortiAP icon to open its details pane.
Configuring the AC
These instructions assume that the MRAP is already being managed by the AC (see Configuring the FortiGate interface
to manage FortiAP units on page 887 and Discovering, authorizing, and deauthorizing FortiAP units on page 888).
1. Go to WiFi & Switch Controller > SSID and create a mesh SSID.
2. Go to WiFi & Switch Controller > Managed FortiAPs, edit the MRAP, and assign the mesh SSID to the MRAP,
The MLAP can be configured to use the mesh link as its Main uplink or a Backup link for Ethernet connections.
Main uplink
When a mesh link is set as the main uplink of the MLAP, the Ethernet port on the MLAP can be set up as a bridge to the
mesh link. This allows downstream wired devices to use the mesh link to connect to the network.
To enable a mesh Ethernet bridge, select Ethernet Bridge in the FortiAP Connectivity section in the GUI, or use the
following console commands:
cfg -a MESH_ETH_BRIDGE=1
cfg -c
When a mesh link is set to be the backup link for an Ethernet connection, the mesh link will not be established unless
the Ethernet connection goes offline. When a mesh link is in this mode, the Ethernet port cannot be used as a bridge to
the mesh link.
After the AP joins, a CAPWAP tunnel is established between the FortiGate and FortiAP.
There are two channels inside the CAPWAP tunnel:
l The control channel for managing traffic, which is always encrypted by DTLS.
l The data channel for carrying client data packets, which can be configured to be encrypted or not.
The default setting for dtls-policy is clear-text, meaning it is non-encrypted. There are two settings available
to encrypt the data channel: dtls-enabled and ipsec-vpn:
config wireless-controller wtp-profile
edit "FortiAP-profile-name"
set dtls-policy clear-text|dtls-enabled|ipsec-vpn
next
end
Of the three settings, clear-text has the highest possible data throughput. Furthermore, FortiGates with hardware
acceleration chips can offload CAPWAP data traffic in clear-text and achieve much higher throughput performance.
You can only configure the data channel using the CLI.
When data security is not a major concern, we recommend that you set the data channel to non-encrypted. For
example, when the FortiGate and FortiAP are operating in an internal network.
When the FortiGate and FortiAP are in different networks, and the data channel might transit through a public network,
we recommend that you encrypt the data channel to protect your data with either DTLS or IPsec VPN.
DTLS
set dtls-in-kernel is only available after dtls-policy is set to dtls-enabled. When you enable dtls-
in-kernel, the FortiAP OS kernel processes the traffic encryption and decryption, which could provide better
throughput performance. DTLS encryption cannot be hardware-accelerated on the FortiGate so when DTLS is enabled,
data throughput performance is significantly lower than with clear-text.
IPsec VPN
To encrypt the data channel with IPsec VPN using the CLI:
This automatically establishes an IPsec VPN tunnel between the FortiGate and FortiAP that carries CAPWAP data
packets. FortiGates with NP6 chips can offload CAPWAP data traffic in IPsec, so this encryption option has better
throughput performance than DTLS. Because there is no built-in hardware acceleration chip, the FortiAP is considered
the performance bottleneck in this scenario.
SSID authentication
You can replace the built-in WiFi certificate with one you upload.
These instruction apply to FortiWiFi devices using internal WiFi radios and
FortiGate/FortiWiFi devices configured as WiFi Controllers that are managing FortiAP
devices, and have WiFi clients that are connected to WPA2-Enterprise SSID and
authenticated with local user groups.
On FortiOS, the built-in Fortinet_Wifi certificate is a publicly signed certificate that is only used in WPA2-Enterprise
SSIDs with local user-group authentication. The default WiFi certificate configuration is:
config system global
set wifi-ca-certificate "Fortinet_Wifi_CA"
set wifi-certificate "Fortinet_Wifi"
end
1. Get new certificate files, including a root CA certificate, a certificate signed by the CA, and the corresponding
private key file.
You can purchase a publicly signed certificate from a commercial certificate service provider or generate a self-
signed certificate.
2. Import the new certificate files into FortiOS:
a. In FortiGate, go to System > Certificates.
If VDOMs are enabled, go to Global > System > Certificates.
b. Click Import > CA Certificate.
c. Set the Type to File and upload the CA certificate file from the management computer.
d. Click OK.
The imported CA certificate is named CA_Cert_N or G_CA_Cert_N when VDOMs are enabled, where N
starts from 1 and increments for each imported certificate, and G stands for global range.
e. Click Import > Local Certificate.
f. Set the Type to Certificate, upload the certificate file and key file, enter the password, and enter the certificate
name.
g. Click OK.
The imported certificates are listed on the Certificates page.
3. Change the WiFi certificate settings:
a. Go to System > Settings and scroll down to the WiFi Settings section.
b. In the WiFi certificate dropdown menu, select the imported local certificate.
d. Click Apply.
As the factory default certificates are self-signed, WiFi clients need to accept it at the connection prompt or import the
Fortinet_CA certificate to validate it.
Additional Information
The Fortinet_Wifi certificate can be updated automatically through the FortiGuard service certificate bundle update.
If the built-in Fortinet_Wifi certificate has expired and not been renewed or replaced, WiFi clients can still connect to the
WPA2-Enterprise SSID with local user-group authentication by ignoring any warning messages or bypassing Validate
server certificate (or similar) options.
This topic provides simple configuration instructions for developing WPA2-Personal SSID with FortiAP. The steps
include creating an SSID, selecting the SSID for the FortiAP, and creating a policy from the SSID to the Internet.
The following shows a simple network topology for this recipe:
c. From the Incoming Interface dropdown list, select the source interface, such as wifi-vap.
d. From the Outgoing Interface dropdown list, select the destination interface, such as wan1.
e. In the Source and Destination fields, select all. In the Service field, select ALL. If desired, you can configure
different values for these fields.
f. Click OK.
This topic provides simple configuration instructions for developing WPA2-Enterprise SSID with FortiAP. The steps
include creating an SSID, selecting the SSID for the FortiAP, and creating a policy from the SSID to the Internet.
The following shows a simple network topology for this recipe:
This topic provides simple configuration instructions for developing captive portal SSID with FortiAP. The steps include
creating an SSID, selecting the SSID for the FortiAP, and creating a policy from the SSID to the Internet.
The following shows a simple network topology for this recipe:
4. Select the SSID on a managed FortiAP. The following configuration is based on a example using a managed
FortiAP-320C and a "FAP320C-default" profile that is applied to the FortiAP-320C. Do one of the following:
a. Select the SSID by editing the FortiAP:
i. Go to WiFi & Switch Controller > Managed FortiAPs. Select the FortiAP-320C and click Edit.
ii. Ensure that Managed AP Status is Connected.
iii. Under WiFi Setting, ensure that the configured FortiAP profile is the desired profile, in this case
FAP320C-default. Click Edit entry.
iv. To broadcast the SSID from 2.4 G radio, scroll to Radio 1 > SSIDs. Select Manual, then click + to create
the Fortinet-PSK SSID.
v. To broadcast the SSID from 5 G radio, scroll to Radio 2 > SSIDs. Select Manual, then click + to create
the Fortinet-PSK SSID.
vi. Click OK.
b. Select the SSID by editing the FortiAP profile:
i. Go to WiFi & Switch Controller > FortiAP Profile. Select the FAP320C-default profile, then click Edit.
ii. To broadcast the SSID from 2.4 G radio, scroll to Radio 1 > SSIDs. Select Manual, then click + to create
the Fortinet-PSK SSID.
iii. To broadcast the SSID from 5 G radio, scroll to Radio 2 > SSIDs. Select Manual, then click + to create
the Fortinet-PSK SSID.
iv. Click OK.
5. Create the SSID-to-Internet firewall policy:
a. Go to Policy & Objects > IPv4 Policy, then click Create New.
b. Enter the desired policy name.
c. From the Incoming Interface dropdown list, select the source interface, such as wifi-vap.
d. From the Outgoing Interface dropdown list, select the destination interface, such as wan1.
e. In the Source and Destination fields, select all. In the Service field, select ALL. If desired, you can configure
different values for these fields.
f. Click OK.
To deploy captive portal SSID to FortiAP units using the FortiOS CLI:
This topic provides instructions on simple configuration for on SSID. Consider the following for this feature:
l The quarantine function only works with SSID tunnel mode.
l The quarantine function is independent of SSID security mode.
The following shows a simple network topology for this recipe:
1. In FortiOS, go to the policy applied to the SSID and enable All Sessions for Log Allowed Traffic.
2. Edit the SSID:
a. Go to WiFi & Switch Controller > SSID, and select the desired SSID.
b. Enable Device Detection.
c. Enable Quarantine Host.
d. Click OK.
3. Quarantine a wireless client:
a. Do one of the following:
i. Go to Security Fabric > Physical Topology. View the topology by access device.
ii. Go to FortiView > Traffic from LAN/DMZ > Source.
iii. Go to FortiView > Traffic from LAN/DMZ > WiFi Clients.
b. Right-click the wireless client, then click Quarantine Host.
Follow these instructions to enable MAC filter on SSID. Consider the following when using this function:
l The MAC filter function is independent of the SSID security mode.
l To enable MAC filter on SSID, first configure the wireless controller address and address group. See instructions
below.
Sample topology
To block a specific client from connecting to the SSID using MAC filter:
1. Create a wireless controller address with the client MAC address and set the policy to deny. In this example, the
client MAC address is b4:ae:2b:cb:d1:72.
config wireless-controller address
edit "client_1"
set mac b4:ae:2b:cb:d1:72
set policy deny
next
end
2. Create a wireless controller address group using the above address and set the default policy to allow.
config wireless-controller addrgrp
edit mac_grp
set addresses "client_1"
set default-policy allow
next
end
3. On the virtual access point (VAP), select the above address group.
config wireless-controller vap
edit wifi-vap
set ssid "Fortinet-psk"
set security wpa2-only-personal
set passphrase fortinet
set address-group "mac_grp"
next
end
After this configuration, the client (MAC address b4:ae:2b:cb:d1:72) is denied connecting to SSID Fortinet-
psk. Other clients can connect, such as a client with MAC address e0:33:8e:e9:65:01.
1. Create a wireless controller address with the same MAC address as the client and set the policy to allow. In this
example, the client's MAC address is b4:ae:2b:cb:d1:72.
config wireless-controller address
edit "client_1"
set mac b4:ae:2b:cb:d1:72
set policy allow
next
end
2. Create a wireless controller address group using the above address and set the default policy to deny.
config wireless-controller addrgrp
edit mac_grp
set addresses "client_1"
set default-policy deny
next
end
3. On the virtual access point, select the above address group.
config wireless-controller vap
edit wifi-vap
set ssid "Fortinet-psk"
set security wpa2-only-personal
set passphrase fortinet
set address-group "mac_grp"
next
end
After this configuration, the client (MAC address b4:ae:2b:cb:d1:72) can connect to SSID Fortinet-psk. Other
clients are denied from connecting, such as a client with MAC address e0:33:8e:e9:65:01.
This feature is implemented on FortiOS 6.2.0 b0816 and FAP-S/W2 6.2.0 b0218.
In October 2017, Mathy Vanhoef published a document exposing a flaw in WPA2 networks known as Key Reinstallation
Attack (KRACK). To avoid the attack, the Wi-Fi Alliance announced in January that WPA2 enhancements and a new
WPA3 standard is coming in 2018.
1. WPA3 OWE.
a. WPA3 OWE only. Clients which support WPA3 can connect with this SSID.
config wireless-controller vap
edit "80e_owe"
set ssid "80e_owe"
set security owe
set pmf enable
set schedule "always"
next
end
b. WPA3 OWE TRANSITION. Clients connect with normal OPEN or OWE depending on its capability. Clients
which support WPA3 connect with OWS standard. Clients which cannot support WPA3 connect with Open
SSID.
config wireless-controller vap
edit "80e_open"
set ssid "80e_open"
set security open
set owe-transition enable
set owe-transition-ssid "wpa3_open"
set schedule "always"
next
edit "wpa3_owe_tr"
set ssid "wpa3_open"
set broadcast-ssid disable
set security owe
set pmf enable
set owe-transition enable
set owe-transition-ssid "80e_open"
set schedule "always"
next
end
2. WPA3 SAE.
a. WPA3 SAE. Clients which support WPA3 can connect with this SSID.
config wireless-controller vap
edit "80e_sae"
set ssid "80e_sae"
set security wpa3-sae
set pmf enable
set schedule "always"
set sae-password 12345678
next
end
b. WPA3 SAE TRANSITION. There are two passwords in the SSID. If passphrase is used, the client connects
with WPA2 PSK. If sae-password is used, the client connects with WPA3 SAE.
config wireless-controller vap
edit "80e_sae-tr"
set ssid "80e_sae-transition"
set security wpa3-sae-transition
set pmf optional
set passphrase 11111111
set schedule "always"
set sae-password 22222222
next
end
3. WPA3 Enterprise. Using this option, you can select the auth type to use either RADIUS authentication or local
user authentication.
edit "80e_wpa3_user"
set ssid "80e_wpa3_user"
set security wpa3-enterprise
set pmf enable
set auth usergroup
set usergroup "usergroup"
set schedule "always"
next
end
In addition to rogue AP detection, another concern is phishing SSIDs, which are defined as:
l An SSID defined on FortiGate that is broadcast from an uncontrolled AP.
l A pre-defined pattern for an offending SSID pattern. For example, you can define any SSID that contains your
company name to be a phishing SSID.
This function enables FortiAP to monitor and report these SSIDs in logs with the option to suppress them. You can only
configure this function using the CLI.
set phishing-ssid- Enable or disable the phishing SSID detection function. The default is enable.
detect enable|disable
set fake-ssid-action Specify the FortiGate action after detecting a fake SSID. The default is log and
log|suppress can be set to either one or both.
set ssid-pattern Specify the criteria to match an offending SSID. This example shows all SSID
"OFFENDING*" names with a leading string OFFENDING (not case-sensitive).
set action log|suppress Specify the FortiGate action after detecting the offending SSID pattern entry.
The default setting is log and can be set to either one or both.
Log examples
Following is a sample of the log that is generated when a fake SSID is first detected:
1: date=2019-03-01 time=14:53:23 logid="0104043567" type="event" subtype="wireless"
level="warning" vd="root" eventtime=1551480803 logdesc="Fake AP detected" ssid="CORP_
WIFI_ACCESS" bssid="08:5b:0e:18:1b:d0" aptype=0 rate=130 radioband="802.11n-5G"
channel=149 action="fake-ap-detected" manuf="Fortinet, Inc." security="WPA2 Personal"
encryption="AES" signal=-41 noise=-95 live=173397 age=0 onwire="no" detectionmethod="N/A"
stamac="N/A" apscan="N/A" sndetected="FP321C3X15001615" radioiddetected=1 stacount=0
snclosest="FP321C3X15001615" radioidclosest=1 apstatus=0 msg="Detected Fake AP CORP_WIFI_
ACCESS 08:5b:0e:18:1b:d0 chan 149 live 173397 age 0"
Following is a sample of the log that is periodically generated when a fake SSID is continuously detected:
1: date=2019-03-01 time=14:58:53 logid="0104043568" type="event" subtype="wireless"
level="warning" vd="root" eventtime=1551481133 logdesc="Fake AP on air" ssid="CORP_WIFI_
ACCESS" bssid="08:5b:0e:18:1b:d0" aptype=0 rate=130 radioband="802.11n-5G" channel=149
action="fake-ap-on-air" manuf="Fortinet, Inc." security="WPA2 Personal" encryption="AES"
signal=-41 noise=-95 live=173728 age=330 onwire="no" detectionmethod="N/A" stamac="N/A"
apscan="N/A" sndetected="N/A" radioiddetected=0 stacount=0 snclosest="FP321C3X15001615"
radioidclosest=1 apstatus=0 msg="Fake AP On-air CORP_WIFI_ACCESS 08:5b:0e:18:1b:d0 chan
149 live 173728 age 330"
Following is a sample of the log that is generated when a fake SSID is suppressed:
1: date=2019-03-01 time=14:53:23 logid="0104043569" type="event" subtype="wireless"
level="warning" vd="root" eventtime=1551480803 logdesc="Rogue AP suppressed" ssid="CORP_
WIFI_ACCESS" bssid="08:5b:0e:18:1b:d0" aptype=0 rate=130 radioband="802.11n-5G"
channel=149 action="rogue-ap-suppressed" manuf="Fortinet, Inc." security="WPA2 Personal"
encryption="AES" signal=-41 noise=-95 live=173397 age=0 onwire="no" detectionmethod="N/A"
stamac="N/A" apscan="N/A" sndetected="N/A" radioiddetected=0 stacount=0
snclosest="FP321C3X15001615" radioidclosest=1 apstatus=0 msg="AP CORP_WIFI_ACCESS
08:5b:0e:18:1b:d0 chan 149 live 173397 age 0"
Following a sample of the log that is generated when an offending SSID is first detected:
1: date=2019-03-01 time=14:53:33 logid="0104043619" type="event" subtype="wireless"
level="warning" vd="root" eventtime=1551480811 logdesc="Offending AP detected"
ssid="OFFENDING_SSID" bssid="1a:5b:0e:b5:f3:bf" aptype=0 rate=130 radioband="802.11n-5G"
channel=153 action="offending-ap-detected" manuf="Fortinet, Inc." security="WPA2
Personal" encryption="AES" signal=-41 noise=-95 live=173406 age=8 onwire="no"
detectionmethod="N/A" stamac="N/A" apscan="N/A" sndetected="FP321C3X15001615"
radioiddetected=1 stacount=0 snclosest="FP321C3X15001615" radioidclosest=1 apstatus=0
msg="Detected Offending AP OFFENDING_SSID 1a:5b:0e:b5:f3:bf chan 153 live 173406 age 8"
Following is a sample of a log that is periodically generated when an offending SSID is continuously detected:
1: date=2019-03-01 time=14:55:54 logid="0104043620" type="event" subtype="wireless"
level="warning" vd="root" eventtime=1551480952 logdesc="Offending AP on air"
ssid="OFFENDING_SSID_TEST" bssid="9a:5b:0e:18:1b:d0" aptype=0 rate=130
radioband="802.11n-5G" channel=149 action="offending-ap-on-air" manuf="N/A"
security="WPA2 Personal" encryption="AES" signal=-41 noise=-95 live=173548 age=150
onwire="no" detectionmethod="N/A" stamac="N/A" apscan="N/A" sndetected="N/A"
radioiddetected=0 stacount=0 snclosest="FP321C3X15001615" radioidclosest=1 apstatus=0
Following is a sample of the log that is generated when an offending SSID is suppressed:
1: date=2019-03-01 time=14:53:33 logid="0104043569" type="event" subtype="wireless"
level="warning" vd="root" eventtime=1551480811 logdesc="Rogue AP suppressed"
ssid="OFFENDING_SSID" bssid="1a:5b:0e:b5:f3:bf" aptype=0 rate=130 radioband="802.11n-5G"
channel=153 action="rogue-ap-suppressed" manuf="Fortinet, Inc." security="WPA2 Personal"
encryption="AES" signal=-41 noise=-95 live=173406 age=8 onwire="no" detectionmethod="N/A"
stamac="N/A" apscan="N/A" sndetected="N/A" radioiddetected=0 stacount=0
snclosest="FP321C3X15001615" radioidclosest=1 apstatus=0 msg="AP OFFENDING_SSID
1a:5b:0e:b5:f3:bf chan 153 live 173406 age 8"
This feature changes the wireless-controller VAP (for SSID configuration) from a global object to a VDOM object,
simplifying tracking the object reference count. It also removes the vdom setting from VAP configuration. When
multi-vdom is enabled on a FortiGate, the wireless-controller VAP can be added, edited, or deleted only inside of a
VDOM.
l When vdom-mode is multi-vdom, references to user-group and radius can be checked correctly when they are
used by a VAP interface:
l A VAP interface with security-mode set to WPA2-Enterprise and RADIUS authentication:
(vdom2) # show wireless-controller vap new
config wireless-controller vap
edit "new"
set ssid "new"
set security wpa2-only-enterprise
set auth radius
set radius-server "peap"
next
end
(vdom2) # diagnose sys cmdb refcnt show user.radius.name peap
entry used by table wireless-controller.vap:name 'new'
Statistics
The following shows a simple network topology when using FortiAPs with FortiGate:
To view connected WiFi clients on the FortiGate unit, go to Monitor > WiFi Client Monitor. The following columns
display:
Column Description
SSID SSID that the client connected to, such as the tunnel, bridge, or mesh.
FortiAP Serial number of the FortiAP unit that the client connected to.
Signal Strength/Noise Signal-to-noise ratio in decibels calculated from signal strength and noise level.
Association Time How long the client has been connected to this AP.
The following shows a simple network topology when using FortiAPs with FortiGate:
The Monitor > WiFi Health Monitor page displays the following charts:
l Active Clients: Currently active clients on each FortiAP
l AP Status: APs by status, sorted by those that have been up for over 24 hours, rebooted in the past 24 hours, and
down/missing
l Channel Utilization: Allow users to view 10-20 most and least utilized channels for each AP radio and a third
histogram view showing utilization counts
l Client Count: Shows client count over time. Can view for the past hour, day, or 30 days.
l Login Failures: Time, SSID, hostname, and username for failed login attempts. The widget also displays the AP
name and group of FortiAP units with failed login attempts.
l Top Wireless Interference: Separate widgets for 2.4 GHz and 5 GHz bands. This requires spectrum analysis to
be enabled on the radios.
WiFi maps
WiFi Maps allow you to place FortiAP units on a custom map that you upload, such as an office floor plan. WiFi Maps
show real-time status and alerts of FortiAP units so that you can quickly see the location and status of each FortiAP unit
on the map.
1. Obtain a floor plan or map (in PNG, JPEG, or GIF format) of where FortiAP units are located.
2. Go to WiFi & Switch Controller > WiFi Maps.
3. Click the + or Add Map button.
You must use the GUI to upload WiFi maps.
d. Click OK.
c. Drag and drop each FortiAP unit onto its location on the map.
d. When all FortiAP units have been placed on the map, click the lock icon.
The WiFi map shows where each FortiAP unit is located.
6. Hover the cursor over a FortiAP icon to view the FortiAP unit's operating data.
7. To view a FortiAP unit's detailed operating data or to configure AP settings, click that FortiAP icon.
8. Use the dropdown lists above the map to show one or both the 2.4 GHz or 5 GHz band. You can also show
numerical operating data such as client count, channel, radio TX power, and channel utilization using the options in
the dropdown list above the map.
The following shows a simple network topology when using FortiAP as part of the Security Fabric:
The Security Fabric > Settings page on the root FortiGate lists all FortiAP devices on the CSF root and leaf.
The Security Fabric > Physical Topology view on the root FortiGate shows the devices in the Security Fabric and the
devices they are connected to.
You can enable SNMP directly on FortiAP by implementing a SNMPD daemon/subagent on the FortiAP side.
FortiAP-S and FortiAP-W2 6.2 and later support SNMP query and trap messages according to the wireless controller
SNMP settings pushed from the FortiGate device.
The example below shows an Ubuntu-OS querying a FortiAP 222E unit with the snmpwalk command. The SNMP
agent software has the FORTINET-FORTIAP-MIB already imported.
tester@ControlPC:~$ snmpwalk -v 2c -c QAMikeAn 172.18.56.32 .1.3.6.1.4.1.12356.120.1
FORTINET-FORTIAP-MIB::fapVersion.0 = STRING: FP222E-v6.2-build0231
FORTINET-FORTIAP-MIB::fapSerialNum.0 = STRING: FP222E3X17000073
FORTINET-FORTIAP-MIB::fapHostName.0 = STRING: FortiAP-222E
FORTINET-FORTIAP-MIB::fapRegionCode.0 = STRING: A
FORTINET-FORTIAP-MIB::fapBaseMacAddr.0 = STRING: 70:4c:a5:5d:ea:d0
FORTINET-FORTIAP-MIB::fapBiosVer.0 = STRING: 04000002
FORTINET-FORTIAP-MIB::fapBiosDataVer.0 = INTEGER: 3
FORTINET-FORTIAP-MIB::fapSysPartNum.0 = STRING: 20844-04
Five kinds of trap messages can be sent by the FortiAP-S and FortiAP-W2 devices:
l fapDevUp: Indicates that the specified AP device is up.
l CpuOverloadfap: Indicates that the CPU usage of the specified AP has exceeded the configured threshold.
l MemOverload: Indicates that the memory usage of the specified AP has exceeded the configured threshold.
l fapDevDown: Indicates that the specified AP device is down.
l fapfapAcConnected: Indicates that the specified AP device has connected to the specified AC.
The following screenshot shows an SNMP trap receiver (SnmpB) that has received one fapDevUp trap message from a
FortiAP unit (serial number: FP222E3X17000000).
Wireless security
The guide provides simple configuration instructions for enabling ap-scan on FortiAP. The steps include creating a
WIDS profile and selecting the WIDS profile on the managed FortiAP.
1. Create a WIDS profile:
a. In FortiOS, go to WiFi & Switch Controller > WIDS Profiles. Click Create New.
b. Enable Enable Rogue AP Detection.
c. Complete the configuration, then click OK.
2. Select the WIDS profile for the managed FortiAP:
a. Go to WiFi & Switch Controller > FortiAP Profiles.
b. Select the FortiAP profile applied to the managed FortiAP, then click Edit.
c. Enable WIDS Profile. Select the profile created in step 1. Click OK.
1. Create a WIDS profile:
config wireless-controller wids-profile
edit "example-wids-profile"
set ap-scan enable
next
end
2. Select the WIDS profile for the managed FortiAP:
config wireless-controller wtp-profile
edit "example-FAP-profile"
config platform
set type <FAP-model-number>
end
set handoff-sta-thresh 55
set ap-country US
config radio-1
set band 802.11n
set wids-profile "example-wids-profile"
set vap-all disable
end
config radio-2
set band 802.11ac
set vap-all disable
end
next
end
The guide provides simple configuration instructions for suppressing rogue APs on FortiAP. The steps include creating a
WIDS profile and suppressing rogue APs.
1. Create a WIDS profile:
a. In FortiOS, go to WiFi & Switch Controller > WIDS Profiles. Click Create New.
b. For Sensor Mode, select Foreign and Home Channels.
c. Enable Enable Rogue AP Detection.
d. Complete the configuration, then click OK.
2. Select the WIDS profile for the managed FortiAP. The monitoring radio must be in Dedicated Monitor mode:
a. Go to WiFi & Switch Controller > FortiAP Profiles.
b. Select the FortiAP profile applied to the managed FortiAP, then click Edit.
c. Select Dedicated Monitor on Radio 1 or Radio 2.
d. Enable WIDS Profile. Select the profile created in step 1. Click OK.
3. Suppress FortiAP:
a. Go to Monitor > Rogue AP Monitor.
b. Right-click the desired SSID, then select Mark as Rogue.
c. Right-click the SSID again, then select Suppress AP.
1. Create a WIDS profile:
config wireless-controller wids-profile
edit "example-wids-profile"
set sensor-mode both
set ap-scan enable
next
end
2. Select the WIDS profile for the managed FortiAP:
config wireless-controller wtp-profile
edit "example-FAP-profile"
config platform
set type <FAP-model-number>
end
config radio-1
set mode monitor
set wids-profile "example-wids-profile"
end
next
end
3. Suppress FortiAP:
config wireless-controller ap-status
edit 1
set bssid 90:6c:ac:da:a7:f1
set ssid "example-SSID"
set status suppressed
next
end
The guide provides simple configuration instructions for enabling a Wireless Intrusion Detection System (WIDS) profile
on FortiAP.
1. Create a WIDS profile:
a. In FortiOS, go to WiFi & Switch Controller > WIDS Profiles. Click Create New.
b. In the Name field, enter the desired name.
c. Under Intrusion Detection Settings, enable all intrusion types as desired.
d. Complete the configuration, then click OK.
2. Select the WIDS profile for the managed FortiAP:
a. Go to WiFi & Switch Controller > FortiAP Profiles.
b. Select the FortiAP profile applied to the managed FortiAP, then click Edit.
c. Enable WIDS Profile. Select the profile created in step 1. Click OK.
config platform
set type <FAP-model-number>
end
set handoff-sta-thresh 55
set ap-country US
config radio-1
set band 802.11n
set wids-profile "example-wids-profile"
set vap-all disable
end
config radio-2
set band 802.11ac
set wids-profile "example-wids-profile"
set vap-all disable
end
next
end
This function enables FortiGate to preserve the WiFi Multi-Media (WMM) QoS marking of packets by translating them
to Differentiated Services Code Point (DSCP) values when forwarding upstream.
Use the following QoS profile CLI commands to implement this function:
wmm-dscp-marking Enable/disable WMM Differentiated Services Code Point (DSCP) marking (default =
disable).
wmm-vo-dscp DSCP marking for voice access (default = 48).
wmm-vi-dscp DSCP marking for video access (default = 32).
wmm-be-dscp DSCP marking for best effort access (default = 0).
wmm-bk-dscp DSCP marking for background access (default = 8).
1. Create a QoS profile with wmm-dscp-marking enabled, and modify the wmm-dscp settings.
config wireless-controller qos-profile
edit qos-wifi
set wmm-dscp-marking enable
set wmm-vo-dscp 44
set wmm-vi-dscp 24
set wmm-be-dscp 12
set wmm-bk-dscp 6
end
4. Verify that, when sending traffic from a client with a WMM setting of VO, the FortiGate receives the packets with a
DSCP TID value or 44.
5. Verify that, when sending traffic from a client with a WMM setting of VI, the FortiGate receives the packets with a
DSCP TID value or 24.
6. Verify that, when sending traffic from a client with a WMM setting of BE, the FortiGate receives the packets with a
DSCP TID value or 12.
7. Verify that, when sending traffic from a client with a WMM setting of BK, the FortiGate receives the packets with a
DSCP TID value or 6.
Other
This guide provides instructions for simple configuration of security profile groups for FortiAP, including creating security
profile groups and selecting profile groups for the SSID.
2. Create a local bridge mode SSID and enable security profile groups:
a. Go to WiFi & Switch Controller > SSID. Select SSID, then click Create New.
b. Enter the desired interface name. For Traffic mode, select Bridge.
c. In the SSID field, enter the desired SSID name. Configure security as desired.
d. Enable Security Profile Group, then select the group created in step 1.
e. Click OK.
3. Select the SSID on a managed FortiAP by editing the FortiAP profile. The following configuration is based on a
example using a managed FortiAP-320C and a "FAP320C-default" profile that is applied to the FortiAP-320C:
a. Go to WiFi & Switch Controller > FortiAP Profile. Select the FAP320C-default profile, then click Edit.
b. To broadcast the SSID from 2.4 G radio, scroll to Radio 1 > SSIDs. Select Manual, then click + to create the
Fortinet-PSK SSID.
c. To broadcast the SSID from 5 G radio, scroll to Radio 2 > SSIDs. Select Manual, then click + to create the
Fortinet-PSK SSID.
d. Click OK.
The following shows a simple network topology for this recipe. The primary and secondary FortiGates should reach the
FortiAP at the physical level:
1. On the primary FortiGate, run the diag wireless-controller wlac -c ha command. The output should
resemble the following:
WC fast failover info
cfg iter: 1 (age=17995, size=220729, fp=0x5477e28)
dhcpd_db iter: 123 (age=132, size=1163, fp=0x5435930)
dhcpd_ipmac iter: 123 (age=132, size=2860, fp=0x587d848)
mode: 1+1-ffo
pri: primary
key csum: 0x9c99
max: 10
wait: 10
peer cnt: 1
FWF60E4Q16027198: 10.43.1.62:5245 secondary UP (age=0)
2. On the secondary FortiGate, run the diag wireless-controller wlac -c ha command. The output
should resemble the following:
WC fast failover info
mode: 1+1-ffo
status: monitoring
pri: secondary
key csum: 0x9c99
max: 10
wait: 10
peer cnt: 1
FWF60E4Q16027198: 10.43.1.62:5245 secondary UP (age=0)
NP6 offloading over CAPWAP traffic is supported by all the FortiGate high-level models and most middle-level models.
l check the system session, when dtls-policy=clear-text to verify npu info: flag=0x81/0x89, offload=8/8
FG1K2D3I16800192 (vdom1) # diag sys session list
l check the system session, when dtls-policy=ipsec-vpn to verify npu info: flag=0x81/0x82, offload=8/8
FG1K2D3I16800192 (vdom1) # diag sys session list
Airtime fairness
WiFi has a natural tendency for clients farther away or clients at lower data rates to monopolize the airtime and slow
down overall performance. Airtime fairness helps to improve the overall network performance in these conditions.
Airtime fairness has these characteristics:
l Only applies to downlink traffic.
l Can be set on both 2.4 GHz and 5 GHz radio bands.
l Can be set per-SSID. Each VAP is granted airtime according to the percentage assigned to the VAP.
l Can apply to all kinds of VAP (Bridge, Tunnel, or Mesh) and all kinds of authentication (Open, PSK, or Enterprise).
l Only applies to data and is not for control or management.
Airtime fairness is balanced from TX side from AP to client since that's the only direction under the control of AP.
For example, there are two Bridge mode SSIDs with a wireless client and an airtime fairness weight of 80% and 20%.
Using WaveDynamix to simulate the same traffic from Ethernet to the wireless client, the traffic for each SSID matches
the airtime fairness weight assigned to them.
Airtime fairness is not related to SSID type or authentication type. In this example, it uses Bridge mode SSID and Open
Authentication.
You must use the CLI to configure this function.
The default atf-weight is 20 so there is no need to set this option for atf_br2.
config wireless-controller vap
edit "atf_br1"
set atf-weight 80
set ssid "atf_br1"
set security open
set local-bridging enable
set schedule "always"
next
end
This example uses one FAP-S423E unit with airtime fairness enabled on the 5 GHz radio band.
config wireless-controller wtp-profile
edit "S423E_atf"
config platform
set type S423E
end
config radio-1
set mode disabled
end
config radio-2
set band 802.11ac
set airtime-fairness enable
set vap-all disable
set vaps "atf_br1" "atf_br2"
set channel "149"
end
set ext-info-enable enable
next
end
Using WaveDynamix to create two same clients connected with two SSIDs, downlink traffic is passed from Ethernet to
the wireless client with the same bit rate.
This example shows that tx_bytes from atf_br1 is almost four times higher than atf_br2.
Extended logging
Extended logging information in these four key areas help WiFi troubleshooting: Association, Authentication, DHCP,
and DNS.
The detailed wireless event logs show client connection procession to help IT administrators troubleshoot WiFi
connection problems. The FortiAP can send more detailed events of client connections (such as probe, associate,
authentication, 4-way handshake, DHCP), and FortiGate can create associated logs of these event.
New probe, authentication, and associate logs when wireless clients try to connect a broadcasted SSID
with any security-mode
New WPA 4-Way handshake logs when wireless clients try to connect WPA2-Personal/WPA2-Enterprise
SSID
New RADIUS authentication logs when clients connect WPA2-Enterprise with User-group or Radius-auth
SSID
New RADIUS MAC authentication logs when clients try to connect a SSID with radius-mac-auth enabled
RADIUS MAC authenticate success log when client passes RADIUS MAC authentication
RADIUS MAC authenticate failure log when client fails to pass RADIUS MAC authentication
New Fast-BSS-Transition (FT) logs when 802.11r clients roam between 2 FAPs
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.
FortiLink setup
Go to WiFI & Switch Controller > FortiLink Interface to create or edit FortiLink interfaces. The available options
depend on the FortiGate model.
By automatically creating FortiLink interfaces as a logical aggregate or hard/soft switch, you can modify the FortiLink
interfaces. If the physical port in use changes, you don't need to migrate existing policies.
The switch controller has a network auto-config option which contains configurable defaults, policy customization,
and an individual interface override. This gives administrators simple and flexible control.
Following is a description of these options:
auto-config Provides the default actions for the first hop (fgt-policy) and lower-tier devices (isl-
default policy).
auto-config A database containing policies that can be applied as a system-wide default or to a specific
policy interface.
auto-config Allows for the override of the auto-config default on a specific interface. This
custom information is retained and is reapplied if an interface leaves and then is rediscovered.
The switch controller has a traffic-sniffer option to provide a targeted approach where mirrored traffic is always
directed towards the FortiGate on a dedicated VLAN. This allows for easy sniffing by using the CLI or GUI. Also, the
traffic can be routed through the FortiGate using Encapsulated Remote Switched Port Analyzer (ERSPAN) for external
analysis and storage.
Use this option to define targeted sniffers by IP or MAC address. Traffic matching is replicated to the FortiGate, which is
helpful when you know what device you are looking for but don't know where it is located.
FortiLink networks can have multiple switches and traffic typically traverses several switches. If each switch mirrors any
match, the sniffer would see multiple copies of traffic. To reduce this, the targets are applied at the perimeter of the
FortiSwitch network. Traffic entering by a user port or traffic from FortiGate is considered eligible for mirroring.
You can also enable traditional port-based sniffers in the ingress or egress direction.
All sniffer traffic arrives at the FortiGate using ERSPAN and the traffic is encapsulated in generic routing encapsulation
(GRE).
To enable traffic sniffer based on target IP or MAC address on target ports of managed FortiSwitch units:
In WiFi & Switch Controller > FortiSwitch Ports, you can enable MCLAG and view ports grouped by trunks. You need
to configure ports from two switches, that is, two MCLAG peer switches to be included in one MCLAG.
Sample configuration
In WiFi & Switch Controller > FortiSwitch Ports, there is an MC-LAG option.
In WiFi & Switch Controller > FortiSwitch Ports, there is a Trunk view.
The following recipes provide instructions on configuring a standalone FortiGate as a switch controller:
l Standalone FortiGate as switch controller
l Multiple FortiSwitches managed via hardware/software switch on page 962
l Multiple FortiSwitches in tiers via aggregate interface with redundant link enabled on page 966
l Multiple FortiSwitches in tiers via aggregate interface with MCLAG enabled only on distribution on page 969
In this example, one FortiSwitch is managed by a standalone FortiGate. The FortiGate uses an aggregate interface to
operate as a switch controller. This configuration might be used in branch office. It might also be used before increasing
the number of connected FortiSwitch units and evolving to a multi-tier structure.
Prerequisites:
If the FortiSwitch ports used for the FortiLink connection have auto-discovery-fortilink enabled, executing
authorization on FortiGate will trigger the transformation to FortiLink mode automatically.
config switch interface
edit "port1"
set auto-discovery-fortilink enable
……
next
end
Check the CLI output for Connection: Connected to show that FortiLink is up:
execute switch-controller get-conn-status FSWSerialNum
Troubleshooting
If an authorized FortiSwitch is always offline, go to the FortiGate CLI and use the command below to see all the
checkpoints. Inspect each checkpoint to find the cause of the problem.
execute switch-controller diagnose-connection S248EPTF18001384
Fortilink
Status ... SWITCH_AUTHORIZED_READY
Last keepalive ... 1 seconds ago
CAPWAP
Remote Address: 2.2.2.2
Status ... CONNECTED
Last keepalive ... 26 seconds ago
This example provides a recommended configuration of FortiLink where multiple FortiSwitches are managed by a
standalone FortiGate as switch controller via hardware or software switch interface; such as when you need multiple
distribution FortiSwitches but lack supporting aggregate on FortiGate.
Prerequisites:
If the FortiSwitch ports used for the FortiLink connection have auto-discovery-fortilink enabled, executing
authorization on FortiGate will trigger the transformation to FortiLink mode automatically.
config switch interface
edit "port1"
set auto-discovery-fortilink enable
……
next
end
Create hardware or software switch interface and designate it as FortiLink interface on the FortiGate:
Check the CLI output for Connection: Connected to show that FortiLink is up:
execute switch-controller get-conn-status FSWSerialNum
Troubleshooting
Fortinet recommends binding FortiLink on the hardware switch interface. Since the hardware switch interface can
leverage hardware chips to forward traffic, it does not consume CPU capacity, unlike a software switch.
If an authorized FortiSwitch is always offline, go to the FortiGate CLI and use the command below to see all the
checkpoints. Inspect each checkpoint to find the cause of the problem.
execute switch-controller diagnose-connection S248EPTF18001384
Fortilink
Status ... SWITCH_AUTHORIZED_READY
Last keepalive ... 1 seconds ago
CAPWAP
Remote Address: 2.2.2.2
Status ... CONNECTED
Last keepalive ... 26 seconds ago
This example provides a recommended configuration of FortiLink where multi-tier FortiSwitches are managed by a
standalone FortiGate as switch controller via aggregate interface, where the FortiGate can provide redundant links to
multiple distribution FortiSwitches.
Prerequisites:
If the FortiSwitch ports used for the FortiLink connection have auto-discovery-fortilink enabled, executing
authorization on FortiGate will trigger the transformation to FortiLink mode automatically.
config switch interface
edit "port1"
set auto-discovery-fortilink enable
……
next
end
Check the CLI output for Connection: Connected to show that FortiLink is up:
execute switch-controller get-conn-status FSWSerialNum
Troubleshooting
If an authorized FortiSwitch is always offline, go to the FortiGate CLI and use the command below to see all the
checkpoints. Inspect each checkpoint to find the cause of the problem.
execute switch-controller diagnose-connection S248EPTF18001384
Fortilink
Status ... SWITCH_AUTHORIZED_READY
Last keepalive ... 1 seconds ago
CAPWAP
Remote Address: 2.2.2.2
Status ... CONNECTED
Last keepalive ... 26 seconds ago
Multiple FortiSwitches in tiers via aggregate interface with MCLAG enabled only
on distribution
This example provides a recommended configuration of FortiLink where multi-tier FortiSwitches are managed by a
standalone FortiGate as switch controller via aggregate interface, where the FortiGate can provide active-active links to
two distribution FortiSwitches connected to each other by MCLAG.
Prerequisites:
If the FortiSwitch ports used for the FortiLink connection have auto-discovery-fortilink enabled, executing
authorization on FortiGate will trigger the transformation to FortiLink mode automatically.
config switch interface
edit "port1"
set auto-discovery-fortilink enable
……
next
end
Check the CLI output for Connection: Connected to show that FortiLink is up:
execute switch-controller get-conn-status FSWSerialNum
Enable MCLAG on the ICL link between the distribution FortiSwitch devices:
When you enable mclag-icl, MCLAG on the FortiLink interface is enabled automatically and active-active backup
links between the distribution FortiSwitches are established.
Troubleshooting
If an authorized FortiSwitch is always offline, go to the FortiGate CLI and use the command below to see all the
checkpoints. Inspect each checkpoint to find the cause of the problem.
execute switch-controller diagnose-connection S248EPTF18001384
Fortilink
Status ... SWITCH_AUTHORIZED_READY
Last keepalive ... 1 seconds ago
CAPWAP
Remote Address: 2.2.2.2
Status ... CONNECTED
Last keepalive ... 26 seconds ago
The following recipes provide instructions on configuring a FortiGate HA in Active-Passive (A-P) mode as a switch
controller:
l Multiple FortiSwitches managed via hardware/software switch on page 973
l Multiple FortiSwitches in tiers via aggregate interface with redundant link enabled on page 978
l Multiple FortiSwitches in tiers via aggregate interface with MCLAG enabled only on distribution on page 982
This example provides a recommended configuration of FortiLink where multiple FortiSwitches are managed by an A-P
mode HA cluster of FortiGates as switch controller via hardware or software switch interface. An example of common
usage is when you need multiple distribution FortiSwitches but lack supporting aggregate on the FortiGate pairs.
Prerequisites:
If the FortiSwitch ports used for the FortiLink connection have auto-discovery-fortilink enabled, executing
authorization on FortiGate will trigger the transformation to FortiLink mode automatically.
config switch interface
edit "port1"
set auto-discovery-fortilink enable
……
next
end
Create hardware or software switch interface and designate it as FortiLink interface on the FortiGate:
Check the CLI output for Connection: Connected to show that FortiLink is up:
execute switch-controller get-conn-status FSWSerialNum
FortiSwitch.
2. Configure FortiSwitch ports.
a. On the FortiGate, go to WiFi & Switch Controller > FortiSwitch Ports.
b. Select one or more FortiSwitch ports and assign them to the switch VLAN.
c. You can also select POE/DHCP Snooping, STP, and other parameters for the FortiSwitch ports to show their
real-time status such as link status, data statistics, etc.
3. Configure access authentication.
a. On the FortiGate, go to WiFi & Switch Controller > FortiSwitch Security Policies.
b. Configure the 802.1X security policies.
c. Select Port-based or MAC-based mode and select User groups from the existing VDOM.
d. Configure other fields as necessary.
e. Go to WiFi & Switch Controller > FortiSwitch Ports.
f. Select one or more FortiSwitch ports, click + in the Security Policy column, then make a selection from the
pane.
Troubleshooting
Fortinet recommends binding FortiLink on the hardware switch interface. Since the hardware switch interface can
leverage hardware chips to forward traffic, it does not consume CPU capacity, unlike a software switch.
If an authorized FortiSwitch is always offline, go to the FortiGate CLI and use the command below to see all the
checkpoints. Inspect each checkpoint to find the cause of the problem.
execute switch-controller diagnose-connection S248EPTF18001384
Fortilink
Status ... SWITCH_AUTHORIZED_READY
Last keepalive ... 1 seconds ago
CAPWAP
Remote Address: 2.2.2.2
Status ... CONNECTED
Last keepalive ... 26 seconds ago
HA sync fails
If HA sync fails, use the command below to diagnose and locate the cause.
# diagnose system ha checksum cluster
is_manage_master()=1, is_root_master()=1
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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_master()=0, is_root_master()=0
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
This example provides a recommended configuration of FortiLink where multi-tier FortiSwitches are managed by an A-P
mode HA cluster of FortiGates as switch controller via aggregate interface, where each FortiGate cluster member can
provide redundant links to multiple (>=2) distribution FortiSwitches.
Prerequisites:
This operation will cleanup all of the configuration and reboot the system!
Do you want to continue? (y/n)y
Backing up local mode config before entering FortiLink mode....
If the FortiSwitch ports used for the FortiLink connection have auto-discovery-fortilink enabled, executing
authorization on FortiGate will trigger the transformation to FortiLink mode automatically.
config switch interface
edit "port1"
set auto-discovery-fortilink enable
……
next
end
Check the CLI output for Connection: Connected to show that FortiLink is up:
execute switch-controller get-conn-status FSWSerialNum
Troubleshooting
If an authorized FortiSwitch is always offline, go to the FortiGate CLI and use the command below to see all the
checkpoints. Inspect each checkpoint to find the cause of the problem.
execute switch-controller diagnose-connection S248EPTF18001384
Fortilink
Status ... SWITCH_AUTHORIZED_READY
Last keepalive ... 1 seconds ago
CAPWAP
Remote Address: 2.2.2.2
Status ... CONNECTED
Last keepalive ... 26 seconds ago
HA sync fails
If HA sync fails, use the command below to diagnose and locate the cause.
is_manage_master()=1, is_root_master()=1
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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_master()=0, is_root_master()=0
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
Multiple FortiSwitches in tiers via aggregate interface with MCLAG enabled only
on distribution
This example provides a recommended configuration of FortiLink where multi-tier FortiSwitches are managed by an A-P
mode HA cluster of FortiGates as switch controller via aggregate interface, where FortiGates provide active-active links
to two distribution FortiSwitches connected to each other by MCLAG.
Prerequisites:
If the FortiSwitch ports used for the FortiLink connection have auto-discovery-fortilink enabled, executing
authorization on FortiGate will trigger the transformation to FortiLink mode automatically.
config switch interface
edit "port1"
set auto-discovery-fortilink enable
……
next
end
Check the CLI output for Connection: Connected to show that FortiLink is up:
execute switch-controller get-conn-status FSWSerialNum
Enable MCLAG on the ICL link between the distribution FortiSwitch devices:
next
end
When you enable mclag-icl, MCLAG on the FortiLink interface is enabled automatically and active-active backup
links between the distribution FortiSwitches are established.
Troubleshooting
If an authorized FortiSwitch is always offline, go to the FortiGate CLI and use the command below to see all the
checkpoints. Inspect each checkpoint to find the cause of the problem.
execute switch-controller diagnose-connection S248EPTF18001384
Fortilink
Status ... SWITCH_AUTHORIZED_READY
Last keepalive ... 1 seconds ago
CAPWAP
Remote Address: 2.2.2.2
Status ... CONNECTED
Last keepalive ... 26 seconds ago
HA sync fails
If HA sync fails, use the command below to diagnose and locate the cause.
# diagnose system ha checksum cluster
is_manage_master()=1, is_root_master()=1
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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_master()=0, is_root_master()=0
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
Multiple FortiSwitches in tiers via aggregate interface with MCLAG enabled on all
tiers
This example provides a recommended configuration of FortiLink where multi-tier FortiSwitch devices are managed by
an A-P mode HA cluster of FortiGates acting as a switch controller via an aggregate interface. The FortiGates provide A-
A links to two distribution FortiSwitches that are connected to each other by MCLAG. All access FortiSwitch devices
have A-A links with two upper tier FortiSwitches, as long as the MCLAG-ICL has been enabled between the upper tiers.
Prerequisites:
If the FortiSwitch ports used for the FortiLink connection have auto-discovery-fortilink enabled, executing
authorization on FortiGate will trigger the transformation to FortiLink mode automatically.
config switch interface
edit "port1"
set auto-discovery-fortilink enable
……
next
end
Check the CLI output for Connection: Connected to show that FortiLink is up:
execute switch-controller get-conn-status FSWSerialNum
Enable MCLAG on the ICL link between the distribution FortiSwitch devices:
When you enable mclag-icl, MCLAG on the FortiLink interface is enabled automatically and active-active backup
links between the distribution FortiSwitches are established.
Troubleshooting
If an authorized FortiSwitch is always offline, go to the FortiGate CLI and use the command below to see all the
checkpoints. Inspect each checkpoint to find the cause of the problem.
execute switch-controller diagnose-connection S248EPTF18001384
Fortilink
Status ... SWITCH_AUTHORIZED_READY
Last keepalive ... 1 seconds ago
CAPWAP
Remote Address: 2.2.2.2
Status ... CONNECTED
Last keepalive ... 26 seconds ago
HA sync fails
If HA sync fails, use the command below to diagnose and locate the cause.
# diagnose sys ha checksum cluster
is_manage_master()=1, is_root_master()=1
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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_master()=0, is_root_master()=0
debugzone
global: 2b e9 81 38 c2 9d 4f db b7 0e 1f 49 42 c6 1e fb
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
vdom5: 3d dc e7 70 69 22 c3 12 a7 ac 68 06 21 21 ef 8f
vdom3: 89 59 1f 45 7a 75 ae fc 71 bc 42 f4 5e c2 47 c8
vdom2: b2 a5 f3 e7 85 02 62 e5 2a 23 23 64 04 66 76 cc
vdom1: 1f b5 11 61 31 c4 0c 72 2e 97 8d d8 45 7e d6 0c
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
The following recipes provide instructions on configuring switch related authentication and security:
l MAC-based 802.1X authentication on page 992
l Port-based 802.1X authentication on page 996
l MAC layer control - Sticky MAC and MAC Learning-limit on page 999
l Quarantine on page 1000
This example show how to configure MAC-based 802.1X authentication to managed FortiSwitch ports when using
FortiLink. Managed FortiSwitch devices will authenticate and record the MAC addresses of user devices. If there is a
hub after the FortiSwitch that connects multiple user devices, each device can access the network after passing
authentication.
Prerequisites:
l The certificates and authentication protocol supported by the supplicant software and RADIUS server are
compatible.
l The managed FortiSwitches using FortiLink act as authenticators.
Create a firewall policy to allow the RADIUS authentication related traffic from the Fortilink interface to the
outbound interface on the FortiGate:
8. Create a new group, and add the RADIUS server to the Remote Groups list.
9. Click OK.
Configure the guest VLAN, authentication fail VLAN, and other parameters as needed.
Using the GUI:
1. Go to WiFi & Switch Controller > FortiSwitch Security Policies
2. Use the default 802-1X-policy-default, or create a new security policy.
3. Use the RADIUS server group in the policy.
4. Set the Security mode to MAC-based.
5. Configure other fields as necessary.
6. Click OK.
end
next
end
Sessions info:
00:0c:29:d4:4f:3c Type=802.1x,MD5,state=AUTHENTICATED,etime=6,eap_cnt=3
params:reAuth=3600
This example show how to configure Port-based 802.1X authentication to managed FortiSwitch ports when using
FortiLink. Managed FortiSwitch devices will authenticate user devices per each FortiSwitch port. If there is a hub after
the FortiSwitch that connects multiple user devices to the same port, they can all access the network after
authentication, which is not recommended from a security perspective.
Prerequisites:
l The certificates and authentication protocol supported by the supplicant software and RADIUS server are
compatible.
l The managed FortiSwitches using FortiLink act as authenticators.
Create a firewall policy to allow the RADIUS authentication related traffic from the Fortilink interface to the
outbound interface on the FortiGate:
9. Click OK.
Configure the guest VLAN, authentication fail VLAN, and other parameters as needed.
Using the GUI:
Sessions info:
00:0c:29:d4:4f:3c Type=802.1x,MD5,state=AUTHENTICATED,etime=0,eap_cnt=6
params:reAuth=3600
Persistent MAC learning, or Sticky MAC, is a port security feature that lets an interface retain dynamically learned MAC
addresses when a switch is restarted, or an interface goes down and then is brought back online.
Enabling Sticky MAC along with MAC Learning-limit restricts the number of MAC addresses that are learned. This
prevents layer 2 Denial of Service (DoS) attacks, overflow attacks on the Ethernet switching table, and DHCP starvation
attacks by limiting the number of MAC addresses that are allowed while still allowing the interface to learn a specified
number of MAC addresses. The interface is secured because, after the specified limit has been reached, additional
devices cannot connect to the port. Interfaces can be allowed to learn the MAC address of trusted workstations and
servers from the time that the interfaces are connected to the network, until the MAC address limit is reached.
Prerequisites
l Sticky MAC save is hardware and CPU intensive if there are too many entries.
l Dual chip device models (X48 and XX48 FortiSwitch models) do not support MAC Learning-limit on VLANs, but still
support it on FortiSwitch ports.
Check the MAC-table on the FortiSwitch to see that the status of related MAC items on the Sticky MAC enabled
ports has changed from dynamic to static:
Before Sticky-MAC is enabled:
diagnose switch mac-address list
MAC: 08:5b:0e:06:6a:d4 VLAN: 1 Port: port1(port-id 1) Flags: 0x00030440 [ hit dynamic
src-hit native move ]
Saving Sticky-MAC items from the running memory into the database, and deleting unsaved items, will ensure that,
even after the FortiSwitch is rebooted, the trusted MAC addresses will be kept and will not need to be relearned.
execute switch-controller switch-action sticky-mac save all S248EPTF1800XXXX
S248EPTF1800XXXX: Save started...
Warning: Please wait save will take longer time upto 30 seconds...
Collecting config data....Done
Collecting hardware data....Done
Saving....Done
Sticky MAC entries saved = 1 ----------------> Number of saved Sticky MAC items is shown
Configure the MAC Learning-limit under the VLAN or managed FortiSwitch ports view:
VLAN view:
config system interface
edit vsw.aggr1
set switch-controller-learning-limit 10
next
end
Ports view:
config switch-controller managed-switch
edit S248EPTF1800XXXX
config ports
edit port6
set learning-limit 11
next
end
next
end
Quarantine
When the FortiGate detects devices that have lower trust scores, lack mandatory installed software, or are sending out
malicious traffic, an administrator can quarantine the device from the normal switch VLAN to the quarantine VLAN. This
can limit the device's access, or provide them specific information on the quarantine portal page.
Data statistic
This example shows a FortiLink scenario where the FortiGate acts as the switch controller that collects the data
statistics of managed FortiSwitch ports. This is counted by each FortiSwitch and concentrated in the controller.
Sample topology
This example shows one of the key components in the concept of Security Fabric: FortiSwitches in FortiLink. In the
FortiGate GUI, you can see the whole picture of the Security Fabric working for your network security.
Sample topology
Persistent MAC learning
Persistent MAC learning or sticky MAC is a port security feature where dynamically learned MAC addresses are retained
when a switch or interface comes back online. The benefits of this feature include:
l Prevent traffic loss from trusted workstations and servers since there is no need to relearn MAC address after a
restart.
l Protect the switch and the whole network when combined with MAC-learning-limit against security attacks such as
Layer 2 DoS and overflow attacks.
Persistent MAC learning is configured in FortiGate and implemented in FortiSwitch.
This feature is disabled by default. You can use persistent MAC learning together with MAC limiting to restrict the
number of persistent MAC addresses.
This feature is hardware and CPU intensive and can take several minutes depending on the number of entries.
You can only use CLI to configure this feature.
Before saving sticky Mac entries into CMDB, you might want to delete the unsaved sticky MAC items so that only the
items you want are saved.
Saving sticky MAC items copies the sticky MAC items from memory to CMDB on FortiSwitches and FortiGates.
The quad, small, form-factor pluggable plus (QSFP/QSPF28) is a transceiver module that offers high-density 40/100
Gigabit Ethernet connectivity options for data center and high-performance computing networks. The QSFP transceiver
module is a hot-swappable, parallel fiber-optic/copper module with four independent optical transmit and receive
channels. These channels can terminate in another Ethernet QSFP transceiver, or the channels can be broken out to
four separate physical ports.
Configuration of which FortiSwitch ports are split is controlled directly on the FortiSwitch. An administrator needs to
manually log into the FortiSwitch and set the desired split port configuration. After a split port configuration change is
made on the FortiSwitch, it will automatically reboot. If the FortiSwitch was previously discovered or authorized, it
should be deleted to allow the switch to be newly discovery again.
This feature requires a FortiSwitch model with SFP+ 40G ports, and FortiSwitch must be in
Fortlink mode when changing the split configuration.
To use previously discovered FortiSwitch with split ports with the switch controller:
To use FortiSwitch with factory defaults with split ports with the switch controller:
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 is passing through, starting from, or ending on the FortiGate device, and the actions that
the FortiGate device 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). FortiGate devices support
several different log devices, such as FortiAnalyzer, FortiGateCloud, and Syslog servers. A FortiGate's system memory
and local disk can also be configured to store logs, and is also considered a log device.
Reports are used to show 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.
A more comprehensive reporting and monitoring tool for the network is FortiView. It integrates real-time and historical
data into a single view on the FortiGate. For more information, see FortiView on page 225.
Sn list:
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
subcategory:
traffic: forward local multicast sniffer
anomaly: anomaly
This topic describes which log messages are supported by each logging destination.
CIFS No Yes No
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
end
set log-all-domain enable
set block-botnet enable
next
end
Sample log
Sample log
Sample log
Sample log
Sample log
For SSL-UTM-log
#EVENTTYPE="SSL-ANOMALIES"
For SSL-Traffic-log
For SSL-UTM-log
#EVENTTYPE="SSL-ANOMALIES"
Sample log
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.
Troubleshooting
l The following commands display different status/stats 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:
For example, use the following command to display all login system event log:
exe log filter device disk
exe log filter category event
exe 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
match sn=FL-8HFT718900132
<16206> _faz_post_connection()-292: Certificate verification:enabled, Faz verified:1
<16206> _send_queue_item()-518: xfer_status changed from 2 to 1 for global-faz
<16206> _send_queue_item()-523: type=0, cat=0, logcount=0, len=0
<16206> _oftp_send()-487: dev=global-faz type=17 pkt_len=34
......
<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 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
memory
traffic: logs=462 len=389648, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75
event: logs=3724 len=1170237, Sun=670 Mon=700 Tue=531 Wed=0 Thu=392 Fri=747 Sat=684
app-ctrl: logs=16 len=9613, Sun=3 Mon=3 Tue=3 Wed=0 Thu=0 Fri=5 Sat=2
dns: logs=71 len=29833, Sun=0 Mon=0 Tue=0 Wed=0 Thu=71 Fri=0 Sat=0
disk
traffic: logs=462 len=389648, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75 com-
pressed=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 com-
pressed=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 local/remote log device since the miglogd daemon start:
ID=2, duration=70486.
ID=3, duration=1.
FGT-B-LOG (global) # diagnose test application miglogd 14
FGT-B-LOG (global) # diagnose test application miglogd 15
Main miglogd: ID=0, children=2, active-children=2
ID=1, duration=70604.
ID=2, duration=70604.
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 exe log backup or dump log messages to USB.
This command backs up all disk log files and is only available on FortiGates with SSD disk.
Before running exec log backup, we recommend temporarily stopping miglogd and reportd.
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 that is 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 type of logging device that is attached to the FortiGate, use the following command:
To get the present state of the logging device that is attached to the FortiGate, use the following command:
To get the failed log count value, use the following command:
There are three scenarios in which the FortiOS SIP solution are 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
config firewall policy
edit 1
set srcintf "port1"
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"
set service "SIP"
set nat enable
next
end
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:
next
end
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:
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
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.
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
porta of 30000/30001.
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.
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.
HTTP redirect can only be configured in the CLI. To redirect HTTPS traffic, deep
inspection is required.
d. Also set Source and Destination to all, Scheduleto 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.
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 1061
l URL pattern on page 1062
l URL category on page 1062
l HTTP method on page 1063
l HTTP header on page 1064
l User agent on page 1065
l Advanced (source) on page 1066
l Advanced (destination) on page 1067
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:
In this address type, a user can create a hostname as a regular expression. Once created, the hostname address can be
selected on the destination tab of an explicit 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 in the destination tab of an explicit 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/.
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 in the destination tab of an explicit 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 .
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 in the source tab of an explicit 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.
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 in the source tab of an explicit 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].
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 in the destination tab of an explicit 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.
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 in the source tab of an explicit 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 Host to all,
l Request Method to GET,
l User Agent to Google Chrome, and
l HTTP header to Header_Test : Q[A-B].
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 in the destination tab of an explicit 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 .
4. Click OK.
Security profiles must be created before they can be used in a policy, see Security Profiles on
page 493 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
next
end
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.
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.
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 > Fabric Connectors.
b. Click Create New and select Fortinet Single Sign-On Agent from the SSO/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 & Device > 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 & Device > 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.
set dn "dc=fortinetqa,dc=local"
set type regular
set username "CN=root,CN=Users,DC=fortinetqa,DC=local"
set password ENC
6q9ZE0QNH4tp3mnL83IS/BlMob/M5jW3cAbgOqzTBsNTrGD5Adef8BZTquu46NNZ8KWoIoclAMlrGTR0z1IqT8n
7FIDV/nqWKdU0ehgwlqMvPmOW0+S2+kYMhbEj7ZgxiIRrculJIKoZ2gjqCorO3P0BkumbyIW1jAdPTOQb749n4O
cEwRYuZ2odHTwWE8NJ3ejGOg==
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:
5. Also set Destination to all, Schedule to always, Service to webproxy, and Action to ACCEPT.
6. Click OK.
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
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.
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 ENC
I4b2VpJAM5AZsbqGsIJ/EfvYgbN3hmEU7O2PXU9YK0AbmpTiX7Evlo5xy74bkgPniWJrHJ49Gtx8mGb4HcGa2XKdD9b
STvgQqfCcZuLANBSrJg/Qy4V7RyrkKp8B3Zsbj7nN+Rzg5FAoNhnw1Hrf0ZvdSTKvAGN5e+OtILz7lR9jaudydIOpy6
0qq4I7RHeGiVQiXA==
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
set uuid bb7488ee-2a6b-51e9-45c6-1715bdc271d8
set proxy explicit-web
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set service "web"
set action accept
set schedule "always"
set logtraffic all
set groups "NTLM-FSSO"
set webproxy-profile "test"
set utm-status enable
set av-profile "av"
set webfilter-profile "content"
set ssl-ssh-profile "deep-custom"
next
end
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
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
Sandbox inspection is a network process that allows files to be sent to a separate device, such as FortiSandbox, to be
inspected without risking network security. This allows the detection of threats capable of bypassing other security
measures, including zero-day threats.
You can configure your FortiGate device to send suspicious files to FortiSandbox for inspection and analysis. The
FortiGate queries scan results and retrieves scan details. The FortiGate can also download malware packages as a
complementary AV signature database to block future intrusions by the same malware and download URL packages as
complementary web-filtering black lists.
The FortiSandbox uses virtual machines (VMs) running different operating systems to test a file and to determine if it is
malicious. If the file exhibits risky behavior, or is found to contain a virus, a new signature can be added to the
FortiGuard antivirus signature database.
When a FortiGate learns from FortiSandbox that an endpoint is infected, the administrator can quarantine the host, if it
is registered to a FortiClient.
FortiSandbox has a VM pool and processes multiple files simultaneously. The amount of time to process a file depends
on hardware and the number of sandbox VMs used to scan the file. For example, it can take 60 seconds to five minutes
to process a file. FortiSandbox has a robust prefiltering process that, if enabled, reduces the need to inspect every file
and reduces processing time. For more information on enabling prefiltering, refer to the FortiSandbox documentation.
The following are some frequently asked questions about using sandbox inspection with FortiSandbox and FortiGate.
Why is the FortiSandbox Cloud option not available when sandbox inspection is enabled?
This option is only available if you have created a FortiGate Cloud account. For more information, see the FortiGate
Cloud documentation.
Why don't results from FortiSandbox Cloud appear in the FortiGate GUI?
Go to Log & Report > Log Settings and make sure that Send Logs to FortiGate Cloud is enabled and GUI Preferences
is set to Display Logs from FortiGate Cloud .
Make sure that port 3 on the FortiSandbox has an active Internet connection. This is required in order to activate the
FortiSandbox VMs.
Make sure an antivirus profile that sends files to FortiSandbox is enabled for all policies that require sandbox inspection.
Yes, a FortiGate can be in either NAT or transparent mode and support FortiSandbox.
Yes, multiple FortiGates can be supported in-line with FortiSandbox. Note that the FortiSandbox will see all FortiGates
only as one device so there is no way to differentiate reports.
If the FortiGate has a dynamic IP, will the FortiSandbox automatically update the FortiGate?
Yes. Dynamic IPs are supported and the FortiGate will not have to be reconfigured on the FortiSandbox each time.
FortiSandbox is available as a physical or virtual appliance (FortiSandbox Appliance), or as a cloud advanced threat
protection service integrated with FortiGate (FortiSandbox Cloud).
To select the settings for Sandbox Inspection, such as the FortiSandbox type, server, and notifier email, go to
Security Fabric > Settings.
The table below highlights the supported features of both types of FortiSandbox:
Sandbox inspection for FortiGate Yes (FortiOS 5.0.4+) Yes (FortiOS 5.2.3+)
Sandbox inspection for FortiMail Yes (FortiMail OS 5.1+) Yes (FortiMail OS 5.3+)
Sandbox inspection for FortiWeb Yes (FortiWeb OS 5.4+) Yes (FortiWeb OS 5.5.3+)
Dynamic Threat Database updates Yes (FortiOS 5.4+) Yes (FortiOS 5.4+)
for FortiGate
Dynamic Threat Database updates Yes (FortiClient 5.4 for Windows Yes (FortiClient 5.6+ for Windows
for FortiClient only) only)
Note that a separate Dynamic Threat Database is maintained for FortiMail. For more information, see the
FortiSandbox documentation.
Recipes about Sandbox inspection are organized into the following categories:
l Antivirus on page 1089
Antivirus
The following recipes provide information about Sandbox inspection with antivirus:
l Use FortiSandbox appliance with antivirus on page 1089
l Use FortiSandbox Cloud with antivirus on page 1100
Antivirus can use FortiSandbox to supplement its detection capabilities. In real-world situations, networks are always
under the threat of zero-day attacks.
Antivirus 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/risky by FortiSandbox. This helps FortiGate antivirus detect zero-day virus and malware whose signatures are
not found in the FortiGate antivirus Database.
l FortiSandbox can be used with antivirus in both proxy-based and flow-based inspection modes.
l With FortiSandbox enabled, Full Scan mode antivirus can do the following:
l Submit only suspicious files to FortiSandbox for inspection.
l Submit every file to FortiSandbox for inspection.
l Do not submit anything.
l Quick Scan mode antivirus cannot submit suspicious files to FortiSandbox. It can only do the following:
l Submit every file to FortiSandbox for inspection.
l Do not submit anything.
To configure antivirus to work with an external block list, the following steps are required:
1. Enable FortiSandbox on the FortiGate.
2. Authorize FortiGate on the FortiSandbox.
3. Enable FortiSandbox inspection.
4. Enable use of the FortiSandbox database.
2. Use the FortiGate serial number to quickly locate the desired FortiGate and select the link icon to authorize the
FortiGate.
3. Enable the desired VDOM in the same manner.
4. The link icon changes from an open to closed link. This indicates that the FortiSandbox has authorized this
FortiGate.
3. Files can be excluded from being sent to FortiSandbox based on their file types by choosing from a list of supported
file types.
4. Files can also be excluded from being sent to FortiSandbox by using wild card patterns.
5. Select Apply.
3. Select Apply.
l Update daemon:
FGT_PROXY (global) # diagnose debug application quarantined -1
FGT_PROXY (global) # diagnose debug enable
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
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
addr=172.18.52.154/514, source-ip=0.0.0.0, keep-alive=no.
ssl_opt=3, hmac_alg=0
fortisandbox-fsb3 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-fsb4 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-fsb5 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-fsb6 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
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_PROXY (global) #
Feature overview
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 compliances regarding data storage locations.
l In FortiOS 6.2 and later, users do not require a FortiGate Cloud account to use FortiSandbox Cloud.
l Without a valid AVDB license, FortiGate devices are limited to 100 FortiGate Cloud submissions per day.
l Unlimited FortiGate Cloud submissions are allowed if the FortiGate has a valid AVDB license.
l There is a limit on how many submissions are sent per minute.
l Per minute submission rate is based on the FortiGate model.
l FortiSandbox can be used with antivirus in both proxy-based and flow-based policy inspection modes.
l With FortiSandbox enabled, Full Scan mode antivirus can do the following:
l Submit only suspicious files to FortiSandbox for inspection.
l Submit every file to FortiSandbox for inspection.
l Do not submit anything.
l Quick Scan mode antivirus cannot submit suspicious files to FortiSandbox. It can only do the following:
l Submit every file to FortiSandbox for inspection.
l Do not submit anything.
To configure antivirus to work with an external block list, the following steps are required:
1. Through FortiCare/FortinetOne, register the FortiGate device and purchase a FortiGuard antivirus license
2. Enable FortiSandbox Cloud on the FortiGate
3. Enable FortiSandbox inspection
4. Enable the use of the FortiSandbox database
1. Please see the video How to Purchase or Renew FortiGuard Services for FortiGuard antivirus license purchase
instructions.
2. Once a FortiGuard license has been purchased or activated, users will be provided with a paid FortiSandbox Cloud
license.
a. Go to Global > Main Dashboard to view the FortiSandbox Cloud license indicator.
1. Go to Global > Security Fabric > Settings and set the Sandbox Inspection toggle to the On position.
2. Select FortiSandbox Cloud and choose a region from the dropdown list.
4. When the FortiGate is connected to the FortiSandbox Cloud, FortiSandbox's current database version is displayed.
3. Files can be excluded from being sent to FortiSandbox based on their file types by choosing from a list of supported
file types.
4. Files can also be excluded from being sent to FortiSandbox by using wild card patterns.
5. Select Apply.
3. Select Apply.
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=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
quar_fsb_handle_quar()-1439: added a req-6 to fortisandbox-fsb1, vfid=1, oftp-name=[].
__quar_start_connection()-908: start server fortisandbox-fsb1-172.18.52.154 in vdom-1
[103] __ssl_cert_ctx_load: Added cert /etc/cert/factory/root_Fortinet_Factory.cer, root ca
Fortinet_CA, idx 0 (default)
[551] ssl_ctx_create_new_ex: SSL CTX is created
[578] ssl_new: SSL object is created
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
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
addr=172.18.52.154/514, source-ip=0.0.0.0, keep-alive=no.
ssl_opt=3, hmac_alg=0
fortisandbox-fsb3 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-fsb4 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-fsb5 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
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.
Initializing firewall...
System is starting...
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
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 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 # dia fdsm fmg-auto-discovery-status
dhcp: fmg-ip=172.18.60.115, fmg-domain-name='', config-touched=1(/bin/dhcpcd)
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 # dia fdsm fmg-auto-discovery-status
dhcp: fmg-ip=0.0.0.0, fmg-domain-name='', config-touched=1(/bin/dhcpcd)
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
In FortiView, you can filter source IPs or destination IPs with a subnet mask using the x.x.x.x/x format. You can view the
results in real-time or historical mode.
Both logging from disk and logging from FortiAnalyzer are supported.
This example shows how to filter destination IPs with a subnet mask using the x.x.x.x/x format.
FortiView is consolidated within the System Dashboards. FortiView pages are available as widgets that can be added to
the flexible dashboards.
Only core FortiView pages are available in the FortiView menu. All non-core FortiView pages
are available as dashboard widgets.
l Securitydashboard
1. Within the Dashboard menu, select the dashboard you wish to edit (in the example, Top Usage LAN/DMZ).
2. Click the gear button in the bottom-right corner of the screen.
3. Click Add Widget.
4. Under the FortiView section, select FortiView Top N. The Add Dashboard Widget pane opens.
5. Under the FortiView dropdown, select the widget. There are three submenus to choose from: LAN/DMZ, WAN, or
All Segments.
l For example, if you add a Sessions widget to the root VDOM as shown below:
The FortiView Sources and Destinations views leverage UUID to resolve firewall object (address) names for improved
usability.
Requirements
l The Firewall Objects-based view is only available when the data source is disk.
l To have a historical Firewall Objects-based view, address objects' UUIDs need to be logged.
Sample configuration
In this example, firewall addresses have been configured using the commands in To configure firewall addresses in the
CLI:, and each firewall address object is associated with an unique UUID.
In the Sources and Destinations views, firewall objects can be displayed in real-time or in a historical chart. Objects can
also be drilled down for more details.
l This example shows a drill down of 172.16.200.55-PC5 from the Destinations view.
To configure the firewall policy with defined firewall addresses in the CLI:
The Sources view displays avatar and device information (for real-time and historical views). You can also create or edit
device or address definitions.
2. Right-click on a source and select Drill Down to Details. The Summary of box displays the avatar and device
details.
This cloud-based SaaS management service is available through FortiManager. This service is also included in the 360
Protection Bundle.
Once the FortiGate has acquired a contract named FortiManager Cloud, FortinetOne creates a cloud-based
FortiManager instance under the user account. You can launch the portal for the cloud-based FortiManager from
FortinetOne, 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.
1. In the FortiCare portal, ensure you have a product entitlement for FortiManager Cloud.
a. Go to Asset > Information > Entitlement.
b. Take note of your user ID number in the top-right corner.
The FortiManager portal opens. The URL incorporates the user ID for the dedicated instance.
The FortiManager Cloud button can only be selected if you have a FortiManager
Cloud product entitlement.
5. 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.
Traffic and security logs are not supported in the initial version of FortiAnalyzer Cloud.
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.
Limitations
In the FortiOS Security Fabric > Settings pane under Cloud Logging, FortiAnalyzer Cloud is grayed out when you do
not have a FortiAnalyzer Cloud entitlement.
You can also view the FortiAnalyzer Cloud settings in the Log & Report > Log Settings pane.
In FortiAnalyzer Cloud, you can view logs from FortiOS in the Event > All Types pane.
Sample log
Upcoming recipes
Category Recipe
Security Fabric
WiFi
SIP Debugging