FortiGate, like other systems implementing Public Key Infrastructure (PKI), builds and validates certificate chains by linking a certificate to its issuer. This is primarily achieved using the Authority Key Identifier (AKI) and Subject Key Identifier (SKI) extensions. The AKI extension within a signed certificate contains a value that matches the SKI value of the issuing Certificate Authority's (CA) certificate. This direct correspondence allows FortiGate to unambiguously identify the specific issuer certificate and key used for signing, which is essential for constructing the correct chain of trust.

B. S/MIME Capabilities value: This extension is specific to the S/MIME standard and describes the cryptographic capabilities of an email client, not the issuer-subject relationship in a certificate chain.

C. Subject value: The Subject field identifies the entity to whom the certificate is issued. While the Issuer field of this certificate must match the Subject field of the CA's certificate, the SKI provides a more precise link to the specific key used.

D. Subject Alternative Name value: This extension lists additional identities (like hostnames or IP addresses) for the certificate's subject, but it does not provide any information about the certificate's issuer.

1. Fortinet FortiOS 7.0.1 Handbook - Public Key Infrastructure: In the "Certificate verification" section

it states

"The Authority Key Identifier (AKI) extension in a certificate points to the Subject Key Identifier (SKI) of the certificate that signed it. This allows the FortiGate to build the certificate chain of trust." (p. 21).

2. IETF RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile:

Section 4.2.1.1

"Authority Key Identifier

" explains that this extension identifies the public key used to sign a certificate

typically by referencing the issuer's Subject Key Identifier.

Section 4.2.1.2

"Subject Key Identifier

" defines this extension as a means of identifying certificates that contain a particular public key

which is then referenced by the AKI of certificates it issues.

FortiGate is a stateful firewall that establishes a session for new connections. A route lookup is performed on the first packet from the session originator to determine the egress interface and next-hop gateway for the forward path. This information is then stored in a new session table entry. Subsequently, when the first reply packet is received from the responder, a second route lookup is performed for the original source IP address (which is the destination for the reply packet). This confirms the return path and fully populates the session table. All subsequent packets for that session are processed quickly using the established session information, without requiring additional route lookups.

B. A route lookup is not performed on the last packet; forwarding is based on the already established session table entry.

C. This describes stateless behavior. FortiGate is stateful and uses a session table to avoid resource-intensive lookups for every packet.

1. Fortinet. (2024). FortiGate / FortiOS 7.0.12 / Administration Guide. Fortinet Document Library. In the "Firewall" chapter

section "Life of a packet"

the "New session" subsection states: "The FortiGate then does a route lookup to determine the egress interface that it can use to forward the packet to its destination." This directly supports the lookup on the first packet from the originator.

2. Fortinet. (2021). FortiOS Handbook - Firewall for FortiOS 7.0.0. Fortinet Document Library. On page 10

under "Packet flow and session management"

the text confirms the process for the initial packet: "When the first packet of a new session arrives...the FortiGate performs a route lookup for the destination address to find the egress interface."

3. The route lookup on the first reply packet is a fundamental aspect of establishing the bidirectional session state. The FortiGate must determine the return path to the originator. This principle is a core component of the official Fortinet Certified Professional (FCP) curriculum

which explains that the session table stores information for both directions of traffic

and this information is populated by lookups on the initial and reply packets.

The antivirus profile successfully blocks the EICAR test file over unencrypted HTTP, which confirms that the antivirus engine and its definitions are functioning correctly. The failure to detect the virus when downloaded over encrypted HTTPS indicates that the FortiGate is not decrypting the traffic to inspect its content. For FortiGate to apply security profiles like Antivirus to encrypted traffic, the SSL/SSH Inspection profile must be configured for 'deep-inspection'. The described behavior suggests the profile is either not applied or is incorrectly set to 'certificate-inspection', which only examines the server certificate but does not decrypt and inspect the traffic payload.

A. Application control is not enabled: Application control is used to identify and manage applications; it is not the primary feature responsible for decrypting and scanning encrypted content for viruses.

C. Antivirus profile configuration is incorrect: The antivirus profile is proven to be working correctly because it successfully blocks the EICAR file over HTTP.

D. Antivirus definitions are not up to date: The antivirus definitions are effective, as demonstrated by the successful detection and blocking of the EICAR file in the unencrypted HTTP download.

---

1. Fortinet FortiOS 7.0.0 Administration Guide

Security Profiles > SSL/SSH Inspection

Page 1138.

The guide states: "Deep inspection... allows FortiGate to inspect the content of secure traffic... This allows FortiGate to enforce security features such as... Antivirus

Web Filtering

and DLP." This confirms that deep inspection is required for the antivirus profile to function on HTTPS traffic.

2. Fortinet FortiOS 7.0.0 Security Profiles Guide

SSL/SSH Inspection

Page 10.

This document explicitly differentiates the inspection modes: "Certificate Inspection... The content of the packet is not inspected... Deep Inspection... The content of the packet is inspected by FortiGuard and other security profiles." This directly supports the conclusion that the failure to inspect content is due to the SSL/SSH inspection mode.

The FortiOS Intrusion Prevention System (IPS) engine is a core component that performs pattern matching and protocol decoding for multiple security functions, especially in flow-based inspection mode. Application control is fundamentally built on the IPS engine, using its decoders and signature-matching capabilities to identify application traffic. Similarly, when operating in flow-based mode, both the web filter and antivirus features leverage the high-performance IPS engine to scan traffic content for threats and policy violations without the need for full proxying, enabling faster throughput.

C. DNS filter: This feature is primarily handled by a dedicated daemon (dnsfilterd) and process, which is distinct from the core IPS engine used for general signature matching.

D. Web application firewall: The WAF feature on a FortiGate uses its own specialized engine for deep inspection of HTTP/S traffic and protection against web application attacks, separate from the IPS engine.

1. Fortinet FortiOS 7.0.0 Administration Guide: In the "Security Profiles" section

under "Application Control

" it is stated that "Application control uses IPS protocol decoders and signatures to identify the applications that generate network traffic." (p. 689).

2. Fortinet FortiOS 7.0.0 Handbook - Architecture: The "Life of a Packet" chapter details the packet flow. In the flow-based inspection path

the diagram and accompanying text show that the ipsengine is responsible for processing IPS

Application Control

flow-based Web Filtering

and flow-based Antivirus. (Section: "Flow-based inspection").

3. Fortinet FortiOS 7.0.0 Handbook - Security Profiles: The "Antivirus" chapter explains

"In flow-based inspection

the FortiGate uses the IPS engine to scan content as it passes through the FortiGate without any buffering." This same principle is described for flow-based Web Filtering. (Section: "Inspection modes").

When a FortiGate is configured in transparent mode, it functions as a Layer 2 bridge or switch. By default, all physical interfaces are placed into a single virtual switch, effectively making them part of the same broadcast domain. In this mode, the FortiGate inspects and forwards Ethernet frames based on their destination MAC address. It does not modify the source or destination MAC addresses of the original frames as they pass through, making its presence on the network "transparent" to other devices. This allows the FortiGate to be inserted into an existing network without requiring any changes to the IP addressing scheme.

B. The primary advantage of transparent mode is that it can be deployed without altering the existing network's IP address schema, making this statement false.

C. Transparent mode operates at Layer 2, forwarding frames based on a MAC address table. Static routes, a Layer 3 concept, are not required for traffic forwarding through the device.

1. FortiOS Administration Guide 7.0.0

System > Operation Mode > Transparent mode

Page 218: "In Transparent mode

the FortiGate is installed between the internal network and the router. In this mode

the FortiGate acts as a transparent bridge

forwarding frames without modifying the MAC addresses." This directly supports option D.

2. FortiOS Administration Guide 7.0.0

System > Operation Mode > Transparent mode

Page 218: "When you install a FortiGate in Transparent mode

you do not have to change the IP addresses of the computers on the private network." This directly refutes option B.

3. FortiOS Administration Guide 7.0.0

System > Operation Mode > Example: Transparent mode

Page 220: "When you change the operating mode to Transparent

the FortiGate configuration is reset and the FortiGate restarts. All physical interfaces are now part of the default virtual switch

root." This supports option A

as a virtual switch groups interfaces into a single broadcast domain.

4. FortiOS Administration Guide 7.0.0

System > Operation Mode > Transparent mode

Page 218: "The FortiGate unit functions like a bridge

and traffic is not routed." This refutes the premise of option C

which implies Layer 3 routing is the primary forwarding mechanism.

In FortiOS, the Internet Service Database (ISDB) objects are treated as a special category within firewall policies. Due to their dynamic nature and complex definitions (which can include multiple IP addresses, ports, and protocols), they cannot be combined with other object types like IP addresses, FQDNs, or user groups within the same source or destination field. When an Internet Service is selected, the policy matching engine is dedicated to that specific object type for that field, and the GUI/CLI prevents the addition of any other objects to maintain policy integrity and avoid matching conflicts.

A. IP address: An IP address object is a standard address type and cannot be added to the source field once an Internet Service object has been selected. C. User or User Group: User and User Group objects are used for identity-based policies and cannot be mixed with Internet Service objects in the source field. D. FQDN address: An FQDN address object is another type of standard address object and is not permitted in the source field alongside an Internet Service object.

1. Fortinet FortiOS 7.4.0 Administration Guide: In the section describing firewall policy components, it explicitly states the limitation. "When an Internet Service is selected as the source or destination in a firewall policy, other types of addresses cannot be added." (See FortiOS Administration Guide 7.4.0, Page 818, "Firewall policies > Internet Service").

2. Fortinet FortiOS 7.2.0 Administration Guide: This behavior is consistent across versions. The guide notes, "When an Internet Service is selected as the source or destination in a firewall policy, other types of addresses cannot be added." (See FortiOS Administration Guide 7.2.0, Page 778, "Firewall policies > Internet Service").

3. Fortinet Cookbook: In a recipe detailing the use of the Internet Service Database, the configuration steps and notes reinforce this rule. "Note that you cannot add any other addresses to the policy when using an Internet Service." (See Fortinet Cookbook, "Internet Service Database (ISDB)", Version 7.4.0, Configuration section).

The FortiGate sniffer command diagnose sniffer packet any '...' 4 0 l uses verbosity level 4. According to the FortiOS Command Line Interface (CLI) Reference, verbosity level 4 is defined to "print header of packets with interface name."

The exhibit's output confirms this:

1. Interface name (A): The line begins with port1 out, explicitly showing the interface.

2. IP header (C): The summary line 10.0.1.254 -> 10.0.1.10 icmp: echo request contains information parsed from the IP and ICMP headers.

3. Ethernet header (B): The hexadecimal dump below the summary line displays the raw packet data, which starts with the Layer 2 Ethernet header (containing source and destination MAC addresses).

Therefore, all three are present in the output.

D. Application header: The sniffer does not parse or explicitly display application (Layer 7) headers in this mode. The protocol shown, ICMP, operates at the network layer.

E. Packet payload: Verbosity level 4 is specified to show only packet headers. While the payload is present within the raw hexadecimal dump, levels designed to show payload data (e.g., 2, 5, 6) also include an ASCII representation, which is absent here.

1. Fortinet FortiOS 7.4.0 CLI Reference: In the diagnose sniffer packet command documentation

the description for verbosity level 4 is "print header of packets with interface name." This supports that the primary information displayed includes headers and the interface name. (FortiOS 7.4.0 CLI Reference

p. 1985).

2. FortiGate Infrastructure 7.4 Study Guide: The troubleshooting chapter explains packet sniffing. It clarifies the verbosity levels

stating that level 4 adds the interface name to the header information provided by level 1. The guide distinguishes header-only levels (1

4) from levels that also display data/payload (2

3

5

6). (FortiGate Infrastructure 7.4 Study Guide

"Troubleshooting" chapter

section "Packet Sniffer").

3. Fortinet Document Library: The technical article "Troubleshooting Tip: Using the FortiOS built-in packet sniffer" details the output for each verbosity level. It shows that the hex dump is included in level 4

but the descriptive text emphasizes that its purpose is to display headers

contrasting with levels that are meant to display "header and data". (Document ID: FD33742).

In an IPsec VPN, the Internet Key Exchange (IKE) protocol establishes Security Associations (SAs). The Phase 1 SA (IKE SA) is a single, bidirectional channel created to authenticate the peers and secure the negotiation of the Phase 2 SAs. The Phase 2 SAs (IPsec SAs) are unidirectional and are used to apply security services, such as encryption and authentication via ESP or AH, to the actual data traffic flowing through the tunnel. To ensure security, Phase 2 SAs have a finite lifetime, which can be configured to expire based on a set time duration, a specific volume of processed data, or whichever of these two limits is reached first.

B. An SA never expires.

This is incorrect. All SAs have a defined lifetime (time or volume-based) to force re-keying, which is a critical security practice to limit the impact of a compromised key.

E. Both the phase 1 SA and phase 2 SA are bidirectional.

This is incorrect. The Phase 1 (IKE) SA is bidirectional, but the Phase 2 (IPsec) SAs are unidirectional. Two Phase 2 SAs are required for bidirectional data communication.

1. Fortinet FortiOS 7.0 Administration Guide:

In the "IPsec VPN concepts > IKE and IPsec > Phase 1 and Phase 2" section

it states: "The IKE SA is a bidirectional secure channel... The purpose of IKE phase 2 is to negotiate IPsec SAs to set up the IPsec tunnel. The IPsec SAs are unidirectional... The IPsec SAs handle the encryption and decryption of traffic in the IPsec tunnel." This supports options A and C.

In the "IPsec VPN concepts > IKE and IPsec > Phase 2 settings" section

it details lifetime settings: "You can define the SA lifetime in seconds

in kilobytes of data processed

or both. The SA expires when one of these values is reached." This supports option D and refutes B.

2. RFC 4301

Security Architecture for the Internet Protocol:

Section 4.1

"Security Associations": "An SA is unidirectional. That is

it is a security relationship that applies to traffic in one direction... For peer-to-peer communication

two SAs are required

one in each direction." This confirms the unidirectional nature of IPsec (Phase 2) SAs

supporting option C and refuting E.

3. RFC 7296

Internet Key Exchange Protocol Version 2 (IKEv2):

Section 1.2

"The IKESA": "An IKESA is a bidirectional entity that is created as the result of an IKESAINIT exchange... All IKE messages are protected by an IKESA." This confirms the bidirectional nature of the IKE (Phase 1) SA

supporting option C.

According to the FortiOS packet processing order, also known as the "Life of a Packet," Denial of Service (DoS) policy checks are performed at the very beginning of the packet flow. This happens immediately after the packet is received on the ingress interface and before a session is created. Intrusion Prevention System (IPS) scanning, which evaluates signatures and filters, occurs much later in the process, after a firewall policy has accepted the traffic and a session has been established. Therefore, the ipsrcsession anomaly defined in the DoS policy is the first item to be evaluated by FortiGate.

A. SMTP.Login.Brute.Force: This is an IPS signature, which is evaluated by the IPS engine after the DoS policy check and session establishment. B. IMAP.Login.brute.Force: This is an IPS signature, which is processed later in the packet flow by the IPS engine, not before the DoS policy. D. Location: server Protocol: SMTP: This is an IPS filter used to apply specific signatures. It is part of the IPS engine's logic, which runs after the DoS policy.

1. Fortinet FortiOS 7.4.0 Administration Guide, Packet flow and security profiles > Life of a packet, Page 1031. The packet flow diagram and description clearly show that the dos-policy check occurs at the ingress stage, well before session setup and the application of security profiles like IPS (ipsscan).

2. Fortinet FortiOS 7.4.0 Administration Guide, Security Profiles > DoS Protection, Page 568. This section explains that DoS policies are designed to "protect the FortiGate unit from denial of service attacks" by inspecting traffic before it is processed by the CPU, confirming its early position in the packet flow.

When a FortiGate unit is set to split VDOM mode, the system automatically partitions its resources into two predefined Virtual Domains (VDOMs). The root VDOM is created specifically for management purposes, isolating administrative traffic and typically containing only the dedicated management interfaces. Concurrently, a second VDOM named FG-traffic is created to handle all data plane traffic, and all non-management interfaces are moved into this VDOM. This architecture enhances security by separating network management from general network traffic.

B. Mgmt: This is not a default VDOM name. The management VDOM is named root by default in split VDOM mode.

C. FG-Mgmt: This is not a default VDOM name created by FortiGate in split VDOM mode.

1. Fortinet. (2023). FortiOS Administration Guide 7.4.0. Fortinet Document Library. In the "System > VDOMs > Split VDOM mode" section

it states

"When split VDOM mode is enabled

two VDOMs are created: root and FG-traffic. The root VDOM is the management VDOM and contains only the management interfaces. All remaining interfaces are in the FG-traffic VDOM."

2. Fortinet. (2022). FortiGate Infrastructure 7.2 Study Guide. Fortinet Training Institute. Page 318

under the "Split VDOM Mode" heading

specifies

"When split VDOM mode is enabled

two VDOMs are created: root and FG-traffic."