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

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

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.

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.

The default route is incorrectly configured

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

Check routing, then check NAT rules, then check firewall policies, then review logs, then perform packet capture

Why it fails: Starting with routing and NAT before firewall policies is inefficient because the FortiGate evaluates policy as the first logical gate; if traffic is denied by a policy, no route or NAT rule can rescue it, and you may spend time analyzing routing tables for packets that are never forwarded. Additionally, placing review logs before packet capture inverts the correct forensic flow: logs often only show high-level results (e.g., 'denied by policy'), while a packet capture provides the raw packets needed to understand why the session failed, such as NAT port exhaustion or asymmetric routing. A proper diagnosis should eliminate the most common policy issues first, then verify NAT and routing, because both NAT and routing assume a policy already allowed the session.

Review logs, then check firewall policies, then check NAT rules, then check routing, then perform packet capture

Why it fails: Beginning with logs is misleading because a log entry only tells you that a session was dropped or accepted, not which configuration object caused the action—for example, a log might show 'action=deny' but you still need to check the firewall policy to see which policy did the denial and why. It also risks anchoring you to a single log record without context; you might miss that the traffic was never logged because it was dropped before the policy check, such as on the incoming interface due to IPS or route lookup failure. Furthermore, saving packet capture for last means you may have already committed to a hypothesis based on logs, whereas capturing earlier—after policy, NAT, and routing checks—would give you decisive packet-level evidence to confirm the actual path.

Check NAT rules, then perform packet capture, then check firewall policies, then check routing, then review logs

Why it fails: Checking NAT rules before firewall policies is inherently flawed because a FortiGate does not even consult the NAT table until the session has matched a policy; so a NAT rule you diagnose may be irrelevant if the traffic is denied by policy or falls into an implicit deny. Performing packet capture immediately after NAT and before policy checks will capture traffic indiscriminately, including packets that are about to be dropped by policy, which wastes analysis time and can hide the real root cause behind irrelevant packets. Even worse, this order places routing last, yet routing is critical for the return path and for determining which interface the packet egresses; without checking routing, you might capture ingress packets and think the problem is NAT when it is actually a missing route. A correct sequence must follow the dataplane's actual evaluation order: policy, NAT, routing, then capture, with logs used only for final confirmation.

Phase 1 authentication method

Why it fails: Phase 1 authentication is validated during Phase 1, which is already established, so a mismatch there would have prevented Phase 1 from coming up. It is tempting because authentication mismatches are a classic IPsec fault, but they surface as Phase 1 failures, not Phase 2 proposal errors.

Phase 2 local and remote subnets

Why it fails: 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 it fails: Phase 1 encryption is negotiated and completed before Phase 2 begins; since Phase 1 is up, its algorithm already matches, so it cannot cause the Phase 2 'no matching proposal' error. It is tempting because encryption mismatches do break IPsec, but only at the phase whose proposal is failing.

Aggressive mode is more secure than main mode

Why it fails: Aggressive mode is not more secure than main mode; the opposite is true. Main mode uses a six-message exchange that lets both peers establish a Diffie-Hellman shared secret and create an encrypted channel before transmitting their identification payloads, so identities are protected. Aggressive mode sends the identity in the clear, as it has not yet established encryption keys. Thus, main mode is the security-hardened choice when identity privacy is a concern.

Aggressive mode provides perfect forward secrecy (PFS) by default

Why it fails: Perfect forward secrecy (PFS) is not an inherent attribute of aggressive mode or of any IKE Phase 1 mode; it is an independent configuration in the Phase 2 proposal. PFS forces a new Diffie-Hellman key exchange during each re-key, ensuring that compromising a single long-term key does not expose past session keys. Enabling PFS in the VPN settings is done separately and has no relation to whether main or aggressive mode is selected. Therefore, aggressive mode does not provide PFS by default.

Aggressive mode uses six messages instead of three

Why it fails: Aggressive mode actually requires only three messages to complete IKE Phase 1: the initiator sends its proposal and DH data, the responder answers with the selected proposal and DH data, and the initiator confirms. This compact exchange reduces the number of round trips and makes aggressive mode faster, but it sacrifices identity protection because the identities are exposed in those early packets. The six-message exchange is characteristic of main mode, which separates the negotiation into a cryptographic proposal phase and an authenticated key exchange phase.

The allow policy at ID 10 will override the deny policy because it is more specific

Why it fails: This option assumes a longest-prefix or 'most specific match' rule, but FortiGate does not use that logic. A packet is matched against the first policy whose source, destination, service, and interface criteria are all satisfied; if that policy is a deny, the session is terminated and subsequent policies, including a more specific allow, are not evaluated.

The traffic will be matched by the implicit deny at the end of the policy list

Why it fails: The implicit deny policy is only evaluated if no explicit firewall policy matches the traffic. Because ID 5 explicitly matches and denies this source range, the session ends at that point and is never passed down to the implicit rule at the bottom of the list, so the implicit deny is irrelevant to this failure.

The administrator should enable 'policy override' on the allow policy

Why it fails: FortiGate has no configuration option named 'policy override' that lets a later allow bypass an earlier deny. Policy lookup is strictly sequential by ID, so the only ways to make the allow effective are to modify the earlier deny policy's match conditions or to reposition the allow policy before ID 5.

Security logs

Why it fails: Security logs (also called UTM logs) are produced when traffic triggers a security profile such as IPS, antivirus, web filtering, or application control. They record the threat verdict and the action taken (block, allow, or detect) for that profile, but they are not generated merely because a firewall policy was matched. A policy hit with no security-profile event produces a traffic log, not a security log, and FortiGate keeps these categories separate in the Log & Report section.

Event logs

Why it fails: Event logs record administrative and system-level activity on the FortiGate appliance itself: admin logins, configuration changes, HA failover events, interface link state changes, and system resource alerts. These logs help audit who changed the device and when system events occurred, but they do not capture per-session traffic details such as policy ID or byte counts. Policy enforcement happens per session, and only traffic logs contain the session-level data tied to a specific firewall policy.

Audit logs

Why it fails: FortiOS does not have a distinct log category called audit logs; the administrative and compliance-related information you might think of as an audit trail is captured in event logs for configuration changes and admin activity. When logging for regulatory auditing, you forward event and traffic logs to syslog or FortiAnalyzer, but the native FortiGate log menu splits logs only into traffic, event, and security (UTM) categories. Therefore, no separate audit log type records firewall policy usage.

Increase the severity level of the IPS sensor.

Why it fails: Increasing the severity level of an IPS sensor only adjusts which signatures are considered high priority and how many logs are generated, not whether detection occurs. Detection is governed by signature matching against the traffic stream, and severity thresholds primarily affect alerting and default response. If the traffic isn't being inspected because the IPS profile isn't attached to the relevant firewall policy, a higher severity setting will have no effect on whether an attack is identified.

Disable flow-based inspection and enable proxy-based inspection.

Why it fails: Switching from flow-based to proxy-based inspection, or vice versa, does not change the underlying signature database or enable detection of new attacks. Flow-based inspection is a single-pass architecture that scales well, while proxy-based uses full proxy and may offer additional protocol validation, but both modes apply the same IPS signatures and are equally capable of pattern matching. If a signature fails to trigger, the cause is more likely a missing policy association or an outdated signature set, not the inspection mode.

Change the IPS signature action from 'default' to 'block'.

Why it fails: Changing a signature's action from 'default' to 'block' alters the response when a match occurs—it does not turn on detection. Detection happens during traffic inspection, and the action only dictates whether the matched traffic is passed, dropped, or reset. Furthermore, 'default' action commonly inherits the signature's vendor-recommended blocking behavior, so overriding it may have little practical effect; if the profile is not applied to the correct policy, no signature will ever trigger regardless of the action setting.

Web filter profile is not applied to the firewall policy.

Why it fails: Web filter profiles in FortiOS control URL access by categorizing domain names and paths, not by identifying the application generating the traffic. Application control is a separate security profile that uses protocol decoders and FortiGuard signatures on the session payload, independent of the web filter. Not applying a web filter profile would only leave URL categorization unmanaged; it would not prevent the firewall from recognizing applications. Therefore, the missing web filter profile is unrelated to the inability to identify certain web-based apps.

Deep packet inspection is not enabled on the firewall policy.

Why it fails: On FortiOS there is no single 'deep packet inspection' toggle; inspection depth is determined by which security profiles are attached to the policy, such as application control, IPS, web filter, and SSL inspection. While application control and IPS both inspect packet payloads, HTTPS traffic cannot be evaluated beyond the initial handshake unless an SSL/SSH inspection profile decrypts it. Saying 'deep packet inspection is not enabled' is imprecise, and even if it were enabled, applications would still be invisible inside TLS without decryption. The real prerequisite for seeing inside HTTPS sessions is SSL inspection, not a generic DPI switch.

IPS is not enabled on the firewall policy.

Why it fails: IPS is designed to detect known attack signatures, protocol anomalies, and exploit attempts by inspecting network, transport, and application payloads. In contrast, application control uses the FortiGuard application identification database and protocol logic to classify which application is in use, and it works independently of the IPS engine. Disabling IPS would only remove intrusion-prevention coverage—it would not prevent the firewall from identifying applications. Consequently, this option misdiagnoses the absence of application classification as an IPS misconfiguration, when the true root cause is missing SSL inspection.

The pre-shared key is incorrect

Why it fails: The pre-shared key is only used in the final authentication messages of IKE Phase 1, not during the initial SA proposal exchange. If the PSK were incorrect, the peers would successfully agree on a proposal and then fail the authentication hash, producing an INVALID_COOKIE or AUTHENTICATION_FAILED notify instead. 'No proposal chosen' is generated when the responder rejects the proposal itself, which happens before authentication is ever attempted.

The local firewall is blocking UDP port 500

Why it fails: If a firewall were blocking UDP port 500, the initial IKE packets would never reach the remote peer, so no negotiation would occur at all. The initiator would retransmit and eventually time out without ever receiving a protocol response. The 'no proposal chosen' error is a specific IKE notify payload that can only be sent by a peer that has actually received and processed the SA proposal, which proves UDP 500 connectivity exists.

The Phase 2 encryption algorithm is not supported

Why it fails: The 'no proposal chosen' error is inherently a Phase 1 failure: it is the responder's rejection of the IKE SA proposal that includes encryption, hash, DH group, and authentication method for the IKE tunnel. Phase 2 encryption algorithms are negotiated only after Phase 1 is successfully established, so a Phase 2 mismatch would produce a later failure like a Quick Mode timeout or authentication error, not a Phase 1 notify. Thus this option incorrectly assigns a Phase 2 attribute to a Phase 1 negotiation problem.

Pre-shared key mismatch

Why it fails: A pre-shared key (PSK) mismatch would cause Phase 1 authentication to fail, producing an error like 'invalid identity' or 'authentication failed' before any Phase 2 exchange occurs. Since the problem is observed after Phase 1 is already up, the PSK must have matched. Therefore, a PSK mismatch is eliminated as a cause of the Phase 2 failure.

IKE version mismatch (IKEv1 vs IKEv2)

Why it fails: IKEv1 and IKEv2 are different protocols that are negotiated during Phase 1 via SA payloads. A version mismatch would prevent the peers from even completing IKE SA establishment. Given that Phase 1 is successfully up, both peers have agreed on the same IKE version, so this cannot be the reason the Phase 2 tunnel fails.

Phase 1 encryption algorithm mismatch

Why it fails: Phase 1 encryption algorithm mismatch (e.g., AES128 vs AES256) would cause a Phase 1 proposal mismatch, resulting in an IKE SA that never reaches active state. The tunneling process cannot proceed to Phase 2 if Phase 1's encryption algorithms are not mutually acceptable. Because Phase 1 is operational, the encryption algorithms are already aligned, ruling out this option.

The pre-shared key is incorrect

Why it fails: The pre-shared key is used during IKE Phase 1 authentication to establish the ISAKMP/IKE SA. If the PSK were incorrect on either side, Phase 1 would fail with an authentication error, and no Phase 2 negotiations would occur. Since the log explicitly shows Phase 2 completed, both peers successfully authenticated, proving the PSK values match and are correct.

The IKE mode is set to aggressive mode on one side and main mode on the other

Why it fails: IKE aggressive mode and main mode are Phase 1 exchange modes; they determine how the IKE SA is authenticated and how many packets are exchanged. A mismatch in these modes causes a Phase 1 failure—the two peers cannot agree on the IKE SA parameters, so the tunnel never reaches Phase 2. Because Phase 2 has completed, the Phase 1 negotiation must have succeeded, meaning both sides used a compatible mode (likely main mode).

Firewall policy not allowing ESP traffic

Why it fails: A firewall policy blocking ESP (IP protocol 50) would prevent user data from traversing the tunnel, but it would not prevent Phase 2 from completing. Phase 2 Quick Mode (IKEv1) or IKE_AUTH exchanges (IKEv2) ride over the existing UDP 500/4500 IKE channel established during Phase 1, not over ESP. Therefore, if Phase 1 is up, the IKE negotiate channel exists, so Phase 2 can still negotiate; ESP blocking would only manifest as traffic drop after the SAs are created. This option is thus not the cause of a Phase 2 bring-up failure.

Incorrect local or remote gateway IP

Why it fails: The local and remote gateway IP addresses are used in initial IKE contact to establish Phase 1. If either IP were incorrect, the peers could not reach each other, and Phase 1 would never come up. Since the symptom states Phase 1 is up, the gateway IPs must be correctly configured and routable. Moreover, Phase 2 reuses the same IKE channel; it does not re-verify peer addresses, so incorrect gateway IPs cannot cause a selective Phase 2 failure.

Mismatch in Phase 1 pre-shared key

Why it fails: The pre-shared key is only used during IKE Phase 1 authentication (e.g., Main Mode/MM or Aggressive Mode/AM). If the keys did not match, the peers would generate different SKEYID and fail authentication, resulting in Phase 1 not reaching active status. The fact that Phase 1 is up proves the pre-shared keys matched on both sides. Since Phase 2 relies on the already-established IKE security association, a key mismatch from Phase 1 cannot cause a Phase 2 failure—it is a zero possibility.

Increase the authentication timeout

Why it fails: The authentication timeout parameter only governs how long an authenticated SSL VPN session remains valid before requiring re-authentication, and it has no effect on the forwarding plane or on how traffic is routed or permitted through the firewall. If users cannot reach internal resources, the cause is a missing policy, incorrect routing, or a NAT issue, not a timeout value. Increasing the timeout would simply keep sessions alive longer without resolving the underlying packet flow problem.

Restart the FortiGate

Why it fails: Restarting the FortiGate clears transient states and may temporarily restore service if memory or a process hung, but it does not repair persistent misconfigurations such as a missing firewall policy or an absent static route. It is an indiscriminate action that causes disruption to all users and should be avoided during initial troubleshooting because it masks the actual issue rather than identifying it. For a logical configuration problem like a missing policy or route, a reboot will not produce a permanent fix.

Disable the SSL VPN portal

Why it fails: Disabling the SSL VPN portal would remove the web-based entry point that users access to download the FortiClient launcher or initiate the tunnel, effectively blocking all SSL VPN connections entirely. Since the reported problem is about traffic not flowing to the internal network after the tunnel is established, the portal itself is not the bottleneck; it is merely the initial login interface. Changing the portal state would make the situation worse by preventing tunnel establishment altogether, rather than addressing the routing or policy failure that causes the connectivity issue.