Fortinet SD Wan Lab Guide For Fortios 72
Fortinet SD Wan Lab Guide For Fortios 72
© FORTINET
SD-WAN
Lab Guide
for FortiOS 7.2
DO NOT REPRINT
© FORTINET
Fortinet Training Institute - Library
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
3/30/2023
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
Network Topology 6
Lab 1: Basic DIA Setup 7
Exercise 1: Configuring a Basic DIA Setup 8
Configure a Zone and Members for DIA 8
Configure a Performance SLA 9
Configure Rules 11
Configure a Static Route and Firewall Policy 15
Exercise 2: Monitoring DIA Traffic 18
Generate Internet Traffic From branch1_client 18
Monitor DIA Traffic Distribution 19
Bring Down port1 21
Monitor SD-WAN Events and Traffic Logs 21
Bring Up port1 24
Lab 2: Centralized Management 25
Exercise 1: Configuring SD-WAN on FortiManager 28
Add branch1_fgt and branch2_fgt to FortiManager 28
Import SD-WAN Settings Into the SD-WAN Template 31
Configure the SD-WAN Template 33
Configure the Device Settings and Policy Package 40
Install the Device Settings and Policy Package 45
Verify Installed Settings and Logging 47
Exercise 2: Monitoring DIA Traffic on FortiManager 50
Generate Internet Traffic From branch1_client and branch2_client 50
Monitor DIA Traffic Distribution 50
View Traffic Logs 54
Exercise 3: Configuring an IPsec VPN Using the FortiManager IPsec
Recommended Templates 57
Add dc1_fgt to FortiManager 57
Configure Mappings for dc1_fgt 58
Create VPN IPsec Hub and Spoke Configurations With Recommended Templates 59
Create a CLI Template for Advanced IPsec Parameters 62
Install the VPN Configuration 63
Map the VPN Interfaces 63
DO NOT REPRINT
© FORTINET
Configure the Firewall Policies 64
Configure a Static Route on the Branches 68
Configure FortiAnalyzer Logging on dc1_fgt 69
Install the Configuration on Devices 69
Exercise 4: Verifying the IPsec VPN 71
Verify That the Tunnels Are Up 71
Verify Connectivity Across the VPN 73
Exercise 5: Configuring the Overlay With the SD-WAN Overlay Template 75
Configure the Overlay With the SD-WAN Overlay Template 77
Review and Install the Overlay the SD-WAN Overlay Template Created 81
Lab 3: Members, Zones, and Performance SLAs 85
Exercise 1: Configuring SD-WAN Zones and Members 88
Review the VPN Tunnels and Their Status 88
Configure an SD-WAN Zone 90
Configure VPN Tunnels as SD-WAN Members 91
Configure an SD-WAN Rule for the Overlays 95
Verify the Overlays as SD-WAN Members 96
Exercise 2: Using Ping to Actively Monitor the Overlays 100
Configure an Active Performance SLA (Ping) 100
Verify the Health of the Overlays 102
Exercise 3: Testing an Active Performance SLA 108
Monitor a Performance SLA on the FortiGate CLI 108
Test the Performance SLA 109
Exercise 4: Using HTTP to Actively Monitor the Overlays 115
Configure an Active Performance SLA (HTTP) 115
Verify the Health of the Overlays 117
Lab 4: Routing and Sessions 122
Exercise 1: Troubleshooting Spoke-to-Spoke Traffic (Single Hub) 124
Configuration 124
Problem Description 124
Objective 125
Solution Requirements 125
Tips for Troubleshooting 125
Solution 127
Exercise 2: Troubleshooting DIA Traffic 128
Configuration 129
Problem Description 129
Objective 130
Solution Requirements 130
Tips for Troubleshooting 130
Solution 132
DO NOT REPRINT
© FORTINET
Lab 5: Rules 133
Exercise 1: Configuring and Testing Rule Strategies 136
Configure and Test a Best Quality Rule 136
Configure and Test a Lowest Cost (SLA) Rule 141
Configure and Test a Maximize Bandwidth (SLA) Rule 145
Exercise 2: Troubleshooting Rules 151
Configuration 152
Problem Description 152
Objective 153
Solution Requirements 153
Tips for Troubleshooting 153
Solution 155
Lab 6: SD-WAN Overlay Design and Best Practices 156
Exercise 1: Configuring Overlays and BGP 159
Configure Overlay Addresses and Basic BGP 159
Fine-Tune IPsec and BGP 164
Exercise 2: Configuring FEC and Packet Duplication 168
Configure FEC 168
Configure Packet Duplication 171
Exercise 3: Configuring ADVPN 178
Configure Basic ADVPN 178
Configure an Idle Timeout for ADVPN 186
Lab 7: SD-WAN Monitoring With FortiAnalyzer 188
Exercise 1: Monitoring SD-WAN With FortiAnalyzer 191
Confirm Log Forwarding on the FortiGate Devices 191
Analyze Traffic Logs 192
Analyze Event Logs 196
Discover the Secure SD-WAN Monitor Page 199
Discover the SD-WAN Summary Page 201
DO Network
NOTTopology
REPRINT
© FORTINET
Network Topology
In this lab, you will configure the following basic SD-WAN direct internet access (DIA) setup on branch1_fgt:
After that, you will generate internet traffic on branch1_client and monitor the traffic distribution and events on the
FortiGate GUI.
Objectives
l Configure a basic SD-WAN DIA setup
l Configure route and firewall policies for SD-WAN
l Verify SD-WAN traffic distribution and events
Time to Complete
Estimated: 50 minutes
In this exercise, you will configure a basic DIA setup using the FortiGate GUI. You will create a zone for port1 and
port2 on branch1_fgt, and then configure SD-WAN rules to steer traffic for critical and non-critical internet
applications.
You will configure the underlay zone, and then add port1 and port2 as members.
Field Value
Interface port1
© FORTINET
7. Click OK to save the settings.
8. Repeat the previous steps to add port2 as an SD-WAN member and assign it to the same zone (underlay).
9. On the SD-WAN Zones tab, expand the underlay zone.
Your page should look similar to the following example:
You didn't configure the gateway for each member. Yet, FortiGate is displaying them correctly. Why?
When you added port1 and port2 as SD-WAN members, you selected Dynamic for the Gateway setting.
This instructs FortiGate to automatically retrieve the member gateway address. Because port1 and port2
are both configured as DHCP interfaces, FortiGate uses the gateway assigned over DHCP.
You will configure a performance SLA for monitoring the health of port1 and port2.
Field Value
Name Level3_DNS
Server 4.2.2.1
© FORTINET
Field Value
6. Click Dashboard > Network, and then click the Routing widget.
Your page should look similar to the following example:
© FORTINET
There are no routes to 4.2.2.1 and 4.2.2.2, yet the performance SLA shows that port1 and port2 are up.
Why?
To route the health check probes, FortiOS installs special routes in the FIB using the gateway information of
members. These routes are not displayed in the routing table, but you can use the get router info
kernel CLI command to see them.
Configure Rules
You will configure two SD-WAN rules. One rule will be used to steer the traffic of critical applications. The other
rule will be used to steer the traffic of non-critical applications. Both rules will use manual mode.
By default, application detection for SD-WAN rules is not visible on the GUI. Before you can configure SD-WAN
rules to steer traffic per application, you must enable GUI visibility with CLI commands.
To view the application field on the GUI, you must refresh the browser page.
Alternatively, you can log out of the GUI, and then log in again.
To configure rules
1. Return to the branch1_fgt GUI, and then refresh the browser page.
2. Click Network > SD-WAN, and then click the SD-WAN Rules tab.
© FORTINET
3. Click Create New to add a rule.
4. Configure the following settings:
Field Value
Name Critical-DIA
Your page should look similar to the following example. Note that you might not be able to view the application
icons at this stage.
© FORTINET
Field Value
Name Non-Critical-DIA
© FORTINET
© FORTINET
port1 is the preferred member for rule ID 1, and port2 is the preferred member for rule
ID 2.
You will configure a static route and firewall policy for routing and allowing SD-WAN traffic. Both objects will
reference the underlay zone.
Field Value
Name DIA
Source LAN-net
Destination all
Schedule always
© FORTINET
Field Value
Service ALL
NAT Enable
Log Allowed Traffic Enable this setting, and then select All Sessions.
© FORTINET
In this exercise, you will generate internet traffic from branch1_client. Next, you will monitor DIA traffic distribution
and logs using the SD-WAN tools available on the FortiGate GUI.
You will generate internet traffic from branch1_client using the traffic generator tool.
© FORTINET
Monitor DIA Traffic Distribution
You will use the SD-WAN page on the FortiGate GUI to monitor the DIA traffic distribution. Next, you will view the
traffic logs to obtain additional details.
4. Hover over each graph to display the bandwidth that each member (port1 and port2) uses.
5. Click the Volume and Sessions graphs to explore them.
3. Click the gear icon, and then click Destination Interface, SD-WAN Quality, and SD-WAN Rule Name.
4. Click Apply to save the settings.
Your page should look similar to the following example:
© FORTINET
You may notice that, initially, traffic for some applications doesn't match the expected
rule. This is because of the application learning phase, which you will learn more about
in another lab. However, eventually, traffic should end up matching the expected rule.
Logs for all other traffic (DNS, HTTP_BROWSER, and so on) show no information in the SD-WAN Quality
and SD-WAN Rule Name columns. Why?
The traffic doesn't match any of the configured SD-WAN rules. As a result, it matches the implicit SD-WAN
rule. The SD-WAN implicit rule load balances sessions based on the FIB contents.
All other traffic is always forwarded to the same port (this can be port1 or port2). The implicit rule is not load
balancing the traffic. Why?
By default, the implicit rule load balances the traffic based on the source IP address of the connection.
Because all traffic is sourced from the same IP address (branch1_client), the selected outgoing interface is
always the same. You will learn more about implicit rule load balancing in another lab.
© FORTINET
Bring Down port1
You will bring down port1 to force FortiGate to forward all internet traffic to port2.
3. On the branch1_fgt GUI, click Network > SD-WAN, and then click the Performance SLAs tab.
port1 is down (red down arrow). Your page should look similar to the following example:
You will review SD-WAN events and traffic logs triggered by the previous action.
4. Double-click the log with the SD-WAN health-check member changed state message to see the log details.
Your page should look similar to the following example:
© FORTINET
5. Double-click the log with the Service will be redirected in sequence order message to see the log details.
Your page should look similar to the following example:
© FORTINET
The log indicates that the Critical-DIA rule (ID 1) was updated. The new sequence
(outgoing interface list) now contains member ID 2 only (port2). You will learn more
about the outgoing interface list in another lab.
© FORTINET
Bring Up port1
You will bring up port1 and confirm that the original traffic distribution is restored.
To bring up port1
1. Continuing on the WAN simulator HTTP interface, scroll up and locate BR1-ISP1.
2. Click UP to bring up the link on port1 on branch1_fgt.
In this lab, you will configure the same DIA SD-WAN setup you configured on branch1_fgt, on branch2_fgt. For
this, you will import existing SD-WAN settings on branch1_fgt to an SD-WAN template on FortiManager. You will
then use the SD-WAN template to deploy DIA on branch2_fgt. You will also monitor DIA traffic on FortiManager.
After that, you will use IPsec recommended templates on FortiManager to deploy the following hub-and-spoke
dial-up IPsec VPN topology:
In the topology, branch1_fgt and branch2_fgt are dial-up clients, and dc1_fgt is a dial-up server. You will use static
routing for the VPN, and you will also verify that the tunnels come up and that there is spoke-to-hub and spoke-to-
spoke connectivity.
Note that you will deploy overlays for one underlay only (ISP1). You can follow the same procedure for overlays
established over the other underlays (ISP2 and MPLS), but these will be automatically configured for you in
another lab. Also note that there is no separate FortiAnalyzer. Instead, you will configure devices to send logs to
FortiManager, which has the FortiAnalyzer features enabled.
Objectives
l Add all devices to FortiManager
l Deploy DIA using central management (SD-WAN templates)
© FORTINET
l Configure firewall policies, static routes, normalized interfaces, metadata variables, and firewall address objects to
deploy SD-WAN and the VPN
l Monitor SD-WAN on FortiManager
l Configure a hub-and-spoke dial-up IPsec VPN using IPsec recommended templates
l Use the SD-WAN overlay template to configure IPsec VPN tunnels for the overlay and BGP routing
Time to Complete
Estimated: 135 minutes
In this exercise, you will add branch1_fgt and branch2_fgt to FortiManager. Next, you will create an SD-WAN
template with settings imported from branch1_fgt. Finally, you will use the template to deploy DIA on branch2_fgt.
Field Value
IP Address 192.168.0.31
Password password
4. Click Next.
5. Click Next, and then wait until the Add Device task is completed.
6. Click Import Now.
7. Select Import Policy Package, and then click Next.
8. In the Policy Package Name field, type branches_pp.
9. In the port5 device interface settings, in the Mapping Type column, select Per-Device, and then in the
Normalized Interface column, type LAN.
© FORTINET
15. Repeat steps 2–5 for branch2_fgt, but use the IP address 192.168.0.32 and the same administrator credentials.
16. Click Import Later.
© FORTINET
You don't need to import policies and objects from branch2_fgt because you will push
them from FortiManager.
17. Click Device & Groups > Managed FortiGate to display the list of managed devices.
18. Drag and drop the Policy Package Status and Provisioning Templates columns to the right of the Config
Status column so you can see them without having to scroll to the right.
Your page should look similar to the following example:
© FORTINET
Import SD-WAN Settings Into the SD-WAN Template
First, you will view the current SD-WAN settings on branch1_fgt (per-device management), and then you will
import the settings into an SD-WAN template for central SD-WAN management purposes.
© FORTINET
© FORTINET
The Gateway setting for port1 and port2 is set to 0.0.0.0. You will change this
setting to use metadata variables later in this lab.
2. Click More, and then select Import to import the settings into the template.
Field Value
Name branches
You will configure the template to use metadata variables for the gateway settings. After that, you will configure
branch1_fgt and branch2_fgt as the template targets.
© FORTINET
To configure metadata variables for the SD-WAN member gateway settings
1. Continuing on the FortiManager GUI, click Provisioning Templates > SD-WAN Templates.
2. Double-click branches to edit the template settings.
3. In the Interface Members section, double-click port1 to edit the member settings.
Field Value
Name sdwan_port1_gw
© FORTINET
Field Value
Per-Device Mapping Expand this section, click Create New, and then configure the following
settings:
1. In the Mapped Device field, select branch1_fgt (root).
2. In the Value field, type 192.2.0.2.
3. Click OK to save the settings.
Click Create New again, and then configure the following settings:
1. In the Mapped Device field, select branch2_fgt (root).
2. In the Value field, type 203.0.113.2.
3. Click OK to save the settings.
© FORTINET
Field Value
Name sdwan_port2_gw
Per-Device Mapping Expand this section, click Create New, and then configure the following
settings:
1. In the Mapped Device field, select branch1_fgt (root).
2. In the Value field, type 192.2.0.10.
3. Click OK to save the settings.
The Interface Members section of your template should look similar to the following example:
© FORTINET
11. Click OK to save the template settings.
You don't. Your underlay members are configured as DHCP clients, and the member gateway setting was
configured for automatic detection. As a result, gateway detection was already working on branch1_fgt, and
would have also worked on branch2_fgt. However, it is important to know how to use metadata variables in
case the members require manual configuration.
1. Continuing on the FortiManager GUI, click Device Manager > Policy & Objects.
2. Select Tools > Feature Visibility.
You can now manage metadata variables by clicking Object Configurations > Advanced > Metadata
Variables.
© FORTINET
If you upgrade FortiManager from version 7.0 to version 7.2, the meta fields configured
are automatically converted to metadata variables. For reference, you can view meta
fields by clicking System settings > Advanced.
1. Continuing on the FortiManager GUI, click Object Configurations > Advanced > Metadata Variables.
2. Click Create New to create a new metadata variable.
3. In the Name field, type branch_id.
4. Expand the Per-Device Mapping section.
5. Configure the following settings to create branch ID entries for branch1_fgt and branch2_fgt:
Field Value
Value 1
Value 2
© FORTINET
Field Value
Name Branch_Local_Subnet
Per-Device Mapping
Mapped Device Value
branch1_fgt(root) 10.0.1.0/24
branch2_fgt(root) 10.0.2.0/24
© FORTINET
3. Move branch1_fgt and branch2_fgt to the Selected Entries list.
First, you will configure a system template for enabling FortiAnalyzer logging on both branch1_fgt and branch2_
fgt. After that, you will configure a static default route for the underlay zone on branch2_fgt. Then, you will edit a
firewall address object for branch2_fgt. Finally, you will add branch2_fgt as a target for the branches_pp policy
package you imported from branch1_fgt.
Field Value
© FORTINET
Field Value
© FORTINET
2. Click Network > Static Route, and then click Create New > Static Route.
© FORTINET
© FORTINET
3. Double-click the LAN-net address object, and then configure the following settings:
Field Value
Per-Device Mapping table Click Create New, and then configure the following settings:
1. In the Mapped Device field, select branch2_fgt.
2. In the Map to Address IP/Netmask field, type 10.0.2.0/24.
3. Click OK to save the per-device mapping.
LAN-net is now a dynamic firewall address object. You added a per-device mapping
rule that FortiManager uses when it pushes the object to the managed devices. The
goal is for FortiManager to use the correct value based on the target device.
© FORTINET
2. Click Edit, and then move branch2_fgt to the Selected Entries list.
You will install the device settings and policy package on both branch1_fgt and branch2_fgt.
© FORTINET
The policy package references the LAN normalized interface. The normalized interface doesn't have a
mapping configured for branch2_fgt, which is why FortiManager requires you to configure it.
5. In the Device Interface field, select port5, and then click Validation.
6. Click Install to install the configuration on both devices.
7. Wait for the installation to finish.
Your page should look similar to the following example:
© FORTINET
8. Click Finish.
You will verify installed settings on branch1_fgt and branch2_fgt by connecting to them over SSH. After that, you
will verify that FortiManager is receiving logs from branch1_fgt and branch2_fgt.
© FORTINET
The green circle beside Real Time indicates that FortiManager is receiving logs from
the managed devices.
3. Click Device Manager > Log View, and then click Event > All Types.
Your page should look similar to the following example:
Serial numbers (Device ID column) of managed devices may be different in your lab.
4. In the upper-right corner, click the column setting icon, and then click More Columns.
© FORTINET
5. In the search box, type Device Name, and then select the Device Name checkbox in the list.
The logs now include the device name for easier identification.
In this exercise, you will first generate internet traffic from branch1_client and branch2_client. After that, you will
monitor DIA traffic distribution and logs using the SD-WAN tools available on FortiManager.
You will generate internet traffic from branch1_client and branch2_client using the traffic generator tool.
You will use the SD-WAN monitor on FortiManager to monitor the DIA traffic distribution on both devices.
© FORTINET
The port details show bandwidth is utilized, and that the member has active sessions. However, the upload
and download utilization bars show 0% for both FortiGate devices.
Why?
The usage percentage that appears on the bars is calculated based on the estimated-upstream-
bandwidth and estimated-downstream-bandwidth settings, which you haven't configured yet.
Because those settings are not configured, FortiManager doesn't know the bandwidth capacity of the ports,
and therefore, is unable to determine the usage percentage.
© FORTINET
The page shows the health check status for port1 and port2, the status of all
configured SD-WAN rules on branch2_fgt, and their preferred members. The page
also indicates the speed and amount of traffic measured on each port.
Note that, by default, FortiManager stores SD-WAN statistics over 10 minutes. If you
want to keep data over a longer period of time, you must enable this feature by
entering the following commands:
config system admin settings
set sdwan-monitor-history enable
end
© FORTINET
Value
Role WAN
Estimated Bandwidth In both the Kbps Upstream and Kbps Downstream fields, type 10240.
You can set the estimated bandwidth only for WAN interfaces. Therefore, you must set
the interface role before you can see the Kbps Upstream and Kbps Downstream
fields.
© FORTINET
The ports can handle more bandwidth than 10 Mbps, but you will use a lower
bandwidth value for now, so it's easier to see the change in the usage percentage.
If you require assistance, or to verify your work, review the procedure described previously in this exercise.
You will view the traffic logs on FortiAnalyzer (feature activated on FortiManager) to confirm SD-WAN is steering
traffic on both branch1_fgt and branch2_fgt.
© FORTINET
The serial numbers (Device ID column) of the managed devices may be different in
your lab.
2. In the upper-right corner, click the column setting icon, and then click More Columns.
Use the column settings search box to quickly find the columns.
© FORTINET
Your page should look similar to the following example:
If you want to display logs for a specific device, in the upper-left corner, click All
FortiGate to select the managed device you want to display logs for.
In this exercise, you will configure a hub-and-spoke dial-up IPsec VPN between branch1_fgt, branch2_fgt, and
dc1_fgt, using FortiManager IPsec recommended templates. You will configure dc1_fgt as a hub, and the other
two FortiGate devices as spokes. You will do the following:
Field Value
IP Address 192.168.0.41
Password password
4. Click Next.
5. Click Next, and then wait until the Add Device task is completed.
© FORTINET
6. Click Import Now.
7. Select Import Policy Package, and then click Next.
8. In the Policy Package Name field, type dc_pp.
9. Click Next.
10. Click Next, and then wait until the Import Device task is completed.
11. Click Finish.
12. Click Managed FortiGate to display the list of managed devices.
Your page should look similar to the following example:
You will configure a mapping on the LAN-net firewall address object for dc1_fgt. This mapping is required to define
the protected networks during the VPN configuration. You will also configure a mapping for the LAN normalized
interface.
© FORTINET
4. Click OK to save the settings.
You will use IPsec tunnel recommended templates to prepare a dial-up server for IPsec hub and IPsec
configuration for branch devices.
Field Value
© FORTINET
Field Value
8. Continuing on the VPN1 menu, edit the following settings for the phase2:
Field Value
Note that you can apply only one IPsec tunnel template per device. However, if you
want to configure multiple tunnels on one device, you can add tunnel instances to the
template.
© FORTINET
To create an IPsec tunnel template for branches
1. Select BRANCH_IPsec_Recommended.
2. Click More > Activate to start the template configuration wizard.
3. Configure the following settings:
Field Value
6. Double-click HUB1-VPN1, and then edit the following settings for the phase1:
Field Value
7. Continuing on the HUB1-VPN1 menu, edit the following settings for the phase2:
© FORTINET
Field Value
You will use a CLI template to define the local subnet as a phase2 source subnet. Because the local subnet is
different on each device, you will use metadata variables.
Field Value
© FORTINET
Field Value
4. Click OK to validate.
For the CLI script, when you type $, FortiManager automatically lists the available
metadata variables. You can then select Branch_Local_Subnet in the list.
5. Select the IPsec_P2_advanced template, and then assign it to branch1_fgt and branch2_fgt.
Before you create firewall policies, you must install the VPN settings on the FortiGate devices. This creates the
IPsec interfaces that are required for the firewall policies.
8. Click Finish.
Now that you have installed the VPN configuration on all the FortiGate devices, you will map the VPN interfaces to
a dynamic interface on FortiManager.
© FORTINET
4. In the Name field, type T_INET_0.
5. In the Per-Device Mapping section, click Create New, and then in the Mapped Device field, select dc1_fgt.
6. In the Mapped Interface Name field, select T_INET_0, and then click OK.
7. Repeat the previous steps to add the T_INET_0 per-device mapping for branch1_fgt and branch2_fgt.
Your page should look similar to the following example:
8. After you add the VPN interfaces mapping for all three FortiGate devices, click OK to validate the settings.
After you map the VPN interfaces, you can configure the firewall policies to allow IPsec traffic to pass.
© FORTINET
l Allow traffic from the branch to dc1_fgt
l Allow traffic from dc1_fgt to the branch
You will configure the following firewall policies on dc1_fgt:
l Allow traffic from the branches to dc1_fgt
l Allow traffic from dc1_fgt to the branches
l Allow traffic between the branches
Because the branches share the same policy package, you will create the firewall policies in one policy package
(branches_pp). Similarly, you will configure firewall policies for dc1_fgt in the dc_pp policy package. Then, you
will push the changes to all FortiGate devices.
Field Value
Name To Hub0-INET0
Source LAN-net
Destination all
Service ALL
Schedule always
Action Accept
Inspection-Mode Flow-based
NAT Disable
Logging Options Enable Log Allowed Traffic, and then select All Sessions.
5. Click OK.
6. Right-click the To Hub0_INET0 policy you created, and then select Clone Reverse to create a similar policy in the
reverse direction.
© FORTINET
7. Double-click the policy that the clone reverse function created, and then in the Name field, type From Hub0-
INET0.
8. Ensure that the policy has the following settings:
Field Value
Source all
Destination LAN-net
Service ALL
Schedule always
Action Accept
Inspection-Mode Flow-based
NAT Disable
Logging Options Enable Log Allowed Traffic, and then select All Sessions.
9. Click OK.
© FORTINET
Field Value
Name To Branch-INET0
Source LAN-net
Destination all
Service ALL
Schedule always
Action Accept
NAT Disable
Logging Options Enable Log Allowed Traffic, and then select All Sessions.
5. Click OK.
6. Right-click the To Branch-INET0 policy you created, and then select Clone Reverse to create a similar policy in
the reverse direction.
7. Double-click the policy that the clone reverse function created, and then in the Name field, type From Branch-
INET0.
8. Ensure that the policy has the following settings:
Field Value
Source all
Destination LAN-net
Service ALL
Schedule always
Action Accept
NAT Disable
Logging Options Enable Log Allowed Traffic, and then select All Sessions.
© FORTINET
9. Click OK.
10. Click Create New again.
11. Configure the following settings:
Field Value
Source all
Destination all
Service ALL
Schedule always
Action Accept
NAT Disable
Logging Options Enable Log Allowed Traffic, and then select All Sessions.
You will configure a static route for the VPN traffic on the branches. You don't need to configure static routes on
dc1_fgt because these will be automatically installed by IKE after the tunnel comes up.
Field Value
© FORTINET
Configure FortiAnalyzer Logging on dc1_fgt
You will add dc1_fgt as a target in the corp_st system template you configured for the branches.
You will install the policy package on each device. For branch1_fgt and branch2_fgt, you will also install the static
routes. For dc1_fgt, you will also install the FortiAnalyzer logging settings.
7. Click Finish.
7. Click Finish.
8. Click Policy & Objects > Device Manager > Device & Groups, and then click Managed FortiGate to display the
list of managed devices.
Your page should look similar to the following example:
© FORTINET
All managed devices are synchronized and logging to FortiManager. You will verify
tunnels and connectivity in the next exercise.
In this exercise, you will verify that the IPsec tunnels you configured using IPsec tunnel templates came up. After
that, you will test connectivity across the tunnels by generating spoke-to-hub and spoke-to-spoke traffic.
You will verify that the tunnels are up using FortiManager and the FortiGate CLI.
© FORTINET
© FORTINET
The tunnels are up and the static routes were installed. On dc1_fgt, the static routes
were automatically installed by FortiOS based on the remote protected network:
10.0.1.0/24 for branch1_fgt and 10.0.2.0/24 for branch2_fgt.
You will test connectivity across the tunnels by generating spoke-to-hub and spoke-to-spoke traffic.
© FORTINET
In this exercise, you will use the SD-WAN overlay template to configure IPsec VPN tunnels for the overlay and
BGP for routing on the overlay. The template will guide you and prepare, with the elements you provide, a
configuration that follows Fortinet recommendations. You will start from the following configuration, which is
similar to the one you reached at the end of exercise 2, and has no IPsec overlay tunnels:
l FortiManager manages branch1_fgt, branch2_fgt, and dc1_fgt.
l SD-WAN is configured on branch1_fgt and branch2_fgt, with rules to steer the traffic over the underlay (port1 and
port2).
The objective of this exercise is to configure the overlay and create the topology shown in the following diagram:
Prerequisites
Before you begin this exercise, you must restore the configuration files for branch1_fgt, branch2_fgt, and dc1_fgt,
as well as FortiManager.
© FORTINET
Write, and then click Yes to confirm.
3. In the upper-right corner, click admin, and then click Configuration > Restore.
© FORTINET
12. Confirm that the three devices—branch1_fgt, branch2_fgt, and dc1_fgt—are correctly managed (green up arrow)
and have a Config Status of either Synchronized or Auto-update.
Your page should look similar to the following example:
You will use the SD-WAN overlay template to configure the IPsec overlay and BGP routing configuration.
FortiManager will guide you through a few pages where you will enter the specific parameters for the network.
© FORTINET
To prepare the SD-WAN overlay template
1. On the FortiManager GUI, log in with the username admin and password password.
2. Click root > Device Manager > Device & Groups > Managed FortiGate.
3. In the top bar, click Device Group, select Create New Group, and then configure the following settings:
Field Value
Device Name l Click Add Member, and then select branch1_fgt and branch2_fgt.
l Click Add to validate the device selection.
To use the SD-WAN overlay template, it is mandatory to group the branch devices in a
device group. When the network expands, you can add additional devices to the
device group, and then the devices are automatically configured with the template
settings.
5. Continuing on the FortiManager GUI, click Provisioning Templates > SD-WAN Overlay Templates.
6. Click Create New.
7. In the Name field, type SOT-1H, and then click OK to validate.
8. Select Single HUB.
9. Expand the Advanced menu, and then configure the following settings:
Field Value
The Region Settings (1/5) page should look similar to the following example:
© FORTINET
10. Click Next, and then on the Role Assignment (2/5) page, configure the following settings:
Field Value
Field Value
Network Advertisement Select Connected, and then type port5 as the Interface 1 interface to
advertise the network connected to the LAN interface.
© FORTINET
Field Value
Network Advertisement Select Connected, and then type port5 as the Interface 1 interface to
advertise the network connected to the LAN interface.
© FORTINET
By selecting Connected in the Network Advertisement field, FortiManager creates a
template that instructs BGP to advertise networks connected to interface port5 only. In
our topology, that corresponds to the LAN subnet.
Field Value
Review and Install the Overlay the SD-WAN Overlay Template Created
The SD-WAN overlay template tool has created multiple templates using the settings that you configured and
Fortinet recommended settings for SD-WAN overlay with BGP routing. You will review these templates. After that,
you will install the changes on the hub and spoke devices. Finally, you will check the health of the overlay tunnels
created.
© FORTINET
You can see two templates: SOT-1H_BRANCH_CLI and SOT-1H_HUB1_CLI. These templates create
loopback addresses and, for the branches, the BGP router ID. You can double-click the template names to
review them.
The templates are added to CLI template groups, SOT-1H_BRANCH_CLIGRP and SOT-1H_HUB1_
CLIGRP, respectively.
port1 and port2, which were previously in the underlay zone, have been moved to the WAN1 and WAN2
zones. You will move them back to the underlay zone.
The SD-WAN overlay template placed the underlay interfaces, port1 and port2, in new
underlay zones called WAN1 and WAN2. Because you will continue to use SD-WAN
rules and the firewall policy that you created previously, and defined with the zone
named underlay, you must place the port1 and port2 interfaces back in the underlay
zone.
The SD-WAN overlay template has created multiple templates but, for all templates you reviewed, the
Assigned to Device /Group list is empty. Why? Do you need to manually assign them to the hub and the
branches ?
No. The SD-WAN overlay template has created the template and grouped them in template groups. It's a
group that is assigned to each device.
11. Click Template Groups, and then review the groups assigned to the branches and hub.
The template groups contain the templates created or updated by the SD-WAN overlay template. They don't
include the template that you assigned to the device before.
© FORTINET
16. Double-click the SOT-1H_BRANCH template group to edit it.
17. Repeat the previous steps to add the corp_st system template to the group.
© FORTINET
branch1_fgt has a route to the corporate LAN 10.1.0.0 using the two overlay tunnels.
The SD-WAN overlay template helped you configure the overlay tunnels and BGP routing to direct the traffic
through them. It has also created an SD-WAN overlay zone called HUB1 and placed the tunnels in it.
The administrator must now configure the SD-WAN rules to steer the traffic according to the requirements.
In this lab, you will configure an overlay zone and its members using FortiManager. The VPN tunnels have been
preconfigured for you. The following topology has been preconfigured for you:
Three communities were configured, one for each overlay (ISP1, ISP2, and MPLS). The lo_HC loopback interface
is also preconfigured and you will use it as the target server on one of the performance SLAs for overlays.
You will configure two performance SLAs for overlays, one using ping as the protocol, and another using HTTP.
You will also increase the latency on the overlays and see the changes introduced in the status of the performance
SLAs and overlays.
Objectives
l Configure zones and members for overlays
l Use ping and HTTP to actively monitor the performance and health of overlays
l Configure SLA targets
l Use the SD-WAN monitor on FortiManager and the FortiGate CLI to check the status of performance SLAs, SLA
targets, and overlays
Time to Complete
Estimated: 110 minutes
branch2_fgt lab3-branch2_fgt_7-2-4_initial.conf
dc1_fgt lab3-dc1_fgt_7-2-4_initial.conf
In this exercise, you will review the existing VPN configuration and its status. After that, you will configure the VPN
tunnels as SD-WAN members and place them in a separate zone called the overlay zone. Finally, you will verify
the resulting configuration on FortiManager and the FortiGate CLI.
In lab 2, you configured the T_INET_0 overlay. In this lab, the T_INET_1 and T_MPLS overlays have been
preconfigured for you. You will review the existing configuration and status of the tunnels on both FortiManager
and the FortiGate CLI.
The three tunnels definitions are grouped within the same template. This is mandatory
because you can apply only one IPsec tunnel template to each FortiGate. However,
each template can contains multiple tunnel definitions.
© FORTINET
7. Click Return to go back to the IPsec tunnel menu.
8. Click Monitors > VPN Monitor.
9. Select Show Table.
Your page should look similar to the following example:
There are six tunnels configured in total, and all of them are up (green up arrow).
If you don't see the tunnels established and up, check the FortiManager status in the
top bar. Offline mode must be disabled.
10. Open an SSH session to each device (branch1_fgt, branch2_fgt, and dc1_fgt).
11. Log in with the username admin and password password.
12. On each device, enter the following commands to verify the tunnel status and routing table:
get ipsec tunnel list
get router info routing-table all
The following image shows an example of branch1_fgt:
© FORTINET
You will configure a zone for the IPsec overlays. After that, you will install the changes. You must install the zone
first, before you can reference it in firewall policies and static routes.
© FORTINET
To install the device settings
1. Continuing on the FortiManager GUI, click Install Wizard.
2. Confirm that you see Install Device Settings (only), and then click Next.
3. Select branch1_fgt and branch2_fgt, and then click Next.
4. Click Install to install the configuration on both devices.
5. Wait for the installation to finish.
6. Click Finish.
First, you will remove the references to the VPN tunnels in firewall policies. Instead of referencing the tunnels, you
will reference the overlay zone. Otherwise, you won't be able to configure the VPN tunnels as SD-WAN members.
You will also make the same change for static routes. Next, you will configure the VPN tunnels as SD-WAN
members of the overlay zone. Finally, you will install the changes and verify the configuration on the FortiGate
CLI.
Field Value
© FORTINET
Stop and think!
Did you configure a normalized interface called overlay? Remember that on FortiManager, firewall policies
can reference only normalized interfaces. Yet overlay is available as a possible source or destination for the
firewall policy.
When you create an SD-WAN zone with the SD-WAN template, FortiManager automatically creates a
corresponding normalized interface.
Field Value
You require only one firewall policy in each direction that references the overlay zone.
Using SD-WAN zones greatly reduces the number of policies required for your
deployment.
© FORTINET
You require only one static route that references the overlay zone. FortiGate
automatically creates ECMP routes for the members in the zone. For this reason, you
can delete the other two individual static routes.
© FORTINET
Field Value
In the Interface Member field, make sure you type the name exactly as it is spelled
above, including capitalization. Otherwise, the installation will fail.
© FORTINET
The IDs for T_INET_0, T_INET_1, and T_MPLS should be 3, 4, and 5, respectively. If
you followed the order of the instructions, those should be the assigned member IDs.
Field Value
Name Corp
The Corp-net firewall address object has been preconfigured for you.
© FORTINET
3. Click OK to save the settings.
The SD-WAN Rules section in your template should look similar to the following example:
You will verify the overlays as SD-WAN members using FortiManager and the FortiGate CLI.
© FORTINET
Note that you might need to adjust the map size to view the circle for FortiGate devices.
The overlays are configured as SD-WAN members and are up (green up arrow).
© FORTINET
The overlays were configured as SD-WAN members and placed in the overlay zone.
© FORTINET
Stop and think!
You didn't configure a gateway for the overlays. Yet, FortiGate displays a gateway address for each of them.
Why?
You must not configure a gateway address for members that are IPsec tunnels. FortiGate automatically
determines the gateway address. That is, FortiGate uses the IPsec tunnel ID as the gateway address. You
can view the tunnel ID (tun_id in the CLI) in the output of the diagnose vpn tunnel list command.
In this exercise, you will configure a performance SLA named VPN_PING that you will use to actively monitor the
overlays using the ping protocol. You will also configure two SLA targets for VPN_PING. After that, you will check
the health of the overlays using FortiManager.
You will configure a performance SLA to monitor the health and performance of the overlays. You will configure
ping as the protocol and two SLA targets.
Field Value
Name VPN_PING
Protocol Ping
Server 10.200.99.1
Participants Select Specify, and then select T_INET_0, T_INET_1, and T_MPLS.
SLA Targets 1. Click Add Target, and then configure the following settings:
l Latency Threshold: 100
l Jitter Threshold: 20
l Packet Loss Threshold: 10
2. Click + to add a second target, and then configure the following
settings:
l Latency Threshold: 150
l Jitter Threshold: 40
l Packet Loss Threshold: 20
© FORTINET
© FORTINET
6. Click OK to save the settings.
7. Click OK to save the template settings.
You will use the SD-WAN monitor on FortiManager to check the health of the overlays.
You configured a performance SLA for the overlays. However, the overlays are
currently marked as down (red x). Next, you will find out the reason.
© FORTINET
The 10 at the end of the command indicates the number of packets to capture. That is,
the sniffer command will stop after capturing 10 packets.
FortiGate is sending ICMP echo requests to 10.200.99.1, but there are no replies. Why?
The overlays don't have an IP address assigned to them. Therefore, FortiGate uses the address of the
interface with the lowest index number (port1) as the source address (192.2.0.1). However, the
192.2.0.1 address is not routable within the overlay, which is why there are no replies. Next, you will fix
this issue by using metadata variables and a CLI template to assign a source address for probes on
overlays. In another lab, you will assign an address to the overlays.
© FORTINET
© FORTINET
The CLI template configures the source setting on each overlay (members 3, 4, and
5). The CLI template also references the metadata variable sdwan-vpn-hc-srcip.
Both the CLI template and the metadata variable have been preconfigured for you.
You can see that a CLI template group is already configured and assigned to the
branches devices (branch1_fgt and branch2_fgt). Because you can assign only one
CLI template or CLI template group to a FortiGate, if you need to assign multiple CLI
templates to a device, you must combine them in a CLI template group.
© FORTINET
© FORTINET
2. Continuing in the branch1_fgt SSH window, enter the following command to capture probe packets to 10.200.99.1:
diagnose sniffer packet any "host 10.200.99.1 and icmp" 4 10
Your output should look similar to the following example:
The probes now use the LAN interface address as the source, and now there are
replies. For branch1_fgt, the source address is 10.0.1.254, and for branch2_fgt, it
should be 10.0.2.254. You can run the same sniffer command on branch2_fgt to
verify the source address.
In this exercise, you will use FortiManager and the FortiGate CLI to monitor the status of the VPN_PING
performance SLA and overlays before and after you increase the latency on the overlays.
In the previous exercise, you configured a performance SLA to monitor the health and performance of overlays.
You will now monitor SD-WAN link behavior when the performance changes.
The output includes the different metrics (packet loss, latency, jitter, mos, and
bandwidth) that the VPN_PING performance SLA measures on each overlay. Note
that all overlays indicate sla_map=0x3, which means that the overlays meet the two
SLA targets configured.
4. Enter the following commands to display additional information about the health of the T_INET_0 overlay:
diagnose sys link-monitor interface T_INET_0
diagnose sys sdwan sla-log VPN_PING 3
diagnose sys sdwan intf-sla-log T_INET_0
Your output should look similar to the following example:
© FORTINET
l The first command (first output) reports on the T_INET_0 metrics that the link-
monitor process (lnkmtd) measures. Remember that the performance SLA relies on
the link-monitor process to measure the member metrics.
l The second command (second output) shows the latency, jitter, packet loss, and
mos that the link-monitor measures on member ID 3 (T_INET_0). The output shows
the results for each probe sent for the last 10 minutes. Because the probes are sent
every 500 ms, the output shows two lines per second. The output has been cut to fit
the page.
l The third command (third output) shows the measured incoming, outgoing, and
bidirectional bandwidth on T_INET_0 for the last 10 minutes. Bandwidth is
measured every 10 seconds. The output has been cut to fit the page.
You will increase the latency on two of the overlays on branch1_fgt, and then see the changes introduced in the
overlay and performance SLA status.
© FORTINET
4. On BR1-ISP2, use the vertical bar to increase the delay to 160 ms.
© FORTINET
5. Continuing on the branch1_fgt SSH session, enter the following command to display the status of the VPN_PING
performance SLA:
diagnose sys sdwan health-check status VPN_PING
Your output should look similar to the following example:
The performance SLA status reflects the increased latency on T_INET_0 and T_INET_
1. The sla_map on T_INET_0 and T_INET_1 also changed. The former indicates that
only one SLA target is met. The latter indicates that no SLA targets are met. For T_
MPLS, however, all SLA targets are still met.
© FORTINET
6. On the FortiManager GUI, log in with the username admin and password password.
7. Click root > Device Manager, and then click Monitors > SD-WAN Monitor.
Your page should look similar to the following example:
The page reports that T_INET_0 and T_INET_1 on branch1_fgt are not meeting one
or more SLA targets (orange color).
8. Hover over T_INET_0 on branch1_fgt to show more details about the overlay.
Your page should look similar to the following example:
9. In the Table View, hover over the red cross beside T_INET_0 to show more details about the status of the SLA
targets.
Your page should look similar to the following example:
© FORTINET
© FORTINET
11. Continuing on the wan simulator page, set the latency of BR1-ISP1 and BR1-ISP2 back to 0 ms.
12. Use the SD-WAN monitor on FortiManager and the FortiGate CLI to confirm that both overlays now meet all SLA
targets.
In this exercise, you will configure a performance SLA named VPN_HTTP that you will use to actively monitor the
overlays using the HTTP protocol. After that, you will check the performance SLA status using FortiManager and
the FortiGate CLI.
You will configure a performance SLA to monitor the health and performance of the overlays. You will configure
HTTP as the protocol.
Field Value
Name VPN_HTTP
Protocol HTTP
Server 10.1.0.7
Participants Select Specify, and then select T_INET_0, T_INET_1, and T_MPLS.
© FORTINET
The http-match setting instructs FortiGate to look for the fortinet string in the
HTTP response received from the server. If the response includes the string, the
probe is considered successful.
© FORTINET
Verify the Health of the Overlays
You will use the SD-WAN monitor on FortiManager to check the health of the overlays.
You configured an HTTP performance SLA for the overlays. However, the overlays are
currently marked as down (red x). Next, you will find out the reason.
2. Hover over the impacted overlays to get more details about their status.
For T_MPLS on branch2_fgt, your page should look similar to the following example:
The overlay is down for the new HTTP performance SLA. Next, you will find out the
reason by using the FortiGate CLI.
© FORTINET
3. Open an SSH session to branch2_fgt.
4. Log in with the username admin and password password.
5. Enter the following command to check the status of the VPN_HTTP performance SLA:
diagnose sys sdwan health-check status VPN_HTTP
The FortiGate CLI confirms that all overlays are down for the VPN_HTTP performance
SLA.
6. Enter the following command to check the status of the overlays in SD-WAN rule 3:
diagnose sys sdwan service 3
The VPN_HTTP performance SLA and SD-WAN monitor on FortiManager report the overlays as down. Yet,
the SD-WAN rule status indicates that the overlays are up. Why?
SD-WAN rules consider a member as down when all of its performance SLAs report the member as down. If
at least one performance SLA reports the member as up, the rule considers the member up. In this case, the
VPN_PING performance SLA still reports the overlays as up. This means that the overlays can be used to
steer traffic that matches the SD-WAN rule 3.
© FORTINET
FortiGate is exchanging HTTP packets with 10.1.0.7, so connectivity is fine. You will
enable debug for the link monitor to troubleshoot further.
The debug indicates that the HTTP probes fail when processing the HTTP response.
That is, the HTTP response doesn't contain the expected string (fortinet).
9. Enter the following command to reset the debug settings and stop the debug output:
diagnose debug reset
10. Open an SSH session to branch2_client.
11. Log in with the username root and password password.
12. Enter the following command to display the HTTP response that 10.1.0.7 provided:
curl 10.1.0.7
Your output should look similar to the following example:
© FORTINET
The output doesn't include the fortinet string. You should use any of the strings
shown in the output for the http-match setting. You will update the http-match
setting to use the following string: successfully.
13. Continuing on the FortiManager GUI, edit the VPN_HTTP performance SLA, and then update the http-match
setting to use successfully.
14. Install the device settings.
15. On FortiManager, confirm that the SD-WAN monitor now reports all overlays as up.
Your page should look similar to the following example:
© FORTINET
16. In the branch2_fgt SSH window, confirm that the VPN_HTTP performance SLA is now showing overlays as up.
Your output should look similar to the following example:
17. In the branch2_fgt SSH window, enable debug for the HTTP probes and confirm that the probes are now
successful.
Your output should look similar to the following example:
18. Enter the following command to reset the debug settings and stop the debug output:
diagnose debug reset
In this lab, you will put the concepts that you learned in lesson 4 into practice by troubleshooting the following SD-
WAN deployments:
l Spoke-to-spoke traffic (single hub)
l Direct internet access (DIA) traffic
For each exercise, you will load the required configuration, troubleshoot the issues reported, identify the root
cause, and fix the issues.
You will not use FortiManager in this lab. You will access the FortiGate devices directly to troubleshoot and fix the
issues described.
Objectives
l Configure static routing in SD-WAN
l Troubleshoot routing issues in SD-WAN
l Troubleshoot session reevaluation in SD-WAN
Time to Complete
Estimated: 115 minutes
branch2_fgt lab4-ex1-branch2_fgt_7-2-4_initial.conf
dc1_fgt lab4-ex1-dc1_fgt_7-2-4_initial.conf
In this lab, you will troubleshoot spoke-to-spoke traffic in the following preconfigured topology:
Configuration
This is a hub-and-spoke deployment with two overlays. The overlays are used to route traffic between the spokes.
Problem Description
When the administrator generates traffic from branch1_client to branch2_client, the traffic is always routed over
T_MPLS. However, the MPLS link is expensive, and therefore, the administrator wants to use T_MPLS for spoke-
to-spoke traffic only when T_INET_0 goes down. That is:
1. branch1_fgt must use T_INET_0 as the primary member to route traffic to branch2_fgt.
2. branch1_fgt must use T_MPLS to route traffic to branch2_fgt only if T_INET_0 is detected to be down.
3. After T_INET_0 recovers, spoke-to-spoke traffic must be routed back through T_INET_0.
© FORTINET
Objective
To complete this lab, you must fix all the issues described.
Solution Requirements
l Focus on branch1_fgt only. Don't make changes on any other device in the network.
l On branch1_fgt, don't change the existing SD-WAN rule configuration. Spoke-to-spoke traffic must match SD-WAN
rule ID 3. You can change other parts of the configuration.
l To optimize the branch1_fgt configuration, static routes and firewall policies must reference SD-WAN zones and not
the individual members.
l To fix all issues reported, you must perform multiple configuration changes.
© FORTINET
Solution
If you require assistance with this exercise, see the Solutions lesson in the Study Guide.
In this lab, you will troubleshoot direct internet access (DIA) traffic in the following preconfigured topology:
Prerequisites
Before beginning this lab, you must restore a configuration file to branch1_fgt.
© FORTINET
Configuration
This is a DIA deployment with two underlays. The underlays are used to route traffic to the internet. SD-WAN rules
have been configured to steer traffic for critical applications (GoToMeeting, Salesforce, and the Microsoft Office
365 portal), and for the cloud web server (128.66.0.1).
Problem Description
© FORTINET
Objective
To complete this lab, you must fix all the issues described.
Solution Requirements
l Focus on branch1_fgt only. Don't make changes on any other device in the network.
l On branch1_fgt, don't change the existing SD-WAN rule configuration. You can change other parts of the
configuration.
l Internet traffic must be SNATed with ippool 192.2.0.100.
l To fix all issues reported you need to perform multiple configuration changes.
If you decide to use the traffic generator, remember to stop it when you finish the lab.
l To simulate failover and failback of existing sessions, you can initially establish an SSH connection to the internet
web server (128.66.0.1) by running the ssh 128.66.0.1 command from branch1_client. Then, log in using the
username root and password password. The SSH session should remain up (it should continue to respond to
user commands) during failover and failback. If the SSH session becomes unresponsive, it is an indication that the
session timed out.
l To simulate link failure and recovery, bring BR1-ISP1 down and back up again on the WAN simulator.
l Use debug flow to know how packets to branch2_client are processed.
diagnose debug flow filter addr <target-addr>
diagnose debug flow trace start 100
diagnose debug console timestamp enable
diagnose debug enable
l Use the sniffer to capture ingress and egress packets.
diagnose sniffer packet any "host <target-addr>" 4 0 l
l View session details to verify the matching SD-WAN rule and firewall policy.
diagnose sys session filter dst <target-addr>
diagnose sys session list
l Check the routing table using the following command:
© FORTINET
get router info routing-table all
l Check the system configuration.
show system sdwan
show firewall policy
show system interface
diagnose sys sdwan zone
diagnose sys sdwan member
diagnose sys sdwan service
diagnose sys sdwan health-check status Level3_DNS
Remember to bring BR1-ISP1 back up when you finish the exercise. Also, remember
to stop the traffic generator on branch1_client by pressing Ctrl+C in the SSH session.
Solution
If you require assistance with this exercise, see the Solutions lesson in the Study Guide.
In this lab, you will configure and test the following rule strategies: best quality, lowest cost (SLA), and maximize
bandwidth (SLA). After that, you will troubleshoot rules on a hub-and-spoke topology that uses SD-WAN to steer
DIA, RIA, and site-to-site traffic.
For each exercise, you will load the required configuration. You will use FortiManager for the first exercise only.
Objectives
l Configure and test best quality, lowest cost (SLA), and maximize bandwidth (SLA) rules
l Troubleshoot rules
Time to Complete
Estimated: 80 minutes
In this exercise, you will configure an SD-WAN rule to steer traffic between branch1_client and dc1_host. You will
first use best quality as the strategy, then lowest cost (SLA), and finally maximize bandwidth (SLA). You will test
each strategy by generating traffic between branch1_client and dc1_host, while at the same time changing the link
metrics using the WAN simulator and observing the changes in the outgoing interface list and traffic steering.
You will configure a rule that uses best quality as the strategy and latency as the metric. Next, you will test the rule
by generating ping traffic and changing the condition of the links.
© FORTINET
4. In the SD-WAN Rules section, click Create New.
5. Configure the following settings:
Field Value
Name Best_Quality_Latency
Make sure that you set the configuration priority (or interface preference list
configuration) as follows (most preferred first):
l T_INET_0
l T_INET_1
l T_MPLS
© FORTINET
3. Select branch1_fgt, and then click Next.
4. Click Install to install the configuration on branch1_fgt.
5. Wait for the installation to finish.
6. Click Finish.
BR1-ISP1 100 ms
BR1-ISP2 110 ms
BR1-MPLS 120 ms
6. On the first SSH session on branch1_fgt, enter the following command to display the rule status:
diagnose sys sdwan service
Your output should look similar to the following example:
By default, FortiGate calculates the member latency and jitter based on the last 30
health check probes. For this reason, you may have to wait a few seconds before
FortiGate can reflect the actual latency.
After a few seconds, FortiGate reflects the actual latency for the links. T_INET_0 is
the preferred member.
7. On the second SSH session on branch1_fgt, enter the following command to capture ping traffic to 10.1.0.7:
diagnose sniffer packet any "host 10.1.0.7 and icmp" 4 | grep T_
© FORTINET
Leave the command running.
According to the rule status, FortiGate prefers T_INET_0, and therefore picked that
member to steer the ping traffic.
12. Use the WAN simulator to reduce the latency of T_INET_1 (BR1-ISP2) to 95 ms.
13. On branch1_fgt, check the rule status and sniffer again.
The latency of T_INET_1 is now the lowest among all the members. Yet, FortiGate still prefers T_INET_0
and steers traffic to it. Why?
Remember the link-cost-threhold setting, which is set to 10 by default. The setting gives an
advantage to members with a higher configuration priority. The corrected metric (CM) for T_INET_0, which
factors in the advantage, is determined by dividing its actual latency by 1.10. That is, assuming an actual
latency of 100 ms, the CM would be about 91 ms (110 / 1.10).
14. Use the WAN simulator to reduce the latency of T_INET_1 (BR1-ISP2) to 85 ms.
15. On branch1_fgt, check the rule status and sniffer again.
Your output should look similar to the following example:
© FORTINET
T_INET_1 beat the advantage given to T_INET_0. FortiGate now prefers T_INET_1,
and therefore picked that member to steer the ping traffic.
16. Use the WAN simulator to increase the latency of T_INET_1 (BR1-ISP2) to 95 ms.
17. On branch1_fgt, check the rule status and sniffer again.
The latency of T_INET_1 is still the lowest. Yet, FortiGate now prefers T_INET_0 and steers traffic to it.
Why?
FortiGate allows a quick recovery of the highest priority member (T_INET_0) by considering its CM when
competing against other lower priority members. In this case, the CM of T_INET_0 (~91 ms) is lower than
the actual latency of T_INET_1 (~95 ms).
18. Use the WAN simulator to increase the latency of T_INET_1 (BR1-ISP2) to 110 ms.
19. On branch1_fgt, check the rule status to confirm latency of T_INET_1 is ~110 ms.
20. Use the WAN simulator to reduce the latency of T_MPLS (BR1-MPLS) to 95 ms.
21. On branch1_fgt, check the rule status again.
Your output should look similar to the following example:
T_MPLS moved up in the list because its real latency is lower than the CM of T_INET_
1 (~100 ms).
© FORTINET
22. Use the WAN simulator to increase the latency of T_MPLS (BR1-MPLS) to 115 ms.
23. On branch1_fgt, check the rule status again.
Your output should look similar to the following example:
24. Use the WAN simulator to reduce the latency of all three overlays back to 0 ms.
25. On branch1_client, stop the ping to 10.1.0.7.
26. On branch1_fgt, stop the sniffer.
27. Keep the SSH sessions to branch1_client and branch1_ fgt open because you will need them for the next task.
You will configure a rule that uses lowest cost (SLA) as the strategy, and two SLA targets. Next, you will test the
rule by generating ping traffic and changing the SLA status of the links.
Field Value
Name Lowest_Cost
© FORTINET
Field Value
Set the configuration priority (or interface preference list configuration) to the following
(most preferred first):
l T_INET_0
l T_INET_1
l T_MPLS
© FORTINET
3. On the second SSH session on branch1_fgt, enter the following command to capture ping traffic to 10.1.0.7:
diagnose sniffer packet any "host 10.1.0.7 and icmp" 4 | grep T_
Leave the command running.
According to the rule status, FortiGate prefers T_INET_0, and therefore picked that
member to steer the ping traffic.
4. Use the WAN simulator to increase the latency of T_INET_0 (BR1-ISP1) to 160 ms, so it fails to meet both SLA
targets.
5. On branch1_fgt, check the rule status and sniffer again.
Your output should look similar to the following example:
© FORTINET
Stop and think!
T_INET_0 fails to meet both SLA targets, and therefore, is placed at the bottom of the outgoing interface list.
T_INET_1 and T_MPLS have the same SLA status (0x3) and cost (0), yet FortiGate picks T_INET_1 to
steer ping traffic. Why?
In the lowest cost (SLA) strategy, when multiple members have the same SLA status and cost, FortiGate
uses the configuration priority as the tie-breaker. T_INET_1 has a higher configuration priority than T_
MPLS, and therefore it becomes the preferred member.
Next, you will change the member cost, and then observe its impact in the outgoing interface list.
6. On the FortiManager GUI, edit the branches SD-WAN template, and then configure the following settings:
T_INET_1 Cost 10
T_MPLS Cost 5
7. Save the template changes, and then install the device settings on branch1_fgt.
8. On branch1_fgt, check the rule status and sniffer again.
Your output should look similar to the following example:
T_MPLS now has a lower cost than T_INET_1, and therefore becomes the preferred
member.
9. Use the WAN simulator to increase the latency of all three overlays to 160 ms.
10. On branch1_fgt, check the rule status and sniffer again.
Your output should look similar to the following example:
© FORTINET
All overlays fail to meet all SLA targets. However, T_INET_0 becomes the preferred
member because it has the lowest cost.
11. Use the WAN simulator to reduce the latency of all three overlays back to 0 ms.
12. On the branch1_client, stop the ping to 10.1.0.7.
13. On the branch1_fgt, stop the sniffer.
14. Keep the SSH sessions to branch1_client and branch1_fgt open because you will need them for the next task.
You will configure a rule that uses maximize bandwidth (SLA) as the strategy, and two SLA targets. After that, you
will test the rule by generating iperf traffic and changing the SLA status of the links.
Field Value
Name Maximize_Bandwidth
© FORTINET
Field Value
Make sure that the configuration priority (or interface preference list configuration) is
the following (most preferred first):
l T_INET_0
l T_INET_1
l T_MPLS
© FORTINET
The additional options in the command instruct iperf to generate six UDP streams at 1-
Mbps rate each. The UDP packet length will be 1000 bytes and traffic will be generated
for an hour (3600 seconds).
5. On the first SSH session, enter the following command to display the rule status:
diagnose sys sdwan service
Your output should look similar to the following example:
The rule strategy is load-balance (maximize bandwidth (SLA)), and the load
balancing algorithm is round-robin (equal distribution).
6. On the second SSH session on branch1_fgt, enter the following command to capture the first 30 packets of iperf
UDP traffic to 10.1.0.7:
diagnose sniffer packet any "host 10.1.0.7 and udp port 5201" 4 30 | grep T_
Your output should look similar to the following example:
© FORTINET
According to the rule status, all members have the same SLA status. Therefore,
FortiGate uses all the members to distribute the traffic.
From the sniffer output, you can tell that each member handles two sessions, for a
total of six sessions (round-robin distribution).
7. Use the WAN simulator to increase the latency of T_INET_0 (BR1-ISP1) to 110 ms, so that it fails to meet one of
the SLA targets.
8. On branch1_fgt, check the rule status and sniffer again.
Your output should look similar to the following example:
FortiGate placed T_INET_0 at the bottom of the list because it meets the lowest
number of SLA targets. Therefore, FortiGate distributes the iPerf traffic between the
other two members, as shown in the sniffer output.
9. Use the WAN simulator to increase the latency of all three overlays to 160 ms.
10. On branch1_fgt, check the rule status and sniffer again.
Your output should look similar to the following example:
© FORTINET
All overlays have the same SLA status (none meet any SLA targets). Because the
members have the same SLA status, FortiGate uses all of them to distribute traffic.
11. On the FortiManager GUI, click Provisioning Templates > SD-WAN Templates.
12. Double-click branches to edit the template settings.
13. In the SD-WAN Rules section, double-click the Maximize_Bandwidth rule to edit the rule settings.
14. In the Advanced Options section, set minimum-sla-meet-members to 1.
© FORTINET
The rule was disabled because none of the members met at least one SLA target.
When you set minimum-sla-meet-members to 1, FortiGate requires the rule to have
at least one member that meets one or more SLA targets. Otherwise, the rule is
disabled.
Because the rule is disabled, the traffic matches the implicit rule, which means that
FortiGate performs standard FIB routing.
19. Use the WAN simulator to reduce the latency of all three overlays back to 0 ms.
20. Close all the SSH sessions (branch1_fgt, branch1_client, and dc1_host).
In this exercise, you will troubleshoot SD-WAN rules used for steering DIA, RIA, and site-to-site traffic.
Prerequisites
Before beginning this lab, you must restore a configuration file to branch1_fgt, branch2_fgt, and dc1_fgt. Note that
although you must restore a configuration file to branch2_fgt, you will not be using branch2_fgt in this exercise.
You will not use FortiManager either.
© FORTINET
branch2_fgt lab5-ex2-branch2_fgt_7-2-4_initial.conf
dc1_fgt lab5-ex2-dc1_fgt_7-2-4_initial.conf
Configuration
This is a hub-and-spoke deployment with one underlay (port1) and two overlays (T_INET_1 and T_MPLS). port2
and T_INET_0 are configured but not used for steering traffic. There are rules configured to steer DIA, RIA, and
site-to-site traffic.
Internal BGP (IBGP) is used for exchanging routing information between the sites. On dc1_fgt, the administrator
assigned the community 65000:10 to advertised prefixes. On branch1_fgt, the administrator assigns prefixes
that match the 65000:10 community a route tag of 10.
Problem Description
© FORTINET
l Issue 2: The administrator configured the SD-WAN rule 1 to steer traffic to the corporate network (10.0.0.0/8).
For this, the administrator configured the rule to match the destination based on the BGP routes that are assigned
10 as a route tag. However, when the administrator checks the rule, the rule is disabled because it has no
destination.
l Issue 3: The administrator configured the SD-WAN rule 1 in manual mode. However, the administrator wants
branch1_fgt to prefer the member with the best route to the destination. This way, the administrator can control the
member preference by advertising from dc1_fgt a better route over its preferred overlay, and without having to
change the configuration on the branch.
Objective
To complete this lab, you must fix all the issues described.
Solution Requirements
l Unless otherwise stated, focus on branch1_fgt only. Don't make changes on any other device in the network.
l On branch1_fgt, do not change the existing IPsec, static route, and firewall policy configuration. You can change the
SD-WAN rule settings, except the mode in use and the member and zone preference lists.
© FORTINET
show system interface
diagnose sys sdwan zone
diagnose sys sdwan member
diagnose sys sdwan service
diagnose firewall proute list
diagnose sys sdwan health-check status Level3_DNS
diagnose sys sdwan health-check status VPN_PING
l To confirm that rule 1 prefers the member with the best route (issue 3), enter the following commands on dc1_fgt to
advertise a prefix for 10.1.0.7/32 over T_MPLS:
config router bgp
config neighbor-group
edit Branches_MPLS
set route-map-out prefer-dc1_host
next
end
end
execute router clear bgp all soft
Do not make any other changes on dc1_fgt.
Solution
If you require assistance with this exercise, see the Solutions lesson in the Study Guide.
In this lab, you will configure basic and advanced IPsec overlay and BGP settings for the following hub-and-spoke
topology:
After that, you will configure FEC and packet duplication. Finally, you will configure ADVPN to negotiate shortcuts
between the branches.
Objectives
l Configure basic and advanced IPsec overlay and BGP settings
l Configure FEC and packet duplication
l Configure ADVPN
Time to Complete
Estimated: 120 minutes
Device Configuration
branch2_fgt lab6-branch2_fgt_7-2-4_initial.conf
dc1_fgt lab6-dc1_fgt_7-2-4_initial.conf
In this exercise, you will configure the addresses and BGP configuration that the IPsec overlays use. In previous
labs, these settings were preconfigured for you, but this time you will configure them using FortiManager.
First, you will configure the overlay addresses by using IKE mode config. You will also configure a basic BGP
setup for your hub-and-spoke topology. Finally, you will fine-tune your IPsec and BGP settings to speed up SD-
WAN convergence, failover, and recovery.
You will assign the addresses using IKE mode config. For BGP, you will configure a basic IBGP setup. On dc1_
fgt, you will use neighbor group and neighbor range features because they are required on the dial-up server side.
All the metadata variables that you will use in this lesson were preconfigured for you.
You can view the metadata variable settings on the Policy & Objects page. Click
Device Manager > Policy & Objects, and then click Object Configurations >
Advanced > Metadata Variables.
© FORTINET
l In the system interface configuration for each overlay, the local and remote IP
addresses are defined. The $(dc-id) metadata variable is used to define the
correct IP address to use on each dc (useful if there are multiple hubs).
l In the IPsec phase 1 configuration, mode-cfg is enabled on each overlay, and the
$(dc-id) metadata variable is also used to indicate the right network to use on
each dc.
l In the BGP configuration, the interface and update-source settings are used
to define the interface and source IP address to send the BGP packets from. Also,
the route-reflector-client setting instructs FortiGate to reflect IBGP routes
between spokes. All these settings are applied to a neighbor-group, which in
turn is referenced by a neighbor-range.
l In the BGP configuration, the $(dc-id) metadata variable is used to define the
correct router ID and network statement for BGP.
Field Value
Field Value
© FORTINET
11. Click OK to save the settings.
12. Select the Spoke CLI template group, and then click Assign to Device/Group.
13. Move branch1_fgt and branch2_fgt to the Selected Entries list.
14. Click OK to save the settings.
15. Select the Hub CLI template group, and then click Assign to Device/Group.
16. Move dc1_fgt to the Selected Entries list.
17. Click OK to save the settings.
4. On both SSH sessions, enter the following commands to display the status of BGP peerings and the BGP routes in
the routing table:
get router info bgp summary
get router info routing-table bgp
For example, on branch2_fgt, your output should look similar to the following example:
© FORTINET
There is a BGP peering established over each overlay. The branch is also learning BGP prefixes from dc1_
fgt. The 10.1.0.0/24 prefix is sourced from dc1_fgt, and the 10.0.branch-id.0/24 prefix is sourced
from the other branch and reflected by dc1_fgt. The former prefix is learned over each overlay, but the latter
is not. Why?
The paths over the other overlays are not shown because you didn't configure additional paths on the
branches and dc1_fgt. In the next task, you will configure additional paths so the branches show nine
different paths for the 10.0.branch-id.0/24 prefix (three prefixes per overlay).
© FORTINET
The performance SLA marked T_INET_0 down shortly after bringing down port1 on
dc1_fgt. However, the IPsec tunnel and BGP peering remain up.
8. Repeat the previous commands every few seconds to track the status of the overlay and BGP.
© FORTINET
Stop and think!
Eventually (after two minutes or so), the tunnel and the BGP peering goes down. For example:
Why?
Although it is not shown in the output, the tunnel and the BGP peering go down because of DPD and the
hold timer expiration, respectively. Both the DPD and BGP timers are set to the default values. In the next
task, you will adjust the timers to speed up SD-WAN convergence, failover, and recovery.
9. On the WAN simulator page, locate DC1-ISP1, and then click UP to bring up the link on port1 on dc1_fgt.
You will configure some IPsec and BGP settings to speed up SD-WAN convergence, failover, and recovery. You
will also configure additional paths on dc1_fgt and the branches to exchange all available routes between them.
© FORTINET
l In the IPsec phase 1 configuration, the dpd-mode, dpd-retrycount, and dpd-
retryinterval settings are set to on-idle, 2, and 2, respectively. With these
settings, DPD should detect a tunnel that is down 6 seconds after the connectivity is
lost.
l In the BGP configuration, the soft-reconfigurationand link-down-
failoversettings are enabled. The former instructs FortiGate to save the received
routes in a separate table, which is useful for troubleshooting, and is required to soft
reset BGP peerings after a change. The latter instructs FortiGate to clear a BGP
peering after the interface in use goes down.
l In the BGP configuration, the connect-timer and additional-path settings
are set to 1 and receive, respectively. The former speeds up the frequency of the
connection attempts made by FortiGate to establish a BGP peering. The latter
instructs FortiGate to accept additional paths from a BGP neighbor.
l The DPD settings are set to the same values as in the spoke template. In the BGP
configuration, the soft-reconfiguration and link-down-failover settings
are also enabled. All settings have the same effect as in the spoke.
l In the BGP configuration, the keepalive-timer, holdtime-timer, and
advertisement-interval settings are set to 5, 15, and 1, respectively, to
speed up routing convergence and failover.
l In the BGP configuration, the additional-path and additional-path-
select settings are set to enable and 3, respectively. Also, inside each neighbor-
group, the additional-path and adv-additional-path settings are set to
send and 3, respectively. The result is that dc1_fgt can identify up to three
additional paths per prefix, and send them to the branches.
© FORTINET
The routing table now displays nine available paths for the 10.0.branch-id.0/24
prefix. Some of the routes are duplicate routes. You can see the duplicate routes in the
output of the get router info routing-table database command.
© FORTINET
16. Use the WAN simulator page to bring down DC1-ISP1 again to verify the faster convergence.
17. On any of the branch SSH sessions, enter the following commands multiple times to monitor the status of the T_
INET_0 overlay and BGP status:
diagnose sys sdwan health-check status VPN_PING
get ipsec tunnel list
get router info bgp summary
The tunnel and BGP peering are now brought down much faster, which speeds up
network convergence and failover.
In this exercise, you will impact the link quality of the T_INET_0 overlay by adding packet loss to the link, which
you will then correct by configuring FEC. After that, you will configure packet duplication on SD-WAN, and then
verify that FortiGate sends duplicates on the sender side and discards them on the receiver side.
Configure FEC
You will use FortiManager CLI templates to configure FEC on the branches and dc1_fgt. The CLI templates were
preconfigured for you.
To configure FEC
1. On the FortiManager GUI, log in with the username admin and password password.
2. Click root > Device Manager, and then click Provisioning Templates > CLI Templates.
3. Double-click Spoke-Enable FEC to view the CLI template settings, and then examine the CLI template.
FEC is enabled on the outgoing direction on the spoke, and on the incoming direction on the hub. Why?
The packet loss that you will add using the WAN simulator impacts only the outgoing traffic on the spoke.
For this reason, you must correct only the outgoing traffic on the spoke, which is also the incoming traffic on
the hub. In production networks, you usually want to enable FEC on both directions of the traffic to guard
against brownout conditions impacting any direction of the link.
© FORTINET
9. Double-click the Hub CLI template group to edit its settings.
10. In the Members list, add Hub-Enable FEC.
11. Click OK to save the settings.
To test FEC
1. Access the WAN simulator page.
2. Locate the DC1-ISP1 control panel.
3. Use the vertical bar to increase the loss of the link to 30%.
From dc1_fgt perspective, you introduced packet loss on port1 on the incoming
direction (from the branch to dc1_fgt).
© FORTINET
FortiGate calculates the member packet loss based on the last 100 health check
probes. For this reason, you may have to wait a few seconds before FortiGate can
reflect the latest packet loss.
There is an SD-WAN rule that steers corporate traffic. The preferred member is T_
INET_0.
The SD-WAN performance SLA reports a ~30% packet loss on T_INET_0. However, when you ping from
branch1_client to the dc1_host over T_INET_0, there is only 3% packet loss. Why?
Local traffic, such as the health check probes, is not subject to FEC. Only traffic passing through the firewall
is. This is why the ping traffic from branch1_client to dc1_fgt is corrected, and the health check traffic is not.
10. On FortiManager, edit the Spoke-Enable FEC CLI template, and set fec-redundant to 4.
11. Save the CLI template settings, and then install the device settings on branch1_fgt and branch2_fgt.
© FORTINET
12. On the branch1_client, repeat the ping test, and then examine the ping statistics.
Your output should look similar to the following example:
Packet loss is reduced even further after you increased the fec-redundant setting.
15. On FortiManager, edit the Spoke CLI template group, remove the Spoke-Enable FEC CLI template from the
Members list, and then save the setting.
16. Edit the Hub CLI template group, remove the Hub-Enable FEC CLI template from the Members list, and then
save the setting.
17. Click Device Manager > Policy & Objects.
18. Install the policy package and device settings on branch1_fgt and branch2_fgt.
Select branches_pp as the policy package.
You will configure forced packet duplication using FortiManager SD-WAN templates. You will also configure
overlay stickiness on the hub using CLI templates. When you configure overlay stickiness, dc1_fgt prefers to keep
© FORTINET
the traffic in the same overlay. Overlay stickiness is also recommended for ADVPN. You will configure ADVPN in
another exercise.
Field Value
© FORTINET
© FORTINET
4. Click OK to save the settings.
5. In the Duplication section, click Create New, and then configure the following settings to configure duplication
discard from overlay to LAN:
Field Value
© FORTINET
© FORTINET
6. Click OK to save the settings.
7. Click OK to save the template settings.
You didn’t configure the duplication-max-num setting. Therefore, you will use the
default value: 2. That is, FortiGate forwards up to two copies of the packet—the
original packet plus one duplicate.
There are three policy routes, one for each overlay. Each policy route instructs
FortiGate to keep the traffic within the overlay.
2. Edit the Hub CLI template group, add the Hub-Overlay Stickiness CLI template to the Members list, and then
save the settings.
3. Install the device settings on branch1_fgt, branch2_fgt, and dc1_fgt.
You increased the latency on the traffic forwarded to dc1_fgt over T_INET_0.
By increasing the latency on DC1-ISP1, you ensure that duplicate pings sent over T_
INET_0 arrive later than those sent over T_INET_1.
2. On the branch1_fgt SSH session, enter the following command to capture ping traffic to branch2_client:
diagnose sniffer packet any "host 10.0.2.101 and icmp" 4
3. Open an SSH session to branch2_fgt, and then run the previous sniffer capture command.
4. On the branch1_client, enter the following command to send one ping to branch2_client:
ping 10.0.2.101 -c 1
You should be able to ping the address.
5. Examine the sniffer output on the branch1_fgt and branch2_fgt SSH sessions.
Your output should look similar to the following example:
© FORTINET
branch1_fgt generates two packets—the original ping packet and one duplicate. One
packet is forwarded to T_INET_1 and another to T_INET_0.
On branch2_fgt, the packet that arrives first (T_INET_1) is accepted, and the packet
that arrives second (T_INET_0, about 100 ms later) is discarded.
6. Continuing on the FortiManager GUI, edit the branches SD-WAN template, and delete the two packet duplication
rules.
7. Install the device settings on branch1_fgt and branch2_fgt.
8. On the WAN simulator page, reduce the delay on DC1-ISP1 back to 0 ms.
In this exercise, you will configure and test ADVPN. After that, you will configure an ADVPN idle timeout.
You will use FortiManager CLI templates to configure ADVPN on the branches and dc1_fgt. The CLI templates
were preconfigured for you.
In the IPsec phase 1 configuration, the net-devicesetting is disabled, and the auto-
discovery-sender setting is enabled on each overlay. The former is required for
ADVPN to work on hubs, and the latter instructs FortiGate to facilitate shortcut
negotiation between spokes.
© FORTINET
15. In the SD-WAN Rules section, double-click Corp to edit the rule settings.
16. In the Outgoing Interfaces section:
l In the Strategy field, select Lowest Cost (SLA).
l In the Required SLA Target field, select VPN_PING#1.
To test ADVPN
1. Open an SSH session to branch1_fgt.
2. Log in with the username admin and password password.
3. Enter the following commands:
get ipsec tunnel list
diagnose sys sdwan service
get router info routing-table details 10.0.2.101
© FORTINET
Your output should be similar to the following example:
4. Continuing on the branch1_fgt SSH session, enter the following command to capture ping traffic to branch2_client:
diagnose sniffer packet any "host 10.0.2.101 and icmp" 4
5. Open an SSH session to branch1_client.
6. Log in with the password password.
© FORTINET
7. Ping 10.0.2.101, and then leave the ping running.
8. On the branch1_fgt SSH session, examine the sniffer output.
The packets are initially routed through the overlay (T_INET_0, the parent tunnel),
and then through the shortcut (T_INET_0_0).
9. On the branch1_fgt SSH session, stop the sniffer, and then enter the following commands:
get ipsec tunnel list
diagnose sys sdwan service
get router info routing-table details 10.0.2.101
Your output should be similar to the following example:
© FORTINET
You increased the latency on the traffic forwarded to branch1_fgt over T_INET_0,
specifically in the network segment between branch1_fgt and ISP1. The latency
between ISP1 and dc1_fgt is not impacted.
© FORTINET
13. On the branch1_fgt SSH session, stop the sniffer, and then check the rule status again.
Your output should be similar to the following example:
© FORTINET
l The new shortcut (T_INET_1_0) is listed in the rule status, and placed at the top of
the outgoing interface list. That is, the new shortcut is now the preferred member.
l The T_INET_0_0 shortcut and its parent tunnel don't meet any SLA targets, and
therefore, are placed at the bottom of the outgoing interface list.
l There are three shortcuts negotiated, one for each overlay, but only one is currently
used.
l The lifetime of the shortcuts are inherited from the parent IPsec settings (1800
seconds). That is, idle shortcuts remain up until the lifetime is reached.
l In the next task, to save system resources, you will configure an idle timeout for the
shortcuts.
18. On the WAN simulator page, reduce the delay on BR1-ISP1 and BR1-ISP2 back to 0 ms.
19. On the branch1_client, stop the ping.
© FORTINET
To check VPN log messages
On the FortiGate event logs, you will display event logs related to ADVPN shortcuts and master tunnels.
1. Continuing on the branch1_fgt SSH session, enter the following commands to filter ADVPN shortcut log messages
and review them:
execute log filter category event
execute log filter field advpnsc 1
execute log display
Your output should look similar to the following example:
2. Enter the following commands to update the filter and display VPN logs related to master tunnels:
execute log filter field advpnsc 0
execute log display
Your output should look similar to the following example:
© FORTINET
diagnose vpn ike gateway clear name T_INET_1_0
diagnose vpn ike gateway clear name T_MPLS_0
5. On the branch1_fgt SSH session, check the IPsec tunnel list to confirm that all the shortcuts were cleared.
You will configure an idle timeout for ADVPN to save system resources.
In the IPsec phase 1 configuration, each overlay has the idle-timeout setting
enabled and the idle-timeoutinterval setting set to 5 minutes.
© FORTINET
The shortcut appears in the IPsec list. Notice that the tunnel lifetime is close to 1800
seconds.
11. On the branch1_fgt SSH session, enter the following commands to enable debug for the IKE process:
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable
12. On the branch1_client, stop the ping.
13. On the branch1_fgt SSH session, wait 5 minutes, and then monitor the output.
After 5 minutes, the debug shows the following messages to indicate that the shortcut timed out:
FortiGate monitors the shortcut using ping. The ping probes are sent to the address of the remote end over
the shortcut. Therefore, the shortcut is not really idle. Why did it time out?
FortiGate does not consider health check probes to be user traffic. Therefore, health check probes don't
prevent a shortcut from timing out.
In this lab, you will monitor your SD-WAN deployment using FortiAnalyzer. Note that, for this lab exercise, there is
no separate FortiAnalyzer. Instead, you will use the FortiAnalyzer features enabled on FortiManager.
Objectives
l Verify log settings on FortiGate devices
l Analyze traffic logs
l Analyze SD-WAN event logs
l Discover the Secure SD-WAN Monitor page
l Discover the SD-WAN Summary page
Time to Complete
Estimated: 40 minutes
FortiAnalyzer centralizes all log messages that the managed devices send. It stores the log messages, correlates
the information received, and presents the information in easy-to-read graphs to help administrators with day-to-
day network monitoring tasks or punctual troubleshooting tasks.
In this exercise, you will navigate through the FortiAnalyzer menus to understand how you can use it for
monitoring your SD-WAN deployment.
In a previous lab, you configured the FortiGate devices to send logs to FortiAnalyzer. You also configured SLA
health checks to send sla-fail-log and sla-pass-log messages to FortiAnalyzer. You will review these
settings.
© FORTINET
2. Confirm that sla-fail-log-period and sla-pass-log-period are set for both health checks.
You will generate internet traffic from branch1_client and branch2_client using the traffic generator tool. Then, you
will review the corresponding traffic logs on FortiAnalyzer.
© FORTINET
The green circle beside Real Time indicates that FortiAnalyzer is receiving logs from
the connected devices.
© FORTINET
Serial numbers (Device ID column) of managed devices may be different in your lab.
3. In the upper-right corner, click the column setting icon, and then click More Columns.
4. Select Destination Interface, SD-WAN Internet Service, SD-WAN Quality, SD-WAN Rule ID, and SD-WAN
Rule Name.
© FORTINET
Use the column settings search box to quickly find the columns.
6. Identify messages for the main SD-WAN rules configured: Critical-DIA and Non-Critical-DIA.
7. Double-click a log message to view details.
8. Expand the Others submenu to see the SD-WAN details contained in the log message.
© FORTINET
If you want to display logs for a specific device, in the upper-left corner, click All
FortiGate to select the managed device you want to display logs for.
You will trigger link down and link up events, and then review the log messages corresponding to those events on
FortiAnalyzer.
To trigger events
1. Access the WAN simulator page.
2. Locate the BR1-ISP1 and BR1-MPLS control panels.
3. On BR1-ISP1, click DOWN to switch off the interface.
© FORTINET
4. Wait a few seconds, and then click UP to switch the interface back on.
5. On BR1-MPLS, use the vertical bar to increase the delay to 120 ms.
© FORTINET
6. Identify SLA pass log messages, and then double-click some messages to see details.
7. Click Other to see SD-WAN information.
For each device and each interface, FortiAnalyzer receives a health-check SLA
status, pass or fail, every 10 seconds.
You see those messages because for each health check, the sla-fail-log-
period and sla-pass-log-period settings are set to 10.
FortiAnalyzer receives both SLA pass and SLA fail log messages for the T_MPLS interface of device
branch1_fgt. Why?
Log details show that the SLA pass message correspond to the SLA target ID 2 of the VPN_PING health
check, while the SLA fail message corresponds to the SLA target ID 1 of the same health check.
8. Right-click an SLA pass log message, and then select the filter, as shown in the following image, to filter the list to
remove the SLA pass log messages:
9. Repeat the previous step to filter out SLA fail log messages.
Your page should look similar to the following example:
© FORTINET
10. Identify the log messages related to the BR1-ISP1 interface shut down.
You should see the following:
l The SD-WAN health-check member changed state for port1, overlay tunnel T_INET_0, and ADVPN shortcut
(level warning).
l Service prioritized by SLA will be redirected in sequence order (level notice).
l The member link is unreachable or missed the threshold. Stop forwarding traffic (level notice).
11. Double-click messages to see details.
12. Identify log messages related to the BR1-ISP1 interface going up.
You should see the following:
l The SD-WAN health-check member changed state for port1 and the T_INET_0 overlay tunnel (level notice).
l Service prioritized by SLA will be redirected in sequence order (level notice).
l The member link is available. Start forwarding traffic (level notice).
13. Double-click messages to see details.
The Secure SD-WAN Monitor page provides you with a centralized view of SD-WAN status information for each
managed FortiGate. You will discover the widgets available and how to use them.
© FORTINET
4. In the SD-WAN Bandwidth Overview widget, click T_INET_1, T_MPLS, and port2 to display only the graphs for
the port1 interface and T_INET_0 and T_INET_0_0 tunnels.
5. Continuing in the SD-WAN Bandwidth Overview widget, use the bottom bar to reduce the time period that is
displayed.
This allows you to see additional details for a specific period of time.
© FORTINET
The SD-WAN Summary page provides a centralized view of your SD-WAN deployment. It summarizes data for
all managed FortiGate devices.
© FORTINET
2. Click the Healthy Device link to display the list of devices identified as healthy.
3. Close the window, and then click the Major Alerts link to display the list of devices identified with an alert.
Your page should look similar to the following example:
4. Click the device name (should be branch1_fgt) to view the cause of the alert.
Your page should look similar to the following example:
© FORTINET
Note the red or orange bars that correspond to the downtime for the port1 and T_INET_0 interfaces. The SD-
WAN Health Overview widget reports it as an alert.
The SD-WAN Health Overview widget now shows both devices as healthy. Why?
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© 2023 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.