FortiGate II Student Guide-Online

DO NOT REPRINT
FORTINET
FortiGate II
Student Guide
for FortiGate 5.2.1
DO NOT REPRINT
FORTINET
FortiGate II Student Guide
for FortiGate 5.2.1
Last Updated: 10 June 2015
Fortinet, FortiGate, and FortiGuard are registered trademarks of Fortinet, Inc., and other Fortinet
names herein may also be trademarks, registered or otherwise, of Fortinet. All other product or
company names may be trademarks of their respective owners. Copyright 2002 - 2015 Fortinet, Inc.
All rights reserved. Contents and terms are subject to change by Fortinet without prior notice. 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.
DO NOT REPRINT
FORTINET
Table of Contents
VIRTUAL LAB BASICS ...................................................................................7
Topology..................................................................................................................................8
Logging In ...............................................................................................................................8
Disconnections/Timeouts .............................................................................................................................13
Transferring Files to the VM....................................................................................................13
Using HTML5 Instead of Java ................................................................................................13
Screen Resolution ...................................................................................................................14
International Keyboards ..........................................................................................................14
Troubleshooting Tips ..............................................................................................................15
INITIALIZING THE LAB ...................................................................................17
Basic Network Settings ...........................................................................................................17
ROUTING......................................................................................................18
Lab 1: Router Configuration & Troubleshooting .....................................................................18

Objectives.....................................................................................................................................................18
Time to Complete .........................................................................................................................................18
Exercise 1 Connectivity Troubleshooting ..............................................................................19
Exercise 2 Link Health Monitoring .........................................................................................22
Exercise 3 Failover & Load Balancing Using Static Routing .................................................25
Exercise 4 WAN Link Load Balancing ...................................................................................28

DO NOT REPRINT
FORTINET
VIRTUAL DOMAINS .......................................................................................30
Lab 1: Virtual Domains............................................................................................................30

Objectives.....................................................................................................................................................30
Time to Complete .........................................................................................................................................30
Exercise 1 Creating VDOMs & VDOM Objects .....................................................................31
TRANSPARENT MODE ...................................................................................36
Lab 1: Transparent Mode VDOMs ..........................................................................................36

Objectives.....................................................................................................................................................36
Time to Complete .........................................................................................................................................36
Transparent Mode Topology ........................................................................................................................36
Exercise 1 Transparent VDOMs ............................................................................................37
Exercise 2 Inter-VDOM Links.................................................................................................38
HIGH AVAILABILITY ......................................................................................41
Lab 1: High Availability............................................................................................................41

Objectives.....................................................................................................................................................41
Time to Complete .........................................................................................................................................41
HA Topology.................................................................................................................................................41
Exercise 1 Configuring HA & Observing Failover ..................................................................42
Exercise 2 Configuring a Non-Synchronizing HA Management Port ....................................45
ADVANCED IPSEC VPN ................................................................................47
Lab 1: Advanced IPsec VPN ..................................................................................................47

Objectives.....................................................................................................................................................47
Time to Complete .........................................................................................................................................47
Exercise 1 Configuring an IPsec VPN ...................................................................................48
Exercise 2 Configuring a Redundant IPsec VPN ..................................................................51
Lab 2: IPsec VPN with FortiClient...........................................................................................53

Objectives.....................................................................................................................................................53
Time to Complete .........................................................................................................................................53
DO NOT REPRINT
FORTINET
Exercise 1 Configuring the FortiGate as a VPN Gateway .....................................................54
Exercise 2 Configuring and Testing FortiClient .....................................................................56
INTRUSION PREVENTION SYSTEM ..................................................................58
Lab 1: Intrusion Prevention System ........................................................................................58

Objectives.....................................................................................................................................................58
Time to Complete .........................................................................................................................................58
Exercise 1 Blocking Known Exploits ......................................................................................59
Exercise 2 Mitigating a DoS Attack........................................................................................62
Exercise 3 Creating Custom Signatures ................................................................................63
FORTINET SSO ............................................................................................64
Lab 1: Fortinet Single Sign On ................................................................................................64

Objectives.....................................................................................................................................................64
Time to Complete .........................................................................................................................................64
Exercise 1 Installing FSSO on a Windows Server ................................................................65
Exercise 2 Configuring FSSO on FortiGate ...........................................................................69
Exercise 3 Testing FSSO On Authentication.........................................................................71
CERTIFICATE OPERATIONS ...........................................................................72
Lab 1: Certificate Operations ..................................................................................................72

Objectives.....................................................................................................................................................72
Time to Complete .........................................................................................................................................72
Exercise 1 Creating a Certificate Request.............................................................................73
Exercise 2 SSL Deep Inspection ...........................................................................................81
DATA LEAK PREVENTION..............................................................................84
Lab 1: Data Leak Prevention ..................................................................................................84

Objectives.....................................................................................................................................................84
Time to Complete .........................................................................................................................................84
DO NOT REPRINT
FORTINET
Exercise 1 Blocking Files by Type .........................................................................................85
Exercise 2 Quarantining a User that is Leaking Sensitive Data ............................................87
Exercise 3 DLP Fingerprinting ...............................................................................................88
IPV6 ............................................................................................................90
Lab 1: IPv6 Transition Technologies ......................................................................................90

Objectives.....................................................................................................................................................90
Time to Complete .........................................................................................................................................90
Exercise 1 IPv6 Setup............................................................................................................91

Exercise 2 NAT64 .......................................................................................................................................93
Exercise 3 Using IPsec to Tunnel IPv6 over an IPv4 Network ....................................................................94
APPENDIX A: ADDITIONAL RESOURCES........................................................97
APPENDIX B: PRESENTATION SLIDES............................................................98
Module 11: Routing .................................................................................................................99
Module 12: Virtual Domains ....................................................................................................143
Module 13: Transparent Mode ................................................................................................174
Module 14: High Availability ....................................................................................................190
Module 15: Advanced IPsec VPN...........................................................................................229
Module 16: Intrusion Prevention System ................................................................................260
Module 17: FSSO....................................................................................................................302
Module 18: Certificate-Based Operations ...............................................................................327
Module 19: Data Leak Prevention ..........................................................................................372
Module 20: Diagnostics...........................................................................................................392
Module 21: Hardware Acceleration.........................................................................................433
Module 22: IPv6 ......................................................................................................................476

DO NOT REPRINT Virtual Lab Basics Topology
FORTINET
Virtual Lab Basics
In this class, you will use a virtual lab for hands-on exercises. This section explains how to connect to
the lab and its virtual machines. It also shows the topology of the virtual machines in the lab.
Note: If your trainer asks you to use a different lab, such as devices physically located in
your classroom, please ignore this section. This applies only to the virtual lab accessed
through the Internet. If you do not know which lab to use, please ask your trainer.
FortiGate II Student Guide 7

DO NOT REPRINT Virtual Lab Basics Topology
FORTINET
Topology
port2
10.200.1.241
FortiManager FortiAnalyzer
WIN-LOCAL port1 port1
10.0.1.10 10.0.1.241 10.0.1.210
10.0.1.254/24 port3
port3 10.200.1.210
LOCAL
port2 port1
10.200.2.1/24 10.200.1.1/24
LINUX
10.200.2.254 10.200.1.254
eth2 eth1
eth0
eth4 eth3
10.200.4.254 10.200.3.254
REMOTE
10.200.4.1/24 10.200.3.1/24
port5 port4
WIN-REMOTE
10.0.2.10 port6
10.0.2.254/24
Logging In
1. Run the System Checker. This will fully verify both:
compatibility with the virtual lab environment's software, and
that your computer can connect
It can also diagnose problems with your Java Virtual Machine, firewall, or web proxy.
Use the URL for your location.
North America/South America:
https://remotelabs.training.fortinet.com/training/syscheck/?location=NAM-West

DO NOT REPRINT Virtual Lab Basics Logging In
FORTINET
Europe/Middle East/Africa:
https://remotelabs.training.fortinet.com/training/syscheck/?location=Europe
Asia/Pacific:
https://remotelabs.training.fortinet.com/training/syscheck/?location=APAC
If a security confirmation dialog appears, click Run.
If your computer successfully connects to the virtual lab, the result messages for the browser and
network checks will each display a check mark icon. Continue to the next step.
If a browser test fails, this will affect your ability to access the virtual lab environment. If a network
test fails, this will affect the usability of the virtual lab environment. For solutions, either click the
Support Knowledge Base link or ask your trainer.
2. With the user name and password from your trainer, log into the URL for the virtual lab. Either:

FORTINET
https://remotelabs.training.fortinet.com/
https://virtual.mclabs.com/
3. If prompted, select the time zone for your location, then click Update.
This ensures that your class schedule is accurate.
4. Click Enter Lab.
A list of virtual machines that exist in your virtual lab should appear.

FORTINET
From this page, you can access the console of any of your virtual devices by either:
clicking on the devices square, or
selecting System > Open.

FORTINET
5. Click K2-Win-Student to open a connection to that server.
A new window should open within a few seconds. (Depending on your accounts preferences, the
window may be a Java applet. If this fails, you may need change browser settings to allow Java to
run on this web site. You also may need to review and accept an SSL certificate.)
Depending on the virtual machine, the applet provides access to either the GUI or a text-based
CLI. Connections to Windows machines will use a Remote Desktop-like GUI. The applet
should automatically log in, then display the Windows desktop. For most lab exercises, you will
connect to this VM.

DO NOT REPRINT Virtual Lab Basics Transferring Files to the VM
FORTINET
Disconnections/Timeouts
If your computers connection with the virtual machine times out or if you are accidentally
disconnected, to regain access, return to the initial window/tab that contains your sessions list of VMs
and open the VM again.
If your session frequently times out or does not connect, ask your instructor.
Transferring Files to the VM

When using the Java applet to connect to a VM, you can drag-and-drop files from your computer to
the VM. For example, if you have a FortiGate configuration file that you want to upload to your lab VM,
you could create it on your computer, then drag it into the Java application window that is connected to
the Windows VM. Usually the destination folder is C:\Uploads.
Alternatively, if you store files in a cloud service such as Dropbox or SugarSync, you can use the web
browser to download them to your VM instead.
Using HTML5 Instead of Java

When you open a VM, your browser may download and use a Java application to connect to the
virtual labs VM. This means that Java must be installed, updated, and enabled in your browser.
Alternatively, you can use HTML5 instead. Click the Settings button, then select Use Java Client. Click
Save & Disconnect, then log in again. (To use this preference, your browser must allow cookies.)

DO NOT REPRINT Virtual Lab Basics Screen Resolution
FORTINET
When connecting to a VM, your browser should then open a display in a new window or tab.
Screen Resolution
Some Fortinet devices' user interfaces require a minimum screen size.
In the Java client, to configure the screen resolution, click the arrow at the top of the window.
In the HTML 5 client, to configure screen resolution, open the System menu.
International Keyboards
If characters in your language dont display correctly, keyboard mappings may not be correct.

DO NOT REPRINT Virtual Lab Basics Troubleshooting Tips
FORTINET
To solve this in the HTML 5 client, open the Keyboard menu at the top of the window. Choose to either
display an on-screen keyboard, or send text from your computer to the VM's clipboard.
To solve this in the Java client, copy and paste between your computer and the Java applet. This
sends special characters or combinations using the keyboard icon at the top of the applet window.
Troubleshooting Tips
If the HTML 5 client does not work, try the Java client instead. Remembering this preference
requires that your browser allow cookies.
Do not connect to the virtual lab environment through a low-bandwidth or high-latency connection,
including VPN tunnels or wireless such as 3G or Wi-Fi. For best performance, use a stable
broadband connection such as a LAN.
Do not disable or block Java applets. On Mac OS X since early 2014, to improve security, Java
has been disabled by default. In your browser, you must allow Java for this web site. On
Windows, if the Java applet is allowed and successfully downloads, but does not appear to
launch, you can open the Java console while troubleshooting. To do this, open the Control
Panel, click Java, and change the Java console setting to be Show console.
Network firewalls can also block Java executables.
Note: JavaScript is not the same as Java.

DO NOT REPRINT Virtual Lab Basics Troubleshooting Tips
FORTINET
Prepare your computer's settings:

o Disable screen savers
o Change the power saving scheme so that your computer is always on, and does not go to
sleep or hibernate
If disconnected unexpectedly from any of the virtual machines (or from the virtual lab portal),
please attempt to reconnect. If unable to reconnect, please notify the instructor.
If during the labs, particularly when reloading configuration files, you see a message similar to the
one shown below, the VM is waiting for a response to the authentication server.
To retry immediately, go to the console and enter the CLI command:
exec update-now

DO NOT REPRINT Initializing the Lab Basic Network Settings
FORTINET
Initializing the Lab
Basic Network Settings
Before some exercises, you must upload prerequisite configuration files. They contain objects and
settings required by the exercises. To do this, you must be able to connect to that VM through your lab
network. This means that the VM must already have basic network settings, such as an IP address
that you can connect to.
If you have just attended FortiGate I, during that course, you have already done this. Otherwise,
configure basic network settings now. (The Student and Remote FortiGate may have been instantiated
from an unconfigured VM image.)
1. Connect to the console of the Student FortiGate. (To do this, in the virtual lab applet, go to
Operations > Connect to Secondary > Student.) Enter the CLI commands to configure port3.
conf system interface
edit port3
set ip 10.0.1.254/24
set allowaccess https ping ssh
end
2. Connect to the console of the Remote FortiGate. (In the virtual lab applet, go to Operations >
Connect to Secondary > Remote.) Enter the CLI commands to configure port4 and a default
gateway.
edit port4
set ip 10.200.3.1/24
end
conf route static
edit 0
set device port4
set gateway 10.200.3.254
end

DO NOT REPRINT Routing Lab 1: Router Configuration & Troubleshooting
FORTINET
Routing
Lab 1: Router Configuration & Troubleshooting
In this lab, you will configure the router settings and try scenarios to learn how FortiGate decides to
route packets. You will also troubleshoot and diagnose routing misconfigurations.
Objectives
Students will complete the following tasks:
Implement routing failover by using link health monitors
Balance the traffic among multiple links by WAN link load balancing and equal cost multipath
(ECMP)
Override static routes with policy routes
Diagnose routing issues
Time to Complete
Estimated: 40 minutes

FORTINET
Exercise 1 Connectivity Troubleshooting
From the Student Windows server you will connect to an external web site (or http://10.200.3.254/)
and observe the output of the diagnostic commands. Note that you must reload the web page for each
command tested in the steps below.
Initializing the Configuration

1. From the Win-Student computer, go to the Remote FortiGate's GUI:
http://10.200.3.1/
Log in as the account named admin. Leave the password blank.
2. Restore the configuration file that is required by this lab:
Resources\Routing\Remote\remote-routing.conf
FortiGate will reboot and load is new configuration.
3. Log on to the GUI on the Student FortiGate's GUI:
http://10.0.1.254/
Log in as the account named admin. Leave the password blank.
Resources\Routing\Student\\student-routing.conf
The FortiGate will reboot and load its new configuration.
Note: Upon reboot, the console may show a message similar to this:
waiting for authentication

This can occur if the initial request for license authentication did not succeed. To force
an immediate license authentication retry, enter:
execute update-now
Performing a Filtered Packet Capture

5. Open an SSH client such as PuTTY. Connect to the CLI of the Student FortiGate.
6. Start a packet capture. This will record packets that ingress/egress from FortiGate interfaces, if
they match the filter that you set. Capture only packets with a source address of 10.0.1.10 (the
Windows server) and the destination port number of 80, the IANA standard port number for
HTTP. This focuses output on your interest, ignoring irrelevant traffic.
diagnose sniffer packet any 'host 10.0.1.10 and port 80' 4

7. Open a web browser and go to any web site. (Notice that HTTPS-encrypted web sites use port
443 instead of port 80, so your filtered packet capture won't capture traffic to secure sites such
as https://www.twitter.com/.) Observe the output.
STUDENT # diagnose sniffer packet any 'host 10.0.1.10 and not port
22' 4

FORTINET
interfaces=[any]
filters=[host 10.0.1.10 and not port 22]
8.425242 port3 in 10.0.1.10.4680 -> 10.200.3.254.80: syn 2724505985
8.425574 port3 out 10.200.3.254.80 -> 10.0.1.10.4680: syn 3099662156

ack 2724505986
8.426190 port3 in 10.0.1.10.4680 -> 10.200.3.254.80: ack 3099662157
8.426218 port3 in 10.0.1.10.4680 -> 10.200.3.254.80: psh 2724505986

ack 3099662157
8.426516 port3 out 10.200.3.254.80 -> 10.0.1.10.4680: ack 2724506380

This is the three-way TCP handshake complete and the first exchange of data (psh). Notice that
because of the NAT action, we do not see the traffic on the outgoing interface.
Tracing the Packet Processing on FortiGate

8. Use a filter to record firewall policy actions for only packets that match the specific IP address and
service.
diagnose debug flow filter clear
diagnose debug flow filter addr 10.0.1.10
diagnose debug flow filter port 80
diagnose debug flow show console enable
diagnose debug flow show function enable
diagnose debug enable
diagnose debug flow trace start 5
Tip: Usually, it is better to filter by address and port, not source/destination address nor
source/destination port. Otherwise, you will only capture traffic in one direction not both
forward and reply.
9. Refresh the web page to trigger more traffic. To do this, either click the Refresh button or press
the F5 key. You should see packets captured such as these.
First, FortiGate receives the client's SYN signal on the ingress interface.
id=20085 trace_id=13 func=print_pkt_detail line=4368 msg="vd-root

received a packet(proto=6, 10.0.1.10:65229->10.200.3.254:80) from
port3. flag [S], seq 4030988021, ack 0, win 8192"
FortiGate allocates a new ID in the session table to track this session's states.
id=20085 trace_id=13 func=init_ip_session_common line=4517

msg="allocate a new session-000003fe"

FORTINET
FortiGate performs a gateway lookup. If this doesn't change (for example, due to ECMP), then
FortiGate will do this only once for each session, at the start.
id=20085 trace_id=13 func=vf_ip4_route_input line=1596 msg="find a

route: flags=00000000 gw-10.200.1.254 via port1"
FortiGate performs a firewall policy lookup.
id=20085 trace_id=13 func=fw_forward_handler line=671 msg="Allowed by

Policy-1: SNAT"
Source NAT (SNAT) is applied. (Notice that this is after routing.)
id=20085 trace_id=13 func=__ip_session_run_tuple line=2518 msg="SNAT

10.0.1.10->10.200.1.1:65229"
The server replies with SYN ACK.
id=20085 trace_id=14 func=print_pkt_detail line=4368 msg="vd-root

received a packet(proto=6, 10.200.3.254:80->10.200.1.1:65229) from
port1. flag [S.], seq 2497669735, ack 4030988022, win 5840"
For the reply traffic, FortiGate looks for, and finds, an existing matching session ID. (It does not
require a separate policy for reply traffic.)
id=20085 trace_id=14 func=resolve_ip_tuple_fast line=4427 msg="Find

an existing session, id-000003fe, reply direction"
Destination NAT (DNAT) is applied to reply traffic, the inverse of SNAT for initiator traffic.
id=20085 trace_id=14 func=__ip_session_run_tuple line=2532 msg="DNAT

10.200.1.1:65229->10.0.1.10:65229"
FortiGate performs a gateway lookup for the reply packet.
id=20085 trace_id=14 func=vf_ip4_route_input line=1596 msg="find a

route: flags=00000000 gw-10.0.1.10 via port3"
Tip: For most connectivity issues, exec ping, exec traceroute, and the diag
debug flow command provide enough information. To help you troubleshoot more
complex problems, you can combine information from diagnose debug flow with other
commands, such as diag sniffer packet and diag debug application.
10. In a group discussion with your instructor, discuss the output of these commands.
When would you use a packet capture instead of a processing flow trace?
Even if the LAN has only one client, what irrelevant packets might the packet capture show
if you did not filter the output?
In a real network, why should you configure your SSH client to save output to a text file,
instead of reading it in the window, as each packet is recorded?
In a real network, why should you disable packet capture and packet flow as soon as you
are done?

FORTINET
Exercise 2 Link Health Monitoring
When there are multiple paths to the same destination for example, if you have redundant ISP
connections you can use a link health monitor to provide failover. To monitor viability of each path to
an upstream device, FortiGate sends a signal to that destination, and listens for a reply.
Often, you'll configure FortiGate to use ICMP type 8 (ping), but it also supports UDP echo, TCP echo
and HTTP. If the device fails to respond after the number of retries that you have configured, then
FortiGate removes static routes associated with that gateway from its routing table.
When you configure FortiGate as part of a site-to-site VPN, the target is often the VPNs remote
gateway. This helps to detect dead tunnels.
1. In this lab, the Student FortiGate has 2 link health monitors. From the GUI on the Student
FortiGate device, go to Router > Static > Settings. Verify the link health monitor configuration.
Refer to Topology in this document to verify each FortiGates IP addresses.
First Entry:
Interface: port1
Gateway IP: 10.200.1.254
Server: 10.200.3.1
Second Entry:
Interface: port2
Gateway IP: 10.200.2.254
Server: 10.200.4.1
2. From the CLI of the Student FortiGate, start a packet capture:
diagnose sniffer packet any 'icmp' 4

Now you should observe the request/response traffic on port1, but there is no response on port2.
This is because of the Remote FortiGates current configuration. To stop the packet capture, press
Ctrl + C.
3. From the GUI on the Remote FortiGate, go to Router > Static > Settings. Click Create New and
configure these 2 link health monitor objects:
First:
Name: Port4
Interface: port4
Gateway 10.200.3.254

FORTINET
Health Check Enabled
Probe Type: Ping
Server: 10.200.1.1
Probe Interval(s) 5
Failure Threshold 5
Recovery Threshold 5
HA Priority 1
Update Routing Table Enabled
Bring Down (Up) Interface Disabled
Second:
Name: Port5
Interface: port5
Gateway 10.200.4.254
Health Check Enabled
Probe Type: Ping
Server: 10.200.2.1
Probe Interval(s) 5
Failure Threshold 5
Recovery Threshold 5
HA Priority 1
Update Routing Table Enabled
Bring Down (Up) Interface Disabled
4. From the CLI of the Student FortiGate, start a packet capture again:
diagnose sniffer packet any 'icmp' 4

Output should now show both the local probe, and the echo request/reply on port2. By adding
the link health monitor entry, you created a route back to this source in the kernels routing
table. Therefore FortiGates reverse path forwarding (RPF) check now accepts these packets.

FORTINET
5. View the gateway detection entries in the kernel routing table. Notice the destination and gateway
addresses.
# get router info kernel
tab=254 vf=0 scope=0 type=1 proto=14 prio=0

10.200.1.1/255.255.255.255/0->10.200.3.1/32 pref=0.0.0.0
gwy=10.200.1.254 dev=2(port1)
tab=254 vf=0 scope=0 type=1 proto=14 prio=0

10.200.2.1/255.255.255.255/0->10.200.4.1/32 pref=0.0.0.0
gwy=10.200.2.254 dev=3(port2)

FORTINET
Exercise 3 Failover & Load Balancing Using Static

Routing
1. Currently routing is set up for failover. The Student FortiGate has these routes:
0.0.0.0/0 port1 10.200.1.254 distance 10
0.0.0.0/0 port2 10.200.2.254 distance 20

The Remote FortiGate uses the same method: it implements a failover route by giving the second
one a higher administrative distance. FortiGate uses the route with a smaller distance, unless it is
unavailable (and therefore removed from the routing table). Then it loads and uses the second
route.
On the Student FortiGate, verify the routing table:
get router info routing-table all

You should observe that there is only one default route.
2. Examine the database or routes:
get router info routing-table database

You should observe that the second default route exists, but is not currently a selected route.
3. On the Win-Student computer, open a web browser. Execute the same commands used above
from the CLI on the Remote FortiGate device. You should observe a similar configuration.
Stop and Think

When will the second default route, listed in the database, be used?
If the primary link fails, FortiGate will use the redundant path (second default route). Link
failure could be if you accidentally unplug the network cable, or if the link health monitor
associated with that gateway detects that the path is broken.
4. On the Win-Student computer, open a web browser. Try to connect to the GUI of the Remote
FortiGate through port5.
http://10.200.4.1/
You should observe that this connection fails. This is because the Remote FortiGate has no
route back to the source on port4. Only a route back to the link health monitor exists.
Therefore we require a default route for that interface in the routing table. In order to have both
default routes in the routing table they must both be of equal distance.
5. On both the Student and Remote FortiGate, go to Router > Static > Static Routes. On the
Student FortiGate, edit port2 and set the distance to 10. On the Remote FortiGate, edit port5
and set the distance to 10.
6. Verify the routing table and route database:

FORTINET
get router info routing-table database
You should observe that the second route is now loaded into the routing table.
7. On the Win-Student computer, open a web browser. Try again to connect to the GUI of the
Remote FortiGate through port5:
http://10.200.4.1/
The connection should succeed now.
8. We now have a multi-path configuration: there are 2 available default routes, equally prioritized.
The priority is not used/visible in the routing table, but its in the forwarding information base (FIB).
Stop and Think

What is the difference between the routing table vs. the FIB?
FortiGates routing process generates the FIB. It is loaded into RAM, and the
table that FortiGate actually uses to look up where to forward the packet.
Usually, this lookup occurs when FortiGate receives the first packet in a session.
It can be useful to think of the routing table as the management plane and the
FIB as the forwarding plane. HA shows this difference.
On the primary, both the management plane and forwarding plane exist.
On the secondary, only the forwarding plane exists. It is derived from the
management plane of the primary.
By default, the priority is 0, so for multiple static routes to the same destination, ECMP is enabled.
FortiOS supports equal cost multi path (ECMP) routing for static, OSPF, and BGP routes.
Observe this in the FIB:
get router info kernel

There should be two entries with destination 0.0.0.0/0. Both entries should have prio=0.
9. By default, ECMP distributes load by using the source hash technique. This means same source
IP and same gateway.
In our example, because all traffic is coming from the same source address (the Windows server),
FortiGate will egress those packets towards the same gateway, so this is not an effective example
of load balancing. Therefore, for the purposes of this example, we will adjust the distribution
settings so that FortiGate distributes packets between valid routes, even if they are from the same
source IP. (You may see a similar scenario in real networks.)
On the Student FortiGate, go to Router > Static > Settings. Set the ECMP load balancing
method to Source-Destination IP based. This changes the priority of the static route.
10. On the Win-Student computer, open a web browser. Go to several web sites.
11. On the CLI of the Student FortiGate, verify that the traffic is distributed between the two
Internet connections:
diagnose sys session filter clear
diagnose sys session filter dport 80
diagnose sys session list | grep dev

FORTINET
Since these commands output the interface numbers and not their names, you can use the output
of the next CLI command to map the interface number to its name:
diagnose netlink interface list

Alternatively, use this packet capture command to show only TCP packets on port 80 with the
SYN flag:
diag sniffer packet any 'tcp[13]&2==2 and port 80' 4

12. Sometimes, you do not want to load balance all traffic. Some hosts and/or protocols may require a
specific gateway. To do this, you can use policy-based routing, which takes precedence over the
static routing table.
Create a policy route to force all outgoing HTTPS traffic on the Student FortiGate to use the
gateway 10.200.2.254. Go to Router > Static > Policy Routes. Click Create New and use these
settings:
Protocol: 6 (TCP)
Incoming Interface: port3
Destination Ports: From: 443 To: 443
Action Forward Traffic
Outgoing Interface: port2
Gateway Address: 10.200.2.254
Note: Link health monitoring also affects policy routes as well as static routes, so if
these do not work, check those settings.
13. Performing a packet capture while connecting to an HTTPS web site:
diagnose sniffer packet any 'port 443' 4

For example, from the web browser on the Windows server, connect to:
https://mail.google.com/
Alternatively, you can use https://10.200.3.254/ as a target while running the packet capture:
diagnose sniffer packet any 'host 10.200.3.254' 4

Verify that your policy-based routes are being used.

FORTINET
Exercise 4 WAN Link Load Balancing
In the previous exercise, you configured load balancing using two static routes with the same distance
and priority. In this exercise, you will use WAN link load balancing instead.
1. First, access the GUI of the Student FortiGate and delete the following objects:
The policy route created in the previous exercise under Static > Static > Policy Routes
The two default routes under Static > Static > Static Routes
The two firewall policies under Policy & Objects > Policy > IPv4
The two link health monitor objects under Router > Static > Settings
2. Go to System > Network > WAN Link Load Balancing, change the WAN Load Balancing to
Source-Destination IP and add two Interface Members.
First member:
Interfaces: port1
Gateway IP: 10.200.1.254
Second member:
Interfaces: port2
Gateway IP: 10.200.2.254
Click on Apply.
3. Go to Router > Static > Static Routes and add this default route:
Destination: 0.0.0.0/0.0.0.0
Device: wan-load-balance
Distance: 10
Priority: 0
4. Go to Policy & Objects > Policy > IPv4. Create a new firewall policy:
Source Address STUDENT_INTERNAL
Outgoing Interface wan-load-balance
Destination Address all
Schedule always

FORTINET
Services ALL
NAT Enabled
5. Open a web browser. Go to several web sites.

6. Verify that FortiGate is load balancing traffic between its 2 Internet connections:
diagnose sys session filter clear
diagnose sys session filter dport 80
diagnose sys session list | grep dev

Or:
diag sniffer packet any 'tcp[13]&2==2 and port 80' 4

After you run the diag sniffer command, you may need to refresh the web page in order to be able
to view the packet capture.
Stop and Think

How does WAN link load balancing simplify the configuration?
If you compare the FortiGate configuration in the previous exercise to the one in this
exercise, you will notice that in this case you had to create only one static route and only
one firewall policy for both ISPs. In the previous example, you have to create one route
and one firewall policy per ISP: 2 routes, and 2 ISPs. If your configuration had more
than 2 ISPs, this could mean many routes and firewall policies. So WAN link load
balancing could greatly reduce the number of routes and policies that you must
manage.

DO NOT REPRINT Virtual Domains Lab 1: Virtual Domains
FORTINET
Virtual Domains
Lab 1: Virtual Domains
In this lab, you will enable with VDOMs and configure inter-VDOM links.
Objectives
Use VDOMs to split a FortiGate into multiple virtual units
Create an administrative account with the access limited to one VDOM
Route traffic between VDOMs by using inter-VDOM links
Time to Complete

FORTINET
Exercise 1 Creating VDOMs & VDOM Objects
1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Student,
and log in as admin.
http://10.0.1.254/
Resources\Virtual-Domains\Student\Student-vdom.conf
FortiGate will reboot.
3. Before enabling VDOMs, use the CLI to view the current list of VDOMs.
diagnose sys vd list

This command shows the configured VDOMs. Notice that there are already VDOMs:
the root VDOM, which is the default VDOM for all interfaces
vsys_ha which is used for HA
vsys_fgfm which is used for FortiManager
We will not be discussing them further. However, notice that when we say enable VDOMs,
technically we really mean that we are enabling you to create more VDOMs. Some VDOMs are
actually inherent in FortiOS, and therefore it is not a separate feature that can be completely
disabled.
4. On the Student FortiGate, go to System > Dashboard > Status. In the System Information widget,
in the Virtual Domain row, click the Enable link.
FortiGate will automatically log you out.
5. Log in again.
Notice that now, the GUI initially displays the Global Configuration tab. To access the root VDOM,
click Virtual Domains which is at the bottom of the GUIs navigation menu on the left side.
6. Go to Global > VDOM > VDOM. Create and enable a new VDOM in NAT mode called customer.
Notice that, after that, the customer VDOM is listed and you can select it from the VDOM list by
clicking Virtual Domains in the lower left-hand corner of the GUI.
7. Create an administrator for the customer VDOM. To do this, in Global Configuration, go to Global
> Admin > Administrators and create a new administrator:
Administrator: customer-admin
Type: Regular
Password Fortinet
Administrator Profile prof-admin
Virtual Domain Customer

FORTINET
Note: After adding the customer VDOM to the list of Virtual Domain, remove the root
VDOM from that list so that the new administrator will be able to access only
customer, not root.
This account will only be able to log in through an interface in the customer VDOM.
8. Put the port3 interface, which connects to the internal network, in the customer VDOM. To do this,
go to Global > Network > Interfaces and edit port3. Change the Virtual Domain to customer.
Leave the port1 and port2 interfaces in the root vdom. This will provide a separation between the
customer VDOM and the VDOM (root) that is providing Internet or external access. This is a
common usage scenario.
9. Go to the CLI and look at the routing table for each VDOM:

Did the CLI reject the command? When VDOMs are enabled, in order to run this command, you
must be in the context of your VDOM in order for FortiGate to know which VDOMs routing table to
display.
To enter the customer VDOM context, enter:
config vdom
edit customer
Note: Be careful when typing VDOM names with the edit command.
VDOM names are case-sensitive, and the edit command can both modify and create.
For example, if you enter edit Root, you will not enter the pre-existing VDOM named
root. Instead, this will create and enter a new VDOM named Root.
10. Try again to look at the routing table.

11. Go to the root vdom to view its routing table:
next
edit root

12. Create an inter-VDOM link to connect the 2 VDOMs.

FORTINET
On the Student FortiGate, go to Global > Network > Interfaces.
Click next to Create New in the top left corner of the page, then select VDOM link. Create this
new VDOM Link:
Name: vlink
Interface #0 vlink0
Virtual Domain: root
IP/Network Mask: 10.10.100.1/30
Administrative
HTTPS, PING, SSH
Access:
Interface #1 vlink1
Virtual Domain: customer
IP/Network Mask: 10.10.100.2/30
Administrative
HTTPS, PING, SSH
Access:
After creating the inter-VDOM link, notice the 2 inter-VDOM sub-interfaces created and placed
within the root and customer VDOMs. These interfaces are named vlink0 and vlink1. They allow
communication between both VDOMs. IP addresses are not required on these interfaces, but can
help with troubleshooting routing issues (for example, when running an exec traceroute
command).
13. In the customer VDOM, the newly created inter-VDOM links interface requires a default route.
Click Virtual Domains > customer > Router > Static > Static Routes. Create this new route:
Destination IP/Mask: 0.0.0.0/0

FORTINET
Device: vlink1
Gateway: 10.10.100.1
14. FortiGate also requires a route for the root VDOM to the internal network.
Go to Virtual Domains > root > Router > Static > Static Routes. Create this new route:
Device: vlink0
Gateway: 10.10.100.2
15. In the root VDOM, create a zone that contains port1 and port2.
Go to Virtual Domains > root > System > Network > Interfaces. Click next to Create New and
create the new Zone.
Assign a name of External and specify port1 and port2 as members.
16. Create a firewall policy to allow traffic from the customer VDOM out to the Internet through the
interfaces. While in the root VDOM, go to Policy & Objects > Policy > IPv4 and create a new policy
for traffic to External:
Incoming Interface: vlink0
Source Address: STUDENT_INTERNAL
Outgoing Interface: External
Destination Address: All
Schedule: Always
Service: ALL
Action: ACCEPT
NAT: Enabled
17. Switch to the customer VDOM. Create another firewall policy that allows traffic from port3 to
vlink1:
Source Address: All
Outgoing Interface: vlink1
Destination Address: All
Schedule: Always

FORTINET
Service: ALL
Action: ACCEPT
NAT: Disabled
18. While in the customer VDOM, go to System > Network > DNS Servers and click Create New to
add DNS service on the port3 interface.
Interface: port3
Mode: Forward to System DNS
19. Connect to an external web site. Traffic should be flowing through both VDOMs now.
From a command prompt on the Win-Student computer, verify the path over the inter-VDOM link:
tracert d 4.2.2.2
20. On the Win-Student computer, log in to the customer VDOM (10.0.1.254) with the user name
and password customer-admin.
You can access the customer VDOM on port3 because it is a member interface of that VDOM.
Navigate through the GUI and examine what the VDOM administrator is allowed to control.
Since the customer-admin administrator can access to the customer VDOM only, they will not
automatically enter the Global Configuration, nor will they have access to it. The display of the GUI
will change as the customer-admin user has access to only the VDOM-specific objects.

DO NOT REPRINT Transparent Mode Lab 1: Transparent Mode VDOMs
FORTINET
Transparent Mode
Lab 1: Transparent Mode VDOMs
In this lab, you will configure one transparent mode VDOM. To interconnect 2 VDOMs without
requiring packets to egress from FortiGate, you will use an inter-VDOM link.
Objectives
Configure one transparent mode VDOM
Time to Complete
Transparent Mode Topology

After you upload the required configurations to each FortiGate, the logical topology will change to this.
REMOTE
FortiGate
inspect VDOM
link1 port1
link0
10.200.1.1/24 LINUX
Management IP
10.200.1.200/24 10.200.1.254
port3
eth1
10.0.1.254/24
STUDENT eth2
FortiGate 10.200.2.254
root VDOM
port2
10.200.2.1/24
WIN-STUDENT
10.0.1.10
eth0

FORTINET
Exercise 1 Transparent VDOMs
http://10.0.1.254/
Resources\Transparent-Mode\Student\Student-tp.conf
3. Log in again and go to System > Dashboard > Status. In the System Information widget, in the
Virtual Domain row, click the Enable link.
FortiGate will automatically log you out.
4. Log in again. Initially, the GUI will display the configuration for Global.
5. Go to Global > VDOM > VDOM and click Create New to add new VDOM. Configure the following
settings:
Name: inspect
Enable: enabled
Operation Mode: Transparent
Management IP/Netmask: 10.200.1.200/24
Default Gateway: 10.200.1.254

FORTINET
Exercise 2 Inter-VDOM Links
1. In the CLI, create an inter-VDOM link:
config global
config system vdom-link
edit link
set type ethernet
end
end
2. Next, you will move the port1 interface to the inspect VDOM. In the GUI go to Global > Network >
Interface and edit the port1 interface. From the Virtual Domain drop-down list select the inspect
VDOM. This is only possible because the port1 interface is not referenced by any firewall policies
or routing. Also ensure that Ping access is enabled on port1
3. Configure the inter-vdom link interfaces:
config global
config system interface
edit link0
set vdom root
set ip 10.200.1.1/24
set allowaccess ping ssh
next
edit link1
set vdom inspect
end
end
4. In the GUI go to Global > Network > Interface and review the inter-VDOM link interfaces
created above. Note that link0 and link1 are logical interfaces that allow communication
between the root and inspect VDOMs. An IP address is only configurable on the NAT/Route
mode VDOM interface.
5. Review the new VDOM tree display by selecting Virtual Domains and reviewing the root and
inspect VDOMs.

FORTINET
6. In the inspect VDOM, go to Policy & Objects > Policy > IPv4. Create the following policy to allow
traffic between the port1 and link1 interfaces initiated in either direction:
Incoming Interface: any
Source Address: all
Outgoing Interface: any
Destination Address: all
Schedule: always
Service: ALL
Action: ACCEPT
Enable AntiVirus under Security Profile and select default as the antivirus profile. Click OK to save
the change.
7. In the root VDOM, go to Policy & Objects > Policy > IPv4. Create a new policy for port3 to link0:
Source Address: all
Outgoing Interface: link0
Schedule: always
Service: ALL
Action: ACCEPT
Enable NAT: enabled
Logging Options: Log all sessions
8. To direct traffic from your Windows host to the inspect VDOM, in the root VDOM, go to Router
> Static > Static Routes. Create a new static route pointing to the inter-VDOM link using the
following settings:
Device: link0
Gateway: 10.200.1.254
Click OK.

FORTINET
9. Increase the cost of the priority of the port2 default route to 50, so that this is not the preferred
route.
10. On the Win-Student computer, verify that your hops are 10.0.1.254 and 10.200.1.254:
tracert d 10.200.3.1
11. Run a continuous ping to 10.200.1.254.
12. Download the EICAR antivirus test file from EICARs web site:
http://eicar.org
13. Go to Log & Report > Traffic Log > Forward Traffic and find related messages in the root VDOM
and a UTM message in the inspect VDOM.
14. From the GUI on the Student FortiGate, go to Global > Dashboard > Status. Click Dashboard in
the top left-hand corner of the page and then click Add Dashboard. Add a new single width
dashboard with the name of your choice.
15. Click Widget and add the All Sessions widget. Click on Column Settings and add the Virtual
Domain field. Try to download the virus again and check that there are sessions reported in each
VDOM.

DO NOT REPRINT High Availability Lab 1: High Availability
FORTINET
High Availability
Lab 1: High Availability
In this lab, you will set up a high availability (HA) cluster of FortiGate devices. You will explore each
HA mode and use diagnostic commands to observe FortiGate HA behavior.
Objectives
Set up an HA cluster using FortiGate devices
Interpret diagnostic output
Observe HA synchronization and failover
Time to Complete
HA Topology
After you upload the required configurations to each FortiGate, the logical topology will change to this.
FortiGate
REMOTE
port3 port1
LINUX
port2 10.200.1.254
eth1
port2
port3 port1
10.0.1.254/24 10.200.1.1/24
WIN-STUDENT STUDENT
10.0.1.10 FortiGate
eth0
LAN3 LAN0
0.0.0.0 0.0.0.0

FORTINET
Exercise 1 Configuring HA & Observing Failover
1. On the Win-Student server, open a web browser. Go to the GUI for the FortiGate named Remote,
http://10.200.3.1/
Resources\High-Availability\Remote\remote-ha.conf.
3. Go to the GUI for the FortiGate named Student, and log in as admin.
http://10.0.1.254/
Resources\High-Availability\Student\student-ha.conf.
5. Open the console for both the Student and Remote FortiGate. This allows you to observe the
error messages that FortiGate sends to the console. This sometimes shows useful status change
information, such as:
slave succeeded to sync external files with master

Wait 4 to 5 minutes for each FortiGate to synchronize. To check the status, use this command:
diag sys ha showcsum

on both Student and Remote. If both FortiGates are synchronized, then the checksum will match.
The Student FortiGates configuration has these HA settings:
config system ha
set mode a-a
set priority 200
set group-name training
set password Fortinet
set session-pickup enable
set hbdev port2 50
end
The Remote FortiGates configuration has these HA settings:
config system ha
set mode a-a

FORTINET
set priority 100
set group-name training
set password Fortinet
set session-pickup enable
set hbdev port2 50
end
6. Verify that the HA cluster has been established:
get system status

View the Current HA mode line. Notice that the Student FortiGate is a-a master, and the
Remote FortiGate device is a-a backup.
7. Connect to the GUI of the clusters primary FortiGate (http://10.0.1.254/). Go to System > Config >
HA to v status information of the cluster members.
8. Go to a few pages from several web sites, then use the CLI to see the session table entries of
both the Student and Remote FortiGate, and examine to see which sessions are synchronized:
diag sys session filter dport 80
diag sys session list

From the CLI, enter the command:
diag sys session stat

If you are using SSH or Telnet instead of the console, use this command instead to access the
secondary CLI via the primarys HA link:
execute ha manage <id> (use ? to list the id values)
exit (to return to the primary)

The primarys session table should be larger than the secondarys. This is because all
management traffic is with the primary; all non-TCP traffic is handled by the primary, too. By
default, only TCP sessions destined for proxy inspection are load balanced between the primary
and secondary FortiGate.
9. To test fail-over, view a long YouTube video. During this, run a continuous ping to a public IP
address.
To trigger a failover, reboot the Student FortiGate device by entering the command:
execute reboot
10. Because of the failover, the Remote FortiGate device is now the primary processor of traffic.
Use the CLI to verify this:
get sys stat

11. When the Student FortiGate finishes rebooting and rejoins the cluster, does it rejoin as the
secondary, or resume its initial role of primary? To see the status of all member FortiGates,
use the command:

FORTINET
diag sys ha status
You should observe the Student FortiGate rejoins the cluster as a secondary. It has lost its role of
primary.
12. From the Remote FortiGate, execute this command to make the Student FortiGate become the
primary again:
diagnose sys ha reset-uptime

By resetting the HA uptime, you are forcing the cluster to use the next value to determine which
FortiGate has priority for becoming the primary. You should observe that the Student FortiGate is
now primary.
13. Check the system uptime to see that this remains unchanged:
get sys perf status

Notice that each FortiGates FortiOS uptime is not reset, only its HA uptime.
14. The HA synchronization process is responsible for FGCP packets that communicate cluster status
and build the cluster. You can observe this process.
On the Student FortiGate, enter:
diagnose debug enable
diag debug application hasync 0
diagnose debug application hasync 255

On the Remote FortiGate, enter:
execute reboot
On the Student FortiGate, observe the output while the secondary reboots and starts
communicating with the cluster.
To stop the debug output on the Student FortiGate, press the up-arrow key twice, selecting the
command before last (in this case diag debug app hasync 0), then press the Return key.

FORTINET
Exercise 2 Configuring a Non-Synchronizing HA

Management Port
In this exercise, you will configure a spare interface of the cluster to be a non-synchronizing
management interface. This will allow both FortiGate to be reachable for SNMP and management
purposes only.
1. On the Student FortiGate (normally the primary), go to System > Config > HA. Edit the Student
FortiGate. Select Reserve Management Port for Cluster Member and choose port7. Click Apply.
Port7 connects to the same LAN segment as port3.
2. Go to System > Network > Interface. Configure port7 with the address 10.0.1.253/24.
Note: Even though this address overlaps with port3, and would not be normally
allowed (FortiGate does not allow overlapping subnets), it is allowed here because the
interface now has a special purpose, and is excluded from the routing table.
Enable HTTPS, SNMP and PING access.

3. Verify connectivity to port7 by browsing to:
https://10.0.1.253
4. Configure the secondary. Go to the CLI of the Remote FortiGate device. Verify that the non-
synchronizing interface settings have been synced to the secondary.
show system ha
Look for ha-mgmt-status and ha-mgmt-interface. These should be set. Notice that you have the
option for ha-mgmt-gateway too.
5. From the CLI of the Remote FortiGate device, to verify that port7 has no configuration, enter:
show sys int

6. Configure port7 via the CLI:
conf sys int
edit port7
set ip 10.0.1.252/24
set allowaccess https ping snmp
end
7. Verify connectivityto port7 by browsing to:
https://10.0.1.252/
Each device in the cluster now has its own management IP address for monitoring purposes.
8. Before proceeding to the next lab, connect to https://10.0.1.254/. Go to System > Config > HA.

FORTINET
For the Remote, click the Disconnect from cluster icon. This will remove it as an HA cluster
member.
9. When prompted, configure port3 with the IP address 10.0.1.251/24. Log in to the disconnected
FortiGates new IP address, then enable HTTP administrative access.
STUDENT # execute ha disconnect FGVM010000006759 port3 10.0.1.251

255.255.255.0
Sending cmd to HA member 0

If after disconnecting the HA you are no longer able to access the Remote FortiGate, you can go
to its console and manually configure the port using the following commands:
edit port4
set ip 10.200.3.1/24
end
conf route static
edit 0
set device port4
set gateway 10.200.3.254
end
Note: Failure to do the last step will prevent you from doing the next exercise.

DO NOT REPRINT Advanced IPsec VPN Lab 1: Advanced IPsec VPN
FORTINET
Advanced IPsec VPN
Lab 1: Advanced IPsec VPN
In this lab, you will configure a more advanced IPsec VPN topology.
Objectives
Configure redundant VPNs between two FortiGates
Time to Complete

FORTINET
Exercise 1 Configuring an IPsec VPN
During this lab, you will configure two redundant VPNs between the Student and Remote FortiGates.
In this first exercise, you configure the first of those two VPNs.
http://10.200.3.1/
Resources\Advanced-IPsec-VPN\Remote\remote-ipsec2.conf
The Remote FortiGate will reboot.
http://10.0.1.254/
Resources\Advanced-IPsec-VPN\Student\student-ipsec2.conf
The Student FortiGate will reboot.
5. On the Student FortiGates GUI, go to VPN > IPsec > Tunnels. Click Create New.
Use the name Remote_1 and select Custom VPN Tunnel. Click Next and configure these settings:
Remote Gateway: Static IP Address
IP Address: 10.200.3.1
Interface: port1
Method: Preshared Key
Pre-shared Key: Fortinet
Leave the other settings with their default values and click OK.
6. Go to Router > Static > Static Routes and create this new static route:
Device: Remote_1
7. Go to System > Network > Interfaces, and create this new zone:
Zone Name: VPN
Interface Members: Remote_1
8. Create two firewall policies between port3 and Remote_1, for both directions:

FORTINET
Source Address: STUDENT_INTERNAL
Outgoing Interface: VPN
Destination Address: REMOTE_INTERNAL
Schedule: Always
Service: ALL
Action: ACCEPT
NAT: Disable
Incoming Interface: VPN
Source Address: REMOTE_INTERNAL
Outgoing Interface: port3
Destination Address: STUDENT_INTERNAL
Schedule: Always
Service: ALL
Action: ACCEPT
NAT: Disable
9. Given the settings that you have just configured on the Student FortiGate, and the network
diagram (located in Topology), complete the other half of the VPN by configuring the Remote
FortiGate.
On the Remote FortiGate, for the VPN object on port4, use the name Student_1. Remember to
also create the static route, the VPN zone, and incoming and outgoing firewall policies.
10. To test the VPN, from a command prompt on the Win-Student computer, ping these IP addresses
in the remote network:
ping 10.0.2.10
ping 10.0.2.254
Note: FortiGate may not have previously established the VPN. If so, the first two
pings will fail while it negotiates and establishes the VPN.
11. From the Student FortiGate, set the source IP address of the ping packets to port3s IP
address (10.0.1.254):

FORTINET
execute ping-options source 10.0.1.254
Then ping the remote network from the Student FortiGate:
execute ping 10.0.2.254

After the test succeeds, change the ping source address back to its default value (automatic):
execute ping-options source auto

12. On the Student FortiGate, go to VPN > Monitor > IPsec Monitor.
Confirm that the Remote_1 VPN is up. A green arrow should be displayed in the Status column.

FORTINET
Exercise 2 Configuring a Redundant IPsec VPN
In this exercise, you will create the second route-based VPN for redundancy.
1. Repeat the configuration steps of exercise 1, but this time, make the VPN from the Student
FortiGate port2 to Remote FortiGate port 5.
On the Student FortiGate, for the VPN, use the name Remote_2. On the Remote FortiGate, for
the VPN, use the name Student_2.
2. On the Student FortiGate, add this static route:
Device: Remote_2
Distance: 20
3. Go to System > Network > Interfaces, and edit the zone VPN. Add the interface Remote_2 to it.
4. On the Remote FortiGate, add this static route:
Device: Student_2
Distance: 20
5. Go to System > Network > Interfaces, and edit the VPN zone. Add the interface Student_2 to it.
6. To start testing the VPN fail-over, from the command prompt on the Win-Student computer, run a
continuous ping to an IP address in the remote network:
ping t 10.0.2.10
7. On the Student FortiGate, go to System > Network > Interfaces and edit port1. Set the
Administrative Status to bring down the interface.
Note: Alternatively, you can simulate an upstream device failure by disabling a network
interface on the Linux server.
To access the Linux server, use PuTTY to connect to 10.200.1.254 via SSH. Log in
with the username root and password password. From a command prompt, enter:
ifconfig eth3 down

The IPsec DPD mechanism should detect that the tunnel is down.
To bring up the primary path again, enter:
ifconfig eth3 up
8. On the Student FortiGate, observe the session failover:

FORTINET
diagnose sys session filter dst 10.0.2.10
diagnose sys session list

Sample output:
session info: proto=1 proto_state=00 duration=676 expire=59 timeout=0

flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 policy_dir=0 tunnel=Remote_2/
state=may_dirty none app_ntf
statistic(bytes/packets/allow_err): org=33240/554/1 reply=31500/525/1

tuples=2
orgin->sink: org pre->post, reply pre->post dev=4->16/16->4

gwy=10.0.2.10/10.0.1.10
hook=pre dir=org act=noop 10.0.1.10:1->10.0.2.10:8(0.0.0.0:0)
hook=post dir=reply act=noop 10.0.2.10:1->10.0.1.10:0(0.0.0.0:0)
misc=0 policy_id=3 auth_info=0 chk_client_info=0 vd=0
serial=00000c20 tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
total session 1
Observe in the output the name of the VPN used for the session. In the example above, the ICMP
traffic is going through the VPN Remote_2, which is the secondary one.
9. On the Student FortiGate, return the Administrative Status of the port1 interface to up. If you
brought down the Linux eth3 interface, also bring it back up.
Note: Failure to do the last step will prevent you from doing the next exercise.

DO NOT REPRINT Advanced IPsec VPN Lab 2: IPsec VPN with FortiClient
FORTINET
Lab 2: IPsec VPN with FortiClient
In this lab, you will create a dial-up VPN.
Objectives
Configure an IPsec VPN between the Student FortiGate and a computer with FortiClient
installed
Time to Complete

FORTINET
Exercise 1 Configuring the FortiGate as a VPN Gateway
http://10.200.3.1/
Resources\Advanced-IPsec-VPN\Remote\remote-ipsec3.conf.
The Remote FortiGate device will reboot.
http://10.0.1.254/
Resources\Advanced-IPsec-VPN\Student\student-ipsec3.conf.
The Student FortiGate device will reboot.
5. On the Student FortiGate, go to VPN > IPsec > Tunnels. Click Create New. Type the name
FClient and select the Dialup FortiClient template. Click Next and configure these settings:
Authenticated Method: Pre-shared Key
Pre-Shared Key: Fortinet
User Group: training
Click Next. Configure these other settings in the next wizard step:
Local Interface: port3
Local Address: STUDENT_INTERNAL
Client Address Range: 172.20.1.1-172.20.1.5
Subnet: 255.255.255.0
DNS Server: Use System DNS
Enable IPv4 Split Tunnel: Enabled
Accessible Networks: STUDENT_INTERNAL
Allow Endpoint Registration: Disabled
Click Next. Verify that Save Password is enabled, then click Create.
The VPN wizard creates not only IPsec Phase 1 and 2, but also a firewall address, named

FORTINET
FClient_range, and two firewall policies to allow VPN traffic both ways.
Note: Although you have created a route-based IPsec tunnel, you do not need to add
a static route because it is a dial-up VPN. FortiGate will automatically add or remove
appropriate static routes to each dial-up peer when their VPNs are established or
disconnected.

FORTINET
Exercise 2 Configuring and Testing FortiClient
1. On the Win-Remote computer, double-click the FortiClient icon to start that application.
2. Click the Configure VPN link. Click IPsec and configure these settings:
Connection Name: FC_VPN
Remote Gateway: 10.200.1.1
Authentication Method: Preshared Key with the password fortinet
Authentication (XAuth): Save Login
Username: student
Click Apply, then click Close.

3. To establish the dial-up VPN, enter the password F0rtinet, then click Connect.
4. Wait a few seconds. Open the FortiClient application again. A green checkmark confirms that the
tunnel is up:
5. The Win-Remote computer receives a VPN IP address within the 172.20.1.1 - 172.20.1.5
range. Open a command prompt to confirm it:
ipconfig /all
6. Display the routing table information:
route print
Locate the 10.0.1.0/24 network entry in the output.
7. Try to ping both the Win-Student computer (10.0.1.10) and the port3 interface of the Student
FortiGate (10.0.1.254).

FORTINET
8. On the Student FortiGate, go to Router > Monitor > Routing Monitor. Find the static route that was
automatically added by the FortiGate.
9. Go to VPN > Monitor > IPsec Monitor to view the details of the FClient-0 VPN connection. Notice
the Remote Gateway IP address.
10. On the Win-Remote compute, open FortiClient and click Disconnect to bring down the tunnel.

DO NOT REPRINT Intrusion Prevention System Lab 1: Intrusion Prevention System
FORTINET
Intrusion Prevention System
Lab 1: Intrusion Prevention System
In this lab, you will set up DoS policies and IPS profiles on your FortiGate. You will use a vulnerability
scanner. You will also use packet crafting software to attempt to flood one of the FortiGates, then
examine the resulting log entries on both FortiGates.
Objectives
Block attempts to exploit known vulnerabilities
Mitigate a DoS attack
Interpret attack log entries
Diagnose an attack attempt
Time to Complete

FORTINET
Exercise 1 Blocking Known Exploits
In this exercise, you will block and log some known exploits that the nikto vulnerability scanner will
simulate.
http://10.0.1.254/
Resources\Introduction\Student\student-initial.conf
The FortiGate will reboot, which automatically will log you out.
3. Log in again. Go to System > Config > Features. In the Security Features dropdown, select Full
UTM. (This is required for the GUI to show some things, such as security logs.)
4. Go to Security Profiles > Intrusion Protection.
To create a new sensor, click the plus sign (+) in the upper-right corner of the Edit IPS Sensor
window. In Name, type LINUX_SERVER, then click OK.
In the Edit IPS Sensor window, click Create New. Configure a new IPS filter with these settings:
Sensor Type: Filter Based
Filter Options Basic
Severity: All
Target: server
OS: Linux
Action: Signature Defaults
Packet Logging: Enabled
5. Go to Policy & Objects > Policy > IPv4.

Edit the port3 port1 firewall policy. In the Security Profiles section, set IPS to ON, then from the
drop-down list, select LINUX_SERVER.
6. On the Win-Student desktop, open a command prompt. Go to the folder for
Resources\Intrusion-Prevention-System\nikto-2.1.5:
C:> cd \
C:> cd Documents and Setting
C:> cd Administrator
C:> cd Desktop

FORTINET
C:> cd Resources
C:> cd Intrusion-Protection-System
C:> cd nikto-2.1.5
7. Scan the Linux server for vulnerabilities:
nikto.pl -host 10.200.1.254

The test will stop automatically once finished. Otherwise, you can use CTRL+C to stop the utility.
8. On the Student FortiGate, go to Log & Report > Security Log > Intrusion Protection. Locate the
multiple entries for the attacks generated by nikto.
Note: The Security Log menu item will not display if there are no UTM logs. FortiGate
will show it after creating logs. After starting the Nikto utility, if this menu item does not
display, click the browsers Refresh button to reload the GUI.
If the exploits are not logged, verify:

Is the LINUX_SERVER IPS sensor selected in the policy?
Is the traffic matching the correct policy?
If both are true, but the exploits are still not being logged, ask your instructor for help.
9. Right-click any of the column titles to display the Column Settings dialog. Add the Action field to
the display. To move the column to a location that is easier to view, click and drag the column.
Note that for some of the attacks discovered by this sensor, in the Action column, the value is
detected. This indicates that a signature was matched, but that FortiGate was configured to allow
traffic to pass.
In the spaces below, write the names for two of the detected signatures. The signature name
appears in the Message column of the log.
Signature 1: ____________________________________
Signature 2: ____________________________________
10. Go to UTM Security Profiles > Intrusion Protection > IPS Sensor. Edit the sensor named
LINUX_SERVER.
Click Create New to add a filter. Set the Type to Specify Signatures. Click in the search field
located on the left side of the window (close to the top), then enter the name that you wrote in
Signature 1 from the previous step.
Select the signature.
Set its Action to Block All, and enable Packet Logging.
Repeat this step for the signature that you noted in Signature 2.
11. By dragging and dropping in the IPS filter list, move the newly-created signatures above the
Default filter.
12. From a command prompt on the Windows server, run the vulnerability scan again:
nikto.pl -host 10.200.1.254

13. Go to Log & Report > Security Log > Intrusion Protection.

FORTINET
Examine the log entries again. Locate log messages which indicate that attacks were blocked.
The Status field should contain dropped. This indicates either: a dropped packet, dropped session,
or cleared session.

FORTINET
Exercise 2 Mitigating a DoS Attack
In this exercise, add basic flood protection.

1. On the Student FortiGates GUI, go to Policy & Objects> Policy > DoS Policy. Create a DoS
policy:
Source Address: all
Service: ALL
Anomalies: Threshold for icmp_flood: 200.

Status enable
Logging enable
Action: Block
2. Open an SSH connection and login to the Linux host (10.200.1.254). Enter the username root with
a password of password.
3. Use the ping flood option against the external server:
ping -f 10.200.1.1
The command options used here will cause the ping utility to run continuously and not wait for
replies between ICMP echo requests.
FortiGate should block pings when the packets per second exceed the configured threshold. The
periods displayed from the ping utility represent packet loss because there was no response.
Leave this window open with the ping test still running.
4. Go to Log & Report > Security Log > Anomaly and examine the logs. Note that the ICMP flood has
been blocked; this is indicated by the Status field entry clear_session.
Note: You may need to refresh the GUI for the Anomaly menu item to display.
5. From the CLI on the Student FortiGate, verify the current counter thresholds :
diagnose ips anomaly list

Sample output:
list nids meter:
id=icmp_flood ip=10.200.1.254 dos_id=1001 exp=932 pps=21 freq=20
total # of nids meters: 1.

When done, in PuTTY, press Ctrl + C to stop the flood, then close the terminal.

FORTINET
Exercise 3 Creating Custom Signatures
The custom signature created in this exercise will detect the RETR (GET) command on the FTP
control session in the direction of the server and generate an attack log event.
1. On the Student FortiGate, create a custom signature to detect the FTP GET command:
config ips custom
edit "FTP_GET"
set severity medium
set protocol FTP
set log-packet enable
set action pass
set signature "F-SBID(--name 'FTP Download'; --flow from_client; --

pattern RETR;)"
end
2. Go to Security Profiles > Intrusion Protection. Edit the LINUX_SERVER sensor created earlier.
Create a new filter and set the Sensor Type to Specify Signatures. Select the Custom [FTP_GET]
signature located at the top of the list. Set the Action to Reset and enable Packet Logging.
3. Once this has been created, move this filter to the top of the list and click Apply to save the
change.
4. On the Student FortiGate device, trace the session:
diag sniffer packet any 'port 21' 4

5. From the Win-Student computer, open the FileZilla Client from the desktop.
Open the Site manager and connect to the Linux Server entry.
Change to the /pub folder on the server and download the file called test.text
The connection to the remote host should be closed.
Note: When FortiGate resets the TCP connection, FileZilla may show a notification pop-
up a few times.
6. In the CLI, examine the trace output to verify that the reset action was applied to the session.
You should see a TCP reset sent out to the client on port3 and the server on port1.
Alternately, On the Student FortiGate device go to Log & Report > Security Log > Intrusion
Protection, and locate the attack log entry to verify that the reset action taken as shown below:

DO NOT REPRINT Fortinet SSO Lab 1: Fortinet Single Sign On
FORTINET
Fortinet SSO
Lab 1: Fortinet Single Sign On
In this lab, you will configure Fortinet Single Sign On to enable the FortiGate to collect authentication
information from Windows Active Directory. Once users log into the Windows domain, they will not be
required to authenticate again to access other web sites.
Objectives
Configure a collector agent
Configure FortiGate to transparently authenticate users using FSSO
Monitor the status and operation of FSSO
Time to Complete

FORTINET
Exercise 1 Installing FSSO on a Windows Server
http://10.0.1.254/
Resources\FSSO\Student\Student-sso.conf
3. On the Win-Student server, right-click the Fortinet Single Sign On (FSSO) installation file located
in Resources\FSSO, then select Run as administrator.
This should launch the Fortinet Single Sign On Agent Installation Wizard. Follow the wizard to
install the agent on the Win-Student server.
4. When prompted for the Windows server administrator password, enter password:
Click Next.
5. In the Install Options window, accept the default settings:
Click Next.

FORTINET
6. Click Install to complete the installation.
7. At the end of the Single Sign On Agent installation, the Launch DC Agent Install Wizard option will
be selected.
Click Finish to complete the collector agent Installation. This launches the Domain Controller
Agent Installation Wizard.
8. In the Install DC Agent Wizard, accept the Collector Agent IP Address of 10.0.1.10 and the
Collector Agent Listening Port of 8002.
Click Next.
9. Select the TRAININGAD:trainingAD.training.lab domain to monitor.
Click Next.
10. Only the student account needs to be monitored in this exercise. Expand the TRAININGAD
domain and disable all the users in the TRAININGAD domain EXCEPT for student.:
Click Next.
11. Set the Working Mode to Polling Mode and Check Windows Security Event Logs.

FORTINET
Click Next.
12. In the Win-Student computer, click the windows icon > down arrow. Under the Fortinet section run
Configure Fortinet Single Sign-on.
Perform the following tasks in the Fortinet single sign on agent configuration window:
Change the Require authenticated connection from FortiGate password to Fortinet
Click Show Monitored DCs to verify the communication between the collector agent and the domain
controller agent. The IP address of 10.0.1.10 should show as being logged in. Click Close.
Click Select Domains to Monitor and verify the TRAININGAD:trainingAD.training.lab domain is
selected. Click OK.
Click Set Group Filters. Click Add and enable the Default filter. Click Advanced and expand the
domain name of TRAININGAD. From the expanded list select Users. Click Add, then OK.

FORTINET
Click OK.
Click Save & Close to close the Fortinet single sign on agent configuration window.

FORTINET
Exercise 2 Configuring FSSO on FortiGate
1. On the Student FortiGate, go to User & Device > Authentication > Single Sign-On. Create a new
entry with these settings:
Type: Fortinet Single-Sign-on Agent

Name: TrainingDomain
Primary Agent IP/Name: 10.0.1.10
Password: Fortinet
Click Apply & Refresh, you should observe that the trainingad/users group is displayed.
If the trainingad/users group does not appear, it could be an issue with the Windows Firewall on
the Win-Student server. Turn off the firewall and then click Apply and Refresh .
2. Begin to monitor the communication between the FSSO collector agent and the FortiGate. Use
these CLI commands:
diagnose debug en
diagnose debug application auth 8256

You will return to this output after you have tested the configuration.
3. Go to User & Device > User > User Groups. Create a new user group:
Name: Training
Type: Fortinet Single Sign On (FSSO)
Add TRAININGAD/USERS as members to the group.

4. Edit the port3 port1 firewall policy, and configure it with the following settings:
Source Address STUDENT_INTERNAL
Source User(s) Training
Outgoing Interface port1
Destination Address all
Schedule Always
Service ALL
Action ACCEPT

FORTINET
NAT Enabled

FORTINET
Exercise 3 Testing FSSO On Authentication
1. On the Win-Student computer, click the Windows button. Click the search icon (magnifying glass)
on the top. Search for the name mstsc. Launch Windows Remote Desktop.
2. Enter the remote computer IP address 10.0.1.10:
Log in with these credentials:
Username: student
Password: Fort1net
Ignore the error message indicating that the user is not authorized for remote login. The objective
of this step is to generate a logon event that the DC agent can capture, without needing to reboot
the Win-Student server.
3. Open a web browser on the Win-Student computer. Try to connect to a web site. You should be
able to access the Internet without receiving a prompt for user authentication.
4. Observe the output from the diagnose command that is still running in the CLI.
5. Display which users are currently logged on using FSSO:
diagnose debug application auth 0
diagnose debug authd fsso list

Review the output. You may see two IP addresses for the user named "student" because the
Win-Student computer has two NICs.

DO NOT REPRINT Certificate Operations Lab 1: Certificate Operations
FORTINET
Certificate Operations
Lab 1: Certificate Operations
In this lab, you will learn the basics of all SSL-based inspection that a FortiGate is capable of
performing. You will learn how FortiGate inspects secure traffic, and what encryption it uses. You will
also examine the server's certificate to understand its general layout and contents.
Objectives
Create different certificate signing requests (CSRs)
Use OpenSSL to sign a CSR
Load signed certificates into the FortiGate
Use certificates for various purposes including administrative use (GUI access), SSL VPN,
and deep inspection
Time to Complete

FORTINET
Exercise 1 Creating a Certificate Request
This lab was designed and tested using Firefox and XCA. Steps may vary if you use another
browser and/or CA.
http://10.0.1.254/
Resources\Certificate-Operations\student\student-certificate.conf.
3. Log in again using HTTP (HTTPS will be used later) and go to System > Certificates > Local
Certificates.
Click Generate to create a certificate request and enter the Certificate Name: MyCert. For
Subject Information choose host IP and enter:
10.0.1.254
You can enter whatever information you like into the rest of the fields.
Once created, the certificate will display in the GUI showing a status of PENDING.
4. Select the newly created certificate and download it.
5. Open a new browser tab. Using HTTPS, connect to the Student FortiGates GUI:
https://10.0.1.254

FORTINET
You should receive an error message. Dont add an exception, nor log in yet.
Expand the technical details. You should see there are actually 2 errors.
The certificate is self-signed (not issued by a known certificate authority).
The certificate is only valid for a specific location (The VM serial number that was included
with the VM license file).
Note: If your browser does not display a warning, then you have previously added an
exception. To restore the error, remove the exception from your browser. To delete
the certificate exception in Firefox, click the button with three lines on the top right,
then select Options. Select the Advanced tab, then the Certificates tab. Click the View
Certificates button and select the Servers tab. Scroll down to Fortinet and highlight
the certificate for the Student FortiGate (10.0.1.254) and click the delete button. Click
OK twice and refresh your browser.
Note: Different browsers sometimes have separate certificate repositories, but

accessing the FortiGate with HTTPS through Internet Explorer or Chrome should still
result in their equivalent warnings.
6. On the Win-Student computer, open XCA.
You can find the software on the task bar. The icon looks like a key.
Enter the password Fortinet at the prompt.
7. Select the Certificate Signing Requests tab and click Import

FORTINET
Import the certificate request file that you downloaded from FortiGate in the previous step.
Note: Firefox saves files into the Downloads folder. If the file name was not
changed, it will be MyCert.csr
XCA should show an unhandled request for 10.0.1.254.
8. Select the Certificates tab, then click New certificate
9. In the Create x509 Certificate window popup, click the Source tab.

FORTINET
Go to the Template for the new certificate area. Make sure it is set to [default] CA, then click
Apply all.
10. Click the Subject tab, enter these settings:
Internal Name Training Authority
countryName (use the 2 letter abbreviation for your country)
stateOrProvineName (use the full name of the state or province)
localityName (use the full name of the city)
organizationName Fortinet Training
organizationalUnitName Global Training services
commonName Training
emailAddress Training@fortinet.com
11. In the Private key section at the bottom, click Generate a new key.
12. In the X Certificate and Key management popup, do not change the settings. Click Create.

FORTINET
The Private key area should now be populated.
13. Click OK.

XCA should display a message that it successfully created the certificate, and show the certificate
in the list as a CA certificate.
14. Go to the Certificate signing requests tab, right-click on the request from 10.0.1.254, then select
Sign.
15. On the Source tab in the Signing section, select Use this Certificate for signing.
16. At the bottom of the Source tab in the Template for the new certificate section, select [default]
HTTPS_Server, then click Apply all

FORTINET
Click OK to finish signing the certificate. The request should now be signed.
17. Go the Certificates tab, select the 10.0.1.254 certificate, then click Export.
18. On the Certificate export window, click OK to save the certificate to a file.
Note: Make note of the filename and folder the certificate is going to be saved too.
Change them as needed.
19. Export the Training Authority certificate as well.

20. From the HTTP connection to the ForitGate GUI go to System > Certificate > Local Certificate
Click Import and browser to the certificate file that was exported in step 15..
If you cant load the certificate, then go to XCA, delete both certificates, and try the process again.
21. Connect to the CLI on the Student FortiGate. Change the certificate that the FortiGate uses for
HTTPS connections to its GUI.
config system global
set admin-server-cert MyCert
end
22. Using HTTPS, connect to the Student FortiGates GUI:
https://10.0.1.254
There will still be 1 warning message. Do not add an exception.
Review the technical details and observe that the only error is with the issuer chain. The CA is
not trusted. Since the authority that signed the certificate is not a public root CA, your browser
will not be able to find any information about it in its repository of default CA certificates.

FORTINET
But the certificate is now valid for that URL (assuming you used the correct IP address when
creating the request).
Note: The behavior change will be immediate, but your browser may use locally cached
information. If you still see the old certificate, clear your browsers cache, then refresh
the page.
23. Click the Open Menu icon in Firefox and select Options.
24. Under Advanced, on the Certificates tab, select View Certificates.
25. Select the Authorities tab and click Import.

FORTINET
Select the Training_authority certificate that you exported previously.

26. When prompted, enable all trust options for the certificate, then click OK.
27. Go to the certificate warning that your browser displayed when trying to access FortiGates GUI
via HTTPS. Click refresh.
The login prompt should now display. No warning should appear.

FORTINET
Exercise 2 SSL Deep Inspection
1. In the Student FortiGates GUI, go to Policy & Objects > Policy > IPv4. Edit the port3 port1
firewall policy. Select the default antivirus profile and the deep-inspection SSL/SSH inspection
profile.
Save the change by clicking OK.

2. In a new browser window, go to:
https://www.google.com
You should receive a certificate warning. DO NOT ADD AN EXCEPTION.
Note: If you review the technical details the certificate issuer is not trusted. The
default SSL inspection certificate is signed by Fortinet. Fortinet is not a public root
CA.
Note: If you use Chrome, you wont be able to access Google unless HSTS is
disabled in the browser, or Full-SSL Inspection is disabled on FortiGate.
3. On the Student FortiGate, go to System > Certificates > Local Certificates.

Click Generate to create a certificate request and enter the Certificate Name: SSLCert. For
Subject Information choose Domain name and enter SSL.Proxy.
You can enter whatever information you like into the rest of the fields.
Click OK to generate the new request.

FORTINET
4. Select the certificate and download it.
5. Import the certificate request into XCA.
Refer to exercise 1 step 6 for the process.
6. On the Certificate signing requests tab, right click on the request from SSL.Proxy and select Sign.
7. On the Source tab in the Signing section, select Use this Certificate for signing
8. Go to the Template for the new certificate section. Make sure it is set to [default] CA and click
Apply all.
9. On the Extensions tab set the Time range to 1 years and click Apply.
10. Go the Key Usage tab enable Digital Signature, Non Repudiation, Key Encipherment and Data
Encipherment.
Click OK to finish signing the certificate.

11. Go the Certificates tab, select the SSL.Proxy certificate and click Export.
Refer to exercise 1 steps 15 and 16 for the steps to properly export the certificate.
12. From the GUI of the student FortiGate go to System > Certificates > Local Certificates and click
Import.
Select the SSL.Proxy certificate.

FORTINET
13. From the GUI of the student FortiGate go to Policy & Objects > Policy > SSL/SSH Inspection. Edit
the deep-inspection profile.
Set the CA Certificate to SSLCert, then click Apply to save the change.
Note: Certificates unsuitable for SSL content inspection will be automatically filtered
out and are not selectable. MyCert cannot be used sign other certificates.
14. Return to the certificate warning for Google, then refresh the page.
The page should display normally.
Note: The CA that signed this certificate is not public, but the browser is aware of it
because you added it as a trusted authority in the previous exercise.

DO NOT REPRINT Data Leak Prevention Lab 1: Data Leak Prevention
FORTINET
Data Leak Prevention
Lab 1: Data Leak Prevention
In this lab, you will use data leak prevention rules and sensors to block sensitive data from leaving the
private network.
Objectives
Configure DLP to block executable files
Read and interpret DLP log entries
Set up DLP banning and quarantining
Configure DLP fingerprinting
Time to Complete

FORTINET
Exercise 1 Blocking Files by Type
http://10.0.1.254/
Resources\Data-Leak-Prevention\Student\student-dlp.conf
3. Go to Security Profiles > Data Leak Prevention > Sensor. Create a sensor called
No_executable_files. (Click Create New in the upper right-hand corner of the Edit DLP Sensor
window.).
Note: DLP is not enabled in the GUI by default. If you do not see it listed in the
menu, enable it on the status page using the Features widget and click Apply.
System >Config >Features
Note: Blocking based upon a file name of *.exe is also possible, but not
recommended. The obvious weakness however, is that a person could circumvent
that type of DLP by changing the filename to, for example, *.ex1, or *.txt.
In comparison, file type identification works by analyzing the binary layout of the file.
Not all file types have a strict design, however, and these cannot be identified by this
method.
4. In the Edit DLP Sensor window, create a new rule.
Filter: Files
Specify File Types: Click on radio button to select
File Types: Select the following from drop down: Batch file
(bat), Executables (exe), Executables (elf), HTML
Application (hta)
Examine the Following services: HTTP-POST
Action: Block
Click OK to save the changes.

FORTINET
5. Go to Policy & Objects> IPv4 > Policy and edit the port3 port1(external1) firewall policy to
enable the DLP sensor called No_executable_files.
6. To test the DLP sensor, transmit an executable file through FortiGate via HTTP.
To do this, open a web browser and go to:
http://www.sendbigfiles.com
On the web page, click the Choose File button and locate the putty.exe executable file on the
desktop of the virtual Windows 2003 Server. Then enter your email address and the recipient
email address, and click SEND!
The DLP block message should display once the file is fully transmitted.
7. From the GUI on the student FortiGate, go to the forward traffic log. Find the entry that has a
blocking security action for this attempted data leak.
Click Log details to show forward traffic log information. Click DLP to view security log
information..
You can view DLP logs under Log & Report > Security Log > Data Leak Prevention.
Compare the details of the DLP log to the forward traffic log.

FORTINET
Exercise 2 Quarantining a User that is Leaking

Sensitive Data
1. Edit the No_executable_files DLP sensor. Change the action for the filter entry that detects
executable files to Quarantine IP Address to have an interval of 5 minutes.
2. Return to the sendbigfiles.com web site.

3. On the sendbigfiles.com web page, click Choose File and locate putty.exe file again. Enter the
email address of a recipient along with your own email address in the appropriate fields then click
SEND!
The file upload should be blocked.
4. Quickly go to another web site, such as google.ca.
A replacement message should appear instead of the web site. This occurs because the IP
address that is sending the request has been quarantined and is not allowed through any Firewall
policy on the FortiGate.
Note: If you try to visit other web sites now you will be blocked and a replacement
message appears instead of the website. Not all protocols support replacement
messages.
5. From the GUI on the Student FortiGate, go to User & Device > Monitor > Banned User and locate
your entry in the list of temporarily banned IP addresses.
6. Select and remove the banned entry.
You should now be able to access the Internet again, even if 5 minutes has not yet elapsed.

FORTINET
Exercise 3 DLP Fingerprinting
1. Back up the configuration of the Student FortiGate. (Check your browser's downloads folder.)
2. From the GUI on the Student FortiGate device, go to Security Profiles > Advanced > DLP
Fingerprint.
In the Manual Document Fingerprints section, upload a new document to take a fingerprint of.
Click Create New and locate the configuration file on the desktop that you created in step 1.
Set the Sensitivity Level to Critical.
Note: The GUI may not auto-refresh when the file has finished being processed. If this
happens, wait a few seconds then click on the DLP Fingerprint menu item.
3. Create a new DLP filter in the No_executable_files DLP sensor with the following details:
Filter: Files
File Finger Print: Critical
Examine the Following Services: HTTP-POST
Action: Block
Click OK to save the change to the filter and click Apply to save the change to the sensor.
4. On the sendbigfiles.com web page, click Choose File and locate the configuration file that you
downloaded from the FortiGate. (Check the download folder of the browser youve chosen to use)
Enter the email address of a recipient along with your own email address in the appropriate fields
then click SEND!
The file will be blocked.
5. Open the configuration file in a text editor such as Notepad++ (anything that can handle word
wrapping is fine). Make a few small changes to different areas of the configuration, then save the
file.
Note: If you use Notepad++ there is a FortiGate language file that has been written to
parse configurations for FortiGate devices. Enable it by clicking selecting FortiGate from
the Language menu.
6. On the sendbigfiles.com web site, attempt to send the configuration file again. The file download
will be blocked (assuming that changes were not too large, and not in too many areas).

FORTINET
Note: Fingerprinting breaks the file into chunks and makes checksums of each part. By
default, DLP will detect a match if any chunks checksum from the fingerprint matches.

DO NOT REPRINT IPv6 Lab 1: IPv6 Transition Technologies
FORTINET
IPv6
Lab 1: IPv6 Transition Technologies
In this lab, you will perform the initial IPv6 interface configuration, adding an IPv6 network prefix to
your Student FortiGate to automatically configure your internal Windows Server host. You will
configure a range of IPv6 transition technologies: the internal network will be configured for dual-stack;
NAT64 will be used on the FortiGate, allowing your IPv6 internal address range to communicate with
IPv4 hosts on the external network; using IPsec, you will tunnel IPv6 over an IPV4 network.
You will configure a tunnel connecting the two internal networks of your FortiGate devices, Student
and Remote. The remote FortiGate device is already configured, therefore you only configure the
local side of the tunnel and test that your configuration works correctly.
Objectives
Configure the FortiGate to announce an IPv6 prefix to local hosts supporting auto-
configuration
Configure transition technologies including NAT64, dual-stack, and IPv6 over IPv4 IPsec.
Time to Complete

FORTINET
Exercise 1 IPv6 Setup
http://10.200.3.1/
Resources\IPv6\Remote\remote-ipv6.conf
http://10.0.1.254/
Resources\IPv6\Student\student-initial.conf
5. Configure the port3 interface of the Student FortiGate device for IPv6 by adding an IPv6 network
prefix for the interface and configuring Stateless Address Auto-Configuration (SLAAC) for hosts on
that link.
The CLI for setting an IPv6 interface with a routing prefix:
config system interface
edit port3
config ipv6
set autoconf enable
set ip6-send-adv enable
set ip6-address 2001:db8:1::254/64
set ip6-allowaccess ping http https ssh
config ip6-prefix-list
edit 2001:db8:1::/64
set autonomous-flag enable
set onlink-flag enable
next
next
end

FORTINET
6. Verify that the Window servers IPv6 settings are auto-configured by FortiGate.
To do this, from Windows PowerShell, run the command:
ipconfig

FORTINET
Exercise 2 NAT64
In order to deal with the CLI only settings, the configuration in this exercise will be done from the CLI.
1. Enable the NAT64 service using the default prefix and enable DNS64 by enabling always-
synthesize-aaaa-record.
config system nat64
set status enable
set always-synthesize-aaaa-record enable
end
2. Review the configuration changes just made and check any default settings by showing default
settings using the full modifier.
show full system nat64

3. Create IPv6 firewall address objects for use in this lab.
config firewall address6
edit "STUDENT_INTERNAL6"
set ip6 2001:db8:1::/64
next
edit "REMOTE_INTERNAL6"
set ip6 2001:db8:2::/64
next
end
4. Create a NAT64 policy from the CLI. Remember the source address is an IPv6 address and the
destination address is an IPv4 address.
config firewall policy64
edit 1
set srcintf "port3"
set dstintf "port1"
set srcaddr "STUDENT_INTERNAL6"
set dstaddr "all"
set action accept
set schedule "always"

FORTINET
set service "HTTP" "ALL_ICMP6"
next
end
5. From the Win-Student computer, test IPv6 by running the ping command:
ping 64:ff9b::ac8:1fe
What is this address? This is the IPv4 address 10.200.1.254 in NAT64 format.
6. Connect to the GUI of the Student FortiGate using the IPv6 interface address:
http://[2001:db8:1::254]/
7. Go to System > Config > Features and enable IPv6 in the GUI.
8. Connect via SSH using the IPv6 interface address.
Once connected, enter the following command:
diag sys session clear

Your SSH session is still active, why?
diag netlink interface list
Exercise 3 Using IPsec to Tunnel IPv6 over an IPv4 Network

In order to deal with the CLI only settings, you will perform this exercise using the CLI.
1. In the CLI of the Student FortiGate (10.0.1.254), create an IPsec phase1 interface object with the
IP of the Remote FortiGate as the remote gateway.
config vpn ipsec phase1-interface
edit "ipv4_to_ipv6"
set interface "port1"
set remote-gw 10.200.3.1
set psksecret fortinet
next
end
2. Create an IPsec Phase2 interface object and configure IPv6 source and destination address
selectors.
config vpn ipsec phase2-interface
edit "ipv4_to_ipv6-P2"
set phase1name "ipv4_to_ipv6"
set src-addr-type subnet6

FORTINET
set dst-addr-type subnet6
set src-subnet6 2001:db8:1::/64
set dst-subnet6 2001:db8:2::/64
next
end
3. Create a static route for the 2001:db8:2::/64 prefix, select the local IPsec interface as the device.
config router static6
edit 0
set dst 2001:db8:2::/64
set device "ipv4_to_ipv6"
next
end
4. Create IPv6 firewall accept policies between the internal network and IPsec interface.
config firewall policy6
edit 0
set srcintf "port3"
set dstintf "ipv4_to_ipv6"
set srcaddr "STUDENT_INTERNAL6"
set dstaddr "REMOTE_INTERNAL6"
set action accept
set service "ALL"
next
edit 0
set srcintf "ipv4_to_ipv6"
set dstintf "port3"
set srcaddr "REMOTE_INTERNAL6"
set dstaddr "STUDENT_INTERNAL6"

FORTINET
set action accept
set service "ALL"
next
end
5. From the Windows server, test the tunnel by running the ping command for the remote internal
gateway address:
ping 2001:db8:2::254
6. From the CLI check the IPv6 routes, interface addresses and the tunnel state, noting the selectors
(proxy IDs) for the IPv6 subnets.
# get router info6 routing-table
# get router info6 interface
# diag vpn tunnel list

DO NOT REPRINT Appendix A: Additional Resources
FORTINET
Appendix A: Additional Resources
Training Services http://training.fortinet.com
Technical Documentation http://help.fortinet.com
Knowledge Base http://kb.fortinet.com
Forums https://support.fortinet.com/forum
Customer Service & Support https://support.fortinet.com
FortiGuard Threat Research & Response http://www.fortiguard.com

DO NOT REPRINT Appendix B: Presentation Slides
FORTINET
Appendix B: Presentation Slides

DO NOT REPRINT Routing
FORTINET
In this lesson, we are going to talk about how to route traffic with FortiGate devices.

FORTINET
After completing this lesson, you should have these practical skills that you can use
to implement routing failover and load balancing using static routes. You will also
learn how to configure link aggregation, policy routes, and black hole routes. Finally,
you will learn some debug commands for troubleshooting routing problems.
Although this lesson briefly introduces the concept of dynamic routing, it is mostly
about implementing routing with static and policy-based routes.
Lab exercises can help you to test and reinforce your skills.

FORTINET
What is routing?
Routing decides where FortiGate in NAT mode will send the packets that it receives,
and that it generates. A routing table contains routing rules. For example, FortiGate
can check the destination field of the packets IP header. If routing rules match that
destination, FortiGate can transmit the packet from port1 to port2, towards Router 1.
If an allowed packet is not destined for the FortiGate itself not administrative
access, for example FortiGate must relay the packet. FortiGate searches for
matching routes in the routing table that it can use to deliver the packet. FortiGate
either delivers the packet directly to its final destination, or relays it to the next router
along the path towards the destination.
Usually, IP routing is done by taking into account only the destination IP address.
However, as well see later, you can decide to route packets using more than just
that.
Proper routing configuration is important. If the routing directions are misconfigured,

packets will not reach their destination and will be lost.

FORTINET
One type of manually configured route is called a static route. In the route table, its
Type column is Static.
We are manually telling the FortiGate device, When you see a packet whose
destination is within this specific range of destination addresses, send it through this
network interface, towards this router. We also configure the distance and priority
so that FortiGate knows which routes to load into memory, and in what order. We
will talk about distance and priority in later slides.
For example, in simple home networks, DHCP automatically retrieves and

configures one static route. Your modem then sends all outgoing traffic through your
ISPs Internet router, which can relay packets to their destination.
When do you not require a static route?
When a destination is cabled directly to one of FortiGates network interfaces, with

no router in between, FortiGate will be aware of the destination. In the route table,
its Type is Connected.

FORTINET
For large networks, manually configuring hundreds static routes may not be
practical.
Your FortiGate can help, by configuring 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 FortiGates routing table. (So verify that your neighbor
routers are trusted and secured!)
Larger networks also may need to balance routing load among multiple valid paths,
and detect and avoid routers that are down. Well discuss that soon also.

FORTINET
Which rows are extra automatic entries that arent from your static routes
configuration?
Directly connected subnets When a subnet is assigned to a FortiGates
interface, a route to the subnet is automatically added to the routing table. The
FortiGate knows how to route those packets.
Dynamic routes On larger networks, your FortiGate may receive routes from
other routers, via protocols such as BGP. This is faster and more scalable than
manually configuring many routers.
Which configured routes arent loaded into this table?

Worse routes to the same IP Only the best paths should be used. We will see
in a later slide how the best path is elected when there are multiple routes to the
same destination.
Policy routes These are omitted, too. Why? By design, policy routes override
the routing table we dont want them to be ignored, losing precedence to OSPF
or static routes. So they have to be in a separate table, which is searched before
this one. Well discuss policy routes later.
So remember, expect differences from your configured list of static routes. And
when troubleshooting, dont only check this table. Also check the table for policy-
based routes, and (if youre using dynamic routing) your other routers.

FORTINET
In the routing table, each of the entries has a few pieces of data, such as distance
and gateway IP. They are used to relay or deliver each matching packet.
Destination IP addresses and gateway routers are self-explanatory. The device is

the name of the outgoing interface where the packet will be routed to. But what
about the distance, metric, and priority? How do they effect which routing path
packets will use?
Lets explain each briefly.

FORTINET
Distance, or administrative distance, is a number that estimates the reliability or

quality of each routing protocol and static route. If there are two routes to the same
destination, the one with the lower distance is added or loaded to the routing table,
as it is considered to be more reliable.
By default, for example, routes learned via the RIP protocol have a higher distance
that routes learned via the OSPF protocol, as OSPF is considered to be more
accurate than RIP.

FORTINET
In the case of routes learned via a dynamic routing protocols, metric is another
element that is used to determine the best route to a destination. If two routes have
the same distance, the metric is then used for tie breaking. The route with the
lowest metric is loaded to the routing table.
How the metric is measured depends on the routing protocol. RIP uses hop counts:
how many routers must be used to reach the destination. OSPF uses cost, which is
determined by how much bandwidth a link has.

FORTINET
In the case of static routes, the priority is used for tie breaking when the distances
are the same. FortiGate will use the route with the smallest number configured in
the routes priority setting.
In other words, if we have two routes with the same distance to the same
destination, only the one with the smallest priority will be used. Note that unlike with
distances/metrics, both routes with the same distance are loaded into the routing
table. However, only the route with the smallest priority will be routing traffic. This,
as we will see later, is an important concept when dealing with reverse forwarding
path check issues.

FORTINET
This is summary of the logic behind which routes are loaded into the routing table.
Routes are only active if the interface is currently both physically linked and
administratively up. If the cable isnt plugged in, or if a Wi-Fi network has no signal,
for example, packets cant be transmitted along that path. All routes through that link
will be temporarily unloaded from the table until the link is available again.
When 2 or more actives routes have the same destination subnet, only the one with
the smallest distance is loaded to the routing table.
If the distances are equal, only the routes with the smallest metric are included.
If the metric also is identical, then, depending on the dynamic routing protocols
rules, FortiGate will select which one to include in the routing table.

FORTINET
Static routes are simple, and are often enough for small networks. Policy routes,
however, are more powerful. They can match more than just the destination IP
address. An 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 with the action forward traffic have precedence over static and
dynamic routes. So, if a packet matches the policy route, the FortiGate bypasses
the routing table lookup.
Like static routes, policy routes must be valid: a destination and gateway are
required, and disconnected or down links cant be used. For policy routes, though,
packets also must match all subnets, ToS bits, and port numbers that you specify.
So if a setting shouldnt be a criteria for matching, leave it blank.

FORTINET
When a packet matches a policy route, the FortiGate takes either 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 depending on the routing table.

FORTINET
Many aspects of FortiGate are (at least by default) stateful, so it decides many
things at the beginning of a session, when it receives the first packets.
For each session, FortiGate makes only 2 routing lookups:

1. Upon the first packet sent by the originator, and
2. Upon the first reply packet coming from the responder.
After that, 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. There is an exception to this rule, though: 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.

FORTINET
How does FortiGate decide routes? FortiGate has multiple routing modules. This
diagram shows the logic among them.
First FortiGate searches its policy routes. You can view them with the command
diagnose firewall proute list. If there is a match in the policy routes
and the action is Forward Traffic, FortiGate will use the policy route. If the action is
Stop Policy Routing, the FortiGate will use the next table.
After that, FortiGate searches its route cache. You can view that with the CLI
command diagnose ip rtcache list. If a match exists, the packet is sent
to that next-hop gateway.
Finally, FortiGate searches the forwarding information base (FIB). The FIB is
generated by the routing process, and is the table used for packet forwarding. Think
of the routing tables purpose as for management, while the FIB is for forwarding.
This separation becomes more clear in FortiGate active-active HA. In an HA cluster,
both route management and forwarding tables exist on the master FortiGate. But on
the slave FortiGate, only the forwarding table exists.
If theres no match in any of those tables, FortiGate will drop the packet because it
is unroutable.

FORTINET
We saw how the distance, metric and priority are used 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 those routing elements?
If the routes are static, OSPF or BGP, FortiGate balances the traffic among all the
routes. This is what is called Equal Cost Multi-path (ECMP).

FORTINET
When the FortiGate is doing ECMP, one of the these four methods is used.
Sessions can be balanced among equal routes depending on the source IP

address, source and destination IP addresses, or interface weight. There is an
additional method called spillover, where the FortiGate will use a primary route until
a traffic volume threshold is reached; after that, another route will be used.

FORTINET
(slide contains animation)
This is an example of ECMP. In the FortiGate routing table, there are two default
routes with the same distance and priority. One using the wan1 interface, another
one using the wan2 interface. So, outgoing traffic is load balanced among the two
ISPs.
If an interface becomes unavailable because of, for example, a physical

disconnection, all routes associated with that link/gateway are temporarily removed
from the routing table.
(click)
So if WAN1 went down, its routes would be dropped from the routing table. The only
remaining available default route for traffic would be through WAN2.
When WAN1 comes up again, then its routes will be loaded back into the routing
table.

FORTINET
If you do not want to load balance, you can change which route will be primarily
used for the outgoing traffic by changing the priority number.
(click)
In this way, FortiGate will simply switch to use the route with the smallest priority.
Remember that both routes are still in the routing table, as long as they both keep
the same distance number.

FORTINET
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 in HA
deployments, or for dual ISP links.
When configured, FortiGate periodically sends 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 via that path. Usually, its best to choose a stable server with robust
infrastructure, and to choose the protocol that the server would normally respond to.
If the FortiGate stops receiving a replay from the server, all the routes using that
gateway will be removed from the routing table. Alternatively, you can configure the
unit to administratively bring down an interface, so all routes using that interface will
be removed. While a server is unresponsive, FortiGate will continue to send link
health monitor signals. As soon as FortiGate receives a reply, it will reinstate the
routes.
It may be useful to choose a server that is indirectly attached, located 1 or 2

hops beyond the FortiGates gateway. This does not exactly test availability of
this one gateway, but rather the combination of gateways. That way, the
FortiGate will accurately indicate availability of services and subsequent hops.

FORTINET
Here is where you configure the link health monitor.
You must enter the egress interface, the IP address of the gateway router, and the
IP address and the protocol (HTTP, ICMP, UDP or TCP) of a beacon that is beyond
that gateway.

FORTINET
Packets are sometimes dropped for reasons where routing and security are related.
Reverse path forwarding (RFP) is a mechanism that protects the FortiGate

and the network from IP spoofing attacks. It checks if there is a valid route back
to the packets source, through the interface where the packet is coming from. If
there is not a valid route, the packet is dropped.
This checking is executed over the first packet of any new session. It is also
executed after a route change, over the next packet in the original direction.
When packets are dropped because of the RFP mechanism, the debug flow will
output an error like the one shown in this slide.

FORTINET
Heres a sample network setup and routing table.
There are two routing errors here, two interfaces that wont route traffic properly.
They are port1 and wan2.
port1 will not route traffic properly. The reason is because of the subnet for the
computers. Theyre in 10.0.0.0/24, and theres no route for that subnet in the routing
table to egress through port1.
(click)
So anything coming from 10.0.0.0/24 to that interface will be dropped because that
subnet cannot be routed back.

FORTINET
The problem is fixed by adding a route to 10.0.0.0/24. Now, when FortiGate does
the RPF check for the incoming packet, it finds a valid route to that subnet through
out port1. The packet is now accepted.

FORTINET
The other interface that will not be able to route traffic properly either is WAN2.
While it is physically connected to the Internet, the only IP addresses that would be
valid as sources or destinations would be those in the 2.2.2.0/30 subnet. So,
incoming Internet traffic will not pass the RPF check and will be dropped.

FORTINET
Once again, this is fixed by adding a route for wan2. In this case, the route needs to
act as a default gateway in order to provide Internet access. To become part of
the routing table, it needs to have the same distance as the default route for
wan1. They both can have different priorities, but as we saw in previous slides, they
must have the same distance to be included in the routing table.
(click)
If the priorities are also the same, this creates a situation like the one we saw for
ECMP. So, if the destination is the Internet, there are 2 possible paths to take:
through either wan1 or wan2. Some sessions will exit from wan1, and others will
exit from wan2.

FORTINET
Reverse path forwarding can be either strictly or loosely enforced.
Loose RPF checks that the sender can be routed out from the interface where the
packet was received. This simply confirms that a response is possible.
Strict RPF requires that the receiving interface is not only valid, but that it is also
the best interface for the reply. If you have multiple routes, it must be the preferred
one.

FORTINET
Lets look at an example of loose RFP.
(click)
In this case, 20.20.20.20 pings 10.10.10.5, but fakes a source IP of 10.10.10.6,

making the packet appear to be initiated from the internal network. Loose RPF
would allow this traffic because the route on wan1 is a default route (0.0.0.0/0),
which is valid (although not the best one).
(click)
What would happen next is that 10.10.10.6 would send the SYN/ACK packet to the
real device with the IP address 10.10.10.5.
(click)
But since 10.10.10.5 is not expecting SYN/ACK packets (because it has not
previously sent any SYN packet to 10.10.10.6), it will reply with a TCP Reset (RST)
packet.

FORTINET
Lets see what happens in the same topology with strict reverse path forwarding.
(click)
Strict RPF drops the packet. The default route in wan1 is a valid route to the subnet
10.10.10.0/24, but it not the best route. The best route is through the internal
interface. So the packet should have been coming from the internal interface.
Although strict RPF is more secure, it can backfire if you use dynamic routing.
Dynamic routes can change quickly, and this fact combined with strict reverse path
forwarding could cause FortiGate to drop packets each time the preferred route
changes.

FORTINET
Some dynamic routing protocols require access to an interface that is always up.
A loopback interface isnt correlated to any of FortiGates physical links. It exists in

the FortiGate software only. So all traffic with that destination stops at your
FortiGate. A loopback interface is always up and available, regardless of physical
cabling.
To create a loopback interface, go to System > Network > Interface and click on
Create New. The type must be loopback Interface.

FORTINET
Link aggregation is when multiple physical interfaces are logically bound into a
single channel. This increase bandwidth and provides redundancy between two
network devices.

FORTINET
WAN link load balancing, on the hand, consists of a group of interfaces connected
to multiple ISPs. Once created, the FortiGate sees all those Internet interfaces as
one single logical interface, the virtual WAN link. This helps to simplify the
configuration as now the administrator only needs to configure a single set of routes
and firewall policies that will be applied to all the ISPs.
There can be only one virtual WAN link per VDOM.

FORTINET
How FortiGate distributes traffic across its WAN links is very similar to how ECMP
does it. It can be based on:
source IP address,
source and destination IP addresses,
interfaces weight, or
spillover (like ECMP)
However, in WAN link load balancing, there is one more method, called measured
volume. With this method, sessions are distributed among all the links based on
each link current bandwidth utilization.

FORTINET
To configure WAN link load balancing, you need to specify which interfaces are
going to be members. In other words, which interfaces are connected to the
Internet. For each member, you can configure health check. If the health check fails,
the member is removed from the WAN link load balancing.

FORTINET
Optionally, you can be more selective and specify that specific traffic services are
routed through specific interfaces that are members of the virtual WAN. Additionally,
you can configure the FortiGate to measure the quality of each link (by measuring
either the latency or the jitter). So, selected traffic services can then be routed to the
interface with the highest or lowest measured quality.

FORTINET
After WAN link load balancing have been configured, a logical interface with the
name wan-load-balance is automatically added to the FortiGate. What you need to
do next is to create the routes and firewall policies that are going to be applied to all
the members of the virtual WAN.

FORTINET
Common routes are used to build a path so that the source can reach the
destination. Black hole routes do the opposite, making the destination unreachable.
Sometimes administrators require the use of wide summarized subnets. To avoid

unnecessary traffic, packets to unused subnets must be dropped. To do this, you
can create a black hole route to silently drop unwanted traffic.
In the above example, all spoke sites (R3, R4 etc.) use addresses in the
172.16.0.0/16 range. They have a routing protocol within their domain to reach the
specific 172.16.x.0/24 subnets. They also have a default route to access the
internet. The link between R1 and R2 is static only.
A packet sent from R3 whose destination is in the 172.16.0.0/16 range (but to a /24
network that does not exist) will take the default route path. R2 will then forward to
R1 and R1 will bounce this back to R2 because of the summarized static route. This
will continue until the packet TTL drops to 0. To prevent it, R2 should have a black
hole route for the network 172.16.0.0/16. In this way, if a packet is destined to a
subnet 172.16.x.0/24 that does not exist, it will be dropped and not forwarded to the
default route path (R1).

FORTINET
Multicast is traffic sent from one source to multiple destinations. A multicast routing
protocol populates the routing tables with information about how to route multicast
traffic.
Multicast is commonly used for video conferencing because it lowers the origins
resource usage and hardware requirements of transmitting to multiple destinations.
One stream of data goes to the router, which then multiplies that into data streams
for each destination.
A FortiGate device can be configure to route and apply NAT over multicast traffic.

FORTINET
Weve seen the routing table in the GUI. Now, lets see some diagnostics you can
use in the CLI.
This is the equivalent CLI command, which shows the routing table.
At the top, each code is defined.
Each route begins with a flag that shows what kind of route it is, or how it was
learned.
After the flag there is the route itself, then the distance and metric. Next you have
the gateway (if there is one), and the egress network interface. Finally, for dynamic
routes, you have a timer that indicates when the route will expire (if not renewed).

FORTINET
This command is very low-level. It shows the actual Forward Information Database
(FIB), which is the routing information that the kernel uses to route traffic.

FORTINET
This command gives a quick list of IP addresses associated with each interface.
They can be physical, VLAN, or virtual interfaces.

FORTINET
If you suspect that there is an IP address conflict, or that an IP has been assigned
to the wrong interface, you may need to look at the ARP table. This command is
used for that purpose. It shows the interface, IP address, and associated MAC
address.

FORTINET
The GUI offers a monitor to check the status of all the members of the virtual WAN
interface. It also shows the status of all the link health monitors configured in the
FortiGate.

FORTINET
To review, here is what we discussed. We talked about not only routing concepts
and configuration, but also diagnostics.

DO NOT REPRINT Virtual Domains
FORTINET
In this lesson, we will show how to configure virtual domains (VDOMs) and common usage
examples.

FORTINET
After completing this lesson, you should have these practical skills that you can use to create
VDOMS and VLANs, which are commonly used logical interfaces when working with virtual domains
in a FortiGate. You will also learn to limit the resources allocated to each VDOM and create per-
VDOM administrative accounts. The lesson also covers inter-VDOM connectivity.

FORTINET
VDOMs are a virtualization within FortiOS, providing virtual firewalls. Interfaces have VDOM
membership, the interface a packet arrives on determines which VDOM will process the traffic.
Interfaces can be physical or logical; IEEE 802.1Q VLANs are a logical interface commonly used with
VDOMS.
VLANs splits your physical LAN into multiple logical LANs. Each VLAN forms a separated broadcast
domain. In a same interface (or collision domain) multiple VLANs can coexist. 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 that it belongs to.

FORTINET
This slide shows a Ethernet frame. The frame contains the MAC addresses, the type, the data
payload, and a CRC code to confirm that is not corrupted.
In the case of Ethernet frames with VLAN tagging, according with the 802.11q standard, 4 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 router or a FortiGate, can change the VLAN tag before proceeding to route
the traffic. In this way, they can route traffic between VLANs.

FORTINET
When operating in NAT/route mode, the FortiGate device operates as a 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.
When operating in Transparent mode, the FortiGate device operates as a Layer 2 bridge in its most
basic configuration. In this mode, a VLAN is an identifier for identifying traffic flows. The VLAN does
not exist on the FortiGate, in FortiOS the broadcast domain which is an accepted as a property of a
VLAN, is defined by the virtual domain, and the broadcast domain can only be modified using
forwarding domains as a sub-division. So to create a VLAN like behavior on FortiOS in transparent
mode, you would need ingress and egress VLAN interfaces using the same VID, and a forwarding
domain within the virtual domain containing those two interface, plus firewall policies to allow traffic.

FORTINET

In this example of NAT/route 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 and adds the VLAN 100 tag on the
tagged trunk link between switch A and the FortiGate, where the VLAN 100 gateway is configured.
(click)
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.
(click)
Switch B receives the frame on the VLAN trunk interface and removes the VLAN tag when it forwards
the frame to its destination on the untagged VLAN 300 interface.

FORTINET
In this example, some computers located in separate buildings are part of the same department:
Accounting. They often share files, which results in much traffic.
But notice the other computers in each location. They are not part of Accounting. They are connected
to the same switch only because they are located in the same room, not because they are logically
related. So, they shouldnt be bombarded with frames from Accounting computers.
To isolate each department, we could use different physically switches in each location to create a
distinct physical LANs. Instead, the network administrator here has decided to use only one switch in
each site and configure network devices to VLAN tag the frames. This causes traffic to be forwarded
only to devices in the same VLAN. To route information between different VLANs, the frame must
reach a Layer 3 router such as FortiGate, which can rewrite the VLAN tag.

FORTINET
To create a VLAN from the GUI, click on Create New and select VLAN as the Type. You must specify
the VLAN ID and the physical interface where the VLAN will be bound to. 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.

FORTINET
So far, weve seen network segments subdivided and unified. It was one organization, with a single
set of policies and a few administrators in effect, a single security domain.
What if you are an MSSP? What if you are a very large company? What if 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.

FORTINET
Remember, VDOMs are a logical separation only each VDOM shares physical resources with the
others.
Unlike with FortiGate-VM, VDOMs are not allocated and balanced with weighted vCPU cores, vRAM,
and other virtualized hardware.
To fine-tune performance, you configure resource limits for each feature IPSec tunnels, address
objects, etc. at both the global level and at each VDOM level. This controls the ratio of each
VDOMs system resource usage to the total available resources.

FORTINET
For example, on this FortiGate, the hardware is powerful enough to handle up to 2000 IPSec VPN
tunnels. The FortiGate is configured with 3 VDOMs.
VDOM 1 and VDOM 2 dont use IPSec VPN tunnels often, so, they are allowed to have up to 50
tunnels each.
VDOM 3, however, uses VPN extensively. Therefore this FortiGate will be configured to allow VDOM
3 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.

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.

FORTINET
Most settings, however, can be configured to be different for each VDOM. Some example are:
firewall policies, firewall objects, static routes, security profiles, etc.

FORTINET
To enable VDOMs from the GUI, in the System Information widget on the dashboard, in the Virtual
Domain row, click the Enable link.
Alternatively, to enable VDOMs when you are logged into the CLI, enter this command.
This wont reboot your FortiGate, but it will log you out; enabling VDOMs restructures both the GUI
and CLI, which you will see when you log in again.

FORTINET
(slide contains animations)
After enabling VDOMs, by default, only one VDOM exists: the root VDOM. Its the default
management VDOM, which we will discuss further soon.
You need to add a VDOM for each of your security domains. If youre an MSSP, for example, you
might add one VDOM per client company. If you are an enterprise business, you might add one
VDOM for each division of your company.
(click)
After adding the additional VDOMs, you can proceed to specify which interfaces belong to each
VDOM.

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 arent assigned to any VDOM.
To enter a VDOM on the GUI, click the Virtual Domains part of the menu. Inside, you will see the
default VDOM, named root. Other VDOMs that you configure will also appear under the Virtual
Domains menu. To access a VDOM, click it and expand its contents.
Inside each VDOM, the submenu should be familiar: it is essentially the same navigation menu that
you had before you enabled VDOMs, except that the global settings moved out, to the Global part of
the menu.

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 will be able to configure all VDOMs.
Best practice dictates that you usually should avoid unnecessary security holes, however. 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.

FORTINET
In most cases, youll start by creating one administrator account per VDOM. He or she will be chiefly
responsible for that domain, including that VDOMs configuration backups. In larger organizations,
you may need to make more VDOM administrators. Multiple administrators can be assigned to each
VDOM. You can subdivide their 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.

FORTINET
To create new administrator accounts and assign them to a VDOM, go to the Global part of the
navigation menu.

FORTINET
To review, each VDOM behaves as 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. With inter-VDOM links, you wont send traffic out through a physical
cable or VLAN, then back into the same FortiGate to reach another VDOM. Inter-VDOM links are a
type of virtual interface.
Note that like with inter-VLAN routing, Layer 3 must be involved you cannot create an inter-VDOM
link between layer-2 transparent mode VDOMs! At least 1 of the VDOMs must be operating in NAT
mode. This, among other benefits, prevents potential layer-2 loops.

FORTINET
When creating inter-VDOM links, youll need to create the virtual interface. You must also create a
matching firewall policy, 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.

FORTINET
In the menu, creating a network interface is located in the Global settings. To create the virtual
interface, click the drop-down menu arrow, then choose VDOM Link.

FORTINET
In the global section of the GUI, there is a VDOM monitor. It displays the CPU and memory usage
per VDOM. It also shows the amount of sessions and sessions created per second.

FORTINET
Up until now, weve discussed traffic passing through FortiGate, from one VLAN or VDOM to another.
What about traffic originating from your FortiGate itself, or destined to it?
Administrator sessions and system daemons, such as NTP and FortiGuard updates, generate this
kind of traffic. When VDOMs are enabled, this means that a special VDOM, known as management
VDOM, must be automatically created so that FortiGate has network interfaces that can continue to
send and receive system-related packets. By default, the VDOM root acts as the management
VDOM, but you can manually re-assign this task to a different VDOM.
Similar to a FortiGate without VDOMs, the administrative VDOM usually should have outgoing
Internet access. Otherwise features such as scheduled FortiGuard updates will fail.

FORTINET
There are a few ways you can arrange your VDOMs. In this topology, each network accesses the
Internet through its own VDOM.

FORTINET
Notice that there were no inter-VDOM links in the previous example. So, inter-VDOM traffic is not
possible unless it physically leaves the FortiGate, towards the Internet, and is rerouted back. This is
most suitable for multiple customers sharing a single FortiGate, each in their own VDOM, with
physically separate ISPs or large pipes, for example.

FORTINET
This is another example.
Like the previous topology, each network sends traffic through its VDOM. But after that, traffic is
routed through the management VDOM by default, named root. So, Internet-bound traffic flows
through a single pipe in the root VDOM.
This could be suitable for multiple customers sharing a single FortiGate, each in their own VDOM.
But in this case, the management VDOM could log and monitor traffic and/or provide standard
services like antivirus scanning.

FORTINET
Note that this topology has inter-VDOM links, but peer VDOMs are only linked with the management
VDOM, not with each other.
Inspection could be done by either the root or original VDOM, depending on your requirements.
Alternatively, you could split inspection so that some scans occur while traffic is in the root VDOM,
ensuring a common security baseline, while more intensive VDOM-specific scans can optionally
occur in the originating or destination VDOM.

FORTINET
Here, traffic again flows through a single pipe in the root VDOM towards the Internet. Traffic
between VDOMs doesnt need to leave the FortiGate either.
However, traffic doesnt need to flow through the management VDOM either. Inter-VDOM links
between VDOMs allow more direct communication.
Like the previous example, inspection could be done by either the root or original VDOM, depending
on your requirements.

FORTINET
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 also be required, and inter-VDOM traffic performance may be better due to a
shorter processing path which bypasses the management VDOM.

FORTINET
This a review of what we covered: VLANs, VDOMs, Inter-VDOM links and VDOM topologies.

DO NOT REPRINT Transparent Mode
FORTINET
In this lesson, we will show you how to configure FortiGate to operate in transparent mode, and
discuss differences with NAT mode.

FORTINET
After completing this lesson, you should have these practical skills that you can use to configure
FortiGate features that are specific to transparent mode, such as STP and port pairing.

FORTINET
Traditional IPv4 firewalls and NAT mode FortiGates are routers, not just switches. So, each interface
has to be in different subnets and each forms different broadcast domains. The FortiGate routes IP
packets based on the IP header information, overriding the source MAC address. So, if a client sends
a packet to a server connected to a different FortiGate interface, the packet will arrive to the server
with a FortiGates MAC address, instead of the clients.
In the case of transparent 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 servers real MAC address FortiGate doesnt rewrite the MAC header. The
FortiGate is a Layer 2 bridge or switch. So, the interfaces do not have IP addresses and all belong
(by default) to the same broadcast domain.
This means that a transparent mode FortiGate can be installed in a customer network without
changing the customers IP address plan. Some customers, specially large organizations, dont want
to reconfigure thousands of devices to define a new internal vs. external network.

FORTINET
Here is an example showing NAT mode.
FortiGate has 3 connected ports, each with separate IP subnets. All interfaces on the 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, which are in most of the cases 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.

FORTINET
Here is an example showing transparent mode. Firewall policies still scan, then allow or block traffic.
But there are differences.
Notice that the physical interfaces on FortiGate have no IPs. So FortiGate wont respond to ARP
requests. There are only 2 exceptions.
When changing to transparent mode, you must specify a management IP address to receive
connections from your network administrators; and send log messages, SNMP traps, alert email, and
so forth. This IP address is not assigned to any particular interface, but to the VDOM settings.
You can configure individual interfaces with an IP to also apply NAT or PAT. (Note that this is rarely
required. NAT with transparent mode is usually a misconfiguration: either FortiGate isnt positioned
correctly in your topology, or the appropriate operation mode wasnt chosen.)
By default, a transparent FortiGate wont do NAT. Also, clients will send frames destined directly to
the real router or server MAC address.

FORTINET
We have mentioned that 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.

FORTINET
In transparent mode, by default, each VDOM has a separate forwarding domain. Interfaces, though,
dont. 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 the destination MAC address. On large networks, this could generate massive broadcast traffic
and overwhelming replies a broadcast storm.

FORTINET
Heres an illustration of the problem a broadcast with all the interfaces on the forwarding domain 0
(default). An ARP whois is sent by a single device. It reaches FortiGate through one of the
interfaces in the VDOM.
(click)
Because they all belong to the same forwarding domain, FortiGate then re-broadcasts to all
interfaces, even to interfaces that belong to a different VLAN. This generates a lot of traffic. But in
theory, the ARP reply still will arrive on only 1 interface, and FortiGate will learn that the MAC is on
that interface. However, what if there is more than one path?
FortiGate would rapidly switch between links because the last interface that receives an ARP reply
with the MAC address will vary slightly. This will cause transmission problems: the 3-way TCP
handshake involves 3 packets, and if the IP session is transferred from 1 interface to another in the
middle of transmission, the handshake will fail.

FORTINET
As we explained, forwarding domains are like broadcast domains.
Heres the same network that we showed before for VDOMs, but here, VLAN 101 is only on 2
interfaces. Placing them in a separate forward domain ID (101) segregates them.
(click)
Traffic arriving on 1 interface is only broadcast to interfaces that are in the same forwarding domain.

FORTINET
You can use port pairing when only two interfaces need to be connected to the same broadcast
domain. This is usually the case, for example, of a FortiGate connected between the internal network
and the ISPs router.
When you configure port pairing, two ports are logically bound or linked, acting like a filtered cable or
pipe. All the traffic that arrived to one port, is forwarded to the other port. This avoids issues related
with broadcast storms or MAC address flapping.
You could make more than one port pair in a FortiGate.

FORTINET
Heres an example where 2 port pairs are used.
This FortiGate has 4 ports, each connected to different physical locations. But traffic is not allowed to
flow between all 4 locations. Port pairing only allow traffic 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, but the networks on
port2 and port1 cant reach the Internet They can only reach each other.

FORTINET
Spanning tree protocol automatically ensures that there are no Layer 2 loops. By default, FortiGate
does not participate in STP learning, nor forward BPDUs. But you can enable it. (You must still
restrict broadcast domains so that they are not overwhelmingly large, though)

FORTINET
To enable the FortiGate to participate in the STP tree, use the config system stp command in the
CLI.
Note that this is only supported on models with switch interfaces, such as FortiGate 30D, 60C, 60D,
80C, and 90D .

FORTINET
Alternatively, and for interfaces that are not switch interfaces, you can either forward or block STP
BPDUs.

FORTINET
This debug command is used to list the MAC address table in a VDOM that is operating in
transparent mode. The table, as we explained before, contains the interfaces that must be used to
reach each learned MAC address.

FORTINET
This is a review of the topics we covered.

DO NOT REPRINT High Availability
FORTINET
In this lesson, you will learn about FortiGate high availability (HA).

FORTINET
When youve completed this lesson, you should be able to configure, operate, and monitor a FortiGate
HA cluster.

FORTINET
The idea of HA is simple. HA links and synchronizes 2 or more devices.
Like HA you may have seen on other vendors products, 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 among all the appliances is used to detect when any unit becomes unresponsive.
What is synchronized among the units? Are all FortiGate devices processing traffic? Does HA literally
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. Lets examine the differences.

FORTINET
Lets examine first the active-passive mode. In any of the two HA operation modes, the configuration
of the secondary FortiGates are synchronized with the configuration in the primary device.
(click)
In the case of the active-passive mode, the primary FortiGate is the only FortiGate device that actively
processes traffic. secondary FortiGates remains 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 what we call HA failover.

FORTINET
The other HA mode is called active-active.
Like with active-passive HA, in active-active, all FortiGates configurations are synchronized. Also, if a
problem is detected with the primary device, one of the secondaries will take over the role of primary
traffic processing.
However, one of the main differences with active-passive mode is that in active-active mode all of the
FortiGates are processing traffic. As we will see later, one of the tasks of a primary FortiGate in active-
active mode is to balance some of the traffic among all the secondary devices.

FORTINET

FortiGate HA requires
First, at least 2, but up to 4, FortiGate devices with the same:

Firmware
Hardware model and VM license
Hard drive capacity and partitions
Operating mode (transparent or NAT)
(click)
Second, at least 1 link between the FortiGate units for the HA communication, which is called
heartbeat traffic. For redundancy, up to 8 heartbeat interfaces can be used. If one link fails, HA will
use the next one by priority and position in the heartbeat interface list.
(click)
Third, the same interfaces on each FortiGate unit have to be connected to the same switch or LAN
segment. Notice that in this illustration, the FortiGate units 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.
(click)
One important change in FortiOS 5.2, related with HA, is that now the cluster can include interfaces
whose IP addresses are assigned dynamically, via either DHCP or PPPoE. Prior to FortiOS 5.2, a HA
cluster could only contain interfaces with static IP addresses.

FORTINET
The process for electing the primary FortiGate depends on a HA setting called HA override. This slide
shows how a cluster elects the primary when that setting is disabled, which is the default behavior:
The cluster compares first the number of monitored interfaces whose status are up. We will talk the
HA monitored interfaces in a later slide. The FortiGate device with the most available monitored
interfaces becomes the primary.
The cluster compares the system uptimes. If the system uptime of a unit is 5 minutes more than the
system uptimes of the other FortiGates, it becomes the primary.
The FortiGate with the configured highest priority becomes the primary.
Then the cluster chooses the primary by comparing the serial numbers.
So with HA override disabled, the uptime has precedence over the priority setting. If for any reason
you need to change which unit 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 command diagnose
sys ha reset-uptime in the primary FortiGate.

FORTINET
You can alter the order of what clusters consider when electing the primary FortiGate.
If the HA override setting is enabled, priority precedes system uptime.
This means you can specify which unit is preferably the primary 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, as it will take back its primary role from the secondary
FortiGate that temporally replaced it.
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.

FORTINET
So, what are the tasks of a primary?
It monitors the cluster by sending HELLO signals, and listening for replies, to know if each other
FortiGate is alive and available. It also synchronizes its routing table and part of its configuration to the
other devices.
You can optionally configure the primary FortiGate to synchronize some traffic session information to
all the secondary devices. This allows a faster and seamless failover for some sessions. Some
customers will not need to reestablish their sessions after a failure in the primary FortiGate. We will
see later which session information can be synchronized.
In active-active mode only, a primary FortiGate also distributes traffic among all the available devices
in the cluster.

FORTINET
Lets see now the secondary FortiGates tasks.
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, though, secondary dont wait passively. They process all traffic assigned to
them by the primary device.

FORTINET
To forward traffic correctly, a FortiGate HA solution uses virtual MAC addresses.
When a primary joins an HA cluster, each interface is given a virtual MAC.

Through the heartbeats, the primary informs all secondaries about the assigned virtual MAC.
Upon failover, a secondary adopts the same virtual MAC addresses for equivalent interfaces.
(click)
The new primary broadcasts gratuitous ARP packets, notifying the network that each virtual MAC
address is now reachable through a different switch port.

FORTINET
As already explained, if a primary fails, a new primary is elected. But, what happens if a secondary
FortiGate unit fails? It depends again 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.
In an active-active cluster, though, 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, but it must also reassign sessions from the failed FortiGate device to a different secondary
FortiGate.

FORTINET
This visualizes 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 cluster.

FORTINET
Lets show how a HA cluster in active-active mode distributes traffic.
(click)
First, the client side sends a SYN packet. Its forwarded always to the primary FortiGate using the
internal interfaces virtual MAC address as the destination.
(click)
If the primary decides that the session is going to be inspected by an secondary, the primary forwards
the SYN packet to the secondary that will do the inspections. In this case, the destination MAC
address is the physical MAC address of the secondary FortiGate.
(click)
The secondary responds with SYN/ACK to the client and starts the connection with the server by
directly sending a SYN packet.

FORTINET
Next the client acknowledges the ACK. Its forwarded again to the primary using the virtual MAC
address as the destination.
(click)
The primary device forwards the packet to the secondary inspecting that session, using the
secondarys physical MAC address.

FORTINET
When the server responds to the TCP SYN, again, the packet is sent to the primary using the external
interfaces virtual MAC.
(click)
So the primary signals the secondary.
(click)
And it is the secondary the one who replies to the server.
The idea is not to load balance bandwidth. The traffic is always sent first to the primary. The main
objective is to share CPU and memory among multiple FortiGates for traffic inspection.

FORTINET
There are multiple events that might trigger a HA failover, such as hardware or software failure in the
primary FortiGate or an issue in one of the primarys interfaces. When a failover is triggers an event
log is generated. Optionally, the unit can also generate a SNMP trap and a alert email.

FORTINET
There are two types of failovers: device failover and link failover.
Lets see the device failover first. It is basically triggered when the primary FortiGate stops sending
heartbeat traffic. In that case, the secondaries renegotiate a new primary.
The other type is link failover. You can configure a 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.

FORTINET
So how do the FortiGate units in a HA cluster communicate?
FortiGate HA uses FGCP, the FortiGate clustering protocol, for HA-related communications. FGCP
travels among the clustered FortiGate units over the links that you have designated as the heartbeats.
A heartbeat link between two devices should be just a cable. If you have another device in between,
such as a switch, ensure that it is dedicated and isolated from the rest of your network. In this way,
critical FGCP traffic does not need to compete with other traffic for bandwidth.

FORTINET
Now, weve seen how HA effectively transfers virtual IP addresses from a failed FortiGate unit to a
different one. What about the heartbeat interfaces?
You dont need to configure them. FGCP will automatically negotiate the heartbeat IP addresses
based on each unit serial number. 169.254.0.1 is assigned to the unit with the highest serial number,
.2 to the device with the second highest serial number, and so on. This IP address assignation does
not change when a failover happens. Regardless of the unit role at any time (primary or secondary),
its heartbeat virtual IP address remains the same.
A change in the heartbeat IP addresses might happen, although, when a FortiGate device joins or
leave the cluster. In those cases, the cluster renegotiates the heartbeat IP address assignment, this
time taking into account the serial number of any new unit, or removing the serial number of any
device that left.

FORTINET
To prepare for failover, a HA cluster keeps configurations in sync. Lets study that now.
FortiGate HA uses a combination of both incremental and complete synchronizations.
When a new FortiGate is added to the cluster,
(click)
the primary compares the new secondary configuration.
(click)
If it does not match, the primary uploads its complete configuration to that secondary.

FORTINET
After the initial synchronization is achieved, the primary will send any further configuration change
done by an administrator to all the secondaries. For example, if you create an firewall address object,
the primary doesnt resend its complete configuration just the new object.

FORTINET
HA propagates more than just the configuration. Some runtime data, such as DHCP leases and
routing tables, are also maintained in sync.
Also, the cluster periodically checks that all units are synchronized. If any secondary is suddenly out of
sync during 5 consecutives checks, a complete re-synchronization is done.

FORTINET
Not all the configuration settings are synchronized. There are a few that do not, such as the HA
override, virtual cluster and device HA priorities, hostname, ping server HA priorities and all the
settings related with the HA reserved management interface (if any). So, this mean that if you want to
be able to connect to each unit directly, you can reserve an interface for HA management, so its
configuration will not be synchronized and each unit can have different management IP addresses.
The HA reserved management interface can also be used by each unit to send SNMP traffic and logs
independently.

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 dont need to reconnect the sessions again.
Once session synchronization is enabled, by default the unit synchronizes TCP and IPSec VPN
sessions that comply with one requirement, which is basically not being handled by a UTM proxy,
such as the antivirus, or web filtering.
You can optionally enable the synchronization of UDP and ICMP sessions. Although both protocols
are session-less, entries are created in the FortiGate session table for each UDP and ICMP traffic
flow. Usually, this synchronization is not required, as most of the network applications based on UDP
or ICMP are able to keep the communication even when their session information is lost.
Synchronization of multicast and SSL VPN sessions is not supported.

FORTINET
So far, weve discussed HA clustering where each FortiGate unit acts as a whole security domain.
But if you have a HA cluster with multiple VDOMs, you can configure virtual clusters.
Virtual clusters allow you, for example, to have one unit acting as the primary for one VDOM and as
the secondary for a different VDOM. Each VDOM has a primary and an secondary FortiGate, and any
unit can act as the primary for some VDOMs, and as the secondary for the other VDOMs at the same
time.

FORTINET
So, virtual clustering offers a failover mechanism per VDOM between two FortiGates. Virtual
clustering can only be configured in a cluster operating in active-passive mode. As traffic from different
VDOMs can go to different primary FortiGates, you can use virtual clustering to manually distribute
your traffic between the two cluster units.

FORTINET
The same as with a standalone device, when upgrading a HA cluster, each updating FortiGate unit
must reboot. 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 former primary device
is upgraded. If the cluster is operating in active-active mode, traffic load balancing is temporally
disabled while all units are upgrading their firmware.

FORTINET
At the beginning, we showed a simple HA topology. Now, lets look at a more robust one. It is called
flush mesh HA.
The idea is to prevent any single point of failure, no only in the FortiGate units, but also in the network
switches and interfaces.
As you can notice in the slide, not only you have two FortiGates for redundancy, but also each
FortiGate is connected to two redundant switches using two different interfaces.

FORTINET
A flush mesh HA is more complicated to assemble and administer, but 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.

FORTINET
FortiGate session life support protocol (FGSP) is an alternative to active-passive HA. It allows per-
VDOM session synchronization between two FortiGate devices in standalone mode.
As we will see in the next slide, it requires external devices to balance sessions between each
FortiGate.
FGSP was formerly known in previous FortiOS releases as session synchronization. However, the
FGSP feature has been expanded to support now not only TCP session synchronization, but also
UDP, ICMP, and NAT session synchronization, as well as configuration synchronization.
With FGSP, TCP sessions can only be synchronized if they do not require security profile or UTM
inspection.

FORTINET
So, FGSP is a simpler solution than HA because traffic redirection is done by external devices. In
most FGSP implementations, two standalone FortiGate devices are installed between two load
balancers.

FORTINET
This is how you configure FGSP on each FortiGate. In this case, the port2 in VDOM root is used for
session synchronization (similar to the heartbeat interface for HA).
(click)
In the CLI, under config system session-sync, you specify the IP address of the other
FortiGate,
(click)
the name of the VDOM where the interface port2 is located,
(click)
and the name of the VDOMs whose sessions are going to be synchronized.

FORTINET
By default, only TCP sessions with no NAT are synchronized. Usually, due to their non-stateful nature,
UDP and ICMP sessions are not required to be synchronized.
However, if such synchronization is wanted, you can enable it with the settings session-pickup
and session-pickup-connectionless.
NAT sessions can also be synchronized with the setting session-pickup-nat.
Finally, we can enable configuration synchronization with the command standalone-config-

sync.

FORTINET
If the HA cluster has formed successfully, the GUI displays all the FortiGates, together with their
hostnames and serial numbers.

FORTINET
From the CLI, although, we can get more information about the status of the HA. For example, the
command diagnose sys ha status displays heartbeat traffic statistics, as well as the serial
number and HA priority of each FortiGate. The command also shows the heartbeat interface IP
address automatically assigned to the primary FortiGate.

FORTINET
When troubleshooting any problem in a HA cluster, it is useful to know that you can connect to the CLI
of any secondary from the primary CLI. 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 use the question mark at the end of that same command.

FORTINET
Another indication of the health of a HA cluster is the status of the configuration synchronization. To
check that all the secondary configurations are synchronized with the primary configuration, you have
to execute the command diagnose sys ha showcsum in all the HA units. If a secondary
FortiGate displays exactly the same sequence of numbers than the primary, its configuration its well
synchronized.

FORTINET
Here is a review of what we discussed. We showed:

The two HA modes: active-passive and active-active
How the primary FortiGate is elected
How the primary FortiGate in an active-active cluster distributes the traffic to the secondaries units
Which events can trigger a HA failover
Configuration and session synchronization
Virtual clustering
FGSP
How to check the health of a HA cluster

DO NOT REPRINT Advanced IPsec VPN
FORTINET
In this lesson, we will show you how to set up IPsec VPN topologies such as partial mesh or full mesh
in other words, complex point-to-multipoint VPNs.
Although well quickly review, you should already be familiar with site-to-site VPNs that are taught in
the basic IPsec VPN lesson. This lesson assumes you are familiar with:
IPsec terminology, such as what is an SA and a peer
Diffie-Hellman exchanges
Quick Mode selectors
Policy-based vs. route-based VPNs
How to configure a point-to-point VPN
How to use the VPN monitor

FORTINET
After completing this lesson, you should have these practical skills that you can use to choose the
right VPN topology for your needs, increase security and availability, optimize VPN performance, and
troubleshoot tunnels.
Unlike a simple static VPN such as between two offices VPNs between multiple dynamic and
static peers require additional considerations.

FORTINET

As we saw in the class for basic IPsec VPNs, on FortiGate, IPsec both authenticates and encrypts
network traffic passing through FortiGate. Although the standard acknowledges the possibility of
expansion, in practice, the 3 most used protocols are:
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
(click)
Each FortiGate uses ESP to transport the packet payload, not AH, although the IPsec standard did
define it.

FORTINET
Since well expand first on IKE, lets review a little about the key exchange, which uses port UDP 500
(and, if NAT-T is enabled, UDP port 4500).
IKE establishes an IPsec VPN tunnel. FortiGate uses it to negotiate with the client and determine the
security association (SA) the authentication, keys, and settings that will be used to encrypt/decrypt
that clients packets. It is based on the Internet Security Association and Key Management Protocol
(ISAKMP).
Each SA is direction-specific. So in two-way traffic, there are 2 SAs per tunnel.
As explained during the basic IPsec VPN class, IKE defines 2 phases. In phase 1, there are two
possible negotiation methods: Main mode and Aggressive mode. Phase 2, where the tunnel keys are
refreshed, only has quick mode. Main mode and aggressive mode have different considerations with
dialup VPNs, so lets study some details of the differences between main mode and aggressive mode.

FORTINET

This shows main mode. 6 packets are exchanged. (click)
First, the client initiates by proposing that the tunnel will use one or more security policies. (click)
The responder selects which security policy it will agree to use, and replies. (click)
Then, the initiator sends its key. (click)
The responder replies with its own key. (click)
Finally, the initiator sends its peer ID and hash payload, (click)
and the responder replies in the same way. (click)
Initially, the responder can only identify the initiator by the source IP address. Nothing else. This is
because the initiators peer ID hasnt been established yet. That works for point-to-point VPNs
because both ends have static IPs, so the responder can predict the clients ID, and knows which
security policies to propose, even if you have configured multiple possible VPN settings. Its also OK
for a dialup VPN where youve configured only one Phase 1: the responder cant predict the IP
address of its peer, but only one proposal is possible. (click)
However, it is a problem for a responder to have multiple possible proposals, and multiple possible
peers. Then, it cant predict which client is connecting at that IP. So it also doesnt know which is the
appropriate tunnel configuration to propose for each incoming connection attempt. So Main mode isnt
appropriate there.

FORTINET

In comparison, lets show aggressive mode negotiation. Only 3 packets are exchanged:
(click)
First, the client initiates by suggesting a security policy, and providing its key and peer ID.
(click)
The responder replies with the same information, plus a hash.
(click)
Finally, the initiator sends its hash payload.
(click)
Unlike main mode, the first packet contains the initiators peer ID. Therefore, the responder can
use this ID (and not only the source IP address) to know who the peer is, and which security policy to
use. It doesnt require a static source address, nor only a single VPN configuration. But because the
peer ID is exposed in the initial, unsecured exchange, attackers could see it and use it to try to make a
fraudulent connection, so its safer to pair this mode with XAuth.

FORTINET
Another advanced Phase 1 option is XAuth.
Phase 1 supports two types of authentication: pre-shared keys and digital certificates. The XAuth
extension to IPsec requires that, between Phase 1 and Phase 2, clients also must supply a user name
and password. So additional packets are exchanged if you enable it, making tunnel startup slightly
slower, and you must configure FortiGate for user authentication.
What is the benefit? Stronger authentication.

FORTINET
Like any half-open stateful connection, IKEv2 can be abused for denial of service (DoS). FortiGate
has built-in protection for this VPN-specific type of DoS attack.

FORTINET
While showing how to choose between main mode and aggressive mode, we briefly mentioned effects
of static vs. dynamic IP addresses. Lets explain further.
When configuring Phase 1, we must specify the type of remote peer. There are 3 types:
Static IP Address
Dynamic DNS. This is where the peers IP is dynamic, but FortiGate can resolve it through a DNS
query. This makes it in effect a static peer.
For example, branch offices often use DHCP from an ISP. The IP address changes, but not often.
So you could use Dynamic DNS to get a static DNS name that resolves to the dynamic IP. Then
you would configure your FortiGate with the peers DNS domain name, which your FortiGate will
query to resolve whenever it needs to connect.
Dialup is (unlike its name implies) not necessarily through a dialup modem. Its where the peers
IP is dynamic, and there is no dynamic DNS. This is often true for branch offices, satellite
campuses, and FortiClient VPN clients.
Can these peers ever receive a VPN connection request?
No, because they are a moving target. Your FortiGate cant predict what their next IP address will be.
Unlike Dynamic DNS peers, there is no way to find their current location on the IP network.

FORTINET
Now that weve seen some effects of dynamic vs. static IP addresses on configuration, lets expand
and see possible topologies with those. There are 5 types:
Point-to-point
Dialup
Hub-and-spoke
Full mesh
Partial mesh
Point-to-point VPNs are simplest. 2 peers basically communicate directly. This topology, and how to
configure it, was covered in the basic IPsec VPN lesson. Now, lets see the other 4 topologies.

FORTINET

First, here is a dialup VPN. Its geometry is simple.
Dialup VPN is used when you dont know where the remote peer will be connecting from, such as with
travelling employees with FortiClient on their laptops.
Unlike site-to-site VPNs, one dialup VPN configuration on your FortiGate can be used for multiple
IPsec tunnels with many remote offices or users. Hence its other name, point-to-multipoint.
(click)
Remember that, in dialup, the clients IP is dynamic, so FortiGate cant predict where it will be. That
means that FortiGate cannot initiate the VPN. Only the remote peer can.

FORTINET
One point-to-multipoint topology variation is called hub-and-spoke. Its name 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 each branch offices FortiGate. For any branch office to
reach another, its traffic must pass through headquarters.
An advantage of this topology is that the VPN configuration and firewall policies are easily managed:
they exist mostly on the central FortiGate. System requirements are also minimal for the branch office
FortiGates, since each only needs to maintain 1 tunnel 2 SAs. In total, only 4 tunnels 8 SAs are
required.
A disadvantage is that especially if headquarters is physically distant like it can be for global
companies communications between branch offices through headquarters will be much slower than
with a direct connection. If your headquarters is in Brazil and you have offices in Japan and Germany,
latency can be very significant. If the FortiGate at HQ fails, VPN failure will be company-wide. Also,
the FortiGate at headquarters must be much more powerful. It must be able to handle 4 tunnels
simultaneously 8 SAs.
So what would a topology look like if some, or all, branch offices could bypass headquarters, and
connect directly to each other?

FORTINET

These are VPNs with a mesh topology. Two variations exist.
(click)
Full mesh connects every location to every other. Like the previous hub-and-spoke example, there
are only 5 locations here. But to fully interconnect, every FortiGate requires 4 VPN tunnels 8 SAs
to the others. This is 3 more tunnels per FortiGate than most in hub-and-spoke. In total, 20 tunnels
are required, not 40. If you expand to 6 locations, it would require 30 VPNs, 7 locations would need
42, etc..
This topology causes less latency and requires much less headquarters bandwidth than hub-and-
spoke. Its disadvantage? Every FortiGate must be more powerful than the average hub-and-spoke
FortiGate.
(click)
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, each
FortiGates configuration is still much more complex than hub-and-spoke. Routing especially may
require extensive planning.
So generally, the more locations you have, hub-and-spoke will be cheaper (but slower) than a
meshed topology. Mesh will place less strain on the central location, and be more fault-
tolerant (but more expensive).

FORTINET
To review, here is a quick comparison. Each topology has its benefits and tradeoffs, so you should
choose the one that is most appropriate to your situation.

FORTINET
Now that weve shown the topological differences, lets look at how to configure them.
Before, we said that hub-and-spoke, full mesh, and partial mesh can be built using a combination of
point-to-point (site-to-site) and point-to-multipoint VPNs. Point-to-point configuration was shown in the
basic IPsec VPN lesson. And dynamic DNS is a slight modification of that. So lets configure point-to-
multipoint, called Dialup VPN on the GUI.
Notice that the steps are the same. What is different? The settings. For each peer, we must:
1. Configure Phase 1.
2. Configure at least one phase 2. In this topology, you can have multiple, corresponding to the
multiple peers.
3. Configure firewall policies.
You may need static routes or a dynamic routing protocol. That way, once a peer joins the VPN and
receives their virtual IP, its traffic can be routed through the VPNs.
Remember there are two different ways to bring up the VPN on FortiGate: policy-based, or interface-
(route-) based.
For policy-based VPNs, additional routing entries are usually not required. Only one bidirectional
firewall policy is required.
For interface-based VPNs, at least two firewall policies are usually required, one policy for each
direction.

FORTINET
If your spokes are FortiClient installations and its a route mode VPN, then often you will want to
enable and configure Mode Config on the hubs Phase 1. This is for an IPsec extension called IKE
mode configuration.
Its usually not practical to allocate static IPs to each of many laptops and mobile phones, for example.
IKE mode configuration is an alternative.
Like DHCP for VPNs, Mode Config automatically configures the clients network settings. Like with
DHCP, you define a range for the pool of VPN virtual IPs, the DNS settings, and the clients gateway
router. Remember, these settings are all for the virtual network not their local LAN. So theyll usually
be different.

FORTINET

Lets start by configuring a Phase 1 for the hub in a hub-and-spoke.
(click)
Since hub-and-spoke topology is a variation of point-to-multipoint, Remote Gateway must be set to
Dialup User.
(click)
If each spoke requires a different policy, then usually we must configure multiple dialup VPNs.
Remember, this requires IKE Aggressive Mode, which in turn requires both the key and the peer ID.
(Main Mode key exchanges dont support one-to-many topologies.)
(Next, when we configure the spokes, the spoke FortiGate or FortiClient on the other end of the VPN
tunnel must use that exact same ID: the hub identifies each spoke by its peer ID, and applies
corresponding VPN settings.)
(click)
To strengthen authentication, you can enable XAuth. The hub FortiGate will use the Enable as
Server setting. (Each FortiClient or spoke FortiGate will use Enable as Client.) Then, we select the
user group than contains all the users (and credentials) that will be accepted by this VPN.
(click)
NAT Traversal should be enabled if your spokes are mobile dialup users, because they are usually
behind NAT at airport terminals, home routers, and hotel firewalls. In this case, youll often want to
enable Mode Config too.

FORTINET
Lastly on the hub, configure Phase 2.

Usually the quick mode selector is 0.0.0.0/0 for both source and destination. This matches any
connecting IP. (By the way, it also now supports IPv6.)
Beginning with FortiOS 5.2, dialup clients can advertise a default route (0.0.0.0/0) as source subnet
selector. Basically, this asks the hub to create a default route pointing inside the newly created tunnel.
There was an accidental src-subnet 0.0.0.0/0 in the spokes phase 2. This could cause an
Internet outage traffic inside the tunnel could not leave the private network to reach the Internet! To
avoid this, FortiOS 5.2 changed Phase 1s default administrative distance (set distance). It was
increased from 1 to 15.

FORTINET

Next, lets configure a spoke. This is Phase 1.
(click)
First, specify whether the hub for this spoke is using a Static IP or Dynamic DNS.
(click)
If the Mode is set to Aggressive, then, in the Local ID, enter the name that this spoke will use to
identify itself to the hub. This ID must match the one we configured on the hub.
(click)
If you enable XAuth on the hub, you must enable XAuth on the spoke, too, and configure the user
name and password.

FORTINET

Finally, this is the spokes Phase 2.
(click)
For the quick mode selectors, the source address (that is, the Local Address) must be the spokes
internal network. For interface-based VPNs, the hub will automatically add a static route to this subnet
from the spokes IP, immediately after the VPN is established. (That way, you dont need to manually
configure the hub FortiGate with all static routes for each spoke.)
(click)
The destination (that is, the Remote Address) usually should be the hubs network. Unlike with the
source network, on the spoke FortiGate, you must manually add a static route to this
destination network its not added automatically.
Note that unlike with point-to-point VPNs, quick mode selectors for point-to-multipoint do not need to
mirror each other.

FORTINET
If your clients are FortiClient, theres a simpler alternative to configure your spokes.
Use the wizard. It will enable IKE Mode Config, XAuth, and other appropriate settings.

FORTINET
We mentioned briefly that hub-and-spoke is inherently not fault-tolerant: if the hub fails, then all VPN
tunnels are down. How can you make your hub-and-spoke IPsec VPN more resilient?
Provide a second ISP connection to your hub, and configure two interface-based VPNs. If the primary
VPN fails, another tunnel can be used instead.
Two types of redundant VPNs exist:
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 it can use an
alternative VPN if, for example, ISP1 or WAN1 fails. But on the other peer (usually the spokes),
both VPNs terminate on the same physical port so the spoke is not fault-tolerant.
Fully-redundant Both peers terminate their VPNs on different physical ports. So both hub and
spoke are fault-tolerant.

FORTINET

So how can we configure a partially or fully redundant VPN?
(click)
First, create one interface-based Phase 1 for each path one Phase 1 for the primary VPN, and one
for the backup. Enable Dead Peer Detection (DPD) so that FortiGate will detect when the VPN tunnel
to its peer is down, and switch to route traffic through the backup VPN.
(click)
Create a Phase 2, too.
(click)
Because these are interface-based VPNs, we must add at least 1 static route per VPN. Routes for the
primary VPN must have a smaller distance than the backup. This causes FortiGate to use the primary
VPN while its available. If the primary VPN fails, then FortiGate automatically adds the backup routes
which have a slightly larger distance, and wouldnt otherwise be used to the routing table.
Alternatively, by the way, we could use a dynamic routing protocol, such as OSPF or BGP.
(click)
Finally, configure firewall policies to allow traffic through both the primary and the backup VPNs. Since
these are interface-based VPNs, at least 2 firewall policies are required per VPN: one for each
direction.

FORTINET
When you configure a VPN via the wizard, it wont allow you to select multiple interfaces so you
cant make a redundant VPN in the wizard. But after, you can do it. Simply edit the firewall policies.

FORTINET
With multiple redundant VPN tunnels for failover, proper dynamic routing would require that a route is
only added when its associated virtual interface and its tunnel are up.
This also allows VPNs to be configured on virtual WAN interfaces. In this way redundancy is built-in:
the VPN will automatically apply to all interfaces current belonging to the virtual WAN. In the future, if
you add to the virtual WAN, you wont need to adjust VPN settings and firewall policies.

FORTINET

As you can see, IPsec VPN configuration can be very complex. What is the best way to solve
problems?
When troubleshooting, look for setting mismatches first. Most connection failures are due to
misconfiguration. Is a route missing? Is a firewall policy missing, or blocking the traffic? Are VPN
settings mismatched?
(click)
If settings are correct, then youll enter most diagnostic commands on the responder FortiGates CLI,
not the initiators. This is because from the initiators side, you can see only what the initiator sends
you cannot read the responders console, which would have messages that indicate why it has
refused the connection. In comparison, the responder can see both: both the initiating packet, and the
responders own decisions and response (if any).
(click)
If both sides of the VPN can reach each other to bring the tunnel up, then look for routing problems
within the virtual network. Remember that once a peer joins the VPN, it has another IP address within
the virtual network. If routes dont exist to allow traffic to be routed between those IPs, then
communication inside the VPN will fail, even though its containing tunnel is up.

FORTINET

If settings are correct, you can use the command line to display details of the VPN tunnel as it occurs.
(click)
Run diagnose debug reset before and after each diagnostic session to reset and enable other
IPsec diagnostic commands. They dont usually significantly impact the CPU. However, you should
always disable them after finishing the troubleshooting, because logging out will NOT stop a
diagnostic command.
(click)
The filter command restricts debug logging to IPsec traffic from a specific remote peer. There are
many different filter options. If the problem is a tunnel that is not coming up, you should filter based on
the initiators IP address. After the filter is set up, you enable the IKE application debug with the value
255 to see all the output.
(click)
The output from the debug command is extensive. It details Phase 1 and 2 negotiations. We will not
show the whole output here, but the next 2 slides will show the most important messages you should
see if everything is OK.

FORTINET

This shows some output for a successful Phase 1 negotiation using Main mode.
(click)
The first line shows the arrival of a VPN connection attempt from the IP address 172.20.187.114. The
third line shows that the packet received was the first Main mode packet.
(click)
A bit later, the debug shows that FortiGate accepted the SA proposal from the remote peer. It shows
the name of the Phase 1 that matches the proposal. In this case, its the name Remote.
(click)
FortiGate replies to the first Main mode packet. Then, the second Main mode packet arrives.
(click)
FortiGate replies again, and the third Main mode packet is received.
(click)
After finishing negotiation, the output will display two messages. They indicate that the key exchange
was successful, and SA was established.

FORTINET

Lets see what is displayed during the phase 2 negotiation. Again the output is much longer than this.
The slide only shows a sample of some parts of that output.
(click)
The first line announces the arrival of the first Quick mode packet.
(click)
The second line shows the Quick mode selector proposed by the remote peer. In this case, it is
0.0.0.0/0 for both the source and destination.
(click)
Some lines below, the debug displays the Quick mode selector that was successful negotiated
between both peers.
(click)
The last two lines finally show that the tunnel is up and the phase 2 SA is established.
If there is any problem in the establishment of either the phase 1 or 2, the output to the console shows
the problem.

FORTINET

If the tunnel is up, but the traffic is not passing through the VPN, we can use the diagnose debug
flow CLI command to troubleshoot. This will display, step by step, what each FortiGate module does
with each packet.
(click)
With the first command, diagnose debug flow filter, set the filter that identifies which traffic
to monitor. For IPsec, we usually filter with a valid IP address in the remote site.
Then we enter the other 4 commands, and send traffic to that remote IP address. For example, we
can try to ping the remote IP address from our local site.
(click)
If successful, we should see an output similar to this.
(click)
This line indicates that the packet was encrypted.
(click)
This other line indicates that the encrypted packet was sent to the tunnel with the name HQ.
If there is a problem either encrypting or routing the packet, the output of this command will show the
problem.

FORTINET
To review, this is what we talked about in this lesson.
We showed how to choose between Main Mode and Aggressive Mode, how NAT Traversal works,
extended authentication, VPN topologies, dialup VPNs, IKE mode configuration, and redundant VPNs.
We also showed how to troubleshoot IPsec VPN tunnels.

DO NOT REPRINT Intrusion Prevention System
FORTINET
In this lesson, we will show you how to use FortiGate IPS. IPS is part of what
makes FortiGate a UTM that can keep pace with the latest attacks.
The lesson also covers DoS protection.

FORTINET
After completing this lesson, you should have these practical skills. Essentially, you
will learn how to use your FortiGate to study what is normal for your network, then
detect and block rate anomalies and mechanism attacks.

FORTINET
Before we begin, its important to understand: Not all attacks can be 100%
positively identified. Sometimes, there is uncertainty.
What is the difference between an attack and an anomaly? To compare, FortiGate

IPS uses attack signatures where it can detect an attack with relative certainty and
performance. But the IPS engine also can use heuristic methods to find statistical
anomalies unusual order in the packet flow. An example: the client uses the
HTTP MKCOL method, but your web site has only static web pages, so its
suspicious to use a method for dynamic sites.
Many anomalies indicate a DoS attempt. So, FortiGate also provides DoS
protection, which is executed either by specialized hardware or the kernel.

FORTINET
Lets define what IPS currently means on FortiGate. You may be surprised.
On older systems, IPS might have meant purely a Snort-style signature matching. It
was similar to anti-virus signatures, but for protocols instead of files.
But on FortiGate UTM, IPS has evolved to also detect anomalous traffic patterns
and to apply heuristics that prevent an unexpected behavior of the protocol.
(click)
Why? Arent IPS signatures enough?
Some attacks cant be successfully or efficiently defined in a signature. If the attack

is qualitatively or quantitatively too similar to legitimate traffic, IPS false positives will
block your network service not the result you want.

FORTINET

How does the IPS engine determine if a packet contains an attack or anomaly?
Protocol decoders parse each packet according to the protocol specifications. Some
protocol decoders do require a port number specification (configured in the CLI), but
usually, the protocol is automatically detected. If the traffic doesnt conform to
specification if, for example, it sends malformed or invalid commands to your
servers then the protocol decoder detects the error. For example, a stream of
packets might match the HTTP decoders pattern named
Cisco.CatOS.CiscoView.HTTP.Server.Buffer.Overflow.
(click)
A default, initial set is included in each FortiGate firmware. FortiGuard IPS service
updates them, sometimes daily, with new signatures. That way, IPS remain effective
against new exploits. Unless a protocol specification or RFC changes (which is not
very often), protocol decoders are rarely updated. The IPS engine itself changes
more frequently, but still not often.
What part of IPS is updated most? The IPS signatures. New signatures are
identified and built during the day by FortiGuard research teams, just like with anti-
virus. So if your FortiGuard Services contract expires, you can still use IPS.
However, just like with anti-virus scans, IPS scans will over time become
increasingly ineffective old signatures wont defend against new attacks.

FORTINET
Regular updates are vital. If your FortiGate doesnt have the latest signatures,
your network is vulnerable. Always make sure that your FortiGate has a reliable
Internet connection, and that it is scheduled to often request updates from
FortiGuard.
What is included in a FortiGuard IPS update? Protocol decoders, the engine, and
signatures. The signature database is subdivided into Regular and Extended.

FORTINET
Regular signatures are common attacks whose signatures, during testing prior to
release on the FortiGuard Distribution Network, caused rare or no false positives.
So its a smaller database, and its default action is to block the detected attack.
Extended signatures contain everything else. In FortiOS 5.2, the IPS extended
database is enabled by default for all FortiGate models that
have multiple CP8. Otherwise, they are disabled, because either:
Performance impact is significant, or
Nature of the attack doesnt support blocking
By default, the Regular database is selected, not the Extended. In fact, due to its
size, the extended database is not available for FortiGate models with a smaller
disk and/or RAM. But for high security networks, you may be required to enable
extended signatures. In that case, you should mark the Enable Extended IPS
Signature Package option on System > Config > FortiGuard.

FORTINET
When your FortiGate downloads new IPS signatures, or a new engine, syntax may
change. So if you write your own custom signatures, especially after upgrading your
FortiGates firmware, you may need to check if its still compatible.
IPS involves anomaly inspection, deep packet inspection, full content inspection,
activity inspection, and heuristic detection. Some software does not maintain a
constant pattern. Skype and other peer-to-peer software, for example, periodically
change in order to avoid detection. So in order to correctly identify it, IPS requires
heuristics and adaptive detection.
As a result, FortiGuard IPS also provides updates for application control, for
example.

FORTINET
When your FortiGate downloads a FortiGuard IPS package, new signatures will
appear in the signature list. For each sensor that uses a signature, when
configuring, you can change its Action setting.
The default often is correct, except if:

Your software vendor releases a security patch. Continuing to scan for exploits
will waste FortiGate resources.
Your network has a custom application with traffic that inadvertently triggers an
IPS signature. You can disable it until you notify Fortinet so that FortiGuard can
modify the signature to avoid false positives.
The list of IPS signatures also indicates the severity level. What do the indicators
mean?

FORTINET
The FortiGuard severity level is based on the CVSS 2 rating system. There are
many contributing factors. For details, go to the first.org web site.
Do all severity levels match CVSS exactly? No.
Fortinet always marks remote code execution as high or critical severity, regardless
of the CVSS rating. Details are explained on the FortiGuard web site.

FORTINET
Do you have the CVE ID or Microsoft ID for a specific vulnerability, but dont know if
there is a corresponding IPS signature yet?
On the FortiGuard web site, you can search for the latest IPS signatures. But you
can also read details about recently discovered zero-day attacks, white papers,
blogs and security advisories.

FORTINET
If youre not sure if you should enable an IPS signature on your FortiGate, you can
search the FortiGuard web sites encyclopedia.
The encyclopedia has useful information such as affected systems and

recommended corrective actions. So if you dont use that protocol or dont have a
vulnerable system, you can safely disable the corresponding signature. But if you
are vulnerable, the encyclopedia can provide information about how to protect
yourself.
The FortiGuard encyclopedia only contains publicly disclosed vulnerabilities,

though. Obviously it cant contain vulnerabilities that, for whatever reason, cant yet
be responsibly disclosed.

FORTINET
Exploits for unknown vulnerabilities called zero-day attacks are sold for large
amounts of money on the black market. Since these exploits arent known to their
vendors, nor to security experts, theres no available patch or signature for
detection. Thats what makes them so dangerous.
Some companies and organizations like Facebook and Google have offered
bounties for the responsible disclosure of these exploits, but theres a very profitable
market for black hat hackers to sell these discoveries to everyone from covert
government surveillance to organized crime syndicates.
Zero-day attacks are the keys to your networks kingdom.

FORTINET
If you notice an attack, your initial self-defense instinct may be to immediately take
the server offline, then format it to remove all traces of malware. But by doing this,
youll alert the attacker, and destroy forensic evidence. For motivated attackers, this
will only educate them their next attack will be harder to detect, and more
sophisticated. Make sure your PSIRT team understands the most appropriate
way to respond to each different type of intrusion.
If youre vigilant, and if you have the resources, you can also write your own custom
IPS signatures. Well talk about how to do that next.

FORTINET
Before you write custom IPS signatures, lets first explain how the IPS engine
works.
FortiGate doesnt compare traffic to each signature individually. This would require
the CPU to load from disk and then evaluate each complete signature. In total,
when fully enabled, this would be more than 8,000 disk accesses and comparisons.
So instead, IPS compiles them into a decision tree, similar to the example shown
here.

FORTINET
FortiGate loads this entire decision tree into RAM. This can increase memory usage
significantly, especially on desktop FortiGate models that dont have much RAM. So
if your RAM usage is already high, you should reduce it first before enabling IPS.
Otherwise, your FortiGate may immediately enter conserve mode, and refuse to
accept any more configuration changes! But the advantage is that the tree takes
much less CPU and total RAM for a full IPS scan.
To make the tree, FortiGate breaks down signatures into identical pieces port,
protocol, etc. and shares the evaluation. So if traffic does not match that part, then
the IPS engine can bypass comparisons with all similar signatures. But if it does
match, then IPS continues with the next shared segment of the signature. When it
finds a match, FortiGate applies its corresponding action.
Remember discussing the difference between attacks and anomalies? Detecting

uncertain attacks can require even more ongoing analysis, and more RAM to store
traffic statistics. So if your CPU usage or RAM usage is high, and if you dont
require anomaly analysis for all protocols, clients, or servers, disable it. Better yet,
offload it to an NP FortiASIC if your FortiGate model has them. Hardware
accelerated anomaly detection can be configured in the CLI.

FORTINET
To write custom signatures, first use packet capture to record packet samples.
Understand and avoid mismatches with normal packets on your network, including
at other OSI layers such as Layer 2 and Layer 3, which will be evaluated first.
Remember: if you misconfigure a custom signature, or if you configure a custom

signature that is no longer supported after you update the FortiGate firmware or IPS
engine, problems like this often arent included in Fortinet Technical Support. So if
possible, you should also test your custom signatures in a lab.

FORTINET
Well show one example here.
(click)
All start with F-SBID(.
(click)
After that, protocol-specific key words define what part of the packet to search for a
match, and what values comprise a match. Usually, a keyword is followed by a
corresponding value that is its setting, except for a few standalone keywords such
as --no_case. Each key-value pair ends with a semi-colon and a space. You can
include multiple key-value pairs. The signature ends with the closing parenthesis.
A reference to syntax for custom IPS signatures is in the FortiGate Handbook.

Supported key words vary by the protocol decoders. For example, the SMTP
protocol supports the VRFY command, and so there is a protocol decoder flag for
it.. So if you create custom signatures, you should be sure to read the Release
Notes and new Handbook before upgrading, and (if possible) test the firmware
before installing it in a live traffic environment. Lets see some examples.

FORTINET
Here is a sample custom signature called Ping.Death. It searches for ICMP traffic
that exceeds about 32 KB.
(click)
After you create and save the signature, FortiGate will automatically add an attack
ID. So dont include it when you enter the signature.
(click)
Next is a signature for HTTP.
It searches for the pattern POST in a very specific location inside the packet. In
normal HTTP POST requests, the method should be in this specific location. This
prevents IPS from scanning the entire HTTP payload, which could contain a web
page that accidentally matches, for example, due to the words POSTAL CODE.
Your signature should be specific, but not too specific extra comparisons reduce
performance.

FORTINET
Once you have created your custom signature, pair it with an action within an IPS
sensor. Then reference that IPS sensor in a firewall policy.
The steps are the same, by the way, regardless of whether you want to use custom
signatures or ones predefined by FortiGuard.

FORTINET
Heres an example of an IPS filter being created.
To include all signatures in the filter, weve marked ALL options. To include only a
few signatures in the filter, we would only mark one option. For example, if we only
marked the Client option, only 4 signatures would be included in the filter.
Each individual signature can have multiple tags, such as HTTP, Microsoft, IIS, and
TCP. The more specific you can make your filter, the less resources will be used to
scan your traffic, because its parts will seldom match and so the IPS engine will
quickly continue with the next comparison or scan.

FORTINET
When the IPS engine compares traffic with the signatures in each filter, order
matters. The rules are similar to firewall policy matching: topmost filters are
evaluated first, and the first match applies. Subsequent filters are skipped.
So position most likely matching filters at the top of the list, unless they might cause
false positives. (Position those last, so that FortiGate will test them only if no
previous, more sure signature matches.) Avoid making too many filters, since this
will increase evaluations and CPU usage. Also avoid making very large signature
trees in each filter, which will increase RAM usage all unique pieces of the attack
pattern must be loaded into RAM. Strike a balance. If an attack can be prevented in
hardware (by NP FortiASIC chips, for example), or by another method (by
disallowing an unnecessary protocol at the firewall level, for example), do this first.
Then, for the remaining, craft careful IPS sensors to protect relevant vulnerabilities.
For rate-based signatures (previously called anomalies), you can choose how to
match: by source IP, destination IP, DHCP Client MAC, or DNS Domain Name.
Choose whichever will generate the least entries yet behave correctly. For Internet-
facing policies, this is unfortunately one that requires IPS to analyze many clients
connections: Source IP. So enable only rate-based signatures for vulnerable
protocols you actually use. Then block malicious clients for extended periods. This
saves system resources and can discourage a repeat attack: FortiGate will not track
statistics for that client while it is temporarily blacklisted.

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

FORTINET
So far weve shown signatures that match illegal commands and invalid protocol
implementations. Those are easy to confirm as an attack.
What about attacks that function by exploiting asymmetric processing, or bandwidth

between clients and servers? There are many ways to make a Denial of Service
attack. Some denial of service (DoS) attacks, for example, exhaust limited server-
side bandwidth or sockets. Unless you know what bandwidth is abnormal for your
network, you may not be able to confirm an attack.
(click)
The goal is to overwhelm the target to consume resources until it cant respond to
legitimate traffic. This can be done in various ways. High bandwidth usage is only
one type of DoS. Many sophisticated DoS such as Slowloris dont require high
bandwidth.
For high-bandwidth DoS, remember that although your FortiGate blocks traffic
floods, the flood is still consuming bandwidth up to the point of its external interface.
So your servers are protected from impact, but if the upstream network is not, so
your servers may still be effectively unavailable. Especially for distributed denial of
service attacks, you must work with your ISP to fully prevent high-bandwidth DoS.

FORTINET
To block DoS attacks, apply a DoS policy on a FortiGate that is between attackers
and all resources that you want to protect.

FORTINET
DoS protection exists for 4 protocols: TCP, UDP, ICMP and SCTP. Each one has 4
different types of anomaly detection.
A flood sensor detects a high volume of that particular protocol, or signal in the
protocol.
Sweep/Scan detects attempts to map which of a hosts ports respond and
therefore may be vulnerable.
Source signatures look for large volumes of traffic originating from a single IP.
Destination signatures looks for large volumes of traffic destined for a single IP.

FORTINET
If you do not have an accurate baseline for your network, then when you implement
DoS for the first time, be careful not to completely block network services. To
prevent this, initially configure the DoS policy to log but not block. Using the logs,
you can analyze and determine normal and peak levels for each protocol. Then
adjust the thresholds to comfortably, but not loosely, allow the usual peaks.
Thresholds that are too high can allow your resources to be exhausted before the
DoS policies trigger. Thresholds that are too low will cause FortiGate to drop normal
traffic.

FORTINET
Now we will take a look at some common types of DoS attacks. The first is called a
SYN flood.
In TCP, the client sends a SYN signal to initiate a connection. The server must
respond, then remember the start of the connection in RAM while it waits for the
client to acknowledge (or ACK). Until ACK, the connection is only half-formed,
so it wont show up in a connection table. Normal clients will quickly ACK and
begin to transmit data. But malicious clients continue quickly or slowly, to avoid
detection to send more SYN packets, half-opening more connections, until the
servers table is full. Then, the server cannot accept more. It begins to ignore all
new clients. Depending on the system, this attack can also damage hardware.
(click)
To defend against this, FortiGate acts as a pseudo-proxy. It waits until the client has
finished connection build-up to form the back-end connection. If this doesnt
complete quickly, FortiGate begins to drop the attackers connection requests from
the table.

FORTINET
Another type of anomaly is an ICMP sweep. ICMP is used during troubleshooting:

devices will respond with success or error messages. But attackers can use this to
probe the network for valid routes and responsive hosts.
(click)
This provide information about your network before the attacker crafts more serious
exploits.

FORTINET
An individual DoS attack is a flood of traffic coming from a single address. It can
originate from the Internet or even from your internal network. Typically a single
device makes many connections or sessions, and possibly uses much bandwidth to
a single location.
(click)
All four protocols in the DoS profile (ICMP, TCP, UDP, SCTP) have an anomaly
sensor for the source. These are built to examine the traffic each IP is generating
and compare that to the threshold value.

FORTINET
A variation of this is the DDOS, or Distributed Denial of Service attack. It has many
of the same characteristics. The main difference is that multiple devices are all
attacking at the same time. This could be 5, or maybe 50, or 500 or more devices
attacking together.
(click)
Remember earlier when we showed that despite FortiGate protecting the host, the
resource could still become unavailable if the bandwidth to the ISP was consumed?
Think about how these detections work. They do not trigger until the threshold is
reached. Lets say, for example, that the DoS sensor doesnt trigger until 5000
sessions occur within 1 second. These 5000 sessions are allowed: first come, first
served. So if multiple external devices are all generating connections to the same
destination, attackers which are creating connections the fastest, will be the ones
most likely to get the connections. Many of these DoS attacks can physically
damage systems, so the goal is to prevent that from happening and prevent this
kind of damage.
But how can you find the right threshold? You must know what normal traffic
thresholds are on your network in other words, the baseline.

FORTINET
Everything we have shown so far is inline scanning: traffic passes through FortiGate
from one interface to another. But you can also deploy FortiGate outside of the
direct path of packets, in a one-arm topology with a monitor-only mechanism. This
is also called sniffer mode because it detects but does not block.
To do this, connect FortiGate to a switchs SPAN or mirroring port. The switch will
send a duplicate of egressing packets to FortiGate, which FortiGate then scans.
Notice that because its scanning a copy not the original packet it cant modify or
block the original packet.

FORTINET
When should you use one-arm IPS?
Historically, when IPS scanning was first invented, it was slow. Old IPS could
introduce high latency. So one-arm deployment was common, but IPS on an inline
firewall wasnt.
Now, hardware performance is much better. And one-arm has a significant

limitation: one-arm FortiGate cannot block traffic. Because its on a mirrored port
on the switch, not directly in between the attacker and your protected network,
FortiGate isnt placed to intervene. So today, most people use one-arm only during
testing or evaluation. Think of one-arm IPS as log-dont-block.

FORTINET
Before sniffer mode, the only way you could demonstrate a FortiGate without
changing IP addresses was to put it transparently inline with the traffic. This could
potentially disrupt the network if you didnt understand the Layer 2 topology. But
now, there is no risk.

FORTINET
Sniffer mode is enabled on a FortiGates physical interface, not a logical interface

such as a VLAN.
After you select One-Arm Sniffer on an interface, you can choose any security
profile that uses the IPS engine. For example, you can use an application control
profile if it is flow-based, since flow-based scans use the same engine as IPS. (One-
arm DLP is also configurable, but via the CLI only.)
FortiGate wont allow you to choose proxy-based profiles that arent supported in
one-arm inspection.
Why arent all profiles/actions supported? Its not technically possible. This is due to
the nature of the topology and asynchronous scanning. To modify traffic or proxy
connections, FortiGate must be in line not out of band on a SPAN port and
stop the packet until it finishes scanning. That is, inspection must be in sync with the
connection. However, one-arm scans after the interface has already forwarded the
packet. Scanning and forwarding are out of sync. Since the packet has already
egressed, FortiGate cant proxy or block. Thats why its not possible to support all
features in this mode.

FORTINET
Now lets see some logs that are generated by IPS.
Anomalies and signature matches have different logs associated with them.
Since an anomalys name already gives information about the traffic and the attack,
such as protocol and source address, many details in the logs arent needed.
But you often will require information about which applications or operating systems
are vulnerable. You also need to know the action whether FortiGate blocked or
simply monitored (detected) the attack. If you configured FortiGate to only monitor,
you may need to forensically investigate the targeted host. This is where host-based
tripwires can be useful.

FORTINET
When DoS policies generate logs, they are aggregated. When several incidents
occur together, this reduces the number of log messages.
In large attacks, the number of incidents can easily reach 100,000 in a few
seconds. Generating a log entry for every packet that matches would completely
utilize the CPU. So instead, FortiGate collapses incidents by periodically recording
only one message for all of them, and noting the number of incidents.
Here, the detection threshold was 50, and the total count is 75. So FortiGate
doesnt make 24 separate log entries (1 for each incident above 50). Its just one log
message.

FORTINET
In the CLI, use diag ips anomaly list to show all hosts that are currently
being limited by DoS policies, and by what signature. If theres no matching traffic,
then it will not display any output.

FORTINET
Another available diagnostic command is diag autoupdate version. This

lists various IPS databases and engines that are installed on the FortiGate.
It also displays the results of the last update attempt. So it can be useful if you
suspect interruptions to FortiGuard connectivity.

FORTINET
Another command that can be used is troubleshoot the IPS is diag test app
ipsm.
For example, you could type diag test app ipsm 99.

FORTINET
What does the IPSEngine actually do?
Notice that if you run the diag test app ipsm 5 command, and if you have
any kind of flow-based inspection profile, the CPU usage of the IPSEngine process
drops dramatically, but doesnt reach 0.
This is because IPSEngine is responsible for most of the things weve shown in this
class: intrusion protection, and protocol decoders. Its also responsible for
application control, flow-based policies for antivirus, web filtering, email filtering, and
DLP.

FORTINET

The difference between a signature that matches a known attack, versus one that
matches a traffic pattern anomaly
How protocol decoders find anomalies, and how this is different than proxy-based
scans
Severity levels
How to configure IPS sensors, including ones with custom signatures
Denial of Service attacks, which are a type of anomaly
One-arm deployment, both its limitations and purpose
IPS logs
Diagnostic commands for IPS, including expected output, since some processes
of the IPS engine are used by other scans

DO NOT REPRINT FSSO
FORTINET
In this lesson, we will talk about Fortinet Single Sign On (FSSO). With this FortiGate feature, your
users do not need to log in repeatedly, each time they access a different network resource.

DO NOT REPRINT FSSO
FORTINET
After completing this lesson, you should have these practical skills. You will be able to compare the
access methods for collecting user login information using FSSO. You will also learn how to configure
and test an FSSO solution to transparently authenticate users.

DO NOT REPRINT FSSO
FORTINET
FSSO enables FortiGate to leverage your networks existing authentication system for firewall
authentication. Once a user logs in, he or she can access other network resources without having to
authenticate again.
FSSO is typically used with directory service networks such as Windows Active Directory (AD) or
Novell eDirectory. But it can also be implemented in other network environments.

DO NOT REPRINT FSSO
FORTINET
Depending on the server that provides your directory services, you will deploy and configure FSSO
differently.
In this presentation, we are going to talk mostly about the two methods available for Windows Active
Directory environments.

DO NOT REPRINT FSSO
FORTINET
Lets start with the domain controller agent mode. It requires:
One domain controller agent installed on each Windows domain controller. (If you have multiple DCs,
this means multiple DC agents.) The DC agents, as we will see later, monitor and forward user logon
events to another FSSO component called the collector agent.
The collector agent is installed on a Windows server. It consolidates events received from the DC
agents, then forwards them to FortiGate.

DO NOT REPRINT FSSO
FORTINET
Here we show what happens between DC agents, the collector agent, and a FortiGate configured for
FSSO authentication.
When users authenticate with the DC, they provides their credentials.
(click)
The DC agent notices the logging event, and forwards it to the collector agent.
(click)
The collector agent aggregates all logon events, then forwards that information to FortiGate. The
information sent by the collector agent contains the: User name, Host name, IP address, User
group(s). Now FortiGate knows who the user is at that IP address, and which Active Directory group
permissions also apply.
(click)
So if the person now tries to access the Internet, FortiGate compares the source IP address to its list
of active FSSO users. In this case, the user has already logged on, so FortiGate will not request the
user to authenticate again.

DO NOT REPRINT FSSO
FORTINET
Lets see polling mode. This can be either agent-based, or agentless.
First, lets look at the agent-based polling mode. Like the DC agent mode, this requires a collector
agent to be installed on a Windows server. However, it doesnt require DC agents installed in each
DC. But the tradeoff is that the server with the collector agent must be more powerful, and it will also
generate unnecessary traffic when there have been no logon events.
In this mode, the collector agent contacts periodically the DC and gets its information directly.

DO NOT REPRINT FSSO
FORTINET
Lets see an example of FSSO using the agent-based polling mode. Here again is a DC, a collector
agent, and FortiGate. But the DC doesnt have an agent installed.
(click)
The collector agent periodically polls the DC to ask if anyone has logged in.
(click)
Next, the collector agent sends the login information to FortiGate. This is the same as the DC agent
mode.
(click)
When user traffic arrives at the FortiGate, it already knows who is at that IP address, and no repeated
authentication is required.

DO NOT REPRINT FSSO
FORTINET
In the cases of agent-based polling mode, there are two methods (or options) for getting logon
information:
Security Event Log (WinSecLog): Polls the security events on the DC. It does not miss any logon
events, because events are not normally deleted from the logs. But there can be some delay in
FortiGate receiving these events if the network is large and therefore writing to the log is slow.
NetAPI: Calls the netsessionenum function on Windows. This is faster than the other method,
because it is reading a table in RAM. But the other effect is that it can sometimes miss 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.

DO NOT REPRINT FSSO
FORTINET
Finally, you can alternatively deploy FSSO without installing any agents. FortiGate will poll the DCs
directly, instead of receiving login information indirectly from a collector agent.
Because FortiGate collects all of the data by itself remember, the DCs never initiate contact with a
FortiGate to send login information this method requires greater system resources on your
FortiGate, and it doesnt scale as easily. Additionally, this mode supports only the WinSecLog option.
It does not support the NetAPI option as in the case of agent-based polling mode.

DO NOT REPRINT FSSO
FORTINET
Here we see FortiGate polling the DC. There is no collector agent, nor any DC Agent.
(click)
After the user logs in, FortiGate will discover that authentication during its next poll.
(click)
Again, when the user sends traffic, FortiGate already knows whose traffic that is.

DO NOT REPRINT FSSO
FORTINET
Regardless of the login collector method you choose, some FSSO requirements for your Active
Directory network are the same:
Microsoft Windows logon events only have the workstation name and username, but not the
workstation IP address. When the collector agent gets 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.
Collectors must have connectivity with all workstations. Because an event log is not generated upon
logoff, either the FortiGate or the collector agent (depending on the FSSO mode) must use a different
method to verify whether users are still logged on. So, polls are done to each user workstations to see
if users are still there.

DO NOT REPRINT FSSO
FORTINET
This table summarizes the main differences between DC agent mode and polling mode.
DC agent solutions are usually more complex: it requires not only a collector agent, but also a DC
agent per DC. However, its more scalable because the workload is distributed among all of the
agents (the collector agent and the DC agents). Additionally, this deployment offers redundancy,
because you can have more than one collector agent. And because the DC agent is hosted on the DC
itself, all logon events will be captured and recorded.
In comparison, if you use polling, some logon events might be missed or delayed, depending on the
polling option used.

DO NOT REPRINT FSSO
FORTINET
In an Active Directory environment, FSSO can also work with NTLM authentication. We will see next
an example of how NTLM authentication works.
NTLM authentication does not require DC agents, but it is not fully invisible to users: they must enter
their credentials again when the NTLM negotiation happens. Also, NTLM authentication is a Microsoft-
proprietary solution, so it can only be implemented in a Windows network.
NTLM is most useful when either:

Users log into DCs that, for some reason, cannot be monitored by the collector agent, or
When there is a communication problem between the collector agent and one of the DCs agents. In
other words, NTLM authentication is best used as a backup to FSSO.

DO NOT REPRINT FSSO
FORTINET
This shows how the messages flow during NTLM authentication.
The process is triggered when FortiGate receives traffic from an IP address that doesnt exist in the
list of active FSSO users.
(click)
FortiGate replies with an NTLM challenge, requesting credentials.
(click)
The user enters the user name and password.
(click)
FortiGate receives them, then authenticates them with the collector agent. FortiGate will also get from
the collector agent the user groups that the user belongs to.
(click)
If the credentials are correct, FortiGate authorizes the access.

DO NOT REPRINT FSSO
FORTINET
We mentioned that, unlike full FSSO, NTLM authentication is not transparent for users. This is
because, in most of the browsers, and by default in Internet Explorer, users must manually enter their
credentials whenever the browser receives a NTLM authentication challenge.
However, Internet Explorer can be configured to automatically send the users Active Directory
credentials each time it receives an NTLM challenge. To do this, open Internet Explorers Internet
Options dialog and switch to the Security tab. Then click the Custom Level button and select the
option Automatic logon with current user name and password.

DO NOT REPRINT FSSO
FORTINET
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 guess users
that do not belong to the Windows Active Directory domain.
However, if both passive and active authentication are in placed, the behaviors is different. Users that
do not belong to any FSSO group will be prompted to enter their credentials.

DO NOT REPRINT FSSO
FORTINET
Another FSSO setting that we must configure is called AD Access Mode. It specifies how the
collector agent accesses and collects the user and user group information. There are two modes:
standard and advanced.
Differences include the naming convention used to provide the domain and user name.
Standard mode uses the Windows convention: Domain\Username.
Advanced mode uses the LDAP convention: CN=User, OU=Name, DC=Domain.
If there is not any special requirement, use standard mode. Advanced mode, however, supports
nested or inherited groups. This means that users may be members of subgroups that belong to
monitored parent groups. Additionally, advanced mode enables FortiGate to apply protection profiles
to individual users and to user groups. In comparison, with standard mode, protection profiles can only
be applied to user groups not individual users.

DO NOT REPRINT FSSO
FORTINET
Lets see the FSSO configuration now. This is the collector agent. From the FSSO Agent
Configuration application, we can configure settings like the:
Listening port for the communication with the DC agents.

Listening port for the communication with the FortiGate.
Enabling or disabling NTLM authentication.
And, enabling pre-shared password authentication between the collector agent and the FortiGate.
From the FSSO Agent Configuration tool, we can also access the collector agent logs, which can be
used to troubleshoot FSSO issues.

DO NOT REPRINT FSSO
FORTINET
By clicking on the Set Directory Access Information button, we can select either standard or
advanced Active Directory access mode.

DO NOT REPRINT FSSO
FORTINET
FortiGate FSSO configuration is straightforward.
If FortiGate is acting as a collector for agentless polling mode, we must select Poll Active Directory
Server and configure the IP addresses and Active Directory Administrator credentials for each DC.
If we have external collector agents (either using the DC agent mode or the agent-based polling
mode), we must select Fortinet Single Sign On and configure the IP address and password for each
collector agent.

DO NOT REPRINT FSSO
FORTINET
Lets see now some of the diagnostic commands available in FortiGate for FSSO.
To shows the status of the communication between the FortiGate and each collector agent, use the
CLI command diagnose debug authd fsso server-status.

DO NOT REPRINT FSSO
FORTINET
To display the list of FSSO users that are currently logged on, use the command diagnose debug
authd fsso list. For each user, we see the user name, user group, and the IP address and
workstation name from which they logged in.

DO NOT REPRINT FSSO
FORTINET
These are some additional FSSO commands, all of them under diagnose debug authd fsso.
For example, there are commands for:
Clearing the FortiGates cache of all currently logged in users.

Filtering the display of that list.
Refreshing the logon and user group information.

DO NOT REPRINT FSSO
FORTINET
Here is an overview of what we discussed. We compared the methods for collecting user login
information using FSSO. We also showed NTLM authentication and AD access modes. Additionally,
you learned how to configure FortiGate and the collector agent for FSSO, how to troubleshoot it and
monitor it.

DO NOT REPRINT Certificate Operations
FORTINET
In this lesson, you will learn how to manage certificates on FortiGate, and how to inspect the contents
of encrypted traffic.

FORTINET
After completing this lesson, you should have these practical skills in certificate management, such as
how to upload certificates, private keys, and CRLs where appropriate, and how to configure a
FortiGate device and browsers to use certificates and keys for SSH, SSL, or TLS content inspection,
as well as troubleshooting common misconfigurations.

FORTINET
Secure traffic protects your communications between you and someone else. There are 4 properties
that define security in this case: data privacy, data integrity, authentication, non-repudiation.
Not all secure channels will require all four features. The RFC for IPSec VPN allows tunnels to be
built with no encryption. However, people almost always want privacy for important data and its
usually pointless to make data private if you dont know who sent it, and that it hasnt been tampered
with, in practice, most secure traffic has at least the first 3 properties.

FORTINET
Data privacy is achieved with encryption. Encryption applies an algorithm and key to the information,
making it unintelligible to a third party before it travels across the network. Only the intended recipient,
who also knows the pattern, is able to decrypt the data and access the information. There are multiple
ciphers in common use, such as triple DES and AES-256. The strength of a cipher varies by the
computational requirements for an attacker to recover the plain text.

FORTINET
Your data may be private, but could be corrupted in transit or falsified by a third party, therefore your
traffic isnt secure. How do we guarantee that an encrypted message arrived intact? There are
several methods to verify data integrity; generally these are checksums (CHKSUM), or one-way
hashes, which generate a unique value from applying the hashing algorithm to the original clear text.
The sender would send the cipher text and the hash; the receiver would recover the plain text and
recalculate the hash, if the calculated hash is the same as the received value, then the message is
intact.

FORTINET
Authentication is a cornerstone of secure computing. When transmitting and receiving secure data, it
is important to include the identity of the message originator. Asymmetric cryptography is often used
to achieve this: a message checksum is calculated and signed using the senders private key, the
receiver recovers the checksum using the senders public key, which is commonly published in a
certificate; this mechanism is used in PKI.

FORTINET
Authentication supports the concept of non-repudiation, which means a sender cannot claim they did
not send a particular message because the senders identity is bound to it. Again, data integrity is
important because you want to ensure non-repudiation data is not forged.

FORTINET
Several methods of encryption involve using a piece of data called a key to mathematically scramble
the message in a way that only the recipient can predict and undo.
In symmetric cryptography the same key is used for encryption and decryption, both sides agree upon
an algorithm and generate the same key, before sending messages. Plain text is processed through
the agreed symmetric algorithm and key, generating the encrypted text, or cipher text. The receiver
reverses this process to recover the plain text.

FORTINET
A key generation mechanism is required to generate the shared keys; this mechanism needs to be
secure and repeated regularly to limit the amount of data exposed should a key be compromised.
Symmetric cryptography is typically used for the bulk encryption of user data, because it is
computationally much faster than asymmetric encryption, discussed next.

FORTINET
Asymmetric cryptography is a technique that uses a pair of keys: a public key and a private key. Both
keys are mathematically related. They are generated from the same random number, and using the
same key generator algorithm. However, because of the algorithm (large prime numbers are popular
since these are impossible to factor, and very difficult and rare to find) it is extremely difficult to get the
private key from the public key. It is practically impossible to guess the public key from the private
key. What is encrypted with the private key can only be decrypted with the public key. In a similar
way, what is encrypted with the public key can only be decrypted with the private key.

FORTINET
Public keys are distributed publicly. Private keys are never distributed, and must be kept secret by the
owners.
Public keys can be distributed using different methods: email; secure web sites; public repositories;
using a Public-Key Infrastructure (PKI) server such as a CA (Certificate Authority).
Private keys must be stored in a secure and private place, such as a file in a single physically secure
location with very restrictive permissions.

FORTINET
In this example of asymmetric cryptography, the sender obtains the recipients public key to encrypt a
message, only the recipient can decrypt this message using the corresponding private key. If the
identity of the public key cannot be verified, using PKI, then there is a potential for a man-in-the-middle
attack, allowing a third party to view the clear text without having to brute force the encryption key.

FORTINET
How can encryption be used to strengthen authentication?

A digital certificate is a digital credential that identifies someone or something. That someone or
something could be either a network user, a network service or a network device. The certificate
contains information about the entity that is being identifying, including the entitys public key. A
digital certificate is issued and signed by a Certificate Authority (or CA), which certifies that the digital
certificate and its content, is trustable and valid.

FORTINET
Digital certificates can be classified into three groups.

A CA certificate identifies a certificate authority. It contains the CAs public key that is needed to
decrypt the signatures in the local service and user certificates.
A local service certificate identifies a network service, such as an HTTPS web site or email server.
A user certificate identifies a network user.
User and local service certificates are also called end-entity certificates.

FORTINET
Certificates include information about the entity. They also contains information about the CA that
signed the certificate.
These are the most important fields that any certificate has:
There is a serial number that is unique to each certificate signed by the same CA.
In the case of a user certificate, the Subject: contains the user login name.
In the case of a local service certificate, the Subject: can contain either the FQDN or the IP address
of the server.
The Signature of the CA is encrypted using the CAs private key.
The Issuer field is the name of the CA that signed the certificate.
The Valid-From: and Valid-To: fields specify when the certificate is valid, including the expiration
date.
Key-Usage: defines the roles and activities the certificate can be used in.

FORTINET
When a user authenticates, they send a digital certificate which includes not only their public key, but
also the signature of the CA that certifies their certificate, which is encrypted using the private key of
the CA.
The authentication server must trust the CA. In other words, it must have the certificate of the CA
that signed the users certificate. That CA certificate contains the CAs public key, allowing the
authentication server to decrypt/validate anything encrypted/signed by the CAs private key.
Additionally, for a user certificate to be valid, it cannot be listed as untrustworthy in a certificate
revocation list. Furthermore, the user certificate must be within its validity period; that is, not expired.
If any of these verifications failed, the user authentication would fail.

FORTINET
An HTTPS server(a website) identifies itself by using a digital local service certificate. When a user is
connecting to the web site, the browser receives the web sites local service certificate. In this case, it
is signed by a CA called CA1 and the signature is encrypted using CA1s private key.
The users browser must trust the entity that issued the certificate. In other words, it must have the
CA certificate of CA1 installed, which contains CA1s public key. This public key is used to decrypt and
validate the signature in the web sites local certificate. The most common browsers already have pre-
installed the CA certificates of the well-known public CAs. So, installing the CA certificate in the
browser is usually not required as long as the web sites certificate has been signed by a well-known
CA. However, it is a required step if the certificate has been signed, for example, by a private CA.
The browser also verifies that the certificate is still valid and has not expired yet. Additionally, the
certificate must not be listed in any certificate revocation list. If any of these verifications fails, the
browser will give a certificate warning to the user, indicating that something is not right with the site
being visited.

FORTINET
SSL is the cryptographic protocol used by the HTTPS protocol, and by other standard protocols, such
as SMTPS and FTPS. When a connection is made to an HTTPS site, this is the protocol used
between the web server and the browser to authenticate and encrypt the data. This is a fairly
simplistic look at how SSL negotiations happen, which highlights both client and server certificate
validation.
1. First a secure (HTTPS) URL is entered into the browser.
2. The browser then sends a Hello packet to the web server which includes the local certificate.
3. The server evaluates the certificate for validity. Does it trust the CA that signed the certificate? Is
the certificate still valid? Has the certificate been revoked? The server evaluates the clients
certificate in order to decide if it meets whatever security options there are.
4. Assuming the certificate is accepted the server sends a Hello back with its own certificate and the
browser performs its own security checking on the servers certificate.

FORTINET
The browser (as the client) creates a symmetric key. This symmetric key is encrypted using the
servers public key which was received as part of the certificate in the Hello. The encrypted symmetric
key is then sent to the server and decrypted using the servers Private key. A 3rd party that does not
have access to the private key of the server or browser cannot decrypt the traffic, because even if they
have the symmetric key they dont have the private key needed to decode the information.

FORTINET
The final part of setting up encryption between parties is to negotiate exactly which protocol and
cypher are going to be used in the communications. Both sides advertise what options they support.
After that, the 2 sides propose combinations until an agreement is reached regarding how the
encryption will actually work (which protocols will be used). If a setting can not be agreed upon then
just like a rejected certificate the entire connection fails. Once both sides agree on what encryption to
use, the data that is being sent gets put through those algorithms and encrypted using the symmetric
key and public key from the other side, before it gets sent over the connection.

FORTINET
In a SSL session, asymmetric cryptography is used to generate and share a symmetric key. After that,
symmetric cryptography is used to encrypt the user and server data. The symmetric key is valid only
for the length of the session. If you close the current session, that symmetric key is no longer valid
and cannot be used again. When a new SSL session is created, a new symmetric key will be created
between the browser and the server.

FORTINET
The most common way of getting a digital certificate for a FortiGate or server is by generating the
private and the public key first. Usually, those two keys are generated internally by the device where
the certificate is going to be installed. After that, the public key is given to a public Certificate
Authority, such as GoDaddy, or Verisign usually in the form of a *.CSR file. CSR stands for Certificate
Signing Request. The CA verifies first that the information submitted is valid. After that the CA
generates and signs a digital certificate, which contains the public key sent by the user. The CA will
also encrypt the certificate and its signature using its private key.

FORTINET
The FortiGate generates the private and public keys. The public key is stored in a file with the
standard format PKCS#10. The file contains what is called a Certificate Signing Request (CSR). The
CSR also contains information about the network device as entered by the Administrator, such as IP
address (or FQDN), and company name. Once the details are completed this can be downloaded and
sent to a CA for signing. After the CSR is submitted, and while waiting for the signed certificate,
FortiGate will show the certificate as Pending.

FORTINET
Certificate Signing Requests can be created on the FortiGate by going to System > Certificate > Local.
When and admin clicks on generate, the CSR form must be filled out in order to set the details and
fields that will be included in the certificate. After the CSR has been created, the status of the
certificate will be Pending. While the status is Pending the certificate can not be enabled or used.
The administrator can now download the PKCS#10 file and submit it to the CA.

FORTINET
When the administrator receives the signed certificate back from the CA, it must import it to FortiGate.
After that the status of the certificate will change from Pending to OK, meaning it can be used.
Adding a certificate that the FortiGate will use in SSL communications can be done without generating
and signing a CSR. In that case, all 3 parts of the certificate must be loaded: The signed certificate,
the public Key and the private Key/password. PKSC#12 is a file format that combines the Certificate
and the Public key into a single file. Since the certificate will be used as part of encrypted
communications the private portion is still required.

FORTINET
If you wish to have the FortiGate unit preventing certain certificates from being used, then you will
need to maintain a Certificate Revocation List (CRL). A CRL contains the serial numbers of all the
digital certificates that cannot be trusted anymore. For example, digital certificates of ex-employees
that left the company can be added to the list. When FortiGate is validating a certificate, it will check
that its serial number is not listed in a CRL. CRLs must be kept up-to-date manually by the
administrator.

FORTINET
CRLs can be created and managed under System > Certificates > CRL in the FortiGate GUI.

FORTINET
Digital certificates stored in a FortiGate device can be separately backed up to a PKCS#12 file. The
file will include the keys (private and public) and the certificate itself. The backup and restore can be
done only from the CLI and requires the use of a TFTP server. Once this information is backed up, it
can be restored back to the same FortiGate device. We can also restore it to any other FortiGate,
regardless of the model, or firmware version.
A backup of the FortiGate configuration also includes the keys and certificates. However, in the case
of the configuration backup, the restore can only be done to a FortiGate unit of the same model and
running the same firmware version.

FORTINET
Some FortiGate devices offer a mechanism to inspect and apply protection profiles over SSL
encrypted traffic. It is called SSL Content Inspection. Under normal circumstances (without SSL
Content Inspection), encrypted traffic cannot be inspected, as the firewall does not have the key that is
required to decrypt the data.
In order to work, the FortiGate must be located in the middle of the communication between the users
browser and the web site example.com. When the browse connects to the site, the web server sends
its certificate, which contains its public key. Its certificate has been issued to example.com by a CA.
The FortiGate intercepts the web server certificate and generates a new one on the fly. The new
certificate is also issued to example.com, but this time it is issued by the CA installed on the FortiGate,
which may not be a public CA. The FortiGate also generates on the fly a new pair of public and private
keys. The new certificate contains the public key generated by the FortiGate.
So, now the FortiGate unit will use the FortiGate public key, not the web servers public key, to start
the encryption to the users browser. On the other side, it will use the web servers public key to start
the encryption and establish the conversation with the server.

FORTINET
SSL Inspection requires a SSL Proxy certificate that allows the unit to generate a new pair of keys,
and a new certificate. The unit must do it on the fly and each time the user is connecting to a different
site. In other words, the FortiGate must act as a sub-CA. So, the certificate that is required for SSL
Inspection is not a usual one, but one that has either the CA field equal to True, or the Key Usage
includes KeyCertSign. The FortiGate models that support SSL Inspection come from factory with one
SSL Proxy certificate that can be used to SSL Inspection. It is called Fortinet_CA_SSLProxy and is
signed by a CA called FortiGate CA, which is not public

FORTINET
When doing SSL Inspection, your browser will start displaying a certificate warning each time a user is
connecting to a HTTPS site. The reason for this warning is that the certificates received by the
browser are now being signed by the FortiGate, which is a CA that the browsers do not know and
trust. There are three ways for avoiding this warning:
The first option is to download the certificate used on the SSL Proxy and install it in all the
workstations as a public authority.
Another option is to generate a new SSL Proxy certificate from a private CA. In that case this
certificate will need to be installed into the FortiGate and configure the unit to use it for SSL Inspection.
This private CA may still need to be and installed in all the workstations.
Finally you may be able to purchase a suitable certificate from a public CA.
This is not a limitation in FortiGates, but a consequence of how digital certificates were designed to
work.
The only way for any vendor device, to inspect encrypted traffic is to intercept the certificate coming
from the server and generate a new one. In other words, the unit must do a man-in-the-middle attack
or have the private keys already installed.

FORTINET
Replacing the certificate on the traffic can cause problems. Some software or servers have specific
limitations on the certificates that are allowed to be used.
HSTS is a security feature of the google browser Chrome. It is designed to detect Man-in-the-middle
SSL attacks by making sure that any certificate presented when accessing a google resource is
signed by a specific CA. If it detects any other CA it will simply refuse to continue the SSL handshake
and prevent access to the website.
The options available for this are limited.
The only option that will allow content of the traffic to be inspected is to replace the certificate on the
SSL Proxy with one that will satisfy the security settings.
Another option is to disable the settings causing this. HSTS can be turned off in chrome, but this is
not an option in all environments.
The last option is to bypass SSL inspection of that traffic.
Other servers or software can have their own requirements on the certificates that get used for SSL.

FORTINET
Whenever a Private CA is used for the SSL Proxy its important to remember to install that into your
software as a Certificate Authority (CA).
Failure to do this will result in warning messages in web browsers anytime there is access to any
HTTPS website. It may also result in encrypted communications failing, simply because the CA on
the certificates is untrusted.
Once the certificate is downloaded off the FortiGate it can easily be installed into any web browser or
software. Not all software uses the same certificate repository. For example, Firefox and Internet
explorer are both web browsers but they use different certificate repositories. In order to avoid
certificate warnings in both browsers the SSL Proxy certificate needs to be installed as a root authority
in both browsers.
When the certificate is being installed its important to make sure that it is properly setup as a root
authority. Normally setting a certificate up as an authority requires a few manual selections to be
made in order to properly classify the certificate. Exactly how it is done and what needs to be done
manually will vary from one software to another.

FORTINET
Once an appropriate SSL Inspection certificate is installed on the FortiGate, enabling SSL inspection
is quite simple. First, an SSL inspection profile needs to be created and configured. Here, we can
specify which SSL Proxy Certificate is going to be used for SSL Inspection. The dropdown list will
only show only the certificates that are valid for use with SSL Inspection.
Once the certificate is selected, the secure protocols that will be inspected can also be selected.
There is no option in any UTM profile to apply separate rules for secure traffic. The encrypted version
of the protocol will be inspected with the same rules as the non-encrypted one. For example. HTTPS
traffic will be inspected with the same options that have been enabled for HTTP.
The inspection method selected will impact all of the enabled UTM profiles. If this is set to SSL
Certificate Inspection then none of the SSL content can be scanned. This will prevent some feature
from functioning altogether (Virus scanning, some DLP options..) and impact the accuracy of the rest.

FORTINET
Within the SSL inspection profile there is a section that allows for exemption of traffic some SSL
inspection. There are a number of reasons why this may be necessary.
The first reason would be that the act of SSL Inspection causes a problem with the traffic. HSTS with
chrome, for example. Unless an appropriate certificate is used chrome will drop the connection. If
access to google with chrome is a requirement and an appropriate certificate cannot be used, the only
option is not to do SSL inspection of that traffic. Googles network is vast so setting up an exemption
with a firewall policy may not be a feasible workaround, so the option is built into the SSL Inspection
profile.
Another reason that it may be necessary to bypass SSL inspection on some of the traffic would be for
legal reasons. In the some countries it is illegal to do SSL inspection of banking related traffic for
example. Again, setting up Firewall policies for each individual bank could be tedious, so configuring
an exemption for specific categories (like Finance and Banking) would be simpler. Become familiar
with whatever local laws may apply to encrypted internet traffic in your jurisdiction.

FORTINET
After an SSH Inspection profile has been created and configured, it must be applied to a Firewall
policy in order to start inspecting traffic.
The purpose of the SSH Inspection profile is to define exactly how encrypted traffic is handled.
From the GUI, enabling any kind of UTM profile also requires an SSH Inspection profile to be enabled.
This does not mean that traffic must be subjected to SSL Inspection and subject to Man-in-the-middle
decryption by the FortiGate. It simply means that how encrypted traffic will be handled, needs to be
defined when you enable UTM.
From the CLI however, an SSL Inspection profile is not required because this is a more advanced
method of configuration. UTM inspection without an SSL Inspection profile will result in encrypted
protocols being ignored through that firewall policy.

FORTINET
A FortiGate device can be configure to user certificate-based user authentication for admin users.
Users with a digital certificates are called PKI users.
After the first user has been created from the CLI, you can now add that PKI user to a group.
Once a PKI user has been added to group, that group can now be selected as part of the PKI user
configuration for administrative users.
The CA needs to be loaded onto the FortiGate in order to verify and compare the Certificate that gets
presented. Assuming this CA is secure and kept private this will allow administrative users to connect
without needing to login. The user information is linked to the certificate that gets presented for the
SSL communications when attempting to access the administrative interface.

FORTINET
Under certain circumstances it is possible for the FortiGate to do inline SSL decoding, rather then
normal man-in-the-middle inspection.
Inline decoding it performed by the IPSEngine, rather then the SSL proxy. The IPSEngine is not a
proxy so doing this does not break communication on layer 3, the way a proxy does. In order to
accomplish this, the key negotiation is modified so that the traffic can be decrypted as needed.

FORTINET
Not all SSL connections can be decoded inline. It is only possible when certain technologies are
being used.
The IPSEngine looks at the SSL handshake as it is happening. If it detects, Client Channel, NPN,
ALPN, or SPDY, then inline inspection is used automatically. If they are not detected then the SSL
traffic is handed over to the SSL proxy for man-in-the-middle negotiations.

FORTINET
https://technotes.googlecode.com/git/nextprotoneg.html
NPN is a feature of Google Chrome designed to control application layer protocol negotiation. The
purpose is to help choose the protocol to use for encryption in order to help optimize secure
communications. This is an older feature that is being phased out. As of Chrome versions 20 and
later, it is disabled by default.
NPN is not a encryption protocol. It is a method of performing the encryption handshake.

FORTINET
http://www.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation
ALPN is the same idea as NPN. It helps to optimize and speed up SSL negotiations. While it has the
same purpose the design is very different. In NPN the server makes the initial declaration of
protocols, which the gets confirmed by the client. In ALPN this is reversed and the client makes the
initial declaration. All the protocols that get listed in the exchange are forced to use the IANA standard
numbering.
ALPN (like NPN) is not an encryption protocol. It is a method for doing the encryption handshake and
decides what kind of encryption to use.

FORTINET
Another aspect of ALPN is that it allows for streaming. Normal SSL communications only allows for 1
piece of data to be transmitted through a session encrypted with SSL. ALPN allows for multiple data
streams within a single TCP session, bypassing the need to initiate new encrypted sessions for each
piece of data.

FORTINET
A high level comparison of NPN and ALPN shows the differences in how those 2 technologies alter
the SSL handshake.
In the case of NPN the initial Hello includes the declaration that the client supports the NP Extension.
When a server also supports this, it hellos back that it also supports this along with the options for
encryption. The client completes the handshake and advertises which protocol will be used to used
for the session.
Looking at ALPN the difference is that the protocol options for the session come from the client along
with the initial handshake. The server selects the encryption protocol and sends that information with
its Hello and the client finishes the SSL handshake as normal. The end result is that ALPN results in
less overall packet overhead compared to NPN.
In both cases, if the server does not support the extension it returns a normal Hello and SSL
communications continue normally.

FORTINET
http://www.wikipedia.org/wiki/SPDY
SPDY is a protocol supported by all versions of Chrome as well as newer versions of other browsers.
Like NPN or ALPN it is also a protocol designed to optimize SSL. Its in use on some of the larger
web service provides on the internet currently.
SPDY is an actual encryption protocol, unlike ALPN or NPN which are an extension of SSL. Rather
then simply focusing on being secure like other methods of encryption, it also has considerations for
allowing users to download content faster.
Traffic is not simply encrypted, it is subjected to several different methods to reduce the amount of
data that flows over the wire. Common parts of the data are turned into tokens to reduce their size
and other parts are compressed using GZIP or DEFLATE. This reduces the amount of data that is
being sent in order to help improve load times.

FORTINET
Here is a review of the topics that were discussed:

Methodologies for securing network traffic
How symmetric cryptography works
How asymmetric cryptography works
Digital certificates
Certificate-based user authentication
Mechanics of the SSL handshake
Generating and signing certificates
Importing certificates
Managing CRLs
Mechanics of content inspection
Certificate warnings
Installing the certificate from the FortiGate as a root authority
Configuring and enabling SSL content inspection

DO NOT REPRINT Data Leak Protection
FORTINET
In this lesson, we will show you how to prevent crucial private data, such as bank account routing
numbers and credit card numbers, from leaving your network, and from being inappropriately
transmitted.
Data leak prevention is required by some compliance regimes, such as PCI DSS and HIPAA, but
other networks may also find it useful to help prevent, for example, student cheating.

FORTINET
After this lesson, you should have these practical skills, such as knowing when to use DLP, and
knowing how to monitor specific data types, and how to configure DLP filters and sensors.

FORTINET
FortiGate has other features, such as IPS and antivirus, that can detect and block files. What makes
DLP different? Why should you use it?
Traditional firewalls and first-generation UTMs were designed to prevent attacks and nuisances from
getting into your network. Web filtering is only applied to traffic coming in. Likewise, despite best
practice to apply it in both directions, many people apply antivirus and email filtering only to traffic
coming in.
But DLP is to prevent specific data from getting out.
How can traffic that is leaving your network affect security?
Often its normal for co-workers to share sensitive documents inside your network. Sensitive
information is also normal between servers that work together to host a single application. But if
sensitive data such as financial information becomes public, it can have serious effects. Stock prices,
bank transactions, privacy, and password security can all be compromised.
So DLP helps to ensure that your network follows the rules required by your real-world organization,
and doesnt give out important information.

FORTINET
So how does DLP work?
FortiGate scans traffic matching your firewall policy for the DLP patterns that you specify.
When you configure a pattern, whether pre-defined or custom, DLP doesnt directly inspect traffic
itself. Instead, it communicates the pattern to the proxys or IPS engines processes, which actually do
the scanning. So remember that when troubleshooting, you may need to investigate flow through
modules that you didnt manually enable.
If the scan finds a match, it executes the filters corresponding action. So, in the example here, the first
2 filters didnt match the file, but the 3rd one did, so FortiGate performed its action.

FORTINET
Now that weve seen the basic idea, lets start from the beginning show how to add filters in a DLP
sensor. Initially, well use some default file filters and message patterns. Later, well show how to
customize and expand them. Most DLP behavior is dependent on the filter type. So well show that in
depth. But first, lets briefly see the service inspection and action.
First, change the GUI menu settings to show DLP. (By default, its hidden. To show it, go to System >
Config > Features.)
Then, go to the DLP submenu that is now available: Security Profiles > Data Leak Prevention >
Sensor. Create a DLP sensor. Inside it, add a filter.
In each filter, well specify:

match criteria
which protocols to scan
actions that FortiGate will apply when traffic matches
In the Examine the following Services area, choose which network protocols should be scanned.
Like with other security features, secure protocols arent in the list of scannable network services.
However, if you enabled SSL/SSH Inspection, FortiGate will scan both each protocol that you
choose and its secure equivalent. For example, if you mark the check box for HTTP, FortiGate will
also scan HTTPS. More information is in the lesson on certificates.

FORTINET
To scan secure protocols, select an SSL/SSH inspection profile in the traffics matching firewall policy.
With DLP, you usually need a profile that does full inspection.
There are two levels of inspection:

Certificate-only
Full content inspection
Certificate inspection only verifies the certificate and any unencrypted headers that are sent before
encryption begins. Because FortiGate doesnt interrupt the handshake, for certificate inspection, DLP
cant scan contents. So this mostly effectively bypasses DLP. When would it be effective? Only if you
need to act on the certificate or URL of a web site, for example. The client sends this before the
encryption handshake occurs.
What if we want to scan inside the payload of the packet?
In full inspection, FortiGate terminates the SSL/TLS handshake at its own interface, before it reaches
the server. When certificates and private keys are exchanged, it is with FortiGate, and not the server.
Next, FortiGate starts a second connection with the server. Because traffic is unencrypted while
passing between its interfaces, FortiGate can inspect the contents and look for matches with
DLP sensors, before it re-encrypts the packet and forwards it.

FORTINET
For each filter in the DLP sensor, you must indicate the Action what FortiGate should do if traffic
matches.
The default setting is Log Only. If youre not sure which action to choose, this can be useful initially.
While you study your network, use this action to see what sensitive information is being transmitted,
then later fine-tune your sensor and select the most appropriate action to block sensitive files from the
WAN.

FORTINET
Now lets return to the top of the filter, which is the more complex part of the configuration. Choose the
type: either Message or Files. Most other available options depend on this initial choice.
Messages scans for words, credit card numbers, or other text-based patterns directly embedded in
the protocol, not as a file. There are two preconfigured Messages filters available: Credit Card and
SSN.
If the pre-defined DLP patterns dont match exactly what youre looking for, to configure your own
custom pattern, you can use the Regular Expression option.
Use PCRE syntax. Supported expressions and performance with complex Turing complete
expressions always vary by the regular expression engine, so if youre looking for references, look
specifically for PCRE, not others such as the similarly-named Perl language.
File changes the available options to be appropriate for files, such as file size, fingerprinting, and
watermarking.

FORTINET
In this example, we are blocking credit card numbers from leaving the network using preconfigured
Message filter.
Block action also generates log, which can be viewed under Log & Report >Traffic Log > Forward
Traffic.
Log Details provides important information that security event matches DLP and it is blocked.
DLP provides additional information such as Filter Type, Filter Category, DLP Profile Name.

FORTINET
If you choose a File type for the filter, and select Specify File Type option; File Types and File
Name Patterns becomes available.
File Types is based on examination of file contents, regardless of the file name/extension. Even if the
file is renamed with different extension, DLP will still detect it. It has a corresponding drop-down menu
where youll select which file types to scan for.
File Name Patterns is based on examining and filtering purely on the names of files and are
configured manually.
Here is an example file filter table that matches all Microsoft Office files. Notice that, to do this, it
contains sub-filters of both types. This is because:
Older versions of Office use a binary file format, identifiable by a binary file type scan.
Office 2010 and newer files are not binary, but a ZIP archive. They are actually XML files inside
a ZIP archive. This is documented on the Microsoft website, but the link here is easier to read.
Its crucial to realize that because Office 2010 uses a nested file type, if you use file type
filters with them, they will accidentally match any ZIP file, not just Office files. This is a
common DLP misconfiguration. So to avoid false positives with these newer versions of Office,
the default profile matches by file extension instead. Note, however, that the tradeoff is possible
false negatives.

FORTINET
Lets explain the file-specific sub-filters.
File name patterns are intuitive. If a file name either:

matches literally, or
matches the pattern
then FortiGate will perform the action.
As a result, if an important file name varies (which is usually the case users may try to evade DLP
by renaming files to a harmless-sounding name), then you should use patterns, not the literal file
name. Configure FortiGate to match all intended file names but no unintended file names. For
example, browsers often rename downloads of duplicate file names to prevent accidentally overwriting
an existing different yet identically named file. Before the file extension, for example, they would add
(2) . Likewise, Windows renames copies of file so that they start with Copy of. So usually you
should use a name pattern such as nice*.jpg, not the literal file name, nicepainting.jpg.
The example here shows which filters would match the file name, and which filters wouldnt.
But what if the file name doesnt match any pattern? What if the file name is radically different, and
therefore a broad pattern would cause false positives? What if we want to block all executables
regardless of name or platform, for example?

FORTINET
File name matching alone is often not enough for very sensitive data. You may want a more
sophisticated filter. One addition or alternative is to use file type filtering.
File type matching behaves as youd expect. This is because file types are identified not by the
extension such as .doc in that case, users could circumvent DLP by simply renaming the
extension. Instead, FortiGate enforces file type scans the binary for matching binary patterns how
that file type stores data in specific areas, in specific patterns of 1s and 0s. The tradeoff for this
accurate technology, however, is that unless FortiGate has a corresponding decoder that
understands the binary data structure, it cannot decipher the string of zeros and ones, and therefore
cannot identify the file type.

FORTINET
To return to our DLP sensors filter, when scanning files, types and names arent our only option.
On most networks, its typically not an option to block all Microsoft Office files. And blocking by file
name is not effective if users intentionally try to circumvent. What other alternatives do we have?
FortiGate can use a content-based filter called document fingerprinting. Fingerprinting identifies
specific files via one or more CRC checksums, so its best used with files such as secure PDFs and
photographs files whose contents do not change, or that dont change much. But fingerprinting can
sometimes be configured for files that occasionally do change entirely, such as expense
spreadsheets. Well show that next. The file itself is not stored in memory; only the checksums. So
you can fingerprint many or on very large files.
How accurate is the fingerprint? How many checksums DLP will calculate and store?
Smaller chunks mean that more checksums will be calculated per file. So DLP will fingerprint more
accurately: it will still be able to identify a file, even if someone changes it in a few places, because the
checksums of the other chunks will still match. The tradeoff is that more checksums require more
FortiGate memory for storage. So you must decide the best balance between performance and
accuracy.

FORTINET
Now lets configure fingerprinting.
Before you actually make any fingerprints, consider whether youd like to make custom sensitivity
level tags. For example, you could make a custom sensitivity level named Finance, then next, while
configuring fingerprints, tag all money-related fingerprints.
The sensitivity level has two effects:

It will appear in log files.
When you configure each filter in a DLP sensor, you will select which fingerprints the file filter will
use by specifying a sensitivity level. All fingerprints having that sensitivity level will be included in
that filter.
For example, if you configure a filter in your DLP sensor to be a File type, the File Finger Print
option appears. When you select it, its drop-down menu then becomes available. In the drop-down,
you choose whether the filter will use Critical, Private, Warning, or your own custom group of
fingerprints, according to their sensitivity level tag.

FORTINET
Once youve defined any custom sensitivity levels, youre ready to define your fingerprints.
Go to Security Profiles > Advanced > DLP Fingerprint.
Fingerprinting can be done in two ways:
In the GUI, click on Create new under Manual Document Fingerprints to upload files to FortiGate so
that it can create and store checksums.
You can configure FortiGate to connect to a file share by clicking Create new under Document
Sources . If you prefer, it can do this periodically. Each time, FortiGate can automatically recreate
checksums for all files in the share, or retain old fingerprints (in case an old version of the file is still
circulating).
Fingerprinting via file share is useful if you must add many files, or if your files change periodically or
extensively. That way, you dont need to manually update the fingerprint each time the file changes
significantly.
While configuring either method, choose which sensitivity level FortiGate will use to tag those
fingerprints.
After fingerprints are defined, go to a DLP sensors filter where the type is File and File Finger Print
is chosen, and select a file sensitivity level.

FORTINET
In this working example, there are two manual fingerprints setup on the FortiGate. DLP will scan and
inspect these rules (filters) for fingerprint matching from top to bottom.
The first manual fingerprint doesnt match with the original files, DLP will then move on to scan and
inspect the next filter. As DLP stores the file checksum in chunks, it detected that second manual
fingerprint file has changed from the original file and take action as defined in the DLP sensor.

FORTINET
So now weve configured a few filters in the DLP sensor. Continue with more filters until the sensor
matches all traffic that it should, but doesnt match unintentionally. Finally, apply the DLP sensor by
selecting it in a firewall policy.
Here is an example DLP sensor with a few filters. Each filter searches traffic for different types of
sensitive information, such as a credit card number or fingerprint. If traffic matches a filter, FortiGate
will apply that filters action.
Remember, DLP filters are evaluated for a match sequentially, from top to bottom, and FortiGate uses
the first matching filter. So, for example, lets say an email contains a credit card number (which filter 1
says to block), but also has sensitive text (which filter 5 says to log but allow). FortiGate will only use
the first filter: the email will be blocked, not allowed.

FORTINET
Up until now, weve shown DLP blocking or monitoring sensitive data. What else can DLP do?
It can record traffic summaries that is, logs and, if enabled, the full files and messages that were
contained in the traffic.
If you were familiar with content archiving on older versions of FortiOS, you will recognize summary
archives and full archives here.
Summary archiving records a log message that summarizes the traffic, and therefore will vary by
protocol. For example, with an email message, the summary archive would contain the senders email
address, the recipients email address, and the size. When users access the Web, FortiGate logs
would record every URL they visited.

FORTINET
Full archiving records the summary log, but also a complete copy of the traffics contents.
This can be useful in forensic investigations. Its not meant for prolonged use, however. Depending on
what youre archiving, full archiving can require large amounts of FortiGates disk, CPU, and RAM
resources, decreasing performance.
For example, if you fully DLP archive a 100 MB file, FortiGate will actually store more than just 100
MB. It stores the data plus Ethernet, IP, and other headers that were used during network
transmission, plus the log message. So it will require slightly more than 100 MB. But also, this
requires RAM and CPU until the FortiGate finishes writing the file to its hard disk. Full DLP archiving
also consumes limited disk space that FortiGate may need for other UTM features.
So for performance reasons, its better to use a FortiAnalyzer or external storage device.
If you need to inspect and archive email especially for prolonged times then FortiMail may be a
better alternative. It has local archiving, plus many antispam, secure messaging, and other in-depth
features that FortiGates SMTP proxy cannot support.

FORTINET
To review, heres the topics we covered in this lesson. We discussed:

When to use DLP
Differences between detecting sensitive data via protocol filters and files
How DLP fingerprinting works, and how to choose the best method for the number of files and how
frequently they change
Logs and traffic contents that DLP can record

DO NOT REPRINT Diagnostics
FORTINET
In this lesson, we will teach you how to locate the source of problems in your network. Well also show
you fundamental troubleshooting commands on FortiGate that you can use to pinpoint and resolve
issues everything from high CPU usage to network unreachable errors.

FORTINET
After completing this lesson, you should have these practical skills that you can use. Youll know to
how to determine your network baseline, read diagnostic output, troubleshoot the physical and
network layers, trace packet flow through FortiGate processing, and find the root causes of abnormally
high CPU or memory usage.

FORTINET
In order to define any problem, first you must know what is your networks normal behavior.
In the graph here, the range that indicates normal is in blue. What is the blue line? Its in blue, and
indicates the average our baseline. What is the thick black line? Its the behavior right now. When it
leaves the normal range, FortiGate generates an alert, indicated by the red X.
Normal is measured and defined in many ways. Its performance: the expected CPU and memory
utilization, bandwidth and traffic volumes. But it is also your network topology: which devices are
normally connected at each node, and which direction traffic should flow. Its behavior: which protocols
are blocked or proxied, and the distribution of protocols and applications used during specific times of
the day, week, or year.

FORTINET
Lets look at each of these measurements how you can determine if the network has a problem.
If you are starting a new network, many things may not work yet. Many problems are obvious, and
normal behavior is, too.
But in large or established networks, the difference between normal and broken may be subtle.
How can you find what to fix or improve?

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

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 logical Layer 3) between virtual LANs,
IP subnets, and routers. Sometimes it also shows application protocols such as HTTP or DHCP.
Lets say that a guest is unable to use the Wi-Fi network. The client attempts to connect with a static
IP of 10.0.0.5, a /24 netmask, and a gateway of 10.0.0.1. Is this normal? Its difficult to guess. But if
you have a network scheme where Wi-Fi uses DHCP to assign clients an address in the
192.168.1.0/24 subnet, and all of the subnets IP leases are currently taken, then the problems
become obvious.

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 email processing is suddenly slow, and your FortiGates CPU usage is 75%, what
does that indicate? If weekday CPU utilization 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: on a workday or holiday, for
each network application, how many bits per second should ingress or egress from each interface in
your network diagrams?
Does the marketing department usually send an email campaign each Tuesday? This Tuesday, lets
say it contains a video. So many inbound requests for video from the media servers are probably not
an attack its probably normal. However, normal doesnt mean its irrelevant.
Should you expand your networks capacity? Lease another line from your ISP?
Should you add another HA FortiGate to your active-active cluster?
Should you configure link aggregation, or QoS?

FORTINET
Every 5 minutes, FortiGate generates a performance statistics log. But in large deployments with
hundreds of FortiGates, its not practical to search event logs to calculate every normal range. SNMP
or SIEMs are more scalable.
If youre getting network usage data via SNMP or syslog, remember that theyre transported via UDP.
So dropped packets mean missed data. But its very light weight. And the newer SNMP version 3 is
also more secure.
To use SNMP, download the MIB files to an SNMP manager such as Cacti. MIBs define which queries
and messages (called traps) that FortiGate supports. Configure FortiGate to accept queries from the
managers IP address. If you select authentication and/or encryption, be sure to match the security
settings, too.
Collect data for at least a week to find your normal normal usage can be different during the
weekdays vs. the weekends vs. holidays. This may vary by region and business type. What is
normal for one interface, or one FortiGate, may not be normal for another. Many places celebrate
New Years, but its often not big for online shopping; meanwhile, many branch offices will be closed,
for example.

FORTINET
Once you have specifications and some data for example, a months worth of system event logs,
traffic logs, and SNMP queries then you know how your network should behave.
How do you determine if theres a problem? Compare that normal behavior with now.

FORTINET
Once your SNMP manager is receiving data about normal usage, what is next?
Obviously you dont want to stare at a screen, every hour of every day, watching your FortiGate for
abnormal behavior. You want each FortiGate to notify you when abnormal events occur for
FortiGate to be proactive.
FortiGate can do this in multiple ways:

Alert email or text messages, via servers defined in System > Config > Advanced
FortiAnalyzer or Syslog, via servers defined in Log & Report > Log Config
SNMP traps, via servers defined in System > Config > SNMP or config sys snmp sysinfo
How are abnormal events defined? It varies by notification method. For SNMP, they are defined on an
individual basis for each SNMP manager. For alert email, they are defined globally, Logs are in the
Log & Report > Log Config menus. For FortiAnalyzer or syslog servers, you define alert-worthy events
for your whole network externally, on the FortiAnalyzer or syslog server, not on each FortiGate.

FORTINET
How else can we get current statuses? Lets show CLI commands first: you can use them via local
console, even if network issues make GUI access slow or impossible.
A few commands provide system statuses. get system status provides most general purpose
information. Output shows:
Model
Serial number
Boot loader version (called the BIOS in the output)
Firmware version (including, for virtual machines, the amount of virtual CPUs and RAM allowed
and allocated remember, normal RAM and CPU usage may vary by firmware enhancements and
new features)
Host name
HA status
FortiGuard license status, system time, and versions of the FortiGuard Antivirus, IPS, and IP
Reputation databases
VDOM status, number, and operation mode
and others.
get system performance status provides resource usage. Together, these provide most of
the same information that you can get from the GUIs dashboard.

FORTINET
What about network usage? diagnose firewall statistic show categorizes packets and
bandwidth by application type. If you dont know if BitTorrents are impacting your VoIP phones, for
example, this is a good places to start.
diagnose hardware deviceinfo nic varies by that interfaces NIC. Here, we see output from
FortiGate VM. It shows that interfaces:
Link speed and statistics for transmitted (Tx) and received (Rx) bandwidth
Physical MAC address
Errors and collisions
This command shows how much of your total bandwidth capacity is currently used on that interface.
So its useful for planning network expansion.
But it can also be used to diagnose problems. If some cables might be bad or interference may be
corrupting frames, or if a hub needs to be replaced with a switch, this command can help to determine
the problem. It can also help you to troubleshoot performance problems where you dont know what
version of NP4 or other ASIC the interface has, or Layer 2 loops or forwarding failures if FortiGate is
operating in transparent mode.

FORTINET
In the GUI, bandwidth, CPU load, available RAM, and bandwidth usage is displayed on the dashboard
System > Dashboard > Status. You can also view logs if youve configured FortiGate to store them
locally in Log & Report > Event Log and Traffic Log.

FORTINET
If you find that something is not normal, what should you do?
It depends on the type of the problem.

FORTINET
At the physical layer, troubleshooting analyzes which ports are plugged in, media capacity, and
electromagnetic interference resulting in transmission errors.
At the data link layer, diagnostics often analyze how many frames are being dropped due to CRC
errors or collisions. If your FortiGate is operating in transparent mode, and you need to troubleshoot
Layer 2 loops, you might also need to show bridges using diagnose netlink brctl list.
If an interface is wired to a Fortinet ASIC chip that accelerates processing such as IP session handling
and encryption or decryption, output can look slightly different. This shows output for an NP6 2nd
revision interface from a FortiGate 3700D that is running FortiOS 5.0.9. Like the output from a CPU-
processed interface, it shows the physical MAC address, administrative status, link status, and
bandwidth usage. But it shows more.
Do you see the platform and chip version? Do you see also that bandwidth statistics separates your
network traffic from traffic with the FortiGate itself that is, FortiGuard updates and administrative
sessions? You can accurately measure your networks firewall throughput. Network throughput data
shouldnt include your FortiGuard, FortiManager, FortiAnalyzer, SNMP, GUI or SSH sessions.

FORTINET
Lets say that FortiGate can contact some hosts through port1, but not others. Is the problem in the
physical or link layer? No. Connectivity has been proven with at least part of the network. Instead, you
should check the network layer. To test this, like usual, we start with ping and traceroute.
The same commands exist for IPv6 too: exec ping becomes exec ping6, for example.
Remember: location matters. Tests will be accurate only if you use the exact same path as traffic that
you are troubleshooting. To test from FortiGate (to a FortiAnalyzer or FortiGuard, for example), use
FortiGates own execute ping and execute traceroute CLI commands. But to test the path through
FortiGate, use ping and tracert or traceroute on the endpoint from the Windows, Linux, or Mac
OS X computer, not from the FortiGates CLI.
Due to NAT and routing, you may need to specify a different ping source IP address the default is
the IP of the physical interface, but you might want to use a VIP or FortiGuard push address, for
example. If there is no response, verify that the target is configured to respond to ICMP echo requests.
Also notice the first option, data-size, and the tos option. If you need to test quality of service
(QoS), or whether IPS is successfully configured to block oversize ping of death attacks, exec ping
can do that, too.

FORTINET
Does a route exists between the source and destination, but there are intermittent interruptions, or
some applications fail? Then the problem may be with the session table, with port address translation
(that is, PAT), or with higher-layer protocols.
FortiGates entire session table could be many millions of entries. Also, usually you want to clear only
sessions for affected traffic, not interrupt others. To do this, use filters. These are the steps, in order.
What happens if you clear the session table, but there is no filter? All sessions would be interrupted.
For protocols with transmission control like TCP, the client and server may be able to recover
gracefully. But for stateless protocols such as UDP and this includes logs such as UDP syslog about
attacks the data could be lost. It is up to the individual application to detect and recover from the
interruption.

FORTINET
In the IP session table, output for each entry will vary slightly by the transport protocol ICMP, TCP,
UDP, and so on in the encapsulation layer above IP. But in general, it contains:
Protocol number (6 is TCP)
Connection state (since most sessions are TCP connections)
Remaining time-to-live (TTL) until session expiry
Destination port number (TCP socket)
Traffic shaping (QoS), if any
Packet counter
How NAT or PAT is done (including the NATed IP address)
Counts if the session was offloaded to an NP ASIC processor for hardware acceleration
Session handling flags (state=)
All of these are important. Lets look at each in detail.

FORTINET
In the proto= field of the session table, there is a number. Each number corresponds to a service
that is, the protocol that is used in the next layer of packet encapsulation. Proxies and protocol
decoders in packet capture often examine both this and the destination port number.
So if a route exists, but the session table shows that the client is trying to use a service that is not
allowed by the firewall policy, for example, FortiGate will not allow connectivity. (Even if it is allowed, if
a FortiGate explicit proxy is configured, but the client is attempting to establish a session on the wrong
port number, connectivity via that protocol will fail. It wont match the socket.)
The most commonly used protocols are ICMP, TCP, UDP and SCTP. Their protocol numbers are
shown here.

FORTINET
The session table also records the state of TCP connections. There are 2 numbers:
the state of the connection between the FortiGate and the client, and
the state of the connection from the FortiGate to the sever
This is because FortiGate in NAT/route mode terminates the TCP connection, and makes a second
connection to the back-end server.
Unless FortiGate proxies the session, the first number normally should be 0.
Well talk more about session expiry later.

FORTINET
Although UDP is a message-oriented, stateless protocol it doesnt inherently require confirmed bi-
directional connections like TCP, so there is no connection state FortiGates session table does use
the proto_state= field to track UDP conversations.
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.

FORTINET
SCTP sessions also have distinct states, so those are also separate.

FORTINET
Aside from information about the IP session itself, the session table includes how FortiGate is
handling the session: bridging, IPS, and so forth. In the FortiOS kernel, each session has state flags
for handling. The session tables state= field shows these flags.
Here, the example shows 3 flags: this session is being logged (state=log), traffic shaped (shape), and
subject to a firewall policy (may_dirty).
Session state flags dont comprehensively track all possible firewall states. But many that it does track
are important. Understanding the NPU flag (npu) is critical. If its disabled, then the session is:
Processed by CPU
Not hardware accelerated by specialized FortiASIC chips (so usually performance will decrease)
Visible to the kernel (session statistics, packet capture, etc.)
But if a session is offloaded, the NP or other chip maintains the session state during almost the whole
session. The kernel is only aware of the state at the beginning and end. This is discussed in detail in
the hardware acceleration lesson.

FORTINET
Now weve shown whats in the session table. Weve also shown you how to manually remove specific
session table entries during troubleshooting, by setting a filter before running the command to clear
them.
But when will FortiGate automatically remove an entry?
FortiGate will automatically remove IP sessions from the table when one of three things happens,
either:
Session timeout
TCP connection tear-down
TCP connection timeout
Notice that IP sessions are sometimes removed due to events at the higher, TCP layer not just due
to the IP layer session timeout.

FORTINET
If the session table appears normal, but a specific protocol fails, you can examine higher layers of the
network stack via packet capture. Packet capture can show any packet ingressing or egressing.
Basic packet capture is shown in the firewall policy lesson. Lets show 2 more notable options.
By default, the packet capture will run until you press Ctrl + C to stop it, and will use timestamps in
seconds and milliseconds relative to the start of the packet capture. This is what happens if you leave
the count and timestamp arguments blank, and press the Enter key.
To capture only a specific number of packets that match your filter, type a number for the count.
To use a timestamp in absolute UTC time (a) or local time (l), type either a or l. These are useful for
correlating packet traces with logs, but shouldnt be used if you want to open the paceket trace in
Wireshark, because they will interfere with the packets own time stamp.
Lets see those options in some examples.

FORTINET
The 1st trace shows does not use the settings for packet count or timestamp; the 2nd does.
In the example at the top, the command ran until we manually interrupted it by pressing Ctrl + C, or
disconnecting our management session. When interrupted, it had captured 4 packets. But on busy
networks, by the time you press Ctrl + C, this might be 4,000 packets
To compare, the example at the bottom stopped automatically after exactly 3 packets because thats
what we indicated via the counter argument.
With regard to time stamps, the first command did not specify. By default, time stamps are relative to
when the trace started. In the output, an ICMP ping began about 2.1 seconds after the trace.
To compare, in the example on the bottom, the command has the option for a local timestamp: the
letter L. This trace was taken on November 14th, 2014 at 10:28 AM (according to the FortiGates
clock). To discover corresponding traffic or system events, we would check the logs and SNMP
messages with a matching 10:28 AM time stamp.

FORTINET
Does packet capture show that normal packets arrive, only for FortiGate to drop them internally? To
find which feature is dropping packets, you can follow packets through FortiGates internal decision
tree the packet flow.
In the firewall policy lesson, we show diagnose debug flow. But its useful for more than simply
firewall policies. Packet flow also shows routing and UTM scan decisions.
To review, here are the steps to record packet flow:

1. Enable packet flow output.
2. Define a filter.
3. Enable recording of the debug log.
4. On your computer, either make sure that the buffer is large enough, or configure your terminal
emulator to save output to a text file. (Like packet capture, flow traces generate text quickly
usually scrolling too quickly to read.)
5. Start the trace.
6. Stop when youve finished.

FORTINET
Not all problems are network connectivity failures. Sometimes, its just slowness.
What causes latency? Once on the physical media, bits travel relatively quickly the speed of light or
electricity. Latency is usually due to slow processing at each hop. If your monitoring shows that
bandwidth usage is normal and links are not saturated, then you should also check:
CPU usage
RAM usage
sometimes disk usage
If usage is high, tools can find which feature is consuming the most. However, you can troubleshoot
more quickly if you know precisely which change corresponds with when the problem began. So its a
good idea to gradually enable features. Dont enable everything at once.
If the CPU or RAM usage is too high, and youve just enabled all or many features, it will be more
complex to determine how to lower the usage.
Always begin with both diagnose sys top 1 and get system performance status when investigating
very high CPU levels. When the CPU usage is high, diagnose sys top, which by default refreshes
every 5 seconds, may not be accurate enough. Adding the number 1 at the end causes the display to
refresh more often.

FORTINET
Lets begin by showing get system performance status.
At the top, output shows that FortiGate that has a multicore CPU: usage is shown for each core,
CPU0 to CPU3. This is followed by the RAM usage.
At the bottom, output shows your network traffic. If the bit rate (throughput) or number of sessions is
higher than normal for your network, sometimes this can also explain slowness, even if the RAM or
CPU usage is not very high.

FORTINET
Next, lets examine output for diagnose sys top.
At the top, total CPU and RAM usage are shown. User space is made of inspection like antivirus
scans, whereas system space is used for operating system activities such as routing traffic and
reading or writing files. This is essential to understanding all of the other system usage statistics, and
your baseline.
Next, FortiGate lists processes that use the most CPU and RAM. 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, press Shift-P. To sort by highest RAM usage, press Shift-M.

FORTINET
Previously, we showed that diagnose sys top has a column for process state. This explains the
relationship between the states.
Most of the time, the process state will be either R or S. This means the process is doing
something (running), or waiting to be told to do something (sleeping).
Occasionally you may also see processes in the D state while writing to a disk. Obviously, if the
process is frequently in the D state, or never leaves it, this could mean there is a problem reading or
writing to that device.
You should never see a process in a Z state. Its a zombie process and it means the OS has
encountered an error it cant continue from. Only a reboot can terminate it.

FORTINET
Is one of the inspection features, such as IPS, using most of the CPU?
You can globally, temporarily bypass that specific feature with the command diagnose test app. Set
the flag to 5. Then verify the CPU usage again. Has it decreased to acceptable levels? While the CPU
has some temporary relief, you can connect to the GUI to quickly disable or adjust those parts of your
configuration.
For complex configurations, this is usually faster than trying while the CPU usage is high.
For example, if top indicated that the IPS engine had the biggest CPU workload, you could
temporarily toggle off all IPS inspection. This would immediately lower the CPU usage. Then, you
would check logs to find unnecessary workload, then adjust those settings before re-enabling IPS.

FORTINET
diagnose sys top can also be used to look at memory usage, not just CPU.
Remember that FortiOS itself uses some RAM, too not only the scan processes. The first
commands show RAM used by spawned processes such as IPSEngine. To show memory used by
the operating system itself, use these other commands below.

FORTINET
diagnose sys top-summary is slightly different from the diagnose sys top command. This
command is better for examining memory usage. Why?
This command collects all memory being used a process and its child processes, including any
memory that is shared between the processes, such as antivirus signatures loaded into RAM.

FORTINET
Lets compare output from diagnose sys top and diagnose sys top-summary. Output is very
different. In the diagnose sys top output, processes are listed multiple times, but in the diagnose sys
top-summary output, each is listed only once. The name is marked by an X if the processes has been
forked multiple times.
Because RAM for all forks is added together into a total, this output is better when you need to
determine which feature to adjust in order to make the most impact when correcting performance.
What is forking?

FORTINET
Forking is when the operating system makes multiple copies of a process in order to either subdivide
processing load, or handle multiple similar tasks.
If diagnose sys top shows scanunitd running 3 times, diagnose sys top-summary would show 1
entry with an x3, meaning it was forked 3 times. But diagnose sys top-summary shows that
scanunitd is using 12 MB of RAM, while diagnose sys top indicates that scanunitd should be using
just under 2 MB.
Why do they indicate different RAM usage?
The 10 MB anti-virus database isnt duplicated in RAM for each child process; it is loaded into shared
memory, which isnt counted by diagnose sys top.
FortiOS doesnt allow different processes to communicate directly. So if memory wasnt 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 3 concurrent scans would require 33 MB.
Performance would decrease. Either that or the entire database would need to be passed through the
operating system stack.

FORTINET
To see FortiGates overall memory usage, including shared memory, use this command.
At the top is RAM usage. Below this, usage is analyzed. Different models will obviously have different
values, since RAM varies by model.

FORTINET
What if you want to see memory allocation for the kernel, not shared memory?
Use diagnose hardware system slab.
Note that this is a very low-level look at the device. For example, there is an entry for inodes, which
are essentially pointers for file handles. A large number of inodes indicates that there are an
abnormally large number of files open by the operating system. So while this may not directly help you
to troubleshoot, it can be useful in rare cases where Fortinet Technical Support needs to provide this
information to programmers.

FORTINET
If your FortiGate is unstable, your problem may not be with the configuration it could be corrupted
firmware or damaged hardware. How can you diagnose this?
Rather than simply installing a new firmware image, you can use the console to temporarily load a
new firmware image for testing, before you upgrade. New firmware can contain new features that
change the original behavior. If your network depends on a previous default setting, for example, this
can require that you adjust the configuration. But until you discover this, will traffic flow be broken?
If you upgrade (for example, from FortiOS 4.3 to 5.0) you can use this feature in order to load the new
image and try it out before actually saving it to your FortiGates disk. This way, if you discover upgrade
issues, you can simply reboot, and FortiGate will revert to the previous firmware and configuration
while you plan your migration strategy.
You can also use this feature to load special HQIP software that can diagnose hardware problems.

FORTINET
Damage to RAM during shipping, for example, like with any other electronic device, can cause
intermittent crashes.
If you suspect hardware failure, download special HQIP hardware testing images from the Fortinet
Technical Support web site. Theres a basic test image, an advanced test (which we recommend for
RMA), a hard disk testing image, and flash disk testing image.
Run its tests to see if hardware has failed.
How do you load the diagnostic image?

FORTINET
To load an image, power cycle or reboot your FortiGate. Then, from a local console, enter the boot
loader menu. Download the image from a TFTP server.
If you choose Default, the boot loader will save the firmware image to disk, and load it every time it
boots up.
If you select Run, FortiGate will only temporarily load the image into RAM. It wont install it to disk.
After a reboot or power cycle, RAM will reset, and the temporary image will be forgotten.
For a diagnostic image, dont save it to disk instead, choose the Run option, then wait. Save the
output to a file. If the hardware requires an RMA, Fortinet Technical Support will ask you for the HQIP
output in order to authorize the RMA.
You can also use this method for testing new firmware images and patches. This way, if you discover
issues, you can simply power cycle to return to the previous firmware. If you decide to install the new
firmware, but want a clean install instead of an upgrade, use the boot loader menu to format the flash
disk first. This will reform the partition tables if they have been damaged, before you install a new
FortiOS image.

FORTINET
How to determine your networks baselines

How to monitor your network for abnormal behavior your network
Commonly used CLI commands for diagnosing network and system problems, such as:
diag sys session list
diag sniffer packet
diag sys top-summary
How to test firmware upgrades and hardware

DO NOT REPRINT Hardware Acceleration
FORTINET
In this lesson, we will show how FortiGate ASIC chips and mezzanine cards accelerate network
performance. This includes discussing how processing that is accelerated by specialized hardware is
different from processing by traditional, general-purpose CPUs.

FORTINET
After completing this lesson, you should have these practical skills.
This lesson is mostly about tuning your configuration for performance. You should be able to use
FortiGate features provided by the Network Processor (NP), Content Processor (CP), Security
Processor (SP), and System on a Chip (SoC), such as offloaded IP sessions, accelerated IPsec and
SSL encryption, and accelerated IPS and antivirus scans.

FORTINET
To begin, how can your configuration impact performance? Not all configurations are supported by
hardware acceleration.
So what does hardware acceleration mean? With hardware acceleration, a FortiGates CPU
transfers some of its processing load to a specialized processor:
Network Processors (NP)
Security Processors (SP)
Content Processes (CP)
Offloading frees up CPU cycles, and offloaded tasks execute faster on specialized hardware than they
do on a general-purpose CPU. Its a similar idea to how your computer uses the GPU on its graphics
card: GPU often have dedicated RAM of their own, and GPU circuits are designed to be more efficient
at processing images.

FORTINET
Like your computer uses its GPU to calculate graphics, your FortiGate uses its specialized chips to
process networking and security. These specialized chips are called ASICs (Application-Specific
Integrated Circuits).
FortiGate ASICs are identified by their type (NP, SP, CP) and version (1, 2, 3...). Generally, newer
versions have more features and better performance.
ASICs are wired into the circuit board, and therefore are not upgradable.

FORTINET
What types of processing does each ASIC do?
Network Processors (NP) can handle packet forwarding, IPsec cryptography and hashing, link
aggregation, HA, and a few other types of packet processing.
Security Processors (SP) have their own CPU and memory, and can run security profile processes
such as IPS and other flow-based inspection.

FORTINET
Content Processors (CP) do some types of content inspection, such as pattern matching, but they
also handle SSL cryptography. NP can also handle cryptography, so what is the difference? CP acts
like a co-processor in terms of its physical wiring: unlike most NP, CP are not bound to a specific
network interface.
System-on-a-Chip (SoC) processors combine a traditional system CPU with both a CP and NP.

FORTINET
Now that weve briefly compared the types of ASIC chips, lets look at the evolution of each chip, and
how to configure your FortiGate to use each ASIC for performance boosts. Well also show how
offloading changes expected output for diagnostics.
Well begin with NP.

FORTINET
This diagram shows how FortiGate decides whether or not to accelerate packet forwarding and IP
session handling.
For each new session, the first packet always goes to the kernel, on the CPU.
If the NP supports all features youve configured FortiGate to apply to that session, then the kernel
sends an instruction to the NP. This programs it to handle that session.
Otherwise, if the NP doesnt support everything thats required, the kernel must continue to process all
of that sessions packets.
All subsequent packets for the fast path session is forwarded by the NP, not the CPU. The NP
accelerates transmission.
Finally, upon the last packet a TCP FIN (finish) or RST (reset) signal, for example, or if there are
errors then the NP returns the session to the CPU so it can tear down the session.

FORTINET
Several hardware revisions of Network Processors exist.
The first and seconds revisions can offload most types of IPv4 traffic. The next generation, NP4, has
a significant performance increase over earlier versions. NP6 doubles that, and adds support for
IPv6, CAPWAP traffic (for wireless control and provisioning) and multicast.

FORTINET
To find information about each of your FortiGates network processors, use the CLI command get
hardware npu.

FORTINET
The first three versions of the NP do not support traffic statistics (including logs) except for the first
and last packets in the IP session.
Why?
Because those two packets when the session is being formed, and torn down are handled by the
kernel, on the CPU, before the session information is passed to an ASIC. In between, the ASIC chip
processes packets mostly autonomously, so the kernel is not aware of statistics occurring during that
time. (Remember that we will notice its effects again during diagnostics.) And NP1 through NP4 did
not have the memory to be able to keep their own statistics.
NP6 is capable. It also supports the SNMP Ethernet MIB, so it can answer queries about these
statistics, too.

FORTINET
To be eligible for offload, the traffic match the ASIC chips design criteria. For NP4, the criteria are:
Layer 2 type/length must be set to 0X0800. IEEE 802.1q and 802.3ad traffic can also be offloaded
Layer 3 must be unicast IPv4. (Multicast and IPv6 are not supported by NP4.)
Layer 4 must be UDP, TCP, SCTP or ICMP
Header or content must not require modification by a session helper
Traffic must not inspected by any kind of security profile, such as antivirus or web filtering
Traffic must not have originated from the firewall itself either
Ingress and egress ports must be on the same NP4, unless there is an EEI bridge between two
communicating NP4s
So you can see by comparing with this list that the NP6 criteria are like NP4, except that NP6 adds
support for IPv6, NAT64, NAT46 and others.

FORTINET
FortiGate models with NP6 are physically wired together with an Integrated Switch Fabric (ISF). This
allows communication between all interfaces and the NP6 processors without passing through the
CPU. So offloading is possible, even if ingress and egress are not on the same processor.

FORTINET
To verify that a session is offloaded, use the CLI command diagnose sys session list.
Offloaded sessions have the npu info line.

FORTINET
A minute ago, we mentioned that the kernel is not aware of what is happening with a session while it
is being handled by an NP. So it impacts logging. What else does it impact?
Packet capture involves the FortiGates kernel, which uses the CPU. NP chips do not send all of their
data back to the CPU, since this would counteract acceleration. As a result, once a session is
offloaded to an NP, the sniffer will not see those packets.
During troubleshooting, you often need to see the entire session. So you may need to temporarily
disable offloading. You can do this on a per-policy basis, in the CLI.

FORTINET
NP does more than just IP layer packet forwarding:

Active-Active HA load balancing
IPsec cryptography
Link aggregation
Basic anomaly detection that occurs before the software IPS engine
Basic traffic shaping

FORTINET
In HA active-active, the offload criteria is the same as for a standalone FortiGate.
Hardware acceleration of user traffic is decided by each individual FortiGate in the cluster. Generally,
traffic is load balanced for content inspection purposes, so hardware acceleration does not apply. It is,
however, the redirection of packets in the same session that is offloaded, whereby the network
processor re-writes the MAC addresses thus offloading the CPU from these interrupts.

FORTINET
If an IPsec tunnel uses encryption and hashing algorithms supported by the network processor, then
the IPsec user data processing can be offloaded.

FORTINET
To verify IPsec traffic is offloaded, use the CLI command diagnose vpn tunnel list. This shows the
status and statistics for each VPN tunnel. If it contains a line with npu_flag, the tunnel is being
offloaded.

FORTINET
Network processors can also accelerate traffic for 802.3ad link aggregation if all aggregated
interfaces are associated with the same NP. (Depending on which vendors youre familiar with, link
aggregation is also called NIC teaming, channeling, or link bonding.) To determine if the channel
is offloaded, use the CLI command diagnose netlink aggregate.
Will all link aggregation-related processing be offloaded? No, again, offloading doesnt occur until the
CPU establishes the session and sends it to the NP. So in the initial phase of hashing which is how
the kernel decides which interface in the aggregate will send the first frame the CPU is still involved.
Offloading occurs after link aggregate hashing.

FORTINET
Some network processors can also detect some anomalies and drop those packets. This occurs in
hardware, independently from and before the IPS engine is involved. To do this, configure the
interface with set fp-anomaly. For example, you could configure your NP processor to drop packets
with an unknown protocol number.

FORTINET
Some types of traffic shaping can be offloaded to a network processor. Limiting and prioritization are
supported however guaranteed bandwidth cannot be offloaded and is handled by the CPU. The
network processors have limited shaper objects (NP6 has more shaping objects and packet flow
improvements), therefore traffic shaping by the CPU is still common.

FORTINET
Now that weve talked about which configurations that NP can improve performance for, lets discuss
SP.

FORTINET
Like a network processor, a security processor can also offload packet transmission. It can offload
multicast, IPv4, IPv6, and NAT64 traffic. But it can also perform flow-based content inspection and
provides SYN proxy functionality.

FORTINET
Like network processors, security processor features increase with each revision. The first revision
can handle IPS and encrypted multicasting offload. The second revision added support for flow-based
inspection. The third revision has performance benefits.

FORTINET
To determine the type of security processor in your FortiGate model (if any), use the CLI command
diagnose npu spm list.
In the example here, xh0 indicates that an FMC-XH0 model mezzanine expansion card is installed.
This product family uses SP3.

FORTINET
Security processors mostly accelerate security related features, a network processor does not support
these sessions. Security processors handling flow-based inspection, such as flow AV, IPS and
application control, provide significant throughput benefits.

FORTINET
Flow-based IPS in a firewall policy can be offloaded; the ingress and egress interfaces must be bound
to the same security processor.

FORTINET
DoS policies, depending on the type, can also be offloaded to the security processor.
Like with antivirus, ASIC-based IPS doesnt support proxy-based scans, since this would require more
dedicated memory, or shared memory which would decrease performance.

FORTINET
An interface on a security processor can act as a TCP SYN proxy, dropping all connections not
completed by the client within the timeout period, therefore providing greater protection for your back-
end servers against SYN floods.

FORTINET
With a SYN proxy inline, the client must close the three way handshake before the connection is
passed to the kernel to establish the connection to the server, thus preserving CPU resources.

FORTINET
The SYN proxy is configured in the DoS profile tcp_syn_flood setting, and applied to an interface
with security processor.

FORTINET
Next, lets show you the features of CP chips, and which configurations can use them for higher
performance.

FORTINET
The content processor is a co-processor for the CPU. Since the very first FortiGate models, Fortinet
has included a CP in the design. Those first models are obviously obsolete by now, so we wont start
at the beginning. Where will we start?
CP4 has existed for some time, but is still relevant. Lets start there.
Processes content
Generate pseudorandom numbers for cryptography
Encrypt and decrypt DES, 3DES, and AES for IPsec Phase 2
Calculate SHA-1 and MD5 checksums for message authentication
Validate RSA public keys in PKCS#1 certificates

FORTINET
CP5 added FIPS and RFC compliance, and improved IPsec offloading with support for IKE and RSA.
Additionally, its random number generator is compliant with SSL, which would become especially
relevant to the next generation, CP6.

FORTINET
CP6 added hardware support for SSL, which was required for performance given the growing
popularity of SSL VPN and SSL inspection.

FORTINET
CP8 added support for an IPS engine for signature pattern-matching, extended cryptographic support
to include ARC4 and SHA-256, and large public keys. Additionally CP8 chips can be stacked for
scalability.

FORTINET
Which CP does your FortiGate have? To determine this, use the CLI command get hardware
status.

FORTINET
Finally, lets look at a type of ASIC that integrates two of the others: SoC.

FORTINET
System on a Chip (SoC) combines a general purpose CPU with Fortinets custom ASIC network,
security and content processors, into a single chip. Usually found in desktop or small office models
because it allows smaller form factors, but cannot handle a carrier grade computing load, the biggest
benefit of SoC is greater cost and energy efficiency.

FORTINET
With the CP8 and partial NP integrated onto a SoC processor, FortiGate can accelerate IP session
handling, IPS, IPsec, and SSL.

FORTINET
A SoC processor integrates three ASICs.

The VPN module includes the SSL, TLS, and IPsec engines, which handle the encryption and
decryption of traffic and message authentication algorithms.
The NPLite module is a light version (with fewer features) of an NP processor. It accelerates
session handling.
The IPS deterministic finite automata (DFA) module is used to offload some IPS signature-
matching.

FORTINET

Architecture of each of the FortiASIC chip families
Which features can be offloaded to each chip
Differences between the chips
How to find which chips your model has
How to determine if traffic is taking advantage of offloading

DO NOT REPRINT IPv6
FORTINET
In this lesson, we will show fundamentals of IPv6, and how to configure your FortiGate for it. This includes
examples of how to enable security features in an IPv6 environment.

DO NOT REPRINT IPv6
FORTINET
After completing this lesson, you should have these practical skills in IPv6 fundamentals and be familiar with
FortiOS IPv6 features and their configuration:
IPv6 routing and firewalling
transition technologies such as dual-stack, NAT64 and 6to4 tunneling
IPv6-compatible security profiles

DO NOT REPRINT IPv6
FORTINET
The newer version of the Internet Protocol adds an almost inexhaustible number of addresses thanks to a
128-bit long address field, compared to the 32-bits used by version 4. Since every connected device on the
Internet needs an IP address, there will be increasing pressure to move to IPv6 as more non-computer
devices come online in the so-called Internet of things.
IPv6 specifies a new packet format designed to minimize packet header processing by routers. Because the
headers of IPv4 packets and IPv6 packets are significantly different, the two protocols are not interoperable,
therefore transition technologies are required to exchange traffic between the different networks. Such
technologies include NAT64, tunneling, and dual-stack, which are covered in this call. That said, most
transport and application-layer protocols need little or no change to operate over IPv6.

DO NOT REPRINT IPv6
FORTINET
IPv6 packets only use the headers needed, and can concatenate as many headers as required. For
example, a packet that does not require routing will not have the routing header. There are as many
extension headers as there are protocols on IPv4, plus new headers. Example extension headers include:
Hop by Hop (data to be processed by all the routers in the path of the packet); ICMPv6, TCP, UDP;
Fragmentation; Routing; Destination Options (parameters/data that must be processed only by the
destination host only); Authentication (AH, IPSEC); and Encrypted (ESP, IPSEC).

DO NOT REPRINT IPv6
FORTINET
There are three types of addresses: unicast, anycast, and multicast. Unicast is an identifier for a single
interface. A packet sent to a unicast address is delivered to the interface identified by that address. Anycast
is an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast
address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the
routing protocols' measure of distance). Multicast is an identifier for a set of interfaces (typically belonging to
different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address.
There are no broadcast addresses in IPv6; their function being superseded by multicast addresses.

DO NOT REPRINT IPv6
FORTINET
IPv6 defines a 128-bit (16 bytes) address space. The 128-bit address is divided into eight 16-bit hexadecimal
blocks, separated by colons. Therefore, theoretically there can be total 2^128 possible IPv6 addresses. The
Prefix Length specifies how many left-most bits of the address belong to the network. It is comparable to the
subnet mask in IPv4. A unicast address is composed of a Subnet ID (the first 64 bits) and an Interface ID (the
other 64 bits).

DO NOT REPRINT IPv6
FORTINET
To make the 128-bit address simpler, some abbreviations are possible. Take the address,
2000:5374:7564:656e:7431:0000:0000:1000. Leading zeros in a 16-bit block can be skipped,
2000:5374:7564:656e:7431:0:0:1000. A double colon can replace consecutive zeros or leading or trailing
zeros within the address, 2000:5374:7564:656e:7431::1000. Note that the double colon can appear only
once in an address.
Any IPv6 host/node can have many IPv6 addresses on the same network interface card (NIC).

DO NOT REPRINT IPv6
FORTINET
IPv4 network masks (255.255.0.0, etc.) are not practical with 128 bits. On IPv6, we now use prefixes as with
IPv4, but with the huge address space of IPv6.
Typical prefixes for IPv6 are: /48 an organization; /48 for a home user (or /64 if they are absolutely sure the
address wont change); and /128 for a point-to-point.

DO NOT REPRINT IPv6
FORTINET
The Global Unicast Addresses is the most used prefix. This is the prefix from which your ISP provides your
IPv6 addresses.
Link-Local addresses are designed for addressing on a single link for purposes such as auto-address
configuration, neighbor discovery, or when no routers are present. Routers must not forward any packets
with link-local source or destination addresses to other links.
Site-Local addresses are designed for addressing inside of a site without the need for a global prefix. Routers
must not forward any packets with site-local source or destination addresses outside of the site.
RFC 2373 describes the IPv6 Addressing Architecture (http://www.ietf.org/rfc/rfc2373.txt).

DO NOT REPRINT IPv6
FORTINET
An IPv6 anycast address is an address assigned to more than one interface (typically belonging to different
nodes). A packet sent to an anycast address is routed to the "nearest" interface having that address,
according to the routing protocols' measure of distance.
Anycast addresses are allocated from the unicast address space, using any of the defined unicast address
formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When a
unicast address is assigned to more than one interface, thereby turning it into an anycast address, the nodes
to which the address is assigned must be explicitly configured to know that it is an anycast address.

DO NOT REPRINT IPv6
FORTINET
An IPv6 multicast address is an identifier for a group of nodes. A node may belong to any number of
multicast groups. Multicast addresses have the FF00 prefix plus 112 bits group id. After the first 8 bits of the
prefix (0xFF), the next 4 bits are the flags (the first 0x0 of the prefix) and indicate a permanent (0x0) or
transient (0x1) address. The next 4 bits (the second 0x0 of the prefix) is the scope of the multicast group.

DO NOT REPRINT IPv6
FORTINET
The "meaning" of a permanently-assigned multicast address is independent of the scope value. In the
example, the "NTP servers group" is assigned a permanent multicast address with a group ID of 101 (hex).
Non-permanently-assigned multicast addresses are meaningful only within a given scope. For example, a
group identified by the non-permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one site bears no
relationship to:
a group using the same address at a different site
a non-permanent group using the same group ID with different scope, or
a permanent group with the same group ID
Multicast addresses must not be used as source addresses in IPv6 packets or appear in any routing header.

DO NOT REPRINT IPv6
FORTINET
IPv6 uses the Internet Control Message Protocol (ICMP), as defined for IPv4, with a number of changes. The
resulting protocol is called ICMPv6 and has an IPv6 Next Header value of 58.
ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets and to perform other
internet-layer functions, such as diagnostics (ICMPv6 "ping"). ICMPv6 is an integral part of IPv6.
The table shows common IPv6 types and codes. The Related Messages column indicates the message type.
Its value determines the format of the remaining data. The code field depends on the message type.
ICMPv6 messages are grouped into two classes: error messages and informational messages. Error
messages are identified by a zero in the high-order bit of their message Type field values. Thus, error
messages have message types from 0 to 127; informational messages have message types from 128 to 255.
ICMPv6 is defined in RFC 4443.

DO NOT REPRINT IPv6
FORTINET
This specification defines the Neighbor Discovery Protocol (NDP) for IPv6. Nodes (hosts and routers) use
NDP to determine the link-layer addresses for neighbors known to reside on attached links and to quickly
purge cached values that become invalid. Hosts also use NDP to find neighboring routers willing to forward
packets on their behalf. Finally, nodes use the protocol to actively keep track of which neighbors are
reachable and which are not, as well as to detect changed link-layer addresses. When a routeor the path
to a router fails a host actively searches for functioning alternates.
NDP replaces the following IPv4 mechanisms: ARP, ICMPv4 Router Discovery, ICMPv4 Redirect.
NDP is defined in RFC 4861.

DO NOT REPRINT IPv6
FORTINET
The autoconfiguration process includes generating a link-local address, generating global addresses via
stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness
of the addresses on a link.
Address autoconfiguration typically generates the global address on the network prefix, the node MAC
address, and some additional bytes to complete the address space.
IPv6 autoconfiguration is defined in RFC 4862.
The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any)
configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its
own addresses using a combination of locally available information and information advertised by routers.
Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an
"interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the
two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses
are sufficient for allowing communication among nodes attached to the same link.

DO NOT REPRINT IPv6
FORTINET
This slide demonstrates the stages a node progresses through to create link local and global unicast
addresses.
During the stateless ICMP6 autoconfiguration, no DNS information is exchanged. When using
autoconfiguration, DHCP6 may be used to provide DNS and other values. If DHCP6 is configured as stateful,
it may provide other options, such as providing an address from a range, querying a node, or changing an
address. The gateway is provided by the router announcing the prefix.

DO NOT REPRINT IPv6
FORTINET
The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use,
so long as they are unique and properly routable. On the other hand, Dynamic Host Configuration Protocol
for IPv6 (DHCPv6), defined in RFC 3315, is used when a site requires tighter control over exact address
assignments.
Clients and servers exchange DHCP messages using UDP. The client uses a link-local address or
addresses determined through other mechanisms for transmitting and receiving DHCP messages.
DHCP servers receive messages from clients using a reserved, link-scoped multicast address. A DHCP
client transmits most messages to this reserved multicast address, so that the client need not be configured
with the address or addresses of DHCP servers.
To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, a DHCP
relay agent on the client's link will relay messages between the client and server.

DO NOT REPRINT IPv6
FORTINET
For HTTP, to use a literal IPv6 address for an adapter URI, enclose the IP address in square brackets "[", "]".
For example, the nomenclature for a URI with the IPv6 address 2001:DB8:2a:1005:230:48ff:fe73:989d would
be: [2001:DB8:2a:1005:230:48ff:fe73:989d].
Some changes to the application layer protocols are required to recognize the IPv6 address format.
For DNS, a Name record for an IPv6 address is known as a AAAA record.

DO NOT REPRINT IPv6
FORTINET
IPv6 transition mechanisms are technologies that facilitate the transitioning of the Internet from its initial (and
current) IPv4 infrastructure to the successor addressing and routing system of IPv6. As IPv4 and IPv6
networks are not directly interoperable, these technologies are designed to permit hosts on either network to
participate in networking with the other network.

DO NOT REPRINT IPv6
FORTINET
The difference in security is that IPsec may be installed separately for IPv4, whereas it is a mandatory and
integral part of the IPv6 stack and therefore available with any implementation. The IPsec specification
defines protocols for the Authentication Header (AH) and the Encapsulating Security Payload header (ESP).
With IPv6, these headers are included as Extension headers.
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4
and IPv6. ESP may be applied alone. The ESP header is either inserted after the IP header and before the
next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode).
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay
service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services
provided depends on options selected at the time of Security Association (SA) establishment and on the
location of the implementation in a network topology.
The header diagram, which applies to both IPv4 and IPv6, is taken from its RFC.

DO NOT REPRINT IPv6
FORTINET
There are two fields in the IPv6 header that can be used for Quality of Service (QoS): the Traffic Class and
the Flow Label field.
The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or forwarding
routers to identify and distinguish between different classes or priorities of IPv6 packets. The Traffic Class
field is specified in RFC 2474, and introduces the term DS field for the Traffic Class field. The goal of this
specification is that DiffServ routers have a known set of DS routines, which are determined by the value in
the DS field. The forwarding path behaviors thus includes the differential treatment an individual packet
receives, as implemented by queue service disciplines and/or queue management disciplines. These per-
hop behaviors are useful and required in network nodes to deliver differentiated treatment of packets.
The 20-bit Flow Label field in the IPv6 header may be used by a source to label sequences of packets for
which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time"
service. The Flow Label field is specified in RFC 6437, and may be used by a source to label packets for
which it requests special handling by the IPv6 routers, such as non-default QoS or real-time service. Packet
classifiers can use the triplet of Flow Label, Source Address, and Destination Address fields to identify the
flow to which a particular packet belongs.

DO NOT REPRINT IPv6
FORTINET
Numerous IPv4 routing protocols are available for finding routes between networks, and almost every one of
them has an IPv6 version or extension. As with IPv4, there are still interior gateway protocols (IGPs) and
exterior gateway protocols (EGPs), distance vector based and link-state-based routing protocol algorithms.

DO NOT REPRINT IPv6
FORTINET
FortiOS provides support for IPv6 firewalling, translation technologies for IPv4 and IPv6 interoperation, and
security profiles. Malware and network-based threats are largely independent of the IP version.
FortiOS is typically deployed with dual stack routing, where administrators assign both IPv4 and IPv6
addresses to interfaces.
You can configure the FortiOS IPv6 features from the CLI or by enabling IPv6 through the GUI (System >
Config > Features). Some IPv6 settings, however, remain CLI only.

DO NOT REPRINT IPv6
FORTINET
To get started, configure an interface for IPv6 and add a prefix. Specify an easy to remember address and
add a prefix for the same network. This causes FortiOS to send out router announcements supporting the
auto configuration of your IPv6 enabled host.

DO NOT REPRINT IPv6
FORTINET
Hosts on a link connected to a FortiGate may receive their address via SLAAC (stateless) or DHCPv6
(stateful).
The address range for technical documentation is 2001:db8::/32 and is used throughout this lesson.

DO NOT REPRINT IPv6
FORTINET
The example CLI configuration enables stateless autoconfiguration. It defines a network prefix that
connected hosts use to create a global address.
The interface IPv6 configuration is a sub-branch of the interface CLI. You can configure dual stack by
configuring the IPv4 address and configuring an IPv6 address in the sub-branch. The onlink flag indicates the
address is assigned to the interface on that specific link.

DO NOT REPRINT IPv6
FORTINET
In this example, a hosts global address is provided in the stateful autoconfiguration process. Rather that
receiving a prefix, the node sends a DHCPv6 request to the link-scope multicast address. The DHCPv6
response allocates an address from the configured range.

DO NOT REPRINT IPv6
FORTINET
You can configure a FortiGate interface to receive its global IPv6 address via DHCPv6.

DO NOT REPRINT IPv6
FORTINET
NAT64 is a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence. Together with DNS64, these two
mechanisms allow an IPv6-only client to initiate communications to an IPv4-only server. They also enable
peer-to-peer communication between an IPv4 and an IPv6 node, where the communication is initiated when
either end uses existing, NAT-traversal, peer-to-peer communication techniques, such as Interactive
Connectivity Establishment (ICE). Stateful NAT64 also supports IPv4-initiated communications to a subset of
the IPv6 hosts through statically configured bindings in the stateful NAT64, which could be achieved using
VIP46 in FortiOS.

DO NOT REPRINT IPv6
FORTINET
DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. The IPv6 address
contained in the synthetic AAAA RR is algorithmically generated from the IPv4 address and the IPv6 prefix
assigned to a NAT64 device.
DNS64 is defined in RFC 6052.

DO NOT REPRINT IPv6
FORTINET
This configuration shows a sample NAT64 policy that is configured from the CLI. The source interface is an
IPv6-enabled interface and the destination interface is an IPv4-enabled interface.

DO NOT REPRINT IPv6
FORTINET
NAT66 is a stateless IPv6-to-IPv6 Network Prefix Translation (NPTv6) function, designed to provide address
independence to the edge network. It is transport-agnostic with respect to transports that do not checksum
the IP header. NAT66 provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes,
preserving end-to-end reachability at the network layer. NAT66 is experimental and defined in RFC 6296.
Note the IETF does not recommend the use of Network Address Translation (NAT) technology for IPv6.

DO NOT REPRINT IPv6
FORTINET
You can apply security profiles to IPv6 firewall polices in the same way as IPv4 firewall polices.

DO NOT REPRINT IPv6
FORTINET
FortiOS implements several tunneling protocols that are part of the transition technologies, allowing IPv6
communication to tunnel across an IPv4 network. FortiOS implementation includes IPsec to secure IPv6 in
IPv4 tunnels. This mechanism is outlined in RFC 4891.

DO NOT REPRINT IPv6
FORTINET
From a security perspective, we will focus on IPv6 tunneling over an IPv4 IPsec tunnel. To do this, in FortiOS
create an IPsec interface mode tunnel, as with the regular site-to-site VPN configuration. Your Phase 2
selectors, routes, and firewall policies are all IPv6.

DO NOT REPRINT IPv6
FORTINET
The diagnose command branch allows you to get status information and manually manipulate the IPv6
configuration.
In the route list, note the link-local and multicast prefixes.
In the neighbor-cache list, look for the autoconfuguration address for both FortiOS and any host. Note how
the MAC address is used in the autoconfuration addresses. Remember in IPv6 there is no ARP, the neighbor
mechanism replace this. From a Windows host you can view the neighbor-cache using the command
netsh interface ipv6 show neighbors (or ip -6 neighbor show in Linux).
The packet sniffer supports IPv6. The following are example IPv6 filters:
ip6 and host 2000:5374:7564:656e:7431::3000 to capture IPv6 host
ip6 and net 2000::/8 to capture IPv6 prefix
ip6 and tcp port 80 to capture TCP port number

DO NOT REPRINT IPv6
FORTINET
In this lesson, we covered the following topics.
We explained the IPv6 fundamentals necessary to configure FortiOS in an IPv6 environment and enable
features such as transition technologies and security profiles. We also looked at the common diagnostic
commands, and new commands, for IPv6 networks.

FortiGate II Student Guide-Online

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

FortiGate II Student Guide-Online

Caricato da

Copyright:

Formati disponibili

DO NOT REPRINT

VIRTUAL LAB BASICS ...................................................................................7

Transferring Files to the VM....................................................................................................13

Using HTML5 Instead of Java ................................................................................................13

Screen Resolution ...................................................................................................................14

International Keyboards ..........................................................................................................14

Troubleshooting Tips ..............................................................................................................15

INITIALIZING THE LAB ...................................................................................17

Basic Network Settings ...........................................................................................................17

Lab 1: Router Configuration & Troubleshooting .....................................................................18

Exercise 1 Connectivity Troubleshooting ..............................................................................19

Exercise 2 Link Health Monitoring .........................................................................................22

Exercise 3 Failover & Load Balancing Using Static Routing .................................................25

Exercise 4 WAN Link Load Balancing ...................................................................................28

Lab 1: Virtual Domains............................................................................................................30

Exercise 1 Creating VDOMs & VDOM Objects .....................................................................31

TRANSPARENT MODE ...................................................................................36

Lab 1: Transparent Mode VDOMs ..........................................................................................36

Exercise 1 Transparent VDOMs ............................................................................................37

Exercise 2 Inter-VDOM Links.................................................................................................38

HIGH AVAILABILITY ......................................................................................41

Lab 1: High Availability............................................................................................................41

Exercise 1 Configuring HA & Observing Failover ..................................................................42

Exercise 2 Configuring a Non-Synchronizing HA Management Port ....................................45

ADVANCED IPSEC VPN ................................................................................47

Lab 1: Advanced IPsec VPN ..................................................................................................47

Exercise 1 Configuring an IPsec VPN ...................................................................................48

Exercise 2 Configuring a Redundant IPsec VPN ..................................................................51

Lab 2: IPsec VPN with FortiClient...........................................................................................53

Exercise 2 Configuring and Testing FortiClient .....................................................................56

INTRUSION PREVENTION SYSTEM ..................................................................58

Lab 1: Intrusion Prevention System ........................................................................................58

Exercise 1 Blocking Known Exploits ......................................................................................59

Exercise 2 Mitigating a DoS Attack........................................................................................62

Exercise 3 Creating Custom Signatures ................................................................................63

FORTINET SSO ............................................................................................64

Lab 1: Fortinet Single Sign On ................................................................................................64

Exercise 1 Installing FSSO on a Windows Server ................................................................65

Exercise 2 Configuring FSSO on FortiGate ...........................................................................69

Exercise 3 Testing FSSO On Authentication.........................................................................71

CERTIFICATE OPERATIONS ...........................................................................72

Lab 1: Certificate Operations ..................................................................................................72

Exercise 1 Creating a Certificate Request.............................................................................73

Exercise 2 SSL Deep Inspection ...........................................................................................81

DATA LEAK PREVENTION..............................................................................84

Lab 1: Data Leak Prevention ..................................................................................................84

Exercise 2 Quarantining a User that is Leaking Sensitive Data ............................................87

Exercise 3 DLP Fingerprinting ...............................................................................................88

Lab 1: IPv6 Transition Technologies ......................................................................................90

Exercise 1 IPv6 Setup............................................................................................................91

APPENDIX A: ADDITIONAL RESOURCES........................................................97

APPENDIX B: PRESENTATION SLIDES............................................................98

Module 11: Routing .................................................................................................................99

Module 12: Virtual Domains ....................................................................................................143

Module 13: Transparent Mode ................................................................................................174

Module 14: High Availability ....................................................................................................190

Module 15: Advanced IPsec VPN...........................................................................................229

Module 16: Intrusion Prevention System ................................................................................260

Module 17: FSSO....................................................................................................................302

Module 18: Certificate-Based Operations ...............................................................................327

Module 19: Data Leak Prevention ..........................................................................................372

Module 20: Diagnostics...........................................................................................................392

Module 21: Hardware Acceleration.........................................................................................433

Module 22: IPv6 ......................................................................................................................476