Antivirus

DO NOT REPRINT
© FORTINET

Regardless of which mode you use, both use the full antivirus database (extended or extreme—depending on
the CLI command use-extreme-db and the FortiGate model) and the scan techniques give similar
detection rates. How can you then choose between the inspection modes?

If security is your priority, proxy inspection mode—with client comforting disabled—is more appropriate. If
performance is your top priority, then flow inspection mode is more appropriate. Depending on the FortiGate
model, flow-based pattern matching can be offloaded to CP8 or CP9 processors, and FortiGate models that
support Nturbo can accelerate antivirus processing to enhance performance. NTurbo creates a special data
path to redirect traffic from the ingress interface to the IPS engine, and from the IPS engine to the egress
interface. So, this acceleration does not apply to proxy-based inspection.

FortiGate 7.4 Administrator Study Guide 201

 Antivirus

DO NOT REPRINT
© FORTINET

Protocol options provide more granular control than antivirus profiles. You can configure protocol port
mappings, common options, web options, and email options, to name a few. Some options apply only to
proxy-based inspection, like Protocol Port Mapping.

Protocol options are used by antivirus and other security profiles, such as web filtering, DNS filtering, and data
loss prevention (DLP), to name a few.

Once protocol options are configured, they are applied in the firewall policy.

FortiGate 7.4 Administrator Study Guide 202

 Antivirus

DO NOT REPRINT
© FORTINET

So, what does the additional granularity provided by protocol options include? It allows you to block large files.
You can also adjust the Threshold for optimal performance in your network. The buffer limit varies by model.
A smaller buffer minimizes proxy latency (for both scanning modes) and RAM usage, but that may allow
viruses to pass through undetected. When a buffer is too large, clients may notice transmission timeouts. You
must balance the two.

You can also disable the oversize option and adjust the oversize-limit per protocol from the config
firewall profile-protocol-options command tree.

If you aren’t sure about the value to set the oversize-limit to, you can temporarily enable the oversize-
log to see if FortiGate is scanning large files frequently. You can then adjust the value accordingly.

FortiGate 7.4 Administrator Study Guide 203

 Antivirus

DO NOT REPRINT
© FORTINET

Large files are often compressed. When compressed files go through scanning, the compression acts like
encryption: the signatures won't match. So, FortiGate must decompress the file in order to scan it.

Before decompressing a file, FortiGate must first identify the compression algorithm. Some archive types can
be correctly identified using only the header. Also, FortiGate must check whether the file is password
protected. If the archive is protected with a password, FortiGate can’t decompress it, and, therefore, can’t
scan it.

FortiGate decompresses files into RAM. Just like other large files, the RAM buffer has a maximum size.
Increasing this limit may decrease performance, but it allows you to scan larger compressed files.

If an archive is nested—for example, if an attacker is trying to circumvent your scans by putting a ZIP file
inside the ZIP file—FortiGate will try to undo all layers of compression. By default, FortiGate will attempt to
decompress and scan up to 12 layers deep, but you can configure it to scan up to the maximum number
supported by your device (usually 100). Usually, you shouldn’t increase this setting because it increases RAM
usage.

FortiGate 7.4 Administrator Study Guide 204

 Antivirus

DO NOT REPRINT
© FORTINET

Logging is an important part of managing a secure network. When you enable logging, you can find details on
the AntiVirus log page under Security Events.

When the antivirus scan detects a virus, by default, it creates a log about what virus was detected, as well as
the action, policy ID, antivirus profile name, and detection type. It also provides a link to more information on
the FortiGuard website.

When you enable oversized files logging, a log entry is also created with the details including the message
“Size limit is exceeded”.

FortiGate 7.4 Administrator Study Guide 205

 Antivirus

DO NOT REPRINT
© FORTINET

You can also view log details on the Forward Traffic log page, where firewall policies record traffic activity.
You’ll find a summary of the traffic on which FortiGate applied an antivirus action in the corresponding security
details.

FortiGate 7.4 Administrator Study Guide 206

 Antivirus

DO NOT REPRINT
© FORTINET

You can also use the Security dashboard to view relevant information regarding threats to your network. The
security dashboard organizes information into source and destination and allows you to drill down with
session logs details.

For the Advanced Threat Protection Statistics, you can add the corresponding widget on the dashboard for
monitoring purposes.

FortiGate 7.4 Administrator Study Guide 207

 Antivirus

DO NOT REPRINT
© FORTINET

Viruses are constantly evolving and you must have the latest antivirus definitions version to ensure correct
protection.
With a valid license, FortiGate checks regularly for updates. If an antivirus profile is applied on at least one
firewall policy, you can also force an update of the antivirus definitions database with the CLI command
execute av-update.

If you are having issues with the antivirus license or FortiGuard updates, start troubleshooting with basic
connectivity tests. Most of the time, issues related to updates are caused by connectivity problems with
FortiGuard servers. You can do the following to handle common antivirus issues:
• Make sure that FortiGate has a stable internet connection and can resolve DNS
([Link]).
• If there is another firewall between FortiGate and the internet, make sure TCP port 443 is open and traffic
is allowed from and to the FortiGate device.
• If you continue to see issues with the update, run the real-time debug command to identify the problem.

FortiGate 7.4 Administrator Study Guide 208

 Antivirus

DO NOT REPRINT
© FORTINET

What if you have a valid contract and updated database, and you are still having issues catching viruses?
Start troubleshooting for basic configuration errors. Most of the time, issues are caused by misconfiguration
on the device. You can do the following to verify:
• Make sure that the correct antivirus profile is applied on the right firewall policy.
• Make sure that the right protocol port is configured when the inspection mode is proxy-based.
• Make sure that you are using the correct antivirus profile and SSL/SSH inspection on all firewall policies.

FortiGate 7.4 Administrator Study Guide 209

 Antivirus

DO NOT REPRINT
© FORTINET

To troubleshoot further common antivirus issues, you can check information provided by the following
commands:
• get system performance status: Displays statistics for the last one minute.
• diagnose antivirus database-info: Displays current antivirus database information.
• diagnose autoupdate versions: Displays current antivirus engine and signature versions.
• diagnose antivirus test "get scantime": Displays scan times for infected files.

FortiGate 7.4 Administrator Study Guide 210

 Antivirus

DO NOT REPRINT
© FORTINET

FortiGate 7.4 Administrator Study Guide 211

 Antivirus

DO NOT REPRINT
© FORTINET

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

By mastering the objectives covered in this lesson, you learned how to use FortiGate features and functions to
protect your network against viruses.

FortiGate 7.4 Administrator Study Guide 212

 Web Filtering

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to configure web filtering on FortiGate to control web traffic in your network.

FortiGate 7.4 Administrator Study Guide 213

 Web Filtering

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in web filtering configuration, you will be able to implement the web filter profile
in an effective manner.

FortiGate 7.4 Administrator Study Guide 214

 Web Filtering

DO NOT REPRINT
© FORTINET

As shown in this HTTP filter process flow example, FortiGate looks for the HTTP GET request to collect URL
information and perform web filtering.

In HTTP, the domain name and URL are separate parts. The domain name might look like the following in the
header: Host: [Link], and the URL might look like the following in the header:
/[Link]?login=true.

If you filter by domain, sometimes it blocks too much. For example, the blogs on [Link] are considered
different content, because of all the different authors. In that case, you can be more specific, and block by the
URL part, [Link]/hacking, for example.

In the default profile-based mode, FortiGate provides two inspection modes (flow-based and proxy-based) to
perform web filtering.

FortiGate 7.4 Administrator Study Guide 215

 Web Filtering

DO NOT REPRINT
© FORTINET

You can configure web filtering in flow-based or proxy-based inspection mode.

Flow-based inspection mode examines the file as it passes through FortiGate. Packets are analyzed and
forwarded as they are received. Original traffic is not altered. Therefore, advanced features that modify
content, such as safe search enforcement, are not supported.

The advantages of flow-based inspection mode are:

• The user sees a faster response time for HTTP requests compared to proxy-based inspection mode.
• There is less chance of a time-out error caused by the server at the other end responding slowly.

The disadvantages of flow-based inspection mode are:

• A number of security features that are available in proxy-based inspection mode are not available in flow-
based inspection mode.
• Fewer actions are available based on the categorization of the website by FortiGuard services.

On the other hand, proxy-based scanning refers to transparent proxy. It’s called transparent because, at the
IP layer, FortiGate is not the destination address, but FortiGate does intercept the traffic. When proxy-based
inspection is enabled, FortiGate buffers traffic and examines it as a whole, before determining an action.
Because FortiGate examines the data as a whole, it can examine more points of data than it does when using
flow-based inspection.

The proxy analyzes the headers and may change the headers, such as HTTP host and URL, for web filtering.
If a security profile decides to block the connection, the proxy can send a replacement message to the client.
This adds latency to the overall transmission speed.

FortiGate 7.4 Administrator Study Guide 216

 Web Filtering

DO NOT REPRINT
© FORTINET

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

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

SSL certificate inspection works correctly with web filtering, because the full payload does not need to be
inspected.

FortiGate 7.4 Administrator Study Guide 217

 Web Filtering

DO NOT REPRINT
© FORTINET

FortiGate has a read-only preconfigured profile for SSL certificate inspection named certificate-inspection. If
you want to enable SSL certificate inspection, select this profile when configuring a firewall policy.

Alternatively, you can create your own profile for SSL certificate inspection by following these steps:

1. On the FortiGate GUI, click Security Profiles, and then click SSL/SSH Inspection.
2. Click Create New to create a new SSL/SSH inspection profile.
3. Select Multiple Clients Connecting to Multiple Servers, and then click SSL Certificate Inspection.
4. Select the action for Server certificate SNI check.

When the Server certificate SNI check configuration is Enable, FortiGate uses the domain in the CN field
instead of the domain in the SNI field if the domain in the SNI field does not match any of the domains listed in
the CN and SAN fields. With Strict, FortiGate closes the client connection if there is a mismatch. When SNI
check is Disable, FortiGate always rates URLs based on the FQDN.

FortiGate 7.4 Administrator Study Guide 218

 Web Filtering

DO NOT REPRINT
© FORTINET

Now, you will look at the web filter profile.

You can configure this security profile to use a feature set for proxy-based or flow-based inspection modes.
However, depending on the mode you select, the available settings are different. Flow-based inspection has
fewer available options.

FortiGate 7.4 Administrator Study Guide 219

 Web Filtering

DO NOT REPRINT
© FORTINET

In the example shown on this slide, the security profile is configured to use a proxy-based feature set. It
provides features specific to proxy-based configuration.

After you configure your web filter profile, you can apply this profile to the firewall policy configured to use
proxy-based inspection mode, so the filtering is applied to your web traffic.

FortiGate 7.4 Administrator Study Guide 220

 Web Filtering

DO NOT REPRINT
© FORTINET

In the web filter profile, Fortiguard category filtering enhances the web filter features. Rather than block or
allow websites individually, it looks at the category that a website has been rated with. Then, FortiGate takes
action based on that category, not based on the URL.

FortiGuard category filtering is a live service that requires an active contract. The contract validates
connections to the FortiGuard network. If the contract expires, there is a two-day grace period during which
you can renew the contract before the service ends. If you do not renew, after the two-day grace period,
FortiGate reports a rating error for every rating request made. In addition, by default, FortiGate blocks web
pages that return a rating error. You can change this behavior by enabling the Allow websites when a rating
error occurs setting.

You can configure FortiManager to act as a local FortiGuard server. To do this, you must download the
databases to FortiManager, and configure FortiGate to validate the categories against FortiManager, instead
of FortiGuard.

You can enable the FortiGuard category filtering on the web filter profile. Categories are listed, and you can
customize the actions to perform individually. In the default profile-based mode, the actions available are
Allow, Monitor, Block, Warning, and Authenticate.

To review the complete list of categories, visit the FortiGuard web filter website.

FortiGate 7.4 Administrator Study Guide 221

 Web Filtering

DO NOT REPRINT
© FORTINET

Besides the Allow and Block actions, which respectively permit and block access to the sites, the Monitor
action allows access to the sites in the category and logs it at the same time. In proxy-based mode, you can
also configure a usage quota.

FortiGate 7.4 Administrator Study Guide 222

 Web Filtering

DO NOT REPRINT
© FORTINET

Quotas allow daily access for a specific length of time or bandwidth. At midnight, quotas reset. Once the daily
quota is reached for a category, FortiGate blocks the traffic and displays a replacement message page.
Besides the Monitor action, you can also apply quotas to the Warning and Authenticate actions.

FortiGate 7.4 Administrator Study Guide 223

 Web Filtering

DO NOT REPRINT
© FORTINET

The Warning action informs users that the requested website is not allowed by the internet policies. However,
the action gives the user the option to proceed to the requested website, or return to the previous website.

You can customize the warning interval. When the timer expires, FortiGate displays the warning message
again if you access other websites in the same category.

FortiGate 7.4 Administrator Study Guide 224

 Web Filtering

DO NOT REPRINT
© FORTINET

You can customize the warning replacement message. By default, it provides information of the URL and its
corresponding category. With this information, the user can click Proceed to override the internet usage
policy.

FortiGate 7.4 Administrator Study Guide 225

 Web Filtering

DO NOT REPRINT
© FORTINET

The Authenticate action blocks the requested websites, unless the user enters a successful username and
password. FortiGate supports local and remote authentication using LDAP, RADIUS, and so on for web
filtering authentication. Choosing this action prompts you to define user groups that are allowed to override
the block.

You can also customize the interval of time to allow access. Users are not prompted to authenticate again if
they access other websites in the same category until the timer expires.

FortiGate 7.4 Administrator Study Guide 226

 Web Filtering

DO NOT REPRINT
© FORTINET

Like the Warning action, FortiGate displays a replacement message to proceed and a second one asks for
the user credentials. You can customize these replacement messages in System > Replacement Messages.

FortiGate 7.4 Administrator Study Guide 227

 Web Filtering

DO NOT REPRINT
© FORTINET

If you consider that a particular URL does not have the correct category, you can ask to re-evaluate the rating
in the Fortinet URL Rating Submission website. You can also override a web rating for an exceptional URL in
the FortiGate configuration.

Remember that changing categories does not automatically result in a different action for the website. This
depends on the settings within the web filter profile.

FortiGate 7.4 Administrator Study Guide 228

 Web Filtering

DO NOT REPRINT
© FORTINET

Static URL filtering is another web filter feature, which provides more granularity. Configured URLs in the URL
filter are checked from top to bottom against the visited websites. If FortiGate finds a match, it applies the
configured action. You can configure one of four actions:

• Exempt allows the traffic from trusted sources to bypass all security inspections.
• Block denies the attempt and the user receives a replacement message.
• Allow permits access. The traffic is passed to the remaining operations, including FortiGuard web filter,
web content filter, web script filters, and antivirus scanning.
• Monitor allows the traffic while creating log entries. The traffic is still subject to all the other security profile
inspections.

To find the exact match, URL filtering has three pattern types: Simple, Regular Expressions, and Wildcard.

FortiGate 7.4 Administrator Study Guide 229

 Web Filtering

DO NOT REPRINT
© FORTINET

So, with these different features, what is the inspection order? If you have enabled many of them, the
inspection order flows as follows:

1. The local static URL filter

2. FortiGuard category filtering (to determine a rating)
3. Advanced filters (such as safe search or removing Active X components)

For each step, if there is no match, FortiGate moves on to the next check enabled.

FortiGate 7.4 Administrator Study Guide 230

 Web Filtering

DO NOT REPRINT
© FORTINET

Category-based filtering requires a live connection to FortiGuard.

You can verify the connection to FortiGuard servers by running the diagnose debug rating CLI
command. This command displays a list of FortiGuard servers you can connect to, as well as the following
information:
• Weight: It is based on the difference in time zones between FortiGate and this server to reduce the
possibility of using a remote server.
• RTT: Return trip time
• Flags: D (IP returned from DNS), I (Contract server contacted), T (being timed), F (failed)
• TZ: Server time zone
• FortiGuard-requests: The number of requests sent by FortiGate to FortiGuard
• Curr Lost: Current number of consecutive lost FortiGuard requests (in a row, it resets to 0 when one
packet succeeds)
• Total Lost: Total number of lost FortiGuard requests

The list is of variable length depending on the FortiGuard Distribution Network and the FortiGate
configuration.

FortiGate 7.4 Administrator Study Guide 231

 Web Filtering

DO NOT REPRINT
© FORTINET

By default, FortiGate is configured to enforce the use of HTTPS port 443 to perform live filtering with
FortiGuard or FortiManager. When the fortiguard-anycast command is enable, the FortiGuard domain
name resolves to a single anycast IP address, which is the only entry in the list of FortiGuard servers. By
disabling the FortiGuard anycast setting on the CLI, other ports and protocols are available. These ports and
protocols query the servers (FortiGuard or FortiManager) on HTTPS port 53 and port 8888, UDP port 443,
port 53, and port 8888. If you are using UDP port 53, any kind of inspection reveals that this traffic is not DNS
and prevents the service from working. In this case, you can switch to the alternate UDP port 443 or port
8888, or change the protocol to HTTPS, but these ports are not guaranteed to be open in all networks, so you
must check beforehand.

If the number of FortiGuard requests is too high, you can also enable Web Filter cache. Once enabled,
FortiGate maintains a list of recent website rating responses in memory. So, if the URL is already known,
FortiGate doesn’t send back a rating request. Caching responses reduces the amount of time it takes to
establish a rating for a website. Also, memory lookup is much quicker than packets travelling on the internet.

FortiGate 7.4 Administrator Study Guide 232

 Web Filtering

DO NOT REPRINT
© FORTINET

What if you have a live connection to FortiGuard and configured your security profiles, but they are not
performing web inspection?

Most of the time, issues are caused by misconfiguration on the device. You can verify them as follows:
• Make sure that the SSL Inspection field includes at least one profile with an SSL certification inspection
method.
• Make sure that the correct web filter profile is applied on the firewall policy.
• Verify the inspection mode setting with the feature set in the corresponding web filter profile.

FortiGate 7.4 Administrator Study Guide 233

 Web Filtering

DO NOT REPRINT
© FORTINET

To confirm the correct configuration and web filtering behavior, you can view the web filter logs.

This slide shows an example of a log message. Access details include information about the FortiGuard quota
and category (if those are enabled), which web filter profile was used to inspect the traffic, the URL, and more
details about the event.

You can also view the raw log data by clicking the download icon at the top of the GUI. The file downloaded is
a plain text file in a syslog format.

FortiGate 7.4 Administrator Study Guide 234

 Web Filtering

DO NOT REPRINT
© FORTINET

FortiGate 7.4 Administrator Study Guide 235

 Web Filtering

DO NOT REPRINT
© FORTINET

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

By mastering the objectives covered in this lesson, you learned how to configure web filtering on FortiGate to
control web traffic in your network.

FortiGate 7.4 Administrator Study Guide 236

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to use FortiGate to protect your network against intrusions and how to
monitor and control network applications that may use standard or non-standard protocols and ports—beyond
simply blocking or allowing a protocol, port number, or IP address.

FortiGate 7.4 Administrator Study Guide 237

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in intrusion prevention systems (IPS), you will be able to implement an
effective IPS solution to protect your network from intrusion.

By demonstrating competence in configuring and monitoring the application control features that are available
on FortiOS, you will be able to use and maintain application control in profile mode in an effective manner.

FortiGate 7.4 Administrator Study Guide 238

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

IPS on FortiGate uses signature databases to detect known attacks, like exploits. Rate-based IPS signatures
also allows you to detect anomalies, which are unusual behaviors in the network, such as higher-than-usual
CPU use or network traffic. Rate-based IPS signatures are part of behavioral analysis, like DoS policies and
protocol constraints inspection, which detect and monitor (and, in some cases, block or mitigate) anomalies,
because they reveal the symptoms of a new, never-previously-seen attack.

Unlike proxy-based scans, IPS works in flow-based inspection and is not limited to IANA standard ports.
Protocol decoders parse each packet according to the protocol specifications. If the traffic doesn’t conform to
the specification—if, for example, it sends malformed or invalid commands to your servers—then the protocol
decoder detects the error.

Another important IPS component is the engine. The IPS engine is responsible for IPS and protocol decoders,
in addition to application control, flow-based antivirus protection, web filtering, and email filtering.

FortiGate 7.4 Administrator Study Guide 239

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

After FortiGate downloads a FortiGuard IPS package, new signatures appear in the signature list. When
configuring FortiGate, you can change the Action setting for each sensor that uses a signature.

The default action setting is often correct, except in the following cases:
• Your software vendor releases a security patch. Continuing to scan for exploits wastes FortiGate
resources.
• Your network has a custom application with traffic that inadvertently triggers an IPS signature. You can
change the action setting until you notify Fortinet so that the FortiGuard team can modify the signature to
avoid false positives.

FortiGate 7.4 Administrator Study Guide 240

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

There are two ways to add predefined signatures to an IPS sensor. One way is to select the signatures
individually. After selecting a signature in the list, the signature is added to the sensor with its default action.

The second way to add a signature to a sensor is using filters. FortiGate adds all the signatures that match
the filters.

The purpose of the IPS feature is to protect the inside of the network from outside threats.

FortiGate 7.4 Administrator Study Guide 241

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

You can also add rate-based signatures to block specific traffic when the threshold is exceeded. On the CLI, If
you set the command rate-mode to periodical, FortiGate triggers the action when the threshold is
reached during the configured Duration time period. You should apply rate-based signatures only to protocols
you use. This saves system resources and can discourage a repeat attack. FortiGate does not track statistics
for that client while it is temporarily blocklisted.

FortiGate 7.4 Administrator Study Guide 242

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

When the IPS engine compares traffic with the signatures in each filter, order matters. The rules are similar to
firewall policy matching; the engine evaluates the filters and signatures at the top of the list first, and applies
the first match. The engine skips subsequent filters.

So, position the most likely matching filters, or signatures, at the top of the list. Avoid making too many filters,
because this increases evaluations and CPU usage. Also, avoid making very large signature groups in each
filter, which increase RAM use.

In the event of a false-positive outbreak, you can add the triggered signature as an individual signature, and
then set the action to Monitor. This allows you to monitor the signature events using IPS logs, while
investigating the false-positive issue.

FortiGate 7.4 Administrator Study Guide 243

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

Sometimes, it is necessary to exempt specific source or destination IP addresses from specific signatures.
This feature is useful during false-positive outbreaks. You can temporarily bypass affected endpoints until you
investigate and correct the false-positive issue.

You can configure IP exemptions on individual signatures only. Each signature can have multiple exemptions.

FortiGate 7.4 Administrator Study Guide 244

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

When you create a new entry to add signatures or filters, you can select the action by clicking Action.

Select Allow to allow traffic to continue to its destination. Select Monitor to allow traffic to continue to its
destination and log the activity. Select Block to silently drop traffic matching any of the signatures included in
the entry. Select Reset to generate a TCP RST packet whenever the signature is triggered. Select Default to
use the default action of the signatures.

Quarantine allows you to quarantine the attacker’s IP address for a set duration. You can set the quarantine
duration to any number of days, hours, or minutes.

If you enable Packet logging, FortiGate saves a copy of the packet that matches the signature.

You can set these actions on hold for new FortiGuard IPS signature by enabling the override-signature-
hold-by-id CLI command. During the time defined by the CLI command signature-hold-time, the
action is then set to Monitor to avoid false positives, with a log created including the message ‘signature
is on hold’.

FortiGate 7.4 Administrator Study Guide 245

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

For consolidated botnet protection, you can enable botnet scanning on the IPS profile that you apply the
firewall policy on.

There are three possible actions for Botnet and C&C:

• Disable: Do not scan connections to botnet servers
• Block: Block connections to botnet servers
• Monitor: Log connections to botnet servers

FortiGate 7.4 Administrator Study Guide 246

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

To apply an IPS sensor, you must enable IPS and then select the sensor in a firewall policy.

Certain vulnerabilities apply only to encrypted connections and FortiGate can’t identify the threat reliably if it
can’t parse the payload. For this reason, you must use an SSL inspection profile, usually deep-inspection, if
you want to get the maximum benefit from your IPS features.

By default, FortiGate logs all security events. This means you can see any traffic that is being blocked or
monitored by IPS.

If you think some traffic should be blocked but is passing through the policy, you should change the Log
Allowed Traffic method to All Sessions. This logs all traffic processed by that firewall policy, and not just the
traffic that is blocked or monitored by the security profiles. This can help you in identifying false negative
events.

FortiGate 7.4 Administrator Study Guide 247

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

If you enabled security events logging in the firewall policies that apply IPS, the logs are available on the
Security Events pane on the Log & Report page. You can view the logs by clicking on Intrusion
Prevention.

You should review IPS logs frequently. The logs are an important source of information about the kinds of
attacks that are being targeted at your network. This helps you develop action plans and focus on specific
events, for example, patching a critical vulnerability.

FortiGate 7.4 Administrator Study Guide 248

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

While using IPS, short spikes in CPU usage by IPS processes can be caused by firewall policy or profile
changes. These spikes are usually normal. Spikes might happen when FortiGate has hundreds of policies and
profiles, or many virtual domains. Continuous high-CPU use by the IPS engines is not normal, and you should
investigate it. You can use the command shown on this slide, along with displayed options, to troubleshoot
these issues.

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

If the CPU use remains high after enabling IPS bypass mode, it usually indicates a problem in the IPS engine,
which you must report to Fortinet support. You can disable the IPS engine completely using option 2. If you
want to restore IPS inspection of traffic after you finish troubleshooting, use option 2 again. At any time, you
can check the status of the IPS engines using option 1.

Another recommendation to keep in mind is that if you need to restart the IPS, use option 99, as the slide
shows. This guarantees that all the IPS-related processes restart correctly.

FortiGate 7.4 Administrator Study Guide 249

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

As previously mentioned, the IPS engine is also responsible for application control. You can configure
application control in proxy-based and flow-based firewall policies. However, because application control uses
the IPS engine, which uses flow-based inspection, the inspection is always flow-based.

Application control identifies applications, such as Google Talk, by matching known patterns to the application
transmission patterns. Therefore, an application can be accurately identified, only if its transmission pattern is
unique. However, not every application behaves in a unique way. Many applications reuse pre-existing,
standard protocols and communication methods. For example, many video games, such as World of
Warcraft, use the BitTorrent protocol to distribute game patches. Still, with the help of the IPS engine,
application control analyzes network traffic and detects application traffic, even if the application is using
standard or non-standard protocols and ports. It doesn’t operate using built-in protocol states. As a
consequence, application control is better suited for detecting P2P protocols, because they use port
randomization, pinholes, and changing encryption pattern techniques.

FortiGate 7.4 Administrator Study Guide 250

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

Many web applications offer functionality that can be embedded in third-party websites or applications. For
example, you can embed a Facebook Like button at the end of an article, or reference a YouTube video on an
educational website. FortiOS gives administrators all the tools they need to inspect subapplication traffic. The
FortiGuard application control signature database is organized in a hierarchical structure. This gives you the
ability to inspect the traffic with more granularity. You can block Facebook applications while allowing users to
collaborate using Facebook chat.

FortiGate 7.4 Administrator Study Guide 251

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

After FortiGate downloads a FortiGuard Application Control Signature package, new signatures appear in the
signature list.

In the example shown on this slide, the signatures are filtered with linkedin, showing its category and the
corresponding hierarchical structure.

FortiGate 7.4 Administrator Study Guide 252

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

In profile-based mode, you configure application control profiles on the Application Control page.

The application control profile consists of three different types of filters:

• Categories: Groups applications based on similarity. For example, all applications that are capable of
providing remote access are grouped in the Remote Access category. The Unknown Applications
category refers to traffic that can’t be matched to any application control signature. You can configure an
action per category or to all of them.
• Application overrides: Provides the flexibility to control specific signatures and applications.
• Filter overrides: Useful when a predefined category does not meet your requirements and you want to
modify the action for all applications based on criteria that are not available in categories. Besides
category, the additional criteria are behavior, protocol, vendor, popularity, risk, or the technology used by
the applications.

At the top of the Application Control profile page, you will see a summary of how many cloud applications
require deep inspection. Cloud applications that use SSL encryption cannot be scanned without a deep
inspection profile. FortiGate must decrypt the traffic in order to perform inspection and control application
traffic.

FortiGate 7.4 Administrator Study Guide 253

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

For each filter in the application control profile, you must indicate an action—what FortiGate does when traffic
matches. Actions include the following:
• Allow: Passes the traffic and does not generate a log
• Monitor: Passes the traffic, but also generates a log message
• Block: Drops the detected traffic and generates a log message
• Quarantine: Blocks the traffic from an attacker IP address until the expiration time is reached, and
generates a log message

The View Signature action allows you to view signatures from a particular category only and is not a
configurable action. The View Cloud Signatures action allows you to view application signatures for cloud
applications from a particular category.

Which is the correct action to choose?

If you’re not sure which action to choose, Monitor can be useful initially, while you study your network. Later,
after you have studied your network traffic, you can fine-tune your filter selection by choosing the most
appropriate action. The action you choose also depends on the application. If an application requires feedback
to prevent instability or other unwanted behavior, then you might choose Quarantine instead of Block.
Otherwise, the most efficient use of FortiGate resources is to block.

FortiGate 7.4 Administrator Study Guide 254

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

The Application Sensor provides also additional options.

Network Protocol enforcement allows you to configure network services (for example, FTP, HTTP, and
HTTPS) on known ports (for example, 21, 80, and 443), while blocking those services on other ports.

The feature takes action in the following scenarios:

• When one protocol dissector confirms the service of network traffic, Network Protocol Enforcement can
check whether the confirmed service is allowlisted under the server port. If it is not, then the traffic is
considered a violation and IPS can take the action (for example, block) specified in the configuration.
• There is no confirmed service for network traffic. It would be considered a service violation if IPS dissectors
rule out all the services enforced under its server port, for example, if port 21 is configured for FTP and the
protocol dissector could not decide on the exact service but is sure it is not FTP. If the port of the non-FTP
traffic is 21, it will be a violation.

With the Block applications detected on non-default ports option, FortiGate compares the ports used by
the application with the ones defined in FortiGuard application signatures. The traffic is blocked if it does not
match.

The Replacement Messages for HTTP-based Applications setting allows you to replace blocked content
from HTTP/HTTPS applications with an explanation for the user’s benefit. For non-HTTP/HTTPS applications,
FortiGate only drops the packets or resets the TCP connection.

FortiGate 7.4 Administrator Study Guide 255

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

For HTTP-based applications, application control can provide feedback to the user about why their application
was blocked. This is called a block page, and it is similar to the one you can configure for URLs that you block
using FortiGuard web filtering.

It is also worth mentioning that, if deep inspection is enabled in the firewall policy, all HTTPS-based
applications provide this block page.

The block page contains the following information:

• Signature that detected the application (in this case, Dailymotion)
• Signature’s category (in this case, Video/Audio)
• URL that was specifically blocked (in this case, the index page of [Link]), since a web
page can be assembled from multiple URLs
• User name (if authentication is enabled)
• Group name (if authentication is enabled)
• UUID of the policy governing the traffic

The last item in this list can help you to identify which policy on FortiGate blocked the page, even if you have a
large number of policies with many FortiGate devices securing different segments.

FortiGate 7.4 Administrator Study Guide 256

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

With these multiple filters, which one has the priority?

After the IPS engine examines the traffic stream for a signature match, FortiGate scans packets for matches,
in this order, for the application control profile:

1. Application and filter overrides: If you have configured any application overrides or filter overrides, the
application control profile considers those first. It looks for a matching override starting at the top of the
list, like firewall policies.
2. Categories: Finally, the application control profile applies the action that you’ve configured for applications
in your selected categories.

FortiGate 7.4 Administrator Study Guide 257

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

In the example profile shown on this slide, the application control profile blocks the Game and Video/Audio
categories. All other categories are set to Monitor, except Unknown Applications, which is set to Allow.

In the Application and Filter Overrides section, you can see that some exceptions are specified. Instead of
being set to Block, [Link] (Game), and Dailymotion (Video/Audio) are set to Monitor. Because
application overrides are applied first in the scan, these two applications are allowed, and generate logs.

Next, the scan checks for Application and Filter Overrides. Because a filter override is configured to block
applications that use excessive bandwidth, it blocks all applications using excessive bandwidth, regardless of
categories that allow these applications.

This slide shows an example of how several security profile features could work together, overlap, or work as
substitutes, on the same traffic.

After the application control profile scan is done, FortiGate begins other scans, such as web filtering. The web
filtering scan could block [Link] and Dailymotion, but it would use its own block message. Also, web
filtering doesn’t check the list of application control overrides. So, even if an application control override allows
an application, web filtering could still block it.

Similarly, static URL filtering has its own exempt action, which bypasses all subsequent security checks.
However, application control occurs before web filtering, so that the web filtering exemption cannot bypass
application control.

FortiGate 7.4 Administrator Study Guide 258

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

In the example profile shown on this slide, the filter override has been moved above the application override.
In this scenario, the filter override (Excessive-Bandwidth) is blocked and, since Dailymotion falls under the
excessive bandwidth category, Dailymotion is blocked even though it is set to Monitor under the Application
and Filter Overrides section.

The priority in which application and filter overrides are placed takes precedence.

FortiGate 7.4 Administrator Study Guide 259

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

After you configure an application control profile, you must apply it to a firewall policy. This instructs FortiGate
to start scanning application traffic that is subject to the firewall policy.

FortiGate 7.4 Administrator Study Guide 260

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

When you enable the logging of security events or all sessions on a firewall policy, application control events
are also logged. It allows you to monitor the application control use.

FortiGate 7.4 Administrator Study Guide 261

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

FortiGate logs all application control events on the Log & Report > Security Events page. You can view the
logs by clicking on Application Control.

In the example shown on this slide, the default application control profile blocks access to Dailymotion. You
can view this information in the Log Details section, as well as information about the log source, destination,
application, and action.

You can also view the details on the Forward Traffic logs pane, where firewall policies record activity. You
can also find a summary of the traffic to which FortiGate applied application control. Again, this is because
application control is applied by a firewall policy. To find out which policy applied application control, you can
review either the Policy ID or the Policy UUID fields of the log message.

FortiGate 7.4 Administrator Study Guide 262

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

Because not all traffic requires an application control scan, you must monitor the security event logs. If a traffic
match is incorrect, you must then modify your configuration by first finding the firewall policy involved. This
firewall policy reference is available in the Security Events logs and also in the Forward Traffic logs.

You can also check the traffic matching with application control profiles on the Dashboard > FortiView
Applications page. You can then select a specific application and drill down to view the sessions and bytes
information for the traffic matching that application.

FortiGate 7.4 Administrator Study Guide 263

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

FortiGate 7.4 Administrator Study Guide 264

 Intrusion Prevention and Application Control

DO NOT REPRINT
© FORTINET

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

By mastering the objectives covered in this lesson, you gained the skills and knowledge you need to
configure, maintain, and troubleshoot the FortiGate IPS solution. You also learned how to use methods
beyond simply blocking protocols, port numbers, or IP addresses, to monitor and control both standard and
non-standard network applications.

FortiGate 7.4 Administrator Study Guide 265

 SSL VPN

DO NOT REPRINT
© FORTINET

In this lesson, you will learn how to configure and use SSL VPNs. SSL VPNs are an easy way to give remote
users access to your private network.

FortiGate 7.4 Administrator Study Guide 266

 SSL VPN

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in understanding the different ways FortiGate allows SSL VPN connections,
you will be able to better design the configuration and architecture of your SSL VPN. You will also be able to
avoid, identify, and solve common issues and misconfigurations.

FortiGate 7.4 Administrator Study Guide 267

 SSL VPN

DO NOT REPRINT
© FORTINET

There are two modes you can use to access an SSL VPN. Both can build an SSL VPN connection, but they
don’t support the same features.

Which should you choose?

It depends on which applications you need to send through the VPN, the technical knowledge of your users,
and whether or not you have administrative permissions on their computers.

Tunnel mode supports the most protocols, but requires the installation of a VPN client, or more specifically, a
virtual network adapter. To tunnel traffic using the virtual adapter, you must use the FortiClient remote access
feature or FortiClient VPN-only client.

Web mode requires only a web browser, but supports a limited number of protocols. You will only learn SSL
VPN tunnel mode in this lesson.

FortiGate 7.4 Administrator Study Guide 268

 SSL VPN

DO NOT REPRINT
© FORTINET

Tunnel mode is the second option FortiGate provides to access resources within an SSL VPN.

Tunnel mode requires FortiClient to connect to FortiGate. FortiClient adds a virtual network adapter identified
as fortissl to the user’s PC. This virtual adapter dynamically receives an IP address from FortiGate each
time FortiGate establishes a new VPN connection. Inside the tunnel, all traffic is SSL/TLS encapsulated.

The main advantage of tunnel mode is that after the VPN is established, any IP network application running
on the client can send traffic through the tunnel. The tunnel mode requires the installation of a VPN software
client, which requires administrative privileges.

FortiGate 7.4 Administrator Study Guide 269

 SSL VPN

DO NOT REPRINT
© FORTINET

How does tunnel mode work?

1. Users connect to FortiGate through FortiClient.

2. Users provide credentials to successfully authenticate.
3. FortiGate establishes the tunnel and assigns an IP address to the client’s virtual network adapter
(fortissl). This is the client’s source IP address for the duration of the connection.
4. Then, users can access services and network resources through the encrypted tunnel.

FortiClient encrypts all traffic from the remote computer and sends it over the SSL VPN tunnel. FortiGate
receives the encrypted traffic, de-encapsulates the IP packets, and forwards them to the private network as if
the traffic originated from inside the network.

FortiGate 7.4 Administrator Study Guide 270

 SSL VPN

DO NOT REPRINT
© FORTINET

You can configure FortiGate as an SSL VPN client, using an SSL-VPN Tunnel interface type. When an SSL
VPN client connection is established, the client dynamically adds a route to the subnets that the SSL VPN
server returns. You can define policies to allow users who are behind the client to be tunneled through SSL
VPN to destinations on the SSL VPN server.

FortiGate 7.4 Administrator Study Guide 271

 SSL VPN

DO NOT REPRINT
© FORTINET

This setup provides IP-level connectivity in tunnel mode and allows you to configure hub-and-spoke
topologies with FortiGate devices as both the SSL VPN hub and spokes. This can be useful to avoid issues
caused by intermediate devices, such as:
• ESP packets being blocked
• UDP ports 500 or 4500 being blocked
• Fragments being dropped, causing IKE negotiation that uses large certificates to fail if the peer
does not support IKE fragmentation

If the client specified destination is all, a default route is effectively dynamically created on the SSL VPN client,
and the new default route is added to the existing default route in the form of ECMP. You can modify the
route distance or priority according to your requirements. To prevent a default route being learned on the SSL
VPN client, define a specific destination on the SSL VPN server. Split tunneling is used so that only the
destination addresses defined in the server firewall policies are routed to the server, and all other traffic is
connected directly to the internet.

This configuration requires you to install the correct CA certificate because the SSL VPN client FortiGate/user
uses PSK and a PKI client certificate to authenticate. You must install the correct CA certificate on the
FortiGate devices to verify the certificate chain to the root CA that signed the certificate.

FortiGate 7.4 Administrator Study Guide 272

 SSL VPN

DO NOT REPRINT
© FORTINET

How does tunnel mode work when FortiGate is configured as client?

1. Client FortiGate connects to server FortiGate using SSL/TLS

2. Client FortiGate provides credentials to successfully authenticate. It includes both PSK (local or remote
user account) and PKI (certificate) accounts.
3. Server FortiGate establishes the tunnel and assigns an IP address to the client’s virtual network adapter.
This is the client’s source IP address for the duration of the connection.
4. Then, users can access services and network resources through the encrypted tunnel behind client
FortiGate.

SSL VPN client FortiGate device encrypts all traffic from the remote computer and sends it over the SSL VPN
tunnel. SSL VPN server FortiGate receives the encrypted traffic, de-encapsulates the IP packets, and
forwards them to the private network as if the traffic originated from inside the network.

FortiGate 7.4 Administrator Study Guide 273

 SSL VPN

DO NOT REPRINT
© FORTINET

Tunnel mode also supports split tunneling.

When split tunneling is disabled, all IP traffic generated by the client’s computer—including internet traffic—is
routed across the SSL VPN tunnel to FortiGate. This sets up FortiGate as the default gateway for the host.
You can use this method in order to apply security features to the traffic on those remote clients, or to monitor
or restrict internet access. This adds more latency and increases bandwidth usage.

In a FortiGate (client) to FortiGate (server) setup, a default route is effectively dynamically created on the SSL
VPN client FortiGate, and the new default route is added to the existing default route in the form of ECMP.
The following options are available to configure routing:
• To make all traffic default to the SSL VPN server and still have a route to the server's listening
interface, on the SSL VPN client, set a lower distance for the default route that is learned from the
server.
• To include both default routes in the routing table, with the route learned from the SSL VPN server
taking priority, on the SSL VPN client, set a lower distance for the route learned from the server. If
the distance is already zero, then increase the priority on the default route.

When split tunneling is enabled, only traffic that is destined for the private network behind the remote
FortiGate is routed through the tunnel. All other traffic is sent through the usual unencrypted route. There is no
traffic inspection by FortiGate.

Split tunneling helps to conserve bandwidth and alleviates bottlenecks.

FortiGate 7.4 Administrator Study Guide 274

 SSL VPN

DO NOT REPRINT
© FORTINET

The first step is to create the accounts and user groups for the SSL VPN clients.

You can use all FortiGate authentication methods, with the exception of remote password authentication using
the Fortinet Single Sign-On (FSSO) protocol, for SSL VPN authentication. This includes local password
authentication and remote password authentication (using the LDAP, RADIUS, and TACACS+ protocols).

This slide shows the steps an administrator must take to configure SSL VPN. You can configure some steps
in a different order than what is shown on this slide.

FortiGate 7.4 Administrator Study Guide 275

 SSL VPN

DO NOT REPRINT
© FORTINET

The next step is to configure the SSL VPN portal(s). An SSL VPN portal contains tools and resource links for
the users to access.

In tunnel mode, when you enable split tunneling, you need to select either Enabled Based on Policy
Destination or Enabled for Trusted Destination setting, which usually specifies networks behind the
FortiGate for the SSL VPN users to access. Enabled Based on Policy Destination allows client traffic in
which destination is matched with the destination configured on the SSL VPN firewall policy where as
Enabled for Trusted Destination allows client traffic that does not match the explicitly trusted destination.

Routing Address Override allows you to define the destination network (usually the corporate network) that
routes through the tunnel. If you don’t select the Routing Address Override, the destination address in the
respective firewall policies defines the destination network.

Also, for tunnel mode you need to select an IP pool for users to acquire an IP address when connecting.
There is a default pool available within the address objects if you do not create your own.

FortiGate 7.4 Administrator Study Guide 276

 SSL VPN

DO NOT REPRINT
© FORTINET

The next step is to configure the SSL VPN portal(s). An SSL VPN portal contains tools and resource links for
the users to access.

In tunnel mode, when you enable split tunneling, you need to select either Enabled Based on Policy
Destination or Enabled for Trusted Destination setting, which usually specifies networks behind the
FortiGate for the SSL VPN users to access. Enabled Based on Policy Destination allows client traffic in
which destination is matched with the destination configured on the SSL VPN firewall policy where as
Enabled for Trusted Destination allows client traffic that does not match the explicitly trusted destination.

Routing Address Override allows you to define the destination network (usually the corporate network) that
routes through the tunnel. If you don’t select the Routing Address Override, the destination address in the
respective firewall policies defines the destination network.

Also, for tunnel mode you need to select an IP pool for users to acquire an IP address when connecting.
There is a default pool available within the address objects if you do not create your own.

If you enable web mode, you can customize the SSL VPN portal and preconfigure bookmarks to appear for all
users who log in to the SSL VPN portal. Also, you can individually configure and link each portal to a specific
user or user group, so they have access to only required resources.

FortiGate 7.4 Administrator Study Guide 277

 SSL VPN

DO NOT REPRINT
© FORTINET

After you configure the SSL VPN portal, the next step is to configure the SSL VPN settings.

Let’s start with the Connection Settings section. Here, you need to map a FortiGate interface to the SSL
VPN portal. The default port for the SSL VPN portal is 443. This means users need to connect to the IP
address of the FortiGate interface mapped to the SSL VPN portal, using port443 HTTPS. If you enable
Redirect HTTP to SSL VPN, users who connect using HTTP (TCP port 80) will be redirected to HTTPS.

Port 443 is the standard default port for administration of the HTTPS protocol. This is convenient because
users do not need to specify the port in their browsers. For example, [Link]
automatically uses port443 in any browser. This is considered a valid setup on FortiGate because you usually
don’t access the SSL VPN login through every interface. Likewise, you generally don’t enable administrative
access on every interface of your FortiGate. So, even though the ports may overlap, the interfaces that each
one uses to access may not. However, if the SSL VPN login portal and HTTPS admin access both use the
same port, and are both enabled on the same interface, only the SSL VPN login portal will appear. To have
access to both portals on the same interface, you need to change the port number for one of the services. If
you change the administrator access port, this will affect the port number for that service on all interfaces.

Also, an inactive SSL VPN is disconnected after 300 seconds (5 minutes) of inactivity. You can change this
timeout using the Idle Logout setting on the GUI.

Finally, like other HTTPS websites, the SSL VPN portal presents a digital certificate when users connect. By
default, the portal uses a self-signed certificate, which triggers the browser to show a certificate warning. To
avoid the warning, you should use a digital certificate signed by a publicly known certificate authority (CA).
You can also generate a certificate for interface. Alternatively, you can load the FortiGate self-signed digital
certificate into the browser as a trusted authority.

FortiGate 7.4 Administrator Study Guide 278

 SSL VPN

DO NOT REPRINT
© FORTINET

Define the tunnel-mode client settings and the authentication rules that map users to the appropriate portal.

When users connect, the tunnel is assigned an IP address. You can choose to use the default range or create
your own range. The IP range determines how many users can connect simultaneously.

DNS server resolution is effective only when the DNS traffic is sent over the VPN tunnel. Usually, this is the
case only when split tunnel mode is disabled and all traffic is sent from the user’s computer across the tunnel.

Finally, you can allow different groups of users to access different portals. In the example shown on this slide,
teachers have access only to the Teacher_Portal. Accountants can connect to tunnel-access portal.

FortiGate 7.4 Administrator Study Guide 279

 SSL VPN

DO NOT REPRINT
© FORTINET

The fourth, and last, mandatory step involves creating firewall policies for logging on.

SSL VPN traffic on FortiGate uses a virtual interface called ssl.<vdom_name>. Each virtual domain (VDOM)
contains a different virtual interface based on its name. By default, if VDOMs are not enabled, then the device
operates with a single VDOM called root.

To activate and successfully log in to the SSL VPN, there must be a firewall policy from the SSL VPN
interface to the interface to which you want to allow access for the SSL VPN users, including all of the users
and groups that can log in as the source. Without a policy like this, no login portal is presented to users.

If there are resources behind other interfaces that users need access to, then you need to create additional
policies that allow traffic from [Link] to exit those interfaces.

FortiGate 7.4 Administrator Study Guide 280

 SSL VPN

DO NOT REPRINT
© FORTINET

Any traffic from SSL VPN users, whether in web portal or tunnel mode, exits from the ssl.<vdom_name>
interface.

This slide shows an example of firewall policies that are configured to allow access to resources behind other
interfaces that users need access to when connected through SSL VPN.

Optionally, if split tunneling is disabled, you need to create an additional firewall policy from [Link] to the
egress interface to allow clients access to the internet.

You can also apply security profiles to this firewall policy to restrict user access to the internet.

FortiGate 7.4 Administrator Study Guide 281

 SSL VPN

DO NOT REPRINT
© FORTINET

To configure FortiGate as an SSL VPN server, you must take the steps shown on this slide.

This includes local or remote user accounts or groups and PKI users. The PKI menu is available on the GUI
only after you have created a PKI user using the CLI. You can configure a CN only on the CLI. If you do not
specify a CN, then any certificate that is signed by the CA is considered valid and matched. Client
authentication requires both the client certificate and username and password.

The other steps are identical to SSL VPN setup for remote users. You can configure some steps in a different
order than what is shown on this slide.

FortiGate 7.4 Administrator Study Guide 282

 SSL VPN

DO NOT REPRINT
© FORTINET

This slides shows the steps you must take to configure FortiGate as an SSL VPN client.

The PKI user must have the same CN if a CN is configured on the SSL VPN server FortiGate certificate. You
must also select a CA certificate that allows FortiGate to complete the certificate chain and verify the server
certificate. Next, create the SSL VPN tunnel interface using the ssl.<vdom> interface.

The SSL-VPN Clients settings include name, virtual SSL VPN interface, SSL VPN server FortiGate IP
address and SSL port number, and local username, password and PKI(Peer) user. The Client Certificate as
shown on this slide is the local certificate that is used to identify this client, and is assumed to already be
installed on FortiGate. The SSL VPN server requires it for authentication.

Lastly, you must create a firewall policy to allow traffic from the internal interface to the SSL VPN interface.

FortiGate 7.4 Administrator Study Guide 283

 SSL VPN

DO NOT REPRINT
© FORTINET

You can monitor which SSL VPN users are connected on the SSL VPN widget. This shows the names of all
SSL VPN users who are currently connected to FortiGate, their IP addresses (both inside the tunnel and
outside), and connection times.

When a user connects using tunnel model, the Active Connections column shows the IP address assigned
by FortiGate to the fortissl virtual adapter on the client’s computer. Otherwise, the user is connected only
to the web portal page.

FortiGate 7.4 Administrator Study Guide 284

 SSL VPN

DO NOT REPRINT
© FORTINET

You can also review SSL VPN logs. On Log & Report > System Events:
• Select the VPN Events widget to show new connection requests, and if the SSL VPN tunnel is established
or closed.
• Select the User Events widget to see the authentication action related to SSL VPN users.

FortiGate 7.4 Administrator Study Guide 285

 SSL VPN

DO NOT REPRINT
© FORTINET

When an SSL VPN is disconnected, either by the user or through the SSL VPN idle setting, all associated
sessions in the FortiGate session table are deleted. This prevents the reuse of authenticated SSL VPN
sessions (not yet expired) after the initial user terminates the tunnel.

The SSL VPN user idle setting is not associated with the firewall authentication timeout setting. It is a
separate idle option specifically for SSL VPN users. A remote user is considered idle when FortiGate does not
see any packets or activity from the user within the configured timeout period.

FortiGate 7.4 Administrator Study Guide 286

 SSL VPN

DO NOT REPRINT
© FORTINET

When connected to SSL VPN over high latency connections, FortiGate can time out the client before the client
can finish the negotiation process, such as DNS lookup and time to enter a token. Two new CLI commands
under config vpn ssl settings have been added to address this. The first command allows you to set
up the login timeout, replacing the previous hard timeout value. The second command allows you to set up
the maximum DTLS hello timeout for SSL VPN connections.

Also, timers can help you to mitigate vulnerabilities such as Slowloris and R-U-Dead-Yet, that allow remote
attackers to cause a denial of service through partial HTTP requests.

FortiGate 7.4 Administrator Study Guide 287

 SSL VPN

DO NOT REPRINT
© FORTINET

In the typical enterprise network, there can be multiple WAN links. In the FortiGate, by default, any session
with source NAT disabled go through the route lookup when routing table changes. The sessions are marked
dirty after changes to routing table and reevaluated. Because of these route changes in multi-WAN setup,
there is possibility that request comes from one interface and response goes out through other causing
disconnections.

The set preserve-session-route command keeps the session on same interface even if session is
eligible for routing changes. By default, route preservation is disabled on the interface.

The example on this slide shows port1 is reserved for SSL VPN connections and port2 is used for other
services. Even if port2 becomes primary connection because of route changes, FortiGate will keep the
existing SSL VPN sessions on port1 interface.

FortiGate 7.4 Administrator Study Guide 288

 SSL VPN

DO NOT REPRINT
© FORTINET

The following are some best practices to keep in mind when using SSL VPNs. These best practices can also
be helpful in many SSL VPN troubleshooting situations:
• Use a FortiClient version that is compatible with your FortiOS firmware
• Enable split tunneling or create an egress firewall policy for SSL VPN connections in order to allow access
for external resources
• Connect to the correct port number
• Add SSL VPN groups, SSL VPN users, and destination addresses to the firewall policies
• Set DTLS timeout for high latency network connections
• Flush inactive sessions by timeout

FortiGate 7.4 Administrator Study Guide 289

 SSL VPN

DO NOT REPRINT
© FORTINET

There are several useful troubleshooting commands available under diagnose vpn ssl. They include:
• list: Lists logged-on users
• info: Shows general SSL VPN information
• statistics: Shows statistics about memory usage on FortiGate
• tunnel-test: Enables or disables SSL VPN old tunnel mode IP allocation method
• web-mode-test: Enables or disables random session ID in proxy URL for testing

The command diagnose debug application sslvpn shows the entire list of debug messages for SSL
VPN connections.

Remember, to use the commands listed above, you must first run the diagnose debug enable command.
Also, check SSL VPN debug logs on FortiClient.

FortiGate 7.4 Administrator Study Guide 290

 SSL VPN

DO NOT REPRINT
© FORTINET

FortiGate 7.4 Administrator Study Guide 291

 SSL VPN

DO NOT REPRINT
© FORTINET

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

By mastering the objectives covered in this lesson, you learned how to configure and use SSL VPNs to give
remote users access to your private network.

FortiGate 7.4 Administrator Study Guide 292

 IPsec VPN

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the architectural components of IPsec VPN and how to configure them.

FortiGate 7.4 Administrator Study Guide 293

 IPsec VPN

DO NOT REPRINT
© FORTINET

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

By demonstrating competence in IPsec, you will be able to understand IPsec concepts and benefits. You will
also be able to successfully determine the settings required for your IPsec VPN deployment, set up
appropriate routing and firewall policies on FortiGate, and add redundancy to your IPsec VPN deployment.

FortiGate 7.4 Administrator Study Guide 294

 IPsec VPN

DO NOT REPRINT
© FORTINET

What is IPsec? When should you use it?

IPsec is a vendor-neutral set of standard protocols that is used to join two physically distinct LANs. The LANs
are joined as if they were a single logical network, despite being separated by the internet.

In theory, IPsec does support null encryption—that is, you can make VPNs that don't encrypt traffic. IPsec
also supports null data integrity. But does that provide any advantages over plain traffic? No. No one can trust
traffic that may have had an attack injected by an attacker. Rarely do people want data sent by an unknown
source. Most people also want private network data, such as credit card transactions and medical records, to
remain private.

Regardless of the vendor, IPsec VPNs almost always have settings that allow them to provide three important
benefits:
• Authentication: to verify the identity of both ends
• Data integrity (or HMAC): to prove that encapsulated data has not been tampered with as it crosses a
potentially hostile network
• Confidentiality (or encryption): to make sure that only the intended recipient can read the message

FortiGate 7.4 Administrator Study Guide 295

 IPsec VPN

DO NOT REPRINT
© FORTINET

If you’re passing your VPN through firewalls, it helps to know which protocols to allow.

IPsec is a suite of separate protocols, which includes:

• Internet Key Exchange (IKE): used to authenticate peers, exchange keys, and negotiate the encryption and
checksums that are used—essentially, it is the control channel
• AH: contains the authentication header—the checksums that verify the integrity of the data
• Encapsulating Security Payload (ESP): the encapsulated security payload—the encrypted payload, which
is essentially the data channel

So, if you must pass IPsec traffic through a firewall, remember that allowing only one protocol or port number
is usually not enough.

Note that the IPsec RFC mentions AH, however, AH does not offer encryption, which is an important benefit.
Therefore, FortiGate does not use AH. As a result, you don’t need to allow the AH IP protocol (51).

To set up a VPN, you must configure matching settings on both ends of the VPN—whether the VPN is
between two FortiGate devices, FortiGate and FortiClient, or a third-party device and FortiGate. If the settings
don’t match, the tunnel setup fails.

The default ports for standard IKE traffic and IKE NAT-T traffic are UDP 500 and UDP 4500, respectively. You
can use the CLI command shown on this slide to configure a custom port for both IKE and IKE NAT-T. The
custom port is used to initiate and respond to tunnel requests. If NAT is detected, then the custom port can be
used for both IKE and UDP-encapsulated ESP traffic. Note that FortiGate always listens for port UDP 4500
regardless of the custom port settings. This enables FortiGate to negotiate NAT-T tunnels on custom and
standard ports.

FortiGate 7.4 Administrator Study Guide 296

 IPsec VPN

DO NOT REPRINT
© FORTINET

IPsec provides services at the IP (network) layer. During tunnel establishment, both ends negotiate the
encryption and authentication algorithms to use.

After the tunnel has been negotiated and is up, data is encrypted and encapsulated into ESP packets.

FortiGate 7.4 Administrator Study Guide 297

 IPsec VPN

DO NOT REPRINT
© FORTINET

What’s encapsulated? It depends on the encapsulation mode IPsec uses. IPsec can operate in two modes:
transport mode and tunnel mode.

• Transport mode directly encapsulates and protects the fourth layer (transport) and above. It does not
protect the original IP header and does not add an additional IP header.
• Tunnel mode is a true tunnel. It encapsulates the whole IP packet and adds a new IP header at the
beginning. After the IPsec packet reaches the remote LAN and is unwrapped, the original packet can
continue on its journey.

Note that after you remove the VPN-related headers, a transport mode packet can’t be transmitted any
further; it has no second IP header inside, so it’s not routable. For that reason, this mode is usually used only
for end-to-end (or client-to-client) VPNs.

FortiGate 7.4 Administrator Study Guide 298

 IPsec VPN

DO NOT REPRINT
© FORTINET

IKE uses UDP port 500. If NAT-T is enabled in a NAT scenario, IKE uses UDP port 4500.

IKE establishes an IPsec VPN tunnel. FortiGate uses IKE to negotiate with the peer and determine the IPsec
security association (SA). The IPsec SA defines the authentication, keys, and settings that FortiGate uses to
encrypt and decrypt that peer’s packets. It is based on the Internet Security Association and Key Management
Protocol (ISAKMP).

IKE defines two phases: phase 1 and phase 2.

There are two IKE versions: IKEv1 and IKEv2. Even though IKEv2 is a newer version and features a simpler
protocol operation, this lesson focuses on IKEv1 only, because of its much wider adoption.

FortiGate 7.4 Administrator Study Guide 299

 IPsec VPN

DO NOT REPRINT
© FORTINET

This slide shows a table comparing some of the IKEv1 and IKEv2 features that FortiOS supports. IKEv2
provides a simpler operation, which is the result of using a single exchange mode and requiring less
messages to bring up the tunnel.

Authentication-wise, both versions support PSK and certificate signature. Although only IKEv1 supports
XAuth, IKEv2 supports EAP, which is equivalent to XAuth. However, the FortiOS IKEv2 EAP implementation
is pass-through only. That is, FortiOS doesn’t support EAP as a client, which means that you cannot revoke
access to peers using IKEv2 unless you use a certificate signature. With IKEv1, you can deny access to VPN
peers without having to use a certificate signature by using XAuth. IKEv2 also supports asymmetric
authentication, which enables you to configure each peer to use a different authentication method.

Both IKE versions support NAT-T. However, IKEv2 supports NAT-T natively, while IKEv1 supports NAT-T as
an extension. Also, IKEv2 is a more reliable protocol than IKEv1 because, like TCP, peers must acknowledge
the messages exchanged between them. IKEv1 doesn’t support such a mechanism.

When you configure multiple dial-up IPsec VPNs, IKEv2 makes it simpler to match the intended gateway by
peer ID. With IKEv2, you can either use the standard peer ID attribute or the Fortinet proprietary network ID
attribute to indicate the phase 1 gateway to match on the dial-up server, regardless of the authentication mode
in use. However, with IKEv1, you can use the peer ID only, and then combine it with aggressive mode and
pre-shared key authentication, or with main mode and certificate signature authentication.

Finally, IKEv2 allows the responder to choose a subset of the traffic the initiator proposes. This is called traffic
selector narrowing and enables you to have more flexible phase 2 selector configurations. Traffic selector
narrowing enables a peer to automatically narrow down its traffic selector addresses, so it agrees with the
traffic selector the remote peer proposes.

FortiGate 7.4 Administrator Study Guide 300

 IPsec VPN

DO NOT REPRINT
© FORTINET

In order to create an IPsec tunnel, both devices must establish their SAs and secret keys, which are facilitated
by the IKE protocol.

The IPsec architecture uses SAs as the basis for building security functions into IPsec. An SA is the bundle of
algorithms and parameters being used to encrypt and authenticate data travelling through the tunnel. In
normal two-way traffic, this exchange is secured by a pair of SAs, one for each traffic direction. Essentially,
both sides of the tunnel must agree on the security rules. If both sides cannot agree on the rules for sending
data and verifying each other’s identity, then the tunnel is not established. SAs expire and need to be
renegotiated by the peers after they have reached their lifetime.

IKE uses two distinct phases: phase 1 and phase 2. Each phase negotiates different SA types. The SA
negotiated during phase 1 is called IKE SA, and the SA negotiated during phase 2 is called IPsec SA.
FortiGate uses IKE SAs for setting up a secure channel to negotiate IPsec SAs. FortiGate uses IPsec SAs for
encrypting and decrypting the data sent and received, respectively, through the tunnel.

FortiGate 7.4 Administrator Study Guide 301

 IPsec VPN

DO NOT REPRINT
© FORTINET

Use remote access VPNs when remote internet users need to securely connect to the office to access
corporate resources. The remote user connects to a VPN server located on the corporate premises, such as
FortiGate, to establish a secure tunnel. After the user is authenticated, FortiGate provides access to network
resources, based on the permissions granted to that user.

In a remote access VPN, FortiGate is usually configured as a dial-up server. You will learn more about dial-up
VPNs in this lesson. The IP address of the remote internet user is usually dynamic. Because FortiGate does
not know the IP address of the remote user, only the remote user can initiate a VPN connection request.

The remote user side needs a VPN client, such as FortiClient. You must configure FortiClient to match the
VPN server settings. FortiClient takes care of establishing the tunnel, as well as routing the traffic destined to
the remote site through the tunnel.

In addition, you can use one remote access VPN configuration on your FortiGate device for many remote
users. FortiGate establishes a separate tunnel for each of them.

FortiGate 7.4 Administrator Study Guide 302

 IPsec VPN

DO NOT REPRINT
© FORTINET

Site-to-site VPN is also known as LAN-to-LAN VPN. A simple site-to-site deployment involves two peers
communicating directly to connect two networks located at different offices.

When you need to connect more than two locations, you can use a hub-and-spoke topology. In hub-and-
spoke, all clients connect through a central hub. In the example shown on this slide, the clients—spokes—are
branch office FortiGate devices. For any branch office to reach another branch office, its traffic must pass
through the hub. One advantage of this topology is that the configuration needed is easy to manage. Another
advantage is that only the FortiGate at HQ must be very powerful because it handles all tunnels
simultaneously, while the branch office FortiGate devices require much fewer resources because they
maintain only one tunnel. One disadvantage is that communication between branch offices through HQ is
slower than in a direct connection, especially if your HQ is physically distant. Also, if the FortiGate device at
HQ fails, VPN failure is company-wide.

FortiGate 7.4 Administrator Study Guide 303

 IPsec VPN

DO NOT REPRINT
© FORTINET

In a mesh topology, you can connect FortiGate devices directly and therefore bypass HQ. Two variations of
mesh topology exist: full mesh and partial mesh. Full mesh connects every location to every other location.
The higher the number of FortiGate devices, the higher the number of tunnels to configure on each FortiGate
device. For example, in a topology with five FortiGate devices, you would need to configure four tunnels on
each device, for a total of 20 tunnels. This topology causes less latency and requires much less HQ
bandwidth than hub-and-spoke, but requires each FortiGate device to be more powerful. Partial mesh
attempts to compromise, minimizing required resources but also latency. Partial mesh can be appropriate if
communication is not required between every location. However, the configuration of each FortiGate device is
more complex than in hub-and-spoke. Routing, especially, may require extensive planning.

Generally, the more locations you have, hub-and-spoke will be cheaper, but slower, than a mesh topology.
Mesh places less strain on the central location. It’s more fault-tolerant, but also more expensive.

FortiGate 7.4 Administrator Study Guide 304

 IPsec VPN

DO NOT REPRINT
© FORTINET

To review, this slide shows a high-level comparison of VPN topologies. You should choose the topology that
is most appropriate to your situation.

FortiGate 7.4 Administrator Study Guide 305

 IPsec VPN

DO NOT REPRINT
© FORTINET

When you create an IPsec tunnel on the GUI, FortiGate redirects you to the IPsec Wizard. The wizard
simplifies the creation of the new VPN by walking you through a four to five-step process. The first step is to
select a template type. If you want to manually configure your VPN, you can select Custom as Template
type, upon which FortiGate takes you directly to the phase 1 and phase 2 settings of the new VPN.

If you want the wizard to configure the VPN for you, then select the template type (Site to Site, Hub-and-
Spoke, or Remote Access) that best matches your VPN. After that, the wizard asks you for key information,
such as the remote gateway information, authentication method, interfaces involved, and subnets. Based on
the input you provide, the wizard applies one of the preconfigured IPsec tunnel templates comprising IPsec
phase 1 and 2 settings and other related firewall address objects, routing settings, and firewall policies
needed for the new tunnel to work.

In addition, the wizard shows a network diagram that changes based on the input you provide. The purpose of
the diagram is for the administrator to have a visual understanding of the IPsec VPN deployment that the
wizard configures based on the input it receives.

At the end of the wizard, the wizard provides a summary of the configuration changes made in the system,
and that the administrator can review if needed.

If you are new to FortiGate, or don’t have much experience with IPsec VPNs, using the IPsec wizard is
recommended. You can later adjust the configuration applied by the wizard to match your specific needs.

Note that, in this lesson, you will learn only about IKEv1 configuration.

FortiGate 7.4 Administrator Study Guide 306

 IPsec VPN

DO NOT REPRINT
© FORTINET

A common use of the IPsec wizard is for configuring a remote access VPN for FortiClient users. The wizard
enables IKE mode config, XAuth, and other appropriate settings for FortiClient users. You will learn more
about IKE mode config and XAuth in this lesson.

The images on this slide show the four-step process used by the IPsec wizard for assisting the administrator
on the FortiClient VPN configuration.

FortiGate 7.4 Administrator Study Guide 307

 IPsec VPN

DO NOT REPRINT
© FORTINET

The IPsec wizard uses one of the templates shown on this slide when applying the configuration for the new
IPsec tunnel. You can review the settings of a template by selecting the template, and then clicking View. You
cannot change the template settings.

FortiGate 7.4 Administrator Study Guide 308

 IPsec VPN

DO NOT REPRINT
© FORTINET

Phase 1 takes place when each peer of the tunnel—the initiator and the responder—connects and begins to
set up the VPN. The initiator is the peer that starts the phase 1 negotiation, while the responder is the peer
that responds to the initiator request.

When the peers first connect, the channel is not secure. An attacker in the middle could intercept unencrypted
keys. Neither peer has a strong guarantee of the other peer’s identity, so how can they exchange sensitive
private keys? They can’t. First, both peers create a secure tunnel. Then, they use this secure tunnel to
negotiate the real keys for the tunnel later.

FortiGate 7.4 Administrator Study Guide 309

 IPsec VPN

DO NOT REPRINT
© FORTINET

Now you’ll examine how phase 1 works.

The purpose of phase 1 is to authenticate peers and set up a secure channel for negotiating the phase 2 SAs
(or IPsec SAs) that are later used to encrypt and decrypt traffic between the peers. To establish this secure
channel, the peers negotiate a phase 1 SA. This SA is called the IKE SA and is bidirectional because it uses
the same session key for both inbound and outbound.

To authenticate each other, the peers use two methods: pre-shared key or digital signature. You can also
enable an additional authentication method, XAuth, to enhance authentication.

In IKEv1, there are two possible modes in which the IKE SA negotiation can take place: main, and aggressive
mode. Settings on both ends must agree; otherwise, phase 1 negotiation fails and both IPsec peers are not
able to establish a secure channel.

At the end of phase 1, the negotiated IKE SA is used to negotiate the DH keys that are used in phase 2. DH
uses the public key (that both ends know) plus a mathematical factor called a nonce, in order to generate a
common private key. With DH, even if an attacker can listen to the messages containing the public keys, they
cannot determine the secret key.

FortiGate 7.4 Administrator Study Guide 310

 IPsec VPN

DO NOT REPRINT
© FORTINET

Phase 1 configuration is broken down on the GUI into four sections: Network, Authentication, Phase 1
Proposal, and XAUTH. You will learn about the settings available on each section. You will learn about some
of these settings in more detail on separate slides.

The section shown on this slide corresponds to the Network settings. The section includes the settings
related to the connectivity of the IPsec tunnel:

• IP Version: select the IP version to use for the IPsec tunnel. Note that this defines only the IP version of
the outer layer of the tunnel (after encapsulation). The packets being encapsulated (protected traffic) can
be IPv4 or IPv6, and their IP version is defined in the phase 2 selectors.
• Remote Gateway: defines the type of the remote gateway. There are three types: Static IP Address,
Dialup User, and Dynamic DNS. You will learn more about these types later in this lesson.
• IP Address: the IP address of the remote gateway. This field appears only when you select Static IP
Address as Remote Gateway.
• Interface: refers to the interface where the IPsec tunnel terminates on the local FortiGate. Usually, this is
the interface connected to the internet or the WAN. You need to make sure there is an active route to the
remote gateway through this interface, otherwise the tunnel won’t come up.
• Local Gateway: enable this setting when the interface where the tunnel terminates has multiple addresses
assigned, and you want to specify which address to use for the tunnel. When you enable this setting, you
see three options: Primary IP, Secondary IP, and Specify. Select Specify if you want to use an IP
address different from the primary or secondary IP address.
• Mode Config: Enables automatic configuration through IKE. FortiGate acts as an IKE mode config client
when you enable Mode Config and you set Remote Gateway to either Static IP address or Dynamic
DNS. If you set Remote Gateway to Dialup User, FortiGate acts as an IKE mode config server, and more
configuration options appear on the GUI. You will learn more about Mode Config in this lesson.

FortiGate 7.4 Administrator Study Guide 311

 IPsec VPN

DO NOT REPRINT
© FORTINET

The following are the other options available on the GUI in the Network section:
• NAT Traversal: The option controls the behavior for NAT traversal. You will learn more about NAT
traversal later in this lesson.
• Keepalive Frequency: When you enable NAT traversal, FortiGate sends keepalive probes at the
configured frequency.
• Dead Peer Detection: Use dead peer detection (DPD) to detect dead tunnels. There are three DPD
modes. On Demand is the default mode. You will learn more about DPD later in this lesson.
• Forward Error Correction: Forward error correction (FEC) is a technique that you can use to reduce the
number of retransmissions in IPsec tunnels established over noisy links, at the expense of using more
bandwidth. You can enable FEC on egress and ingress, and it is only supported when you disable IPsec
hardware offloading. You will learn more about IPsec hardware offloading later in this lesson.
• Advanced:
• Add route: Disable this setting if you are using a dynamic routing protocol over IPsec and do not
want FortiGate to automatically add static routes.
• Auto discovery sender: Enable this setting on a hub if you want the hub to facilitate ADVPN
shortcut negotiation for spokes. When enabled, the hub sends a shortcut offer to the spoke to
indicate that it can establish a shortcut to the remote spoke.
• Auto discovery receiver: Enable this setting on a spoke if you want the spoke to negotiate an
ADVPN shortcut.
• Exchange interface IP: Enable this setting to allow the exchange of IPsec interface IP addresses.
This allows a point-to-multipoint connection between the hub and spokes..
• Device creation: Enable this setting to instruct FortiOS to create an interface for every dial-up
client. To increase performance, disable this setting in dial-up servers with many dial-up clients.
• Aggregate member: FortiGate allows you to aggregate multiple IPsec tunnels into a single
interface. Enable this option if you want the tunnel to become an aggregate member.

FortiGate 7.4 Administrator Study Guide 312

 IPsec VPN

DO NOT REPRINT
© FORTINET

You have three options when configuring the remote gateway type of your VPN: Dialup User, Static IP
Address, and Dynamic DNS.

Use Dialup User when the remote peer IP address is unknown. The remote peer whose IP address is
unknown acts as the dial-up client, and this is often the case for branch offices and mobile VPN clients that
use dynamic IP addresses, and no dynamic DNS. The dial-up client must know the IP address or FQDN of
the remote gateway, which acts as the dial-up server. Because the dial-up server doesn’t know the remote
peer address, only the dial-up client can initiate the VPN tunnel.

Usually, dial-up clients are remote and mobile employees with FortiClient on their computer or handheld
devices. You can also have a FortiGate device acting as a dial-up client for a remote office. You can use one
dial-up server configuration on FortiGate for multiple IPsec tunnels from many remote offices or users.

FortiGate 7.4 Administrator Study Guide 313

 IPsec VPN

DO NOT REPRINT
© FORTINET

Use Static IP Address or Dynamic DNS when you know the remote peer address. If you select Static IP
Address, then you must provide an IP address. If you select Dynamic DNS, then you must provide a fully
qualified domain name (FQDN), and make sure FortiGate can resolve that FQDN. When both peers know the
remote peer address, that is, the remote gateway on both peers is set to Static IP Address or Dynamic DNS,
then any peer can initiate the VPN tunnel.

Note that in a dial-up setup, the dial-up client is just a VPN peer with the remote gateway set to static IP
address or dynamic DNS. When setting your VPN, you can combine different types of remote gateways. For
obvious reasons, a tunnel in which both peers have the remote gateway set to Dialup user won’t work.

FortiGate 7.4 Administrator Study Guide 314

 IPsec VPN

DO NOT REPRINT
© FORTINET

IKE Mode Config is similar to DHCP because a server assigns network settings such as IP address,
netmask, and DNS servers, to clients. This assignment takes place over IKE messages.

When you enable Mode Config on a FortiGate device acting as dial-up server, it pushes network settings to
dial-up clients. The dial-up clients are usually FortiClient peers, but they can also be FortiGate peers.

For IKE mode config to work, you must enable the feature on both peers. On FortiClient, Mode Config is
enabled by default, but on FortiGate, you must manually enable it.

Note that the IKE Mode Config settings, are displayed on the GUI only when you set Remote Gateway to
Dialup User. On the FortiGate device acting as dial-up client, you can select Mode Config on the GUI, but
the additional settings are not displayed.

FortiGate 7.4 Administrator Study Guide 315

 IPsec VPN

DO NOT REPRINT
© FORTINET

The ESP protocol usually has problems crossing devices that are performing NAT. One of the reasons is that
ESP does not use port numbers, like TCP and UDP do, to differentiate one tunnel from another.

To solve this, NAT transversal (NAT-T) was added to the IPsec specifications. When NAT-T is enabled on
both ends, peers can detect any NAT device along the path. If NAT is found, then the following occurs on both
peers:

• IKE negotiation switches to using UDP port 4500.

• ESP packets are encapsulated in UDP port 4500.

So, if you have two FortiGate devices that are behind, for example, an ISP modem that performs NAT, you
will probably need to enable this setting.

When you set the NAT Traversal setting to Forced, UDP port 4500 is always used, even when there is no
NAT device along the path.

When you enable NAT-T, the Keepalive Frequency option shows the interval (in seconds) at which FortiGate
sends keepalive probes. You need NAT-T when there is one or more routers along the path performing NAT.
The purpose of the keepalive probes is to keep the IPsec connection active across those routers along the
path.

FortiGate 7.4 Administrator Study Guide 316

 IPsec VPN

DO NOT REPRINT
© FORTINET

After the peers negotiate the IPsec SAs of a tunnel and, therefore, the tunnel is considered up, the peers
usually don’t negotiate another IPsec SA until it expires. In most cases, the IPsec SA expires every few hours.
This means that if there is a network disruption along the path of the tunnel before the IPsec SA expires, the
peers will continue to send traffic through the tunnel even though the communication between the sites is
disrupted.

When you enable DPD, DPD probes are sent to detect a failed (or dead) tunnel and bring it down before its
IPsec SAs expire. This failure detection mechanism is very useful when you have redundant paths to the
same destination, and you want to fail over to a backup connection when the primary connection fails to keep
the connectivity between the sites up.

FortiGate supports three DPD modes:

• On Demand: FortiGate sends DPD probes if there is only outbound traffic through the tunnel, but no
inbound. Because network applications are usually bidirectional, observing only traffic on the outbound
direction could be an indication of a network failure.
• On Idle: FortiGate sends DPD probes when no traffic is observed in the tunnel. An idle tunnel does not
necessarily mean the tunnel is dead. Avoid this mode if you have many tunnels, because the overhead
introduced by DPD can be very resource intensive.
• Disabled: FortiGate replies only to DPD probes received. FortiGate never sends DPD probes to the
remote peer and therefore cannot detect a dead tunnel.

The default DPD mode is On Demand. In terms of scalability, On Demand is a better option than On Idle.

FortiGate 7.4 Administrator Study Guide 317

 IPsec VPN

DO NOT REPRINT
© FORTINET

Now, you will learn about the Authentication section in phase 1 configuration:

• Method: FortiGate supports two authentication methods: Pre-shared Key and Signature. When you
select Pre-shared Key, you must configure both peers with the same pre-shared key. When you select
Signature, phase 1 authentication is based on digital certificate signatures. Under this method, the digital
signature on one peer is validated by the presence of the CA certificate installed on the other peer. That is,
on the local peer, you need to install both the local peer’s certificate and the CA certificate that issued the
remote peer certificate.
• Version: allows you to select the IKE version to use. When selecting version 2, aggressive and main
modes disappear because they don’t apply to IKEv2.
• Mode: refers to the IKEv1 mode. Two options are available: Aggressive and Main (ID protection). You
will learn more about these modes in this lesson.

FortiGate 7.4 Administrator Study Guide 318

 IPsec VPN

DO NOT REPRINT
© FORTINET

IKE supports two different negotiation modes: main and aggressive. Which one should you use?

To answer that question, we can analyze three categories: security, performance, and deployment.

Security wise, main mode is considered more secure because the pre-shared key hash is exchanged
encrypted, whereas in aggressive mode, the hash is exchanged unencrypted. Although the attacker would still
have to guess the cleartext pre-shared key for the attack to be successful, the fact that the pre-shared key
hash has been encrypted in main mode reduces considerably the chances of a successful attack.

In terms of performance, aggressive mode may be a better option. This is because the negotiation is
completed after only three packets are exchanged, whereas in main mode, six packets are exchanged. For
this reason, you may want to use aggressive mode when a great number of tunnels terminate on the same
FortiGate device, and performance is a concern.

Another use case for aggressive mode, is when there is more than one dial-up tunnel terminating on the same
FortiGate IP address, and the remote peer is authenticated using a peer ID because its IP address is
dynamic. Because peer ID information is sent in the first packet in an aggressive mode negotiation, then
FortiGate can match the remote peer with the correct dial-up tunnel. The latter is not possible in main mode
because the peer ID information is sent in the last packet, and after the tunnel has been identified.

When both peers know each other's IP address or FQDN, you may want to use main mode to take advantage
of its more secure negotiation. In this case, FortiGate can identify the remote peer by its IP address and, as a
result, associate it with the correct IPsec tunnel.

FortiGate 7.4 Administrator Study Guide 319

 IPsec VPN

DO NOT REPRINT
© FORTINET

Now, you will learn about the Phase 1 Proposal section of phase 1 configuration. This section allows you to
enable the different proposals that FortiGate supports when negotiating the IKE SA (or phase 1 SA). You can
combine different parameters to suit your security needs. You must at least configure one combination of
encryption and authentication algorithms, or several.

• Encryption: select the algorithm to use for encrypting and decrypting the data.
• Authentication: select the authentication algorithm to use for verifying the integrity and authenticity of the
data.
• Diffie-Hellman Groups: The Diffie-Hellman (DH) algorithm is used during IKE SA negotiation. The use of
DH in phase 1 is mandatory and can’t be disabled. You must select at least one DH group. The higher the
DH group number, the more secure the phase 1 negotiation is. However, a higher DH group number also
results in a longer compute time.
• Key Lifetime: defines the lifetime of the IKE SA. At the end of the lifetime, a new IKE SA is negotiated.
• Local ID: if the peer accepts a specific peer ID, type that same peer ID in this field.

FortiGate 7.4 Administrator Study Guide 320

 IPsec VPN

DO NOT REPRINT
© FORTINET

Phase 1 supports two types of authentication: pre-shared keys and digital signatures. The XAuth extension,
sometimes called phase 1.5, forces remote users to authenticate additionally with their credentials (username
and password). So, additional authentication packets are exchanged if you enable it. What is the benefit?
Stronger authentication.

When you set Remote Gateway to Dialup User, FortiGate acts as the authentication server. The XAUTH
section shows the authentication server type options: PAP Server, CHAP Server, and Auto Server. In the
example shown on this slide, Auto Server is selected, which means that FortiGate automatically detects the
authentication protocol used by the client.

After you select the authentication server type, you configure how user group matching is performed. There
are two options: Inherit from policy and Choose. The latter is used in the example on this slide, and allows
you to select one of the user groups available on FortiGate. Note that, when you select Choose, you must
configure a separate dial-up VPN for every group of users that require a different network access policy.

The other way to authenticate VPN users with XAuth is by selecting Inherit from policy. When you select this
option, FortiGate authenticates users based on their matching IPsec policy and, as a result, the configuration
for controlling network access is simpler. That is, you control network access by configuring multiple policies
for different user groups, instead of configuring multiple tunnels for different user groups. The Inherit from
policy option follows a similar authentication approach used for SSL VPN remote users that you learned in
the SSL VPN lesson.

When Remote Gateway is set to Static IP Address or Dynamic DNS, FortiGate acts as the client, and the
XAUTH section shows the Client option as Type. You can then set the credentials that FortiGate uses to
authenticate against the remote peer through XAuth.

FortiGate 7.4 Administrator Study Guide 321

 IPsec VPN

DO NOT REPRINT
© FORTINET

After phase 1 has established a secure channel to exchange data, phase 2 begins.

Phase 2 negotiates security parameters for two IPsec SAs over the secure channel established during phase
1. ESP uses IPsec SAs to encrypt and decrypt the traffic exchanged between sites, one outbound and one
inbound.

Phase 2 does not end when ESP begins. Phase 2 periodically renegotiates IPsec SAs to maintain security. If
you enable Perfect Forward Secrecy, each time phase 2 expires, FortiGate uses DH to recalculate new
secret keys. In this way, new keys are not derived from older keys, making it much harder for an attacker to
crack the tunnel.

Each phase 1 can have multiple phase 2s. When would this happen? For example, you may want to use
different encryption keys for each subnet whose traffic is crossing the tunnel. How does FortiGate select
which phase 2 to use? By checking which phase 2 selector (or quick mode selector) matches the traffic.

FortiGate 7.4 Administrator Study Guide 322

 IPsec VPN

DO NOT REPRINT
© FORTINET

In phase 2, you must define the encryption domain (or interesting traffic) of your IPsec tunnel. The encryption
domain refers to the traffic that you want to protect with IPsec, and it is determined by your phase 2 selector
configuration.

You can configure multiple selectors to have more granular control over traffic. When you configure a phase 2
selector, you specify the encryption domain by indicating the following network parameters:
• Local Address and Remote Address: as seen in the example shown on this slide, you can define IPv4 or
IPv6 addresses using different address scopes. When selecting Named Address or Named IPv6
Address, FortiGate allows you to select an IPv4 or IPv6 firewall address object, respectively, configured in
the system.
• Protocol: is in the Advanced section, and is set to All by default.
• Local Port and Remote Port: are also shown in the Advanced section, and are set to All by default. This
applies only to port-based traffic such as TCP or UDP. You will learn more about the Advanced section
later in this lesson.

Note that after the traffic is accepted by a firewall policy, traffic is dropped before entering the IPsec tunnel if
the traffic does not match any of the phase 2 selectors configured. For this reason, usually, it’s more intuitive
to filter traffic with firewall policies. So, if you don’t want to use phase 2 selector filtering, you can just create
one phase 2 selector with both the local and remote addresses set to any subnet, like in the example shown
on this slide, and then use firewall policies to control which traffic is accepted on the IPsec tunnel.

In addition, the phase 2 selector network parameters on both peers must match if the tunnel is point-to-point,
that is, when the remote gateway is not set to dial-up user.

FortiGate 7.4 Administrator Study Guide 323

 IPsec VPN

DO NOT REPRINT
© FORTINET

For every phase 2 selector, you need to configure one or more phase 2 proposals. A phase 2 proposal
defines the algorithms supported by the peer for encrypting and decrypting the data over the tunnel. You can
configure multiple proposals to offer more options to the remote peer when negotiating the IPsec SAs.

Like in phase 1, you need to select a combination of encryption and authentication algorithms. Some
algorithms are considered more secure than others, so make sure to select the algorithms that conform with
your security policy. However, note that the selection of the algorithms has a direct impact on FortiGate IPsec
performance. For example, 3DES is known to be a much more resource-intensive encryption algorithm than
DES and AES, which means that your IPsec throughput could be negatively impacted if you select 3DES as
the encryption algorithm. Also, note that if you select NULL as the encryption algorithm, traffic is not
encrypted.

In addition, some encryption algorithms, such as CHACHA20POLY1305, are not supported for hardware
offload. That is, if you have a FortiGate device that contains network processor (NP) units, you can achieve
higher IPsec performance if you select an algorithm that is supported for IPsec offload by your NP unit model,
such as AES or DES. For a list of supported encryption algorithms for IPsec hardware offloading, refer to
[Link]

When configuring the phase 2 proposal, you can select Enable Replay Detection to detect antireplay attacks
on ESP packets. Note that this is a local setting and, therefore, it is not included as part of the proposals
presented by the peer during phase 2 negotiation.

Also, if you enable Perfect Forward Secrecy, FortiGate uses DH to enhance security during the negotiation
of IPsec SAs.

FortiGate 7.4 Administrator Study Guide 324

 IPsec VPN

DO NOT REPRINT
© FORTINET

IPsec SAs are periodically renegotiated to improve security, but when does that happen? It depends on the
key lifetime settings configured on the phase 2 proposal.

The expiration of an IPsec SA is determined by the lifetime type and threshold configured. By default, Key
Lifetime is set to Seconds (time-based). This means that when the SA duration reaches the number of
seconds set as Seconds, the SA is considered expired. You can also set the key lifetime to Kilobytes
(volume-based), upon which the SA expires after the amount of traffic encrypted and decrypted using that SA
reaches the threshold set. Alternatively, you can select Both as the key lifetime type, upon which FortiGate
tracks both the duration of the SA and the amount of traffic. Then, when any of the two thresholds is reached,
the SA is considered expired. Note that the key lifetime thresholds do not have to match for the tunnel to come
up. When thresholds are different, the peers agree on using the lowest threshold value offered between the
two.

When IPsec SAs expire, FortiGate needs to negotiate new SAs to continue sending and receiving traffic over
the IPsec tunnel. Technically, FortiGate deletes the expired SAs from the respective phase 2 selectors, and
installs new ones. If IPsec SA renegotiation takes too much time, then FortiGate might drop interesting traffic
because of the absence of active SAs. To prevent this, you can enable Auto-negotiate. When you do this,
FortiGate not only negotiates new SAs before the current SAs expire, but it also starts using the new SAs right
away. The latter prevents traffic disruption by IPsec SA renegotiation.

Another benefit of enabling Auto-negotiate is that the tunnel comes up and stays up automatically, even
when there is no interesting traffic. When you enable Autokey Keep Alive and keep Auto-negotiate
disabled, the tunnel does not come up automatically unless there is interesting traffic. However, after the
tunnel is up, it stays that way because FortiGate periodically sends keep alive packets over the tunnel. Note
that when you enable Auto-negotiate, Autokey Keep Alive is implicitly enabled.

FortiGate 7.4 Administrator Study Guide 325

 IPsec VPN

DO NOT REPRINT
© FORTINET

On some FortiGate models, you can offload the encryption and decryption of IPsec traffic to hardware. The
algorithms that are supported depend on the NP unit model present on FortiGate. For a list of supported
encryption algorithms for IPsec hardware offloading, refer to [Link]

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

FortiGate 7.4 Administrator Study Guide 326

 IPsec VPN

DO NOT REPRINT
© FORTINET

FortiGate supports two types of IPsec VPNs: route-based and policy-based. Policy-based is a legacy IPsec
VPN that is supported only for backward compatibility reasons, and its use is not recommended for new
deployments. Unless otherwise stated, all IPsec VPN references in this lesson are for route-based IPsec
VPNs.

In a route-based IPsec VPN, FortiGate automatically adds a virtual interface with the VPN name. This means
that not only can you configure routing and firewall polices for IPsec traffic in the same way you do for non-
IPsec traffic, but you also can leverage the presence of multiple connections to the same destination to
achieve redundancy.

Another benefit of route-based IPsec VPNs is that you can deploy variations of IPsec VPNs such as L2TP-
over-IPsec and GRE-over-IPsec. In addition, you can also enable dynamic routing protocols for scalability
purposes and best path selection.

FortiGate 7.4 Administrator Study Guide 327

 IPsec VPN

DO NOT REPRINT
© FORTINET

Although you can use dynamic routing protocols for IPsec VPNs, this lesson covers only the use of static
routes.

The routing configuration needed for your IPsec VPN depends on the type of remote gateway configured.
When you set the remote gateway to Dialup User and enable add-route, FortiGate automatically adds a
static route for the local network presented by the remote peer during phase 2 negotiation. In addition, the
route is added to the routing table only after phase 2 is up. If phase 2 goes down, the static route is removed
from the routing table.

When you set the remote gateway to Dialup User and disable add-route, FortiGate does not add static
routes automatically. In this case, a dynamic routing protocol is used between the remote peers to exchange
routing information.

When the remote gateway is set to Static IP Address or Dynamic DNS, you must configure static routes.
When you configure a static route, you select the virtual interface of the IPsec tunnel as the outgoing interface.

FortiGate 7.4 Administrator Study Guide 328

 IPsec VPN

DO NOT REPRINT
© FORTINET

You must configure at least one firewall policy that accepts traffic on your IPsec tunnel. Otherwise, the tunnel
will not come up.

When you configure firewall policies for non-IPsec traffic, the policy determines the direction of the traffic that
initiates sessions. The same applies to IPsec traffic. For this reason, you usually want to configure at least two
firewall policies for your IPsec VPN: one incoming policy and one outgoing policy. The incoming policy allows
traffic initiated from the remote site, while the outgoing policy allows traffic to be initiated from the local
network.

Note that the policies are configured with the virtual tunnel interface (or phase 1 name) as the incoming or
outgoing interface.

FortiGate 7.4 Administrator Study Guide 329

 IPsec VPN

DO NOT REPRINT
© FORTINET

How can you make your IPsec VPN deployment more resilient? Provide a second ISP connection to your site
and configure two IPsec VPNs. If the primary IPsec VPN fails, another tunnel can be used instead.

There are two types of redundant VPNs:

• Partially redundant: on one peer (usually the hub, where a backup ISP is available if the main ISP is down),
each VPN terminates on different physical ports. That way, FortiGate can use an alternative VPN. On the
other peer, each VPN terminates on the same physical port—so the spoke is not fault tolerant.

• Fully-redundant: both peers terminate their VPNs on different physical ports, so they are both fault tolerant.

FortiGate 7.4 Administrator Study Guide 330

 IPsec VPN

DO NOT REPRINT
© FORTINET

So, how do you configure a partially or fully redundant VPN?

First, create one phase 1 for each path—one phase 1 for the primary VPN and one for the backup VPN. You
should also enable DPD on both ends.

Second, create at least one phase 2 definition for each phase 1.

Third, you must add at least one static route for each VPN. Routes for the primary VPN must have a lower
distance (or lower priority) than the backup. This causes FortiGate to use the primary VPN while it’s available.
If the primary VPN fails, then FortiGate automatically uses the backup route. Alternatively, you could use a
dynamic routing protocol, such as OSPF or BGP.

Finally, configure firewall policies to allow traffic through both the primary and backup VPNs.

FortiGate 7.4 Administrator Study Guide 331

 IPsec VPN

DO NOT REPRINT
© FORTINET

On the GUI dashboard, you can use the IPsec widget to monitor the status of your IPsec VPNs. The widget
shows the phase 1 and phase 2 status of an IPsec VPN.

You can also bring up or bring down individual VPNs, and get additional details. When you bring up an IPsec
VPN using the IPsec widget, you can choose between bringing up a particular phase 2 selector or all phase 2
selectors in that VPN. Because bringing up a phase 2 selector requires bringing up its phase 1 first, then
bringing up a phase 2 selector results in its phase 1 also coming up.

To bring down the VPN, you can choose between bringing down a particular phase 2 selector, all selectors, or
the entire tunnel. When you bring down the entire tunnel, you bring down all phase 2 selectors as well as the
phase 1.

The Name column indicates the VPN status. The VPN is up when at least one of its phase 2 selectors is up. If
all phase 2 selectors are down, the VPN status is also down. The Phase 1 and Phase 2 Selectors columns
indicate the status of phase 1 and phase 2 selectors, respectively.

The IPsec widget also displays the amount of data sent and received through the tunnel. When you right-click
any of the columns, a menu opens with a list of all the columns available. You can enable additional columns
to get further details about the IPsec tunnels.

In the example shown on this slide, the ToRemote VPN is up because at least one of its phase 2 selectors
(ToRemote) is up.

FortiGate 7.4 Administrator Study Guide 332

 IPsec VPN

DO NOT REPRINT
© FORTINET

If you set the remote gateway to Static IP Address or Dynamic DNS, the static routes for these tunnels
become active in the routing table after phase 1 comes up. Phase 1 negotiation is started automatically
because automatic negotiation is enabled on phase 1 by default. This behavior allows FortiGate to match
interesting traffic to the right tunnel. Moreover, if phase 2 is not up, traffic matching the static route triggers a
phase 2 negotiation, which eventually results in the tunnel (or phase 2) to come up.

When you set the remote gateway to Dialup User, by default, a static route for the destination network is
added after phase 2 comes up. The distance set for the static route is 15. If phase 2 goes down, the route is
removed from the routing table.

FortiGate 7.4 Administrator Study Guide 333

 IPsec VPN

DO NOT REPRINT
© FORTINET

FortiGate logs IPsec VPN events by default. To view IPsec VPN event logs, click Log & Report > System
Events > VPN Events.

The logs track the progress of phase 1 and phase 2 negotiations, and report on tunnel up and down events
and DPD failures, among other events. For more information about IPsec logs, visit
[Link]

FortiGate 7.4 Administrator Study Guide 334

 IPsec VPN

DO NOT REPRINT
© FORTINET

The same command diagnose vpn tunnel offers options for listing, shutting down, activating, or flushing
a VPN tunnel.

FortiGate 7.4 Administrator Study Guide 335

 IPsec VPN

DO NOT REPRINT
© FORTINET

The command diagnose vpn tunnel list displays the current IPsec SA information for all active
tunnels.

The command diagnose vpn tunnel list name <tunnel name> provides SA information about a
specific tunnel.

FortiGate 7.4 Administrator Study Guide 336

 IPsec VPN

DO NOT REPRINT
© FORTINET

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

The output shows traffic counters, negotiated quick mode selectors, and negotiated encryption, authentication,
and keys.

FortiGate 7.4 Administrator Study Guide 337

 IPsec VPN

DO NOT REPRINT
© FORTINET

The command diagnose vpn ike gateway list also provides some details about a tunnel.

The command diagnose vpn ike gateway clear closes a phase 1. Be careful when using this
command because it has a global effect. This means that running it without specifying the phase 1 name
results in all phase 1s of all VDOMs being cleared.

FortiGate 7.4 Administrator Study Guide 338

 IPsec VPN

DO NOT REPRINT
© FORTINET

This slide shows a summary of the most common IPsec problems and solutions.

If the tunnel doesn’t come up, use the IKE real-time debug. In such cases, an error message usually appears.

When the tunnel is unstable, you usually see that DPD packets are being lost, which indicates that the
problem might be on the ISP side.

If the tunnel is up but traffic isn’t passing through it, use the debug flow. One of the peers might be dropping
packets or routing traffic incorrectly. Another possibility is that the packets don’t match the quick mode
selectors, so FortiGate drops the packets.

FortiGate 7.4 Administrator Study Guide 339

 IPsec VPN

DO NOT REPRINT
© FORTINET

FortiGate 7.4 Administrator Study Guide 340

 IPsec VPN

DO NOT REPRINT
© FORTINET

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

By mastering the objectives covered in this lesson, you learned how the IPsec protocol works, and how to
configure and monitor IPsec VPNs on FortiGate.

FortiGate 7.4 Administrator Study Guide 341

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

In this lesson, you will learn about the SD-WAN feature available on FortiGate.

FortiGate 7.4 Administrator Study Guide 342

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

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

FortiGate 7.4 Administrator Study Guide 343

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

According to Gartner, software-defined WAN (SD-WAN) provides dynamic, policy-based, application path
selection across multiple WAN connections, and supports service chaining for additional services, such as
WAN optimization and firewalls. The Fortinet implementation of SD-WAN is called secure SD-WAN because it
also provides security by leveraging the built-in security features available on FortiOS.

Secure SD-WAN relies on well-known FortiOS features, such as IPsec, link monitoring, advanced routing,
internet services database (ISDB), traffic shaping, UTM inspection, and load balancing. The administrator can
then combine these features and set rules that define how FortiGate steers traffic across the WAN based on
multiple factors, such as the protocol, service, or application identified for the traffic, and the quality of the
links. Note that SD-WAN controls egress traffic, not ingress traffic. This means that the return traffic may use
a different link from the one SD-WAN chose for egress.

One benefit of SD-WAN is effective WAN use. That is, you can use public (for example, broadband or LTE)
and private (for example, MPLS) links to securely steer traffic to different destinations: internet, public cloud,
private cloud, and the corporate network. This approach of using different types of links to connect sites to
private and public networks is known as hybrid WAN. Using a hybrid WAN reduces costs mainly because
administrators usually steer traffic over low-cost fast internet links more than over high-cost slow private links.
The result is that private links, such as MPLS links, are often used to steer critical traffic only, or as failover
links for high availability.

Another benefit of SD-WAN is improved application performance because you can steer traffic through the
best link that meets the application requirements. During congestion, you can leverage traffic shaping to
prioritize sensitive and critical applications over less important ones.

FortiGate 7.4 Administrator Study Guide 344

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

Direct internet access (DIA), also known as local breakout, is arguably the most common use case for SD-
WAN. A site has multiple internet links (also known as underlay links), and the administrator wants FortiGate
to steer internet traffic across the links. The links are connected to FortiGate using different types of physical
interfaces: physical port, VLAN, link aggregation (LAG), USB modem, or through FortiExtender.

Usually, the administrator chooses to send sensitive traffic over the best-performing links, while distributing
non-critical traffic across one or more links using a best-effort approach. Costly internet links are commonly
used as backup links, or to steer critical traffic only.

Because the internet traffic leaves the organization boundaries directly on the local site, administrators usually
enforce strict security policies on the internet traffic. For routing, a typical configuration makes use of static
default routes. However, in some cases, BGP is used between the ISP and FortiGate, especially if the site
must advertise a public IP prefix.

Administrators can also manually define the upstream and downstream speeds of each link to prevent
saturation during traffic distribution. Alternatively, they can configure FortiGate to use the SD-WAN bandwidth
monitoring service to run speed tests against FortiGuard, and then automatically adjust the upstream and
downstream speeds of the links based on the test results.

FortiGate 7.4 Administrator Study Guide 345

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

You can use SD-WAN to steer corporate site-to-site traffic. Usually, companies follow a hub-and-spoke
topology, and use VPN tunnels—typically dynamic IPsec tunnels—to transport the traffic between the sites.
The tunnels (also known as overlay links) are established over internet or MPLS links (also known as
underlay links). Tunnels can also carry internet traffic from a spoke to a hub where it then exits to the internet.

SD-WAN can monitor the link quality of the tunnels and select the best performing link for sensitive and critical
traffic

For routing, static routing is possible, but a dynamic routing protocol, such as BGP, is often used to exchange
routing information through the tunnels. Dynamic routing scales more easily when adding new sites.

Similar to DIA, the hub FortiGate can run speed tests against the spokes to determine the upstream speed of
tunnels. The hub FortiGate can then apply the speed test result as the upstream speed on the tunnel for traffic
shaping purposes.

In the example shown on this slide, each site has two overlays configured, one using the internet underlay and
the other the MPLS underlay. SD-WAN steers spoke-to-hub traffic.

FortiGate 7.4 Administrator Study Guide 346

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

Remote Internet Access (RIA), also known as remote breakout, is another use case for SD-WAN. Internet
traffic from the spokes is backhauled through the WAN using overlay links. When the traffic arrives at the hub,
it breaks out to the internet.

The most common reason to use RIA is to centralize security inspection and internet access on the hub. For
example, you can have a central high-end FortiGate device that inspects all the internet traffic that leaves the
organization and conforms with the company policy, instead of having each low-end spoke FortiGate device to
inspect traffic, thus reducing costs and administrative overhead.

Another reason to use RIA is for DIA backup. For example, you could configure FortiGate to steer internet
traffic through an MPLS link if the performance measured for internet applications on internet links is worse
than on MPLS links, or simply if the internet links become unavailable.

FortiGate 7.4 Administrator Study Guide 347

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

On FortiGate, an SD-WAN configuration is built on SD-WAN rules. SD-WAN rules combine traffic matching
criteria and traffic steering preferences. They describe the administrator choices related to the SD-WAN
solution.

To define SD-WAN rules use:

• Members: These are the logical or physical interfaces used to steer the traffic.
• Zones: Zones are groups of members used to optimize the configuration.
• Performances SLA rules: With the performance SLA rules you can define how you want to monitor
the status of members and the performance criteria that you want to monitor. It can be packet loss,
jitter, latency, or a weighted mix of a few criteria.

You first define the criteria of the application or traffic to match. Then, you indicate the forward policy to follow
for steering traffic across one or more members and zones, including the strategy to apply and the
performance metrics to determine the preferred members.

In the next few slides, you will learn more about each element that composes an SD-WAN rule.

FortiGate 7.4 Administrator Study Guide 348

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

SD-WAN rules combine traffic-matching criteria and traffic-steering preferences. They describe the
administrator choices related to the SD-WAN solution and the software-defined aspect of it.

You first define the criteria of the application or traffic to match. Then, you indicate the forward policy to follow
for steering traffic across one or more members and zones, including the strategy to apply and the
performance metrics to determine the preferred members.

Preferred members are the best alive members in a zone based on the strategy in use. FortiGate then uses
the preferred members—provided they are acceptable—to steer traffic. For all strategies, if you don’t activate
a load balancing mode, FortiGate chooses a single member to steer traffic. You will discover the strategies
available on a separate slide.

If none of the user-defined SD-WAN rules are matched, then FortiGate uses the implicit rule.

The example on this slide shows three user-defined rules. A rule named Critical-to-HQ which is used to steer
critical traffic from the branch office to the headquarters. The rule steers traffic from LOCAL_SUBNET to the
HQ-Subnet through the overlay links (T_INET and T_MPLS). The member selection is done with a latency
criteria and T_MPLS is the selected member. The rules Critical-DIA and Non-Critical-DIA, which FortiGate
uses to steer traffic for DIA through the underlay zone (port1 and port2), differentiate the link selection
according to the application in use. Note that only the most significant parts of rule configuration are shown in
the output.

FortiGate 7.4 Administrator Study Guide 349

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

FortiGate evaluates SD-WAN rules in the same way as firewall policies: from top to bottom, using the first
match. However, unlike firewall policies, they are used to steer traffic, not to allow traffic. When you use SD-
WAN rules, you must configure corresponding firewall policies to allow SD-WAN traffic.

There is an implicit SD-WAN rule created by default. It is always present at the bottom of the SD-WAN rule
list. If none of the user-defined SD-WAN rules are matched, then the implicit rule is used. This means that
FortiGate routes the traffic according to the regular process. By default, the implicit rule load balances the
traffic across all available SD-WAN members. In the example above, the implicit rule can steer the traffic
through overlay (T_INET, T_MPLS) or underlay (port1, port2) members, according to the best match in the
routing table.

You can double-click the implicit rule to display the load balancing options. By default, the implicit rule load
balances the traffic according to Source IP. You can decide to load balance according to Source-Destination
IP, Sessions, Volume, or Spillover.

FortiGate 7.4 Administrator Study Guide 350

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

The first step to configure SD-WAN is to define the members and assign them to zones. This configuration is
done on the SD-WAN Zones page.

Members (also known as links) are existing physical or logical FortiOS interfaces that you select to be part of
SD-WAN. FortiGate then uses the interfaces to steer traffic based on the SD-WAN rules configured.

When you configure a member in SD-WAN, you must assign it to a zone and, optionally, set a gateway.
Zones are logical groupings of interfaces. The interfaces in a zone have similar configuration requirements.
Like FortiGate interface zones, the goal with SD-WAN zones is to reference them in the configuration instead
of individual members to optimize the configuration by avoiding duplicate settings. When set, FortiGate uses
the Gateway setting as the next hop to forward traffic through the member.

FortiGate creates one zone by default, called virtual-wan-link zone. It is where FortiGate places any new
member if you don’t assign them to a user-defined zone.

The example on this slide shows the default SD-WAN zone—virtual-wan-link—and two user-defined zones:
underlay and overlay. The underlay zone contains port1 and port2 as members, which are used for a basic
DIA setup. Note that although the zone is named underlay because it contains this type of members, you can
assign any name you like.

FortiGate 7.4 Administrator Study Guide 351

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

In an SD-WAN environment, the terms underlay and overlay are commonly used to describe the link type of
an SD-WAN member.

Underlays refer to the physical links that you can rent or buy from an ISP, such as cable, DSL, fiber, MPLS,
3G/4G/LTE, and ATM links. These links are part of the ISP physical infrastructure that is responsible for
delivering packets across networks. The traffic that travels through underlays is restricted to the routing
policies deployed by the ISP and, therefore, the packet source and destination IP addresses must be routable
within the ISP network. This restriction leaves you with limited options to define your network addressing plan.
In addition, traffic transmitted through underlays is usually not encrypted by the ISP network, which means
that unauthorized parties can access sensitive data if the sender does not encrypt the data.

Overlays are virtual links that you build on top of underlays. A common example of an overlay is an IPsec
tunnel. Because original packets are often encapsulated in ESP packets, the networks that communicate
through the IPsec tunnel are no longer restricted to the routing policies of the ISP. In addition, the privacy and
authentication features provided by IPsec protect your traffic from unauthorized access.

This slide shows the different underlay and overlay links supported by FortiGate as SD-WAN members.

FortiGate 7.4 Administrator Study Guide 352

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

Usually, you should apply a different set of policies based on the link type of your SD-WAN members. For
example, you may want to enable NAT and apply strict security policies to internet traffic sent through
underlay links, because the traffic directly leaves the site boundaries. Conversely, you may want to disable
NAT and apply basic filtering and inspection to traffic sent through overlay links, because the remote site is
fully routable and performs additional filtering and inspection on the traffic.

SD-WAN zones allow administrators to group members that require a similar set of firewall policies. Usually,
this means grouping underlays and overlays into different SD-WAN zones.

FortiGate creates the virtual-wan-link SD-WAN zone by default, which you can’t delete. It contains any SD-
WAN member not explicitly assigned to a user-defined SD-WAN zone. Firewall policies defined for your SD-
WAN traffic, must reference the SD-WAN zones, and cannot reference individual SD-WAN members.

The topology shown on this slide shows a branch office with two SD-WAN zones configured: overlay and
underlay. The overlay SD-WAN zone is composed of IPsec tunnels and the underlay SD-WAN zone is
composed of an internet link and a 3G/4G link. The branch office uses the overlays to access the headquarter
networks, and the underlays to access services in the public cloud. By dividing SD-WAN members into zones,
you can apply the same set of firewall policies to a zone instead of having to apply them to their individual
members, thus reducing the administrative overhead and building a cleaner configuration.

FortiGate 7.4 Administrator Study Guide 353

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

After you define your SD-WAN members and assign them to zones, you will probably want to monitor the
health of your SD-WAN members on the Performance SLAs page. Although configuring performance SLAs
is optional, you should configure them to ensure members meet the health and performance requirements for
steering traffic, which is critical for effective WAN use with SD-WAN.

FortiGate performance SLAs monitor the state of each member—whether it is alive or dead—and measures
the member packet loss, latency, and jitter. SD-WAN then uses the member health information to make traffic
steering decisions based on the configured SD-WAN rules. For example, you can instruct FortiGate to steer
internet traffic to a member, provided the member is alive and its latency doesn’t exceed a given threshold.
Performance SLAs also detect situations where the interface is physically up, but FortiGate is unable to reach
the desired destination and flags the corresponding link as dead.

When you configure a performance SLA, you can decide whether you want to monitor the link health actively
or passively. In active monitoring, the performance SLA checks the health of the member periodically—by
default every 500ms— sending probes from the member to one or two servers that act as a beacon. In
passive monitoring, the performance SLA determines the health of a member based on the traffic passing
through the member. Note that only active monitoring can detect if a link is alive or dead.

The example on this slide shows an entry named Level3_DNS. The entry contains the well-known [Link] and
[Link] DNS servers, both of which are used to monitor the health of port1 and port2. The performance SLA
VPN_PING monitors the health of the two overlay tunnels, T_INET and T_MPLS. The results show that the
members are alive (green arrow), report no packet loss, and have average values for latency (jitter is also
measured but not visible in this example).

FortiGate 7.4 Administrator Study Guide 354

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

When you configure a performance SLA rule, you first define the link health monitor parameters.

In this section you will define the detection mode that FortiGate uses to monitor the link quality:
• Active: FortiGate sends active probes to the configured server to monitor the link health.
• Passive: FortiGate uses traffic through the link to evaluate the link health. It uses session
information from traffic on selected firewall policies (firewall policies with the parameter passive-
wan-health-measurement enabled).
• Prefer Passive: FortiGate uses passive monitoring and, only if there is no traffic through the link,
sends probes.

You can specify up to two servers to act as your beacons. This guards against the server being at fault, and
not the link.

The SLA target section is optional. It’s where you define the performance requirements of alive members
(latency, jitter, and packet loss thresholds). The performance SLA uses SLA targets with some SD-WAN rule
strategies, like Lowest Cost (SLA), to decide if the link is eligible for traffic steering or not.

The link status section is available for Active and Prefer Passive probe mode. It is where you define how
often FortiGate sends probes through each monitored link, and how many failed probes you accept before
declaring a link as dead.

The example of this slide shows the configuration of a performance SLA named Level3_DNS. It is defined
with Active probe mode, and default values for SLA target and probe configuration. It monitors the status and
performances of two underlay interfaces, port1 and port2.

FortiGate 7.4 Administrator Study Guide 355

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

The strategy in a rule defines the requirements for preferred members. The preferred members are the best
members from the outgoing interface (oif) list—based on the strategy in use—that meet the SLA
requirements (if applicable). The oif list sorts the configured members by preference. That is, although the
members are the same, their order in the oif list, and in Interface Preference list, can be different. There
are three strategies you can chose from:

• Manual: FortiGate prefers members according to configuration order. Member metrics are not considered
for member preference.

• Best Quality: FortiGate prefers the best-performing member based on the configured quality criteria.

• Lowest Cost (SLA): FortiGate prefers the member that meets the configured SLA target. If multiple
members meet the SLA target, member cost, followed by the configuration order, are used as tiebreakers.

Note that for all strategies, by default, FortiGate must check that the preferred member has a valid route to the
destination. If the member doesn’t have a valid route, then FortiGate checks the next member in the oif list,
and so on, until it finds an acceptable member. Moreover, all strategies, except Manual, consider the member
metrics for member preference.

FortiGate 7.4 Administrator Study Guide 356

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

The load balancing strategies allow you to distribute the traffic among multiple SD-WAN members. To be
eligible for traffic distribution the member must be alive, have a valid route to destination, and, in the case of
Lowest cost strategy, meet the SLA target.

You can choose the load balancing strategy under the Manual and the Lowest cost (SLA) strategies.
FortiGate applies load balancing as follows:
•Manual: load balancing across all members available in the zone
•Lowest cost (SLA): load balancing across all members that meet SLA targets

When you activate load balancing, by default, FortiGate distributes the traffic through all available members
following the round-robin algorithm (sessions are distributed to selected interfaces in equal portions and
circular order). Through CLI commands, you can select another load balancing algorithm. Some of the hash
modes available are source-ip-based, source-dest-ip-based, and inbandwidth.

FortiGate 7.4 Administrator Study Guide 357

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

You can configure rules to match traffic based on the following criteria:

• Source IP address, source interface, firewall user, and firewall user group. If you want to specify the source
interface, you should use the CLI commands input-device and input-device-negate.
• Destination IP address, IP protocol, destination port number
• Internet service
• Application: single application, application category, or group of applications
• Type of Service (ToS)

SD-WAN rules offer great flexibility for traffic matching. For example, you can match Netflix traffic sourced
from specific authenticated users, or match the ICMP traffic—IP protocol 1—destined to a particular address.

Note that, by default, the GUI rule configuration menu does not display the application criteria field. If you want
to use this feature, you should enable the criteria visibility from the CLI under config system global.

FortiGate 7.4 Administrator Study Guide 358

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

To be allowed by FortiGate, the traffic steered by an SD-WAN rule must also be allowed by a firewall policy.

You configure SD-WAN firewall policies in the same way as regular firewall policies, except that, when
selecting an outgoing or incoming interface, you must reference a normalized interface that refers to an SD-
WAN zone. When you reference a zone, you simplify the configuration by avoiding duplicate firewall policies.
You can’t use individual members of an SD-WAN zone in firewall policies.

The example on this slide shows firewall policies that reference the underlay and overlay SD-WAN zones.
The underlay zone contains port1 and port2 as members, and the overlay zone contains T_INET and
T_MPLS. Those policies also contain, as source or destination, the normalized interface for the individual port
port3. This interface is not part of an SD-WAN zone.

FortiGate 7.4 Administrator Study Guide 359

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

When you configure an SD-WAN rule, FortiGate essentially applies a policy route on FortiOS. For this reason,
before learning how routing in SD-WAN works, it is useful to first understand policy routes.

Static routes are simple and are often used in small networks. Policy routes, however, are more flexible
because they can match more than just the destination IP address. For example, you can configure as
matching criteria the incoming interface, the source and destination subnets, protocol, and port number.
Because regular policy routes have precedence over any other routes, it is a best practice to narrow down the
matching criteria as much as possible. Otherwise, traffic that is expected to be routed by SD-WAN rules or
other routes in the forwarding information base (FIB) could be handled by regular policy routes instead.

This slide shows an example of a policy route configured using the FortiGate GUI. The policy route instructs
FortiGate to match traffic received at port5, sourced from [Link]/24 and destined to the host
[Link]. The traffic must also be destined to TCP port 10444 for the policy route to match. FortiGate
then forwards the traffic—the Forward Traffic action—to port1 through the gateway [Link].

FortiGate 7.4 Administrator Study Guide 360

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

When a packet matches a policy route, FortiGate takes one of two actions. Either it routes the packet to the
configured outgoing interface and gateway—the Forward Traffic action—or it stops checking the policy
routes—the Stop Policy Routing action—so the packet is routed based on the FIB.

Note that when you configure Forward Traffic as the action, the Destination Address, Outgoing interface,
and the Gateway address settings must match a route in the FIB. Otherwise, the policy route is considered
invalid and, as a result, skipped.

Also note that policy routes have precedence over SD-WAN rules, and over any routes in the FIB. That is, if a
packet matches a policy route and the policy route has a matching route in the FIB, then FortiGate doesn’t
check any of the configured SD-WAN rules or the routes in the FIB.

FortiGate 7.4 Administrator Study Guide 361

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

SD-WAN rules define the traffic steering policies in SD-WAN. However, traffic won’t be forwarded to an SD-
WAN member unless there is a valid route that matches the destination address of the traffic through the SD-
WAN member.

Because the goal is to have SD-WAN pick the best member to forward the traffic to, based on the SD-WAN
rule criteria, it’s a best practice to configure your routing setup so your SD-WAN sites know all possible routes
to all possible destinations that are intended for handling by SD-WAN. Otherwise, SD-WAN may fail to choose
the best member, not because it doesn’t meet the application requirements, but because FortiGate doesn’t
have a route for the destination and member.

You can use static and dynamic routing in SD-WAN. This slide shows an example of a static default route
configured for the underlay zone, which is used to route traffic in a basic DIA setup.

FortiGate 7.4 Administrator Study Guide 362

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

When you configure a static route, you can reference one or more zones as the outgoing interface. As a
result, FortiOS installs a static route in the routing table for every member configured in the zone. Because the
static routes share the same distance, they become ECMP routes. FortiOS uses the gateway defined for each
zone member.

Alternatively, you can configure per-member static routes for more granular control over traffic. However,
unlike static routes for zones, which retrieve the member gateway from the member configuration, with per-
member static routes, you must specify a gateway if the interface type requires it.

When you create a static route for a zone, FortiOS assigns the routes with a distance of 1 by default. FortiOS
assigns such a low distance by default because administrators usually want their SD-WAN routes to have
preference over other routes in the FIB. However, you can change the distance to a different value if required.
Static routes for individual members have default distance of 10.

In the example shown on this slide, port1 and port2 are members of the underlay zone. The
administrator created a default static route that references this zone. The result is that the routing table
displays ECMP routes for each member of the zone. In addition, the administrator created a per-member
static route for [Link] through port1. All three routes can then be used by SD-WAN rules to route traffic, or by
the FIB to route traffic when no rule is matched.

FortiGate 7.4 Administrator Study Guide 363

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

Routing is a core component of SD-WAN. Understanding how routing works in SD-WAN is essential for
design and troubleshooting. The following are the SD-WAN key routing principles:

• SD-WAN rules are policy routes. Like regular policy routes, SD-WAN rules route traffic based on multiple
criteria. That is, when you configure an SD-WAN rule, the kernel installs a corresponding policy route that
reflects the source, destination, service, and outgoing interfaces configured in the SD-WAN rule.

• Regular policy routes have precedence over SD-WAN rules. Therefore, if you configure regular policy
routes, you should ensure that their matching criteria is as narrow as possible. Otherwise, traffic that is
intended to be handled by SD-WAN could end up being handled by regular policy routes instead.

• FortiGate performs route lookup on both new and dirty sessions. A dirty session is a session that must be
re-evaluated by the kernel after it is impacted by a routing, firewall policy, or interface change. FortiGate
performs route lookups for both original and reply traffic. During route lookup, FortiGate also checks policy
routes.

• By default, FortiGate skips SD-WAN rules if the best route to the destination isn’t an SD-WAN member. If
the best route matches an SD-WAN member, then the selected member in the rule must have a valid route
to the destination, otherwise FortiGate skips the member, and checks the next best member. If none of the
members have a valid route to the destination, then FortiGate skips the rule.

• The implicit SD-WAN rule equals standard FIB lookup. That is, if the traffic doesn’t match any of the SD-
WAN rules, then FortiGate routes the traffic using the regular process, which consists of looking for the
best route in the FIB. If the best route matches equal cost multipath (ECMP) routes—usually the case—
then FortiGate load balances the traffic using the configured load balancing algorithm.

FortiGate 7.4 Administrator Study Guide 364

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

To verify SD-WAN traffic routing, for logged flows, you can use the forward traffic logs. You can use the
Destination Interface column in the Forward Traffic logs to verify that traffic is egressing the SD-WAN
member interfaces. The column SD-WAN Rule Name indicates the name of the SD-WAN rule that applies. No
name in this column means that the flow was routed according to the default Implicit SD-WAN rule.

Alternatively, you can use verbosity levels 4 to 6 to view the egress interface using the CLI packet capture
tool.

The example on this slide shows a capture with a filter that matches any packets with the SYN flag on and port
443. So, the sniffer output shows all SYN packets to port 443 (HTTPS).

FortiGate 7.4 Administrator Study Guide 365

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

FortiOS maintains a policy route table that you can view by running the diagnose firewall proute
list command.

There are three types of policy routes displayed in the policy route table: regular policy routes, ISDB routes,
and SD-WAN rules. Follow these rules to identify each type of policy route in the table:

• Regular policy routes are assigned an ID no higher than 65535. In the output shown on this slide, the first
entry is assigned ID 1, which makes it a regular policy route.

• ISDB routes and SD-WAN rules are assigned an ID higher than 65535. However, SD-WAN rule entries
include the vwl_service field, and ISDB route entries don’t. The vwl_service field indicates the ID
and the name of the rule from the SD-WAN configuration perspective. In the output shown on this slide, the
second entry is an ISDB route and the third entry an SD-WAN rule.

In the output of some CLI commands related to SD-WAN you will notice some entries with VWL like
vwl_service or vwl_mbr_seq. vwl stands for Virtual Wan Link, it corresponds to the former naming of
SD-WAN.

FortiGate 7.4 Administrator Study Guide 366

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

This slide shows an example of a policy route list output.

Note the fields vwl_service and vwl_mbr, which indicate the SD-WAN rule that allowed the route
creation and the SD-WAN member used to steer the traffic.

The ID displayed in the diagnose firewall proute list command output corresponds to the ID
displayed in the debug flow output when a packet matches a rule. The output also includes the outgoing
interface list, with the interface preference sorted from left to right.

For troubleshooting purposes, the output of the diagnose firewall proute list command also
displays the rule hit count and the last time the rule was hit.

FortiGate 7.4 Administrator Study Guide 367

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

The CLI command diagnose sys session filter allows you to filter the sessions to display. Then, use
the command diagnose sys session list to display the session detail.

You can use diagnose sys session filter ? to view available filters, diagnose sys session
filter to see active filters, and diagnose sys session filter clear to reset the filters settings.
Use the command diagnose sys session list for IPv4 traffic, and diagnose sys session6 list
for IPv6 traffic.

The right part of this slide shows an example output with detailed information about the session table entry.

Only information related to SD-WAN is highlighted. From left to right, and from top to bottom:

• The ID of the matching policy

• The application ID (used for SD-WAN rules with application criteria)
• The SD-WAN-specific session information. sdwan_mbr_seq and sdwan_service_id indicate the SD-
WAN member ID and the SD-WAN rule ID in use, respectively. If the session matched the SD-WAN
implicit rule, and therefore was handled using standard FIB routing, those SD-WAN fields do not appear.

FortiGate 7.4 Administrator Study Guide 368

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

Because of the dynamic nature of SD-WAN routing, you should periodically check the link health, routing
behavior, and traffic distribution of your SD-WAN devices. You might want to check that traffic distribution
corresponds to expectations with, for instance, only critical traffic steered through the costliest links. On the
other hand, when you detect an unexpected event on your network, you want to be able to easily understand
the impact on SD-WAN traffic steering and routing decisions.

For those activities, you can count on some general FortiGate monitoring tools you already know, like the
routing table, the session table or the embedded packet capture tool. You can also benefit from dedicated SD-
WAN monitoring tools provided by the FortiGate GUI interface. Through the next few slides, you will discover
the SD-WAN monitoring tools provided by the FortiGate GUI.

FortiGate 7.4 Administrator Study Guide 369

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

By default, the Network dashboard includes three widgets useful for SD-WAN monitoring. It should be the
first place you look when you want to check the SD-WAN behavior on a FortiGate device.

From this page you can view:

• Static and dynamic routing
• IPsec tunnels status
• SD-WAN interfaces performances

Click any widget to expand and get additional details per topic. The SD-WAN widget provides an overview of
the status of each monitored SD-WAN link.

The example on this slide shows the details you can view by clicking the SD-WAN widget. Note that the
packet loss diagram reports that one interface is at medium level, which means between 10%-40% of packet
loss.

FortiGate 7.4 Administrator Study Guide 370

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

From the SD-WAN widget detailed view, you can hover over the graph to view details. You can also click a
graph part to filter the member list and display only the members that match the selected criteria.

In the example shown on this slide, two members have a high rate of packet loss—above 40%. This is
displayed on the diagram as the red part of the circle. When you click this red part of the circle, FortiGate
filters the member list to display only members with a high rate of packet loss—for this example, T_INET and
T_MPLS.

FortiGate 7.4 Administrator Study Guide 371

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

The SD-WAN Zones page in the menu Network > SD-WAN, provides a synthetic view of the SD-WAN zones
and members configuration. Note that zones with no member appear with a red icon. Next to zones with
members is a + sign that you can click to display the members.

The diagram at the top of the page displays traffic allocation per interface, evaluated by bandwidth use,
volume, or number of sessions.

From this menu, you can double-click zone or interface lines to adjust their configurations.

FortiGate 7.4 Administrator Study Guide 372

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

From the SD-WAN zone page presented on the previous slide, you can monitor the traffic distribution over the
SD-WAN members. The page contains graphs that display traffic distribution based on bandwidth, volume, or
sessions. Note that bandwidth refers to the data rate, while volume refers to the amount of data.

You can also hover over a member or the graph to get a specific amount of bandwidth, volume, or sessions.

FortiGate 7.4 Administrator Study Guide 373

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

The SD-WAN Rules page in the menu Network > SD-WAN, provides a summary view of SD-WAN rules
configuration. From this list you can quickly view the main configuration parameters of a rule, members in use,
and the last time the rule was used to steer traffic. With drag-and-drop you can re-order the rules. You can
also double-click any user-defined rule to adjust its configuration.

If you want to adjust the view, you can reorder the column with drag-and-drop, add or remove columns with
the parameter menu on the left side of the top bar. You can also filter on any column to adjust the display to
what you are looking for. Hover over the columns corner to view the filter configuration icon.

FortiGate 7.4 Administrator Study Guide 374

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

You can browse to the Performance SLAs page to monitor the health of your members. You first select the
performance SLA you want to check (Level3_DNS in the example). The graphs on the page will then display
the packet loss, latency, and jitter of each member using the selected performance SLA. Note that the
information shown on the graphs is limited to the last 10 minutes.

If you configured an SLA target, it appears on the graph as a horizontal dotted line. You can quickly detect the
member status. The FortiGate GUI shows alive members with a green up arrow icon, and dead members with
a red down arrow icon. For a missed SLA target, FortiGate highlights the impacted metric in red. It is
important to note that the green up arrows indicate only that the server is responding to the health check,
regardless of the packet loss, latency, and jitter values. It is not an indication that any of the SLAs are being
met.

You can display graphs for Packet Loss, Latency, or Jitter by selecting the upper tabs. You can also hover
over the graph to get a specific amount of packet loss, latency, or jitter. Because link quality plays an
important role in link selection when using SD-WAN, monitoring the link quality status of the SD-WAN
member interfaces is a good practice. You should investigate any prolonged issues with packet loss, latency,
or jitter to ensure your network traffic does not experience outages or degraded performance.

In the example shown on this slide, the Level3_DNS performance SLA is selected and reports that port2 is
alive and port1 is dead. The graph shows latency for both monitored interfaces over the past 10 minutes.

From this page you can also update a performance SLA configuration, or create a new one.

FortiGate 7.4 Administrator Study Guide 375

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

From the System Events log summary menu, you get an overview of recent events ordered by category and
message type. By default, the summary page considers logs received over the past 5 minutes. You can adjust
to get a summary over the past 1 hour or past 24 hours. In the SD-WAN Events summary widget, you will log
events about SLA status changes, priority member order changes, and so on. The VPN Events widget
provides useful information to understand overlay links behavior.

Click the widget title to view the corresponding logs in detail. Click an event name to view the logs filtered by
event name.

FortiGate 7.4 Administrator Study Guide 376

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

The SD-WAN Events subsection on the Events page displays logs that report the state changes of the SD-
WAN members.

In most cases, you want to click a log to fully understand the event. For example, the warning log message
highlighted in the table indicates that the state of port2 changed from alive to dead. Although the details
above this one are not shown, the logs report that port2 stopped forwarding traffic, and that the member
preference in the rule that uses port2 was updated to remove port2.

FortiGate 7.4 Administrator Study Guide 377

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

The Forward Traffic logs page is useful to identify how sessions are distributed in SD-WAN and the reason.
Make sure to enable the SD-WAN Rule Name and SD-WAN Quality columns, which are disabled by default.
The former indicates the matched SD-WAN rule for a session, and the latter the member the session was
steered to and the reason.

Note that the Implicit SD-WAN rule name does not appear in the SD-WAN Rule Name column. When the
traffic is steered according to this rule the field remains empty.

The table on this slide shows multiple sessions. The first session in the table was identified as a Salesforce
application, matched the Critical-DIA rule, and was sent to port1. The reason that port1 was selected was
because it had the lowest latency.

The second session in the table, which was identified as a Facebook application, matched the Non-Critical-
DIA rule, and was sent to port2. The Non-Critical-DIA rule instructs FortiGate to steer matching traffic to
port2 only, provided the port is alive. This behavior matches the reason described in the SD-WAN Quality
column for that session.

FortiGate 7.4 Administrator Study Guide 378

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

FortiGate 7.4 Administrator Study Guide 379

 SD-WAN Configuration and Monitoring

DO NOT REPRINT
© FORTINET

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

By mastering the objectives covered in this lesson, you learned how to configure, maintain, and monitor a
FortiGate SD-WAN solution.

FortiGate 7.4 Administrator Study Guide 380

 Security Fabric

DO NOT REPRINT
© FORTINET

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

FortiGate 7.4 Administrator Study Guide 381

 Security Fabric

DO NOT REPRINT
© FORTINET

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

By demonstrating a competent understanding of key concepts of the Fortinet Security Fabric, you will better
understand the value of the Security Fabric, the servers that comprise it, how to deploy it, and how it helps to
manage all your network devices more efficiently and from a single point of view.

FortiGate 7.4 Administrator Study Guide 382

 Security Fabric

DO NOT REPRINT
© FORTINET

What is the Fortinet Security Fabric?

It is a Fortinet enterprise solution that enables a holistic approach to network security, whereby the network
landscape is visible through a single console and all network devices are integrated into a centrally managed
and automated defence.

The network devices include all components, from physical endpoints to virtual devices in the cloud. Because
devices are centrally managed and are sharing threat intelligence with one another in real time, and are
receiving updates from Fortinet at the macro level, your network can quickly identify, isolate, and neutralize
threats as they appear.

The Security Fabric has the following attributes:

• Broad: It provides visibility of the entire digital attack surface to better manage risk
• Integrated: It provides a solution that reduces the complexity of supporting multiple point products
• Automated: Threat intelligence is exchanged between network components in real-time allowing for
automated response to threats

A fourth attribute could be added to this description of the Security Fabric: open. The API and protocol are
available for other vendors to join and for partner integration. This allows for communication between Fortinet
and third-party devices.

FortiGate 7.4 Administrator Study Guide 383

 Security Fabric

DO NOT REPRINT
© FORTINET

Why has Fortinet deemed the Security Fabric an essential solution for a robust network defence?

As networks evolved and various new types of threats surfaced, point security products were deployed to
address these emerging threats. Often, these piecemeal solutions were effective, but deploying products
using different standards and protocols meant that defence assets could not be effectively coordinated.

The illustration on the right side of the slide tells a story of a network that has deployed security solutions from
four different vendors. The administrator at the center, working from the security console, has visibility into
only some of the security solutions. This lack of visibility of the entire network defence is a serious flaw, and
could allow a foreign infiltrator to breach network defences undetected.

The sheer complexity of today’s networks compounds this problem. In addition, increasingly sophisticated
malware has an expanding attack surface on which to exploit, because networks have broken out of the
confines of a traditional network perimeter and have expanded to virtualized networks and public clouds. Add
to this mix, the ever growing numbers of unmanaged devices, as a result of BYOD programs, and you have
the perfect security storm.

The most feasible solution is to build a centrally managed, holistic approach to security, whereby you have a
clear line of sight to all potential infiltration points and can coordinate defences to contain and neutralize
network breaches.

FortiGate 7.4 Administrator Study Guide 384

 Security Fabric

DO NOT REPRINT
© FORTINET

As shown on this slide, the Fortinet Security Fabric offers eight solutions: network access, security
WLAN/LAN, public and private cloud infrastructure, applications, endpoint, security operations, open fabric
ecosystem, and fabric management center. Each of these solutions is based on specific use cases and
involve the integration of specific Fortinet products.

The Fortinet Security Fabric offers network security with FortiGate, IPS, VPN, SD-WAN. It also offers multi-
cloud strategy across public clouds, private clouds, hybrid clouds, and software as a service (SaaS). It also
offers quite a sophisticated endpoint offering ranging from the Fabric Agent all the way up to full endpoint
protection, email security, web application security, secure access across distributed enterprises and SD-
WAN environments, advanced threat protection, management and analytics, and security information and
event management (SIEM).

All of these are underscored and supported by FortiGuard Services, which deliver AI-powered intelligence and
protection across the Security Fabric.

FortiGate 7.4 Administrator Study Guide 385

 Security Fabric

DO NOT REPRINT
© FORTINET

FortiGate devices are the core of the Security Fabric, plus one FortiAnalyzer or cloud logging solution.
FortiAnalyzer Cloud or FortiGate Cloud can act as the cloud logging solution. The FortiGate devices must be
running in NAT mode and can have one of the following roles:

• Root
• Downstream

Root FortiGate is the main component in the Security Fabric. It is typically located on the edge of the network
and connects the internal devices and networks to the internet through your ISP. From the root FortiGate, you
can see information about the entire Security Fabric on the Physical and Logical Topology pages in the GUI.

After a root FortiGate is installed, all other downstream FortiGate devices in the Security Fabric act as Internal
Segmentation Firewalls (ISFWs), located at strategic points in your internal network, rather than on the
network edge. This allows extra security measures to be taken around key network components, such as
servers that contain valuable intellectual property. ISFW FortiGate devices create network visibility by sending
traffic and information about the devices that are connected to them to the root FortiGate.

To add more visibility and control, Fortinet recommends adding FortiManager, FortiAP, FortiClient, FortiClient
EMS, FortiSandbox, FortiMail, FortiWeb, FortiNDR, FortiDeceptor, and FortiSwitch.

The solution can be extended by adding other network security devices, including several third-party products.

FortiGate 7.4 Administrator Study Guide 386

 Security Fabric

DO NOT REPRINT
© FORTINET

This simple network that comprises only the core devices of a Security Fabric includes one FortiAnalyzer and
four next-generation firewall (NGFW) FortiGate devices.

The FortiGate device named External is acting as the edge firewall and is configured as the root firewall within
the Security Fabric.

Downstream from the root firewall, three internal segmentation firewalls compartmentalize the WAN in order
to contain breaches and to control access to various LANs. This example uses Accounting, Marketing, and
Sales LANs.

FortiGate 7.4 Administrator Study Guide 387

 Security Fabric

DO NOT REPRINT
© FORTINET

To configure a new Security Fabric, follow the general steps described here:

First, on the root FortiGate device, you must enable Security Fabric Connection on the interfaces that face
any downstream FortiGate device. Then, enable the Security Fabric connector, and select Serve as Fabric
Root. You also need to configure FortiAnalyzer or a cloud logging solution. This logging configuration is
pushed to all the downstream FortiGate devices.

Optionally, you can preauthorize your downstream devices by adding their serial numbers. When you add the
serial number of a Fortinet device to the trusted list on the root FortiGate device, the device can join the
Security Fabric as soon as it connects. After you authorize the new FortiGate, additional connected FortiAP
and FortiSwitch devices automatically appear in the topology tree.

FortiGate 7.4 Administrator Study Guide 388

 Security Fabric

DO NOT REPRINT
© FORTINET

The second step in implementing the Security Fabric is configuring the downstream Fortinet devices. On the
downstream FortiGate devices, you must enable Security Fabric Connection and Device Detection on the
interfaces facing the downstream FortiGate devices. On the Fabric Connectors page, select Join Existing
Fabric and add the root (upstream) FortiGate IP address.

The third step in implementing the Security Fabric is to authorize the downstream FortiGate devices on the
root FortiGate.

FortiGate 7.4 Administrator Study Guide 389

 Security Fabric

DO NOT REPRINT
© FORTINET

When the Security Fabric is enabled, settings to sync various objects, such as addresses, services, and
schedules, from the upstream FortiGate device to all downstream FortiGate devices is enabled by default.
Synchronization always happens from the root FortiGate to downstream FortiGate devices. Any object that
can be synced will be available on downstream FortiGate devices after synchronization.

The CLI command fabric-object-unification is available only on the root FortiGate device. When set
to local, global objects are not synchronized to downstream devices in the Security Fabric. The default
value is default.

The CLI command configuration-sync local is used when a downstream FortiGate device doesn’t
need to participate in object synchronization. When set to local on a downstream FortiGate device, the
device does not synchronize objects from the root, but still participates in sending the synchronized object
downstream.

You can also enable or disable per-object synchronization in the Security Fabric. This option is not available
for objects you create on a downstream FortiGate device. Security Fabric synchronization is disabled by
default for supported Security Fabric objects, and these Security Fabric objects are kept as locally created
objects on all the FortiGate devices in the Security Fabric. If object synchronization is disabled on the root
FortiGate device, using the command set fabric-object disable, firewall addresses and address
groups are not synchronized to downstream FortiGate devices.

Note that if a device in the Security Fabric is in multi-VDOM mode, the GUI does not display the Security
Fabric synchronization option. Even if this is enabled in the CLI, the object is not synchronized to any
downstream devices.

FortiGate 7.4 Administrator Study Guide 390

 Security Fabric

DO NOT REPRINT
© FORTINET

If an object conflict occurs during synchronization, you will get a notification in the topology tree.

The process to resolve a synchronization conflict is as follows:

1. Click the notification message: 1 Firewall objects is in conflict with other FortiGates in the
fabric. Click the notification message.

2. On the Firewall Object Synchronization page, you can see that both the root FortiGate and
downstream FortiGate devices contain the sync_add_1 object (with a different IP address/subnet
schema on each device), causing a status of Content mismatch. The Strategy field, displays
two options to resolve the conflict: Automatic and Manual. Select Automatic, as shown in this
example, and then click Rename All Objects.

3. Remote-FortiGate is appended to the name of the downstream FortiGate device sync_add_1

address object and the status changes to Resolved.

4. The conflict message disappears.

FortiGate 7.4 Administrator Study Guide 391

 Security Fabric

DO NOT REPRINT
© FORTINET

When you configure FortiGate devices in multi-vdom mode and add them to the Security Fabric, each VDOM
with its assigned ports is displayed when one or more devices are detected. Only the ports with discovered
and connected devices appear in the Security Fabric view and, because of this, you must enable Device
Detection on ports you want to have displayed in the Security Fabric. VDOMs without ports with connected
devices are not displayed. All VDOMs configured must be part of a single Security Fabric. In the example
shown on this slide, the Local-FortiGate is configured in multi-VDOM mode, and has three VDOMs (root,
VDOM1, and VDOM2), each with ports that have connected devices.

FortiGate 7.4 Administrator Study Guide 392

 Security Fabric

DO NOT REPRINT
© FORTINET

Device identification is an important component in the Security Fabric. FortiGate detects most of the third-
party devices in your network and add them into the topology view in the Security Fabric. There are two
device identification techniques: with an agent and without an agent (agentless).

Agentless identification uses traffic from the device. Devices are indexed by their MAC address and there are
various ways to identify devices, such as HTTP user-Agent header, TCP fingerprint, MAC address OUI, and
FortiOS-VM detection methods, to name a few. Agentless device identification is only effective if FortiGate
and the workstations are directly connected network segments, where traffic is sent directly to FortiGate, and
there is no intermediate router or Layer 3 device between FortiGate and the workstations.

Note that FortiGate uses a first come, first served approach to determine the device identity. For example, if a
device is detected by the HTTP user agent, FortiGate updates its device table with the detected MAC address
and scanning stops as soon as the type has been determined for that MAC address.

Agent-based device identification uses FortiClient. FortiClient sends information to FortiGate, and the device
is tracked by its unique FortiClient user ID (UID).

FortiGate 7.4 Administrator Study Guide 393

 Security Fabric

DO NOT REPRINT
© FORTINET

By default, FortiGate uses device detection (passive scanning), which runs scans based on the arrival of
traffic.

FortiGate 7.4 Administrator Study Guide 394

 Security Fabric

DO NOT REPRINT
© FORTINET

The slide shows the list of products that Fortinet recommends to extend the Security Fabric.

For example, Fortinet recommends using a FortiManager for centralized management of all FortiGate devices
and to access devices in the Security Fabric. You can also extend the Security Fabric down to the access
layer by integrating FortiSwitch and FortiAP devices.

FortiGate 7.4 Administrator Study Guide 395

 Security Fabric

DO NOT REPRINT
© FORTINET

Administrator-defined automated workflows (called stitches) cause FortiOS to automatically respond to an

event in a preprogrammed way. Because this workflow is part of the Security Fabric, you can set up
automation stitches for any device in the Security Fabric. However, the Security Fabric is not required to use
stitches.

Each automation stitch pairs a trigger and one or more actions. FortiOS has several predefined stitches,
triggers and actions. However, you can create custom automation based on the available options.

Automation stitches allow you to monitor your network and take appropriate action when the Security Fabric
detects a threat. You can use automation stitches to detect events from any source in the Security Fabric and
apply actions to any destination.

You can configure the Minimum internal (seconds) setting on some of the available actions to make sure
they don’t run more often than needed.

FortiGate 7.4 Administrator Study Guide 396

 Security Fabric

DO NOT REPRINT
© FORTINET

This slide shows an example of how automation stitches can be configured to work in the Security Fabric:

1. FortiClient sends logs to FortiAnalyzer.

2. FortiAnalyzer discovers IoCs in the logs and notifies FortiGate.
3. FortiGate identifies whether FortiClient is a connected endpoint, and whether it has the login credentials
for the FortiClient EMS that FortiClient is connected to. With this information, FortiGate sends a
notification to FortiClient EMS to quarantine the endpoint.
4. FortiClient EMS searches for the endpoint and sends a quarantine message to it.
5. The endpoint receives the quarantine message and quarantines itself, blocking all network traffic. The
endpoint notifies FortiGate and EMS of the status change.
6. FortiGate sends a notification to a Microsoft Teams channel to alert the administrators about the event.

FortiGate 7.4 Administrator Study Guide 397

 Security Fabric

DO NOT REPRINT
© FORTINET

External connectors allow you to integrate multi-cloud support, such as Microsoft Azure and AWS, among
others.

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

FortiGate 7.4 Administrator Study Guide 398

 Security Fabric

DO NOT REPRINT
© FORTINET

The Security Fabric Status widget shows a summary of the devices in the Security Fabric.

You can hover over the icons at the top of the widget to display a quick view of their statuses. From here, you
can click to authorize FortiAP and FortiSwitch devices that are connected to an authorized FortiGate.

Icons represent the other Fortinet devices that can be used in the Security Fabric:

• Devices in blue are connected in your network.

• Devices in gray are not configured, or not detected in your network.
• Devices in red are no longer connected, or not authorized in your network.

FortiGate 7.4 Administrator Study Guide 399

 Security Fabric

DO NOT REPRINT
© FORTINET

Security rating is a subscription service that requires a security rating license. This service provides the ability
to perform many best practices, including password checks, to audit and strengthen your network security.

The Security Rating page is separated into three major scorecards: Security Posture, Fabric Coverage,
and Optimization.

These scorecards provide executive summaries of the three largest areas of security focus in the Security
Fabric.

The scorecards show an overall letter grade and breakdown of the performance in subcategories. Click a
scorecard to drill down to a detailed report of itemized results and compliance recommendations. The point
score represents all passed and failed items in that area. The report includes the security controls that were
tested, linking them to specific FSBP or PCI compliance policies. You can click FSBP and PCI to reference
the corresponding standard.

In multi-VDOM mode, administrators with read/write access can generate security rating reports in the Global
VDOM for all the VDOMs on the device. Administrators with read-only access can view the report, but not
generate it.

On the scorecards, the Scope column shows the VDOM or VDOMs that the security rating checked. On
checks that support Easy Apply, you can run the remediation on all the associated VDOMs.

The security rating event log is available on the root VDOM.

FortiGate 7.4 Administrator Study Guide 400