Troubleshooting practice questions

The firewall policy's NAT setting is set to 'disable'

Why wrong: The admin stated NAT is enabled.

The IP pool is configured for one-to-one NAT

Why wrong: One-to-one NAT does not prevent the pool from being used; it's a different type.

The internal host is using a non-standard source port

Why wrong: Source port does not affect IP pool matching.

The Phase 2 proposal uses AES256 but the remote client only supports AES128

Why wrong: If the Phase 2 proposal were mismatched, the IPsec SA negotiation would fail and the tunnel would not come up at all. Since the tunnel is established and the problem is that user traffic is not passing, the proposals must have been successfully negotiated with matching cipher and integrity algorithms. Therefore, a mismatch in AES key lengths cannot be the cause of post-negotiation traffic loss.

The FortiGate's routing table does not have a route to the remote user's subnet

Why wrong: In a dial-up VPN scenario, the remote user's IP address is dynamically assigned, so the FortiGate typically relies on a static route pointing toward the dial-up tunnel interface or a per-user host route learned from IKE. If the FortiGate lacked such a route, return packets from the destination network could not be sent back, but the symptom of no sessions suggests the initial forward packets are being dropped before any session creation. Missing routes usually manifest as asymmetric routing or ICMP unreachable messages, not a clean absence of sessions when a policy drop is the culprit.

The remote user's FortiClient is blocking split tunneling

Why wrong: Split tunneling controls which destination networks the FortiClient routes directly vs. through the IPsec tunnel; blocking it would force all client traffic into the tunnel, not prevent it from doing so. If split tunneling were disabled, we would expect to see more sessions and traffic hitting the FortiGate's tunnel interface, yet the session table shows no traffic at all. The absence of any sessions indicates the packets are not reaching the FortiGate or are being explicitly dropped by policy rather than being influenced by client-side routing decisions.

execute ping 203.0.113.50

Why wrong: Ping tests connectivity, not policy matching.

diagnose debug flow

Why wrong: `diagnose debug flow` is an active debugging command that generates verbose output for every packet matching its filter, making it inefficient for simply identifying the policy number. It is designed to trace the exact path of a specific packet through the FortiGate in real-time, showing precisely where it is denied or allowed, including the policy ID. This command is invaluable for deep-diving into live traffic issues, analysing the full processing flow to understand *why* a decision was made, rather than just quickly identifying a matching policy.

get firewall policy

Why wrong: This command shows the configuration, not real-time matching.

get system performance status

Why wrong: This shows system performance, not policy matching.

config system ha

Why wrong: This is for HA configuration, not troubleshooting.

execute ping options

Why wrong: Ping tests connectivity, not policy matching.

The default route on the FortiGate is missing

Why wrong: For the FortiGate to successfully ping 8.8.8.8, it must have a valid route to that destination—usually a default route pointing to its next-hop gateway. If the default route were missing, the FortiGate would return 'Destination host unreachable' because no route exists for the packet. Thus, the administrator's test proves the FortiGate's routing is operational, so this cannot explain why internal hosts fail to connect.

DNS resolution is failing

Why wrong: The administrator's connectivity test to 8.8.8.8 uses a raw IP address, so a DNS failure would have no impact on that test. DNS is only required when resolving hostnames to IPs; if DNS were broken, pinging an IP would still work perfectly. Since the problem is that clients cannot reach external destinations even by IP, the cause is strictly routing or forwarding, not name resolution.

The FortiGate's interface to the internal network is down

Why wrong: If the interface were down, the FortiGate likely wouldn't be able to ping from itself either, but it could still ping if the internal interface is separate? Actually ping from FortiGate uses its own routing, so internal interface down would not affect pinging 8.8.8.8 if default route is via port1. So internal interface could be down and still ping. But then internal hosts wouldn't reach the FortiGate. So this is plausible. However, the most likely is wrong gateway.

The firewall policy allowing IPsec traffic is missing.

Why wrong: A firewall policy that permits IPsec traffic governs which data flows are allowed to traverse an established VPN tunnel, but it does not drive the IKE Phase 2 negotiation itself. In route-based VPNs the tunnel can establish with no policy present, and in policy-based VPNs the policy's local/remote selectors must match the Phase 2 proxy IDs, but a missing policy would show symptoms like dropped traffic or no matching policy, not a failure to create the Phase 2 IPsec SA. Therefore, if Phase 2 is not coming up, the root cause is not the absence of a firewall policy.

The remote gateway IP address is unreachable.

Why wrong: If the remote gateway IP address were unreachable, the FortiGate would be unable to send IKE packets, and Phase 1 would never complete. Because Phase 2 negotiation is only initiated after a successful Phase 1, a reachability failure would abort the process before Phase 2 is ever attempted. Since the administrator observes a Phase 2 failure, the Phase 1 SA exists, which proves the remote gateway is reachable over the network, eliminating this option as the cause.

The pre-shared key is incorrect.

Why wrong: An incorrect pre-shared key is used in IKE Phase 1 to authenticate the peers—not in Phase 2. If the PSK does not match, authentication during Phase 1 Main Mode or Aggressive Mode exchange fails, and no IKE SA is established. Thus the Phase 2 Quick Mode would never be invoked, so a PSK mismatch cannot be the explanation for a Phase 2-specific failure; this issue would prevent Phase 1 entirely.

Client certificate authentication is required but not provided

Why wrong: If client certificate authentication is required, the FortiGate would reject the SSL VPN handshake or the user would fail to authenticate before any tunnel is established. Since the user is able to connect (we are troubleshooting traffic flow after successful login), the issue is not at the authentication stage. Therefore this option is wrong; it would manifest as a login failure, not as a connectivity problem after the tunnel is up.

Split tunneling is disabled

Why wrong: Split tunneling controls whether the client sends only specific routes over the tunnel (split) or all traffic (full tunnel). When split tunneling is disabled (i.e., full tunnel is in effect), the client sends all traffic through the SSL VPN tunnel, which actually would allow more traffic to the internal network, not block it. The issue here is at the FortiGate firewall policy level, not on the client side. Thus disabling split tunneling would not prevent access; it would direct more traffic into the tunnel.

The SSL VPN realm is not configured correctly

Why wrong: The realm is used in the SSL VPN portal URL to select a specific authentication method and portal configuration. If the realm were misconfigured, the user would not be able to access the correct login page or would receive an authentication error. The traffic forwarding after a successful connection is independent of realm settings; realms affect the pre-authentication phase and portal presentation, not how the FortiGate routes traffic from ssl.root to internal networks.

Ensure that the antivirus profile is enabled on the policy

Why wrong: An antivirus profile is responsible for scanning files and message bodies for malware signatures; it does not inspect or categorize URLs. Even if the antivirus profile is disabled on the policy, the web filter will still evaluate the requested URL against the configured Social Networking category and block Facebook when the action is Block. Enabling antivirus has no bearing on the symptom, so it is not one of the three most likely causes for this issue.

Confirm that the 'Social Networking' category is not set to 'Monitor' instead of 'Block'

Why wrong: The administrator has explicitly set the Social Networking category to Block in the profile, so rechecking the dropdown would only confirm an action that is already correct. Even if a group override or a custom category redefined the action, the field value shown would reflect that, and merely verifying it does not address the root cause when the symptom is that Facebook is still accessible. This is a reasonable sanity check, but it is not one of the three most likely causes because the configuration already matches the intended blocking action.

The default route is incorrectly configured

Why wrong: The default route on a FortiGate is used by the FortiGate itself to reach remote networks. Since the administrator's ping from the FortiGate to an external address succeeds, the default route is correctly installed and functional. The problem involves traffic sourced from internal users, which also requires proper NAT for return path, not just routing. Therefore, a default-route misconfiguration cannot explain why user traffic fails while the FortiGate's own traffic succeeds.

An implicit deny policy is blocking traffic from internal to external

Why wrong: An implicit deny policy would affect all sessions matching no explicit firewall policy, including the FortiGate's own outbound pings if they were processed by the same policy set. However, the FortiGate's ping succeeds, proving that either an explicit policy allows it or that local-out traffic bypasses the inter-zone policy engine. In FortiOS, the implicit deny is a final catch-all for traffic between zones, but local management traffic uses different handling. Thus, the symptom contradicts an implicit deny blocking all internal-to-external traffic.

External access profile is set to read-only

Why wrong: External access profiles in FortiOS are administrative-level permissions that control which admin accounts can access the device and what they can view or change via protocols like HTTPS or SSH. They are completely separate from the data-plane functions of the FortiGate, such as firewall policies, NAT, and routing. A read-only external access profile would restrict an admin's changes but would not block or alter user traffic through the device. Therefore, this setting is unrelated to the connectivity problem described.

Pre-shared key mismatch

Why wrong: PSK mismatch causes authentication failure, not proposal mismatch.

Lifetime mismatch (e.g., 86400 vs 3600)

Why wrong: Lifetime mismatch typically results in negotiation succeeding but rekey issues.

Phase 1 authentication method

Why wrong: Already negotiated successfully in Phase 1.

Phase 2 local and remote subnets

Why wrong: While mismatched subnets can cause issues, the error 'no matching proposal' typically refers to algorithms/PFS, not selectors. However, sometimes selectors are included in the proposal; but the two most common causes are encryption and PFS.

Phase 1 encryption algorithm

Why wrong: Phase 1 is already up, so its settings are fine; the error is in Phase 2.

diagnose npu np6 ipsec-sa list

Why wrong: Shows hardware offload SA, not helpful for negotiation issues.

diagnose sys session clear

Why wrong: Clears sessions, not a diagnostic command for IKE.

diagnose vpn tunnel list

Why wrong: Shows tunnel status but not detailed debug information.

Pre-shared key

Why wrong: Pre-shared key mismatch would show 'authentication failed', not 'no acceptable proposal'.

Phase 2 local and remote networks

Why wrong: Phase 2 networks are negotiated after Phase 1.

IKE version (IKEv1 vs IKEv2)

Why wrong: IKE version mismatch would cause a different error or no response.

Check the routing table on the FortiGate for the internal subnet

Why wrong: Routing is usually correct if the policy allows; routing issues would affect all traffic.

Ensure the users have the correct client software installed

Why wrong: Client software is needed for tunnel mode, but the issue seems to be connectivity after tunnel is up.

Check the FortiGate's DNS settings

Why wrong: DNS is not directly related to traffic forwarding.

Disable deep inspection on the policy

Why wrong: This would stop inspection for all traffic, which may not be desired.

Change the policy action to DENY

Why wrong: Denying access is not the goal; they want to allow access.

Disable certificate validation in the SSL/SSH profile

Why wrong: Disabling validation might allow the connection but would weaken security and is not recommended; it also does not fix the underlying certificate trust issue.

diagnose hardware sysinfo memory

Why wrong: Memory info is not relevant to VPN traffic flow.

diagnose netlink interface list

Why wrong: Interface status is already known; tunnel is up.

execute ping-options source and execute ping

Why wrong: Ping tests connectivity but does not isolate configuration issues.