Troubleshooting practice questions

The Phase 2 replay window size, which must be set to the same value on both peers.

Why it fails: The replay window size is a local anti-replay parameter and does not need to match on both peers. It affects how many out-of-order packets are accepted, but it does not influence Phase 2 negotiation. Mismatched replay windows will not prevent the tunnel from establishing, so this is not a requirement.

The Phase 2 key lifetime, which must be identical in seconds on both peers.

Why it fails: Phase 2 key lifetime does not need to be identical; the shorter lifetime will trigger rekeying, and the peers will negotiate a new SA. Mismatched lifetimes do not prevent the tunnel from coming up. While it is good practice to align lifetimes, it is not a strict requirement for Phase 2 negotiation success.

The Phase 2 local and remote subnets, which must be mirrored exactly on both peers.

Why it fails: Phase 2 selectors (local and remote subnets) must be complementary, not identical. On one peer the local subnet should match the other peer's remote subnet. If they are mirrored incorrectly, the tunnel may still negotiate but traffic will not match the selectors. The question asks what must match for the tunnel to come up, which is the proposal.

The tunnel interface is not added to the SD-WAN zone.

Why it fails: If the tunnel were not in the SD-WAN zone, it would not be monitored by the health check at all. The scenario implies the tunnel is part of the SD-WAN zone because health checks are failing and marking it down. Therefore, this is not the cause.

The SD-WAN health check is configured with the wrong protocol (e.g., HTTP instead of ping).

Why it fails: The protocol mismatch could cause health check failures if the server does not respond to that protocol. However, the administrator has not indicated that the protocol is wrong; it is a possibility but less likely than a routing issue. The scenario states the administrator verifies selectors, implying other basic checks are done. Routing is a more fundamental and common cause.

The IPsec tunnel's Phase 1 proposal does not match the remote gateway.

Why it fails: If the Phase 1 proposal did not match, the tunnel would not come up at all. The scenario states the tunnel is up, so Phase 1 is correctly negotiated. Therefore, this is not the cause of health check failures.

The health check server IP is not reachable from the FortiGates.

Why it fails: If the health check server were unreachable, the health check would fail, but the configuration would still show the correct server IP. The issue described is that the FortiGates are not using the expected server, not that the check is failing. Therefore, reachability is not the primary cause of the discrepancy in configuration.

The FortiGates are running an older FortiOS version that does not support the configured health check protocol.

Why it fails: If the FortiOS version did not support the protocol, the health check would fail or not be configurable, but the server IP would still be present. The issue is the server IP itself being different, not the protocol. Version mismatch might cause other problems but not this specific discrepancy.

The SD-WAN template was not installed on those FortiGates.

Why it fails: If the template was not installed, the SD-WAN configuration might be missing entirely, but the administrator has already installed the template. The issue is that the health check server is different from expected, not that it is absent. So this is unlikely.

The VLAN interface was added to the zone but is not configured as a member of the SD-WAN rule, so it is not eligible for selection.

Why it fails: SD-WAN rules reference SD-WAN zones, not individual member interfaces. When an interface is added to a zone, it becomes available to all rules that reference that zone. There is no separate step to add a member to a rule; doing so is not part of the configuration model. This option misstates the relationship between zones, members, and rules.

The VLAN interface must be assigned an IP address and have an administrative distance lower than the existing members before it can be used in the zone.

Why it fails: Administrative distance affects route selection, not SD-WAN member eligibility. A VLAN interface used as an SD-WAN member does not require a lower distance than other members; the SD-WAN rule and SLA health determine path selection. The absence of an IP address would prevent the interface from participating in health checks, but the scenario states the interface was added successfully to the zone, so the issue is elsewhere.

The VLAN interface is not referenced in any firewall policy, so the FortiGate cannot forward traffic through it.

Why it fails: A firewall policy referencing the SD-WAN zone (not the individual member) is required for traffic to be processed. Once the interface is a member of the zone, existing policies that reference the zone automatically include the new member. The absence of a dedicated policy for the VLAN interface is not the cause; the zone-level policy covers all members, and the scenario implies the zone was already in use.

Confirm that member1 has a lower cost than member2.

Why it fails: Cost is used by the 'Lowest Cost (SLA)' strategy, not by 'Best Quality'. In 'Best Quality', the member with the best measured quality (lowest latency, jitter, and packet loss) is selected regardless of cost. Therefore, cost differences would not cause member2 to be chosen over member1 when member1 has better quality.

Ensure that the Performance SLA is configured with the 'Best Quality' algorithm.

Why it fails: The Performance SLA does not have an algorithm setting; it only defines probes and thresholds. The 'Best Quality' strategy is a property of the SD-WAN rule, not the SLA. Configuring the SLA differently would not change how the rule selects members based on quality metrics.

Verify that the 'Best Quality' strategy is supported on the FortiGate model.

Why it fails: 'Best Quality' is a standard SD-WAN strategy available on all FortiGate models that support SD-WAN. It is not model-dependent. Checking model support would not explain why a lower-quality member is being used when a higher-quality member is available. The issue is more likely related to rule order or SLA binding.

Member2 is not being used because its health check is failing, even though it appears to be passing in the GUI.

Why it fails: The scenario explicitly states that both members are passing their SLA health checks. Therefore, a failing health check is not the cause. The behavior is expected due to the Lowest Cost (SLA) strategy's selection logic. Introducing a health-check failure would contradict the given information and mislead troubleshooting.

Member2 is not being used because it is not included in the SD-WAN rule, even though it is in the zone.

Why it fails: The scenario states that the rule includes two members: member1 and member2. Therefore, member2 is part of the rule. The issue is not inclusion but the strategy's selection logic. The Lowest Cost (SLA) strategy will only use member2 if member1 becomes unhealthy or if member2's cost is lower, which is not the case here.

Member2 is not being used because its cost is higher than member1's, and the strategy requires equal costs for load balancing.

Why it fails: The Lowest Cost (SLA) strategy does not require equal costs for load balancing; in fact, it does not load-balance at all. It simply picks the lowest-cost healthy member. The higher cost of member2 is the reason it is not selected, but the explanation that equal costs are needed for load balancing is incorrect because load balancing is not the behavior of this strategy.

The SD-WAN rule is configured with a manual interface selection instead of using the SLA.

Why it fails: If the rule were configured with manual interface selection, it would not use the SLA to select the best path. However, the scenario states that the rule uses a performance SLA, so this is not the cause. The issue is more likely related to the SLA configuration or monitoring.

The SD-WAN template was applied to the wrong device group.

Why it fails: If the template was applied to the wrong device group, it would not be installed on the intended FortiGate. However, the scenario states that the template was installed successfully on the FortiGate, so this is not the issue. The problem is with the rule enforcement, not the template deployment.

The FortiGate does not support SD-WAN performance SLAs.

Why it fails: FortiGates that support SD-WAN generally support performance SLAs. If the FortiGate did not support it, the template installation would likely fail or not include the SLA. Since the template was installed successfully, this is unlikely to be the cause.

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 restrict which subnets traverse a tunnel; they do not gate SD-WAN rule evaluation, and 0.0.0.0/0 selectors are a common configuration choice for route-based VPNs, not a requirement. Mismatched selectors cause tunnel traffic to be dropped or routed elsewhere, not service matching to be skipped.

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

Why it fails: SSL inspection decrypts traffic so application signatures can identify it, but SD-WAN service objects such as HTTPS match on destination port and protocol, which remain visible without decryption. Disabling inspection would instead break application-control rules that rely on deep packet inspection of encrypted sessions.

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

Why it fails: SD-WAN service and application rules are evaluated in the kernel's session setup path and work with NP7 acceleration enabled; hardware acceleration is not a prerequisite to disable. Disabling it is used when troubleshooting offload-related session or inspection anomalies, not to make service-based steering match.

get system interface physical

Why it fails: get system interface physical reports interface link state, speed and counters, not the SLA probe measurements for health check members. It is tempting when packet loss suggests a physical link fault, and would be correct for confirming a down or flapping port, but latency, jitter and loss come from the health-check diagnostics.

execute ping-server status

Why it fails: execute ping-server status shows the status of the ping server daemon, not the per-member SLA measurements the administrator needs. It is tempting because ping relates to reachability testing, and would be correct for checking whether the ping server is running, but it exposes no latency, jitter or packet loss figures.

show system sdwan

Why it fails: show system sdwan displays overall SD-WAN configuration and status, not per-member latency, jitter and packet loss for a health check. It is tempting because it is the obvious SD-WAN command, and would be correct for verifying general SD-WAN operation, but the diagnostic detail lives in the health-check diagnostics output.

The SD-WAN rule is disabled.

Why it fails: A disabled rule is simply skipped, so traffic would never be evaluated against it; the stem states criteria are met, implying the rule is active. Disabling is tempting as an obvious toggle, but the actual cause is that the rule's source, destination or application does not match the flow.

The Performance SLA has timed out.

Why it fails: A Performance SLA timeout marks a member unhealthy and removes it from selection, but the rule itself still matches traffic and steers it to remaining members. A rule that is configured but never matched usually stems from a missing or misordered reference in the policy route.

The interface is not in an SD-WAN zone.

Why it fails: An interface outside any SD-WAN zone cannot carry SD-WAN traffic, so the rule would have no member links to select and traffic would bypass it. This is tempting because zone membership is required, but the stem says criteria are met, pointing instead to a disabled rule.

execute ipsec tunnel list

Why it fails: Enumerates IPsec tunnel names, gateways and status, confirming Phase 1/Phase 2 state but not BGP neighbour relationships or prefix advertisements. It is tempting because BGP over IPsec depends on the tunnel being up, making it the right first check when tunnels are flapping, yet here the tunnel is presumably established and routes are missing.

diagnose sys sdwan member

Why it fails: Displays SD-WAN member link status, SLA and path selection, not BGP peering state or advertised prefixes. It is tempting because SD-WAN tunnel health directly affects whether IPsec overlays carry traffic, making it the right tool when members are down or SLA probes fail, but here the BGP session itself needs inspection.

get system interface physical

Why it fails: Lists physical interface link state, speed and duplex, offering nothing about BGP neighbour adjacency or route advertisement. It is tempting because a down underlay interface would break the IPsec tunnel and hence BGP, making it correct when you suspect a physical-layer fault, but the stem already presumes tunnels are established.

The health check probes are not configured on the higher bandwidth tunnel, so it is not considered.

Why it fails: If health checks were not configured on the higher bandwidth tunnel, it would not be a member of the SD-WAN zone with SLA monitoring, and the rule might not consider it at all. However, the scenario states that the tunnel is up and passing health checks. So this is not the case. The issue is more likely that the tunnel is not meeting the SLA thresholds, not that health checks are missing. This option contradicts the given information.

The SD-WAN rule is misconfigured; the 'maximize-bandwidth (SLA)' strategy always uses the tunnel with the lowest cost.

Why it fails: The 'maximize-bandwidth (SLA)' strategy does not use cost; it selects the tunnel with the highest bandwidth that meets SLA. Cost is used in 'lowest-cost (SLA)' strategies. Therefore, the rule is not misconfigured in that sense. The behavior is likely due to SLA failure on the higher bandwidth tunnel. This option incorrectly describes the strategy's behavior, leading to a wrong conclusion.

The SD-WAN rule is using the 'maximize-bandwidth (SLA)' strategy, but the higher bandwidth tunnel is in a different SD-WAN zone.

Why it fails: If the higher bandwidth tunnel were in a different SD-WAN zone, it would not be a member of the zone referenced by the rule, and thus not considered. However, the scenario implies both tunnels are part of the same SD-WAN rule. The rule includes two tunnels, so they are likely in the same zone. The issue is not zone membership but SLA compliance. This option introduces an unlikely configuration error that is not supported by the scenario.

fmg_event.log

Why it fails: fmg_event.log records daemon and system events, not the per-command template installation output, so it cannot pinpoint the failing CLI line. It is tempting because event logs surface general FortiManager errors, and would be the right choice when diagnosing service restarts or unexpected daemon behaviour rather than template push failures.

fmg_audit.log

Why it fails: fmg_audit.log records configuration changes and administrative actions, showing that a template install was attempted but not the individual CLI command that failed. It is tempting because audit trails track who changed what, and would be the right choice when attributing configuration modifications to an administrator rather than debugging push failures.

fmg_system.log

Why it fails: fmg_system.log captures FortiManager system-level activity such as administrative and background operations, not the CLI-by-CLI result of a template install to a managed FortiGate. It is tempting because system logs reveal platform faults, and would be correct when investigating FortiManager host issues rather than SD-WAN template deployment errors.

Use the FortiGate CLI to manually apply the configuration.

Why it fails: Manually applying the configuration bypasses FortiManager and does not help diagnose the template installation failure. It may also lead to configuration drift. The goal is to fix the template deployment process, not to work around it.

Restart the FortiGate to clear any temporary issues.

Why it fails: Restarting the FortiGate is unlikely to resolve a configuration installation failure. The issue is typically due to a configuration mismatch or error, not a transient device problem. Restarting does not provide diagnostic information and may disrupt network operations.

Delete and recreate the SD-WAN template from scratch.

Why it fails: Deleting and recreating the template is a drastic step that does not help identify the root cause. It may temporarily resolve the issue if the template was corrupted, but it does not provide insight into why the installation failed. Troubleshooting should focus on diagnostics first.

The SD-WAN rule is configured with a higher sequence number than the default route.

Why it fails: SD-WAN rules are evaluated in sequence order, but the default route is not an SD-WAN rule. The default route is a static route in the routing table. SD-WAN rules are applied to traffic that matches their criteria, regardless of the default route, as long as the traffic is routed through the SD-WAN zone. A higher sequence number only affects the order among SD-WAN rules, not the interaction with the default route. Therefore, this is not the cause.

The SD-WAN members are not configured with a gateway, so the SLA cannot determine the next hop.

Why it fails: If the members lacked a gateway, the SLA probes would likely fail, and the members would be considered down. However, the scenario states that the SLA is up on both members, so the gateway must be correctly configured. Even if the gateway were missing, the symptom would be SLA failure, not the rule being bypassed. Therefore, this is not the cause of the rule not being matched.

The Performance SLA probes are using the wrong protocol for VoIP traffic.

Why it fails: The Performance SLA protocol (e.g., ping, HTTP, TCP) is used to measure latency and determine member health. It does not need to match the application protocol. VoIP traffic can be matched by the SD-WAN rule based on its own criteria, and the SLA simply provides the latency measurements. Using a different probe protocol does not prevent the rule from being matched. Therefore, this is not the likely cause.