Troubleshooting practice questions

diagnose vpn ike gateway list

Why it fails: This command displays IKE gateway information, such as phase-1 status, remote gateway, and encryption details. It does not show routing or traffic flow through the tunnel. While useful for verifying phase-1, it does not help diagnose why traffic is not passing through the tunnel due to routing. Therefore, it is not the correct command for this scenario.

diagnose ip route list

Why it fails: This command lists the routing table, which can help verify if routes are present. However, it does not show which route a specific packet would take. It only shows the static and dynamic routes. To verify that traffic for a specific destination is routed through the tunnel, you need a more specific command that shows the route lookup for a given IP address.

diagnose firewall iprope list

Why it fails: This command lists the firewall's IP rope, which includes policy routes and other routing information. It is not the standard command to check the routing table for a specific IP. It may show some route information, but it is not as direct as using 'diagnose ip route list' or 'get router info routing-table'. For verifying routing of specific traffic, a more precise command is needed.

Enable 'Auto-Update' on the device in FortiManager

Why it fails: Auto-Update is a feature that automatically retrieves and installs configuration changes from FortiManager to the device, but it does not retrieve the device's configuration into FortiManager. Enabling it would not help compare configurations; it would potentially push FortiManager's configuration to the device, overwriting local changes. It is not a troubleshooting tool for configuration drift.

Run 'Import Configuration' from the Policy & Objects

Why it fails: FortiManager does not have a standalone 'Import Configuration' function under Policy & Objects. Importing configuration is typically done via the 'Retrieve Config' option in Device Manager or by using the 'Import Policy' wizard, but the latter is for importing policies from a device into a policy package, not for retrieving the full configuration. The scenario requires retrieving the entire configuration to compare, not just policies.

Use the 'Install Wizard' to push the FortiManager configuration to the device

Why it fails: The Install Wizard is used to install policy packages and device settings from FortiManager to the managed FortiGate, not to retrieve the device's configuration. Using it here would overwrite the device's local changes, which is the opposite of what the administrator wants when trying to identify differences. It does not help in comparing configurations.

get system status

Why it fails: get system status returns firmware version, serial number and uptime, not CPU consumption by process. It is tempting because it is a familiar first command on any FortiGate, and would be correct for verifying the FortiOS build before comparing behaviour against known IPS engine issues.

diagnose hardware status

Why it fails: diagnose hardware status reports sensor temperatures, fan and power supply states, which says nothing about which process consumes CPU. It is tempting because hardware faults can cause high CPU, and it would be the right command when suspecting thermal throttling or failing components rather than an IPS engine.

show sys resource

Why it fails: show sys resource displays system-wide CPU, memory and session totals, not per-process breakdown, so it cannot attribute load to the IPS engine. It is tempting as a quick health snapshot, and would be correct for confirming overall device saturation before drilling into individual daemons.

SNMP community strings and syslog server settings

Why it fails: SNMP community strings and syslog server settings are not synchronized by default. They are management-plane configurations that often differ per unit for monitoring purposes. Administrators must manually configure or enable synchronization for these settings if they want them replicated across the cluster.

The FortiGate hostname and administrative passwords

Why it fails: The hostname and administrator passwords are not synchronized by default because they are considered per-device settings. Each unit can have a unique hostname for identification, and password synchronization must be explicitly enabled. This prevents an attacker who compromises one node from automatically gaining credentials for the other.

The cluster's virtual MAC address and HA priority

Why it fails: The virtual MAC address is a cluster-wide setting that is already identical on all nodes, and HA priority is a per-device setting that determines which unit becomes primary. Neither is part of the configuration synchronization process; they are HA operational parameters configured independently or set identically as part of HA setup.

Traffic that is subject to simple firewall policies without UTM.

Why it fails: Simple firewall policies that only allow or deny traffic based on IP addresses and ports are typically offloaded to the NP6 processor. The NP6 is designed to handle these basic forwarding and filtering tasks at high speeds, so they do not contribute significantly to CPU usage.

Traffic that uses NAT with a small number of concurrent sessions.

Why it fails: NAT is a common function that is offloaded to the NP6 processor. Even with many concurrent sessions, NAT operations are handled in hardware. A small number of sessions would certainly not cause high CPU usage; this traffic type is efficiently processed by the NP6.

Traffic that is routed between VLAN interfaces on the same physical interface.

Why it fails: Inter-VLAN routing on the same physical interface is generally offloaded to the NP6 processor, as it involves standard Layer 3 forwarding. The NP6 can handle this traffic efficiently, so it is unlikely to be the cause of high CPU usage.

Session table

Why it fails: The session table shows active sessions and their state, including the policy ID that allowed them. However, it only shows sessions that are already established. If traffic is being blocked, there may be no session, so the session table would not show a matching policy. It is useful for confirming existing sessions but not for pre-emptively checking policy match.

Debug flow

Why it fails: Debug flow is a powerful CLI tool that traces packet processing and can show which policy a packet matches. However, it requires generating the actual traffic and interpreting verbose output. It is more complex than policy lookup and is not a simple lookup tool. It is useful for deep troubleshooting but less direct for verifying policy order.

Packet capture

Why it fails: Packet capture allows you to capture packets on an interface for analysis, but it does not tell you which policy matched. You would need to analyze the capture and correlate with logs to infer policy matching. It is not a direct tool for policy lookup and is more useful for seeing actual traffic.

diagnose sys session stat

Why it fails: This command provides statistics about the session table, such as the number of sessions and memory usage. It does not list individual offloaded sessions or provide details about which sessions are offloaded. It is useful for overall session health but not for verifying offload of specific traffic.

diagnose debug flow filter

Why it fails: This command is used to set filters for debug flow, which traces packet processing through the CPU. It does not show offloaded sessions because offloaded traffic bypasses the CPU and thus does not appear in debug flow output. Therefore, it cannot be used to verify offload status.

diagnose sys session list

Why it fails: This command lists all current sessions and includes information about offloading status, but it is not the most direct command to verify offload specifically. It provides a comprehensive session list, which can be overwhelming. While it does show offload flags, the administrator would need to filter or interpret the output. A more specific command exists for offload diagnostics.

Policy package installation history

Why it fails: Installation history shows previous installs and their statuses, but if the install was successful, it does not explain why the FortiGate lacks the change. The issue is likely due to a workflow state, such as a pending workspace or unapproved change. Checking history would confirm the install occurred but not why the configuration didn't take effect on the device.

FortiGate's local configuration backup

Why it fails: The FortiGate's local configuration backup reflects the device's current settings, but it does not explain why a FortiManager-installed policy is missing. The issue is on the FortiManager side, likely due to workflow approval. Checking the FortiGate backup would only confirm the policy is absent, not the reason. The engineer should focus on FortiManager's workflow state.

ADOM revision control

Why it fails: ADOM revision control tracks changes to the ADOM configuration, but it is not the primary cause for a policy not applying after a successful install. The engineer should first verify if the policy was part of the installed package. Revision control helps revert changes but does not explain why a successfully installed policy is absent on the FortiGate.

Use the 'Revision History' to revert to a previous policy package version that did not have the duplicate object.

Why it fails: This is incorrect because reverting to a previous version might temporarily resolve the issue but does not identify the duplicate object. It also discards any legitimate changes made since that revision. The administrator needs to identify and resolve the specific conflict, not avoid it by rolling back.

Use the 'Device Manager' to compare the FortiGate's configuration with the policy package and find duplicate objects.

Why it fails: This is incorrect because the Device Manager provides a view of the device's configuration, but it does not automatically compare it with the policy package to highlight duplicate objects. While an administrator could manually inspect both, it is not an efficient or reliable method compared to the Installation Preview.

Use the 'Policy Check' feature to validate the policy package for conflicts before installation.

Why it fails: This is incorrect because Policy Check validates policy consistency and potential issues but does not specifically detect duplicate object names across the policy package and device configuration. It focuses on policy rules and their interactions, not on object name collisions. It would not directly identify the duplicate object causing the installation failure.

Check that the phase 1 proposal includes a matching pre-shared key.

Why it fails: A mismatched pre-shared key would cause phase 1 to fail, resulting in errors like 'PSK_MISMATCH' or authentication failures. The error 'NO_PROPOSAL_CHOSEN' occurs during phase 2, after phase 1 is established. Therefore, the pre-shared key is not the cause of this specific error.

Ensure that the local and remote subnets in the phase 2 selectors are identical.

Why it fails: Mismatched phase 2 selectors typically cause traffic to not match the tunnel, but they do not generate 'NO_PROPOSAL_CHOSEN' errors. That error is specifically about proposal mismatches. Selector mismatches would result in traffic being dropped or sent unencrypted, but the tunnel itself might still be up.

Restart the IKE daemon on both FortiGates to clear stale security associations.

Why it fails: Restarting the IKE daemon might temporarily clear the error, but it does not fix the underlying proposal mismatch. The tunnel would fail again on the next negotiation. The permanent solution is to align the phase 2 proposals on both peers, not to restart services.

diagnose sniffer packet any 'host <peer-ip> and port 500' 4

Why it fails: Packet sniffing can show IKE packets on the wire, but it does not decode the IKE payload or provide FortiGate's internal processing details. It can be useful to confirm packets are reaching the FortiGate, but it is less detailed than IKE debug for understanding negotiation failures.

diagnose vpn ike gateway list

Why it fails: This command lists the current IKE gateways and their status but does not provide detailed negotiation logs. It is useful for a quick check of whether the gateway is up, but it does not show the exchange of proposals or errors during negotiation. It is not the most detailed for troubleshooting.

get vpn ipsec tunnel details

Why it fails: This command displays details about established tunnels, such as encryption and traffic statistics, but it does not show the negotiation process. It is useful for verifying an active tunnel's parameters, not for diagnosing why a tunnel is not coming up.

get system ha status

Why it fails: This command shows the HA status, including which unit is primary and the cluster uptime, but it does not provide configuration checksums or detailed synchronization status. It is useful for basic HA health but not for troubleshooting sync issues.

diagnose debug application hatalk -1

Why it fails: This command enables debugging for the HA talk protocol, which can show HA communication messages. While it can be used for advanced troubleshooting, it does not directly show configuration checksums or sync status. It is not the primary command for verifying synchronization.

execute ha synchronize start

Why it fails: This command manually triggers a configuration synchronization from the primary to the secondary. It is used to force a sync, but it does not verify the current synchronization status or show checksums. It is a corrective action, not a diagnostic one.

diagnose sniffer packet

Why it fails: Captures live packets traversing an interface, showing traffic rather than the chosen route. Tempting for confirming whether packets leave FortiGate, but it cannot display which next-hop or interface the routing lookup selected for a specific IP.

get system status

Why it fails: `get system status` reports firmware version, uptime, HA state and licence details, not routing lookups. It tempts because it is the standard first diagnostic for confirming build and serial numbers during support cases. For tracing a route to a specific IP, `get router info routing-table details <ip>` is the correct command.

exec ping-options

Why it fails: Sets source interface, source address and packet size for subsequent pings; it performs no route lookup itself. Tempting because ping-options is used in connectivity testing, yet it only configures echo parameters, not the routing table entry for a destination.

Force an 'Import Policy' operation

Why it fails: Import Policy pulls the device's current configuration into FortiManager, overwriting the manager's database; it cannot reveal which object differs between the two. It is tempting because import is the standard way to resynchronise a device, but that is a remediation step, not diagnosis — the conflict must first be identified via policy diff or revision comparison.

Reboot the FortiManager

Why it fails: Rebooting FortiManager only restarts services; the configuration conflict persists in the database and no comparison is produced. It is tempting as a generic first-line fix for stuck installations, but rebooting is appropriate for hung daemons or memory exhaustion, not for identifying which policy or object differs between FortiManager and the managed FortiGate.

Disable the policy package entirely

Why it fails: Disabling the policy package removes it from installation scope, hiding the conflict rather than revealing which object or attribute clashes. FortiManager's conflict detection requires comparing the package against device configuration, typically via installation preview or revision diff. Disabling is tempting as a quick workaround, but it eliminates the diagnostic evidence needed to identify the mismatch.

diagnose sys process pid list

Why it fails: The 'diagnose sys process pid list' command lists processes with their PIDs, but it does not show CPU usage. It is useful for finding the PID of a process for other commands, but it does not provide the CPU consumption data needed to troubleshoot high CPU usage. To see CPU usage per process, a different command is required.

diagnose test application ipsmonitor 99

Why it fails: The 'diagnose test application ipsmonitor 99' command is used to display statistics about the IPS monitor, such as the number of IPS engines and their status, but it does not show real-time CPU usage. It provides operational data but not the CPU consumption of the IPS engine process itself. To see CPU usage, a process monitoring command is needed.

get system performance status

Why it fails: The 'get system performance status' command provides a summary of system performance, including CPU usage, memory usage, and network utilization, but it does not break down CPU usage by individual processes. It gives an overall view, not per-process details, so it cannot specifically identify the IPS engine's CPU usage.