FortiOS-6 0 0-Cookbook
FortiOS-6 0 0-Cookbook
Version 6.0.0
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com
FORTINET VIDEO GUIDE
https://video.fortinet.com
FORTINET BLOG
https://blog.fortinet.com
CUSTOMER SERVICE & SUPPORT
https://support.fortinet.com
FORTINET COOKBOOK
https://cookbook.fortinet.com
FORTINET TRAINING & CERTIFICATION PROGRAM
https://www.fortinet.com/support-and-training/training.html
NSE INSTITUTE
https://training.fortinet.com
FORTIGUARD CENTER
https://fortiguard.com/
END USER LICENSE AGREEMENT
https://www.fortinet.com/doc/legal/EULA.pdf
FEEDBACK
Email: [email protected]
March 4, 2019
FortiOS 6.0.0 Cookbook
01-600-000000-20190304
TABLE OF CONTENTS
Change Log 9
Getting started 10
Installing a FortiGate in NAT mode 10
Connecting network devices 10
Configuring interfaces 11
Adding a default route 12
Selecting DNS servers (optional) 13
Creating a policy 13
Results 14
Fortinet Security Fabric installation 16
Configuring Edge 17
Installing Accounting and Marketing 22
Installing Sales 27
Configuring the FortiAnalyzer 33
Adding security profiles (optional) 36
Results 37
VDOM configuration 39
Enabling and creating VDOMs 40
Configuring a management interface 40
Assigning interfaces 41
Creating per-VDOM administrators 43
Configuring the VDOMs 44
Configuring global security profiles 45
Results 46
FortiGate registration and basic settings 48
Registering your FortiGate 48
Setting system time 51
Creating administrators 51
Using a trusted host (optional) 53
Results 55
Verifying FortiGuard licenses and troubleshooting 56
Viewing your licenses 56
Troubleshooting 58
Results 60
Logging FortiGate traffic and using FortiView 62
Configuring log settings 62
Enabling logging 63
Results 63
Creating security policies for different users 66
Creating the Employee user and policy 67
Creating the Accounting user and policy 69
Creating the Admin user, device, and policy 70
Ordering the policy table 72
Results 73
Upgrading FortiGate firmware 74
Change Log
This section contains information about installing and setting up a FortiGate, as well common network configurations.
In this example, you connect and configure a new FortiGate in NAT mode, to securely connect a private network to the
Internet.
In NAT mode, you install a FortiGate as a gateway, or router, between two networks. Typically, you set the FortiGate up
between a private network and the Internet, which allows the FortiGate to hide the IP addresses of the private network
using NAT.
NAT mode is the most commonly used operating mode for a FortiGate.
1. Connect the FortiGate to your ISP-supplied equipment using the Internet-facing interface. This is typically WAN or
WAN1, depending on your model.
2. Connect a PC to the FortiGate, using an internal port (in the example, port 3).
3. Power on the ISP equipment, the FortiGate, and the PC on the internal network.
4. Use the PC to connect to the FortiGate GUI using either FortiExplorer or an Internet browser. For more information
about connecting to the GUI, see the QuickStart Guide for you FortiGate model.
5. Log in using an admin account. The default admin account has the username admin and no password.
Configuring interfaces
1. To edit the Internet-facing interface (in the example, wan1), go to Network > Interfaces.
2. Set the Estimated Bandwidth for the interface based on your Internet connection.
3. Set Role to WAN.
4. To determine which Addressing mode to use, check if your ISP provides an IP address for you to use or if the ISP
equipment uses DHCP to assign IP addresses.
a. If your ISP provides an IP address, set Addressing mode to Manual and set the IP/Network Mask to that
IP address.
b. If your ISP equipment uses DHCP, set Addressing mode to DHCP to allow the equipment to assign an IP
address to WAN1.
5. Edit the lan interface, which is called internal on some FortiGate models.
If your FortiGate doesn't have a default LAN interface, for this step, you can use either an
individual interface or create a software switch to combine the separate interfaces into a
single virtual interface.
1. To create a new default route, go to Network > Static Routes. Typically, you have only one default route. If the
static route list already contains a default route, you can edit it, or delete the route and add a new one.
2. Set Destination to Subnet and leave the destination IP address set to 0.0.0.0/0.0.0.0.
3. Set Gateway to the IP address provided by your ISP and Interface to the Internet-facing interface.
The FortiGate DNS settings are configured to use FortiGuard DNS servers by default, which is sufficient for most
networks.
If you need to change the DNS servers, go to Network > DNS, select Specify, and add Primary and Secondary
servers.
Creating a policy
Some FortiGate models include an IPv4 security policy in the default configuration. If you
have one of these models, edit it to include the logging options shown below, then proceed to
the results section.
1. To create a new policy, go to Policy & Objects > IPv4 Policy. Give the policy a Name that indicates that the
policy will be for traffic to the Internet (in the example, Internet).
2. Set the Incoming Interface to lan and the Outgoing Interface to wan1. Set Source, Destination Address,
Schedule, and Services, as required.
3. Ensure the Action is set to ACCEPT.
4. Turn on NAT and select Use Outgoing Interface Address.
5. Scroll down to view the Logging Options. To view the results later, enable Log Allowed Traffic and select All
Sessions.
Results
4. To view more detailed information about the traffic from the PC, right-click the entry for the PC and select Drill
Down to Details.
5. If your FortiGate model has internal storage and disk logging enabled, a drop-down menu in the top corner allows
you to view historical logging information for the previous 5 minutes, 1 hour, and 24 hours.
6. If you’re not sure whether your model supports disk logging, check the FortiGate Feature/Platform Matrix.
For further reading, check out NAT mode installation.
In this recipe, you configure a Fortinet Security Fabric that consists of four FortiGate devices and a FortiAnalyzer. One
of the FortiGate devices acts as the network edge firewall and root FortiGate of the Security Fabric, while the other
FortiGate devices function as Internal Segmentation Firewalls (ISFWs).
The example network uses the following FortiGate aliases:
l Edge: the root FortiGate in the Security Fabric. This FortiGate is named “Edge” because it’s the only FortiGate
that directly connects to the Internet. This role is also known as the gateway FortiGate.
This FortiGate has already been installed in NAT mode using Installing a FortiGate in
NAT mode on page 10.
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 FortiOS 6.0 Release Notes.
Configuring Edge
In the Security Fabric, Edge is the root FortiGate. This FortiGate receives information from the other FortiGates in the
Security Fabric.
In the example, the following interfaces on Edge connect to other network devices:
l Port 9 connects to the Internet (this interface was configured when Edge was installed)
l Port 10 connects to Accounting (IP address: 192.168.10.2)
l Port 11 connects to Marketing (IP address: 192.168.200.2)
l Port 16 connects to the FortiAnalyzer (IP address: 192.168.55.2)
1. To edit port 10 on Edge, go to Network > Interfaces. Set an IP/Network Mask for the interface (in the example,
192.168.10.2/255.255.255.0).
2. Set Administrative Access to allow FortiTelemetry, which is required so that FortiGate devices in the Security
Fabric can communicate with each other.
3. Repeat the previous steps to configure the other interfaces with the appropriate IP addresses, as listed above.
4. To create a policy for traffic from Accounting to the Internet, go to Policy & Objects > IPv4 Policy and select
Create New.
5. Set Incoming Interface to port 10 and Outgoing Interface to port 9.
6. Enable NAT.
9. To create a policy that allows Accounting and Marketing to access the FortiAnalyzer, go to Policy & Objects >
IPv4 Policy.
10. To enable communication between the FortiGate devices in the Security Fabric, go to Security Fabric > Settings
and enable FortiGate Telemetry. Set a Group name and Group password (the Group password option isn’t
available isn’t available in FortiOS 6.0.3 and later).
11. FortiAnalyzer Logging is enabled by default. Set IP address to an internal address that will later be assigned to
port 1 on the FortiAnalyzer (in the example, 192.168.65.10). Set Upload option to Real Time.
12. Select Test Connectivity. An error appears because the FortiGate isn’t yet authorized on the FortiAnalyzer. This
authorization is configured in a later step.
It's a best practice to enable Device Detection on all interfaces classified as LAN or
DMZ.
9. To add a static route, go to Network > Static Routes. Set Gateway to the IP address of port 10 on Edge.
10. To create a policy to allow users on the Accounting network to access Edge, go to Policy & Objects > IPv4
Policy.
11. To add Accounting to the Security Fabric, go to Security Fabric > Settings. Enable FortiGate Telemetry, then
enter the same Group name and Group password that you set previously on Edge (the Group password
option isn’t available isn’t available in FortiOS 6.0.3 and later).
12. Enable Connect to upstream FortiGate and enter the IP address of port 10 on Edge.
13. FortiAnalyzer Logging is enabled by default. Settings for the FortiAnalyzer are retrieved when Accounting
connects to Edge.
Installing Sales
1. To edit the interface on Marketing that connects to Sales (in the example, port12), go to Network > Interfaces.
2. Set an IP/Network Mask for the interface (in the example, 192.168.135.2/255.255.255.0).
3. Set Administrative Access to allow FortiTelemetry.
4. To create a policy for traffic from Sales to Edge, go to Policy & Objects > IPv4 Policy.
5. Enable NAT.
14. To add a default route, go to Network > Static Routes and select Create New. Set Gateway to the IP address of
the internal 14 interface on Marketing.
15. To create a policy that allow users on the Sales network to access Marketing, go to Policy & Objects > IPv4
Policy.
16. To add Sales to the Security Fabric, go to Security Fabric > Settings. Enable FortiGate Telemetry, then enter
the same Group name and Group password that you set previously..
17. Enable Connect to upstream FortiGate and enter the IP address of the internal 14 interface on Marketing.
18. FortiAnalyzer Logging is enabled by default. Settings for the FortiAnalyzer are retrieved when Sales connects to
Edge.
To use the FortiAnalyzer in the Security Fabric, make sure that the firmware is compatible with the version of FortiOS on
the FortiGates. To check for compatibility, see the FortiAnalyzer Release Notes.
1. To edit the port on FortiAnalyzer that connects to Edge (in the example, port4), go to System Settings > Network
and select All Interfaces.
2. Set IP Address/Netmask to the IP address that you use to configure the Security Fabric settings on Edge
(192.168.65.10/255.255.255.0).
3. Add a Default Gateway, using the IP address of port 16 on Edge.
The Default Gateway setting may not appear until you save the settings with the new IP
address.
7. After a moment, a warning icon appears beside Edge because the FortiAnalyzer needs administrative access to the
root FortiGate in the Security Fabric.
You may need to refresh the page before the icon appears.
9. On Edge, go to Security Fabric > Settings. FortiAnalyzer Logging now shows Storage usage information.
The Security Fabric allows you to distribute security profiles to different FortiGates in your network, which can lessen the
workload of each device and avoid creating bottlenecks. For example, you can implement antivirus scanning on Edge
while the ISFW FortiGates apply application control and web filtering.
This results in distributed processing between the FortiGates in the Security Fabric, which reduces the load on each
one. It also allows you to customize the web filtering and application control for the specific needs of the Accounting
network since other internal networks may have different application control and web filtering requirements.
This configuration may result in threats getting through Edge, which means you should very closely limit access to the
network connections between the FortiGates in the network.
1. To edit the policy that allows traffic from Accounting to the Internet, connect to Edge and go to Policy & Objects
> IPv4 Policy.
2. Under Security Profiles, enable AntiVirus and select the default profile.
3. SSL Inspection is enabled by default. Set it to the deep-inspection profile.
4. Do the same for the policy that allows traffic from Marketing to the Internet.
5. To edit the policy that allows traffic from the Accounting network to Edge, connect to Accounting and go to Policy
& Objects > IPv4 Policy.
6. Under Security Profiles, enable Web Filter and Application Control. Select the default profile for both.
7. SSL Inspection is enabled by default. Set it to the deep-inspection profile.
Results
1. On Edge, go to Dashboard > Main. The Security Fabric widget displays the names of the FortiGates in the
Security Fabric.
The icons on the top of the widget indicate the other Fortinet devices that can be used in a Security Fabric. Devices
in blue are detected in your network, devices in gray aren’t detected in your network, and devices in red are also not
detected in your network but are recommended for a Security Fabric.
If either of this widgets doesn’t appear on your dashboard, you can add them using the settings button in the
bottom right corner.
2. Go to Security Fabric > Physical Topology. This page shows a visualization of access layer devices in the
Security Fabric.
3. Go to Security Fabric > Logical Topology. This dashboard displays information about the interface (logical or
physical) that each device in the Security Fabric connects.
4. On the FortiAnalyzer, go to Device Manager. The FortiGates are now shown as part of a Security Fabric group.
The * beside Edge indicates that it’s the root FortiGate in the Security Fabric.
5. Right-click on the Security Fabric group and select Fabric Topology. The topology of the Security Fabric is
displayed.
For further reading, check out Configuring the Security Fabric in the FortiOS 6.0 Online Help.
VDOM configuration
In this recipe, you use virtual domains (VDOMs) to provide Internet access for two different companies (called Company
A and Company B) using a single FortiGate.
1. To enable VDOMs, go to System > Settings. Under System Operation Settings, enable Virtual Domains.
2. Select OK to confirm the VDOM mode change. When the change is applied, you are logged out of the FortiGate.
3. Log back in. To edit global settings, select Global from the dropdown menu located in the top-left corner.
4. To create a new VDOM, go to System > VDOM and select Create New. Enter a name (VDOM-A).
By default, root is the management VDOM. You use the management VDOM to access the global settings for the
FortiGate as well as the settings for each VDOM.
1. To configure an interface to connect to the management VDOM, go to Global > Network > Interfaces and edit
an interface (in the example, mgmt).
2. Enable Dedicated Management Port and add the management computers as Trusted Host.
Assigning interfaces
In this example, you assign two interfaces each to VDOM-A and VDOM-B: one for Internet access and one for use by
the local network.
You can’t change the VDOM assignment if an interface is used in an existing FortiGate configuration. You may need to
delete existing policies and routes in order to add a particular interface, as some FortiGate models have default
configurations.
1. To assign an interface that provides VDOM-A with Internet access, go to Network > Interfaces and edit an
interface (in the example, wan 1).
2. Set Virtual Domain to VDOM-A and Role to WAN.
3. Check if your ISP provides an IP address for you to use or if the ISP equipment uses DHCP to assign IP addresses.
l If your ISP provides an IP address, set Addressing mode to Manual and set the IP/Network Mask to that
IP address.
l If your ISP equipment uses DHCP, set Addressing mode to DHCP to allow the equipment to assign an IP
address to WAN1.
4. To assign an interface for the VDOM-A internal network, go to Network > Interfaces and edit the interface (in the
example, port 1).
5. Set Virtual Domain to VDOM-A and Role to LAN.
6. Set Addressing Mode to Manual, assign an IP/Network Mask to the interface (in the example,
192.168.46.1/255.255.255.0), and set Administrative Access to HTTPS, PING, and SSH.
7. If you need to assign IP addresses to devices on your internal network, enable DHCP Server.
Per-VDOM administrator accounts only allow administrative access to specific VDOMs. By creating per-VDOM
administrators, you allow both Company A and Company B to manage their respective VDOMs without allowing access
to settings for other VDOMs or the global settings.
1. To create a per-VDOM administrator for VDOM-A, go to System > Administrators and select Create New >
Administrator.
2. Enter a Username and set Type to Local User. Enter and confirm a Password. Set Administrator Profile to
prof_admin.
You must use either the prof_admin or a custom profile for per-VDOM administrators.
3. Remove the root VDOM from the Virtual Domains list and add VDOM-A.
1. Access VDOM-A using the dropdown menu located in the top-left corner.
2. To add a static route, go to Network > Static Routes and select Create New.
3. Set Destination to Subnet and leave the destination IP address set to 0.0.0.0/0.0.0.0.
4. Set Gateway to the IP address provided by your ISP and Interface to the Internet-facing interface.
5. To create a new policy, go to Policy & Objects > IPv4 Policy and select Create New.
6. Set the Incoming Interface to port 1 and set the Outgoing Interface to wan 1.
You can create two types of security profiles for VDOMs: per-VDOM profiles that are only available to a specific VDOM,
and global security profiles which are available for use by multiple VDOMs. You can use both types of profiles for your
configuration.
Global profiles are available for the following security features:
l Antivirus
l Application control
l Data leak prevention
l Intrusion prevention
l Web filtering
Each security feature has at least one default global profile. Global profiles are identified by the “g-” at the beginning of
the profile name.
Some security profile features, such as URL filters, are not available for use in a global profile.
1. To edit the default global web filter, go to Global > Security Profiles > Web Filter and edit g-default.
2. Right-click the Bandwidth Consuming category and select Block.
Results
1. Connect to VDOM-A and log in using the VDOM-A administrator account. Only the per-VDOM options are shown.
2. To view the default global web filter, go to Security Profiles > Web Filter and select g-default. The VDOM-A
administrator can’t edit the profile.
3. To view a summary of the VDOM configuration, connect to the management VDOM and go to Global > System >
VDOM.
For further reading, check out Virtual domains overview in the FortiOS 6.0 Online Help.
In this recipe, you will complete these following basic administrative tasks to get a newly installed FortiGate ready for
use:
l Register your FortiGate with a Fortinet Support account.
l Set the system time.
l Create a new administrator and edit the default account.
l Restrict administrative access to a trusted host (optional).
You must register your FortiGate to receive firmware upgrades, FortiGuard updates, and access to Fortinet Support.
Before you register your FortiGate, it must be connected to the Internet.
1. Connect to your FortiGate. A message appears that states that FortiCare registration is required. Select Register
Now.
2. To allow Fortinet Support to keep a complete list of your devices, you should use one account to register all of your
Fortinet products.
If you have a Fortinet Support account, set Action to Login.
4. Your other FortiGuard licenses now show as licensed. There may be a delay before all of them appear as licensed.
1. Go to System > Settings. Under System Time, select your Time Zone and either set the time manually or
select Synchronize with NTP Server.
Creating administrators
1. Go to System > Administrators and create a new account. Set User Name and Password.
2. Set Administrator Profile to super_admin. This profile allows the administrator full access to configure the
FortiGate.
3. Log out of the FortiGate and log in using your new account.
4. To secure your FortiGate, it’s recommended that you change the name and password of the default admin
account. Go to System > Administrators and edit the default account. Change the User Name.
You can configure an administrative account to be accessible only to someone who is using a trusted host. You can set
a specific IP address for the trusted host or use a subnet.
1. Go to System > Administrators and edit the default admin account.
2. Enable Restrict login to trusted hosts. Set Trusted Host 1 to the static IP address of the computer you use to
administer the FortiGate.
Results
1. Attempt to log in using the original credentials for the default account. Access is denied.
2. Log in using the new credentials for the default account. Access is granted.
3. Go to Log & Report > System Events. You can see the successful and failed login attempts in the events list.
For system events to appear in the GUI, you must configure disk logging in the log
settings on the FortiGate. This option is only available on FortiGate models that have an
internal hard drive.
For further reading, check out Basic Administration in the FortiOS 6.0 Online Help.
In this recipe, you verify that your FortiGate displays the correct FortiGuard licenses and troubleshoot any errors. You
must register your FortiGate before it can show your FortiGuard licenses.
1. To view your licenses, go to the Dashboard and find the Licenses widget. The FortiGuard licenses are listed, with
their status indicated:
2. The widget only displays licenses for features you enabled in feature visibility. To enable more features, go to
System > Feature Visibility.
3. The Web Filtering license only appears as active when a web filter profile is applied to a firewall policy.
When you apply the profile, a warning will appear stating that web filtering doesn't have a
valid license. You can ignore this for the moment.
4. You can also view FortiGuard license information by going to System > FortiGuard.
Troubleshooting
Connecting to FortiGuard
1. To prompt your FortiGate to connect to FortiGuard, connect to the CLI and use the following command:
diagnose debug application update -1
diagnose debug enable
execute update-now
2. If your FortiGate has multiple VDOMs, make sure that you use the management VDOM and that the VDOM has
Internet access. To set the proper VDOM as the management VDOM, use the following command:
config system global
set management-vdom
end
If you're updating FortiGuard using a FortiManager, the FortiGuard Filtering Port can
also be 80.
1. To test if your DNS can reach FortiGuard, use the following CLI command:
execute ping guard.fortinet.net
2. If you can reach the address, run the following command:
diagnose debug application update -1
diagnose debug enable
execute update-now
3. If you can’t reach the address, go to System > DNS and verify that the settings are correct. Then run the PING
test again.
Contacting Support
Results
1. Go to the Dashboard and view the Licenses widget. Any subscribed services should have a green check mark
beside it.
2. Go to System > FortiGuard. Features and services you’re subscribed to should have a green check mark beside
them.
For further reading, check out FortiGuard in the FortiOS 6.0 Handbook.
In this example, you will configure logging to record information about sessions processed by your FortiGate. You will
then use FortiView to look at the traffic logs and see how your network is being used.
FortiView is a logging tool that contains dashboards that show real time and historical logs. You can filter the
dashboards to show specific results and also drill down for more information about a particular session. Each dashboard
focuses on a different aspect of your network traffic, such as traffic sources of WiFi clients.
Some FortiView dashboards, such as applications and web sites, require you to apply security profiles to traffic before
you can view results.
4. Under Log Settings, set both Event Logging and Local Traffic Log to All.
Enabling logging
Because logging all sessions uses more system resources, it is typically recommended to log only security events.
However, for the purpose of this recipe, all sessions will be logged to ensure that logging has been configured correctly.
1. To edit the Internet policy, go to Policy & Objects > IPv4 Policy.
2. Under Logging Options, enable Log Allowed Traffic and select All Sessions.
Results
3. If you right-click a session in the list, you can choose to end the session, end all sessions, ban the source IP, or filter
logs by the source device.
4. Select the 24 hours view. You can see a historical view of your traffic. To see more information, doubleclick a
session.
Historical views are only available on FortiGate models with internal hard drives.
5. To view a list of the sources in your network traffic, go to FortiView > Traffic from LAN/DMZ > Sources.
6. Right-click on any source listed and select Drill Down to Details. You can view a variety of information about the
source address, including traffic destinations, security policies used, and if any threats are linked to traffic from this
address.
For further reading, check out FortiView in the FortiOS 6.0 Online Help.
In this recipe, you will create multiple security policies, which will apply security inspection to different users based on
which user group they belong to.
This example contains three IPv4 policies:
l Internet: The policy that the Employee user group uses to access the Internet. You use the FortiGate to apply
some security inspection to traffic.
l Accounting: The policy that the Accounting user group uses to access the Internet. You use the FortiGate to apply
increased security inspection to protect sensitive information.
l Admin: The policy that the Admin user group uses, connecting from a specific computer, to access the Internet.
You use the FortiGate to apply limited security inspection.
For information about creating the Internet policy, see Installing a FortiGate in NAT mode on
page 10.
1. To create a new user, go to User & Device > User Definition (in the example, this account is called jpearson).
2. In the User Type section, select Local User.
5. In the Extra Info section, verify that User Account Status is Enabled.
7. To create a new user group, go to User & Device > User Groups (in the example, this group is called
Employees). Add user jpearson to the Members list.
9. To edit the Internet policy, go to Policy & Objects > IPv4 Policy.
10. For Source, set Address to all and User to the Employees group.
11. Under Security Profiles, enable AntiVirus and Web Filter. Set both to use the default profile.
12. SSL Inspection is enabled by default. Set it to the deep-inspection profile.
1. To create another user, go to User & Device > User Definition and select Create New (in the example,
akeating).
2. To create another user group, go to User & Device > User Groups and select Create New (in the example,
Accounting). Add user akeating to the Members list.
3. To create a new Accounting policy, go to Policy & Objects > IPv4 Policy and select Create New.
4. For Source, set Address to all and User to the Accounting group.
5. Under Security Profiles, enable AntiVirus, Web Filter, Application Control, and IPS. Set all of these to use
the default profile.
6. SSL Inspection is enabled by default. Set it to the deep-inspection profile.
1. To create another user, go to User & Device > User Definition and select Create New (in the example, tal-
jamil).
2. To create another user group, go to User & Device > User Groups and select Create New (in the example,
Admin). Add user tal-jamil to the Members list.
3. To add a new device, go to User & Device > Custom Devices & Groups and select Create New.
4. Set Alias to AdminPC and enter the MAC Address of the PC. Select the appropriate Device Type.
6. To create a new Admin policy, go to Policy & Objects > IPv4 Policy and select Create New.
7. For Source, set Address to all, User to the Admin group, and Device to the AdminPC.
8. Under Security Profiles, enable AntiVirus and set it to use the default profile.
9. SSL Inspection is enabled by default. Set it to the deep-inspection profile.
1. To view the policy table, go to Policy & Objects > IPv4 Policy. Select the By Sequence view, which shows the
policies in the order that they are used by your FortiGate.
Currently, the policies are arranged in the order you created them, with the oldest policy at the top of the list.
2. To have the correct traffic flowing through each policy, you must arrange them so that the more specific policies are
located at the top.
To rearrange the policies, select the column on the far left (in the example, ID) and drag the policy to the required
Results
1. From any PC in the internal network, attempt to browse the Internet. A log in screen will appear. Use the jpearson
account to log in. After authentication, you can connect to the Internet.
If a certificate error occurs during the authentication process, browse to a different site
and re-attempt user authentication.
2. Go to Monitor > Firewall User Monitor. The list shows jpearson is online.
5. The Firewall User Monitor now shows akeating is online and you can access the Internet.
6. From the AdminPC, attempt to browse the Internet. Log in using the tal-jamil account.
7. The Firewall User Monitor now shows tal-jamil is online and you can access the Internet.
8. If you attempt to log in from any other device using the tal-jamil account, the account will authenticate; however,
you will not have Internet access.
9. Go to FortiView >All Segments> Policies and select the 5 minutes view. You can see traffic hitting all three
policies and that each user's traffic is flowing through the correct policy.
For further reading, check out Firewall policies in the FortiOS 6.0 Online Help.
In this example, you upgrade your FortiGate firmware from FortiOS 6.0.0 to 6.0.1.
1. To check which firmware version you’re using, go to the Dashboard and view the System Information widget,
which shows the current Firmware.
2. To find out if a new FortiOS version is available, go to System > Firmware. If new firmware is available, a notice
appears under Current version.
When a new FortiOS version is released, it may not be listed on your FortiGate right away.
If this occurs, download the firmware from Fortinet Support, then use Upload Firmware
to upgrade your FortiGate.
1. Under FortiGuard Firmware, select Latest. A notice may appear stating that there is no valid upgrade path for
this firmware version. If this is the case, select All available instead and find a suitable firmware version for your
FortiGate.
For more information about the upgrade path, go to Fortinet Support.
2. If no warning appears, select Release notes to learn more about the firmware build. Release notes are also
available at the Fortinet Documentation Library.
3. To upgrade your FortiGate, select Backup config and upgrade. When prompted, select Continue.
4. Save the backup of your current FortiGate configuration, in case you need to restore it after the upgrade process.
Results
1. The FortiGate uploads and installs the firmware, then restarts. This process takes a few minutes. When the
firmware is installed, the FortiGate login appears.
2. Go to the Dashboard. The System Information widget shows the new Firmware version.
In this recipe, you create tag categories and tags for your network. By applying these tags to different devices,
interfaces, and addresses, you identify the location and function of each part of your Security Fabric and increase
network visibility.
In this example, you use tags to identify the following things about devices in the Security Fabric:
l Physical location
l Department
l Network administrators
1. To create the tag category for physical location, connect to Edge and go to System > Tags.
2. Set Tag Category to Location. Because each device in the network can only have one location, disable Allow
multiple tag selection.
3. Add Tags for the first floor, second floor, and third floor.
4. Under Tag Scope, set Device to Mandatory.
8. For the network administrators tag, enable Allow multiple tag selection.
11. Because the configuration of tag categories and tags isn’t synchronized across the Security Fabric, you must
connect to each FortiGate device separately and add the appropriate tags for the part of your network that uses
that FortiGate.
Connect to Accounting and repeat the previous steps to create the tags that are shown.
Applying tags
1. To apply tags to devices in your network, go to User & Device > Device Inventory.
2. Edit the Accounting FortiGate.
3. Under Tags, add the following tags:
l For Department, add the Accounting tag
l For Location, add the Third floor tag
l For Network administrators, add the Robert and Lisa tags
4. Edit all other devices listed and apply the appropriate tags for department, location, and administrators.
5. To apply tags to interfaces in your network, go to Network > Interfaces. Edit the interface that connects Edge and
Accounting (in the example, port 10).
6. Under Tags, set Department to Accounting.
7. Edit all other interfaces and apply the appropriate tag for department.
8. To apply tags to addresses in your network, go to Policy & Objects > Addresses. Edit the address for the
Accounting subnet.
9. Under Tags, set Department to Accounting.
10. Edit all other addresses and apply the appropriate tag for department.
11. To apply tags to devices in on the accounting network, connect to Accounting and go to User & Device > Device
Inventory.
12. Edit a computer on this network.
13. Under Tags, add the following tags:
l For Department, add the Accounting tag
l For Location, add the Third floor tag
lFor Network administrators, add the Robert tag
14. Apply the appropriate tags to other devices, interfaces, and addresses on this network.
Results
1. To sort devices and interfaces by tags, connect to Edge and go to Security Fabric > Logical Topology.
2. In the Search field, enter Robert. The devices that have the Robert tag are highlighted.
3. To view more information about a highlighted device, including tags, hover over that device in the topology. The
Robert tag is highlighted.
Port forwarding
In this recipe, you configure port forwarding to open specific ports and allow connections from the Internet to reach a
server located behind the FortiGate. This allows Internet users to reach the server through the FortiGate without
knowing the server’s internal IP address. Users can also connect using only the ports that you choose.
In this example, you open TCP ports 8096 (HTTP), 21 (FTP), and 22 (SSH) for remote users to communicate with the
server behind the firewall. The external IP address of the server is 172.25.176.60, which is mapped to the internal IP
address 192.168.70.10.
1. To create a virtual IP (VIP) address for port 8096, go to Policy & Objects > Virtual IPs and create a new virtual
IP address.
2. Set External IP Address/Range to 172.25.176.60 and set Mapped IP Address/Range to 192.168.65.10.
3. Enable Port Forwarding. Set Protocol to TCP, set External Service Port to 8096, and set Map to Port to
8096.
4. Create a second VIP address for port 21. Set both External Service Port and Map to Port to 21.
5. Create a third VIP address for port 22. Set both External Service Port and Map to Port to 22.
1. To add the new virtual IP addresses to a virtual IP group, go to Policy & Objects > Virtual IPs and create a new
group.
2. Set the new virtual IP addresses as Members of the group.
1. To allow Internet users to reach the server, go to Policy & Objects > IPv4 Policy and create a new policy.
2. Set Incoming Interface to your Internet-facing interface, Outgoing Interface to the interface connected to the
server, and Destination Address to the VIP group.
NAT is disabled for this policy so that the server sees the original source addresses of the packets it receives. This
is the preferred setting for a number of reasons. For example, the server logs are more meaningful if they record
the actual source addresses of your users.
If the FortiGate has Central NAT enabled, the VIP objects won't be available for selection
in the policy editing window.
Results
2. Next, ensure that TCP port 21 is open by using an FTP client to connect to the FTP server from a remote
connection on the other side of the firewall.
3. Finally, ensure that TCP port 22 is open by connecting to the SSH server from a remote connection on the other
side of the firewall.
For further reading, check out Virtual IPs in the FortiOS 6.0 Online Help.
Security Rating
In this recipe, you run a Security Rating check, which analyzes the Fortinet Security Fabric deployment to identify
potential vulnerabilities and highlight best practices.
Using the Security Rating can help you improve your network configuration, deploy new hardware and software, and
gain more visibility and control over your network. By regularly checking your Security Rating and your Security Rating
Score, and making the recommended improvements, you can have confidence that your network is getting more secure
over time.
To run all available checks, you must have a valid Security Rating license from FortiGuard. If you don’t have a license,
only certain checks are available. For more information about these checks, see Security Best Practices & Security
Rating Feature.
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 FortiOS 6.0 Release Notes.
1. Go to the Dashboard and locate the Security Rating widget. In the example, the widget doesn’t display any
information because it’s not properly configured.
2. Once you configure the widget, it displays a comparison between your Security Rating and the ratings of other
organizations. You can compare your rating to the ratings of organizations that belong to all industries or the same
industry as your organization. You can also compare your rating with organizations in your region or all regions.
3. To change which organizations your score is compared to, select the options menu in the top right corner, then
select Settings.
1. On Edge, go to Security Fabric > Security Rating. The Security Rating runs automatically on the root
FortiGate. However, if you want more recent results, select Run Now to run another Security Rating.
2. You can also select whether to run the Security Rating on All FortiGates or on specific FortiGate devices in the
Security Fabric.
3. At the top of the page, you can see your network’s Security Rating, which shows which percentile your network is
in compared to other organizations. You can also see your Security Rating Score, which is based on how many
checks your Security Fabric passed or failed, and how many FortiGate units are in your network.
4. Further down the page, you can see information about each failed check, including which FortiGate failed the
check, the effect on your Security Rating Score, and recommendations for how you can the issue.
5. In the next step of the Security Rating, you can apply recommendations marked as Easy Apply to any FortiGate in
the Security Fabric. However, if the Security Rating results are older than 30 minutes, you must first run it again to
make sure all information is current and accurate.
6. By using Easy Apply, you can change the configuration of any FortiGate in the Security Fabric from the root
FortiGate.
7. Select all the changes that you want to make, then select Apply Recommendations.
Results
1. Go to the Dashboard. The Security Rating widget displays information from the most recent Security Rating
check.
2. Go to Security Fabric > Physical Topology. Each FortiGate has a Security Rating indicator, which is circle that
contains a number. The number shows how many checks the FortiGate failed and the color shows the severity of
failed checks (red for critical, orange for high, yellow for medium, and blue for low).
3. To view the failed checks on a specific FortiGate device, select the Security Rating indicator on the FortiGate in the
topology.
4. A screen appears, showing the Security Rating recommendations for that unit. You can also apply Easy Apply
recommendations from here.
For further reading, check out Running a Security Fabric Rating in the FortiOS 6.0 Online Help.
Automation stitches
In this recipe, you configure Automation stitches for your Fortinet Security Fabric. Each Automation pairs an event
trigger and one or more actions, which allows you to monitor your network and take appropriate action when the Security
Fabric detects a threat. You can use Automation stitches to detect events from any source in the Security Fabric and
apply actions to any destination.
In this example, you create the following Automation stitches:
l Ban a compromised host’s IP address.
l Send an email alert when HA failover occurs.
In this example, the Security Fabric consists of Edge, an HA cluster that is the root FortiGate of the Security Fabric, and
three ISFW FortiGate devices (Accounting, Marketing, and Sales). You configure the Automation stitches on the root
FortiGate and the settings are synchronized with the other FortiGate devices in the Security Fabric.
1. To create a new Automation that bans the IP address of a compromised host, go to Security Fabric >
Automation and select Create New.
2. Set FortiGate to All FortiGates.
3. Set Trigger to Compromised Host. Set IOC level threshold to High.
4. Set Action to IP Ban.
5. Create a second Automation that sends an email alert when HA failover occurs.
6. Set FortiGate to Edge-Primary, which is part of the only HA cluster in the Security Fabric.
7. Set Trigger to HA Failover. Set Action to Email.
1. If your FortiOS version is 6.0.2 or higher, to test the Automation stitches go to Security Fabric > Automation,
right-click the Automation, and select Test Automation Stitch.
2. If your FortiOS version is 6.0.0 or 6.0.1, use the following instructions to test the automation stitches.
Instead of testing the Automation that blocks compromised hosts, the following steps simulate its effects by
manually blocking the IP address of a PC on your network. Go to Security Fabric > Physical Topology and
locate a PC on your network. Right-click the PC and select Ban IP.
4. To test the Automation for HA failover, go to Edge-Primary. In the administrative drop-down menu, select System
> Reboot.
Results
1. If you have simulated the the Automation that blocks compromised hosts, the banned device can no longer access
the Internet.
2. When HA failover occurs or when the Automation is tested, an email similar to the one shown is sent to the email
that you configured in the Automation.
In this recipe, you will add a FortiSandbox to the Fortinet Security Fabric and configure each FortiGate in the network to
send suspicious files to FortiSandbox for sandbox inspection. The FortiSandbox scans and tests these files in isolation
from your network.
This example uses the Security Fabric configuration created in Fortinet Security Fabric installation on page 16. The
FortiSandbox connects to the root FortiGate in the Security Fabric, known as Edge. There are two connections between
the devices:
l FortiSandbox port 1 (administration port) connects to Edge port 16
l FortiSandbox port 3 (VM outgoing port) connects to Edge port 13
If possible, you can also use a separate Internet connection for FortiSandbox port 3, rather than connecting through the
Edge FortiGate to use your main Internet connection. This configuration avoids having IP addresses from your main
network blacklisted if malware that’s tested on the FortiSandbox generates an attack. If you use this configuration, you
can skip the steps listed for FortiSandbox port 3.
1. On Edge (the root FortiGate in the Security Fabric), go to Security Fabric > Security Rating.
2. Since you haven’t yet installed a FortiSandbox in your network, the Security Fabric fails the Advanced Threat
Protection check. In the example, the Security Rating Score decreases by 30 points for each of the four
FortiGates in the Security Fabric.
4. Edit port 3. This port is used for outgoing communication by the virtual machines (VMs) running on the
FortiSandbox. It’s recommended that you connect this port to a dedicated interface on your FortiGate to protect the
rest of the network from threats that the FortiSandbox is currently investigating.
5. Set IP Address/Netmask to an internal IP address (in the example, 192.168.179.10/255.255.255.0).
6. To add a static route, go to Network > System Routing. Set Gateway to the IP address of the FortiGate
interface that port 1 connects to (in the example, 192.168.65.2).
7. Connect to Edge.
8. To configure the port that connects to port3 on the FortiSandbox (in the example, port13), go to Network >
Interfaces. Set IP/Network Mask to an address on the same subnet as port 3 on the FortiSandbox (in the
example, 192.168.179.2/255.255.255.0)
1. Connect to Edge.
2. To create a policy that allows connections from the FortiSandbox to the Internet, go to Policy & Objects > IPv4
Policy.
3. Connect to FortiSandbox.
4. Go to Scan Policy > General and select Allow Virtual Machines to access external network through outgoing
port3. Set Gateway to the IP address of port 13 on the FortiGate.
5. Go to the Dashboard and locate the System Information widget. Verify that VM Internet Access has a green
check mark beside it.
1. Connect to Edge.
2. To add FortiSandbox to the Security Fabric, go to Security Fabric > Settings. Enable Sandbox Inspection.
3. Make sure FortiSandbox Appliance is selected and set Server to the IP address of port 1 on the FortiSandbox.
4. Select Test Connectivity. An error message appears because Edge hasn’t been authorized on the FortiSandbox.
5. Edge, as the root FortiGate, pushes FortiSandbox settings to the other FortiGates in the Security Fabric. To verify
this, connect to Accounting and go to Security Fabric > Settings.
6. On the FortiSandbox, go to Scan Input > Device. The FortiGates in the Security Fabric (Edge, Accounting,
Marketing, and Sales) are listed but the Auth column indicates that the devices are unauthorized.
7. Select and edit Edge. Under Permissions & Policies, select Authorized.
You can apply sandbox inspection with three types of security inspection: antivirus, web filter, and FortiClient
compliance profiles. In this step, you add sandbox to all FortiGate devices in the Security Fabric individually, using the
profiles that each FortiGate applies to network traffic.
In order to pass the Advanced Threat Protection check, you must add sandbox inspection to antivirus profiles for all
FortiGate devices in the Security Fabric.
1. Go to Security Profiles > AntiVirus and edit the default profile.
2. Under Inspection Options, set Send Files to FortiSandbox Appliance for Inspection to All Supported
Files.
3. Enable Use FortiSandbox Database, so that if the FortiSandbox discovers a threat, it adds a signature for that
file to the antivirus signature database on the FortiGate.
4. Go to Security Profiles > Web Filter and edit the default profile.
5. Under Static URL Filter, enable Block malicious URLs discovered by FortiSandbox. If the FortiSandbox
discovers a threat, the URL that threat came from is added to the list of URLs that are blocked by the FortiGate.
6. Go to Security Profiles > FortiClient Compliance Profiles and edit the default profile. Enable Security
Posture Check.
7. Enable Realtime Protection and Scan with FortiSandbox.
Results
1. If a FortiGate in the Security Fabric discovers a suspicious file, it sends the file to the FortiSandbox.
You can view information about scanned files on either the FortiGate that sent the file or the FortiSandbox. On one
of the FortiGate devices, go to the Dashboard and locate the Advanced Threat Protection Statistics widget.
This widget shows files that both the FortiGate and FortiSandbox scan.
2. On the FortiSandbox, go to System > Status and view the Scanning Statistics widget for a summary of scanned
files.
3. You can also view a timeline of scanning in the File Scanning Activity widget.
4. On Edge, go to Security Fabric > Security Rating and run a rating. When it is finished, select the All Results
view.
In the example, all four FortiGate devices in the Security Fabric pass the Advanced Threat Protection check and
the Security Rating Score increases by 9.7 points for each FortiGate.
In this recipe, you add a FortiManager to the Security Fabric. This simplifies network administration because you
manage all of the FortiGate devices in your network from the FortiManager.
In this example, you add the FortiManager to an existing Security Fabric, with an HA cluster called Edge as the root
FortiGate and three internal FortiGates: Accounting, Marketing, and Sales. Network resources, such as a FortiManager,
are located on the subnet 192.168.65.x.
3. To configure the interface on the FortiManager, connect to the FortiManager, go to System Settings > Network,
select All Interfaces, and edit port 4.
4. Set IP Address/Netmask to an internal IP address (in the example, 192.168.65.30/255.255.255.0).
5. Select Routing Table and add a default route for port 4. Set Gateway to the IP address of port 16 on Edge.
6. If you haven’t already done so, connect the FortiManager and Edge.
2. To allow the FortiManager to access the Internet, go to Policy & Objects > IPv4 Policy, and create a new
policy.
1. To enable central management, connect to Edge, go to Security Fabric > Settings, and enable Central
Management.
2. Set Type to FortiManager, Mode to Normal, and set IP/Domain Name to the IP address of port 4 on the
FortiManager.
3. After you select Apply, a message appears stating that the FortiManager received the message and Edge is
waiting for management confirmation.
4. Edge, as the root FortiGate, pushes FortiManager settings to the other FortiGate devices in the Security Fabric. To
verify this, connect to Accounting and go to Security Fabric > Settings.
5. To confirm the management connection, connect to the FortiManager and go to Device Manager >
Unregistered Devices. Select the FortiGate devices and select + Add.
7. Connect to Edge. A warning message appears stating that the FortiGate is now managed by a FortiManager.
Select Login Read-Only.
8. Go to Security Fabric > Settings. Under Central Management, the Status is now Registered on
FortiManager.
Results
1. The FortiGate devices are on the Managed FortiGate list and appear as part of a Security Fabric group. The *
beside Edge indicates that it’s the root FortiGate in the Security Fabric.
2. Right-click on any of the FortiGate devices and select Fabric Topology. The topology of the Security Fabric is
displayed.
This recipe provides an example of how you can configure redundant Internet connectivity for your network using SD-
WAN. This allows you to load balance your Internet traffic between multiple ISP links and provides redundancy for your
network’s Internet connection if your primary ISP is unavailable.
1. Connect the FortiGate to your ISP devices by connecting the Internet-facing (WAN) ports on the FortiGate to your
ISP devices. Connect WAN1 to the ISP that you want to use for most traffic, and connect WAN2 to the other ISP.
2. Before you can configure FortiGate interfaces as SD-WAN members, you must remove or redirect existing
configuration references to those interfaces in routes and security policies. This includes the default Internet access
policy that’s included with many FortiGate models. Note that after you remove the routes and security policies,
traffic can’t reach the WAN ports through the FortiGate. Redirecting the routes and policies to reference other
interfaces avoids your having to create them again later. After you configure SD-WAN, you can reconfigure the
routes and policies to reference the SD-WAN interface. Remove existing configuration references to interfaces:
a. Go to Network > Static Routes and delete any routes that use WAN1 or WAN2.
b. Go to Policy & Objects > IPv4 Policy and delete any policies that use WAN1 or WAN2.
3. Create the SD-WAN interface:
a. Go to Network > SD-WAN and set Status to Enable.
b. Under SD-WAN Interface Members, select + and select wan1. Set the Gateway to the default gateway for
this interface. This is usually the default gateway IP address of the ISP that this interface is connected to.
Repeat these steps to add wan2.
c. Go to Network > Interfaces and verify that the virtual interface for SD-WAN appears in the interface list. You
can expand SD-WAN to view the ports that are included in the SD-WAN interface.
4. Configure SD-WAN load balancing:
a. Go to Network > SD-WAN Rules and edit the rule named sd-wan.
b. In the Load Balancing Algorithm field, select Volume, and prioritize WAN1 to serve more traffic. the example,
the ISP connected to WAN1 is a 40Mb link, and the ISP connected to WAN2 is a 10Mb link, so we balance the
weight 75% to 25% in favor of WAN1.
c. You can view link quality measurements on the Performance SLA page. The table displays information about
configured health checks. The values in the Packet Loss, Latency, and Jitter columns apply to the server that
the FortiGate is using to test the health of the SD-WAN member interfaces. The green (up) arrows indicate
only that the server is responding to the health checks, regardless of the packet loss, latency, and jitter values,
and do not indicate that the health checks are being met.
c. Go to Monitor > SD-WAN Monitor to view the number of sessions, bit rate, and more information for each
interface.
9. To test failover of the redundant Internet configuration, you must simulate a failed Internet connection to one of the
ports. Do so by physically disconnecting the Ethernet cable connected to WAN1:
a. Verify that users still have Internet access by navigating to Monitor > SD-WAN Monitor. The Upload and
Download values for WAN1 show that traffic is not going through that interface.
b. Go to Network > SD-WAN. In the SD-WAN Usage section, you can see that bandwidth, volume, and
sessions have diverted entirely through WAN2.
c. Users on the internal network should not notice the WAN1 failure. Likewise, if you are using the WAN1
gateway IP address to connect to the admin dashboard, nothing should change from your perspective. It
appears as though you are still connecting through WAN1. After you verify successful failover, reconnect the
WAN1 Ethernet cable.
Authentication
In this recipe, you use agent-based Fortinet single sign-on (FSSO) to allow users to login to the network once with their
Windows AD credentials and seamlessly access all appropriate network resources.
This example uses the FSSO agent in advanced mode. The main difference between advanced and standard mode is
the naming convention used when referring to username information. Standard mode uses Windows convention:
Domain\Username. Advanced mode uses LDAP convention: CN=User, OU=Name, DC=Domain.
Advanced mode is required for multi-domains environments.
Connect to the Windows AD server and download the FSSO agent from Fortinet Support.
1. To install the agent, open the installer file and use the installation wizard.
2. Set a User Name and Password for the FSSO domain administrator.
3. For the Install Options, select Advanced to use advanced mode instead of standard.
5. Set the Collector Agent IP address and the Collector Agent listening port.
7. Exclude any users that you don’t want to monitor, including the administrator.
1. To configure the settings for your network, open the FSSO agent. You can use the default for most settings.
Because you have installed FSSSO in advanced mode, you need to configure LDAP to use with FSSO.
1. To configure the LDAP service, go to User & Device > LDAP Servers and select Create New.
2. Enter all information about your LDAP server. Select Test Connectivity. If your information is correct,
Connection status is Successful.
3. Create a Fabric Connector to the FSSO agent by going to Security Fabric > Fabric Connectors and select +
Create New.
4. Under SSO/Identity, select Fortinet Single Sign-On Agent.
5. Set the Name and enter the IP address and password for the Primary FSSO Agent.
6. Set Collector Agent AD access mode to Advanced and set LDAP Server to the new LDAP service.
7. Your FortiGate displays information retrieved from the AD server. Select Groups, then right-click the FSSO group
and select + Add Selected.
8. Select Selected.
The FSSO group is shown.
9. To create a user group for FSSO users, go to User & Device > User Groups and select Create New.
10. Enter a group Name and set Type to Fortinet Single Sign-On (FSSO). Add the FSSO users to Members.
11. To create a policy for FSSO users, go to Policy & Objects > IPv4 Policy and select Create New.
12. For Source, set User to the FSSO user group.
Results
Log into a computer on the domain and access the Internet. The FortiGate uses FSSO for authentication and doesn’t
require your credentials to be entered again.
On the FortiGate, go to Monitor > Firewall User Monitor and select Show all FSSO Logons.
In this recipe, you use Fortinet single sign-on (FSSO) in polling mode to allow users to log in to the network once with
their Windows Active Directory (AD) credentials and seamlessly access all appropriate network resources.
1. To configure the LDAP service, go to User & Device > LDAP Servers and select Create New.
2. Enter all information about your LDAP server. Select Test Connectivity. If your information is correct,
Connection status is Successful.
3. To create a Fabric Connector, go to Security Fabric > Fabric Connectors and select Create New.
6. Your FortiGate displays information retrieved from the AD server. Select Groups, then right-click the FSSO group
and select + Add Selected.
7. Select Selected. The list includes the FSSO group.
1. To create a user group for FSSO users, go to User & Device > User Groups and select Create New.
2. Enter a group Name and set Type to Fortinet Single Sign-On (FSSO). Add the FSSO users to Members.
Creating a policy
1. To create a policy for FSSO users, go to Policy & Objects > IPv4 Policy and select Create New.
2. For Source, set User to the FSSO user group.
Results
1. Log in to a computer on the domain and access the Internet. The FortiGate uses FSSO for authentication and
doesn’t require your credentials to be entered again.
2. On the FortiGate, go to Monitor > Firewall User Monitor and select Show all FSSO Logons.
For further reading, check out Single sign-on to Windows AD in the FortiOS 6.0 Online Help.
High availability
This section includes recipes about how you can use high availability (HA) with your FortiGate.
This recipe describes how to add a backup FortiGate to a previously installed FortiGate, to form a high availability (HA)
cluster to improve network reliability.
Before you begin, make sure that the FortiGates are running the same FortiOS firmware version and interfaces are not
configured to get their addresses from DHCP or PPPoE. Also, you can't use a switch port as an HA heartbeat interface.
If necessary, convert the switch port to individual interfaces.
This recipe is in the Fortinet Security Fabric collection. It can also be used as a standalone recipe.
This recipe uses the FortiGate Clustering Protocol (FGCP) for HA. After you complete this recipe, the original FortiGate
continues to operate as the primary FortiGate and the new FortiGate operates as the backup FortiGate.
For a more advanced HA recipe that includes CLI steps and involves using advanced options such as override to
maintain the same primary FortiGate, see High Availability with FGCP (expert) on page 140.
1. Make sure both FortiGates are running the same FortiOS firmware version. Register and apply licenses to the new
FortiGate unit before you add it to the HA cluster.
This includes licensing for FortiCare Support, IPS, AntiVirus, Web Filtering, Mobile Malware, FortiClient,
FortiCloud, and additional virtual domains (VDOMs).
All FortiGates in the cluster must have the same level of licensing for FortiGuard, FortiCloud, FortiClient, and
VDOMs. You can add FortiToken licenses at any time because they're synchronized to all cluster members.
If the FortiGates in the cluster will run FortiOS Carrier, apply the FortiOS Carrier license
before you configure the cluster (and before you apply other licenses). When you apply the
FortiOS Carrier license, the FortiGate resets its configuration to factory defaults, requiring
you to repeat steps performed before applying the license.
2. You can also install any third-party certificates on the primary FortiGate before you form the cluster. Once the
cluster is running, the FGCP synchronizes third-party certificates to the backup FortiGate.
1. On the primary FortiGate, go to System > Settings and change the Host name to identify this as the primary
FortiGate in the HA cluster.
2. Go to System > HA and set the Mode to Active-Passive. Set the Device priority to a higher value than the
default (in the example, 250) to make sure this FortiGate will always be the primary FortiGate. Also, set a Group
name and Password.
Make sure you select Heartbeat interfaces (in the example, port3 and port4). Set the Heartbeat Interface
Priority for each interface to 50.
Since the backup FortiGate isn't available, when you save the HA configuration, the primary FortiGate forms a
cluster of one FortiGate but keeps operating normally.
If these steps don't start HA mode, make sure that none of the FortiGate interfaces use
DHCP or PPPoE addressing.
If there are other FortiOS HA clusters on your network, you may need to change the cluster group ID, using this CLI
command:
config system ha
set group-id 25
end
Connect the backup FortiGate to the primary FortiGate and to the network, as shown in the network diagram at the start
of this use case.
Since these connections disrupt traffic, you should make the connections when the network isn’t processing a lot of
traffic. If possible, make direct Ethernet connections between the heartbeat interfaces of the two FortiGate units.
This example uses two FortiGate-600Ds and the default heartbeat interfaces (port3 and
port4). You can use any interfaces for HA heartbeat interfaces. A best practice is to use
interfaces that don't process traffic, but this is not a requirement. If you are setting up HA
between two FortiGates in a VM environment (for example, VMware or Hyper-V) you must
enable promiscuous mode and allow mac address changes for heartbeat communication to
work. Since the HA heartbeat interfaces must be on the same broadcast domain, for HA
between remote data centers (called distributed clustering) you must support layer 2
extensions between the remote data centers, using technology such as MPLS or VXLAN.
You must use switches between the cluster and the Internet, and between the cluster and the internal networks, as
shown in the network diagram. You can use any good quality switches to make these connections. You can also use one
switch for all of these connections, as long as you configure the switch to separate traffic from the different networks.
1. If required, change the firmware running on the new FortiGate to be the same version as is running on the primary
FortiGate.
2. Enter the following command to reset the new backup FortiGate to factory default settings.
execute factoryreset
You can skip this step if the new FortiGate is fresh from the factory. But if its configuration has been changed at all,
it's a best practice to reset your FortiGate to factory defaults to reduce the chance of synchronization problems.
3. Register and apply licenses to the backup FortiGate before configuring it for HA operation. This includes licensing
for FortiCare Support, IPS, AntiVirus, Web Filtering, Mobile Malware, FortiClient, FortiCloud, Security
Rating, Outbreak Prevention, and additional virtual domains (VDOMs). All FortiGates in the cluster must have
the same level of licensing for FortiGuard, FortiCloud, FortiClient, and VDOMs. You can add FortiToken licenses
at any time because they're synchronized to all cluster members.
If the FortiGates in the cluster will run FortiOS Carrier, apply the FortiOS Carrier license
before you configure the cluster (and before applying other licenses). When you applying
the FortiOS Carrier license the FortiGate resets its configuration to factory defaults,
requiring you to repeat steps performed before applying the license.
4. Click on the System Information dashboard widget and select Configure settings in System > Settings.
Change the FortiGate's Host name to identify it as the backup FortiGate.
If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use
DHCP or PPPoE addressing.
Connect to the GUI of the primary FortiGate. The HA Status widget shows the cluster mode (Mode) and group name
(Group).
It also shows the host name of the primary FortiGate (Master), which you can hover over to verify that the cluster is
synchronized and operating normally. You can click on the widget to change the HA configuration or view a list of
recently recorded cluster events, such as members joining or leaving the cluster.
To view the cluster status, click on the HA Status widget and select Configure settings in System > HA (or go to
System > HA).
If the cluster is part of a Security Fabric, the FortiView Physical and Logical Topology views show information about the
cluster status.
Results
All traffic should now be flowing through the primary FortiGate. If the primary FortiGate becomes unavailable, traffic
fails over to the backup FortiGate. When the primary FortiGate rejoins the cluster, the backup FortiGate should
continue operating as the primary FortiGate.
To test this, ping a reliable IP address from a PC on the internal network. After a moment, power off the primary
FortiGate.
If you are using port monitoring, you can also unplug the primary FortiGate's Internet-facing
interface to test failover
You will see a momentary pause in the ping results, until traffic diverts to the backup FortiGate, allowing the ping traffic
to continue.
64 bytes from 184.25.76.114: icmp_seq=69 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=70 ttl=52 time=8.822 ms\
64 bytes from 184.25.76.114: icmp_seq=71 ttl=52 time=9.034 ms\
64 bytes from 184.25.76.114: icmp_seq=72 ttl=52 time=9.536 ms\
64 bytes from 184.25.76.114: icmp_seq=73 ttl=52 time=8.877 ms\
64 bytes from 184.25.76.114: icmp_seq=74 ttl=52 time=8.901 ms\
Request timeout for icmp_seq 75\
64 bytes from 184.25.76.114: icmp_seq=76 ttl=52 time=8.860 ms\
64 bytes from 184.25.76.114: icmp_seq=77 ttl=52 time=9.174 ms\
64 bytes from 184.25.76.114: icmp_seq=78 ttl=52 time=10.108 ms\
64 bytes from 184.25.76.114: icmp_seq=79 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=80 ttl=52 time=10.861 ms\
64 bytes from 184.25.76.114: icmp_seq=81 ttl=52 time=10.757 ms\
64 bytes from 184.25.76.114: icmp_seq=82 ttl=52 time=8.158 ms\
64 bytes from 184.25.76.114: icmp_seq=83 ttl=52 time=8.639 ms}
You can log into the cluster GUI or CLI using the same IP address as you had been using to the log into the primary
FortiGate. If the primary FortiGate is powered off you will be logging into the backup FortiGate. Check the host name to
verify the FortiGate that you have logged into. The FortiGate continues to operate in HA mode and if you restart the
primary FortiGate, after a few minutes it should rejoin the cluster and operate as the backup FortiGate. Traffic should
not be disrupted when the restarted primary unit rejoins the cluster.
Upgrading the firmware on the primary FortiGate automatically upgrades the firmware on the backup FortiGate. Both
FortiGates are updated with minimal traffic disruption. Always review the Release Notes before you install new
firmware.
1. Click the System Information widget and select Update firmware in System > Firmware. Back up the
configuration and update the firmware from FortiGuard or upload a firmware image file. The firmware installs onto
both the primary and backup FortiGates.
After the upgrade completes, verify that the System Information widget shows the new firmware version.
This recipe describes how to enhance the reliability of a network protected by a FortiGate by adding a second FortiGate
and setting up a FortiGate Clustering Protocol (FGCP) High Availability cluster.
You will configure the FortiGate already on the network to become the primary FortiGate by:
1. Licensing it (if required)
2. Enabling HA
3. Increasing its device priority
4. Enabling override
You will prepare the new FortiGate by:
1. Setting it to factory defaults to wipe any configuration changes
2. Licensing it (if required)
3. Enabling HA without changing the device priority and without enabling override
4. Connecting it to the FortiGate already on the network
The new FortiGate becomes the backup FortiGate and its configuration is overwritten by the primary FortiGate.
This recipe describes best practices for configuring HA and involves extra steps that are not required for a basic HA
setup. If you are looking for a basic HA recipe see High availability with two FortiGates on page 132.
Before you start, the FortiGates should be running the same FortiOS firmware version and their interfaces should not be
configured to get addresses from DHCP or PPPoE.
This recipe features two FortiGate-51Es. FortiGate-51Es have a 5-port switch lan interface. Before configuring HA, the
lan interface was converted to 5 separate interfaces (lan1 to lan5). The lan1 interface connects to the internal network
and the wan1 interface connects to the Internet. The lan4 and lan5 interfaces will become the HA heartbeat interfaces.
The FGCP does not support using a switch interface for the HA heartbeat. As an alternative to
using the lan4 and lan5 interfaces as described in this recipe, you can use the wan1 and wan2
interfaces for the HA heartbeat.
1. Connect to the primary FortiGate, click on the System Information dashboard widget and select Configure
settings in System > Settings.
2. Change the Host name to identify this FortiGate as the primary FortiGate.
If the FortiGates in the cluster will run FortiOS Carrier, apply the FortiOS Carrier license
before you configure the cluster (and before applying other licenses). When you applying
the FortiOS Carrier license the FortiGate resets its configuration to factory defaults,
requiring you to repeat steps performed before applying the license.
You can also install any third-party certificates on the primary FortiGate before forming the cluster. Once the cluster
is formed, third-party certificates are synchronized to the backup FortiGate(s).
4. Enter this CLI command to set the HA mode to active-passive, set a group id, group name and password, increase
the device priority to a higher value (for example, 250) and enable override.
config system ha
set mode a-p
set group-id 100
set group-name My-cluster
set password <password>
set priority 250
set override enable
set hbdev lan4 200 lan5 100
end
Enabling override and increasing the device priority means this FortiGate always becomes the primary unit.
This configuration also selects lan4 and lan5 to be the heartbeat interfaces and sets their priorities to 200 and 100
respectively. Its a best practice to set different priorities for the heartbeat interfaces (but not a requirement).
If you have more than one cluster on the same network, each cluster should have a different group id. Changing the
group id changes the cluster interface virtual MAC addresses. If your group id causes a MAC address conflict on
your network, you can select a different group id.
You can also configure most of these settings from the GUI (go to System > HA).
Override and the group id can only be configured from the CLI.
config system ha
set group-id 100
set override enable
end
After you enter the CLI command or make the GUI changes, the FortiGate negotiates to establish an HA cluster.
You may temporarily lose connectivity with the FortiGate as FGCP negotiation takes place and the MAC addresses
of the FortiGate interfaces are changed to HA virtual MAC addresses.
If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use
DHCP or PPPoE addressing.
To reconnect sooner, you can update the ARP table of your management PC by deleting the ARP table entry for
the FortiGate unit (or just deleting all ARP table entries). You can usually delete the ARP table from a command
prompt using a command similar to arp -d.
The FGCP uses virtual MAC addresses for failover. The virtual MAC address assigned to each FortiGate interface
depends on the HA group ID. A group ID of 100 sets FortiGate interfaces to the following MAC addresses:
00:09:0f:09:64:00, 00:09:0f:09:64:01, 00:09:0f:09:64:02 and so on.
You can verify that the FGCP has set the virtual MAC addresses by viewing the configuration of each FortiGate
interface from the GUI (go to Network > Interfaces) or by entering the following CLI command (shown below for
lan2 on a FortiGate-51E):
You can also use the diagnose hardware deviceinfo nic lan2 command to display this information.
The output shows the current hardware (MAC) address (the virtual MAC set by the FGCP) and the permanent
hardware (MAC) address for the interface.
1. If required, change the firmware running on the new FortiGate to be the same version as is running on the primary
FortiGate.
2. Enter the following command to reset the new backup FortiGate to factory default settings.
execute factoryreset
You can skip this step if the new FortiGate is fresh from the factory. But if its configuration has been changed at all,
it's a best practice to reset your FortiGate to factory defaults to reduce the chance of synchronization problems.
3. Register and apply licenses to the backup FortiGate before configuring it for HA operation. This includes licensing
for FortiCare Support, IPS, AntiVirus, Web Filtering, Mobile Malware, FortiClient, FortiCloud, Security
Rating, Outbreak Prevention, and additional virtual domains (VDOMs). All FortiGates in the cluster must have
the same level of licensing for FortiGuard, FortiCloud, FortiClient, and VDOMs. You can add FortiToken licenses
at any time because they're synchronized to all cluster members.
If the FortiGates in the cluster will run FortiOS Carrier, apply the FortiOS Carrier license
before you configure the cluster (and before applying other licenses). When you applying
the FortiOS Carrier license the FortiGate resets its configuration to factory defaults,
requiring you to repeat steps performed before applying the license.
4. Click on the System Information dashboard widget and select Configure settings in System > Settings.
Change the FortiGate's Host name to identify it as the backup FortiGate.
end
9. Duplicate the primary FortiGate HA settings, except set the Device Priority to a lower value (for example, 50) and
do not enable override.
config system ha
set mode a-p
set group-id 100
set group-name My-cluster
set password <password>
set priority 50
set hbdev lan4 200 lan5 100
end
Similar to when configuring the primary FortiGate, once you enter the CLI command the backup FortiGate
negotiates to establish an HA cluster. You may temporarily lose connectivity with the FortiGate as FGCP
negotiation takes place and the MAC addresses of the FortiGate interfaces are changed to HA virtual MAC
addresses.
If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use
DHCP or PPPoE addressing.
If the group ID is the same, the backup FortiGate interfaces get the same virtual MAC addresses as the primary
FortiGate. You can check Network > Interfaces on the GUI or use the get hardware nic command to verify.
Connect the primary and backup FortiGates together and to your network as shown in the network diagram at the start
of the use case. Making these connections disrupts network traffic as you disconnect and re-connect cables.
Switches must be used between the cluster and the Internet and between the cluster and the internal network as shown
in the network diagram. You can use any good quality switches to make these connections. You can also use one switch
for all of these connections as long as you configure the switch to separate traffic from the different networks.
The example shows the recommended configuration of direct connections between the lan4 heartbeat interfaces and
between the lan5 heartbeat interfaces.
When the heartbeat interfaces are connected, the FortiGates find each other and negotiate to form a cluster. The
primary FortiGate synchronizes its configuration to the backup FortiGate. The cluster forms automatically with minimal
or no additional disruption to network traffic.
The cluster will have the same IP addresses as the primary FortiGate had. You can log into the cluster by logging into
the primary FortiGate CLI or GUI using one of the original IP addresses of the primary FortiGate.
Check the cluster synchronization status to make sure the primary and backup FortiGates both have the same
configuration.
1. Log into the primary FortiGate CLI and enter this command:
diagnose sys ha checksum cluster
The command output lists all cluster members' configuration checksums. If both cluster members have identical
checksums you can be sure that their configurations are synchronized. If the checksums are different, wait a short
while and enter the command again. Repeat until the checksums are identical. It may take a while for some parts
of the configuration to be synchronized.
If the checksums never become identical visit the Fortinet Support website for assistance.
2. The HA Status dashboard widget also shows synchronization status. Mouse over the host names of each
FortiGate in the widget to verify that they are synchronized and both have the same checksum.
3. To view more information about the cluster status, click on the HA Status widget and select Configure Settings
in System > HA (or go to System > HA).
When the checksums are identical, disable override on the primary FortiGate by entering the following command:
config system ha
set override disable
end
FGCP clusters dynamically respond to network conditions. If you keep override enabled, the same FortiGate always
becomes the primary FortiGate. With override enabled; however, the cluster may negotiate more often to keep the
same FortiGate as the primary FortiGate, potentially increasing traffic disruptions.
If you disable override it is more likely that the backup FortiGate could become the primary FortiGate. Disabling override
is recommended unless its important that the same FortiGate remains the primary FortiGate
To see how enabling override can cause minor traffic disruptions, with override enabled set up
a continuous ping through the cluster. Then disconnect power to the backup unit. You will
most likely notice a brief disruption in the ping traffic. Try the same thing with override
disabled and you shouldn't see this traffic disruption.
With override enabled, the disruption is minor and shouldn't be noticed by most users. For
smoother operation, the best practice is to disable override.
Results
All traffic should now be flowing through the primary FortiGate. If the primary FortiGate becomes unavailable, traffic
fails over to the backup FortiGate. When the primary FortiGate rejoins the cluster, the backup FortiGate should
continue operating as the primary FortiGate.
To test this, ping a reliable IP address from a PC on the internal network. After a moment, power off the primary
FortiGate.
If you are using port monitoring, you can also unplug the primary FortiGate's Internet-facing
interface to test failover
You will see a momentary pause in the ping results, until traffic diverts to the backup FortiGate, allowing the ping traffic
to continue.
64 bytes from 184.25.76.114: icmp_seq=69 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=70 ttl=52 time=8.822 ms\
64 bytes from 184.25.76.114: icmp_seq=71 ttl=52 time=9.034 ms\
64 bytes from 184.25.76.114: icmp_seq=72 ttl=52 time=9.536 ms\
64 bytes from 184.25.76.114: icmp_seq=73 ttl=52 time=8.877 ms\
64 bytes from 184.25.76.114: icmp_seq=74 ttl=52 time=8.901 ms\
Request timeout for icmp_seq 75\
64 bytes from 184.25.76.114: icmp_seq=76 ttl=52 time=8.860 ms\
64 bytes from 184.25.76.114: icmp_seq=77 ttl=52 time=9.174 ms\
64 bytes from 184.25.76.114: icmp_seq=78 ttl=52 time=10.108 ms\
64 bytes from 184.25.76.114: icmp_seq=79 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=80 ttl=52 time=10.861 ms\
64 bytes from 184.25.76.114: icmp_seq=81 ttl=52 time=10.757 ms\
64 bytes from 184.25.76.114: icmp_seq=82 ttl=52 time=8.158 ms\
64 bytes from 184.25.76.114: icmp_seq=83 ttl=52 time=8.639 ms}
You can log into the cluster GUI or CLI using the same IP address as you had been using to the log into the primary
FortiGate. If the primary FortiGate is powered off you will be logging into the backup FortiGate. Check the host name to
verify the FortiGate that you have logged into. The FortiGate continues to operate in HA mode and if you restart the
primary FortiGate, after a few minutes it should rejoin the cluster and operate as the backup FortiGate. Traffic should
not be disrupted when the restarted primary unit rejoins the cluster.
This use case describes how to add a third FortiGate to an already established FGCP cluster (the cluster fromHigh
Availability with FGCP (expert) on page 140) and configure active-active HA.
You prepare the new FortiGate by:
1. Setting it to factory defaults to wipe any configuration changes.
2. Licensing it (if required).
3. Enabling HA without changing the device priority and without enabling override.
4. Connecting it to the FGCP cluster already on the network.
The new FortiGate becomes a second backup FortiGate; its configuration synchronized to match the configuration of
the cluster.
Before you start, the new FortiGate should be running the same FortiOS firmware version as the cluster and its
interfaces should not be configured to get addresses from DHCP or PPPoE.
After the third FortiGate joins the cluster, this recipe also describes how to switch the cluster to operate in active-active
(or a-a) mode. Active-active HA enables proxy-based NGFW/UTM load-balancing to allow the three FortiGates to share
proxy-based NGFW/UTM processing. If the cluster handles a large amount of NGFW/UTM traffic, active-active HA with
three FortiGates may enhance performance.
This use case features three FortiGate-51Es. These FortiGate models include a 5-port switch lan interface. Before
configuring HA, the lan interface was converted to five separate interfaces (lan1 to lan5). The lan1 interface connects to
the internal network and the wan1 interface connects to the Internet. The lan4 and lan5 interfaces become the HA
heartbeat interfaces.
The FGCP does not support using a switch interface for the HA heartbeat. As an alternative to
using the lan4 and lan5 interfaces as described in this recipe, you can use the wan1 and wan2
interfaces for the HA heartbeat.
Before adding the third FortiGate to the cluster, enable override on the primary FortiGate. In most cases this step would
not be necessary but it is a best practice because enabling override makes sure the configuration of the primary
FortiGate is not overwritten by the configuration of the new backup FortiGate.
To enable override, log into the primary FortiGate CLI and enter this command:
config system ha
set override enable
end
1. Enter this command to reset the new FortiGate to factory default settings:
execute factoryreset
You can skip this step if the new FortiGate is fresh from the factory. But if its configuration has been changed at all
it's recommended to set it back to factory defaults to reduce the chance of synchronization problems.
2. If required, change the firmware running on the new FortiGate to match the cluster firmware version.
3. Register and apply licenses to the new FortiGate before configuring it for HA operation. This includes licensing for
FortiCare Support, IPS, AntiVirus, Web Filtering, Mobile Malware, FortiClient, FortiCloud, Security
Rating, Outbreak Prevention, and additional virtual domains (VDOMs). All FortiGates in the cluster must have
the same level of licensing for FortiGuard, FortiCloud, FortiClient, and VDOMs. You can add FortiToken licenses
at any time because they're synchronized to all cluster members.
If the FortiGates in the cluster will run FortiOS Carrier, apply the FortiOS Carrier license
before you configure the cluster (and before applying other licenses). When you applying
the FortiOS Carrier license the FortiGate resets its configuration to factory defaults,
requiring you to repeat steps performed before applying the license.
4. Change the host name of the new FortiGate to identify it as Backup-2 by clicking on the System Information
dashboard widget and selecting Configure settings in System > Settings and changing the Host name.
If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use
DHCP or PPPoE addressing.
If the group ID is the same, the backup FortiGate interfaces get the same virtual MAC addresses as the primary
FortiGate. You can check Network > Interfaces on the GUI or use the get hardware nic command.
Connect the new FortiGate to the cluster and your network as shown in the network diagram at the start of this use
case. Making these connections disrupts network traffic as you disconnect and re-connect the heartbeat interfaces. If
you have already added switches to connect the heartbeat interfaces, you can connect the new FortiGate without
disrupting network traffic.
When you add a third FortiGate to a cluster you need to connect the heartbeat interfaces together using switches. You
can use separate switches for each heartbeat interface (recommended for redundancy) or you can use the same switch
for both heartbeat interfaces as long as you separate the traffic from each heartbeat interface.
When you connect the heartbeat interfaces of the new FortiGate, the cluster re-negotiates. If you have enabled override
on the primary FortiGate and set its priority highest, the primary FortiGate synchronizes its configuration to the new
FortiGate. The cluster automatically forms with minimal or no additional disruption to network traffic.
The new cluster will have the same IP addresses as the primary FortiGate. You can log into the cluster by logging into
the primary FortiGate CLI or GUI.
Check the cluster synchronization status to make sure the primary and backup FortiGates both have the same
configuration.
1. Log into the primary FortiGate CLI and enter this command:
diagnose sys ha checksum cluster
The command output lists all cluster members' configuration checksums. If they all have identical checksums, you
can be sure that the configurations are synchronized. If the checksums are different, wait a short while and enter
the command again. Repeat until the checksums are identical. It may take a while for some parts of the
configuration to be synchronized.
If the checksums never become identical visit the Fortinet Support website for assistance.
2. The HA Status dashboard widget also shows synchronization status. Mouse over the host names of each
FortiGate in the widget to verify that they are synchronized and both have the same checksum.
3. To view more information about the cluster status, click on the HA Status widget and select Configure Settings
When the checksums are identical, disable override on the primary FortiGate by entering the following command:
config system ha
set override disable
end
FGCP clusters dynamically respond to network conditions. If you keep override enabled, the same FortiGate always
becomes the primary FortiGate. With override enabled; however, the cluster may negotiate more often to keep the
same FortiGate as the primary FortiGate, potentially increasing traffic disruptions.
If you disable override it is more likely that the backup FortiGate could become the primary FortiGate. Disabling override
is recommended unless its important that the same FortiGate remains the primary FortiGate
To see how enabling override can cause minor traffic disruptions, with override enabled set up
a continuous ping through the cluster. Then disconnect power to the backup unit. You will
most likely notice a brief disruption in the ping traffic. Try the same thing with override
disabled and you shouldn't see this traffic disruption.
With override enabled, the disruption is minor and shouldn't be noticed by most users. For
smoother operation, the best practice is to disable override.
Log into the primary FortiGate CLI and enter this command to convert the cluster from an active-passive to an active-
active cluster. The cluster changes modes without any traffic interruption.
config system ha
set mode a-a
end
Results
Most traffic should now be flowing through the primary FortiGate with proxy-based NGFW/UTM sessions distributed to
all three FortiGates in the cluster. If the primary FortiGate becomes unavailable, traffic fails over to the backup
FortiGate. When the primary FortiGate rejoins the cluster, the backup FortiGate should continue operating as the
primary FortiGate.
To test this, ping a reliable IP address from a PC on the internal network. After a moment, power off the primary
FortiGate.
If you are using port monitoring, you can also unplug the primary FortiGate's Internet-facing
interface to test failover.
You will see a momentary pause in the ping results, until traffic diverts to the backup FortiGate, allowing the ping traffic
to continue.
64 bytes from 184.25.76.114: icmp_seq=69 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=70 ttl=52 time=8.822 ms\
64 bytes from 184.25.76.114: icmp_seq=71 ttl=52 time=9.034 ms\
64 bytes from 184.25.76.114: icmp_seq=72 ttl=52 time=9.536 ms\
64 bytes from 184.25.76.114: icmp_seq=73 ttl=52 time=8.877 ms\
64 bytes from 184.25.76.114: icmp_seq=74 ttl=52 time=8.901 ms\
Request timeout for icmp_seq 75\
64 bytes from 184.25.76.114: icmp_seq=76 ttl=52 time=8.860 ms\
64 bytes from 184.25.76.114: icmp_seq=77 ttl=52 time=9.174 ms\
64 bytes from 184.25.76.114: icmp_seq=78 ttl=52 time=10.108 ms\
64 bytes from 184.25.76.114: icmp_seq=79 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=80 ttl=52 time=10.861 ms\
64 bytes from 184.25.76.114: icmp_seq=81 ttl=52 time=10.757 ms\
64 bytes from 184.25.76.114: icmp_seq=82 ttl=52 time=8.158 ms\
64 bytes from 184.25.76.114: icmp_seq=83 ttl=52 time=8.639 ms}
You can log into the cluster GUI or CLI using the same IP address as you had been using to the log into the primary
FortiGate. If the primary FortiGate is powered off you will be logging into the backup FortiGate. Check the host name to
verify the FortiGate that you have logged into. The FortiGate continues to operate in HA mode and if you restart the
primary FortiGate, after a few minutes it should rejoin the cluster and operate as the backup FortiGate. Traffic should
not be disrupted when the restarted primary unit rejoins the cluster.
In this use case you set up a FortiGate Clustering Protocol (FGCP) virtual clustering configuration with two FortiGates to
provide redundancy and failover protection for two networks. The FortiGate configuration includes two VDOMs. The
root VDOM handles internal network traffic and the Engineering VDOM handles Engineering network traffic. This use
case describes a very simple two-VDOM configuration. However, the same principles described in this example apply to
a virtual cluster with more VDOMs.
In this virtual cluster configuration the primary FortiGate processes all internal network traffic and the backup FortiGate
processes all Engineering network traffic. Virtual clustering enables override and uses device priorities to distribute
traffic between the primary and backup FortiGates in the virtual cluster.
This use case describes the recommended steps for setting up a virtual cluster of two FortiGates. You can follow the
procedure described in High Availability with FGCP (expert) on page 140 to configure virtual clustering by converting a
FortiGate with VDOMs to HA mode and then adding another FortiGate to form a cluster. However, taking this approach
with virtual clustering is not as foolproof as a normal HA configuration. If you accidentally add the management VDOM
to virtual cluster 2 before adding the backup FortiGate, the configuration of the primary FortiGate can be overwritten by
the backup FortiGate. If want to experiment with this approach, make sure you don't add the management VDOM to
virtual cluster 2 until all of the FortiGates have joined the cluster.
Before you start, the FortiGates should be running the same FortiOS firmware version and their interfaces should not be
configured to get addresses from DHCP or PPPoE.
This user case features two FortiGate-51Es. FortiGate-51Es have a 5-port switch lan interface. Before configuring HA,
the lan interface was converted to 5 separate interfaces (lan1 to lan5).
The FGCP does not support using a switch interface for the HA heartbeat. As an alternative to
using the lan4 and lan5 interfaces as described in this recipe, you can use the wan1 and wan2
interfaces for the HA heartbeat.
1. If required, upgrade the firmware running on the FortiGates. Both FortiGates should be running the same version
of FortiOS.
2. On each FortiGate, enter the following command to reset them factory default settings.
execute factoryreset
You can skip this step if the FortiGates are fresh from the factory. But if their configurations have changed at all, it's
a best practice to reset them to factory defaults to reduce the chance of synchronization problems.
In some cases, after resetting to factory defaults you may want to make some initial configuration changes to
connect the FortiGates to the network or for other reasons. To write this recipe, the lan switch on the FortiGate-
51Es was converted to separate lan1 to lan5 interfaces.
3. Change the primary FortiGate Host name to identify it as the primary FortiGate by going to System > Settings.
4. Change the backup FortiGate Host name to identify it as the backup FortiGate by going to System > Settings.
You can also use the CLI to change the host name. From the Primary FortiGate:
config system global
set hostname Primary
end
From the Backup-1 FortiGate:
config system global
set hostname Backup
end
5. Register and apply licenses to the FortiGates before configuring the cluster. This includes licensing for FortiCare
Support, IPS, AntiVirus, Web Filtering, Mobile Malware, FortiClient, FortiCloud, Security Rating,
Outbreak Prevention, and additional virtual domains (VDOMs).
Both FortiGates in the cluster must have the same level of licensing for FortiGuard, FortiCloud, FortiClient, and
VDOMs. You can add FortiToken licenses at any time because they're synchronized to all cluster members.
If the FortiGates in the cluster will run FortiOS Carrier, apply the FortiOS Carrier license
before you configure the cluster (and before applying other licenses). When you applying
the FortiOS Carrier license the FortiGate resets its configuration to factory defaults,
requiring you to repeat steps performed before applying the license.
Configuring clustering
1. On the primary FortiGate, enter the following CLI command to set the HA mode to active-passive, set a group-id,
group name, and password, increase the device priority to 200, enable override, and configure the heartbeat
interfaces (lan4 and lan5 in this example).
config system ha
set mode a-p
set group-id 88
set group-name My-vcluster
set password <password>
set priority 200
set override enable
set hbdev lan4 200 lan5 100
end
If you have more than one cluster on the same network, each cluster should have a
different group id. Changing the group id changes the cluster interface virtual MAC
addresses. If your group id causes a MAC address conflict on your network, you can select
a different group id.
Enabling override is optional; but it makes sure the FortiGate with the highest device
priority becomes the primary unit.
You can also configure most of these settings from the GUI (go to Global > System > HA). The group-id and
override can only be configured from the CLI.
2. On the backup FortiGate, duplicate the primary FortiGate HA mode, group-id, group-name, password, override,
and heartbeat device settings. Set the device priority to 50.
config system ha
set mode a-p
set group-id 88
set group-name My-vcluster
set password <password>
set priority 50
set override enable
set hbdev lan4 200 lan5 100
end
After you enable HA, each FortiGate negotiates to establish an HA cluster. You may temporarily lose connectivity
as FGCP negotiation takes place and the MAC addresses of the FortiGate interfaces change to HA virtual MAC
addresses.
If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use
DHCP or PPPoE addressing.
To reconnect sooner, you can update the ARP table of your management PC by deleting the ARP table entry for
the FortiGate (or just deleting all ARP table entries). You can usually delete the ARP table from a command prompt
using a command similar to arp -d.
The FGCP uses virtual MAC addresses for failover. The virtual MAC address assigned to each FortiGate interface
depends on the HA group ID. A group ID of 88 sets FortiGate interfaces to the following MAC addresses:
00:09:0f:09:58:00, 00:09:0f:09:58:01, 00:09:0f:09:58:02 and so on. For details, see Cluster virtual MAC
addresses.
You can verify that the FGCP has set the virtual MAC addresses by viewing the configuration of each FortiGate
interface from the GUI (go to Network > Interfaces) or by entering the following CLI command (shown below for
lan2 on a FortiGate-51E):
get hardware nic lan2
...
Current_HWaddr 00:09:0f:09:58:01
Permanent_HWaddr 70:4c:a5:98:11:54
...
You can also use the diagnose hardware deviceinfo nic lan2 command to display this information.
The output shows the current hardware (MAC) address (the virtual MAC set by the FGCP) and the permanent
hardware (MAC) address for the interface.
Connect the FortiGates together and to your networks as shown in the network diagram at the start of the use case.
Making these connections disrupts network traffic as you disconnect and re-connect cables.
Switches must be used between the cluster and the Internet, between the cluster and the internal network, and between
the cluster and the Engineering network as shown in the diagram. You can use any good quality switches to make these
connections.
To make HA heartbeat connections, connect all of the lan4 interfaces to the same switch and all of the lan5 interfaces to
another switch.
You can also use fewer switches for all of these connections as long as you configure the switches to separate traffic
from the different networks.
When you connect the heartbeat interfaces and power on the FortiGates, they find each other and negotiate to form a
cluster. The cluster will have the same IP addresses as the primary FortiGate. You can log into the cluster by logging
into the primary FortiGate GUI or CLI using one of the original IP addresses of the primary FortiGate.
Check the cluster synchronization status to make sure the primary and backup FortiGates both have the same
configuration. Log into the primary FortiGate CLI and enter this command:
diagnose sys ha checksum cluster
The command output lists all cluster members' configuration checksums. If both cluster members have identical
checksums you can be sure that their configurations are synchronized. If the checksums are different, wait a short while
and enter the command again. Repeat until the checksums are identical. It may take a while for some parts of the
configuration to be synchronized. If the checksums never become identical you can use the information in Synchronizing
the configuration to troubleshoot the problem or visit the Fortinet Support website for assistance.
You can also use the get system ha status command to display detailed information about the cluster. .
The HA Status dashboard widget also shows synchronization status. Hover over the host names of each FortiGate in
the widget to verify that they are synchronized and both have the same checksum.
1. Enable VDOMs by going to System > Settings > System Operation Settings and enabling Virtual Domains.
Or enter the following CLI command.
config system global
set vdom-admin enable
end
2. Add VDOMs as required. Go to Global > System > VDOM and select Create New. Or enter the following CLI
command to add the Engineering VDOM.
config global
edit Engineering
end
3. Configure virtual clustering and VDOM partitioning on the primary FortiGate. The following command enables
virtual cluster 2, adds the Engineering VDOM to virtual cluster 2, and sets the virtual cluster 2 device priority of the
primary FortiGate to 50.
config global
config system ha
set vcluster2 enable
config secondary-vcluster
set vdom Engineering
set priority 50
end
You can also configure virtual clustering and VDOM partitioning from the GUI by going to Global > System > HA.
4. Set the virtual cluster 2 priority of the backup FortiGate to a relatively high value (in this example, 200) so that this
FortiGate processes traffic for the VDOMs in virtual cluster 2. The FGCP synchronizes all other HA settings from
the primary FortiGate.
You can only configure the virtual cluster 2 priority of the backup FortiGate from the CLI. Use execute ha
manage to access the backup FortiGate CLI.
config global
config system ha
config secondary-vcluster
set priority 200
end
1. Once again use the diagnose sys ha checksum cluster command and the get system ha status
command to check the cluster synchronization status to make sure the primary and backup FortiGates both have
the same configuration.
The HA Status dashboard widget shows the VDOMs in the virtual clusters. You can hover over the VDOM names
to see status information for the VDOMs. You can hover over the host names of each FortiGate to verify that they
are synchronized and both have the same checksum.
2. To view more information about the cluster status, click on the HA Status widget and select Configure Settings
in System > HA (or go to System > HA).
The HA status page shows both FortiGates in the cluster. It also shows that Primary is the primary (master)
FortiGate for the root VDOM (so the primary FortiGate processes all root VDOM traffic). The page also shows that
Backup is the primary (master) FortiGate for the Engineering VDOM (so the backup FortiGate processes all
Engineering VDOM traffic).
Results
All traffic should now be flowing through the primary FortiGate. If the primary FortiGate becomes unavailable, traffic
fails over to the backup FortiGate. When the primary FortiGate rejoins the cluster, the backup FortiGate should
continue operating as the primary FortiGate.
To test this, ping a reliable IP address from a PC on the internal network. After a moment, power off the primary
FortiGate.
If you are using port monitoring, you can also unplug the primary FortiGate's Internet-facing
interface to test failover
You will see a momentary pause in the ping results, until traffic diverts to the backup FortiGate, allowing the ping traffic
to continue.
You can log into the cluster GUI or CLI using the same IP address as you had been using to the log into the primary
FortiGate. If the primary FortiGate is powered off you will be logging into the backup FortiGate. Check the host name to
verify the FortiGate that you have logged into.
When you restart the primary FortiGate, after a few minutes it should rejoin the cluster and because override is enabled,
the original virtual cluster configuration should be re-established. Traffic may be temporarily disrupted when the
restarted primary FortiGate rejoins the cluster.
In this use case you set up a FortiGate Clustering Protocol (FGCP) virtual clustering configuration with four FortiGates
to provide redundancy and failover protection for two networks. The FortiGate configuration includes two VDOMs. The
root VDOM handles internal network traffic and the Engineering VDOM handles Engineering network traffic. This recipe
describes a very simple two-VDOM configuration. However, the same principles described in this example apply to a
virtual cluster with more VDOMs.
In this virtual cluster configuration the primary FortiGate processes all internal network traffic and the backup FortiGate
processes all Engineering network traffic. Virtual clustering enables override and uses device priorities to distribute
traffic between the primary and backup FortiGates in the virtual cluster.
The third FortiGate (the recipe names it Backup-2) acts as a backup to the primary FortiGate; if the primary FortiGate
fails, all primary FortiGate network traffic transfers to the Backup-2 FortiGate, which becomes the new primary
FortiGate.
The fourth FortiGate (Backup-3) acts as a backup to the backup FortiGate; if the backup FortiGate fails, all backup
FortiGate network traffic transfers to the Backup-3 FortiGate, which becomes the new backup FortiGate.
This recipe describes the recommended steps for setting up a virtual cluster of four FortiGates. You can follow the
procedure described in High Availability with FGCP (expert) on page 140 to configure virtual clustering by converting a
FortiGate with VDOMs to HA mode and then adding another FortiGate to form a cluster. However, taking this approach
with virtual clustering is not as foolproof as a normal HA configuration. If you accidentally add the management VDOM
to virtual cluster 2 before adding the backup FortiGate, the configuration of the primary FortiGate can be overwritten by
the backup FortiGate. If want to experiment with this approach, make sure you don't add the management VDOM to
virtual cluster 2 until all of the FortiGates have joined the cluster.
Before you start, the FortiGates should be running the same FortiOS firmware version and their interfaces should not be
configured to get addresses from DHCP or PPPoE.
This recipe features four FortiGate-51Es. FortiGate-51Es have a 5-port switch lan interface. Before configuring HA, the
lan interface was converted to 5 separate interfaces (lan1 to lan5).
The FGCP does not support using a switch interface for the HA heartbeat. As an alternative to
using the lan4 and lan5 interfaces as described in this recipe, you can use the wan1 and wan2
interfaces for the HA heartbeat.
1. If required, upgrade the firmware running on the FortiGates. All of the FortiGates should be running the same
version of FortiOS.
2. On each FortiGate, enter the following command to reset them factory default settings.
execute factoryreset
You can skip this step if the FortiGates are fresh from the factory. But if their configurations have changed at all, it's
a best practice to reset them to factory defaults to reduce the chance of synchronization problems.
In some cases, after resetting to factory defaults you may want to make some initial configuration changes to
connect the FortiGates to the network or for other reasons. To write this recipe, the lan switch on the FortiGate-
51Es was converted to separate lan1 to lan5 interfaces.
3. Change the primary FortiGate Host name to identify it as the primary FortiGate by going to System > Settings.
4. Change the backup FortiGate Host name to identify it as Backup-1 by going to System > Settings.
5. Change the third FortiGate Host name to identify it as Backup-2 by going to System > Settings.
6. Change the fourth FortiGate Host name to identify it as Backup-3 by going to System > Settings.
You can also use the CLI to change the host name. From the Primary FortiGate:
config system global
set hostname Primary
end
From the Backup-1 FortiGate:
config system global
set hostname Backup-1
end
From the Backup-2 FortiGate:
config system global
All FortiGates in the cluster must have the same level of licensing for FortiGuard, FortiCloud, FortiClient, and
VDOMs. You can add FortiToken licenses at any time because they're synchronized to all cluster members.
If the FortiGates in the cluster will run FortiOS Carrier, apply the FortiOS Carrier license
before you configure the cluster (and before applying other licenses). When you applying
the FortiOS Carrier license the FortiGate resets its configuration to factory defaults,
requiring you to repeat steps performed before applying the license.
Configuring clustering
1. On the primary FortiGate, enter the following CLI command to set the HA mode to active-passive, set a group-id,
group name, and password, increase the device priority to 200, enable override, and configure the heartbeat
interfaces (lan4 and lan5 in this example).
config system ha
set mode a-p
set group-id 88
set group-name My-vcluster
set password <password>
set priority 200
set override enable
set hbdev lan4 200 lan5 100
end
If you have more than one cluster on the same network, each cluster should have a
different group id. Changing the group id changes the cluster interface virtual MAC
addresses. If your group id causes a MAC address conflict on your network, you can select
a different group id.
Enabling override is optional; but it makes sure the FortiGate with the highest device
priority becomes the primary unit.
You can also configure most of these settings from the GUI (go to Global > System > HA). The group-id and
override can only be configured from the CLI.
2. On the Backup-1 FortiGate, duplicate the primary FortiGate HA mode, group-id, group-name, password, override,
and heartbeat device settings. Set the device priority to 50. Setting the device priority to a relatively low value
means the Backup-1 FortiGate will most likely always become the backup FortiGate.
config system ha
set mode a-p
set group-id 88
set group-name My-vcluster
set password <password>
set priority 50
set override enable
set hbdev lan4 200 lan5 100
end
3. On the Backup-2 FortiGate, duplicate the primary FortiGate HA mode, group-id, group-name, password, override,
and heartbeat device settings. Set the device priority to 150. A device priority of 150 is almost as high as the device
priority of the primary FortiGate. So if the primary FortiGate fails, the Backup-2 FortiGate should become the new
primary FortiGate.
config system ha
set mode a-p
set group-id 88
If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use
DHCP or PPPoE addressing.
To reconnect sooner, you can update the ARP table of your management PC by deleting the ARP table entry for
the FortiGate (or just deleting all ARP table entries). You can usually delete the ARP table from a command prompt
using a command similar to arp -d.
The FGCP uses virtual MAC addresses for failover. The virtual MAC address assigned to each FortiGate interface
depends on the HA group ID. A group ID of 88 sets FortiGate interfaces to the following MAC addresses:
00:09:0f:09:58:00, 00:09:0f:09:58:01, 00:09:0f:09:58:02 and so on. For details, see Cluster virtual MAC
addresses.
You can verify that the FGCP has set the virtual MAC addresses by viewing the configuration of each FortiGate
interface from the GUI (go to Network > Interfaces) or by entering the following CLI command (shown below for
lan2 on a FortiGate-51E):
get hardware nic lan2
...
Current_HWaddr 00:09:0f:09:58:01
Permanent_HWaddr 70:4c:a5:98:11:54
...
You can also use the diagnose hardware deviceinfo nic lan2 command to display this information.
The output shows the current hardware (MAC) address (the virtual MAC set by the FGCP) and the permanent
hardware (MAC) address for the interface.
Connect the FortiGates together and to your networks as shown in the network diagram at the start of the use case.
Making these connections disrupts network traffic as you disconnect and re-connect cables.
Switches must be used between the cluster and the Internet, between the cluster and the internal network, and between
the cluster and the Engineering network as shown in the diagram. You can use any good quality switches to make these
connections.
To make HA heartbeat connections, connect all of the lan4 interfaces to the same switch and all of the lan5 interfaces to
another switch.
You can also use fewer switches for all of these connections as long as you configure the switches to separate traffic
from the different networks.
When you connect the heartbeat interfaces and power on the FortiGates, they find each other and negotiate to form a
cluster. The cluster will have the same IP addresses as the primary FortiGate. You can log into the cluster by logging
into the primary FortiGate GUI or CLI using one of the original IP addresses of the primary FortiGate.
Check the cluster synchronization status to make sure the primary and backup FortiGates both have the same
configuration. Log into the primary FortiGate CLI and enter this command:
diagnose sys ha checksum cluster
The command output lists all cluster members' configuration checksums. If both cluster members have identical
checksums you can be sure that their configurations are synchronized. If the checksums are different, wait a short while
and enter the command again. Repeat until the checksums are identical. It may take a while for some parts of the
configuration to be synchronized. If the checksums never become identical you can use the information in Synchronizing
the configuration to troubleshoot the problem or visit the Fortinet Support website for assistance.
You can also use the get system ha status command to display detailed information about the cluster. .
The HA Status dashboard widget also shows synchronization status. Hover over the host names of each FortiGate in
the widget to verify that they are synchronized and both have the same checksum.
1. Enable VDOMs by going to System > Settings > System Operation Settings and enabling Virtual Domains.
Or enter the following CLI command.
config system global
set vdom-admin enable
end
2. Add VDOMs as required. Go to Global > System > VDOM and select Create New. Or enter the following CLI
command to add the Engineering VDOM.
config global
edit Engineering
end
3. Configure virtual clustering and VDOM partitioning on the primary FortiGate. The following command enables
virtual cluster 2, adds the Engineering VDOM to virtual cluster 2, and sets the virtual cluster 2 device priority of the
primary FortiGate to 50.
config global
config system ha
set vcluster2 enable
config secondary-vcluster
set vdom Engineering
set priority 50
end
You can also configure virtual clustering and VDOM partitioning from the GUI by going to Global > System > HA.
4. Set the virtual cluster 2 priority of the Backup-1 FortiGate to a relatively high value (in this example, 200) so that
this FortiGate processes traffic for the VDOMs in virtual cluster 2. The FGCP synchronizes all other HA settings
from the primary FortiGate.
You can only configure the virtual cluster 2 priority of the backup FortiGate from the CLI. Use execute ha
manage to access the backup FortiGate CLI.
config global
config system ha
config secondary-vcluster
set priority 200
end
5. Set the virtual cluster 2 priority of the Backup-2 FortiGate to 100 so that if the primary FortiGate fails, Backup-2 will
become the primary FortiGate but will have the lowest virtual cluster 2 priority. The FGCP synchronizes all other HA
settings from the primary FortiGate.
You can only configure the virtual cluster 2 priority of the Backup-2 FortiGate from the CLI. Use execute ha manage
to access the backup FortiGate CLI.
config global
config system ha
config secondary-vcluster
set priority 100
end
6. Set the virtual cluster 2 priority of the Backup-3 FortiGate to 150 so that if the backup FortiGate fails, Backup-3 will
have the highest virtual cluster 2 device priority. The FGCP synchronizes all other HA settings from the primary
FortiGate.
You can only configure the virtual cluster 2 priority of the backup FortiGate from the CLI. Use execute ha manage
to access the backup FortiGate CLI.
config global
config system ha
config secondary-vcluster
set priority 150
end
1. Once again use the diagnose sys ha checksum cluster command and the get system ha status
command to check the cluster synchronization status to make sure the primary and backup FortiGates both have
the same configuration.
The HA Status dashboard widget shows the VDOMs in the virtual clusters. You can hover over the VDOM names
to see status information for the VDOMs. You can hover over the host names of each FortiGate to verify that they
are synchronized and both have the same checksum.
2. To view more information about the cluster status, click on the HA Status widget and select Configure Settings
in System > HA (or go to System > HA).
The HA status page shows all four FortiGates in the cluster. It also shows that Primary is the primary (master)
FortiGate for the root VDOM (so the primary FortiGate processes all root VDOM traffic). The page also shows that
Backup-1 is the primary (master) FortiGate for the Engineering VDOM (so the backup FortiGate processes all
Engineering VDOM traffic).
Results
All root VDOM traffic should now be flowing through the primary FortiGate and Engineering VDOM traffic should be
flowing through the backup FortiGate. If the primary FortiGate becomes unavailable, the cluster negotiates and traffic
fails over and all traffic would be processed by the backup FortiGate.
To test this, ping a reliable IP address from a PC on the internal network. After a moment, power off the primary
FortiGate.
If you are using port monitoring, you can also unplug the primary FortiGate's Internet-facing
interface to test failover.
You will see a momentary pause in the ping results, until traffic diverts to the backup FortiGate, allowing the ping traffic
to continue.
64 bytes from 184.25.76.114: icmp_seq=69 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=70 ttl=52 time=8.822 ms\
64 bytes from 184.25.76.114: icmp_seq=71 ttl=52 time=9.034 ms\
64 bytes from 184.25.76.114: icmp_seq=72 ttl=52 time=9.536 ms\
64 bytes from 184.25.76.114: icmp_seq=73 ttl=52 time=8.877 ms\
64 bytes from 184.25.76.114: icmp_seq=74 ttl=52 time=8.901 ms\
Request timeout for icmp_seq 75\
64 bytes from 184.25.76.114: icmp_seq=76 ttl=52 time=8.860 ms\
64 bytes from 184.25.76.114: icmp_seq=77 ttl=52 time=9.174 ms\
64 bytes from 184.25.76.114: icmp_seq=78 ttl=52 time=10.108 ms\
64 bytes from 184.25.76.114: icmp_seq=79 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=80 ttl=52 time=10.861 ms\
64 bytes from 184.25.76.114: icmp_seq=81 ttl=52 time=10.757 ms\
64 bytes from 184.25.76.114: icmp_seq=82 ttl=52 time=8.158 ms\
64 bytes from 184.25.76.114: icmp_seq=83 ttl=52 time=8.639 ms}
You can log into the cluster GUI or CLI using the same IP address as you had been using to the log into the primary
FortiGate. If the primary FortiGate is powered off you will be logging into the Backup-1 FortiGate. Check the host name
to verify the FortiGate that you have logged into.
After the primary FortiGate fails the HA Status dashboard widget shows that the Backup-2 has become the primary
(master) FortiGate.
The System > HA page shows that the Backup-2 FortiGate has become the primary FortiGate for virtual cluster 1. This
page also shows that the Backup-1 FortiGate continues to process virtual cluster 2 traffic.
If you restart the primary FortiGate, after a few minutes it should rejoin the cluster and because override is enabled, the
original virtual cluster configuration should be re-established. Traffic may be temporarily disrupted when the restarted
primary FortiGate rejoins the cluster.
You can also try powering off other FortiGates in the virtual cluster to see how the cluster adapts to the failover.
Because of the device priority configuration, if two FortiGates are operating, virtual cluster 1 and virtual cluster 2 traffic
will be distributed between them.
This use case provides an example of how to set up a FortiGate for redundant Internet connectivity using SD-WAN and
then convert this single FortiGate into an FGCP HA cluster of two FortiGates. This SD-WAN HA configuration allows
you to load balance your Internet traffic between multiple ISP links and provides redundancy for your network's Internet
connection if your primary ISP is unavailable or if one of the FortiGates in the HA cluster fails.
This use case features two FortiGate-51Es, which have a 5-port switch lan interface. Before starting the steps in this
recipe, we converted the lan interface to 5 separate interfaces (lan1 to lan5). The lan1 interface connects to the internal
network, the wan1 interface connects to one Internet service provider (ISP) and the wan2 to a second ISP. For the
FGCP HA configuration, the lan4 and lan5 interfaces become HA heartbeat interfaces.
Connect the Internet-facing ports (WAN ports) on the FortiGate to your ISP devices. Connect WAN1 to the ISP that you
want to use for most traffic. Connect WAN2 to the other ISP.
Before you can configure FortiGate interfaces as SD-WAN members, you must remove or redirect existing configuration
references to those interfaces in routes and security policies. This includes the default Internet access policy that's
included with many FortiGate models. Note that after you remove the routes and security policies, traffic can't reach the
WAN ports through the FortiGate.
Redirecting the routes and policies to reference other interfaces avoids your having to create them again later. After you
configure SD-WAN, you can reconfigure the routes and policies to reference the SD-WAN interface.
1. Go to Network > Static Routes and delete any routes that use WAN1 or WAN2.
2. Go to Policy & Objects >IPv4 Policy and delete any policies that use WAN1 or WAN2.
2. Go to Network > Interfaces and verify that the virtual interface for SD-WAN appears in the interface list. You can
expand SD-WAN to view the ports that are included in the SD-WAN interface.
1. Go to Network > SD-WAN Rules and edit the rule named sd-wan.
2. In the Load Balancing Algorithm field, select Volume, and prioritize WAN1 to serve more traffic.
In the example, the ISP connected to WAN1 is a 40Mb link, and the ISP connected to WAN2 is a 10Mb link, so we
balance the weight 75% to 25% in favor of WAN1.
5. If you previously removed or redirected existing references in routes to interfaces that you wanted to add as SD-
WAN interface members, you can now reconfigure those routes to reference the SD-WAN interface.
1. Configure a security policy that allows traffic from your organization’s internal network to the SD-WAN interface.
2. Go to Policy & Objects >IPv4 Policy and create a policy.
3. Set Incoming Interface to the interface that connects to your organization's internal network, and set Outgoing
Interface to the SD-WAN interface.
4. Enable NAT and apply Security Profiles as required.
5. Configure other policy options as required.
1. Change the Host name to identify this FortiGate as the primary FortiGate. From the System Information
dashboard widget, select Configure settings in System > Settings.
2. Register and apply licenses to the primary FortiGate before configuring it for HA operation.
3. Enter this CLI command to set the HA mode to active-passive; set a group ID, group name and password; increase
the device priority to a higher value (for example, 250); and enable override.
config system ha
set mode a-p
set group-id 100
set group-name My-cluster
set password <password>
set priority 250
set override enable
set hbdev lan4 200 lan5 100
end
Enabling override and increasing the device priority means this FortiGate always becomes the primary unit.
This configuration also selects lan4 and lan5 to be the heartbeat interfaces and sets their priorities to 200 and 100
respectively. It's a best practice to set different priorities for the heartbeat interfaces (but not a requirement).
If you have more than one cluster on the same network, each cluster should have a different group ID. Changing
the group id changes the cluster interface virtual MAC addresses. If your group ID causes a MAC address conflict
on your network, you can select a different group ID.
Override and the group ID can only be configured from the CLI.
config system ha
set group-id 100
set override enable
end
4. You can also configure most of these settings from the GUI (go to System > HA).
After you enter the CLI command or make changes from the GUI, the FortiGate negotiates to establish an HA
cluster. You may temporarily lose connectivity with the FortiGate as FGCP negotiation takes place and the MAC
addresses of the FortiGate interfaces are changed to HA virtual MAC addresses.
If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use
DHCP or PPPoE addressing.
To reconnect sooner, you can update the ARP table of your management PC by deleting the ARP table entry for
the FortiGate unit (or just deleting all ARP table entries). You can usually delete the ARP table from a command
prompt using a command similar to arp -d.
If required, change the firmware running on the new FortiGate to the same version as is running on the primary
FortiGate.
Enter the following command to reset the new backup FortiGate to factory default settings.
execute factoryreset
You can skip this step if the new FortiGate is fresh from the factory. But if its configuration has been changed at all, it's a
best practice to reset your FortiGate to factory defaults to reduce the chance of synchronization problems.
Connect the primary and backup FortiGates to each other and to your network as shown. Making these connections
disrupts network traffic as you disconnect and re-connect cables.
Switches must be used between the cluster and the ISPs and between the cluster and the internal network as shown in
the network diagram. You can use any good quality switches to make these connections. You can also use one switch
for all of these connections as long as you configure the switch to separate traffic from the different networks.
The example shows the recommended configuration of direct connections between the lan4 heartbeat interfaces and
between the lan5 heartbeat interfaces.
When the heartbeat interfaces are connected, the FortiGates find each other and negotiate to form a cluster. The
primary FortiGate synchronizes its configuration to the backup FortiGate. The cluster forms automatically with minimal
or no additional disruption to network traffic.
The cluster will have the same IP addresses as the primary FortiGate had. You can log into the cluster by logging into
the primary FortiGate CLI or GUI using one of the original IP addresses of the primary FortiGate.
Check the cluster synchronization status to make sure the primary and backup FortiGates both have the same
configuration.
1. Log into the primary FortiGate CLI and enter this command:
diagnose sys ha checksum cluster
The command output lists all cluster members' configuration checksums. If both cluster members have identical
checksums you can be sure that their configurations are synchronized. If the checksums are different, wait a short
while and enter the command again. Repeat until the checksums are identical. It may take a while for some parts
of the configuration to be synchronized.
If the checksums never become identical visit the Fortinet Support website for assistance.
2. The HA Status dashboard widget also shows synchronization status. Mouse over the host names of each
FortiGate in the widget to verify that they are synchronized and both have the same checksum.
3. To view more information about the cluster status, click on the HA Status widget and select Configure Settings
in System > HA (or go to System > HA).
When the checksums are identical, disable override on the primary FortiGate by entering the following command:
config system ha
set override disable
end
FGCP clusters dynamically respond to network conditions. If you keep override enabled, the same FortiGate always
becomes the primary FortiGate. With override enabled; however, the cluster may negotiate more often to keep the
same FortiGate as the primary FortiGate, potentially increasing traffic disruptions.
If you disable override it is more likely that the backup FortiGate could become the primary FortiGate. Disabling override
is recommended unless its important that the same FortiGate remains the primary FortiGate
To see how enabling override can cause minor traffic disruptions, with override enabled set up
a continuous ping through the cluster. Then disconnect power to the backup unit. You will
most likely notice a brief disruption in the ping traffic. Try the same thing with override
disabled and you shouldn't see this traffic disruption.
With override enabled, the disruption is minor and shouldn't be noticed by most users. For
smoother operation, the best practice is to disable override.
Results
3. Go to Monitor > SD-WAN Monitor to view the number of sessions, bit rate, and more information for each
interface.
Testing HA failover
All traffic should now be flowing through the primary FortiGate. If the primary FortiGate becomes unavailable, traffic
fails over to the backup FortiGate. When the primary FortiGate rejoins the cluster, the backup FortiGate should
continue operating as the primary FortiGate.
To test this, ping a reliable IP address from a PC on the internal network. After a moment, power off the primary
FortiGate.
If you are using port monitoring, you can also unplug the primary FortiGate's Internet-facing
interface to test failover
You will see a momentary pause in the ping results, until traffic diverts to the backup FortiGate, allowing the ping traffic
to continue.
64 bytes from 184.25.76.114: icmp_seq=69 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=70 ttl=52 time=8.822 ms\
64 bytes from 184.25.76.114: icmp_seq=71 ttl=52 time=9.034 ms\
64 bytes from 184.25.76.114: icmp_seq=72 ttl=52 time=9.536 ms\
64 bytes from 184.25.76.114: icmp_seq=73 ttl=52 time=8.877 ms\
64 bytes from 184.25.76.114: icmp_seq=74 ttl=52 time=8.901 ms\
Request timeout for icmp_seq 75\
64 bytes from 184.25.76.114: icmp_seq=76 ttl=52 time=8.860 ms\
64 bytes from 184.25.76.114: icmp_seq=77 ttl=52 time=9.174 ms\
64 bytes from 184.25.76.114: icmp_seq=78 ttl=52 time=10.108 ms\
64 bytes from 184.25.76.114: icmp_seq=79 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=80 ttl=52 time=10.861 ms\
64 bytes from 184.25.76.114: icmp_seq=81 ttl=52 time=10.757 ms\
64 bytes from 184.25.76.114: icmp_seq=82 ttl=52 time=8.158 ms\
64 bytes from 184.25.76.114: icmp_seq=83 ttl=52 time=8.639 ms}
You can log into the cluster GUI or CLI using the same IP address as you had been using to the log into the primary
FortiGate. If the primary FortiGate is powered off you will be logging into the backup FortiGate. Check the host name to
verify the FortiGate that you have logged into. The FortiGate continues to operate in HA mode and if you restart the
primary FortiGate, after a few minutes it should rejoin the cluster and operate as the backup FortiGate. Traffic should
not be disrupted when the restarted primary unit rejoins the cluster.
1. To test failover of the redundant Internet configuration, you must simulate a failed Internet connection to one of the
ports. You can do so by disconnecting power from the wan1 switch or otherwise disconnecting the wan1 interfaces
of both FortiGates from ISP 1.
2. Verify that users still have Internet access by navigating to Monitor > SD-WAN Monitor. The Upload and
Download values for WAN1 show that traffic isn’t going through that interface.
3. Go to Network > SD-WAN. In the SD-WAN Usage section, you can see that bandwidth, volume, and sessions
have diverted entirely through WAN2.
Users on the internal network shouldn’t notice the WAN1 failure. Likewise, if you’re using the WAN1 gateway IP
address to connect to the admin dashboard, nothing should change from your perspective. It appears as though
you’re still connecting through WAN1.
4. After you verify successful failover, re-establish the connection to ISP 1.
Security profiles
This section contains information about using FortiOS security features to protect your network.
In this recipe, you block access to Facebook using web filtering, while making an exception to allow access to Workplace
by Facebook.
1. To make sure the features you need are available in the GUI, go to System > Feature Visibility. Under Security
Features, enable Web Filter. Under Additional Features, enable Multiple Security Profiles.
2. To create a web filter profile, go to Security Profiles > Web Filter and select .
3. Enter a Name for the profile. Under Static URL Filter, enable URL Filter. Create a new URL filter to block
Facebook. Set URL to facebook.com, Type to Wildcard, and Action to Block.
4. Create a URL filter to allow Workplace by Facebook. Set URL to your Workplace by Facebook site (in the example,
fortinet.facebook.com), Type to Simple, and Action to Allow.
URL filters are applied in the order that they are listed. Make sure the filter allowing Workplace by Facebook is
located above the filter blocking Facebook.
1. To apply the security profiles to traffic, go to Policy > IPv4 Policy and edit the policy allowing Internet access.
2. Under Security Profiles, enable Web Filter and set it to use the new profiles.
3. Set SSL Inspection to certificate-inspection.
Results
Attempt to access www.facebook.com. Access is blocked. Access is also blocked for the Facebook app.
Browse to your Workplace by Facebook site. Access is allowed.
To view information about the blocked traffic, go to FortiView > Threats. The page shows the blocked attempts to
access Facebook.
In this recipe, you will turn on flow-based inspection on your FortiGate and apply flow-based antivirus scanning to
network traffic.
For more information about the different antivirus inspection modes available in FortiOS, see FortiOS antivirus
inspection modes.
1. Flow-based is the default inspection mode for FortiOS. To verify that your FortiGate is in this mode, go to System
> Settings and locate System Operations Settings.
2. Verify that Inspection Mode is set to Flow-based and NGFW Mode is set to Profile-based.
1. Go to System > Feature Visibility and verify that AntiVirus is enabled under Security Features.
Using the deep-inspection profile may cause certificate errors. See Preventing certification
warnings for more information.
Results
1. To test the antivirus scanning, go to www.eicar.org and attempt to download a test file. The browser will display a
message denying permission to download the file.
2. To view information about the blocked file, go to FortiView > Traffic from LAN/DMZ > Threats.
In this recipe, you will add a FortiSandbox to the Fortinet Security Fabric and configure each FortiGate in the network to
send suspicious files to FortiSandbox for sandbox inspection. The FortiSandbox scans and tests these files in isolation
from your network.
This example uses the Security Fabric configuration created in the Fortinet Security Fabric collection recipe. The
FortiSandbox connects to the root FortiGate in the Security Fabric, known as External. There are two connections
between the devices:
l FortiSandbox port 1 (administration port) connects to Edge port 16
l FortiSandbox port 3 (VM outgoing port) connects to Edge port 13
If possible, you can also use a separate Internet connection for FortiSandbox port 3, rather than connecting through the
Edge FortiGate to use your main Internet connection. This configuration avoids having IP addresses from your main
network blacklisted if malware that’s tested on the FortiSandbox generates an attack. If you use this configuration, you
can skip the steps listed for FortiSandbox port 3.
On Edge (the root FortiGate in the Security Fabric), go to Security Fabric > Security Rating.
Since you haven’t yet installed a FortiSandbox in your network, the Security Fabric fails the Advanced Threat
Protection check.
In the example, the Security Rating Score decreases by 30 points for each of the four FortiGates in the Security
Fabric.
4. Edit port3.
This port is used for outgoing communication by the virtual machines (VMs) running on the FortiSandbox. It’s
recommended that you connect this port to a dedicated interface on your FortiGate to protect the rest of the
6. To add a static route, go to Network > System Routing. Set Gateway to the IP address of the FortiGate
interface that port 1 connects to (in the example, 192.168.65.2).
7. Connect to Edge.
8. To configure the port that connects to port3 on the FortiSandbox (in the example, port13), go to Network >
Interfaces. Set IP/Network Mask to an address on the same subnet as port 3 on the FortiSandbox (in the
example, 192.168.179.2/255.255.255.0)
1. Connect to Edge.
2. To create a policy that allows connections from the FortiSandbox to the Internet, go to Policy & Objects > IPv4
Policy.
3. Connect to FortiSandbox.
4. Go to Scan Policy > General and select Allow Virtual Machines to access external network through
outgoing port3. Set Gateway to the IP address of port 13 on the FortiGate.
5. Go to the Dashboard and locate the System Information widget. Verify that VM Internet Access has a green
checkmark beside it.
1. Connect to Edge.
2. To add FortiSandbox to the Security Fabric, go to Security Fabric > Settings. Enable Sandbox Inspection.
3. Make sure FortiSandbox Appliance is selected and set Server to the IP address of port 1 on the FortiSandbox.
4. Select Test Connectivity. An error message appears because Edge hasn’t been authorized on the FortiSandbox.
5. Edge, as the root FortiGate, pushes FortiSandbox settings to the other FortiGates in the Security Fabric. To verify
this, connect to Accounting and go to Security Fabric > Settings.
6. On the FortiSandbox, go to Scan Input > Device. The FortiGates in the Security Fabric (Edge, Accounting,
Marketing, and Sales) are listed but the Auth column indicates that the devices are unauthorized.
7. Select and edit Edge. Under Permissions & Policies, select Authorized.
9. On Edge, go to Security Fabric > Settings and test the Sandbox Inspection connectivity again. External is now
connected to the FortiSandbox.
You can apply sandbox inspection with three types of security inspection: antivirus, web filter, and FortiClient
compliance profiles. In this step, you add sandbox to all FortiGate devices in the Security Fabric individually, using the
profiles that each FortiGate applies to network traffic.
In order to pass the Advanced Threat Protection check, you must add sandbox inspection to antivirus profiles for all
FortiGate devices in the Security Fabric.
1. Go to Security Profiles > AntiVirus and edit the default profile.
2. Under Inspection Options, set Send Files to FortiSandbox Appliance for Inspection to All Supported
Files.
Enable Use FortiSandbox Database, so that if the FortiSandbox discovers a threat, it adds a signature for that
file to the antivirus signature database on the FortiGate.
3. Go to Security Profiles > Web Filter and edit the default profile.
4. Under Static URL Filter, enable Block malicious URLs discovered by FortiSandbox.
If the FortiSandbox discovers a threat, the URL that threat came from is added to the list of URLs that are blocked
by the FortiGate.
5. Go to Security Profiles > FortiClient Compliance Profiles and edit the default profile. Enable Security
Posture Check.
6. Enable Realtime Protection and Scan with FortiSandbox.
Results
If a FortiGate in the Security Fabric discovers a suspicious file, it sends the file to the FortiSandbox.
You can view information about scanned files on either the FortiGate that sent the file or the FortiSandbox.
1. On one of the FortiGate devices, go to the Dashboard and locate the Advanced Threat Protection Statistics widget.
This widget shows files that both the FortiGate and FortiSandbox scan.
2. On the FortiSandbox, go to System > Status and view the Scanning Statistics widget for a summary of scanned
files.
You can also view a timeline of scanning in the File Scanning Activity widget.
3. On Edge, go to Security Fabric > Security Rating and run a rating. When it is finished, select the All Results view.
In the example, all four FortiGate devices in the Security Fabric pass the Advanced Threat Protection check and the
Security Rating Score increases by 9.7 points for each FortiGate.
DNS Filtering
In this recipe you will set up DNS filtering to block access to bandwidth consuming websites.
Following the results section, you will find instructions for changing the FortiDNS server that your FortiGate will use to
verify domains, as well as troubleshooting information.
If DNS Filter is not listed under Security Profiles, go to System > Feature Visibility, and enable DNS Filter under
Security Features.
1. Go to Security Profiles > DNS Filter, and edit the default profile.
2. Enable FortiGuard category based filter, right-click Bandwidth Consuming, and set it to Block.
All traffic that matches this policy will be redirected to the FortiDNS server.
1. Go to Policy & Objects > IPv4 Policy, and edit the outgoing policy that allows Internet access.
2. Under Security Profiles, enable DNS Filter and set it to default.
Results
Open a browser using a computer on the internal network and navigate to dailymotion.co.uk. The page will be blocked.
Enter the following CLI command to sniff packets with a destination URL that does not belong to the bandwidth
consuming category:
diagnose sniffer packet any 'port 53' and 'host 194.153.110.160' 4
The resulting output should indicate that the IP (in this example, paris.fr) was allowed by FortiGuard:
interfaces=[any]
filters=[port 53]
2.851628 172.20.121.56.59046 -> 208.91.112.52.53: udp 43
2.916281 208.91.112.52.53 -> 172.20.121.56.59046: udp 436
3.336945 10.1.2.102.51755 -> 208.91.112.53.53: udp 37
3.338611 208.91.112.53.53 -> 10.1.2.102.51755: udp 37
You can use the default FortiDNS server located in Sunnyvale, USA (IP address 208.91.112.220), or you can switch to
the server in London, UK (IP address 80.85.69.54).
Communication between your FortiGate and the FortiDNS server uses Fortinet’s proprietary DNS communication
protocol.
The North American server should work in most cases, however you can switch to the European server to see if it
improves latency.
You can also change the port used to communicate with the FortiDNS server using the following command:
config system fortiguard
set sdns-server-port <value>
end
Troubleshooting
Verify that DNS Filter is enabled in a policy and SSL Inspection has been applied as needed (SSL inspection is
required in order to block traffic to sites that use HTTPS).
If both settings are enabled, verify that the policy is being used for the correct traffic and that traffic is flowing by going to
the policy list and viewing the Sessions column.
If the above settings are correct, verify that DNS requests are going through the policy, rather than to an internal DNS
server. Also verify that proxy options and SSL/SSH inspection settings have both HTTP and HTTPS enabled and use the
correct ports.
Verify that the correct FortiDNS server is configured using the following diagnose command:
diag test application dnsproxy 3
The resulting output should indicate that communication with the correct FortiDNS server was established. For
example:
FWF60D4615016384 # diag test application dnsproxy 3
vdom: root, index=0, is master, vdom dns is enabled, mip-169.254.0.1 dns_log=1
dns64 is disabled
dns-server:208.91.112.53:53 tz=0 req=919160 to=545900 res=117880 rt=1800 secure=0
ready=1
dns-server:208.91.112.52:53 tz=0 req=913029 to=520111 res=134810 rt=6 secure=0
ready=1
dns-server:208.91.112.220:53 tz=-480 req=0 to=0 res=0 rt=0 secure=1 ready=1
dns-server:80.85.69.54:53 tz=0 req=0 to=0 res=0 rt=0 secure=1 ready=1
vfid=0, interface=wan1, ifindex=6, recursive, dns
DNS_CACHE: hash-size=2048, ttl=1800, min-ttl=60, max-num=5000
The resulting output should indicate that the IP (in this example, dailymotion.co.uk) was blocked by the FortiDNS
server:
interfaces=[any]
filters=[port 53]
2.026733 172.20.121.56.59046 -> 208.91.112.220.53: udp 117
2.027316 172.20.121.56.59046 -> 80.85.69.54.53: udp 112
2.028480 172.20.121.56.59046 -> 208.91.112.220.53: udp 116
2.029591 172.20.121.56.59046 -> 208.91.112.220.53: udp 117
If you believe a website has been placed in the wrong category by FortiGuard, you can submit the URL for re-
classification by going to the FortiGuard website.
In this recipe you will configure the default AntiVirus security profile to include a new FortiOS 6.0 feature: Content
Disarm and Reconstruction (CDR). You will apply this security profile to the Internet access policy so that exploitable
content leaving the network is stripped from documents and replaced with content that is known to be safe.
In the example, we will use FortiSandbox as the original file destination, where the original file is archived and can be
retrieved if necessary. The CDR feature works without FortiSandbox configured, but only if you wish to discard the
original file.
Content that can be scanned includes PDF and Microsoft Office files leaving the network on CDR-supported protocols*
(for more information, refer to the Security Profiles handbook).
Note that the FortiGate must be in Proxy inspection mode for CDR to function.
Go to System > Settings and set System Operation Settings > Inspection Mode to Proxy.
1. On the FortiGate, go to Security Fabric > Settings and enable Sandbox Inspection.
2. Select your FortiSandbox type and Server address.
3. Confirm that the service is available by selecting Test connectivity.
The Status should read "Service is online."
If you enable FortiSandbox as the file destination, original files caught by the AntiVirus profile are archived on the
FortiSandbox. The FortiSandbox administrator can retrieve the original files, but only for a short time.
If you enable either File Quarantine or Discard as the file destination, original files caught by the AntiVirus profile
are lost. Only the disarmed content is made available.
1. Go to Policy & Objects > IPv4 Policy and Edit the Internet access policy.
2. Under Security Profiles, enable the default AntiVirus profile. Proxy Options and SSL Inspection are
automatically enabled.
Results
As the AntiVirus profile scans files using CDR, it replaces content that is deemed malicious or unsafe with content that
will allow the traffic to continue but not put the recipient at risk.
CDR appends a new cover page to the malicious/unsafe content that includes a replacement message.
If you wish to disable the cover page, enter the following commands in the CLI Console:
config antivirus profile
edit default
config content-disarm
set cover-page disable
end
end
Troubleshooting
Confirm that the Inspection Mode is set to Proxy under System > Settings.
Also check that the AntiVirus profile inspection mode is set to proxy using the CLI Console:
config antivirus profile
edit default
set inspection-mode proxy
next
end
If you receive an error message when attempting to enable Content Disarm and Reconstruction on the AntiVirus profile,
check the Proxy Options settings in the CLI Console and disable splice and clientcomfort on CDR-supported
protocols:
>config firewall profile-protocol-options
>edit default
>config smtp
>unset options splice
>next
>config http
>unset options clientcomfort
>next
>end
>end
You should also confirm the AntiVirus profile’s protocol settings under config antivirus profile:
l ensure that set options scan is enabled on CDR-supported protocols
l if set options av-monitor is configured on a CDR-supported protocol, it overrides the config content-
disarm detect-only setting (and CDR will not occur)
If testing the FortiSandbox connectivity returns a “Service is unreachable” error message, then you may need to
authorize the FortiGate on the FortiSandbox.
On the FortiSandbox, go to Scan Input > Device and edit the entry for the FortiGate.
Under Permissions & Policy, enable Authorized.
In this recipe, you prevent users from receiving a security certificate warning when your FortiGate performs full SSL
inspection on incoming traffic. There are several methods for doing this, depending on whether you're using a CA-
signed certificate, as presented here, your FortiGate default certificate (see Preventing certificate warnings (default
certificate) on page 229, or a self-signed certification (see Preventing certificate warnings (self-signed) on page 236).
When you enable full SSL inspection, your FortiGate impersonates the recipient of the originating SSL session, then
decrypts and inspects the content. The FortiGate then re-encrypts the content, creates a new SSL session between the
FortiGate and the recipient by impersonating the sender, and sends the content to the end user. This is the same
process used in "man-in-the-middle" attacks, which is why a user's device may show a security certificate warning.
For more information about SSL inspection, see Why you should use SSL inspection on page 244.
Often, when users receive security certificate warnings, they simply select Continue without understanding why the
error is occurring. To avoid encouraging this habit, you can prevent the warning from appearing in the first place.
In this method, you obtain a CA-signed certificate and install this certificate on your FortiGate to use with SSL
inspection. In order to implement SSL inspection, you also need to add another security profile to your policy controlling
Internet traffic. You can use either FortiAuthenticator as your CA or a trusted private CA.
If you use FortiAuthenticator as a CA, you generate a certificate signing request (CSR) on your FortiGate, have it signed
on the FortiAuthenticator, import the certificate into your FortiGate, and configure your FortiGate to use the certificate
for SSL deep inspection of HTTPS traffic.
If you use a trusted private CA, you generate a CSR on your FortiGate, apply for an SSL certificate from the trusted
private CA, import the certificate into your FortiGate, and configure your FortiGate so the certificate can be used for SSL
deep inspection of HTTPS traffic.
1. On your FortiGate, create a new CSR by going to System > Certificates and select Generate.
2. Enter a Certificate Name, the external IP of your FortiGate, and a valid email address.
3. To ensure the certificate is securely encrypted, set Key Type to RSA and Key Size to 2048 Bit (the industry
standard).
Once generated, the certificate shows a Status of Pending. To save the .csr file to your local drive, highlight the
certificate and select Download.
If you want to use a trusted private CA to sign the certificate, use the CSR to apply for an SSL certificate with your
trusted private CA.
FortiAuthenticator:
1. If you want to use a FortiAuthenticator as a CA to sign the certificate, on the FortiAuthenticator, go to Certificate
Management > Certificate Authorities > Local CAs and select Import.
2. Set Type to CSR to sign, enter a Certificate ID, and import the example-cert.csr file. Make sure to select the
Certificate authority from the drop-down menu and set the Hash algorithm to SHA-256.
3. Once imported, you should see that example_cert has been signed by the FortiAuthenticator, showing a Status of
Active, and with the CA Type of Intermediate (non-signing) CA. Highlight the certificate and select Export.
This will save the example_cert.crt file to your local drive.
1. On your FortiGate, go to System > Certificates and select Local Certificate from the Import drop-down menu.
You should now see that the certificate has a Status of OK.
1. To use your certificate in an SSL inspection profile go to Security Profiles > SSL/SSH Inspection. Use the
dropdown menu in the top right corner to select deep-inspection.
2. The deep-inspection profile is read-only. To use the CA-signed certificate for SSL inspection, you must clone the
deep-inspection profile and configure the new profile to use your certificate. To clone an existing profile, select the
Clone icon (one page behind another) and enter a new name when prompted. In this example, the name of the
profile is custom-deep-inspection.
4. Verify that SSL inspection is applied to your policy that controls traffic to the Internet. You must also apply at least
one other security profile to that policy in order to implement SSL inspection. In this example, we apply antivirus.
Once your certificate is signed by FortiAuthenticator, you need to import the certificate into users' browsers.
If you have the right environment, such as the Windows Group Policy Management Console,
you can push the certificate to users' browsers using the Windows Group Policy Editor. In this
case, you do not have to import the certificate into users' browsers.
The method you use for importing the certificate varies depending on the type of browser.
Internet Explorer, Chrome, and Safari use the operating system's certificate store for Internet browsing. If users will be
using these browsers, you must install the certificate into the certificate store for the OS.
1. If you are using Windows 7/8/10, double-click the certificate file and select Open. Select Install Certificate to
launch the Certificate Import Wizard.
2. Use the wizard to install the certificate into the Trusted Root Certificate Authorities store. If a security warning
appears, select Yes to install the certificate.
3. If you are using macOS, double-click the certificate file to launch Keychain Access.
4. Locate the certificate in the Certificates list and select it. Expand Trust and select Always Trust. If necessary,
enter the administrative password for your computer to make this change.
Firefox has its own certificate store. To avoid errors in Firefox, the certificate must be installed in this store, rather than
in the OS.
If users are using Firefox, instead of being pushed to all of their devices, the certificate must be installed on each
device.
1. In Firefox, go to Options > Privacy & Security (Windows) or Preferences > Privacy & Security (macOS).
2. Scroll down to the Certificates section. Select View Certificates, select the Authorities list. Import the
Results
Before you install the certificate, an error message appears in users' browsers when they access a site that uses HTTPS
(this example shows an error message in Firefox).
After you install the certificate, users shouldn't experience a certificate security issue when they browse to sites that the
FortiGate performs SSL content inspection on.
Users can view information about the connection and the certificate that's used.
When users view information about the connection, they'll see that it's verified by Fortinet.
When users view the certificate in the browser, they will see which certificate is used and information about that
certificate.
In this recipe, you prevent users from receiving a security certificate warning when your FortiGate performs full SSL
inspection on incoming traffic. There are several methods for doing this, depending on whether you're using your
ForiGate default certificate, as presented here, your a CA-signed certificate (see Preventing certificate warnings (CA-
signed certificate) on page 218, or a self-signed certification (see Preventing certificate warnings (self-signed) on page
236).
When you enable full SSL inspection, your FortiGate impersonates the recipient of the originating SSL session, then
decrypts and inspects the content. The FortiGate then re-encrypts the content, creates a new SSL session between the
FortiGate and the recipient by impersonating the sender, and sends the content to the end user. This is the same
process used in "man-in-the-middle" attacks, which is why a user's device may show a security certificate warning.
For more information about SSL inspection, see Why you should use SSL inspection on page 244.
Often, when users receive security certificate warnings, they simply select Continue without understanding why the
error is occurring. To avoid encouraging this habit, you can prevent the warning from appearing in the first place.
All FortiGate devices have a default certificate that’s used for full SSL inspection. This certificate is also used in the
default deep-inspection profile. To prevent users from seeing certificate warnings, you can install this certificate on
users’ devices.
Run the following CLI command to generate an SSL certificate that’s unique to your FortiGate:
exec vpn certificate local generate default-ssl-ca
1. Go to Security Profiles > SSL/SSH Inspection. Use the drop-down menu in the top right corner to select deep-
inspection, which is the profile used to apply full SSL inspection.
2. The default FortiGate certificate is listed as the CA Certificate. Select Download Certificate.
Before you import the certificate, verify that SSL inspection is applied to your policy that controls traffic to the Internet.
You must also apply at least one other security profile to that policy in order to implement SSL inspection
Once you have your FortiGate device’s default certificate, you need to import the certificate into users’ browsers.
If you have the right environment, such as the Windows Group Policy Management Console,
you can push the certificate to users' browsers using the Windows Group Policy Editor. In this
case, you do not have to import the certificate into users' browsers.
The method you use for importing the certificate varies depending on the type of browser.
Internet Explorer, Chrome, and Safari use the operating system's certificate store for Internet browsing. If users will be
using these browsers, you must install the certificate into the certificate store for the OS.
1. If you are using Windows 7/8/10, double-click the certificate file and select Open. Select Install Certificate to
launch the Certificate Import Wizard.
2. Use the wizard to install the certificate into the Trusted Root Certificate Authorities store. If a security warning
appears, select Yes to install the certificate.
3. If you are using macOS, double-click the certificate file to launch Keychain Access.
4. Locate the certificate in the Certificates list and select it. Expand Trust and select Always Trust. If necessary,
enter the administrative password for your computer to make this change.
Firefox has its own certificate store. To avoid errors in Firefox, the certificate must be installed in this store, rather than
in the OS.
If users are using Firefox, instead of being pushed to all of their devices, the certificate must be installed on each
device.
1. In Firefox, go to Options > Privacy & Security (Windows) or Preferences > Privacy & Security (macOS).
2. Scroll down to the Certificates section. Select View Certificates, select the Authorities list. Import the
Results
Before you install the certificate, an error message appears in users' browsers when they access a site that uses HTTPS
(this example shows an error message in Firefox).
After you install the certificate, users shouldn't experience a certificate security issue when they browse to sites that the
FortiGate performs SSL content inspection on.
Users can view information about the connection and the certificate that's used.
When users view information about the connection, they'll see that it's verified by Fortinet.
When users view the certificate in the browser, they will see which certificate is used and information about that
certificate.
In this recipe, you prevent users from receiving a security certificate warning when your FortiGate performs full SSL
inspection on incoming traffic. There are several methods for doing this, depending on whether you're using a self-
signed certificate, as presented here, your FortiGate default certificate (see Preventing certificate warnings (default
certificate) on page 229, or a CA-signed certification (see Preventing certificate warnings (CA-signed certificate) on page
218).
When you enable full SSL inspection, your FortiGate impersonates the recipient of the originating SSL session, then
decrypts and inspects the content. The FortiGate then re-encrypts the content, creates a new SSL session between the
FortiGate and the recipient by impersonating the sender, and sends the content to the end user. This is the same
process used in "man-in-the-middle" attacks, which is why a user's device may show a security certificate warning.
For more information about SSL inspection, see Why you should use SSL inspection on page 244.
Often, when users receive security certificate warnings, they simply select Continue without understanding why the
error is occurring. To avoid encouraging this habit, you can prevent the warning from appearing in the first place.
1. If necessary, download and install Open SSL. Make sure that the openssl.cnf file is located in the BIN folder for
OpenSSL.
2. Using a command prompt (CMD), navigate to the BIN folder.
In this example, the command is:
cd c:\OpenSSL\bin
3. Generate an RSA key with the following command:
openssl genrsa -aes256 -out fgcaprivkey.pem 2048 -config openssl cnf
This RSA key uses AES-256 encryption and a 2048-bit key.
4. When prompted, enter a passphrase for encrypting the private key.
Use the following command to launch OpenSSL, submit a new certificate request, and sign the request:
openssl req -new -x509 -days 3650 -extensions v3_ca -key fgcaprivkey.pem -out fgcacert.pem
-config openssl.cnf
The result is a standard x509 binary certificate that’s valid for 3650 days (approximately 10 years).
5. When prompted, re-enter the passphrase for encryption, then enter the details required for the certificate request,
such as location and organization name.
Two new files are created: a public certificate (fgcacert.pem) and a private key (fgcaprivkey.pem).
1. To use your certificate in an SSL inspection profile go to Security Profiles > SSL/SSH Inspection. Use the
dropdown menu in the top right corner to select deep-inspection.
2. The deep-inspection profile is read-only. To use the CA-signed certificate for SSL inspection, you must clone the
deep-inspection profile and configure the new profile to use your certificate. To clone an existing profile, select the
Clone icon (one page behind another) and enter a new name when prompted. In this example, the name of the
profile is custom-deep-inspection.
Before you import the certificate, verify that SSL inspection is applied to your policy that controls traffic to the Internet.
You must also apply at least one other security profile to that policy in order to implement SSL inspection.
Once you have your self-signed certificate, you need to import the certificate into users’ browsers.
If you have the right environment, such as the Windows Group Policy Management Console,
you can push the certificate to users' browsers using the Windows Group Policy Editor. In this
case, you do not have to import the certificate into users' browsers.
The method you use for importing the certificate varies depending on the type of browser.
Internet Explorer, Chrome, and Safari use the operating system's certificate store for Internet browsing. If users will be
using these browsers, you must install the certificate into the certificate store for the OS.
1. If you are using Windows 7/8/10, double-click the certificate file and select Open. Select Install Certificate to
launch the Certificate Import Wizard.
2. Use the wizard to install the certificate into the Trusted Root Certificate Authorities store. If a security warning
appears, select Yes to install the certificate.
3. If you are using macOS, double-click the certificate file to launch Keychain Access.
4. Locate the certificate in the Certificates list and select it. Expand Trust and select Always Trust. If necessary,
enter the administrative password for your computer to make this change.
Firefox has its own certificate store. To avoid errors in Firefox, the certificate must be installed in this store, rather than
in the OS.
If users are using Firefox, instead of being pushed to all of their devices, the certificate must be installed on each
device.
1. In Firefox, go to Options > Privacy & Security (Windows) or Preferences > Privacy & Security (macOS).
2. Scroll down to the Certificates section. Select View Certificates, select the Authorities list. Import the
Results
Before you install the certificate, an error message appears in users' browsers when they access a site that uses HTTPS
(this example shows an error message in Firefox).
After you install the certificate, users shouldn't experience a certificate security issue when they browse to sites that the
FortiGate performs SSL content inspection on.
Users can view information about the connection and the certificate that's used.
When users view information about the connection, they'll see that it's verified by Fortinet.
When users view the certificate in the browser, they will see which certificate is used and information about that
certificate.
Most of us are familiar with HTTPS and how it protects a variety of activities on the Internet by applying SSL encryption
to the web traffic.
Using HTTPS provides the benefit of using encryption keeps your private data safe from prying eyes. However, there are
risks associated with its use, since encrypted traffic can be used to get around your normal defenses.
For example, you might download a file containing a virus during an e-commerce session. Or you could receive a
phishing email containing a seemingly harmless downloader file that, when launched, creates an encrypted session to a
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.
To protect your network from these threats, SSL inspection is the key your FortiGate uses to unlock encrypted sessions,
see into encrypted packets, find threats, and block them. SSL inspection not only protects you from attacks that use
HTTPS, but also from other commonly used encrypted protocols, such as SMTPS, POP3S, IMAPS, and FTPS.
To make sure that all encrypted content is inspected, you must use full SSL inspection (also known as deep inspection).
When full SSL inspection is used, the FortiGate impersonates the recipient of the originating SSL session, then decrypts
and inspects the content. The FortiGate then re-encrypts the content, creates a new SSL session between the
FortiGate and the recipient by impersonating the sender, and sends the content to the sender.
When the FortiGate re-encrypts the content it uses a certificate stored on the FortiGate. The client must trust this
certificate to avoid certificate errors. Whether or not this trust exists depends on the client, which can be the computer’s
OS, a browser, or another application, which will likely maintain its own certificate repository.
There are two deployment methods for full SSL inspection:
l Uses a server certificate (which can be uploaded using the Certificates menu) to protect a single server
l Typically used on inbound policies to protect servers available externally through Virtual IPs
l Since this is typically deployed “outside-in” (clients on the Internet accessing server(s) on the internal side of the
FortiGate), server certificates using the public FQDN of the server are often purchased from a commercial
Certificate Authority and uploaded to the FortiGate. This avoids client applications generating SSL certificate errors
due to certificate mismatch.
More detail is available in the FortiOS Online Help. Also, check the Fortinet Knowledge Base for these technical notes:
l How to Enable SSL inspection from the CLI and Apply it to a Policy
l How to block web-based chat on Gmail webmail using App Sensor + SSL inspection
The FortiGate also supports a second type of SSL inspection, called SSL certificate inspection. When certificate
inspection is used, the FortiGate inspects only the header information of the packets.
Certificate inspection is used to verify the identity of web servers and can be used to make sure that HTTPS protocol is
not used as a workaround to access sites you have blocked using web filtering.
The only security feature that can be applied using SSL certificate inspection mode is web filtering. However, since only
the packet header is inspected, this method does not introduce certificate errors and can be a useful alternative to full
SSL inspection when web filtering is used.
When using SSL certificate inspection, you may get certificate errors for blocked websites, due to your FortiGate
attempting to display a replacement message for that site using HTTPS. To prevent these errors, you must install the
certificate that the FortiGate uses for encryption in your browser. By default, this is the same certificate used for SSL
inspection.
For more information, see:
l Preventing certificate warnings (CA-signed certificate) on page 218.
l Preventing certificate warnings (default certificate) on page 229.
l Preventing certificate warnings (self-signed) on page 236
Troubleshooting
The most common problem with SSL inspection is users receiving SSL errors when the certificate is not trusted. This is
because, by default, the FortiGate uses a certificate that is not trusted by the client. There are several methods to fix
this, depending on whether you are using your FortiGate’s default certificate, a self-signed certificate, or a CA-signed
certificate.
Best practices
Because all traffic needs to be decrypted, inspected, and re-encrypted, using SSL inspection can reduce the overall
performance of your FortiGate. To avoid using too many resources for SSL inspection, do the following:
l Know your traffic – Know how much traffic is expected and what percentage of the traffic is encrypted. You can
also limit the number of policies that allow encrypted traffic.
l Be selective – Use whitelists or trim your policy to apply SSL inspection only where it is needed.
l Use hardware acceleration – FortiGate models with either the CP6 or CPU processor have an SSL/TLS protocol
processor for SSL content scanning and SSL acceleration. For more information about this, see the Hardware
Acceleration handbook.
l Test real-world SSL inspection performance yourself – Use the flexibility of FortiGate’s security policy to
gradually deploy SSL inspection, rather than enabling it all at once.
VPNs
This section contains information about creating and using a virtual private network (VPN).
In this example, you will allow remote users to access the corporate network using an SSL VPN, connecting either by
web mode using a web browser or tunnel mode using FortiClient.
Web mode allows users to access network resources, such as the the AdminPC used in this example.
For users connecting via tunnel mode, traffic to the Internet will also flow through the FortiGate, to apply security
scanning to this traffic. During the connecting phase, the FortiGate will also verify that the remote user’s antivirus
software is installed and up-to-date.
This recipe is in the Basic FortiGate network collection. You can also use it as a standalone recipe.
1. To edit the full-access SSL VPN portal, go to VPN > SSL-VPN Portals. The full-access portal allows the use of
tunnel mode and web mode.
2. Under Tunnel Mode, disable Enable Split Tunneling for both IPv4 and IPv6 traffic to ensure all Internet traffic
will go through the FortiGate.
3. Set Source IP Pools to use the default IP range SSLVPN_TUNNEL-ADDR1.
4. Under Enable Web Mode, create Predefined Bookmarks for any internal resources that the SSL VPN users
need to access. In the example, the bookmark allows the remote user RDP access to a computer on the internal
network.
4. Under Tunnel Mode Client Settings, set IP Ranges to use the default IP range SSLVPN_TUNNEL-ADDR1.
5. Under Authentication/Portal Mapping, click Create New to add the Employee user group and map it to the full-
access portal.
6. If necessary, map a portal for All Other Users/Groups.
1. To add an address for the local network, go to Policy & Objects > Addresses.
2. Set Type to Subnet, Subnet/IP Range to the local subnet, and Interface to lan.
3. To create a security policy allowing access to the internal network through the VPN tunnel interface, go to Policy &
Objects > IPv4 Policy.
4. Set Incoming Interface to ssl.root and Outgoing Interface to lan. Select Source and set Address to all and
User to the Employee user group. Set Destination Address to the local network address, Service to ALL, and
enable NAT.
5. Add a second security policy allowing SSL VPN access to the Internet.
6. For this policy, set Incoming Interface to ssl.root and Outgoing Interface to wan1. Select Source and set
Address to all and User to the Employee user group.
To verify that remote users are using up-to-date devices to connect to your network, you can configure a host check for
both operating system (supported for Windows and Mac OS) and software.
You can configure an OS host check for specific OS versions. This check includes the following options: allow the device
to connect, block the device, or check that the OS is up-to-date. The default action for all OS versions is allow.
The software host can verify whether the device has AntiVirus software recognized by Windows Security Center, firewall
software recognized by Windows Security Center, both, or a custom setting.
Configure both checks using the CLI:
config vpn ssl web portal
edit full-access
set os-check enable
config os-check-list {macos-high-sierra-10.13 | macos-sierra-10.12 | os-x-el-capitan-
10.11 | os-x-mavericks-10.9 | os-x-yosemite-10.10 |windows-7 | windows-8 |
windows-8.1 | windows-10 | windows-2000 | windows-vista | windows-xp}
set action {deny | allow | check-up-to-date}
end
set host-check {av | fw | av-fw| custom}
end
Results
The steps for connecting to the SSL VPN differ depending on whether you are using a web browser or FortiClient.
Web browsers
1. Using a supported Internet browser, connect to the SSL VPN web portal using the remote gateway configured in
the SSL VPN settings (in the example, https://172.25.176.62:10443).
2. Log in to the SSL VPN.
3. After authenticating, you can access the SSL-VPN Portal. From this portal, you can launch or download
FortiClient, access Bookmarks, or connect to other resources using the Quick Connection tool.
In this example, selecting the bookmark enables you to connect to the AdminPC.
4. To connect to the Internet, select Quick Connection. Select HTTP/HTTPS, then enter the URL and select
Launch.
5. To view the list of users currently connected to the SSL VPN, go to Monitor > SSL-VPN Monitor. The user is
connected to the VPN.
6. If a remote device fails the OS or host check, a warning message appears after authentication instead of the portal.
FortiClient
6. To view the list of users currently connected to the SSL VPN, go to Monitor > SSL-VPN Monitor. The user is
connected to the VPN.
In this recipe, you configure a FortiAuthenticator as a RADIUS server to use with a FortiGate SSL VPN. Remote users
connect to the SSL VPN using FortiClient and use FortiToken for two-factor authentication.
If you do not already have an SSL VPN tunnel configured, see SSL VPN using web and tunnel mode.
1. To create a user account, connect to the FortiAuthenticator, go to Authentication > User Management > Local
Users, and select Create New.
2. Enter a Username and set Password creation to Specify a password. Enter and confirm the password. Enable
Allow RADIUS authentication and set Role to User.
3. After you create the user, more options are available. Edit the account and enable Token-based authentication.
4. Set Deliver token code by to FortiToken. Set FortiToken Mobile to an available FortiToken. Set Delievery
method to Email.
5. Under User Information, set Email to the user’s email address.
6. To create a user group, go to Authentication > User Management > User Groups and select Create New.
Add the new user to the group.
7. After you create the user group, more options are available. Edit the group and create a new RADIUS attribute. Set
Vendor to Fortinet, set Attribute ID to Fortinet-Group-Name, and set Value to the name of the group (in the
example, SSL_VPN_RADIUS).
1. To create a RADIUS client, go to Authentication > RADIUS Service > Clients, and select Create New.
2. Enter a Name for the client. Set Client address to IP/Hostname and enter the IP address of the FortiGate (in the
example, 172.25.176.62). Set a Secret for the client.
3. Under User Authentication, set Authentication method to Apply two-factor authentication if available.
Select Enable FortiToken Mobile push notifications authentication.
4. For Realms, set the default realm to local | Local users. Under Groups, enable Filter and set it to the user
group.
1. To add the FortiAuthenticator as a RADIUS server for FortiGate, connect to the FortiGate, go to User & Device >
RADIUS Servers and select Create New.
2. Set a Name for the server and set Authentication method to Default.
3. Under Primary Server, set IP/Name to the IP address of the FortiAuthenticator (in this example, 172.25.176.141)
and set Secret to the same secret you configured on the FortiAuthenticator.
4. Select Test Connectivity to make sure you used the proper settings.
5. To import the user group, go to User & Device > User Groups and create a new group.
6. Set a Name for the group. Under Remote Groups, select +Add and select the RADIUS server. Set Groups to
the RADIUS attribute you assigned to the group (in the example, SSL_VPN_RADIUS).
2. Under Authentication/Portal Mapping, create a new entry for the RADIUS group. Set Portal to tunnel-access,
which allows users to connect using FortiClient.
3. To allow the new group access to the VPN, go to Policy & Objects > IPv4 Policy and edit the policy for the SSL
VPN. Select Source and set User to include the RADIUS group.
Results
In this recipe, you set up FortiAuthenticator to function as a RADIUS server to authenticate SSL VPN users using
FortiToken Mobile Push two-factor authentication. With Push notifications enabled, the user can easily accept or deny
the authentication request.
For this configuration, you:
l Create a user on the FortiAuthenticator.
l Assign a FortiToken Mobile license to the user.
l Create the RADIUS client (FortiGate) on the FortiAuthenticator, and enable FortiToken Mobile Push notifications.
l Connect the FortiGate to the RADIUS server (FortiAuthenticator).
l Create an SSL VPN on the FortiGate, allowing internal access for remote users.
The following names and IP addresses are used:
l Username: gthreepwood
l User group: RemoteFTMGroup
l RADIUS server: OfficeRADIUS
l RADIUS client: OfficeServer
l SSL VPN user group: SSLVPNGroup
l FortiAuthenticator: 172.25.176.141
l FortiGate: 172.25.176.92
For the purposes of this recipe, a FortiToken Mobile free trial token is used. This recipe also assumes that the user has
already installed the FortiToken Mobile application on their smartphone. You can install the application for Android and
iOS. For details, see:
1. On the FortiAuthenticator, go to Authentication > User Management > FortiTokens, and select Create New.
2. Set Token type to FortiToken Mobile, and enter the FortiToken Activation codes in the field provided.
1. On the FortiAuthenticator, go to Authentication > User Management > Local Users, and select Create New.
2. Enter a Username (gthreepwood) and enter and confirm the user password.
4. Enable Token-based authentication and select to deliver the token code by FortiToken. Select the FortiToken
added earlier from the FortiToken Mobile drop-down menu.
5. Set Delivery method to Email. This will automatically open the User Information section where you can enter
the user email address in the field provided.
6. Next, go to Authentication > User Management > User Groups, and select Create New.
7. Enter a Name (RemoteFTMUsers) and add gthreepwood to the group by moving the user from Available users
to Selected users.
8. The FortiAuthenticator sends the FortiToken Mobile activation to the user’s email address. If the email does not
appear in the inbox, check the spam folder.
9. The user activates their FortiToken Mobile through the FortiToken Mobile application by either entering the
activation code provided or by scanning the QR code attached.
1. On the FortiAuthenticator, go to Authentication > RADIUS Service > Clients, and select Create New to add
the FortiGate as a RADIUS client.
2. Enter a Name (OfficeServer), the IP address of the FortiGate, and set a Secret. The secret is a pre-shared secure
password that the FortiGate will use to authenticate to the FortiAuthenticator.
3. Set Authentication method to Enforce two-factor authentication and check the Enable FortiToken Mobile
push notifications authentication checkbox.
Note the Username input format. This is the format that the user must use to enter their
username in the web portal, made up of their username and realm. In this example, the
full username for gthreepwood is "gthreepwood@local".
4. Set Realms to local | Local users, and add RemoteFTMUsers to the Groups filter.
1. On the FortiGate, go to User & Device > RADIUS Servers, and select Create New to connect to the RADIUS
server (FortiAuthenticator).
2. Enter a Name (OfficeRADIUS), the IP address of the FortiAuthenticator, and enter the Secret created before.
3. Select Test Connectivity to be sure you can connect to the RADIUS server. Then select Test User Credentials
and enter the credentials for gthreepwood.
4. Because the user has been assigned a FortiToken, the test should come stating that More validation is
required.
5. The FortiGate can now connect to the FortiAuthenticator as the RADIUS client configured earlier.
6. Then go to User & Device > User Groups, and select Create New to map authenticated remote users to a user
group on the FortiGate.
7. Enter a Name (SSLVPNGroup) and select Add under Remote Groups.
8. Select OfficeRADIUS under the Remote Server drop-down menu, and leave the Groups field blank.
1. On the FortiGate, go to VPN > SSL-VPN Portals, and edit the full-access portal.
2. Toggle Enable Split Tunneling so that it is disabled.
access — this will grant all other users access to the web portal only.
8. Go to Policy & Objects > IPv4 Policy and create a new SSL VPN policy.
9. Set Incoming Interface to the SSL-VPN tunnel interface and set Outgoing Interface to the Internet-facing
interface (in this case, wan1).
10. Set Source to the SSLVPNGroup user group and the all address.
11. Set Destination Address to all, Schedule to always, Service to ALL, and enable NAT.
Results
1. From a remote device, open a web browser and navigate to the SSL VPN web portal (https://<fortigate-ip>:10443).
2. Enter gthreepwood‘s credentials and select Login. Use the correct format (in this case, username@realm), as
per the client configuration on the FortiAuthenticator.
3. The FortiAuthenticator will then push a login request notification through the FortiToken Mobile application. Select
Approve.
4. Upon approving the authentication, gthreepwood is successfully logged into the SSL VPN portal.
5. On the FortiGate, go to Monitor > SSL-VPN Monitor to confirm the user’s connection.
In this example, you allow remote users to access the corporate network using an IPsec VPN that they connect to using
FortiClient. The remote user Internet traffic is also routed through the FortiGate (split tunneling will not be enabled).
1. To create a new firewall address, go to Policy & Objects > Addresses and select Create New > Address.
2. Set Category to Address and enter a Name. Set Type to Subnet, Subnet/IP Range to the local subnet, and
Interface to lan.
1. To create the VPN, go to VPN > IPsec Wizard and create a new tunnel using a pre-existing template.
2. Name the VPN. The tunnel name cannot include any spaces or exceed 13 characters. Set Template to Remote
Access, and set Remote Device Type to FortiClient VPN for OS X, Windows, and Android.
3. Set the Incoming Interface to wan1 and Authentication Method to Pre-shared Key.
4. Enter a pre-shared key. This pre-shared key is a credential for the VPN and should differ from the user password.
Select the Employees group.
5. Set Local Interface to lan and set Local Address to the local network address.
6. Enter a Client Address Range for VPN users. The IP range you enter here prompts FortiOS to create a new
firewall object for the VPN tunnel using the name of your tunnel followed by the _range suffix (in the example,
IPsec-FCT_range).
7. Make sure Enable IPv4 Split Tunnel is not selected, so that all Internet traffic will go through the FortiGate. If
you do select Enable Split Tunneling, traffic not intended for the corporate network will not flow through the
FortiGate or be subject to the corporate security profiles.
9. After you create the tunnel, a summary page appears listing the objects which have been added to the FortiGate’s
configuration by the wizard.
10. To view the VPN interface created by the wizard, go to Network > Interfaces.
11. To view the firewall address created by the wizard, go to Policy & Objects > Addresses.
12. To view the security policy created by the wizard, go to Policy & Objects > IPv4 Policy.
The IPsec wizard automatically created a security policy allowing IPsec VPN users to access the internal network.
However, since split tunneling is disabled, another policy must be created to allow users to access the Internet through
the FortiGate.
1. To create a new policy, go to Policy & Objects > IPv4 Policies and select Create New. Set a policy name that
will identify what this policy is used for (in the example, IPsec-VPN-Internet).
2. Set Incoming Interface to the tunnel interface and Outgoing Interface to wan1. Set Source to the IPsec client
address range, Destination Address to all, Service to ALL, and enable NAT.
3. Configure any remaining firewall and security options as desired.
Configuring FortiClient
Results
1. On FortiClient, select the VPN, enter the username and password, and select Connect.
2. Once the connection is established, the FortiGate assigns the user an IP address and FortiClient displays the
status of the connection, including the IP address, connection duration, and bytes sent and received.
3. On the FortiGate, go to Monitor > IPsec Monitor and verify that the tunnel Status is Up.
4. Under Remote Gateway, the monitor shows the FortiClient user’s assigned gateway IP address.
In this recipe, you use the new cloud-assisted OCVPN solution in FortiOS 6.0 or later to greatly simplify the provisioning
and configuration of IPsec VPN.
Note the following limitations:
l The FortiGate must be registered with a valid FortiCare Support license. You can verify the status of your FortiCare
Support contract under System > FortiGuard.
l Only full-mesh VPN configurations using PSK cryptography are supported.
l Public IPs must be used (FortiGates behind NAT cannot participate).
l Non-root VDOMs and FortiGate VMs are not supported.
l Up to 16 nodes can be added to the OCVPN cloud, each with a maximum of 16 subnets.
You can repeat the "Enabling OCVPN" section to add up to 16 nodes to the OCVPN cloud (barring the above
limitations), but you will configure only two nodes in this example.
Enabling OCVPN
1. In the Cloud Members table on FGT_1, click Refresh and confirm the entries.
The remote gateway and corresponding subnets for each device should populate the list.
2. You can perform step 1 on any FortiGate that is a member of the OCVPN cloud.
FGT_2 should return the same results as in step 1.
Results
As the Cloud Members table populates, the OCVPN cloud updates each member automatically.
You can now verify that the remainder of the configuration has also been created, and proceed to test the tunnel.
1. On either FortiGate, go to VPN > IPsec Tunnels and confirm the entry of a new tunnel with the prefix _OCVPN.
2. Go to Network > Static Routes and confirm the new static routes.
3. Go to Policy & Objects > IPv4 Policy and confirm the new policies.
4. Go to Monitor > IPsec Monitor and verify that the tunnel status is Up.
5. Go to Log & Report > VPN Events and view the tunnel statistics.
6. Using Command Prompt/Terminal, attempt a ping from one internal network to the other. Ping should be
successful:
7. Now, disable OCVPN (VPN > One-Click VPN Settings) and repeat the ping attempt to confirm that OCVPN was
indeed responsible for the successful ping above:
8. Re-enable OCVPN.
Troubleshooting
In this recipe, you create a site-to-site IPsec VPN tunnel to allow communication between two networks that are located
behind different FortiGate devices. You use the VPN Wizard’s Site to Site – FortiGate template to create the VPN
tunnel on both FortiGate devices.
In this example, one FortiGate is called HQ and the other is called Branch.
1. To create a new IPsec VPN tunnel, connect to HQ, go to VPN > IPsec Wizard, and create a new tunnel.
2. In the VPN Setup step, set Template Type to Site to Site, set Remote Device Type to FortiGate, and set
NAT Configuration to No NAT between sites.
3. In the Authentication step, set IP Address to the public IP address of the Branch FortiGate (in the example,
172.25.177.46).
4. After you enter the IP address, the wizard automatically assigns an interface as the Outgoing Interface. If you
want to use a different interface, select it from the drop-down menu.
5. Set a secure Pre-shared Key.
6. In the Policy & Routing step, set Local Interface to lan. The wizard adds the local subnet automatically. Set
Remote Subnets to the Branch network’s subnet (in the example, 192.168.13.0/24).
8. A summary page shows the configuration created by the wizard, including interfaces, firewall addresses, routes,
and policies.
9. To view the VPN interface created by the wizard, go to Network > Interfaces.
10. To view the firewall addresses created by the wizard, go to Policy & Objects > Addresses.
11. To view the routes created by the wizard, go to Network > Static Routes.
12. To view the policies created by the wizard, go to Policy & Objects > IPv4 Policy.
1. To create a new IPsec VPN tunnel, connect to Branch, go to VPN > IPsec Wizard, and create a new tunnel.
2. In the VPN Setup step, set Template Type to Site to Site, set Remote Device Type to FortiGate, and set
NAT Configuration to No NAT between sites.
3. In the Authentication step, set IP Address to the public IP address of the HQ FortiGate (in the example,
172.25.176.62).
4. After you enter the IP address, the wizard automatically assigns an interface as the Outgoing Interface. If you
want to use a different interface, select it from the drop-down menu.
5. Set the secure Pre-shared Key that was used for the VPN on HQ.
6. In the Policy & Routing step, set Local Interface to lan. The wizard adds the local subnet automatically. Set
Remote Subnets to the HQ network’s subnet (in the example, 192.168.65.0/24).
7. Set Internet Access to None.
8. A summary page shows the configuration created by the wizard, including interfaces, firewall addresses, routes,
and policies.
9. To bring the VPN tunnel up, go to Monitor > IPsec Monitor. Right-click under Status and select Bring Up.
Results
Users on the HQ internal network can access resources on the Branch internal network and vice versa.
To test the connection, ping HQ’s LAN interface from a device on the Branch internal network.
In this recipe, you add FortiTelemetry traffic to an existing IPsec VPN site-to-site tunnel between two FortiGate devices,
in order to add a remote FortiGate to the Security Fabric. You also allow the remote FortiGate to access the
FortiAnalyzer for logging.
If you do not already have a site-to-site VPN created, see Site-to-site IPsec VPN with two FortiGate devices on page 294
In this example, an HA cluster called Edge is the root FortiGate in the Security Fabric and a FortiGate called Branch is
the remote FortiGate.
1. To configure Edge to listen for FortiTelemetry traffic over the VPN, connect to Edge, go to Network > Interfaces,
and edit the tunnel interface.
2. Set IP to the local IP address for this interface (10.10.10.1) and Remote IP/Network mask to the IP address for
the Branch tunnel interface (10.10.10.2/32).
4. Connect to Branch, go to Network > Interfaces, and edit the tunnel interface.
5. Set IP to the local IP address for this interface (10.10.10.2) and Remote IP/Network mask to the IP address for
the Edge tunnel interface (10.10.10.1/32).
1. To create an address for the Edge tunnel interface, connect to Edge, go to Policy & Objects > Addresses, and
create a new address.
2. Set Category to Address and set Subnet/IP Range to the IP address for the Edge tunnel interface
(10.10.10.1/32).
3. Create a second address for the Branch tunnel interface. For this address, enable Static Route Configuration.
4. To allow VPN traffic between the Edge tunnel interface and the Branch tunnel interface, go to VPN > IPsec
Tunnels, and edit the VPN tunnel. Select Convert To Custom Tunnel.
5. Under Phase 2 Selectors, create a new Phase 2. Set Local Address to use a Named Address and select the
address for the Edge tunnel interface. Set Remote Address to use a Named Address, and select the address for
the Branch tunnel interface.
6. To route traffic to the Branch tunnel interface, go to Network > Static Routes, and create a new route.
7. Set Destination to Named Address, and select the address for the Branch tunnel interface. Set Device to the
tunnel interface.
8. To allow traffic between the tunnel interfaces, go to Policy & Objects > IPv4 Policy and edit the policy allowing
local VPN traffic.
9. Set Source to include the Edge tunnel interface and Destination to include the Branch tunnel interface. To
configure this, you must have Multiple Interface Policies enabled. If you have not done this already, go to System
> Feature Visibility.
10. Edit the policy allowing remote VPN traffic to include the tunnel interfaces.
1. You can authorize a FortiGate, FortiAP, or FortiSwitch to join the Security Fabric by using the device’s serial
number, rather than sharing the password for the Security Fabric (the Group password option is not available
FortiOS 6.0.3 and later). To authorize Branch, connect to Edge, and enter the following CLI command:
2. To add Branch to the Security Fabric, connect to Branch, and go to Security Fabric > Settings.
3. Enable FortiGate Telemetry. Set the Group name. Leave Group password blank (the Group password
option is not available in FortiOS 6.0.3 and later). Enable Connect to upstream FortiGate. Set FortiGate IP to
the IP address of the Edge tunnel interface.
4. To verify that Branch is now part of the Security Fabric, connect to Edge, and go to Security Fabric > Settings.
Branch appears in the Topology.
1. To create an address for the FortiAnalyzer, connect to Branch, go to Policy & Objects > Addresses, and create
a new address. Enable Static Route Configuration.
2. To allow VPN traffic between the FortiAnalyzer and the Branch tunnel interface, go to VPN > IPsec Tunnels, and
create a new Phase 2.
3. To route traffic to the FortiAnalyzer, go to Network > Static Routes, and create a new route.
4. On Edge, repeat this step to create an address for FortiAnalyzer and a new Phase 2 that allows traffic between the
FortiAnalyzer and the Branch tunnel interface. Edge doesn’t require a new static route.
5. To allow traffic between Branch and the FortiAnalyzer, go to Policy & Objects > IPv4 Policy, and create a new
policy.
6. Set Incoming Interface to the VPN interface, and set Outgoing Interface to the interface that connects to the
FortiAnalyzer (in the example, port16). Set Source to the Branch tunnel interface, and set Destination to the
FortiAnalyzer.
8. To authorize the Branch FortiGate on the FortiAnalyzer, connect to the FortiAnalyzer, and go to Device Manager
> Unregistered.
9. Select Branch, then select +Add to register Branch.
Results
To view Branch as part of the Security Fabric topology, connect to Edge and go to Security Fabric > Logical
Topology. Branch is shown as part of the Security Fabric, connecting over the IPsec VPN tunnel.
1. If you don’t want Branch to automatically use the settings that Edge pushes for the FortiAnalyzer, FortiSandbox,
and FortiManager, use the following CLI command to configure these settings locally:
2. Go to Security Fabric > Settings. You can now configure the settings for FortiAnalyzer logging, Central
Management, and Sandbox Inspection. You can also choose to use local logging rather than sending logs to a
FortiAnalyzer.
This option is available for all FortiGate devices in the Security Fabric, except for the root
FortiGate.
In this recipe, you create a route-based IPsec VPN tunnel, as well as configure both source and destination NAT, to
allow transparent communication between two overlapping networks that are located behind different FortiGates.
In this example, one FortiGate will be referred to as HQ and the other as Branch. They both have 192.168.1.0/24 in use
as their internal network (LAN), but both LANs need to be able to communicate to each other through the IPsec tunnel.
In order for overlapping subnets to be able to communicate over a route-based IPsec tunnel, new virtual subnets of
equal size must be decided upon and used for all communication between the two overlapping subnets.
Devices on both local networks DO NOT need their IP addresses changed. However, the
devices/users will need to be sure to use the new subnet range of the remote network when
communicating across the tunnel.
In this example, you perform a one-to-one mapping of HQ’s 192.168.1.0/24 network to 10.1.1.0/24, and Branch’s
192.168.1.0/24 network to 10.2.2.0/24. This will allow HQ clients to use Branch’s new subnet to communicate to Branch
clients, and vice-versa.
1. To create the tunnel on HQ, connect to HQ and go to VPN > IPsec Tunnels.
2. In the VPN Setup step, set Template Type to Custom and enter VPN-to-Branch for the Name.
3. Enter Branch’s public IP address (in the example, 172.25.177.46) for the IP Address, and select HQ’s WAN
interface for Interface (in the example, wan1).
4. Enter a secure key for the Pre-shared Key. Later, you will enter the same key in the "Configuring the IPsec VPN on
Branch" section.
5. Type the new address ranges selected in the "Planning the new addressing scheme" section for HQ and Branch’s
LAN in the Local Address and Remote Address fields (in the example, 10.1.1.0/24 and 10.2.2.0/24,
respectively).
1. To create the necessary routes on HQ, go to Network > Static Routes and select Create New.
2. Enter the new subnet created in the "Planning the new addressing scheme" section for Branch’s LAN in the
Destination field, and select the VPN tunnel created in the "Configuring the IPsec VPN on HQ" section as the
Interface (in the example, this is 10.2.2.0/24 and VPN-to-Branch).
3. Create an additional route with the same Destination as the previous route, but this time change the
Administrative Distance to 200 and select Blackhole as the Interface. This is the best practice for route-based
IPsec VPN tunnels, as it ensures traffic for the remote FortiGate's subnet is not sent using the default route in the
event that the IPsec tunnel goes down.
1. To create address objects you will utilize in a later step, navigate to Policy & Objects > Addresses and select
Create New > Address.
2. Enter HQ-original for the Name, the original LAN subnet of HQ for Subnet (in the example, 192.168.1.0/24), and
select the LAN-side interface for Interface (in the example, internal).
5. To create an IP Pool, navigate to Policy & Objects > IP Pools and select Create New.
6. Enter HQ-new for the Name and select Fixed Port Range for Type. For the External IP Range enter the new
subnet for HQ (in the example, 10.1.1.1 – 10.1.1.254). You do not need to include the network address or the
broadcast address for the subnet in the External IP Range of the IP Pool. For the Internal IP Range, enter the
original subnet for HQ (in the example, 192.168.1.1 – 192.168.1.254).
7. Finally, to create a Virtual IP, navigate to Policy & Objects > Virtual IPs and select Create New > Virtual IP.
8. Enter HQ-new-to-original for the Name and select the VPN interface for Interface (in the example, VPN-to-
Branch). For the External IP Address/Range enter the new subnet for HQ (in the example, 10.1.1.1 –
10.1.1.254). You do not need to include the network address or the broadcast address for the subnet in the External
IP Range of the Virtual IP. For the Mapped IP Address/Range, enter the original subnet (in the example,
192.168.1.1 – 192.168.1.254).
1. To create firewall policies on HQ, go to Policy & Objects > IPv4 Policies and select Create New.
2. Enter From-HQ-to-Branch for the Name, the LAN-side interface on HQ for Incoming Interface (in the example,
internal), and the VPN tunnel interface for Outgoing Interface (in the example, VPN-to-Branch).
3. For the Source, select HQ-original, for the Destination select Branch-new, and for the Service select ALL.
4. Finally, enable NAT, select Use Dynamic IP Pool, and select the HQ-new IP Pool.
5. Repeat the process to create an additional new IPv4 Policy.
6. Enter From-Branch-to-HQ for the Name, the VPN interface for Incoming Interface (in the example, VPN-to-
Branch), and the LAN-side interface for Outgoing Interface (in the example, internal).
7. For the Source, select Branch-new, for the Destination select HQ-new-to-original (the Virtual IP object you
created in the "Configuring static routes on HQ" section), and for the Service select ALL.
8. Note for this policy, you do not need to enable NAT.
1. To create the tunnel on Branch, connect to Branch, and go to VPN > IPsec Tunnels and create a new tunnel.
2. In the VPN Setup step, set Template Type to Custom and enter VPN-to-HQ for the Name.
3. Enter HQ’s public IP address (in the example, 172.25.176.142) for the IP Address, and select Branch’s WAN
interface for Interface (in the example, wan1).
5. Type the new address ranges selected in the "Planning the new addressing scheme" section for Branch and HQ’s
LAN in the Local Address and Remote Address fields (in the example, 10.2.2.0/24 and 10.1.1.0/24,
respectively). The Local and Remote Address fields are the reverse of what you created in the "Configuring the
IPsec VPN on HQ" section.
1. To create the necessary routes on Branch, go to Network > Static Routes and select Create New.
2. Enter the new subnet created in the "Planning the new addressing scheme" section for HQ’s LAN in the
Destination field, and select the VPN tunnel created in the "Configuring the IPsec VPN on Branch" section as the
Interface (in the example, this is 10.1.1.0/24 and VPN-to-HQ).
3. Create an additional route with the same Destination as the previous route, but this time change the
Administrative Distance to 200 and select Blackhole as the Interface.
1. To create address objects you will utilize in a later step, navigate to Policy & Objects > Addresses and select
Create New > Address.
2. Enter Branch-original for the Name, the original LAN subnet of Branch for Subnet (in the example,
192.168.1.0/24), and select the LAN-side interface for Interface (in the example, lan).
5. To create an IP Pool, navigate to Policy & Objects > IP Pools and select Create New.
6. Enter Branch-new for the Name and select Fixed Port Range for Type. For the External IP Range enter the
new subnet for Branch (in the example, 10.2.2.1 – 10.2.2.254), and enter the original subnet for Branch in the
Internal IP Range (in the example, 192.168.1.1 – 192.168.1.254).
7. Finally, to create a Virtual IP, navigate to Policy & Objects > Virtual IPs and select Create New > Virtual IP.
8. Enter Branch-new-to-original for the Name and select the VPN interface for Interface (in the example, VPN-to-
HQ). For the External IP Range enter the new subnet for Branch (in the example, 10.2.2.1 – 10.2.2.254), and
enter the original subnet for Branch in the Internal IP Range (in the example, 192.168.1.1 – 192.168.1.254).
1. To create firewall policies on Branch, navigate to Policy & Objects > IPv4 Policies and select Create New.
2. Enter From-Branch-to-HQ for the Name, the LAN-side interface on Branch for Incoming Interface (in the
example, lan), and the VPN tunnel interface for Outgoing Interface (in the example, VPN-to-HQ).
3. For the Source, select Branch-original, for the Destination select HQ-new, and for the Service select ALL.
4. Finally, enable NAT, select Use Dynamic IP Pool, and select the Branch-new IP Pool.
5. Repeat the process to create an additional new IPv4 Policy.
6. Enter From-HQ-to-Branch for the Name, the VPN interface for Incoming Interface (in the example, VPN-to-HQ),
and the LAN-side interface for Outgoing Interface (in the example, lan).
7. For the Source, select HQ-new, for the Destination select Branch-new-to-original (the Virtual IP object you
created in the "Configuring address objects, Virtual IPs, and IP Pools on Branch" section), and for the Service
select ALL.
8. Note for this policy, you do not need to enable NAT.
Results
1. The IPsec tunnels should now be up on both sides, which you can verify under Monitor > IPsec Monitor. If you
did not enable auto-negotiate in the "Configuring the IPsec VPN on HQ" section or "Configuring the IPsec VPN on
Branch" section earlier, then you may have to highlight the tunnel and select Bring Up.
2. From a PC on the HQ network, try to ping a PC on the Branch network using the new IP for the Branch PC. The ping
should be successful.
3. From a PC on the Branch network, try to ping a PC on the HQ network using the new IP for the HQ PC. The ping
should be successful.
Explanation
Using the two example PCs below, the source and destination NAT that is performed in order to allow these two PCs in
overlapping subnets to communicate is explained.
Step 1 – Ping Request: HQ Test PC sends a ping destined for Branch Test PC’s new IP address of 10.2.2.98.
Src IP: 192.168.1.12
Dst IP: 10.2.2.98
Step 2 – Source NAT: The HQ FortiGate receives the ping, and after a route lookup, matches the traffic to firewall
policy From-HQ-to-Branch that you created in the "Configuring firewall policies on HQ" section of the recipe.
Since the policy has NAT enabled and the HQ-new IP Pool selected, the HQ FortiGate will perform source NAT on HQ
Test PC’s IP address before sending into the IPsec tunnel.
Src IP: 10.1.1.12
Dst IP: 10.2.2.98
When you created an IP Pool with Type of Fixed Port Range, and then selected an External IP
Range and Internal IP Range of equal size, the last octet of the IP addresses after SNAT will
not change. This means 192.168.1.12 will be changed to 10.1.1.12, which makes using the
new address range as simple as possible.
Step 3 – Destination NAT: Branch FortiGate receives the traffic on the IPsec tunnel, and before a policy is matched,
the Virtual IP (VIP) you created called Branch-new-to-original performs destination NAT (DNAT).
Similar to our Fixed Port Range IP Pool, a VIP will exactly map the External IP Range to the
Mapped IP Range. This means that 10.2.2.98 will DNAT to 192.168.1.98.
After DNAT, a route lookup is performed, and the traffic will match the From-HQ-to-Branch policy that you created in the
"Configuring firewall policies on Branch" section of the recipe.
Src IP: 10.1.1.12
Dst IP: 192.168.1.98
Step 4 – Ping Reply: Branch Test PC receives the ping request from HQ Test PC and sends the ping reply back to
10.1.1.12.
The FortiGate is a stateful firewall, and the same firewall policy that was used when the session was initiated will be
used on the way back (the From-HQ-to-Branch policy on both FortiGates).
The session table on each FortiGate remembers the SNAT or DNAT that was performed in the "Configuring the IPsec
VPN on HQ" section and "Configuring static routes on HQ" section, and will perform the reverse operation on the reply
traffic.
Src IP: 192.168.1.98
Dst IP: 10.1.1.12
The following recipe demonstrates how to configure a site-to-site IPsec VPN tunnel to Alibaba Cloud (AliCloud).
Using FortiOS 6.0.0, the example describes how to configure the tunnel between each site, avoiding overlapping
subnets, so that a secure tunnel can be established.
The following is required for this recipe:
l One FortiGate (physical or virtual) with an Internet-facing IP address
l One valid Alibaba Cloud (AliCloud) account
l One VPC that has already been created
1. Log into Alibaba Cloud (AliCloud) and go to Products & Services > VPN Gateway.
2. Ensure that the correct region is selected in the top left corner. Otherwise, you cannot see your VPC. Verify that the
VPC has already been configured.
3. Create the VPN gateway:
a. Click Create VPN Gateway.
b. In the Name field, enter the desired name.
c. From the VPC dropdown list, select the desired VPC.
d. For IPsec VPN, select Enable.
e. Click Buy Now.
f. Select VPN Gateway Agreement of Service.
g. Click Activate.
4. Return to the Alibaba Cloud (AliCloud) management console and verify that the VPN gateway has been created
under VPNs > VPN Gateways.
5. An IP address has been assigned to the VPN gateway. Note down this IP address, as you will need it later in the
process.
6. Register the FortiGate on your site as the customer gateway:
a. Go to VPN > Customer Gateways, then click Create Customer Gateway.
b. In the Name field, enter the FortiGate name.
c. In the IP Address field, enter the FortiGate's Internet-facing interface.
d. Click OK.
7. Set parameters for the IPsec tunnel:
a. Go to VPN > IPsec Connections, then click Create IPsec Connection.
b. In the Name field, enter the IPsec connection name.
c. For VPN Gateway and Customer Gateway, select those created in steps 3 and 6.
d. In the Local Network field, enter the VPC subnet address.
e. In the Remote Network field, enter the subnet address of the LAN on your site.
f. Set Effective Immediately to Yes. If this option is set to No, the VPN gateway attempts to establish IPsec
tunnel connection only when traffic occurs and may cause delays in sending traffic.
g. Configure advanced settings:
i. Click Advanced Configuration.
ii. Enter the Pre-Shared Key for authentication purposes. Your FortiGate will require this keyword in a later
step.
iii. From the Version dropdown list, select ikev2.
iv. Leave the other parameters as-is.
v. Under IPsec Configurations, modify SA Life Cycle (seconds) to 43200 so that it matches the FortiGate
default value. Advanced Configuration contains two SA Life Cycle (seconds) fields: one for IKE
configuration and one for IPsec configuration. Ensure that you are modifying the one under IPsec
configuration.
vi. Click OK.
8. Configure a static route that will route traffic to the IPsec tunnel:
a. Go to VPC > Route Tables. You will see a routing table for your VPC. Click Manage.
e. For Source, select all, or specify any address objects if you want to allow access only from specific addresses.
f. For Destination, select the address object created for your VPC subnet in step 3.
g. For Service, select all or specify any services you want to allow.
h. Ensure that NAT is not enabled.
i. Click OK.
5. Create a policy for incoming sessions from the VPC. Repeat the steps above, except for the following:
a. In the Incoming Interface field, select the IPsec tunnel created in step 2.
b. In the Outgoing Interface field, select your local LAN interface.
c. For Source, select subnets on your VPC.
6. To avoid packet drops and fragmentation, it is recommended to limit the TCP maximum segment size (MSS) being
sent and received. For both firewall policies, configure the following in the CLI console:
config firewall policy
edit <policy-id>
set tcp-mss-sender 1350
set tcp-mss-receiver 1350
next
end
7. Go to Monitor > IPsec Monitor. If all configuration is complete as desired, the IP tunnel displays as being up.
Otherwise, you must review and correct your settings.
8. Create a static route to forward traffic from the LAN to Alibaba Cloud (AliCloud):
a. Go to Network > Static Routes, then select Create New.
b. For Destination, select Named Address. From the list, select your remote subnet.
c. From the Interface dropdown list, select the IPsec tunnel created in step 2.
d. Click OK.
9. FortiOS is now connected to Alibaba Cloud (AliCloud) via IPsec. You should see the traffic counter in Monitor >
IPsec Monitor.
WiFi
This section contains information about creating and configuring WiFi networks.
In this recipe, you will set up a WiFi network with by adding a FortiAP in Tunnel mode to your network.
You can configure a FortiAP in either Tunnel mode (default) or Bridge mode. When a FortiAP is in Tunnel mode, a
wireless-only subnet is used for wireless traffic. When a FortiAP is in Bridge mode, the Ethernet and WiFi interfaces are
connected (or bridged), allowing wired and wireless networks to be on the same subnet.
Connecting FortiAP
1. To edit the interface that will connect to the FortiAP (in the example, port 22), go to Network > Interfaces.
2. Set Role to LAN and Addressing Mode to Manual. Set IP/Network Mask to a private IP address (in the
example 10.10.200.1/255.255.255.0).
3. Under Administrative Access, enable CAPWAP.
4. Enable DHCP Server.
5. Under Networked Devices, enable Device Detection.
8. After a few minutes, select Refresh. The FortiGate shows the FortiAP as authorized.
Creating an SSID
1. To create a new SSID to be broadcast for WiFi users, go to WiFi & Switch Controller > SSID.
2. Set Traffic Mode to Tunnel and set IP/Network Mask to a private IP address (in the example
10.10.201.1/255.255.255.0).
3. Enable DHCP Server and Device Detection.
4. Under WiFi Settings, name the SSID (in the example, Office-WiFi) and set a secure Pre-shared Key.
1. To create a new FortiAP profile, go to WiFi & Switch Controller > FortiAP Profiles.
2. Set Platform to the FortiAP model you are using (in the example, FAP221C) and Country/Region to the
appropriate location.
3. Set an AP Login Password to secure the FortiAP.
4. Under Radio 1, set Mode to Access Point and SSIDs to Manual. Add your new SSID.
5. To assign the new profile, go to WiFi & Switch Controller > Managed FortiAPs and right-click the FortiAP.
Select Assign Profile and set the FortiAP to use the new profile.
1. To create a new policy for wireless Internet access, go to Policy & Objects > IPv4 Policy and select Create
New.
2. Set Incoming Interface to the SSID and Outgoing Interface to your Internet-facing interface.
3. Enable NAT.
Results
1. Connect to the SSID with a wireless device. After a connection is established, browse the Internet to generate
traffic.
2. To view the traffic using the wireless Internet access policy, go to FortiView > All Segments > Polices.
3. To view more information about this traffic, right-click the policy and select Drill Down to Details.
For further reading, check out Configuring a WiFi LAN in the FortiOS 6.0 Online Help.
In this recipe, you create temporary guest accounts that can connect to your WiFi network after authenticating using a
captive portal. To make management easier, you also create a separate administrative account that can only be used to
manage guest accounts.
This example uses a FortiAP in Tunnel mode to provide WiFi access to guests. For information about configuring the
FortiAP, see Setting up WiFi with FortiAP on page 328.
1. To create a guest user group, go to User & Device > User Groups and create a new group.
2. Set Type to Guest and set User ID to Email.
3. Under Guest Details, enable Require Email, enable Password, and set the password to Auto Generated.
4. Under Expiration, set Start Countdown to After First Login and set Time to 5 minutes for testing purposes.
Creating an SSID
1. To create an SSID for guest users, go to WiFi & Switch Controller > SSID and create a new SSID.
2. Set Traffic Mode to Tunnel. Assign an IP/Network Mask to the interface and enable DHCP Server.
4. To broadcast the new SSID, go to WiFi & Switch Controller > FortiAP Profiles and edit the profile used by the
FortiAP.
5. Under Radio 1 set SSIDs to include the new SSID.
1. To allow WiFi guest users to access the Internet, go to Policy & Objects > IPv4 Policy and create a new policy.
2. Set Incoming Interface to the guest SSID and set Outgoing Interface to your Internet-facing interface. Select
Source and set Address to all and User to the guest user group.
3. Enable NAT.
To simplify guest account creation, you can create an admin account that is only used for guest user management. This
allows new accounts to be made as needed without requiring full administrative access to the FortiGate. In this
example, the account is made for use by receptionist.
1. To create the guest management account, go to System > Administrators and create a new account.
2. Set a User Name and set Type to Local User. Set and confirm a Password.
3. Enable Restrict admin to guest account provisioning only and set Guest Group to the WiFi guest user
group.
3. After you select OK, a User Created Successfully notice appears that shows the new account’s Password. This
password can then be printed or emailed to the guest user. You can also view the password by editing the user
account.
Results
1. On a PC, connect to the guest SSID and attempt to browse the Internet. When the authentication screen appears,
log in using the guest user’s credentials.