Nse7 SD Wan Security Profiles Routing And Ipsec practice questions

SD-WAN health check probes are overwhelming the IPsec tunnel bandwidth

Why it fails: Health check probes consume negligible bandwidth and their loss would affect SLA measurement, not produce drops tied specifically to the smaller-MTU backup tunnel. It is tempting because probe traffic does traverse the tunnel, so it is the correct suspect when SLA metrics themselves flap, not when payload packets drop.

The Antivirus proxy buffer is overflowing due to UDP streaming packets

Why it fails: UDP is not proxied by the antivirus buffer, and drops correlate with the backup tunnel's smaller MTU, not buffer exhaustion. It is tempting because proxy buffer overflow does cause drops under heavy streaming load, which is the right diagnosis when traffic volume, not path MTU, changes.

The SSL inspection profile is attempting to decrypt UDP traffic, causing kernel panic and packet drops

Why it fails: SSL inspection targets TLS over TCP and does not decrypt UDP, so it cannot cause these drops; the correlation is with the smaller-MTU backup tunnel. It is tempting because SSL inspection is resource-intensive and can drop traffic when overloaded, which is the right suspect when TLS sessions, not UDP streams, fail.

AS-PATH prepend

Why it fails: AS-PATH prepend lengthens the path to influence inbound traffic from remote autonomous systems; applied outbound to a neighbour it affects how that neighbour reaches you, not your own outbound selection among SD-WAN members. It is tempting because prepending is a classic BGP traffic-engineering tool, but local outbound preference is set with LOCAL_PREF.

Cluster ID

Why it fails: Cluster ID is a route reflector loop-prevention attribute, not a path-selection tiebreaker; BGP best-path comparison never consults it when choosing between SD-WAN members. It is tempting because it is a genuine BGP attribute configurable in FortiOS route-maps, but it exists to discard reflected routes, not to steer outbound preference.

Origin code

Why it fails: Origin code reflects how a route entered BGP (IGP, EGP, incomplete) and is compared late in best-path selection, after LOCAL_PREF and AS-PATH. It is tempting because it is a real, settable attribute, but manipulating it cannot override the earlier LOCAL_PREF comparison that determines which SD-WAN member wins.

Disable all security profiles on the SD-WAN interface zone

Why it fails: Removing all security profiles stops Application Control from classifying traffic, so SD-WAN loses the application signatures it needs to steer those custom applications. It is tempting because disabling profiles eliminates false positives instantly, which is the right move only when inspection itself is the problem, not signature accuracy.

Configure static routes for the application servers and bypass SD-WAN rules completely

Why it fails: Static routes bypass SD-WAN rules entirely, so application-based steering cannot occur and failover is lost. It is tempting because pinning traffic to a known path avoids misclassification, which is correct only when a single deterministic egress is genuinely required, not when SD-WAN steering must remain.

Switch the inspection mode from flow-based to proxy-based for all firewall policies

Why it fails: Proxy-based inspection changes how the FortiGate buffers and scans traffic; it does not correct application signature misclassification, and it alters performance characteristics. It is tempting because proxy mode offers deeper inspection for protocols needing full reassembly, which is the right choice when flow-based inspection misses threats, not for signature accuracy.

Enable split-horizon globally within the OSPF routing process

Why it fails: OSPF split-horizon suppresses re-advertisement of routes learned on an interface back out the same interface, which would block spoke-to-spoke prefix propagation rather than enable next-hop resolution. It tempts as a loop-prevention measure, but ADVPN requires the hub to reflect spoke routes, so split-horizon must stay disabled.

Enable exchange-interface in the hub's OSPF interface configuration

Why it fails: exchange-interface is an OSPF setting controlling whether interface addresses are carried in LSAs; it does not resolve the next-hop for dynamically created shortcut tunnels. It tempts because it sounds like it governs interface-level route exchange, yet the mandatory hub step is enabling the ADVPN setting so shortcut next-hops resolve.

Configure a static blackhole route for all spoke subnets on the hub

Why it fails: A static blackhole route for spoke subnets would discard traffic rather than resolve next-hops, preventing shortcut establishment. It tempts as a loop or summarisation safeguard, but ADVPN needs the hub to advertise spoke routes with next-hop resolution enabled so spokes can build direct tunnels.

Weight replaces the need for SD-WAN SLA rules by performing layer 7 packet inspection

Why it fails: Weight is a local BGP path-selection attribute that biases route preference; it performs no layer 7 inspection and does not replace SD-WAN SLA rules, which probe latency, jitter and packet loss. It tempts because weight does influence which path FortiOS prefers, but that is BGP best-path selection, not application-aware SLA steering.

Weight automatically adjusts the SD-WAN health check probe frequency based on route stability

Why it fails: Weight only influences BGP best-path selection on the local router; it has no mechanism to alter SD-WAN health check probe intervals, which are configured under the performance SLA settings. It tempts because both features concern path selection and link quality, so weight appears related to health checking, though they operate independently.

Weight is propagated to all iBGP peers, ensuring cluster-wide path synchronization

Why it fails: Weight is a Cisco-style attribute local to the router and is never carried in BGP updates to iBGP peers, so no cluster-wide synchronisation occurs. It tempts because other attributes such as local preference are propagated within an autonomous system, making weight seem similarly shared, but it is confined to the receiving device.

set mode aggressive

Why it fails: Aggressive mode changes IKE Phase 1 identity exchange, not shortcut signalling. Tempting because aggressive mode is used for dial-up peers with dynamic IPs, which suits some hub-and-spoke deployments, but ADVPN 2.0 shortcut creation depends on the Phase 1 parameter enabling exchange of shortcut offers.

set dhcp-interception enable

Why it fails: DHCP interception lets the FortiGate answer DHCP on an interface, unrelated to IPsec shortcut negotiation. Tempting because it appears in interface and tunnel-related configuration, so it is correct when clients behind the tunnel need DHCP service, but it does not enable spoke-to-spoke shortcut creation.

set pfs-group modp1024

Why it fails: PFS group defines Perfect Forward Secrecy encryption parameters, not ADVPN shortcut creation capability.

BGP Multipath relaxing with maximum-paths set to 32

Why it fails: Multipath with maximum-paths 32 only permits installing several equal-cost next hops into the routing table; it does not alter which prefixes the hub relays to spokes. The scenario needs route propagation control, such as a route reflector or route-map/community filtering, so spokes do not receive peer subnets via the hub before a shortcut exists.

Static default route redistribution with aggregate-address suppression

Why it fails: Redistributing a static default and suppressing aggregates changes what the hub originates, not how learned spoke prefixes are reflected between iBGP peers. Preventing spoke-to-spoke learning through the hub requires route reflection or outbound route-map filtering on the hub, which static redistribution cannot achieve.

BGP Confederation with each spoke acting as a separate autonomous system

Why it fails: Confederations partition a single autonomous system into sub-ASs to reduce iBGP full-mesh requirements; they do not stop the hub relaying one spoke's prefix to another. The scenario needs route reflection or route-map filtering controlling which prefixes the hub advertises to each spoke, independent of AS structure.

The SD-WAN health check probe is not monitoring the corporate subnet gateway

Why it fails: Health checks measure probe reachability and SLA for SD-WAN member selection; they do not enforce segmentation. Guest traffic still reaches corporate subnets because no policy blocks that inter-zone traffic. Health checks would be correct when selecting the best link by latency or jitter, not for restricting guest access.

The IPsec Phase 2 security association selectors include the guest subnet range

Why it fails: Including the guest subnet in Phase 2 selectors would widen the tunnel to carry guest traffic, the opposite of the requirement. The guest subnet should be excluded from the VPN selectors and blocked by a policy denying guest-to-corporate traffic; selectors define which traffic is encrypted, not which is permitted.

The SD-WAN rule priority for the internal VPN interface is set higher than the broadband interface

Why it fails: SD-WAN rule priority orders member link selection for matching traffic; it does not permit or deny flows. Guest access to corporate subnets persists because no firewall policy blocks that traffic. Priority ordering would be correct when choosing between two viable WAN links for the same traffic.

Check the firewall policy statistics to ensure SD-WAN rules have zero hit counts globally

Why it fails: Policy statistics count matches against firewall policies, not SD-WAN rule selection, so zero hits reveal nothing about shortcut negotiation. It is tempting because policy hit counts do diagnose broadly blocked traffic, and would be correct if spokes' underlay traffic were being dropped by a deny policy rather than failing ADVPN shortcut negotiation.

Execute 'execute format disk' to reset the internal flash storage and clear corrupted ADVPN certificates

Why it fails: Formatting internal flash erases all configuration and logs, destroying the evidence needed to diagnose shortcut failures, and does not target ADVPN certificates. It is tempting as a last-resort recovery when storage corruption is suspected, and would be correct only if FortiGate firmware or configuration files were genuinely corrupted.

Round-Robin DNS Load Balancing

Why it fails: Round-robin DNS load balancing distributes client queries across address records at the DNS layer, outside FortiOS SD-WAN rule strategy selection. It suits publishing multiple service endpoints, but SLA-based rules choose among members using measured latency, jitter and packet loss.

Dynamic BGP AS-Prepending

Why it fails: BGP AS-prepending manipulates inbound path selection on remote routers; it does not select an outbound SD-WAN member per session. It is correct for influencing which ISP a remote AS prefers, whereas SLA strategies pick members using measured latency, jitter and packet loss.

Static Flow-Hashing

Why it fails: Flow hashing distributes sessions across members statically, ignoring measured SLA values. It suits ECMP-style spreading where links are equivalent, but SLA-based rules must react to latency, jitter and packet loss thresholds, which static hashing cannot evaluate.

Configure the two IPsec tunnels as members of a redundant interface and reference that interface in the SD-WAN rule.

Why it fails: Redundant interfaces provide link-level failover, not session-level load balancing, and combining them with SD-WAN rule steering is not a supported way to distribute sessions across overlay members. Moreover, SD-WAN rules must reference SD-WAN members or zones, not redundant interfaces, so this configuration would not achieve the goal.

Enable 'preserve-session-route' on the SD-WAN rule to allow symmetric session distribution.

Why it fails: preserve-session-route is used to keep an existing session on its original member when a better member becomes available; it prevents mid-session re-selection and does not introduce load-balancing across members. Enabling it would reinforce the single-tunnel behavior rather than distribute new sessions, so it does not satisfy the requirement.

Add a second SD-WAN rule with the same destination and a higher priority, and reference the second tunnel.

Why it fails: Adding a lower-priority rule does not load-balance existing traffic; FortiOS evaluates rules top-down and the first matching rule wins, so the second rule is never consulted for sessions already matched. This approach also does not alter the per-rule selection strategy, so it fails to distribute sessions across the two overlay members as required.

Web Filtering requires SSL inspection to be enabled on the SD-WAN rule for all categories to be blocked.

Why it fails: While deep inspection can improve coverage for HTTPS, the primary issue is that profiles must be applied on the firewall policy, not the SD-WAN rule. Without the policy-level profile, even HTTP traffic is not filtered. SSL inspection on the SD-WAN rule is not a supported placement and would not address the missing policy enforcement.

The SD-WAN zone must be referenced in a separate 'security-profile' CLI section before profiles take effect.

Why it fails: There is no separate security-profile CLI section for SD-WAN zones. Security profiles are attached directly to firewall policies via the profile options. Creating such a section is not a supported configuration and would not cause or fix the inspection gap, making this an incorrect explanation for the observed behavior.

The IPsec tunnel must have 'inspection-mode' enabled for security profiles to inspect decrypted traffic.

Why it fails: IPsec tunnels do not use an inspection-mode setting; FortiGate inspects traffic after decryption as part of normal policy processing. Security profile enforcement is tied to the firewall policy, not to a tunnel-level mode. Enabling such a non-existent setting would not resolve the missing inspections, so this is not the cause.

execute router clear bgp all

Why it fails: This command clears BGP neighbour sessions, forcing route recalculation; it does not display shortcut tunnel state. It is tempting because it relates to BGP over ADVPN, but clearing sessions disrupts routing rather than reporting anything. Shortcut verification uses diagnostic commands that list active shortcuts and their states.

get system sdwan neighbor

Why it fails: The sdwan neighbour command reports SD-WAN health-check and SLA neighbour state, not ADVPN shortcut sessions. Shortcut tunnels are IPsec selectors negotiated between spokes, so the hub's shortcut state is inspected with diagnose vpn or get vpn ipsec tunnel commands; sdwan neighbour fits SD-WAN link monitoring instead.

diagnose netlink interface list

Why it fails: Netlink interface listing shows kernel-level interface and route entries, not ADVPN shortcut state; shortcut tunnels and their negotiation status are held in the ADVPN shortcut database, queried with diagnose vpn adVPN shortcut list. It tempts because netlink output does confirm tunnel interfaces exist, useful when checking whether an IPsec interface came up at all.

Directly inside the SD-WAN rule configuration under the advanced settings tab

Why it fails: SD-WAN rule advanced settings hold only steering criteria such as SLA targets, priority and load-balancing method; no security profile can be attached there. It tempts because the rule is what selects the member, so administrators assume inspection belongs with the steering logic, but profiles are enforced by a firewall policy referencing the SD-WAN zone.

Globally under the system settings as an SD-WAN overlay inspection profile

Why it fails: FortiOS has no global SD-WAN overlay inspection profile; security profiles are referenced per firewall policy, not system-wide. It tempts because centralising inspection sounds tidy and mirrors other global settings, yet the profile must be applied in the policy that permits traffic through the SD-WAN zone.

Within the IPsec tunnel phase 2 security association settings

Why it fails: Phase 2 security association settings define proxy IDs, PFS and selectors for the IPsec SA; they cannot host a Web Filtering profile. It tempts because the traffic traverses the tunnel, but inspection occurs in the firewall policy that references the SD-WAN zone, after decryption.

Disable DPD entirely so the FortiGate never tears down the tunnel

Why it fails: Disabling DPD removes failure detection entirely, so dead peers are never detected and traffic blackholes silently, contradicting the requirement to retain detection. It is tempting because it stops the flapping immediately, but the correct fix lengthens DPD retry intervals and timeouts to tolerate satellite latency.

Enable NP6/NP7 hardware offloading for Phase 1 SA renegotiation

Why it fails: Hardware offloading accelerates SA processing on NP6/NP7 chips but does not alter DPD timers or retry thresholds, so the satellite latency still triggers false peer-death declarations. It is tempting because offload reduces CPU load and improves throughput, which is the right fix when IPsec performance, not DPD sensitivity, is the bottleneck.

Change the IPsec phase 1 mode from Main mode to Aggressive mode

Why it fails: Aggressive mode changes how Phase 1 identities are exchanged, not how DPD detects peer liveness, so satellite latency still causes false timeouts. It is tempting because Aggressive mode completes negotiation in fewer packets, which suits dynamic-IP peers or faster IKE setup, not DPD tuning.

get system interface physical

Why it fails: Displays physical interface link state, speed, duplex and error counters, not health-check probe metrics. Tempting because interface faults can cause packet loss, so it is the right command when verifying cabling or NIC errors, but it exposes no latency, jitter or SLA data.

execute ping-server status

Why it fails: Reports FortiGate ping-server daemon status, not per-health-check-member SLA statistics. Tempting because it references ping and server reachability, so it fits confirming whether the ping server process is running, but it returns no latency, jitter or packet-loss figures for members.

show system sdwan

Why it fails: Prints the SD-WAN configuration itself — members, zones, SLA targets and rules — rather than live probe results. Tempting because it is SD-WAN-specific, so it is correct when auditing configuration, but it shows no real-time latency, jitter or packet loss per health check member.

OSPF sends a special multicast hello packet across the hub to establish mesh point-to-point links

Why it fails: OSPF multicast hellos build neighbour adjacencies on broadcast segments; they do not carry BGP-learned prefixes or trigger shortcuts. Tempting because OSPF over ADVPN is a valid design, so it is correct when running OSPF as the routing protocol, but this scenario uses BGP, whose next-hop triggers the shortcut.

FortiManager pushes a dynamic static route to both spokes simultaneously

Why it fails: FortiManager pushing static routes gives no on-demand tunnel initiation and cannot react to live traffic. Tempting because centralised route provisioning is valid for stable topologies, so it is correct when spokes need permanent routes, but ADVPN shortcuts are triggered dynamically by the spoke resolving the BGP next hop.

The Web Filtering profile intercepts the packet and redirects it via proxy to the destination spoke

Why it fails: Web Filtering inspects HTTP/HTTPS content and applies proxy-based category actions; it never redirects tunnel establishment. The shortcut is triggered by the hub advertising the peer's route with the ADVPN gateway/community attribute, prompting the spoke to send an IKE proposal directly. Web Filtering would be the right control for blocking or logging web categories, not for path negotiation.

The round-robin algorithm applied sequentially across all active links

Why it fails: Lowest Cost (SLA) selects the member with the lowest configured cost value among links meeting the SLA targets; round-robin is a separate load-balancing strategy. It tempts because round-robin does distribute sessions across members, and would be correct when even traffic spreading rather than cost-based preference is required.

The lowest physical port number on the FortiGate hardware

Why it fails: Interface selection under Lowest Cost (SLA) uses the configured cost metric of each SD-WAN member, not hardware port numbering. It tempts because physical port order can appear to determine default interface ordering in some configurations, but FortiOS ranks members by their assigned cost value instead.

The highest interface bandwidth capacity defined in the static route table

Why it fails: FortiOS derives the Lowest Cost metric from the SD-WAN member's configured cost value, not from interface bandwidth in the static route table. Bandwidth capacity is tempting because it intuitively reflects link quality, and it would matter when manually weighting members by throughput, but it plays no part in this strategy's selection.

probe-packet-size

Why it fails: probe-packet-size sets the size of the ICMP or HTTP payload sent by the health check, affecting fragmentation and MTU testing, not response validation. The parameter that defines the expected string in the HTTP response body is 'http-match', which FortiGate compares against the server's reply to mark the path healthy.

sla-break-time

Why it fails: sla-break-time sets how long an SLA must fail before the member is removed from SD-WAN selection; it never inspects HTTP payload content. The string expected in the response body is defined by the http-get match parameter. sla-break-time is tempting because it also tunes health-check behaviour, but it governs failure duration, not body validation.

server-response-timeout

Why it fails: server-response-timeout defines how long the FortiGate waits for the HTTP server to reply before marking the probe failed; it does not specify any string to match in the response body. That matching string is set by the http-get match parameter. server-response-timeout is tempting because it is configured within the same health-check, but it controls timing, not content validation.

IPsec VPN phase 2 selectors must be set to 0.0.0.0/0 for service-based rules to evaluate

Why it fails: Phase 2 selectors govern which subnets traverse the IPsec tunnel, not whether an SD-WAN rule evaluates service objects. The rule is skipped because the firewall policy lacks the SD-WAN rule's service object in its matching criteria, so traffic falls through to the static route. Narrow selectors are tempting when tunnels drop traffic, but that is a routing issue.

The firewall policy containing the traffic has SSL inspection disabled, preventing service-based identification

Why it fails: SSL inspection decrypts traffic for application control and threat inspection; it is not required for SD-WAN service objects such as HTTPS, which match on port and protocol. The rule is bypassed because the firewall policy does not reference the SD-WAN rule's service object, so the static route wins. SSL inspection would matter for application-based rules.

The FortiGate kernel requires hardware acceleration (NP7) to be disabled for service-based SD-WAN rules to function

Why it fails: NP7 offload is unrelated to SD-WAN rule evaluation; service-based rules function with hardware acceleration enabled. The rule fails because the firewall policy does not include the SD-WAN rule's service object, so matching traffic takes the default static route. Disabling acceleration is tempting when offload interferes with inspection, but not here.