FortiGate Infrastructure Study Guide Online PDF

DO NOT REPRINT
© FORTINET
FortiGate Infrastructure Study Guide

for FortiOS 5.6.2
DO NOT REPRINT
© FORTINET
Fortinet Training
http://www.fortinet.com/training
Fortinet Document Library
http://docs.fortinet.com
Fortinet Knowledge Base
http://kb.fortinet.com
Fortinet Forums
https://forum.fortinet.com
Fortinet Support
https://support.fortinet.com
FortiGuard Labs
http://www.fortiguard.com
Fortinet Network Security Expert Program (NSE)

https://www.fortinet.com/support-and-training/training/network-security-expert-program.html
Feedback
Email: courseware@fortinet.com
2/9/2018
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
01 Routing 4
02 Software-Defined WAN 62
03 Virtual Domains 90
04 Layer 2 Switching 133
05 Site-to-Site IPsec VPN 179
06 Fortinet Single Sign-On 217
07 High Availability 269
08 Web Proxy 315
09 Diagnostics 354
Supplementary Material 398
Firewall Policies 399
Network Address Translation 446
 Routing
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about the routing capabilities and features available on FortiGate.
FortiGate Infrastructure Study Guide 4

 Routing
DO NOT REPRINT
© FORTINET
In this lesson, you will explore the following topics:

• Routing on FortiGate
• Routing monitor and route attributes
• Equal cost multipath routing
• Reverse path forwarding
• Best practices
• Diagnostics

 Routing
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to:

• Identify the routing capabilities on FortiGate
• Configure static routing
• Implement policy based routes
• Control traffic for well-known Internet services
By demonstrating competence in routing on FortiGate, you should be able to implement static, and policy
routing. You will also be able to control traffic routing for well-known Internet services.

 Routing
DO NOT REPRINT
© FORTINET
What is routing?
Routing is how FortiGate in NAT mode decides where to send the packets that it receives and the packets
that it generates.
All network devices that perform routing have a routing table. A routing table contains a series of rules. Each
rule specifies the next hop, which may or may not be the final destination of the packet. Each routing hop in
the routed path requires a routing table lookup to pass the packet along until it reaches the final destination.
When routing packets, FortiGate will first find a matching route in its list of routes based on the packet’s
destination address. When performing this match, FortiGate evaluates the entire routing table to find the most
specific match before selecting a route. If FortiGate finds multiple matches, it uses various route attributes to
determine the best route.
Proper routing configuration is important. If routes are misconfigured, packets will not reach their destination
and will be lost.

 Routing
DO NOT REPRINT
© FORTINET
By default, many aspects of FortiGate are stateful. That is, FortiGate decides many things at the beginning of
a session, when it receives the first packet.
For each session, FortiGate performs two routing lookups:

• For the first packet sent by the originator
• For the first reply packet coming from the responder
After completing these two lookups, FortiGate writes the routing information to its session table. Subsequent
packets are routed according to the session table, not the routing table. So, all packets that belong to the
same session follow the same path, even after a change in the static routes. However, there is an exception
to this rule: if there is a change in the routing table, FortiGate removes the route information for the session
table, and then it makes additional routing table lookups to rebuild this information.

 Routing
DO NOT REPRINT
© FORTINET
One type of manually configured route is called a static route. When you configure a static route, you are
telling FortiGate, “When you see a packet whose destination is within a specific range, send it through a
specific network interface, towards a specific router.” You can also configure the distance and priority so that
FortiGate can identify the best route to any destination matching multiple routes. You will learn about distance
and priority later in this lesson.
For example, in simple home networks, DHCP automatically retrieves and configures one static route. Your
modem then sends all outgoing traffic through your ISP’s Internet router, which can relay packets to their
destination. This is typically referred to as a default route, because all traffic not matching any other routes
will, by default, be routed using this route. The example shown here is a default route. The destination subnet
value of 0.0.0.0/0.0.0.0 will match all addresses within any subnet. Most FortiGate devices deployed at
the edge of the network will have at least one of these default routes to ensure Internet traffic is forwarded to
the ISP network.
Static routes are not needed for subnets to which FortiGate has direct layer 2 connectivity.

 Routing
DO NOT REPRINT
© FORTINET
If you create a firewall address object with the type IP/Netmask or FQDN, you can use that firewall address
as the destination of one or more static routes. First, enable Static Route Configuration in the firewall
address configuration. After it is enabled, the firewall address object becomes available for use in the
Destination drop-down list for static routes with named addresses.

 Routing
DO NOT REPRINT
© FORTINET
For large networks, manually configuring hundreds of static routes may not be practical. Your FortiGate can
help, by learning routes automatically. FortiGate supports several dynamic routing protocols: RIP, OSPF,
BGP, and IS-IS.
In dynamic routing, FortiGate communicates with nearby routers to discover their paths, and to advertise its
own directly connected subnets. Discovered paths are automatically added to FortiGate’s routing table. So
verify that your neighbor routers are trusted and secured!
Larger networks also may need to balance the routing load among multiple valid paths, and detect and avoid
routers that are down. You’ll learn more about that in this lesson.

 Routing
DO NOT REPRINT
© FORTINET
Static routes are simple and are often used in small networks. Policy-based routes, however, are more
flexible. They can match more than just the destination IP address. For example, If you have two links—a
slow one and a fast one—you can route packets from low-priority source IPs to the slow link.
Policy routes set to the action Forward Traffic have precedence over static and dynamic routes. So, if a
packet matches the policy route, FortiGate bypasses any routing table lookup.
Like static routes, policy-based routes must be valid: a destination and gateway are required, and
disconnected (or down) interfaces can’t be used. For policy-based routes, packets must also match all
specified subnets, ToS bits, and port number. So, if you don’t want a setting to be included in the matching
criteria, leave it blank.
Policy routes are maintained in a separate routing table by FortiGate, and have precedence over the regular
routing table.

 Routing
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 interface and gateway, bypassing the routing table, or it stops checking the policy routes, so the
packet will be routed based on the routing table.
Remember, for a policy route to forward traffic out a specific interface, there should be an active route for that
destination using that interface in the routing table. Otherwise the policy route will not work.

 Routing
DO NOT REPRINT
© FORTINET
What happens if you need to route traffic to a public Internet service (such as Dropbox or Apple Store)
through a specific WAN link? Let's say that you have two ISPs and you want to route Netflix traffic through
one ISP and all your other Internet traffic though the other ISP. To achieve this goal, you need to know the
Netflix IP addresses and configure the static route. After that, you need to frequently check that none of the IP
addresses have changed. The Internet service database (ISDB) helps make this type of routing easier and
simpler. ISDB entries are applied to static routes to selectively route traffic though specific WAN interfaces.
Even though they are configured as static routes, ISDB routes are actually policy routes and take precedence
over any other routes in the routing table. As such, ISDB routes are added to the policy routing table.

 Routing
DO NOT REPRINT
© FORTINET
To enable routing configuration for IPv6 addresses using the GUI, you must enable IPv6 in the Feature
Visibility menu. Then, you can create static routes and policy routes with IPv6 addresses. Enabling the IPv6
feature also enables GUI configuration options for IPv6 versions of the dynamic routing protocols.

 Routing
DO NOT REPRINT
© FORTINET

 Routing
DO NOT REPRINT
© FORTINET
Good job! You now understand routing in FortiGate.
Next, you learn about the routing monitor and route attributes.

 Routing
DO NOT REPRINT
© FORTINET

• Interpret the routing table on FortiGate
• Identify how FortiGate decides which routes are activated in the routing table
• Identify how FortiGate chooses the best route using route attributes
By demonstrating competence in understanding the routing monitor and route attributes, you should be able to
interpret the routing table, identify how routes are activated, and identify how FortiGate chooses the best route
using route attributes.

 Routing
DO NOT REPRINT
© FORTINET
The routing table monitor on the FortiGate GUI shows the active routes.
Which routes, besides the static routes, are displayed here?
• Directly connected subnets

• When a subnet is assigned to FortiGate’s interface, a route to the subnet is automatically added with
Connected shown in the Type column. There has to be layer 2 connectivity to the subnets for their
respective routes to be added to the routing table. This means that if an interface is down, or there is no
link established, the route will not be added.
• Dynamic routes
• On larger networks, your FortiGate may receive routes from other routers, through protocols such as
BGP or OSPF. FortiGate will add these routes to the routing table with the respective routing protocol’s
name under the Type column.
Which configured routes aren’t displayed in the routing table monitor?
• Inactive routes
• If an interface is down, or FortiGate does not have layer 2 connectivity to a subnet, that route is
considered inactive, and will not be added to the routing table.
Policy routes are viewed in a separate table. ISDB routes are also added as policy routes in the policy route
monitor.

 Routing
DO NOT REPRINT
© FORTINET
Each of the routes listed in the routing table includes several attributes with associated values.
The Network column lists the destination IP address and subnet mask that will be matched. The Interface
column lists the interface that will be used to deliver the packet.
The Distance, Metric, and Priority attributes are used by FortiGate to make various route selection
decisions. You will learn about each later in this lesson.

 Routing
DO NOT REPRINT
© FORTINET
Distance, or administrative distance, is a number that is used by routers to determine which route is preferred
for a particular destination. If there are two routes to the same destination, the one with the smaller distance is
considered better and used for routing. The routes with higher distances are inactive and not added to the
routing table.
By default, routes learned through the RIP protocol have a higher distance value than routes learned through
the OSPF protocol. OSPF is considered to be more accurate than RIP.
The following values are the default distances on FortiGate:

• 0 - directly connected
• 5 - DHCP gateway
• 20 - external BGP (EBGP) routes
• 200 - internal BGP (IBGP) routes
• 110 - OSPF routes
• 120 - RIP routes
• 10 - static routes

 Routing
DO NOT REPRINT
© FORTINET
The metric attribute is used to determine the best route to a destination when dealing with routes learned
through dynamic routing protocols. If two routes have the same distance, the metric value is used to break the
tie. The route with the lowest metric is chosen for routing.
How the metric value is measured depends on the routing protocol. For example, RIP uses the hop count,
which is the number of routers the packet must pass through to reach the destination. OSPF uses cost, which
is determined by how much bandwidth a link has.

 Routing
DO NOT REPRINT
© FORTINET
When multiple static routes have the same distance value, they are both active in the routing table. So which
route will be used to route matching packets? In this scenario, FortiGate uses the priority value as a tiebreaker
to determine the best route. Routes with lower priority are always preferred.
The priority attribute is only applicable to static routes, and is configured under the Advanced Options on the
GUI. By default, all static routes have a priority of 0.
Priority values are viewed in the static route configuration, and on the routing table on the CLI, which you will
learn later in this lesson. It is not displayed on the GUI routing table.

 Routing
DO NOT REPRINT
© FORTINET

 Routing
DO NOT REPRINT
© FORTINET
Good job! You now understand the routing monitor and route attributes.
Next, you’ll learn about equal cost multipath routing.

 Routing
DO NOT REPRINT
© FORTINET

• Identify the requirements for equal cost multipath routing
• Implement route redundancy and load balancing
By demonstrating competence in ECMP, you should be able to identify the requirements for implementing
ECMP, and implement ECMP load balancing.

 Routing
DO NOT REPRINT
© FORTINET
So far you’ve learned about the different route attributes available for routers to determine the best route to a
destination. So, what happens when two or more routes to the same destination share the same values for all
of the attributes?
If multiple routes to the same destination share the same distance, metric, and priority, they are all considered
the best candidate. If the routes are static, OSPF, or BGP, FortiGate load balances the traffic across all
routes. This is called equal cost multi-path (ECMP).

 Routing
DO NOT REPRINT
© FORTINET
ECMP can load balance traffic using one of these four methods. Sessions can be balanced among equal
routes depending on the source IP address, source and destination IP addresses, route or interface weights,
or interface volume thresholds.
When using the source IP method, all traffic originating from the same source IP is expected to use the same
path. The source-destination IP method works similarly, but it also factors in the destination IP. So, sessions
from a specific source to a specific destination are expected to use the same path.
With the ECMP load balancing method set to weighted, FortiGate distributes sessions with different
destination IPs by generating a random value to determine the route to select. The probability of selecting one
route over another is based on the weight value of each route or interface. Higher weights are more likely to
be selected.
There is an additional method called usage-based (or spillover). In usage-based load balancing, FortiGate
uses a primary route until a traffic volume threshold is reached; after that, it uses the next available route.
If one of the ECMP routes fails and is removed from the routing table, the traffic will be routed over the
remaining routes. There is no specific configuration necessary for route failover.

 Routing
DO NOT REPRINT
© FORTINET
FortiGate uses source-ip-based as the default ECMP method. You can change this setting on the CLI
using the commands shown on this slide.
For spillover-based ECMP, you must configure additional settings at the interface level. For weight-based
ECMP, you must assign weight values to interfaces, or routes. You can do this on the CLI using the
commands shown on this slide.

 Routing
DO NOT REPRINT
© FORTINET
In the scenario shown on this slide, FortiGate has two equal candidate routes for the 10.0.4.0/24 subnet
using port1 and port2 respectively. Using the default source-based ECMP method, FortiGate may use either
route to deliver traffic destined for the 10.0.4.0/24 subnet from User A and User B. If port1 loses
connectivity, FortiGate will automatically use port2 to deliver all traffic destined for the 10.0.4.0/24 subnet.
ECMP allows you to maintain multiple links for the same destination, as well as provide built-in failover. This
can be deployed for any network resources that have high bandwidth demands, and are mission critical.
Employing ECMP for these resources allows you to aggregate the available bandwidth of multiple links, and
load balance traffic across those links.
When using ECMP, you must have the proper firewall policies in place to allow traffic to egress all interfaces
participating in ECMP.
While you can use ECMP to maintain multiple Internet (WAN) connections on FortiGate, it can be more
efficient to use the software-defined WAN (SD-WAN) feature to accomplish this. You can still use ECMP for
internal resources.

 Routing
DO NOT REPRINT
© FORTINET

 Routing
DO NOT REPRINT
© FORTINET
Good job! You now understand ECMP routing.
Next, you will learn about reverse path forwarding.

 Routing
DO NOT REPRINT
© FORTINET

• Identify how FortiGate detects IP spoofing
• Block traffic from spoofed IP addresses
• Differentiate between and implement the different RPF check methods
By demonstrating competence in RPF, you should be able to identify and block IP spoofing attacks in your
network.

 Routing
DO NOT REPRINT
© FORTINET
Packets are sometimes dropped for routing and security reasons. RPF is a mechanism that protects FortiGate
and your network from IP spoofing attacks. It checks if there is a route back to the packet’s source. This check
is run on the first packet of any new session. It is also run after a route change, on the next packet in the
original direction.
There are two RPF methods: loose and strict.

 Routing
DO NOT REPRINT
© FORTINET
In the scenario shown on this slide, incoming Internet traffic arriving at wan1 will be accepted because the
default route is a valid route back to the source.
However, there are two interfaces that will not route some incoming traffic: port1 and wan2. port1 will not
route traffic because the subnet for user C is 10.0.4.0/24. There is no active route for that subnet through
port1. So, traffic coming from 10.0.4.0/24 to port1 will be dropped because it failed the RPF check.
The other interface that will not route traffic is wan2. While wan2 is physically connected to the Internet, the
only IP addresses that are valid as sources or destinations for wan2 are those in the 10.0.2.0/24 subnet.
So, incoming traffic from any other source will not pass the RPF check and will be dropped.

 Routing
DO NOT REPRINT
© FORTINET
So how can you fix this problem?
The first problem is fixed by adding a static route to 10.0.4.0/24 through port1. Now, when FortiGate
runs the RPF check for User C’s packets, it finds an active route to that subnet through port1 and the packet
is accepted.
The second problem is also fixed by adding a static route. In this case, it will be a default route for wan2. This
second default route needs to have the same distance as the default route for wan1. This will ensure that both
routes will be active in the routing table. They both can have different priorities, but they must have the same
distance to be active.
This is an example of when two routes with the same distance, but different priorities, are required. So, one
route will be the best (the one with the lowest priority), but both will be active. The best route will be used for
outbound traffic, but both can receive incoming connections without failing the RPF check.

 Routing
DO NOT REPRINT
© FORTINET
RPF can be either strictly or loosely enforced.
In loose mode, the packet is accepted as long as there is one active route to the source IP through the
incoming interface. It does not have to be the best route, just an active one.
In strict mode, FortiGate checks that the best route to the source IP address is through the incoming interface.
The route not only has to be active (as in the case of loose mode), but it also has to be the best.
RPF checking can be disabled in two ways. If you enable asymmetric routing, it will disable RPF checking
system wide. However this reduces the security of your network greatly. Features such as antivirus, and IPS
become non-effective. So if you need to disable RPF checking, you can do so at the interface level using the
commands shown here.

 Routing
DO NOT REPRINT
© FORTINET
In the example shown on this slide, 10.0.4.1 sends a SYN packet to 10.0.1.2, but spoofs a source IP of
10.0.1.1. This makes the packet appear to be initiated from the internal network behind port1. Loose RPF
allows this traffic because the active route on wan1 is a default route (0.0.0.0/0).
Next, 10.0.1.2 (User B) would send the SYN/ACK packet to the real device with the IP address of
10.0.1.1 (User A).
Since 10.0.1.1 (User A) is not expecting any SYN/ACK packets (because it has not previously sent any
SYN packet to 10.0.1.2), it will reply with an RST (reset) packet.

 Routing
DO NOT REPRINT
© FORTINET
So what happens in the same scenario when strict RPF is used?
Strict RPF drops the SYN packet. Even though the wan1 default route is an active route for the 10.0.4.0/24
subnet, it’s not the best route. The best route is through the port1 interface because it has a lower distance
value. Remember, the default distance value for directly connected routes is 0, which is lower than the default
route’s distance value of 10.
Although strict RPF is more secure, it can cause false positives if you use dynamic routing. Dynamic routes
can change quickly, and they could cause FortiGate to drop legitimate packets each time the preferred route
changes. In general, it is recommended to use loose RPF in combination with firewall policies that block
spoofed traffic, instead of using strict RPF for that purpose.

 Routing
DO NOT REPRINT
© FORTINET

 Routing
DO NOT REPRINT
© FORTINET
Good job! You now understand RPF.
Next, you will learn some routing best practices.

 Routing
DO NOT REPRINT
© FORTINET

• Configure the link health monitor
• Implement route failover
• Apply network design best practices
• Apply static route configuration best practices
• Use the forward traffic logs
By demonstrating competence in routing best practices, you should be able apply them in your own network
and routing designs to maintain an effective and efficient routing configuration.

 Routing
DO NOT REPRINT
© FORTINET
When using ECMP routing, you don’t have to implement anything extra for route failover. Because of the
design of ECMP, route failover happens automatically. How do you implement route failover when you’re not
using ECMP?
Link health monitor is a mechanism for detecting when a router along the path is down. It is often used where
there are redundant routers onsite, such as for dual ISP links. When configured, FortiGate periodically sends
probing signals through one of the gateways to a server that acts as a beacon. The server can be any host
that should normally be reachable through that path. Usually, it’s best to choose a stable server with robust
infrastructure, and to choose the protocol to which the server would normally respond.
If the FortiGate stops receiving a reply from the server, all the routes using that gateway will be removed from
the routing table. Alternatively, you can configure the device to administratively bring down an interface, so all
routes using that interface will be removed. While a monitored route is removed, FortiGate will continue to
send link health monitor signals. As soon as FortiGate receives a reply, it will reactivate the associated routes.
It may be useful to choose a server that is indirectly attached, located one or two hops beyond the FortiGate’s
gateway. This does not exactly test availability of this one gateway, but rather the combination of gateways.
That way, FortiGate will accurately indicate availability of services and subsequent hops.

 Routing
DO NOT REPRINT
© FORTINET
The link health monitor is configured on the CLI.
You must set the egress interface, the IP address of the gateway router, and the IP address and protocol
(http, ping, udp-echo, tcp-echo, or twamp).
You need to enable the update-static-route setting to ensure that FortiGate removes any matching
static route, in the event link health monitor detects an outage. This will allow any secondary route configured
with a higher distance to be activated.
You can configure multiple link health monitors, for example, one for each ISP.

 Routing
DO NOT REPRINT
© FORTINET
In the example shown on this slide, the FortiGate has two ISP connections: ISP1 and ISP2. Within each ISP’s
network there are servers that the FortiGate is probing.
Before failover the wan1 default route is active in the routing table since it has the lower distance. The wan2
default route is configured with a higher distance and, therefore, inactive. The link health monitor probes the
ISP1-Server located within ISP1’s network through the wan1 interface. When the ISP1-Server does not
respond to the probing attempts, FortiGate removes the primary route from the routing table and, because
there is a second default route through wan2, activates it to route traffic to the Internet.
In this dual-ISP scenario, your first reaction might be to implement ECMP routing. After all, ECMP would allow
you to utilize both ISP links at the same time, which increases the available bandwidth for Internet traffic.
However, it may not always be feasible to implement ECMP. Most of the time it is related to cost
considerations—the secondary ISP may be charging based on bandwidth or data usage. This is where you
can use the distance attribute, in conjunction with link health monitoring, to implement route failover.

 Routing
DO NOT REPRINT
© FORTINET
Routing best practices start at the network design phase. One of the biggest challenges with static routing is
figuring out how to handle discontiguous networks. While dynamic routing protocols are better equipped to
handle them, they still create issues with large routing tables and route summarization. In some situations,
you will not be able to handle discontiguous networks with static routing alone, and may need to resort to NAT
to allow traffic.
Another challenge to consider is asymmetric routing. Asymmetric routing is a situation where packets, in the
same session, might flow through different routes to reach the destination. FortiGate, being a stateful firewall,
will drop such packets. So, if multiple paths exist in your network for the same destination, consider using the
distance attribute to ensure only one route is active at a time. You can also consider using ECMP; however,
the effectiveness of this will also depend on whether or not the remote side router is also capable of ECMP, or
some form of session persistence. In other words, the remote side router will also need to send the reply
packets back through the same path.
While FortiGate can be configured to allow asymmetric routing, it is highly discouraged to do so. Enabling
asymmetric routing disables FortiGate’s stateful inspection capability. Antivirus and intrusion prevention will
not be effective since the FortiGate will be unaware of sessions and treat each packet individually. Disable
RPF check at the interface level.

 Routing
DO NOT REPRINT
© FORTINET
If you find yourself creating multiple host routes (/32 subnet mask), investigate whether you can summarize
them to a supernet. Dynamic routing protocols are designed to summarize contiguous networks to keep
routing tables small, reducing the size of routing updates and the time it takes to do a route lookup. You
should employ the same methodology when creating static routes.
When configuring policy routes, treat them as an exception to the routing table. If you find yourself
continuously having to create policy routes, you should re-evaluate your static route configuration to see if you
can make adjustments there first. Remember, policy routes override the routing table. So, the only way to
override a policy route is by configuring another one. If you don’t plan your policy route configuration, it can
quickly become an issue. Also, large policy route tables are difficult to troubleshoot.
Finally, if ECMP routing is not possible with multiple routes, use link health monitor, in conjunction with the
distance attribute, to ensure you have route failover.

 Routing
DO NOT REPRINT
© FORTINET
If you enable the Destination Interface column in the Forward Traffic logs, you can view the egress
interface for traffic passing through your FortiGate. This information can be used to determine which route is
applied to which traffic stream, as well as identify any routing configuration issues.
If your firewall policies do not have any security profiles applied, you should enable logging for all sessions in
your policies; otherwise, FortiGate will not generate any Forward Traffic logs. Use this feature with some
caution, since enabling all sessions logging can generate a lot of logs if the firewall policy is handling a high
volume of traffic. You should enable it when necessary, and disable it immediately afterwards.

 Routing
DO NOT REPRINT
© FORTINET

 Routing
DO NOT REPRINT
© FORTINET
Good job! You now understand some routing best practices.
Next, you learn some routing diagnostics.

 Routing
DO NOT REPRINT
© FORTINET

• View active and inactive routes
• View policy routes on the CLI
• Use the built-in packet capture tools
By demonstrating competence in routing diagnostics, you should be able to determine the root causes of any
routing failures in your network.

 Routing
DO NOT REPRINT
© FORTINET
The CLI command shown here displays all active routes in the routing table. The left-most column indicates
the source for the route.
Route attributes are shown inside square brackets. The first number, in the first pair of attributes, is distance,
which applies to both dynamic and static routes. The second number is metric, which applies to dynamic
routes only.
Static routes can also have priority and weight attributes, which are shown as the last pair of attributes for the
respective route.
This command doesn't show inactive routes. For example, when two static routes to the same destination
subnet have different distances, the one with the lower distance is active. The one with the higher distance is
inactive. So, this command displays only the one with the lowest distance (the active one).

 Routing
DO NOT REPRINT
© FORTINET
If you want to display both the active and the inactive routes, use the CLI command shown here.
In the example shown on this slide, you can see that the command shows one inactive route. The route is
inactive because it has a higher distance than the one below.
Remember, a route will also be inactive if the connected interface is down, or if FortiGate does not have layer
2 connectivity to that subnet.

 Routing
DO NOT REPRINT
© FORTINET
Policy routes, and static routes created using ISDB addresses are not added to the routing table; they are
added to the policy routing table. These routes can be displayed using the CLI command shown here. This
command lists all the active routes in the policy routing table.

 Routing
DO NOT REPRINT
© FORTINET
Packet captures, or sniffers, are one of the most useful sources of information for debugging routing
problems. FortiGate includes a built-in traffic sniffer tool. It can be used to verify the ingress and egress
interfaces of packets as they pass through. The built-in sniffer can be run from either the GUI or the CLI. The
syntax of the CLI command is shown on this slide.
The <interface> is the name of the physical or logical interface. If your account has the access profile
super_admin, you can specify any to capture on all the interfaces. If you’re using the any option, just
remember that the sniffer will not print any interface MAC addresses.
The filters are similar to tcpdump on Linux. You should configure specific filters to ensure you’re only
capturing what you need. You can also specify a <count> value to automatically stop the sniffer after
capturing a certain number of packets. Otherwise the sniffer will continue capturing packets until you manually
stop it using Ctrl + C. The <timestamp> option can be used to print time stamp information. Use a to print
the absolute timestamp, or l (lower-case L) to print the local time-zone based time stamp. Timestamp
information is particularly useful when correlating sniffer output to debug flow messages. You will learn more
about debug flow later in the course.
By default, the sniffer uses the MTU configured on the interface. Using the <frame size> argument you can
specify a length larger or smaller than the interface MTU. If you use the any interface, the sniffer will default to
1600 bytes.

 Routing
DO NOT REPRINT
© FORTINET
The verbosity level specifies how much information you want to display. There are six different levels and this
table shows which ones display the IP headers, packet payload, Ethernet headers, and interface names.
Verbosity level 4 is used to take a quick look at how the traffic is flowing through FortiGate (if packets are
arriving and how FortiGate is routing them out). Level 4 can also be used to easily check if FortiGate is
dropping packets.
Verbosity levels 3 and 6 provide the most output. Both show the IP payloads and Ethernet headers. You can
save the output and export it to a packet capture (pcap) file using a Perl script. The pcap file can then be
opened with a packet analyzer, such as Wireshark, for further investigation. The Perl script that converts the
sniffer output to pcap can be found on the Fortinet Knowledge Base website (kb.fortinet.com).

 Routing
DO NOT REPRINT
© FORTINET
This slide shows two examples of packet capture outputs. The first example captures all traffic to and from
port 443. It uses verbosity 4, so the information is easy to read. It displays one line per packet, containing the
incoming and outgoing interface, IP addresses, port numbers, and type of packet (SYN, SYN/ACK, and so on).
The second example captures all ICMP traffic coming from or going to the host 192.168.1.254. In this
case, the verbosity is 3, which is longer and more difficult to read as it includes the IP payload of the packets.
However, this is one of the two verbosity levels to use (6 being the other one) if you need to export the output
to Wireshark.

 Routing
DO NOT REPRINT
© FORTINET
If your model of FortiGate has internal storage, you can capture packets on the GUI. The options are similar to
those for the CLI. To run a trace, specify a source interface and a filter.
What is the main advantage of using the GUI over the CLI? You download the output in a file format (pcap)
that is ready to be opened using Wireshark, without having to use a conversion script.
Regardless of which method you use (CLI or GUI), packet capture filters should be very specific to make sure
only the relevant packets are captured, and large amounts of data are not being written to the disk.

 Routing
DO NOT REPRINT
© FORTINET

 Routing
DO NOT REPRINT
© FORTINET
Congratulations! You have completed the lesson.
Now you will review the objectives that you covered in this lesson.

 Routing
DO NOT REPRINT
© FORTINET
This lesson covered the following objectives:

• Configure static routing
• Implement policy-based routes
• Control traffic for well-known Internet services
• Interpret the routing table on FortiGate
• Implement ECMP routing
• Block traffic from spoofed IP addresses
• Apply network design and static routing best practices
• Implement route failover
• View active and inactive routes
• Use the built-in sniffer tools
By mastering the objectives covered in this lesson, you have gained the skills and knowledge that you need to
configure, maintain, and troubleshoot the FortiGate routing configuration.

 Software-Defined WAN (SD-WAN)
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about the Software-Defined WAN feature available on FortiGate.

DO NOT REPRINT
© FORTINET

• Introduction to Software-Defined WAN
• SD-WAN status check
• SD-WAN rules
• SD-WAN diagnostics

DO NOT REPRINT
© FORTINET

• Identify use cases for SD-WAN
• Identify the implementation requirements for SD-WAN
• Configure SD-WAN virtual link and load balancing
• Configure static routes and firewall policies for SD-WAN
By demonstrating competence in SD-WAN, you should be able to configure the SD-WAN virtual link and
traffic load balancing to use multiple WAN links effectively on FortiGate.

DO NOT REPRINT
© FORTINET
SD-WAN is a virtual interface consisting of a group of member interfaces that can be connected to different
link types. FortiGate groups all the physical member interfaces into a single virtual interface: the SD-WAN
interface. Using SD-WAN simplifies configuration, because the administrator can configure a single set of
routes and firewall policies and apply them to all member interfaces. There can be only one SD-WAN
interface per VDOM.
One of the main motivators for deploying SD-WAN is effective WAN use, when you are using multiple WAN
links. Effective WAN use is achieved using various load balancing algorithms, such as bandwidth usage,
sessions, or application-aware routing. Another important feature of SD-WAN is link quality measurements.
Using ping or HTTP echo, FortiGate can determine the latency, jitter, or packet loss percentage for each link,
and dynamically select links based on these measurements. This ensures high availability for business critical
applications.

DO NOT REPRINT
© FORTINET
When you configure SD-WAN, you must specify at least two member interfaces and their associated
gateways. You should configure SD-WAN early during the initial setup of a FortiGate because, if an interface
is already referenced by a firewall policy or static route, you cannot use it as a member interface. If you intend
to use an interface as an SD-WAN member, and that interface is being referenced by a firewall policy or static
route, you must delete the associated firewall policy and static route before you can assign that interface as
an SD-WAN member. SD-WAN supports physical interfaces as well VLAN, aggregate, and IPsec interfaces.
When you enable SD-WAN, you must specify the load balancing method.

DO NOT REPRINT
© FORTINET
SD-WAN load balancing uses traffic distribution methods that are similar to those used by equal cost
multipath (ECMP). However, SD-WAN link load balancing includes one more balancing method: volume.
SD-WAN link load balancing uses these methods:
• Source IP: Traffic from the same IP address uses the same link.
• Source-destination IP: Traffic from the same pair of source and destination IP addresses uses the same
link.
• Spillover: This method is similar to the spillover method used by ECMP. A link routes all the traffic until the
volume reaches a threshold, after that, another link is used.
• Sessions: The interface weights determine the proportion of sessions that each link should handle.
Sessions are distributed among the links, based on the interface weights.
• Volume: The interface weights determine the proportion of traffic volume that each link should handle.
Sessions are balanced so that traffic volume is distributed based on the interface weights.

DO NOT REPRINT
© FORTINET
After you have enabled SD-WAN, and configured the member interfaces and the load balancing method, a
logical interface with the name sd-wan is automatically added to the interface list. Next, you must create the
routes and firewall policies using this virtual interface.
You must still configure a default route when implementing SD-WAN. The default route configuration using the
sd-wan interface does not require a gateway address because FortiGate will forward packets to the
appropriate gateway, based on the member interface gateway information.
When using SD-WAN, you do not need to configure multiple firewall policies for individual member interfaces.
Firewall policies created with the sd-wan interface allow traffic to be forwarded through any member interface.

DO NOT REPRINT
© FORTINET
Even though you must configure routes using the sd-wan virtual interface, FortiGate installs individual routes
for the member interfaces in the routing table. These routes share the same attributes (destination address
and subnet, distance, and priority) and are both active. This allows FortiGate to remove individual routes in
the event of an interface outage, and redirect all traffic to the remaining member interfaces, without affecting
the whole SD-WAN load balancing group.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand the SD-WAN feature on FortiGate.
Next, you’ll learn about the SD-WAN status check and link quality measurements.

DO NOT REPRINT
© FORTINET

• Configure SD-WAN status check
• Identify how FortiGate measures link quality
By demonstrating an understanding of SD-WAN status check, you should be able to configure SD-WAN
status check, and identify how FortiGate measures link quality.

DO NOT REPRINT
© FORTINET
For load balancing to be effective, there needs to be a constant monitoring of the health and status of the links
that make up the SD-WAN link. FortiGate can check the status of each SD-WAN member interface. If SD-
WAN status check is configured, FortiGate periodically sends packets to the server through each of the links.
If the number of consecutive packets sent to a link with no reply goes above the Failures before inactive
threshold, that member is removed from the SD-WAN load balancing group.
SD-WAN status checks are used by SD-WAN rules. Depending on how you configure the rule, the status
check can apply to individual member interfaces, or the SD-WAN group as a whole.

DO NOT REPRINT
© FORTINET
SD-WAN status checks also measure the quality of the links connected to each member interface. Three
different criteria are used for this measurement: latency, jitter, and packet loss percentage. These link quality
measurement checks can be used by SD-WAN rules to dynamically route traffic based on the quality of each
member interface. You will learn more about SD-WAN rules later in this lesson.
SD-WAN status check allows FortiGate to dynamically deactivate and activate routes based on link
availability. If status check reports an interface as inactive, the corresponding routes will be removed from the
routing table. If multiple status checks are configured, all need to report an interface as inactive for the route to
be removed.
If you choose to configure only one status check, you should be aware of the risks of false positive events. For
example, if the server you are using in the status check configuration experiences an outage, but your ISP link
is operational, it will cause unnecessary traffic disruption in your network. To reduce false positive events, it is
recommended that you configure multiple status checks with different servers. This ensures that the affected
routes are only removed if multiple servers are unreachable using that interface, which can mean that your
ISP link may be experiencing issues.

DO NOT REPRINT
© FORTINET
The CLI commands for configuring status check provides more options. The tcp-echo, udp-echo, and
twamp options are only available on the CLI. These options provide different methods of measuring round-trip
network performance between any two devices that support them. There are other CLI-only options that are
available only based on the status check protocol you choose. For more information on these options, refer to
the CLI Reference Guide on docs.fortinet.com.
You can also configure the warning and alert thresholds for the latency, jitter, and packet loss quality checks.
These are also not available on the GUI.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand SD-WAN status check.
Next, you’ll learn about SD-WAN rules.

DO NOT REPRINT
© FORTINET

• Identify SD-WAN rule matching criteria
• Configure dynamic link selection based on link quality
By demonstrating competence in SD-WAN rules, you should be able to configure dynamic link selection
based on link quality to ensure high availability for business critical applications.

DO NOT REPRINT
© FORTINET
SD-WAN rules allow you to specify which traffic you want to route through which interface. You can configure
the SD-WAN rules to choose the egress interface based on a link’s latency, jitter, or packet loss percentage.
The rules are evaluated in the same way as firewall policies: from top to bottom, using the first match. The
following parameters can be used to match the traffic:
• Source IP address
• Destination IP address
• Destination port number
• ISDB address objects as destination
• Users or user groups
• Type of service (ToS)
SD-WAN rules offer great flexibility when matching traffic. For example, you can route Netflix traffic from
specific authenticated users through one ISP, while keeping the rest of your Internet traffic through another
ISP.

DO NOT REPRINT
© FORTINET
Similar to ISDB routes, SD-WAN rules function as policy routes. They take precedence over any other routes
in the routing table.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand SD-WAN rules.
Next, you’ll learn about SD-WAN diagnostics.

DO NOT REPRINT
© FORTINET

• Monitor SD-WAN link usage
• Monitor SD-WAN link quality status
• Verify SD-WAN traffic routing
By demonstrating competence in SD-WAN diagnostics, you should be able to maintain an efficient and
effective SD-WAN solution.

DO NOT REPRINT
© FORTINET
You can use the SD-WAN usage monitor to view traffic distribution between the member interfaces, based on
bandwidth or volume.
The Volume view gives a better representation of the sessions being load-balanced across all the member
interfaces; whereas the Bandwidth view shows you how much bandwidth each interface is using as a result
of the sessions passing through them.

DO NOT REPRINT
© FORTINET
Since link quality plays a big role in link selection when using SD-WAN, monitoring the link quality status of
the SD-WAN member interfaces is a good practice. Any prolonged issues with packet loss and latency should
be investigated to ensure your network traffic does not experience outage or degraded performance. Green
arrows indicate interfaces are active in the SD-WAN group. Red arrows indicate that the interface is inactive
for that specific status check.
FortiGate will also generate system event logs when an SD-WAN member interface’s route is removed from
or added to the routing table. Use System Events log menu to investigate the reasons for any route failovers.

DO NOT REPRINT
© FORTINET
You can use the Destination Interface column in the Forward Traffic logs to verify that traffic is egressing
the SD-WAN member interfaces. Alternatively, you can use verbosity levels 4 and 6 to view the egress
interface using the CLI packet capture tool.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Now, you will review the objectives that you covered in this lesson.

DO NOT REPRINT
© FORTINET

• Identify use cases for SD-WAN
• Identify the implementation requirements for SD-WAN
• Configure SD-WAN virtual link and load balancing
• Configure static routes and firewall policies for SD-WAN
• Configure SD-WAN status check
• Identify how FortiGate measures link quality
• Identify SD-WAN rule matching criteria
• Configure dynamic link selection based on link quality
• Monitor SD-WAN link usage
• Monitor SD-WAN link quality status
• Verify SD-WAN traffic routing
By mastering the objectives covered in this lesson, you have gained the skills and knowledge that you need to
configure, maintain, and diagnose your FortiGate’s SD-WAN solution.

 Virtual Domains
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to configure virtual domains (VDOMs) and examine common usage
examples.

 Virtual Domains
DO NOT REPRINT
© FORTINET

• VDOM concepts
• VDOM administrators
• Configuring VDOMs
• Inter-VDOM links
• Best practices and troubleshooting

 Virtual Domains
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to define and describe virtual domains (VDOMs).
By demonstrating competence in Virtual Domains, you will be able to understand the key benefits and usage
cases for Virtual Domains.

 Virtual Domains
DO NOT REPRINT
© FORTINET
What if, more than segmenting your network, you want to subdivide policies and administrators into multiple
security domains?
In that case, you can enable FortiGate VDOMs, which split your physical FortiGate into multiple logical
devices. Each VDOM has independent security policies and routing tables. Also, and by default, traffic from
one VDOM cannot go to a different VDOM. This means that two interfaces in different VDOMs can share the
same IP address, without any overlapping subnet problems.
When you use VDOMs, a single FortiGate appliance becomes a virtual data center of network security, UTM
inspection, and secure communication devices.

 Virtual Domains
DO NOT REPRINT
© FORTINET
There are a few ways you can arrange your VDOMs. In the topology shown in this example, each network
accesses the Internet through its own VDOM.
Notice that there are no inter-VDOM links. So, inter-VDOM traffic is not possible unless it physically leaves the
FortiGate, towards the Internet, and is rerouted back. This topology would be most suitable in a scenario
where multiple customers are sharing a single FortiGate, each in their own VDOM, with physically separated
ISPs.

 Virtual Domains
DO NOT REPRINT
© FORTINET
Like the topology shown in the previous example, each network in this example topology sends traffic through
its VDOM. However, after that, traffic is routed through the To_Internet VDOM. So, Internet-bound traffic
flows through a single pipe in the To_Internet VDOM.
This could be suitable in a scenario where multiple customers are sharing a single FortiGate, each in their
own VDOM. In this case, the Internet-facing VDOM could log and monitor traffic, or provide standard services
like antivirus scanning, or do both.
This topology has inter-VDOM links. VDOMs are linked only with the To_Internet VDOM, but not with each
other. If VDOM1 needs to communicate with VDOM3, this traffic would need to be routed through the
To_Internet VDOM through IP routing decisions, and is subject to all firewall policies.
Inspection could be done by either the Internet-facing or originating VDOM, depending on your requirements.
Alternatively, you could split inspection so that some scans occur in the Internet-facing VDOM–ensuring a
common security baseline–while other more intensive scans occur in the originating VDOM.

 Virtual Domains
DO NOT REPRINT
© FORTINET
In this example topology, traffic again flows through a single pipe in the To_Internet VDOM towards the
Internet. Traffic between VDOMs doesn’t need to leave the FortiGate.
However, now inter-VDOM traffic doesn’t need to flow through the To_Internet VDOM. Inter-VDOM links
between VDOMs allow more direct communication.
Similar to the previous example topology, inspection can be done by either the To_Internet or originating
VDOM, depending on your requirements.
Due to the number of inter-VDOM links, this example is the most complex, requiring the most routes and
firewall policies. Troubleshooting meshed VDOMs can also be more time consuming.
However, meshed VDOMs also provide the most flexibility. For large businesses, inter-VDOM communication
may be required. Also, inter-VDOM traffic performance may be better due to a shorter processing path which
bypasses intermediate VDOMs.

 Virtual Domains
DO NOT REPRINT
© FORTINET
Up until now, we’ve discussed traffic passing through FortiGate, from one VDOM to another. What about
traffic originating from FortiGate?
Some system daemons, such as NTP and FortiGuard updates, generate traffic coming from FortiGate. One,
and only one, of the VDOMs on a FortiGate device is assigned the role of the management VDOM. Traffic
coming from FortiGate to those global services originates from the management VDOM. By default, the
VDOM root acts as the management VDOM, but you can manually reassign this task to a different VDOM.
Similar to a FortiGate without VDOMs enabled, the administrative VDOM should have outgoing Internet
access. Otherwise, features such as scheduled FortiGuard updates will fail.
It is important to note that the management VDOM designation is solely for traffic originated by FortiGate,
such as FortiGuard updates, and has no effect on traffic passing through FortiGate. As such, the management
function can be performed by any designated VDOM.

 Virtual Domains
DO NOT REPRINT
© FORTINET

 Virtual Domains
DO NOT REPRINT
© FORTINET
Good job! You now understand some basic concepts about VDOMs.
Next, you’ll learn about VDOM administrators.

 Virtual Domains
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to create administrative accounts with access that is limited
to one or more VDOMs.
By demonstrating competence in VDOM Administrators, you will be able to understand the differences
between the various levels and types of VDOM Administrators.

 Virtual Domains
DO NOT REPRINT
© FORTINET
If you want to grant access to all VDOMs and global settings, select super_admin as the access profile when
configuring the administrator account. Similar to the account named admin, this account can configure all
VDOMs.

 Virtual Domains
DO NOT REPRINT
© FORTINET
In most cases, you’ll start by creating one administrator account per VDOM. That administrator will be chiefly
responsible for that domain, including that VDOM’s configuration backups. In larger organizations, you may
need to make multiple VDOM administrators. Multiple administrators can be assigned to each VDOM. You
can subdivide permissions using access profiles, in order to follow best practices for segregation of duties.
The converse is also possible. If required, you can assign an administrator to multiple VDOMs.

 Virtual Domains
DO NOT REPRINT
© FORTINET
To create new administrator accounts and assign them to a VDOM, click Global > System > Administrators.

 Virtual Domains
DO NOT REPRINT
© FORTINET

 Virtual Domains
DO NOT REPRINT
© FORTINET
Good job! You now understand VDOM administrators.
Next, you’ll learn how to configure VDOMs.

 Virtual Domains
DO NOT REPRINT
© FORTINET
After completing this section, you will be able to configure VDOMs to split a FortiGate into multiple virtual
devices.
By demonstrating competence in configuring VDOMs, you will be able to effectively implement VDOMs in
your FortiGate.

 Virtual Domains
DO NOT REPRINT
© FORTINET
To enable VDOMs from the GUI, click System > Settings. Then, click Enable in the Virtual Domain section.
Alternatively, to enable VDOMs when you are logged in to the CLI, enter the following command:
config system global
set vdom-admin enable
end
This won’t reboot your FortiGate, but it will log out all active admin sessions. Enabling VDOMs restructures
both the GUI and CLI, which you will see when you log in again. This also does not affect any traffic passing
through FortiGate.

 Virtual Domains
DO NOT REPRINT
© FORTINET
After enabling VDOMs, by default, only one VDOM exists: the root VDOM. It’s the default management
VDOM.
You need to add a VDOM for each of your security domains. If you’re an MSSP, for example, you might add
one VDOM for each client company. If you are an enterprise business, you might add one VDOM for each
division of your company.
The inspection mode (proxy-based or flow-based) is a per VDOM setting that defines how traffic is inspected.
In a VDOM in proxy mode, FortiGate inspects the traffic acting as an implicit TCP proxy. The original client-to-
server TCP session is actually split into two TCP sessions: one from the client to the FortiGate, and another
one from the FortiGate to the server.
In a VDOM in flow-based mode, the traffic is scanned on a TCP flow basis as it passes through FortiGate.
There is no implicit TCP proxy involved.
The operation mode is also a per-VDOM setting. You can combine transparent mode VDOMs with NAT mode
VDOMs in the same physical FortiGate.

 Virtual Domains
DO NOT REPRINT
© FORTINET
After adding the additional VDOMs, you can proceed to specify which interfaces belong to each VDOM. Each
interface (physical or VLAN) can belong to only one VDOM.
Interfaces can be moved from one VDOM to another, provided they have no references associated with them,
for example, firewall policies.

 Virtual Domains
DO NOT REPRINT
© FORTINET
Global resource limits are an example of global settings. The firmware on your FortiGate, and some settings,
such as system time, apply to the entire appliance–they are not specific to each VDOM.

 Virtual Domains
DO NOT REPRINT
© FORTINET
Most settings, however, can be configured to be different for each VDOM. Some examples are: firewall
policies, firewall objects, static routes, protection profiles, and so on.

 Virtual Domains
DO NOT REPRINT
© FORTINET
If you log in as most administrator accounts, you will enter your VDOM automatically.
But, if you are logged in as the account named admin, you aren’t assigned to any VDOM. As such, you have
access to all VDOMs
To enter a VDOM on the GUI, select the VDOM from the drop-down list at the top of the page.
Inside each VDOM, the submenu should be familiar; it is essentially the same navigation menu that you had
before you enabled VDOMs. However, the global settings are moved to the Global menu.

 Virtual Domains
DO NOT REPRINT
© FORTINET
To access the global configuration settings from the CLI, you must enter config global to enter into the
global context. After that, you can execute global commands and change global configuration settings.
To access per-VDOM configuration settings from the CLI, you must enter config vdom, then enter edit
followed by the VDOM name. From the VDOM context, you can execute VDOM-specific commands and
change per-VDOM configuration settings. It is important to note that VDOM names are case sensitive. If you
enter the name using the incorrect case, FortiGate will create a new VDOM.
Regardless of which context you are in (global or VDOM), you can use the sudo keyword to execute
diagnostics commands in a context different than your current one. This allows you, for example, to execute
global and per-VDOM commands without switching back and forth between the global and per-VDOM
context.

 Virtual Domains
DO NOT REPRINT
© FORTINET

 Virtual Domains
DO NOT REPRINT
© FORTINET
Good job! You now understand how to configure VDOMs.
Next, you’ll learn about inter-VDOM links.

 Virtual Domains
DO NOT REPRINT
© FORTINET
After completing this section, you will be able to route traffic between VDOMs using inter-VDOM links.
By demonstrating competence in Inter-VDOM Links, you will be able to effectively and efficiently route traffic
between VDOMs within a FortiGate.

 Virtual Domains
DO NOT REPRINT
© FORTINET
To review, each VDOM behaves like it is on a separate FortiGate appliance. With separate FortiGates, you
would normally connect a network cable and configure routing and policies between them. But VDOMs are on
the same FortiGate. So how should you route traffic between them?
The solution is inter-VDOM links. Inter-VDOM links are a type of virtual interface that route traffic between
VDOMs. This removes the need to loop a physical cable between two VDOMs.
In the case of a NAT-to-NAT inter-VDOM link, both sides of the link must be on the same IP subnet, because
you are creating a point-to-point network connection.
Note that similar to using inter-VLAN routing, Layer 3 must be involved–you cannot create an inter-VDOM link
between Layer 2 transparent mode VDOMs. At least one of the VDOMs must be operating in NAT mode.
This, among other benefits, prevents potential Layer 2 loops.

 Virtual Domains
DO NOT REPRINT
© FORTINET
When creating inter-VDOM links, you’ll need to create the virtual interfaces. You must also create the
appropriate firewall policies in each VDOM, just as you would if the traffic were arriving on a network cable.
Otherwise, FortiGate will block it.
Additionally, routes are required to properly route packets between two VDOMs.

 Virtual Domains
DO NOT REPRINT
© FORTINET
In the GUI, you create a network interface in the Global settings. To create the virtual interface, click Create
New, then select VDOM Link.

 Virtual Domains
DO NOT REPRINT
© FORTINET
FortiGates with NP4 or NP6 processors include inter-VDOM links that can be used to accelerate inter-VDOM
link traffic. For a FortiGate with two NP4 or NP6 processors there are two accelerated inter-VDOM links, each
with two interfaces:
• npu0_vlink:
• npu0_vlink0
• npu0_vlink1
• npu1_vlink:
• npu1_vlink0
• npu1_vlink1
These interfaces are visible from the GUI and CLI. By default the interfaces in each inter-VDOM link are
assigned to the root VDOM. To use these interfaces to accelerate inter-VDOM link traffic, assign each
interface in the pair to the VDOMs that you want to offload traffic between. For example, if you have added a
VDOM named New-VDOM to a FortiGate with NP4 processors, you can click System > Network >
Interfaces and edit the npu0-vlink1 interface and set the VDOM to New-VDOM. This results in an
accelerated inter-VDOM link between root and New-VDOM.

 Virtual Domains
DO NOT REPRINT
© FORTINET

 Virtual Domains
DO NOT REPRINT
© FORTINET
Good job! You now understand inter-VDOM Links.
Next, you’ll learn some VDOM best practices and troubleshooting.

 Virtual Domains
DO NOT REPRINT
© FORTINET
After completing this section, you will be able to limit the resources allocated globally and per VDOM.
By demonstrating competence in VDOM best practices and troubleshooting, you will be able to avoid, identify,
and solve common VDOM issues.

 Virtual Domains
DO NOT REPRINT
© FORTINET
Remember, VDOMs are only a logical separation–each VDOM shares physical resources with the others.
Unlike FortiGate-VM, VDOMs are not allocated and balanced with weighted vCPU cores, vRAM, and other
virtualized hardware.
To fine-tune performance, you can configure resource limits for each feature–IPsec tunnels, address objects,
and so on–at the global level and at each VDOM level. This controls the ratio of each VDOM’s system
resource usage to the total available resources.

 Virtual Domains
DO NOT REPRINT
© FORTINET
For example, on this FortiGate, the hardware is powerful enough to handle up to 2000 IPsec VPN tunnels.
The FortiGate is configured with three VDOMs.
VDOM1 and VDOM2 don’t use IPsec VPN tunnels often. So, they are allowed to have up to 50 tunnels each.
VDOM3, however, uses VPN extensively. Therefore, this FortiGate will be configured to allow VDOM3 to have
up to 1900 tunnels. Additionally, 1000 of those tunnels will be guaranteed.
Configure your FortiGate with global limits for critical features such as sessions, policies, and others. Then,
configure each VDOM with its own quotas and minimums, within the global limits.

 Virtual Domains
DO NOT REPRINT
© FORTINET
On the GUI, you can click Global > System > VDOM to see the VDOM monitor. It displays the CPU and
memory usage for each VDOM.

 Virtual Domains
DO NOT REPRINT
© FORTINET
Best practice dictates that you should usually avoid unnecessary security holes. Do not provide super_admin
access if possible. Instead, restrict each administrator to their relevant domain. That way, they cannot
accidentally or maliciously impact other VDOMs, and any damage or mistakes will be limited in scope.

 Virtual Domains
DO NOT REPRINT
© FORTINET
With VDOMs configured, administrators have an extra layer of permissions and may have problems
accessing the desired information.
If an administrator cannot gain access, check the following:
• Confirm the admininstrator’s VDOM: Each administrator account, other than the super_admin account, is
tied to one or more specific VDOMs. That administrator is not able to access any other VDOM. It may be
possible they are trying to access the wrong VDOM (one that they do not have permissions for).
• Confirm the VDOM’s interfaces: An administrator can access their VDOM only through interfaces that are
assigned to that VDOM. If interfaces on that VDOM are disabled or unavailable, there will be no method of
accessing that VDOM by its local administrator. The super_admin will be required to either bring up the
interfaces, fix the interfaces, or move another interface to that VDOM to restore access.
• Confirm the VDOMs admin access: As with all FortiGate devices, administration access on the VDOM’s
interfaces must be enabled for that VDOM’s administrators to gain access. For example, if SSH is not
enabled, that is not available to administrators. To enable admin access, the super_admin clicks Global
> Network > Interfaces, and enables admin access for the interface in question.
• Confirm trusted host and IP: If trusted hosts are enabled on the administrator account, ensure the user is
connecting from the correct, specified host address, and that no intermediate devices are performing NAT
functions on the connection.

 Virtual Domains
DO NOT REPRINT
© FORTINET
Besides ping and traceroute, there are additional tools for troubleshooting your VDOM configurations. The
primary tools for VDOM troubleshooting include packet sniffing and debugging the packet flow.
• Perform a sniffer trace: When troubleshooting networks, it helps to look inside the headers of packets to
determine if they are traveling along the expected route. Packet sniffing can also be called a network tap,
packet capture, or logic analyzing. Sniffer also indicates what traffic is entering or leaving the egress and
ingress interfaces in all VDOMS. This makes it extremely useful for troubleshooting inter-VDOM routing
issues.
• Debug the packet flow: Traffic should come in to, and leave the VDOM. If you have determined that
network traffic is not entering and leaving the VDOM as expected, debug the packet flow. Debugging can
only be performed using CLI commands. This tool provides more granular details for help in
troubleshooting inter-VDOM traffic, as it gives details of routing selection, NAT, and policy selection.

 Virtual Domains
DO NOT REPRINT
© FORTINET

 Virtual Domains
DO NOT REPRINT
© FORTINET
Congratulations! You have completed this lesson.

 Virtual Domains
DO NOT REPRINT
© FORTINET

• Define and describe VDOMs
• Create administrative accounts with the access limited to one or more VDOMs
• Configure VDOMs to split a FortiGate into multiple virtual devices
• Route traffic between VDOMs
• Limit the resources allocated globally and per VDOM

 Layer 2 Switching
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to use transparent operation mode and layer 2 switching on FortiGate.

DO NOT REPRINT
© FORTINET

• Virtual local area networks (VLANs)
• Transparent operation mode
• Virtual wire pairing
• Software switch
• Spanning Tree Protocol (STP)
• Best practices

DO NOT REPRINT
© FORTINET
• Configure VLANs to logically divide a layer 2 network into multiple broadcast domains
• Describe VLANs and VLAN tagging
By demonstrating competence in understanding and configuring VLANs, you will be able to effectively divide
your network into smaller, logical segments.

DO NOT REPRINT
© FORTINET
VLANs split your physical LAN into multiple logical LANs. In NAT operation mode, each VLAN forms a
separate broadcast domain. Multiple VLANs can coexist in the same physical interface, provided they have
different VLAN IDs. In this way, a physical interface is split into two or more logical interfaces. A tag is added
to each Ethernet frame to identify the VLAN to which it belongs.

DO NOT REPRINT
© FORTINET
This slide shows an Ethernet frame. The frame contains the destination and source MAC addresses, the type,
the data payload, and a CRC code, to confirm that it is not corrupted.
In the case of Ethernet frames with VLAN tagging, according to the 802.1q standard, four more bytes are
inserted after the MAC addresses. They contain an ID number that identifies the VLAN.
An OSI layer 2 device, such as a switch, can add or remove these tags from Ethernet frames, but it cannot
change them.
A layer 3 device, such as a router or a FortiGate, can change the VLAN tag before proceeding to route the
packet. In this way, they can route traffic between VLANs.

DO NOT REPRINT
© FORTINET
When operating in NAT mode, FortiGate operates as an OSI layer 3 router in its most basic configuration. In
this mode, a VLAN is an interface on the device. VLAN tags may be added on egress, removed on ingress, or
rewritten based on a routing decision. FortiGate does not add VLAN tags on ingress (this is the responsibility
of a previous device).

DO NOT REPRINT
© FORTINET
In this example of NAT operation mode, a host on VLAN 100 sends a frame to a host on VLAN 300. Switch A
receives the frame on the untagged VLAN 100 interface. After that, it adds the VLAN 100 tag on the tagged
trunk link between switch A and FortiGate.
FortiGate receives the frame on the VLAN 100 interface. Then, it routes the traffic from VLAN 100 to VLAN
300, rewriting the VLAN ID to VLAN 300 in the process.
Switch B receives the frame on the VLAN trunk interface and removes the VLAN tag before forwarding the
frame to its destination on the untagged VLAN 300 interface.

DO NOT REPRINT
© FORTINET
To create a VLAN using the GUI, click Create New, select Interface, and then, in the Type drop-down list,
select VLAN. You must specify the VLAN ID and the physical interface to which the VLAN will be bound.
Frames that belong to interfaces of that type are always tagged. On the other hand, frames sent or received
by the physical interface segment are never tagged. They belong to what is called the native VLAN (VLAN ID
0).
Note: In a multi-VDOM environment, the physical interface and its VLAN sub-interface can be in separate
VDOMs.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand VLANs.
Next, you’ll learn about transparent mode.

DO NOT REPRINT
© FORTINET

• Configure FortiGate interfaces to operate as a layer 2 switch
• Configure a virtual domain (VDOM) to operate in transparent mode
By demonstrating competence in understanding and configuring transparent operation mode, you will
understand a key component of implementing layer 2 switching on FortiGate.

DO NOT REPRINT
© FORTINET
Traditional IPv4 firewalls and NAT mode FortiGate devices handle traffic the same way that routers do. Each
interface must be in different subnets and each subnet forms a different broadcast domain. FortiGate routes
IP packets based on the IP header information, overwriting the source MAC address. So, if a client sends a
packet to a server connected to a different FortiGate interface, the packet will arrive at the server with a
FortiGate MAC address, instead of the client’s MAC address.
In transparent operation mode, FortiGate forwards frames without changing the MAC addresses. When the
client receives a packet from a server connected to a different FortiGate interface, the frame contains the
server’s real MAC address—FortiGate doesn’t rewrite the MAC header. FortiGate is a layer 2 bridge or
switch. So, the interfaces do not have IP addresses and, by default, all belong to the same broadcast domain.
This means that you can install a transparent mode FortiGate in a customer network without having to change
the customer’s IP address plan. Some customers, especially large organizations, don’t want to reconfigure
thousands of devices to define a new internal network that is separate from their external network.

DO NOT REPRINT
© FORTINET
This slide shows an example of NAT operation mode.
FortiGate has three connected ports, each with separate IP subnets. All interfaces on FortiGate have IP
addresses, and, in this case, NAT translates between networks. Firewall policies allow traffic to flow between
networks.
FortiGate handles packets according to their routes. In most cases, routes are based on the destination IP
address (at layer 3 of the OSI model).
Clients on each subnet send frames that are destined for a FortiGate MAC address—not the real MAC
address of the server.

DO NOT REPRINT
© FORTINET
This slide shows an example of transparent operation mode. Firewall policies scan, then allow or block traffic.
But there are differences.
Notice that the physical interfaces on FortiGate have no IP addresses. Therefore, FortiGate won’t respond to
ARP requests. However, there are some exceptions. For example, when changing to transparent operation
mode, you must specify a management IP address in order to receive connections from your network
administrators and send log messages, SNMP traps, alert email, and so on. This IP address is not assigned
to a specific interface. It is assigned to the VDOM settings. The management IP address has no effect on
traffic passing through FortiGate.
By default, a transparent mode FortiGate won’t perform NAT. Also, clients will send frames destined directly
to the real router or server MAC address.

DO NOT REPRINT
© FORTINET
A transparent mode FortiGate acts as a transparent bridge. What does that mean?
It means that FortiGate has a MAC address table that contains, among other things, the interface that must be
used to reach each MAC address. FortiGate populates this table with information taken from the source MAC
address of each frame.
FortiGate, as a transparent switch, splits the network into multiple collision domains, reducing the traffic in the
network and improving the response time.

DO NOT REPRINT
© FORTINET
By default, in transparent operation mode each VDOM forms a separate forward domain; however, interfaces
do not. How does this affect the network?
Until you change the initial VDOM configuration, all interfaces, regardless of their VLAN ID, are part of the
same broadcast domain. FortiGate will broadcast from every interface in the VDOM in order to find any
unknown destination MAC address. On large networks, this could generate massive broadcast traffic and
overwhelming replies—a broadcast storm.

DO NOT REPRINT
© FORTINET
This slide illustrates a problem—a broadcast with all the interfaces on the forward domain 0 (default). One
device sends an ARP request. It reaches FortiGate through one of the interfaces in the VDOM.
Because all interfaces belong to the same forward domain, FortiGate rebroadcasts to all the other interfaces,
even to interfaces that belong to different VLANs. This generates unnecessary traffic. After that, the ARP reply
will still arrive on only one interface, and FortiGate will learn that the MAC is on that interface.

DO NOT REPRINT
© FORTINET
As you learned earlier in this lesson, forward domains are like broadcast domains.
The example on this slide shows the same network as before, but different forward domain IDs are assigned
to each VLAN.
Traffic arriving on one interface is only broadcast to interfaces that are in the same forward domain ID.

DO NOT REPRINT
© FORTINET
This debug command lists the MAC address table in a VDOM operating in transparent mode. The table
contains the outbound interfaces to reach each learned MAC address.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand transparent mode.
Next, you’ll learn about virtual wire pairing.

DO NOT REPRINT
© FORTINET
After completing this section, you will be able to segment the layer 2 network into multiple broadcast domains.
By demonstrating competence in using virtual wire pairing, you will understand another way to create
broadcast domains and be able to create interface pairs operating like transparent mode in a NAT VDOM.

DO NOT REPRINT
© FORTINET
You can use virtual wire pairing when only two physical interfaces need to be connected to the same
broadcast domain. The most frequently seen example of this is FortiGate connected between the internal
network and the ISP’s router.
When you configure virtual wire pairing, two ports are logically bound or linked, acting like a filtered cable or
pipe. All the traffic that arrived at one port is forwarded to the other port. This prevents issues related to
broadcast storms or MAC address flapping.
You can create more than one port pair on FortiGate.

DO NOT REPRINT
© FORTINET
This slide shows an example of two virtual wire pairs used on FortiGate in transparent mode.
This FortiGate has four ports, each connected to different physical locations. But traffic is not allowed to flow
between all four locations. Virtual wire pairing allows traffic only between ports in the same pair: between
port1 and port2, and between port3 and wan1.
So, in this example, the network on port3 can reach the Internet through wan1. However, the networks on
port2 and port1 can’t reach the Internet. They can only reach each other.

DO NOT REPRINT
© FORTINET
This slide shows an example of a virtual wire pair on FortiGate operating in NAT mode. In this example, IP
packets ingressing interfaces wan1 and internal are routed using the IP header information. Those two
interfaces have different IP addresses, and each one forms a separate broadcast domain.
The case of interfaces wan2 and dmz are different. Because these interfaces are configured as a virtual port
pair, they don't have assigned IP addresses, and they form one single broadcast domain. Observe the IP
addresses for the server and the router connected to wan2. They must both belong to the same subnet.
So, virtual wire pairing offers a way to mix NAT mode functionalities with some transparent mode
functionalities in the same VDOM.
This scenario is most commonly used as a segmentation firewall. This configuration allows for integrating
FortiGate into an existing network where the web server is on a public IP address. It prevents the need to use
a virtual IP, and provides isolation from the rest of network. It also allows immediate integration of FortiGate
into an established network and provides a migration path to the FortiGate infrastructure.

DO NOT REPRINT
© FORTINET
When you create a virtual wire pair, you must select two physical interfaces—no more, no less.
After selecting the two interfaces, you create the virtual wire pair policies that inspect the traffic crossing the
virtual wire pair. The Wildcard VLAN setting specifies how those policies are applied to the different VLANs
whose traffic flows between the pair:
• If Wildcard VLAN is enabled, the virtual wire pair policies are applied equally to the physical interfaces
and VLANs.
• If Wildcard VLAN is disabled, the virtual wire pair policies are applied only to the physical interfaces.
Traffic with any VLAN tag is denied.

DO NOT REPRINT
© FORTINET
The firewall policies for virtual wire pairing are configured under a different menu item. This menu item is
displayed when you have created at least one virtual wire pair. Remember that you will need separate firewall
policies for traffic flow in each direction on the virtual wire pair.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand virtual wire pairing.
Next, you’ll learn about the software switch function.

DO NOT REPRINT
© FORTINET
After completing this section, you should be able to configure a software switch. A software switch adds a
virtual layer 2 switch to the FortiGate configuration.
By demonstrating competence in using the software switch feature, you will understand how to group multiple
physical and wireless interfaces into a single virtual interface.

DO NOT REPRINT
© FORTINET
A software switch groups multiple interfaces to form a virtual switch, which acts as a traditional layer 2 switch.
This means that all switch interfaces are part of the same broadcast domain.

DO NOT REPRINT
© FORTINET
Each software switch has a virtual interface associated with it. Its IP address is shared by all the physical
switch interfaces and member SSIDs. You use this virtual interface in the firewall policies and routing
configuration.

DO NOT REPRINT
© FORTINET
In this example, the administrator grouped a wireless interface with port1 and port2 to form a software
switch. These three interfaces are part of the same broadcast domain. All the devices connected to the switch
interfaces belong to the same IP subnet: 192.168.1.0/24. This allows FortiGate to forward broadcast traffic
from the wireless clients to port1 and port2.
The software switch interface itself has an IP address, which is also in the same subnet: 192.168.1.0/24. This
is the default gateway IP address for all the devices connected to the software switch.
The server 10.0.1.1 is connected to an interface (dmz) that is not part of the software switch. So, it belongs to
a different broadcast domain and IP subnet.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand the software switch function.
Next, you’ll learn about spanning tree protocol (STP).

DO NOT REPRINT
© FORTINET
After completing this section, you should be able to install FortiGate in networks running spanning tree
protocol (STP).
By demonstrating competence in STP, you will understand how to install FortiGate in a network running STP,
and how to avoid common STP-related issues.

DO NOT REPRINT
© FORTINET
Whenever possible, network designers try to provide redundancy in their networks. The larger the network,
the more critical the need for redundancy. However, redundancy introduce its own issues.
When an Ethernet switch receives a frame, it forwards that frame to all ports in the same broadcast domain,
except the port it received the frame on. If there is a redundant path in the network, the frame will be
broadcast over both links. This would create what is called a broadcast storm, which will eventually lead to a
complete collapse of the network as the frame gets rebroadcast over and over again, across each port.

DO NOT REPRINT
© FORTINET
To prevent broadcast storms, you can use STP.
STP works by first electing one switch in the broadcast domain to serve as the root bridge. The switches then
begin exchanging special packets called bridge protocol data units or BPDUs. These BPDUs provide each
switch with information about its neighbors and its neighbors interfaces. When all paths are known, the
switches identify potential loops and designate a root port, based on lowest forwarding cost, that will be the
primary path. The other ports, which could result in a loop, are blocked.
Because the BPDUs are sent every two seconds, the switches are able to detect any network outages, and
unblock ports as needed to restore an alternate path around the outage.
By default, FortiGate does not participate in STP learning, or forward BPDUs. But you can enable it. (You
must still restrict broadcast domains so that they are not overwhelmingly large.)

DO NOT REPRINT
© FORTINET
To enable FortiGate to participate in the STP tree, use the config system stp command on the CLI.
Note: This is only supported on models that have physical switch interfaces, such as FortiGate 30D, 60D,
60E, and 90D.

DO NOT REPRINT
© FORTINET
For interfaces that are not physical switch interfaces, you can either forward or block STP BPDUs.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand STP.
Next, you’ll learn some best practices to employ when using layer 2 switching.

DO NOT REPRINT
© FORTINET
After completing this section, you will be able to use best practices when working with layer 2 switching on
FortiGate.
By demonstrating competence in using best practices for layer 2 switching on FortiGate, you will understand
how to identify, resolve, and prevent common layer 2 issues.

DO NOT REPRINT
© FORTINET
When you implement a FortiGate device that has layer 2 features, these are some best practices you should
follow to avoid preventable issues within your network.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

• Configure VLANs to logically divide a layer 2 network into multiple broadcast domains
• Describe VLANs and VLAN tagging
• Configure FortiGate interfaces to operate as a layer 2 switch
• Configure a VDOM to operate in transparent mode
• Segment the layer 2 network into multiple broadcast domains
• Configure a software switch
• Install FortiGate in networks running STP
• Understand best practices for using layer 2 switching on FortiGate

 Site-to-Site IPsec VPN
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to set up a site-to-site IPsec VPN.
In today’s IT infrastructure, VPNs are frequently used to join private corporate networks across the Internet.
IPsec is an RFC standard. So, whether your network contains only FortiGate devices, or a combination of
FortiGate devices and devices from other vendors, the principles of applying IPsec are essentially the same.

DO NOT REPRINT
© FORTINET
In this lesson, we will examine the following topics:

• VPN topologies
• Site-to-site VPN manual configuration

DO NOT REPRINT
© FORTINET
After completing this lesson, you will be able to select an appropriate VPN topology.
By demonstrating competence in VPN topologies, you will able to choose appropriate VPN topology for your
network environment.

DO NOT REPRINT
© FORTINET
First, you’ll review the fundamentals of IPsec.
IPsec is a suite of protocols that is used for authenticating and encrypting traffic between two peers. The three
most used protocols in the suite are the following:
• Internet Key Exchange (IKE), which does the handshake, tunnel maintenance, and disconnection
• Encapsulation Security Payload (ESP), which ensures data integrity and encryption
• Authentication Header (AH), which offers only data integrity—not encryption.
FortiGate uses only ESP to transport the packet payload. AH is not used by FortiGate.
Now, you’ll review the fundamentals of IKE.
IKE uses port UDP 500 (and, if NAT-T is enabled in a NAT scenario, UDP port 4500).
IKE establishes an IPsec VPN tunnel. FortiGate uses the tunnel to negotiate with the peer and determine the
security association (SA). The SA defines the authentication, keys, and settings that will be used 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. Each IPsec SA negotiated during phase 2 is direction specific. So, in two-way traffic,
there are two SAs per phase 2.
For phase 1, there are two possible negotiation modes that can be used: main mode and aggressive mode.
Phase 2 uses only one negotiation mode: quick mode.

DO NOT REPRINT
© FORTINET
Site-to-site VPN is also know as point-to-point VPN. Site-to-site VPNs are the simplest type of VPN. In site-to-
site, two peers communicate directly.
Site-to-site VPN allows transparent communication between two networks that are located at different offices.

DO NOT REPRINT
© FORTINET
One point-to-multipoint topology variation is called hub-and-spoke. The name hub-and-spoke describes how
all clients connect through a central hub, similar to how spokes connect to hubs on wheels.
In this example, 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 VPN configuration and firewall policies are easily managed. System
requirements are also minimal for the branch office FortiGate devices, because each needs to maintain only
one tunnel—two SAs. In this example, four tunnels—eight SAs—are required in the hub.
One disadvantage is that communications between branch offices through HQ will be slower than with a direct
connection. This is especially true if your HQ is physically distant, like it can be for some global companies.
For example, if your HQ is in Brazil and you have offices in Japan and Germany, latency can be significant.
Also, if the FortiGate at HQ fails, VPN failure will be company-wide. In the example shown on this slide, the
FortiGate at HQ must be much more powerful because it handles four tunnels simultaneously—eight SAs.
So what would a topology look like if some, or all, branch offices could bypass HQ and connect directly to
each other?

DO NOT REPRINT
© FORTINET
This slide shows VPNs in a mesh topology. Two variations of mesh topology exist.
Full mesh connects every location to every other location.
Like the previous hub-and-spoke example, the example shown on this slide contains five locations. To fully
interconnect, every FortiGate device requires four VPN tunnels—eight SAs—to connect to the other FortiGate
devices. So, in total, 20 tunnels are required. That is three more tunnels per FortiGate than was required in
the hub-and-spoke example. If this example was expanded to six locations, 30 VPNs would be required. If it
was expanded to seven locations, 42 would be required, and so on.
This topology causes less latency and requires much less HQ bandwidth than hub-and-spoke. Its
disadvantage? Every spoke FortiGate must 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 is more complex than in hub-and-spoke. Routing, especially, may require extensive planning.
Generally, with the more locations you have, hub-and-spoke will be cheaper, but slower, than a mesh
topology. Mesh will place less strain on the central location, and be more fault-tolerant, but it will also be more
expensive.

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.

DO NOT REPRINT
© FORTINET
Each VPN topology has its advantages and disadvantages.
Auto discovery VPN (ADVPN) is a FortiGate feature that achieves the benefits of a full-mesh topology with the
easier configuration and scalability benefits of hub-and-spoke and partial-mesh topologies.
First, you add the VPN configurations for building either a hub-and-spoke or a partial-mesh topology to the
FortiGate devices. Then, you enable ADVPN on the VPNs. ADVPN dynamically negotiates tunnels between
spokes (without having them preconfigured) to get the benefits of a full-mesh topology.
ADVPN requires a dynamic routing protocol running over the IPsec tunnels so that spokes can learn the
routes to other spokes, after the dynamic VPNs negotiate.

DO NOT REPRINT
© FORTINET
This slide shows an example of how ADVPN works. An administrator configures IPsec VPNs on multiple
FortiGate devices to form a VPN partial-mesh topology. There are two hubs. Hub 1 has three spokes. Hub 2
has two spokes.
The administrator also enables ADVPN in all the VPNs. To do that, the administrator must enable the
following IPsec phase 1 settings:
• auto-discovery-receiver in the spokes' VPNs
• auto-discovery-sender in the hubs' VPNs that go to each spoke
• auto-discovery-forwarded in the hubs' VPNs that go to every other hub
The dynamic tunnels between spokes are created on demand. Say that a user in Boston sends traffic to
London; the direct tunnel between Boston and London has not been negotiated yet. So, the first packets from
Boston to London are routed through Hub 1 and Hub 2. When Hub 1 receives those packets, it notices that
ADVPN is enabled in all the VPNs through to London. So, Hub 1 sends an IKE message to Boston informing
Boston that it can try to negotiate a direct connection to London. On receipt of this IKE message, Boston
creates a FortiOS-specific IKE information message which contains its public IP address, its local subnet, the
desired destination subnet (London's subnet), and an auto-generated PSK to use for securing the direct tunnel
(alternatively digital certificate authentication can be used instead). This IKE message is sent to London
through Hub 1 and Hub 2. When London receives the IKE message from Boston, it stores the PSK and replies
with another IKE information message that contains London's public IP address. After the reply arrives at
Boston, the dynamic tunnel is negotiated between both peers. The negotiation will succeed because London
is expecting a connection attempt from Boston's public IP address.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand VPN topologies.
Next, you’ll learn the steps for configuring site-to-site VPN.

DO NOT REPRINT
© FORTINET
After completing this section, you will be able to:

• Deploy a site-to-site VPN between two FortiGate devices
• Compare route-based configuration mode to policy-based configuration mode
• Configure redundant VPNs between two FortiGate devices
• Understand hardware offloading requirements
By demonstrating competence in VPN configuration, you will have better understanding of deploying a VPN
between sites.

DO NOT REPRINT
© FORTINET
Because encapsulation styles and other settings vary, and any mismatches cause VPNs to fail, FortiGate
includes VPN templates to overcome this problem.
You can use these templates to simplify VPN setup—reducing the guesswork about what settings are
compatible between devices.
The VPN wizard uses these templates to make IPsec VPN creation easier for administrators.

DO NOT REPRINT
© FORTINET
The VPN wizard comprises a three-step process. Administrators provide the VPN name, remote IP,
authentication method, interfaces, and subnets.
After you have completed the VPN wizard, it automatically creates many of the required objects:
• Addresses and address groups
• Static routes
• Policies
• Phase 1 and phase 2 settings

DO NOT REPRINT
© FORTINET
On FortiGate, there are two ways to manually configure an IPsec VPN. These configurations define how to
create the firewall policies for VPN traffic: route-based configuration and policy-based configuration.
How do you know when to use policy-based or route-based?
Generally, try to use route-based because it offers more flexibility and control.
Transparent mode supports only policy-based VPNs.

DO NOT REPRINT
© FORTINET
How are the two configuration modes different?
• In a route-based configuration, FortiGate automatically adds a virtual interface with the VPN name. Two
firewall policies with the Action set to ACCEPT are usually required: one for sessions originating on the
local network, and another for sessions originating on the remote network. You also need to route the VPN
traffic to the virtual network interface. (Usually, you’ll use static routes.) This is the type of VPN
configuration created by the VPN wizard.
• In a policy-based configuration, only one firewall policy with the action IPsec is usually required. The policy
is bidirectional. By default, the GUI hides the policy-based configuration settings.
Both sides of your VPN don’t need to be configured to use the same mode. You can configure one peer as
route-based and the other as policy-based. But the phase 1 and phase 2 settings must match.
If FortiGate is operating in transparent mode, then only policy-based VPN will be used. To achieve full
redundancy between VPNs, route-based VPN is used.

DO NOT REPRINT
© FORTINET
If you are configuring a custom VPN, you can start by using the wizard. Click Custom (no template).
Configure the WAN IP address for the remote FortiGate device, and indicate which network interface on this
local FortiGate is the gateway that leads to it. FortiGate will use this to connect to the other end.
If your peers use pre-shared keys for the initial (IKE) authentication, both peers must be configured with the
same pre-shared key. For phase 1, choose which encryption and authentication to propose, and so on. They
must match too. If peers can’t agree on IKE security, even phase 1 won’t be established.
If you need detailed control of your VPN, such as for IKE version 2, you can still configure it manually.

DO NOT REPRINT
© FORTINET
After phase 1 is complete, phase 2 begins. This sets up the ESP tunnels that will be used for actual data
transfer. For each subnet on each end of the VPN, you can specify different levels of ESP security. For
example, connections to the Finance LAN might need larger key sizes and stronger authentication. To do this,
configure multiple phase 2 entries. For simplicity, in the example shown on this slide, we show only one phase
2: the Local Address is the LAN, and the Remote Address is the remote LAN.
Remember that if traffic doesn’t match the quick mode selectors of any phase 2 SA, the IPsec engine will drop
the packet. Usually, it’s more intuitive to filter traffic with firewall policies. So, if you don’t want to use quick
mode selector filtering, you can just create one phase 2 with the quick mode selectors set to 0.0.0.0/0.

DO NOT REPRINT
© FORTINET
If you use the wizard, it creates routes and policies suitable for a route-based VPN.
However, what if you have, for example, a FortiGate in transparent mode? Transparent mode supports only
policy-based VPNs, which cannot be created with the wizard (the wizard creates only route-based VPNs).
Remember, first, you must enable the GUI to show policy-based IPsec options. Configure your phases as
before, then create a policy. When policy-based VPN settings are visible, an additional firewall policy with the
Action setting is available. Choose IPsec. Then choose the policy-based VPN to use.

DO NOT REPRINT
© FORTINET
With a route-based VPN, firewall policies are different.
• Usually, there are two policies, not one.

• The interface doesn’t match a WAN interface; it matches the virtual interface, which, in this example, is
named ToRemote.
The VPN wizard is the easiest way to make these policies. If you used the wizard, you can skip this step.
But, if you want to manually set up a VPN, use the settings shown on this slide as examples.

DO NOT REPRINT
© FORTINET
In route-based VPNs, you also need to route VPN traffic destined for the remote LAN to the IPsec interface. If
you used the wizard, this was created for you automatically.
To do this manually, usually you’ll add a static route.
You usually do not need to do this step when configuring a policy-based VPN because traffic that does not
belong to any internal subnet is routed through the default gateway, which uses the WAN interface.

DO NOT REPRINT
© FORTINET
On the GUI, there is a tool that you can use to monitor the status of your IPsec VPNs. Using this tool, you can
see how much traffic has passed through each tunnel. You can also start and stop individual tunnels, and get
additional details.
If the tunnel is up, a green arrow is displayed next to its name. If it is down or not in use, then a red arrow is
displayed.

DO NOT REPRINT
© FORTINET
The hub-and-spoke topology is inherently not fault-tolerant: if something fails, then all VPN tunnels might
close. How can you make your hub-and-spoke or point-to-point VPN more resilient?
Provide a second ISP connection to your site and configure two route-based VPNs. If the primary 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.
• SD-WAN feature can also be used for VPN redundancy.

DO NOT REPRINT
© FORTINET
So, how do you configure a partially or fully redundant VPN?
First, create one route-based phase 1 for each path—one phase 1 for the primary VPN and one for the
backup VPN. Enable dead peer detection (DPD) on both ends. DPD is a method that IPsec gateways use to
detect when the VPN tunnel to its peer is down.
Second, create at least one phase 2 definition for each phase 1.
Third, because these are route-based VPNs, you must add at least one static route for each VPN. Routes for
the primary VPN must have a smaller distance (or smaller 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 the backup VPNs.

DO NOT REPRINT
© FORTINET
On some FortiGate models, you can offload the encryption and decryption of IPsec traffic to hardware. The
supported algorithms depend on the model and type of processor on the unit that is offloading the encryption
and decryption.
By default, hardware offloading is enabled for the supported algorithms. This slide shows the commands you
can use to disable hardware offloading per tunnel, if necessary.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand site-to-site VPN configuration.
Next, you’ll learn best practices and troubleshooting for site-to-site IPsec VPNs.

DO NOT REPRINT
© FORTINET

• Use best practices to deploy site-to-site IPsec VPNs
• Verify the offload of IPsec VPN
• Troubleshoot common site-to-site IPsec VPN problems
By demonstrating competence in knowing best practices and troubleshooting techniques, you will be able to
apply best practices for IPsec VPN deployment and use basic troubleshooting techniques when working with
IPsec VPNs.

DO NOT REPRINT
© FORTINET
Most IPsec VPN issues occur when you are creating tunnels between FortiGate and a third-party device.
Unlike FortiGate, some vendors don’t support quick mode selectors that are 0.0.0.0/0, or that use subnets of
different sizes. So, those vendor devices require a different SA (and a different phase 2) for each pair of local
and remote protected subnets. In these cases, FortiGate configuration might be complicated and time
consuming, because administrators need to create several different phase 2s.
One alternative is to use the command set mesh-selector-type subnet when configuring phase 1.
When you use this command, FortiGate automatically creates phase 2 on demand. This can simplify
FortiGate configuration considerably.

DO NOT REPRINT
© FORTINET
To verify if IPsec traffic is offloaded, use the following CLI command: diagnose vpn tunnel list.
This command shows the status and statistics for each VPN tunnel. If the output contains a line that contains
npu_flag, the tunnel is being offloaded for hardware acceleration.
Remember, you must get initial packets from both directions, before checking the npu_flag field. Otherwise,
it is expected to be 0/0—initially.

DO NOT REPRINT
© FORTINET
What do you do if, after creating a tunnel, it does not come up?
When troubleshooting a tunnel that does not negotiate, look for setting mismatches first. Most connection
failures are caused by misconfiguration.
If you do not see any configuration mismatches, run the IKE real-time debug. The output of this command is
extensive. It shows the phase 1 and phase 2 negotiations step-by-step. If the negotiation fails, the IKE real-
time debug shows messages that can guide you toward a resolution to the problem.
To enable and use IKE real-time debug
1. Create a filter using the following command:

diagnose vpn ike log-filter dst-addr4 <IPsec peer's public IP address>
2. Enable the debug using the following commands:
diagnose debug application ike -1
diagnose debug enable
3. Try to open the tunnel while the debug is running, and capture all the output.
4. After you have captured the output, stop the debug using the following commands:
diagnose debug reset
diagnose debug disable.
Keeping a real-time debug running on the background of a FortiGate for a long time is not recommended.

DO NOT REPRINT
© FORTINET
This slide shows some output for a successful phase 1 negotiation using main mode.
The first line shows the arrival of an IPsec packet from the IP address 172.20.187.114. The third line
indicates that the peer is using main mode.
A bit later, the debug shows that FortiGate accepted the SA proposal from the remote peer. It displays the
name of the phase 1 that matches the proposal. In this case, it’s the name Remote.
FortiGate replies to the first main mode packet. Then, the second main mode packet arrives.
FortiGate replies again, and the third main mode packet is received.
After finishing the negotiation, the output displays messages that indicate that the key exchange was
successful and the IKE SA was established.

DO NOT REPRINT
© FORTINET
This slide shows some output from a phase 2 negotiation. The full output is much longer than this. The slide
only shows a sample of some parts of that output.
The first line announces the arrival of the first quick mode packet.
The second line shows the quick mode selector proposed by the remote peer. In this case, it's 0.0.0.0/0 for
both the source and destination.
Several lines below, the debug displays the quick mode selector that was successfully negotiated between
both peers.
Finally, the last two lines show that the tunnel is up and the IPsec SAs are established.
If there were any problem in the negotiation of either the phase 1 or phase 2, the output would show an error
message.

DO NOT REPRINT
© FORTINET
This slide shows a summary of the most common problems and solutions.
If the tunnel is not coming up, use the IKE real-time debug. You will usually see one of the error messages
listed in this slide in the output.
If the tunnel is bouncing, you will usually see the message DPD packets lost in the output. This indicates
that the problem might be on the ISP side.
If the tunnel is up, but traffic does not go through, use the debug flow. It could indicate that:
• Packets are being dropped at either the local or remote gateway.
• Packets are not being routed properly.
• Packets do not match the quick mode selectors, so they are being dropped.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

• Reviewed IPsec and IKE
• Choose an appropriate VPN topology
• Compare route-based configuration mode to policy-based configuration mode
• Deploy a site-to-site VPN configuration between two FortiGate devices
• Understand hardware offloading requirements
• Configure redundant VPNs between two FortiGate devices
• Use best practices to deploy site-to-site IPsec VPNs
• Verify the offload of IPsec VPN
• Troubleshoot common site-to-site IPsec VPN problems

 Fortinet Single Sign-On (FSSO)
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about Fortinet single sign-on (FSSO). When you use this feature, your users don’t
need to log on each time they access a different network resource.

DO NOT REPRINT
© FORTINET

• FSSO Function and Deployment
• FSSO With Active Directory
• NTLM Authentication
• FSSO Settings
• Troubleshooting

DO NOT REPRINT
© FORTINET

• Define single sign-on (SSO) and Fortinet single sign-on (FSSO)
• Understand FSSO deployment and configuration
By demonstrating competence in understanding SSO concepts, you will be able to more effectively
understand FSSO methods.

DO NOT REPRINT
© FORTINET
SSO is a process that allows users to be automatically logged in to every application after being identified,
regardless of platform, technology, and domain.
FSSO is a software agent that enables FortiGate to identify network users for security policies or for VPN
access, in advanced deployments with FortiAuthenticator, without asking for their username and password.
When a user logs in to a directory service, the FSSO agent sends FortiGate the username, the IP address,
and the list of groups that the user belongs to. FortiGate uses this information to maintain a local database of
usernames, IP addresses, and group mappings.
Because the domain controller authenticates users, FortiGate does not perform authentication. When the user
tries to access network resources, FortiGate selects the appropriate security policy for the destination. If the
user belongs to one of the permitted user groups, the connection is allowed.
FSSO is typically used with directory service networks such as Windows Active Directory or Novell eDirectory.

DO NOT REPRINT
© FORTINET
How you deploy and configure FSSO depends on the server that provides your directory services.
FSSO for Windows Active Directory (AD) uses a collector agent. Domain controller (DC) agents may also be
required, depending on the collector agent working mode. There are two working modes that monitor user
sign-on activities in Windows: DC agent mode and polling mode. FortiGate also offers a polling mode that
does not require a collector agent, which is intended for simple networks with a minimal number of users.
There is another kind of DC agent that is used exclusively for Citrix and terminal services environments:
terminal server (TS) agents. TS agents require the Windows Active Directory collector agent or
FortiAuthenticator to collect and send the logon events to FortiGate.
The eDirectory agent is installed on a Novell network to monitor user sign-ons and send the required
information to FortiGate. It functions much like the collector agent on a Windows AD domain controller. The
agent can obtain information from the Novell eDirectory using either the Novell API or LDAP.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand basic concepts about the function of FSSO and how it is deployed.
Next, you’ll learn about user logon events in Windows Active Directory using FSSO.

DO NOT REPRINT
© FORTINET

• Detect user logon events in Windows AD using FSSO
• Identify FSSO modes for Windows AD
By demonstrating competence in understanding the different ways, you can configure FSSO for Windows AD,
you will be able to better design the architecture of your SSO system.

DO NOT REPRINT
© FORTINET
DC agent mode is considered the recommended mode for FSSO.
DC agent mode requires:
• One DC agent installed on each Windows DC

If you have multiple DCs, this means that you need multiple DC agents. DC agents monitor and forward
user logon events to the collector agents.
• A collector agent, which is another FSSO component

The collector agent is installed on a Windows server that is a member of the domain you are trying to
monitor. It consolidates events received from the DC agents, then forwards them to FortiGate. The
collector agent is responsible for group verification, workstation checks, and FortiGate updates of logon
records. The FSSO collector agent can send domain local security group, organizational units (OUs), and
global security group information to FortiGate devices. It can also be customized for DNS lookups.

DO NOT REPRINT
© FORTINET
(slide contains animation)
This slide shows the process of information between DC agents, the collector agent, and a FortiGate
configured for FSSO authentication.
1. When users authenticate with the DC, they provide their credentials.
2. The DC agent sees the logon event, and forwards it to the collector agent.
3. The collector agent aggregates all logon events and forwards that information to FortiGate. The
information sent by the collector agent contains the user name, host name, IP address, and user group(s).
The collector agent communicates with FortiGate over TCP port 8000 (default) and it listens on UDP port
8002 (default) for updates from the DC agents. The ports are customizable.
4. Once the collector agent forwards the user logon information, FortiGate knows who the user is, their IP
address, and some of the AD groups that they are a member of. When a user tries to access the Internet,
FortiGate compares the source IP address to its list of active FSSO users. Because the user in this case
has already logged in to the domain, and FortiGate already has their information, FortiGate will not prompt
the user to authenticate again. Rather it will simply allow or deny the traffic based on the matching firewall
policy.

DO NOT REPRINT
© FORTINET
Polling mode can be collector agent-based or agentless.
First, you’ll look at the collector agent-based polling mode. Like DC agent mode, collector agent-based mode
requires a collector agent to be installed on a Windows server, but it doesn’t require DC agents to be installed
on each DC. In collector agent-based polling mode, the collector agent must be more powerful than the
collector agent in DC agent mode, and it also generates unnecessary traffic when there have been no logon
events.
In Windows Event Log Polling, the most common deployed polling mode, the collector agent uses the SMB
(TCP port 445) protocol to periodically request event logs from the domain controllers. Other methods may
gather information differently, but once the logon is received by the collector agent, the collector agent parses
the data and builds the user logon database, which consists of usernames, workstation names/IP, and user
group memberships. This information is then ready to be sent to FortiGate.

DO NOT REPRINT
© FORTINET
As previously stated, collector agent-based polling mode has three methods (or options) for collecting logon
information:
• NetAPI: Polls temporary sessions created on the DC when a user logs in or logs off and calls the
NetSessionEnum function on Windows. It’s faster than the WinSec and WMI methods; however, it can
miss some logon events if a DC is under heavy system load. This is because sessions can be quickly
created and purged from RAM, before the agent has a chance to poll and notify FortiGate.
• WinSecLog: Polls all the security event logs from the DC. It doesn’t miss any logon events that have been
recorded by the DC because events are not normally deleted from the logs. There can be some delay in
FortiGate receiving events if the network is large and, therefore, writing to the logs is slow. It also requires
that the audit success of specific event IDs is recorded in the Windows security logs. For a full list of
supported event IDs, visit the Fortinet knowledge base site (http://kb.fortinet.com).
• WMI: A Windows API that gets system information from a Windows server. The DC returns all requested
logon events. The collector agent is a WMI client and sends WMI queries for user logon events to the DC,
which, in this case, is a WMI server. The collector agent doesn’t need to search security event logs on the
DC for user logon events; instead, the DC returns all requested logon events. This reduces network load
between the collector agent and DC.

DO NOT REPRINT
© FORTINET
This slide shows an example of FSSO using the collector agent-based polling mode. This example includes a
DC, a collector agent, and FortiGate, but the DC doesn’t have the dcagent (or, alternatively, dcagent.dll)
installed.
1. The user authenticates with the DC, providing their credentials.
2. The collector agent periodically (every few seconds) polls TCP port 445 of each DC directly, to ask if
anyone has logged in.
3. The collector agent sends logon information to FortiGate over TCP port 8000. This is the same
information that is sent in DC agent mode.
4. When user traffic arrives at FortiGate, FortiGate already knows which users are at which IP addresses,
and no repeated authentication is required.

DO NOT REPRINT
© FORTINET
You can deploy FSSO without installing an agent. FortiGate polls the DCs directly, instead of receiving logon
information indirectly from a collector agent.
Because FortiGate collects all of the data itself, agentless polling mode requires greater system resources,
and it doesn’t scale as easily.
Agentless polling mode operates in a similar way to WinSecLog, but only with two event IDs: 4768 and 4769.
Because there’s no collector agent, FortiGate uses the SMB protocol to read the event viewer logs from the
DCs.
In agentless polling mode, FortiGate acts as a collector. It is responsible for polling on top of its normal FSSO
tasks but does not have all the extra features, such as workstation checks, that are available with the external
collector agent.

DO NOT REPRINT
© FORTINET
This slide shows how communication is processed without agents. (There is no collector agent or DC agent.)
1. FortiGate polls the DC’s TCP port 445 to collect user logon events.
2. After the user authenticates with the DC, FortiGate registers the logon event during its next poll, obtaining
the following information: the user name, the host name, and the IP address, and then querying for their
user group(s).
3. When the user sends traffic, FortiGate already knows whose traffic it is receiving; therefore, the user does
not need to authenticate.

DO NOT REPRINT
© FORTINET
This table summarizes the main differences between DC agent mode and polling mode.
DC agent mode is more complex. It requires not only a collector agent, but also a DC agent for each
monitored domain controller. However, it is also more scalable, because the work of capturing logons is done
by the DC agents who pass their information directly to the collector.
In polling mode, the collector needs to query every domain controller, every few seconds. So, with each DC
that is added, the number of queries grows. If you want to add a second collector agent for redundancy in
polling mode, both collector agents need to query every DC individually.
In DC agent mode, the DC agent just has to collect the log once, and send a copy of the necessary
information to all the collector agents. In comparison, if you use polling mode, some logon events might be
missed or delayed, depending on the polling option used.

DO NOT REPRINT
© FORTINET
Regardless of the collector method you choose, some FSSO requirements for your AD network are the same:
• Microsoft Windows logon events have the workstation name and username, but not the workstation IP
address. When the collector agent receives a logon event, it will query a DNS server to resolve the IP
address of the workstation. So, FSSO requires that you have your own DNS server. If a workstation IP
address changes, DNS records must be updated immediately in order for the collector agent to be aware
of the change and report them to FortiGate.
• For full feature functionality, collector agents need connectivity with all workstations. Since a monitored
event log is not generated on logoff, the collector agent (depending on the FSSO mode) must use a
different method to verify whether users are still logged in. So, each user workstation is polled to see if
users are still there.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand how FortiGate detects logon events in Windows Active Directory (AD) using
FSSO.
Next, you’ll learn about how NT LAN manager (NTLM) works and interacts with FSSO for a web-initiated
logon.

DO NOT REPRINT
© FORTINET

• Define what NT LAN manager (NTLM) authentication is and how it is used
• Describe how NTLM works with simple and multiple domains
• Describe the interaction between FSSO and NTLM authentication
By demonstrating competence in understanding NTLM authentication and its interaction with FSSO, you will
be able to configure a transparent web-initiated logon session with NTLM authentication.

DO NOT REPRINT
© FORTINET
In an AD environment, FSSO can also work with NTLM, which is a suite of Microsoft security protocols that
provides authentication, integrity, and confidentiality to users.
NTLM authentication does not require DC agents, but it is not fully invisible to users; users must enter their
credentials during NTLM negotiation. NTLM authentication is a Microsoft-proprietary solution, so it can be
implemented only in a Windows network.
NTLM is most often used when users authenticate against DCs that, for some reason, can’t be monitored by
the collector agent, or when there are communication problems between the collector agent and one or more
of the DCs’ agents. In other words, NTLM authentication is best used as a backup to FSSO.
Notice that FortiGate cannot do NTLM authentication on its own. FortiGate needs to pass the user-entered
credentials back to a collector agent for verification. The collector agent will, in turn, respond to FortiGate with
the appropriate user's groups if the authentication is successful.

DO NOT REPRINT
© FORTINET
This slide shows how messages are processed during NTLM authentication in a simple domain configuration.
1. When both FSSO and NTLM are enabled, NTLM is used as a fallback for FSSO. When FortiGate
receives traffic from an IP address that doesn’t exist in the FSSO user list, NTLM is triggered.
2. FortiGate replies with an NTLM challenge, requesting credentials.
3. The user’s browser sends the requested credentials.
4. FortiGate receives the user’s credentials, then authenticates them with the collector agent over TCP port
8000. The FortiGate also receives the names of the groups that the user belongs to.
5. If the credentials are correct, FortiGate authorizes access for the user.

DO NOT REPRINT
© FORTINET
Unlike full FSSO, NTLM authentication is not transparent to users. In most browsers, and by default in Internet
Explorer, users must enter their credentials whenever the browser receives an NTLM authentication
challenge.
However, Internet Explorer can be configured to automatically send the user’s credentials each time it
receives an NTLM challenge. To do this, in the Internet Options dialog, click Custom level. Then, in the
Settings dialog, scroll to User Authentication Logon and select Automatic logon with current user name
and password.

DO NOT REPRINT
© FORTINET
In a multiple domain environment for NTLM, it’s important to have a trust relationship between the domains.
When multiple domains exist in an AD forest, a trust relationship is automatically created, so only one DC
agent is required on one of the domain controllers. But, when multiple domains are not in an AD forest, you
have two options:
• Create a trust relationship between the domains through AD settings
• Install one DC agent on each domain, then use security policies for network access
If you decide to install one DC agent on each domain, the DC agent sends logon information to the collector
agent. This process works as follows:
1. The user logs in to their local DC.

2. The DC agent sends the user logon event information to the collector agent.
3. The user attempts to access the Internet.
4. FortiGate verifies that the user is authenticated by contacting the collector agent for the logon information.
5. If the user is properly authenticated, FortiGate allows them to access to the Internet.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand how to use FSSO with NTLM authentication.
Next, you’ll lean how to configure FSSO settings.

DO NOT REPRINT
© FORTINET

• Configure SSO settings on FortiGate
• Install FSSO agents
• Configure the Fortinet collector agent
By demonstrating competence in configuring the FSSO settings on FortiGate and installing and configuring
the FSSO agents, you will be able to implement FSSO within your network.

DO NOT REPRINT
© FORTINET
FortiGate FSSO configuration is straightforward.
If FortiGate is acting as a collector for agentless polling mode, you must select Poll Active Directory Server
and configure the IP addresses and AD administrator credentials for each DC.
FortiGate uses LDAP to query AD to retrieve user group information. For this to happen, the LDAP server
must be added to the Poll Active Directory Server configuration.

DO NOT REPRINT
© FORTINET
If you have collector agents, either using the DC agent mode or the collector agent-based polling mode, you
must select Fortinet Single-Sign-On Agent and configure the IP address and password for each collector
agent.
The FSSO collector agent can access Windows AD in one of two modes:
• Standard: Group Filters are created on the collector agent. FortiGate can be set to Standard mode, and
the collector agent can still use Advanced mode to access nested groups.
• Advanced: Group Filters are created directly on FortiGate, using the LDAP server. If FortiGate is set to
Advanced mode, the collector agent must also be set to Advanced mode, otherwise the collector agent
will not recognize the group filter sent by FortiGate and will not pass down any user logons.

DO NOT REPRINT
© FORTINET
The FSSO agents are available on the Fortinet Support website. There you will find the following:
• The DC agent
• The collector agent for Microsoft servers: FSSO_Setup,
• The collector agent for Novell directories: FSSO_Setup_edirectory
• The terminal server agent (tsagent) installer for Citrix and terminal servers: TSAgent_Setup.
Also, for each agent, there are two versions: the executable (.exe) and Microsoft Installer (.msi).
Notice that you do not need to match the FSSO version with your exact FortiGate firmware version. When
installing FSSO, grab the latest collector agent for your major release. You do however, need to match the
dcagent version to the collector agent version.

DO NOT REPRINT
© FORTINET
After you’ve downloaded the collector agent, run the installation process as Administrator and follow these
steps in the installation wizard:
1. Read and accept the license agreement.
2. Optionally, change the installation location. The default folder is named FSAE (Fortinet Server
Authentication Extension).
3. Enter the user name. By default, the agent uses the name of the currently running account; however, you
can change it using the format: DomainName\UserName.
4. Alternatively, configure your collector agent for monitoring, NTLM authentication, and directory access.
These options are also customizable after installation. Although the default is Standard mode, when
doing new FSSO setups it is always best practice to install in Advanced mode. We will look at some of
the advantages later in this lesson.
5. If you want to use DC agent mode, ensure that Launch DC Agent Install Wizard is selected. This will
automatically start the DC agent installation.

DO NOT REPRINT
© FORTINET
If you have just installed the collector agent and you selected Launch DC Agent Install Wizard, the
installation process for domain controller agent automatically starts.
1. Enter the IP address for the collector agent. Optionally, you can customize the listening port, if the default
value is already used by another service.
2. Select the domains to monitor. If any of your required domains are not listed, cancel the wizard and set up
the proper trusted relationship with the domain controller. Then, run the wizard again. Note that this could
also be a result of using account without all the necessary permissions.
3. Optionally, select users that you do not want to monitor; these users' logon events will not be recorded by
the collector and therefore will not be passed to FortiGate. While these users are still able to generate
logon events to the domain, when they are detected by the collector agent, they are discarded so as to not
interfere with the logged on user. This is especially useful in environments with a centrally managed
antivirus solution, or a scheduled backup service that uses an AD account to start. These accounts can
create logon events for the collector agent that overwrite existing user logons. This may result in
FortiGate applying the incorrect policies and profiles based on the overriding account. The option to
ignore users can be also customized after installation is complete.
4. Optionally, clear the check boxes of domain controllers that you don’t want to install the DC Agent on.
Remember, for DC agent mode FSSO, at least one domain controller must have the DC agent installed.
Remember that installing the dcagent requires a reboot of the DC before it will start gathering logon
events. You can add or remove the dcagent to DCs at any time after the installation is complete.
5. Select DC Agent Mode as the working mode. If you select Polling Mode the DC agent will not be
installed.
Finally, the wizard requests a system reboot.

DO NOT REPRINT
© FORTINET
On the FSSO agent configuration GUI, you can configure settings such as:
• The listening port for the communication with the DC agents (UDP)
• The listening port for the communication with FortiGate (TCP)
• NTLM authentication support
• Password authentication between the collector agent and FortiGate
• Timers

DO NOT REPRINT
© FORTINET
The FSSO collector agent allows you to configure a FortiGate group filter, which actively controls what user
logon information is sent to each FortiGate. So, you can define which groups the collector agent passes to
individual FortiGate devices.
Monitoring the entire group list in a large AD structure is highly inefficient, and a waste of resources. Most
FSSO deployments need group segmentation (at least four or five groups), with the intention of assigning
varying levels of security profile configurations to the different groups, using identity-based policies.
Group filters also help to limit the traffic sent to FortiGate. The maximum number of Windows AD user groups
allowed on a FortiGate depends on the model. Low-end FortiGate models support 256 Windows AD
user groups. Mid-range and high-end models can support more groups. This is per VDOM, if VDOMs are
enabled on FortiGate.
Filtering can be done on FortiGate instead of the collector agent but only if the collector agent is operating in
advanced mode. In this case, the collector agent uses the list of groups you selected on FortiGate as
its group filter for that device.
The filter list is initially empty. At a minimum, you should at least create a default filter that applies to all
FortiGate devices without a defined filter.
Note that if you change the AD access mode from Standard to Advanced or Advanced to Standard, you will
need to recreate the filters because they vary depending on the mode.

DO NOT REPRINT
© FORTINET
The FSSO collector agent ignores any logon events that match the Ignore User List entries. Therefore, these
logon events are not recorded by the collector agent nor are they reported to FortiGate.
It is a good practice to add all network service accounts to the Ignore User List. Service accounts tend to
overwrite user logon events, and create issues with identity-based policy matching.
You can add users to the Ignore Users List in the following ways:
• Manually enter the username.
• Click Add Users and choose the users you do not want to monitor.
• Click Add by OU and select an OU from the directory tree.

DO NOT REPRINT
© FORTINET
The FSSO collector agent timers play an important role in ensuring the proper operation of FSSO.
Now you’ll take a look at each one and how they work.
• Workstation verify interval. This setting controls when the collector agent connects to individual
workstations on port 139 (or port 445), and uses the remote registry service to verify if a user is still logged
on to the same station. It changes the status of the user under Show logon User, to not verified when it
cannot connect to the workstation. If it does connect, it verifies the user and the status remains OK. To
facilitate this verification process, the remote registry service should be set to auto start on all domain
member PCs.
• Dead entry timeout interval. This setting applies only to entries with an unverified status. When an entry
is not verified, the collector starts this timer. It’s used to age out the entry. When the timer expires, the
logon is removed from the collector. From FortiGate’s perspective, there is no difference between entries
that are OK and entries that are not verified. Both are considered valid.
• IP address change verify interval. This setting checks the IP addresses of logged in users and updates
the FortiGate when a user’s IP addresses change. This timer is especially important in DHCP or dynamic
environments to prevent users from being locked out if they change IP addresses. The domain's DNS
server should be accurate; if the DNS server does not update the affected records promptly, the collector
agent's IP information will be inaccurate.
• Cache user group lookup result. This setting caches the user group membership for a defined period of
time. It is not updated, even if the user changes group membership in AD.

DO NOT REPRINT
© FORTINET
Another important FSSO setting is the AD access mode. You can set the AD access mode by clicking Set
Directory Access Information. The AD access mode specifies how the collector agent accesses and
collects the user and user group information. There are two modes that can be used to access AD user
information: Standard and Advanced.
The main difference between modes is the naming convention used:

• Standard mode uses the Windows convention, NetBios: Domain\Username, while
• Advanced mode uses the LDAP convention: CN=User, OU=Name, DC=Domain.
Also, advanced mode supports nested or inherited groups; that is, users can be members of subgroups that
belong to monitored parent groups. Additionally, in advanced mode, FortiGate can apply protection profiles to
individual users, user groups, and organizational units (OUs).
In comparison, in standard mode, protection profiles can only be applied to user groups, not individual users.
In advanced mode, you can configure FortiGate as an LDAP client and configure the group filters on the
FortiGate. You can also configure group filters on the collector agent.
If the LDAP on the collector agent fails, it doesn't matter what the LDAP on the FortiGate says, FSSO won't
work. If the FortiGate LDAP fails, but the LDAP on the collector agent is still running, the FortiGate may not be
able to collect logs, but the collector agent will still collect logs.
Fortinet strongly encourages users to create filters from the collector agent.

DO NOT REPRINT
© FORTINET
In AD settings, not all group types are supported. It only supports filtering groups from:
• Security groups
• Universal groups
• Groups inside OUs
• Local or universal groups that contain universal groups from child domains (only with Global Catalog)
All FortiGate configurations include a user group called SSO_Guest_User. When only passive authentication
is used, all the users that do not belong to any FSSO group are automatically included in this guest group.
This allows an administrator to configure limited network access to guest users that do not belong to the
Windows AD domain.
However, if both passive and active authentication are enabled for specific traffic, SSO_Guest_User cannot
be used, as traffic from IP addresses not on the FSSO user list will need to be prompted to enter their
credentials.

DO NOT REPRINT
© FORTINET
Depending on your network, you may need to configure advanced settings in your FSSO collector agent.
Citrix servers support FSSO. Terminal server (TS) agent mode allows the server to monitor user logons in
real time. The TS agent is like a DC agent, it also needs the collector agent to collect and send the logon
events to FortiGate. It then uses the same ports to report the logons back to the collector agent.
The collector agent on its own can only get accurate logon events from Citrix servers if each user gets their
own IP address. Otherwise if multiple users share the same IP address, TS agent is needed so that it can
report to the collector agent the user, IP address, and source port range assigned to that user. The TS agent
cannot forward logs directly to FortiGate, they first have to be gathered by a collector. This does not work with
polling from FortiGate.
A RADIUS server configured as a RADIUS-based accounting system can interact in your network by sending
accounting messages to the collector agent. The FSSO collector agent also supports integration with syslog
servers for the same purpose.
The FSSO collector agent can also monitor a Microsoft Exchange server, which is useful when users access
their email using their domain account.
For Windows Security Event Logs polling mode, Event IDs to poll can be configured here. For specific
event IDs, visit the Fortinet knowledge base site (http://kb.fortinet.com).

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand how to configure the SSO settings on FortiGate and the FSSO collector agent.
Next, you’ll learn some basic troubleshooting options.

DO NOT REPRINT
© FORTINET

• Recognize and monitor FSSO-related log messages
• Perform basic FSSO troubleshooting
By demonstrating competence in FSSO monitoring and troubleshooting, you will be able to avoid, identify, and
solve common issues related to FSSO.

DO NOT REPRINT
© FORTINET
FSSO-related log messages are generated from authentication events. These include user logon and log off
events, and NTLM authentication events. These log messages are central to network accounting policies, and
can also be useful in troubleshooting issues.
To ensure you log all the events needed, set the minimum log level to Notification or Information. Firewall
logging requires Notification as a minimum log level. The closer to the log level is to Debug level, the more
information will be logged.

DO NOT REPRINT
© FORTINET
When troubleshooting FSSO agent-based deployments, you may want to look at the log messages generated
directly on the FSSO collector agent.
The Logging section of the FSSO collector agent allows the following configurations:
• Log level: Select the minimum severity level of logged messages. Includes these levels:
• Debug: The most detailed log level. It is used when actively troubleshooting issues.
• Information: Includes details about logon events and workstation checks. This is the
recommended level for most troubleshooting.
• Warning: The default level. It provides information about failures.
• Error: This level lists only the most severe events.
• Log file size limit (MB): Enter the maximum size for the log file in MB. The default is 10.
• View Log: View all FSSO agent logs.
• Log logon events in separate logs: Record user logon-related information separately from other logs.
The information in this log includes: data received from DC agents, user logon/logoff information,
workstation IP change information, and data sent to FortiGate units. When selected, a summary of events
sent and removed from the FortiGate is listed under View Logon Events, while all other information
remains under View Log.
• View Logon Events: If Log logon events in separate logs is enabled, you will be able to view user
logon-related information.

DO NOT REPRINT
© FORTINET
Let’s begin with these tips that are useful in many FSSO troubleshooting situations:
• FSSO has a number of required ports that must be allowed through all firewalls, or connections will fail.
These include ports: 139 (workstation verification), 445 (workstation verification and event log polling),
389 (LDAP), and 445 and 636 (LDAPS).
• Configure traffic shaping between FortiGate and the domain controllers to ensure that the minimum
bandwidth is always available. If there is insufficient bandwidth, some FSSO information might not reach
FortiGate.
• In an all Windows environment, flush inactive sessions. Otherwise, you can have a sessions for non-
authenticated machines go out as an authenticated user. This can occur if the DHCP lease expires for the
authenticated user with the collector agent being able to verify that the user has indeed logged out.
• Ensure DNS is configured correctly and updating IP addresses if workstations' IP address changes.
• Never set workstation verify interval to 0. This prevents the collector agent from aging out stale entries.
They can only be removed by a new event overwriting them. This can be especially dangerous in
environments where FSSO and non-FSSO users share the same DHCP pool.
• When using passive authentication only, include the group of guest users in a policy and give them
access. Associate their group with a security policy. If active authentication is used as a backup, ensure
that SSO_Guest_User is not added to polices. SSO_Guest_User and active authentication are mutually
exclusive.

DO NOT REPRINT
© FORTINET
If the tips from the previous slide didn’t solve your FSSO issues, you may need to apply some debug
commands.
To display the list of FSSO users that are currently logged on, use the CLI command diagnose debug
authd fsso list.
For each user, the user name, user group, IP address, and the name of the workstation from which they
logged on are shown. The MemberOf section shows the group that was created on the firewall, to which you
mapped the AD group. The same group should be shown in the User group screen on the GUI.
Also, use exec fsso refresh to manually refresh user group information from any directory service
servers connected to FortiGate, using the collector agent.

DO NOT REPRINT
© FORTINET
To show the status of communication between the FortiGate and each collector agent, you can use the CLI
command diagnose debug authd fsso server-status.
However, before you use that command, you must first run the command diagnose debug enable.

DO NOT REPRINT
© FORTINET
Also, available under diagnose debug authd fsso are commands for clearing FortiGate’s cache of all
currently logged on users, filtering the display of the list of logged on users, and refreshing the logon and user
group information.

DO NOT REPRINT
© FORTINET
The command diagnose debug fsso-polling detail displays status information and some statistics
related with the polls done by FortiGate on each DC in agentless polling. If the read log offset is
incrementing, FortiGate is connecting to and reading the logs on the domain controller. If the read log
offset is incrementing but you are not getting any logon events, check that the group filter is correct and
that the domain controller is creating the correct event IDs.
The command diagnose debug fsso-polling refresh-user flushes information about all active
FSSO users.
In agentless polling mode, FortiGate frequently polls the event viewer to get the logon events. You can sniffer
this traffic on port 445.
Also, there is a specific FortiGate daemon that handles polling mode. It is the fssod daemon. To enable
agentless polling mode real-time debug, use the diagnose debug application fssod -1 command.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

• Define SSO and FSSO
• Understand FSSO deployment and configuration
• Detect user logon events in Windows Active Directory using FSSO
• Identify FSSO modes for Windows Active Directory
• Understand NTLM authentication for simple and multiple domains
• Configure SSO settings on FortiGate
• Install FSSO agents
• Configure Fortinet collector agent
• Recognize and monitor FSSO-related messages
• Perform basic FSSO troubleshooting

 High Availability
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about the fundamentals of FortiGate high availability (HA) and how to configure it.
FortiGate HA provides a solution for enhanced reliability and increased performance.

DO NOT REPRINT
© FORTINET

• HA operation modes
• HA cluster synchronization
• HA failover and workload
• Monitoring and troubleshooting

DO NOT REPRINT
© FORTINET

• Identify the different operation modes for high availability (HA).
• Understand the primary FortiGate election in an HA cluster.
By demonstrating competence in HA operation modes and primary FortiGate election, you will be able to
choose and implement the right high availability (HA) operation mode in your network based on your
requirements. You will be able to use the FortiGate devices effectively in your network.

DO NOT REPRINT
© FORTINET
The idea of HA is simple. HA links and synchronizes two or more devices.
In FortiGate HA, one FortiGate device acts as the primary appliance (also called the active FortiGate). It
synchronizes its configuration to the other devices. The other FortiGates are called secondary or standby
devices.
A heartbeat link between all the appliances is used to detect unresponsive devices.
What is synchronized between the devices? Are all FortiGate devices processing traffic? Does HA improve
availability, or does it improve throughput?
The answers vary, depending on the HA mode. There are currently two HA modes available: active-active and
active-passive. Let’s examine the differences.

DO NOT REPRINT
© FORTINET
First, let's take a look at active-passive mode. In either of the two HA operation modes, the configuration of
the secondary FortiGates is synchronized with the configuration of the primary device.
(click)
In active-passive mode, the primary FortiGate is the only FortiGate device that actively processes traffic.
Secondary FortiGates remain in passive mode, monitoring the status of the primary device.
(click)
If a problem is detected in the primary FortiGate, one of the secondary devices will take over the primary role.
This event is called HA failover.

DO NOT REPRINT
© FORTINET
The other HA mode is active-active.
Like active-passive HA, in active-active HA, all FortiGate configurations are synchronized. Also, if a problem is
detected in the primary device, one of the secondaries will take over the role of the primary, to process the
traffic.
However, one of the main differences in the active-passive mode is that in the active-active mode, all of the
FortiGate devices are processing traffic. One of the tasks of a primary FortiGate in active-active mode is to
balance some of the traffic among all the secondary devices.

DO NOT REPRINT
© FORTINET
So how do the FortiGate devices in an HA cluster communicate?
FortiGate HA uses FGCP, the FortiGate clustering protocol, for HA-related communications. FGCP travels
between the clustered FortiGate devices over the links that you have designated as the heartbeats.
You should create a heartbeat link between two FortiGate devices using a regular RJ45 or crossover cable. If
you have another device between the two FortiGates, such as a switch, ensure that it is dedicated and
isolated from the rest of your network. This way, critical FGCP traffic does not need to compete with the other
traffic for bandwidth.
NAT mode cluster and transparent mode cluster use different Ethernet type values to discover and verify the
status of other FortiGates in an operating cluster.
FortiGates in a cluster uses telnet sessions over TCP port 23, with Ethernet type 0x8893 over heartbeat links,
to synchronize the cluster configuration and to connect to the CLI of another FortiGate in a cluster.
Starting in FortiOS 5.6.0, when you manually restart or shut down the primary FortiGate, before the primary
FortiGate actually shuts down, it becomes the secondary device in a HA cluster, and waits for the traffic to
failover to new primary, before it shuts down or reboots.

DO NOT REPRINT
© FORTINET
FortiGate HA configuration requires a specific set up and devices.

First, at least two, but up to four, FortiGate devices with the same:
• Firmware
• Hardware model and VM license
• FortiGuard, FortiCloud, and FortiClient licenses
• Hard drive capacity and partitions
• Operating mode (transparent or NAT)
What if one of the FortiGate device has a lower level of licensing than other FortiGate devices in the cluster?
All of the FortiGates in the cluster will revert to that lower licensing level. For example, if you only purchase
FortiGuard Web Filtering for one of the FortiGate devices in a cluster, when the cluster is operating, none of
the cluster members will support FortiGuard Web Filtering.
Second, at least one link between the FortiGate devices for HA communication. HA communication is called
heartbeat traffic. For redundancy, up to eight heartbeat interfaces can be created. If one link fails, HA will use
the next one, as indicated by priority and position in the heartbeat interface list.
Third, the same interfaces on each FortiGate device have to be connected to the same switch or LAN
segment. Notice that in the example shown on the slide, the FortiGate devices are redundant to mitigate
failure. But, the switches and their links still are a single point of failure. As we will see later, you can also have
redundancy in the network switches and links.
As a best practice (and Fortinet recommendation), configure the FortiGate interfaces with static IP addresses
when forming an HA cluster. Once an HA is formed, you can configure the DHCP or PPPoE addressing for an
interface. If an interface is configured for DHCP or PPPoE, enabling HA may result in the interface receiving
an incorrect address, or not being able to connect to the DHCP or PPPoE server correctly.

DO NOT REPRINT
© FORTINET
The process for electing the primary FortiGate depends on an HA setting called HA override. This slide shows
the process and selection criteria that a cluster uses to elect the primary FortiGate when the HA override
setting is disabled, which is the default behavior.
Note: The selection process stops at the first matching criteria that successfully selects a primary FortiGate in
a cluster.
1. The cluster first compares the number of monitored interfaces whose statuses are up. The FortiGate
device with the most available monitored interfaces becomes the primary.
2. The cluster compares the HA uptimes of the individual devices. If the HA uptime of a device is at least five
minutes more than the HA uptimes of the other FortiGates, it becomes the primary.
3. The FortiGate with the configured highest priority becomes the primary.
4. The cluster chooses the primary by comparing the serial numbers.
When HA override is disabled, the HA uptime has precedence over the priority setting. If for any reason you
need to change which device is the current primary, you can manually force a failover event. When the
override setting is disabled, the easiest way of doing this is by executing the CLI command diagnose sys
ha reset-uptime in the primary FortiGate.
Note: The reset-uptime command resets the HA uptime internally and does not affect the system up time
displayed on the dashboard of a FortiGate. Also, if a monitored interface fails, or a FortiGate in a cluster
reboots, the HA uptime for that FortiGate is reset to 0.
Note: You can view the HA uptime difference between the cluster members. The device with 0 in the uptime
column indicates the device with lower uptime. In this example, the device ending with serial number 92 has
an HA uptime 7814/10 seconds greater than the other device in the HA cluster. The reset _cnt column
indicates the number of times HA uptime has been reset for that device.

DO NOT REPRINT
© FORTINET
You can alter the order of the selection criteria that clusters consider when electing the primary FortiGate.
If the HA override setting is enabled, priority is considered before the HA uptime.
The advantage of this method is that you can specify which device is the preferred primary every time (as long
as it is up and running) by configuring it with the highest HA priority value. The disadvantage is that a failover
event is triggered not only when the primary fails, but also when the primary is available again. When a
primary becomes available again, it takes back its primary role from the secondary FortiGate that temporarily
replaced it.
Note: The selection process stops at the first matching criteria that successfully selects a primary FortiGate in
a cluster.
When override is enabled, the easiest way of triggering a failover is to change the HA priorities. For example,
you can either increase the priority in one of the secondaries, or decrease the priority in the primary.
The override setting and device priority values are not synchronized to all cluster members. You must enable
override and adjust device priority manually and separately for each cluster member.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand HA operation modes and the election of the primary FortiGate in a HA cluster.
Next, you’ll learn about HA cluster synchronization.

DO NOT REPRINT
© FORTINET

• Identify primary and secondary device tasks in an HA cluster.
• Identify what is synchronized between HA cluster members.
• Configure session synchronization for seamless failover.
By demonstrating competence in cluster synchronization, you will be able to identify the tasks of FortiGate
devices and synchronized between cluster members is. You will also learn how to configure and use session
synchronization for specific types of traffic for seamless failover.

DO NOT REPRINT
© FORTINET
So, what are the tasks of a primary FortiGate?
It monitors the cluster by sending hello signals and listening for replies, to determine if each other FortiGate
is alive and available. It also synchronizes its routing table, DHCP information, and part of its configuration to
the other devices.
Optionally, you can configure the primary FortiGate to synchronize some of the traffic session information to
all the secondary devices. This allows a faster, seamless failover for some sessions. Some applications will
not need to reestablish their sessions after a failure of a primary FortiGate. We will discuss which session
information can be synchronized later in the lesson.
In active-active mode only, a primary FortiGate also distributes certain traffic among all the available devices
in the cluster.

DO NOT REPRINT
© FORTINET
Now, let's take a look at the tasks of secondary FortiGates.
If the mode is active-passive, the secondaries simply wait, receiving synchronization data but not actually
processing any traffic. If the primary FortiGate fails, the secondaries will elect a new primary.
In active-active mode, the secondaries don’t wait passively. They process all traffic assigned to them by the
primary device.

DO NOT REPRINT
© FORTINET
What about the heartbeat interfaces?
You don’t need to configure heartbeat interfaces. FortiGate clustering protocol automatically negotiates the
heartbeat IP addresses based on each device’s serial number. The IP address 169.254.0.1 is assigned to the
device with the highest serial number. The IP address 169.254.0.2 is assigned to the device with the second
highest serial number, and so on. The IP address assignment does not change when a failover happens.
Regardless of the device role at any time (primary or secondary), its heartbeat virtual IP address remains the
same.
A change in the heartbeat IP addresses might happen, when a FortiGate device joins or leaves the cluster. In
those cases, the cluster renegotiates the heartbeat IP address assignment, this time taking into account the
serial number of any new device, or removing the serial number of any device that left the cluster.
The HA cluster uses these virtual IP addresses to distinguish the cluster members and update configuration
changes to the cluster members.

DO NOT REPRINT
© FORTINET
There are a few items that need to be considered when connecting heartbeat interfaces and configuring
interface monitoring:
• Heartbeat ports contain sensitive information about cluster configuration and require a fair amount of
bandwidth to make sure cluster configurations are in a synchronized state at all times. You must have at
least one port for the heartbeat traffic, preferably two. As a best practice, configure an alias for the
heartbeat interfaces. It helps to identify what these interfaces are being used for in a HA cluster.
Note: Heartbeat communication can be enabled for physical interfaces, but not for VLAN subinterfaces, IPsec
VPN interfaces, redundant interfaces, 802.3ad aggregate interfaces, or FortiGate switch ports.
• You should configure interface monitoring only for those ports whose failure should trigger a device failover
(for example, high-priority traffic ports). You should not configure port monitoring for dedicated heartbeat
ports.
As a best practice, wait until a cluster is up and running and all interfaces are connected before enabling
interface monitoring. A monitored interface can easily become disconnected during initial setup and cause
failovers to occur before the cluster is fully configured and tested.

DO NOT REPRINT
© FORTINET
To prepare for a failover, an HA cluster keeps its configurations in sync. Let’s take a look at that now.
FortiGate HA uses a combination of both incremental and complete synchronizations.
When a new FortiGate is added to the cluster, the primary FortiGate compares its configuration checksum
with the new secondary FortiGate configuration checksum. If the checksums don't match, the primary
FortiGate uploads its complete configuration to the secondary FortiGate.

DO NOT REPRINT
© FORTINET
After the initial synchronization is complete, the primary will send any further configuration changes done by
an administrator to all the secondaries. For example, if you create a firewall address object, the primary
doesn’t resend its complete configuration, it sends just the new object.

DO NOT REPRINT
© FORTINET
HA propagates more than just configuration details. Some runtime data, such as DHCP leases and routing
tables, are also synchronized.
By default, the cluster checks every 60 seconds to ensure that all devices are synchronized. If any secondary
is out of sync, the checksum of secondary devices is then checked every 15 seconds. If checksums don’t
match for five consecutive checks, a complete re-synchronization is done.

DO NOT REPRINT
© FORTINET
Not all the configuration settings are synchronized. There are a few that are not, such as:
• The system interface settings of the HA reserved management interface and the HA default route for the
reserved management interface
• In-band HA management interface
• HA override
• HA device priority
• The virtual cluster priority
• The FortiGate host name
• The HA priority setting for a ping server (or dead gateway detection) configuration
• Licenses
• Caches
The primary FortiGate synchronizes all other configuration settings, including other configurations related to
HA settings.

DO NOT REPRINT
© FORTINET
Session synchronization enables seamless failover for some traffic. The information of some sessions is
synchronized, so when the primary fails, the new primary can take over those sessions where they were left
and keep them open. Traffic might be interrupted for a few seconds, but the network applications don’t need to
reconnect the sessions again.
Once session synchronization is enabled, the device synchronizes TCP and IPsec VPN sessions that comply
with one requirement: they are not handled by a proxy-based security profiles. Although, session using flow-
based security profiles is supported but failed over sessions are no longer inspected by security profile
functions.
Note: If both flow-based and proxy-based security profile features are applied to a TCP session, that session
will not resume after a failover.
You can optionally enable the synchronization of UDP and ICMP sessions. Although both protocols are
sessionless, entries are created in the FortiGate session table for each UDP and ICMP traffic flow. Usually,
this synchronization is not required, because most of the network applications based on UDP or ICMP are
able to keep the communication even when their session information is lost.
You can also enable synchronization of multicast sessions. The multicast time to live (TTL) timer controls how
long to keep synchronized multicast routes on the secondary devices in HA cluster so they are present on the
secondary devices when it becomes the new primary device after a failover.
The synchronization of SSL VPN sessions is not supported.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand HA cluster synchronization.
Next, you’ll learn about HA cluster failover protection types and workload for primary and secondary
FortiGates in a HA cluster.

DO NOT REPRINT
© FORTINET

• Identify the HA failover types.
• Interpret how an HA cluster in active-active mode distributes traffic.
• Implement virtual clustering per virtual domain (VDOM) in a HA cluster.
By demonstrating competence in failover types and work load, you will be able to identify how enhanced
reliability is achieved through HA failover protection. You will also learn about distribution of traffic in active-
active cluster and distributing traffic using virtual clustering.

DO NOT REPRINT
© FORTINET
The most common types of failovers are device failovers and link failovers.
A device failover is basically triggered when the primary FortiGate stops sending heartbeat traffic. When this
happens, the secondaries renegotiate a new primary.
A link failover occurs when the link status of a monitored interface on the primary FortiGate goes down. You
can configure an HA cluster to monitor the link status of some interfaces. If a monitored interface on the
primary FortiGate is unplugged, or its link status goes down, a new primary FortiGate is elected.
If session pickup is enabled for the type of traffic you want to synchronize among cluster members, the
sessions are resumed in the event of device failover or link failover.
There are multiple events that might trigger an HA failover, such as hardware or software failure in the primary
FortiGate or an issue in one of the primary’s interfaces. When a failover occurs, an event log is generated.
Optionally, the device can also generate a SNMP trap and an alert email.

DO NOT REPRINT
© FORTINET
To forward traffic correctly, a FortiGate HA solution uses virtual MAC addresses. When a primary joins an HA
cluster, each interface is assigned a virtual MAC address. The HA group ID is used in the creation of virtual
MAC addresses assigned to each interface. So, if you have two or more HA clusters in the same broadcast
domain, and using the same HA group ID, you might get MAC address conflicts. For those cases, it is strongly
recommended to assign different HA group IDs to each cluster.
Through the heartbeats, the primary informs all secondaries about the assigned virtual MAC address. Upon
failover, a secondary adopts the same virtual MAC addresses for the equivalent interfaces.
The new primary broadcasts gratuitous ARP packets, notifying the network that each virtual MAC address is
now reachable through a different switch port.
Note: The MAC address of a reserved HA management interface is not changed to a virtual MAC address.
Instead the reserved management interface keeps its original MAC address.

DO NOT REPRINT
© FORTINET
As you learned earlier in this lesson, if a primary fails, a new primary is elected. But what happens if a
secondary FortiGate device fails? It depends on the HA mode.
In an active-passive cluster, the primary only updates its list of available secondary FortiGates. It also starts
monitoring for the failed secondary, waiting for it to come online again.
However, in an active-active cluster, all secondaries are handling traffic. So the primary (which tracks and
assigns sessions to each secondary) must not only update its list of available secondary FortiGates, it must
also reassign sessions from the failed FortiGate device to a different secondary FortiGate.

DO NOT REPRINT
© FORTINET
This is how the workload is distributed between roles, depending on the HA mode.
Notice that traffic workload is not distributed in active-passive mode, but it is in active-active mode.

DO NOT REPRINT
© FORTINET
Let’s look at how an HA cluster in active-active mode distributes traffic.

(click)
First, the client side sends a SYN packet. It’s always forwarded to the primary FortiGate using the internal
interface’s virtual MAC address as the destination.
(click)
If the primary decides that the session is going to be inspected by a secondary, the primary forwards the SYN
packet to the secondary that will do the inspections. In this example, the source MAC address of the
forwarded frame is changed to the physical MAC address of the primary FortiGate internal interface and the
destination MAC address is the physical MAC address of the secondary FortiGate internal interface.
(click)
The secondary FortiGate starts the connection with the server by directly sending a SYN packet using
external interface physical MAC address. The secondary also responds with SYN/ACK to the client, for which
source MAC address is physical MAC address of secondary FortiGate internal interface.

DO NOT REPRINT
© FORTINET
Next, the client acknowledges the ACK. It’s forwarded again to the primary FortiGate using the virtual MAC
address of internal interface as the destination.
(click)
The primary device forwards the packet to the secondary inspecting that session, using the secondary’s
physical MAC address.

DO NOT REPRINT
© FORTINET
When the server responds to the TCP SYN, again, the packet is sent to the primary using the external
interface’s virtual MAC address.
(click)
So, the primary signals the secondary.

(click)
The secondary replies to the server.
The idea is not to load balance bandwidth. The traffic is always sent to the primary first. The main objective is
to share CPU and memory among multiple FortiGates for traffic inspection.

DO NOT REPRINT
© FORTINET
So far, we’ve discussed HA clustering where each FortiGate device acts as a whole security domain.
But, if you have an HA cluster with multiple VDOMs, you can configure virtual clusters.
Virtual clusters allow you to have one device acting as the primary for one VDOM and as the secondary for a
different VDOM. Each VDOM has a primary and a secondary FortiGate, and any device can act as the
primary for some VDOMs, and as the secondary for the other VDOMs at the same time. Because traffic from
different VDOMs can go to different primary FortiGates, you can use virtual clustering to manually distribute
your traffic between the two cluster devices, and allow the failover mechanism for each VDOM between two
FortiGates.
Note: You can configure virtual clustering between only two FortiGate devices with multiple VDOMs.

DO NOT REPRINT
© FORTINET
At the beginning of this lesson, you reviewed a simple HA topology. Now, let’s look at a more robust topology.
It is called full mesh HA.
The idea is to prevent any single point of failure, not only in the FortiGate devices, but also in the network
switches and interfaces.
As you can see on this slide, you have two FortiGates for redundancy and each FortiGate is connected to two
redundant switches, using two different interfaces.
A full mesh HA is more complicated to assemble and administer, but it can provide the availability required by
critical installations. This solution is only available with higher-end FortiGate models because not all FortiGate
models are capable of creating aggregated or redundant interfaces, which are required for building this type of
topology.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand HA failover and workload.
Next, you’ll learn about monitoring and troubleshooting an HA cluster.

DO NOT REPRINT
© FORTINET

• Verify the normal operation of an HA cluster.
• Configure HA management interface.
• Upgrade an HA cluster’s firmware.
By demonstrating competence in monitoring and troubleshooting, you will be able to make sure cluster is
synchronized properly. You will also learn how to configure and access secondary devices in an HA cluster
and how to upgrade the firmware on the HA cluster.

DO NOT REPRINT
© FORTINET
If the HA cluster has formed successfully, the GUI displays all the FortiGate devices in the cluster. It shows
cluster members synchronized status, hostnames, serial numbers, roles, priorities, uptime, and active
sessions.
You can view the HA status by adding HA Status dashboard widget. You can also view HA status information
by clicking System > HA, where you can see more details by adding columns such as checksum, CPU, and
memory, to name a few.
You can also disconnect a cluster member from the cluster and edit the HA configurations.

DO NOT REPRINT
© FORTINET
You can get more information about the status of the HA from the CLI. For example, the command diagnose
sys ha status displays heartbeat traffic statistics, as well as the serial number and HA priority of each
FortiGate. This command also shows the heartbeat interface IP address automatically assigned to the
FortiGate with the highest serial number.
Remember, the heartbeat IP address assignment changes only when a FortiGate leaves or joins the cluster.

DO NOT REPRINT
© FORTINET
Another indication of the health of an HA cluster is the status of the configuration synchronization. The
diagnose sys ha checksum command tree provides many options that you can use to check or
recalculate the HA checksum.
To check that all the secondary configurations are synchronized with the primary configuration:
• Execute the diagnose sys ha checksum cluster command to view the checksums of all cluster
members from any FortiGate in a cluster.
• The diagnose sys ha checksum show command shows the checksum of the individual FortiGate
from which this command is executed.
• You can also run the diagnose sys ha checksum recalculate command from any cluster member
to recalculate the HA checksums.
If a secondary FortiGate displays exactly the same sequence of numbers as the primary, its configuration is
well synchronized with the primary FortiGate in the cluster. In this example, the diagnose sys ha
checksum cluster command is executed to view the checksums of all cluster members.
• global represents the checksum of the global configuration, such as administrators, admin profiles,
global logging settings, and FortiGuard settings, to name a few.
• root is the checksum for the root VDOM. If you have configured multiple VDOMs, you will see checksums
of all configured VDOMs.
• all is the checksum of the global configuration, plus all the VDOMs checksums.

DO NOT REPRINT
© FORTINET
When troubleshooting a problem in an HA cluster, it is useful to know that you can connect to the CLI of any
secondary FortiGate from the CLI of the primary FortiGate. You have to use the command execute ha
manage with the secondary HA index for that purpose.
To get the list of secondary FortiGates with their HA indexes, you can add a question mark to the end of the
execute ha manage command: execute ha manage ?.

DO NOT REPRINT
© FORTINET
If you want to be able to connect to each device directly, you can reserve an interface for HA management.
The FGCP cluster supports reserved HA management interfaces in both NAT and transparent mode. You can
configure up to four dedicated management interfaces. The configuration of a reserved HA management
interface is not synchronized between HA cluster members, and each device can have different management
IP addresses. The HA reserved management interface can also be used by each device to send SNMP traffic
and logs independently.
What if you don’t have free interface available to reserve it as a dedicated HA management interface? You
can configure a management IP address from the CLI on any interface that is connected to a network and
processing traffic. This doesn’t require reserving an interface just for management access, and is an
alternative to reserving a dedicated HA management interface.

DO NOT REPRINT
© FORTINET
As with a standalone device, when upgrading an HA cluster, each updating FortiGate device must reboot. As
the uninterruptable upgrade is enabled by default, the cluster upgrades the secondary FortiGates first. Once
all the secondary FortiGates are running the new firmware, a new primary is elected and the firmware in the
original primary device is upgraded.
If the cluster is operating in active-active mode, traffic load balancing is temporally disabled while all devices
are upgrading their firmware.
You can change the firmware upgrade process by disabling uninterruptable upgrade from the CLI using
config system ha. This will result in all FortiGates in a cluster being upgraded at the same time. This
takes less time, but interrupts the traffic flow.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
• Identify the different operation modes for HA.

• Understand the primary FortiGate election in an HA cluster.
• Identify primary and secondary device tasks in an HA cluster.
• Identify what is synchronized between HA cluster members.
• Configure session synchronization for seamless failover.
• Identify the HA failover types.
• Interpret how an HA cluster in active-active mode distributes traffic.
• Implement virtual clustering per VDOM in a HA cluster.
• Verify the normal operation of an HA cluster.
• Configure HA management interface.
• Upgrade an HA cluster’s firmware.

 Web Proxy
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to configure FortiGate to act as a web proxy.

 Web Proxy
DO NOT REPRINT
© FORTINET

• Web proxy concepts
• Web proxy configuration
• Web proxy authentication and authorization

 Web Proxy
DO NOT REPRINT
© FORTINET

• Describe how a web proxy works
• Use a proxy automatic configuration (PAC file) and Web proxy auto-discovery protocol (WPAD) to
configure explicit proxy settings in web browsers
By demonstrating competence in web proxy concepts, you will be able to understand the fundamentals web
proxy operation.

 Web Proxy
DO NOT REPRINT
© FORTINET
A web proxy receives or intercepts requests from a client to a server. If allowed, and if no cache is available,
the web proxy forwards the client’s request to the web server.
Two TCP connections are created: one from the client to the web proxy and one from the web proxy to the
server.

 Web Proxy
DO NOT REPRINT
© FORTINET
A transparent web proxy does not require any configuration changes to the client’s configuration. Clients
continue to use the web, just like they would without a web proxy.
Clients send requests to the web server’s IP address and port number. The web proxy intercepts the client’s
requests transparently; that is, at the IP layer. The destination address doesn’t change.

 Web Proxy
DO NOT REPRINT
© FORTINET
How is an explicit web proxy different from a transparent web proxy? When you use explicit web proxy, you
must configure clients to send the requests to the web proxy IP address and port number, not the website’s
servers.

 Web Proxy
DO NOT REPRINT
© FORTINET
Usually, you will enable the proxy to cache responses from web servers.
A web cache stores responses from web servers. So, when a client repeats a request, FortiGate can quickly
send the cached content (response), instead of forwarding the request and waiting for the response. This
reduces WAN bandwidth usage, server load, and delay.
Web cache is supported in both transparent and explicit web proxy modes.

 Web Proxy
DO NOT REPRINT
© FORTINET
Web proxies provide an extra layer of security. They can block any traffic in the standard HTTP and HTTPS
ports that is not web traffic.
Explicit web proxies offer another security benefit: administrators do not need to allow direct Internet access
to clients. Only the explicit web proxy requires direct Internet access. Administrators can enforce clients to
send traffic to the web proxy first, if they require Internet access.
The FortiGate web proxy solution offers two additional benefits. One is that administrators can use the content
of the HTTP fields as matching criteria in the firewall policies.
The FortiGate web proxy solution also provides an extra benefit not available if you are not doing web proxy:
support for Kerberos authentication. Kerberos authentication provides a mechanism for doing Fortinet single
sign-on (FSSO) without installing any agent across the Windows AD domains.

 Web Proxy
DO NOT REPRINT
© FORTINET
How do you configure users’ web browsers to use an explicit web proxy?
One method is to set up the proxy IP address and port manually, using browser settings. In large networks,
you can use an Active Directory login script or roaming profile, rather than configure each computer
individually.
Alternatively, you can configure browsers to use explicit proxies by installing a PAC file, or using WPAD.

 Web Proxy
DO NOT REPRINT
© FORTINET
When you set up an explicit web proxy by configuring the web browser settings, you must provide the proxy’s
FQDN or IP address and TCP port number. You can specify only one proxy address at a time.
If you want to exempt specific destination IP addresses, subnets, and FQDNs from using the proxy, you can
add them to a list. For those destinations, the browser will send the requests directly to the web servers.

 Web Proxy
DO NOT REPRINT
© FORTINET
Another configuration method uses a standard explicit auto-configuration file, called a PAC file. A PAC file
contains instructions that tell the browser when to use a proxy and which proxy to use, depending on the
destination.
This configuration method supports the use of multiple web proxy servers.
To deploy the PAC file, first you must install it on an HTTP server that the clients can reach. (Your FortiGate
can act as the HTTP server for the PAC file.) Then, you must configure all browsers with the PAC file’s URL.

 Web Proxy
DO NOT REPRINT
© FORTINET
What does a PAC file contain?
A PAC file is a JavaScript. It determines whether the request will use a proxy, and what the addresses for the
proxies are.
In this example:
• The PAC file allows any connection to example.com to bypass the proxies.
• Connections to servers in the 10.0.0.0/24 subnet use the proxy named fastproxy.example.com.
• All other requests are made through the proxy named proxy.example.com.

 Web Proxy
DO NOT REPRINT
© FORTINET
Browsers can use WPAD to determine the URL where the PAC file is located.
WPAD can use two discovery methods: DNS-based and DHCP-based.
When using the DHCP method, the browser sends a DHCPINFORM request to the DHCP server. The DHCP
server replies with the PAC file’s URL.
When the DNS method is used, the browser first queries the DNS server to resolve the FQDN
wpad.<local-domain>. The DNS server replies with the IP address where the PAC file is located. The
browser downloads the PAC file from the URL: http://<pac-server-ip>:80/wpad.dat.
Most browsers try the DHCP server method first. If it fails, they try the DNS server method.

 Web Proxy
DO NOT REPRINT
© FORTINET

 Web Proxy
DO NOT REPRINT
© FORTINET
Good job! You now understand web proxy concepts.
Next, you’ll learn about web proxy configuration.

 Web Proxy
DO NOT REPRINT
© FORTINET

• Configure FortiGate to act as a web proxy
• Reduce WAN bandwidth usage and improve responsiveness using web cache
• Apply security policies to web proxy traffic based on HTTP headers
By demonstrating competence in these topics, you will be able to configure a FortiGate as a web proxy.

 Web Proxy
DO NOT REPRINT
© FORTINET
The steps for configuring web proxy differ according to the type of proxy (explicit or transparent) you are
configuring.
To configure explicit web proxy, you must:

1. Enable explicit web proxy in the VDOM, indicating the interfaces that the web proxy clients will be
connecting to.
2. Create proxy policies to authorize and inspect the web traffic.
3. Configure the browsers to send the web traffic to the web proxy.
To configure transparent web proxy, you must:

1. Create regular firewall policies to match the traffic, applying a proxy profile with the HTTP Policy
Redirect setting enabled.
2. Create proxy policies to authorize and inspect the web traffic.
Keep in mind that web proxy (explicit and transparent) is available only in VDOMs configured for proxy-based
inspection.

 Web Proxy
DO NOT REPRINT
© FORTINET
Once explicit proxy settings are visible in the GUI, you can enable and configure them.
You must add the interface or interfaces that will be listening to explicit web proxy connections.
Additionally, you can change the TCP port where the proxy is listening, edit and upload the PAC file, and
choose the default action that FortiGate takes for traffic that doesn’t match any proxy policy.

 Web Proxy
DO NOT REPRINT
© FORTINET
The next step is to create explicit proxy policies to specify which traffic and users are allowed to use the
proxy. Policies for explicit proxy are configured in a different configuration section than regular firewall
policies.
Web proxy traffic that does not match any policy is accepted or denied depending on the configuration setting
Default Firewall Policy Action (shown on the previous slide).

 Web Proxy
DO NOT REPRINT
© FORTINET
To configure transparent web proxy, the web traffic must first match a firewall policy using a proxy option
profile with the setting HTTP Policy Redirect enabled. This setting instructs FortiOS to redirect the traffic to
the transparent web proxy.
Regular firewall policies match traffic based on Layer 3 and Layer 4 information only. The web proxy offers
more flexible and gradual policy matching, based not only on information from those two OSI layers, but also
on Layer 7 information (HTTP headers).
The setting HTTP Policy Redirect affects only web (HTTP and HTTPS) traffic. Other protocols' traffic is not
redirected to the web proxy, and is authorized and inspected based on the regular firewall policy configuration.

 Web Proxy
DO NOT REPRINT
© FORTINET
Similar to explicit web proxy, the next step is to create proxy policies to specify when the transparent proxy
must accept and inspect the traffic.

 Web Proxy
DO NOT REPRINT
© FORTINET
Web cache is available both in explicit and transparent web proxy. It can be enabled or disabled per proxy
policy through the CLI.

 Web Proxy
DO NOT REPRINT
© FORTINET
Similar to creating firewall policies, when creating proxy policies, you use firewall address objects to specify
the source and destination. There is one category of address objects that are used only for proxy policies:
proxy addresses.
Proxy addresses offer more granularity when matching HTTP traffic. They can match HTTP traffic based on
the content of any HTTP field.
For example, the HTTP headers include a field named Host, which usually contains the FQDN of the web
server. With proxy addresses, you can create policies that match the traffic based on this destination FQDN,
regardless of the destination IP address.
Another example is matching by URL pattern. Proxy addresses can match traffic to URLs that match a regex
expression, regardless of the destination IP address.

 Web Proxy
DO NOT REPRINT
© FORTINET
There are two groups of proxy address types. One group is for address types that are used as destinations in
proxy policies. They can match URL patterns, URL categories, and HTTP host names.
The other group is for address types that are used as a sources in proxy policies. They can match HTTP
methods, user agents, and other HTTP headers fields.

 Web Proxy
DO NOT REPRINT
© FORTINET
In the example shown in this slide, the administrator created a transparent proxy policy to block any attempt
from the Student_Addresses subnet to upload files to the Fortinet website. The administrator created two
proxy addresses for this purpose:
• The POST_From_Students address matches any HTTP POST request coming from the
Student_Addresses subnet.
• The Fortinet address matches any web connection to a host name that contains the text string
fortinet.com.

 Web Proxy
DO NOT REPRINT
© FORTINET

 Web Proxy
DO NOT REPRINT
© FORTINET
Good job! You now understand web proxy configuration.
Next, you’ll learn about web proxy authentication and authorization.

 Web Proxy
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to configure FortiGate to authenticate, authorize, and
monitor web proxy users.

 Web Proxy
DO NOT REPRINT
© FORTINET
FortiOS 5.6 improves web proxy by separating user authentication from user authorization. User
authentication is enforced by using authentication schemes and rules, while user authorization is enforced in
the proxy policies.
Authentication schemes define sets of authentication methods (form, NTLM, digest, and so on) and user
databases (LDAP, local, RADIUS, FSSO, and so on).
Authentication rules are used to specify the schemes (the authentication methods and databases) to use
depending on the user IP address and protocol. Up to two authentication schemes can be configured in each
rule: one for active authentication and one for passive authentication.

 Web Proxy
DO NOT REPRINT
© FORTINET
An authentication scheme specifies a method and a database to be used in one or more authentication rules.
The available methods are basic, digest, NTLM, form, FSSO, and RSSO. If the method is configured as
negotiate, the FortiGate negotiates the method with the web client.
The available databases are local, LDAP, RADIUS, FSSO, RSSO, and TACACS+.
Not all the databases are available for all the methods. For example, you cannot select the local database if
the method has been set to FSSO.
Web proxy supports two-factor authentication, which can be enabled in the authentication schemes.

 Web Proxy
DO NOT REPRINT
© FORTINET
An authentication rule defines which scheme is used for active authentication, and which scheme is used for
passive (SSO) authentication. Authentication rules are matched from top to bottom (as in the case of firewall
policies). The web proxy uses the source IP address and protocol to match the traffic and know which scheme
to use.
The protocols, between the FortiGate and the browser, supported for authentication are HTTP, FTP, and
SOCKS5.
The rules also define if the authentication will be based on IP address, or based on session. The differences
between both are described in this lesson.

 Web Proxy
DO NOT REPRINT
© FORTINET
What happens to traffic that requires authorization, but does not match any authentication rule?
The active and passive (SSO) schemes to use for those cases is defined under config authentication
setting.

 Web Proxy
DO NOT REPRINT
© FORTINET
Web proxy authentication can be based on either source IP address or HTTP session.
With IP-based authentication, all traffic sessions from same source IP address are treated as a single user.
With session-based authentication, each session can be treated as coming from different users.
How should you decide which to use?
IP-based authentication requires less RAM to remember the authenticated sessions. However, it should only
be used when each user has a different IP address (and there is no NAT device between the user and the
FortiGate).
If you have multiple users sharing the same IP address, such as in the case of users behind NAT, use HTTP
session-based authentication instead. In this mode, each browser inserts an HTTP cookie in its requests. The
cookie identifies the user. This method requires slightly more RAM because FortiGate must remember all
session cookies.

 Web Proxy
DO NOT REPRINT
© FORTINET
What does the traffic flow look like when a user authenticates with the web proxy, using HTTP session-based
authentication?
If a user connects and the request doesn’t have any associated authentication session, FortiGate replies to
the browser, requesting login credentials. The browser prompts the user to authenticate, and remembers the
authenticated state by storing a cookie.
If the same user makes more requests later, the browser automatically sends the same cookie again.
FortiGate identifies the user by this session cookie. The user does not need to authenticate for every request,
only the first time.

 Web Proxy
DO NOT REPRINT
© FORTINET
FortiOS 5.6 web proxy separates user authentication from user authorization. User authentication is enforced
using schemes and rules. User authorization is enforced in the source field of the proxy policies by indicating
which users (or user groups) can access which resources in the network.

 Web Proxy
DO NOT REPRINT
© FORTINET
Once the web proxy is working, you can monitor which users are connected to it. You can do this from the
GUI, or from the CLI by using the command: diagnose wad user list

 Web Proxy
DO NOT REPRINT
© FORTINET

 Web Proxy
DO NOT REPRINT
© FORTINET

 Web Proxy
DO NOT REPRINT
© FORTINET
• Describe how a web proxy works

• Use a PAC file and WPAD to configure explicit proxy settings in web browsers
• Configure FortiGate to act as a web proxy
• Reduce WAN bandwidth usage and improve responsiveness using web cache.
• Apply security policies to web proxy traffic based on HTTP headers
• Authenticate, authorize, and monitor web proxy users

 Diagnostics
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about using diagnostic commands and tools.

 Diagnostics
DO NOT REPRINT
© FORTINET

• General diagnosis
• Debug flow
• CPU and memory
• Firmware and hardware

 Diagnostics
DO NOT REPRINT
© FORTINET

• Identify your network’s normal behavior
• Monitor for abnormal behavior, such as traffic spikes
• Diagnose problems at the physical and network layers
By demonstrating competence in general diagnosis, you will be able to determine general information about
the status of FortiGate.

 Diagnostics
DO NOT REPRINT
© FORTINET
In order to define any problem, first you must know what your network’s normal behavior is.
In the graph shown on this slide, the range that indicates normal is shown in blue. What exactly is this blue
line? It indicates the averages–our baseline. What is the thick black line? It’s the current behavior. When the
current behavior (black line) leaves the normal range, an abnormal event is happening.
Normal is measured and defined in many ways. It can be performance: the expected CPU and memory
utilization, bandwidth, and traffic volumes. But, it can also be your network topology: which devices are
normally connected at each node. It is also behavior: traffic flow directions, which protocols are blocked or
proxied, and the distribution of protocols and applications used during specific times of the day, week, or year.

 Diagnostics
DO NOT REPRINT
© FORTINET
What is the first way to define what normal is for your network?
Topology. Flows and other specifications of normal behaviour are derived from topology. So, during
troubleshooting, a network diagram is essential. If you create a ticket with Fortinet Technical Support, a
network diagram should be the first thing you attach.
Network diagrams sometimes combine the two types of diagrams:

• Physical
• Logical
A physical diagram shows how cables, ports, and devices are connected between buildings and cabinets. A
logical diagram shows relationships (usually at OSI Layer 3) between virtual LANs, IP subnets, and routers. It
can also show application protocols such as HTTP or DHCP.

 Diagnostics
DO NOT REPRINT
© FORTINET
Another way to define normal is to know the average performance range. On an ongoing basis, collect data
that shows normal usage.
For example, if traffic processing is suddenly slow, and your FortiGate’s CPU usage is 75%, what does that
indicate? If CPU use is usually 60-69%, then 75% is probably still normal. But if normal is 12-15%, there may
be a problem.
Get data on both typical maximum and minimum for the time and date. That is, on a workday or holiday, how
many bits per second should ingress or egress each interface in your network diagrams?

 Diagnostics
DO NOT REPRINT
© FORTINET
How can we get information about the current status? First, let’s look at CLI commands: you can use them
through a local console, even if network issues make GUI access slow or impossible.
A few commands provide system statuses. The get system status command provides most general
purpose information. Output shows:
• Model
• Serial number
• Firmware version
• Host name
• FortiGuard license status
• System time
• Version of the FortiGuard antivirus, IPS, and IP reputation databases, and others

 Diagnostics
DO NOT REPRINT
© FORTINET
At the physical layer, troubleshooting analyzes which ports are plugged in, media capacity, and negotiated
speed and duplex mode.
At the data link layer, diagnostics often analyze how many frames are being dropped due to CRC errors or
collisions.
The output might vary depending on the model and NIC driver version. In all the cases, the output shows the
physical MAC address, administrative status, and link status.

 Diagnostics
DO NOT REPRINT
© FORTINET
If you suspect that there is an IP address conflict, or that an IP has been assigned to the wrong device, you
may need to look at the ARP table. The get system arp command is used for that purpose. It shows the
FortiGate interface, IP address, and associated MAC address. This command lists the information for all
external devices connected to the same LAN segments where FortiGate is connected. FortiGate’s own IP and
MAC addresses are not included.

 Diagnostics
DO NOT REPRINT
© FORTINET
Let’s say that FortiGate can contact some hosts through port1, but not others. Is the problem in the physical
layer or the link layer? Neither. Connectivity has been proven with at least part of the network. Instead, you
should check the network layer. To test this, as usual, start with ping and traceroute.
The same commands exist for IPv6: execute ping becomes execute ping6, for example.
Remember: location matters. Tests will be accurate only if you use the same path as the traffic that you are
troubleshooting. To test from FortiGate (to a FortiAnalyzer or FortiGuard, for example), use FortiGate’s own
execute ping and execute traceroute CLI commands. But, to test the path through FortiGate,
additionally use ping and tracert or traceroute from the endpoint– from the Windows, Linux, or Mac OS
X computer–not only from the FortiGate CLI.
Due to NAT and routing, you may need to specify a different ping source IP address–the default is the IP of
the outgoing interface. If there is no response, verify that the target is configured to reply to ICMP echo
requests.

 Diagnostics
DO NOT REPRINT
© FORTINET

 Diagnostics
DO NOT REPRINT
© FORTINET
Good job! You now understand general diagnostics.
Next, you’ll learn about debug flow.

 Diagnostics
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to diagnose connecting problems using debug flow.

 Diagnostics
DO NOT REPRINT
© FORTINET
If FortiGate is dropping packets, can a packet capture (sniffer) be used to determine the reason? To find the
cause, you should use the debug (packet) flow.
The debug flow shows, step-by-step, how the CPU is handling each packet.
To use the debug flow, follow these steps:

1. Define a filter.
2. Enable debug output.
3. Start the trace.
4. Stop when you’ve finished.

 Diagnostics
DO NOT REPRINT
© FORTINET
This is a sample of a debug flow output. Here we have captured the first packet of a TCP three-way
handshake, the SYN packet. It shows:
• The packet arriving to the FortiGate, indicating the source and destination IP addresses, port numbers, and
incoming interface
• The FortiGate creating a session, indicating the session ID
• The route to the destination, indicating the next-hop IP address and outgoing interface
• The ID of the policy that matches and allows this traffic
• How the source NAT is applied

 Diagnostics
DO NOT REPRINT
© FORTINET
This is the output for the SYN/ACK packet. It shows:
• The packet arrival, indicating again the source and destination IP addresses, port numbers, and incoming
interface
• The ID of the existing session for this traffic. This number matches the ID of the session created during the
SYN packet.
• How the destination NAT is applied
• The route to the destination, indicating again the next-hop IP address and outgoing interface
If the packet is dropped by FortiGate, this debug shows the reason for that action.
This tool is useful for many other troubleshooting cases, including when you need to understand why a packet
is taking a specific route, or why a specific NAT IP address is being applied.

 Diagnostics
DO NOT REPRINT
© FORTINET

 Diagnostics
DO NOT REPRINT
© FORTINET
Good job! You now understand debug flow.
Next, you’ll learn about FortiGate CPU and memory diagnosis.

 Diagnostics
DO NOT REPRINT
© FORTINET

• Diagnose resource problems, such as high CPU or memory usage
• Diagnose memory conserve mode
• Diagnose fail-open session mode
By demonstrating competence in these topics, you will be able to diagnose the most common CPU and
memory problems.

 Diagnostics
DO NOT REPRINT
© FORTINET
Not all problems are network connectivity failures. Sometimes, there are resource problems in the devices.
What else could cause latency? Once you have discarded problems with the physical media and bandwidth
usage, you should check the FortiGate resources usage: CPU and memory.
If usage is high, there are tools that can determine which feature is consuming the most CPU. Additionally,
you can troubleshoot faster if you know precisely which change (if any) corresponds with when the problem
began.

 Diagnostics
DO NOT REPRINT
© FORTINET
Let’s begin by looking at the get system performance status command.
At the top, output shows that this FortiGate model has one CPU: CPU0. This is followed by the RAM usage.
At the bottom, output shows your network traffic.

 Diagnostics
DO NOT REPRINT
© FORTINET
Next, let’s examine the output for diagnose sys top. It lists processes that use the most CPU or memory.
Some common processes include:
• ipsengine, scanunitd, and other inspection processes

• reportd
• fgfmd for FortiGuard and FortiManager connections
• forticron for scheduling
• management processes (newcli, miglogd, cmdb, sshd, and httpsd)
To sort the list by highest CPU usage, press Shift+P. To sort by highest RAM usage, press Shift+M.

 Diagnostics
DO NOT REPRINT
© FORTINET
The diagnose sys top-summary command is slightly different than the diagnose sys top
command. The former is better for examining memory usage. Why?
It collects all memory being used by a process and its child processes, including any memory that is shared
between the processes.
Let’s compare the outputs of diagnose sys top and diagnose sys top-summary. They are different.
In the diagnose sys top output, child processes are listed individually. But in the diagnose sys top-
summary output, all child processes are listed together. The name is marked by an X, indicating how many
times a process has forked.
Because RAM for all forks (children) is added together into a total, diagnose sys top-summary is better
when you need to determine which feature to adjust, in order to correct performance.
What is forking?

 Diagnostics
DO NOT REPRINT
© FORTINET
Forking is when the operating system makes multiple copies of a process in order to subdivide processing
load, or handle multiple similar tasks.
If diagnose sys top shows scanunitd running three times, diagnose sys top-summary would show
one entry with an x3, meaning it was forked three times. But diagnose sys top-summary shows that all
scanunitd processes are using 12 MB of RAM, while diagnose sys top indicates that each scanunitd
is using just under 2 MB. Why do they indicate different RAM usage?
The 10 MB antivirus database isn’t duplicated in RAM for each child process; it is loaded into shared memory,
which isn’t counted by diagnose sys top.
FortiOS doesn’t allow different processes to communicate directly. So, if memory wasn’t shared, then FortiOS
would be required to load a copy of the antivirus database for each scan process. Each individual process
would be using around 11 MB; only three concurrent scans would require 33 MB. Performance would
decrease.

 Diagnostics
DO NOT REPRINT
© FORTINET
If the memory usage goes too high, the FortiGate may enter into memory conserve mode. While the FortiGate
is in memory conserve mode, it takes some actions to prevent the memory usage from increasing, which
could cause the system to become unstable and inaccessible.
Memory conserve mode is never a desirable state, as it impacts the user traffic.
Three different configurable thresholds define when the FortiGate enters in to and exits from, conserve mode.
If the memory usage goes above the percentage of total RAM defined as the red threshold, the FortiGate
enters conserve mode. The actions that the device takes depend on the device configuration.
If the memory usage keeps increasing, it might exceed the extreme threshold. While the memory usage is
above this highest threshold, all new sessions are dropped.
The third configuration setting is the green threshold. If the memory usage goes below this threshold, the
FortiGate exits conserve mode.

 Diagnostics
DO NOT REPRINT
© FORTINET
What actions does the FortiGate take to preserve memory while in conserve mode?
• FortiGate does not accept configuration changes, as they might increase the memory usage.
• FortiGate does not execute any quarantine action, including forwarding suspicious files to FortiSandbox.
• The fail-open setting under config ips global controls how the IPS engine behaves during
conserve mode. If the setting is enabled, packets are allowed without any IPS-engine inspection. If the
setting is disabled, packets that require IPS-engine inspection are dropped. Remember that the IPS engine
is used for all types of flow-based inspections. The IPS engine is also used when the FortiGate must
identify the network application, regardless of the destination TCP/UDP port (for example, for application
control).

 Diagnostics
DO NOT REPRINT
© FORTINET
The av-failopen setting defines the action that is applied to any proxy-based inspected traffic, while the
unit is in conserve mode (and as long as the memory usage does not exceed the extreme threshold). This
setting also applies to flow-based AV inspection. Four different actions can be configured:
Idledrop: Drops all idle proxied sessions.

off: All new sessions with content scanning enabled are not passed.
pass (default): All new sessions pass without inspection.
one-shot: Similar to pass in that traffic passes without inspection. However, it will keep bypassing the AV
proxy even after it leaves conserve mode. Administrators must either change this setting, or restart the unit, to
restart the AV scanning.
However, if the memory usage exceeds the extreme threshold, new sessions are always dropped, regardless
of the FortiGate configuration.

 Diagnostics
DO NOT REPRINT
© FORTINET
The diagnose hardware sysinfo conserve command is used to determine if a FortiGate device is
currently in memory conserve mode.

 Diagnostics
DO NOT REPRINT
© FORTINET
Another undesirable state for a FortiGate is the fail-open session mode. This mode kicks in not during a high
memory situation, but when a proxy on the FortiGate runs out of available sockets to process more proxy-
based inspected traffic.
If av-failopen-session is enabled, FortiGate will act according to the av-failopen setting. Otherwise,
by default, it will block new sessions that require proxy-based inspection until new sockets become available.

 Diagnostics
DO NOT REPRINT
© FORTINET

 Diagnostics
DO NOT REPRINT
© FORTINET
Good job! You now understand FortiGate CPU and memory diagnosis.
Next, you’ll learn about FortiGate firmware and hardware diagnosis.

 Diagnostics
DO NOT REPRINT
© FORTINET

• Format the flash memory
• Load a firmware image from the BIOS menu
• Run hardware tests
• Display crash log information
By demonstrating competence in these topics, you will be able to diagnose the most common firmware and
hardware problems.

 Diagnostics
DO NOT REPRINT
© FORTINET
From the FortiGate BIOS, administrators can execute some operations over the flash memory and the
firmware images. To access the BIOS menu, you must reboot the device while connected to the console port.
The booting process, at one point, shows the following message:
Press any key to display configuration menu
While this prompt is displayed, press any key to interrupt the booting process and display the BIOS menu.

 Diagnostics
DO NOT REPRINT
© FORTINET
From the BIOS menu, select F to format the flash memory.
Doing this might be required if the firmware gets corrupted, or if the administrator wants to do a clean
installation of new firmware. Keep in mind, though, that formatting the flash deletes any information stored on
it, such as firmware images, configuration, and digital certificates.

 Diagnostics
DO NOT REPRINT
© FORTINET
After reformatting the flash, you will need to install the firmware image from the BIOS. Follow these steps:
1. Run a TFTP server.
2. Configure the TFTP server with the folder where the firmware image file is stored.
3. Connect the PC Ethernet port to the FortiGate TFTP install interface.
4. Select get firmware image from the BIOS menu.
The interface assigned as the TFTP install interface depends on the model. However, and in most cases, it is
either the port1 or internal interface.

 Diagnostics
DO NOT REPRINT
© FORTINET
From the BIOS menu, select the option G to install a new firmware.
The BIOS will ask for:

• The IP address of the TFTP server
• The FortiGate IP address (it must be in the same class-C subnet as the TFTP server)
• The name of the firmware image
If everything is ok, you should see a series of pound signs, indicating that the device is downloading the
image. The BIOS will then verify the integrity of the file and give you these three options:
• Save it as the default firmware

• Save it as the backup firmware
• Run the image without saving it
If the firmware is going to be used in production, select the first option: Save it as the default
firmware.
The last option (Run the image without saving it) allows you to run and test firmware without
overwriting any existing firmware in the flash. Once you have finished the tests and are ready to roll back the
change, you need to reboot the device, and the previously existing firmware will be used.

 Diagnostics
DO NOT REPRINT
© FORTINET
Like with any other electronic device, damage to RAM can cause intermittent crashes.
If you suspect hardware failure, you can run hardware tests.
How do you run the hardware tests? It depends on the FortiGate model.

 Diagnostics
DO NOT REPRINT
© FORTINET
For some FortiGate E-series models, you can run the hardware tests directly from the FortiOS CLI.
For other models, you must download special HQIP hardware testing images from the Fortinet Technical
Support website.
The steps for uploading the hardware test image are the same as the ones used for uploading a firmware
image. You can run the hardware test image without saving it in the flash, so any existing firmware image
won’t be overwritten.

 Diagnostics
DO NOT REPRINT
© FORTINET
For some E-series models, the command diagnose hardware test suite all runs the hardware tests
from FortiOS. The hardware tests require user interaction while running. Users can skip some of the steps
and some tests require connecting external devices (such as USB sticks) or network cables to the FortiGate.

 Diagnostics
DO NOT REPRINT
© FORTINET
Another area you may want to monitor, purely for diagnostics, is the crash logs. Crash logs are available
through the CLI. Any time a process is closed for any reason, the crash log records this as a crash. Most of
the logs in the crash log are normal. For example, any time the antivirus definitions package is updated, the
scanunit process needs to close down in order to apply the new package. This is a normal shutdown.
Some logs in the crash log might indicate problems. For that reason, crash logs are frequently requested by
Fortinet Technical Support for troubleshooting purposes. This slide shows the command you have to use to
get a crash log.
Two commands can show information from the crash logs:

• diagnose debug crashlog history: Lists a summary of the processes that have crashed, how
many crashes has happened, and the time of the last crash
• diagnose debug crashlog read: Provides details about each crash, in addition to other system
events, such as conserve mode entry and exit times

 Diagnostics
DO NOT REPRINT
© FORTINET
These are the entries generated in the crash logs when a FortiGate enters and exits memory conserve mode.

 Diagnostics
DO NOT REPRINT
© FORTINET

 Diagnostics
DO NOT REPRINT
© FORTINET

 Diagnostics
DO NOT REPRINT
© FORTINET

• Identify your network’s normal behavior
• Monitor for abnormal behavior, such as traffic spikes
• Diagnose problems at the physical and network layers
• Diagnose connectivity problems using the debug flow
• Diagnose resource problems, such as high CPU or memory usage
• Diagnose memory conserve mode
• Diagnose fail-open session mode
• Format the flash memory
• Load a firmware image from the BIOS menu
• Run hardware tests
• Display crash log information

DO NOT REPRINT Supplementary Material
© FORTINET
Supplementary Material

 Firewall Policies
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to understand and apply firewall policies to allow and deny traffic passing
through FortiGate. At its core, FortiGate is a firewall, so almost everything that it does to your traffic is linked
to your firewall policies.

DO NOT REPRINT
© FORTINET

• Firewall policies
• Configuring firewall policies
• Managing firewall policies

DO NOT REPRINT
© FORTINET

• Identify the components of firewall policies
• Understand how FortiGate matches traffic to firewall policies by interface, zone, source, destination,
service, or schedule
By demonstrating competence in identifying the different components of firewall policies, and recognizing how
FortiGate matches traffic with firewall policies and takes appropriate action, you will have a better
understanding of how firewall policies interact with network traffic.

DO NOT REPRINT
© FORTINET
To begin, let’s talk about what firewall policies are.
Firewall policies define which traffic matches them and what FortiGate will do if it matches.
Should the traffic be allowed? Initially, FortiGate bases this decision on simple criteria, such as the source of
the traffic. Then, if the policy does not block the traffic, FortiGate begins a more computationally expensive
security profile inspection–often known as unified threat management (UTM)–such as antivirus, application
control, and web filtering, if you’ve chosen it in the policy. Those scans could block the traffic if, for example, it
contains a virus. Otherwise, the traffic is allowed.
Will network address translation (NAT) be applied? Authentication required? Firewall policies also determine
the answers to these questions. After processing is finished, FortiGate forwards the packet toward its
destination.
FortiGate looks for the matching firewall policy from top to bottom and, if a match is found, the traffic is
processed based on the firewall policy. If no match is found, the traffic is dropped by the default Implicit Deny
firewall policy.

DO NOT REPRINT
© FORTINET
Each policy matches traffic and applies security by referring to the objects that you’ve defined, such as
addresses and profiles.
What about other firewall policy types? Do IPv6 or virtual wire policies exist? Yes. These policies use slightly
different objects that are relevant to their type. In this lesson, we are discussing IPv4 firewall policies because
they are the most common use case.

DO NOT REPRINT
© FORTINET
When a packet arrives, how does FortiGate find a matching policy? Each policy has match criteria, which you
can define using the following objects:
• Ingress and egress interfaces

• Source: IP address, user, device ID
• Destination: IP address or Internet Services
• Network service(s): IP protocol and port number
• Schedule: applies during configured times
When the traffic matches a firewall policy, FortiGate applies the configured action in the firewall policy.
• If the Action is set to DENY, FortiGate will drop the session.
• If the Action is set to ACCEPT, FortiGate will apply other configured settings for packet processing, such
as antivirus scanning, web filtering, or source NAT.
For example, if you want to block incoming FTP to all but a few FTP servers, you would define the addresses
of your FTP servers, select those as the destination, and select FTP as the service. You probably wouldn’t
specify a source (often any location on the Internet is allowed) or schedule (usually FTP servers are always
available, day or night). Finally, you would set the Action setting to ACCEPT.
This might be enough, but often you’ll want more thorough security. Here, the policy also authenticates the
user, scans for viruses, and logs blocked connection attempts.
Note: We will discuss the Action of LEARN later in the lesson.

DO NOT REPRINT
© FORTINET
To begin describing how FortiGate finds a policy for each packet, let’s start with the interface(s).
Packets arrive on an incoming, or ingress, interface. Routing determines the outgoing, or egress, interface. In
each policy, you must set a source and destination interface; even if one or both are set to any. Both
interfaces must match the policy’s interface criteria in order to be a successful match.
For example, if you configure policies between port3 (LAN) ingress and port1 (WAN) egress and a packet
arrives on port2, the packet would not match your policies and therefore would be dropped because of the
implicit deny policy at the end of the list. Even if the policy is from port3 (LAN) ingress to any egress, the
packet would still be dropped because it did not match the incoming interface.
To simplify policy configuration, you can group interfaces into logical zones. For example, you could group
port4 to port7 as a DMZ zone. Zones can be created from the Interfaces page. However, you should note that
an interface in a zone cannot be referenced individually, and if you need to add the interface to the zone, you
must remove all references to that interface (for example, firewall policies, firewall addresses, and so on). If
you think that you might need to reference interfaces individually, you should set multiple source and
destination interfaces in the firewall policy, instead of using zones.

DO NOT REPRINT
© FORTINET
By default, you can select only a single interface as the incoming interface and a single interface as the
outgoing interface. This is because the option to select multiple interfaces, or any interface in a firewall policy,
is disabled on the GUI. However, you can enable the Multiple Interface Policies option on the Feature
Visibility page to disable the single interface restriction.
You can also select multiple interfaces, or select the any option, if you configure a firewall policy on the CLI,
regardless of the default GUI setting.
It is also worth mentioning that when you choose the any interface option, you cannot select multiple
interfaces for that interface. In this example, because any is selected as the outgoing interface, you cannot
add any additional interfaces, as any interface implies that all interfaces have already been selected.

DO NOT REPRINT
© FORTINET
The next match criteria that FortiGate considers is the packet’s source.
In each firewall policy, you must select a source address object. Optionally, you can refine your definition of
the source address by also selecting a user, a group, or a specific device. If your organization allows bring
your own device (BYOD), then a combination of all three provides a much more granular match, for increased
security.
When selecting a fully qualified domain name (FQDN) as the source address, it must be resolved by DNS and
cached in FortiGate. Make sure FortiGate is configured properly for DNS settings. If FortiGate is not able to
resolve an FQDN address, it will present a warning message, and a firewall policy configured with that FQDN
may not function properly.

DO NOT REPRINT
© FORTINET
If a user is added as part of the source, FortiGate must verify the user before allowing or denying access
based on the firewall policy. There are different ways that a user can authenticate.
For local users, the username and password is configured locally on FortiGate. When a local user
authenticates, the credentials that they enter must match the username and password configured locally on
FortiGate.
For a remote user (for example, LDAP or RADIUS), FortiGate receives the username and password from the
remote user and passes this information to the authentication server. The authentication server verifies the
user login credentials and updates FortiGate. After FortiGate receives that information, it grants access to the
network based on the firewall policy.
A Fortinet single sign-on (FSSO) user's information is retrieved from the domain controller. Access is granted
based on the group information on FortiGate.

DO NOT REPRINT
© FORTINET
There are two device identification techniques: with an agent and without an agent (agentless).
Agentless 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, FortiOS-VM
detection methods to name a few. The agentless device identification is only effective if FortiGate and the
workstations are on directly connected network segments, where traffic is sent directly to the FortiGate and
there is no intermediate router or layer 3 device between FortiGate and workstations.
Note: 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 uses FortiClient. FortiClient sends information to FortiGate, and the device is tracked by its
unique FortiClient user ID (UID).

DO NOT REPRINT
© FORTINET
If you enable Source Device type in the firewall policy, FortiGate enables Device Detection on the source
interface(s) of the policy. By default, FortiGate uses Device Detection (passive scanning) which runs the
scans based on the arrival of traffic.
What if the FortiGate is unable to detect the device?
You can enable Active Scanning. If passive detection fails to detect the device type for more than five
minutes, active scanning is triggered and scans every three minutes. If active scanning fails to detect the
device type, the next scan occurs 10 minutes later. If that scan fails, the next occurs 15 minutes later.
FortiGate uses an (N+1)*5 minutes algorithm for scanning, where N is the number of scans that have been
done. Active scanning scans for device type, OS, and OS version.

DO NOT REPRINT
© FORTINET
FortiGate can control FortiClient settings through the FortiClient profile and registration. In order for FortiClient
to register with FortiGate, FortiTelemetry must be enabled on the interface(s) facing the endpoints on the
network because it listens for the connection from the devices that have FortiClient installed. FortiTelemetry is
a TCP protocol used for communication between FortiClient and FortiGate, which operates on TCP port 8013.
There are other configuration settings worth mentioning:
• Enforce FortiClient Compliance Check: If enabled, it also enables Device Detection. Noncompliant
devices are blocked and redirected to a web portal that explains the noncompliance and provides a link to
download FortiClient. You can exempt devices from FortiClient enforcement using source, destination, or
services.
After FortiClient is registered, it is added to the device list. FortiGate also pushes the FortiClient profile to the
registered FortiClient(s). You can configure the default FortiClient profile or add additional profiles. You can
also view the FortiClient endpoint information on the FortiClient Monitor page on FortiGate.
You can run the CLI commands to view the FortiClient unique UID. FortiClient devices have a unique UID
which can be used as an index for the device. The unique UID is used instead of the MAC address because
using MAC addresses can be problematic when a device has multiple MAC addresses (such as servers or
virtual machines), or when there is no Layer 2 visibility of the device.
The Licenses widget on the FortiGate GUI dashboard shows the total number of registered devices and the
total number of devices available for registration. Windows and Mac OS X FortiClient installers are also
available from this dashboard widget.

DO NOT REPRINT
© FORTINET
The Device Inventory shows the list of detected devices. You can right-click any detected device to edit,
delete, or view details in FortiView. The details include session, destination, policies, and more.
Devices are indexed by MAC and identified from multiple sources. The CLI command shows a more detailed
listing than the Device Inventory page, including the detection method. In the example shown on this slide,
devices are detected by source as HTTP user agent and FortiClient.
Detected devices are saved to FortiGate’s flash drive for 28 days. Therefore, on restart, FortiGate knows that
devices have already been identified, and does not have to recategorize each device. However, the device
information will expire and be removed from the device inventory table if no traffic is seen from that device for
28 days. This action can be altered on a per VDOM basis using FortiGate CLI commands.
The user displayed in the device information is just a tag; it cannot be used as a means of identification for an
authentication policy.

DO NOT REPRINT
© FORTINET
In this example, all three source selectors identify the user group, device type, and specific subnet.
Remember, user and device are optional objects. They are used here to make the policy more specific. If you
wanted the policy to match more traffic, you would leave the user and device objects undefined.

DO NOT REPRINT
© FORTINET
Like the packet’s source, FortiGate also checks the destination address for a match.
You can use address objects or ISDB objects as destinations in the firewall policy. The address object may be
a host name, IP subnet, or range. If you enter an FQDN as the address object, make sure that you’ve
configured your FortiGate with DNS servers. FortiGate uses DNS to resolve those FQDN host names to IP
addresses, which are what actually appear in the IP header.
Geographic addresses, which are groups or ranges of addresses allocated to a country, can be selected
instead. These objects are updated through FortiGuard.
Why is there is no option to select user or devices? The user identification or device identification is
determined at the ingress interface, and packets are forwarded only to the egress interface after user or
device authentication is successful.

DO NOT REPRINT
© FORTINET
Internet Service is a database that contains a list of IP addresses, IP protocols, and port numbers used by the
most common Internet services. FortiGate periodically downloads the newest version of this database from
FortiGuard. These can be selected as Destination in the firewall policy.
What happens if you need to allow traffic to only a few well-known public Internet destinations, such as
Dropbox or Facebook?
You can use Internet Service, which contains all the IP addresses, ports and protocols used by that service.
For the same reason, you cannot mix regular address objects with Internet service database (ISDB) objects,
and you cannot select services on a firewall policy. The ISDB objects already have services information which
is hard-coded.
Compared with address objects, which you need to check frequently to make sure that none of the IP
addresses have changed or appropriate ports are allowed, Internet services helps make this type of
deployment easier and simpler.

DO NOT REPRINT
© FORTINET
Schedules add a time element to the policy. For example, a policy allowing backup software may activate at
night, or a remote address may be allowed for testing purposes, and a schedule provides a test window.
Schedules can be configured and use a 24-hour time clock. There are a few configuration settings worth
mentioning:
• Recurring: If All Day is enabled, traffic will be allowed for 24 hours for the days selected. When
configuring recurring schedules, if the stop time is set earlier than the start time, the stop time will occur the
next day. For example, if you select Sunday as the day, 10:00 as the start time, and 09:00 as the stop time,
the schedule will stop on Monday at 09:00. If the start and stop time are identical, the schedule will run for
24 hours.
• One-time: The start date and time must be earlier than the stop date and time. You can also enable the
Pre-expiration event log, which will generate an event log N number of days before the schedule expires,
where N can be from 1 to 100 days.

DO NOT REPRINT
© FORTINET
Another criterion that FortiGate uses to match policies is the packet’s service.
At the IP layer, protocol numbers (for example, TCP, UDP, SCTP, and so on) together with source and
destination ports, define each network service. Generally, only a destination port (that is, the server’s listening
port) is defined. Some legacy applications may use a specific source port, but in most modern applications,
the source port is randomly identified at transmission time, and therefore is not a reliable way to define the
service.
For example, the predefined service object named HTTP is TCP destination port 80 and the predefined
service object named HTTPS is TCP destination port 443. However, the source ports are ephemeral and,
therefore, not defined.
By default, services are grouped together to simplify administration, so you can view the services By
Category or Alphabetically. If the predefined services don’t meet your organizational needs, you can create
one or more new services, service groups, and categories.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand the components used in firewall policies and matching criteria used by
FortiGate.
Next, you’ll learn how to configure firewall policies.

DO NOT REPRINT
© FORTINET

• Restrict access and make your network more secure using security profiles
• Configure logging
• Configure learning mode to evaluate and analyze traffic
By demonstrating competence in configuring firewall policies, you will be able to apply the correct settings,
such as security profiles, logging, and traffic shaping, to firewall policies on FortiGate, and make your network
more secure.

DO NOT REPRINT
© FORTINET
When you configure a new firewall policy on the GUI, you must specify a unique name for the firewall policy
because it is enabled by default, but it is optional in the CLI. This helps the administrator to quickly identify the
policy that they are looking for. However, you can make this feature optional on the GUI on the Feature
Visibility page by enabling Allow Unnamed Policies.
Note: If a policy is configured without a policy name on the CLI and you modify that existing policy on the GUI,
you must specify a unique name.
The FortiGate flat GUI view allows you to select interfaces and other objects by clicking or dragging and
dropping on the list populated on the right side.
There are many other options that you can configure in the firewall policy, such as firewall and network
options, security profiles, logging options, and enabling or disabling a policy.
When creating firewall objects or policies, a universally unique identified (UUID) attribute is added so that logs
can record these UUID and improve functionality when integrating with FortiManager or FortiAnalyzer.
When creating firewall policies, remember that FortiGate is a stateful firewall. As a result, you need to create
only one firewall policy that matches the direction of the traffic that initiates the session. FortiGate will
automatically remember the source-destination pair and allow replies.

DO NOT REPRINT
© FORTINET
One of the most important features that a firewall policy can apply is security profiles, such as IPS and
antivirus. A security profile inspects each packet in the traffic flow, where the session has already been
conditionally accepted by the firewall policy.
When inspecting traffic, FortiGate can use one of two methods: flow-based or proxy-based. Different security
features are supported by each type.

DO NOT REPRINT
© FORTINET
If you have enabled logging in the policy, FortiGate will generate traffic logs after a firewall policy closes an IP
session.
By default, Log Allowed Traffic is set to Security Events and generates logs for only the applied security
profiles in the firewall policy. However, you can change the setting to All Sessions, which generates logs for
all sessions.
If you enable Generate Logs when Session Starts, FortiGate creates a traffic log when the session begins.
FortiGate also generates a second log for the same session when it is closed. But remember that increasing
logging decreases performance, so use it only when necessary.
During the session, if a security profile detects a violation, FortiGate records the attack log immediately. To
reduce the amount of log messages generated and improve performance, you can enable a session table
entry of dropped traffic. This creates the denied session in the session table and, if the session is denied, all
packets of that session are also denied. This ensures that FortiGate does not have to do a policy lookup for
each new packet matching the denied session, which reduces CPU usage and log generation.
This option is in the CLI, and is called ses-denied-traffic. You can also set the duration for block
sessions. This determines how long a session will be kept in the session table by setting block-session-
timer in the CLI. By default, it is set to 30 seconds.
If the GUI option Generate Logs when Session Starts is not displayed, this means that your FortiGate
device does not have internal storage. This option is in the CLI, regardless of internal storage, and is called
set logtraffic-start enable.

DO NOT REPRINT
© FORTINET
You can also enable learning mode on a firewall policy. When you set Action to LEARN, it enables Device
Detection on the source interface(s) of the policy. The firewall policy automatically applies default static
profiles and passes traffic to security profiles for monitoring. It also enables logging with full capabilities, which
are tagged as Learn in the logs.
You can view the comprehensive report that results from learning mode on the Learning Reports page. This
report uses all of the learning logs, across all traffic and security vectors, to generate a complete summary
report for recommendation purposes. This enables users to easily implement a monitor then enforce process.

DO NOT REPRINT
© FORTINET
Two types of traffic shapers can be configured: shared and per IP.
A shared shaper applies a total bandwidth to all traffic using that shaper. The scope can be per policy or for all
policies referencing that shaper. FortiGate can count the packet rates of ingress and egress to police traffic.
FortiGate allows you to create three types of traffic shaping policies:
• Shared policy shaping: bandwidth management of security policies

• Per-IP shaping: bandwidth management of user IP addresses
• Application control shaping: bandwidth management by application
When creating traffic shaping policies, you must ensure that the matching criteria is the same as the firewall
policies you want to apply shaping to. Note that these apply equally to TCP and UDP, and UDP protocols may
not recover as gracefully from packet loss.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand how to configure firewall policies on FortiGate.
Next, you’ll learn how to manage and fine-tune settings for firewall policies.

DO NOT REPRINT
© FORTINET

• Identify policy list views
• Understand the use of policy IDs and sequence numbers
• Identify where an object is referenced
By demonstrating competence in managing firewall policies, you will be able to understand the difference the
between the policy ID and sequence number of a firewall policy. Also, you will be able to pinpoint object
usage, and simplify policies using object groups.

DO NOT REPRINT
© FORTINET
Firewall policies appear in an organized list. The list is organized either in Interface Pair View, or By
Sequence.
Usually, the list will appear in Interface Pair View. Each section contains policies for that ingress-egress pair.
Alternatively, you can view your policies as a single, comprehensive list by selecting By Sequence at the top
of the page.
In some cases, you won’t have a choice of which view is used.
If you use multiple source or destination interfaces, or the any interface in a firewall policy, policies cannot be
separated into sections by interface pairs–some would be triplets or more. So instead, policies are then
always displayed in a single list (By Sequence).
To help you remember the use of each interface, you can give them aliases by editing the interface on the
Network page. For example, you could call port3 Lan_network. This can help to make your list of policies
easier to understand.

DO NOT REPRINT
© FORTINET
Firewall policies in the GUI are ordered primarily by the policy sequence number. Policy sequence numbers
define the order in which rules are processed. Policy IDs are identifiers. By default, sequence numbers are
displayed on the GUI. CLI commands, however, use policy ID.
Be careful not to accidentally modify the wrong policy. To avoid such errors, you can add the policy ID to the
GUI using the column settings.
FortiGate automatically assigns a policy ID when a new firewall policy is created on the GUI. The policy ID
never changes, even if the rule is moved higher or lower in the sequence.

DO NOT REPRINT
© FORTINET
To simplify administration, you can group service and address objects. Then, you can reference that group in
the firewall policy, instead of selecting multiple objects each time or making multiple policies.
On this slide, four services are used to configure the policy: HTTP, HTTPS, FTP, and DNS. DNS is used by
browsers to resolve URLs to IP addresses because people remember domain names for web sites instead of
IP addresses. If you need to make many policies for web and FTP traffic, then it makes sense to create a
service object named Web-FTP. That way, you don’t have to manually select all four services each time you
make a policy. Policies can reference the Web-FTP service group instead.
Also, you can consolidate source addresses in source groups.

DO NOT REPRINT
© FORTINET
We’ve just shown several component objects that can be reused as you make policies. What if you want to
delete an object?
If an object is being used, you can’t delete it. First, you must reconfigure the objects that are currently using it.
The GUI provides a simple way to find out where in the FortiGate’s configuration an object is being
referenced. See the numbers in the Ref. column? They are the number of places where that object is being
used. The number is actually a link, so if you click it, you can see which objects are using it.
In this example, the all address object is being used by the Training address group and three firewall policies.
If you select a firewall policy, you can use the Edit, View List, and View Properties tabs.
• Edit: Allows you to edit the selected object. In this example, it shows the edit page for the firewall policy ID
4.
• View List: Allows you to view selected objects in its category. In this example, it will show you the list of all
the firewall policies.
• View Properties: Shows where the object is used in that configuration. In this example, address object all
is being used in the destination address and source address of that firewall policy.

DO NOT REPRINT
© FORTINET
You can right-click any firewall policy sequence number to see different menu options to edit or modify the
policy. The options include enabling or disabling a firewall policy, inserting firewall policies (above or below),
copying and pasting policies, and cloning reverse (only if NAT is disabled on that policy).
Clicking Edit in CLI opens the CLI console for the selected firewall policy or object. It shows the configured
settings in the CLI and can modify the selected firewall policy or object directly in the CLI Console.
Right-clicking the object provides you with options to add or remove an object of the same type, modify an
object, and show a reference for that object.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand how to manage firewall policies on FortiGate.
Next, you’ll learn about best practices and troubleshooting related to firewall policies.

DO NOT REPRINT
© FORTINET
• Identify naming restrictions for firewall policies and objects

• Reorder firewall policies for correct matching
• Demonstrate how to find matching policies for traffic types
By demonstrating competence in knowing firewall policy restrictions and using policy matching techniques,
you will be able to apply best practices and basic troubleshooting techniques when working with firewall
policies.

DO NOT REPRINT
© FORTINET
When configuring names for firewall objects, only certain characters are supported. For example,
Training(Lan) is not a valid name for an address object because it includes special characters that are not
supported. Although spaces are supported in the names, as a best practice, avoid using spaces in names.
Instead, use a hyphen or underscore. Using spaces can cause issues when trying to modify on the CLI or
troubleshooting.
However, many special characters are supported in passwords, comments, replacement messages, and so
on.

DO NOT REPRINT
© FORTINET
Always plan a maintenance window and create a test case for a few IP addresses, users, or devices before
implementing configuration changes in the production network. Any configuration changes made using the
GUI or CLI take effect immediately, and can interrupt service.
As a best practice, try to configure firewall policies as specifically as possible. This helps to restrict access
only to those resources. For example, use proper subnets when configuring address objects.
Another setting worth mentioning is security profiles, which help to provide appropriate security for your
network. Proper logging configuration can also help you to analyze, diagnose, and resolve common network
issues.

DO NOT REPRINT
© FORTINET
Remember you learned that only the first matching policy applies? Arranging your policies in the correct
position is important. It affects which traffic is blocked or allowed. In the applicable interface pair’s section,
FortiGate looks for a matching policy, beginning at the top. So, you should put more specific policies at the
top; otherwise, more general policies will match the traffic first, and more granular policies will never be
applied.
In the example shown on this slide, you’re moving the Block_FTP policy (sequence number 3, ID 5) that
matches only FTP traffic, to a position above a more general Unrestricted (accept everything from
everywhere) policy. Otherwise, FortiGate would always apply the first matching policy in the applicable
interface pairs–Unrestricted–and never reach the Block_FTP policy.
Notice that after moving this policy higher in the list, the sequence number changed from 3 to 2, but the policy
ID 5 remained the same on the GUI. Because the CLI uses only the policy ID, before the move, policy ID 4
was at the top, and after the move, policy ID 5 is at the top.
As a best practice, always add the policy ID column on the GUI. While the sequence number changes when a
policy is moved, the value that remains with a policy is the policy ID.
Note: Sequence numbers are shuffled (reused) as firewall policies are added or deleted; however, for policy
IDs, FortiGate assigns the next highest available ID number as policies are created.

DO NOT REPRINT
© FORTINET
In order to optimize and consolidate firewall policies, always check all configured settings. In this example, the
two firewall policies have differences in terms of services, security profiles, and logging settings. You can
consolidate these two firewall policies by combining services and choosing appropriate logging settings.
If you select Security Events (UTM) for the logging settings, traffic logs will not be generated for ALL_ICMP
traffic.
Note: ALL_ICMP service is not subject to web filter and antivirus scans, which means that applying these
security profiles to the ICMP traffic will result in the traffic passing through without being inspected.

DO NOT REPRINT
© FORTINET
You can find a matching firewall policy based on the policy lookup input criteria. Policy lookup creates a
packet flow over FortiGate without real traffic. From this, policy lookup can extract a policy ID from the flow
trace and highlight it on the GUI policy configuration page.
Depending upon the protocol you select (for example, TCP, UDP, IP, ICMP, and so on), you need to define
other input criteria. For example, when you select TCP as the protocol, you need to define the source
address, source port (optional), destination port, and destination address. When you select ICMP as the
protocol, you need to define the ICMP type/code, source address, and destination address.
When FortiGate is performing policy lookup, it performs a series of checks on ingress, stateful inspection, and
egress, for the matching firewall policy, from top to bottom, before providing results for the matching policy.
Note: If the firewall policy status is set to disable, the policy lookup skips the disabled policy and checks for
the next matching policy in the list.

DO NOT REPRINT
© FORTINET
Based on the input criteria, after clicking Search, the trace result will be selected and highlighted on the IPv4
Policy page.
Why didn’t Seq.# 1 or Seq. #2 firewall policy match the input criteria?
Because Seq.# 1 firewall policy status is set to disable, policy lookup skips the disabled policy. For Seq.# 2
firewall policy, it doesn’t match the destination port specified in the policy lookup matching criteria.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Now, you will review the objectives that you covered in the lesson.

DO NOT REPRINT
© FORTINET

• Recognize how packets match a firewall policy based on:
• Interfaces and zones
• Source and destination
• Network services
• Schedules
• Configure firewall policies
• Understand how policy IDs and sequence numbers are used
• Identify the object usage
• Reorder policies to match more granular policies first
• Use policy lookup to find matching policies

 Network Address Translation (NAT)
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to configure network address translation (NAT) and use it to implement
source NAT and destination NAT for the traffic passing through FortiGate.

DO NOT REPRINT
© FORTINET
• Introduction to NAT
• Firewall policy NAT
• Central NAT
• Session helpers
• Sessions

DO NOT REPRINT
© FORTINET
• Understand NAT and port address translation (PAT)

• Understand the different configuration modes available for NAT
By understanding how NAT and PAT work, and the available NAT configuration modes, you will have a good
start for planning the implementation of NAT in your network.

DO NOT REPRINT
© FORTINET
NAT is the process that enables a single device, such as a firewall or router, to act as an agent between the
Internet, or public network, and a local, or private, network.
NAT is usually implemented for one, or a combination, of the following reasons:
• Improved security: The addresses behind the NAT device are virtually hidden.
• Amplification of addresses: Hundreds of computers can use as few as one public IP address.
• Internal address stability: The addresses can stay the same, even if Internet service providers (ISPs)
change.
NAT and PAT, also known as NAPT, translate internal, typically private, IP addresses to external, typically
public or Internet, IP addresses. In FortiOS, NAT and traffic forwarding apply to the same firewall policy.
However, diagnostics clearly show NAT and forwarding as separate actions.
• For outgoing connections: The NAT option in a firewall policy, IP Pool, and central SNAT table can be
used and known as source NAT.
• For incoming connections: Virtual IPs (VIPs) and DNAT can be used and known as destination NAT.
NAT64 and NAT46 are the terms used to refer to the mechanism that allows IPv6 addressed hosts to
communicate with IPv4 addressed hosts and the reverse. Without this mechanism, an IPv6 node on a
network, such as a corporate LAN, would not be able to communicate with a website that was in an IPv4-only
environment, and IPv4 environments would not be able to connect to IPv6 networks.
NAT66 is NAT between two IPv6 networks.

DO NOT REPRINT
© FORTINET
When you use firewall policy NAT mode, you must configure SNAT and DNAT for each firewall policy.
Central NAT configurations are done per virtual domain, which means SNAT and DNAT configurations
automatically apply to multiple firewall policies. This is according to the SNAT and DNAT rules that you
specify, as opposed to each firewall policy in firewall policy NAT.
As a best practice, when you use central NAT, you should configure specific SNAT and DNAT rules, so that
they match only the desired firewall policies in your configuration.
Both firewall policy NAT and central NAT produce the same results; however, some deployment scenarios are
best suited to firewall policy NAT and some are best suited to central NAT.
Firewall policy NAT is suggested for deployments that include relatively few NAT IP addresses and where
each NAT IP address would have separate policies and security profiles. Central NAT is suggested for more
complex scenarios where multiple NAT IP addresses have identical policies and security profiles, or in next
generation firewall (NGFW) policy mode, where the appropriate policy may not be determined at the first
packet. NGFW policy mode is covered in the Firewall Policies lesson.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You have been introduced to NAT.
Next, you’ll learn about firewall policy NAT.

DO NOT REPRINT
© FORTINET

• Configure a firewall policy to perform SNAT and DNAT
• Apply SNAT with IP pools
• Configure DNAT with VIPs or a virtual server
By demonstrating competence in these areas, you will be able to configure firewalls policies to perform SNAT
and DNAT, and understand how it is applied to the traffic traversing through FortiGate.

DO NOT REPRINT
© FORTINET
There two ways to configure firewall policy source NAT:

• Use the outgoing interface address
• Use the dynamic IP pool

DO NOT REPRINT
© FORTINET
The source NAT option uses the egress interface address when NAT is enabled on the firewall policy. This is
many-to-one NAT. In other words, PAT is used, and connections are tracked using the original source
address and source port combinations, as well as the allocated source port. This is the same behavior as the
overload IP pool type, which you will learn about later.
Optionally, you may select a fixed port, in which case the source port translation is disabled. With a fixed port,
if two or more connections require the same source port for a single IP address, only one connection can
establish.
In the example shown on this slide, a firewall policy from internal to wan1 (IP address 100.64.100.10) is
created, and the user initiates traffic from source 10.10.10.10:1025 destined for 192.168.10.10:80. Because
NAT is enabled on the firewall policy, the source IP address is translated to the egress interface IP with port
translation.

DO NOT REPRINT
© FORTINET
IP Pools are a mechanism that allow sessions leaving the FortiGate firewall to use NAT. An IP pool defines a
single IP address or a range of IP addresses to be used as the source address for the duration of the session.
These assigned addresses will be used instead of the IP address assigned to that FortiGate interface.
IP pools are usually configured in the same range as the interface IP address.
When you configure the IP pools that will be used for NAT, there is a limitation that you must take into
account. If the IP addresses in the IP pool are different from the IP addresses that are assigned to the
interface(s), communications based on those IP addresses may fail if the routing is not properly configured.
For example, if the IP address assigned to an interface is 172.16.100.1/24, you cannot choose 10.10.10.1 to
10.10.10.50 for the IP pool unless appropriate routing is configured.
There are four types of IP pools that can be configured on the FortiGate firewall:
• Overload
• One-to-one
• Fixed port range
• Port block allocation

DO NOT REPRINT
© FORTINET
If you use an IP pool, the source address is translated to an address from that pool, rather than the egress
interface address. The larger the number of addresses in the pool, the greater the number of connections that
can be supported. For example, in an enterprise network where you require a greater number of connections,
or in a network where you want one subnet to use one specific public IP over another to restrict access based
on source IP address.
The default IP pool type is overload. In the overload IP pool type, a many-to-one or many-to-few relationship
and port translation is used.
In this example, source IP 10.10.10.10 will be translated to an IP address from the IP pool
(100.64.100.2 – 100.64.100.5).

DO NOT REPRINT
© FORTINET
In the one-to-one pool type, an internal IP address is mapped with an external address on a first-come, first-
served basis.
There is a single mapping of an internal address to an external address. Mappings are not fixed and, if there
are no more addresses available, a connection will be refused.
Also, in one-to-one, PAT is not required. In the example on this slide, you can see the same source port is
shown for both the ingress and egress address.

DO NOT REPRINT
© FORTINET
The fixed port range IP pool type associates internal IP address ranges and external IP address ranges, and
disables PAT. It allows fixed mapping of the internal start IP or internal end IP range to the external start IP or
external end IP range.
The example on this slide shows a fixed port range IP pool. The internal address range 10.0.1.10 to
10.0.1.11 maps to the external address range 10.200.1.7 to 10.200.1.8.

DO NOT REPRINT
© FORTINET
The two CLI outputs shown on this slide illustrate the behavior difference between the port block allocation IP
pool type and the default overload IP pool type.
Using hping, a rogue client generates many SYN packets per second. In the first example, the port block
allocation type limits the client to 64 connections for that IP pool. Other users will not be impacted by the
rogue client.
In the second example, the overload type imposes no limits, and the rogue client uses many more
connections in the session table. Other users will be impacted.

DO NOT REPRINT
© FORTINET
VIPs are DNAT objects. For sessions matching a VIP, the destination address is translated: usually a public
Internet address is translated to a server’s private network address. VIPs are selected in the firewall policy’s
Destination field.
The default VIP type is static NAT. This is a one-to-one mapping, which applies for incoming and outgoing
connections; that is, an outgoing policy with NAT enabled would use the VIP address instead of the egress
interface address. However, this behavior can be overridden using an IP pool.
The static NAT VIP can be restricted to forward only certain ports. For example, connections to the external IP
on port 8080 map to the internal IP on port 80.
On the CLI, you can select the NAT type as load-balance and server-load-balance. Plain load
balancing distributes connections from an external IP address to multiple internal addresses. Server load
balancing builds on that mechanism, using a virtual server and real servers, and provides session persistence
and server availability check mechanisms.
VIPs should be routable to the external facing (ingress) interface. FortiOS responds to ARP requests for VIP
and IP pool objects. ARP responses are configurable.

DO NOT REPRINT
© FORTINET
In this example, source IP address 192.168.10.10 is trying to access destination IP address

100.64.100.22 over port TCP 80.
Connections to the VIP 100.64.100.22 are NATed to the internal host 10.10.10.10.
Because this is static NAT, all NATed outgoing connections from 10.10.10.10 will use the VIP address in
the packet’s destination field, not the egress interface’s address.

DO NOT REPRINT
© FORTINET
In FortiOS, VIPs and firewall address objects are completely different, they are stored separately with no
overlap. By default, firewall address objects do not match VIPs. In the example shown on this slide, the all
address object as a destination in the first policy does not include any VIPs, so traffic destined to the
Webserver VIP will skip the first policy and match the second Allow_access. In order for the first policy to
match the VIP, you either need to edit the policy on the CLI and set match-vip enable, which allows
address objects to match the VIP address, or change the destination address of the first policy to be the VIP
in question.
Traffic is permitted to fall through to the next policy; however, when you use VIP firewall policies, there can be
some exceptions.
When VIP(s) are configured, for incoming (WAN to LAN) connections, it will be first matched against the VIP
table.
In the example shown on this slide, a firewall policy from WAN to LAN is configured with a specific source
and the action is Deny. There is second firewall policy that is allowing access to the VIP (the destination
address). Even though the deny firewall policy is at the top of the list, the denied source is still allowed by the
second firewall policy to access the VIP.
In order to block traffic from the denied source, you must enable set match-vip enable in the deny
firewall policy, which skips the VIP id checking. Alternatively, you can configure the destination address as the
virtual IP in the deny policy instead of all.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand firewall policy NAT.
Next, you’ll learn about central NAT.

DO NOT REPRINT
© FORTINET
After completing this section, you should know how to configure central NAT.
By demonstrating competence in configuring central NAT to perform SNAT and DNAT, you will be able to use
NAT on a more granular level to control IP address, protocol, and port translation.

DO NOT REPRINT
© FORTINET
By default, central NAT is disabled and can only be enabled on the CLI. After central NAT is enabled, these
two options are available to be configured on the GUI:
• Central SNAT
• DNAT & Virtual IPs
What happens if you try to enable central NAT, but there are still IP pool or VIPs configured in firewall
policies?
The CLI will not allow this and will present with a message referencing the firewall policy ID with the VIP or IP
pool. You must remove VIP or IP pool references from existing firewall policies in order to enable central NAT.
Central SNAT is mandatory for the new NGFW mode in policy-based in FortiOS 5.6.

DO NOT REPRINT
© FORTINET
Starting in FortiOS 5.6, you can have more granular control based on source and destination interfaces in the
central SNAT policy, over traffic passing through firewall policies.
You can now define matching criteria in the central SNAT policy, based on:
• Source interface
• Destination interface
• Source address
• Destination address
• Protocol
• Source port
On FortiGate, the central SNAT policy is applied to all firewall policies and not to a specific firewall policy. The
NAT on the firewall policy controls whether the central SNAT is used or not. If NAT is enabled on a firewall
policy, central SNAT is used.
If the central SNAT policy criteria matches the traffic based on multiple firewall policies, the central SNAT
policy will be applied to those firewall policies, as long as NAT is enabled on those firewall policies.
What happens if NAT is enabled on a firewall policy when there is no matching central SNAT policy or no
central SNAT policy configured? In this case, if no matching central SNAT policy exists, then FortiGate will
automatically use the outgoing interface IP address for the source NAT.
Similar to firewall policies, a central SNAT policy is processed from top to bottom and if a match is found,
source address and source port are translated based on that central SNAT policy.

DO NOT REPRINT
© FORTINET
In the example shown on this slide, the central SNAT policy translates the source IP address to the defined IP
pool address (100.64.100.5). However, the translation takes place only if the traffic matches all the
variables defined in the central SNAT policy, that is, traffic from the source IP address through the source
interface internal to FortiGate must be destined for destination IP address (192.168.10.10) through
destination interface wan1 and the protocol must be TCP. For illustration purposes, only a single IP address is
used for the destination, and the IP pool type is set to overload with a single IP address.
The firewall policy is created from internal to wan1 with NAT enabled. Remember that the NAT option on the
firewall policy controls whether or not a central SNAT policy is used.
If the user tries any TCP-based sessions (for example http, https) to the destination IP address
192.168.10.10, the source IP address will be translated to an IP pool address or addresses defined in the
central NAT policy.
What if the user tries to send any ICMP or UDP-based traffic to 192.168.10.10? Will the source address be
translated to the IP pool defined in the central NAT policy?
As the central SNAT policy does not match, FortiGate will automatically use the outgoing interface IP address
wan1 for the source NAT. What if the user tries TCP-based traffic to another destination IP address,
192.168.10.20? Will the source address be translated to the IP pool defined in the central NAT policy?
Again, the destination IP address of 192.168.10.20 does not match the central NAT policy, so FortiGate
will use the outgoing interface IP address (wan1) for the source NAT.

DO NOT REPRINT
© FORTINET
Traditionally on FortiGate, VIPs are selected in the firewall policy as the destination address.
On FortiGate, you can configure DNAT and VIPs for DNAT. As soon as a VIP is configured, FortiGate
automatically creates a rule in the kernel to allow DNAT to occur. No additional configuration is required.
Do you lose the granularity of being able to define a firewall policy for a specific VIP and services?
No, you don’t. If you have several WAN-to-internal policies and multiple VIPs, and you want to allow specific
services for specific VIPs, you can define each firewall policy with the destination address of the mapped IP of
the VIP, and select the appropriate services to allow or deny.
Note that if both central SNAT and central DNAT (VIP) are configured, the outgoing (internal-to-WAN) traffic
will source NAT to the DNAT or VIP address, based on the central SNAT and DNAT (VIP) configurations.

DO NOT REPRINT
© FORTINET
In the example shown on this slide, a DNAT and VIP rule is created to map external IP address 100.64.100.22
to internal IP address 10.10.10.10. Remember, as soon as a VIP is created, a rule is created in the kernel to
allow DNAT to occur.
The firewall policy from wan1 to internal is created with the destination address all or Mapped IP
Address/Range (10.10.10.10) of the VIP.
The source IP address 192.168.10.10 is trying to access the destination IP address 100.64.100.22 over port
TCP 80. Connections to the VIP 100.64.100.22 are NATed to the internal host 10.10.10.10, without any
additional configuration.

DO NOT REPRINT
© FORTINET
Central NAT can be disabled on the CLI by running set central-nat disable under the config
system setting. What happens to firewall policies that are using central SNAT and DNAT rules, if central
NAT is disabled?
For new firewall sessions, the incoming to outgoing firewall policies may still work using the egress interface
IP address. However, the incoming to outgoing firewall policies will not use the IP pool addresses, which were
previously tied to the central SNAT policy. If you need to use the IP pool, you need to edit the firewall policy to
use the IP pool.
Egress-to-ingress firewall policies that use DNAT and VIP will stop working because, in central NAT, the
destination address in the firewall policy is simply an address object, not an actual VIP. Without the central-nat
hook into the DNAT table, the address object will cause a forward policy check failure—the traffic will be
denied by policy ID 0.
You need to edit the egress-to-ingress firewall policies and select VIP as the destination address.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand central NAT.
Next, you’ll learn about session helpers.

DO NOT REPRINT
© FORTINET

• Understand how session helpers work
• Use a session helper for VoIP
By demonstrating competence in understanding how session helpers work, you will be able to use session
helpers to analyze data in the packets of some protocols and allow those protocols to pass traffic through
FortiGate.

DO NOT REPRINT
© FORTINET
Some application layer protocols are not fully independent of the lower layers, such as the network or
transport layers. The addresses may be repeated in the application layer, for example. If the session helper
detects a pattern like this, it may change the application headers, or create the required secondary
connections.
A good example of this is an application that has both a control channel and a data or media channel, such as
FTP. Firewalls will typically allow the control channel and rely on the session helpers to handle the dynamic
data or media transmission connections.
When more advanced application tracking and control is required, an application layer gateway (ALG) can be
used. The VoIP profile is an example of an ALG.

DO NOT REPRINT
© FORTINET
In the examples shown on this slide, the media recipient address in the SIP SDP payload is modified to reflect
the translated IP address.
Notice how, because firewall policies are stateful, a pinhole is opened to allow reply traffic,
even though you have not explicitly created a firewall policy to allow incoming traffic. This concept is used with
some other protocols, such as NAT-T for IPsec.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand session helpers.
Next, you’ll learn about sessions.

DO NOT REPRINT
© FORTINET

• Understand the session table on FortiGate
• Understand the session TTL
• Analyze session diagnose command output
• Understand TCP UDP and ICMP states on FortiGate
By demonstrating competence in understanding how a session table keeps track of the session information,
you will be better able to use that information to understand the actions applied to traffic, such as SNAT,
DNAT, and routing.

DO NOT REPRINT
© FORTINET
You can view the All Sessions page on the GUI, but the CLI provides more information regarding sessions in
the session table.
Firewall performance of connections for each session, and the maximum number of connections, are
indicated by the session table. However, if your FortiGate contains FortiASIC NP chips designed to accelerate
processing without loading the CPU, the session table information may not be completely accurate, because
the session table reflects what is known to, and processed by, the CPU.

DO NOT REPRINT
© FORTINET
Each session on FortiGate can idle for a finite time, which is defined by time to live (TTL). When the FortiGate
detects the session is idle after some time of inactivity, and TTL is reached, the session is deleted from the
session table.
Because the session table has a finite amount of RAM that it can use on FortiGate, adjusting the session TTL
can improve performance. There are global default timers, session state timers, and timers configurable in
firewall objects.

DO NOT REPRINT
© FORTINET
The diagnose sys session command tree provides options to filter, clear, or show the list of sessions.
You can also list brief information about sessions by running the get system session list command.
Before looking at the session table, first build a filter. To look at our test connection, you can filter on dst
10.200.1.254 and dport 80.

DO NOT REPRINT
© FORTINET
In the example shown on this slide, you can see the session TTL, which reflects how long FortiGate can go
without receiving any packets for this session, until it will remove the session from its table.
Here you can see the routing and NAT actions that apply to the traffic. The firewall policy ID is also tracked.
The proto_state for TCP is taken from its state machine, which you’ll learn about in this lesson.

DO NOT REPRINT
© FORTINET
In the example shown on this slide, you can see the session TTL, which reflects how long FortiGate can go
without receiving any packets for this session, until it will remove the session from its table.
Here you can see the routing and NAT actions that apply to the traffic. The firewall policy ID is also tracked.
The proto_state for TCP is taken from its state machine, which you’ll learn about in this lesson.

DO NOT REPRINT
© FORTINET
Earlier in this lesson, you learned that the session table contains a number that indicates the connection’s
current TCP state. These are the states of the TCP state machine. They are single digit values, but
proto_state is always shown as two digits. This is because FortiGate is a stateful firewall and keeps track
of the original direction (client-side state) and the reply direction (server-side state). If there are too many
connections in the SYN state for long periods of time, this indicates a SYN flood, which you can mitigate with
DoS policies.
This table and flow graph correlate the second digit value with the different TCP session states. For example,
when the FortiGate receives the SYN packet, the second digit is 2. It goes to 3 once the SYN/ACK is
received. After the three-way handshake, the state value changes to 1.
When a session is closed by both sides, FortiGate keeps it in the session table for a few seconds more, to
allow any out-of-order packets that could arrive after the FIN/ACK packet. This is the state value 5.

DO NOT REPRINT
© FORTINET
Although UDP is a message-oriented, stateless protocol, it doesn’t inherently require confirmed bidirectional
connections like TCP, so there is no connection state. However, FortiGate’s session table does use the
proto_state= field to track the unidirectional UDP as state 0, and the bidirectional UDP as state 1.
When FortiGate receives the first packet, it creates the entry and sets the state to 0. If the destination replies,
FortiGate updates the state flag to 1 for the remainder of the conversation.
Notably, ICMP, such as ping and traceroute, have no protocol state and it will always show
proto_state=00.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand sessions.
Next, you’ll learn about best practices and troubleshooting NAT.

DO NOT REPRINT
© FORTINET

• Identify common NAT issues by reviewing traffic logs
• Monitor NAT sessions using diagnose commands
• Use VIP filters for central NAT
• Use NAT implementation best practices
By demonstrating competence in using traffic logs, diagnose commands, VIP filters, and best practices for
NAT implementation, you should be able to monitor for and troubleshoot common NAT issues and
successfully implement NAT in your network.

DO NOT REPRINT
© FORTINET
NAT port exhaustion occurs when there is so much traffic traversing the border and being translated, that all
ports are being used. When NAT port exhaustion occurs, FortiGate informs the administrator by displaying the
log shown on this slide, with a severity of critical.
To address NAT port exhaustion, you need to take one of the following actions:
• Create an IP pool that has more than one external IP tied to it (so it load balances across them).
• Reduce the traffic traversing the border.
To receive important logs like this one, you must make sure that the necessary logging is enabled. On the
FortiGate GUI, click Log&Report > Log Settings, to check that the default setting, logging to disk or
memory, is activated.

DO NOT REPRINT
© FORTINET
NAT port exhaustion is also highlighted by a rise in the clash counter from the diagnose system session
stat command.

DO NOT REPRINT
© FORTINET
You can use diagnose firewall ippool-all list command which will lists all of the configured
NAT IP pools with their NAT IP range and type.

DO NOT REPRINT
© FORTINET
The diagnose firewall ippool-all stats shows the stats for all of the IP pools.
The stats command provide the following data and information:

• NAT sessions per IP pool
• Total tcp sessions per IP pool
• Total udp sessions per IP pool
• Total others (non-tcp and non-udp) sessions per IP pool
Optionally, you can filter the output for specific IP pool by using the name of IP pool.

DO NOT REPRINT
© FORTINET
The Services option has been added to VIP objects in FortiOS 5.6. When services and portforward are
configured, only a single mapped port can be configured. However, multiple external ports can be mapped to
that single internal port.
This configuration was made possible to allow for complex scenarios where multiple sources of traffic are
using multiple services to connect to a single computer, while requiring a combination of source and
destination NAT, and not requiring numerous VIPs to be bundled into VIP groups.
VIPs with different services are considered non-overlapping.

DO NOT REPRINT
© FORTINET
Use the following best practices when implementing NAT:
• Avoid the misconfiguration of an IP pool range:

• Double-check the start and end IPs of each IP pool.
• Ensure that the IP pool does not overlap with addresses assigned to FortiGate interfaces or to any
hosts on directly connected networks.
• If you have internal and external users accessing the same servers, use split DNS to offer an
internal IP to internal users so that they don’t have to use the external-facing VIP.
• Don’t enable NAT for inbound traffic unless it is required by an application. If, for example, NAT is enabled
for inbound SMTP traffic, the SMTP server might act as an open relay.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
• Understand NAT and PAT.

• Understand the different configuration modes for NAT.
• Configure a firewall policy to perform SNAT and DNAT (VIPs).
• Configure central NAT.
• Understand session helpers and use a SIP session helper for VoIP.
• Understand and interpret the session table.
• Analyse session diagnose command output.
• Understand TCP, UDP, and ICMP states.
• Use traffic logs to identify common NAT issues and monitor NAT sessions using session diagnose
commands.
• Use NAT implementation best practices.

DO NOT REPRINT
© FORTINET
No part of this publication may be reproduced in any form or by any means or used to make any
derivative such as translation, transformation, or adaptation without permission from Fortinet Inc.,
as stipulated by the United States Copyright Act of 1976.
Copyright© 2018 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet,
Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company
names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and
actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein
represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written
contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified
performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For
absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate.
Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify,
transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.

FortiGate Infrastructure Study Guide Online PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

FortiGate Infrastructure Study Guide Online PDF

Hochgeladen von

Copyright:

Verfügbare Formate

DO NOT REPRINT

FortiGate Infrastructure Study Guide

Fortinet Network Security Expert Program (NSE)

FortiGate Infrastructure Study Guide 4

In this lesson, you will explore the following topics:

FortiGate Infrastructure Study Guide 5

After completing this section, you should be able to:

FortiGate Infrastructure Study Guide 6

FortiGate Infrastructure Study Guide 7

For each session, FortiGate performs two routing lookups:

FortiGate Infrastructure Study Guide 8

FortiGate Infrastructure Study Guide 9

FortiGate Infrastructure Study Guide 10

FortiGate Infrastructure Study Guide 11

FortiGate Infrastructure Study Guide 12

FortiGate Infrastructure Study Guide 13

FortiGate Infrastructure Study Guide 14

FortiGate Infrastructure Study Guide 15

FortiGate Infrastructure Study Guide 16

Good job! You now understand routing in FortiGate.

FortiGate Infrastructure Study Guide 17

After completing this section, you should be able to:

FortiGate Infrastructure Study Guide 18

Which routes, besides the static routes, are displayed here?

• Directly connected subnets

Which configured routes aren’t displayed in the routing table monitor?

FortiGate Infrastructure Study Guide 19

FortiGate Infrastructure Study Guide 20

The following values are the default distances on FortiGate:

FortiGate Infrastructure Study Guide 21

FortiGate Infrastructure Study Guide 22

FortiGate Infrastructure Study Guide 23

FortiGate Infrastructure Study Guide 24

Next, you’ll learn about equal cost multipath routing.

FortiGate Infrastructure Study Guide 25

After completing this section, you should be able to:

FortiGate Infrastructure Study Guide 26

FortiGate Infrastructure Study Guide 27

FortiGate Infrastructure Study Guide 28

FortiGate Infrastructure Study Guide 29

FortiGate Infrastructure Study Guide 30

FortiGate Infrastructure Study Guide 31

Good job! You now understand ECMP routing.

Next, you will learn about reverse path forwarding.

FortiGate Infrastructure Study Guide 32

After completing this section, you should be able to:

FortiGate Infrastructure Study Guide 33

There are two RPF methods: loose and strict.

FortiGate Infrastructure Study Guide 34

FortiGate Infrastructure Study Guide 35

So how can you fix this problem?

FortiGate Infrastructure Study Guide 36

RPF can be either strictly or loosely enforced.

FortiGate Infrastructure Study Guide 37

FortiGate Infrastructure Study Guide 38

So what happens in the same scenario when strict RPF is used?

FortiGate Infrastructure Study Guide 39

FortiGate Infrastructure Study Guide 40

Good job! You now understand RPF.

Next, you will learn some routing best practices.

FortiGate Infrastructure Study Guide 41

After completing this section, you should be able to:

FortiGate Infrastructure Study Guide 42