Troubleshooting Scenario 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.

Create a firewall policy from the internal interface to the external interface with NAT enabled.

Why it fails: In transparent mode, the FortiGate acts as a Layer 2 bridge, so NAT is not applied and would break the transparent behavior. A policy is required, but enabling NAT is incorrect because the FortiGate does not perform address translation in this mode. NAT would only be relevant in NAT/route mode, not when bridging traffic between interfaces.

Configure a static route on the FortiGate pointing to the external router.

Why it fails: In transparent mode, the FortiGate does not perform routing; it bridges traffic between interfaces. Static routes are used in NAT/route mode where the FortiGate makes forwarding decisions based on routing table. Adding a static route would not help because the FortiGate is not acting as a router in this scenario.

Enable DHCP on the internal interface to provide IP addresses to users.

Why it fails: Enabling DHCP on the internal interface would provide IP addresses to clients, but the issue is that traffic is not being forwarded. The FortiGate already has connectivity to the internet, so the problem is likely a missing firewall policy. DHCP configuration is unrelated to the forwarding of existing traffic in transparent mode.

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.

Incorrect IPsec phase 2 key lifetime.

Why it fails: The phase 2 key lifetime determines how often keys are renegotiated. If mismatched, it can cause intermittent drops, but the tunnel would still pass some traffic initially. Since the tunnel is up and no traffic passes at all, a lifetime mismatch is unlikely to be the sole cause.

The remote gateway IP address is incorrect.

Why it fails: An incorrect remote gateway would prevent phase 1 negotiation, so the tunnel would not be up. Since the tunnel is established, the remote gateway is correct. The problem is more likely related to routing or policy after the tunnel is up.

The phase 1 proposal mismatch.

Why it fails: A phase 1 proposal mismatch would prevent the tunnel from coming up in the first place. Since the tunnel is up, phase 1 is established, so a mismatch there is not the cause. The issue lies elsewhere, likely in routing or policy ordering.

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.

Incorrect IKE version

Why it fails: IKE version is negotiated during Phase 1; a mismatch there prevents Phase 1 completing, so Phase 2 is never reached. It is tempting because both phases share proposal settings, and it would be the correct choice when Phase 1 itself fails with a version or proposal error.

Expired certificate

Why it fails: Certificate expiry breaks IKE authentication during Phase 1, so the tunnel fails before Phase 2 proposals are exchanged. It is tempting because certificates appear in VPN configuration, and it would be the correct choice when Phase 1 authentication fails with a certificate validation error.

Mismatched pre-shared key

Why it fails: A mismatched pre-shared key fails Phase 1 authentication, so Phase 2 is never negotiated. It is tempting because both peers must match secrets, and it would be the correct choice when Phase 1 stalls with authentication failure rather than Phase 2 proposal errors.

Set the redundant interface's IP address to 0.0.0.0 to allow DHCP.

Why it fails: The IP address configuration is independent of the interface's ability to pass traffic. Setting the IP to 0.0.0.0 disables IP processing on the interface and would not enable traffic forwarding. The missing member interfaces are the actual cause of the problem.

Configure a virtual MAC address for the redundant interface to avoid ARP conflicts.

Why it fails: Virtual MAC addresses are used in HA configurations to prevent ARP cache issues on switches, not for redundant interfaces. While a redundant interface can have a MAC address, it is not required for basic operation. The primary issue remains the absence of member interfaces.

Enable LACP on the redundant interface to allow link aggregation.

Why it fails: LACP is used with 802.3ad aggregate interfaces, not redundant interfaces. Redundant interfaces provide active-passive failover without link aggregation. Enabling LACP on a redundant interface is not supported and would not resolve the issue of missing member interfaces.

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.