Authentication and VPN practice questions

The phase1 keylife is longer than the phase2 keylife, causing rekey issues.

Why it fails: Phase1 and phase2 keylifetimes are independent, and a longer phase1 lifetime does not break rekeying or traffic flow; mismatched lifetimes are normal and valid. This option is tempting because rekey failures do cause drops, but those stem from mismatched proposals or PFS settings, not lifetime ordering.

The 'set net-device disable' prevents the tunnel from being used for routing.

Why it fails: 'set net-device disable' only affects how the FortiGate derives tunnel interface addressing; it does not stop the tunnel carrying routed traffic, so it cannot explain users failing to reach main-office resources. It is genuinely used for route-based IPsec where overlapping subnets or interface addressing cause problems.

The phase2 proposal does not match the phase1 proposal.

Why it fails: Phase1 and phase2 negotiate separate proposals at different stages, so a mismatch between them is expected and not a fault; the tunnel would still establish. It is tempting because proposal mismatches are a classic IPsec fault, but the relevant comparison is phase2 against phase2 on the peer, or phase1 against phase1.

IPsec VPN: Uses TLS/SSL for secure web-based access

Why it fails: This statement is incorrect because IPsec VPNs do not use TLS/SSL; they rely on IKE for key negotiation and ESP/AH for packet security. TLS/SSL is the protocol stack that powers SSL VPNs, which operate at the application layer to provide browser-based secure access. Assigning TLS/SSL to IPsec swaps the two distinct VPN families' signature technologies, which is the core reason this option is wrong.

SSL VPN: Uses ESP/AH protocols for secure communication

Why it fails: This statement is incorrect because SSL VPNs do not use ESP/AH at all; they establish secure connections with TLS/SSL protocols at the application layer, often through a browser. ESP (Encapsulating Security Payload) and AH (Authentication Header) are the protocol headers used by IPsec, which works at the network layer to protect entire IP packets. Confusing these two very different protocol suites is a common misconception, but the technology doesn't belong to SSL VPNs.

The session is fully established and has been active for 3600 seconds.

Why it fails: The hexadecimal state value '01' in the diagnose sys session output is the TCP SYN_SENT state, not an established session. Fortinet represents fully established sessions with state codes such as '09' or '0a', and a session in state 01 has never completed the three-way handshake, so it cannot be 'fully established' despite the 3600-second duration.

The session has been idle for 3599 seconds and will expire soon.

Why it fails: The 'expire' field in the diagnose sys session output is a countdown timer that decrements until the session is purged from the session table, not a measurement of idle time. A value of 3599 seconds means the session still has close to an hour before timing out, so it is not expiring soon, and the state code 01 shows the session is in SYN_SENT, not an idle established connection.

The session is in FIN_WAIT state and is being closed.

Why it fails: TCP FIN_WAIT states are represented by different hex codes, such as '03' for FIN_WAIT, and occur during connection teardown after an established connection has exchanged FIN packets. Since the output shows state '01', the session is still in SYN_SENT and has never reached the established state, so it cannot be in the process of closing a connection.

The remote user's browser does not support SSL VPN.

Why it fails: All modern web browsers fully support TLS/SSL, the cryptographic protocol that secures FortiGate SSL VPN web mode. The user is able to reach the SSL VPN portal and authenticate, which itself proves the browser can handle SSL. A browser that could not perform SSL would not even load the HTTPS login page. Therefore, browser incompatibility is not the cause of the internet access failure.

The split tunneling setting is disabled.

Why it fails: Split tunneling determines whether only corporate-destination traffic enters the tunnel or all traffic (including internet traffic) enters the tunnel. When split tunneling is disabled, all traffic is forced through the FortiGate tunnel — it does not cause internet traffic to bypass the FortiGate. The user's failure to reach the internet is therefore not because split tunneling is disabled; in fact, disabling split tunneling ensures internet traffic arrives at the FortiGate, where it still requires a permissive security policy to be forwarded out the WAN. A missing firewall policy, not the split-tunnel setting, best explains the symptom.

The SSL VPN portal is configured in web mode only; tunnel mode is required for internet access.

Why it fails: Web mode on an SSL VPN portal is a reverse-proxy feature that provides browser-based access only to specified web applications, not a full network-layer tunnel. While a full internet tunnel is typically delivered via tunnel mode, the portal being in web mode does not preclude internet access for browser-based HTTP/HTTPS traffic — the FortiGate can still apply firewall policies and NAT. The administrator's configuration of web mode is not the fundamental cause of the internet failure; the missing or incorrect firewall policy is. Moreover, split tunneling is a tunnel-mode concept, so citing it alongside a web-mode portal is a category error when diagnosing this issue.

Enable NAT on the hub's tunnel interface.

Why it fails: NAT on the hub tunnel interface rewrites spoke source addresses, so the hub cannot preserve the original spoke subnets needed for spoke-to-spoke routing; the requirement is permitting intra-overlay traffic via firewall policy and routing. NAT would be correct when hiding private addresses behind a single public address.

Configure the hub as a DNS server for the spokes.

Why it fails: DNS resolution does not enable IP forwarding between spokes; the hub must route and permit overlay traffic between spoke subnets through firewall policy and correct phase 2 selectors. DNS on the hub would be correct when spokes need centralised name resolution for internal hostnames.

Configure IKEv2 instead of IKEv1 on all tunnels.

Why it fails: IKEv2 versus IKEv1 is a negotiation-version choice and does not control whether the hub relays traffic between spokes; that requires hub-and-spoke overlay configuration such as a spoke-to-spoke firewall policy and route propagation. IKEv2 would be correct when stronger rekeying or MOBIKE support is required.

'execute ping 8.8.8.8'

Why it fails: The 'execute ping 8.8.8.8' command only tests the FortiGate's outbound Internet connectivity, which is unrelated to the SSL VPN tunnel's ability to reach internal resources. SSL VPN users connect via the tunnel interface, so their traffic is governed by internal routing and firewall policies; an external ping neither validates the tunnel nor the internal path. Thus, it provides no diagnostic value for an SSL VPN access problem.

'diagnose debug application sslvpn -1'

Why it fails: The debug command 'diagnose debug application sslvpn -1' activates low-level SSL VPN debugging with maximum verbosity, generating a continuous and overwhelming stream of log messages that can degrade FortiGate performance and make it impossible to isolate the actual fault. For initial troubleshooting, administrators should instead examine the SSL VPN endpoint status, event logs, or use a filtered debug like 'diagnose debug application sslvpn 5' with a time limit. Consequently, this command is too broad and disruptive for the first diagnostic step.

Configure a RADIUS server to forward FortiToken requests

Why it fails: This approach misunderstands where FortiToken validation occurs. FortiToken seeds are stored natively on the FortiGate, and the device itself generates and verifies the expected OTP based on the system time. A RADIUS server can be used as an external authentication source, but it does not 'forward' FortiToken requests; the FortiGate retains the token-seed database and performs the challenge itself. Configuring RADIUS in this manner would not enable FortiToken validation and would instead add an unnecessary dependency.

Set the SSL VPN portal to require client certificates

Why it fails: Client certificates rely on a public key infrastructure (PKI) and prove device or user identity via a digital certificate installed on the client. FortiToken, by contrast, is a time-based one-time password (TOTP) mechanism that requires the user to type a dynamically generated code. Requiring client certificates changes the TLS handshake requirements for the SSL VPN portal but does nothing to enforce, validate, or even involve FortiToken OTPs. These are independent cryptographic methods and cannot be substituted for one another.

Install the FortiToken mobile app on the FortiGate

Why it fails: The FortiToken mobile app is a software token that runs on the end user's smartphone or other client device. It generates the OTP that the user enters during the authentication process. Installing it on the FortiGate would be nonsensical, because the FortiGate's role is to validate the OTP using the stored token seed, not to generate the user's login code for itself. This misplacement does not satisfy the configuration requirement and would leave two-factor authentication fully unimplemented.

Set the SSL VPN portal's 'tunnel mode' to 'web-only'

Why it fails: The 'tunnel mode' setting in an SSL VPN portal is a toggle, not an enum that accepts 'web-only'. Tunnel mode and web mode are distinct access mechanisms: if tunnel mode is enabled, the client establishes a Layer 3 tunnel; if disabled, the portal provides web-based access to specific resources. 'Web-only' is not a valid value, so this option is a misconfiguration that would not produce a working tunnel or split tunneling behavior.

Disable 'tunnel mode' and use 'web mode' instead

Why it fails: Web mode does not provide a Layer 3 virtual adapter on the client, so it cannot install routes or carry arbitrary IP traffic to the 192.168.1.0/24 network. It only gives browser-based access to a pre-defined set of web applications or shared files. For split tunneling, the client must be in tunnel mode to create a virtual interface, receive pushed routes, and forward IP packets; disabling tunnel mode in favor of web mode eliminates this capability entirely.

Create a firewall policy on the FortiGate allowing traffic from the SSL VPN interface to the corporate network

Why it fails: A firewall policy permitting traffic from the SSL VPN interface to the corporate network is a necessary but not sufficient condition for connectivity; it applies equally to full-tunnel and split-tunnel configurations. This policy does not affect the client's route table or its decision of which destinations to send through the tunnel. Merely creating the policy would still allow a client that is not configured with the 192.168.1.0/24 route to fail to reach the corporate network, so it is not the specific setting for split tunneling.

A single firewall policy can control traffic to all spokes

Why it fails: A single firewall policy cannot control traffic to all spokes. Each spoke terminates its own tunnel interface on the hub, and FortiGate policies are tied to specific interfaces (or zones). Even if multiple spokes are in the same zone, a policy defined for one tunnel interface does not automatically apply to others unless they are grouped in a zone and the policy uses that zone. In practice, each spoke's tunnel interface must be matched by its own policy or a zone-based policy, but a single policy referencing only one interface will not cover all spokes.

Aggressive mode must be enabled for the hub to accept multiple spokes

Why it fails: Aggressive mode is not required for the hub to accept multiple spokes. FortiGate hubs can accept multiple IPsec connections using main mode by setting the remote gateway to 0.0.0.0 (or 0.0.0.0/0) in the Phase 1 configuration, which allows any peer IP to initiate. Main mode is more secure because it does not send identity information unencrypted (unlike aggressive mode). Aggressive mode is only needed when the peer's IP address is dynamic and cannot be predefined, but a hub can still use main mode with a wildcard remote gateway to accommodate multiple spokes.

All spokes can share the same Phase 1 configuration

Why it fails: All spokes cannot share the same Phase 1 configuration. Each spoke has a unique IP address and typically a unique pre-shared key (PSK) or certificate, so Phase 1 parameters like the peer ID and secret must differ per spoke. On the hub, you either create separate Phase 1 entries for each spoke or use a dial-up group with distinct authentication per peer, but the configuration cannot be identical for all spokes because the hub must be able to distinguish between them. Sharing one Phase 1 with a single peer IP would only allow one spoke to connect, and reusing the same PSK across all spokes would compromise security.

Create a RADIUS server pointing to FortiAuthenticator

Why it fails: Creating a RADIUS server pointing to FortiAuthenticator is not required for FortiGate to use FortiTokens locally. FortiGate can act as a token server, and tokens can be registered directly on the FortiGate itself via the user account settings. Using a RADIUS server introduces an external dependency and does not enable the built-in FortiToken two-factor feature on the user group; it would instead rely on a separate authentication path that does not match the direct local token method.

Set the authentication timeout to 60 seconds

Why it fails: Setting the authentication timeout to 60 seconds merely controls how long a user has to complete the authentication challenge, typically after entering credentials or a token code. This parameter does not configure any token or two-factor mechanism on the FortiGate. For FortiToken two-factor authentication, the token must be assigned to the user account and the user group must require the 'fortitoken' authentication method; adjusting the timeout has no bearing on enabling that method.

Configure SSL VPN to use certificate authentication

Why it fails: Configuring SSL VPN to use certificate authentication is a different form of two-factor authentication that relies on a client certificate, not a FortiToken. FortiToken is a hardware or software OTP generator, and its use is controlled by adding the token to the user account and enabling 'fortitoken' in the user group. Certificate authentication does not incorporate FortiToken and would not satisfy the requirement to enable FortiToken-based two-factor authentication.

Pre-shared key (PSK) for each user

Why it fails: Managing individual PSKs is difficult; certificates are better.

IKEv2 with EAP

Why it fails: While IKEv2 with EAP is a robust authentication method for VPNs, it's not the ideal choice here because it typically relies on an external RADIUS server for user authentication, which isn't specified as part of this FortiGate dial-up VPN setup for individual user identities. It's tempting because EAP provides a framework for various authentication protocols, making it suitable for scenarios where integration with enterprise identity providers like Microsoft Entra ID or RADIUS is required to authenticate users dynamically.

Aggressive mode with PSK

Why it fails: Aggressive mode with PSK is less secure and does not provide individual identity.

The Phase 1 proposal is too strong and the remote FortiGate does not support DH14

Why it fails: If the remote side does not support DH14, Phase 1 would fail, but typically both sides are configured identically. The issue is Phase 2 mismatch.

The VPN policy has not been configured on the remote FortiGate

Why it fails: Missing policy would cause traffic not to be encrypted, but the tunnel can still establish.

The pre-shared key is incorrect

Why it fails: Incorrect PSK would cause Phase 1 failure, not specifically Phase 2 mismatch.

The remote user's client does not support split tunneling

Why it fails: Split tunneling is configured on the FortiGate, not the client.

The authentication timeout is too short

Why it fails: Timeout would cause disconnection, not inability to access resources.

The SSL VPN portal does not have the correct bookmark configured

Why it fails: Bookmarks are for web mode, not tunnel mode.

IKEv2 without mode

Why it fails: IKEv2 is a separate protocol version, not a negotiation mode like main or aggressive mode. It consolidates the entire phase 1 into a single exchange (IKE_SA_INIT and IKE_AUTH) that intrinsically supports dynamic IP addresses through built-in NAT traversal and optional EAP. Since the question explicitly asks for an IKE mode, selecting 'IKEv2 without mode' is technically invalid — it does not exist as an option within IKEv1's mode framework.

Dial-up mode

Why it fails: Dial-up mode in FortiOS is designed for client-to-site VPNs where remote users with dynamic IPs (e.g., FortiClient or third-party IPsec clients) dial in to a central FortiGate. For a site-to-site VPN, both endpoints are gateway peers, and the configuration expects a pre-shared key and symmetric negotiation; dial-up mode is a one-way, responder-style setup that does not support the bidirectional tunnel requirements between two sites. Even if one site has a dynamic IP, the peer type must remain gateway, not dial-up client.

Main mode

Why it fails: Main mode in IKEv1 uses a six-packet exchange and encrypts identity payloads only after the Diffie-Hellman session is established, which requires both peers to have predictable, static IP addresses. Since the responder cannot pre-identify a dynamic initiator without seeing identity in cleartext, main mode will fail when the remote side's IP changes. The lack of identity protection during the first packets is precisely why main mode is unsuitable for dynamic peer scenarios.

Enable 'forward traffic' in Phase 1 settings

Why it fails: There is no such setting; traffic forwarding is controlled by policies and routing.

Disable anti-replay on all tunnels

Why it fails: Disabling anti-replay is not required and reduces security.

Captive portal enabled

Why it fails: A captive portal is a firewall authentication method used to redirect and authenticate devices that attempt HTTP/HTTPS access through an interface before granting network access. It authenticates users against firewall policies, not as part of an SSL VPN tunnel establishment, and it does not invoke FortiToken OTP validation as a second factor. Enabling it would only affect network access control for local LAN/WAN traffic, leaving the SSL VPN authentication sequence completely unchanged.

RADIUS server configured for one-time passwords

Why it fails: Although a RADIUS server can provide one-time passwords through external OTP systems like RSA SecurID or a separate token server, it is not a required component for FortiGate's native FortiToken-based two-factor authentication. The question specifically asks about the required components for SSL VPN two-factor authentication; the mandatory pieces are the portal toggle and a user-bound FortiToken, while RADIUS is only an alternative or supplementary authentication source. Configuring RADIUS for OTP does not by itself set up two-factor authentication on the SSL VPN portal unless the token source is properly integrated and the portal is configured to enforce it.

IPsec Phase 1 authentication set to 'signature'

Why it fails: The IPsec Phase 1 authentication setting of 'signature' refers to the IKE authentication method for IPsec VPN tunnels, specifically RSA digital signatures used in certificate-based authentication, not to SSL VPN or OTP. Since SSL VPN operates on the web portal and uses TLS/HTTPS, its authentication is configured separately through the SSL VPN settings and user group policies, not via IPsec Phase 1 parameters. Even if this setting were changed, it would have zero effect on SSL VPN two-factor authentication and would only impact IPsec peer authentication behavior.

The captive portal is using a self-signed certificate causing browser warnings

Why it fails: A self-signed certificate on the captive portal will generate an HTTPS warning in the browser, but after the user manually accepts the certificate and logs in, the FortiGate has already authenticated the user and created a session. Browser warnings do not retroactively block subsequent HTTP/HTTPS requests to other sites; they only affect the initial portal page load. Therefore, this explains why the portal page appears, not why the user is denied access after a successful login.

The DNS server is not configured on the FortiGate

Why it fails: The FortiGate's own DNS configuration is used for resolving FQDNs in firewall policies, DNS server objects, and FortiGuard lookups, but it is not involved in forwarding user client DNS queries after captive portal authentication. End-user devices typically get their DNS servers from DHCP or are statically configured, and they send queries directly to those servers, completely bypassing the FortiGate's DNS settings. A missing or misconfigured DNS on the FortiGate would cause issues like failing to resolve an FQDN in a policy, but it would not block a user from reaching an IP-based site immediately after logging in, nor would it affect only the post-authentication state.

The session timeout is set too low

Why it fails: A session timeout that is too low would cause the FortiGate to expire the user's session or the firewall session after a period of inactivity, forcing the user to re-authenticate or making the connection drop after an idle time. It would not, however, cause the user to lose access to all other sites immediately after a successful login, because the newly created session has plenty of time left. If the timeout were the problem, the user would initially be able to browse normally and then, after a short idle period, be redirected to the captive portal again or see connection failures, not an instant denial of all subsequent traffic.

diagnose hardware sysinfo memory

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

diagnose netlink interface list

Why it fails: Interface status is already known; tunnel is up.

execute ping-options source and execute ping

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

Assign a public IP address to the SSL VPN interface

Why it fails: Assigning a public IP address to the SSL VPN interface is incorrect because the SSL VPN interface is a logical tunnel endpoint on the FortiGate that uses a private IP address from a reserved range (e.g., 10.212.134.200/32). The public IP address belongs on the WAN interface, where the SSL VPN terminates the encapsulated tunnel. Putting a public IP on the SSL VPN interface would cause IP conflicts and routing ambiguities, and it is not part of the split-tunneling configuration.

Configure a static route on the FortiGate to send all traffic through the SSL VPN tunnel

Why it fails: Configuring a static route on the FortiGate to send all traffic through the SSL VPN tunnel is the opposite of split tunneling and misplaces the routing control. A static route on the FortiGate would affect traffic originating from the FortiGate itself or from other interfaces, not the routing decisions made by the SSL VPN client. Moreover, directing all traffic into the tunnel interface would cause a routing loop or a black hole, because the tunnel interface itself relies on the WAN interface for encapsulation. Split tunneling is about client-side routing, so the correct place to define tunneled destinations is in the portal's routing policy.

A RADIUS server configured for user authentication

Why it fails: A RADIUS server is not part of FSSO; FSSO uses Active Directory logon events.

An IPsec tunnel between FortiGate and the domain controller

Why it fails: An IPsec tunnel is not required; the FortiGate communicates with the domain controller or collector agent via standard network paths.

FortiToken license for each user

Why it fails: FortiToken licenses are for two-factor authentication, not for FSSO operation.