FCSS_EFW_AD-7.6 Practice Questions

The exhibit shows a FortiGate connected to a pair of FortiSwitch devices using a single logical interface. This topology represents a Multi-Chassis Link Aggregation (MCLAG) configuration, which provides link and device redundancy.

To connect to an MCLAG peer group, the FortiGate must use a Link Aggregation Group (LAG) interface, which is standardized as IEEE 802.3ad. This bundles the physical links to each switch into one logical interface.

This integrated deployment is managed using FortiLink, where the 802.3ad aggregate interface on the FortiGate is configured as the FortiLink interface. This allows the FortiGate to act as the switch controller, centrally managing the FortiSwitch units and provisioning VLANs across the switched network.

A. MCLAG is specifically designed to provide a loop-free, active-active topology, making Spanning Tree Protocol (STP) on the aggregate links unnecessary.

D. SD-WAN is a feature for aggregating and managing multiple Wide Area Network (WAN) links for internet and private network access, not for LAN-side switch connectivity.

1. FortiSwitch—Managed by FortiOS 7.4.0

Administration Guide

Page 51

Section: "FortiLink split interface and MCLAG".

The documentation states: "On the FortiGate unit

you create an 802.3ad aggregate interface with at least two member interfaces." This directly supports that an 802.3ad interface type is required (Answer B).

The same section describes this exact topology as a FortiLink configuration for managing an MCLAG peer group

which includes VLAN management (Answer C).

2. FortiSwitchOS 7.4.0

Administration Guide

Page 183

Section: "Configuring MCLAG".

The guide explains: "MCLAG provides Layer-2 redundancy by preventing the spanning-tree protocol (STP) from blocking the redundant links between the MCLAG peer group and the client network device." This confirms that STP is not the required loop-prevention mechanism (Refutes Answer A).

3. FortiOS 7.4.0

Administration Guide

Page 1789

Section: "SD-WAN".

The guide defines SD-WAN: "SD-WAN simplifies the management of multiple WAN connections...". This confirms SD-WAN is a WAN technology

not used for LAN switch connections (Refutes Answer D).

The core issue is that FortiGate cannot inspect the content of encrypted HTTPS traffic by default. Standard certificate inspection only verifies the server's certificate and uses the Server Name Indication (SNI) for web filtering, but it does not decrypt the traffic payload. To detect malware hidden within an encrypted session, FortiGate must perform deep inspection. Enabling full SSL inspection configures the FortiGate to act as a "man-in-the-middle," decrypting the traffic, applying security profiles (like Antivirus and IPS) to the plaintext content, and then re-encrypting it before forwarding it to the user. This is the only method that allows FortiGate to analyze the actual data being transferred for threats.

A. This option uses FortiGuard ratings for web filtering but does not decrypt and inspect the traffic's content. A reputable website can be compromised to serve malware, which this method would miss.

B. Certificate inspection already uses SNI to identify the website for policy matching. This does not enable payload inspection, which is necessary to find malware within the encrypted stream.

C. DNS over TLS secures DNS queries to prevent spoofing and eavesdropping. It does not provide any mechanism for inspecting the content of the subsequent HTTPS session where the malware resides.

1. FortiGate Security 7.0 Study Guide

p. 119: "Full SSL inspection

also known as deep inspection

is a more advanced and resource-intensive method of SSL inspection. FortiGate impersonates the recipient of the originating SSL session

and then decrypts and inspects the content... Full SSL inspection allows FortiGate to apply security features

such as antivirus

web filtering

and data leak prevention

to encrypted traffic." This directly states that full inspection is required to apply security features like antivirus to encrypted traffic.

2. FortiOS 7.0.0 Administration Guide

Security Profiles > SSL/SSH Inspection > SSL/SSH Inspection

Section: Inspection modes: "Full SSL inspection (or deep inspection) involves the FortiGate unit becoming a man-in-the-middle... This allows the FortiGate to decrypt the traffic to scan it for threats

and then re-encrypt it before sending it to its destination." This confirms that decryption for threat scanning is the purpose of full inspection.

3. FortiOS 7.0.0 Administration Guide

Security Profiles > SSL/SSH Inspection > SSL/SSH Inspection

Section: Inspection modes: "In certificate inspection mode

the FortiGate unit only inspects the SSL certificate... FortiGate can only apply security features that do not require inspection of the traffic's payload

such as web filtering by SNI." This explains why the administrator's initial configuration failed to detect the malware.

The NP7 (Network Processor 7) is a specialized System-on-a-Chip (SoC) designed by Fortinet to accelerate network-intensive tasks. Its functions include offloading traffic from the main CPU for operations such as routing, NAT, and handling various tunneling protocols. Specifically, the NP7 processor provides hardware acceleration for VXLAN encapsulation and decapsulation, which significantly improves performance and throughput in environments that heavily utilize VXLAN for network virtualization.

B. SP5: The SP5 (Security Processor 5) is designed for cryptographic acceleration, primarily offloading IPsec and SSL VPN encryption and decryption, not network tunneling protocols like VXLAN.

C. СР9: The CP9 (Content Processor 9) accelerates content-level security inspection, such as Intrusion Prevention System (IPS), antivirus (AV) scanning, and SSL/TLS deep inspection.

D. NTurbo: NTurbo is a feature that offloads firewall sessions to network processors (like the NP7). It is not the hardware itself but rather a mechanism that utilizes the NP hardware.

1. Fortinet Document Library

FortiOS 7.4.0

Hardware Acceleration Guide:

Section: "NP7 processors" -> "NP7 features". This section explicitly lists "VXLAN and GENEVE tunneling" as a feature offloaded by the NP7 processor.

Section: "SP5 processors". This section details that SP5 processors accelerate IPsec encryption and decryption.

Section: "CP9 processors". This section describes the CP9's role in offloading flow-based and proxy-based content inspection.

Section: "NTurbo". This section defines NTurbo as a feature for offloading firewall sessions to network processors

confirming it is not the hardware component itself.

The Fortinet Internet Service Database (ISDB) is a feature that simplifies firewall policy creation by grouping all IP addresses, protocols, and port numbers associated with a specific internet service (like Microsoft 365 or Google Services). FortiGuard Labs continuously maintains and updates this database, which the FortiGate downloads. When an ISDB object is used in a firewall policy with a 'deny' action, the FortiGate blocks traffic at OSI Layers 3 (IP addresses) and 4 (TCP/UDP ports) that matches the entries in the database for that specific service. This provides an efficient way to control access without manually tracking all of a service's network endpoints.

C. The ISDB is a database of network endpoints, not an inspection mode. It can be used in firewall policies operating in either flow or proxy mode; it is not exclusive to proxy mode.

D. Limiting access by URL and domain is a Layer 7 function performed by the Web Filter security profile, not the ISDB, which operates primarily at Layers 3 and 4.

1. FortiOS 7.4.0 Administration Guide

Page 1010

Section: Internet Service Database.

"The FortiGuard Internet Service Database is a comprehensive

up-to-date list of all public IP addresses used by popular internet services... Each Internet Service can contain multiple entries

and each entry consists of an IP address or range

and a protocol and port number." This statement directly supports options A and B by defining the ISDB as a list of IPs and ports provided by FortiGuard.

2. FortiOS 7.4.0 Administration Guide

Page 1011

Section: Internet Service Database.

"When an Internet Service is selected as the source or destination in a firewall policy

traffic matching any of the IP addresses and port numbers in the service will have the policy's action applied to it." This confirms that the ISDB's mechanism is to match and block (or allow) based on the predefined IP addresses and ports (Layers 3 and 4).

3. FortiOS 7.4.0 Administration Guide

Page 1178

Section: Web filter.

"The web filter security profile can inspect HTTP

HTTPS

and FTP traffic... You can configure the web filter profile to block or allow access to web sites by matching their URLs against lists of URLs..." This clearly distinguishes the function of Web Filtering (URL/domain-based) from the ISDB (IP/port-based)

invalidating option D.

To establish an eBGP session using loopback interfaces, two specific configurations are required. First, the update-source command must be used to change the source IP address of the BGP packets from the physical egress interface to the loopback interface's IP address.

Second, by default, eBGP peers are expected to be directly connected (TTL=1), a rule enforced by ebgp-enforce-multihop. Since loopback interfaces are not physically connected, this enforcement must be disabled (set ebgp-enforce-multihop disable) to allow the BGP session to establish between these non-adjacent IP addresses.

ibgp-enforce-multihop: This command applies to internal BGP (iBGP) sessions within the same autonomous system, not to an external (eBGP) session with an ISP.

recursive-next-hop: This setting relates to the resolution of the next-hop attribute in BGP route advertisements, not the establishment of the BGP peering session itself.

1. FortiOS 7.6.0 CLI Reference

config router bgp section

page 1789.

update-source : "Enable/disable use of the interface as the source IP address of BGP connections." This confirms the need to specify the loopback interface.

ebgp-enforce-multihop {enable | disable}: "Enable/disable enforcement of single-hop for EBGP neighbors." The default is enable. This confirms the need to disable this setting for loopback peering.

2. Fortinet Cookbook

"eBGP configuration using loopback interfaces" recipe.

This guide explicitly details the configuration steps for establishing an eBGP session using loopback interfaces

stating: "On both routers

it is necessary to configure set update-source to use the loopback interface as the source of the BGP traffic

and set ebgp-multihop enable [or set ebgp-enforce-multihop disable in modern FortiOS] because the peer is not directly connected."

In an ADVPN configuration that uses both iBGP and eBGP, specific BGP settings are required on the hub FortiGate.

1. set next-hop-self enable: This command is essential for the iBGP peering between the hub and its spokes. The hub acts as a route reflector. When it receives routes from one spoke, it must advertise them to other spokes with itself as the next hop. This action is the trigger for the spokes to initiate the on-demand shortcut tunnel.

2. set ebgp-enforce-multihop enable: This command is required for the eBGP peering. By default, eBGP peers must be directly connected. In a WAN or VPN environment, eBGP peers are typically multiple network hops apart. This setting allows the BGP session to be established between peers that are not on the same subnet.

C. set ibgp-enforce-multihop advpn: iBGP peers are not required to be directly connected by default, so enforcing multihop is generally unnecessary. The advpn keyword for this command is not a standard configuration for this scenario.

D. set attribute-unchanged next-hop: This command would prevent the hub from changing the next-hop attribute, which is the opposite of the required behavior. It would break the ADVPN shortcut mechanism.

1. Fortinet FortiOS 7.4.0 Administration Guide

VPN > IPsec VPN > Auto-Discovery VPN (ADVPN) > BGP configuration for the hub.

This section explicitly shows the command set next-hop-self enable as a required part of the iBGP neighbor group configuration on the hub. It states

"The hub must be configured as a route reflector for iBGP."

2. Fortinet FortiOS 7.4.0 Administration Guide

Routing > BGP > BGP concepts > eBGP multihop.

The documentation states: "By default

eBGP requires neighbors to be directly connected. If they are not

you must configure eBGP multihop routing... config router bgp ... config neighbor ... set ebgp-multihop enable". This confirms the necessity of the command for non-directly connected eBGP peers

as is the case in this ADVPN scenario.

3. Fortinet Cookbook

ADVPN with BGP as the routing protocol (2023/11/21).

In the "Configuring the Hub" section

under the BGP configuration for the neighbor group that includes the spokes

the command set next-hop-self enable is listed as a mandatory step. The explanation notes that this allows the hub to advertise itself as the next hop for routes learned from other spokes.

The command output npustate=0x00000003 is the key indicator of the IPsec tunnel's hardware offloading status. This value is a bitmask where 0x01 represents the inbound Security Association (SA) and 0x02 represents the outbound SA. A value of 0x03 is the sum of 0x01 and 0x02, which confirms that both the inbound and outbound IPsec SAs have been successfully offloaded to the Network Processing Unit (NPU). This means the NPU is handling the encryption and decryption for traffic in both directions, which significantly improves VPN performance.

A. IPsec SAs cannot be offloaded.

This is incorrect. The npustate value of 0x03 explicitly confirms that both SAs have been successfully offloaded to the NPU.

C. Only the outbound IPsec SA is copied to the NPU.

This is incorrect. An npustate value of 0x00000002 would indicate that only the outbound SA is offloaded.

D. Only the inbound IPsec SA is copied to the NPU.

This is incorrect. An npustate value of 0x00000001 would indicate that only the inbound SA is offloaded.

1. FortiGate IPsec VPN 7.4 Study Guide

Chapter 10: Troubleshooting

Verifying IPsec NPU offloading

Page 210. The guide explains the output of the diagnose vpn tunnel list command

stating: "If npustate is 0x3

both inbound and outbound SAs are offloaded."

2. Fortinet Technical Note

Troubleshooting Tip: IPsec VPN packets are not offloaded to NPU

Document ID: FD39207. This document details the meaning of the npustate values:

npustate=0x00000000: No SA is offloaded.

npustate=0x00000001: Only inbound SA is offloaded.

npustate=0x00000002: Only outbound SA is offloaded.

npustate=0x00000003: Both inbound and outbound SAs are offloaded.

ADVPN (Auto-Discovery VPN) 2.0 is the Fortinet technology specifically designed for this scenario. It enables spokes in a hub-and-spoke topology to create dynamic, on-demand IPsec tunnels (shortcuts) directly between each other, bypassing the hub. The "2.0" designation refers to its tight integration with SD-WAN, which allows it to manage multiple internet connections (underlays) per spoke. By using SD-WAN performance SLAs to monitor link quality (latency, jitter, packet loss), ADVPN 2.0 can automatically select the best-performing path for the shortcut tunnel, ensuring optimal link utilization and seamless failover.

A. Set up OSPF routing over static VPN tunnels between spokes.

This requires a full mesh of static tunnels, which is not scalable. OSPF alone does not provide advanced link quality-based path selection like SD-WAN.

C. Establish static VPN tunnels between spokes with predefined backup routes.

This is a rigid, non-scalable solution. It relies on basic static failover, not the dynamic, performance-based optimization required by the scenario.

D. Implement SD-WAN policies at the hub to manage spoke link quality.

Placing SD-WAN policies only on the hub would manage hub-to-spoke traffic but would not facilitate the required direct spoke-to-spoke communication.

---

1. FortiOS Administration Guide 7.0.12 | IPsec VPN > Auto-discovery VPN (ADVPN)

Section: Auto-discovery VPN (ADVPN)

Content: "ADVPN is a technology that allows a traditional hub-and-spoke VPN’s spokes to establish dynamic

on-demand

direct tunnels

known as shortcuts

between each other to avoid routing traffic through the hub... When ADVPN is combined with SD-WAN

it is possible to have ADVPN shortcuts on all overlays." This directly supports the dynamic tunnel creation and multi-link capability.

2. FortiOS SD-WAN Architecture Guide 7.0.0

Section: 4.3. ADVPN with SD-WAN

Content: "ADVPN with SD-WAN allows spokes to establish dynamic tunnels between each other over the available underlays. SD-WAN rules can be used to select the best link for the ADVPN shortcut based on the measured quality of the links." This confirms that the combination of ADVPN and SD-WAN achieves the automatic link optimization requirement.

3. Fortinet Cookbook | ADVPN with SD-WAN (7.0.2)

Section: Introduction

Content: "This recipe details how to configure ADVPN with SD-WAN to allow spokes to establish dynamic tunnels between each other over the available underlays. SD-WAN rules can be used to select the best link for the ADVPN shortcut based on the measured quality of the links." This provides a practical implementation guide confirming the functionality described in the correct answer.

The phase-1 entry shows ‘set dpd on-demand’.

With on-demand DPD, the FortiGate relies on normal user traffic to confirm that the peer is alive and sends a probe only when no traffic is seen. Because no extra keep-alive packets are transmitted during normal activity, this setting is regarded as the most appropriate compromise for links that already exchange traffic at regular intervals; it verifies connectivity while minimising bandwidth and CPU consumption.

B. Peer IDs are exposed only when phase 1 is in aggressive mode; the configuration shown uses main mode, so IDs remain encrypted.

C. ‘set add-route enable’ (default) causes FortiGate to install a route for the negotiated tunnel, so the statement is false.

D. ‘set net-device disable’ keeps a single tunnel interface for all dial-up peers; no extra interfaces (and thus no additional resource load) are created.

1. Fortinet

“FortiOS 7.0 IPSec VPN Guide”

section “Dead Peer Detection”

p. 46-47 – describes on-demand DPD and its suitability for links with regular traffic.

2. Fortinet

“FortiOS 7.0 CLI Reference”

command vpn ipsec phase1-interface

parameter ‘dpd’

p. 1539 – defines ‘on-demand’ behaviour.

3. Fortinet

“FortiOS 7.0 Administration Guide”

chapter “IPSec VPN – Phase 1 parameters”

p. 1292 – notes that aggressive mode reveals peer ID

while main mode encrypts it.

4. Fortinet

“FortiOS 7.0 CLI Reference”

same command

parameters ‘add-route’ and ‘net-device’

p. 1541 – explains default add-route behaviour and interface creation when net-device is enabled.

The primary goal is to scale performance to handle increased traffic and UTM processing load, as the current FortiGate is reaching its resource limits.

FGCP in active-active mode creates a cluster where all FortiGate devices actively process traffic. This distributes the workload, effectively increasing the total capacity for resource-intensive tasks like UTM inspection.

FGSP with external load balancers is another valid scaling solution. An external load balancer distributes new sessions across the FortiGates, and FGSP (FortiGate Session Life Support Protocol) synchronizes session information between them. This ensures session continuity and stateful inspection, allowing multiple devices to share the processing load.

Both methods achieve the objective of integrating the new FortiGate to handle a higher traffic volume and processing demand.

C. FGCP in active-passive mode and with VDOM disabled: This configuration provides only redundancy (failover). The passive unit is on standby and does not process traffic, so it does not help with resource limitations.

D. VRRP with switches: VRRP (Virtual Router Redundancy Protocol) is an active-passive redundancy protocol for gateway availability. It does not distribute the traffic processing load across multiple devices.

1. FortiOS Administration Guide 7.0.0 | High Availability > Active-active HA (Page 1680): "In active-active (A-A) HA

all FortiGates in the cluster process traffic. The primary unit load balances session-based traffic (such as TCP and UDP) and all IPsec and SSL VPN traffic to all cluster members." This confirms that A-A mode is for load balancing and performance scaling.

2. FortiOS Administration Guide 7.0.0 | High Availability > FortiGate Session Life Support Protocol (FGSP) (Page 1761): "FGSP is a proprietary Fortinet protocol that can be used to synchronize sessions on multiple FortiGates for session failover. FGSP is also used for load balancing... FGSP is intended for use in environments that have other devices

such as load balancers

distributing traffic among a group of FortiGates." This validates the use of FGSP with external load balancers for scaling.

3. FortiOS Administration Guide 7.0.0 | High Availability > Active-passive HA (Page 1679): "In active-passive (A-P) HA

only the primary FortiGate processes traffic. The secondary FortiGate is in standby mode..." This confirms A-P mode is for redundancy

not load sharing.

4. FortiOS Administration Guide 7.0.0 | High Availability > Virtual Router Redundancy Protocol (VRRP) (Page 1777): "VRRP provides active-passive redundancy between two or more FortiGates." This confirms VRRP is for redundancy

not performance scaling.