Fortinet Network Security Support Engineer Study Guide for FortiOS 7.2

Citation preview

DO NOT REPRINT © FORTINET

Network Security Support Engineer Study Guide for FortiOS 7.2

DO NOT REPRINT © FORTINET Fortinet Training Institute - Library https://training.fortinet.com Fortinet Product Documentation https://docs.fortinet.com Fortinet Knowledge Base https://kb.fortinet.com Fortinet Fuse User Community https://fusecommunity.fortinet.com/home Fortinet Forums https://forum.fortinet.com Fortinet Product Support https://support.fortinet.com FortiGuard Labs https://www.fortiguard.com Fortinet Training Program Information https://www.fortinet.com/nse-training Fortinet | Pearson VUE https://home.pearsonvue.com/fortinet Fortinet Training Institute Helpdesk (training questions, comments, feedback) https://helpdesk.training.fortinet.com/support/home

6/2/2023

DO NOT REPRINT © FORTINET

TABLE OF CONTENTS 01 Troubleshooting Concepts 02 System Resources 03 Sessions, Traffic Flow, and Networking 04 Security Fabric 05 Firewall Authentication 06 FSSO 07 Security Profiles 08 High Availability 09 IPSec 10 IPsec―IKEv2 11 Routing 12 BGP 13 OSPF Solution Slides Dynamic Routing Supplement

4 29 81 126 153 183 220 273 303 331 352 384 418 450 495

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

In this lesson, you will learn about troubleshooting concepts on a FortiGate device.

Network Security Support Engineer 7.2 Study Guide

4

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating a competent understanding of troubleshooting concepts, you will be able to set up a baseline and identify the GUI tools and CLI commands you should use to monitor and diagnose issues on FortiGate.

Network Security Support Engineer 7.2 Study Guide

5

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

In this section, you will learn about the troubleshooting methods used to approach and diagnose an issue.

Network Security Support Engineer 7.2 Study Guide

6

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

Good administrators know their network. This network knowledge includes an understanding of the normal behavior related to traffic volume, network applications, traffic flows, and the CPU and memory utilization. So, when a problem happens, administrators can identify quickly where the abnormal behavior is happening. Having this knowledge speeds up the troubleshooting process and helps the administrator to isolate the cause of the problem. FortiGate devices operate at all layers of the OSI model. For this reason, troubleshooting problems can be complex. If you establish what normal operating parameters are, or establish a baseline for your system before a problem occurs, it will help reduce the complexity of the issue when you are troubleshooting.

Network Security Support Engineer 7.2 Study Guide

7

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

You can use many different tools to gather statistics and information while the network is operating normally: SNMP, logging, and the monitors located on the FortiGate GUI.

Network Security Support Engineer 7.2 Study Guide

8

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

It is also important to keep the network documentation up to date. Network diagrams should include physical connections, interface names, and subnets. Good network documentation also includes change control records to track any change in the network, such as who made the change, when the change was made, and what the change was.

Network Security Support Engineer 7.2 Study Guide

9

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

If a problem occurs, the first step is to define it well. For example, if the problem definition is “web filtering is not working”, the scope of the problem is too imprecise. Too many things could cause this problem. This makes troubleshooting slow. So, you must ask questions to understand the details. Is the problem happening with one web site? Is it happening with all users? Is it happening randomly? How can you reproduce the problem? After answering the right questions, you can define the problem with details. For example, “web filtering is not blocking website X for user Y”. Having this level of detail, provides a better place to start the troubleshooting process. The following questions can help determine the scope of the problem and isolate it: •

What is the problem?

•

Has the configuration ever worked?

•

Can you reproduce the problem at will, or is it intermittent?

•

What has changed?

•

What applications, users, operating systems does the problem effect?

Network Security Support Engineer 7.2 Study Guide

10

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

One general approach to troubleshooting network issues is to follow the TCP/IP model and work the problem either from the highest layer to the bottom, or from the lowest layer to the top. When you work from the bottom to the top you check the physical layer first. As you determine that a layer is operating properly, you move to the next layer, and so on, until you find the layer where the problem is happening. When you approach the problem from the top down, you check the application layer first. If a layer is not working properly, you move to the layer below to rule out issues in the lower layers.

Network Security Support Engineer 7.2 Study Guide

11

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

In a typical network, you can approach troubleshooting by systematically reviewing the settings of each layer of the network. Working through the problem using the TCP/IP model or OSI model, is one approach that you can take when reviewing issues. As you gain more experience, you may try to resolve issues by forming an hypothesis and go through the resolution step by step. Issues are often very specific. An example is, an HA sync issue, or a routing issue, where a routing protocol has a higher precedence over the static or dynamic protocol. In a case like this, a good understanding of the routing flowchart will be very important. Of course, it is also very important to understand the nuance of routing protocols. When OSPF is used, the hello timers and dead interval must match on both ends, to form a neighbor relationship. In addition, the MTU size must match. In FortiOS, there are other unique parameters and settings that must be configured “correctly” for some features to work as expected.

Network Security Support Engineer 7.2 Study Guide

12

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

Another step to narrowing down the issue and identifying the source is analyzing what could trigger the issue. Figuring out how to reproduce the issue can be a very useful tool for gathering data. After you have identified how to trigger the issue, as a next step, you can analyze what tools you can use to collect debug data, for example, sniffer and CLI debug commands, logs, GUI widgets, and so on.

Network Security Support Engineer 7.2 Study Guide

13

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

In this section, you will learn about the troubleshooting tools available on the GUI.

Network Security Support Engineer 7.2 Study Guide

14

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

The status dashboard is the FortiGate GUI welcome screen. Some of the widgets on the status dashboard contain information that is useful for troubleshooting, such as the CPU, Memory, and Bandwidth widgets, as well as others. Other default widgets on the dashboard include, Security, Network, User & Devices and WiFi. You can configure custom widgets as well. These widgets can deliver useful information for monitoring and troubleshooting FortiGate.

Network Security Support Engineer 7.2 Study Guide

15

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

In addition the dashboard widgets, the GUI includes FortiView, where you can monitor screens for specific features. For example, the FortiView Policies monitor lists the most active firewall policies. Another example is the Routing monitor, which lists the routes that are active in the routing table.

Network Security Support Engineer 7.2 Study Guide

16

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

Another important tool for troubleshooting is the FortiGate logs. The log viewer includes a filter setting that you can use to display only the log entries related with a specific user name, IP address, URL, or event type. Other logs, like System Events, can provide a source of data about FortiGate status when performing analysis of FortiGate.

Network Security Support Engineer 7.2 Study Guide

17

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

This table lists the expected log behavior associated with the different logging settings. Moving from left to right, the first column shows the possible values for the log setting in the firewall policies: no log, log security events, or log all sessions. The second column indicates if the antivirus, web filtering, or email filtering log setting is enabled or disabled. Remember, DLP and IPS profiles always generate logs in the security log section. The last column shows the expected behavior. If you enable any profiles and your policy and logging is not enabled, you will not get logs of any kind—even when profile is blocking traffic. So if you apply a security profile, it’s important to consider the logging settings.

Network Security Support Engineer 7.2 Study Guide

18

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

In this section, you will learn about CLI troubleshooting commands to gather data to diagnose an issue on FortiGate.

Network Security Support Engineer 7.2 Study Guide

19

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

FortiGate includes a number of CLI commands that help you monitor the current status of FortiGate and start diagnosing an issue. Some commands, such as diagnose sys top are useful to monitor process activity in real time. While collecting debug data, execute tac report is a very useful command to collect initial data.

Network Security Support Engineer 7.2 Study Guide

20

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

It is very useful for an administrator to be familiar with the fundamental debug commands used during troubleshooting sessions. This helps to speed up the diagnosis and troubleshooting of a FortiGate.

Network Security Support Engineer 7.2 Study Guide

21

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

The real-time debug commands generate information in real time about what a specific FortiGate process or feature is doing. The debug level is a bitmask value that specifies which types of messages are displayed. This depends on each process. For all cases though, a debug level of 0 means no output (disabled), and a debug level of -1 means enabling all possible message types.

Network Security Support Engineer 7.2 Study Guide

22

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

This slide shows the two commands to enable all the IPsec real-time debug output. You can also enable the option to prepend the system time to each debug line. It is important to disable any real-time debug application after using it. Debug applications consume FortiGate resources and some could be CPU-intensive.

Network Security Support Engineer 7.2 Study Guide

23

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

Application layer test commands do not display information in real time. They display statistics and configuration information about a feature or process. You can also use some of these commands to restart a process or execute a change in its operation.

Network Security Support Engineer 7.2 Study Guide

24

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

FortiGate includes the sniffer command, which is a useful tool when troubleshooting requires you to dig further to diagnose the source of the issue. The sniffer command can sniff packets on physical or virtual interfaces. If the sniffer command is set to any, it can sniff all available interfaces simultaneously. You can use a filter to customize and narrow down the packets that you want to capture. The sniffer filter uses Berkeley Packet Filters syntax. The verbose setting has six verbosity levels: •

1: print header of packets

•

2: print header and data from the IP header of the packets

•

3: print header and data from the Ethernet header of the packets

•

4: print header of packets with interface name

•

5: print header and data from IP of packets with interface name

•

6: print header and data from Ethernet of packets with interface name

Network Security Support Engineer 7.2 Study Guide

25

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

Some CLI debug commands generate a lot of output. If you know that the required information is contained in one specific line of the output, and if you know a keyword that you can use to find that line, you can use the GREP utility. The GREP utility displays only the lines from the output that match a text string. Using the GREP utility, you can reduce the output to only the one line (that contains exactly the information that you need), instead of a long list of entries.

Network Security Support Engineer 7.2 Study Guide

26

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

When you display the FortiGate configuration using the CLI, you can use the GREP utility with the option –f. It will display only the configuration sections or tables where the text string matches at least one value. This is useful, for example, when you need to find all the references to a specific object. In the example shown on this slide, the –f option is being used to find all the references to the port1 interface. The output shows the two tables where port1 is referenced: the definition of the interface itself, and a static route where port1 is the assigned device interface.

Network Security Support Engineer 7.2 Study Guide

27

Troubleshooting Concepts

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned how to diagnose an issue with a FortiGate device by using troubleshooting methods, and the appropriate GUI and CLI command tools.

Network Security Support Engineer 7.2 Study Guide

28

System Resources

DO NOT REPRINT © FORTINET

In this lesson, you will learn about FortiOS System Resources.

Network Security Support Engineer 7.2 Study Guide

29

System Resources

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating a competent understanding of FortiOS system resources, you will be able to identify how FortiOS processes packets and uses memory. You will be able to also diagnose high-resource utilization and conserve mode issues and optimize memory usage.

Network Security Support Engineer 7.2 Study Guide

30

System Resources

DO NOT REPRINT © FORTINET

In this section, you will learn about the life of a packet.

Network Security Support Engineer 7.2 Study Guide

31

System Resources

DO NOT REPRINT © FORTINET

PPP uses the firewall policy configuration to choose from a group of parallel options to identify the optimal path for processing a packet. The path identified by PPP is made up of the various processes the packet must pass through. Hardware, such as CP8, CP9, or network processors, can offload and accelerate many of these processes. FortiGate hardware and software configuration affect the path that a packet takes. The next few slides provide flowcharts displaying examples of packet processing in several scenarios. Note that these examples do not cover all possible scenarios, nor do they show every step or process packets are subjected to during inspection. The purpose of these slides is to provide common examples of packet flow on FortiGate.

Network Security Support Engineer 7.2 Study Guide

32

System Resources

DO NOT REPRINT © FORTINET

This slide shows the steps that the first packets of a session go through as they enter, pass though, and exit FortiGate. This scenario is for FortiGate with SPUs. FortiGate performs some security inspections early in the life of the packet, such as ACL, Host Protection Engine, and IP integrity header checking. FortiGate does this to make sure the packets are within acceptable parameters before allowing the packet to move through the rest of the processes. These inspections are handled by the network processor in order to minimize impact on the FortiGate CPU. Each version of the network processor has criteria that defines which traffic can be offloaded. The network processor enhances overall performance by allowing offloaded sessions to bypass the FortiGate CPU after the session is established and the session key is installed in the network processor. The network processor can also handle IPsec VPN encryption and decryption operations, where the configured encryption and hashing algorithms are supported in hardware. The content processor functions like a co-processor for the FortiGate CPU to improve overall system performance by offloading certain tasks, such as pattern matching for flow-based UTM inspection with the IPS engine, SSL/TLS decryption and encryption for deep SSL inspection, and IPsec encryption and decryption operations for supported algorithms. Note that the packet processing for virtual FortiGate devices is identical with the only difference being that the CPU handles all processes instead of being able to offload some of them to network and content processors.

Network Security Support Engineer 7.2 Study Guide

33

System Resources

DO NOT REPRINT © FORTINET

This slide shows how subsequent packets in an established session where UTM/NGFW inspection is not configured are handled by FortiGate after being offloaded to a network processor. After the session key is installed in the network processor, subsequent packets for the offloaded session skip routing and kernel processors, bypassing the FortiGate CPU, and are forwarded out the egress interface by the network processor. An important consideration is the impact offloading has on troubleshooting. When a session is offloaded to the network processor, you are unable to view these accelerated packets through the diagnose sniffer packet or diagnose debug flow CLI commands or the packet capture feature on the GUI.

Network Security Support Engineer 7.2 Study Guide

34

System Resources

DO NOT REPRINT © FORTINET

This slide shows how subsequent packets in an established session with flow-based UTM/NGFW configured are handled by FortiGate where NTurbo and IPSA are supported and enabled. NTurbo is a feature that enables flow-based UTM/NGFW sessions to be accelerated by NP6 or NP7 network processors to and from the IPS engine. IPSA is a feature that allows basic or advanced pattern matching operations required for flow-based security profile inspection to be offloaded to CP8 or CP9 content processors. When IPSA is enabled, flow-based pattern matching databases are compiled and downloaded to the content processors from the IPS engine and IPS database. After the session key is installed in the network processor, subsequent packets for the accelerated session skip routing and kernel processors but UTM/NGFW operations are still handled by the CPU with IPSA offloading pattern matching to the CP8 or CP9 content processors.

Network Security Support Engineer 7.2 Study Guide

35

System Resources

DO NOT REPRINT © FORTINET

This slide shows how subsequent packets in an established session with proxy-based UTM/NGFW configured are handled by FortiGate. The network processor does not offload sessions where proxy-based features are configured, so the FortiGate CPU handles packet processing and inspection through a combination of the IPS engine and the FortiOS proxy. The network processor still conducts some early security inspections before handing off the packets to the IPS engine, and can still be leveraged for IPsec tunnel decryption and encryption. The FortiGate CPU can leverage the content processors to handle SSL/TLS encryption and decryption—if SSL deep inspection is configured. Note that the packet flow is modified when SSL deep inspection is configured. If the IPS engine determines that the session needs to be decrypted: • The IPS engine sends the packet to the proxy for decryption. • The proxy decrypts the SSL/TLS packet by offloading the operation to the content processor. • The proxy sends the decrypted packet back to the IPS engine for IPS and application control inspection. • The IPS engine sends the decrypted packet back to the proxy for the configured proxy-based inspection. • The proxy encrypts the SSL/TLS packet by offloading the operation to the content processor.

Network Security Support Engineer 7.2 Study Guide

36

System Resources

DO NOT REPRINT © FORTINET

In this section, you will learn about how FortiGate uses memory.

Network Security Support Engineer 7.2 Study Guide

37

System Resources

DO NOT REPRINT © FORTINET

To understand how FortiGate uses its memory, you must understand the architecture of FortiOS. The heart of FortiOS is its kernel. The kernel is where FortiGate makes some of the most basic and important decisions, such as how to route a packet, or when to offload a session to an NPU processor. FortiOS runs on hardware. The device drivers bridge the kernel with the hardware. The user space is located above the kernel. Several application processes or daemons run in the user space. Above the kernel and the user space is the configuration layer.

Network Security Support Engineer 7.2 Study Guide

38

System Resources

DO NOT REPRINT © FORTINET

FortiOS is a 64-bit architecture, therefore the kernel doesn't need to use memory paging to access the whole memory space. All the memory space is directly accessible by the kernel. The command shown on this slide displays: • The total amount of system memory (MemTotal) • The total amount of free memory (MemFree)

Network Security Support Engineer 7.2 Study Guide

39

System Resources

DO NOT REPRINT © FORTINET

FortiGate allocates memory for five main purposes: • Kernel memory slabs • System I/O cache • Buffers • Shared memory • Process memory You will learn about each of these purposes in this lesson.

Network Security Support Engineer 7.2 Study Guide

40

System Resources

DO NOT REPRINT © FORTINET

The kernel memory slabs are collections of objects with a common purpose. They are used by the kernel to store information in memory. This slide shows an example of some slabs. There are slabs for storing information about the TCP sessions. The entries in the route cache are also stored in memory slabs.

Network Security Support Engineer 7.2 Study Guide

41

System Resources

DO NOT REPRINT © FORTINET

To check how much memory is being allocated to kernel slabs, use the command diagnose hardware sysinfo slab. The first column shows the slab name. The second column shows the total amount of active objects, then the amount of available objects, and then the size of each object. You can calculate the total amount of memory allocated to each slab type by multiplying the number of available objects by their size.

Network Security Support Engineer 7.2 Study Guide

42

System Resources

DO NOT REPRINT © FORTINET

There are no direct reads and writes made to hard disks or flash disks. Each access is done through a cache held in memory—the system I/O cache. The system I/O cache is used to speed up access to information stored in the hard and flash disk memories. Some processes, such as logging, WAN optimization, and explicit proxy store information on the hard disk, so they get the performance boost provided by this memory allocation. An I/O cache page is labeled as active when it has been recently used or modified. It enters the inactive state after it has not been used for some time. The kernel may reclaim an inactive page if needed.

Network Security Support Engineer 7.2 Study Guide

43

System Resources

DO NOT REPRINT © FORTINET

Use the command shown on this slide to display the total amount of memory allocated for the I/O cache. This command is useful when troubleshooting high memory issues to determine where memory is being allocated. A high amount of memory allocated to the I/O cache could indicate that too many logs are being created.

Network Security Support Engineer 7.2 Study Guide

44

System Resources

DO NOT REPRINT © FORTINET

Above the kernel layer, there are multiple application processes or daemons running. The operating system allocates separate blocks of memory to each process. A process can access the memory that was allocated to it, but it cannot access the memory that was allocated to any other process. So, a process cannot share information with another process by reading or writing data into the memory allocated to that other process. For that purpose, the operating system dynamically allocates shared memory (SHM). Multiple processes can access the SHM, allowing them to share information.

Network Security Support Engineer 7.2 Study Guide

45

System Resources

DO NOT REPRINT © FORTINET

Next, examine the output for diagnose sys top. It lists processes that use the most CPU or memory. Some common processes include: • • • • •

ipsengine, scanunitd, and other inspection processes reportd fgfmd for FortiGuard and FortiManager connections forticron for scheduling Management processes (newcli, miglogd, cmdb, sshd, and httpsd)

To sort the list by highest CPU usage, press c. To sort by highest RAM usage, press m.

Network Security Support Engineer 7.2 Study Guide

46

System Resources

DO NOT REPRINT © FORTINET

The table on this slide shows some of the most common processes.

Network Security Support Engineer 7.2 Study Guide

47

System Resources

DO NOT REPRINT © FORTINET

The table on this slide shows more of the most common processes.

Network Security Support Engineer 7.2 Study Guide

48

System Resources

DO NOT REPRINT © FORTINET

The command diagnose sys top shows the state of each process. A process can be in one of four states: sleeping (S), running (R), do not disturb (D), or zombie (Z). The S and R states are normal. It is also normal if a process goes briefly to the D state. The Z state is not normal. Also, it is not normal if a process stays in the D state for a long time. This usually indicates that the process is not working properly.

Network Security Support Engineer 7.2 Study Guide

49

System Resources

DO NOT REPRINT © FORTINET

In this section, you will learn about general system troubleshooting commands.

Network Security Support Engineer 7.2 Study Guide

50

System Resources

DO NOT REPRINT © FORTINET

The command shown on this slide is usually one of the first debug commands that you use when troubleshooting. The output shows the firmware version, FortiGuard database versions, license status, operation mode, number of VDOMs, and system time.

Network Security Support Engineer 7.2 Study Guide

51

System Resources

DO NOT REPRINT © FORTINET

The command shown on this slide displays overall memory and CPU use. It also shows session creation rate, number of viruses caught, and number of attacks blocked by the IPS. The last line displays the system uptime. This output gives you a quick view of how much traffic the device is handling.

Network Security Support Engineer 7.2 Study Guide

52

System Resources

DO NOT REPRINT © FORTINET

The command shown on this slide displays overall memory and CPU use. It also shows session creation rate, number of viruses caught, and number of attacks blocked by the IPS. The last line displays the system uptime. This output gives you a quick view of how much traffic the device is handling.

Network Security Support Engineer 7.2 Study Guide

53

System Resources

DO NOT REPRINT © FORTINET

The real-time debug commands generate information in real time about what a specific FortiGate process or feature is doing. The debug level is a bitmask value that specifies which types of messages are displayed. The meaning of the debug value depends on each process. However, for all cases, a debug level of 0 means no output (disabled) and a debug level of -1 means enabling all possible message types.

Network Security Support Engineer 7.2 Study Guide

54

System Resources

DO NOT REPRINT © FORTINET

This slide shows the two commands you use to enable the IPsec real-time debug output. You can also enable the option to prepend the system time to each debug line. It is important to disable any real-time debug after using it because they consume FortiGate resources and some can be CPU intensive. The command diagnose debug reset resets any filters that are configured for debugging, and disables debug output for all administrators currently running debugs on FortiGate.

Network Security Support Engineer 7.2 Study Guide

55

System Resources

DO NOT REPRINT © FORTINET

Application layer test commands don’t display information in real time, but they do show statistics and configuration information about a feature or process. You can also use some of these commands to restart a process or execute a change in its operation.

Network Security Support Engineer 7.2 Study Guide

56

System Resources

DO NOT REPRINT © FORTINET

In this section, you will examine conserve mode, now that you have a better understanding of how FortiGate uses memory.

Network Security Support Engineer 7.2 Study Guide

57

System Resources

DO NOT REPRINT © FORTINET

Conserve mode is a protection mechanism that is triggered when FortiGate doesn’t have enough memory available to handle traffic. Content inspection (especially proxy-based) increases memory use beyond simple firewall policies. In other words, when antivirus is enabled, FortiGate is more likely to use more memory, which can cause FortiGate to enter conserve mode. You can identify whether antivirus or any other process is using too much memory by running the CLI command diagnose sys top. FortiGate has only one conserve mode. It is triggered based on memory usage. There are three memory thresholds that you can configure on the CLI: • Extreme: The threshold at which FortiGate starts dropping new sessions. • Red: The threshold at which FortiGate enters conserve mode. • Green: The threshold at which FortiGate exits conserve mode.

Network Security Support Engineer 7.2 Study Guide

58

System Resources

DO NOT REPRINT © FORTINET

You can use the commands shown on this slide to change the default conserve mode threshold values.

Network Security Support Engineer 7.2 Study Guide

59

System Resources

DO NOT REPRINT © FORTINET

This slide shows the entries that are generated in the event logs when FortiGate enters memory conserve mode. If the GUI is under a heavy load, it may be unresponsive, making the GUI logs inaccessible. In this case, you can view the crash log on the CLI for conserve mode messages. This slide shows an example of a typical conserve mode crash log entry.

Network Security Support Engineer 7.2 Study Guide

60

System Resources

DO NOT REPRINT © FORTINET

What actions does FortiGate take to preserve memory while in conserve mode? • • •

FortiGate does not accept configuration changes, because they might increase memory usage. FortiGate does not run any quarantine action, including forwarding suspicious files to FortiSandbox. FortiGate activates protection measures to recover memory space.

Network Security Support Engineer 7.2 Study Guide

61

System Resources

DO NOT REPRINT © FORTINET

The av-failopen setting defines the action that is applied to any proxy-based inspected traffic, while the unit is in conserve mode (and as long as the memory usage does not exceed the extreme threshold). This setting also applies to flow-based antivirus inspection. Three different actions can be configured: • • •

off: All new sessions with content scanning enabled are not passed but FortiGate processes the current active sessions. pass (default): All new sessions pass without inspection until FortiGate switches back to non-conserve mode. one-shot: Similar to pass in that traffic passes without inspection. However, it will keep bypassing the antivirus proxy even after it leaves conserve mode. Administrators must either change this setting, or restart the unit to restart the antivirus scanning

However, if memory usage exceeds the extreme threshold, new sessions are always dropped, regardless of the FortiGate configuration.

Network Security Support Engineer 7.2 Study Guide

62

System Resources

DO NOT REPRINT © FORTINET

Use the command shown on this slide to identify whether a FortiGate device is currently in conserve mode.

Network Security Support Engineer 7.2 Study Guide

63

System Resources

DO NOT REPRINT © FORTINET

Another undesirable state for FortiGate is the AV fail-open session mode. This mode kicks in, not during a highmemory situation, but when a proxy on FortiGate runs out of available sockets to process more proxy-based inspected traffic. If av-failopen-session is enabled, FortiGate allows all the sessions. Otherwise, by default, it blocks new sessions that require proxy-based inspection until new sockets become available.

Network Security Support Engineer 7.2 Study Guide

64

System Resources

DO NOT REPRINT © FORTINET

FortiGate has one more mechanism to free memory when there is not much available. If the kernel cannot allocate more memory pages, it deletes the oldest sessions. The command shown on this slide displays the numbers of sessions deleted by the kernel because of this mechanism.

Network Security Support Engineer 7.2 Study Guide

65

System Resources

DO NOT REPRINT © FORTINET

FortiGate has a mechanism to protect memory use against some forms of DoS attacks. FortiGate categorizes an entry in the session table as an ephemeral session when it is a TCP session that is not fully established (threeway handshake not completed), or it is a UDP session with only one packet received. During some DoS attacks, the number of these types of sessions tends to increase abnormally, potentially consuming the device’s memory. FortiGate sets a hard limit on the maximum number of ephemeral sessions that can exist at the same time in the session table.

Network Security Support Engineer 7.2 Study Guide

66

System Resources

DO NOT REPRINT © FORTINET

In this section, you will learn how to optimize memory use by fine-tuning the FortiGate configuration.

Network Security Support Engineer 7.2 Study Guide

67

System Resources

DO NOT REPRINT © FORTINET

Many FortiGate processes, such as DLP or antivirus scanning, are memory-intensive. So, memory optimization is important, especially in small devices, to guarantee that these processes do not force FortiGate into memory conserve mode. This slide shows some recommendations for optimizing memory use. These tips might significantly increase the available memory in a device that is frequently entering conserve mode. The first and most logical step is to disable features that are not required. For example, if the network already has a FortiMail device for antispam, an administrator does not need to configure antispam on FortiGate. Also, usually not all IPS signatures are required. Another recommendation is to reduce the maximum file size to inspect, which is set to 10 MB by default. You can reduce this value to 2 or 3 MB without significantly reducing the virus catching rate, because a typical virus size is less than 1 MB.

Network Security Support Engineer 7.2 Study Guide

68

System Resources

DO NOT REPRINT © FORTINET

Additionally, you can reduce the amount of memory allocated to some caches, such as the ones for FortiGuard and DNS.

Network Security Support Engineer 7.2 Study Guide

69

System Resources

DO NOT REPRINT © FORTINET

The FortiGate session table can consume an important portion of memory, especially in networks with a high rate of traffic. By default, a session without traffic remains in the table for up to one hour. Although a TTL this high might be required by some applications, in most networks, you can reduce the session TTL. When you reduce the TTL, FortiGate ages out idle sessions much more quickly, increasing the amount of available memory. There are four places in the FortiGate configuration where you can reduce the session TTL. Two of them are: • Globally, for all the traffic • On an IP protocol and port number basis

Network Security Support Engineer 7.2 Study Guide

70

System Resources

DO NOT REPRINT © FORTINET

The other two places where you can reduce the session TTL are: • For each firewall policy • For each application control If an application requires a high session TTL, you can reduce the TTL globally to five minutes. However, you can also set it to a higher number for the specific application port number, firewall policy, or with an application control application override entry by setting the session-ttl option using the CLI.

Network Security Support Engineer 7.2 Study Guide

71

System Resources

DO NOT REPRINT © FORTINET

You can also reduce most TCP session timers from their default values without causing problems to the applications. This slide shows some recommended values that are equal to or below the default values. Use these recommended values to optimize the memory use. The tcp-halfopen-timer controls for how long, after a SYN packet, a session without SYN/ACK remains in the table. The tcp-halfclose-timer controls for how long, after a FIN packet, a session without FIN/ACK remains in the table. The tcp-timewait-timer controls for how long, after a FIN/ACK packet, a session remains in the table. A closed session remains in the session table for a few seconds more to allow any out-of-sequence packet.

Network Security Support Engineer 7.2 Study Guide

72

System Resources

DO NOT REPRINT © FORTINET

In this section, you will learn how to troubleshoot system crashes.

Network Security Support Engineer 7.2 Study Guide

73

System Resources

DO NOT REPRINT © FORTINET

On some FortiGate models, you can configure the device to store all console logs in the flash memory. This is especially useful when troubleshooting unexpected restarts and devices that randomly become unresponsive. Once FortiGate stores the logs, you can display them on the CLI or download them from the GUI for further analysis. This slide shows the commands for enabling, displaying, and clearing the console logs.

Network Security Support Engineer 7.2 Study Guide

74

System Resources

DO NOT REPRINT © FORTINET

A crash dump message is usually generated through the console port when the device crashes. Crash dump messages can provide useful information to Fortinet developers. If the problem is a FortiGate device that is restarting unexpectedly, you should check the logs, the console logs, and the crash log. If the FortiGate model doesn’t support a console log, keep a laptop connected to the console port and wait until another crash happens.

Network Security Support Engineer 7.2 Study Guide

75

System Resources

DO NOT REPRINT © FORTINET

FortiGate freezes when it stops handling traffic, you cannot connect to it, and you can’t access its console port. Only power cycling fixes the issue. In these cases, you could capture any crash dump message in the console port. Additionally, and in the case of models with more than one CPU, you can enable the NMI watchdog feature, which automatically causes a crash in the system (and forces the crash dump) when no new daemons have been scheduled in the last 10 minutes. This is an indication that the device is not operating normally and might be frozen. Some FortiGate models also have an external NMI button. If the device freezes and no crash dump message was generated, you can press the NMI button to force a crash and generate a crash dump message.

Network Security Support Engineer 7.2 Study Guide

76

System Resources

DO NOT REPRINT © FORTINET

Each time an application crashes, or closes, an entry is generated in the crash log. When an application crashes, the entry contains the name of the application, the time it crashed, and the termination signal. This slide shows a sample of a crash in the crash log. In this example, the application that failed was the miglogd process, which handles logging. The termination signal is 11, which is a segmentation fault.

Network Security Support Engineer 7.2 Study Guide

77

System Resources

DO NOT REPRINT © FORTINET

The table shown on this slide contains the most common termination signal numbers. Any administrator can manually terminate a process by using the command shown on this slide, followed by the termination signal number and the process ID. The command diagnose sys top lists the process ID numbers. Manually terminating a process is not usually required under normal circumstances. If you must terminate a process, use the termination signal 9. Improperly terminating a process can make a FortiGate system unstable. Note that not all the signal numbers generate a crash log. Processes can also be killed through the GUI under admin > System > Process Monitor. If you want to generate a crash log, select Kill&Trace in the Kill Process drop-down menu.

Network Security Support Engineer 7.2 Study Guide

78

System Resources

DO NOT REPRINT © FORTINET

So, how do you know if the crash log is normal or not? In most cases, entries in the crash log are normal. You can consider a crash log entry to be suspicious if it happens at the same time as a failure in a FortiGate feature, or abnormal behavior of FortiGate. For example, a crash log entry that is generated when the device unexpectedly restarts, might provide information about the cause. A crash in the sslvpnd process when all SSL VPN users get disconnected is also relevant. The crash log includes the details about the crash and information that can be used by Fortinet support to identify which code triggered the problem.

Network Security Support Engineer 7.2 Study Guide

79

System Resources

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned how to use and optimize FortiOS system resources.

Network Security Support Engineer 7.2 Study Guide

80

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

In this lesson, you will learn about traffic and session monitoring.

Network Security Support Engineer 7.2 Study Guide

81

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

After completing this section, you should be able to achieve the objectives shown on this slide. By demonstrating competence in traffic and session monitoring, you will be able to interpret the information in the session table, capture traffic using the built-in sniffer, analyze the output of the debug flow, and configure and troubleshoot session helpers and the SIP application layer gateway.

Network Security Support Engineer 7.2 Study Guide

82

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

In this section, you will learn about session table entries.

Network Security Support Engineer 7.2 Study Guide

83

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

The FortiGate session table contains detailed information about every IP connection that crosses or terminates at FortiGate. You can use the commands shown on this slide to display the total number of sessions in an active VDOM, and to view a brief summary of each session. The session list command lists one session on each line, and includes information, such as protocol, source IP address, destination IP address, and port. You can use the grep utility with this command to list only the sessions for a specific IP address.

Network Security Support Engineer 7.2 Study Guide

84

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

To display detailed information about sessions, use the command shown on this slide. It is recommended that you set the session filter first, because an unfiltered output displays all the details about all the existing sessions. For high-end devices, a list of all existing sessions could be in the thousands, or even millions. You can filter the output by policy ID, source IP address, source port, destination IP address, and destination port.

Network Security Support Engineer 7.2 Study Guide

85

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

Some configuration changes, such as security profile changes or session helper changes, apply only to new sessions. In the case of those changes, existing sessions keep using the previous configuration until they expire or are terminated. This is important to remember when troubleshooting problems. After a security profile change, you should clear any sessions related to that change, and generate new sessions. Use the command shown on this slide to remove all sessions that match the session filter. You must be careful with this command because it can, potentially, clear all the existing sessions if no filter has been set. Before clearing out any sessions, use appropriate filters.

Network Security Support Engineer 7.2 Study Guide

86

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows an example output detailing information particular to a single session table entry. From left to right, and from top to bottom, the following information is highlighted: • • • • • • • •

The IP protocol number and the protocol state The length of time until the session expires (if no more traffic matches the session) Traffic shaping counters Session flags Received and transmitted packet and byte counters The original and reply direction of the traffic. If the device is using NAT, this portion shows the type of NAT (source or destination) for each traffic direction, and the NAT IP address. The ID of the matching policy Counters for hardware acceleration—The presence of the npu info field indicates the session has been offloaded to hardware acceleration.

Use the CLI command diagnose sys session list for IPv4 traffic, and the command diagnose sys session6 list for IPv6 traffic. The output for both commands is similar (it displays the same fields, in the same order).

Network Security Support Engineer 7.2 Study Guide

87

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

The protocol state in the session table is a two-digit number. For TCP, the first number (from left to right) is related to the server-side state and is 0 when the session is not subject to any inspection (flow or proxy). If flow or proxy inspection is done, then the first digit is different from 0. The second digit is the client-side state. The table and flow graph shown on this slide correlate the digit value with the different TCP session states. The values apply for both server-side and client-side states. For example, for the client-side state, when FortiGate receives the SYN packet, the second digit is 2. It changes to 3 when FortiGate receives the SYN/ACK packet. Similarly, for the server-side state, the first digit is 2 after FortiGate sends the SYN packet, and then changes to 3 after FortiGate sends the SYN/ACK packet. In addition, proto_state=11 means that the TCP three-way handshake for both server-side and client-side is completed (ESTABLISHED). When a session is closed by both the sender and receiver, FortiGate keeps that session in the session table for a few seconds, to allow for any out-of-order packets that might arrive after the FIN/ACK packet. This is the state value 5.

Network Security Support Engineer 7.2 Study Guide

88

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

For UDP, the session state can have only two values: 00 when traffic is only one way, and 01 when there is traffic two ways. For ICMP, the protocol state is always 00.

Network Security Support Engineer 7.2 Study Guide

89

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This table shows the meaning of the most important session flags. For example, the log flag indicates that the session is being logged. The local flag indicates that the session originates from FortiGate or terminates on FortiGate.

Network Security Support Engineer 7.2 Study Guide

90

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

When working with FortiGate, it’s important to understand the concept of may_dirty and dirty sessions. The may_dirty sessions are firewall sessions that were created after matching a firewall policy with accept as action. For FortiGate to identify the matching policy, it performs a firewall policy lookup, selecting the first matching policy in the configuration from the top down. Most firewall sessions contain the may_dirty flag. However, some sessions such as expectation sessions, do not contain the may_dirty flag because they are not created as a result of matching a firewall policy. For new sessions, FortiGate performs route and firewall policy lookups upon receiving the first packet (in the original direction). FortiGate also performs a route lookup—but not a firewall policy lookup—for the first reply packet. FortiGate then saves the information that results from the route lookup—the outgoing interface and gateway to use—and the firewall policy lookup—policy ID, address translation, inspection, authentication, logging, and so on—to the session. FortiGate doesn’t perform additional lookups for the session unless, the session is flagged as dirty.

Network Security Support Engineer 7.2 Study Guide

91

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

By default, FortiGate flags all may_dirty sessions as dirty if there is a routing, firewall policy, or interface change. The FortiGate must re-evaluate every dirty session. During re-evaluation, it checks both directions of the dirty session.

Network Security Support Engineer 7.2 Study Guide

92

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

After a routing change, the routing information of impacted sessions is flushed. The default re-evaluation process following a routing change for sessions without source NAT (SNAT) is as follows: •

• • • • •

•

If the impacted session is offloaded to the NPU, FortiGate instructs the NPU to send the next packet from each direction of the session to the CPU. This ensures that the session is handled by the CPU, and thus reevaluated. If the session is not offloaded to the NPU, then the packets are always handled by the CPU, and this step is not required. In the original direction, FortiGate performs route and firewall policy lookups for the first packet. In the reply direction, FortiGate performs only a route lookup for the first packet. FortiGate updates the session with the new routing and firewall policy information, and removes the dirty flag. If the matching firewall policy action is still accept, FortiGate forwards the packet. If the matching firewall policy action is deny, FortiGate flags the session as block, drops the packet, and retains the session in the session table until it expires. FortiGate also drops any additional packets that match the session . FortiGate eventually offloads allowed sessions again to the NPU, if they still meet the NPU offloading requirements.

Network Security Support Engineer 7.2 Study Guide

93

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows the transition of an ICMP session from may_dirty to dirty, and then back to may_dirty, following a route change. Note that only relevant lines of the session are displayed. Before the route change, the session is flagged as may_dirty. The session output shows the index number of the outgoing interface in use (19), as well as the gateway information (gwy). After the route change, the session is flagged as dirty. Note that the may_dirty flag is still there, and the dirty flag is just added. The gateway information is also flushed. After re-evaluation, the dirty flag is removed, and the index number of the outgoing interface and the gateway information are updated based on the new route. Note that the firewall policy (policy_id) didn’t change. This is because the firewall policy lookup during reevaluation resulted in the same firewall policy, but this is not always the case.

Network Security Support Engineer 7.2 Study Guide

94

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

By default, SNAT sessions are not flagged as dirty following a routing change that impacts the session. This is true if the route in use is still in the FIB. However, if the route is removed from the FIB, then FortiGate flags the session as dirty, flushes the outgoing interface and gateway information, and then re-evaluates the session on the next packet received. To force the re-evaluation of SNAT sessions following a related routing change, regardless of whether the route in use is still in the FIB or not, enable the snat-route-change setting, as shown on this slide. Note that during re-evaluation of SNAT sessions, if the new route and firewall policy lookup results in a change of the SNAT IP, then FortiGate drops the packet and clears the session. This means that the impacted application could have to initiate a new connection to resume network connectivity, especially if the application is TCP-based. This slide shows the debug flow output for an SNAT session during re-evaluation. Because the SNAT IP of the new path (192.2.0.9) is different from the SNAT IP of the current path (192.2.0.1), FortiGate drops the packet and clears the session. This also means that, from a connectivity point of view, it makes sense to enable snat-route-change only when the new path for the session uses the same SNAT IP, which can be achieved using IP pools.

Network Security Support Engineer 7.2 Study Guide

95

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

When you make a change to a firewall policy, all existing sessions with the flag may-dirty change to status dirty. FortiGate then performs a firewall policy lookup for the first packet received for each existing session; it updates the session table entry and resets the flag to may-dirty. Then, it processes the next packets based on the new firewall settings. If the firewall handles a huge number of sessions, flagging the sessions as dirty, and performing a firewall policy lookup for the sessions may result in high CPU utilization. To prevent this, you can configure FortiGate to flag only new sessions as dirty by setting firewall-session-dirty to check-new. The result is that FortiGate evaluates only new sessions against the new firewall policy configuration. The firewall-session-dirty setting is available on the VDOM and firewall policy levels. It is set to checkall by default, which instructs FortiGate to flag all sessions as dirty. To instruct FortiGate to follow the firewall policy-level setting, you must set the VDOM-level setting to check-policy-option. Note that the firewall policy-level setting is available only if the VDOM-level setting is set to check-policy-option.

Network Security Support Engineer 7.2 Study Guide

96

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows the details of an established SSH session when firewall-session-dirty is set to checknew. Note the presence of the persistent flag in the session, and the absence of the may_dirty flag, which indicates that FortiGate does not perform a new firewall policy lookup if there is a configuration change.

Network Security Support Engineer 7.2 Study Guide

97

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

In this section, you will learn about two useful troubleshooting tools: the built-in sniffer and the debug flow, and how they are affected by hardware acceleration.

Network Security Support Engineer 7.2 Study Guide

98

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

Now you will learn about the built-in sniffer. When you enable this tool, you can choose from six verbosity levels. The table on this slide shows what information is displayed in each level. Level 4 is usually used to check how the traffic is flowing and that FortiGate is not dropping packets. Level 3 or level 6 are usually used to convert the output to PCAP format, which you can later analyze with a tool, such as WireShark.

Network Security Support Engineer 7.2 Study Guide

99

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

To sniffer traffic in all interfaces, use the keyword any as the interface name. Stop the sniffer by pressing Ctrl+C, and check for dropped packets. If there were dropped packets during the sniffer, it means that not all the traffic that matched the sniffer filter could be captured. So, you might need to capture the traffic again using a stricter filter. If you do not specify an option for the timestamp, the debug shows the time, in seconds, since it started running. As you learned earlier in the lesson, you can prepend the local system time to easily correlate a packet with another recorded event.

Network Security Support Engineer 7.2 Study Guide

100

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

In the GUI under Network > Diagnostics > Sniffer, you can perform the same function as on the previous slide without using a CLI command. You also have the option to save the captured packets as a PCAP.

Network Security Support Engineer 7.2 Study Guide

101

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

Another useful FortiGate troubleshooting tool is the debug flow. The debug flow is also called the internal sniffer because it works similarly to the built-in sniffer, but the output shows step-by-step, and with details, what the kernel is doing with each packet.

Network Security Support Engineer 7.2 Study Guide

102

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows an example of a debug flow output. In this example, the debug flow has captured the three packets of a TCP three-way handshake. The output for the SYN packet shows when the kernel creates a new session (with its session ID), finds the route to the destination, and applies NAT. It also shows the ID of the policy that matches this traffic. The output of the SYN/ACK and ACK packets shows the session ID and NAT information. This tool is useful for many troubleshooting cases, such as when you need to understand why a packet is taking a specific route, or why a specific NAT IP address is applied.

Network Security Support Engineer 7.2 Study Guide

103

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

The debug flow can also help you identify why FortiGate is dropping packets. In those cases, the debug flow usually shows an error message explaining why a packet was dropped. This slide shows three messages that you commonly see in debug flow output when FortiGate is dropping packets: • Denied by forward policy check (policy 0) indicates that either no firewall policy allows the traffic, or that a disclaimer has not been accepted yet. • Denied by quota check indicates that the packet was dropped because of a traffic shaper that has exceeded one of its thresholds.

Network Security Support Engineer 7.2 Study Guide

104

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows two more common debug flow error messages. The first error message indicates that the packet failed the reverse path forwarding check. The second error message usually indicates one of the following: • The packet is destined to a FortiGate IP address (for example, management traffic), but the service is not enabled, the service is using a different port, the source IP address is not included in the trusted list, or the packet matches a local-in policy with the action deny. • The packet is destined to a device on the other side of FortiGate, but a virtual IP or IP pool is wrongly using that IP address. In this case, check your virtual IP or IP pool configuration.

Network Security Support Engineer 7.2 Study Guide

105

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

Just like with the sniffer tool, there is the option to run the debug flow in the GUI. Once completed, the output can be saved as a CSV file.

Network Security Support Engineer 7.2 Study Guide

106

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

In order for the packet sniffer and debug flow to pick up traffic, all packets must hit the CPU. This can be accomplished by disabling hardware acceleration. As a best practice, this is only done for troubleshooting purposes. Permanently disabling hardware acceleration will significantly decrease the performance of a FortiGate device. Hardware acceleration can be disabled at the firewall level or the global level. Once disabled, all packets are processed by the CPU, and the sniffer and debug flow will be able to display traffic flow information.

Network Security Support Engineer 7.2 Study Guide

107

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

Hardware acceleration can be disabled at the firewall level by setting auto-asic-offload to disable. This can be useful when the scope of troubleshooting traffic is known to be specific to one firewall policy. It is also possible to disable hardware acceleration globally.

Network Security Support Engineer 7.2 Study Guide

108

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

There are two ways to disable hardware acceleration globally. The first way is to disable it using the diagnose command shown on this slide. Depending on the FortiGate model, one or more NP6 units must be disabled. In this example, the partial output of diagnose npu np6 port-list on a FortiGate 1500D is shown. Since this is a diagnose command, fastpath is automatically re-enabled when the FortiGate reboots. The second way to disable hardware acceleration globally is to use the config command shown on this slide. Fastpath is enabled by default. This will disable all network processor offloading for all traffic. Be aware that disabling hardware acceleration globally could have a significant impact on CPU performance. Disabling hardware acceleration should only be considered for troubleshooting purposes. It is recommended to re-enable hardware acceleration, once troubleshooting has been concluded.

Network Security Support Engineer 7.2 Study Guide

109

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

In this section, you will learn how FortiGate can create sessions for traffic that is expected to come but hasn't arrived yet.

Network Security Support Engineer 7.2 Study Guide

110

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

To understand what a session helper does, take a look at the example shown on this slide of a network protocol that might have problems when a network device is performing NAT. The example shows the FTP protocol working in active mode. Any FTP file transfer is composed of two TCP sessions: one for the control channel and one for data transfer. The control channel is always initiated from the client to the server and is used to send the FTP commands. The FTP commands allow the client to move through the server folder, specify the type of file transfer, and initiate the data channel for uploading or downloading a file. FTP has two modes: active and passive. The mode determines who initiates the data channel. In passive mode, the data channel is initiated by the client. In active mode, the client sends the port command through the control channel. The command includes the client IP address and the TCP port for the incoming data channel. Then, the server initiates the TCP session to the IP address and port number specified by the port command.

Network Security Support Engineer 7.2 Study Guide

111

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

Active FTP does not work if the control channel crosses a network device performing NAT, and that does not have a session helper. In the example shown on this slide, an FTP client is connecting to an active mode FTP server. There is a router in the middle doing NAT of the client IP address 10.0.1.10 to the NAT IP address 10.200.1.1. After the control channel is up, the client sends the port command with its IP address, 10.0.1.10, as the destination for the data channel. When that FTP packet crosses the router, the source IP address in the IP header is changed from 10.0.1.10 to 10.200.1.1. However, the IP address in the FTP port command is not translated to 10.200.1.1. After the server receives that FTP command, it tries to bring up the TCP session for the data channel. It sends the SYN packet to the IP address 10.0.1.10. This address is probably not routable because it is a private IP behind a device performing NAT. The file transfer fails.

Network Security Support Engineer 7.2 Study Guide

112

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

The FTP session helper fixes this problem by replacing the router with a FortiGate device. The following paragraph describe what the FortiGate session helper does. When the packet with the FTP port command arrives at FortiGate, FortiGate not only translates the source IP address in the IP header, the session helper also translates the IP address inside the FTP port command. If the source port is also translated in the TCP header, the session helper also does the same in the port command. Another important function of the session helper is to temporarily create an expected session (or pinhole) for the data channel connection that comes from the server. That means that the administrator does not need to manually create firewall policies to allow these incoming TCP sessions (which use random TCP port numbers). The session helper automatically creates the session and opens the door for the incoming connection. After that, the server connects the data channel to the right IP address: 10.200.1.1. That incoming TCP connection is allowed by the expected session previously created by the session helper, even when there is no firewall policy allowing it.

Network Security Support Engineer 7.2 Study Guide

113

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows a packet capture of the previous FTP traffic before the port command reaches FortiGate. You can see the original client IP address, 10.0.1.10.

Network Security Support Engineer 7.2 Study Guide

114

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows another packet capture, this time after the port command crosses FortiGate. The session helper has translated the IP address inside the port command to 10.200.1.1.

Network Security Support Engineer 7.2 Study Guide

115

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

SIP is another protocol that requires a session helper in a NAT environment. Similar to FTP, SIP uses control channels and data channels. In SIP, four data channels, two for each traffic direction, are required for each call. In the example shown on this slide, there are two SIP phones with the IP addresses 10.0.1.10 and 172.168.100.205. Additionally, FortiGate is performing NAT of 10.0.1.10 to 66.171.121.44. Once the control channel is up, a SIP phone sends an invite packet with its IP address and port numbers for two of the four data channels. The FortiGate session helper creates two expected sessions, and translates the IP address inside the invite packet to 66.171.121.44. The remote phone sends an OK packet to the right destination IP address (66.171.121.44). The packets include the IP address and ports for the other two data channels. The session helper creates two more expected sessions, this time using the information coming in the OK packet. After that, the four data channels are connected through the four expected sessions. Firewall policies are not needed to allow this traffic.

Network Security Support Engineer 7.2 Study Guide

116

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

There is a way to list the expected sessions created by the session helpers. In the example shown on this slide, the command lists an expected session to allow traffic from 10.171.121.38 to 100.64.1.1, port TCP 60426.

Network Security Support Engineer 7.2 Study Guide

117

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

The debug flow shows the name of the session helper (if any) that is inspecting the traffic. In this case, it is the FTP session helper. Also, for traffic that matches an expected session previously created by a session helper, the debug flow shows the message: Find an EXP session.

Network Security Support Engineer 7.2 Study Guide

118

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

There are other protocols that, in some circumstances, also require a session helper. Examples includes PPTP, H323, and RSH. You can list the active session helpers by using the command shown on this slide. The output lists the TCP or UDP port numbers that each session helper is listening to. If one of those protocols is using a different port number, you need to change the FortiGate configuration to match it. You can either change the port number in the existing session-helper entry or add a new entry.

Network Security Support Engineer 7.2 Study Guide

119

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

For SIP traffic inspection, FortiGate includes a feature that is smarter and more versatile than the SIP session helper. It is the SIP ALG. The SIP ALG has all the same functions as the SIP helper but provides more features. Also, while session helpers run in the kernel, the SIP ALG runs as a user space process.

Network Security Support Engineer 7.2 Study Guide

120

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

FortiGate uses either the SIP helper or the SIP ALG, depending on the configuration. The system setting default-voip-alg-mode specifies which one is used when no VoIP profile is applied. If it is set to proxybased (default), FortiGate uses the SIP ALG. If it is set to kernel-helper-based, FortiGate uses the SIP helper. If the SIP traffic matches a firewall policy with a VoIP profile, FortiGate always uses the SIP ALG, regardless of the default-voip-alg-mode setting. Fortinet recommends that FortiGate use the SIP ALG. FortiGate should use the SIP helper only when the SIP ALG is not working as expected.

Network Security Support Engineer 7.2 Study Guide

121

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows the commands you use to change the ports for the SIP ALG. The SIP ALG supports SIP over UDP, SIP over TCP, and encrypted (SSL) SIP.

Network Security Support Engineer 7.2 Study Guide

122

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

You can display all active SIP calls, and disconnect any active SIP calls, using the commands shown on this slide.

Network Security Support Engineer 7.2 Study Guide

123

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

You can use sip real-time debugs to display real-time information about SIP traffic.

Network Security Support Engineer 7.2 Study Guide

124

Sessions, Traffic Flow, and Networking

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned about traffic and session monitoring.

Network Security Support Engineer 7.2 Study Guide

125

Security Fabric

DO NOT REPRINT © FORTINET

In this lesson, you will learn about the Fortinet Security Fabric.

Network Security Support Engineer 7.2 Study Guide

126

Security Fabric

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in the Security Fabric, you will be able to describe what the Security Fabric is, the protocols it operates on, and how to troubleshoot common communication and resource issues. You will also learn how to diagnose automation stitches.

Network Security Support Engineer 7.2 Study Guide

127

Security Fabric

DO NOT REPRINT © FORTINET

In this section, you will get a quick overview of the Security Fabric.

Network Security Support Engineer 7.2 Study Guide

128

Security Fabric

DO NOT REPRINT © FORTINET

The Security Fabric provides an intelligent architecture that allows security devices to communicate with each other. This integrated approach allows for the detection, monitoring, and remediation of attacks across the entire attack surface. Hardware, virtual, and cloud-based systems are supported, delivering broad protection and visibility throughout the network.

Network Security Support Engineer 7.2 Study Guide

129

Security Fabric

DO NOT REPRINT © FORTINET

At the core of the solution, the mandatory products are two or more FortiGate devices in NAT mode and a logging system. The logging system must be FortiAnalyzer, FortiAnalyzer Cloud, or FortiGate Cloud. Note that all FortiGate devices must be operate in NAT mode in order to participate in the Security Fabric.

To add more visibility and control, Fortinet recommends adding FortiManager, FortiAP, FortiClient, FortiSandbox, FortiMail, and FortiSwitch. You can extend the solution by adding other network security devices.

Network Security Support Engineer 7.2 Study Guide

130

Security Fabric

DO NOT REPRINT © FORTINET

The Security Fabric uses two Fortinet proprietary protocols: FortiTelemetry and Neighbor Discovery. The default TCP port 8013 for FortiTelemetry can be changed if necessary. In order for a downstream FortiGate to join the Security Fabric, it must initiate the session to the upstream FortiGate through TCP port 8013. For an upstream FortiGate to be able to accept connections from a downstream FortiGate, the Security Fabric Connection setting must be enabled on the network interface (on the GUI under Administrative Access). UDP port 8014 is used for the Neighbor Discovery protocol. This protocol and port are used to exchange informational updates, such as topology changes, among Security Fabric member nodes. It is also used to control logging behavior, so that the same traffic is not logged multiple times. Only FortiGate, or the device connected to the source of the session, creates the log. Unlike the FortiTelemetry port, the Neighbor Discovery port cannot be changed.

Network Security Support Engineer 7.2 Study Guide

131

Security Fabric

DO NOT REPRINT © FORTINET

In this section, you will learn about FortiGate-to-FortiGate communications within the Security Fabric, as well as how to diagnose and troubleshoot potential issues.

Network Security Support Engineer 7.2 Study Guide

132

Security Fabric

DO NOT REPRINT © FORTINET

The screenshot on this slide shows a communication issue between an upstream FortiGate and a downstream FortiGate. Some common causes of this issue include: • The Security Fabric Connection setting has not been enabled on the upstream FortiGate GUI (under Administrative Access). • The FortiGate devices in the Security Fabric are not using the same firmware. • The device has not been authorized on the root FortiGate yet. • The wrong root FortiGate IP address is configured on the downstream FortiGate. • The FortiGate is not configured in NAT mode. • TCP port 8013 is blocked. You can use the diagnose sniffer command to verify this.

Network Security Support Engineer 7.2 Study Guide

133

Security Fabric

DO NOT REPRINT © FORTINET

The first step in troubleshooting communication issues related to the Security Fabric is to run a sniffer on TCP port 8013 or UDP port 8014. In this example, the downstream FortiGate with the the IP address 192.168.1.112 is unable to establish a connection with the upstream FortiGate configured with 192.168.1.111. Since you can see the traffic arriving on the upstream FortiGate, TCP port 8013 is not blocked along the way. Instead, FortiTelemetry has not been enabled on the appropriate interface.

Network Security Support Engineer 7.2 Study Guide

134

Security Fabric

DO NOT REPRINT © FORTINET

After you select the Security Fabric Connection checkbox, and then apply the changes, FortiTelemetry becomes active on the FortiGate interface, which allows incoming Security Fabric connection requests to be accepted. The downstream FortiGate has successfully established a connection with the upstream FortiGate.

Network Security Support Engineer 7.2 Study Guide

135

Security Fabric

DO NOT REPRINT © FORTINET

Use the command diagnose test app csfd 1 to confirm that two ore more devices in the Security Fabric are communicating properly. The command lists Security Fabric statistics, such as all upstream and downstream devices, including their IP address, serial number, and status. In this example, the command was run on a FortiGate connected to an upstream FortiGate as well as a downstream FortiGate.

Network Security Support Engineer 7.2 Study Guide

136

Security Fabric

DO NOT REPRINT © FORTINET

On this slide, you can see the differences when the command is run on the root FortiGate. The group name is shown, and no upstream information is available, because this FortiGate sits at the top of the topology.

Network Security Support Engineer 7.2 Study Guide

137

Security Fabric

DO NOT REPRINT © FORTINET

Use the commands shown on this slide on a non-root FortiGate to view detailed information about upstream and downstream devices.

Network Security Support Engineer 7.2 Study Guide

138

Security Fabric

DO NOT REPRINT © FORTINET

The command diagnose sys csf global shows a summary of all connected devices in the Security Fabric.

Network Security Support Engineer 7.2 Study Guide

139

Security Fabric

DO NOT REPRINT © FORTINET

In this section, you will learn how to troubleshoot performance issues related to the Security Fabric.

Network Security Support Engineer 7.2 Study Guide

140

Security Fabric

DO NOT REPRINT © FORTINET

Use the real-time application debug shown on this slide to troubleshoot issues as they are occurring. For example, if the GUI lags during login, run the debug before navigating to the FortiGate management IP. This same debug can also be used to troubleshoot communication issues. In this output, you can see communication with the downstream FortiGate. The downstream FortiGate always establishes the Security Fabric session with the upstream FortiGate. This is why the TCP source port in this example is 11405, not 8013.

Network Security Support Engineer 7.2 Study Guide

141

Security Fabric

DO NOT REPRINT © FORTINET

When csfd causes high CPU usage, use the same real-time debug. In addition, it is helpful to gather the output that the three additional diagnose commands shown on this slide provide. All three commands dump CPU information about the csfd process, which can reveal a potential bug. You can find the process ID of csfd by running the diagnose sys top command.

Network Security Support Engineer 7.2 Study Guide

142

Security Fabric

DO NOT REPRINT © FORTINET

When troubleshooting high memory usage issues caused by csfd with Fortinet Support, you should collect the output of the commands shown. Each command output contains valuable information about the cause of the high memory use. Note that the diagnose test application command is not a real-time debug and therefore will not cause additional performance impacts on FortiGate.

Network Security Support Engineer 7.2 Study Guide

143

Security Fabric

DO NOT REPRINT © FORTINET

In this section, you will learn about automation stitches and how to troubleshoot them.

Network Security Support Engineer 7.2 Study Guide

144

Security Fabric

DO NOT REPRINT © FORTINET

Administrator-defined automated workflows (called stitches) use if/then logic to cause FortiOS to automatically respond to an event in a preprogrammed way. Because this workflow is part of the Security Fabric, you can set up stitches for any device in the Security Fabric. If you configure stitches in a Security Fabric, you must configure them on the root FortiGate. You configure stitches to run on all FortiGate devices in the Security Fabric or a subset of FortiGate devices. Stitches configured on the root FortiGate are pushed to the relevant leaf FortiGate devices. The root FortiGate does not need to be operational for previously configured stitches to function on leaf FortiGate devices. Each automation stitch pairs an event trigger and one or more actions, which allows you to monitor your network and take appropriate action when the Security Fabric detects a threat or other actionable event. You can use automation stitches to detect events from many sources. Some examples include high CPU, conserve mode, HA failover, reboot, FortiOS event logs with customizable filters, IoCs, and event handlers from FortiAnalyzer. You can configure the Minimum interval (seconds) setting to make sure you don’t receive repeat notifications about the same event. There are several CLI commands available to test, log, and display settings and statistics. These commands will be covered in this lesson.

Network Security Support Engineer 7.2 Study Guide

145

Security Fabric

DO NOT REPRINT © FORTINET

You can use the diagnose automation test command to manually test an automation stitch. The resulting output reveals whether or not the test was successful. Reasons for a failed test include the wrong stitch name was used or the stitch was unable to perform one or more actions.

Network Security Support Engineer 7.2 Study Guide

146

Security Fabric

DO NOT REPRINT © FORTINET

The real-time application debug shown on this slide can be used to troubleshoot automation stitches as they are running.

Network Security Support Engineer 7.2 Study Guide

147

Security Fabric

DO NOT REPRINT © FORTINET

Use the diagnose test application autod 1 command to toggle log dumping. Executing the command once enables the log dump. Executing it again outputs the dump, while simultaneously disabling it.

Network Security Support Engineer 7.2 Study Guide

148

Security Fabric

DO NOT REPRINT © FORTINET

The diagnose test application autod 2 command displays the settings for all automation stitches.

Network Security Support Engineer 7.2 Study Guide

149

Security Fabric

DO NOT REPRINT © FORTINET

The diagnose test application autod 3 command provides detailed statistics on every automation stitch configured in the Security Fabric.

Network Security Support Engineer 7.2 Study Guide

150

Security Fabric

DO NOT REPRINT © FORTINET

The output of the diagnose test application autod 5 command shows the number of stitches currently running. It also shows how many stitches have been successfully or unsuccessfully completed.

Network Security Support Engineer 7.2 Study Guide

151

Security Fabric

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned about the Security Fabric.

Network Security Support Engineer 7.2 Study Guide

152

Firewall Authentication

DO NOT REPRINT © FORTINET

In this lesson, you will learn about firewall authentication and how to troubleshoot issues.

Network Security Support Engineer 7.2 Study Guide

153

Firewall Authentication

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in understanding firewall authentication, you will be able to understand how to monitor the status of authenticated users and troubleshoot the most common problems with local, LDAP, and RADIUS authentication.

Network Security Support Engineer 7.2 Study Guide

154

Firewall Authentication

DO NOT REPRINT © FORTINET

In this section, you will learn about local authentication troubleshooting commands.

Network Security Support Engineer 7.2 Study Guide

155

Firewall Authentication

DO NOT REPRINT © FORTINET

When a problem occurs, the first thing that you should do is define the problem. The first step in troubleshooting authentication problems is to collect specific information so that you can narrow the scope of the problem. Is the problem occurring for more than one user? Is the problem related to user authentication and not to user permissions? The first place you should check is the logs. What do they show? Is the username correct? Is the traffic being blocked after the authentication? What user profile is assigned to the user? In the case of remote server authentication (such as RADIUS or LDAP), you should also check the logs on the server side. In remote server authentication cases, FortiGate authentication depends on the server response. If the RADIUS credentials are invalid, what do the RADIUS server logs show? Is the user account still active on the RADIUS server?

Network Security Support Engineer 7.2 Study Guide

156

Firewall Authentication

DO NOT REPRINT © FORTINET

This slide shows an example of the Firewall User Monitor. A log and event can be generated each time a user authentication action is successful or fails. This FortiView menu is not included on the GUI menu by default, you must enable it.

Network Security Support Engineer 7.2 Study Guide

157

Firewall Authentication

DO NOT REPRINT © FORTINET

You can check the list of active users on the GUI or CLI. On the CLI, the command is diagnose firewall auth list. You can filter the output with the command diagnose firewall auth filter. In the example on this slide, you can see some of the filter options that are available.

Network Security Support Engineer 7.2 Study Guide

158

Firewall Authentication

DO NOT REPRINT © FORTINET

Any session for traffic coming from an authenticated user contains the authed flag. Additionally, the username is added to the session information.

Network Security Support Engineer 7.2 Study Guide

159

Firewall Authentication

DO NOT REPRINT © FORTINET

There is a real-time debug for troubleshooting problems that are related to any user authentication methods: local, remote, and even FSSO. The debug command is diagnose debug application authd.

Network Security Support Engineer 7.2 Study Guide

160

Firewall Authentication

DO NOT REPRINT © FORTINET

In this section, you will learn about troubleshooting commands and common issues with LDAP authentication.

Network Security Support Engineer 7.2 Study Guide

161

Firewall Authentication

DO NOT REPRINT © FORTINET

Now you will have a quick review of the LDAP protocol. The hierarchy of an LDAP schema is not required to resemble the organization. However, the naming conventions and group structure is usually a close match to the company hierarchy. On this slide, you can see the root or DC. In any LDAP schema, this is where an LDAP tree always starts. After that, the groups (or branches) are defined using C, OU, or O. The exact behavior and options used depend on the schema and what exactly is being defined. Branches may contain objects and each object contains attributes. Objects are uniquely identified by their distinguished names (DNs). The full DN specifies where the object is, and the name and value of an attribute that can be used to find it.

Network Security Support Engineer 7.2 Study Guide

162

Firewall Authentication

DO NOT REPRINT © FORTINET

There are three different methods, or bind types, that FortiGate can use to access an LDAP server: simple, anonymous, and regular. In this lesson, you will learn about regular bind, which is the most complex, versatile, and commonly used method. There are four steps to LDAP authentication using regular bind. First, FortiGate logs in to (binds to) the LDAP server using an LDAP administrator account. At this point, FortiGate knows only the username, but it doesn't know the branch where the user is located. During the second step, FortiGate does a search query in the LDAP database to find the user’s location―in other words, the user’s DN. If the user is found, the server replies with the user’s DN. After that, FortiGate logs out of (unbinds from) the LDAP server. The third step is another bind, but this time using the user credentials. FortiGate sends the DN, which it learned in the previous step, and password. The last step is to get the user group information. How this is done depends on the type of LDAP server, but it is generally achieved through an LDAP query. When you are isolating an issue with LDAP, the first step is to determine which of these four steps is failing.

Network Security Support Engineer 7.2 Study Guide

163

Firewall Authentication

DO NOT REPRINT © FORTINET

Most LDAP authentication issues are caused by misconfigurations. So, now you will learn how to check if the regular-bind LDAP configuration is correct. You will analyze a use case in which an LDAP server is based on Windows AD, which is the most common use case. Misconfigurations usually occur in one of these LDAP settings: • Common Name Identifier • Distinguished Name • Username • Password

Network Security Support Engineer 7.2 Study Guide

164

Firewall Authentication

DO NOT REPRINT © FORTINET

How do you check if the DN is configured correctly? You can run either of these two commands in the Windows AD server command prompt: • dsquery user –name • dsquery user –samid The output displays the user DN. The DN configuration specifies a parent branch that all users are located under. FortiGate searches users in any sub-branch below the parent branch. In the example on this slide, the DN settings are: dc=california,dc=fortinet,dc=com.

Network Security Support Engineer 7.2 Study Guide

165

Firewall Authentication

DO NOT REPRINT © FORTINET

The user DN (or bind DN) setting is the full DN of the LDAP admin account. You can use the Windows LDAP server command (dsquery) to find that information.

Network Security Support Engineer 7.2 Study Guide

166

Firewall Authentication

DO NOT REPRINT © FORTINET

You can simply copy and paste the full DN output from the server command prompt to the FortiGate configuration.

Network Security Support Engineer 7.2 Study Guide

167

Firewall Authentication

DO NOT REPRINT © FORTINET

This is a summary of how to properly configure regular bind for Windows AD. A different type of LDAP server might require a different approach. You usually set the Common Name Identifier to CN or sAMAccountName. If you set it to CN, users must authenticate using their full names (for example, John Smith). If you set it to sAMAccountName, users must authenticate using their login names (for example, jsmith). You can find the DN that you must type in the Distinguished Name field by querying the user’s DN with the Windows AD command dsquery. You can find the information that you must type in the Username field by querying the admin DN with the same Windows AD command dsquery. Finally, the password setting is the LDAP administrator password.

Network Security Support Engineer 7.2 Study Guide

168

Firewall Authentication

DO NOT REPRINT © FORTINET

The CLI includes an LDAP authentication test command, which is diagnose test authserver ldap. If both the credentials and LDAP configuration are correct, you receive an authentication confirmation, as well as a list of the user groups for that user. You can run this test command as soon as you complete the LDAP server configuration—even before you add any user groups, or authentication firewall policies are added to FortiGate. The command tests only the LDAP server configuration and LDAP communication between FortiGate and the server.

Network Security Support Engineer 7.2 Study Guide

169

Firewall Authentication

DO NOT REPRINT © FORTINET

There is a real-time debug for LDAP and RADIUS. This slide shows a sample of the output you will see when the configuration is correct. A start_search_dn message indicates that FortiGate is performing step two: searching for the user in the LDAP tree. This message includes the base branch (distinguished name setting) and the name of the attribute used to locate the user (common name identifier setting). If the LDAP server finds the user, the output shows Found DN, followed by the user’s full DN.

Network Security Support Engineer 7.2 Study Guide

170

Firewall Authentication

DO NOT REPRINT © FORTINET

After that, FortiGate performs the third step: binding using the user credentials. Finally, the output shows the fourth step: getting the list of user groups.

Network Security Support Engineer 7.2 Study Guide

171

Firewall Authentication

DO NOT REPRINT © FORTINET

If there is a problem with the first step (admin bind) or the third step (user bind), you can sniff the traffic between the FortiGate and the LDAP server, to get the error code. The error code states explicitly why the binding is failing.

Network Security Support Engineer 7.2 Study Guide

172

Firewall Authentication

DO NOT REPRINT © FORTINET

Now, you will learn about some of the most common bind issues, and how to identify them in the output of the real-time debug. If you see the invalid credentials error right after an authentication attempt, this means a problem occurred in step one. There is probably an issue with the admin account credentials.

Network Security Support Engineer 7.2 Study Guide

173

Firewall Authentication

DO NOT REPRINT © FORTINET

The message No more DN left indicates that a problem occurred in step two. The LDAP server couldn't find the user in the LDAP tree.

Network Security Support Engineer 7.2 Study Guide

174

Firewall Authentication

DO NOT REPRINT © FORTINET

If the output shows that the user was found, but an Auth denied message appears below, this indicates that a problem occurred in step three. Either the user credentials are wrong or the user account is not active.

Network Security Support Engineer 7.2 Study Guide

175

Firewall Authentication

DO NOT REPRINT © FORTINET

The error message get_member_of_groups-attr= - found 0 values indicates that a problem occurred in step four. The user credentials are correct, but no user group information was found. In some LDAP implementations, the user group information is not used. All LDAP users have the same privileges, regardless of their AD group memberships. In those implementations, this error message can be ignored.

Network Security Support Engineer 7.2 Study Guide

176

Firewall Authentication

DO NOT REPRINT © FORTINET

What do you do if the problem occurs in step one (admin bind is not working)? • Use the dsquery query command to check the admin DN. • Check the admin password. • Sniff the error code coming from the server. What do you do if the problem occurs in step two (LDAP server could not find the user)? • If the common name identifier is set to sAMAccountName, the user must use their login name. If it is set to cn, the user must use their full name. • Check the distinguished name setting with the dsquery command.

Network Security Support Engineer 7.2 Study Guide

177

Firewall Authentication

DO NOT REPRINT © FORTINET

In this section, you will learn about RADIUS authentication troubleshooting commands.

Network Security Support Engineer 7.2 Study Guide

178

Firewall Authentication

DO NOT REPRINT © FORTINET

Normal authentication queries with the RADIUS protocol begin with an Access-Request being sent from the FortiGate to the RADIUS server. A valid response to this query is Access-Accept or Access-Reject (yes or no, effectively). If two-factor authentication is enabled on the server, the response is an Access-Challenge message, which means that the server is essentially looking for more information.

Network Security Support Engineer 7.2 Study Guide

179

Firewall Authentication

DO NOT REPRINT © FORTINET

Just like there is for LDAP, there is a CLI test command for RADIUS. To respond, you must provide not only the credentials for a test user, but also the authentication scheme. FortiGate supports the following RADIUS schemes: CHAP, PAP, MS-CHAP, and MS-CHAPv2. Also, just like it does for LDAP, this command tests only the FortiGate RADIUS server configuration. It does not require any user group or firewall policy in the FortiGate configuration.

Network Security Support Engineer 7.2 Study Guide

180

Firewall Authentication

DO NOT REPRINT © FORTINET

RADIUS is either a one-step or two-step process (depending on the use of two-factor authentication). It is not as long as the four-step process that happens with LDAP regular bind. So, the output of the real-time debug is usually shorter.

Network Security Support Engineer 7.2 Study Guide

181

Firewall Authentication

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned about firewall authentication and how to troubleshoot issues.

Network Security Support Engineer 7.2 Study Guide

182

FSSO

DO NOT REPRINT © FORTINET

In this lesson, you will review FSSO operation and learn about tools and tips for troubleshooting FSSO problems.

Network Security Support Engineer 7.2 Study Guide

183

FSSO

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating a competent understanding of FSSO and its components, you will be able to understand how to track user login events, list authenticated FSSO users, and troubleshoot common FSSO authentication issues.

Network Security Support Engineer 7.2 Study Guide

184

FSSO

DO NOT REPRINT © FORTINET

In this section, you will learn about FSSO modes, its components, and how they interact.

Network Security Support Engineer 7.2 Study Guide

185

FSSO

DO NOT REPRINT © FORTINET

FSSO enables FortiGate to leverage your network’s existing authentication system for firewall authentication. Once a user logs in, they can access other network resources without having to authenticate again. The two most common FSSO methods are DC agent and polling. DC agent mode requires one collector agent. It also requires DC agents installed in all Windows domain controllers. The DC agents detect the login events and "push" this information to the collector agent. The collector agent forwards the login events to FortiGate, together with the workstation IP address and user's group information. The polling mode does not require a DC agent to be installed. In polling mode, the collector agent frequently polls each DC to get the latest login events. There are three types of polling mode: • • •

NetAPI: Polls NetSessionEnum API. WinSecLog: Polls all security event logs. WMI: Polls specific security event logs.

Poll intervals are estimated times that depend on the number of servers and network latency. If a standalone collector agent is used, the three types of polling modes are supported. Alternatively, polling can be performed directly from FortiGate (agentless polling mode), so a standalone collector agent is not required. However, FortiGate acting as a collector agent supports only the WinSecLog polling type.

Network Security Support Engineer 7.2 Study Guide

186

FSSO

DO NOT REPRINT © FORTINET

We can break FSSO Components into four phases: •

Phase 1: This phase starts when a user authenticates on a workstation and triggers a user login event. This phase detects the login event and records the workstation name, domain, and user.

•

Phase 2: In this phase, FSSO receives login information from sources such as: DC agents, NTLM, API polling mode, Win Sec, or TS/CITRIX. After collecting the login information, FortiGate gathers the user group membership performing an active directory query, which can be in standard or advanced mode, or, in the case of eDirectory, using native API or LDAP. This phase resolves the workstation name to an IP address and determines which user groups the user belongs to.

•

Phase 3: This phase handles the process of sending and receiving the user logon information, including the IP address and groups list, to FortiGate.

•

Phase 4: FortiGate receives the authentication details and creates one or more log entries for this login event, as appropriate.

Network Security Support Engineer 7.2 Study Guide

187

FSSO

DO NOT REPRINT © FORTINET

This slide shows how FSSO traffic flows and which ports are used. When polling mode is used, the polling is performed by either the FortiGate or the collector agent, and in both cases, port TCP 445 is used. The communication between the collector agent and FortiGate, by default, uses port TCP 8000. The communication between the DCs and the collector agent uses, also by default, port UDP 8002. FSSO commonly works by identifying each user based on the source IP address of the traffic. Each active FSSO user is associated with one or more IP addresses and one IP address is associated only with one user. This creates conflicts in network using terminal or Citrix servers, where more than one user shares the same IP address. For those cases, you can install a terminal server (TS) agent. The TS agent provides the collector agent and FortiGate with not only the source IP address of each user, but also with the source TCP/UDP ports they are using. So, multiple users sharing the same IP address can be identified by combining the source IP address with the source port. The communication between the TS agent and the collector agent also uses port UDP 8002.

Network Security Support Engineer 7.2 Study Guide

188

FSSO

DO NOT REPRINT © FORTINET

Each time the collector agent receives a login event, it checks if the user is in the ignore list. If it is, the login event is discarded. After that, the collector agent checks if the user's group information is still in the cache. If it is not, the collector agent performs either an LDAP or an API query to get the group information from Windows AD. Once the collector agent knows the user groups, it checks if any of them are included in the list of monitored groups. If none of the groups are included, the login event is not forwarded to FortiGate. If at least one group is included, the login event is forwarded to FortiGate.

Network Security Support Engineer 7.2 Study Guide

189

FSSO

DO NOT REPRINT © FORTINET

An external collector agent periodically checks if each active FSSO user is still logged in. It does this by polling all known active workstations, based on a configurable interval. How this checking is done depends on the FSSO mode. For WMI polling mode, the collector agent checks the WMI service. For all the other modes, the collector agent checks the HKEY_USERS hive through remote registry services. If a workstation does not respond to these checks, the collector agent starts a timer (dead entry timeout interval). After the expiration of that timer, the workstation goes to not verified status and the collector agent assumes that the user has logged out.

Network Security Support Engineer 7.2 Study Guide

190

FSSO

DO NOT REPRINT © FORTINET

You can also configure the external collector agent to periodically check if the IP address of an active FSSO user has changed. This might happen, for example, when a user switches from a wired to a wireless network. When this collector agent feature is enabled, the collector agent periodically uses the DNS server to resolve the workstation name. If the DNS server replies with a new IP address, the collector agent sends first a logout event to FortiGate, followed by a login event with the new IP address. Therefore, it is important for the DNS server to be immediately and automatically updated each time a user changes their IP address.

Network Security Support Engineer 7.2 Study Guide

191

FSSO

DO NOT REPRINT © FORTINET

There are three important requirements for any FSSO network, and most of the FSSO problems happen when any of these requirements are not fulfilled. The collector agent frequently polls each active workstation. For this polling to work properly, TCP ports 139 and 445 must be open between the collector agent and the workstations. Firewalls must allow this traffic. Additionally, the remote registry service must be up and running on the workstations. DNS is used to get the user’s IP address. So, administrators must ensure that each workstation name is registered in the DNS server with the correct and up-to-date IP address.

Network Security Support Engineer 7.2 Study Guide

192

FSSO

DO NOT REPRINT © FORTINET

In this section, you will learn about diagnosing FSSO issues and troubleshooting commands.

Network Security Support Engineer 7.2 Study Guide

193

FSSO

DO NOT REPRINT © FORTINET

What steps should an administrator take when troubleshooting an FSSO problem? This slide offers a general checklist. In this lesson, you will learn how to perform the recommended troubleshooting steps.

Network Security Support Engineer 7.2 Study Guide

194

FSSO

DO NOT REPRINT © FORTINET

Before you start the troubleshooting, it is recommended that you gather configuration and topology information. Analyze what FSSO version is in place, how many DCs are in the network, the FortiGate configuration file, and so on. If an issue occurs, the diagnose debug auth fsso list can show the user information that the collector agent is sending to FortiGate.

Network Security Support Engineer 7.2 Study Guide

195

FSSO

DO NOT REPRINT © FORTINET

As part of the initial troubleshooting steps, make some changes to the collector agent logging settings to ensure that all the required debug information is captured. First, in the Log level field, select Information. Second, increase the setting in the Log file limit (MB) field. If the log file limit is too low, especially in big FSSO networks, you might not have time to see the relevant debug information, because it will be overridden quickly by new log events. Third, you can optionally record the login events in a different file by selecting Log logon event in separate logs.

Network Security Support Engineer 7.2 Study Guide

196

FSSO

DO NOT REPRINT © FORTINET

If the FSSO issue can be reproduced, there are different tools to track the login event as it travels from the DC, to the collector agent, and then to FortiGate. Follow these steps: 1. Perform the login. 2. Check which DC received the login using the Windows command: echo %logonserver% 3. Go to that DC and use the Windows event viewer to find the generated login event. 4. Check the collector agent logs and the list of active FSSO users. 5. Check that at least one user's group is listed as monitored in the group filter. 6. Go to FortiGate and check that the login event was received. 7. List the active FSSO users. 8. Generate traffic from the user workstation and verify that it is added to the FortiGate user monitor.

Network Security Support Engineer 7.2 Study Guide

197

FSSO

DO NOT REPRINT © FORTINET

By clicking Show Service Status in the collector agent, you can check the connectivity between FortiGate and the collector agent. The window displays the serial numbers of all the active FortiGate devices.

Network Security Support Engineer 7.2 Study Guide

198

FSSO

DO NOT REPRINT © FORTINET

When a FortiGate successfully connects to a collector agent, the collector agent logs show these messages. Additionally you can confirm a successful connection while running the FSSO real-time debug on FortiGate.

Network Security Support Engineer 7.2 Study Guide

199

FSSO

DO NOT REPRINT © FORTINET

While the TCP session between FortiGate and the collector agent is up, the collector agent sends heartbeat messages to FortiGate. Both the collector agent logs and the FortiGate real-time debug show this heartbeat interchange.

Network Security Support Engineer 7.2 Study Guide

200

FSSO

DO NOT REPRINT © FORTINET

The error server authentication failed, aborting in the FortiGate real-time debug might indicate a mismatch in the password shared between the collector agent and FortiGate. The error connection refused might indicate that the TCP communication between FortiGate and the collector agent is blocked by a firewall or another device. The error no route to host might indicate that the IP address of the collector agent is not routable from FortiGate.

Network Security Support Engineer 7.2 Study Guide

201

FSSO

DO NOT REPRINT © FORTINET

If you click Show Monitored DCs on the collector agent, you can check the communication between the collector agent and each DC. The table includes the time when the last login event was received from each DC.

Network Security Support Engineer 7.2 Study Guide

202

FSSO

DO NOT REPRINT © FORTINET

The Event Viewer is a Windows tool that displays all the server logs. You can use it to search for login event logs.

Network Security Support Engineer 7.2 Study Guide

203

FSSO

DO NOT REPRINT © FORTINET

The FortiGate FSSO real-time debug generates messages each time a login event arrives. They include the name and IP address of the user, together with the workstation name and user's group information.

Network Security Support Engineer 7.2 Study Guide

204

FSSO

DO NOT REPRINT © FORTINET

You can check the list of logon users by clicking Show Logon Users. The status OK indicates that the user is active. A user goes to not verified status when they log out, or when there is a problem in the polling done by the collector agent to the workstation.

Network Security Support Engineer 7.2 Study Guide

205

FSSO

DO NOT REPRINT © FORTINET

To get the list of active users from FortiGate, use the command diagnose debug authd fsso list. You can set up a filter first with the command diagnose debug authd fsso filter.

Network Security Support Engineer 7.2 Study Guide

206

FSSO

DO NOT REPRINT © FORTINET

The CLI command diagnose debug authd fsso refresh-logons refreshes the active FSSO user list in the FortiGate by getting this information again from the collector agent. The CLI command diagnose debug authd fsso clear-logons flushes the list of active FSSO users in the FortiGate. The CLI command diagnose debug authd fsso refresh-groups refreshes the user group information in the FortiGate by getting this information again from the collector agent. To list the monitored user groups, use the command get user adgrp.

Network Security Support Engineer 7.2 Study Guide

207

FSSO

DO NOT REPRINT © FORTINET

The commands on this slide are executed on a Windows command prompt. They can be useful while diagnosing FSSO issues and analyzing data on the server side. On a Windows server, the command, dsquery user -name is useful to query the DN. You can run this command from the LDAP server’s command prompt. When you use the command wmic, it should return the username of the user currently logged in to the remote workstation. You can use the command netstat to verify that port 8000 is open.

Network Security Support Engineer 7.2 Study Guide

208

FSSO

DO NOT REPRINT © FORTINET

In this section, you will learn about the FSSO agentless method and specific troubleshooting commands for this mode.

Network Security Support Engineer 7.2 Study Guide

209

FSSO

DO NOT REPRINT © FORTINET

The command diagnose debug fsso-polling detail displays the status and some statistics related to the polls done by the FortiGate on each DC. The command diagnose debug fsso-polling refresh-user flushes the information about all active FSSO users. In agentless polling mode, the FortiGate frequently polls all workstations (as a standalone collector agent does) to check which users are still logged on. You can sniffer this traffic on port 445.

Network Security Support Engineer 7.2 Study Guide

210

FSSO

DO NOT REPRINT © FORTINET

There is a specific FortiGate daemon that handles the polling mode. It is the fssod daemon. To enable agentless polling mode real-time debug use: diagnose debug application fssod -1. The slide shows the most common real-time debug errors and the possible causes.

Network Security Support Engineer 7.2 Study Guide

211

FSSO

DO NOT REPRINT © FORTINET

In this section, you will learn about the most common FSSO issues.

Network Security Support Engineer 7.2 Study Guide

212

FSSO

DO NOT REPRINT © FORTINET

What should you do if the collector agent does not have login information? • Verify that the collector agent is monitoring all DCs. • Check that the collector agent is receiving login events from the DCs. • Test the user account and check the collector agent logs. What should you do if the collector agent has the login information, but FortiGate does not? • Check that FortiGate is connected to the collector agent. • Run the real time debugs while testing the user account.

Network Security Support Engineer 7.2 Study Guide

213

FSSO

DO NOT REPRINT © FORTINET

If an FSSO user is listed as active in FortiGate but it cannot browse the internet, you should first confirm that the correct IP address is listed in FortiGate. Also check the user's group information, firewall policies, and collector agent logs. If FortiGate is randomly blocking some users, you should check that the collector agent service, or any FortiGate process, is not crashing. Confirm that the connection between FortiGate and collector agent is up and stable. Try to reproduce the problem and then check the collector agent logs.

Network Security Support Engineer 7.2 Study Guide

214

FSSO

DO NOT REPRINT © FORTINET

DNS resolution is essential for FSSO operation. If a collector agent cannot resolve a workstation name, the user will not be listed as active and the collector agent logs show the errors shown on this slide.

Network Security Support Engineer 7.2 Study Guide

215

FSSO

DO NOT REPRINT © FORTINET

Another common problem with FSSO authentication happens when applications generate login events with an AD account that is different from the users’ accounts. In these cases, the login event overrides the user information for a workstation IP address (a different user is listed as active for the IP address). The collector agent is coded to ignore any login events for anonymous accounts, and accounts with a name starting with '$' (which are system accounts). If any application is using an account that is overriding the user information, the solution is to add that account to the ignore user list.

Network Security Support Engineer 7.2 Study Guide

216

FSSO

DO NOT REPRINT © FORTINET

Active users with the status not verified are also a common problem. That status is normal after a user has logged out. However, it is not normal for a user that is still logged in. This means that polling from the collector agent to the workstation is failing. In these cases, check the collector agent logs. They provide more information about the cause of the problem.

Network Security Support Engineer 7.2 Study Guide

217

FSSO

DO NOT REPRINT © FORTINET

What should you do if a user loses internet access after their IP address changes? This might happen when the user moves back and for from a wired to a wireless network. It might also happen when a workstation comes out of hibernate mode and gets a new IP address from the DHCP server. The first step is to check the DNS resolution. When a user changes their IP address, the DNS server must be automatically updated with the new IP address information. If that is not possible, one workaround is to configure FSSO guest access. So, users whose IP addresses have changed can still have some (probably limited) access to some network resources. For the cases where a workstation was assigned more than one IP address (for example, one address for the wired network and another one for the wireless), the DNS server should be able to return all those IP addresses when resolving the workstation name. The user is then listed multiple times in the FSSO active user list, one time for each IP address.

Network Security Support Engineer 7.2 Study Guide

218

FSSO

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned about FSSO modes, the most common FSSO issues, and how to troubleshoot them.

Network Security Support Engineer 7.2 Study Guide

219

Security Profiles

DO NOT REPRINT © FORTINET

In this lesson, you will learn how to troubleshoot some of the security profile features.

Network Security Support Engineer 7.2 Study Guide

220

Security Profiles

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in understanding security profiles, you will be able to understand how to troubleshoot FortiGuard and web filtering issues. You will also learn how to fix certificate warning problems, and monitor IPS and antivirus events.

Network Security Support Engineer 7.2 Study Guide

221

Security Profiles

DO NOT REPRINT © FORTINET

In this section, you will learn about how FortiGuard and FortiGate communicate. You will also learn troubleshooting commands.

Network Security Support Engineer 7.2 Study Guide

222

Security Profiles

DO NOT REPRINT © FORTINET

You can check the status of FortiGuard licenses and the communication to FortiGuard on the FortiGate GUI. You can also check the versions of the locally installed databases for each of the FortiGuard services.

Network Security Support Engineer 7.2 Study Guide

223

Security Profiles

DO NOT REPRINT © FORTINET

To learn how to troubleshoot FortiGuard problems, you need to understand how FortiGuard communication works. The communication between FortiGate and FortiGuard for web filtering and antispam is different from the communication for antivirus and IPS. First, you will look at how FortiGuard web filtering and antispam work: 1. FortiGate contacts the DNS server to resolve the FortiGuard service name. 2. FortiGate gets a list of IP addresses for servers that it can contact to validate the FortiGuard license. 3. FortiGate contacts one of those servers to check the license and request a list of servers that it can submit web filtering and antispam rating queries to. 4. FortiGate gets the list of servers. 5. FortiGate starts sending rating queries to one of the servers in the list. 6. If the server it contacted does not reply in 2 seconds, FortiGate contacts the next server on the list. The FortiGuard service name depends on the FortiGate configuration: • • • •

service.fortiguard.net: FortiGate is configured to use UDP and communicate with servers located worldwide. securewf.fortiguard.net: FortiGate is configured to use HTTPS and communicate with servers located worldwide. usservice.fortiguard.net: FortiGate is configured to use UDP and communicate with servers located only in the USA. ussecurewf.fortiguard.net: FortiGate is configured to use HTTPS and communicate with servers located only in the USA.

Network Security Support Engineer 7.2 Study Guide

224

Security Profiles

DO NOT REPRINT © FORTINET

Now, you will look at how antivirus and IPS work. How FortiGuard communication works for antivirus and IPS depends on the method used: pull or persistent connection. Note that the persistent connection method is available only on FortiGate models that are 2U and above, and is displayed on the FortiGate GUI as Immediately download updates. The steps in the pull method are: 1. FortiGate contacts the DNS server to resolve the name update.fortiguard.net. 2. FortiGate gets a list of server IP addresses that it can contact. 3. FortiGate periodically connects to one of the servers to check for pending updates. 4. If there is an update, FortiGate downloads the update. The first two steps used in the pull method are also used in the persistent connection method: FortiGate gets a list of IP addresses from a DNS server for the domain name update.fortiguard.net. After that, FortiGate forms an HTTPS connection with FortiGuard. Once this connection is established, FortiGuard uses this connection to send notifications each time there are new updates. FortiGate then proceeds to form a separate secure connection to FortiGuard to download the update.

Network Security Support Engineer 7.2 Study Guide

225

Security Profiles

DO NOT REPRINT © FORTINET

The command shown on this slide displays the list of servers for web filtering and antispam queries. For each IP address, the table shows: • The round trip delay • The server time zone • The number of recent and consecutive queries without reply • The historical total number of queries without reply—these values reset when the device restarts.

Network Security Support Engineer 7.2 Study Guide

226

Security Profiles

DO NOT REPRINT © FORTINET

FortiGate uses the following method to select the server to send the rating requests to: • FortiGate initially uses the delta between the server time zone and the FortiGate system time zone, multiplied by 10. • This is the initial weight of the server. To lower the possibility of using a remote server, the weight is not allowed to drop below the initial weight. • The weight increases with each packet lost. • The weight decreases over time if there are no packets lost. • FortiGate uses the server with the lowest weight as the one for the rating queries. If two or more servers have the same weight, FortiGate uses the server with the lowest round-trip time (RTT).

Network Security Support Engineer 7.2 Study Guide

227

Security Profiles

DO NOT REPRINT © FORTINET

In many cases, problems related to FortiGuard are caused by ISPs. Some ISPs block traffic that is not DNS or that contains large packets on port 53. In those cases, the solution is to switch FortiGuard traffic from port 53 to port 8888. Other ISPs (or upstream firewalls) block traffic to port 8888. In those cases, the solution is to use port 53. When anycast is enabled, which is by default, the protocol is HTTPS and the port is 443. There are also a few cases where ISPs block traffic based on source ports. Changing the source port range for FortiGuard to the range shown on this slide usually fixes the issue.

Network Security Support Engineer 7.2 Study Guide

228

Security Profiles

DO NOT REPRINT © FORTINET

The output of the command diagnose debug rating shows flags beside some of the servers: • I = The server initially contacted to validate the license and get the server list. • Usually, there is only one server with this flag. • D = The IP address FortiGate got when resolving the name service.fortiguard.net. If the administrator has not overwritten the FortiGuard FQDN or IP address in the FortiGate configuration, there are usually two or three servers with this flag. • S = The IP address FortiGate got from FortiManager. • T = The server is not replying to FortiGate queries. • F = The server is down.

Network Security Support Engineer 7.2 Study Guide

229

Security Profiles

DO NOT REPRINT © FORTINET

For antivirus and IPS, communication between FortiGate and FortiGuard happens much less frequently. In the case of web filtering and antispam, FortiGate goes to FortiGuard each time it needs to rate a website or email (if the information is not in the FortiGate cache). In the case of the pull method for antivirus and IPS, by default, FortiGate contacts FortiGuard at an interval calculated based on the FortiGate model and the percentage of valid subscriptions. The update interval is within one hour to check and download any new version of the antivirus or IPS databases and engines. This is done using port TCP 443. This slide shows the commands you use if FortiGate must connect through a web proxy. Usually, clients connecting through a web proxy do not contact the DNS server to resolve names, because it is the web proxy that does it. When connecting through a web proxy, FortiGate can access FortiGuard without DNS resolution.

Network Security Support Engineer 7.2 Study Guide

230

Security Profiles

DO NOT REPRINT © FORTINET

Both the antivirus and IPS databases can be updated either automatically or manually. Automatic updates download the portions of the databases that have changed since the last update. Manual updates download the whole database if there is new version available. In a few cases, FortiGuard problems are fixed by doing a manual update. This forces FortiGate to download and install the whole database. For example, if the antivirus database is corrupted, a manual update might fix the problem.

Network Security Support Engineer 7.2 Study Guide

231

Security Profiles

DO NOT REPRINT © FORTINET

The command diagnose test application dnsproxy 7 displays the FQDN and IP addresses of the FortiGuard servers available for antivirus and IPS updates. The command diagnose autoupdate status provides a summary of the FortiGuard configuration on FortiGate.

Network Security Support Engineer 7.2 Study Guide

232

Security Profiles

DO NOT REPRINT © FORTINET

The command shown on this slide lists all the FortiGuard databases and engines installed. The information includes the version, contract expiration date, time it was updated, and what happened during the last update.

Network Security Support Engineer 7.2 Study Guide

233

Security Profiles

DO NOT REPRINT © FORTINET

If there are problems updating the AV or IPS databases, or if there are problems validating the license, you can use the FortiGuard real-time debug: diagnose debug application update -1 diagnose debug enable After you enable the debug, you can force a manual update on the CLI with the command execute update-now.

Network Security Support Engineer 7.2 Study Guide

234

Security Profiles

DO NOT REPRINT © FORTINET

Remember that FortiGuard traffic always originates from the management VDOM. So, the management VDOM (which is root by default) must have internet access. Correct DNS access from the management VDOM is also important. FortiGate must be able to resolve the names: • update.fortiguard.net • service.fortiguard.net Also, keep in mind that, although it usually takes 1 or 2 hours to update a contract on all the servers, in some cases, it can take up to 24 hours. So, if you have just changed or renewed your FortiGuard contract, and you do not see the change on FortiGate, you may need to wait a bit longer to give FortiGuard time to synchronize the information on all servers.

Network Security Support Engineer 7.2 Study Guide

235

Security Profiles

DO NOT REPRINT © FORTINET

In this section, you will learn how FortiGate processes a packet.

Network Security Support Engineer 7.2 Study Guide

236

Security Profiles

DO NOT REPRINT © FORTINET

On the following slides, we are going to analyze how a FortiGate processes a packet from when it arrives on the FortiGate to when it leaves the FortiGate. You will see the actions that the FortiGate takes and the order of those actions. We have split the process into four stages. The first stage happens when the packet arrives on the FortiGate. First, you can set a limit on the incoming bandwidth (inbandwidth parameter). If the traffic exceeds that limit, the packet is dropped. After that, FortiGate checks the thresholds in the DoS policies. The next steps are the reverse path forwarding and IP header integrity checks. If the traffic terminates at the FortiGate (for example, management, web proxy, and DNS traffic), the specific daemon that handles the requested feature processes the packet. If the traffic does not terminate at the FortiGate, it moves to the second stage, which is the routing and firewall policy.

Network Security Support Engineer 7.2 Study Guide

237

Security Profiles

DO NOT REPRINT © FORTINET

Before doing the routing lookup, the FortiGate (if required) applies the destination NAT. If there is no route to the destination, the packet is dropped. In a similar way, if a firewall policy denies the packet, it will not be allowed. If the packet is allowed, FortiGate checks if the policy requires authentication. After those steps, FortiGate proceeds to identify the traffic, which is then inspected by any session helper that might be required.

Network Security Support Engineer 7.2 Study Guide

238

Security Profiles

DO NOT REPRINT © FORTINET

The third stage is UTM inspection. If the traffic is encrypted and full SSL inspection is used, the FortiGate proceeds to decrypt the traffic. After that, the inspection profiles are applied in this order: IPS, application control, VoIP, DLP, antispam, web filtering, and antivirus.

Network Security Support Engineer 7.2 Study Guide

239

Security Profiles

DO NOT REPRINT © FORTINET

After inspection, FortiGate applies traffic shaping and source NAT. Finally, if the packet must be routed through an IPsec VPN, it is encrypted before leaving the FortiGate.

Network Security Support Engineer 7.2 Study Guide

240

Security Profiles

DO NOT REPRINT © FORTINET

In this section, you will learn web filtering troubleshooting commands.

Network Security Support Engineer 7.2 Study Guide

241

Security Profiles

DO NOT REPRINT © FORTINET

Similar to other UTM features, one of the best troubleshooting tools for web filtering is the FortiGate logs. FortiGate can generate a log each time a website is blocked. The log lists the URL, category, action taken, and so on.

Network Security Support Engineer 7.2 Study Guide

242

Security Profiles

DO NOT REPRINT © FORTINET

You can see a list of error counters that are related to web filtering by entering the command diagnose webfilter fortiguard statistics list.

Network Security Support Engineer 7.2 Study Guide

243

Security Profiles

DO NOT REPRINT © FORTINET

The output also shows counters for the number of sites allowed and blocked, and statistics about the cache (including hit and miss rates).

Network Security Support Engineer 7.2 Study Guide

244

Security Profiles

DO NOT REPRINT © FORTINET

Another tool you can use to troubleshoot web filtering is the web filter real-time debug. You can use the commands shown on this slide. This slide shows an example of real-time debug output when the URL to categorize isn't in the FortiGuard cache. The output shows the URL, category, source, destination IP addresses, and service.

Network Security Support Engineer 7.2 Study Guide

245

Security Profiles

DO NOT REPRINT © FORTINET

To list the content of the FortiGuard web filtering cache, use the command diagnose webfilter fortiguard cache dump. For each URL, the output lists its rating by domain name and IP address. The rating by domain name is the first two digits of the first number from left to right—it is the category ID represented in hexadecimal. The rating by IP address is the first two digits of the second number—it is also the category ID represented in hexadecimal. The command get webfilter categories lists all the categories with their respective ID numbers. In this list, the IDs are represented in decimal. So, if you want to find the category name for a URL in the cache, use the first command to list the cache, and then convert the ID number from hexadecimal to decimal. Then, use the second command to find the category name for that ID number.

Network Security Support Engineer 7.2 Study Guide

246

Security Profiles

DO NOT REPRINT © FORTINET

Now, you will learn some tips for troubleshooting web filtering. • Get the specifics first: • What URLs are having the problem? • Is it random? • Does it happen with all the users? • Check the logs. • Is the problem caused by an incorrect user group configuration? Are the user access privileges correct? • Run the real-time debug while reproducing the issue.

Network Security Support Engineer 7.2 Study Guide

247

Security Profiles

DO NOT REPRINT © FORTINET

Additional tips: • Check that web filtering isn't disabled globally. • If users are having intermittent issues: • Check that the communication with FortiGuard is stable (check the web filtering statistics) • Check also that the device is not entering conserve mode.

Network Security Support Engineer 7.2 Study Guide

248

Security Profiles

DO NOT REPRINT © FORTINET

In this section, you will learn about SSL inspection modes and how to handle certificate warnings.

Network Security Support Engineer 7.2 Study Guide

249

Security Profiles

DO NOT REPRINT © FORTINET

There are two SSL inspection modes: SSL certificate inspection and full SSL inspection. When using SSL certificate inspection, FortiGate is not decrypting the traffic. It is only inspecting the server digital certificates and the name indication (SNI) field, which are interchanged before the encryption. First, FortiGate tries to get the URL from the SNI field. The SNI field is a TLS extension that contains the complete URL that the user is connecting to. It is supported by most modern browsers. If the SNI field is not present (because the web client may not support it), FortiGate proceeds to inspect the server digital certificate.

Network Security Support Engineer 7.2 Study Guide

250

Security Profiles

DO NOT REPRINT © FORTINET

With full SSL inspection, FortiGate does decrypt (and re-encrypt) the SSL traffic. Under normal circumstances (without full SSL inspection), encrypted traffic cannot be inspected, because the firewall does not have the key required to decrypt the data. In order to work, the FortiGate must be located in the middle of the communication between the user’s browser and the website. When the browser connects to the website, the web server sends its certificate, which contains its public key. The FortiGate intercepts the web server certificate and generates a new one. The new certificate is issued by the certificate authority (CA) installed on the FortiGate, which is not a well-known public CA. The FortiGate also generates a new pair of public and private keys.

Network Security Support Engineer 7.2 Study Guide

251

Security Profiles

DO NOT REPRINT © FORTINET

When you enable SSL inspection, browsers start displaying a certificate warning each time a user is connecting to an HTTPS site. The reason is that the certificates that the browsers receive are now being signed by the FortiGate, which is a CA that the browsers do not trust. There are two ways to fix this warning. The first option is to download the default FortiGate certificate for SSL proxy inspection and install it in all the browsers. The second option is to generate a new SSL proxy certificate from a private CA. In this case, the private CA certificate must still be installed in all the browsers. This is not a limitation on FortiGate, but a consequence of how digital certificates are designed to work.

Network Security Support Engineer 7.2 Study Guide

252

Security Profiles

DO NOT REPRINT © FORTINET

Replacing the certificate for the traffic can cause problems. Some software and servers have specific limitations on the certificates that are allowed to be used. HSTS and PKP are security features designed to detect man-in-the-middle SSL attacks by making sure that any certificate presented when accessing a server resource is signed by a specific CA. If the browser detects any other CA, it simply refuses to continue the SSL handshake and prevents access to the website. The solutions available for these issues are limited. One option is to bypass SSL inspection for that traffic. Another option is to use SSL certificate inspection instead.

Network Security Support Engineer 7.2 Study Guide

253

Security Profiles

DO NOT REPRINT © FORTINET

In this section, you will learn how to verify the antivirus status and detections.

Network Security Support Engineer 7.2 Study Guide

254

Security Profiles

DO NOT REPRINT © FORTINET

This is the order of how antivirus inspection is executed. First, the device does the virus scan, then the grayware scan, and finally the machine learning detection. Up to FortiOS 6.4, a heuristic scan could be enabled to perform antivirus inspection after the grayware scan. On FortiOS 7.0 and later, the previous heuristic settings are not kept. On FortiOS 7.0 and later, there is a machine-learning-detection setting, which is an AI-based malware detection feature.

Network Security Support Engineer 7.2 Study Guide

255

Security Profiles

DO NOT REPRINT © FORTINET

One of the best tools for troubleshooting antivirus issues is the FortiGate logs. This is a sample of a log generated when FortiGate detects a virus. You can see the name of the file, time, and name of the virus.

Network Security Support Engineer 7.2 Study Guide

256

Security Profiles

DO NOT REPRINT © FORTINET

What should an administrator do if a virus is detected in a workstation behind a FortiGate performing antivirus. Again, the first step is to get specific information. What antivirus software detected the virus? What is the name of the virus? How did it get inside the network? It might have gotten inside, for example, through a CD or USB stick, so the infected file never went through the FortiGate.

Network Security Support Engineer 7.2 Study Guide

257

Security Profiles

DO NOT REPRINT © FORTINET

Test if FortiGate antivirus is correctly inspecting the user traffic. Go to eicar.org from a user workstation and try to download the EICAR sample file. If you have a sample of the virus, submit it to FortiGuard and check if it is present in any of the FortiGate virus databases. If it is, check the name of the antivirus database where it is present. Does your FortiGate have that database installed?

Network Security Support Engineer 7.2 Study Guide

258

Security Profiles

DO NOT REPRINT © FORTINET

There are three FortiGate AV databases: normal, extended, and extreme. Not all FortiGate models support the three databases, and all three databases may not be installed on your FortiGate.

Network Security Support Engineer 7.2 Study Guide

259

Security Profiles

DO NOT REPRINT © FORTINET

Remember the restrictions for antivirus inspection: • SSL traffic requires SSL deep inspection. • Archive files, such as ZIP files, are examined to certain limits, such as the maximum number of subdirectories and nested archives—there is also the CPU impact of this. • Password protected archives cannot be scanned.

Network Security Support Engineer 7.2 Study Guide

260

Security Profiles

DO NOT REPRINT © FORTINET

In this section, you will learn about IPS troubleshooting.

Network Security Support Engineer 7.2 Study Guide

261

Security Profiles

DO NOT REPRINT © FORTINET

There are two important types of daemons that handle IPS-related tasks: • ipsengine is the main type of daemon that handles all inspection and detection tasks. • ipshelper handles actions whose results can be shared by different ipsengine daemons. ipshelper also monitors configuration changes that impact IPS so it can also start or spawn additional instances of ipsengine. For this reason, it’s normal to see ipshelper running even if you don’t have IPS configured on FortiGate. On some FortiGate models, it is normal to see multiple instances of the ipsengine daemon running.

Network Security Support Engineer 7.2 Study Guide

262

Security Profiles

DO NOT REPRINT © FORTINET

IPS goes into fail open mode when there is not enough available memory in the IPS socket buffer for new packets. The IPS also goes into fail open mode when the FortiGate is in conserve mode. What happens during that state depends on the IPS configuration. If the fail-open setting is enabled, some new packets (depending on the system load) might pass through without being inspected. If it is disabled, new packets might be dropped. Note that NTurbo doesn’t support the fail-open setting. If fail open is triggered, new sessions that would typically be accelerated with NTurbo are dropped, even if the fail-open setting is enabled.

Network Security Support Engineer 7.2 Study Guide

263

Security Profiles

DO NOT REPRINT © FORTINET

The IPS fail open event generates a log in the crash log. The log indicates if new packets are dropped or passed through.

Network Security Support Engineer 7.2 Study Guide

264

Security Profiles

DO NOT REPRINT © FORTINET

IPS fail open entry and exit events also generate event logs.

Network Security Support Engineer 7.2 Study Guide

265

Security Profiles

DO NOT REPRINT © FORTINET

Frequent IPS fail open events usually indicate that the IPS is not able to keep up with the traffic demands. So, try to identify patterns. Has the traffic volume increased recently? Have throughput demands increased? Tune and optimize your IPS configuration: create IPS profiles specific to the type of traffic being inspected, and disable IPS profiles on policies that don’t need them.

Network Security Support Engineer 7.2 Study Guide

266

Security Profiles

DO NOT REPRINT © FORTINET

The Protocol Options setting, which is configurable within each firewall policy, can impact the performance of a FortiGate due to the need for the IPS engine to identify the protocol where particular protocol-to-port mappings are not explicitly set. When a policy is set to proxy-based inspection, the settings in Protocol Options instruct FortiGate to direct specified destination ports to their respective proxy processes, except when Any is set for an enabled protocol. In this scenario, the traffic must be sent to the IPS engine and processed by the CPU, in order to identify the protocol before directing it to the proxy process. This is significant, because it can affect how traffic is processed during an IPS fail open event for both proxy-based and flow-based traffic. Protocol port mapping only works with proxy-based inspection. Flow-based inspection inspects all ports regardless of the protocol port mapping configuration.

Network Security Support Engineer 7.2 Study Guide

267

Security Profiles

DO NOT REPRINT © FORTINET

Short spikes in the CPU usage by IPS processes could be caused by firewall policy or profile changes. These spikes are usually normal. Spikes might happen when FortiGate has hundreds of policies and profiles, or many virtual domains. Continuous high CPU usage by the IPS engines is not normal, and you should investigate it.

Network Security Support Engineer 7.2 Study Guide

268

Security Profiles

DO NOT REPRINT © FORTINET

If there are high CPU usage problems that the IPS caused, you can use the diagnose test application ipsmonitor command with option 5 to isolate where the problem might be. Option 5 enables IPS bypass mode. In this mode, the IPS is still running, but it is not inspecting traffic. If the CPU usage decreases after that, it usually indicates that the volume of traffic being inspected is too high for that particular FortiGate model. If the CPU usage remains high after you enable IPS bypass mode, it usually indicates a problem in the IPS engine that you must report to Fortinet support. If you enable IPS bypass mode, remember to disable it after you finish troubleshooting, using option 5. Another recommendation to keep in mind is if you need to restart the IPS, don't use the diagnose sys kill command. Instead, use option 99, as shown on this slide. This guarantees that all IPS-related processes will restart correctly.

Network Security Support Engineer 7.2 Study Guide

269

Security Profiles

DO NOT REPRINT © FORTINET

If the IPS is generating false positives, first determine which signature is generating them. You can use IP exemptions as a solution. Additionally, you can provide sniffer samples and the matching logs to the FortiGuard team for further investigation.

Network Security Support Engineer 7.2 Study Guide

270

Security Profiles

DO NOT REPRINT © FORTINET

False negatives are more difficult to discover and troubleshoot. Check the following: • Traffic is hitting the correct policy or IPS profile (use the sniffer and debug flow, if necessary). • CPU and memory use is normal. • IPS engines aren’t crashing. • IPS configuration is correct. Again, after you verify all of those factors, you can collect sniffer samples and, along with details of the application traffic, provide all the information to the Fortinet IPS team for investigation.

Network Security Support Engineer 7.2 Study Guide

271

Security Profiles

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned how to troubleshoot some of the security profile features.

Network Security Support Engineer 7.2 Study Guide

272

High Availability

DO NOT REPRINT © FORTINET

In this lesson, you will learn how to monitor the status of a high availability (HA) cluster, configure session synchronization, and use the troubleshooting steps and commands for HA issues.

Network Security Support Engineer 7.2 Study Guide

273

High Availability

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in understanding HA, you will understand how to monitor the status of an HA cluster, configure session synchronization, and diagnose and resolve HA cluster issues.

Network Security Support Engineer 7.2 Study Guide

274

High Availability

DO NOT REPRINT © FORTINET

In this section, you will learn how to monitor the HA configuration status among devices in the HA cluster.

Network Security Support Engineer 7.2 Study Guide

275

High Availability

DO NOT REPRINT © FORTINET

The HA framework consists of two daemons: hatalk and hasync. The process hatalk monitors cluster management and failure monitoring. The process hasync handles the synchronization of configuration files, the upgrade process, IKE notifications, external files, the ARP table, and FIB. The process hasync engages other processes to fulfill its purpose, like configuration daemons cmdb, update, iked, authd, and snmpd.

Network Security Support Engineer 7.2 Study Guide

276

High Availability

DO NOT REPRINT © FORTINET

The HA heartbeats are generated by the kernel. This gives this traffic priority over other types of packets. HA heartbeat packets are prioritized to guarantee the health of the HA cluster and traffic flow. The command diagnose sys ha heartbeat displays how many CPU cores handle the heartbeats and their distribution.

Network Security Support Engineer 7.2 Study Guide

277

High Availability

DO NOT REPRINT © FORTINET

The hbdev interface is configured under config system ha which assigns the interface that will transmit and receive the HA heartbeats. As part of the kernel processing of heartbeat packets, the kernel signals to the hatalk daemon the presence of heartbeat packets to process. The process hatalk time stamps the HA packets that process and perform a diff time function to monitor if it has reached the hb-lost-threshold that could trigger an HA heartbeat timeout. HA heartbeat packets consume more bandwidth if the heartbeat interval is short, but if the heartbeat interval is very long, the cluster is not as sensitive to topology changes and other network changes.

Network Security Support Engineer 7.2 Study Guide

278

High Availability

DO NOT REPRINT © FORTINET

If the HA cluster forms successfully, the GUI displays all the FortiGate members with their host names, serial numbers, role, uptime, and synchronization status.

Network Security Support Engineer 7.2 Study Guide

279

High Availability

DO NOT REPRINT © FORTINET

If the HA cluster forms, but the configurations are not synchronized, the GUI tooltip for the cluster members displays the portions of their configuration that are out of sync.

Network Security Support Engineer 7.2 Study Guide

280

High Availability

DO NOT REPRINT © FORTINET

When troubleshooting a problem in an HA cluster, it is useful to know that you can connect to the CLI of any secondary device from the CLI of the primary device. Using the command shown on this slide with the HA index of the secondary device, you can connect to the CLI of the secondary device. To get the list of secondary FortiGate devices and their HA indexes, type a question mark at the end of that same command.

Network Security Support Engineer 7.2 Study Guide

281

High Availability

DO NOT REPRINT © FORTINET

Using the CLI, you can get more information about the status of HA. For example, the command shown on this slide displays heartbeat traffic statistics, as well as the serial number and HA priority of each FortiGate. This command also shows the IP address of the heartbeat interface that is automatically assigned to the primary FortiGate.

Network Security Support Engineer 7.2 Study Guide

282

High Availability

DO NOT REPRINT © FORTINET

You can use the command shown on this slide to display the following information: • HA health status • Cluster uptime • Criteria used to select the primary device • Override status • Status of the monitored interfaces • Status of the HA ping servers

Network Security Support Engineer 7.2 Study Guide

283

High Availability

DO NOT REPRINT © FORTINET

The HA uptime is one of the variables used to elect the primary device. Depending on other variables and configurations, the devices might compare their system uptimes to elect the primary. If that happens, and if there is one member whose system uptime is 5 minutes more than the system uptimes of all the other devices, that member is elected as the primary. You can use this command to compare the system uptimes of all the devices in a cluster. The reset_cnt value shows you how many times the HA uptime has been reset with the diagnose sys ha reset-uptime command.

Network Security Support Engineer 7.2 Study Guide

284

High Availability

DO NOT REPRINT © FORTINET

A good indication of the health of an HA cluster is the status of the configuration synchronization. To verify that all the secondary configurations are synchronized with the primary configuration, you can use the command shown on this slide on all the HA devices. If a secondary FortiGate displays the same sequence of numbers as the primary, its configuration is synchronized. Also, and as long as there are no configuration changes happening, on each of the devices, the debugzone and the checksum zone must display the same sequence of numbers. Later in this lesson, you will learn some tips for troubleshooting when this is not the case. The checksum zone contains the checksum of the configuration that is actually running on the device. The debugzone is where configuration changes are first stored before they are applied to the running configuration. So, during a configuration change you might see that the debugzone checksum differs from the checksum for a short time, while the configuration changes are copied to the running configuration. After that short time, both checksums should match again.

Network Security Support Engineer 7.2 Study Guide

285

High Availability

DO NOT REPRINT © FORTINET

Instead of using the checksum show command on each of the cluster devices, you can use the command shown on this slide only on the primary. It shows the checksum for all the cluster members. This command is easier to use; however, if there are communication problems between one of the secondary devices and the primary, you might need to use the checksum show command instead.

Network Security Support Engineer 7.2 Study Guide

286

High Availability

DO NOT REPRINT © FORTINET

The command checksum show allows you to drill down to different levels. It can provide a general checksum at the global level, including all the VDOMs configured on FortiGate, as well as provide the checksum for a specific VDOM or the checksum of a specific configuration section from a VDOM. These different levels can be very useful while troubleshooting an HA cluster that needs to identify what setting is triggering an out-of-sync issue.

Network Security Support Engineer 7.2 Study Guide

287

High Availability

DO NOT REPRINT © FORTINET

In this section, you will learn about session synchronization among devices in an HA cluster.

Network Security Support Engineer 7.2 Study Guide

288

High Availability

DO NOT REPRINT © FORTINET

By default, HA session synchronization is disabled. Most sessions can be resumed as a normal result of how TCP/IP communications resume communication after a network interruption. You should balance the traffic requirements and performance impact before enabling session-pickup. If you enable it, a number of session requirements and limitations take place because the primary device synchronizes sessions with the secondary device. Under ideal conditions, all TCP sessions should be resumed. Optionally, you can enable session synchronization for connectionless, ICMP/UDP, and short-lived sessions.

Network Security Support Engineer 7.2 Study Guide

289

High Availability

DO NOT REPRINT © FORTINET

There are some factors and criteria that the primary device follows when synchronizing a session to a secondary device. By default, once session-pickup is enabled, as soon as a new TCP session is added to the primary device session table, that session is synchronized to all devices in the cluster. This synchronization happens as quickly as possible to keep the session tables synchronized. Other events that trigger the session table synchronization from the primary device to the other devices in the cluster occur if there is a session state update or if a session has been deleted. Most of the session synchronization communication comes from the primary to the rest of the devices in the cluster; secondary devices would send queries to the primary device about session timer updates.

Network Security Support Engineer 7.2 Study Guide

290

High Availability

DO NOT REPRINT © FORTINET

By default, session synchronization activity takes place over the HA heartbeat link using TCP/703 and UDP/703 packets. The command get sys ha status displays if session pickup is enabled. The HBDev stats section should show that the RX and TX counters are incrementing. If there is a large number of session synchronizations, this could cause network congestion and impact the HA cluster communication. One option is to select one or more ports to use for synchronizing sessions, which can improve HA heartbeat traffic and the performance of the HA cluster.

Network Security Support Engineer 7.2 Study Guide

291

High Availability

DO NOT REPRINT © FORTINET

You can check the session table of the primary device to see which sessions have been synchronized to the secondary devices. They are the ones with the synced flag. Additionally, and in the case of all sessions, the ha_id field shows the HA member ID of the device that is processing the traffic.

Network Security Support Engineer 7.2 Study Guide

292

High Availability

DO NOT REPRINT © FORTINET

In this section, you will learn about some HA troubleshooting steps and commands.

Network Security Support Engineer 7.2 Study Guide

293

High Availability

DO NOT REPRINT © FORTINET

There are five occurrences that can trigger a failover: • When the primary stops replying to heartbeats • When the link status of a monitored interface goes down. You can configure an HA cluster to monitor the link status of one or more interfaces. • When a server (IP address) stops replying to the ping that the primary sent. You can configure an HA cluster to periodically send a ping to one or more servers to test the connectivity between the primary device and the network services. • When FortiOS detects a failure in an SSD. This is only available for devices with SSDs. • When memory-based failover is enabled and the configured conditions for utilization exceed the threshold during each sample over the monitor period

Network Security Support Engineer 7.2 Study Guide

294

High Availability

DO NOT REPRINT © FORTINET

If a failover happens, the best tool to use to get information about the failover is the FortiGate logs. If the failover happened because the primary device failed, the secondary device logs should show these log entries.

Network Security Support Engineer 7.2 Study Guide

295

High Availability

DO NOT REPRINT © FORTINET

If a new primary was elected because one or more monitored interfaces failed, the former primary displays logs similar to the ones shown on this slide. In the example shown on this slide, the primary device is reporting a problem with the monitored interface port1.

Network Security Support Engineer 7.2 Study Guide

296

High Availability

DO NOT REPRINT © FORTINET

Another useful way to determine the reason for an HA failover is by running the command shown on this slide. This command provides details about past HA events, which allows administrators to identify the reason for previous failover events. This is a useful HA command, especially when HA logs are not available.

Network Security Support Engineer 7.2 Study Guide

297

High Availability

DO NOT REPRINT © FORTINET

An HA split-brain scenario occurs when the FortiGate devices in an HA cluster lose heartbeat communication through the heartbeat links. Because of the lost communication, each FortiGate assumes the role of the primary device. When this issue occurs, the results are very evident because traffic flow is impacted. While experiencing a split-brain issue, the administrative access to the devices in the cluster is intermittent; console access might be required to troubleshoot the device and perform configuration changes, if required. This issue could be triggered by a faulty physical port or cable, a failed firmware upgrade, or a congested heartbeat link.

Network Security Support Engineer 7.2 Study Guide

298

High Availability

DO NOT REPRINT © FORTINET

There are some basic HA troubleshooting steps to verify the HA cluster health and get the cluster out of this situation: 1. 2. 3. 4.

Verify that all devices in the cluster are running the same firmware version. Check that the configuration is synchronized. Verify the status of the heartbeat ports. Verify that the Ethernet packets are transmitted and received successfully between the cluster members.

Following these steps will help to diagnose the root cause that triggered this behavior.

Network Security Support Engineer 7.2 Study Guide

299

High Availability

DO NOT REPRINT © FORTINET

If a device can’t join a cluster, follow these steps: 1. Verify the HA settings. 2. Verify the firmware versions and hardware models. 3. Verify the physical layer connections. 4. Use the HA real-time debug while the device tries to join the cluster. Run the debug on both the primary device and the device with the problem. If the problem is that the checksums between the debugzone and checksum zones don’t match, you can try to fix it by forcing the recalculation.

Network Security Support Engineer 7.2 Study Guide

300

High Availability

DO NOT REPRINT © FORTINET

Traffic from session synchronization is bandwidth intensive. If the session creation rate is high, session synchronization traffic can interfere with heartbeat traffic, creating delays in heartbeat replies. There are two configuration changes that you can make that might help: • •

Use a different interface from the heartbeat interface for session synchronization. Delay the synchronization of new sessions by 30 seconds, so short-lived sessions are not synchronized.

High CPU issues can also create HA heartbeat problems. In those cases, troubleshoot and fix the high CPU problem first, before you check the HA status.

Network Security Support Engineer 7.2 Study Guide

301

High Availability

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned how to monitor an HA cluster and steps to troubleshoot FortiGate devices running in HA.

Network Security Support Engineer 7.2 Study Guide

302

IPsec

DO NOT REPRINT © FORTINET

In this lesson, you will learn about IPsec.

Network Security Support Engineer 7.2 Study Guide

303

IPsec

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating a competent understanding of IPsec, you will be able to manage, monitor, diagnose, debug, and troubleshoot IPsec.

Network Security Support Engineer 7.2 Study Guide

304

IPsec

DO NOT REPRINT © FORTINET

In this section, you will learn the CLI commands to monitor the status and statistics of IPsec VPNs.

Network Security Support Engineer 7.2 Study Guide

305

IPsec

DO NOT REPRINT © FORTINET

The same command diagnose vpn tunnel offers options for shutting down, activating, or flushing a VPN tunnel.

Network Security Support Engineer 7.2 Study Guide

306

IPsec

DO NOT REPRINT © FORTINET

The command diagnose vpn tunnel list displays the current IPsec SA information for all active tunnels. The command diagnose vpn tunnel list name provides SA information about a specific tunnel.

Network Security Support Engineer 7.2 Study Guide

307

IPsec

DO NOT REPRINT © FORTINET

The command get vpn ipsec tunnel details provides detailed information for the active IPsec tunnels. For detailed information about each tunnel, use the command diagnose vpn IPsec tunnel detail. The output shows traffic counters, negotiated quick mode selectors, and negotiated encryption, authentication, and keys.

Network Security Support Engineer 7.2 Study Guide

308

IPsec

DO NOT REPRINT © FORTINET

The command diagnose vpn ike gateway list also provides some details about a tunnel. The command diagnose vpn ike gateway clear closes a phase 1. Be careful when using this command because it has a global effect. This means that running it without specifying the phase 1 name results in all phase 1s of all VDOMs being cleared.

Network Security Support Engineer 7.2 Study Guide

309

IPsec

DO NOT REPRINT © FORTINET

The command get vpn IPsec stats tunnel provides some global overall counters related to all the VPNs that are currently active. The other two commands shown on this slide provide summarized information about the VPNs.

Network Security Support Engineer 7.2 Study Guide

310

IPsec

DO NOT REPRINT © FORTINET

In this section, you will learn the CLI commands to debug a phase 1 and 2 negotiations.

Network Security Support Engineer 7.2 Study Guide

311

IPsec

DO NOT REPRINT © FORTINET

The IKE daemon handles all IPsec connections on FortiGate. It’s important to familiarize yourself with the available filter options. You use these options to filter the output of the IKE real-time debug, so that only information that is relevant to you is displayed. The most common filter option is dst-addr4, which you use to filter the output by the IP address of the remote peer. Also, multiple addresses are supported. Filtering by name is helpful when the remote peer IP address is unknown.

Network Security Support Engineer 7.2 Study Guide

312

IPsec

DO NOT REPRINT © FORTINET

After setting the filter, enable the IKE real-time debug using the commands shown on this slide. The table shown on this slide includes the type of output that is enabled by each bit in the bitmask. The most common value for the bitmask is -1 (all outputs enabled). It shows the DPD packets and all the information required for troubleshooting IPsec negotiation problems.

Network Security Support Engineer 7.2 Study Guide

313

IPsec

DO NOT REPRINT © FORTINET

Now, you will look at the output of the IKE real-time debug during a main-mode negotiation. As explained earlier, main mode requires the interchange of six packets. The real-time debug shows when the first packet (first main mode message) arrives. Then, the debug shows the negotiated settings for the phase 1. A message is generated after FortiGate identifies the VPN configuration to use (with the name of the VPN).

Network Security Support Engineer 7.2 Study Guide

314

IPsec

DO NOT REPRINT © FORTINET

Next, the output shows the remote peer’s information. The second and third main mode messages arrive. After the authentication is successful and the pre-shared key matches, a final message is generated to indicate that phase 1 is up.

Network Security Support Engineer 7.2 Study Guide

315

IPsec

DO NOT REPRINT © FORTINET

This slide shows the output of the real-time debug for phase 1 aggressive mode. It displays the three aggressive-mode packets exchanged, and the proposals.

Network Security Support Engineer 7.2 Study Guide

316

IPsec

DO NOT REPRINT © FORTINET

The IKE real-time debug shows, after phase 1, the exchange of XAuth packets. On this slide, you can see the CFG_REQUEST packet. You can also see the CFG_REPLY, showing the XAuth user and group name. After that, the IKE real-time debug shows the CFG_SET and CFG_ACK.

Network Security Support Engineer 7.2 Study Guide

317

IPsec

DO NOT REPRINT © FORTINET

After the extended authentication, the remote site proceeds to request and receive the IP settings through IKE mode configuration. The output shows the CFG_REQUEST and CFG_REPLY packets.

Network Security Support Engineer 7.2 Study Guide

318

IPsec

DO NOT REPRINT © FORTINET

This slide shows the phase 2 negotiation. The debug shows the phase 2 proposal from the local gateway, and the phase 2 proposal coming to the remote gateway. In this case, both proposals (local and remote) match.

Network Security Support Engineer 7.2 Study Guide

319

IPsec

DO NOT REPRINT © FORTINET

Next, the output shows the negotiated phase 2 settings. The last messages confirm that the phase 2 is up.

Network Security Support Engineer 7.2 Study Guide

320

IPsec

DO NOT REPRINT © FORTINET

In this section, you will learn how to configure and monitor IPsec encryption and decryption on hardware offload.

Network Security Support Engineer 7.2 Study Guide

321

IPsec

DO NOT REPRINT © FORTINET

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

Network Security Support Engineer 7.2 Study Guide

322

IPsec

DO NOT REPRINT © FORTINET

All IPsec SAs have an npu_flag field that indicates the offloading status. In the case of IPsec traffic, the FortiGate session table also includes that field. First, when phase 2 comes up, the IPsec SAs are created and loaded to the kernel. As long as there is no traffic crossing the tunnel, the SAs are not copied to the NPU, and the npu_flag shows 00. The value of that field also remains 00 when IPsec offloading is disabled. Second, if the first IPsec packet that arrives is an outbound packet that can be offloaded, the outbound SA is copied to the NPU and the npu_flag changes to 01. However, if the first IPsec packet is inbound and can be offloaded, the inbound SA is copied to the NPU and the npu_flag changes to 02. After both SAs are copied to the NPU, the npu_flag changes to 03. The value 20 in the npu_flag field indicates that hardware offloading is unavailable because of an unsupported cipher or HMAC algorithm.

Network Security Support Engineer 7.2 Study Guide

323

IPsec

DO NOT REPRINT © FORTINET

This command shows the number of packets encrypted and decrypted by software (CPU), and by each type of processor unit on FortiGate.

Network Security Support Engineer 7.2 Study Guide

324

IPsec

DO NOT REPRINT © FORTINET

In this section, you will learn IPsec troubleshooting steps and commands.

Network Security Support Engineer 7.2 Study Guide

325

IPsec

DO NOT REPRINT © FORTINET

When isolating IPsec problems, it is useful to understand that an IPsec connection can be described as a multistep process: 1. Interesting traffic triggers the VPN negotiation. Traffic is called interesting when it must travel through an IPsec tunnel (encrypted and encapsulated) to reach a remote network. 2. Phase 1 comes up. 3. If extended authentication is required, one side authenticates. 4. If one side requires IP settings, the other side sends the required settings through the IKE mode configuration. 5. One or more phase 2s go up. Two IPsec SAs are negotiated for each phase 2. 6. Traffic crosses the tunnel. So, if you have an IPsec issue, you should identify in which of these steps the problem has occurred.

Network Security Support Engineer 7.2 Study Guide

326

IPsec

DO NOT REPRINT © FORTINET

Now assume that when the phase 1 comes up, the phase 2 also comes up, but, for some reason, the traffic is not crossing the tunnel. If the VPN is up but the traffic can’t cross the tunnel, you should use the debug flow. If possible, run it in both gateways. This will let you know if the local gateway is dropping the packets or not routing the packets through the tunnel, or if the remote gateway is dropping the packets. This slide shows an example output of the debug flow for traffic that is crossing an IPsec tunnel. The output shows the following: • Packet arriving • Packet being allowed by a firewall policy • Packet entering the tunnel • Packet being encrypted and sent If the traffic is not crossing the tunnel because of a routing misconfiguration, the output of the debug flow shows it. The debug flow also displays if the traffic drops and why (for example, when packets don’t match the quick mode selector).

Network Security Support Engineer 7.2 Study Guide

327

IPsec

DO NOT REPRINT © FORTINET

If you need to capture IPsec traffic, remember that the IP protocol and UDP port numbers depend on NAT-T and the use of NAT. If there is no FortiGate located in the middle that is running NAT, IKE traffic uses UDP port 500 and ESP traffic uses IP protocol 50. This slide shows the two sniffer filters that the sniffer command must use to capture each of those traffic protocols. If NAT-T is enabled, and there is a FortiGate located in the middle that is running NAT, the sniffer command must use a different filter. In this case, IKE traffic uses port UDP 500, but switches to UDP port 4500 during the tunnel negotiation. Additionally, ESP traffic is encapsulated inside the UDP 4500 channel. Note that port 500 and port 4500 are the default UDP port numbers for IKE and IKE NAT-T, respectively. These ports can be configured using the command config system settings and options set ikeport and set ike-natt-port .

Network Security Support Engineer 7.2 Study Guide

328

IPsec

DO NOT REPRINT © FORTINET

This slide shows a summary of the most common IPsec problems and solutions. If the tunnel doesn’t come up, use the IKE real-time debug. In such cases, an error message usually appears. When the tunnel is unstable, you usually see that DPD packets are being lost, which indicates that the problem might be on the ISP side. If the tunnel is up but traffic isn’t passing through it, use the debug flow. One of the peers might be dropping packets or routing traffic incorrectly. Another possibility is that the packets don’t match the quick mode selectors, so FortiGate drops the packets.

Network Security Support Engineer 7.2 Study Guide

329

IPsec

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned how to manage, monitor, diagnose, debug, and troubleshoot IPsec.

Network Security Support Engineer 7.2 Study Guide

330

IPsec―IKEv2

DO NOT REPRINT © FORTINET

In this lesson, you will learn you will learn about IPsec IKEv2.

Network Security Support Engineer 7.2 Study Guide

331

IPsec―IKEv2

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating a competent understanding of IPsec IKEv2, you will be able to explain the differences and advantages of IKEv2 and its negotiation process.

Network Security Support Engineer 7.2 Study Guide

332

IPsec―IKEv2

DO NOT REPRINT © FORTINET

In this section, you will learn about the differences between IKEv1 and IKEv2.

Network Security Support Engineer 7.2 Study Guide

333

IPsec―IKEv2

DO NOT REPRINT © FORTINET

Although IKEv1 is still widely used, you must consider multiple factors when deciding whether to continue using IKEv1 or replace it. Notably, IKEv1 development ceased over a decade ago—and unmaintained code can result in security vulnerabilities. IKEv1 has been moved to historic status and some of its RFC specifications have become obsolete. Some algorithms used in IKEv1 are no longer actively deployed or researched, which presents an unknown security risk that you should avoid. Some IKEv1 functionalities never reached the standard state and some do not even have an RFC.

Network Security Support Engineer 7.2 Study Guide

334

IPsec―IKEv2

DO NOT REPRINT © FORTINET

Even though IKEv1 is deprecated, it can still fulfill some system requirements: • When RADIUS or LDAP authentication is required for a FortiGate device acting as a dialup client: Because FortiOS doesn't have an EAP client, a FortiGate device cannot authenticate itself against a RADIUS/LDAP server. In this case, IKEv1 must be used. • When multiple stages of authentication are required: Although IKEv2 can provide a solution to this requirement, it requires multiple authentication exchanges or EAP chaining (EAP TEAP). FortiOS has used IKEv1 for more than 20 years, which has driven fixes and optimizations.

Network Security Support Engineer 7.2 Study Guide

335

IPsec―IKEv2

DO NOT REPRINT © FORTINET

IKEv1 and IKEv2 are incompatible protocols that achieve the same goal, but in different ways. IKE version 2 does not interoperate with IKE version 1, but they both have enough of the header format in common that both versions can unambiguously run over the same UDP port. While the core IKEv1 functionalities are defined through multiple RFCs, the main IKEv2 RFC covers, in a single document, many of the same functionalities, like NAT, mode-cfg, EAP, DPD, and so on.

Network Security Support Engineer 7.2 Study Guide

336

IPsec―IKEv2

DO NOT REPRINT © FORTINET

There are multiple reasons to transition to IKEv2: • IKEv2 is a robust and reliable protocol that developers are actively working on. • One of its improvements is that negotiations require fewer messages, which translates into decreased latency for establishing a tunnel. The initial exchange is two round trips (four messages), which allows the ability to piggyback the setup of a child SA on that exchange. • Other new improvements are: • The negotiation of fragmentation starts with the first message • DoS protection • The rekey logic for IKE/IPSEC SA is more accurately defined • The cryptographic syntax for protecting the IKE messages has been replaced with one based closely on ESP to simplify implementation and security analysis

Network Security Support Engineer 7.2 Study Guide

337

IPsec―IKEv2

DO NOT REPRINT © FORTINET

Other reasons to move to IKEv2 are: • The use of standard EAP as authentication and asymmetric authentication • The option to have matching dial-up phase 1 by ID IKEv2 provides flexibility for traffic selectors. You can specify the payload type for each traffic selector rather than overloading them with ID payloads. IKEv2 also supports a setup with an overlay network ID, SA session resumption, and quick crash detection.

Network Security Support Engineer 7.2 Study Guide

338

IPsec―IKEv2

DO NOT REPRINT © FORTINET

In this section, you will learn about the steps IKEv2 exchange uses to netgotiate an IPsec tunnel.

Network Security Support Engineer 7.2 Study Guide

339

IPsec―IKEv2

DO NOT REPRINT © FORTINET

Unlike IKEv1, IKEv2 is a reliable protocol: The initiator retransmits a request until it either receives a corresponding response or it deems the IKE SA to have failed. In the latter case, the initiator discards the IKE SA and any Child SAs negotiated with the unresponsive peer. IKEv1 has a clearly demarcated phase 1 exchange, which contains six packets followed by a phase 2 exchange of three packets. The IKEv2 exchange is variable. At best, it can exchange as few as four packets. At worst, this can increase to as many as 30 packets, depending on the complexity of authentication. Once the initial exchange takes place, any subsequent traffic then triggers the CREATE_CHILD_SA exchange, which is the equivalent of the phase 2 exchange in IKEv1. IKEv2 does not have aggressive mode or main mode.

Network Security Support Engineer 7.2 Study Guide

340

IPsec―IKEv2

DO NOT REPRINT © FORTINET

IKEv2 doesn’t have a concept of phase 1 or phase 2, but FortiOS CLI and GUI commands and terminology are IKEv1-centric, so you use that format to configure IKEv2 settings. The setting configuration for IKEv2 SA takes place in phase 1. The setting configuration for Child_SA is in phase 2. There are four exchanges during the IKEv2 negotiation. The initial exchanges are: IKE_SA_INIT and IKE_AUTH. IKE_SA_INIT exchange: • Negotiation of security settings to protect the IKE traffic • DoS protection (cookie mechanism) IKE_Auth exchange: • Mutual authentication of two IKE endpoints • Configuration settings like IP/mask, DNS and so on • Child SA: Piggyback setup of a Child_SA. Negotiates IP flow and security settings for the IPsec SA Create_Child_SA exchange: • Creates a new Child_SA or rekey an existing Child_SA • Rekey an IKE SA Informational exchange: • Convey control messages between the IKE endpoints

Network Security Support Engineer 7.2 Study Guide

341

IPsec―IKEv2

DO NOT REPRINT © FORTINET

Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as phase 1). SA_INIT is the first round trip of an IKEv2 initial exchange. An SA_INIT exchange usually takes one round trip. The exchange is extended to two round trips if the responder requests another KE (INVALID_KE_PAYLOAD notification), or if the DoS protection (cookie notification) kicks in. If both KE renegotiation and DoS protection are completed, the exchange increases to three round trips.

Network Security Support Engineer 7.2 Study Guide

342

IPsec―IKEv2

DO NOT REPRINT © FORTINET

IKE_AUTH (authentication) takes place after SA_INIT and is the last stage of the initial exchange. It is protected by the cryptographic algorithms and the keys from the SA_INIT. The peers exchange their identities (IDi, IDr) and provide the proof of their claimed identity (AUTH). When EAP is not used, IKE_AUTH consists of a single request/response exchange. When EAP is used, IKE_AUTH consists of multiple request/response exchanges. The number of exchanges depends on the EAP method being used. By default, a piggyback Child (IPsec) SA is negotiated along with the IKEv2 SA during IKE_AUTH. If additional IPsec SAs are needed (i.e. multiple FortiOS phase 2s are configured), they are negotiated during subsequent CREATE_CHILD_SA exchanges. By IKEv2 design, no Diffie-Hellman public key (KE) is exchanged during an IKE_AUTH exchange. Consequently, any phase 2 DH group configuration mismatch between the FGT and the peer, is only experienced during the first rekey (CREATE_CHILD_SA exchange) of the Child_SA created during IKE_AUTH.

Network Security Support Engineer 7.2 Study Guide

343

IPsec―IKEv2

DO NOT REPRINT © FORTINET

This exchange consists of a single request/response pair, and was referred to as a phase 2 exchange in IKEv1. It be initiated by either end of the IKE_SA after the initial exchanges are completed. All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKE exchange. All subsequent messages included an encrypted payload, even if they are referred to in the text as "empty". Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this section the term "initiator" refers to the endpoint initiating this exchange.

Network Security Support Engineer 7.2 Study Guide

344

IPsec―IKEv2

DO NOT REPRINT © FORTINET

At various points during the operation of an IKE_SA, peers may desire to convey control messages to each other regarding errors or notifications of certain events. To accomplish this, IKE defines an Informational exchange. Informational exchanges must occur only after the initial exchanges and are cryptographically protected with the negotiated keys.

Network Security Support Engineer 7.2 Study Guide

345

IPsec―IKEv2

DO NOT REPRINT © FORTINET

In this section, you will learn the commands to monitor an IKEv2 tunnel and the commands to debug and troubleshoot IKEv2.

Network Security Support Engineer 7.2 Study Guide

346

IPsec―IKEv2

DO NOT REPRINT © FORTINET

The commands to monitor, debug, and troubleshoot IKEv2 are the same as IKEv1. The command diagnose vpn ike gateway list provides some details about a tunnel. The command diagnose vpn ike gateway clear closes a phase 1. It’s useful while troubleshooting to force a tunnel negotiation, but it has to be used with caution. The command diagnose vpn tunnel list displays the current IPsec SA information for all active tunnels. In order to debug the connection of an IPsec IKEv2, use the diagnose debug application ike command, like you would in IKEv1, and apply a filter with diagnose vpn ike log-filter to gather the debug output of a specific tunnel.

Network Security Support Engineer 7.2 Study Guide

347

IPsec―IKEv2

DO NOT REPRINT © FORTINET

Once the debug command diagnose debug application ike is enabled and an IPsec negotiation starts, you can analyze the IKEv2 negotiation process. In the initial negotiation, you can see the SA_INIT exchange. The slide shows the SAN_INIT was sent and that the initiator received the SA_INIT response.

Network Security Support Engineer 7.2 Study Guide

348

IPsec―IKEv2

DO NOT REPRINT © FORTINET

After a successful SA_INIT exchange, the IKE_AUTH exchange takes place. The debug output shows the messages received and their response. The slide shows the AUTH exchange sent by the initiator and the responses that it receives.

Network Security Support Engineer 7.2 Study Guide

349

IPsec―IKEv2

DO NOT REPRINT © FORTINET

After IKE_SA_INIT and IKE_AUTH exchanges are successful, the CHILD_SA exchange takes place. In this exchange, the peers negotiate the CHILD_SA and the traffic selectors (TSr/Tsi).

Network Security Support Engineer 7.2 Study Guide

350

IPsec―IKEv2

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned about the improvements made to IKEv2, its negotiation process, and how to debug an IPsec tunnel using the IKEv2 protocol.

Network Security Support Engineer 7.2 Study Guide

351

Routing

DO NOT REPRINT © FORTINET

In this lesson, you will learn about advanced routing concepts. You will also learn useful troubleshooting commands to debug routing issues.

Network Security Support Engineer 7.2 Study Guide

352

Routing

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in routing, you will be able to describe how FortiGate routes traffic, diagnose routing problems that the reverse path forwarding (RPF) check causes, identify sessions that are routed through a different path, and use debug commands to troubleshoot routing problems.

Network Security Support Engineer 7.2 Study Guide

353

Routing

DO NOT REPRINT © FORTINET

In this section, you will learn about general routing concepts and troubleshooting.

Network Security Support Engineer 7.2 Study Guide

354

Routing

DO NOT REPRINT © FORTINET

FortiGate is a stateful device, so it decodes a lot of information at the beginning of a session, based on the first packets. For any traffic session, FortiGate usually performs only two routing lookups: one on the first packet that the originator sends and another one on the first reply packet that the responder sends. After that, all the routing information is written in the FortiGate session table. However, after a change to the routing table, the route information is flushed from the affected entries in the session table. So, FortiGate would perform additional routing table lookups in order to repopulate the session table with the new routing information.

Network Security Support Engineer 7.2 Study Guide

355

Routing

DO NOT REPRINT © FORTINET

The flowchart on this slide describes the route lookup process on FortiOS. Note that policy routes can be regular policy routes, Internet Service Database (ISDB) routes, or SD-WAN rules. First, FortiGate checks the policy routes. The first type of policy routes that FortiGate checks are the regular policy routes. If there is a match, and the action is Forward Traffic, FortiGate routes the packet accordingly, as long as the policy route passes the forward information base (FIB) validation process. If the action is Stop Policy Routing, FortiGate moves on to check its route cache. If the packet doesn’t match any of the regular policy routes, FortiGate moves on to check the ISDB routes first, and then the SD-WAN rules. If the packet doesn’t match any of the SD-WAN rules, FortiGate checks its route cache. Next, FortiGate checks the FIB, which is the table that is used to perform standard routing. The FIB can be described as the routing table from the kernel point of view, and is built mostly out of routes in the routing table, but also from system-specific entries that FortiOS requires. If the packet doesn’t match any of the routes in the FIB, FortiGate drops the packet and sends an ICMP destination network unreachable message to the sender. This slide also shows the FortiOS CLI commands you can use to display the policy routes, route cache entries, routing table entries, and FIB entries.

Network Security Support Engineer 7.2 Study Guide

356

Routing

DO NOT REPRINT © FORTINET

This slide shows the process for selecting which route to use, if there is more than one route to a destination. First, FortiGate uses the most specific route, which is the one with the longest netmask (smallest subnet). If there are two or more routes with the same longest netmask, the device selects the one with the shortest distance. After that, FortiGate uses the lowest metric as the tiebreaker for dynamic routes. In the case of static routes, FortiGate uses the lowest priority instead. If there are multiple routes with the same netmask, distance, metric, and priority, FortiGate shares the traffic among all of them. This is called equal-cost multi-path (ECMP). ECMP is supported for static, BGP, and OSPF routes.

Network Security Support Engineer 7.2 Study Guide

357

Routing

DO NOT REPRINT © FORTINET

FortiGate adds a static route to the routing table only if the route meets all of the following requirements: • The outgoing interface is up • There is no duplicate route with a shorter distance • The link health monitor (if configured) is up

Network Security Support Engineer 7.2 Study Guide

358

Routing

DO NOT REPRINT © FORTINET

Now, you will review an important routing concept: the reverse path forwarding (RPF) check. The RPF check protects against IP spoofing attacks and routing loops by checking the route to the source IP address. This check is performed on only the first packet when the session is being created. If the check fails, the packet is dropped and the debug flow shows this error: reverse path check fail, drop.

Network Security Support Engineer 7.2 Study Guide

359

Routing

DO NOT REPRINT © FORTINET

The example on this slide shows FortiGate using the feasible path RPF check mode. When FortiGate performs the RPF check, it checks the routing table for a route that matches the source address and incoming interface of the first original packet. Based on the topology and routing table shown on this slide, the RPF check results for traffic sourced from each user are: • • •

User A: Pass. There is a default route through wan1. This means that all packets received at wan1 pass the RPF check, regardless of the source address. User B: Fail. FortiGate doesn’t have a route to 95.56.234.24 through wan2 in its routing table. User C: Fail. Like the user B case, FortiGate doesn’t have a route to 10.0.4.63 through port1 in its routing table.

Network Security Support Engineer 7.2 Study Guide

360

Routing

DO NOT REPRINT © FORTINET

If you consider the packets from user B and user C to be legitimate packets, you can solve the RPF check fail issue by making sure the routing table contains routes for the return path. In the example shown on this slide, the administrator adds two new static routes. The static route through wan2 is a duplicate default route of wan1, but has a lower priority. The two default routes are not ECMP routes because of the priority difference, but FortiGate keeps both routes in the routing table. The result is that packets from user B now pass the RPF check. The static route through port1 references the 10.0.4.0/24 subnet. The subnet includes the user C address (10.0.4.63), and as a result, packets from user C also pass the RPF check.

Network Security Support Engineer 7.2 Study Guide

361

Routing

DO NOT REPRINT © FORTINET

The example on this slide shows FortiGate using the strict RPF check mode. In strict mode, FortiGate also checks if the matching route is the best route to the source. Based on the topology and routing table shown on this slide, the RPF check results for traffic sourced from each user are: • • •

User A: Pass. There is a default route through wan1. The route is also the best (and only) route to 71.234.149.16. User B: Fail. There is a default route through wan2. However, there is a better (more specific) static route to 95.56.234.24 through wan1. User C: Pass. FortiGate has a route to 10.0.4.63 through port1 in its routing table. Although the default routes through wan1 and wan2 are also valid routes for 10.0.4.63, the best route to user C is the route through port1.

Like the feasible path example, you can solve the RPF fail issue for user B by making the respective changes in the routing table so the best route to user B is through wan2.

Network Security Support Engineer 7.2 Study Guide

362

Routing

DO NOT REPRINT © FORTINET

Content inspection requires that routing be kept as symmetric as possible; that is, traffic must follow the same path both ways. There are multiple scenarios where asymmetric routing prevents FortiGate from inspecting traffic content. So, FortiGate routes traffic symmetrically. This means that, in some network topologies, FortiGate might not route the return traffic through the best path, but through the same path that the originating traffic used. For that purpose, FortiGate remembers the interface to the source and uses that interface to route the return packets, even when a better route using a different interface exists.

Network Security Support Engineer 7.2 Study Guide

363

Routing

DO NOT REPRINT © FORTINET

Now, you will analyze the network topology shown on this slide. The local network 10.1.0.0/24 has three network devices: a local workstation, local router, and FortiGate port1. Also, FortiGate port2 is directly connected to the local router (using the subnet 10.2.0.0/24). There is a remote router connected to FortiGate port3 and, behind that, a remote server (10.4.0.1). So, any traffic destined to the remote server must be routed through FortiGate. One important detail in this network is that the local workstation default gateway is 10.1.0.254. This means that if you send an ICMP echo request from the local workstation to the remote server, the packet goes to the local router first, then to FortiGate, then to the remote router, and finally to the destination. When the ICMP packet arrives at FortiGate, an entry for the originating traffic is created in the device route cache, which can be validated using the command diagnose ip rtcache list. This entry contains the interface to source—or the incoming interface where the packet arrived, which is port2 in this case.

Network Security Support Engineer 7.2 Study Guide

364

Routing

DO NOT REPRINT © FORTINET

Additionally, FortiGate creates an entry in the session table. This entry also contains information about the source interface. To view this information, use the diagnose sys session list command. As explained earlier, FortiGate does a first routing lookup to find the next hop to the destination. That IP address is also stored in the session information. Because there is no ICMP echo reply yet, the next hop to the source is still unknown (it is 0.0.0.0). It is identified with the second routing lookup that occurs with the first reply packet.

Network Security Support Engineer 7.2 Study Guide

365

Routing

DO NOT REPRINT © FORTINET

Now, take a look at how FortiGate routes the return packet. Because there is already a session and route cache entry, when FortiGate receives the ICMP echo reply, it uses the interface to the source. So, in this case, the device routes the packet through port2 toward the local router, even though there is a better route to the destination 10.1.0.1. The FortiGate routing table shows port1 as the best route to 10.1.0.1 (locally connected), but it still uses port2. The objective is to keep the traffic flow symmetric. With the first ICMP echo reply, FortiGate adds a second entry to the route cache, this time for the return traffic.

Network Security Support Engineer 7.2 Study Guide

366

Routing

DO NOT REPRINT © FORTINET

Additionally, FortiOS does a second routing lookup, this time to find the next hop (or gateway) to the source. That IP address is added to the session, which was previously set to 0.0.0.0.

Network Security Support Engineer 7.2 Study Guide

367

Routing

DO NOT REPRINT © FORTINET

What happens if the traffic originates from the server side instead? Say that the ping is sent from the remote server to the local workstation. In this case, when the ICMP echo request arrives at FortiGate, there is no session yet. So, FortiGate uses the best route to 10.1.0.1, which is through port1. The example on this slide shows how FortiGate might, in some network topologies, route packets to the same destination differently, depending on who initiated the session.

Network Security Support Engineer 7.2 Study Guide

368

Routing

DO NOT REPRINT © FORTINET

Take a look at the reply traffic in the example shown on this slide. Use the sniffer tool to view the traffic flow. Because the local workstation default gateway is 10.1.0.254, the ICMP echo reply goes to the local router first. Then, the packet arrives at FortiGate port2. The result is asymmetric routing: the return traffic is following a different path than the originating traffic. The return packet is arriving at port2 instead of port1 (where the originating traffic was sent). In these particular cases, FortiGate accepts this asymmetry, no packets are dropped, and security inspection is not affected.

Network Security Support Engineer 7.2 Study Guide

369

Routing

DO NOT REPRINT © FORTINET

This slide shows an example in which asymmetric routing is not allowed by FortiOS. 1. The server sends an echo request to the PC through port 2 of the local router, effectively bypassing FortiGate. 2. When it receives the echo request, the PC responds with an echo reply through its default gateway, 10.1.0.2, which is port1 on FortiGate. 3. Because there is no existing session, the echo reply is dropped. 4. All subsequent echo replies are also blocked. By default, if an echo request does not pass through FortiGate but the response does, the packet is dropped.

Network Security Support Engineer 7.2 Study Guide

370

Routing

DO NOT REPRINT © FORTINET

There are scenarios in which it might make sense to allow this type of asymmetric routing. Example cases include when you are troubleshooting or when you cannot resolve asymmetric routing issues by ensuring that both ingress and egress traffic pass through FortiGate. Enabling asymmetric routing causes FortiOS to be unable to inspect all traffic. Malicious traffic could pass through the FortiGate undetected and compromise the network. Using the commands on this slide, changes the default routing behavior explained on the previous slide to the following: 1. The server’s ICMP request bypasses FortiGate reaching the PC. 2. The PC’s echo reply passes through FortiGate. No session is matched. However, the packet is not dropped. Instead, the packet is passed to the CPU of FortiGate and is then forwarded using the FIB. 3. All subsequent echo replies are handled the same way as in step 2. 4. FortiGate essentially acts as a router. No security inspection is performed. Remember to disable asymmetric routing if it is used for troubleshooting purposes, once the issue has been resolved.

Network Security Support Engineer 7.2 Study Guide

371

Routing

DO NOT REPRINT © FORTINET

When FortiGate is not applying SNAT, when the routing table changes, FortiGate removes the routing information from the sessions that are affected by the change. Additionally, FortiGate deletes related route cache entries. So, FortiGate does two more routing lookups for the next packets in order to learn the new routing information and store it in the routing table. This slide shows an example of a session just after a routing change. The gateways in both directions change to 0.0.0.0/0 and the interfaces to 0, indicating that FortiGate must learn this information again. Additionally, the dirty flag is added.

Network Security Support Engineer 7.2 Study Guide

372

Routing

DO NOT REPRINT © FORTINET

You can configure session route persistence at the interface level using the commands shown on this slide. The default value is disable. If you enable this setting, sessions passing through that interface continue to pass without being affected by the routing changes. The routing changes apply only to new sessions. If the route is removed from the FIB, then FortiGate must flag the session as dirty, flush its gateway information, and reevaluate the session.

Network Security Support Engineer 7.2 Study Guide

373

Routing

DO NOT REPRINT © FORTINET

This slide shows the details of an ICMP session established through an interface (T_INET_0) that has the setting preserve-session-route enabled. Note that only relevant lines of the session are displayed. Also, note the presence of the route_preserve flag in the session. You can find out the interface name by using the diagnose netlink interface list command.

Network Security Support Engineer 7.2 Study Guide

374

Routing

DO NOT REPRINT © FORTINET

By default, SNAT sessions are not flagged as dirty following a routing change that impacts the session. This is true if the route in use is still in the FIB. However, if the route is removed from the FIB, then FortiGate flags the session as dirty, flushes the outgoing interface and gateway information, and then reevaluates the session when the next packet is received. To force the reevaluation of SNAT sessions following a related routing change, regardless of whether or not the route in use is still in the FIB, enable the snat-route-change setting, as shown on this slide. Note that during the reevaluation of SNAT sessions, if the new route and firewall policy lookup results in a change of the SNAT IP, then FortiGate drops the packet and clears the session. This means that the impacted application might have to initiate a new connection to resume network connectivity, especially if the application is TCP based. This slide shows the debug flow output for a SNAT session during reevaluation. Because the SNAT IP of the new path (192.2.0.9) is different than the SNAT IP of the current path (192.2.0.1), FortiGate drops the packet and clears the session. This also means that, from a connectivity point of view, it makes sense to enable snatroute-change only when the new path for the session uses the same SNAT IP, which can be achieved using IP pools.

Network Security Support Engineer 7.2 Study Guide

375

Routing

DO NOT REPRINT © FORTINET

When you enable auxiliary-session, the FortiGate kernel creates a new auxiliary session and attaches it to the main session. For each traffic path (incoming and outgoing), FortiGate continues to create a new auxiliary session. By default, the system CPU handles dirty sessions that are triggered by reply interface changes. Therefore, hardware offloading is not used. For this reason, a large amount of traffic that these dirty sessions handle may result in high CPU utilization and poor performance. Enabling auxiliary-session under config system settings solves this, by offloading asymmetric sessions to hardware by creating an auxiliary session (also known as a reflect session). Symmetric traffic matches the main session, and asymmetric traffic matches the auxiliary session. Both sessions can be offloaded to hardware. For FortiGate VMs, although hardware offload does not apply, performance is improved because FortiGate does not have to reevaluate the asymmetric traffic. Because a new session is created for each route change, the session table could potentially grow significantly in size.

Network Security Support Engineer 7.2 Study Guide

376

Routing

DO NOT REPRINT © FORTINET

In the example shown on this slide, ECMP is configured for both client and server. FortiGate uses ECMP through port1 and port2 to the client, and ECMP through port3 and port4 to the server. Based on this example, you can see how sessions are handled on FortiGate: 1. Initially, traffic flows from port1 to port3. FortiGate creates a new session: the main session. 2. The reply from the server is received on port4 and forwarded out port1. FortiGate creates auxiliary session 1 and attaches it to the main session. 3. The next packet from the client is received on port1 and forwarded out port4. FortiGate matches auxiliary session 1. 4. Additional traffic from the client is received on port2 and leaves through port3. FortiGate creates auxiliary session 2 and attaches it to the main session. 5. The server reply is received on port3 and leaves through port2. FortiGate matches auxiliary session 2. 6. The second reply is received on port4 and forwarded out port2. FortiGate creates auxiliary session 3 and attaches it to the main session. 7. The last packet from the client flows from port2 to port4. FortiGate matches auxiliary session 3. 8. Finally, the server reply is received on port3 and leaves through port1. FortiGate matches the main session. FortiGate can offload all these sessions, if the policy allows offloading.

Network Security Support Engineer 7.2 Study Guide

377

Routing

DO NOT REPRINT © FORTINET

The CLI command shown on this slide displays all entries in the routing table. The routing table displays the routes that make it to the FIB—that is, the best active routes to a destination. The column on the left indicates the route source. Route attributes are shown inside square brackets. The first number, in the first pair of attributes, is distance, which applies to both dynamic and static routes. The second number is metric, which applies to dynamic routes only. Static routes and dynamic routes also have priority and weight attributes, which are shown as the last pair of attributes for the respective route. In the case of dynamic routes, the weight is always zero. This command doesn't show standby or inactive routes, which are present in the routing table database only. For example, when two static routes to the same destination subnet have different distances, the one with the lower distance is installed in the routing table, and the one with the higher distance is installed in the routing table database.

Network Security Support Engineer 7.2 Study Guide

378

Routing

DO NOT REPRINT © FORTINET

If you want to view active, standby, and inactive routes, use the CLI command shown on this slide to display the routing table database entries. In the example on this slide, the command shows two standby routes: one static and the other BGP. Both standby routes are standby because there are better routes—lower distance—to the same destination. The better routes show an asterisk beside the route source to indicate they are FIB entries, and therefore, are used for routing traffic. The output also shows one inactive route. Routes are marked as inactive when the corresponding interface is administratively down, its link is down, or when the link health monitor detected it as down and the update static route action is enabled.

Network Security Support Engineer 7.2 Study Guide

379

Routing

DO NOT REPRINT © FORTINET

This low-level command shows the FIB, which is the routing information that the kernel uses to route traffic. All active routes in the routing table must be present in the FIB. Additionally, the FIB may contain routes that are not in the routing table, but were automatically added by FortiGate, such as routes that are dynamically added to reach SSL VPN users.

Network Security Support Engineer 7.2 Study Guide

380

Routing

DO NOT REPRINT © FORTINET

The route cache contains recently used routing entries in a quick-to-search table. FortiGate consults the route cache before it consults the routing table, to speed up the routing lookup process.

Network Security Support Engineer 7.2 Study Guide

381

Routing

DO NOT REPRINT © FORTINET

FortiOS maintains a policy route table that you can view by running the diagnose firewall proute list command. There are three types of policy routes displayed in the policy route table: regular policy routes, ISDB routes, and SD-WAN rules. Follow these rules to identify each type of policy route in the table: •

Regular policy routes are assigned an ID no higher than 65535. In the output shown on this slide, the first entry is assigned ID 1, which makes it a regular policy route.

•

ISDB routes and SD-WAN rules are assigned an ID higher than 65535. However, SD-WAN rule entries include the vwl_service field, and ISDB route entries do not. The vwl_service field indicates the ID and the name of the rule from the SD-WAN configuration perspective. In the output shown on this slide, the second entry is an ISDB route and the third entry is an SD-WAN rule.

Note that although IDs for regular policy routes are in the 1 to 65535 range, the maximum number of regular policy routes that you can configure are much lower and varies among FortiGate models. For example, you can configure up to 512 regular policy routes on a FortiGate 300D. For more information about the maximum supported values per FortiGate model, refer to the FortiOS Maximum Values Table on docs.fortinet.com. Alternatively, you can run the print tablesize command on the FortiGate CLI to get the maximum values for your FortiGate.

Network Security Support Engineer 7.2 Study Guide

382

Routing

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned about advanced routing concepts and useful troubleshooting commands to debug routing issues.

Network Security Support Engineer 7.2 Study Guide

383

BGP

DO NOT REPRINT © FORTINET

In this lesson, you will learn about Border Gateway Protocol (BGP) and how to monitor it and troubleshoot common issues.

Network Security Support Engineer 7.2 Study Guide

384

BGP

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in BGP, you will be able to monitor and check the status of BGP communication, as well as troubleshoot the most common BGP issues.

Network Security Support Engineer 7.2 Study Guide

385

BGP

DO NOT REPRINT © FORTINET

In this section, you will briefly review BGP.

Network Security Support Engineer 7.2 Study Guide

386

BGP

DO NOT REPRINT © FORTINET

An autonomous system (AS) is a set of routers and networks under the same administration. Each AS is identified by a unique number, and usually runs an interior gateway protocol (IGP), such as OSPF or RIP.

Network Security Support Engineer 7.2 Study Guide

387

BGP

DO NOT REPRINT © FORTINET

A BGP speaker or peer is a router that sends and receives BGP routing information. The connection between two BGP peers is called a BGP session.

Network Security Support Engineer 7.2 Study Guide

388

BGP

DO NOT REPRINT © FORTINET

A BGP router stores routing information in three logical tables: • The RIB-in table contains all routing information received from other BGP routers before any filtering. • The local RIB table contains that same information after the filtering. • The RIB-out table contains the BGP routing information selected to advertise to other BGP routers.

Network Security Support Engineer 7.2 Study Guide

389

BGP

DO NOT REPRINT © FORTINET

This slide shows a flowchart that summarizes the BGP process. The BGP router stores the BGP routes it receives from other routers in the RIB-in table. The BGP router applies a filter, and the resulting routes are stored in the local RIB table. Then, the BGP router adds routes that were redistributed from the routing table, and applies another filter (outbound). The BGP router advertises the resulting routes.

Network Security Support Engineer 7.2 Study Guide

390

BGP

DO NOT REPRINT © FORTINET

BGP routes traffic based on AS paths. Each AS path includes attributes, which BGP uses to select the best route to each destination. One of the attributes is the AS list, which contains the ASs through which the traffic must pass to reach the destination.

Network Security Support Engineer 7.2 Study Guide

391

BGP

DO NOT REPRINT © FORTINET

There are four types of BGP attributes: • Well-known mandatory • Well-known discretionary • Optional transitive, which can be passed from one AS to another • Optional non-transitive, which can’t be passed from one AS to another This slide shows a list of the BGP attributes and their attribute types that FortiGate supports.

Network Security Support Engineer 7.2 Study Guide

392

BGP

DO NOT REPRINT © FORTINET

FortiGate uses some of the BGP attributes during the routing selection process. If all the attributes for multiple routes to the same destination match, and if ECMP is enabled, FortiGate shares the traffic among up to 10 BGP routes. If you don’t enable ECMP, FortiGate uses the route that goes to the router with the lowest BGP router ID.

Network Security Support Engineer 7.2 Study Guide

393

BGP

DO NOT REPRINT © FORTINET

In this section, you will learn about tools and tips for troubleshooting BGP.

Network Security Support Engineer 7.2 Study Guide

394

BGP

DO NOT REPRINT © FORTINET

This slide shows a flow chart of the BGP neighbor states and how they change: • Idle: Initial state • Connect: Waiting for a successful three-way TCP connection • Active: Unable to establish the TCP session • OpenSent: Waiting for an OPEN message from the peer • OpenConfirm: Waiting for the keepalive message from the peer • Established: Peers have successfully exchanged OPEN and keepalive messages

Network Security Support Engineer 7.2 Study Guide

395

BGP

DO NOT REPRINT © FORTINET

This slide shows the debug command you usually use first, to get an overview of the BGP status, and the status of all its neighbors. This slide shows the local router ID and AS. For each neighbor, the output also displays the following: • The AS • Packet counters • How long the neighbor has been up The last column is the neighbor state and number of prefixes. If the state is not established, this column displays the BGP state. If the state is established, this column displays the number of prefixes that the local FortiGate received from that neighbor.

Network Security Support Engineer 7.2 Study Guide

396

BGP

DO NOT REPRINT © FORTINET

You can use the command shown on this slide to get detailed information about each BGP neighbor. The information includes peer IP, peer router ID, remote AS, BGP state, various timers, and message counters.

Network Security Support Engineer 7.2 Study Guide

397

BGP

DO NOT REPRINT © FORTINET

The information also shows the number of prefixes announced and accepted, number of times that the session has dropped, and the last time it was reset.

Network Security Support Engineer 7.2 Study Guide

398

BGP

DO NOT REPRINT © FORTINET

This slide shows the command you can use to get details about the prefixes the local router is advertising. Status codes identifies codes associated with a routing entry. For each prefix, the command displays the following: • Next hop IP • Local preference • Weight • AS path

Network Security Support Engineer 7.2 Study Guide

399

BGP

DO NOT REPRINT © FORTINET

This slide shows the command you can use to display the routes advertised by a neighbor.

Network Security Support Engineer 7.2 Study Guide

400

BGP

DO NOT REPRINT © FORTINET

You can use the get router info bgp network command to display the BGP database. It lists all prefixes that all neighbors advertise, as well as the local router. Highlighted on this slide are also the origin codes used for the BGP table. i for IGP indicates the network command was used to advertise a route. This applies to the last route in the table, 10.20.30.0/24. All other advertised routes are tagged with the ? sign indicating the route was advertised from another routing protocol using redistribution. e for EGP is used only for legacy route advertisement and is rarely seen.

Network Security Support Engineer 7.2 Study Guide

401

BGP

DO NOT REPRINT © FORTINET

Now, FortiGate can log routing events, which enables you to get information that used to be available only when you ran the BGP real-time debug. By default, BGP event logging is enabled. You can disable BGP event logging by using the commands shown on this slide.

Network Security Support Engineer 7.2 Study Guide

402

BGP

DO NOT REPRINT © FORTINET

You can view BGP-related router events on the GUI. You can click any logged entry to view the details.

Network Security Support Engineer 7.2 Study Guide

403

BGP

DO NOT REPRINT © FORTINET

In this section, you will learn about common BGP issues and how to solve them.

Network Security Support Engineer 7.2 Study Guide

404

BGP

DO NOT REPRINT © FORTINET

Follow these steps to troubleshoot a BGP problem between two peers: • Check that the local router can reach the remote peer. • Ensure that TCP port 179 is not blocked between the peers. • Check the TCP session. • Check the BGP session. • If the BGP session is established, check the prefixes received and advertised by each peer.

Network Security Support Engineer 7.2 Study Guide

405

BGP

DO NOT REPRINT © FORTINET

This slide shows the commands you can use to enable and disable the BGP real-time debug. Note that this example enables debug output from event and level information.

Network Security Support Engineer 7.2 Study Guide

406

BGP

DO NOT REPRINT © FORTINET

One common issue is that there is no route to the BGP neighbor in the FortiOS FIB. If that is the case, the realtime BGP application debug will output the message shown on this slide: Sock Status: 113-No route to host. You can also verify this using the get router info bgp summary and get router info bgp neighbor commands. Both outputs show that the status is Active, meaning the TCP 3-way handshake could not be established. The solution is to ensure there is an active route to the IP address of the BGP neighbor.

Network Security Support Engineer 7.2 Study Guide

407

BGP

DO NOT REPRINT © FORTINET

This slide and the next slide show examples of real-time debug outputs from the successful establishment of a BGP session. In this example, the output shows when the session goes to the OpenSent state.

Network Security Support Engineer 7.2 Study Guide

408

BGP

DO NOT REPRINT © FORTINET

This slide shows the real-time debug output containing the OpenConfirm after the keepalive is received from the neighbor, as well as the establishment of the connection. The output also lists the prefixes FortiGate received after the BGP session is established.

Network Security Support Engineer 7.2 Study Guide

409

BGP

DO NOT REPRINT © FORTINET

The command shown on this slide is used to restart a BGP session between two peers. You can also use this command to run a BGP soft reset, which forces both peers to exchange their complete BGP routing tables.

Network Security Support Engineer 7.2 Study Guide

410

BGP

DO NOT REPRINT © FORTINET

In the troubleshooting example shown on this slide, FGT-A is not receiving the prefix that FGT-B advertised. The issue here is that the subnet mask of the prefix is misconfigured on FGT-B, prompting FortiOS to not advertise the network to other BGP peers.

Network Security Support Engineer 7.2 Study Guide

411

BGP

DO NOT REPRINT © FORTINET

There are two ways to fix the issue seen on the previous slide. The first way is to change the prefix manually to represent the network assigned to port3 on FGT-B. This is the recommended method. Changing the subnet mask from 255.255.0.0 to 255.255.255.0 allows FGT-B to advertise the prefix to its peers. Another option is to disable the set network-import-check. This is the safety mechanism that prevented FOS from advertising the falsely configured route. It is generally not recommended to disable this because it ensures only the correct networks are advertised to avoid routing issues.

Network Security Support Engineer 7.2 Study Guide

412

BGP

DO NOT REPRINT © FORTINET

In the scenario shown on this slide, FGT-A again does not receive the expected prefix from FGT-B. FGT-A has been configured with a prefix-list-in, which controls whether networks that neighbors advertise are accepted into the routing table.

Network Security Support Engineer 7.2 Study Guide

413

BGP

DO NOT REPRINT © FORTINET

A closer look into the prefix configuration reveals that any peer advertised network within the 172.16.0.0/16 subnet is not accepted into the BGP database.

Network Security Support Engineer 7.2 Study Guide

414

BGP

DO NOT REPRINT © FORTINET

The preferred solution is to add an additional rule, specifically allowing the 172.16.54.0 prefix in the same prefix-list. Unlike firewall policies, the list is not evaluated from the top-down. Every rule in the list is inspected.

Network Security Support Engineer 7.2 Study Guide

415

BGP

DO NOT REPRINT © FORTINET

After configuring the additional rule, the prefix is accepted and added into the BGP database.

Network Security Support Engineer 7.2 Study Guide

416

BGP

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson.

Network Security Support Engineer 7.2 Study Guide

417

OSPF

DO NOT REPRINT © FORTINET

In this lesson, you will learn about OSPF and how to monitor and troubleshoot it.

Network Security Support Engineer 7.2 Study Guide

418

OSPF

DO NOT REPRINT © FORTINET

After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in understanding OSPF, you will be able to understand, monitor, and troubleshoot OSPF.

Network Security Support Engineer 7.2 Study Guide

419

OSPF

DO NOT REPRINT © FORTINET

In this section, you will briefly review OSPF.

Network Security Support Engineer 7.2 Study Guide

420

OSPF

DO NOT REPRINT © FORTINET

With a link state protocol like OSPF, every router has a complete view of the network topology. Advantages of OSPF include scalability and fast convergence. Every 30 minutes, routers advertise their OSPF information again. Between these 30-minute intervals, routers send updates only if they detect topology changes. So, it is a relatively quiet protocol, as long as the network topology is stable. In large networks, using OSPF requires good planning and may be difficult to troubleshoot.

Network Security Support Engineer 7.2 Study Guide

421

OSPF

DO NOT REPRINT © FORTINET

Each router in the same area has identical and synchronized databases. You will learn about OSPF areas later in this lesson. An OSPF router uses the information in the LSDB and Dijkstra's algorithm to generate an OSPF tree, which contains the shortest path from the local router to each other router and network. This tree gives the best route to each destination, which is the information that OSPF can inject into the device routing table.

Network Security Support Engineer 7.2 Study Guide

422

OSPF

DO NOT REPRINT © FORTINET

LSAs contain the topology information that OSPF peers exchange. The LSDB of a router is populated with information from the local LSAs and all the LSAs received from other routers.

Network Security Support Engineer 7.2 Study Guide

423

OSPF

DO NOT REPRINT © FORTINET

A session between two OSPF peers is called an adjacency. This slide shows the initial interchange between two peers that are forming an adjacency. Any new adjacency goes through different states: Init, 2-way, ExStart, Exchange, Loading, and Full. The Full state indicates that the adjacency has successfully formed, and that both routers have identical copies of the LSDB.

Network Security Support Engineer 7.2 Study Guide

424

OSPF

DO NOT REPRINT © FORTINET

This slide lists the requirements for two peers to form an OSPF adjacency. If any of the requirements are not met, the adjacency fails and will not reach the Full state.

Network Security Support Engineer 7.2 Study Guide

425

OSPF

DO NOT REPRINT © FORTINET

In this section, you will learn the commands necessary for monitoring OSPF.

Network Security Support Engineer 7.2 Study Guide

426

OSPF

DO NOT REPRINT © FORTINET

The command shown on this slide provides detailed information about the OSPF process.

Network Security Support Engineer 7.2 Study Guide

427

OSPF

DO NOT REPRINT © FORTINET

The command on this slide shows information about each area the router belongs to.

Network Security Support Engineer 7.2 Study Guide

428

OSPF

DO NOT REPRINT © FORTINET

For OSPF information about each interface, use the command shown on this slide. It shows: • Network type, in this case broadcast multiaccess • If the interface is a DR or a BDR • DR and BDR IDs and IP addresses • Number of adjacencies and traffic statistics

Network Security Support Engineer 7.2 Study Guide

429

OSPF

DO NOT REPRINT © FORTINET

The command on this slide shows a summary of the statuses of all the OSPF neighbors. For each neighbor, it displays the adjacency state and whether the interface is a DR, a BDR, or neither (DROther). The response displays a dash after the state if the neighbor is in a point-to-point network.

Network Security Support Engineer 7.2 Study Guide

430

OSPF

DO NOT REPRINT © FORTINET

The command shown on this slide provides a summary of all the LSDB entries on FortiGate, ordered by LSA types. It shows the type 1 LSAs (router link states) first, then the type 2 LSAs (net link states).

Network Security Support Engineer 7.2 Study Guide

431

OSPF

DO NOT REPRINT © FORTINET

The command shown on this slide lists the LSAs that originated on the local FortiGate.

Network Security Support Engineer 7.2 Study Guide

432

OSPF

DO NOT REPRINT © FORTINET

Use the command shown on this slide to see details about type 1 LSAs.

Network Security Support Engineer 7.2 Study Guide

433

OSPF

DO NOT REPRINT © FORTINET

This slide shows a sample of more output from the command get router info ospf database router lsa.

Network Security Support Engineer 7.2 Study Guide

434

OSPF

DO NOT REPRINT © FORTINET

In this section, you will learn the tools and tips to troubleshoot OSPF issues.

Network Security Support Engineer 7.2 Study Guide

435

OSPF

DO NOT REPRINT © FORTINET

Follow these steps to troubleshoot an OSPF problem between two peers: • Check that the local router can reach the remote peer. IP addresses must be in the same subnet and have the same subnet mask. • Ensure that IP protocol 89 is not blocked. • Hello and Dead intervals must match. • The OSPF router ID for each peer must be unique. Duplicate router IDs are not allowed. • Do the MTUs match? • If authentication is enabled, the type and password must match on both sides.

Network Security Support Engineer 7.2 Study Guide

436

OSPF

DO NOT REPRINT © FORTINET

The OSPF real-time debug displays information about adjacency establishments and OSPF errors. It also shows information about network topology changes. You can enable the zl flag for the real-time debug to persist after a routing-process restart.

Network Security Support Engineer 7.2 Study Guide

437

OSPF

DO NOT REPRINT © FORTINET

This is a sample of output generated by the OSPF real-time debug. This sample shows the Hello packet being sent.

Network Security Support Engineer 7.2 Study Guide

438

OSPF

DO NOT REPRINT © FORTINET

This is another sample of output generated by the OSPF real-time debug. This sample shows the Hello packet being received.

Network Security Support Engineer 7.2 Study Guide

439

OSPF

DO NOT REPRINT © FORTINET

This slide shows a sample output of the OSPF real-time debug when adjacency fails. In this case, OSPF authentication fails. We can see the DR sending a Hello message with AuType 1, indicating authentication is configured and required for successful adjacency. In the received HELLO messages from the neighbor router, the AuType is 0. As such, the error message in the received HELLO indicates that there is an authentication type mismatch.

Network Security Support Engineer 7.2 Study Guide

440

OSPF

DO NOT REPRINT © FORTINET

This slide shows additional error messages that are helpful for troubleshooting common adjacency issues. Authentication error indicates that the authentication type is the same for both peers, but the passwords configured are not. A hello or dead interval timer mismatch can be confirmed by the error messages HelloInterval mismatch and RouterDeadInterval mismatch respectively. The error message: MTU size is too large, indicates an MTU mismatch.

Network Security Support Engineer 7.2 Study Guide

441

OSPF

DO NOT REPRINT © FORTINET

In the scenario shown on this slide, FGT-A is configured to redistribute all static routes. Note that default static routes are not advertised by default. In this case, only the 8.8.8.8/32 route is advertised.

Network Security Support Engineer 7.2 Study Guide

442

OSPF

DO NOT REPRINT © FORTINET

The routing table on FGT-B shows that the advertised route 8.8.8.8/32 is missing in the routing table. However, you can confirm that the route is being advertised successfully by looking at the LSDB using the command get router info ospf database brief. This also verifies successful OSPF adjacency between FGT-A and FGT-B.

Network Security Support Engineer 7.2 Study Guide

443

OSPF

DO NOT REPRINT © FORTINET

The issue in scenario 1 is that FGT-B is configured with a distribute-list-in that denies any subnet within the 8.8.8.0/24 network to be injected into the routing table. The distribute-list-in is configured under config router ospf. The list itself is configured under config router prefix-list.

Network Security Support Engineer 7.2 Study Guide

444

OSPF

DO NOT REPRINT © FORTINET

The recommended way to solve this is by adding another rule to the prefix list that applies to the OSPF configuration. In this case, the change is made to the Deny-8.8.8.0/24 prefix list. To have FortiOS inject the route from the LSDB into the routing table, you must add the subnet 8.8.8.8/32. Unlike firewall policies, the list is not evaluated from the top down. Every rule within the list is inspected.

Network Security Support Engineer 7.2 Study Guide

445

OSPF

DO NOT REPRINT © FORTINET

The routing table shown on this slide confirms that the advertised route from FGT-A has been successfully injected. You can also see that the distribution-list-in command has no impact on the LSDB.

Network Security Support Engineer 7.2 Study Guide

446

OSPF

DO NOT REPRINT © FORTINET

By default, FortiGate logs the most important OSPF routing events, such as: • Neighbor down or up • OSPF message exchange • Negotiation errors

Network Security Support Engineer 7.2 Study Guide

447

OSPF

DO NOT REPRINT © FORTINET

You can view OSPF-related router events on the GUI. You can click any logged entry to view the details.

Network Security Support Engineer 7.2 Study Guide

448

OSPF

DO NOT REPRINT © FORTINET

This slide shows the objectives that you covered in this lesson. By mastering the objectives covered in this lesson, you learned about OSPF concepts, and how to configure and troubleshoot OSPF.

Network Security Support Engineer 7.2 Study Guide

449

Solution Slides

DO NOT REPRINT © FORTINET

These slides contain the solutions to the troubleshooting exercises.

Network Security Support Engineer 7.2 Study Guide

450

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the traffic and session monitoring lab.

Network Security Support Engineer 7.2 Study Guide

451

Solution Slides

DO NOT REPRINT © FORTINET

There were four problems: • Unable to telnet to ISFW (10.1.10.254) • No Internet access • Unable to telnet to Linux-Router (100.64.1.254)

Network Security Support Engineer 7.2 Study Guide

452

Solution Slides

DO NOT REPRINT © FORTINET

In the first problem, packets were arriving to ISFW as verified with the sniffer command. However ISFW was not replying with the SYN/ACK packets.

Network Security Support Engineer 7.2 Study Guide

453

Solution Slides

DO NOT REPRINT © FORTINET

The next step was to use the debug flow, which showed the error iprope_in_check() check failed on policy 1, drop. As this is FortiGate management traffic, the problem could be one of the following: • The telnet service was not enabled in port3 • The telnet service was using a different port • The source IP address was not in the trusted host list • There was a local-in firewall configured to block telnet traffic

Network Security Support Engineer 7.2 Study Guide

454

Solution Slides

DO NOT REPRINT © FORTINET

The problem was actually a local-in policy blocking the telnet traffic. Removing that policy fixed the problem. If you tried to view the local-in policy on the GUI, you wouldn’t have seen the user created policy. You can only view them on the CLI.

Network Security Support Engineer 7.2 Study Guide

455

Solution Slides

DO NOT REPRINT © FORTINET

For the second problem, users were unable to access public websites. Attempts to connect to yahoo.com were failing, however you could still ping 8.8.8.8. This means that Client-10 does have Internet connectivity but it is having issues resolving domain names. We could confirm this by running a debug flow of the traffic to port 53 (DNS).

Network Security Support Engineer 7.2 Study Guide

456

Solution Slides

DO NOT REPRINT © FORTINET

The problem was that DNS traffic was not allowed in the firewall policies. Adding the DNS service to the firewall policy solved the problem.

Network Security Support Engineer 7.2 Study Guide

457

Solution Slides

DO NOT REPRINT © FORTINET

In the last problem, the sniffer of traffic to port 23 showed that the FortiGate was actually routing the SYN packets properly this time. However, the router was replying with RST packets. So, the problem was not on the FortiGate side, but on the server side.

Network Security Support Engineer 7.2 Study Guide

458

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the security fabric lab.

Network Security Support Engineer 7.2 Study Guide

459

Solution Slides

DO NOT REPRINT © FORTINET

There were three problems: 1. Unable to reach ISFW from NGFW-1 Solution: Enable or create policy on NGFW-2 to allow TCP port 8013 2. Security Fabric is not enabled on port4 on ISFW Solution: Enable Security Fabric for port4 on ISFW 3. NGFW-1 is not authorized Solution:NGFW-1 needs to be authorized on ISFW

Network Security Support Engineer 7.2 Study Guide

460

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the Authentication lab.

Network Security Support Engineer 7.2 Study Guide

461

Solution Slides

DO NOT REPRINT © FORTINET

There are two problems: 1. Why User Authentication request is not displayed? Solution: The LDAP “User” group is nor configured on Firewall Policy #1, that’s why the User Authentication request is not displayed. 2. Why FortiGate doesn’t forward an authentication request to the LDAP server? Solution: The password for the account student fails because there’s a local “student” user account, and FortiGate doesn’t forward an authentication request to the LDAP server. Remove the local “student” account.

Network Security Support Engineer 7.2 Study Guide

462

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the FSSO lab.

Network Security Support Engineer 7.2 Study Guide

463

Solution Slides

DO NOT REPRINT © FORTINET

The problem is that the user on Client-10 VM is unable to browse the internet. The FSSO user pushed by the script is on FSSO group AD_USERS. Firewall policy #1 has configured the Local User Group “Training” which is linked to the FSSO Group “Users”.

Solution: On local user group “Training”, replace the FSSO group “Users” with FSSO group “AD_Users”.

Network Security Support Engineer 7.2 Study Guide

464

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will look at the solutions for the troubleshooting exercises in the Security Profile lab.

Network Security Support Engineer 7.2 Study Guide

465

Solution Slides

DO NOT REPRINT © FORTINET

The first problem was that some users reported that www.eicar.org should be blocked because it belongs to the security risk category. However, the output of the web filtering real time debug showed that it belongs to a different category (Information Technology), which is allowed in the FortiGate configuration.

Network Security Support Engineer 7.2 Study Guide

466

Solution Slides

DO NOT REPRINT © FORTINET

The second problem was that ISFW was not blocking the FTP file transfer of an infected file. The debug flow was not showing the message sent to the application layer, which means that ISFW was actually not inspecting the traffic. The reason that this was not happening was because the FTP connection was using a nonstandard port—222. Switch the

Network Security Support Engineer 7.2 Study Guide

467

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the High Availability lab.

Network Security Support Engineer 7.2 Study Guide

468

Solution Slides

DO NOT REPRINT © FORTINET

The sniffer capture shows that Ethernet proto 0x8890 is flowing in one direction from NGFW-1 to NGFW-2. This is because, NGFW-2 has configured a customized “ha-eth-type”.

Solution: On NGFW-2 set setting “ha-eth-type” to default value “8890”

Network Security Support Engineer 7.2 Study Guide

469

Solution Slides

DO NOT REPRINT © FORTINET

The debug output from command diagnose debug application hatalk -1 on both FortiGate devices show a password mismatch issue: Solution: Configure a new password for the HA configuration on both FortiGate devices

Network Security Support Engineer 7.2 Study Guide

470

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will see the solutions for the troubleshooting exercise in the IPsec lab.

Network Security Support Engineer 7.2 Study Guide

471

Solution Slides

DO NOT REPRINT © FORTINET

The first problem was a misconfiguration in the phase 1. One side was configured with 3DES, the other side was configured with AES.

Network Security Support Engineer 7.2 Study Guide

472

Solution Slides

DO NOT REPRINT © FORTINET

The second problem was a mismatch in the pre-shared key.

Network Security Support Engineer 7.2 Study Guide

473

Solution Slides

DO NOT REPRINT © FORTINET

The third problem is that the sniffer shows that the ESP packets from Spoke-2 are not arriving at Spoke-1. So the most likely reason for this is that the ESP packets are being blocked or dropped in transit (Linux-Router).

Network Security Support Engineer 7.2 Study Guide

474

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will see the solutions for the troubleshooting exercise in the IPSec-IKEv2 lab.

Network Security Support Engineer 7.2 Study Guide

475

Solution Slides

DO NOT REPRINT © FORTINET

The first problem was a misconfiguration in the phase 1. One side was configured with 3DES, the other side was configured with AES.

Network Security Support Engineer 7.2 Study Guide

476

Solution Slides

DO NOT REPRINT © FORTINET

Status of Phase 1 will be shown as up, but Phase 2 as down. Solution: Under Phase 2 configure matching dhgrp setting

Network Security Support Engineer 7.2 Study Guide

477

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the routing lab.

Network Security Support Engineer 7.2 Study Guide

478

Solution Slides

DO NOT REPRINT © FORTINET

When the primary Internet link went down, the routing table changed. So, all the routing information was flushed from the affected sessions and traffic was routed to port2. When port1 came back up, all SNAT sessions continued using port2, because the port2 route was still valid and the interface was still up. Existing SNAT sessions would continue using port2 until they expire. There is a global setting that instructs FortiGate to reroute existing SNAT sessions upon any routing change, even for the cases where the old route is still up. You can enable the snat-route-change setting as shown on this slide.

Network Security Support Engineer 7.2 Study Guide

479

Solution Slides

DO NOT REPRINT © FORTINET

The default route configuration was not working as desired. The default route using port2 was inactive.

Network Security Support Engineer 7.2 Study Guide

480

Solution Slides

DO NOT REPRINT © FORTINET

The port2 default route’s distance was higher than the port1 default route. In order for both default routes to be active, they must have the same distance. Also, the port2 priority value was lower than port1 route’s priority value.

Network Security Support Engineer 7.2 Study Guide

481

Solution Slides

DO NOT REPRINT © FORTINET

Why was traffic to 100.64.3.1 taking port2? The debug flow showed the reason. There was a policy-based route overriding the static route configuration.

Network Security Support Engineer 7.2 Study Guide

482

Solution Slides

DO NOT REPRINT © FORTINET

Removing the policy-based route fixed the problem.

Network Security Support Engineer 7.2 Study Guide

483

Solution Slides

DO NOT REPRINT © FORTINET

Now, we will look at the solutions for the troubleshooting exercise in the BGP lab.

Network Security Support Engineer 7.2 Study Guide

484

Solution Slides

DO NOT REPRINT © FORTINET

The BGP neighbors were not coming up because NGFW-1 was configured with the remote AS 200, but the ISP AS is 100.

Network Security Support Engineer 7.2 Study Guide

485

Solution Slides

DO NOT REPRINT © FORTINET

Changing the remote AS number from 200 to 100 fixes the problem.

Network Security Support Engineer 7.2 Study Guide

486

Solution Slides

DO NOT REPRINT © FORTINET

The second problem is that NGFW-1 is receiving the prefix 8.8.8.8/32 through port2. This was causing all the traffic destined to 8.8.8.8 to be routed through port2 instead of port1.

Network Security Support Engineer 7.2 Study Guide

487

Solution Slides

DO NOT REPRINT © FORTINET

For this issue, the fix is in the hands of the ISP router's administrator. However, while the ISP fixes the problem, we used a prefix list to block the incoming advertisement to the subnet 8.8.8.8/32. Static route can also be used to configure 8.8.8.8/32 traffic to traverse port1.

Network Security Support Engineer 7.2 Study Guide

488

Solution Slides

DO NOT REPRINT © FORTINET

We will see the solutions for the troubleshooting exercise in the OSPF lab.

Network Security Support Engineer 7.2 Study Guide

489

Solution Slides

DO NOT REPRINT © FORTINET

The OSPF real time debug showed why the adjacency was not coming up. The Linux Server is using the router ID 0.0.0.2, which is also being used by DCFW.

Network Security Support Engineer 7.2 Study Guide

490

Solution Slides

DO NOT REPRINT © FORTINET

To solve this problem from the DCFW side, change the DCFW router ID from 0.0.0.2 to any other ID available.

Network Security Support Engineer 7.2 Study Guide

491

Solution Slides

DO NOT REPRINT © FORTINET

If you applied the fix on DCFW, you should see the Linux-Router (0.0.0.0.2) adjacency coming up.

Network Security Support Engineer 7.2 Study Guide

492

Solution Slides

DO NOT REPRINT © FORTINET

DCFW real-time debug is showing authentication type mis-match.

Network Security Support Engineer 7.2 Study Guide

493

Solution Slides

DO NOT REPRINT © FORTINET

To solve this problem from the DCFW side, delete or modify the interface configuration to require no authentication.

Network Security Support Engineer 7.2 Study Guide

494

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

In this lesson, you will review Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP) concepts.

Network Security Support Engineer 7.2 Study Guide

495

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

In this section, you will review OSPF concepts.

Network Security Support Engineer 7.2 Study Guide

496

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

With a link state protocol like OSPF, every router has a complete view of the network topology. Advantages of OSPF include scalability and fast convergence. Every 30 minutes, routers advertise their OSPF information again. Between these 30-minute intervals, routers send updates only if they detect topology changes.. So, it is a relatively quiet protocol, as long as the network topology is stable. In large networks, using OSPF requires good planning and may be difficult to troubleshoot.

Network Security Support Engineer 7.2 Study Guide

497

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

Each router in the same area has identical and synchronized databases. You will learn about OSPF areas later in this lesson. An OSPF router uses the information in the LSDB and Dijkstra's algorithm to generate an OSPF tree, which contains the shortest path from the local router to each other router and network. This tree gives the best route to each destination, which is the information that OSPF can inject into the device routing table.

Network Security Support Engineer 7.2 Study Guide

498

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

The topology information exchanged by OSPF peers is contained in LSAs. The LSDB of a router is populated with information from the local LSAs and all the LSAs received from other routers.

Network Security Support Engineer 7.2 Study Guide

499

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

If there are multiple OSPF routes to the same destination subnet, OSPF selects the route with the lowest cost. Each router interface is associated with an interface cost, which is usually related to how fast or preferable that interface is. An OSPF route cost is the sum of the costs of all interfaces to the final destination.

Network Security Support Engineer 7.2 Study Guide

500

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

This slide and the next slide explain how an OSPF router builds its OSPF tree. The initial information for each router is the locally connected networks, together with the OSPF cost for each interface. In the example shown on this slide, the router R2 has three locally connected subnets: subnet Net 1 with a cost of 2, subnet Net 2 with a cost of 3, and subnet Net 3 with a cost of 1. Router R1 has only one subnet connected: Net 1 with a cost of 2, and so on. Each router starts advertising its locally connected subnets by sending LSAs.

Network Security Support Engineer 7.2 Study Guide

501

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

OSPF routers use Dijkstra’s algorithm to determine the best route to each destination. The best routes can be represented as a tree with the local router at the root. Dijkstra’s algorithm is a recursive process that the router repeats multiple times until it finds the best routes. For example, this slide shows the OSPF tree for router R2. It indicates that the best route to Net 5 and Net 4 is through R3, and that Net 1, Net 2, and Net 3 are locally connected.

Network Security Support Engineer 7.2 Study Guide

502

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

You can segment an OSPF network into areas. Each area is identified by a unique number, which you can define in decimal or IP address formats.

Network Security Support Engineer 7.2 Study Guide

503

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

Each area has its own separate LSDB. All routers in the same area maintain an identical copy of the LSDB of an area. As you will learn in this lesson, a router can belong to more than one area. In those cases, the router maintains multiple LSDBs—one LSDB for each area connected to it. Segmenting big OSPF networks into areas reduces the sizes of the LSDB tables. Additionally, a topology change does not impact the whole network, but only the area where the change happens. Using OSPF areas requires good planning and may complicate the troubleshooting process.

Network Security Support Engineer 7.2 Study Guide

504

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

All OSPF networks must have at least one area—the backbone area. The backbone area is the core of the network, and all the other areas connect to it in a hub-and-spoke topology.

Network Security Support Engineer 7.2 Study Guide

505

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

An internal OSPF router has all its interfaces connected to the same area. So, it maintains only one LSDB. On the other hand, an ABR is connected to multiple areas, so it keeps multiple LSDBs. A backbone router has at least one interface connected to the backbone area. An ASBR redistributes non-OSPF routes into the OSPF network.

Network Security Support Engineer 7.2 Study Guide

506

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

This slide shows an example of each router type.

Network Security Support Engineer 7.2 Study Guide

507

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

There are three types of OSPF networks: • • •

Point-to-point networks contain only two peers, one at each end of a point-to-point link. Broadcast networks support more than two attached routers. They also support sending messages to multiple recipients (broadcasting). Point-to-multipoint networks support more than two attached routers. However, they do not support broadcasting.

Network Security Support Engineer 7.2 Study Guide

508

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

An OSPF session between two OSPF peers is called an adjacency. This slide shows the initial interchange between two peers that are forming an adjacency. Any new adjacency goes through different states: Init, 2-way, ExStart, Exchange, Loading, and Full. The Full state indicates that the adjacency has successfully formed, and both routers have identical copies of the LSDB.

Network Security Support Engineer 7.2 Study Guide

509

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

This slide lists the requirements for two peers to form an OSPF adjacency. If any of the requirements are not met, the adjacency fails and will not reach the Full state.

Network Security Support Engineer 7.2 Study Guide

510

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

In any multi-access network there is one DR and one BDR. The OSPF network elects the router with the highest priority as the DR. If two or more routers are tied with the highest priority, the network elects the router with the highest OSPF ID. The BDR monitors the DR status. If the DR fails, the BDR takes the DR role. Other routers form adjacencies only with the DR and BDR. The DR forwards the link state information from one router to another. This simplifies the number of adjacencies required in multi-access networks.

Network Security Support Engineer 7.2 Study Guide

511

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

This slide shows the multicast addresses that OSPF uses in broadcast multi-access, and point-to-point networks. Keep in mind that OSPF also uses unicast addresses for LSA retransmissions and database description packets.

Network Security Support Engineer 7.2 Study Guide

512

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

There are 11 LSA types. This lesson covers the following five most commonly used types: • Type 1 describes all the links connected to a router. • Type 2 describes all the routers (if more than one) in a multi-access network. • Type 3 describes the networks within an area (only generated by an ABR). • Type 4 describes the path to reach an ASBR. • Type 5 describes the external destinations originated by an ASBR. You will see examples of each of these five types in the next slides.

Network Security Support Engineer 7.2 Study Guide

513

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

Type 1 describes the networks connected to a router. They are advertised by all the routers in an area. Type 1 LSAs are not advertised outside the area where they originate.

Network Security Support Engineer 7.2 Study Guide

514

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

Only DRs advertise Type 2 LSAs. In the example shown on this slide, the area has two multi-access networks, each of them with one DR. The two DRs advertise type 2 LSAs, which contain information about the other routers connected to their multi-access networks.

Network Security Support Engineer 7.2 Study Guide

515

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

Type 3 LSAs contain summarized link state information. They are advertised only by ABRs. In the example shown on this slide, the ABR on the left sends type 3 LSAs to area 1. They contain link state information for the summarized subnets in areas 0 and 2. This same ABR also sends type 3 LSAs to the backbone area, with a summary of the subnets in area 1. Something similar happens with the ABR shown on the right side of the diagram. It sends type 3 LSAs to area 2. They contain link state information for the summarized subnets in areas 0 and 1. This same ABR also sends type 3 LSAs to the backbone area, with a summary of the subnets in area 2.

Network Security Support Engineer 7.2 Study Guide

516

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

An ASBR advertises itself by sending type 1 LSAs. These LSAs have the E-bit on in the OSPF header. Like any other type 1, the LSAs with the E-bit are confined to the area where they originate. However, ABRs in the same area send a type 4 LSA to the other areas with information about how to reach the ASBR. In the example shown on this slide, an ASBR that is redistributing RIP routes into OSPF announces itself by sending type 1 LSAs to the backbone area. The ABR receives that LSA and sends a type 4 LSA to area 1.

Network Security Support Engineer 7.2 Study Guide

517

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

The last type of LSA covered in this lesson is type 5. Type 5 LSAs are sent only by the ASBRs and are not confined to one area. They reach all the standard areas. They contain link state information for routes redistributed to OSPF (also called external routes). Note that all the area examples in this lesson are standard areas. There are also stub and not-so-stubby areas (NSSA), which are not covered in this lesson. Type 5 LSAs are not advertised to stub or NSSAs.

Network Security Support Engineer 7.2 Study Guide

518

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

Each external route is assigned a metric. There are two types of external-route metrics. A type 1 metric is the sum of the external cost plus the internal cost to reach the ASBR. A type 2 metric is only the external cost (the internal cost is not considered). If there are two external routes to the same destination, one type 1 and one type 2, an OSPF router selects the type 1 route over the type 2 route.

Network Security Support Engineer 7.2 Study Guide

519

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

In this section, you will review BGP concepts and how to configure BGP on FortiGate.

Network Security Support Engineer 7.2 Study Guide

520

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

An autonomous system (AS) is a set of routers and networks under the same administration. Each AS is identified by a unique number, and usually runs an interior gateway protocol, such as OSPF or RIP.

Network Security Support Engineer 7.2 Study Guide

521

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

BGP can serve one of two purposes: external BGP (EBGP) or internal BGP (IBGP). An exterior gateway protocol (EGP) exchanges routing information between ASs. BGP4, which runs in the internet, is the dominant EGP protocol today. EBGP is typically used when strict control is required over a large number of routes. Two EBGP routers exchange AS path information for destination prefixes or subnets. When two routers start an EBGP communication, the whole BGP routing table is exchanged. After that, only network updates are sent.

Network Security Support Engineer 7.2 Study Guide

522

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

A BGP speaker or peer is a router that sends and receives BGP routing information. The connection between two BGP peers is called a BGP session.

Network Security Support Engineer 7.2 Study Guide

523

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

There are three types of ASs: • A stub AS handles and routes local traffic only and has only one connection to another AS. One example is a company that is running BGP, and has its own AS number and one ISP connection. • Multihomed AS also handles and routes local traffic only, but it has multiple connections to different ASs. One example is a company that is running BGP, and has its own AS number and multiple ISP connections. • Transit AS handles and routes local traffic as well as traffic that originates and terminates in different ASs (transit traffic). An ISP is an example of a transit AS.

Network Security Support Engineer 7.2 Study Guide

524

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

When running IBGP, you usually need to configure full mesh peering between all the routers. In large networks, full mesh peering between routers can be difficult to administer and is not scalable. RRs help to reduce the number of IBGP sessions inside an AS. An RR forwards the routes learned from one peer to the other peers. If you configure RRs, you don’t need to create a full mesh IBGP network. RRs pass the routing updates to other RRs and border routers within the AS.

Network Security Support Engineer 7.2 Study Guide

525

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

In a BGP RR configuration, the AS is divided into different clusters that each include an RR and clients. The client routers communicate route updates only to the RR in the cluster. The RR communicates with other RRs and border routers. FortiGate can be configured as either an RR or a client.

Network Security Support Engineer 7.2 Study Guide

526

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

A BGP router stores routing information in three logical tables. The RIB-in table contains all routing information received from other BGP routers before any filtering. The local RIB table contains that same information after the filtering. The RIB-out table contains the BGP routing information selected to advertise to other BGP routers.

Network Security Support Engineer 7.2 Study Guide

527

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

This slide shows a flowchart that summarizes the BGP process. The BGP router stores the BGP routes it receives from other routers in the RIB-in table. The BGP router applies a filter, and the resulting routes are stored in the local RIB table. Then, the BGP router adds routes that were redistributed from the routing table, and applies another filter (outbound). The BGP router advertises the resulting routes.

Network Security Support Engineer 7.2 Study Guide

528

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

BGP routes traffic based on AS paths. Each AS path includes attributes, which BGP uses to select the best route to each destination. One of the attributes is the AS list, which contains the ASs through which the traffic must pass to reach the destination.

Network Security Support Engineer 7.2 Study Guide

529

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

There are four types of BGP attributes: • Well-known mandatory • Well-known discretionary • Optional transitive, which can be passed from one AS to another • Optional non-transitive, which can’t be passed from one AS to another This slide shows a list of the BGP attributes and their attribute types that FortiGate supports.

Network Security Support Engineer 7.2 Study Guide

530

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

FortiGate uses some of the BGP attributes during the routing selection process. If all the attributes for multiple routes to the same destination match, and if ECMP is enabled, FortiGate shares the traffic among up to 10 BGP routes. If you don’t enable ECMP, FortiGate uses the route that goes to the router with the lowest BGP router ID.

Network Security Support Engineer 7.2 Study Guide

531

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

There are three important things to consider when you implement BGP on FortiGate. First, there are no hardcoded limits. Limitations on the number of neighbors, routes, and policies depend exclusively on the available system memory. Second, by default, FortiGate doesn’t originate any prefix. You must enable redistribution, or manually indicate the prefixes that FortiGate originates. Third, by default, FortiGate accepts all the prefixes it receives. Optionally, you can filter out or modify some prefixes.

Network Security Support Engineer 7.2 Study Guide

532

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

By default, FortiGate BGP doesn’t advertise prefixes. You can use the redistribution command to configure FortiGate to advertise prefixes. You can redistribute connected and static routes, and routes learned from other routing protocols, into BGP. Optionally, you can add route maps to filter the prefixes or modify some of their BGP attributes.

Network Security Support Engineer 7.2 Study Guide

533

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

You can also use the network command to configure FortiGate BGP to advertise prefixes. However, an exact match of the prefix in the network command must be active in the routing table. If the routing table doesn’t contain an active route with a destination subnet that matches the prefix, FortiGate doesn’t advertise the prefix. You can change this behavior by disabling the network-import-check setting. After you disable the setting, FortiGate advertises all prefixes in the BGP network table, regardless of the active routes present in the routing table.

Network Security Support Engineer 7.2 Study Guide

534

Dynamic Routing Supplement

DO NOT REPRINT © FORTINET

By default, the subnets under the config network command, and the subnets redistributed from other routing protocols, are advertised to all the neighbors. With a prefix list, you can be more selective about which prefixes to advertise to each neighbor. Additionally, prefix lists allow you to select which prefixes you want to use from each neighbor. This example shows a prefix list that allows the prefix 10.0.0.0/8, but blocks the prefix 10.1.0.0/16. By default, all traffic that does not match a prefix list is denied. The prefix list is applied in the incoming direction from the neighbor 10.3.1.254. The local FortiGate applies this filter for all prefix advertisements coming from 10.3.1.254. When applying a prefix list, all the prefixes that don’t match an entry in the list are denied by default.

Network Security Support Engineer 7.2 Study Guide

535

DO NOT REPRINT © FORTINET

No part of this publication may be reproduced in any form or by any means or used to make any derivative such as translation, transformation, or adaptation without permission from Fortinet Inc., as stipulated by the United States Copyright Act of 1976. Copyright© 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.