NSE7_SDW-7-2 Practice Questions

Study guide 7.2 Page 191

The zero-touch provisioning (ZTP) process can fail for several reasons. One critical prerequisite is that the FortiGate device must be registered in the FortiGate Cloud portal using its unique cloud key (serial number). If this key is not added, the FortiDeploy service cannot identify the device when it calls home, and thus cannot provide the initial configuration, causing the process to fail.

Additionally, while a factory reset initiates the ZTP process on a device, it can lead to a failure scenario if the device was previously managed. The FortiManager or FortiGate Cloud may still have a record of the device. When the reset device attempts to re-provision, it might be treated as an unauthorized or duplicate device, requiring manual administrator intervention to be re-authorized. This prevents the fully automated ZTP process from completing successfully.

B. This describes a successful step in the ZTP process where the device receives its FortiManager information. This is an indicator of ZTP progressing correctly, not failing.

C. This statement is ambiguous and does not align with any official terminology or documented failure state for the FortiGate ZTP process. It is an invalid scenario.

D. Obtaining a configuration from a platform template is a method of successful ZTP completion via FortiGate Cloud. This represents a successful outcome, not a failure.

1. FortiManager Administration Guide 7.2.1, Page 190, "Zero-touch deployment". The guide explicitly lists as a requirement: "The FortiGate Cloud key must be added to the FortiGate Cloud portal." This directly supports option A as a failure reason if not met.

2. FortiManager Administration Guide 7.2.1, Page 183, "Adding devices". The guide details that newly discovered devices appear in the "Unauthorized Devices" list and must be authorized by an administrator. A factory-reset device that was previously managed would reappear as a new, unauthorized device, thus halting the automated ZTP process until manual authorization occurs. This supports the reasoning for option E leading to an incomplete ZTP cycle.

3. FortiGate Cloud 23.1 Administration Guide, Page 100, "Deploying a new FortiGate". The documentation states, "A factory reset device automatically attempts to connect to FortiGate Cloud. If the device is associated with an account, FortiGate Cloud can deploy a configuration to it." This confirms that registration (Option A) is essential for the process to even begin.

The Fortinet Secure SD-WAN solution is an integrated ecosystem of products designed for scalable and secure network deployments. The core components are:

FortiGate: The Next-Generation Firewall (NGFW) appliance that serves as the SD-WAN edge device, providing both advanced security and SD-WAN functionality.

FortiManager: The centralized management platform used for orchestrating, provisioning, and monitoring the entire SD-WAN fabric from a single console.

FortiAnalyzer: The centralized analytics and reporting platform that collects logs from all FortiGate devices, providing deep visibility, security analysis, and compliance reporting.

FortiDeploy: A cloud-based service that enables zero-touch provisioning for rapid, large-scale deployment of FortiGate devices in branch offices.

A. These are security services and inspection profiles available on a FortiGate device, not the architectural components of the overall SD-WAN solution.

B. These represent the physical or logical locations (use cases) where an SD-WAN solution is deployed, not the products that constitute the solution.

D. These are legacy telecommunication technologies that can serve as underlay networks, but they are not components of the Fortinet SD-WAN product suite.

1. Fortinet NSE 7—SD-WAN 7.0 Study Guide, Page 6, "Solution Components". The guide explicitly lists the core components: "The Fortinet Secure SD-WAN solution is comprised of the following components: FortiGate, FortiManager, FortiAnalyzer, FortiDeploy...". This directly supports the correct answer.

2. Fortinet Secure SD-WAN Architecture Guide, Page 5, "Fortinet Secure SD-WAN". This document outlines the three key pillars of the solution: "Secure SD-WAN" (enabled by FortiGate), "Centralized Management" (provided by FortiManager), and "Analytics" (delivered by FortiAnalyzer), confirming their roles as primary components.

3. FortiManager 7.2.0 Administration Guide, Page 1003, "SD-WAN". This section details how FortiManager is used to "centrally manage SD-WAN on one or more FortiGate devices," establishing its role as a core management component.

4. FortiGate / FortiOS 7.2.0 SD-WAN Administration Guide, Page 6, "Introduction". The document states, "FortiGate devices support SD-WAN to provide a solution that allows you to use multiple WAN connections for business-critical applications," identifying FortiGate as the fundamental edge device.

The primary purpose of integrating Fortinet SD-WAN with Auto-Discovery VPN (ADVPN) is to leverage dynamic, on-demand tunnels between spoke sites. These ADVPN IPsec overlays (hubs or dynamic shortcuts) are configured as members of the SD-WAN virtual interface. This allows the SD-WAN controller to perform health and performance monitoring (latency, jitter, packet loss) on these tunnels. Based on this monitoring and the configured SD-WAN rules (like best quality or lowest cost), SD-WAN can intelligently steer traffic across the most optimal path, whether it's a static hub-and-spoke tunnel or a dynamic spoke-to-spoke shortcut.

A. Routes for ADVPN shortcuts must be manually configured.

This is incorrect. ADVPN's core function is automation; it relies on a dynamic routing protocol, typically BGP, to automatically advertise and learn routes for the dynamically established shortcuts.

C. SD-WAN does not monitor the health and performance of ADVPN shortcuts.

This is incorrect. A fundamental feature of SD-WAN is to monitor all its member interfaces, including ADVPN tunnels and shortcuts, to make informed traffic-steering decisions based on real-time performance.

D. You must use IKEv2 on IPsec tunnels.

While IKEv2 is a mandatory prerequisite for the ADVPN auto-discovery feature to function, this statement describes a specific configuration requirement rather than the overarching functional relationship between SD-WAN and ADVPN, which option B correctly details.

1. Fortinet FortiOS 7.0.0 SD-WAN Architecture Guide, Page 41, "SD-WAN and ADVPN".

"FortiGate SD-WAN is fully compatible with Auto-discovery VPN (ADVPN). When you configure ADVPN, you can add the IPsec tunnels to the SD-WAN interface as members. SD-WAN can then use the tunnels to route traffic and measure their health." (This supports option B and refutes option C).

2. Fortinet FortiOS 7.0.0 SD-WAN Deployment Guide, "SD-WAN with ADVPN" section.

The configuration example shows adding the IPsec interfaces as members of the SD-WAN. It also details using BGP for dynamic route exchange. (This supports option B and refutes option A).

3. Fortinet FortiOS 7.0.0 Administration Guide, "Auto-discovery VPN (ADVPN)" section.

"ADVPN is supported for IKEv2 only." (This confirms that IKEv2 is a requirement for ADVPN, making option D factually correct but less descriptive of the integrated solution than option B).

When configuring multiple IKEv1 dial-up IPsec tunnels on the same FortiGate interface, the FortiGate processes incoming connection requests sequentially against its VPN list. If the initial negotiation parameters (like proposals) are identical, it will always match the first tunnel. To correctly route connections to their intended tunnels, two conditions must be met:

1. Each tunnel must have a unique peer ID, which the remote client must present for identification.

2. IKEv1 aggressive mode must be used. In main mode, the peer ID is exchanged in encrypted packets late in the negotiation, preventing the FortiGate from using it for initial tunnel selection. Aggressive mode includes the peer ID in the first unencrypted packet, allowing the FortiGate to immediately identify and match the correct tunnel.

B. Using different proposals is not a reliable matching mechanism, as a client's proposal could still match the first tunnel in the list, causing an incorrect match.

D. Using unique Diffie-Hellman groups is not the primary method for differentiating tunnels and is unreliable for the same reason as using different proposals.

1. FortiOS 7.2.0 Administration Guide, IPsec VPN Handbook, Chapter: IPsec VPN, Section: Dial-up IPsec VPN with multiple tunnels.

The guide states: "When you configure multiple dial-up IPsec VPN tunnels on the same FortiGate interface, you must configure a unique peer ID for each tunnel so that the FortiGate unit can distinguish between the tunnels. You must also use aggressive mode." This directly supports both chosen answers.

2. Fortinet Cookbook (docs.fortinet.com), IPsec VPN, Article: Multiple dial-up IPsec VPNs on the same interface.

This technical article explains the configuration requirements: "In order for the FortiGate to distinguish between the different dial-up clients, two conditions must be met: 1. Each phase1 must have a unique Peer ID. 2. The phase1 must be configured to use aggressive mode." This confirms that both changes are necessary.

An SD-WAN member is a routable interface that is added to an SD-WAN virtual interface. The order of these members, represented by a sequence number, can be manually defined in the CLI using the set seq-num command or by reordering them in the GUI. This order is important for certain SD-WAN rule configurations. Furthermore, any interface that can be assigned an IP address and used for routing can serve as an SD-WAN member. This includes physical interfaces, aggregate interfaces, IPsec tunnels, and VLAN interfaces, which are commonly used to segment WAN connections.

B: Virtual wire pair interfaces operate at Layer 2 and are transparent; they do not have IP addresses and cannot be used for routing, which is a prerequisite for an SD-WAN member.

D: An SD-WAN member is an interface that can be assigned to a logical grouping called an SD-WAN zone. However, an interface can only belong to a single SD-WAN zone at a time.

1. Fortinet FortiOS 7.0.2 SD-WAN Administration Guide, Page 16, "SD-WAN members": "Any interface that has an IP address and can be used for routing can be an SD-WAN member. This includes physical ports, VLANs, aggregate interfaces, and IPsec tunnels." This supports option C.

2. Fortinet FortiOS 7.0.2 SD-WAN Administration Guide, Page 16, "SD-WAN members": "Interfaces used as SD-WAN members cannot be part of a virtual wire pair..." This refutes option B.

3. Fortinet FortiOS 7.0.2 SD-WAN Administration Guide, Page 18, "SD-WAN zones": "An SD-WAN member can belong to only one SD-WAN zone." This refutes option D.

4. Fortinet FortiOS 7.0.0 CLI Reference, Page 1883, config system sdwan > config members: The command edit shows that members are identified by a sequence number. The move {after | before} command allows for reordering, which effectively changes the sequence number. This supports option A.

The FortiGate VPN event logs clearly show the establishment of ADVPN shortcut tunnels. The log message msg="IPsec ADVPN shortcut is up" tunnel="TMPLS0" shortcutname="TMPLS00" is explicit. According to the FortiGate log message reference, the tunnel field identifies the parent (master) tunnel, and the shortcutname field identifies the dynamically created shortcut tunnel. Therefore, TMPLS0 is the master tunnel from which one shortcut, named TMPLS00, has been successfully built.

A. The logs contain msg="IPsec tunnel statistics" for tunnelname="TMPLS00" and tunnelname="TINET00", which are the ADVPN shortcut tunnels, disproving this statement.

C. The logs identify TMPLS0 as the master tunnel in the tunnel="TMPLS0" field, while TMPLS00 is explicitly named as the shortcut.

D. The log message msg="IPsec ADVPN shortcut is up" ... tunnel="TINET0" directly confirms that the master tunnel TINET0 successfully negotiated and established an ADVPN shortcut.

1. FortiGate / FortiOS 7.2.0 Log Message Reference, Page 321, Log ID 0101039947.

This document defines the fields for the "IPsec ADVPN shortcut is up" message. It specifies:

tunnel: "Name of the parent tunnel."

shortcutname: "Name of the shortcut tunnel."

This directly supports the explanation that TMPLS0 is the master (parent) and TMPLS00 is the shortcut.

2. FortiOS 7.2.4 Administration Guide, Page 1311, "Monitoring ADVPN".

The guide explains how to monitor ADVPN tunnels. In the output of the command diagnose vpn tunnel list, shortcut tunnels are shown with a suffix (e.g., 0) appended to the master tunnel's name and are identified as dynamic. This confirms the naming convention seen in the logs.

3. SD-WAN 7.2 Study Guide, Page 218, "ADVPN Troubleshooting".

This guide describes the ADVPN shortcut negotiation process. It states, "When a shortcut is created, FortiGate creates a new IPsec phase 1 and phase 2. The new interface name is derived from the original phase 1 name with a number appended to it." This confirms that tunnels like TMPLS00 are the dynamically created shortcuts.

Using an IPsec recommended template in FortiManager for a hub-and-spoke topology provides standardized configurations. The primary advantage of any template is ensuring consistency, which in this context applies to both Phase 1 and Phase 2 settings across all tunnels within the VPN community. This prevents configuration mismatches and simplifies management. Furthermore, the templates labeled as "recommended" are pre-configured by Fortinet with settings that align with security and performance best practices, guiding administrators toward an optimal and reliable setup without requiring deep expertise in every IPsec parameter.

C. Templates standardize configuration but do not automate the installation process. An administrator must still explicitly create the VPN community and install the configuration on the spokes.

D. The VPN monitor tool provides the same set of statistics for all IPsec tunnels, regardless of whether they were configured using a template or created manually.

1. Fortinet FortiManager Administration Guide 7.0.1, Page 418, "IPsec Templates" section: "FortiManager includes some recommended templates that you can use to create VPNs. You can also create your own templates." This supports option B, as it confirms Fortinet provides "recommended" templates.

2. Fortinet Certified Professional - Network Security Study Guide for FortiManager 7.0, Page 218, "IPsec Templates" section: "Using templates ensures that all VPNs in a community have consistent settings." This directly supports option A, highlighting the role of templates in maintaining consistency.

3. Fortinet FortiManager Administration Guide 7.0.1, Page 416, "Creating a hub-and-spoke VPN" section: This section details the manual steps required to create and install the VPN configuration using the wizard, which contradicts the automatic installation suggested in option C.

4. Fortinet FortiManager Administration Guide 7.0.1, Page 161, "Monitoring VPNs" section: The documentation describes the features of the VPN monitor without making any distinction in available statistics based on the tunnel's configuration method, which invalidates option D.

The Fortinet Internet Service Database (ISDB) is a core component for simplifying SD-WAN and firewall policy administration. It contains a dynamically updated list of IP addresses, protocols, and port numbers for thousands of common internet services (like Microsoft 365, Salesforce, etc.).

By using an ISDB object (e.g., Microsoft.Office365) as a destination in an SD-WAN rule, administrators can accurately steer traffic without needing to manually track and update the constantly changing IP addresses of these cloud services. FortiGuard services automatically push updates to the ISDB, which significantly reduces administrative overhead and ensures policies remain effective as services evolve.

B. The ISDB is a database of IP addresses and ports; it does not require Application Control, which uses deep packet inspection for signature-based identification.

C. The SD-WAN rule applies the action. The ISDB is used as a destination matching criterion in the rule, not a source, and it identifies services, not generic application types.

1. Fortinet FortiOS 7.0.0 Administration Guide, Internet Service Database, Page 1081: "The FortiGuard Internet Service Database is a comprehensive, up-to-date public IP address database that combines IP address range, port number, and protocol. FortiGuard services automatically push updates to the database... You can use Internet Services in firewall policies, and SD-WAN rules and performance SLAs to simplify administration." (This supports options A and D).

2. Fortinet SD-WAN Architecture Guide 7.0, Internet Service Database (ISDB), Page 13: "The Fortinet Internet Service Database (ISDB) simplifies this process by providing an up-to-date database of IP addresses, port numbers, and protocols used by all the major cloud services. The ISDB is kept up-to-date automatically by FortiGuard Labs, which removes the administrative burden of constantly updating all the IP addresses used by these services." (This directly confirms the benefits in options A and D).

3. Fortinet NSE 7—SD-WAN 7.0 Study Guide, SD-WAN Deployment and Administration, Section: Internet Service Database: "The Internet Service Database (ISDB) is a database of public IP addresses of well-known internet services, which is compiled and maintained by FortiGuard. The ISDB is dynamically updated on your FortiGate... Using the ISDB in SD-WAN rules simplifies configuration and reduces administrative overhead because you don’t have to manually maintain the IP addresses for the services." (This explicitly validates options A and D as key benefits).

FortiGate SD-WAN rules can use dynamic address objects as a destination. These objects can be populated with routes learned through dynamic routing protocols, specifically BGP and OSPF. When a BGP neighbor is specified in the dynamic address object, all routes learned from that neighbor are dynamically included. This allows SD-WAN rules to steer traffic towards destinations whose IP addresses are not static, such as services in a public cloud (AWS, Azure) or a remote data center, without requiring manual updates to the rules when network prefixes change.

B. You must use BGP to route traffic for both overlay and underlay links.

This is incorrect. Underlay routing can be managed by static routes or other protocols, while BGP is commonly used for the overlay, but it is not a strict requirement for both.

C. You must configure AS path prepending.

This is incorrect. AS path prepending is an optional BGP traffic engineering technique to influence inbound routing paths; it is not a mandatory configuration for using BGP with SD-WAN.

D. You must use external BGP.

This is incorrect. Internal BGP (iBGP) is very commonly used for the SD-WAN overlay, especially in hub-and-spoke or ADVPN topologies where all sites are part of the same Autonomous System.

1. Fortinet FortiOS 7.2.0 SD-WAN Administration Guide, Page 71, "SD-WAN rules > Destination".

The documentation states: "You can also use dynamic addresses as the destination. Dynamic addresses can be populated with routes learned through BGP and OSPF." This directly supports the correct answer (A).

2. Fortinet FortiOS 7.2.0 SD-WAN Architecture Guide, Page 28, "Routing".

This section explains the separation of underlay and overlay routing. It details that underlay routing depends on the ISP connection (often static or DHCP), while overlay routing uses protocols like BGP. It does not mandate BGP for both, refuting option B.

3. Fortinet FortiOS 7.2.0 ADVPN with BGP as the routing protocol Guide, Page 16, "Configuring BGP on the hub".

The configuration example shows the hub and spokes configured within the same AS number (e.g., set as 65000), which is an iBGP deployment. This directly refutes the claim that eBGP must be used (D).

4. Fortinet FortiOS 7.2.0 Routing Administration Guide, Page 111, "AS path prepending".

This section describes AS path prepending as a method to "make a route less preferable" for traffic engineering purposes. It is presented as an optional feature, not a requirement, which refutes option C.