Troubleshooting Scenario Questions

The FortiGate will accept connections from any remote IP address.

Why it fails: peer-id is a phase 1 identity setting, not a source IP filter. Even when peer-id is 'any', the FortiGate still enforces the remote gateway IP address or network as configured in the phase1 interface. Accepting any peer identity does not change IP-based access control. Therefore, this option is incorrect.

The FortiGate will use aggressive mode for IKE negotiation.

Why it fails: The IKE negotiation mode (main or aggressive) is a separate Phase 1 parameter, configured under `set mode main` or `set mode aggressive`. Setting peer-id to 'any' only disables identity validation; it does not alter the IKE exchange mode. Aggressive mode would be selected explicitly, not as a consequence of a wildcard peer identity. This option is wrong because it conflates two independent configurations.

The Phase 2 selectors are configured for any protocol.

Why it fails: Peer identity is validated during Phase 1, while Phase 2 selectors (proxy IDs) define the VPN traffic's source/destination subnets, protocols, and ports. Configuring peer-id as 'any' affects only the authentication identity check; it has no effect on the Phase 2 selector definitions. The selectors remain as configured, for example, `src 10.0.0.0/24 dst 192.168.1.0/24` with protocol 0. This option is incorrect.

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

Why it fails: 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 it fails: 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 it fails: 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.

The pre-shared key is incorrect

Why it fails: An incorrect pre-shared key will not cause a proposal negotiation failure but will result in an authentication failure during IKE phase 1 (IKEv1 main/aggressive mode) or during the IKE_AUTH exchange in IKEv2. The responder will reject the peer's authentication payload, typically logging a 'received an unauthenticated notification' or 'PSK mismatch' error, and the tunnel will not be established beyond that point.

The Phase 1 proposal is mismatched

Why it fails: A mismatch in Phase 1 proposals (encryption algorithm, integrity algorithm, DH group, or PRF) means the two peers cannot agree on a common security parameter set. In IKEv1, this triggers a 'NO_PROPOSAL_CHOSEN' notify response, and in IKEv2 a similar 'NO_PROPOSAL_CHOSEN' occurs, causing the IKE SA to be terminated before any authentication or key exchange can proceed. This failure is immediate and identifiable from the IKE notify message.

A network address translation device is altering the IKE packets

Why it fails: A NAT device altering IKE packets will typically be detected through NAT-D (NAT Discovery) payloads exchanged during IKE phase 1. If NAT is not handled correctly (e.g., not using UDP encapsulation for IPsec), the IKE packets may be dropped or corrupted, but if NAT-T is operating normally, the payloads are encapsulated in UDP and are not 'altered' in a way that breaks authentication. The actual problem with NAT is usually a misconfigured NAT-T policy or a device that fails to pass UDP 500/4500, rather than a generic 'alteration' that would produce a distinguishable IKE error; the administrator would see NAT-D payloads indicating a NAT is present and the tunnel would fail to negotiate if those payloads are missing or mismatched.

Both flow and proxy modes support FortiSandbox equally

Why it fails: Although flow-based and proxy-based inspection modes can both be integrated with FortiSandbox, they are not functionally equal. Proxy-based inspection buffers the entire file and holds the connection until FortiSandbox returns a verdict, enabling true blocking of malicious files. In contrast, flow-based inspection forwards only a file hash or a copy to FortiSandbox without holding the connection, so it cannot quarantine the file at the moment of detection. Therefore, saying both support FortiSandbox 'equally' ignores the significant difference in enforcement capability.

Deep inspection

Why it fails: Deep inspection refers to SSL/TLS decryption, not an antivirus inspection mode. It is a profile that allows FortiGate to decrypt HTTPS traffic so that security profiles, including antivirus, can inspect the content. While deep inspection can be used alongside FortiSandbox for encrypted traffic, it is not the mode that sends files to FortiSandbox. Without an antivirus profile configured with FortiSandbox, deep inspection alone does not submit files for sandbox analysis.

Flow-based inspection

Why it fails: Flow-based inspection can indeed send files to FortiSandbox, but only in a 'copy-and-continue' manner. The FortiGate forwards the file or a hash to FortiSandbox and immediately allows the traffic to proceed without waiting for a verdict. This means it acts as a monitoring or detection tool rather than a blocking control. Even when configured correctly, flow-based mode does not hold the connection, so malicious files may reach the user before the sandbox analysis completes.

NAT is disabled, so the server cannot send replies back.

Why it fails: NAT is not required for traffic between internal VLANs because the FortiGate simply routes packets based on the destination IP, and the server's reply goes directly back to the source IP using the existing routing table. Disabling NAT would affect source address translation for egress to external networks, not internal reachability, so this is not the reason HTTPS is blocked.

The policy order is incorrect; a deny policy above is blocking traffic.

Why it fails: The administrator already verified there are no overlapping or conflicting policies, so a deny policy above would be a separate explicit rule. If a deny policy above were blocking traffic, it would deny all traffic from VLAN10 to VLAN20, not selectively HTTPS; since only HTTPS fails, a policy-order issue is not the cause.

The schedule is configured incorrectly and the policy is inactive during the current time.

Why it fails: The schedule is set to Always, meaning the policy is active 24/7; a schedule-based denial would make the policy inactive at specific times, causing all traffic to fail, not just HTTPS. Since the policy is active and the issue is protocol-specific, the schedule configuration is not the cause.

The firewall policy from internal to DMZ is blocking traffic

Why it fails: The firewall policy between internal and DMZ is explicitly configured to permit traffic, as verified in the policy table. Even if it were blocking, that would affect direct internal-to-DMZ communication, but the problem is about internal users reaching an internal server via the public IP. Since the policy allows traffic, and the destination of the forwarded traffic is a DMZ server, the policy is not the bottleneck. In fact, the traffic path from internal to public IP would first hit the FortiGate's VIP, then be redirected to the DMZ server, which is allowed by the internal-to-DMZ policy.

Hairpin NAT is not enabled on the FortiGate

Why it fails: Hairpin NAT (also known as NAT loopback) is a feature that allows internal clients to access a public IP address that is mapped to an internal server through the FortiGate's external interface. However, in this scenario, the destination server is the DMZ server (10.0.0.10) because the port forwarding rule is defined for that server. Enabling hairpin NAT would only allow the internal users to reach the DMZ server via the public IP; it would not change the destination IP to the internal server. Therefore, the root cause is the misconfiguration of the destination in the VIP/port forwarding rule, not the absence of hairpin NAT.

The IP Pool for outbound NAT is misconfigured

Why it fails: The IP pool is used for source NAT when internal users initiate outbound connections to the Internet. Since internal users are able to browse the Internet successfully, the IP pool is functioning as intended and is not misconfigured. This proves that the outbound NAT path is not the cause of the problem. The issue lies in the inbound port forwarding rule, which uses a VIP rather than an IP pool; a misconfigured IP pool would not affect the forwarding of incoming traffic to an internal server.

The default route on the FortiGate is missing

Why it fails: 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 it fails: 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 it fails: 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 session helper is misconfigured

Why it fails: Session helpers (or application layer gateways) are used to dynamically open pinholes and rewrite payload for protocols like FTP, SIP, or H.323. They are not involved in the NAT port allocation process. A misconfigured session helper might cause specific protocol sessions to fail or interfere with signaling, but it cannot consume the source port pool or prevent new sessions from being created due to port exhaustion.

The IP Pool's public IP has been blacklisted by external websites

Why it fails: If a public IP is blacklisted by external websites, those websites will reject connections from that IP, but that does not affect the FortiGate's ability to allocate source ports. Blacklisting would cause typical error messages or timeout failures for all traffic to those external sites, not just new sessions, and it would not exhaust the port pool. The root cause here is a local resource limitation (ports), not an external policy decision.

The firewall policy is not referencing the IP Pool

Why it fails: If the firewall policy did not reference the IP pool, the FortiGate would simply not apply dynamic PAT from that pool. The traffic might use the outgoing interface's IP address (if NAT is enabled via the interface) or would be translated differently, but it would not attempt to allocate ports from the pool. Consequently, the pool would never run out of ports; instead, you would see a different symptom like missing source NAT or wrong source address, not session failures caused by port exhaustion.

The firewall policy allowing IPsec traffic is missing.

Why it fails: 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 it fails: 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 it fails: 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.

The IKE version is mismatched (IKEv1 vs IKEv2)

Why it fails: A mismatch between IKEv1 and IKEv2 is detected during Phase 1 (the IKE_SA_INIT exchange in IKEv2, or Main/Aggressive Mode in IKEv1), where peers exchange SA proposals with different payload structures and mandatory attributes. Without an established IKE SA, there is no authenticated and encrypted channel over which Phase 2 (Quick Mode or CREATE_CHILD_SA) can run. Consequently, the failure manifests as a Phase 1 negotiation error, not a Phase 2 proposal mismatch.

The pre-shared key is incorrect

Why it fails: An incorrect pre-shared key causes authentication failure during IKE Phase 1 (or the IKE_AUTH exchange in IKEv2), because each peer derives a keyed hash using the PSK and verifies it against the peer's response. If the keys do not match, the IKE SA is never established. Phase 2 is only initiated after the IKE SA is active, and its parameters, including traffic selectors, are never discussed—so this scenario cannot produce a Phase 2 proposal mismatch.

The firewall policies are blocking IKE traffic on UDP port 500

Why it fails: IKE negotiation relies on UDP port 500 (and UDP 4500 for NAT traversal); if a firewall policy blocks these ports, the IKE SA cannot be formed because the initial SA proposal packets are dropped. Without the IKE SA, Phase 2 cannot even begin, as its messages are encapsulated and encrypted inside the IKE SA. Therefore, the failure would appear as a Phase 1 timeout or no-response error, not a proposal mismatch, which is a logical parameter incompatibility and would occur even when the network path is fully open.

Verify the user group configuration

Why it fails: While user group configuration is necessary for VPN firewall policy authorization, it is not the correct first step because a user group is only evaluated after LDAP authentication succeeds. If the FortiGate cannot bind to the LDAP directory using the user's credentials, the group membership lookup is never performed, so checking group filters, member attributes, and group-to-policy mappings prematurely is ineffective. The diagnostic test should be executed first to confirm authentication works; only then can group configuration be meaningfully debugged for issues such as an incorrect LDAP query that fails to locate the user's group.

Restart the FortiGate

Why it fails: Restarting the FortiGate is a non-diagnostic, disruptive action that simply clears cached sessions and reboots the firewall; it does not modify or repair LDAP server object IP addresses, bind credentials, or search base settings. A reboot might temporarily clear a session-related symptom, but it will not resolve an underlying authentication failure and causes a complete interruption of all traffic handled by the device. In contrast, the `diag test authserver` command dynamically interacts with the LDAP server, producing immediate error codes and connection status information that a reboot cannot provide, making restart an inappropriate and ineffective troubleshooting step.

Check the LDAP server's firewall rules

Why it fails: Checking the LDAP server's firewall rules is a possible cause for connectivity failure, but it is subordinate to the direct diagnostic test because that test immediately reveals whether the issue is a network reachability problem (e.g., timeout or connection refused) versus an authentication problem (e.g., invalid bind credentials). Only after the `diag test authserver` command shows a TCP or SSL connection failure should you inspect server-side firewall rules, ACLs, or IP allowlists, as those are not the most common cause of LDAP authentication errors. Moreover, blind firewall inspection does not test the bind operation at all, so it cannot validate the LDAP server's response to a password or account status, making it a slower and less precise next step than the CLI diagnostic.

Client certificate authentication is required but not provided

Why it fails: 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 it fails: 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 it fails: 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.

The remote gateway's IP address is reachable

Why it fails: The remote gateway's public address has already been proven reachable because Phase 2 is up, which necessarily means Phase 1 completed successfully over the network path between the two peers. Reachability of the remote gateway is a prerequisite for building the IPsec tunnel, not a condition that controls whether the tunnel is used for a given subnet after establishment. Thus, this option is redundant and does not identify the critical prerequisite for sending data through a route-based tunnel.

The pre-shared key is correct

Why it fails: A correct pre-shared key is required for IKE Phase 1 authentication, and if the pre-shared key were invalid, the tunnel would never have come up. Since the administrator has already confirmed that Phase 2 is active, the PSK has already been validated by both peers during the IKE handshake. Consequently, PSK correctness is a necessary but already-met condition that cannot be the missing factor allowing traffic to traverse the route-based VPN.

The Phase 2 proposal includes the correct local and remote subnets

Why it fails: In a route-based IPsec VPN, Phase 2 selectors (proxy IDs) are typically configured as 0.0.0.0/0 to avoid subnet-specific matching, allowing the routing table to dictate which destination networks are sent through the tunnel. Unlike policy-based VPNs, the local and remote subnets are not part of the Phase 2 proposal; they are determined by static routes and firewall policies. Therefore, specifying correct local and remote subnets in Phase 2 is neither required nor relevant once the tunnel is already up.

The IKE version is not compatible

Why it fails: The IKE version is not the culprit here because both FortiGates are explicitly configured to use IKEv2, and IKE version negotiation occurs during Phase 1. If the versions were incompatible, the Phase 1 IKE SA would never be established, preventing any Phase 2 negotiation from starting. The presence of a 'proposal mismatch' error during Phase 2 categorically proves that Phase 1 completed successfully, including all IKE version and SA exchanges. Thus, an IKE version mismatch is not a plausible cause for this specific Phase 2 error.

The Phase 2 selectors (local and remote subnets) are misconfigured

Why it fails: While incorrect local and remote Phase 2 selectors (proxy IDs) can prevent a tunnel from carrying traffic, they do not cause a 'proposal mismatch' error in FortiGate's logs. A selector mismatch typically results in 'no proposal chosen' or a failure to negotiate the IPsec SA because the traffic selectors do not match, or the tunnel may come up but fail to encrypt the expected subnets. The 'proposal mismatch' notification specifically indicates that the cryptographic transform sets (encryption, authentication, PFS) offered by the initiator were rejected by the responder, not that the protected subnets were different.

The pre-shared keys do not match

Why it fails: Pre-shared keys are used for authenticating the peer during Phase 1, not Phase 2. If the pre-shared keys did not match, the IKE Phase 1 authentication would fail, generating a different error such as 'pre-shared key mismatched' or 'authentication failed' and preventing the establishment of the IKE SA. A Phase 2 'proposal mismatch' error can only occur after Phase 1 has been successfully established with a valid PSK, so mismatched keys are definitively not the cause. Additionally, PSK mismatch affects the integrity of the entire IKE SA, whereas 'proposal mismatch' is a negotiation error between cryptographic algorithms, which is phase-specific.

Ensure that the antivirus profile is enabled on the policy

Why it fails: 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 it fails: 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.