Security Profiles Routing And IPsec practice questions

AS-PATH prepend

Why it fails: AS-PATH prepending is used to influence inbound traffic selection from external ASes, not primarily for internal SD-WAN tunnel path preference.

Cluster ID

Why it fails: Cluster ID is used in BGP route reflection loops prevention, not path selection.

Origin code

Why it fails: Origin code indicates how the BGP route was learned (IGP, EGP, Incomplete) and is not used for path preference tuning.

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

Why it fails: SD-WAN health check probes consume minimal bandwidth and do not cause application connection drops.

The Antivirus proxy buffer is overflowing due to UDP streaming packets

Why it fails: Antivirus inspection handles TCP streams primarily; UDP traffic goes through flow-based or proxy-based inspection differently and does not typically overflow buffers based on MTU mismatch.

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

Why it fails: SSL/TLS inspection applies to TCP traffic, not raw UDP streams.

Enable split-horizon globally within the OSPF routing process

Why it fails: Split-horizon is typically disabled or managed via non-broadcast multi-access (NBMA) settings in ADVPN, not globally toggled for this purpose.

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

Why it fails: Exchange-interface is not a standard FortiOS OSPF configuration command for ADVPN.

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

Why it fails: A blackhole route would drop traffic destined for the spokes.

Disable all security profiles on the SD-WAN interface zone

Why it fails: Disabling security profiles compromises network security and does not resolve classification issues.

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

Why it fails: Bypassing SD-WAN defeats the purpose of application-based steering.

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

Why it fails: Changing inspection mode globally does not fix application signature misclassification.

The round-robin algorithm applied sequentially across all active links

Why it fails: Round-robin is used for spillover or measured load balancing strategies.

The lowest physical port number on the FortiGate hardware

Why it fails: Port numbers have no bearing on SD-WAN path selection algorithms.

The highest interface bandwidth capacity defined in the static route table

Why it fails: Bandwidth capacity is used for bandwidth-based strategies, not Lowest Cost (SLA).

set mode aggressive

Why it fails: Aggressive mode is an IKE Phase 1 exchange method, not an ADVPN shortcut setting.

set dhcp-interception enable

Why it fails: This is not a valid ADVPN configuration parameter.

set pfs-group modp1024

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

Disable OSPF on the spoke units and rely entirely on static default routes

Why it fails: Relying solely on static default routes defeats the purpose of dynamic routing in ADVPN.

Set the IPsec phase 1 lifetime to infinite to prevent shortcuts from timing out

Why it fails: An infinite lifetime prevents shortcut cleanup and wastes dynamic resources.

Configure asymmetric routing bypass on all firewall policies

Why it fails: Asymmetric routing bypass disables strict state checking, which does not solve routing loops.

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

Why it fails: Health checks monitor WAN link quality, not internal zone access.

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

Why it fails: Phase 2 selectors determine encrypted VPN traffic, not local guest-to-corporate traffic isolation.

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

Why it fails: SD-WAN rules do not control traffic between internal zones unless explicitly routed through the SD-WAN virtual interface.

BGP Multipath relaxing with maximum-paths set to 32

Why it fails: Multipath is used for load balancing across multiple parallel paths to the same destination, not hub-and-spoke ADVPN route reflection.

Static default route redistribution with aggregate-address suppression

Why it fails: Aggregate suppression does not solve dynamic spoke-to-spoke route advertisement.

BGP Confederation with each spoke acting as a separate autonomous system

Why it fails: ADVPN uses iBGP or eBGP; confederations add unnecessary complexity and are not standard for simple spoke-hub ADVPN scaling.

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

Why it fails: SD-WAN hit counts do not diagnose IKE/IPsec shortcut negotiation failures.

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

Why it fails: Formatting disk erases all system data and is never a troubleshooting step for ADVPN.

ADVPN 2.0 automatically disables all firewall inspection profiles on shortcut interfaces to maximize throughput

Why it fails: ADVPN 2.0 does not automatically disable security inspection profiles on shortcut interfaces.

The hub FortiGate inspects all data packets exchanged between spokes even after a direct shortcut tunnel is established

Why it fails: Once an ADVPN shortcut is established, data packets flow directly between the spokes, bypassing the hub entirely.

Round-Robin DNS Load Balancing

Why it fails: Round-Robin DNS Load Balancing is not an SD-WAN rule strategy in FortiOS.

Dynamic BGP AS-Prepending

Why it fails: AS-Prepending is a BGP attribute manipulation technique, not an SD-WAN rule strategy.

Static Flow-Hashing

Why it fails: Static Flow-Hashing is not an SD-WAN rule strategy name.

A BGP route-map that matches the spoke-to-spoke prefixes and sets the next-hop to the hub.

Why it fails: A route-map can influence BGP path selection but does not trigger shortcut tunnel creation. In fact, setting the next-hop to the hub would prevent direct spoke-to-spoke routing. Shortcut tunnels are established based on ADVPN signaling, not BGP route-maps alone.

The 'set auto-discovery-receiver' command under the IPsec phase1-interface.

Why it fails: 'auto-discovery-receiver' enables a spoke to accept shortcut offers, but it does not trigger the creation of shortcut tunnels. The trigger is the hub's decision to send a shortcut offer when it detects traffic between spokes, which is controlled by 'auto-discovery-sender' and 'auto-discovery-shortcut' settings.

An SD-WAN rule with the 'SLA' strategy and a health check monitoring the overlay.

Why it fails: An SLA-based rule uses health check results to select the best path among existing members. It does not trigger the dynamic creation of new IPsec tunnels between spokes. Shortcut creation requires a specific ADVPN setting and BGP next-hop resolution, not merely an SLA strategy.

Set the 'input-device' to the internal interface.

Why it fails: The 'input-device' specifies the incoming interface for traffic matching. While it can be used to narrow matching, it is not required to prioritize Microsoft Teams. The prioritization is based on application identification and SLA, not on the input interface. Setting it incorrectly could exclude relevant traffic.

Set the 'tos' field to match the DSCP value of Microsoft Teams traffic.

Why it fails: While DSCP can be used for matching, it is not required for application-based prioritization. Microsoft Teams traffic may not always have a consistent DSCP marking, and the question specifies prioritization based on application control, not on ToS. Relying on ToS alone could miss traffic.

Configure an SLA health check and set the strategy to 'lowest-cost (SLA)'.

Why it fails: An SLA health check and strategy determine path selection among SD-WAN members, but they do not prioritize one application over another. Prioritization is achieved by assigning a higher priority to the Microsoft Teams rule, not by the strategy alone.

Configure a link health monitor for each tunnel and set the action to "disable" on failure.

Why it fails: Health monitors detect failures and can trigger actions like removing a member from the SD-WAN zone, but they do not disable the entire zone in the routing table. The action "disable" within a health check applies to the member interface, not the zone itself, so this would not enable the backup route as needed.

Create a policy route that redirects traffic to the backup interface when the SD-WAN zone is down.

Why it fails: Policy routes are evaluated before the routing table and can override SD-WAN decisions, but they do not automatically react to SD-WAN zone health. Without a dynamic trigger, the policy route would either always be active or never, not providing the desired failover based on tunnel health.

Set the SD-WAN zone's administrative distance to a higher value than the backup route.

Why it fails: Administrative distance is a static value and does not change based on health. Setting it higher would make the SD-WAN zone less preferred permanently, potentially causing the backup route to always be used even when tunnels are healthy, which is not the intended conditional failover.

Create a firewall address object for the tunnel and add it to an SD-WAN zone via a policy route.

Why it fails: Firewall address objects and policy routes do not control SD-WAN zone membership. Zone membership is determined by interface configuration, not by address objects or policy routes. This approach would not automatically assign the tunnel to the SD-WAN zone and could lead to misconfiguration.

Set the 'interface' parameter in the SD-WAN zone configuration to reference the tunnel.

Why it fails: The SD-WAN zone configuration does not have an 'interface' parameter that references tunnels. Instead, interfaces are added to zones either manually or via the tunnel's own configuration. This option misrepresents the FortiOS CLI structure and would not achieve the desired automatic assignment.

Enable 'auto-discovery' in the IPsec Phase 1 settings.

Why it fails: Auto-discovery is used for ADVPN shortcuts and does not assign interfaces to SD-WAN zones. It allows spokes to dynamically create shortcuts, but zone membership must still be configured manually or via other means. This option does not address the requirement of automatic zone assignment for the tunnel interface.

Enable 'dpd' (Dead Peer Detection) on the Phase 1 configuration.

Why it fails: Dead Peer Detection is used to detect a failed peer and trigger tunnel renegotiation, but it does not send keepalives to keep the tunnel alive during idle periods. DPD only sends probes when traffic is present or after a timeout, and it may tear down the tunnel if the peer is unresponsive. It is not designed to maintain idle tunnels.

Enable 'auto-negotiate' on the Phase 1 configuration.

Why it fails: Auto-negotiate allows the FortiGate to initiate the tunnel automatically when there is traffic, but it does not send periodic keepalives to maintain the tunnel during inactivity. It is useful for on-demand tunnels, but it does not prevent the tunnel from dropping after idle timeouts. This is not the correct setting for persistent connectivity.

Set the Phase 1 'nattraversal' to 'forced'.

Why it fails: Forcing NAT traversal is used when a device is behind NAT and both peers support it; however, it does not keep the tunnel alive during idle periods. It ensures UDP encapsulation for ESP packets, but the tunnel will still time out if no traffic is sent. This setting is not the primary mechanism for maintaining an idle tunnel.

Use RIP with split horizon disabled on all ADVPN interfaces.

Why it fails: RIP is not used in ADVPN 2.0 deployments for shortcut route installation. RIP has limitations in scalability and convergence, and FortiOS ADVPN 2.0 is designed to work with BGP. Disabling split horizon might help with route propagation in RIP, but it does not address the dynamic shortcut route installation required here.

Enable OSPF with point-to-multipoint network type on all ADVPN interfaces.

Why it fails: OSPF point-to-multipoint is useful for broadcast networks, but it does not automatically install shortcut routes in ADVPN 2.0. ADVPN 2.0 relies on BGP for shortcut route propagation, not OSPF. OSPF would require additional configuration and does not have the built-in shortcut discovery mechanism that BGP provides in this context.

Configure BGP with the 'advertise-shortcut' option under the neighbor configuration.

Why it fails: The 'advertise-shortcut' option is not a valid BGP configuration parameter in FortiOS for ADVPN. While BGP is used, the shortcut route installation is triggered by the exchange of BGP routes over the shortcut tunnel once it is established. The hub advertises the shortcut route to the spokes, but there is no specific 'advertise-shortcut' command.

Enable 'inbound' and 'outbound' filters in Phase 2.

Why it fails: FortiOS IPsec Phase 2 does not have 'inbound' or 'outbound' filter options. Traffic filtering is typically handled by firewall policies that reference the tunnel interface. Enabling such filters is not a valid configuration step; the correct approach is to define the quick mode selectors and then use firewall policies to control traffic.

Set the Phase 2 'src-name' and 'dst-name' to the desired subnets.

Why it fails: The 'src-name' and 'dst-name' parameters in Phase 2 are used to specify the source and destination addresses for the quick mode selectors, but they do not enforce traffic filtering. They are used to negotiate the tunnel, not to drop traffic. Additional firewall policies are needed to permit or deny traffic; the selectors alone do not drop traffic.

Set the Phase 2 'keylifeseconds' to a low value to force rekeying and drop non-matching traffic.

Why it fails: The 'keylifeseconds' parameter controls the lifetime of the IPsec security association (SA) and triggers rekeying after the specified time. It does not filter traffic based on subnets. Lowering this value may cause more frequent rekeying but will not drop traffic that does not match the desired subnets; it is unrelated to traffic selection.

The SD-WAN rule's 'Gateway' must be set to the remote gateway IP of Overlay_A.

Why it fails: The 'Gateway' field is used to specify the next-hop IP for a member, typically when the member is an interface without a default gateway. It does not restrict the rule to a specific member; the rule still selects among all members in the SD-WAN zone. Setting the gateway to Overlay_A's remote IP does not prevent other members from being used.

The SD-WAN rule's 'Priority' member list must include only Overlay_A.

Why it fails: The 'Priority' member list is used in the manual strategy to define the preferred order of members. It does not enforce exclusive membership; if other members are in the SD-WAN zone, they can still be selected when the priority member fails or when the rule uses a different strategy. This does not guarantee that only Overlay_A is eligible for the Microsoft 365 rule.

The SD-WAN rule's 'Source' must be set to the local subnet that uses Microsoft 365.

Why it fails: The source address is used to match traffic that should be handled by the rule. It helps identify which traffic the rule applies to, but it does not control which SD-WAN members are eligible for egress. Even with the correct source, the rule could still select the underlay if it remains in the member list.