Fortigate

FortiGate Multi-Threat Security Systems II
Secured Network Deployment and IPSec VPN

Student Lab Guide
Course 301
FortiGate Multi-Threat Security Systems

Secured Network Deployment and IPSec VPN
Student Lab Guide
Course 301
01-50003-0301-20131018-D
Copyright 2013 Fortinet, Inc. All rights reserved. No part of this publication including text,
examples, diagrams, or illustrations may be reproduced, transmitted, or translated in any form
or by any means, electronic, mechanical, manual, optical, or otherwise, for any purpose,
without prior written permission of Fortinet, Inc.
Trademarks
Dynamic Threat Prevention System (DTPS), APSecure, FortiASIC, FortiBIOS, FortiBridge,
FortiClient, FortiGate, FortiGate Unified Threat Management System, FortiGuard, FortiGuardAntispam, FortiGuard-Antivirus, FortiGuard-Intrusion, FortiGuard-Web, FortiLog, FortiAnalyzer,
FortiManager, Fortinet, FortiOS, FortiPartner, FortiProtect, FortiReporter, FortiResponse,
FortiShield, FortiVoIP, and FortiWiFi are trademarks of Fortinet, Inc. in the United States and/or
other countries. The names of actual companies and products mentioned herein may be the
trademarks of their respective owners.
VIRTUAL LAB ENVIRONMENT BASICS ............................................................................... 3

Topology for Labs .............................................................................................................................................................................. 3
Logging in to the Virtual Lab Environment ............................................................................................................................ 4
CLASSROOM LAB CONFIGURATION .................................................................................. 8

Lab Preparation (Optional) ........................................................................................................................................................... 9
MODULE 11 ................................................................................................................... 10
Lab 1: Router Configuration and Troubleshooting ............................................................................................ 10
Exercise 1 Connectivity Troubleshooting ............................................................................................................................11
Exercise 2 Configuring Dead Gateway Detection .............................................................................................................16
Exercise 3 Failover and Load-Balancing Using Static Routing ...................................................................................18
Exercise 4 Dynamic Routing ......................................................................................................................................................22
MODULE 12 ................................................................................................................... 25
Lab 1: Virtual Networking ........................................................................................................................................... 25
Exercise 1 Creating VDOMs and VDOM Objects ................................................................................................................26
MODULE 13 ................................................................................................................... 31
Lab 1: Transparent Mode VDOMs ............................................................................................................................. 31
Exercise 1 Transparent VDOM .................................................................................................................................................32
Exercise 2 InterVDOM Link ........................................................................................................................................................33
MODULE 14 ................................................................................................................... 36
Lab 1: High Availability ................................................................................................................................................ 36
Exercise 1 Configuring and Testing the HA Cluster ........................................................................................................38
MODULE 15 ................................................................................................................... 41
Lab 1: Advanced IPSec VPN ......................................................................................................................................... 41
Exercise 1 Configuring IPSec VPNs .........................................................................................................................................42
Exercise 2 Testing the IPSec VPN Configuration ..............................................................................................................45
Exercise 3 Configuring Semi-Redundant IPSec VPNs.....................................................................................................47
Exercise 4 Testing the Semi-Redundant IPSec VPN Configuration ..........................................................................48
Exercise 5 Configuring OSPF .....................................................................................................................................................50
Exercise 6 Testing the OSPF Configuration ........................................................................................................................53
Exercise 7 Enabling Bi-Directional Forwarding Detection ..........................................................................................55
Page |1
Course 301 Secured Network Deployment and IPSec VPN
01-50003-0301-20131018-D
Lab 2: IPSec VPN with FortiClient ............................................................................................................................. 57

Exercise 1 Configuring the FortiGate as a VPN Gateway ..............................................................................................58
Exercise 2 Configuring FortiClient Connect ........................................................................................................................60
Exercise 3 Testing the FortiGate to FortiClient IPSec VPN Connection .................................................................61
MODULE 16 ................................................................................................................... 62
Lab 1: Intrusion Prevention System ........................................................................................................................ 62
Exercise 1 Defining IPS Sensors ...............................................................................................................................................63
Exercise 2 Defining DoS Policies ..............................................................................................................................................65
Exercise 3 Creating Custom Signatures ................................................................................................................................68
MODULE 17 ................................................................................................................... 69
Lab 1: Fortinet Single Sign On .................................................................................................................................... 69
Exercise 1 Installing FSSO on the Windows Server.........................................................................................................70
Exercise 2 Configuring FSSO on the FortiGate Unit ........................................................................................................72
Exercise 3 Testing FSSO On Authentication .......................................................................................................................73
MODULE 18 ................................................................................................................... 74
Lab 1: Certificate Operations ..................................................................................................................................... 74
Exercise 1 Create a Certificate Request ................................................................................................................................75
Exercise 2 SSL Deep Inspection ...............................................................................................................................................77
MODULE 19 ................................................................................................................... 82
Lab 1: Data Leak Prevention ...................................................................................................................................... 82
Exercise 1 Blocking Files by Type ...........................................................................................................................................83
Exercise 2 Blocking Leakage of Credit Card Information .............................................................................................86
Exercise 3 DLP Fingerprinting ..................................................................................................................................................87
MODULE 21 ................................................................................................................... 88
Lab 1: Case Study Scenario .......................................................................................................................................... 88
Background ........................................................................................................................................................................................88
APPENDIX A: ADDITIONAL RESOURCES........................................................................... 89
Page |2
01-50003-0301-20131018-D
Virtual Lab Environment Basics
This section provides details of the virtual lab environment that will be used for the hands-on labs in
this course. Steps are included for connecting to the virtual environment along with troubleshooting
tips to help students easily navigate the lab configuration.
Alert: The following section is only applicable to the Fortinet hosted virtual lab
environment. Please ignore this section if you are using an alternate classroom lab
environment unless otherwise directed by your trainer. If you are uncertain, consult your
trainer to find out which lab setup documentation you must follow.
The network diagram below shows the configuration of the virtual environment that students will use
in the course.
Page |3
01-50003-0301-20131018-D
1. Run the TrueLab System Checker to verify the compatibility of your computer with the virtual
lab environment.
Use the URL that is specific to your location.
Americas:
http://truelab.hatsize.com/syscheck
EMEA:
http://truelab.hatsize.com/syscheck/frankfurt/
APAC:
http://truelab.hatsize.com/syscheck/singapore/
Click Run if a security warning window appears.
The TrueLab System Checker will determine whether a connection can be established from
the PC to the TrueLab environment. It can also help troubleshoot connectivity problems
related to the Java Virtual Machine, company firewall, or proxy server.
If the PC is successfully able to connect to the TrueLab virtual lab environment a Success
message will be displayed.
Page |4
01-50003-0301-20131018-D
If a status of Failed is displayed, verify the on-screen messages to identify potential problem
areas or click the Troubleshooter link to help diagnose any problems that were encountered.
For assistance with troubleshooting speak to your instructor.
2. If a status of SUCCESS is displayed, log in to the virtual lab portal by browsing to the
following URL:
https://remotelabs.training.fortinet.com/
Enter the username and password provided by the instructor and click LOGIN.
Alternatively, you may have received log in credentials for the following URL:
http://virtual.mclabs.com/
Check with your instructor if you are not certain about which portal to use.
3. Select the time zone for your location from the drop-down menu and click UPDATE.
By selecting the proper time zone you ensure that the class schedule is accurate.
Page |5
01-50003-0301-20131018-D
4. The virtual lab Java applet is launched. Select a resolution for the applet and click Open to
access the Windows 2003 Server device in the virtual lab environment. This will serve as the
primary student machine for the classroom exercises.
Note: If for any reason the connection to the virtual Windows 2003 Server is lost, regain
access by selecting Operations > Disconnect and then Operations > Connect to Primary from
the menu.
5. To connect to other virtual machines in this environment go to Operations > Connect to
Secondary and select one of the available machines in the list.
The instructor will provide a description of each of the virtual systems available to you in the
virtual lab environment.
Page |6
01-50003-0301-20131018-D
Troubleshooting Tips
It is not recommended to connect to the virtual lab environment using a wireless (Wi-Fi)
connection or a VPN tunnel. For optimal performance, connect to the lab environment
through a dedicated LAN connection.
Ensure that the company network or firewall policies are not blocking Java applets.
Students should ensure that the following settings are configured on their computer:
Screen savers should be disabled on the computer
The Power Scheme used on the computer should be set to Always on
In the Java Control Panel (located in the Windows Control Panel) ensure that Java
console is set to Show console. It is recommended that the Java console be left open
as it often provides useful logs for troubleshooting.
If you get disconnected unexpectedly from any of the virtual machines (or from the virtual
lab portal) please reattempt a connection. If unable to reconnect repeatedly after multiple
attempts, please notify the instructor.
If during the labs, particularly when reloading configuration files, you see a message
similar to the one shown below, go to the console and enter the following CLI command:
execute update-now
This message indicates that the FGT VM is waiting for a response from the authentication
server. The command execute update-now will resend the request and force a response.
Page |7
01-50003-0301-20131018-D
Classroom Lab Configuration
The following diagram illustrates the classroom network configuration that will be used for the labs in
this course. Each student has an identical lab environment and has full control of their lab devices.
Each student will manage the following devices located in the same network segment:
Windows 2003 Server (full control with RDP access)
2 FortiGate devices
Windows XP (student working device)
Unix Server (with command line access)
Page |8
01-50003-0301-20131018-D
At various points throughout this lab guide, you will be instructed to load different configuration files which
contain objects and settings needed to complete the exercises.
In order to load these configuration files, you will first need to configure some minimum networking
requirements. This must be done since the Student and Remote FortiGate devices in the virtual networking
environment are provisioned from a raw VM image.
The following steps will guide you through the required preparation. These steps MUST be performed
before proceeding. If you have already performed these steps as part of attending the 201 Course, then
these are not required as the environment has already been prepared.
1. Connect to the console of the Student FortiGate device and enter the CLI commands shown below.
(In the virtual lab applet, go to Operations > Connect to Secondary > Student.)
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 device and enter the CLI commands shown below.
(In the virtual lab applet, go to Operations > Connect to Secondary > Remote.)
conf system interface
edit port4
set ip 10.200.3.1/24
set allowaccess https ping ssh
end
conf route static
edit 0
set device port4
set gateway 10.200.3.254
end
Page |9
01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting
The aim of this lab will be for students to set up a router configuration and test various scenarios to
learn how the FortiGate unit makes routing decisions. Students will also work with diagnostics and
debugging commands to troubleshoot their router set-ups.
Students will complete the following tasks:

Select suitable CLI commands for troubleshooting connectivity issues
Identify the configuration objects for dead gateway detection and describe the correct usage
of this technique
Describe the fail-over and load-balancing techniques available with static routing and
describe how to apply a routing policy which takes precedence of the routing table decision
Identify basic dynamic routing configuration settings and use CLI commands to obtain the
status of these protocols
Estimated time to complete this lab: 50 minutes
P a g e | 10
01-50003-0301-20131018-D
Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1
From the Windows host you will connect to an external web site (or http://10.200.3.254) and
observe the output of the following diag commands. Note that the web page will need to be reloaded for each command tested in the steps below.
You will need to define a filter in order to use these commands more easily. In this example, you
could use the source address of the Windows host (10.0.1.10), the service HTTP (port 80) or the
destination address of your target server.
1. From the Windows host, you first will need to connect to each FortiGate device and restore
the configuration files that are needed for this lab.
Connect to the GUI on the Remote FortiGate (10.200.3.1) and restore the following
configuration file: Resources\Module11\Remote\remote-routing.conf.
The Remote FortiGate device will reboot.
Connect to the GUI on the Student FortiGate device (10.0.1.254) and restore the
following configuration file: Resources\Module11\Student\\student-routing.conf.
The Student FortiGate device will reboot.
Note: Upon reboot you may receive a message similar to the following: waiting
for authentication which relates to the VM license. Use the CLI command
execute update-now to force the check.
2. From the CLI of the Student FortiGate device (either use console or SSH), execute the
following commands. In this example, a filter for the source address is used:
diag sniffer packet any host 10.0.1.10 4
If you are connecting via SSH from that IP you will want to add a negate filter so that your
SSH connection is not also captured by the sniffer.
diag sniffer packet any host 10.0.1.10 and not port 22 4
P a g e | 11
01-50003-0301-20131018-D
Now connect to an external web site and observe the output.

STUDENT # diagnose sniffer packet any 'host 10.0.1.10 and not port
22' 4
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
Here we see the three-way handshake complete and the first exchange of data. Note,
because of the NAT action we do not see the traffic on the outgoing interface.
3. Next execute the following commands to look at the session table (negating port 22 if
necessary):
diag sys session filter src 10.0.1.10
diag sys session filter dport 22
diag sys session filter negate dport
diag sys session list
P a g e | 12
01-50003-0301-20131018-D
You will see various sessions listed such as DNS and HTTP. Look for the HTTP session just
established,
session info: proto=6 proto_state=02 duration=115 expire=4
timeout=3600 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=/
state=may_dirty
statistic(bytes/packets/allow_err): org=48/1/1 reply=0/0/0 tuples=2
orgin->sink: org pre->post, reply pre->post dev=4->2/2->4
gwy=10.200.1.254/0.0.0.0
hook=post dir=org act=snat 10.0.1.10:4699>10.0.3.254:80(10.200.1.1:65115)
hook=pre dir=reply act=dnat 10.0.3.254:80>10.200.1.1:65115(10.0.1.10:4699)
pos/(before,after) 0/(0,0), 0/(0,0)
src_mac=
misc=0 policy_id=1 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0
serial=0000006e tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
per_ip_bandwidth meter: addr=10.0.1.10, bps=264
Note the NAT action in bold. The action in the originator direction is Source NAT (act=snat)
here the original IP address and port number are replaced with the new IP address and port
numbers. (How this new IP address and port number is accessed will be discussed more in
the 201 Firewall Policy module).
4. Next execute the following commands to review the debug flow output, using a filter for the
specific host address and service:
diag debug flow filter addr 10.200.1.254
diag debug flow filter dport 80
diag debug flow show console enable
diag debug flow show function enable
diag debug enable
diag debug flow trace start 20
Note that it is generally better to filter on address and port as opposed to source or
destination address or port as this restricts you to one direction of traffic.
P a g e | 13
01-50003-0301-20131018-D
A sample debug flow output is provided below with notes:
STUDENT # id=13 trace_id=21 func=resolve_ip_tuple_fast line=4048

msg="vd-root received a packet(proto=6, 10.0.1.10:4742>10.200.3.254:80) from port3."
SYN received on ingress interface.
id=13 trace_id=21 func=init_ip_session_common line=4176
msg="allocate a new session-000000ed"
New session ID generated.
id=13 trace_id=21 func=vf_ip4_route_input line=1602 msg="find a
route: gw-10.200.1.254 via port1"
Originator direction gateway lookup, this happens once for the session provided there is no
gateway change. FortiOS is routing first.
id=13 trace_id=21 func=get_new_addr line=2347 msg="find SNAT: IP10.200.1.1, port-65158"
SNAT value lookup.
id=13 trace_id=21 func=fw_forward_handler line=621 msg="Allowed by
Policy-1: SNAT"
Firewall policy match.
id=13 trace_id=21 func=__ip_session_run_tuple line=2290 msg="SNAT
10.0.1.10->10.200.1.1:65158"
SNAT applied to packet (note this is post routing).
id=13 trace_id=22 func=resolve_ip_tuple_fast line=4048 msg="vd-root
received a packet(proto=6, 10.200.3.254:80->10.200.1.1:65158) from
port1."
SYN ACK received from server.
id=13 trace_id=22 func=resolve_ip_tuple_fast line=4082 msg="Find an
existing session, id-000000ed, reply direction"
Matches an existing session ID.
P a g e | 14
01-50003-0301-20131018-D
id=13 trace_id=22 func=__ip_session_run_tuple line=2304 msg="DNAT

10.200.1.1:65158->10.0.1.10:4742"
DNAT applied on reply direction to inverse SNAT action.
id=13 trace_id=22 func=vf_ip4_route_input line=1602 msg="find a
route: gw-10.0.1.10 via port3"
Reply direction gateway lookup.
id=13 trace_id=23 func=resolve_ip_tuple_fast line=4048 msg="vd-root
received a packet(proto=6, 10.0.1.10:4742->10.200.3.254:80) from
port3."
ACK received from client.
id=13 trace_id=23 func=resolve_ip_tuple_fast line=4082 msg="Find an
existing session, id-000000ed, original direction"
Matches an existing session ID.
id=13 trace_id=23 func=ipv4_fast_cb line=50 msg="enter fast path"

Matches an established session.
Debug flow can be combined with other debug commands, such as packet sniffer and
application debug to aid troubleshooting, however for most connectivity issues the debug
flow is a very good tool.
Discuss the output of these commands in a group discussion with your Instructor.
P a g e | 15
01-50003-0301-20131018-D
When there are different paths to the same destination, Dead Gateway Detection can be used to
provide a fail-over mechanism whereby a detect server is configured. The detect server is an
address of a reachable upstream device. The FortiGate unit then uses an echo/echo reply
mechanism, typically ICMP ping, but UDP echo and TCP echo are also supported. If the device fails
to respond after a configured number of retries, then the static routes associated with that interface
are removed from the routing database.
When a FortiGate unit is configured as part of a site-to-site VPN, the detect server is often the VPN
remote gateway.
This is the example we shall use in our virtual lab, therefore the Student FortiGate device has two
Dead Gateway Detection entries:
First Entry:
Interface:
port1
Gateway IP:
10.200.1.254
Ping Server:
10.200.3.1
Second Entry:
Interface:
port2
Gateway IP:
10.200.2.254
Ping Server:
10.200.4.1
Refer to the network diagram provided at the beginning of this lab guide to verify the FortiGate
device IP addresses.
1. From the GUI on the Student FortiGate device, go to Router > Static > Settings and check
the above Dead Gateway Detection configuration. The detect server is enabled on the
interface through the CLI.
From the Student FortiGate device run a packet sniffer as follows:
diagnose sniffer packet any icmp 4
At this stage, you should observe the request/response traffic on port1, however there is no
response on port2 because of the Remote FortiGate units current configuration.
P a g e | 16
01-50003-0301-20131018-D
2. Connect to the GUI on the Remote FortiGate device and go to Router > Static > Settings.
Click Create New and configure the following two Dead Gateway Detection objects:
First:
Interface:
port4
Gateway IP:
10.200.3.254
Ping Server:
10.200.1.1
Second:
Interface:
port5
Gateway IP:
10.200.4.254
Ping Server:
10.200.2.1
3. Again, from the Student FortiGate device run a packet sniffer:

diagnose sniffer packet any icmp 4
You should now observe the echo request/reply on port2. By adding the gwdetect entry this
has created a route back to this source in the kernel routing table and therefore these
gateway detect packets now pass the RPF checking. You should now observe ICMP echo
request/reply for both the local and remote gateway detection traffic.
4. You can see the gateway detection entries as special entries in the kernel routing table.
Look for the destination and gateways entered.
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)
P a g e | 17
01-50003-0301-20131018-D
1. Currently the routing is set up in a fail over configuration. On the Student FortiGate device,
the following routes are configured:
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 same method of higher distance is configured on the Remote FortiGate device.
With this configuration, the higher distance route is prevented from being used in the routing
table.
Check this by entering the following command on the Student FortiGate device:
get router info routing-table all
You should observe that there is only one default route.
2. Next, enter the following command:
get router info routing-table database
You should note that in the routing database, the second default route is present but not a
selected route.
3. Execute the same commands used above from the CLI on the Remote FortiGate device. You
should observe a similar configuration.
Stop and Think
Under which conditions will the second default route listed in the routing table be used?
Discussion
If the primary link fails, the redundant path (second default route) will be used. This failure
could occur if the link goes down or if the Dead Gateway Detection associated with that
interface fails.
4. Open a web browser on the Windows Server, and try to connect to the GUI of the Remote
FortiGate unit (10.200.4.1) on port5.
You should observe that this connection fails. This is because there is no route back to the
source on port4. Only a route back for the gateway detect peer is available on the routing
table.
Therefore, if we want incoming traffic on an interface from an unknown source IP 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.
P a g e | 18
01-50003-0301-20131018-D
5. On the Student and Remote FortiGate devices, set the distance of the second default routes
to be the same as the primary default route.
6. Next, enter the following commands:
get router info routing-table database
You should observe that the route is now selected and appears in the routing table.
Open a web browser on the Windows Server, and connect to the GUI of the Remote
FortiGate unit (10.200.4.1) on port5. Now you should observe that this connection is
successful.
7. We now have a multi-path configuration as there are two available paths for the default route.
FortiOS supports Equal Cost Multi Path routing for static routes. In order to configure ECMP,
a value called priority is used.
The priority is configured in the static route object. The priority is not used/visible in the
routing table. The priority is a value issued in the Forwarding Information Base (FIB).
Tip: What is the FIB?
The FIB is generated by the routing process on the system and is the actual
table used for packet forwarding when sessions are established. It is useful to
think of the routing table as the management plane and the FIB as the
forwarding plane. A useful example to illustrate this separation is HA. In an HA
cluster, the management plane and forwarding plane are present on the primary
device, however only the forwarding plane is present on the secondary device
and this is put in place and updated by the management plane of the primary
device.
8. By default the priority value is 0, therefore, for multiple paths to the same destination in static
routing, ECMP routing is enabled.
This can be observed by entering the command below used to view the FIB:
get router info kernel
Observe the two entries with destination 0.0.0.0/0 and look for the prio value. Both
entries should have prio=0.
By default ECMP uses the source hash technique for traffic distribution, which means same
source IP and same gateway. In our example, as all traffic is coming from the same source
address, the Windows Sever, it will use 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 traffic from the same source IP is distributed. (You may be faced
with a similar scenario in your production network).
P a g e | 19
01-50003-0301-20131018-D
9. Change the ECMP distribution method on the Student FortiGate device in Router > Static >
Settings. Set the ECMP load balance method to Spillover and set the Spillover Threshold to
1(1Kbps)on port1. Leave the port2 setting at 0. (For demonstration purposes we will use this
very low spill-over threshold of 1Kbps).
This will enable spill-over where a new gateway is chosen after a higher numbered interface
is over subscribed.
10. On the virtual Windows Server, open a web browser and connect to a random web site to
generate HTTP traffic.
11. Back in the CLI on the Student FortiGate device, run the following commands:
diagnose sys session filter dport 80
diagnose sys session list | grep dev
Locate the interface pairs by identifying the section dev=4->3/3->4 in the output:
12. From the web browser again on the Windows Server, connect to several other web sites.
With the low spill over threshold set, sessions should be distributed across both links. You
can examine this from the output of the above diagnose command.
Since this command outputs the interface numbers and not their names, use the output of
the following CLI command to match the interface number to its name:
diag netlink interface list
Alternatively, use the following packet sniffer command to filter TCP packets on port 80 with
the SYN flag set:
diag sniffer packet any tcp[13]&2==2 and port 80 4
P a g e | 20
01-50003-0301-20131018-D
13. Next, it may be undesirable to load balance all traffic and there may be hosts and/or
protocols which we would like to use a particular gateway for. This can be achieved with
policy routing which takes precedence over the routing table.
In this example, you will create a policy route to force all outgoing HTTPS traffic on the
Student FortiGate device to use the gateway: 10.200.2.254. Go to Router > Static >
Policy Route. Click Create New and use the following settings to create your policy route:
Protocol:
6 (TCP)
Incoming Interface:
port3
Destination Ports:
From: 443 To: 443
Outgoing Interface:
port2
Gateway Address:
10.200.2.254
Note: Dead gateway detection also affects policy routes as well as static
routes, therefore if these do not work, check your detect server settings.
14. The policy route configuration created above can be tested with the following sniffer
command and by connecting to an HTTPS enabled web site.
Enter the following command from the CLI on the Student FortiGate device:
diag sniffer packet any port 443 4
From the web browser on the Windows Server, connect to the following web site:
https://mail.google.com
Alternatively, you can use https://10.200.3.254 as a target and the packet sniffer filter:
diag sniffer packet any host 10.200.3.254 4
P a g e | 21
01-50003-0301-20131018-D
We will now go through a simple BGP configuration that will show us the steps to set up a BGP peer
relationship between the Student and Remote FortiGate devices. In this lab, you will configure
dynamic routing using the GUI and CLI and run some CLI diagnostic commands.
1. On the Student FortiGate device, go to Router > Dynamic > BGP and set the following
parameters:
Local As:
65501
Router ID :
0.0.0.1
Click Apply.
2. Next add the BGP neighbor to be announced in BGP using the following details:
Neighbor IP:
10.200.3.1
Remote As:
65502
Click Add / Edit.

3. From the CLI of the Student FortiGate device edit the BGP settings and enable multi-hop
BGP by entering the CLI commands shown below. This step is required because the BGP
peer is not the next hop.
config router bgp
config neighbor
edit 10.200.3.1
set ebgp-enforce-multihop enable
end
In addition, configure BGP to redistribute all the connected networks.
config redistribute "connected"
set status enable
end
4. On the Remote FortiGate device, go to Router > Dynamic > BGP and set the following
parameters:
Local As:
65502
Router ID:
0.0.0.2
Click Apply.
P a g e | 22
01-50003-0301-20131018-D
5. Now add the BGP neighbor to be announced in BGP using the following details:
Neighbor IP:
10.200.1.1
Remote As:
65501
Click Add / Edit.

6. From the CLI of the Remote FortiGate device, edit the BGP settings and enable multi-hop
BGP by entering the CLI commands shown below. This step is required because the BGP
peer is not the next hop.
config router bgp
config neighbor
edit 10.200.1.1
set ebgp-enforce-multihop enable
end
In addition, configures BGP to redistribute all the connected networks.
config redistribute "connected"
set status enable
end
7. Check the routing table of both the Student and Remote FortiGate devices. From the GUI go
to Router > Monitor > Routing Monitor, or from the CLI enter get router info routing-table all.
You should see BGP routes to the announced network of the remote AS.
At this stage we have routing information on the FortiGate devices however there are some
issues that would need to be resolved: the Linux router is not aware of the 10.0.1.0/24
and the 10.0.2.0/24 networks. You would need to add static routes to the Linux router for
this traffic to be forwarded correctly. This is an example of a common deployment, albeit the
other way round, where multi-hop BGP is used between routers however it is the FortiGate
device in between the two routers which is configured with static routes.
P a g e | 23
01-50003-0301-20131018-D
8. From the CLI, run the following command to show routing information for BGP:
get router info bgp summary
9. From the CLI, enable dynamic routing diagnostic output. The following commands will
decode the BGP packets being sent and received between the two peers.
diag debug enable
diag ip router bgp all enable
diag ip router bgp level info
10. While the debug is running, from the GUI of the Remote FortiGate device, change the local
AS value to 65522. Observe the error in the debug message now that the remote AS value
no longer matches what is configured for that IP address.
id=0 msg="BGP: 10.200.3.1-Outgoing [DECODE] Open: Bad Remote-AS (65522), expected
65502"
id=0 msg="BGP: 10.200.3.1-Outgoing [FSM] State: OpenSent Event: 22"
id=0 msg="BGP: 10.200.3.1-Outgoing [ENCODE] Msg-Hdr: Type 3"
id=0 msg="BGP: %BGP-3-NOTIFICATION: sending to 10.200.3.1 2/2 (OPEN Message
Error/Bad Peer AS.) 4 data-bytes [ff f2 00 00]"
11. On the Remote FortiGate device, change the AS value back to 65502. You should obsever
in the debug output that the configuration error is resolved.
12. Enter the following commands to switch off the BGP debug.
diag ip router bgp level none
diag ip router bgp all disable
Disable debugging and reset debug output to defaults.
diag debug disable
diag debug reset
P a g e | 24
01-50003-0301-20131018-D
Module 12 Lab 1: Virtual Networking
The aim of this lab is for students to gain experience working with VDOMs and to be familiar with the
VLAN configuration objects.
Configure and test VDOMs
P a g e | 25
01-50003-0301-20131018-D
Module 12 Lab 1: Virtual Networking Exercise 1
1. From the Windows Server, you first will need to connect to the Student FortiGate device and
restore the configuration file that is needed for this lab.
following configuration file: Resources\Module12\Student\Student-vdom.conf
2. Before enabling VDOMs run the following CLI command:
diag sys vd list
This command lists the configured VDOMs. Observe that there are already VDOMs in place,
there is the root VDOM which is the default VDOM for all interfaces and there are two others
vsys_ha and vsys_fgfm. These other VDOMs are special VDOMs used for HA and
FortiManager respectively. We will not be discussing them further in this lab however, the
point is to demonstrate that enabling VDOMs enables the possibility to create more VDOMs.
VDOMs in themselves are fundamental to FortiOS and not a separate feature.
3. On the Student FortiGate device, go to System > Dashboard > Status and in the System
Information widget, click the Enable link for Virtual Domain.
You will be logged out of the FortiGate unit and will need to log back in again.
4. Once logged back into the Student FortiGate device, the GUI will automatically display the
Global Configuration. To access the root VDOM, click Virtual Domains which is displayed
at the bottom of the left-hand menu of the GUI.
5. Go to Global > VDOM > VDOM. Create and enable a new VDOM in NAT mode called
customer.
Note that the customer VDOM is now listed and you can select it from the VDOM list by
clicking Virtual Domains in the lower left-hand corner of the GUI.
6. Create an administrative user for the customer VDOM. In the Global Configuration, go to
Global > Admin > Administrators and create a new administrator with the following details:
Administrator:
customer-admin
Type:
Regular
Password:
Fortinet
Admin Profile:
prof_admin
Virtual Domain:
customer
This administrator will only have permission to edit settings within the customer VDOM. This
administrator will only be able to log in through an interface that is assigned to the customer
VDOM.
P a g e | 26
01-50003-0301-20131018-D
7. You will now place the port3 interface which connects to the internal network, in the customer
VDOM. Before trying to move the interface however, you will first need to ensure the port3
interface is not referenced by any objects such as firewall policies, DNS, routing etc.
Go to Global > Network > Interface and note the value listed in the Ref. column for port3. If
the value is zero, you can simply edit the interface settings and select the customer vdom
from the Virtual Domain drop-down list.
For non-zero Ref. values, click on the value and note the object usage references. Remove
any objects that reference port3. For example, if port3 is referenced by the system DNS, you
will need to go to System > Network > DNS Server (in the root VDOM) and delete the DNS
Service on port3. Once all references have been removed, you will be able to move the port3
interface to the customer VDOM.
Leave the port1 and port2 interfaces in the root vdom. This will provide a separation between
the customer firewall and the firewall that is providing Internet or external access. This is a
common usage scenario and there typically would be several customer type VDOMs
connecting to the single root vdom providing external access. An example of such usage is
an airport where each airline and airport service has their own virtual firewall connected to
the root firewall providing the network services.
Now port3 is in the customer vdom and port1 and port2 are in the root vdom.
8. Go to the CLI and look at the routing table for each VDOM:
You may have difficulty entering this command. This is because you need to be in the
context of your VDOM to enter this command.
To enter the customer vdom context enter the following CLI commands:
config vdom
edit customer
P a g e | 27
01-50003-0301-20131018-D
Note that the VDOM name entered is case sensitive. Afterwards check the routing table
with the following CLI commands:
next
Now go to the root vdom to view the routing table. Be careful with this command because the
VDOM names are case sensitive!! If you enter Root, you will in fact create a new vdom called
Root in addition to the root vdom.
edit root
9. Next you will create an inter-vdom link to the connect the two vdoms.
On the Student FortiGate device, go to Global > Network > Interface. Click next to Create
New displayed in the top left hand corner of the page and select VDOM link. Create a new
VDOM Link using the following details:
Name:
vlink
Interface #0
vlink0
Virtual Domain:
root
IP/Network Mask:
10.10.100.1/30
Administrative
Access:
HTTPS, PING, SSH
Interface #1
vlink1
Virtual Domain:
customer
IP/Network Mask:
10.10.100.2/30
Administrative
Access:
HTTPS, PING, SSH
After creating the inter-VDOM links, note that the VDOM links created along with two subinterfaces have been placed within the root and customer VDOMs. These interfaces have
been named vlink0 and vlink1. These are point-to-point interfaces that allow communication
between the root and services VDOMs. IP addresses are not required on these interfaces,
but can help with troubleshooting routing issues (for example, when using traceroute).
P a g e | 28
01-50003-0301-20131018-D
10. A default route is required for the customer VDOM using the newly created inter-VDOM link
interface.
Click Virtual Domains > customer > Router > Static > Static Route and create a new route
using the following details:
Destination IP/Mask:
0.0.0.0/0
Device:
vlink1
Gateway:
10.10.100.1
11. A route for the internal network is required for the root VDOM using the newly created interVDOM link interface.
Go to Virtual Domains > root > Router > Static > Static Route. Create a new route using the
following details:
10.0.1.0/24
Device:
vlink0
Gateway:
10.10.100.2
12. In the root VDOM create a Zone for port1 and port2. Go to Virtual Domains > root > System
> Network > Interface. Click next to Create New and create a new Zone.
Assign a name of External and specify port1 and port2 as Interface Members.
13. A firewall policy must be created to allow traffic from the customer VDOM out to the Internet
through the interfaces. Still in the root VDOM, go to Policy > Policy > Policy and create a
new policy for traffic to External with the following details:
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
vlink0
Source Address:
all
Outgoing Interface:
External
Destination Address:
all
Schedule:
always
Service:
ALL
Action:
ACCEPT
Enable NAT:
enabled
P a g e | 29
01-50003-0301-20131018-D
14. Switch to the customer VDOM, create a second policy that allows traffic from the port3
interface to the vlink1 interface with the following details:
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
port3
Source Address:
all
Outgoing Interface:
vlink1
all
Schedule:
always
Service:
ALL
Action:
ACCEPT
Enable NAT:
Disabled
15. After that, you will need to reconfigure DNS forwarding on port3 . Still in the customer
VDOM go to System > Network > DNS Server and configure DNS Service on Interface and
configure port3 to forward to system DNS. Connect to an external web site and ensure that
the count field of the firewall policy is incrementing on both the outgoing policy of the
customer VDOM and the outgoing policy of the root VDOM.
16. From a DOS prompt on the Windows Server, run the following trace route command and
verify the path over the inter-vdom link.
tracert d 4.2.2.2
17. In a web browser on the Windows Server, log in to the customer VDOM (10.0.1.254) by
entering the customer-admin username and password in the login screen.
You can access the customer VDOM on port3 because it is a member interface of that
VDOM.
18. Navigate through the GUI and select the various menu items to see what the VDOM
administrator has the ability to control.
Since the customer-admin administrator has access to the customer VDOM only, they will
not automatically be placed into the Global Configuration, nor will they have access to it. The
display of the GUI will change as the service-admin user has access to only the VDOM
specific objects. Logout from the customer VDOM.
P a g e | 30
01-50003-0301-20131018-D
Module 13 Lab 1: Transparent Mode VDOMs
The aim of this lab is for students to configure two transparent mode VDOMs and to enable UTM
inspection to all traffic in the root VDOM. An inter-vdom link will be used to inter-connect the two
VDOMs.
Configure two transparent mode VDOMs

Create and use VDOM objects
P a g e | 31
01-50003-0301-20131018-D
Module 13 Lab 1: Transparent Mode VDOMs Exercise 1
following configuration file: Resources\Module13\Student\Student-tp.conf
2. On the Student FortiGate device, go to System > Dashboard > Status and in the System
Information widget, click the Enable link for Virtual Domain.
You will be logged out of the FortiGate unit and will need to log back in again.
3. Once logged back into the Student FortiGate device, the GUI will automatically display the
Global configuration.
4. 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
P a g e | 32
01-50003-0301-20131018-D
1. Enter the following CLI commands to create an inter-vdom link:

config global
config system vdom-link
edit link
set type ethernet
end
end
2. Next, configure the inter-vdom link interfaces, by entering the following CLI commands:
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
3. Go to Global > Network > Interface and review the inter-vdom link interfaces created above.
Note that link0 and link1 are internal ethernet interfaces that allow communication between
the root and inspect VDOMs. An IP address is only configurable on the NAT/Route mode
vdom interface.
4. Go to the GUI and review the new VDOM tree display by selecting Virtual Domains and
reviewing the root and inspect vdoms.
5. Next, you will move the port1 interface to the inspect VDOM. Go to Global > Network >
Interface and edit the port1 interface. From the Virtual Domain drop-down list select the
inspect VDOM. This is possible because the port1 interface is not referenced by any firewall
policies or routing. Also ensure that Ping access is enabled on port1.
P a g e | 33
01-50003-0301-20131018-D
6. Go to the inspect VDOM and create the following polices to allow traffic between the port1
and link1 interfaces initiated in either direction:
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
any
Source Address:
All
Outgoing Interface:
any
all
Schedule:
always
Service:
ALL
Action:
ACCEPT
From the Firewall Policy display of the inspect VDOM, right-click on the Security Profiles field
and select the default Antivirus profile. A message will prompt you that this change has been
saved.
7. In the root VDOM go to Policy > Policy > Policy and create a new policy for port3 to link0
using the following settings. Note that you may create this policy by performing a copy and
paste of the existing outgoing policy and changing the outgoing interface.
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
port3
Source Address:
all
Outgoing Interface:
link0
all
Schedule:
always
Service:
ALL
Action:
ACCEPT
Enable NAT:
enabled
Logging Options:
Log all sessions
P a g e | 34
01-50003-0301-20131018-D
8. To direct traffic from your Windows host to the inspect VDOM, in the root VDOM, create a
new static route pointing to the inter-vdom link using the following settings:
0.0.0.0/0
Device:
link0
Gateway:
10.200.1.254
Click OK.
Increase the cost of the priority of the port2 default route to 5, so that this is not the preferred
route.
Test by running a tracert d 10.200.3.1 from your Windows Server and check that
your hops are 10.0.1.254 and 10.200.1.254.
Run a continuous ping to 10.200.1.254.
9. Download the Eicar virus test file from the web site:
http://eicar.org.
Check for a traffic log message in the root VDOM and a UTM message in the inspect VDOM.
10. From the GUI on the Student FortiGate device, go to Global > Dashboard. 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.
11. Click +Widget and add the Top Sessions widget. Edit the widget and set Report by: to All.
Edit the column settings and add Virtual Domain. Check that there is a session reported in
each VDOM.
P a g e | 35
01-50003-0301-20131018-D
Module 14 Lab 1: High Availability
The aim of this lab is to set up a high availability cluster configuration using FortiGate devices in the
student environment. Different HA modes will be used to set up various HA configurations and
students use diagnostics and debug commands to observe HA functionality and behavior on the
FortiGate unit.
Set up an HA cluster using FortiGate devices in the student environment

Execute and interpret diagnostic output
Test HA synchronization and failover
P a g e | 36
01-50003-0301-20131018-D
Module 14 Lab 1: High Availability HA Lab Topology
The virtual lab environment has been wired to allow an HA cluster to be configured using the
existing devices as shown in the following network diagram.
P a g e | 37
01-50003-0301-20131018-D
Module 14 Lab 1: High Availability Exercise 1
1. From the Windows Server, you first will need to connect to each FortiGate device and restore
configuration file: Resources\Module14\Remote\remote-ha.conf.
following configuration file: Resources\Module14\Student\student-ha.conf.
2. Open the console on both the Student and Remote FortiGate devices. This allows you to
observe the standard error messages sent to the console which provide useful status
information, such as:
slave succeeded to sync external files with master
Wait 4 to 5 minutes for units to synchronize. You can check on the status by issuing the
command diag sys ha showcsum on both Student and Remote. Checksums will match
if units are in synch. In the sample config of the Remote FortiGate unit, the command should
read: set group-name training.
The Student FortiGate device configuration contains the following 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 FortiGate device configuration contains the following HA settings.
config system ha
set mode a-a
set priority 100
set group training
set password Fortinet
set session-pickup enable
set hbdev port2 50
end
P a g e | 38
01-50003-0301-20131018-D
3. To verify if the cluster has been established, enter the following CLI command:
get system status
View the Current HA mode line. You should observe that the Student FortiGate unit is a-a
master, and the Remote FortiGate device is a-a backup.
Connect to the GUI of the cluster (10.0.1.254) and go to System > Config > HA to see
status information of the cluster members.
4. Next you will test the session sync. To do this load a few pages from several web sites and
from the CLI look at the session table entries of both the Student and Remote FortiGate
devices using the following CLI commands:
diag sys session filter dport 80
From the CLI enter the command:
diag sys session stat
If you are using SSH/Telnet instead of the console, use the following command to access the
slave CLI from the master,
execute ha manage <id>
(use ? to list the id values)
exit (to return to master)

You should observe that the session count is greater on the master device than on the
backup device. The reason for this is because all management traffic goes to and from the
master and all non-TCP traffic is handled by the master. By default, only TCP sessions
destined for proxy inspection are load balanced between the master and backup units.
5. To test fail-over, view a long YouTube video and at the same time run a continuous ping to a
public IP address.
To simulate a failover, reboot the Student FortiGate device by entering the command:
execute reboot
6. Because of the failover condition, the Remote FortiGate device is now master. Check this
from the CLI as follows:
get sys stat
P a g e | 39
01-50003-0301-20131018-D
7. Check the HA status of the Student FortiGate device when it returns to the cluster. Does it
rejoin as backup or as master? You can use the command diag sys ha status to see
all cluster members.
You should observe the device joins as slave and not master.
From the Remote FortiGate device, execute the following command to make the Student
FortiGate device become master again:
diagnose sys ha reset-uptime
By resetting the HA uptime it forces the cluster to use the next value to determine the master
which is the unit priority, You should observe that the Student FortiGate device is now
master. Check the system uptime to see that this remains unchaged, it is the HA uptime that
is reset, get sys perf status.
8. The following is for information purposes only and gives some insight into the ha-sync
process, which is the process responsible for the FGCP packets that communicate cluster
status and build the cluster.
On the Student FortiGate device enter:
diag debug enable
diag debug application ha-sync
255
On the Remote FortiGate device enter:

execute reboot
On the Student FortiGate device observe the debug output as the slave reboots and starts
communicating with the cluster.
9. Important: Before proceeding to the next lab, connect to https://10.0.1.254 and go to
System > Config > HA and for the REMOTE device click the Disconnect from cluster icon to
remove it as an HA cluster member.
When prompted,configure port3 with the IP address 10.0.1.251/24 and allow HTTP
access.
STUDENT # execute ha disconnect FGVM010000006759 port3 10.0.1.251 255.255.255.0
Sending cmd to HA member 0
P a g e | 40
01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN
The aim of this lab is for students to work with some of the more advanced capabilities of IPSec
VPNs. Students configure advanced VPN settings used in hub-spoke and partial meshed
configurations.
Students use debugging and diagnostics commands to observe IPSec VPN traffic and events
Dynamic routing protocols will be introduced to demonstrate a redundant VPN path and failover
P a g e | 41
01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN Exercise 1
You will now configure a site-to-site tunnel between Student port1 and Remote port4. In this
example use interface based IPsec. In a later exercise, you will configure an IP address on this
IPsec interface in order to configure dynamic routing.
Below are the settings to configure the Student FortiGate device. Once you have completed these
steps, you will then need to configure the Remote FortiGate device. Note that the steps for this are
intentionally not provided since the objective of this exercise is for the student to determine the
correct settings on their own, based on the Student device settings that are given. You can also use
the network diagram (located at the beginning of this lab guide) for additional guidance.
configuration file: Resources\Module15\Remote\remote-ipsec2.conf.
following configuration file: Resources\Module15\Student\student-ipsec2.conf.
2. From the GUI on the Student FortiGate Device, go to VPN > IPsec > AutoKey (IKE) and
create a new Phase 1 for an IPSec VPN as follows:
Name:
Remote_1
Remote Gateway:
Static IP Address
IP Address:
10.200.3.1
Local Interface:
port1
Mode:
Main
Authentication Method:
Preshared Key
Pre-shared Key:
fortinet
Click Advanced and set the following:

Enable IPSec Interface Mode:
Enabled
P1 Proposal
1-Encryption:
Authentication:
DH Group::
AES256
SHA1
5
XAuth
Disabled
Dead Peer Detection:
Enabled
Leave other fields at their default value.

P a g e | 42
01-50003-0301-20131018-D
3. Create a new Phase 2 for the VPN as follows:

Name:
P2_Remote_1
Phase 1:
Remote_1 (the name assigned to Phase 1 above)
Click Advanced and set the following:

P2 Proposal
1-Encryption:
Authentication:
AES256
SHA1
Enable replay detection:
Enable
Enable perfect forward secrecy:
Enable
DH Group:
Autokey Keep Alive:
Enable
4. Go to Router > Static > Static Route and create a new static route for the IPSec VPN with the
following details:
10.0.2.0/24
Device:
Remote_1
5. Go to System > Network > Interface, and create a new zone with the following settings:
Zone Name:
VPN
Interface Members:
Remote_1
6. Create two firewall policies between port3 and VPN in both directions with the following
details:
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
port3
Source Address:
STUDENT_INTERNAL
Outgoing Interface:
VPN
REMOTE_INTERNAL
Schedule:
always
Service:
ALL
Action:
ACCEPT
P a g e | 43
01-50003-0301-20131018-D
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
VPN
Source Address:
REMOTE_INTERNAL
Outgoing Interface:
port3
STUDENT_INTERNAL
Schedule:
always
Service:
ALL
Action:
ACCEPT
7. Repeat the configuration on the Remote FortiGate device using the above settings and the
network diagram for guidance.
Use the name Student_1 for the Phase 1 object on port4 on the Remote FortiGate device.
Use the name P2_Student_1 for the Phase 2 object on the Remote FortiGate device.
The route associated with this interface is to 10.0.1.0/24, the internal network of the
Student FortiGate device.
8. Create the VPN zone and incoming and outgoing firewall policies.
P a g e | 44
01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN VPN Connection Troubleshooting
1. From a command prompt on the Windows Server confirm that you can successfully ping the
following IP addresses in the Remote environment:
ping 10.0.2.10
ping 10.0.2.254
2. From the Student FortiGate device, enter the following CLI command. This sets the ping
options for the FortiGate unit to ping from the port3 interface:
exec ping-options source 10.0.1.254
3. From the Student FortiGate device, enter the following CLI command to ping the Remote
environment through the VPN set up on the Student FortiGate unit:
exec ping 10.0.2.254
4. From the GUI on the Student FortiGate device go to VPN > Monitor > IPSec Monitor.
Confirm that the Remote_1 IPSec VPN is UP. A green arrow should be displayed in the
Status column for the connection.
Troubleshooting will be required if the Status column displays a red arrow or the VPN
connects but ping traffic cannot be passed through the connection.
Any connectivity issues should be fixed before continuing. If the IPSec VPN connection is down,
review all settings and re-enter the pre-shared keys.
1. Can the Remote gateway address be pinged? (This is the IP address of the external
interface on the Remote FortiGate device.)
Can the Remote device ping the gateway address of the Student device?
If each others external addresses cannot be pinged in the clear (and ping is enabled on the
interfaces), then basic connectivity for the VPN has not been established.
Note: Be sure to force the pings out to the correct interface. This may mean
shortening the distance value that was configured on the static route being tested.
Can ping be used successfully from the Student FortiGate device to the external interface on
the Remote FortiGate device? Clear the ping-options settings first.
exec ping 10.200.3.1
Can the Remote device ping the Student FortiGate unit?
P a g e | 45
01-50003-0301-20131018-D
Module 15 Lab 1: Advanced IPSec VPN VPN Connection Troubleshooting
2. If the VPN still does not connect, use the following debug commands on one side of the VPN,
for example on the Student FortiGate device:
diag debug enable
diag vpn ike log-filter dst-addr4 10.200.3.1
diag debug app ike -1
Examine the output. It can usually direct to the point of failure.

To turn off the debug enter the following command (keep on typing right through the scrolling
output):
diag debug reset
3. On the Remote FortiGate device (10.0.1.254) , attempt to send traffic. You can either use
a continuous ping to the internal interface or click the up arrow on the VPN Monitor.
4. If the tunnel is connected but not forwarding traffic, the issue may with the zones, routes, or
policies.
Verify that the virtual interfaces are listed as part of the zone.
Verify the static route and confirm that it is listed in the routing monitor.
Verify that there are two firewall policies and that they are to and from the IPSec interface
(
and
)
Verify that the ping is leaving the interface. Run the following command on the sending
FortiGate unit:
diag sniff packet port1 icmp
Verify that the ping is arriving at the interface. Run the following command on the receiving
FortiGate unit:
diag sniff packet port1 icmp
Alternately, you can use diag debug flow.
Speak with your instructor for further guidance if these steps do not help resolve the issue.
P a g e | 46
01-50003-0301-20131018-D
In this exercise, a second route-based VPN will be created from port2 port5.
1. Repeat the configuration steps of exercise 1, this time the VPN is from Student FortiGate
port2 to Remote FortiGate port 5
Use the name Remote_2 for the Phase 1 object on port2 on the Student FortiGate device
Use the name P2_Remote_2 for the Phase 2 object on the Student FortiGate device
Use the name Student_2 for the Phase 1 object on port5 on the Remote FortiGate device
Use the name P2_Student_2 for the Phase 2 object on the Remote FortiGate device
2. Add a second route to the remote network. This time using the second IPSec interface and
using a higher distance of 20.
3. Add the new IPSec interfaces to the zone VPN and enable intra-zone traffic.
P a g e | 47
01-50003-0301-20131018-D
1. From the IPsec Monitor bring up the second tunnel.

2. From the DOS prompt on the Windows Server run continuous pings toIP addresses in the
Remote environment can be successfully pinged:
ping t 10.0.2.10
ping t 10.0.2.254
3. To test the VPN fail-over, in the root VDOM on the Student FortiGate device, go to System >
Network > Interface and edit port1. Set the Administrative Status to DOWN, alternatively use
the example in the note below.
Note: When changing the administrative status of an interface, affected sessions

will not fail back when the primary path is brought back up.
Alternatively, an upstream device failure can be simulated by executing the
following command from a command prompt on the LINUX host:
ifconfig eth3 down
(To access the LINUX device, use PuTTY to connect using SSH to
10.200.1.254.
Log in with the username of root and the password of password.)
This will create a more realistic failure and will require DPD and DGD to detect the
failure.
Also when the primary path is brought back up using the following command, the
affected sessions will fail back:
ifconfig eth3 up
4. Enter the following commands from the CLI on the Student FortiGate device to observe the
session fail-over:
diag sys session filter dst 10.0.2.10
P a g e | 48
01-50003-0301-20131018-D
Sample output:
session info: proto=1 proto_state=00 duration=401 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
statistic(bytes/packets/allow_err): org=16020/267/1 reply=14220/237/1
tuples=2
gwy=10.0.2.10/10.0.1.10
hook=pre dir=org act=noop 10.0.1.10:768->10.0.2.10:8(0.0.0.0:0)
hook=post dir=reply act=noop 10.0.2.10:768->10.0.1.10:0(0.0.0.0:0)
serial=00000231 tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
total session 1
Observe in the above output that the interface pair used for traffic ingress and egress will
update to reflect the VPN failover. For example, the value dev=4->17/17->4 will change to
reflect the new interface pair.
In order to see the name to number mapping, locate the ifindex value in the output of the
following CLI command:
diag netlink interface list
5. Important: Before proceeding, change the Administrative Status of the port1 interface on the
Student FortiGate device back to UP.
P a g e | 49
01-50003-0301-20131018-D
1. On the Student FortiGate device, go to Router > Static > Static Route and increase the
distance for Remote_1 from 10 to 210 and the distance for Remote_ 2 from 20 to 220.
Repeat this on the Remote FortiGate device.
From the CLI use get router info routing-table all to check the change to the
distance for the IPsec interface routes.
2. On the Student FortiGate device, go to System > Network > Interface and edit each of the
IPSec interfaces in the VPN zone to add the Local IP and Remote IP address values from
the chart below:
Interface Names
IP
Remote IP
Remote_1
172.16.1.1
172.16.2.1
Remote_2
172.16.1.2
172.16.2.2
3. On the Student FortiGate device, go to Router > Dynamic > OSPF.

Enter the Router ID of 0.0.0.1. Click Apply before continuing.
Areas
Click Create New to define an area with an IP address of 0.0.0.0. Accept the defaults for
the remaining parameters.
Networks
Click Create New to define the internal subnet for the OSPF networks. Set the IP/Netmask
value to 10.0.1.0/24. Leave the Area value as the default of 0.0.0.0.
Repeat this step to add the IPSec interface subnet of 172.16.0.0/12.
Interfaces
Click Create New to create new OSPF interfaces for the two IPSec interfaces with the values
from the chart below:
Interface Names
Interface
IP
COST
R1_OSPF
Remote_1
172.16.1.1
10
R2_OSPF
Remote_2
172.16.1.2
20
Accept the defaults for the remaining parameters.
P a g e | 50
01-50003-0301-20131018-D
4. To make the VPNs redundant, the cost of the redundant VPN routes must be lowered (the
default cost is 1500) by typing the following CLI commands from the root VDOM:
config router ospf
config ospf-interface
edit R1_OSPF
set mtu 1436
next
edit R2_OSPF
set mtu 1436
next
end
end
5. Repeat all the previous steps of this exercise for the Remote FortiGate device.
For the OSPF configuration (Router > Dynamic > OSPF) on the Remote FortiGate device,
enter the Router ID of 0.0.0.2. Click Apply before continuing
Use the following values for the IPSec interface addresses:
Interface Names
IP
Remote IP
Student_1
172.16.2.1
172.16.1.1
Student_2
172.16.2.2
172.16.1.2
Use the following values for the OSPF configuration:

Areas
Click Create New to define an area with an IP address of 0.0.0.0. Accept the defaults for
the remaining parameters.
Networks
Click Create New to define the internal subnet for the OSPF networks. Set the IP/Netmask
value to 10.0.2.0/24. Leave the Area value as the default of 0.0.0.0.
Repeat this step to add the IPSec interface subnet of 172.16.0.0/12.
Interfaces
Click Create New to create new OSPF interfaces for the two IPSec interfaces with the values
from the chart below:
Interface Names
Interface
IP
Cost
S1_OSPF
Student_1
172.16.2.1
10
S2_OSPF
Student_2
172.16.2.2
20
P a g e | 51
01-50003-0301-20131018-D
6. Next enter the following CLI commands:

config router ospf
edit S1_OSPF
set mtu 1436
next
edit S2_OSPF
set mtu 1436
next
end
end
P a g e | 52
01-50003-0301-20131018-D
In this exercise, you will run the commands given from the Student FortiGate device, however note
that they can also be used on the Remote FortiGate device with equal effect.
1. At this point each student should have two active tunnels. On the Student FortiGate device,
go to VPN > Monitor > IPSec Monitor and verify that the status of the displayed tunnels is UP.
The IPSec VPNs can also be viewed using the following CLI command:
diag vpn tunnel list
2. After a few minutes, the OSPF routes should appear in Router > Monitor > Routing Monitor.
The OSPF routes can also be viewed using the following CLI command :
get router info routing-table ospf
3. Check the OSPF adjacencies and LSAs in the routing table by typing the following CLI
command:
get router info ospf neighbor
Sample output:
OSPF process 0:
Neighbor ID
Pri
State
Address
Interface
0.0.0.2
Full/- 00:00:34
Dead Time
172.16.2.1
Remote_1
0.0.0.2
Full/- 00:00:36
172.16.2.2
Remote_2
4. Type the following CLI command to display all the learned networks:
get router info ospf database router lsa
5. Type the following CLI command to display all the routes learned by OSPF
Sample output:
0 10.0.2.0/24 [110/11] via 172.16.2.1, Remote_1, 00:00:14
6. From the DOS prompt on the Windows Server confirm that the following IP addresses in the
Remote environment can be successfully pinged:
ping 10.0.2.10
ping 10.0.2.254
7. On the Student FortiGate device, set the administrative status for the port1 interface to
DOWN (or from the Linux host enter: ifconfig eth3 down). This will cause a new path to
be selected.
P a g e | 53
01-50003-0301-20131018-D
8. Check the session failover display for all the routes learned by OSPF by running the
following from the CLI:
Sample output:
0 10.0.2.0/24 [110/11] via 172.16.2.2, Remote_2, 00:00:14
9. Clear any active filters with the following CLI command:
diag sys session filter clear
10. Define a new filter with the following command:
diag sys session filter dst 10.0.2.10
11. Run the following command to display the matching sessions:
Sample output:
session info: proto=1 proto_state=00 duration=15 expire=56 timeout=0
flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 hakey=788
policy_dir=0 tunnel=Remote_2/
state=may_dirty rem
statistic(bytes/packets/allow_err): org=240/4/1 reply=120/2/1
tuples=2
gwy=172.16.2.2/10.0.1.10
hook=pre dir=org act=noop 10.0.1.10:768->10.0.2.10:8(0.0.0.0:0)
hook=post dir=reply act=noop 10.0.2.10:768->10.0.1.10:0(0.0.0.0:0)
serial=000073d6 tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_rule_id=0
total session 1
12. Important: Before proceeding, change the administrative status for the port1 interface on the
Student FortiGate device back to UP (or from the Linux host enter: ifconfig eth3
down).
P a g e | 54
01-50003-0301-20131018-D
1. For faster failover, BFD can be implemented. Enable BFD by entering the following CLI
commands on the Student FortiGate device:
config sys settings
set bfd enable
end
2. Enable BFD on the IPSec interfaces by entering the following CLI commands:
config sys interface
edit Remote_1
set bfd enable
next
edit Remote_2
set bfd enable
next
end
3. Enable BFD on the OSPF interfaces, by entering the following CLI commands:
config router ospf
set bfd enable
edit R1_OSPF
set bfd enable
next
edit R2_OSPF
set bfd enable
end
end
P a g e | 55
01-50003-0301-20131018-D
4. Repeat the previous steps of this exercise on the Remote FortiGate device.
5. To display the BFD neighbors, enter the following CLI command in the root VDOM:
get router info bfd neighbor
There should be two BFD neighbors with a status of UP.
6. Test failover and failback by running continuous pings. You should observer fewer ping
failures with this protocol enabled.
P a g e | 56
01-50003-0301-20131018-D
Module 15 Lab 2: IPSec VPN with FortiClient Exercise 1
In this lab, an IPSec VPN will be created between the Student FortiGate unit and the FortiClient
installation on a Windows XP host in the Remote environment.
Configure an IPSec VPN between the Student FortiGate unit and FortiClient Connect
P a g e | 57
01-50003-0301-20131018-D
following configuration file: Resources\Module15\Student\student-ipsec3.conf.
configuration file: Resources\Module15\Remote\remote-ipsec3.conf.
2. On the Student FortiGate device, go to VPN > IPSec > Auto Key (IKE) and click Create
FortiClient VPN.
Configure a new FortiClient VPN using the following details:
Name:
FClient
Local Outgoing Interface:
port1
Authenticated Method:
Pre-shared Key
Pre-Shared Key:
fortinet
User Group:
training
Address Range Start IP:
172.20.1.1
Address Range End IP:
172.20.1.5
Subnet Mask:
255.255.255.0
Enable IPv4 Split Tunnel:
STUDENT_INTERNAL
DNS Server:
Use System DNS
Create the following Firewall Address object for the VPN clients:
Address Name:
VPN-CLIENTS
Type:
IP Range
Subnet/IP Range:
172.20.1.1-172.20.1.5
Interface:
FClient
P a g e | 58
01-50003-0301-20131018-D
3. On the Student FortiGate device, go to Policy > Policy > Policy and create a FClientport3
policy to allow inbound connections with the following details:
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
FClient
Source Address:
VPN-CLIENTS
Outgoing Interface:
port3
STUDENT_INTERNAL
Schedule:
always
Service:
ALL
Action:
ACCEPT
4. Create a port3 FClient policy to allow outbound connections with the following details:
Policy Type:
Firewall
Policy Subtype:
Address
Incoming Interface:
port3
Source Address:
STUDENT_INTERNAL
Outgoing Interface:
FClient
VPN-CLIENTS
Schedule:
always
Service:
ALL
Action:
ACCEPT
5. Go to Router > Static > Static Route and create a new static route with the following details:
172.20.1.0/24
Device:
FClient
P a g e | 59
01-50003-0301-20131018-D
1. Connect to the console of the external Windows host. (In the virtual lab applet, go to
Operations > Connect to Secondary > WinXP. The virtual Windows XP device desktop will
be displayed.)
2. In the FortiClient console, go to Remote Access and Configure VPN.
3. Add a new configuration with the following details:
Configuration Name:
FC_VPN
Type
IPSec VPN
Description:
Student FortiGate
Remote Gateway:
10.200.1.1
Authentication Method:
Preshared Key
Preshared Key:
fortinet
Authentication (XAuth):
Save Login
Username:
student
P a g e | 60
01-50003-0301-20131018-D
1. In Remote Access of the FortiClient console, select the FC_VPN, enter the password
F0rtinet for student and click Connect.
If using the hosted virtual lab the connection to the host console is affected by the routing
change: In the virtual lab applet in the WinXP image, go to Operations > Disconnect. After a
few moments, return to the Operations menu and click Connect to Secondary > WinXP to
return to the Windows XP device.
2. Within a few moments, the external Windows host device should receive an IP address
within the 172.20.1.1 - 172.20.1.5 range identified on the DHCP server on the
FortiGate unit at the other end of the IPSec VPN tunnel. Use the following command in the
DOS Command Prompt on the Windows host device to confirm this:
ipconfig /all
3. Enter the following command in the DOS Command Prompt on the Windows host to display
the routing table information.
route print
Locate the 10.0.1.0/24 network entry in the output.
4. From the Windows host, attempt to ping both the Windows Server (10.0.1.10) and the
port3 interface of the FortiGate device (10.0.1.254).
5. Return to the Windows Server device and attempt to ping the virtual Windows host running
FortiClient (172.20.1.1).
6. On the Student FortiGate device go to Router > Monitor > Routing Monitor and locate the
static route for the FortiClient installation on the external Windows host.
7. Next go to VPN > Monitor > IPSec Monitor to view the details of the FClient-0 VPN
connection.
Alternately use the following CLI command in the root VDOM:
diag vpn tunnel list
8. On the Student FortiGate device, go to VPN > Monitor > IPSec Monitor. Note the Proxy ID
Destination. On the external Windows host go to the IPSec VPN Connections window of the
FortiClient Connect console and click Disconnect.
P a g e | 61
01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System
The aim of this lab is for students to set up DoS policies and IPS profiles on their FortiGate devices.
Packet crafter software will be used to attempt to flood one of the FortiGate units and the resulting
log entries will be examined on both units.
Configure DoS policies and IPS profiles

Read and interpret Attack log entries
Execute diagnostics commands and interpret output
P a g e | 62
01-50003-0301-20131018-D
Module 16 Lab 1: Intrusion Prevention System Exercise 1
following configuration file: Resources\Module16\Student\student-ips.conf
2. On the Student FortiGate device, go to Security Profiles > Intrusion Protection > IPS
Signatures to view the installed signatures. Click the signature name link to view more
information about the signature from the Fortinet web site.
Protocol decoders are used as part of signature matching. HTTP decoder ports are
automatically detected; IPS detects HTTP at the application layer and does not rely on the
TCP port number.
3. Next go to Security Profiles > Intrusion Protection > IPS Sensor and click the plus sign (+) in
the upper-right corner of the Edit IPS Sensor window to create a new sensor. Set the Name
for the new sensor to LINUX_SERVER and click OK.
4. In the Edit IPS Sensor window, click Create New and configure a new IPS filter with the
following settings:
Sensor Type:
Filter Based
Severity:
All
Target:
server
OS:
Linux
Action:
Signature Defaults
Packet Logging:
Enabled
5. On the Student FortiGate device, edit the ALL services port3 port1 firewall policy. Under
Security Profiles, set IPS to ON and select LINUX_SERVER from the drop-down list.
6. From a command prompt on the virtual Windows Server, change directory to the
Resources\Module16\nikto-2.1.5 folder as follows:
C:> cd \
C:> cd Documents and Settings\Administrator\Desktop\\Module16\nikto2.1.5
7. Next run the following command:
nikto.pl -host 10.200.1.254
The test will stop by itself once it has finished.
You can use CTRL+C to stop the utility.
P a g e | 63
01-50003-0301-20131018-D
8. On the Student FortiGate device, go to Log & Report > Security Log > Intrusion Protection
and locate the multiple entries for the attacks generated by the nikto utility.
If the exploits are not logged, verify the following items:
Is the LINUX_SERVER IPS sensor selected in the policy?
Is the traffic matching the correct policy?
If none of these items apply, please discuss this further with your instructor.
9. In the log display window, right-click any of the column titles to display Column Settings and
add the Status field to the display. Move this column accordingly for easier viewing.
Look at the Status field of the log entries and note that for some of the attacks discovered by
this sensor, the Status value appears as detected. This indicates that a signature was
matched and that the traffic was allowed to pass.
In the spaces below, record the names for two of the detected signatures. The signature
name appears in the Message column of the log.
Signature 1:
____________________________________
Signature 2:
____________________________________
10. You will now modify the IPS sensor and change the action for these two signatures to Block.
Go to UTM Security Profiles > Intrusion Protection > IPS Sensor and edit the
LINUX_SERVER sensor.
Create a new filter and set the Type to Specify Signatures. Click in the search field located
on the left-hand side of the window (close to the top) and enter the name the first signature
identified in the previous step.
Select the signature.
Set the Action to Block All and enable Packet Logging.
Repeat this procedure for the second signature name recorded earlier.
11. Move the newly created signatures before the Default filter in the IPS filter list using drag &
drop.
12. From a command prompt on the Windows Server, run the vulnerability scan again by
executing the following command::
nikto.pl -host 10.200.1.254
13. Now examine the log entries again. Go to Log & Report > Security Log > Intrusion Protection
and locate the log messages which should indicate that the attacks were blocked. The Status
field should indicate a status of dropped which includes any of the following actions:
dropped packet, dropped session or cleared session.
P a g e | 64
01-50003-0301-20131018-D
In this exercise, DoS policies will be used to test basic flood protection on the network.
1. On the Student FortiGate device, go to Policy > Policy > DoS Policy and edit the displayed
DoS policy. Configure the following settings:
Incoming Interface:
port1
Source Address:
all
all
Service:
ALL
Anomalies:
set the Threshold for icmp_flood to 200.
Status
enable
Logging
enable
Action:
Block
2. Open an SSH connection and login to the Linux host. Enter the username root with a
password of password.
Run the ping command with the flood option against the external server using the following
syntax:
ping -f 10.200.1.200
The command options used here will cause the ping utility to run continuously and not wait
for replies between ICMP echo requests.
Some pings will be blocked as 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.
3. Go to Log & Report > Security Log > Intrusion Protection and examine the logs. Note that the
ICMP flood has been blocked; this is indicated by the Status field entry clear_session.
P a g e | 65
01-50003-0301-20131018-D
4. From the CLI on the Student FortiGate device, run the following diag command to 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.
5. To demonstrate policy ordering we will now create a second DoS policy that allows the
previously blocked traffic. This time, the Service parameter will be set to ICMP to make this
policy more specialized than the first one you created.
Go to Policy > Policy > DoS Policy and click Create New. Configure the following settings:
Incoming Interface:
port1
Source Address:
all
all
Service:
ALL_ICMP
Anomalies:
set the Threshold for icmp_flood to 200.
Status
enable
Logging
enable
Action:
Pass
6. Return to the window running an SSH connection to the Linux host.

You should observe that the result is the same as before. Excess traffic is being blocked at
the same frequency. Examine the logs and note the same attack log message as before.
7. From the CLI examine the anomaly counters using the following command:
Sample output:
list nids meter:
The PPS stops at the same value, since the more specific DoS sensor is applied after the
general sensor.
8. Use drag & drop to re-order the DOS policies so that the ALL_ICMP policy with the action
Pass is first.
P a g e | 66
01-50003-0301-20131018-D
9. Ensure the ping test is still running and examine the anomaly counters again as follows:
Sample output:
list nids meter:
Note that pings are no longer blocked at the same rate and the anomaly counters for the
PPS are much higher than the previous value but less than the configured threshold; the
traffic is allowed. You can also observe this from the logs. The entries will appear similar to
the following. Modify the Column-Settings to list the Sensor field. This displays the sensor
that was applied. You should also observe that the periods have stopped printing on the
console as the packets are no longer dropped.
This test uses a simple example of ICMP. When enabling DoS protection in your network, be
careful not to block traffic from servers that generate high amounts of traffic, such as DNS,
mail, or web proxy. By creating different sensors with different thresholds, DoS protection can
be optimized for any network.
P a g e | 67
01-50003-0301-20131018-D
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 device, go to Security Profiles > Intrusion Protection > IPS
Signatures and click Create New. Enter the name ftp_get for the new custom signature and
type the following string in the Signature field:
F-SBID( --protocol tcp; --dst_port 21; --flow from_client; --pattern RETR;)
2. On the Student FortiGate device, go to UTM Security Profiles > Intrusion Protection > IPS
Sensor and edit the LINUX_SERVER sensor created earlier. Create a new filter and set the
Sensor Type to Specify Signatures. Click the ftp_get signature created in the previous step
and set the Action to Reset and enable Packet Logging.
Move this filter to the top of the list.
3. On the Student FortiGate device, enter the following CLI command to trace the session:
diagnose sniffer packet any port 21 4
4. From a command prompt on the Windows Server, open a connection to the FTP server listed
below. Log in as an anonymous user:
10.200.1.254
Change to the /pub folder and use the GET command to retrieve the file called test.text.
For example, in a command prompt window enter the following commands:
ftp
open 10.200.1.254
<Enter the username of anonymous with a blank password when prompted>
ftp> cd pub
ftp> get test.text
5. The connection to the remote host should be closed.
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:
P a g e | 68
01-50003-0301-20131018-D
Module 17 Lab 1: Fortinet Single Sign On
In this lab, Fortinet Single Sign On will be configured to allow the FortiGate unit to collect
authentication information from Windows Active Directory. Once a user logs into a Windows domain,
they will not be required to perform any further authentication operations to access protected web
resources.
Install software on Windows systems

Identify the differences between Normal and Polling mode operation
Understand communications (mechanics, ports etc.)
Configure groups
Enable and utilize NLTM
Monitor, Diagnose and Troubleshoot FSSO
P a g e | 69
01-50003-0301-20131018-D
Module 17 Lab 1: Fortinet Single Sign On Exercise 1
following configuration file: Resources\Module17\Student\Student-sso.conf
2. On the Windows Server, double-click the Fortinet Single Sign On installation file located in
Resources\Module17, and click Run to launch the Fortinet Single Sign On Agent Installation
Wizard.
Proceed though the wizard to install the agent on the Windows Server.
3. When prompted for the Windows Server Administrator account password to use to run the
service, enter password. Click Next.
4. In the Install Options window, accept the default settings and click Next.
5. Click Install to complete the installation.
6. 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 Single Sign On Agent Installation. This launches the Domain
Controller Agent Installation Wizard.
7. 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.
8. Select the TRAININGAD:trainingAD.training.lab domain to monitor. Click Next.
9. 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.
10. Set the Working Mode to Polling Mode and Check Windows Security Event Logs. Click Next.
P a g e | 70
01-50003-0301-20131018-D
11. In the virtual Windows Server, click Start > All Programs > Fortinet > Fortinet Single Sign On
Agent > Configure Fortinet Single Sign On Agent.
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 communication between the Collector Agent and
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 the check box
for Users. Click Add, then OK and OK.
12. Click Save&close to close the Fortinet Single Sign On Agent Configuration window.
P a g e | 71
01-50003-0301-20131018-D
1. On the Student FortiGate device, go to User & Device > Authentication > Single Sign-On and
create a new entry with the following 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.
2. Enter the following CLI commands to monitor communications between the FSSO Collector
Agent and the FortiGate unit:
diag debug en
diag debug application auth 8256
Return to this output after you have tested the configuration.
3. On the Student FortiGate device, go to User & Device > User > User Group and create a
new user group with the following details:
Name:
Training
Type:
Fortinet Single Sign On (FSSO)
Add TRAININGAD/USERS as members to the group.

4. Edit the port3 port1 firewall policy for ANY and set the Policy Subtype to User Identity.
Create a new authentication rule using the following settings:
All
Group(s):
Training
Schedule:
Always
Service:
ALL
Log Options:
Log Security Events
P a g e | 72
01-50003-0301-20131018-D
1. On the Windows Server, click Start > Run and enter the program name of mstsc.exe to
launch Windows Remote Desktop.
2. Enter the remote computer IP address of 10.0.1.10 and log in with the following
credentials:
Username:
student
Password:
Fort1net
3. From a web browser on the Windows Server, attempt to connect to a web site. You should
be able to access the web site without being prompted for user authentication.
4. Observe the output from the diag command still running in the CLI.
5. Type the CLI commands shown below to display which users re currently logged on using
FSSO:
diag debug application auth 0
diag debug authd fsso list
Review the debug output. Note that you may see two IP address for user student because
this host has two NICs.
P a g e | 73
01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations
The aim of this lab is for students to lay the ground work for all SSL-based inspection that a
FortiGate unit is capable of performing. Students learn the details of how inspection is performed
and the encryption functions used. In addition, the certificate is examined to understand its general
layout and contents.
Create different certificate signing requests (CSRs)

Use OpenSSL for certification signing requests
Load signed certificates into the FortiGate unit and configure them for various purposes including
administrative use (GUI access) SSLVPN and deep inspection
Identify what a certificate can be used for
P a g e | 74
01-50003-0301-20131018-D
Module 18 Lab 1: Certificate Operations Exercise 1
This lab was designed and tested using Firefox. Each browser, while accomplishing the same objective,
has a different method of configuration. Instructions are provided for doing specific steps using Firefox
only. If you select another browser you will need to accomplish the same things, and instructions are not
provided.
Note: The steps for creating certificates vary depending on the software that is
used. OpenSSL is a free open source application and not endorsed by Fortinet
Technologies in any way. This software has been pre-installed and configured to
operate according to the lab requirements. This is NOT a standard set-up.
1. On the Windows 2003 Server open a command line window and change to a directory where
you can save and load files from.
Notice: You can choose to work in any directory, but Firefox defaults to downloading
files into the downloads directory. You can access this directory by typing:
CD My Documents\downloads
2. Type CREATECA and follow the on screen prompts

Use the name NewCA for the certificate that you are creating.
Note: You will be prompted to enter details regarding the signing authority. Enter
whatever information you desire, so long as it is valid for that field (for example: an
email is: x@x.x).
Several files will be created automatically by this utility. A certificate file (.CRT) a
key file (.key) and a text file that contains the password you used (.pass)
3. Connect to the GUI on the Student FortiGate device 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 may leave all the other fields blank however in recommended best practices, these fields
should be populated.
Note: If Certificates do not appear in the GUI as an option, check the administrator
settings and enable the option to make them display.
This certificate will be used in place of the administrative GUI. In order to avoid a
certificate warning the Subject Information must be set correctly.
P a g e | 75
01-50003-0301-20131018-D
Once created, the certificate will display in the GUI showing a status of PENDING. Select the
certificate and download it to the folder used in step 2.
4. From the command prompt type SIGNCSR and follow the on screen prompts to sign the
certificate request. When prompted for filenames do not enter the file extension.
Note: If you forget what the password you used to create this new Certificate
Authority was, open the .PASS file in a text editor and it will show you. This file
was created automatically during step 2.
5. On the Student FortiGate device, select the pending certificate request and IMPORT the
Local CRT file that was just created.
6. Connect to the GUI on the Student FortiGate device using HTTPS as follows:
https://10.0.1.254
There will be a warning message in the browser. Check the technical details and observe
that there is an error with the issuer chain (the CA is not trusted), AND the certificate is not
valid for this location. Or click on the padlock icon to see the security exception added earlier.
7. From the CLI on the Student FortiGate device, enter the following to configure the
management GUI to use the new certificate.
conf sys global
set admin-server-cert MyCert
end
Note: The certificate name must match EXACTLY. Use the ? to view the list of
available certificates. If the name contains a space, put the certificate name in
single quotations.
8. Connect to the GUI on the Student FortiGate device using HTTPS as follows:
https://10.0.1.254
There will still be a server warning message. Check the technical details and observe that
the only error is with the issuer chain (the CA is not trusted) but the certificate is valid for that
location (assuming you used the correct IP when creating the request).
Note: The behavior change will be immediate but your browser may use local
cached information. If you still see the old certificate, be sure to clear out your
browsers cache and then refresh the page.
Since the authority that signed the certificate is not public, the browser cannot find
any information about it in the certificate repository. Just like the original certificate
it is still perfectly valid but for security purposes the browser will give you a
warning.
P a g e | 76
01-50003-0301-20131018-D
1. On the Student FortiGate device, go to the Local Certificates section and select the import
option. Change the dropdown selection from Local Certificate to Certificate.
2. You will be prompted for the following: a certificate file, a key file, and a password.
Note: If you forget what the password you used to create this new
Certificate Authority was, open the .PASS file in a text editor to find out
what you used. It was created automatically with the CREATECA utility.
Browse to the files and information you created in step 2 of Exercise 1. These files are
named: NewCA.crt and NewCA.key .
Select the imported certificate and view the certificate detail.
P a g e | 77
01-50003-0301-20131018-D
3. From the GUI on the Student FortiGate device go to Policy > Policy > SSL/SSH Inspection
Options, and select the default profile. Enable HTTPS deep inspection as follows:
P a g e | 78
01-50003-0301-20131018-D
4. Next go to UTM Security Profiles > Antivirus > Profile, and select the default profile. Confirm
HTTP virus scanning is enabled as follows:
Modify the outbound firewall policy and enable the default antivirus profile and enable SSL
inspection.
.
5. Open a new web browser window or tab and clear the recent browsing history. Next, connect
to the web site:
https://support.fortinet.com/
Make note of the certificate details and leave this window open.
Note: You should be presented with a self signed certificate warning that shows a
certificate signed by Fortinet. Otherwise try flushing out the browsers cache and
make sure the profiles are properly enabled on the correct Firewall policy.
P a g e | 79
01-50003-0301-20131018-D
6. On the Student FortiGate unit, change the SSL decryption certificate to the one that was
loaded in the earlier step. Edit the SSL/SSH Inspection Options profile and set the CA
(Certificate Authority) Certificate to use the file loaded in step 2 (NewCA).
7. Open a new web browser window or tab and connect to the web site:
https://support.fortinet.com/
You will still get an error because the certificate signer is unknown. Make note of the
certificate details and compare with the certificates in the other window for the same URL.
Visit some additional HTTPS web sites and examine the certificates.
Note: In order to get rid of the self signed certificate warning you will need to load
the certificate used by the SSL Proxy into the browsers root certificate repository.
To add the CA cert to the Firefox browsers certificate repository go to Tools > Options >
Advanced > Encryption > View Certificates. Import the NewCA certificate (created in step 2
of exercise 1) on the Authority tab and allow it to identify websites.
P a g e | 80
01-50003-0301-20131018-D
8. Reload the web page: https://support.fortinet.com. The certificate is now trusted

and no warning messages appear.
Note: Since the authority you created in exercise 1 is now known by the browser
you can also access the GUI of the FortiGate device without any warning at this
point. The certificate is valid for the destination you are visiting (assuming you
entered the correct IP information in the request) and the organization that signed
it is now in the browsers list of known Certificate Authorities.
FortiGate units have multiple interfaces. In NAT mode each one has a different IP
address so you need to either setup DNS so you can access the FortiGate device
by name (and use a hostname in your certificate), or create a certificate that is
valid for multiple IP addresses.
Separate browsers use separate certificate repositories. This means that custom
CAs must be loaded into them independently.
P a g e | 81
01-50003-0301-20131018-D
Module 19 Lab 1: Data Leak Prevention
This lab will demonstrate how to use data leak prevention rules and sensors to block the
transmission of sensitive data outside the network.
Configure DLP to block encrypted files, the leakage of credit card information and oversize files
Set up DLP banning and quarantining
Configure DLP Fingerprinting
Read and interpret DLP log entries
P a g e | 82
01-50003-0301-20131018-D
Module 19 Lab 1: Data Leak Prevention Exercise 1
1. Select Security Profiles > Data Leak Prevention > File Filter and review the file filter called
all_executables
1.
Notice: Using a file name of *.exe is also possible. The obvious weakness however,
is changing the filename to something like *.ex1, or *.txt. File type identification works
by examining the layout of the file. Not all file types has a strict design so many
cannot be identified in this fashion.
2. From the GUI on the Student FortiGate device, go to Security Profiles > Data Leak
Prevention > Sensor. Create a sensor called Training (Click Create New in the upper righthand corner of the Edit DLP Sensor window.)
3. In the Edit DLP Sensor window, create a new rule that uses the default file filter
all_executables with the following settings:
Filter:
Files
File type included in:
all_executables
Examine the Following services:
HTTP
Action:
Block
4. Go to Policy > Policy > Policy and edit the

sensor called Training.
firewall to enable the DLP
5. To test the DLP sensor, an executable file must be sent using HTTP.
In a web browser on the virtual Windows Server, connect to the following URL:
http://www.sendspace.com
6. On the sendspace web page, click Browse and locate the putty.exe executable file on the
desktop of the virtual Windows 2003 Server.
Enter the email address of a recipient along with your own email address in the appropriate
fields then click Upload.
7. From the GUI on the Student FortiGate device, locate the Forward Traffic log and locate
entry with a blocking security action for this attempted data leak. .
P a g e | 83
01-50003-0301-20131018-D
8. Right-click the putty.exe file and select Add to putty.7z to save it as a .7z compressed file
type.
9. Return to the sendspace web page and attempt to transfer the zipped file putty.7z. The file
will be blocked.
10. Check the log events generated by the sensor for this blocked transfer.
11. Right-click the putty.exe file again and select Add to archive to save it as a .7z compressed
file type.
P a g e | 84
01-50003-0301-20131018-D
Rename the archive to putty-password.7z and set the archive password to: test.
12. Return to the sendspace web page and attempt to transfer the encrypted zipped file puttypassword.7z. The file will be transmitted successfully.
Note: Password protected archives cannot have their contents scanned or be
identified by file type only by pattern (name).
13. Edit the sensor Training and add a second filer to block encrypted files. Note this filter will
match all encrypted files and not just encrypted executables.
Filter:
Files
Encrypted
Enable
HTTP
Action:
Block
14. Return to the sendspace web page and attempt to transfer the encrypted zipped file puttypassword.7z. This time the file will be blocked.
P a g e | 85
01-50003-0301-20131018-D
1. Create a new DLP filter in the Training DLP sensor with the following details:
Filter:
Files
Containing:
Credit Card #
HTTP
Action:
Block
Notice: This can be done for different CC types individually (you can find regular
expressions for them on the internet). Hard coding the patterns allows for much faster
detection. The patterns detectable are Visa, Mastercard or American Express, Diners
Club, Discover, JOB
2. In a web browser on the virtual Windows Server, connect to the following URL:
http://www.sendspace.com
3. On the sendspace web page, click Browse and locate the creditcards.txt file in
Resources\Module19.
Enter the email address of a recipient along with your own email address in the appropriate
fields then click Upload.
The file will appear to upload, then a DLP warning message will get displayed (or a reset if
flow based inspection was used).
4. Edit the Training DLP sensor and change the action for the credit card file filter to Quratine
IP,On the sendspace.com web site, attempt to send the creditcard.txt file once again. The file
download will be blocked.
Notice: If you try to visit other web sites now you will be blocked and a replacement
message appears with a block message.
5. From the GUI on the Student FortiGate device, go to User & Device > Monitor > Banned
User and locate the banned entry in the list.
6. Select and delete the banned entry.
P a g e | 86
01-50003-0301-20131018-D
This exercise demonstrates how to work with document finger printing.

1. Back up the configuration of the Student FortiGate device and save it to the Windows 2003
Server desktop.
2. From the GUI on the Student FortiGate device, go to Security Profiles > Data Leak
Prevention > Document Fingerprinting. In the Manual Document Fingerprints section, upload
a new document to fingerprint.
Click Create New and locate the configuration file on the Windows 2003 Server that you
created in step 1.
Set the Sensitivity Level to Critical.
3. Create a new DLP filter in the Training DLP sensor with the following details:
Filter:
Files
File Finger Print:
Critical
Examine the Following Services:
HTTP
Action:
Block
Click OK to save the change to the filter and click Apply to save the change to the sensor.
4. On the sendspace.com web site, attempt to send the configuration file. The file download will
be blocked.
5. Open the configuration file in a text editor that can handle word wrap (for example, Notepad)
and make some changes to the configuration and save them.
6. On the sendspace.com web site, attempt to send the configuration file again. The file
download will most likely be blocked (depending on the number of changes that were made).
Notice: Fingerprinting breaks the file into chunks and does rolling checksums on each
part. Changes in one section do not affect all checksums. The default settings allow
for a single chunk checksum to trigger a match.
P a g e | 87
01-50003-0301-20131018-D
Module 21 Lab 1: Case Study Scenario
The aim of this lab is to introduce students to working with multiple FortiGate device features at once
to implement a solution based on customer needs.
Fulfill the customers requirements for the installation, based on the supplied description.
School KIDZ will be replacing the exterior firewall with a FortiGate device
As a school, one of the top priorities is to prevent students from viewing/accessing
inappropriate material on the Internet
Virus scanning is also needed, as is protection from hacking attempts. These functions
will need to be integrated with the schools current Active Directory system and must
provide separate access for students and teachers
The school also wants to ensure that the students are not permitted to run inappropriate
software of any kind, similar to Cabos.
The firewall must not cause any noticeable or significant delays.
The school currently has an internal exchange server for email which also needs
protection. Ideally the solution should be redundant.
Key Aspect/Features of Installation: 18
Optional Features: 3
P a g e | 88
01-50003-0301-20131018-D
Appendix A
1. Fortinet Documentation: http://docs.fortinet.com

The documentation web site contains all Fortinet manuals, white papers and guides for
Fortinet products.
2. Fortinet Knowledge Base: http://kb.fortinet.com
This site is useful for finding working examples and tips for Fortinet products.
3. Fortinet Web Site: http://www.fortinet.com
The Fortinet web site contains all hardware and product specifications.
4. FortiGuard Web Site: http://www.fortiguard.com
This site is suitable for finding information about the FortiGuard Subscription Services.
5. FortiCare Web Site: https://support.fortinet.com
The FortiCare web site is used to interface with Fortinet support, register devices you have
purchased and download firmware updates.
6. Fortinet User Forums: http://support.fortinet.com/forum/
These are user-led and run forums that discuss many different topics surrounding the use of
Fortinet devices.
P a g e | 89
01-50003-0301-20131018-D

Fortigate

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fortigate

Uploaded by

Copyright:

Available Formats

FortiGate Multi-Threat Security Systems II

Secured Network Deployment and IPSec VPN

FortiGate Multi-Threat Security Systems

VIRTUAL LAB ENVIRONMENT BASICS ............................................................................... 3

CLASSROOM LAB CONFIGURATION .................................................................................. 8

Lab 2: IPSec VPN with FortiClient ............................................................................................................................. 57

APPENDIX A: ADDITIONAL RESOURCES........................................................................... 89

Virtual Lab Environment Basics

Virtual Lab Environment Basics

Virtual Lab Environment Basics

Virtual Lab Environment Basics

Virtual Lab Environment Basics

Classroom Lab Configuration

Module 11 Lab 1: Router Configuration and Troubleshooting

Students will complete the following tasks:

Estimated time to complete this lab: 50 minutes

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1

Now connect to an external web site and observe the output.

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1

A sample debug flow output is provided below with notes:

STUDENT # id=13 trace_id=21 func=resolve_ip_tuple_fast line=4048

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 1

id=13 trace_id=22 func=__ip_session_run_tuple line=2304 msg="DNAT

id=13 trace_id=23 func=ipv4_fast_cb line=50 msg="enter fast path"

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 2

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 2

3. Again, from the Student FortiGate device run a packet sniffer:

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 3

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 3

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 3

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 3

From: 443 To: 443

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 4

Click Add / Edit.

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 4

Click Add / Edit.

Module 11 Lab 1: Router Configuration and Troubleshooting Exercsie 4

Module 12 Lab 1: Virtual Networking

Configure and test VDOMs

Estimated time to complete this lab: 45 minutes

Module 12 Lab 1: Virtual Networking Exercise 1

Module 12 Lab 1: Virtual Networking Exercise 1

Module 12 Lab 1: Virtual Networking Exercise 1

HTTPS, PING, SSH

HTTPS, PING, SSH

Module 12 Lab 1: Virtual Networking Exercise 1

Module 12 Lab 1: Virtual Networking Exercise 1

Module 13 Lab 1: Transparent Mode VDOMs

Configure two transparent mode VDOMs

Estimated time to complete this lab: 45 minutes

Module 13 Lab 1: Transparent Mode VDOMs Exercise 1

Module 13 Lab 1: Transparent Mode VDOMs Exercise 2

1. Enter the following CLI commands to create an inter-vdom link:

Module 13 Lab 1: Transparent Mode VDOMs Exercise 2

Log all sessions

Module 13 Lab 1: Transparent Mode VDOMs Exercise 2

Module 14 Lab 1: High Availability

Set up an HA cluster using FortiGate devices in the student environment

Estimated time to complete this lab: 45 minutes

Module 14 Lab 1: High Availability HA Lab Topology

Module 14 Lab 1: High Availability Exercise 1