Troubleshooting Scenario Questions

Mismatched HA group IDs

Why it fails: Differing HA group IDs stop the devices recognising each other as cluster peers, so the cluster never establishes and no synchronisation occurs at all. Group ID matching is the right check when building a new cluster or when members show as standalone, not for intermittent sync faults.

Incorrect BGP route advertisements

Why it fails: BGP route advertisements affect Layer 3 reachability and path selection, not the HA session-sync channel, which uses the dedicated HA heartbeat and sync interfaces. Verifying BGP is correct when failover succeeds but traffic takes a suboptimal path afterwards.

Mismatched HA passwords

Why it fails: Mismatched HA passwords prevent the cluster from forming or cause members to leave the group entirely, which surfaces as HA status errors rather than selective session-sync failures. Password alignment is the correct check when a FortiGate cannot join an HA cluster at all.

diagnose vpn ike log

Why it fails: The diagnose vpn ike log command filters IKE daemon output by tunnel or peer, which is narrower than the full negotiation trace required here. It is tempting because it targets IKE specifically, but it would be the correct choice when you already know which gateway and need to isolate its messages rather than capture all phase 1 exchanges.

get vpn ipsec tunnel details

Why it fails: The get vpn ipsec tunnel details command displays current tunnel status, selectors and counters, not the live IKE packet exchange. It is tempting because it reports phase 1 and phase 2 state, but it would be the right choice for confirming whether a tunnel is up or down, not for observing the negotiation messages themselves.

diagnose debug application ipsec -1

Why it fails: The diagnose debug application ipsec -1 command enables verbose IPsec debug output, but it does not restrict capture to IKE negotiation messages specifically. It is tempting because it produces detailed IPsec diagnostics, yet it would be the correct choice when troubleshooting data-plane or kernel-level IPsec issues rather than phase 1 IKE exchanges.

Reboot the FortiGate

Why it fails: Rebooting does not reconcile a policy that FortiManager reports as installed but the FortiGate has not applied; the discrepancy lies in installation target, revision, or policy package assignment. It is tempting because reboots clear transient daemon faults, which is the right step when a FortiGate is unresponsive rather than when a specific policy is missing.

Review the FortiGate's routing table

Why it fails: Routing determines whether traffic reaches the FortiGate, not whether an installed policy matches it; a policy that never sees matching traffic is a policy-lookup or installation-scope problem. It is tempting because routing is the first check for traffic that never arrives, which is the correct scenario when sessions fail before policy evaluation.

Verify the FortiGate's HA status

Why it fails: HA status affects which unit holds the primary role and synchronises configuration, but a policy installed to the managed FortiGate is present regardless of HA state; the failure is in policy installation scope or matching. It is tempting because HA failover can revert configuration, which is the right check when a policy disappears after a cluster event.

The ZTNA application is not configured with HTTPS

Why it fails: ZTNA application access requires the application definition to specify the correct protocol and port; HTTPS is only relevant for web apps, so a non-web application would be blocked regardless. It is tempting because HTTPS is the common transport for browser-based ZTNA apps, and would be correct if the failing application were a web service.

The FortiClient EMS server is not reachable from the FortiGate

Why it fails: If FortiClient EMS were unreachable from the FortiGate, tag and posture information would not synchronise, but the client would not show 'Connected'. It is tempting because EMS connectivity underpins ZTNA. The failure occurs after connection, so the blocking mechanism is policy or application matching, not EMS reachability.

The FortiGate is not configured with the correct ZTNA application gateway

Why it fails: A missing or incorrect ZTNA application gateway would prevent the tunnel from establishing, so FortiClient would not report 'Connected'. It is tempting because gateway configuration is central to ZTNA. The correct cause lies in policy or access-proxy matching, since authentication and connection already succeeded.

The pre-shared key is incorrect

Why it fails: PSK mismatch causes Phase 1 authentication failure, not Phase 2 proposal mismatch.

The firewall policy does not allow UDP port 500

Why it fails: This would affect Phase 1 negotiation, not Phase 2.

The IKE version (IKEv1 vs IKEv2) is different

Why it fails: IKE version mismatch prevents Phase 1 from completing, not Phase 2.

One unit has a higher priority

Why it fails: Priority determines which unit becomes primary, not whether heartbeats are exchanged; split-brain arises from lost heartbeat links or monitor failures, so unequal priority merely decides the winner once both units are already active. Priority is genuinely configured to control primary election in a healthy cluster.

Firmware version mismatch

Why it fails: Firmware version mismatch between cluster members prevents proper HA state synchronisation but does not itself cause both nodes to claim active status simultaneously. Version consistency is required for supported clustering, yet split-brain stems from heartbeat or connectivity failures, not image differences.

Session pickup is disabled

Why it fails: Session pickup governs whether TCP sessions survive failover to the new primary; it has no role in detecting peer availability, so disabling it cannot partition the cluster. It is correctly configured when uninterrupted session continuity across a failover is required.

The peer's certificate has expired

Why it fails: An expired peer certificate yields an expiry-specific validation error, whereas 'unable to get local issuer certificate' means the issuing CA certificate cannot be located to build the chain. Expiry is the cause when the log names validity dates.

The certificate revocation list (CRL) is not configured

Why it fails: A missing CRL produces a revocation-status error, not the 'unable to get local issuer certificate' message, which indicates the intermediate CA certificate is absent from the local store. CRL configuration matters when the gateway must confirm a peer certificate has not been revoked.

The local certificate does not match the peer's expected CN

Why it fails: A CN mismatch fails identity verification after the chain validates, producing a peer-ID or DN mismatch error rather than an issuer lookup failure. CN checking is relevant when the gateway must confirm the peer's identity matches the configured remote gateway.

Configure a static route with a gateway IP in the destination VDOM

Why it fails: Inter-VDOM links are point-to-point; adding a gateway IP static route is unnecessary and wrong. It tempts because static routes with next-hop gateways are normal for routed interfaces, but VDOM links route directly once the link and firewall policy exist.

Assign an IP address to the VLAN interface on the source VDOM

Why it fails: A VDOM link is a virtual interface, not a VLAN, so assigning a VLAN interface IP on the source VDOM does not enable inter-VDOM routing. It tempts because interface IPs are needed for routing generally, but the missing piece is the inter-VDOM link itself.

Enable 'inter-vdom' under config system global

Why it fails: There is no 'inter-vdom' setting under config system global; inter-VDOM routing is enabled by creating VDOM links and policies. It tempts because global toggles exist for other features, but FortiOS 7.2 requires explicit VDOM link interfaces instead.

The VDOM link MTU is too small for the traffic

Why it fails: MTU size affects packet fragmentation and large transfers, not whether routes resolve; the routes already appear in both VDOMs. A missing return route or asymmetric routing is the likely cause. MTU issues would be the suspect when large packets fail while small pings succeed.

The VDOM link interfaces are administratively down

Why it fails: Administratively down interfaces would remove the connected routes from 'diagnose ip route list', yet the administrator sees routes present in both VDOMs, so the link is passing traffic at layer 3. This option is tempting because a disabled VDOM link genuinely breaks inter-VDOM routing, but that failure would be visible in the routing table.

The VDOMs are in different administrative domains (ADOMs) on FortiManager

Why it fails: ADOM membership is a FortiManager management-plane grouping for policy packages and device assignment; it has no bearing on runtime packet forwarding between VDOMs on the same FortiGate. Tempting because ADOMs do isolate devices administratively, but routing between VDOMs is unaffected by which ADOM manages them.

Run a packet sniffer on the FortiGate to capture traffic between the subnets.

Why it fails: Running a packet sniffer on the FortiGate captures raw traffic but does not diagnose the root cause of intermittent timeouts during peak hours, which is likely buffer exhaustion or session table overflow rather than a policy or packet-level fault. This step is tempting because sniffing is the default tool for verifying whether packets traverse the firewall correctly, and it would be correct if the issue were suspected to be a silent policy drop or asymmetric routing.

Disable hardware acceleration on the FortiGate.

Why it fails: Disabling hardware acceleration changes how the FortiGate processes packets but does not identify why timeouts occur only at peak hours; it is used to work around offload-related inspection anomalies or specific protocol issues. The first step should gather diagnostic evidence, such as session lists and resource utilisation, before altering forwarding behaviour.

Configure SNAT on the policy to translate the source IP.

Why it fails: SNAT rewrites source addresses and does nothing to diagnose peak-hour timeouts; it is configured to provide outbound internet access or hide internal addressing, not to troubleshoot policy-permitted inter-subnet traffic. The first step should instead inspect session and resource utilisation data, such as checking session tables or conserve mode during the peaks.

Configure traffic shaping to rate limit the URL

Why it fails: Traffic shaping only throttles bandwidth for matching traffic; it cannot block or drop a URL, so the Malware category stays permitted. It is tempting because shaping profiles are applied per firewall policy, but that scenario concerns congestion control, not web-filter enforcement.

Add a static URL filter with the exact URL and action 'block'

Why it fails: A static URL filter matches the literal URL string, so it blocks only that exact form and leaves variants, subdomains and other malicious URLs permitted. It is tempting as a surgical override, and would be correct to exempt or block one specific address regardless of category.

Enable DNS filter with botnet C2 domain blocking

Why it fails: DNS filtering blocks resolution of botnet C2 domains, not HTTP requests to URLs already resolved and categorised as Malware by FortiGuard. It is tempting because DNS filtering is a valid layer for known C2 infrastructure, but this scenario requires changing the web filter profile's Malware action from monitor to block.

The local authentication method (certificate vs pre-shared key)

Why it fails: This is a phase 1 parameter.

The encryption algorithm for phase 2

Why it fails: The question states the proposals match; encryption mismatch would already be covered.

The pre-shared key

Why it fails: PSK is used in phase 1; phase 2 failure occurs after phase 1 is up.

NAT traversal configuration

Why it fails: NAT traversal only matters when a device sits behind a NAT gateway and the tunnel fails to establish; here the tunnel is already up, so NAT-T has done its job. It is tempting because NAT-T is a common IPsec pitfall, but it governs IKE negotiation, not whether traffic traverses an established tunnel.

Static routes

Why it fails: Static routes matter only when the tunnel fails to establish or selectors mismatch; here the tunnel is up, so the fault lies in policy, phase 2 selectors or routing within the tunnel. Checking static routes is tempting because route lookups commonly break VPN traffic, and it would be right if the tunnel were down or traffic egressed the wrong interface.

Phase1 parameters

Why it fails: Phase1 parameters govern IKE SA negotiation; if they mismatched, the tunnel would not establish at all. Since the tunnel is up, Phase1 has already succeeded, so it cannot explain the traffic failure. It is tempting because Phase1 mismatches are a classic IPsec fault, but they produce establishment failures, not silent drops.

diagnose debug flow filter daddr <IP>

Why it fails: This is for flow debugging, not BGP session establishment.

get router info routing-table bgp

Why it fails: This shows BGP routes, not session establishment issues.

diagnose sys session filter dport 179

Why it fails: This shows sessions to port 179 but does not provide detailed BGP negotiation info.

Check the FortiGate's antivirus update status

Why it fails: Antivirus signature freshness has no bearing on whether the ZTNA gateway accepts a TCP session; 'Connection refused' indicates the listener or policy rejected it. Scanning updates matter for malware inspection profiles, so this step would be valid when investigating detection gaps or content-scanning failures rather than connectivity.

Reboot the FortiClient computer

Why it fails: Rebooting the endpoint clears no diagnostic evidence and cannot explain a server-side refusal; the gateway actively rejected the session, so the cause lies in FortiGate ZTNA policy, tags, or the application listener. Rebooting is legitimate for clearing a wedged FortiClient service or stale tunnel state, not a refused connection.