Fortinet NSE7_SDW-7.2 Practice Questions

Explanation:
In FortiOS, a per-IP traffic shaper enforces a bandwidth ceiling on each individual source IP address. When configured with a 10 Mbps limit, FortiGate ensures that each unique source IP can transmit traffic up to 10 Mbps, but no more. This is especially useful in multi-user environments like branch offices or guest networks, where administrators want to prevent any single user or device from consuming excessive bandwidth.

The shaping mechanism is applied at the session level, and FortiGate tracks sessions per source IP. Once the cumulative traffic from a source IP reaches the defined threshold, FortiGate begins to drop or delay packets to maintain the limit. This shaping is not shared across IPs and does not guarantee bandwidth—it simply enforces a maximum.

This behavior is consistent across FortiOS 7.2 and is applicable whether the traffic shaper is applied in a firewall policy, SD-WAN rule, or QoS profile.

Why the other options are incorrect:
A. FortiGate applies traffic shaping to the original traffic direction only.
❌ Incorrect. Traffic shaping can be applied to either direction—ingress or egress—depending on configuration. FortiGate allows shaping on both directions if needed, and per-IP shaping is not restricted to just the original direction.
📚 Reference: FortiOS 7.2 Admin Guide – Traffic Shaping Direction Settings

B. FortiGate shares 10 Mbps of bandwidth equally among all source IP addresses.
❌ Incorrect. This describes a shared shaper, not a per-IP shaper. In a shared shaper, the total bandwidth is divided among all users. In contrast, a per-IP shaper gives each IP its own limit, independent of others.
📚 Reference:
Fortinet KB Article – Difference Between Shared and Per-IP Shapers

D. FortiGate guarantees a minimum of 10 Mbps of bandwidth to each source IP address.
❌ Incorrect. Traffic shaping in FortiGate is used to limit bandwidth, not to guarantee it. Guaranteeing bandwidth would require priority-based QoS or bandwidth reservation, which is not the function of a per-IP shaper.
📚 Reference:
FortiOS 7.2 CLI Guide – set guaranteed-bandwidth (used in QoS, not per-IP shaper)

Operational Use Case:
Imagine a branch office with 100 users and a 1 Gbps internet link. To prevent any single user from hogging bandwidth—say, for large downloads or video streaming—the admin configures a per-IP shaper of 10 Mbps. This ensures fair usage: each user can use up to 10 Mbps, but not more, regardless of how idle or busy the rest of the network is.
This setup is ideal for environments where fairness and bandwidth containment are more important than performance guarantees.

CLI Example:
bash
config firewall shaper per-ip-shaper
edit "limit-10mbps"
set maximum-bandwidth 10000
next
end
Apply this shaper in a firewall policy or SD-WAN rule to enforce the limit per source IP.

📚 References:
FortiOS 7.2 Administration Guide – Traffic Shaping

FortiOS CLI Reference – Per-IP Shaper Configuration

Explanation:
Application steering is a core, advanced feature of SD-WAN that moves beyond simple routing based on IP addresses and ports.

Analysis of Each Option:
A. The traffic always skips the regular policy routes.
Incorrect. The relationship between SD-WAN rules and policy routes is fixed: SD-WAN rules always have precedence over policy routes, regardless of whether application steering is used. This is not a unique benefit of application steering; it's a fundamental characteristic of the SD-WAN path selection order.

B. You steer traffic based on the detected application.
Correct. This is the primary benefit and definition of application steering. It leverages FortiGate's deep packet inspection (DPI) capabilities to identify applications regardless of the port, protocol, or IP address they use. This allows you to create intelligent SD-WAN rules such as:
"Route all Microsoft 365 traffic (identified as an application) over the high-priority link."
"Block all social media applications."
"Send all VoIP traffic (e.g., Skype, Zoom) over the low-latency MPLS link." This provides granular, business-centric control over network traffic.

C. You do not need to enable SSL inspection.
Incorrect. In fact, the opposite is often true. To accurately identify applications that use encrypted HTTPS traffic (which is most modern traffic), you must enable and use SSL/HTTPS inspection. Without it, the FortiGate can only see the initial TLS handshake and the destination IP, severely limiting its ability to perform deep application detection. Application steering often relies on SSL inspection for its accuracy.

D. You do not need to configure firewall policies that accept the SD-WAN traffic.
Incorrect. This is a fundamental misunderstanding of the FortiOS security model. SD-WAN rules are for path selection, not packet acceptance. All traffic, regardless of SD-WAN rules, must still be permitted by a stateful firewall policy that specifies the source interface, source address, destination interface, destination address, and service. The SD-WAN rule determines which path an accepted packet takes, but the firewall policy determines if the packet is accepted in the first place.

Reference:
Fortinet Documentation Library:
The FortiOS SD-WAN guide has a specific section on "Application-based SD-WAN rules." It explicitly states that you can "create SD-WAN rules that steer traffic matching specific applications or groups of applications to a specified SD-WAN service."
It emphasizes that this allows for more granular and intelligent control over traffic than traditional routing based on IP/subnet alone.

Explanation:
For ADVPN (Auto-Discovery VPN) to function within an SD-WAN overlay, the IPsec tunnels themselves must be capable of participating in the ADVPN protocol. This is controlled by two specific commands in the Phase 1 configuration.

Analysis of Each Option:
A. You must set ike-version to 1.
Incorrect. While ADVPN can work with IKEv1 in some specific scenarios, IKEv2 is strongly recommended and required for a full SD-WAN and ADVPN implementation. IKEv2 provides better support for dynamic addressing, rekeying, and dead peer detection (DPD), which are crucial for a stable and scalable SD-WAN network. The exhibit correctly shows set ike-version 2.

B. You must enable net-device.
Incorrect. The net-device setting controls whether a virtual IPsec interface is created in the kernel. For ADVPN and SD-WAN, this must be disabled (set net-device disable). This is a critical requirement because it allows the FortiGate to treat the IPsec tunnel as a logical member of an SD-WAN zone and apply SD-WAN policies and routing to it. The exhibit correctly shows set net-device disable.

C. You must enable auto-discovery-sender.
Correct. ADVPN requires two roles:

auto-discovery-receiver:
This is enabled on the hub FortiGate (or on spokes that will accept incoming shortcut requests). The hub acts as the receiver for queries. The exhibit shows this is enabled (set auto-discovery-receiver enable), which is correct for a hub or a spoke that can receive shortcuts.

auto-discovery-sender:
This must be enabled on the spoke FortiGates that will initiate the shortcut tunnels. This allows them to send the SHORTCUT_QUERY messages to the hub.
For a full ADVPN setup, the hub has receiver enabled, and the spokes have sender enabled. Since the question asks what "you must configure" for ADVPN to work, enabling auto-discovery-sender on spokes is a mandatory part of that configuration.

D. You must disable idle-timeout.
Incorrect. The idle-timeout feature is actually very beneficial for ADVPN. It allows the dynamically created spoke-to-spoke shortcuts to be torn down automatically after a period of inactivity, conserving resources. This is not a requirement but a best practice for managing the lifecycle of on-demand tunnels. The exhibit shows it is enabled, which is fine.

Reference:
Fortinet Documentation Library:
The FortiOS Cookbook chapter on "ADVPN" explicitly details the Phase 1 configuration requirements. It states that for a hub, you configure set auto-discovery-receiver enable, and for a spoke, you configure set auto-discovery-sender enable.

Explanation:
The key difference between Main Mode and Aggressive Mode in IKEv1 is the trade-off between security and speed, primarily reflected in the number of messages exchanged and the exposure of identity information.

Analysis of Each Option:
A. A peer ID is included in the first packet from the initiator, along with suggested security policies.
Correct. This is a fundamental and critical difference. In Aggressive Mode, the first packet from the initiator contains the peer ID (often the IP address), the Diffie-Hellman public value, a nonce, and all the security proposals. This exposes the identities before a secure channel is established. In Main Mode, the identities of the peers are exchanged only in the third and fourth packets, after the secure tunnel (ISAKMP SA) has been established, thus hiding them from eavesdroppers.

B. XAuth is enabled as an additional level of authentication, which requires a username and password.
Incorrect. Extended Authentication (XAuth) is an optional feature that can be used with either Main Mode or Aggressive Mode. It is not a defining characteristic that differentiates the two modes. XAuth occurs after the IKE Phase 1 negotiation is complete.

C. A total of six packets are exchanged between an initiator and a responder instead of three packets.
Correct. This is the most obvious operational difference. Main Mode uses a 6-packet exchange (3 round trips).
Aggressive Mode uses a 3-packet exchange (1.5 round trips). The reduced number of packets in Aggressive Mode is why it is faster, but it achieves this speed by compromising on security aspects like identity protection.

D. The use of Diffie Hellman keys is limited by the responder and needs initiator acceptance.
Incorrect. The Diffie-Hellman key exchange is a core part of both Main Mode and Aggressive Mode. The process is conceptually the same in both: the initiator and responder exchange DH public values and use them to generate a shared secret. The responder does not "limit" the DH groups; rather, both peers must agree on a DH group from the list of proposals offered by the initiator. This negotiation process is similar in both modes.

Reference:
General IPsec/IKEv1 Knowledge:
The 6-packet vs. 3-packet exchange and the identity protection (hiding) in Main Mode are standard, fundamental differentiators between the two modes, documented in RFC 2409 and all major network security textbooks.

Fortinet Documentation Library:
While the FortiOS documentation may not have a dedicated section comparing the two, the CLI reference for config vpn ipsec phase1-interface includes the mode option (main/aggressive), and the underlying protocol behavior is consistent with these industry-standard principles.

Explanation:
SD-WAN zones are logical groupings of interfaces (members) that share common characteristics, allowing you to apply rules to a group rather than individual interfaces.

Analysis of Each Option:
A. The service-sla-tie-break setting enables you to configure preferred member selection based on the best route to the destination.
Correct. The service-sla-tie-break command is used in the SD-WAN rule configuration (config service) to determine how to break a tie when multiple members have the same, best SLA score. One of the options for this setting is cfg-order, which means it will select the member based on the order they are listed in the priority-members list. However, another key option is input-device. When set to input-device, the FortiGate will prefer the member that matches the best route's input device, effectively using the routing table as the tie-breaker. This makes the statement true.

B. You can delete the default zones.
Incorrect. Default zones are system-defined and cannot be deleted. You can create and delete custom zones, but the pre-defined ones like virtual-wan-link are permanent.

C. The default zones are virtual-wan-link and SASE.
Correct. In FortiOS, the virtual-wan-link is the traditional, long-standing default SD-WAN zone. With newer versions and the integration of FortiSASE, the SASE zone has been added as another default zone to facilitate SD-WAN policies for Secure Access Service Edge architectures. These are both pre-configured and cannot be removed.

D. An SD-WAN member can belong to two or more zones.
Incorrect. A fundamental rule of SD-WAN configuration is that a physical or logical interface (a member) can be assigned to one and only one SD-WAN zone. This is because the zone is used to determine the egress path for traffic, and having an interface in multiple zones would create ambiguity in the path selection logic.

Reference:
Fortinet Documentation Library:
The FortiOS SD-WAN guide explains the concept of zones and states that "An SD-WAN zone is a logical group of one or more SD-WAN members." It implies the one-to-one relationship between a member and its zone.

The CLI reference for config system sdwan and config service details the service-sla-tie-break option and its input-device parameter, which uses the routing table information for selection.

The list of default zones (virtual-wan-link, SASE) is visible in the GUI when creating a new SD-WAN zone or in the CLI when using autocomplete.

Explanation:
FortiManager CLI templates offer advanced configuration flexibility for managing FortiGate devices. Two key benefits are:

✅ A. You can reference meta fields.
CLI templates support meta fields, which are dynamic placeholders tied to device-level variables. This allows administrators to create reusable templates that adapt per device, enabling scalable and efficient deployments. For example, you can define a meta field like vlan_id and use it across multiple devices without hardcoding values.
This is especially useful in large environments where device-specific values (like IPs, interface names, or VLANs) vary but the configuration logic remains consistent.

📚 Reference:
Fortinet Docs – Interface Template Support for Meta Fields

✅ D. You can configure advanced CLI settings.
CLI templates allow access to low-level configuration options not exposed in the GUI. This includes advanced VPN parameters, custom routing tweaks, debug commands, and other granular settings. These templates are essential when GUI-based policy packages or object templates lack the required depth.
For example,
configuring auto-discovery-sender for ADVPN or applying custom SD-WAN health checks often requires CLI-level access.

📚 Reference:
Fortinet Docs – CLI Templates

❌ B. You can configure interfaces as SD-WAN members without having to remove references first.
Incorrect.FortiManager requires removal of existing references before reassigning interfaces to SD-WAN zones. This applies regardless of whether you use CLI templates or GUI. Attempting to assign an interface already referenced in another object (e.g., zone or policy) will result in a conflict.

📚 Reference:
Fortinet KB – SD-WAN Interface Assignment Limitations

❌ C. You can configure FortiManager to sync local configuration changes made on the managed device, to the CLI template.
Incorrect. FortiManager does not automatically sync local changes from FortiGate back into CLI templates. While you can detect and import changes using revision control or policy package diff tools, CLI templates remain static unless manually updated. There is no reverse sync mechanism from device to template.

📚 Reference:
Fortinet Docs – Policy and Object Synchronization

Summary:
CLI templates in FortiManager are powerful tools for advanced configuration and scalable deployments. Meta fields enable dynamic, device-specific provisioning, while CLI access allows full control over FortiGate features. However, interface assignment and config sync limitations still apply, reinforcing the need for careful template design and version control.

Explanation:
In FortiGate SD-WAN deployments, application steering relies on accurate identification of traffic using ISDB (Internet Service Database) and deep packet inspection. When traffic unexpectedly matches the implicit SD-WAN rule instead of a defined rule (e.g., rule ID 1), it typically indicates a failure in application detection or session steering logic. Two key reasons explain this behavior:

✅ A. FortiGate did not refresh the routing information on the session after the application was detected.
FortiGate performs application steering based on session information. If the application is detected after the session is established and FortiGate does not refresh the routing decision, the session continues using the default or implicit SD-WAN rule. This is a known behavior in FortiOS where late application identification does not retroactively apply SD-WAN rules unless session refresh is triggered.
This issue is more common when application detection is delayed due to inspection settings or encrypted traffic. FortiGate may classify the session as generic HTTPS initially, and only later identify it as GoToMeeting, but by then the SD-WAN rule has already been bypassed.

📚 Reference:
Fortinet Docs – Application Steering Using SD-WAN Rules

Fortinet KB – SD-WAN Application Steering Behavior

✅ C. Full SSL inspection is not enabled on the matching firewall policy.
Application steering depends on accurate application identification, which often requires full SSL inspection. Without it, FortiGate cannot decrypt and inspect HTTPS traffic deeply enough to identify applications like GoToMeeting. Instead, it may classify the traffic as generic SSL or HTTPS, which does not match the ISDB signature required by SD-WAN rule ID 1.
This results in the traffic falling back to the implicit SD-WAN rule, which handles unmatched sessions. Enabling full SSL inspection allows FortiGate to extract application signatures from encrypted payloads, ensuring proper rule matching.

📚 Reference:
Fortinet KB – Application Control and SSL Inspection

❌ B. Port1 and port2 do not have a valid route to the destination.
Incorrect. If port1 and port2 lacked valid routes, the traffic would be dropped or rerouted, but this would not cause a fallback to the implicit SD-WAN rule. The SD-WAN rule matching process occurs before routing decisions. The issue here is rule matching, not routing.

❌ D. The session 3-tuple did not match any of the existing entries in the ISDB application cache.
Incorrect. ISDB uses multiple attributes beyond just the 3-tuple (source IP, destination IP, port) to identify applications. Even if the 3-tuple is new, FortiGate can still identify the application if SSL inspection is enabled and the traffic matches known patterns. The failure here is due to lack of inspection, not cache mismatch.

Summary:
The traffic matched the implicit SD-WAN rule because:
Application detection occurred too late, and FortiGate did not refresh the session routing.
Full SSL inspection was not enabled, preventing accurate identification of GoToMeeting.