Enterprise Firewall 7.6 Administrator Lab Guide
Enterprise Firewall 7.6 Administrator Lab Guide
com
DO NOT REPRINT
© FORTINET
https://training.fortinet.com
https://docs.fortinet.com
https://kb.fortinet.com
https://fusecommunity.fortinet.com/home
Fortinet Forums
https://forum.fortinet.com
https://support.fortinet.com
FortiGuard Labs
https://www.fortiguard.com
https://www.fortinet.com/nse-training
https://home.pearsonvue.com/fortinet
https://helpdesk.training.fortinet.com/support/home
5/12/2025
Brave-Dumps.com
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
Firmware Version 7
Network Topology 8
Lab Device Credentials 9
Lab 1: Network Security Architecture 10
Lab 2: Central Management 11
Exercise 1: Running Remote, Device, and Policy Scripts 12
Network Topology 12
Run a Script Using the Remote Method 12
Run a Script Using the Device Database Method 16
Run a Script Using the Policy Package or ADOM Database Method 19
Exercise 2: Configuring LTP 22
Network Topology 22
Configure the Metadata Variables 22
Add Metadata Variables to the Pre-CLI Template 24
Add BR2-FGT-1 to FortiManager 26
Register BR2-FGT-1 on FortiManager 32
Add BR3-FGT-1 to FortiManager 34
Register BR3-FGT-1 on FortiManager 38
Lab 3: VLANs and VDOMs 41
Exercise 1: Configuring VDOMs and VLANs on ISFW 42
Network Topology 42
Enable VDOMs 42
Create the Zone1 and Zone2 VDOMs 43
Create VLAN101 and VLAN102 46
Create Inter-VDOM Links 49
Create Static Routes in VDOMs 53
Install Firewall Policies in VDOMs 55
Validate the Communication Between HQ-PC-2 and HQ-PC-3 58
Validate the Communication From HQ-PC-2 to HQ-Web-1, the Internet, and 4.2.2.2 60
Lab 4: High Availability 62
Exercise 1: Configuring VDOM Partitioning 63
Network Topology 63
Verify the HA Status 63
Brave-Dumps.com
DO NOT REPRINT
© FORTINET
Configure VDOM Partitioning 64
Analyze Traffic Distribution 67
Perform a Failover and Analyze the Traffic 68
Exercise 2: Configuring FGSP 71
Network Topology 71
Configure FGSP 71
Test ICMP Session Synchronization Between BR1-FGT-1 and BR1-FGT-2 72
Analyze the Asymmetric Traffic 74
Exercise 3: Encrypting the Session Synchronization 79
Encrypt the Session Synchronization 79
Lab 5: Dynamic Routing Protocols 82
Exercise 1: Configuring OSPF With ECMP 83
Configure OSPF on HQ-DCFW 83
Configure OSPF on HQ-ISFW 86
Configure OSPF on HQ-NGFW 89
Check the OSPF Status on the HQ-ISFW Root VDOM 92
Enable OSPF ECMP on the HQ-ISFW Root VDOM 95
Enable OSPF ECMP on HQ-NGFW 96
Verify OSPF ECMP 97
Check the OSPF Status on HQ-DCFW and HQ-NGFW 98
Check Connectivity 99
Exercise 2: Configuring BGP 100
Configure BGP on FortiManager 100
Exercise 3: Configuring a Loopback Interface as a BGP Source 108
Configure a Loopback Interface as a BGP Source on BR1-FGT-2 108
Establish the BGP connection 110
Lab 6: Security Profiles 112
Exercise 1: Solving an IPS False Positive 113
Apply the IPS_Block Security Profile 113
Install the Policy 114
Test Using hping to HQ-Web-1 115
Verify That HQ-DCFW Detects the Jumbo Packets 116
Solve the IPS False Positive 118
Install the Policy 119
Test Using hping to HQ-Web-1 119
Verify That HQ-DCFW Detects the Jumbo Packets 120
Exercise 2: Protecting Against Unencrypted Attacks 122
Apply the IPS_Monitor Security Profile 122
Install the Policy 123
Access the Website 124
Simulate the Attack 124
Brave-Dumps.com
DO NOT REPRINT
© FORTINET
Verify That HQ-DCFW Detects the Attack 125
Block an Attack on Unencrypted Traffic 126
Install the Policy 128
Simulate the Attack 128
Verify That HQ-DCFW Blocks the Attack 128
Exercise 3: Protecting Against Encrypted Attacks 131
Create a Dynamic Local Certificate and an SSL/SSH Profile 131
Block an Attack on Encrypted Traffic 133
Verify That HQ-DCFW Drops the Attack 134
Lab 7: IPsec VPN (IKEv2) 136
Exercise 1: Configuring IPsec Templates 137
Configure IPsec Templates 137
Create a Normalized Interface for the Hub 148
Configure the Firewall Policies 149
Check the Status of the VPN Tunnels 150
Delete the IPsec Tunnels 151
Lab 8: Auto-Discovery VPN 161
Exercise 1: Configuring ADVPN and IBGP 164
Configure IPsec Templates 164
Configure the BGP Templates 171
Install the Policies 175
Bring Up the On-Demand Tunnel 177
Exercise 2: Configuring ADVPN IBGP and EBGP 180
Prerequisites 180
Configure ADVPN IBGP and EBGP 181
Bring Up the On-Demand Tunnel 184
Lab 9: Security Fabric 188
Exercise 1: Configuring the Security Fabric and SAML SSO 189
Configure the Security Fabric on HQ-NGFW-1 189
Configure the Security Fabric on HQ-DCFW 191
Configure the Security Fabric on HQ-ISFW 193
Access Security Fabric Devices With SAML SSO 194
Exercise 2: Configuring Automatic Configuration Backup 199
Manage Security Fabric Devices on FortiManager 199
Configure an Automation on FortiManager 200
Verify the Stitch on the Security Fabric Devices 205
Exercise 3: Configuring the Automation With a Script 208
Configure the Automation 208
Test the Automation Stitch and View the Email Alert 211
Lab 10: Use Cases 215
Exercise 1: Configuring the HR Network 219
Brave-Dumps.com
DO NOT REPRINT
© FORTINET
Network Topology 219
Requirements 220
Test the Configuration 220
Exercise 2: Configuring ADVPN 222
Network Topology 222
Requirements 222
Test the Configuration 223
Exercise 3: Configuring Automatic Backups 226
Network Topology 226
Requirements 226
Test the Configuration 227
Brave-Dumps.com
DO Firmware
NOTVersion
REPRINT
© FORTINET
Firmware Version
The Enterprise Firewall course content is based on the following products and firmware versions:
FortiGate 7.6.2
FortiManager 7.6.2
FortiAnalyzer 7.6.2
Below are the credentials for all the devices used in the lab guide.
VM Username Password
FortiManager is one of the key pieces of an enterprise firewall solution. Without it, managing multiple FortiGate
devices would be cumbersome. Using FortiManager, you can centralize the management of all FortiGate devices
and create common security policies that multiple devices can easily share. In enterprise networks, FortiManager
ADOMs are used to organize your FortiGate devices into groups whose members all share similar security roles
and policies.
Objectives
l Run remote, device, and policy scripts
l Add BR2-FGT-1 and BR3-FGT-1 using the model device and pre-shared key method to deploy them as if you were
using the low-touch provisioning (LTP) model
Time to Complete
Estimated: 55 minutes
In this exercise, you will find the differences between running remote, device, and policy scripts.
Network Topology
You will create a local certificate using the remote FortiGate direct method (using the CLI).
© FORTINET
4. Select the ACME Certificate checkbox, and then click Run Script.
5. In the Available Entries field, select the HQ-DCFW checkbox, move it to the Selected Entries field, and then click
Run Now.
© FORTINET
6. In the Confirm Running Script window, click OK to confirm that you want to run the script.
After the configuration is applied directly to your FortiGate, for the purposes of this
learning experience, it is recommended that you verify the following configurations:
l FortiManager has triggered an automatic retrieval process to receive the
configuration from FortiGate.
l The FortiGate device database at the device layer has been updated with the
configuration.
You will have a better view of the HQ-DCFW objects that are available in the device layer if you enable the
vertical menu.
8. Click Device Manager > Device & Groups > Managed FortiGate > HQ-DCFW, and then click the Toggle
Vertical Menu icon.
9. Click Device Manager > Device & Groups > Managed FortiGate > HQ-DCFW > Dashboard > Summary.
10. In the Configuration and Installation widget, in the Revision section, in the Total Revision field, click the
Revision History icon.
You can see that the script_manager created the last event, which triggered a Retrieved operation.
© FORTINET
Next, you will enable the visibility of HQ-DCFW certificates, so you can check if the configuration has been
applied to the device database.
11. Click HQ-DCFW > Feature Visibility, and then select the Certificates checkbox.
© FORTINET
Stop and think!
At this point, the ACME certificate has been pushed to HQ-DCFW and its device database has been
updated without you having to manually install the database. FortiManager automatically triggers a retrieve
after it runs a remote script to update the database. This process is registered in the HQ-DCFW revision
history without affecting the status of the device database and policy layer (which were synchronized before
you ran the script).
You should avoid using the remote method to modify, delete, or create objects that are used in firewall
policies. Otherwise, you will trigger a conflict status in the policy layer. If you modify firewall objects using a
remote script, you should also make the same changes in the policy package that your firewall is using.
You should also log in to the HQ-DCFW GUI or CLI with read-only permissions and
validate that the certificate has been installed, so that you can compare this with the
scripts that you will be running next.
You will create a static route using the device database method.
5. In the Available Entries field, select the HQ-DCFW checkbox, move it to the Selected Entries field, and then click
Run Now.
© FORTINET
6. In the Confirm Running Script window, click OK to confirm that you want to run the script.
9. Click Managed FortiGate > HQ-DCFW > Network > Static Routes, and then verify that the static route is in the
HQ-DCFW device database.
© FORTINET
Stop and think!
At this time, you have not pushed any static routes to FortiGate. Using scripts on the device database is
helpful when you want to try new configurations, but you are not ready to push configuration changes to
FortiGate. Device layer scripts are used to modify only device-level settings such as interfaces, DNS, static
routes, dynamic routes, system settings, log settings, or any other part of the FortiGate configuration that
does not affect firewall policy rules.
10. Click Managed FortiGate, select the HQ-DCFW checkbox, click Install, and then select Install Wizard to install
the static route on HQ-DCFW.
11. Select Install Policy Package & Device Settings, and then in the Policy Package field, select DCFW.
You can leave the Create ADOM Revision setting enabled or disable it. You will not
be using this feature in any of the labs, so this setting will not affect the configuration.
Also, you can use any name in the Revision Name field.
© FORTINET
12. Click Next.
13. Click Next.
14. Click Install preview to see what FortiManager will push to HQ-DCFW.
15. Click Close.
16. Click Install.
Even if you made changes only to the device layer, it is recommended that you install the policy package
and device settings at the same time to avoid an unknown policy package status. An unknown policy
package status is generated when you run a script in the device layer.
In real-world environments, you must use the install preview option to accept the changes that FortiManager
will push.
You will create a firewall policy using the policy package or ADOM database method.
Before you run the script to create the policy, it is recommended that you view what is
in the DCFW policy package, in order to see how the policy script is working and what
the firewall policy is creating.
© FORTINET
3. Click Policy & Objects > Policy Packages > DCFW > Firewall Policy.
4. Verify that there is one firewall policy in the DCFW policy package.
5. Click Device Manager > Scripts to run the policy script to add one firewall policy to the DCFW policy package.
6. Select the Firewall rule checkbox, and then click Run Script.
7. In the Run script on policy package field, select DCFW, and then click Run Now.
© FORTINET
Stop and think!
You selected the DCFW policy package previously because there was a firewall policy to create. However, if
you need to create only firewall addresses, services, virtual IP addresses, IP pools, security profiles, user,
user groups, or anything related to the policy layer, you can select any policy package—for example, the
default policy package, which is usually not being used. You should only select a specific policy package if
you create a firewall policy.
Running policy scripts is useful when you need to import hundreds of objects into the policy layer database,
which saves the effort a policy package import requires when you already have FortiGate devices added to
your FortiManager. You can try to generate an object, but make sure that it is not pushed to a FortiGate, and
that you do not reference the object in any policy rules.
11. In the drop-down list beside Install Wizard, select Re-install Policy to reinstall the policy package.
You can reinstall a policy package after you install the policy package the first time.
This applies whether you assign a policy package to FortiGate or you import it, and
then install it for the first time.
Also, reinstalling a policy package shows you an installation preview, which you must
view if you do not know the changes that FortiManager will push.
13. Click Install preview to see what FortiManager will push to HQ-DCFW, and then click Close.
You can see that FortiManager will push one firewall policy.
You will add two FortiGate devices using the model device and link them to FortiManager with the pre-shared key
method. The general process is the following:
Network Topology
© FORTINET
5. Click OK.
You can see the metadata variables shown in the following image:
© FORTINET
The GW, Hostname, IP_port1, IP_port4, and LAN_BR variables have been
preconfigured for you to save time. At this stage, creating the metadata variables
consists of creating an object only. After the FortiGate is added as a model device,
you will assign a value to the object.
5. In the Script Details section, in the port2 part of the script, at the end of the set ip line, type $, and then in the list
that appears, select (IP_port2).
© FORTINET
The IP_port4, IP_port1, GW, and Hostname metadata variables have been
preconfigured for you in Pre-CLI Template to save time.
© FORTINET
The dollar sign ($) must precede any metadata variable (enclosed in parentheses).
Otherwise, you will receive an error when you try to install them.
6. Click OK.
You have created the metadata variables that you will assign when you add new FortiGate devices using
the LTP model. Once you add a FortiGate, you must define each value according to each site.
You will add BR2-FGT-1 to FortiManager using the model device method.
© FORTINET
Field Value
Name BR2-FGT-1
Port Provisioning 4
Metadata Variables Click Edit Variable Mapping, and then continue to the next step.
© FORTINET
When you add a metadata variable, ensure that you click the check mark so that the
metadata variable is saved.
$(GW) 100.65.2.254
© FORTINET
Variable Name Mapping Value
$(Hostname) BR2-FGT-1
$(IP_port1) 192.168.1.112/16
$(IP_port2) 100.65.2.112/24
$(IP_port4) 172.20.2.254/24
$(LAN_BR) 172.20.2.0/24
6. Click OK.
7. Click Next.
8. Click Finish.
You can see that BR2-FGT-1 is available in the device database.
If your view is different from the following image, you can rearrange the table columns
to display the Policy Package Status column, using the gear icon in the upper-right
corner.
© FORTINET
BR2-FGT-1 has been added to the FortiManager device database and it has already been assigned a
name, pre-shared key, device model, port provisioning, pre-run CLI template, policy package, and metadata
variables.
© FORTINET
Stop and think!
Pre-run CLI templates are designed for LTP model devices. After you install one for the first time, you will
notice that the template is automatically unassigned from the firewall.
CLI templates are assigned and stick until you remove them, but pre-run CLI templates are removed
automatically, as you can see in this example.
9. Click Device Manager > Device & Groups > Managed FortiGate.
10. Select BR2-FGT-1, click Install, and then select Install Wizard to install the policy package in the device layer.
11. Click Install Policy Package & Device Settings.
12. In the Policy Package field, select BR.
Once the FortiGate is connected to FortiManager, the firewall is ready to receive all configurations.
© FORTINET
Notice that after you create the default static route, the following message appears:
The destination is set to 0.0.0.0/0 which means all IP
addresses.
Notice that after you configure the central-management settings, the following
message appears:
The Serial Number for FortiManager is not entered.
3. Type y.
© FORTINET
After typing y, you must not press Enter. The following message appears:
Obtained serial number from FortiManager 100.65.0.120 is: FMG-
VMTM24012945
4. Type y.
Notice that this firewall does not have any other configuration except port2 and the FortiManager acting as a
local FortiGuard Distribution Server (FDS). In your topology environments, as long as your firewall has
internet access through a valid internet connection, so it can validate its FortiGuard license, this is enough
since FortiGate must have a valid license to work correctly.
5. Return to the BR2-FGT-1 serial console, and then enter the following command to register FortiGate on
FortiManager:
execute central-mgmt register-device FMG-VMTM24012945 123456789
Ensure that you type the command correctly—if it is not correct, the FortiGate will not
connect to FortiManager.
6. Return to the FortiManager GUI, and then in ADOM EFW, click System Settings > Task Monitor.
In the upper-right corner, you can see that the autolink device process started automatically.
You can also see the autolink and installation configuration process running in ADOM EFW > System
Settings > Task Monitor.
© FORTINET
After you register BR2-FGT-1 on FortiManager, it should not take more than 2 minutes
to finish the installation process. If you registered the device and you do not see any
logs in the task monitor, it means that you should check the spelling of the previous
commands, such as the FortiManager serial number or the correct IP address when
you typed it directly on the BR2-FGT-1 console.
$(GW): 100.65.3.254
$(Hostname): BR3-FGT-1
$(IP_port1): 192.168.1.113/16
$(IP_port2): 100.65.3.113/24
$(IP_port4): 172.20.3.254/24
$(LAN_BR): 172.20.3.0/24
Policy Package: BR
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see "Configuring LTP" on page 38.
© FORTINET
To register BR3-FGT-1 on FortiManager
1. Log in to the FortiManager GUI with the following credentials:
l Username: admin
l Password: Fortinet1!
2. In the Select an ADOM window, select the EFW ADOM.
3. Click Device Manager > Device & Groups > Add Device, and then select Add Model Device.
You do not need to create any templates since you have already done this. Now, you
will add new branches.
Field Value
Name BR3-FGT-1
Port Provisioning 4
Metadata Variables Click Edit Variable Mapping, and then continue to the next step.
© FORTINET
Notice that you are using a different pre-shared key. Since you can add multiple
firewalls, it is recommended that you use a different password based on the firewall
you will be adding.
$(GW) 100.65.3.254
$(Hostname) BR3-FGT-1
$(IP_port1) 192.168.1.113/16
$(IP_port2) 100.65.3.113/24
$(IP_port4) 172.20.3.254/24
$(LAN_BR) 172.20.3.0/24
© FORTINET
Stop and think!
Think about all the possibilities that you can configure using metadata variables, based on the necessities of
your firewalls or sites. At this stage, you have configured three simple parameters: GW, host name, and
network segment. However, you can go beyond the dynamic objects you need to use at the beginning of the
setup of your LTP implementation and your pre-run CLI template, which are only assigned at the beginning
of adding your device to FortiManager.
6. Click OK.
7. Click Next.
8. Click Finish.
You can see that BR3-FGT-1 is available in the device database.
9. Click Device Manager > Device & Groups > Managed FortiGate.
10. Select BR3-FGT-1, click Install, and then select Install Wizard to install the policy package in the device layer.
11. Click Install Policy Package & Device Settings.
12. In the Policy Package field, select BR.
© FORTINET
If you leave the BR2-FGT-1 checkbox selected, you will see No commands to be
installed at the next step.
Once FortiGate is connected to FortiManager, the firewall is ready to receive all configurations.
© FORTINET
edit "port2"
set ip 100.65.3.113 255.255.255.0
set allowaccess ping https ssh fgfm
end
config router static
edit 1
set device port2
set gateway 100.65.3.254
end
config system central-management
set type fortimanager
set fmg 100.65.0.120
end
3. Type y to obtain the FortiManager serial number.
4. Type y to confirm the serial number.
5. Enter the following command to register FortiGate on FortiManager:
execute central-mgmt register-device FMG-VMTM24012945 987654321
Ensure that you type the command correctly—if it is not correct, FortiGate will not
connect to FortiManager.
6. Return to the FortiManager GUI, and then in ADOM EFW, click System Settings > Task Monitor.
In the upper-right corner, you can see that the autolink device process started automatically.
You can also see the autolink and installation configuration process running in ADOM EFW > System
Settings > Task Monitor.
© FORTINET
After you register BR3-FGT-1 on FortiManager, it should not take more than 2 minutes
to finish the installation process. If you registered the device, and you do not see any
logs in the task monitor, it means that you should check the spelling of the previous
commands, such as the FortiManager serial number or the correct IP address when
you typed it directly on the BR3-FGT-1 console.
In this lab, you will configure VLANs and enable VDOMs. Then, you will allow inter-VDOM traffic and configure
internet access using inter-VDOM routing.
Objectives
l Configure VLANs on ISFW
l Enable VDOMs on ISFW
l Allow inter-VDOM traffic between the Zone1 VDOM and Zone2 VDOM
l Configure internet access using inter-VDOM routing from the Zone1 VDOM to the root VDOM
Time to Complete
Estimated: 50 minutes
Prerequisites
Before you begin this lab, you must complete the previous lab. If you haven’t done so, tell your instructor.
In this exercise, you will enable VDOMs and VLANs. Then, you will assign VLANs and use an inter-VDOM link to
interconnect each of them with other resources in your network.
Network Topology
Enable VDOMs
© FORTINET
To enable VDOMs
1. Connect to the FortiManager GUI, and then log in with the following credentials:
l Username: admin
l Password: Fortinet1!
2. In the Select an ADOM window, select the EFW ADOM.
3. Click Device Manager > Device & Groups > Managed FortiGate > HQ-ISFW > Dashboard > Summary.
4. In the System Information widget, in the VDOM field, click the Edit VDOM icon.
5. In the VDOM Mode field, select Multi VDOM, and then click Apply.
© FORTINET
3. Click OK.
4. Click Managed FortiGate > HQ-ISFW > System > Virtual Domain > Create New.
Field Value
© FORTINET
6. Click OK.
Field Value
3. Click OK.
© FORTINET
You should now see that the Zone1 and Zone2 VDOMs were created, as shown in the following image:
Ensure that you configure the VLAN interface settings correctly because you will use
them as normalized interfaces associated between device models and the KVM. If the
settings are not spelled or configured correctly, you will have to delete them and create
the configuration again.
Field Value
Interface port4
VLAN ID 101
© FORTINET
Field Value
IP/Netmask 10.0.2.254/255.255.255.0
4. Click OK.
5. Click Managed FortiGate > HQ-ISFW > Network > Interfaces.
6. Click Create New, and then select Interface.
7. Configure the following settings:
Field Value
Interface port5
VLAN ID 102
IP/Netmask 10.0.3.254/255.255.255.0
© FORTINET
8. Click OK.
Your interface configuration should look like the following image:
© FORTINET
Stop and think!
If your VLAN interface configuration is correct, the Normalized Interface page shows that VLAN101 and
VLAN102 were automatically assigned as normalized interfaces. This is because VLAN101 and VLAN102
have already been configured as normalized interfaces for you using the per-platform method.
Field Value
Name A
IP/Netmask 172.16.1.253/255.255.255.252
© FORTINET
Field Value
IP/Netmask 172.16.1.254/255.255.255.252
4. Click OK.
5. Click Managed FortiGate > HQ-ISFW > Network > Interfaces.
6. Click Create New, and then select VDOM Link.
7. Configure the following settings:
Field Value
Name B
© FORTINET
Field Value
IP/Netmask 172.16.1.245/255.255.255.252
IP/Netmask 172.16.1.246/255.255.255.252
8. Click OK.
9. Click Managed FortiGate > ISFW > Network > Interfaces.
10. Click Create New, and then select VDOM Link.
11. Configure the following settings:
© FORTINET
Field Value
Name C
IP/Netmask 172.16.1.249/255.255.255.252
IP/Netmask 172.16.1.250/255.255.255.252
© FORTINET
You have created inter-VDOM links, which act like physical interfaces between your virtual firewalls.
Also, the A0, A1, B0, B1, C0, and C1 normalized interfaces have been created for you. Therefore,
FortiManager automatically associates the normalized interfaces with the interfaces you have created.
You will create static routes in the Zone1, Zone2, and root VDOMs.
Field Value
Destination 0.0.0.0/0.0.0.0
Interface A1
4. Click OK.
You will see the following message:
Using default destination route 0.0.0.0 0.0.0.0. Are you sure you want to
inject default routes?
5. Click OK.
6. Click Managed FortiGate > HQ-ISFW > Zone1 > Network > Static Routes.
7. Click Create New, and then select IPv4 Static Route.
8. Configure the following settings:
© FORTINET
Field Value
Destination 10.0.3.0/255.255.255.0
Interface B0
9. Click OK.
You should see the static routes shown in the following image in the Zone1 VDOM:
You will push these changes once you assign the policy package to all VDOMs. This way, you will save time
by installing these changes once instead of twice. If you do it the other way, you would install the device
settings, and then install the policy packages.
Field Value
Destination 10.0.2.0/255.255.255.0
Interface B1
4. Click OK.
You should see the static route shown in the following image in the Zone2 VDOM:
© FORTINET
To create a static route in the root VDOM
1. Click Managed FortiGate > HQ-ISFW > root > Network > Static Routes.
2. Click Create New, and then select IPv4 Static Route.
3. Configure the following settings:
Field Value
Destination 10.0.2.0/255.255.255.0
Interface A0
4. Click OK.
You should see the static routes shown in the following image in the root VDOM:
You could install device settings only to all VDOMs. But, since you still need to push
policy changes, in this example, you will add the policies, and then install the policy
package and device settings.
You will run a script on the Policy Package or ADOM Database target for the root_ISFW policy package. Then,
you will install the associated policy packages in the Zone1, Zone2, and root VDOMs.
To run a script on the Policy Package or ADOM Database target for the root_ISFW policy
package
1. Click Device Manager > Scripts.
2. Select the root_ISFW checkbox, and then click Run Script.
© FORTINET
3. In the Run script on policy package field, select root_ISFW, and then click Run Now.
Because this is the first time installation is being done from FortiManager to these
VDOMs, you will see more than the policies being pushed to the VDOMs. After you
install this the first time, consecutive installations should show only the changes you
applied to the policy package or device database installations.
8. In the Select Devices to Install (root_ISFW) (2/4) window, ensure that the root [NAT] (Management) VDOM is
selected, and then click Next.
9. In the Validate Devices (root_ISFW) (3/4) window, click Install.
10. In the Installation Progress (root_ISFW) (4/4) window, click Finish.
© FORTINET
3. Click Zone1 > Firewall Policy, and then verify the firewall policies that will be installed.
© FORTINET
3. Click Zone2 > Firewall Policy, and then verify the firewall policies that will be installed.
© FORTINET
© FORTINET
Validate the Communication From HQ-PC-2 to HQ-Web-1, the Internet, and
4.2.2.2
You will validate that HQ-PC-2 can communicate with HQ-Web-1 and the internet. You will notice in the traceroute
the IP address of the virtual interface—172.16.1.253—that was created using the inter-VDOM link.
To validate the communication from HQ-PC-2 to HQ-Web-1, the internet, and 4.2.2.2
1. Continuing on HQ-PC-2, enter the following commands to ping HQ-Web-1, the internet (www.fortinet.com),
and 4.2.2.2:
ping 10.0.5.11
ping www.fortinet.com
ping 4.2.2.2
2. Enter the following commands to validate the traceroute to HQ-Web-1, the internet (www.fortinet.com), and
4.2.2.2:
traceroute 10.0.5.11
traceroute www.fortinet.com
© FORTINET
traceroute 4.2.2.2
Notice that the root VDOM will send the traffic to either HQ-DCFW (10.0.12.253),
Core1 (10.0.12.254) or Core2 (10.0.11.254), depending on the destination IP address.
In this lab, you will configure VDOM partitioning. Then, you will configure a FortiGate Session Life Support
Protocol (FGSP) cluster inspecting asymmetric traffic with a layer 3 connection, and encrypt the session
synchronization.
Objectives
l Configure virtual clustering on HQ-NGFW-1 and HQ-NGFW-2
l Analyze session handling in VDOM partitioning
l Configure an FGSP cluster with BR1-FGT-1 and BR1-FGT-2 over a layer 3 connection
l Analyze asymmetric traffic across the FGSP cluster
l Configure encryption for the session synchronization
Time to Complete
Estimated: 55 minutes
Prerequisites
Before you begin this lab, you must complete the previous lab. If you haven’t done so, tell your instructor.
In this exercise, you will configure a virtual cluster between HQ-NGFW-1 and HQ-NGFW-2. HA is configured in
active-passive mode between HQ-NGFW-1 and HQ-NGFW-2. Using VDOM partitioning, you will configure virtual
clustering between the Core1 and Core2 VDOMs in a way that traffic for Core1 will be processed by HQ-NGFW-1,
and traffic for Core2 will be processed by HQ-NGFW-2.
Network Topology
Before you configure VDOM partitioning, you will check the HA synchronization status between HQ-NGFW-1 and
HQ-NGFW-2.
© FORTINET
To check the HA status
1. Connect to the HQ-NGFW-1 GUI.
2. Log in with the following credentials:
l Username: admin
l Password: Fortinet1!
3. Click Login Read-Only.
4. Click System > HA, and then analyze the information displayed.
Two green check marks indicate both devices are synchronized with each other. HQ-NGFW-1 is acting as the
primary device and HQ-NGFW-2 is acting as a secondary device.
Ensure that both devices are in sync before moving to the next task.
You will configure Core1 for virtual cluster 1 and Core2 for virtual cluster 2 using FortiManager.
© FORTINET
7. Click ha.
8. Enable vcluster-status.
10. Configure the first virtual cluster with the following settings:
Field Value
vcluster-id 1
priority 200
© FORTINET
Field Value
vcluster-id 2
priority 50
vdom Core2
You might need to click the gear icon in the upper-right corner to enable the priority
and vdom columns. Once they appear in the table, move them to the left.
© FORTINET
You should see HQ-NGFW-1 as the primary for virtual cluster 1 and HQ-NGFW-2 as the primary for virtual
cluster 2.
The default priority for virtual clusters is 128. On HQ-NGFW-1, you configured this priority as 50, which is
lower than the default value. Because the priority is the deciding factor in selecting a primary device in this
setup, the device with the highest priority is elected as the primary for the cluster.
You will generate traffic by running a continuous ping from HQ-PC-2, and then use the sniffer to analyze traffic
distribution.
To generate traffic
1. On HQ-PC-2, open a terminal session, and then enter the following command to start a continuous ping to 8.8.8.8:
ping 8.8.8.8
2. Open a new terminal session, and then enter the following command to start a continuous ping to 4.2.2.2:
ping 4.2.2.2
3. Keep both terminal windows open and leave the pings running.
© FORTINET
You are sending 4.2.2.2 traffic through Core2, which belongs to virtual cluster 2. HQ-NGFW-2 is the primary
device for virtual cluster 2. You must connect to HQ-NGFW-2 to see traffic destined for 4.2.2.2.
4. Continuing in the same SSH session, enter the following commands to connect to HQ-NGFW-2:
end
config global
execute ha manage 0 admin
5. At the prompt, type the password Fortinet1!, and then press Enter.
6. Enter the following commands to view the active ICMP sessions on Core2:
config vdom
edit Core2
get system session list | grep icmp
You should see session information for the continuous ping going to 4.2.2.2.
You will perform a manual failover for virtual cluster 2 by increasing the priority for HQ-NGFW-1. Then, you will
analyze the traffic.
© FORTINET
5. In the vcluster section, select the checkbox for the row with a value of 2 in the vcluster-id column, and then click
Edit.
© FORTINET
After the failover, HQ-NGFW-1 handles all the traffic for the Core1 and Core2 VDOMs.
In this exercise, you will configure FGSP on BR1-FGT-1 and BR1-FGT-2, which handle asymmetric traffic. Port7
on BR1-FGT-1 and port7 on BR1-FGT-2 are both in the same LAN subnet. You will apply the session
synchronization using a layer 3 connection and analyze the asymmetric traffic.
Network Topology
Configure FGSP
Before you test the session synchronization, you will configure FGSP between BR1-FGT-1 and BR1-FGT-2.
© FORTINET
set group-member-id 1
config cluster-peer
edit 1
set peerip 10.1.6.253
next
end
end
4. Type y.
5. Leave the SSH session open.
Command Value
standalone-group-id 5
group-member-id 2
peerip 10.1.6.254
The standalone-group-id must be the same value for all members. The ID can be
a value from 1–255. The group-member-id can be a value from 1–15 and must be
different for each member in the same group.
© FORTINET
3. Connect over SSH to BR1-FGT-2.
4. Log in with the following credentials:
l Username: admin
l Password: Fortinet1!
5. Enter the following command to view the session:
get system session list | grep icmp
The result should be similar to the following output:
FGSP does not synchronize the configuration by default. Here, the traffic is asymmetric and therefore the
configuration, like the firewall policy, is asymmetric also. Therefore, you cannot use standalone
configuration synchronization.
© FORTINET
64 bytes from ec2-35-182-106-253.ca-central-1.compute.amazonaws.com (35.182.106.253):
icmp_seq=2 ttl=50 time=15.6 ms
64 bytes from ec2-35-182-106-253.ca-central-1.compute.amazonaws.com (35.182.106.253):
icmp_seq=3 ttl=50 time=15.9 ms
2. Connect over SSH to BR1-FGT-1.
3. Enter the following command to view the session:
# get system session list | grep icmp
The result should be similar to the following output:
© FORTINET
The sniffer trace confirms that the traffic is exiting from port3 of BR1-FGT-2 and the
return traffic is entering from port2 of BR1-FGT-1.
The firewall policy configured on BR1-FGT-1 allows only sessions from port4 to port2.
FGSP synchronizes the session over the layer 3 connection, which means port7 on BR1-FGT-1 and BR1-
FGT-2.
To confirm the TCP session with asymmetric traffic that FGSP allowed
1. Connect to BR1-PC-1.
2. Open a browser, and then enter the following URL:
www.fortinet.com
3. Return to the BR1-FGT-1 SSH session, and then enter the following command to view the session information:
get system session list | grep 443
The result should be similar to the following output:
© FORTINET
4. In the BR1-FGT-2 SSH session, enter the same command to view the session information:
get system session list | grep 443
The result should be similar to the following output:
Both FortiGate devices show the same TCP session, allowing the asymmetric traffic with FGSP.
The above session lists are extracts because the lists have many entries.
If the session does not appear in the list, refresh the browser page.
3. Return to the BR1-FGT-1 SSH session, and then enter the following command to view the session information:
diagnose sys session filter dport 8080
diagnose sys session list
The result should be similar to the following output:
© FORTINET
4. Return to the BR1-FGT-2 SSH session, and then enter the following command to view the session information:
diagnose sys session filter dport 8080
diagnose sys session list
The result should be similar to the following output:
© FORTINET
The BR1-FGT-2 session list shows a synced flag, which means that BR1-FGT-2 has
synchronized these sessions with its peer (BR1-FGT-1).
In this exercise, you will examine the protocol that handles the layer 3 session synchronization. Then, you will
configure the encryption of the session synchronization.
You will verify the protocol that handles the session synchronization, and then configure the encryption.
© FORTINET
config system standalone-cluster
set encryption enable
set psksecret fortinet
end
2. Connect over SSH to BR1-FGT-2.
3. Log in with the following credentials:
l Username: admin
l Password: Fortinet1!
4. Enter the following commands to enable encryption:
config system standalone-cluster
set encryption enable
set psksecret fortinet
end
© FORTINET
The session synchronization over layer 3 is now encapsulated in ESP packets and
therefore encrypted in the SESSYNC_1 IPsec tunnel.
In this lab, on FortiManager, you will configure the FortiGate devices to use OSPF as the dynamic routing protocol
for the enterprise network. You will also configure BGP on NGFW and use a loopback interface as a BGP source
on BR1-FGT-2.
Objectives
l Use OSPF to dynamically distribute the routes in an enterprise network
l Configure OSPF equal-cost multi-path (ECMP)
l Configure BGP using a FortiManager BGP template
l Implement a loopback interface as a BGP source
Time to Complete
Estimated: 60 minutes
Prerequisites
Before you begin this lab, you must complete the previous lab. If you haven’t done so, tell your instructor.
In this exercise, you will configure OSPF on the three FortiGate devices that are part of the hub network: HQ-
ISFW, HQ-DCFW, and HQ-NGFW. The objective is to remove all static routes from the three firewalls and use
only OSPF to route traffic internally. You will use three OSPF areas and enable the rfc1583-compatible setting to
provide OSPF ECMP for external routes.
First, you will configure OSPF on HQ-DCFW. Next, you will remove the static routes. Finally, you will install the
changes.
© FORTINET
To configure OSPF on HQ-DCFW
1. Log in to the FortiManager GUI with the following credentials:
l Username: admin
l Password: Fortinet1!
2. Click EFW.
3. Click Device Manager.
4. Click Device & Groups > Managed FortiGate > HQ-DCFW > Feature Visibility.
5. On the Global Feature Visibility tab, in the Network section, click OSPF.
6. Click OK.
7. Click Device & Groups > Managed FortiGate > HQ-DCFW > Network > OSPF.
8. Configure the following settings:
Field Value
Router ID 0.0.0.2
Areas 0.0.0.0
© FORTINET
9. Click Apply.
3. Click OK to confirm.
© FORTINET
5. Wait until the installation finishes.
6. Click Finish.
You will configure OSPF on the HQ-ISFW Zone1 VDOM and root VDOM through FortiManager. Try to do this
yourself using the procedure you followed to configure OSPF on HQ-DCFW.
Field Value
Router ID 0.0.0.4
© FORTINET
The type of area is STUB because there is no further routing expected with the Zone2
VDOM.
4. Click Apply.
5. Click Network > Static Routes.
6. Delete the static route used to route internal traffic (don’t delete the default route).
© FORTINET
Field Value
Router ID 0.0.0.3
The HQ-ISFW root VDOM router is connected to multiple areas and is then an area
border router (ABR).
© FORTINET
3. Click Apply.
4. Delete the two static routes used to route internal traffic (don’t delete the default route or the route to
4.2.2.2/255.255.255.255).
You will configure OSPF on the HQ-NGFW Core1 VDOM and Core2 VDOM through FortiManager. Try to do this
yourself using the procedure you followed to configure OSPF on HQ-DCFW and HQ-ISFW.
Field Value
Router ID 0.0.0.5
Areas 0.0.0.0
Networks 10.0.12.0/24
© FORTINET
3. In the Redistribute section, select the static checkbox, and then click Edit.
The Core1 VDOM has a static route preconfigured to reach the IP address
100.75.5.1. You will enable the static route redistribution to import it into OSPF.
5. Click Apply.
6. Delete the two static routes used to route internal traffic (don’t delete the default route or the route to
100.75.5.1/255.255.255.255).
© FORTINET
Field Value
Router ID 0.0.0.6
Areas 0.0.0.2
3. In the Redistribute section, select the static checkbox, and then click Edit.
© FORTINET
The same static route to reach the IP address 100.75.5.1 is preconfigured in the
Core2 VDOM. You will enable the static route redistribution to import it into OSPF.
5. Click Apply.
6. Delete the static route used to route internal traffic (don’t delete the default route or the route to
100.75.5.1/255.255.255.255).
You will run OSPF diagnostic commands on the HQ-ISFW root VDOM to verify OSPF operation.
© FORTINET
Can you identify from this output what the designated router (DR) is?
The State of the DR is displayed as Full/DR. If neither of the routers in the backbone area display this
state, it means that the DR is the local FortiGate. In this case, the DR is HQ-DCFW.
© FORTINET
This confirms that the HQ-ISFW root VDOM is connected to three OSPF areas and is
therefore an ABR. You can also see that OSPF ECMP (defined with the
RFC1583Compatibility flag) is disabled by default.
You should see that the ISFW root VDOM has learned the routes to the 10.0.5.0/24 and 10.0.2.0/24
subnets through OSPF.
© FORTINET
Why is the external route to 100.75.5.1/32 available only through the NGFW Core2 VDOM, meaning
10.0.11.254?
You will enable and install OSPF ECMP on the HQ-ISFW root VDOM.
© FORTINET
8. Click Apply.
You will enable and install OSPF ECMP on the HQ-NGFW Core1 and Core2 VDOMs.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Check Connectivity on page 99.
© FORTINET
To enable OSPF ECMP on the HQ-NGFW Core1 VDOM
1. Continuing on the FortiManager GUI, in the Managed FortiGate list, click HQ-NGFW > Core1 > Network > OSPF.
2. Click Advanced Options.
3. Enable rfc1583-compatible.
4. Click Apply.
4. Click Install.
5. Wait until the installation finishes.
6. Click Finish.
You will verify that the HQ-ISFW root VDOM has multiple routes to the same destination with different next hops.
© FORTINET
get router info ospf status
The output should be similar to the following output:
With OSPF ECMP enabled, the HQ-ISFW root VDOM can now load balance the traffic
to 100.75.5.1/32 with the two routes of the same cost installed with the OSPF
protocol.
You will run OSPF diagnostic commands on HQ-DCFW and HQ-NGFW to verify OSPF operation.
© FORTINET
Take the Expert Challenge!
Check Connectivity
You will confirm that the FortiGate devices are routing traffic correctly by running a ping from HQ-PC-2 to HQ-
Web-1.
To check connectivity
1. On HQ-PC-2, open a terminal window.
2. Run a ping to HQ-Web-1 (10.0.5.11).
The ping should succeed, which confirms that the FortiGate devices are correctly routing the traffic between
the 10.0.2.0/24 and 10.0.5.0/24 subnets.
traceroute 4.2.2.2
The traceroute should succeed, which confirms that the OSPF protocol is correctly handling your internal
enterprise network routing.
HQ-NGFW has two connections to the internet—one using port2 in the Core1 VDOM and the other using port3 in
the Core2 VDOM. You will configure BGP on HQ-NGFW so Core1 and Core2 become BGP peers.
You will create metadata variables and use them in a BGP template. Then, you will install the template in the two
VDOMs, Core1 and Core2.
Field Value
Value 100.65.0.101
© FORTINET
Field Value
Value 172.16.1.1
Field Value
Value 172.16.2.1
© FORTINET
Field Value
Value 65100
Field Value
Value 65200
© FORTINET
Field Value
Value 65200
Field Value
Value 65100
© FORTINET
By default, the BGP settings are hidden on the FortiManager GUI. You will enable
them in the Feature Visibility section.
4. Click OK.
To configure BGP
1. Continuing on the FortiManager GUI, in the menu at the top, click BGP.
2. Click Create New.
© FORTINET
3. Configure the following settings:
Field Value
Name BGP_NGFW
Local As $(AS)
Router ID $(Router_ID)
Field Value
IP $(Neighbor_IP)
Remote AS $(Remote_AS)
When you type $ in the Local AS, Router ID, IP, Remote AS field, you can then select
(AS), (Router_ID), (Neighbor_IP), and (Remote_AS) in the metadata variables list
that appears.
© FORTINET
Because Core1 and Core2 are not directly connected, you must enable multihop in the
BGP configuration.
6. Click OK.
The configuration should look like the following image:
7. Click OK.
8. Select the BGP_NGFW checkbox, and then click Assign to Device/Group.
9. Move HQ-NGFW [Core1] and HQ-NGFW [Core2] from the Available Entries field to the Selected Entries field,
and then click OK.
© FORTINET
To install the BGP configuration
1. Continuing on the FortiManager GUI, click Install Wizard.
2. Verify that Install Device Settings (only) is selected, and then click Next.
3. Verify that the HQ-NGFW, Core1 [NAT], and Core2 [NAT] checkboxes are selected, and then click Next.
4. Click Install.
5. Wait until the installation finishes.
6. Click Finish.
You can check the installation and BGP status in the two VDOMs—Core1 and Core
2—using the following commands:
get router info bgp summary
In this exercise, you will create a loopback interface and configure BGP on BR1-FGT-2, and then establish a BGP
connection with the ISP router.
Since FortiManager does not manage BR1-FGT-2, you must perform the loopback and BGP configurations on
BR1-FGT-2.
© FORTINET
4. Select the BGP_NGFW checkbox, and then click Edit.
5. Create a new neighbor with the following settings:
Field Value
IP 100.75.5.1
Remote AS 65300
8. Click OK.
© FORTINET
Establish the BGP connection
You will verify the BGP status, finalize the BGP configuration, and establish the BGP connection.
Because a loopback interface adds one hop, you must always enable multihop in the BGP configuration that
includes a loopback interface.
© FORTINET
You may see the BGP state showing Connect. You can then enter the get router
info bgp summary command again to confirm that the BGP connection is
established.
In this lab, you will learn how to solve false positive scenarios in your network. Then, you will learn how to protect
against PHP code injection attacks over encrypted and unencrypted traffic.
Objectives
l Use IPS profiles with clients and servers as targets to protect your network resources
l Use IPS profiles to protect against PHP code injection attacks over unencrypted protocols
l Configure a certificate signed by an internal CA to block code injection occurrences over an encrypted protocol
Time to Complete
Estimated: 55 minutes
Prerequisites
Before you begin this lab, you must complete the previous lab. If you haven’t done so, tell your instructor.
In this exercise, you will learn how to solve false positive scenarios in your network. You will configure IPS profiles
with clients and servers as targets to protect your network resources.
You will modify the existing DCFW policy in the FortiManager policy package to apply the IPS_Block profile.
Field Value
IPS IPS_Block
© FORTINET
7. Click OK.
© FORTINET
6. On the Install Preview page, click Close.
7. Click Install.
8. Wait until the installation finishes.
9. Click Finish.
You will confirm that HQ-DCFW is not allowing ICMP oversized packets.
3. When you are prompted for the student account, enter the password Fortinet1!.
hping3 is the program that is used to generate and send the ICMP packets. -1
instructs hping3 to use ICMP for sending packets. -d 654001 sets the ICMP packet
size to 654001 bytes, a size that exceeds the maximum transmission unit (MTU). -c 4
instructs hping3 to send 4 ICMP packets. 10.0.5.11 is the destination IP address
for the ICMP packets.
© FORTINET
You can see that HQ-DCFW is blocking the jumbo packets, which means that suspected risky traffic is being
blocked according to the assigned IPS profile.
You will verify that HQ-DCFW detects jumbo packets as a possible attack.
If the Security section does not appear, you can click Log View > Logs again to
refresh the page.
5. In the All Devices drop-down list, select the HQ-DCFW checkbox, and then click OK.
© FORTINET
© FORTINET
This example of jumbo ICMP packets illustrates a hypothetical scenario where HQ-PC-
2 is trying to transfer, connect, or sync an application to HQ-Web-1, and FortiGate
mistakenly flags it as intrusive. Such occurrences are common when you use IPS
profiles that are aimed at blocking. However, not all flagged traffic is genuinely
malicious. It is important to consider the possibility of false positives when you block
IPS traffic.
You will modify the IPS_Block profile to allow false positive jumbo packets.
Field Value
Action Monitor
Status Enable
Signatures ICMP.Oversized.Packet
© FORTINET
13. Click OK.
14. Move the ICMP.Oversized.Packet signature to the top of the table.
3. When you are prompted for the student account, enter the password Fortinet1!.
HQ-Web-1 is receiving packets from HQ-PC-2.
© FORTINET
The HQ-DCFW firewall now detects the new signature oversized packet as the action monitor, so it allows the
traffic and also generates a log.
You will verify that HQ-DCFW detects the jumbo packets and allows the traffic.
If the log with the detected action does not appear, you can click Log View > Logs
again to refresh the page.
© FORTINET
If you encounter scenarios where an IPS signature blocks your native traffic, and an
application that you are using is considered hostile, you should set the application
signature to monitor, at the top of your rules.
In this exercise, you will learn how to protect against a PHP code injection attack that is acting as an unencrypted
protocol. You will also learn to identify the issue, and then rectify the issue using an IPS profile.
You will modify the existing DCFW policy in the FortiManager policy package to apply the IPS_Monitor profile.
Field Value
IPS IPS_Monitor
© FORTINET
7. Click OK.
© FORTINET
Access the Website
You will test to see if the http://acmetest.com website is accessible, which is hosted on HQ-Web-1.
You will simulate an attack to access the files on HQ-Web-1 using a URL with a PHP code injection.
© FORTINET
To simulate the attack
1. Connect to HQ-PC-2.
2. Navigate to Desktop > Resources > Enterprise-FW.
3. Open the PHP injection.txt file.
4. In the Exercise 2 section, copy the URL.
The URL is http://www.acmetest.com/dir_command.php?arg="; echo system('dir'); //.
5. Open a browser, open a new private window, and then paste the URL.
This HTTP URL triggers the dir command on HQ-Web-1. For example, if you are an administrator user,
accessing the URL in an external browser displays the following files:
dir_command.php
index.html
index_old.html
© FORTINET
To verify the HQ-DCFW logs
1. Log in to the FortiAnalyzer GUI with the following credentials:
l Username: admin
l Password: Fortinet1!
2. Click EFW.
3. Click Log View > Logs > Fortinet Logs.
4. Select Security > Intrusion Prevention.
5. In the All Devices drop-down list, select the HQ-DCFW checkbox, and then click OK.
6. Double-click one of the detected HTTP logs.
You will notice that the HQ-DCFW firewall policy with the policy ID 2 and attack name
PHP.URI.Code.Injection identified the traffic. Optionally, you can click the attack name to see more details.
The attacker was able to successfully run the CLI command on HQ-Web-1 (HTTP)
because the IPS profile is set to monitor only.
This PHP command, or instruction, clearly demonstrates how, without having access
to the remote server, there could potentially be an attempt to exploit a security
vulnerability known as remote code execution (RCE). Specifically, the URL includes a
query parameter that injects PHP code. This type of code injection is malicious
because attackers can use any type of CLI command without having administrative
credentials for HQ-Web-1.
You will learn how to modify the IPS_Monitor profile to block PHP code injection attacks.
© FORTINET
2. Click EFW.
3. Click Policy & Objects > Policy Packages.
4. Click DCFW > Firewall Policy.
5. Select the checkbox for the To HQ-Web-1 policy, and then click Edit > Edit.
6. In the IPS field, click IPS_Monitor, and then click the Edit icon.
Field Value
Type Signature
Action Block
Status Enable
Signatures PHP.URI.Code.Injection
9. Click OK.
10. Move the PHP.URI.Code.Injection signature to the top of the table.
© FORTINET
Install the Policy
You will simulate an attack to access the files on HQ-Web-1 using a URL with a PHP code injection.
5. Open a browser, open a new private window, and then paste the URL.
This time, you can see that the attacker cannot access the HQ-Web-1 file.
© FORTINET
To verify the HQ-DCFW logs
1. Log in to the FortiAnalyzer GUI with the following credentials:
l Username: admin
l Password: Fortinet1!
2. Click EFW.
3. Click Log View > Logs > Fortinet Logs.
4. Select Security > Intrusion Prevention.
5. In the All Devices drop-down list, select the HQ-DCFW checkbox, and then click OK.
6. Double-click one of the HTTP dropped logs.
You will notice that the HQ-DCFW firewall policy with the policy ID 2 and attack name
PHP.URI.Code.Injection blocked the traffic. Optionally, you can click the attack name to see more details.
When an attack like this occurs, one recommendation from the FortiGuard Labs Threat
Encyclopedia is to block it. Ensure that you add a signature at the top of the signature
list to prioritize blocking this attack. When the PHP URI code is considered malicious,
the firewall will drop packets, and the browser will show a connection reset error
because the code can no longer pass through the firewall.
In this exercise, you have used only unencrypted traffic (HTTP) to access HQ-Web-1. What happens if a
code injection occurs over an encrypted protocol? Will a policy with an IPS profile and certificate inspection
be sufficient to analyze HTTPS traffic? In this scenario, FortiGate will detect HTTPS traffic, but it will not
detect an attack. FortiGate will not decrypt packets to analyze if there is a possible attack.
© FORTINET
If you use HTTPS (encrypted) traffic, HQ-DCFW will not be able to detect the attack. The attacker will be able
to access the files on HQ-Web-1, as shown in the following example:
When you receive the Potential Security Risk Ahead warning, click Advanced >
Accept the Risk and Continue to access www.acmetest.com (unsafe).
This HTTPS URL triggers the dir command on HQ-Web-1. Why didn’t HQ-DCFW block the HTTPS
attack?
The PHP.URI.Code.Injection signature is set to block in the profile, but HQ-DCFW cannot open the packet
because the traffic is encrypted, and certificate inspection on its own does not help HQ-DCFW to see the
encrypted traffic.
In this exercise, you will learn how to simulate a PHP code injection attack over an encrypted protocol. You will
use a certificate signed by an internal CA to block code injection occurrences over an encrypted protocol.
You will learn how to block encrypted packets on FortiGate. You must use an SSL protection server on your
SSL/SSH profile.
Field Value
Name Enable_HTTPS
© FORTINET
The acmetest certificate that you are using in this exercise was created in Lab 2,
Exercise 1.
8. Click OK.
9. Click OK again to save the changes.
The configuration should look like the following example:
Field Value
Name HTTPS_Profile
© FORTINET
Why did you have to dynamically map the local certificate? When you have a local certificate, you cannot
use it directly in the policy layer. The local certificate exists only in the device layer. To use the device layer
local certificate in the policy layer, you must use dynamic mapping.
You will learn how to modify the policy to use the certificate that you created in the previous task to block a PHP
code injection attack on encrypted traffic.
© FORTINET
11. Confirm that HQ-DCFW is selected, and then click Next.
12. Click Install Preview to see the changes that will be applied to the FortiGate.
13. On the Install Preview page, click Close.
14. Click Install.
15. Click Finish.
5. Open a browser, open a new incognito window, and then paste the URL.
You can see that HQ-DCFW is blocking the attack.
© FORTINET
You will notice that the HQ-DCFW firewall policy with the policy ID 2 and attack name
PHP.URI.Code.Injection blocked the traffic. Optionally, you can click the attack name to see more details.
With the internally signed CA certificate, HQ-DCFW can inspect the HTTPS traffic and identify the attack.
In this lab, you will configure a hub-and-spoke VPN network using the FortiManager IPsec templates.
Objectives
l Configure a hub-and-spoke topology using IPsec templates on FortiManager
l Use automatic routing to interconnect remote network segments
l Use a zone interface to group spoke interfaces in a hub
l Use a custom configuration of the VPN IPsec templates
l Identify and apply the process to delete IPsec templates
Time to Complete
Estimated: 45 minutes
Prerequisites
Before you begin this lab, you must complete the previous lab. If you haven't done so, tell your instructor.
In this exercise, you will configure a hub-and-spoke topology using IPsec templates.
Field Value
IP Address 100.65.0.101
Interface port2
© FORTINET
Field Value
Diffie-Hellman Groups 20
Phase 2 selectors Click Create New, and then continue to the next step.
© FORTINET
Make sure that the FEC Health Check field remains empty.
Make sure that you distinguish names. You have created the spokes template with the name Spokes, but
the interfaces are named To_hub. This will help you recognize interfaces that are connected to other peers.
When you go to BR2-FGT-1, you will find the hub interface, which will refer to the IPsec VPN connected to
the hub.
Field Value
Name PH2_to_hub
Proposal aes256-sha256
You will find multiple advanced options for IPsec phase2. You can press Ctrl+F to
find dhgrp.
7. Click OK.
© FORTINET
8. Click OK.
9. Click OK.
Field Value
IP Address 100.65.2.112
Interface port2
Diffie-Hellman Groups 20
Phase 2 selectors Click Create New, and then continue to the next step.
© FORTINET
Make sure to distinguish names. You have created the hub template with the name Hub, but the interface
for BR2-FGT-1 is To_BR2-FGT-1 and BR3-FGT-1 will be To_BR3-FGT-1. This will help you recognize
interfaces that are connected to the spokes.
© FORTINET
Field Value
Name PH2_to_BR2-FGT-1
Proposal aes256-sha256
5. Click OK.
6. Click OK again.
7. Click Create New, and then configure the following settings:
© FORTINET
Field Value
IP Address 100.65.3.113
Interface port2
Diffie-Hellman Groups 20
Phase 2 selectors Click Create New, and then continue to the next step.
© FORTINET
Field Value
Name PH2_to_BR3-FGT-1
© FORTINET
Field Value
Proposal aes256-sha256
9. Click OK.
© FORTINET
Stop and think!
Make sure to distinguish names. You have created the hub template with the name Hub, but the interface
for BR2-FGT-1 is To_BR2-FGT-1 and BR3-FGT-1 is To_BR3-FGT-1. This will help you recognize
interfaces from Core1 that are connected to each spoke.
12. On the IPsec Tunnel tab, select the Hub checkbox, and then click Assign to Device/Group to assign the Hub
IPsec template.
13. In the Available Entries field, select the HQ-NGFW [Core1] checkbox, and then move it to the Selected Entries
field.
14. Click OK.
15. On the IPsec Tunnel tab, select the Spokes checkbox, and then click Assign to Device/Group to assign the
Spokes IPsec template.
16. In the Available Entries field, select the BR2-FGT-1 and BR3-FGT-1 checkboxes, and then move them to the
Selected Entries field.
17. Click OK.
© FORTINET
You can see what the template will install if you right-click the template, and then
select Preview CLI Configuration.
If you need to delete your IPsec template, you must consider the objects that the template has created.
FortiManager cannot delete the objects that the template created because there are some dependencies.
18. Click Device Manager > Device & Groups > Managed FortiGate, and then select the Core1, BR2-FGT-1, and
BR3-FGT-1 checkboxes.
19. Click Install > Install Wizard.
20. Verify that Install Device Settings (only) is selected, and then click Next.
21. Verify that BR2-FGT-1, BR3-FGT-1, HQ-NGFW, and Core1 are selected, and then click Next.
22. Click Install.
Notice that once you have installed the templates, FortiManager can automatically detect normalized
interfaces that IPsec templates create.
This normalized interface (To_hub) was created for you before you started this lab. But, consider that every
time you use the IPsec template, the interfaces should be mapped to normalized interfaces. You can use
per device mapping or per platform mapping. If you use per platform mapping, ensure that the spelling of the
platform is correct because it is case sensitive. For example, To_hub will not be the same as To_Hub.
© FORTINET
Create a Normalized Interface for the Hub
You will create a normalized interface for the hub, so that you can manipulate the same firewall policies for all
hubs that you have in your topology.
6. Click OK.
7. Click Device Manager > Device & Groups.
8. Click Core1 > Network > Interfaces.
9. Click Create New > Device Zone.
10. Configure the following settings:
Field Value
© FORTINET
Using a zone in the hub makes it much faster to configure firewall policies for spokes, but everything
depends on your requirements.
After you install the VPN configuration on all FortiGate devices, the interfaces are available to configure the
firewall policies.
You are installing two firewall policies that use the Zone_spokes normalized
interface.
4. Click Close.
5. Click Device Manager > Device & Groups > Managed FortiGate.
6. Select the Core1 checkbox, and then click Install Wizard.
7. Select Install Policy Package & Device Settings.
8. In the Policy Package field, select Core1.
9. Click Next.
10. Click Next.
11. Click Install.
12. Click Finish.
© FORTINET
To configure the firewall policies on the spokes
1. Continuing on the FortiManager GUI, click Device Manager > Scripts.
2. Click the VPN_Spokes checkbox, and then click Run Script.
3. Select the BR policy package, and then click Run Now.
You are installing two firewall policies that use the To_hub normalized interface.
4. Click Close.
5. Click Device Manager > Device & Groups > Managed FortiGate.
6. Select the BR2-FGT-1 and BR3-FGT-1 checkboxes, and then click Install Wizard.
7. Select Install Policy Package & Device Settings.
8. In the Policy Package field, select BR.
9. Click Next.
10. Click Next.
11. Click Install.
12. Click Finish.
© FORTINET
Delete the IPsec Tunnels
Unsetting the template does not delete the configuration in the device layer and on the FortiGate. In this case, you
must remove the associated firewall policies where you reference IPsec interfaces and objects that were
generated in the IPsec templates. The general steps are:
© FORTINET
4. Click OK.
5. Click Device manager > Device & Groups > Managed FortiGate > HQ-NGFW > Core1 > CLI Configurations >
firewall > policy.
6. Click Core1 > CLI Configurations > firewall > policy.
Enable srcintf and dstintf in the engine icon tool, located in the upper-right
corner, so that you can easily identify policies that are using a specific interface. Then,
move the srcintf and dstintf columns to the left.
7. Delete the same policies you deleted in the policy layer for Core1—the ones that use the Zone_spokes interface.
8. Click OK.
9. Click Core1 > Network > Interfaces.
10. Select the Zone_spokes checkbox, and then click Delete.
© FORTINET
© FORTINET
© FORTINET
Make sure you have deleted all previous objects. Otherwise, when you reinstall, you
will receive an error that the policy package cannot be installed.
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
© FORTINET
3. Click OK.
4. Click Device Manager > Device & Groups > Managed FortiGate.
5. Click BR2-FGT-1 > CLI Configurations > firewall > policy.
6. Delete the policies in the device layer that are using the To_hub interface.
7. Click OK.
8. Click Network > Static Routes.
9. Delete the static routes that the IPsec template generated in the device layer.
© FORTINET
13. Click OK.
14. Click VPN > IPsec Phase 2.
15. Delete the IPsec Phase 2 that FortiManager created.
© FORTINET
4. Click OK.
You do not need to delete the firewall policies in the policy layer because you have
deleted policies in the BR policy package in previous steps.
7. Click OK.
8. Click CLI Configurations > firewall > address.
9. Delete the To_hub_remote_subnet_1 address in the device layer.
© FORTINET
© FORTINET
You can connect to the Core1, BR2-FGT-1, and BR3-FGT-1 GUI to confirm that all
objects related to the IPsec template have been deleted.
You will modify the IPsec VPN configuration to enable auto-discovery VPN (ADVPN). You will create an on-
demand tunnel between the two spokes. You will configure IBGP with route reflector enabled on the hub device to
manage the routing.
Objectives
l Configure ADVPN using IPsec templates in a hub-and-spoke topology using IBGP as dynamic routing
l Configure ADVPN using IPsec templates in a dual hub-and-spoke topology using IBGP and EBGP as dynamic
routing
Time to Complete
Estimated: 45 minutes
Prerequisites
Before you begin this lab, you must force HQ-NGFW-1 to be the primary FortiGate. Then, you must restore the
initial configuration files on FortiManager, BR2-FGT-1, BR3-FGT-1, and HQ-NGFW-1. The configuration files are
located on HQ-PC-1.
You must restore the configuration files in the recommended order (FortiManager,
BR2-FGT-1, BR3-FGT-1, and then HQ-NGFW-1) to keep the synchronization with the
FortiManager at the end.
© FORTINET
To restore the FortiManager configuration file
1. On HQ-PC-1, open a browser.
2. Connect to the HQ-FMG-1 GUI, and then log in with the following credentials:
l Username: admin
l Password: Fortinet1!
3. Click root.
4. In the System Information widget, in the System Configuration field, click the Restore icon.
© FORTINET
l Username: admin
l Password: Fortinet1!
3. In the upper-right corner, click admin, and then click Configuration > Restore.
4. Click Local PC, and then click Upload.
5. Click Desktop > Resources > Enterprise-FW > ADVPN > Starting_Point, select BR3-FGT-1_ADVPN_
initial.conf, and then click Select.
6. Click OK.
7. Click OK to reboot.
After the reboot, you can verify that HQ-NGFW-1 remains the primary FortiGate.
In this exercise, you will configure ADVPN in a hub-and-spoke topology. You will use Core1 as a hub, and BR2-
FGT-1 and BR3-FGT-1 as spokes.
You will configure IPsec templates for Core1, BR2-FGT-1, and BR3-FGT-1.
© FORTINET
Field Value
6. Click OK.
7. Click Create New, and then in the Name field, type Local_ID.
8. In the Per-Device Mapping section, configure the following settings:
Field Value
© FORTINET
9. Click OK.
10. Click Policy & Objects > Advanced > Metadata Variables.
11. Select Router_ID, and then click Edit.
12. In the Per-Device Mapping section, configure the following settings:
Field Value
© FORTINET
© FORTINET
Field Value
5. Click OK.
6. Right-click the Hub_overlay1 template, and then select Edit.
7. Right-click the VPN1 template, and then select Edit.
8. Disable Mode Config.
9. In the Transport field, select UDP.
10. In the Tunnel Interface Setup section, configure the following settings:
© FORTINET
Field Value
IP 172.16.1.1/255.255.255.255
Remote IP 172.16.1.254/255.255.255.0
Field Value
Local ID $(Local_ID)
© FORTINET
3. Click OK.
4. Right-click the Branches_overlay1 template, and then select Edit.
5. Right-click HUB1-VPN1, and then select Edit.
6. Disable Mode Config.
7. In the Transport field, select UDP.
Field Value
IP $(Tunnel_IP)
Remote IP 172.16.1.1/255.255.255.0
9. Click OK.
10. Click OK.
© FORTINET
11. Right-click the Branches_overlay1 template, and then select Assign to Device/Group.
12. In the Available Entries field, select the BR2-FGT-1 and BR3-FGT-1 checkboxes, and then move them to the
Selected Entries field.
13. Click OK.
If the BGP section is not available, you can enable BGP in the Feature Visibility
section.
© FORTINET
Field Value
Name Hub_overlay1
Local As 65100
Router ID 172.16.1.1
Field Value
Name Overlay1
Remote AS 65100
6. Click OK.
© FORTINET
Field Value
Prefix 172.16.1.0/255.255.255.0
8. Click OK.
9. In the Networks field, type 10.0.12.0/255.255.255.0.
Field Value
Name Branches_overlay1
Local As 65100
Router ID $(Router_ID)
© FORTINET
Field Value
IP 172.16.1.1
Remote AS 65100
3. Click OK.
5. Click OK.
6. Right-click the Branches_overlay1 template, and then select Assign to Device/Group.
7. In the Available Entries field, select the BR2-FGT-1 and BR3-FGT-1 checkboxes, and then move them to the
Selected Entries field.
8. Click OK.
© FORTINET
You will run scripts to create policies in the Core1 and BR policy packages. Then, you will install the policies.
© FORTINET
© FORTINET
Bring Up the On-Demand Tunnel
Before you generate traffic to trigger the on-demand tunnel, it is a good idea to verify that the IPsec VPN tunnels
are up and the BGP route databases are in sync.
BGP may take about 1 minute to establish and advertise the routes. You can enter the
get router info routing-table bgp command again to refresh the BGP
routing table.
Core1 has learned BGP network segments through IBGP (AS 65100). You should see the network segment
172.20.2.0/24 (from BR2-FGT-1) and 172.20.3.0/24 (from BR3-FGT-1).
Notice that the tunnels are connected to IP addresses 100.65.2.112 (BR2-FGT-1) and 100.65.3.113
(BR3-FGT-1).
© FORTINET
l Username: admin
l Password: Fortinet1!
4. Enter the following commands:
get router info routing-table bgp
get vpn ipsec tunnel summary
© FORTINET
get router info routing-table bgp
get vpn ipsec tunnel summary
The ADVPN tunnel has been created with the IP address 100.65.3.113 and the next hop is 172.16.1.3.
Prerequisites
You must unassign the IPsec templates from the previous exercise.
© FORTINET
Configure ADVPN IBGP and EBGP
You will run a script to enable ADVPN IBGP and EBGP on Core1, Core2, BR2-FGT-1, and BR3-FGT-1.
Field Value
6. Click OK.
7. In the Per-Device Mapping field, click Create New.
8. Configure the following settings:
© FORTINET
Field Value
9. Click OK.
Field Value
© FORTINET
Field Value
You may edit the ADVPN_Core1_ex2 and ADVPN_Core2_ex2 scripts to view the
configurations applied.
© FORTINET
To install policies on Core1, Core2, BR2-FGT-1, and BR3-FGT12
1. Continuing on the FortiManager GUI, click Device Manager > Device & Groups > Managed FortiGate.
2. Select the Core1 and Core2 checkboxes.
3. Click Install, and then click Reinstall policy.
4. Verify that Core1 and Core2 are selected, and then click Next.
5. Click Finish.
6. Select the BR2-FGT-1 and BR3-FGT-1 checkboxes, and then click Install Wizard.
7. In the Choose What To Install (1/4) window, select Install Policy Package & Device Settings.
8. In the Policy Package field, select BR, and then click Next.
9. In the Select Devices to Install (BR) (2/4) window, click Next.
10. In the Validate Devices (BR) (3/4) window, make sure that BR2-FGT-1 and BR3-FGT-1 are selected, and then
click Install.
11. In the Installation progress (4/4) window, click Finish.
12. Click Device Manager > Scripts.
13. Right-click the HQ_NGFW_reinitialize script, and then click Run Script.
14. In the Available Entries field, select the HQ-NGFW checkbox, and then move it to the Selected Entries field.
15. Click Run Now.
16. Click OK.
17. Click Close.
After updating the configurations from the previous exercise, you must reboot HQ-
NGFW before checking ADVPN.
Before you generate traffic to trigger the on-demand tunnel, it is a good idea to verify that the VPN IPsec tunnels
are up and the BGP route databases are in sync.
© FORTINET
Notice that you do not need to change VDOMs to use the get, show, diagnose, or
execute commands. You can see more details in the following image:
© FORTINET
l Username: admin
l Password: Fortinet1!
7. Enter the following commands:
get router info routing-table bgp
get vpn ipsec tunnel summary
BGP may take around one minute to establish and advertise the routes. You can type
again get router info routing-table bgp to refresh the BGP routing table.
© FORTINET
The ADVPN tunnel has been created with the IP address 100.65.3.113 and the next hop is 172.16.2.2,
using a different network segment from AS 65100.
In this lab, first, you will learn how to configure the Fortinet Security Fabric to enable SAML SSO. Next, you will
configure automation for configuration backups. Finally, you will also create a Security Fabric automation to run
CLI scripts if a configuration change occurs.
Objectives
l Use the Security Fabric to enable SAML SSO on all devices
l Use Security Fabric automation for automatic configuration backups
l Use Security Fabric automation to generate CLI scripts
Time to Complete
Estimated: 55 minutes
In this exercise, you will configure the Security Fabric with SAML SSO in the lab network.
You will configure the root FortiGate in the Security Fabric to be the identity provider (IdP).
5. In the Security Fabric Settings window, in the Security Fabric role field, select Serve as Fabric Root.
6. In the Allow other Security Fabric devices to join field, select port5.
7. Click Close.
8. In the Fabric name field, type fortinet.
9. Enable SAML Single Sign-On.
10. In the IdP certificate field, select Fortinet_CA_SSL.
11. In the IdP address field, select Specify, and then in the field, type 10.0.12.254:443.
© FORTINET
Field Value
Username AdminSSO
password password
4. Click OK.
The result should look similar to the following image:
© FORTINET
You will configure HQ-DCFW as one of the branches of the Security Fabric tree with SAML SSO.
Field Value
© FORTINET
6. Click OK.
7. Click OK to confirm.
HQ-NGFW-1 lists the HQ-DCFW as part of the Security Fabric. It may take a few minutes to authorize. You
may need to refresh the page.
© FORTINET
Configure the Security Fabric on HQ-ISFW
You must configure the Security Fabric on HQ-ISFW with SAML SSO and authorize it on HQ-NGFW-1.
Field Value
If you require assistance, or to verify your work, use the step-by-step instructions that follow.
After you complete the challenge, see Access Security Fabric Devices With SAML SSO on page 194.
Field Value
© FORTINET
5. Click OK.
6. Click OK to confirm.
© FORTINET
To access HQ-DCFW using SAML SSO
1. Connect to the HQ-PC-2 VM.
2. Open a browser, and then enter https://10.0.12.253.
© FORTINET
You are logged in to HQ-DCFW at the IP address 10.0.12.253 with the newly
created SSO administrator, AdminSSO.
On the root FortiGate, HQ-NGFW-1, you configured the AdminSSO administrator with the super_admin_
readonly profile. Why is HQ-DCFW showing AdminSSO with the super_admin profile?
When you configured the Security Fabric on HQ-DCFW, you selected super_admin in the Default admin
profile field. This configuration on the downstream FortiGate takes precedence over the configuration from
the root FortiGate.
© FORTINET
In the Security Fabric configuration on HQ-ISFW, you specified the management IP address as
10.0.2.254. After Security Fabric SAML SSO, this IP address must be reachable, along with the
corresponding administrative access.
© FORTINET
This is because you selected the super_admin_readonly administration profile in the Security Fabric
configuration on HQ-ISFW.
You will configure a Security Fabric automation on FortiManager to create automatic configuration backups.
On FortiManager, you will create the Fabric ADOM and move the Security Fabric devices into it.
6. Select the checkboxes for HQ-NGFW, HQ-ISFW, and HQ-DCFW, and then click Add to ADOM.
The result should be similar to the following image:
© FORTINET
7. Click OK.
On FortiManager, you will configure the trigger and action to create an automatic configuration backup stitch.
© FORTINET
You may notice that fortinet is listed in the Device Name column. This confirms that
all the devices nested under fortinet belong to the same Security Fabric environment.
If fortinet is not listed, you must retrieve the HQ-NGFW configuration to update
FortiManager with the Security Fabric environment.
By default, the Security Fabric options are not available. You must enable them in the
Feature Visibility section.
4. On the Customize tab, in the Security Fabric section, select the checkboxes for Automation Stitch,
Automation Trigger, and Automation Action.
© FORTINET
5. Click OK.
6. Click Managed FortiGate > HQ-NGFW > Security Fabric, and then select Automation Trigger.
Field Value
Name Frequency
Type Schedule
Frequency Hourly
For example, if the current time is 12:35 PM, you would add 10 minutes, and
then type 45 in the Minute field (12:35 + 10 minutes = 12:45).
Your configuration should look similar to the following image (with a value in the Minute field that is based on
your current time):
© FORTINET
When you set the Frequency field to Hourly, the stitch is triggered every hour when
the minutes match the number that is configured in the Minute field. You then have 10
minutes before the next stitch occurrence for the purposes of this lab.
8. Click OK.
Field Value
Name Automatic_Backup
© FORTINET
3. Click OK.
Field Value
Name Backup_Stitch
Trigger Frequency
3. Click OK.
© FORTINET
Verify the Stitch on the Security Fabric Devices
You will install the stitch on the root FortiGate and verify the automatic configuration backup.
© FORTINET
In the Date/Time column, you can see that the stitch is triggered a few seconds after
the minutes configured in the automation trigger.
© FORTINET
The same automatic configuration backups are available on the other downstream
FortiGate devices because you configured the stitch to all FortiGates.
In this exercise, you will configure the automation stitch on FortiManager to take CLI commands from a script and
email the results.
On FortiManager, you will verify the preconfigured trigger based on configuration changes, create an action to
take CLI commands with a script, create an action to email the script results, and then add them to a stitch.
7. Click Cancel.
Field Value
Name Alert_Script
© FORTINET
Field Value
exec time
3. Click OK.
Field Value
Name Configuration_Change_Alert
Type Email
From [email protected]
© FORTINET
Field Value
Body %%results%%
4. Click OK.
Field Value
Name Config_Change_Alert
Delay 10
You must click + in the Action column to create a second action object.
© FORTINET
Your configuration should look like the following image:
3. Click OK.
You will test the automation stitch by forcing a configuration change on HQ-NGFW-1, and then view the email
alert.
An SMTP mail server is required for email alerts to operate. Because configuring a mail
server is out of scope for this lab, one was configured for you. You can view the email
service configuration on the HQ-NGFW-1 GUI by clicking System > Settings, and
then scrolling down to the Email Service configuration.
© FORTINET
l Username: admin
l Password: Fortinet1!
4. Click Login Read-Write, and then click Yes.
5. Click VDOM: Global, and then click Core1.
6. Click Network > Diagnostics.
7. In the Packet capture window, click New packet capture.
Field Value
Interface port2
Name Email
Filters Enabled
Host 100.65.0.254
Port 25
© FORTINET
© FORTINET
On the HQ-PC-1 VM, Wireshark allows you to open the Email.pcap file.
15. Right-click the first SYN packet, and then click Follow > TCP Stream.
The email header should look similar to the following example:
In this lab, you will configure Fortinet devices based on requirements that a customer has provided. The lab is
preconfigured with IP addresses.
Objectives
l Complete all tasks to configure the network based on the customer requirements
Time to Complete
Estimated: 150 minutes
In the second exercise, you will implement ADVPN on HQ-NGFW with BR2-FGT-1 and BR3-FGT-1 as spokes.
In the third exercise, you will implement the Fortinet Security Fabric to create an automatic backup.
© FORTINET
Prerequisites
Before you begin this lab, you must restore the initial configuration files on the Fortinet devices. The configuration
files are located on the desktop of HQ-PC-1.
After the reboot, you can adjust the override setting and the HA priority on HQ-NGFW-
1 and HQ-NGFW-2, so HQ-NGFW-1 remains the primary FortiGate.
© FORTINET
4. In the upper-right corner, click admin, and then click Configuration > Restore.
5. Click Local PC, and then click Upload.
6. Click Desktop > Resources > Enterprise-FW > Use_Case, select HQ-ISFW_Use_Case_initial.conf, and
then click Select.
7. Click OK.
8. Click OK to reboot.
© FORTINET
After you restore the database on HQ-FMG-1, you must disable offline mode in
System Settings > Advanced > Misc Settings.
In this exercise, you will configure the enterprise network based on the following basic customer requirements:
l Implement segmentation on the HQ-PC-3 HR network.
l Add dynamic routing.
l Allow the HR segment to access the internet and HQ-Web-1.
Network Topology
Review the current configuration, as shown in the following image, before you proceed to the next section:
The OSPF area 0.0.0.0 is already configured and includes HQ-DCFW, the Core1
VDOM, and the HQ-ISFW root VDOM.
© FORTINET
Requirements
You may use the HQ-ISFW_root and HQ-ISFW_Zone2 scripts to configure the
corresponding policy packages.
Make sure you complete all the configuration steps before you test the configuration.
© FORTINET
l On HQ-DCFW, you must have the 10.0.3.0/24 subnet learned with the OSPF protocol in the routing table.
The output should be similar to the following example:
In this exercise, you will configure the enterprise network based on the following basic customer requirements:
l Implement a VPN with HQ-NGFW as a hub, and BR2-FGT-1 and BR3-FGT-1 as spokes.
l Implement ADVPN on the hub and spokes.
l Allow traffic between the hub and spokes.
l Implement IBGP on the hub and spokes.
Network Topology
Review the current configuration, as shown in the following image, before you proceed to the next section:
Requirements
To implement a VPN with HQ-NGFW as a hub, and BR2-FGT-1 and BR3-FGT-1 as spokes
l Create a VPN tunnel as a hub on the Core1 VDOM.
l Create the corresponding VPN tunnels as spokes on BR2-FGT-1 and BR3-FGT-1.
© FORTINET
To allow traffic on the hub
l Allow traffic from the spokes to the Core1 VDOM.
l Allow traffic from the Core1 VDOM to the spokes.
l Allow traffic between the spokes.
Make sure you complete all the configuration steps before you test the configuration.
© FORTINET
© FORTINET
With the ping option, you generate a ping from the BR2-FGT-1 internal interface to the
BR3-FGT-1 internal interface to bring up the on-demand tunnel.
l On BR3-FGT-1, in the routing table, you must see the BR2-FGT-1 internal subnet 172.20.2.0/24 directly
connected with the on-demand tunnel.
The output should look similar to the following example:
In this exercise, you will configure the enterprise network based on the following basic customer requirements:
l Implement the Security Fabric within the LAN FortiGate devices.
l Implement the automatic configuration backup of the devices in the Security Fabric environment.
Network Topology
Review the current configuration, as shown in the following image, before you proceed to the next section:
Requirements
Log in to the FortiManager GUI and ensure that HQ-NGFW, HQ-DCFW, and HQ-ISFW
are in the EFW_Use_Case ADOM.
© FORTINET
To achieve automatic configuration backup
l Select the automation trigger based on configuration changes.
l Configure the automation action configuration backup.
l Create the stitch based on the automation trigger and action that you configured.
Make sure you complete all the configuration steps before you test the configuration.
© FORTINET
5. On HQ-DCFW, click Log & Report > System Events > Logs.
6. Confirm that you see the Configuration changed stitch and Automation stitch triggered event logs.
The output should be similar to the following image:
No part of this publication may be reproduced in any form or by any means or used to make any
derivative such as translation, transformation, or adaptation without permission from Fortinet Inc.,
as stipulated by the United States Copyright Act of 1976.
Copyright© 2025 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet,
Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company
names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and
actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein
represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written
contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified
performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For
absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate.
Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify,
transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.