Knowledge + Practice

CCNA Authentication and VPN Questions

75 of 148 questions · Page 1/2 · Authentication and VPN · Answers revealed

Practice these questions Domain overview All questions

1

MCQmedium

A FortiGate with multiple VDOMs is configured for FSSO with Active Directory polling. Users in VDOM1 are authenticated correctly, but users in VDOM2 are not. What should be checked FIRST?

A.The DNS resolution for the domain controller in VDOM2

B.The firewall policy ordering in VDOM2

C.The FSSO collector agent settings for VDOM2

D.The LDAP server configuration in VDOM2

AnswerC

In a multi-VDOM architecture, each VDOM is a separate security context, so FSSO collector agent settings must be defined individually for every VDOM that requires single sign-on. If VDOM2 lacks its own collector agent configuration, or if the configured agent's IP, port, shared secret, or AD polling credentials are incorrect, the FortiGate will not receive login events for users in that VDOM. Without these events, FSSO cannot map users to IP addresses, breaking user-aware policies. This is the root cause and the correct answer.

Why this answer

In a multi-VDOM FSSO setup with Active Directory polling, each VDOM requires its own FSSO collector agent configuration to map domain users to the correct VDOM. Since VDOM1 works but VDOM2 does not, the most likely cause is that the FSSO collector agent settings for VDOM2 are missing or misconfigured, such as the collector agent IP, port, or shared secret. This is the first item to verify because FSSO polling relies on per-VDOM agent communication to deliver user-to-IP mappings.

Exam trap

The trap here is that candidates often assume LDAP server configuration is the root cause for any authentication failure, but FSSO polling relies on the collector agent, not LDAP binds, making Option D a common distractor.

How to eliminate wrong answers

Option A is wrong because DNS resolution for the domain controller is a prerequisite for LDAP or FSSO polling to function at all; if it were broken, VDOM1 would also fail, and DNS issues typically affect all VDOMs equally. Option B is wrong because firewall policy ordering affects traffic matching and access control, not the authentication mechanism itself; FSSO user groups can be used in policies, but the failure to authenticate users in VDOM2 is not caused by policy order. Option D is wrong because LDAP server configuration is used for direct LDAP authentication, not for FSSO polling; FSSO with Active Directory polling uses the collector agent to obtain user logon events from domain controllers, not an LDAP bind.

Practice this question →

2

MCQhard

An administrator is troubleshooting an IPsec VPN that fails to establish Phase 2. The Phase 1 is up. The administrator runs 'diagnose vpn ike log' and sees the message 'no matching phase2 proposal found'. What is the MOST likely cause?

A.Pre-shared key mismatch

B.IKE version mismatch (IKEv1 vs IKEv2)

C.Phase 1 encryption algorithm mismatch

D.Phase 2 proxy ID mismatch

AnswerD

Phase 2 proxy IDs define the exact local and remote networks that the IPsec tunnel will protect. A mismatch in these traffic selectors—for example, one side sends 10.0.0.0/24 while the other expects 192.168.0.0/24—causes the Quick Mode negotiation to fail even after a successful Phase 1. FortiGate logs often show 'no matching Phase 2 proposal' or 'receive proxy ID not acceptable.' This is the classic cause of a Phase 2 failure.

Why this answer

The message 'no matching phase2 proposal found' indicates that the IPsec security associations (SAs) proposed by the remote peer do not match the local Phase 2 configuration. Phase 2 uses proxy IDs (local/remote subnets and ports) to define which traffic should be encrypted. A mismatch in these proxy IDs, such as incorrect subnet definitions or protocol/port values, prevents the IKE negotiation from completing Phase 2, even though Phase 1 (which authenticates and establishes the IKE SA) is already up.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 failures, assuming a Phase 2 error like 'no matching phase2 proposal' is caused by authentication or encryption mismatches, when it is specifically a proxy ID or traffic selector mismatch.

How to eliminate wrong answers

Option A is wrong because a pre-shared key mismatch would prevent Phase 1 from establishing, not Phase 2; Phase 1 authentication occurs before Phase 2 begins. Option B is wrong because an IKE version mismatch (IKEv1 vs IKEv2) would cause a failure during Phase 1 negotiation, not Phase 2, as the IKE version is negotiated first. Option C is wrong because a Phase 1 encryption algorithm mismatch would prevent Phase 1 from completing; Phase 2 proposals are independent of Phase 1 algorithms and are negotiated after Phase 1 is established.

Practice this question →

3

MCQhard

A FortiGate is configured in an HA active-passive cluster. When the active unit fails, the passive unit takes over, but IPsec VPN tunnels fail to re-establish. The configuration is synchronized. What is the most likely cause?

A.The pre-shared key is different on the two units.

B.The firewall policies for VPN traffic are not synchronized.

C.The HA heartbeat interface is down.

D.The IPsec VPN is using the physical interface IP instead of a virtual IP (VIP) or floating IP.

AnswerD

In an active-passive HA pair, the physical interface IP address is owned by the active unit only, and when failover occurs the new active unit uses its own physical IP, which differs from the previous one. IPsec tunnels identify peers by IP address during IKE phase 1 and phase 2, so any change in the local endpoint breaks the existing SAs and prevents new ones from being established. Configuring a virtual IP or floating IP for the IPsec endpoint ensures the address stays constant across failover, allowing the tunnel to survive the transition.

Why this answer

In an HA active-passive cluster, IPsec VPN tunnels typically bind to the physical interface IP address. When failover occurs, the passive unit assumes the cluster's virtual MAC and IP addresses, but the IPsec tunnel endpoints remain tied to the original physical IP. Since the new active unit has a different physical interface IP, the remote peer sees a mismatched source address and drops the connection.

Using a virtual IP (VIP) or floating IP ensures the tunnel endpoint stays consistent across failover.

Exam trap

The trap here is that candidates assume configuration synchronization covers all aspects of VPN operation, overlooking that IPsec tunnels bind to physical interface IPs by default unless explicitly configured with a virtual IP or floating address.

How to eliminate wrong answers

Option A is wrong because the pre-shared key is synchronized as part of the configuration, so both units share the same key; a mismatch would prevent initial synchronization, not cause failover-specific failure. Option B is wrong because firewall policies for VPN traffic are also synchronized in the HA configuration, so they are identical on both units. Option C is wrong because the HA heartbeat interface being down would prevent failover from occurring at all, not cause VPN tunnels to fail after a successful takeover.

Practice this question →

4

MCQmedium

You run the following command on a FortiGate: diagnose vpn ike gateway list. The output shows a gateway with state=DOWN. What is the most likely cause?

A.The remote peer is not reachable or is blocking IKE traffic

B.The pre-shared key is correct but expired

C.The IPsec Phase 2 parameters are mismatched

D.The local certificate is not trusted by the remote peer

AnswerA

The `diagnose vpn ike` output showing an IKE SA state of DOWN typically indicates that no IKE negotiation response has been received. This commonly means the remote peer is unreachable at the network layer (no route, filter, or the peer is down) or that IKE traffic on UDP ports 500/4500 is being blocked by an intermediate firewall. Before investigating authentication or configuration mismatches, you must verify basic IP connectivity and bidirectional UDP reachability to the peer's public IP address.

Why this answer

The `state=DOWN` in the `diagnose vpn ike gateway list` output indicates that the IKE Phase 1 (main mode or aggressive mode) negotiation has failed or never completed. The most common cause is that the remote peer is unreachable (e.g., due to network issues, firewall rules blocking UDP ports 500/4500, or incorrect peer IP configuration) or that the remote peer is actively blocking IKE traffic, preventing the initial exchange of IKE SA proposals.

Exam trap

Candidates often confuse Phase 1 (IKE) failures with Phase 2 (IPsec) issues, but state=DOWN indicates a Phase 1 problem. However, certificate trust errors are also Phase 1 failures; they are not excluded by state=DOWN, but the most likely cause among the options is remote peer unreachable/blocking IKE traffic.

How to eliminate wrong answers

Option B is wrong because pre-shared keys do not have an expiration attribute in IKEv1 or IKEv2; they are static credentials and cannot 'expire' — certificate expiration is a separate concept. Option C is wrong because Phase 2 (IPsec SA) parameters are negotiated only after Phase 1 (IKE) is successfully established; a Phase 1 state of DOWN means Phase 2 has not yet been attempted. Option D is wrong because certificate trust issues would only manifest during IKE authentication if certificate-based authentication is configured, but the state=DOWN indicates the IKE SA itself was never formed, which occurs before certificate validation; certificate errors typically result in a state like AUTH_FAILED or DOWN with specific error messages, not a generic DOWN state.

Practice this question →

5

MCQhard

A company has a FortiGate at headquarters running FortiOS 7.2 and a remote office with a FortiGate 60F running FortiOS 7.0. They have an IPsec VPN tunnel between them for site-to-site connectivity. Recently, the remote office upgraded their FortiGate from 6.4 to 7.0. After the upgrade, the VPN tunnel is down. The Phase 1 status shows 'negotiating' but never completes. The administrator has verified that the pre-shared key, IKE version (IKEv2), and authentication method are the same on both sides. The Phase 1 proposal on the headquarters is: encryption: AES256, SHA256, DH group 14, lifetime 86400. The remote office uses: encryption: AES256, SHA1, DH group 14, lifetime 86400. What is the most likely cause of the failure?

A.The DH group is different; headquarters uses group 14, remote uses group 5.

B.The Phase 1 hash algorithm differs; headquarters uses SHA256, remote uses SHA1.

C.The IKE version is mismatched; headquarters uses IKEv2 and remote uses IKEv1.

D.The pre-shared key is incorrect after the upgrade.

AnswerB

The Phase 1 hash algorithm (also known as the integrity algorithm) is indeed the mismatch: the headquarters FortiGate expects SHA-256 while the remote peer is configured with SHA-1. During IKE Phase 1 negotiation, both peers exchange proposal payloads containing the hash algorithm, and if the hashes do not match, the IKE SA cannot be established. SHA-1 is outdated and not often the default in FortiOS 7, but if the remote peer still uses it, the SA negotiation fails immediately. This is the correct answer because the hash algorithm must be identical on both VPN endpoints.

Why this answer

The Phase 1 proposal mismatch on the hash algorithm (SHA256 vs. SHA1) prevents the IKEv2 peers from agreeing on a common transform set. Even though all other parameters match, the hash algorithm must be identical on both sides for the IKE SA to be established.

The 'negotiating' state that never completes is a classic symptom of a proposal mismatch.

Exam trap

The trap here is that candidates assume all Phase 1 parameters are correct because the pre-shared key, IKE version, and authentication method match, overlooking the critical requirement that the hash algorithm must also be identical for the IKE SA to be established.

How to eliminate wrong answers

Option A is wrong because the DH group is explicitly stated as group 14 on both sides, so there is no mismatch. Option C is wrong because the administrator verified that IKEv2 is used on both sides, and the question states the IKE version is the same. Option D is wrong because the administrator has verified that the pre-shared key is the same after the upgrade, and an incorrect PSK would typically result in a different Phase 1 status (e.g., 'down' with authentication failures) rather than indefinite 'negotiating'.

Practice this question →

6

MCQmedium

A company uses Active Directory for user authentication. They want users to automatically authenticate to the FortiGate without entering credentials when accessing the internet. Which authentication method should the administrator configure?

A.LDAP authentication with captive portal

B.RADIUS authentication with PAP

C.Local user authentication

D.FSSO with Active Directory polling

AnswerD

FSSO with Active Directory polling is correct because it provides transparent, non-interactive authentication. A collector agent polls the Active Directory domain controllers for Windows security event logs, capturing successful user logon events and mapping them to the user's IP address. This information is sent to the FortiGate, which dynamically associates the user's traffic with their AD identity without requiring any manual credential entry. As a result, the firewall can apply user-based policies based on AD logon activity, seamlessly authenticating users as they access the network.

Why this answer

FSSO (Fortinet Single Sign-On) with Active Directory polling allows users to be automatically authenticated to the FortiGate based on their existing Windows domain login. The FortiGate polls the domain controllers for user logon events, mapping the user's IP address to their authenticated identity without requiring any additional credential entry. This meets the requirement of transparent internet access authentication.

Exam trap

The trap here is that candidates often confuse LDAP authentication (which requires credential entry) with FSSO (which provides transparent authentication), leading them to select LDAP with captive portal thinking it integrates with Active Directory for automatic login.

How to eliminate wrong answers

Option A is wrong because LDAP authentication with captive portal requires users to manually enter their credentials on a web portal, which contradicts the requirement for automatic authentication. Option B is wrong because RADIUS with PAP still requires the user to provide credentials (typically via a captive portal or VPN client) and does not provide seamless single sign-on from the Windows login. Option C is wrong because local user authentication requires users to be defined locally on the FortiGate and always demands credential entry, offering no integration with Active Directory for automatic authentication.

Practice this question →

7

MCQhard

A FortiGate administrator is configuring FSSO with Active Directory polling. Users in the 'Sales' group are not being authenticated correctly, while users in the 'IT' group are working fine. The administrator verifies that the FSSO agent is connected and polling the domain controllers. Which action should the administrator take to troubleshoot the issue?

A.Verify that the 'Sales' group exists in Active Directory and has the correct permissions.

B.Check the FSSO group filter and ensure that the 'Sales' group is included in the FSSO configuration.

C.Increase the 'polling interval' in the FSSO configuration to reduce latency.

D.Restart the FSSO agent service on the domain controller.

AnswerB

If the 'Sales' group is not included in the FSSO group filter, the FortiGate will not recognize users from that group as authenticated. The administrator should verify that the FSSO configuration on the FortiGate includes the 'Sales' group, either by selecting it in the FSSO connector or by using a group filter that matches it. This is a common oversight when some groups work and others do not.

Why this answer

In FSSO with AD polling, the FortiGate only monitors and authenticates users from groups that are included in the FSSO configuration. If the 'Sales' group is not selected or does not match a group filter, users in that group will not be recognized as authenticated. The administrator should check the FSSO connector settings to ensure the 'Sales' group is included.

Other actions like restarting the agent or changing polling interval are unlikely to help because the 'IT' group works, indicating the agent is operational.

Exam trap

The trap here is assuming that FSSO automatically authenticates all groups, but it only does so for groups explicitly included in the FSSO configuration or matching a filter.

Practice this question →

8

MCQeasy

Which authentication server type can be used with FortiGate to authenticate remote VPN users with two-factor authentication using FortiTokens?

A.POP3

B.LDAP

C.RADIUS

D.TACACS+

AnswerC

RADIUS (Remote Authentication Dial-In User Service) is the standard centralized authentication protocol for network access, and FortiGate supports it for VPN and firewall authentication. It can be integrated with a RADIUS server, such as FortiAuthenticator, to validate both the user password and FortiToken two-factor codes. This makes RADIUS the correct and widely used authentication server type for FortiGate with two-factor authentication.

Why this answer

RADIUS is the correct authentication server type because it supports two-factor authentication with FortiTokens, including the ability to forward token challenges (e.g., one-time passwords) between FortiGate and the RADIUS server. FortiGate acts as a RADIUS client, sending authentication requests to a RADIUS server that validates both the user's primary credentials and the FortiToken OTP, enabling secure remote VPN access.

Exam trap

The trap here is that candidates often confuse LDAP with RADIUS, assuming LDAP can handle two-factor authentication because it is commonly used for user directory lookups, but LDAP lacks the protocol mechanisms (like Access-Challenge) to support token-based OTP validation required for FortiTokens.

How to eliminate wrong answers

Option A is wrong because POP3 is an email retrieval protocol (Post Office Protocol version 3) and cannot perform authentication server functions, let alone two-factor authentication with FortiTokens. Option B is wrong because LDAP is a directory access protocol that supports only single-factor authentication (username/password) and cannot process FortiToken OTP challenges or two-factor authentication natively. Option D is wrong because TACACS+ is a Cisco-proprietary AAA protocol that separates authentication, authorization, and accounting but does not support FortiToken two-factor authentication; FortiGate does not use TACACS+ for FortiToken-based VPN authentication.

Practice this question →

9

MCQmedium

You have a hub-and-spoke IPsec VPN with 10 spokes. The central FortiGate (hub) has 10 phase2 selectors, one for each spoke. You need to add a new spoke. What is the MOST efficient way to configure the hub?

A.Configure a route-based VPN and use dynamic routing protocols to advertise routes

B.Add another phase2 selector for the new spoke

C.Replace all phase2 selectors with a single policy-based VPN

D.Use a single phase2 selector with 0.0.0.0/0.0.0.0 for all spokes

AnswerA

Route-based VPNs abstract the tunnel as a virtual interface, so you can run a dynamic routing protocol like BGP or OSPF across it to advertise learned routes automatically. When a new spoke is added, the hub only needs to form a routing adjacency with that spoke, and the spoke's subnets are injected into the hub's routing table without touching phase2 selectors or traffic policies. This is the only option that truly scales to 10+ spokes because routing information propagates dynamically, eliminating per-spoke manual configuration.

Why this answer

A route-based VPN with dynamic routing (e.g., BGP or OSPF) is the most efficient approach because it eliminates the need to manually add a new phase2 selector for each new spoke. The hub can automatically learn the spoke's routes via the dynamic routing protocol, and the single phase2 selector (0.0.0.0/0) covers all traffic, simplifying configuration and scaling. This design also supports redundancy and load balancing across multiple spokes without reconfiguring the hub.

Exam trap

The trap here is that candidates often think adding a new phase2 selector (Option B) is the simplest solution, but they overlook the scalability and maintenance burden, while the 0.0.0.0/0 selector (Option D) is mistakenly assumed to work in policy-based VPNs without understanding that it requires a route-based design to function correctly.

How to eliminate wrong answers

Option B is wrong because adding another phase2 selector for each new spoke is manual, does not scale well, and requires updating the hub configuration every time a spoke is added, which is inefficient for 10+ spokes. Option C is wrong because replacing all phase2 selectors with a single policy-based VPN would still require manual policy configuration for each spoke and does not leverage dynamic routing, making it less efficient and more error-prone. Option D is wrong because using a single phase2 selector with 0.0.0.0/0.0.0.0 for all spokes in a policy-based VPN would cause traffic to be sent to the wrong spoke (since the selector does not differentiate between spokes), breaking connectivity; this only works with route-based VPNs where the routing table determines the correct tunnel.

Practice this question →

10

MCQhard

A company with multiple remote sites uses IPsec VPNs. One site reports intermittent connectivity. The administrator checks the logs and sees 'IPsec phase 2 negotiation failed' messages. Which configuration change is most likely to resolve the issue?

A.Enable Dead Peer Detection (DPD) on the Phase 1 interface.

B.Change the encryption algorithm from AES256 to 3DES.

C.Increase the Phase 2 lifetime.

D.Enable NAT traversal.

AnswerA

DPD (Dead Peer Detection) sends periodic IKE keepalives to the remote gateway to confirm liveness. If no response is received, DPD marks the peer dead, tears down the stale IPsec SA, and triggers a fresh Phase 1/Phase 2 negotiation. This recovers quickly from transient routing or peer failures, which is exactly what your intermittent VPN drops suggest. Without DPD, the SA persists until its natural lifetime expires, causing a long blackout and requiring manual restart.

Why this answer

Intermittent IPsec phase 2 negotiation failures often occur when one peer's Phase 2 security association (SA) expires while the other peer still considers it valid, causing a mismatch. Enabling Dead Peer Detection (DPD) on the Phase 1 interface allows the FortiGate to actively probe the peer's liveness and renegotiate Phase 1 and Phase 2 SAs before they expire, preventing the state mismatch that leads to intermittent failures.

Exam trap

The trap here is that candidates often mistake intermittent phase 2 failures for a cryptographic or NAT issue, but the real cause is typically a mismatch in SA state between peers, which DPD is specifically designed to detect and recover from.

How to eliminate wrong answers

Option B is wrong because changing the encryption algorithm from AES256 to 3DES would weaken security and does not address the root cause of intermittent phase 2 negotiation failures; the issue is not about algorithm strength or compatibility. Option C is wrong because increasing the Phase 2 lifetime would only delay the SA expiration, not prevent the mismatch that occurs when one peer's SA expires before the other's; it may even mask the problem temporarily. Option D is wrong because NAT traversal is used to allow IPsec traffic to pass through NAT devices, and the problem described is intermittent connectivity due to SA state mismatch, not NAT-related packet drops.

Practice this question →

11

MCQhard

During an SSL VPN tunnel mode connection, the client reports that they cannot access any internal resources, but the VPN connection is established. The FortiGate debug shows 'no matching policy'. The administrator has configured a policy allowing the SSL VPN interface to internal. What else must be configured?

A.Ensure the incoming interface of the policy is set to 'ssl.root' (or the SSL VPN interface)

B.Add the client's assigned IP to a local user group

C.Configure a static route on the FortiGate for the client's tunnel IP

D.Enable split tunneling on the SSL VPN portal

AnswerA

The firewall policy that permits SSL VPN tunnel traffic must use the SSL VPN logical interface (ssl.root) as its incoming interface. When the client establishes a tunnel, the FortiGate terminates the encrypted session on ssl.root and assigns the virtual IP, so packets from the client enter through that interface, not the physical WAN. If the policy's incoming interface is set to WAN or any other interface, the policy lookup fails and the traffic is dropped.

Why this answer

The SSL VPN tunnel mode creates a virtual interface (typically named 'ssl.root' or 'ssl.VDOM') on the FortiGate. Even though the administrator configured a policy allowing the SSL VPN interface to internal, the incoming interface in the policy must explicitly be set to this SSL VPN interface. If it is set to a different interface (e.g., the physical WAN interface), the FortiGate will not match the traffic from the SSL VPN tunnel, resulting in the 'no matching policy' debug message.

Exam trap

The trap here is that candidates often assume that because the VPN connection is established and a policy exists allowing the SSL VPN interface, the traffic should pass, but they overlook that the policy's incoming interface must be explicitly set to the SSL VPN virtual interface (e.g., 'ssl.root') rather than the physical WAN interface.

How to eliminate wrong answers

Option B is wrong because adding the client's assigned IP to a local user group is not required for traffic forwarding; user group membership is used for authentication and policy matching based on user identity, not for IP-based routing or policy interface matching. Option C is wrong because a static route for the client's tunnel IP is unnecessary; the FortiGate automatically installs a route to the client's tunnel IP via the SSL VPN interface when the tunnel is established, and the issue is policy matching, not routing. Option D is wrong because split tunneling controls which traffic goes over the VPN versus the internet, but it does not affect the policy matching on the FortiGate; the 'no matching policy' error indicates the traffic is not hitting any policy, regardless of split tunneling settings.

Practice this question →

12

MCQeasy

An admin needs to authenticate remote users connecting via SSL VPN. The users are in an Active Directory domain. Which authentication method should be configured on the FortiGate to allow users to log in with their domain credentials?

A.LDAP server

B.Local user database

C.RADIUS server

D.FSSO

AnswerA

LDAP is the standard protocol for direct authentication against an Active Directory domain. When a remote user submits credentials via the SSL VPN portal, the FortiGate performs an LDAP bind to the domain controller using that username and password, verifying them against the AD directory. This is the most straightforward and native method for AD-based authentication, requiring no intermediate RADIUS infrastructure. LDAP also allows fetching group memberships for granular authorization policies.

Why this answer

LDAP (Lightweight Directory Access Protocol) allows FortiGate to directly query the Active Directory domain controller to authenticate users with their domain credentials. This method validates the username and password against the AD database without requiring an additional RADIUS server or local user accounts, making it the most straightforward choice for SSL VPN authentication with domain users.

Exam trap

The trap here is that candidates often confuse FSSO with direct authentication, assuming it can handle SSL VPN logins, when in fact FSSO only provides passive identity collection and cannot validate passwords for VPN access.

How to eliminate wrong answers

Option B is wrong because the local user database stores credentials only on the FortiGate itself, not in Active Directory, so domain users cannot log in with their domain credentials unless each user is manually duplicated as a local user. Option C is wrong because while a RADIUS server can proxy authentication to AD, it introduces an unnecessary intermediate server and is not the direct method for authenticating against AD; LDAP is the native protocol for directory services. Option D is wrong because FSSO (Fortinet Single Sign-On) is designed for transparent authentication and monitoring of domain users on the network, not for direct SSL VPN authentication; it does not validate passwords and relies on polling or agent-based logon events.

Practice this question →

13

MCQeasy

Which authentication method allows FortiGate to authenticate users against an Active Directory domain without storing domain credentials locally?

A.FSSO polling

B.RADIUS authentication

C.LDAP authentication

D.Local user database

AnswerC

LDAP authentication enables the FortiGate to connect directly to an Active Directory server using the LDAP protocol and perform a bind with the user's DN and provided password. This real-time directory bind verifies credentials against AD without storing any user secret on the FortiGate. This direct query and bind is why LDAP is the authentic direct authentication method for AD in FortiGate configurations.

Why this answer

LDAP authentication allows FortiGate to verify user credentials directly against an Active Directory domain controller without storing the domain passwords locally. The FortiGate sends a BIND request with the user's DN and password to the LDAP server, which validates the credentials and returns a success or failure response. This avoids local storage of domain credentials while still enabling centralized authentication.

Exam trap

The trap here is that candidates often confuse FSSO with LDAP authentication, thinking FSSO also authenticates users, when in fact FSSO only collects authentication events from the domain controller and does not perform password verification itself.

How to eliminate wrong answers

Option A is wrong because FSSO polling collects login events from domain controllers to map users to IP addresses, but it does not authenticate users by verifying passwords; it relies on the Windows domain already having authenticated the user. Option B is wrong because RADIUS authentication requires the FortiGate to forward credentials to a RADIUS server, which typically stores or has access to a shared secret and user credentials, but the FortiGate itself does not store domain credentials; however, the question specifies 'without storing domain credentials locally,' and LDAP is the direct method for querying AD without any intermediate credential storage on the FortiGate. Option D is wrong because the local user database stores usernames and password hashes directly on the FortiGate, which violates the requirement of not storing domain credentials locally.

Practice this question →

14

MCQhard

A FortiGate is configured with FSSO using a DC agent. Users authenticate to the domain, but the firewall policy using FSSO groups is not matching traffic. The admin runs 'diagnose debug authd fsso list' and sees user entries. However, the traffic is being denied by the default deny policy. What is the most likely issue?

A.The FSSO session timeout is too short

B.The session was established before the user logged in and is not updated with the user identity

C.The firewall policy has the wrong schedule applied

D.The user is not a member of the correct FSSO group in Active Directory

AnswerB

When a client establishes a session (e.g., a TCP connection or UDP flow) before the FSSO DC agent processes the user's login event, the FortiGate's session table entry is initially created with no user identity or with a default guest/anonymous mapping. The FortiGate does not retroactively apply the learned FSSO user to pre-existing sessions; it only assigns the user identity to new sessions created after the login event is synchronized. To resolve this, the existing session must be cleared (via 'execute session clear' or waiting for idle timeout) so that the next packet re-triggers session setup and gets the correct FSSO user attribute.

Why this answer

When a user logs in after a session is already established, the FortiGate does not automatically update that session with the user's identity. The 'diagnose debug authd fsso list' shows the user is authenticated, but the existing session still lacks the FSSO group information, causing it to match the default deny policy instead of the FSSO-based policy.

Exam trap

The trap here is that candidates see the user in the FSSO debug output and assume authentication is fully working, overlooking the fact that session identity is static and not updated for pre-existing sessions.

How to eliminate wrong answers

Option A is wrong because a short FSSO session timeout would cause the user entry to expire and disappear from the FSSO list, but the debug output shows user entries are present, so timeout is not the issue. Option C is wrong because a wrong schedule would cause the policy to be inactive at certain times, but the traffic is being denied by the default deny policy, not by a schedule mismatch. Option D is wrong because the debug output shows user entries, meaning the user is authenticated and the FSSO group membership is correctly retrieved from Active Directory; if the user were not in the correct group, the FSSO list would still show the user but without the expected group, which is not indicated here.

Practice this question →

15

MCQmedium

A company wants to use captive portal authentication on a guest Wi-Fi network. The FortiGate is connected to the switchport of the access point. Which firewall configuration is required to redirect unauthenticated users to the captive portal?

A.Set the 'Guest Management' feature in the FortiGate dashboard.

B.Create a policy with source interface 'guest', destination 'any', and action 'ACCEPT' with 'Authentication' set to 'Captive Portal'.

C.Configure a 'Landing Page' under SSL-VPN settings.

D.Enable 'Captive Portal' on the interface under System > Network > Interface.

AnswerB

The correct method is to configure a firewall policy that selects the 'guest' interface as the source, 'any' as the destination, and sets the action to ACCEPT while enabling 'Captive Portal' as the authentication method. When unauthenticated traffic matches this policy, FortiGate intercepts it and redirects the user to the captive portal for credentials. Once authenticated, the same policy permits the traffic, and this is the standard approach to enforce captive portal on a specific interface.

Why this answer

Captive portal authentication on a FortiGate requires a firewall policy that matches the unauthenticated traffic (source interface 'guest', destination 'any') with action 'ACCEPT' and the 'Authentication' setting set to 'Captive Portal'. This policy triggers the FortiGate to intercept HTTP/HTTPS traffic from unauthenticated users and redirect them to the captive portal login page, enforcing authentication before allowing further access.

Exam trap

The trap here is that candidates often think enabling 'Captive Portal' on the interface is sufficient, but they forget that a firewall policy with the correct action and authentication setting is required to actually trigger the redirect for unauthenticated traffic.

How to eliminate wrong answers

Option A is wrong because the 'Guest Management' feature in the FortiGate dashboard is used for managing guest user accounts and vouchers, not for configuring the redirect mechanism of captive portal authentication. Option C is wrong because 'Landing Page' under SSL-VPN settings is specific to SSL VPN portal customization and has no role in captive portal authentication on a physical or VLAN interface. Option D is wrong because enabling 'Captive Portal' on the interface under System > Network > Interface alone does not create the necessary firewall policy to redirect traffic; without a matching policy with authentication enabled, the captive portal will not intercept user traffic.

Practice this question →

16

MCQmedium

A network administrator configured an IPsec VPN between two FortiGates. Phase 1 is up, but Phase 2 fails to establish. The diagnose output shows 'no matching proposal'. What is the MOST likely cause?

A.The firewall policy allowing the VPN traffic is missing

B.The Phase 2 encryption and authentication algorithms do not match between peers

C.The pre-shared keys do not match

D.The remote gateway IP address is incorrect

AnswerB

Phase 2 negotiation requires both peers to select an identical set of encryption and authentication algorithms for the IPsec SA, such as AES256-GCM or AES128-SHA256, along with matching DH group and optional PFS. If the Phase 2 proposals are not aligned, the initiator's SA payload cannot find an acceptable combination in the responder's proposal list, causing a 'no proposal chosen' error and preventing the IPsec SAs from being created. This occurs after Phase 1 has already succeeded, which is exactly the symptom of a Phase 2-specific failure, such as when the tunnel status shows Phase 1 up but Phase 2 down.

Why this answer

The 'no matching proposal' error in Phase 2 indicates that the IPsec security association (SA) parameters—specifically the encryption algorithm, authentication algorithm, or Diffie-Hellman group—do not match between the two FortiGate peers. Phase 2 uses these proposals to negotiate the IPsec SA for protecting data traffic, and a mismatch prevents the tunnel from establishing. Since Phase 1 completed successfully, the pre-shared keys and gateway IP are already verified, isolating the issue to Phase 2 configuration.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 failures, assuming any 'no matching proposal' error relates to authentication or peer reachability, when it specifically points to mismatched IPsec SA parameters like encryption or authentication algorithms.

How to eliminate wrong answers

Option A is wrong because a missing firewall policy would not cause a 'no matching proposal' error; it would instead result in traffic not being matched to the VPN tunnel or being dropped after Phase 2 is up. Option C is wrong because mismatched pre-shared keys would cause Phase 1 to fail, not Phase 2, as Phase 1 authentication occurs before Phase 2 negotiation. Option D is wrong because an incorrect remote gateway IP would prevent Phase 1 from establishing, as IKE cannot reach the peer; Phase 2 cannot be attempted if Phase 1 is not up.

Practice this question →

17

Multi-Selectmedium

An administrator is troubleshooting an IPsec VPN between two FortiGates. Phase 1 is up but Phase 2 is down. The admin runs 'diagnose vpn ike log' and sees 'no matching proposal'. To resolve this issue, which TWO settings should be checked on both ends?

Select 2 answers

A.Phase 2 PFS (Perfect Forward Secrecy) group

B.Phase 1 authentication method

C.Phase 2 local and remote subnets

D.Phase 2 encryption algorithm (e.g., AES128, AES256)

E.Phase 1 encryption algorithm

AnswersA, D

Phase 2 'no matching proposal' commonly stems from PFS group mismatch. If one peer enables Perfect Forward Secrecy with a specific Diffie-Hellman group and the other uses a different group or disables PFS, the Phase 2 proposal cannot match, so both ends must use identical PFS settings.

Why this answer

The 'no matching proposal' error during Phase 2 negotiation means the two peers cannot agree on the Phase 2 (IPsec SA) parameters, so the administrator must verify the Phase 2 proposal settings on both ends. Option A is correct because the Phase 2 PFS (Perfect Forward Secrecy) group (e.g., DH group 5, 14, 19) is part of the Phase 2 proposal; if one side enables PFS with a different DH group than the other, or one side omits PFS entirely, the proposals will not match and Quick Mode will fail. Option D is correct because the Phase 2 encryption algorithm (e.g., AES128, AES256) must be identical on both peers; a mismatch in the encryption transform is a classic cause of 'no matching proposal' at Phase 2.

Options B and E are incorrect because the Phase 1 authentication method and Phase 1 encryption algorithm are negotiated during Phase 1 (Main/Aggressive Mode), and since Phase 1 is already up, those parameters have already matched successfully. Option C is incorrect because the Phase 2 local and remote subnets are the selectors used to build the IPsec SA; a subnet mismatch typically causes traffic to not match the tunnel or produces a 'no policy' or traffic-selector error, not a 'no matching proposal' error.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 parameters, assuming that a Phase 1 mismatch (like encryption algorithm or authentication method) could cause a Phase 2 'no matching proposal' error, when in fact Phase 2 has its own independent set of proposals including PFS and encryption algorithms.

Practice this question →

18

MCQmedium

An administrator configures a captive portal on the FortiGate to authenticate guest users via a local user database. Users can connect to the SSID, but after entering credentials on the captive portal, they are not redirected to the internet. What is the most likely missing configuration?

A.A firewall policy allowing traffic from the captive portal interface to the internet with the user group

B.The DNS server is not configured on the FortiGate

C.The captive portal timeout is set too low

D.The SSID is not configured with the captive portal security mode

AnswerA

Authentication alone does not grant internet access; FortiGate requires a firewall policy permitting traffic from the captive portal interface outbound, referencing the authenticated user group. Without this policy, credentials succeed but no forwarding rule matches, so users are never redirected.

Why this answer

A captive portal authenticates users but does not automatically grant network access. A firewall policy must explicitly allow traffic from the captive portal interface to the internet and include the authenticated user group as a source. Without this policy, even after successful authentication, traffic is dropped and users are not redirected to the internet.

Exam trap

The trap here is that candidates assume captive portal authentication alone grants internet access, but FortiGate requires a separate firewall policy with the authenticated user group to allow traffic, and the exam tests this distinction between authentication and authorization.

How to eliminate wrong answers

Option B is wrong because DNS server configuration is not required for captive portal redirection; the FortiGate can use DNS proxy or forward queries without a local DNS server. Option C is wrong because a low captive portal timeout would cause the session to expire prematurely, but it would not prevent redirection after successful authentication. Option D is wrong because the SSID must already be configured with captive portal security mode for users to be prompted for credentials; if it were missing, users would not even see the captive portal page.

Practice this question →

19

MCQmedium

A network administrator configures an IPsec VPN between two FortiGate devices. Phase 1 completes successfully, but Phase 2 fails to establish. The administrator runs 'diagnose vpn ike log' and sees the error 'proposal mismatch'. What is the MOST likely cause?

A.The IKE version is mismatched (IKEv1 vs IKEv2)

B.The pre-shared key is incorrect

C.The firewall policies are blocking IKE traffic on UDP port 500

D.The Phase 2 local and remote subnets do not match on both ends

AnswerD

During Phase 2, both peers exchange proxy IDs (traffic selectors) that define the exact local and remote subnets to be protected. For the IPsec SA to be established, the local selector on each peer must be the mirror image of the remote selector on the other peer. If the configured subnets differ on either side (for example, 192.168.1.0/24 versus 192.168.2.0/24), the IKE daemon rejects the proposal with a 'no proposal chosen' error, which is a Phase 2 proposal mismatch. While encryption or integrity algorithms can also cause a Phase 2 failure, mismatched subnet selectors are the most common issue in policy-based VPNs.

Why this answer

The error 'proposal mismatch' in the Phase 2 IKE log indicates that the IPsec security associations (SAs) proposed by one FortiGate do not match the configured Phase 2 parameters on the other. Since Phase 1 completed successfully, the IKE version and pre-shared key are already validated. The mismatch specifically refers to the local and remote subnet definitions, encryption algorithms, or authentication methods in the Phase 2 selectors.

Therefore, the most likely cause is that the Phase 2 local and remote subnets are not correctly mirrored on both ends.

Exam trap

The trap here is that candidates confuse Phase 1 and Phase 2 failures: because Phase 1 completed, they might incorrectly suspect pre-shared key or IKE version issues, but the 'proposal mismatch' error is specific to Phase 2 parameters like subnets or encryption settings.

How to eliminate wrong answers

Option A is wrong because an IKE version mismatch (IKEv1 vs IKEv2) would cause Phase 1 to fail, not Phase 2, and the error would typically be 'no proposal chosen' or 'version mismatch' during Phase 1 negotiation. Option B is wrong because an incorrect pre-shared key would prevent Phase 1 from completing, as it is used during IKE authentication (e.g., Main Mode or Aggressive Mode). Option C is wrong because firewall policies blocking UDP port 500 would prevent IKE packets from reaching the peer, causing Phase 1 to fail entirely, not just Phase 2.

Practice this question →

20

MCQmedium

You run 'diagnose debug application sslvpn -1' and see the following output: sslvpn: SSL VPN tunnel mode connection from 10.0.0.5:12345 to 192.168.1.100:443 sslvpn: User 'john' authenticated successfully sslvpn: Error: no matching policy for the request. What does this indicate?

A.There is no SSL VPN policy that allows the user to access the destination IP/port

B.The user's password has expired

C.The SSL VPN interface is administratively down

D.The FortiGate is not licensed for SSL VPN

AnswerA

The debug message 'no matching policy' occurs after a successful authentication exchange, indicating the FortiGate has already validated the user's credentials and is now performing a firewall policy lookup. For SSL VPN traffic to be permitted, a policy must exist on the SSL VPN interface (e.g., ssl.root) with the user's source, the destination IP/port, and the appropriate action. When none matches, the FortiGate drops the session and logs this exact error, even though the user is fully authenticated. Correctly diagnosing this requires checking `show firewall policy` for a rule that matches the tunnel traffic and the intended internal resource.

Why this answer

The error 'no matching policy for the request' indicates that the SSL VPN tunnel mode connection from user 'john' (source IP 10.0.0.5) to destination 192.168.1.100:443 did not match any SSL VPN policy configured on the FortiGate. SSL VPN policies define which users or user groups can access specific destination IP addresses and ports. Since authentication succeeded but no policy matched, the connection is denied at the policy layer, not due to authentication or interface issues.

Exam trap

The trap here is that candidates often confuse authentication success with authorization success, assuming that because the user authenticated, the connection should proceed, but SSL VPN policies are a separate authorization layer that must explicitly permit the destination.

How to eliminate wrong answers

Option B is wrong because the user 'john' authenticated successfully, as shown in the debug output, so an expired password would have caused an authentication failure, not a policy mismatch. Option C is wrong because if the SSL VPN interface were administratively down, the debug output would show a connection failure or interface error, not a successful authentication followed by a policy error. Option D is wrong because a licensing issue would typically prevent the SSL VPN service from starting or accepting connections entirely, not allow authentication and then fail on policy lookup.

Practice this question →

21

MCQhard

A FortiGate administrator is configuring ZTNA to secure access to an internal application. The administrator creates a ZTNA access proxy and a ZTNA rule. However, users connecting from the internet receive a 403 Forbidden error. The administrator verifies that the users are authenticated and the application is reachable. What is the MOST likely cause?

A.The firewall policy allowing traffic to the application is placed after a deny-all policy

B.The application's IP address is not included in the ZTNA access proxy's destination

C.The ZTNA access proxy does not have a valid SSL certificate

D.The ZTNA rule requires a specific client posture tag that the users' devices do not have

AnswerD

A 403 Forbidden from a ZTNA access proxy typically means the proxy accepted the connection but the ZTNA rule's enforcement conditions were not satisfied. Specifically, if the ZTNA rule requires a client posture tag (e.g., 'OS-Updated' or 'Compliant') and the user's FortiClient does not report that tag, the proxy denies access, returning 403. This is the core posture-check mechanism of ZTNA, distinguishing it from network-level firewall rules or proxy-layer connectivity failures.

Why this answer

The 403 Forbidden error in ZTNA typically indicates that the client device does not meet the required security posture. Even though users are authenticated and the application is reachable, the ZTNA rule enforces a specific client posture tag (e.g., antivirus enabled, OS patch level) via FortiClient telemetry. If the device lacks the required tag, FortiGate denies access with a 403, as the ZTNA access proxy validates both identity and device compliance before proxying traffic.

Exam trap

The trap here is that candidates often assume a 403 Forbidden is always due to firewall policy misconfiguration or authentication failure, but in ZTNA, it specifically indicates a posture compliance failure enforced by the ZTNA rule's tag requirement.

How to eliminate wrong answers

Option A is wrong because firewall policy order is irrelevant in ZTNA; the ZTNA access proxy intercepts traffic at the application layer before any firewall policy is evaluated, and a deny-all policy after the ZTNA rule would not cause a 403 from the proxy itself. Option B is wrong because the ZTNA access proxy's destination is the application's FQDN or IP, and if the IP were missing, the proxy would return a 502 Bad Gateway or connection timeout, not a 403 Forbidden. Option C is wrong because an invalid SSL certificate would cause a certificate warning or error in the browser (e.g., NET::ERR_CERT_AUTHORITY_INVALID), not a 403 Forbidden; the proxy would still attempt the connection but the client would reject it.

Practice this question →

22

Multi-Selecteasy

An organization wants to implement ZTNA (Zero Trust Network Access) on their FortiGate. Which TWO components are essential for ZTNA? (Select two.)

Select 2 answers

A.Client certificates for device posture verification

B.Identity Provider (IdP) for user authentication

C.A dedicated VPN tunnel

D.A static IP address for the client

E.A RADIUS server for two-factor authentication

AnswersA, B

In Fortinet ZTNA, client certificates serve as the primary mechanism for device posture verification. A certificate installed on an endpoint allows the FortiGate access proxy to verify that the device has been provisioned by the organization, is not compromised, and meets compliance requirements such as OS version, antivirus status, or patch level. This certificate-based device trust is crucial for zero trust because it ties the user's session to a validated, healthy endpoint, and it overrides any assumptions based on network location.

Why this answer

Client certificates are essential for ZTNA because they enable device posture verification, ensuring that only trusted and compliant devices can access protected resources. FortiGate uses client certificates to validate the device's identity and health status before granting access, which is a core principle of Zero Trust.

Exam trap

The trap here is that candidates often confuse ZTNA with traditional VPN solutions, mistakenly thinking a dedicated tunnel or static IP is required, when in fact ZTNA operates at the application layer without persistent network tunnels.

Practice this question →

23

MCQmedium

A FortiGate admin configures a remote user for SSL VPN tunnel mode. The user can connect but cannot access resources on the internal network. The admin checks the SSL VPN settings: tunnel mode enabled, split tunneling disabled. What is the issue?

A.The user's FortiClient is outdated

B.The SSL certificate is expired

C.The firewall policy from the SSL VPN interface to the internal network is missing or incorrectly configured

D.The user's client software is not configured to route all traffic through the tunnel

AnswerC

After the SSL VPN tunnel interface comes up, the FortiGate enforces its implicit-deny policy without a matching firewall rule; to reach internal servers, an explicit policy must exist with source set to the SSL VPN interface (e.g., ssl.vpn or ssl.root), destination set to the internal network, and appropriate services/action. A missing or misconfigured policy, such as using the wrong protocol, source address, or interface, silently drops the user's packets, which perfectly matches the symptom of a successful login but no access to internal resources.

Why this answer

When split tunneling is disabled, all traffic from the SSL VPN client is expected to be routed through the FortiGate. However, even with the tunnel established, the FortiGate must have a firewall policy that permits traffic from the SSL VPN interface (e.g., ssl.root) to the internal network interface, with the appropriate source (the user's assigned IP pool) and destination. Without this policy, packets are dropped by the FortiGate's implicit deny rule, preventing access to internal resources.

Exam trap

The trap here is that candidates assume a successful VPN connection automatically grants access to internal resources, overlooking the mandatory firewall policy that must explicitly permit traffic from the SSL VPN interface to the internal network.

How to eliminate wrong answers

Option A is wrong because an outdated FortiClient would typically cause connection failures or feature incompatibility, not a successful connection with no internal access. Option B is wrong because an expired SSL certificate would cause the SSL handshake to fail or generate a security warning, preventing the VPN tunnel from being established at all. Option D is wrong because when split tunneling is disabled on the FortiGate, the client is forced to route all traffic through the tunnel; the client's local routing configuration cannot override the server-side setting.

Practice this question →

24

MCQhard

An administrator is configuring ZTNA on a FortiGate. The goal is to allow access to an internal web server only if the client device has a specific security posture (e.g., antivirus running). Which ZTNA component is responsible for verifying the client's security posture?

A.ZTNA access proxy

B.IPsec VPN interface

C.SSL VPN portal

D.FortiClient EMS

AnswerD

FortiClient EMS is the component that collects endpoint posture, compliance, and security status from managed FortiClient endpoints and reports that information to FortiGate through the EMS connector. It assigns ZTNA tags based on real-time endpoint telemetry, which FortiGate access proxy policies use to make allow or deny decisions. This makes FortiClient EMS essential for posture-aware ZTNA, as the FortiGate cannot independently assess endpoint trust.

Why this answer

FortiClient EMS (Endpoint Management Server) is the ZTNA component that verifies the client's security posture by collecting endpoint telemetry (e.g., antivirus status, OS patch level) and enforcing compliance policies. The FortiGate queries FortiClient EMS via the FortiTelemetry protocol to determine if the client meets the required security posture before granting access. Without EMS, the FortiGate has no mechanism to assess endpoint health in a ZTNA flow.

Exam trap

The trap here is that candidates confuse the ZTNA access proxy (which enforces the policy) with the component that actually verifies the client's security posture, leading them to select Option A instead of recognizing that FortiClient EMS is the dedicated posture verification engine.

How to eliminate wrong answers

Option A is wrong because the ZTNA access proxy handles traffic forwarding and access control decisions based on tags from EMS, but it does not directly verify client security posture—it relies on EMS for that verification. Option B is wrong because an IPsec VPN interface is a site-to-site or remote-access tunnel that provides network-layer connectivity, not endpoint posture assessment; it has no integration with FortiClient EMS for security checks. Option C is wrong because the SSL VPN portal is a web-based interface for remote access that can enforce some client checks (e.g., host check), but it is not the ZTNA component responsible for posture verification; ZTNA uses EMS for dynamic posture-based access, not the legacy SSL VPN portal.

Practice this question →

25

MCQhard

A FortiGate administrator has configured a hub-and-spoke IPsec VPN. The hub FortiGate has two Phase 2 selectors with spokes, but traffic between spokes is not routed via the hub. What must be configured on the hub to allow spoke-to-spoke communication?

A.Set the hub as the default gateway on each spoke

B.Use policy-based VPN instead of route-based

C.Configure NAT on the hub

D.Enable 'add-route' on the hub Phase 2

AnswerD

Enabling 'add-route' on the hub's Phase 2 configuration is the correct solution because it instructs FortiGate to automatically install static routes for each spoke's protected subnet via the respective IPsec tunnel interface. With these routes in place, when the hub receives traffic from one spoke destined for another spoke, it can route the packets out the appropriate tunnel. This eliminates the need for manual static routes or a dynamic routing protocol and is the intended method for simple hub-and-spoke IPsec VPNs.

Why this answer

In a hub-and-spoke IPsec VPN, the hub FortiGate must have 'add-route' enabled on its Phase 2 selectors to automatically install routes for the spoke subnets into its routing table. Without this, the hub knows how to reach each spoke but does not have routes to forward traffic between spokes, so spoke-to-spoke traffic is dropped. Enabling 'add-route' on the hub's Phase 2 configurations ensures the hub learns the remote subnets and can route traffic between spokes.

Exam trap

The trap here is that candidates often assume spoke-to-spoke communication requires only Phase 2 selectors to be configured, but they overlook the need for the hub to have routes to both spoke subnets, which 'add-route' provides automatically.

How to eliminate wrong answers

Option A is wrong because setting the hub as the default gateway on each spoke only ensures spokes send their default traffic to the hub, but does not install the necessary routes on the hub to forward traffic between spoke subnets. Option B is wrong because policy-based VPN does not inherently solve the routing issue; it still requires proper routing or policies to forward inter-spoke traffic, and route-based VPN is actually more flexible for hub-and-spoke topologies. Option C is wrong because NAT on the hub would hide spoke addresses and break direct spoke-to-spoke communication, as the hub would need to translate and forward traffic, which is not the intended solution.

Practice this question →

26

MCQeasy

A network administrator wants to authenticate VPN users against an existing LDAP server. Which authentication method should be configured on the FortiGate?

A.FSSO

B.LDAP

C.RADIUS

D.Local

AnswerB

LDAP authentication is the correct choice because the FortiGate directly binds to the LDAP directory server using the user's distinguished name (DN) and supplied password. A successful bind indicates that the entered credentials are valid, and the FortiGate can also retrieve group memberships to apply access policies. This method validates the remote user against the central enterprise directory without storing passwords locally, making it ideal for a network that already relies on LDAP.

Why this answer

To authenticate VPN users against an existing LDAP server, the FortiGate must be configured to query the LDAP directory directly for user credentials. The LDAP authentication method (option B) allows the FortiGate to bind to the LDAP server using the user's DN and password, verifying identity against the directory. This is the correct choice because the question explicitly specifies an LDAP server, and FortiGate supports native LDAP authentication for SSL/IPsec VPNs without requiring an intermediate RADIUS or FSSO server.

Exam trap

The trap here is that candidates often confuse 'authentication source' with 'authentication method' and select RADIUS (option C) because they assume LDAP must be proxied through RADIUS, but FortiGate can authenticate directly against LDAP for VPN users without any intermediary.

How to eliminate wrong answers

Option A (FSSO) is wrong because FSSO (Fortinet Single Sign-On) is designed for transparent authentication of users on a Windows domain by polling domain controllers for login events, not for direct authentication of VPN users against an LDAP server; it requires a domain controller and does not perform credential validation against LDAP. Option C (RADIUS) is wrong because while RADIUS can proxy authentication to an LDAP server, it introduces an unnecessary intermediary and is not the direct LDAP authentication method the question asks for; the FortiGate can authenticate directly against LDAP without RADIUS. Option D (Local) is wrong because local authentication uses user accounts stored in the FortiGate's local database, not against an external LDAP server, and would require manual duplication of all LDAP users.

Practice this question →

27

MCQeasy

A FortiGate administrator needs to authenticate VPN users against an LDAP server. What is the primary purpose of the 'CN=,OU=,DC=' distinguished name (DN) configured in the LDAP server settings?

A.It is used to encrypt LDAP communication

B.It defines the IP address of the LDAP server

C.It specifies the base DN for searching users

D.It specifies the bind user credentials to connect to the LDAP server

AnswerD

The DN and the associated password serve as the bind user credentials. When the FortiGate connects to the LDAP server, it performs a bind operation using this DN and password to authenticate itself before it can search for VPN users. This account must have read privileges over the user subtree to enable successful authentication and group lookups.

Why this answer

The DN configured in the LDAP server settings on FortiGate specifies the bind user credentials (username and password) that the FortiGate uses to authenticate itself to the LDAP server before performing user searches. This bind DN is required because LDAP servers typically require a valid authenticated session to query the directory; the bind DN provides the necessary identity and privileges for the FortiGate to search for VPN users.

Exam trap

The trap here is that candidates confuse the bind DN (used for authenticating the FortiGate to the LDAP server) with the base DN (used for searching user objects), leading them to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because LDAP encryption is configured separately via the 'Secure Connection' option (LDAPS or StartTLS), not by the DN field. Option B is wrong because the IP address of the LDAP server is configured in the 'Server IP/Name' field, not in the DN field. Option C is wrong because the base DN for searching users is configured in the 'Common Name Identifier' and 'Distinguished Name' fields under the user group or LDAP server's 'Member' settings, not in the bind DN field.

Practice this question →

28

MCQmedium

An administrator is configuring a site-to-site IPsec VPN between two FortiGates. After applying the configuration, the VPN status shows 'down'. Phase 1 parameters are identical on both sides. What is the most likely cause of the failure?

A.The Phase 2 selectors (local and remote subnets) are mismatched.

B.The pre-shared keys do not match.

C.The firewall policies are not configured.

D.NAT traversal is disabled but both FortiGates are behind NAT.

AnswerA

Phase 2 selectors define which traffic is encrypted; mismatched local and remote subnet pairs cause the quick mode negotiation to fail even when Phase 1 succeeds, leaving the tunnel down. Identical Phase 1 parameters rule out authentication or encryption mismatches.

Why this answer

When Phase 1 parameters are identical and the VPN is down, the most common cause is a mismatch in Phase 2 selectors (local and remote subnets). Phase 2 uses these selectors to negotiate the IPsec security associations (SAs); if they do not match exactly on both sides, the IKEv1/v2 Quick Mode or Child SA exchange will fail, leaving the tunnel in a 'down' state even though Phase 1 (IKE SA) may be up.

Exam trap

The trap here is that candidates often assume a Phase 1 mismatch (like pre-shared keys) is the cause when the VPN is down, but the question explicitly states Phase 1 parameters are identical, forcing the focus to Phase 2 selector mismatches, which is a classic NSE4 exam trick.

How to eliminate wrong answers

Option B is wrong because if the pre-shared keys did not match, Phase 1 authentication would fail, and the VPN status would show 'down' with a Phase 1 error, but the question states Phase 1 parameters are identical, implying the pre-shared keys match. Option C is wrong because firewall policies are required to permit traffic through the tunnel, but their absence does not cause the VPN tunnel itself to be 'down'; the tunnel can be up even without policies, but traffic will not pass. Option D is wrong because NAT traversal (NAT-T) being disabled while both FortiGates are behind NAT would cause Phase 1 to fail due to encapsulation issues, but the question states Phase 1 parameters are identical and does not indicate a Phase 1 failure; NAT-T mismatch typically manifests in Phase 1, not Phase 2.

Practice this question →

29

MCQeasy

A remote user reports that they can connect to the FortiGate SSL VPN portal but cannot access internal resources. The administrator checks the SSL VPN settings and sees that the tunnel mode is enabled with split tunneling. What is the most likely cause?

A.The IP pool is exhausted and no IP address was assigned.

B.The firewall policy allowing SSL VPN traffic to internal resources is missing.

C.The routing table on the client is missing the internal network routes.

D.The SSL VPN authentication timeout is too short.

AnswerC

This is the correct explanation. With split tunneling enabled, the FortiGate sends a list of internal subnets to the client, which must be installed into the client's routing table. If those routes are missing or incomplete, traffic destined for internal resources will be sent out the physical interface to the local gateway instead of into the SSL VPN tunnel, causing the connection to the FortiGate to succeed while internal resources remain unreachable. The user's report confirms the tunnel is up, so the next most logical place to look is the client-side routing table.

Why this answer

With split tunneling enabled, the FortiGate SSL VPN portal connection succeeds, but the client's routing table does not automatically include routes for the internal network. Without those routes, traffic to internal resources is sent to the default gateway instead of through the VPN tunnel, causing access failure. This is the most likely cause because the user can authenticate and establish the tunnel but cannot reach internal subnets.

Exam trap

The trap here is that candidates assume split tunneling automatically includes all internal routes, but in FortiGate SSL VPN, split tunneling requires explicit route configuration to direct internal traffic through the tunnel.

How to eliminate wrong answers

Option A is wrong because an exhausted IP pool would prevent the tunnel from establishing entirely, not just block resource access while the portal connects. Option B is wrong because a missing firewall policy would block all SSL VPN traffic, including portal access, not just internal resource access. Option D is wrong because an authentication timeout would cause disconnection or reauthentication prompts, not a persistent inability to access internal resources while remaining connected.

Practice this question →

30

MCQhard

A network administrator is configuring a site-to-site IPsec VPN between two FortiGates. Phase 1 and Phase 2 are both up, but traffic is not passing through the tunnel. The administrator runs 'diagnose debug flow' and sees that packets are being dropped with the message 'iprope_in_check() check failed, drop'. Which configuration change is most likely to resolve this issue?

A.Add a firewall policy that allows traffic from the local subnet to the remote subnet through the IPsec tunnel.

B.Modify the Phase 2 selector to match the remote subnet.

C.Configure a static route for the remote subnet pointing to the IPsec tunnel interface.

D.Enable 'auto-negotiate' in Phase 2 settings to allow dynamic routing.

AnswerA

The 'iprope_in_check() check failed' error indicates that the FortiGate is dropping packets due to a missing or misconfigured firewall policy. For traffic to pass through the IPsec tunnel, a firewall policy must explicitly allow traffic from the local subnet to the remote subnet, with the correct incoming and outgoing interfaces. Without this policy, the FortiGate drops the packets.

Why this answer

The error 'iprope_in_check() check failed, drop' is generated by the FortiGate when a packet is denied by a firewall policy. For IPsec VPN traffic to pass, a firewall policy must allow traffic from the local subnet to the remote subnet, with the correct source and destination interfaces. Even if Phase 1 and Phase 2 are up, without this policy, the FortiGate will drop the packets.

The administrator should verify that the policy exists and is correctly ordered.

Exam trap

The trap here is focusing on Phase 2 or routing when the error clearly indicates a firewall policy drop, so the missing policy is the actual cause.

Practice this question →

31

MCQeasy

Which authentication method allows a FortiGate to transparently authenticate users based on their Active Directory login events without prompting for credentials?

A.RADIUS authentication

B.FSSO (Fortinet Single Sign-On)

C.Local database authentication

D.LDAP authentication

AnswerB

FSSO (Fortinet Single Sign-On) is the correct method because it actively monitors a domain controller for user logon events, either via a Collector Agent or by polling the Windows Security Log. When a user logs into the Windows domain, FSSO fetches the username and the workstation IP/MAC and sends this information to the FortiGate, which then automatically maps the user to the web filter, firewall policy, or application control profiles. The user is never prompted for authentication because the AD authentication is captured transparently, making FSSO the only listed option that meets the requirement.

Why this answer

Fortinet Single Sign-On (FSSO) allows FortiGate to transparently authenticate users by collecting login events from Active Directory domain controllers. It uses the NetAPI or a polling mechanism to capture user logon events without requiring any user interaction or credential prompts, enabling seamless identity-based policy enforcement.

Exam trap

The trap here is that candidates often confuse LDAP or RADIUS with SSO capabilities, but neither provides transparent authentication without credential prompts—only FSSO captures existing Windows logon events to achieve true single sign-on.

How to eliminate wrong answers

Option A is wrong because RADIUS authentication requires users to actively enter credentials (username/password) when prompted by the FortiGate, and it does not passively capture existing AD login events. Option C is wrong because local database authentication stores user credentials locally on the FortiGate and always prompts for manual login, lacking any single sign-on capability. Option D is wrong because LDAP authentication performs a direct bind to the LDAP server (e.g., Active Directory) using user-supplied credentials, which still requires a prompt and does not leverage pre-existing Windows logon events.

Practice this question →

32

Multi-Selecthard

A FortiGate administrator is troubleshooting an IPsec VPN that is dropping traffic intermittently. The administrator runs 'diagnose vpn ike log' and sees many 'DPD' messages. Which THREE conditions could cause frequent DPD (Dead Peer Detection) retransmissions? (Choose three.)

Select 3 answers

A.High network latency causing DPD timeouts

B.The remote peer is rebooting or unstable

C.Mismatched IKE version

D.Incorrect Phase 2 proxy IDs

E.A firewall between the peers dropping UDP port 500 packets

AnswersA, B, E

High network latency can exceed the DPD dead-peer detection timeout. When FortiGate sends R-U-THERE messages to the peer, it expects an ACK within a configured interval (often multiple retries with a given timeout). On WAN links with significant latency or jitter, that round-trip time can exceed the threshold, causing FortiGate to declare the peer dead and take down the VPN tunnel even though the remote peer is actually operational. This is a common cause of intermittent tunnel flaps on satellite or transcontinental links.

Why this answer

High network latency can cause DPD packets to exceed the configured timeout interval, triggering retransmissions. DPD relies on timely responses; if the round-trip time (RTT) consistently exceeds the DPD retry interval, the FortiGate will send repeated DPD messages, leading to intermittent traffic drops as the tunnel may be torn down.

Exam trap

The trap here is that candidates often confuse DPD retransmissions with Phase 2 misconfigurations, but DPD operates at Phase 1 and is unrelated to proxy IDs or IKE version mismatches, which prevent tunnel establishment entirely.

Practice this question →

33

MCQhard

An administrator runs 'diagnose debug application ike -1' and sees the following output: ike 0:come to x.x.x.x:500, IKEv1, cookie 123456789abcdef0 ike 0:incoming IKE packet: src y.y.y.y:500, dst x.x.x.x:500, len 456 ike 0:send IKE packet: src x.x.x.x:500, dst y.y.y.y:500, len 456 ike 0:phase 1 negotiation failed due to time out. What is the likely cause?

A.The remote FortiGate's Phase 1 proposal does not match

B.A firewall rule is blocking UDP 500/4500 between the peers

C.The pre-shared key is incorrect

D.The local FortiGate's external interface is down

AnswerB

IKEv1 Phase 1 uses UDP port 500 for normal negotiation, and UDP port 4500 for NAT traversal and ESP-in-UDP encapsulation. If a firewall silently blocks these UDP ports, the outgoing IKE packets are dropped without any ICMP or TCP RST, so the initiator never receives a response. The FortiGate will retransmit the IKE SA proposal multiple times and, after exhausting retries, log a timeout with a 'negotiate' error. This matches the debug output showing packets sent but no reply, making a firewall rule blocking UDP 500/4500 the most likely cause of the timeout.

Why this answer

The output shows that the IKE packet is being sent and received (no proposal mismatch or interface down), but the negotiation fails due to a timeout. This indicates that the packet is leaving the local FortiGate but the response is not arriving back, which is classic behavior when a firewall (or ACL) between the peers is blocking UDP 500 or 4500. The timeout occurs because the remote peer never receives the initial packet or the local peer never receives the reply, preventing any IKE exchange from completing.

Exam trap

The trap here is that candidates see 'phase 1 negotiation failed due to time out' and incorrectly assume a configuration mismatch (like proposals or PSK), but the debug output clearly shows packets being sent and received locally, pointing to a network-level blockage rather than a VPN parameter mismatch.

How to eliminate wrong answers

Option A is wrong because a Phase 1 proposal mismatch would typically result in an immediate 'no proposal chosen' or 'attribute mismatch' error in the debug output, not a timeout after sending and receiving packets. Option C is wrong because an incorrect pre-shared key would cause a Phase 1 authentication failure (e.g., 'invalid cookie' or 'mismatch') after the proposal is accepted, not a timeout before any cryptographic exchange completes. Option D is wrong because if the local FortiGate's external interface were down, the 'send IKE packet' line would not appear, and the debug would show a local routing or interface error, not a timeout waiting for a response.

Practice this question →

34

MCQhard

A FortiGate in a hub-and-spoke VPN topology is configured with a single IPsec tunnel to each spoke. The hub has a route-based VPN with a tunnel interface for each spoke. After a reboot, traffic between spoke A and spoke B fails, although each spoke can reach the hub. What is the likely cause?

A.The hub is missing static routes to the spoke networks via the respective tunnel interfaces

B.The firewall policies on the hub do not allow traffic between the spoke networks

C.The spokes have mismatched IKE versions

D.The hub's IPsec Phase1 is not configured for DPD

AnswerA

In route-based IPsec VPNs, the hub must have a static route for each spoke's protected network, pointing to the corresponding tunnel interface. Without these routes, the hub cannot determine the correct egress tunnel for inter-spoke packets, so even though the IPsec tunnels are established and firewall policies permit the traffic, the packets are dropped or never forwarded. After a reboot, these static routes are critical because they are not dynamically learned unless a routing protocol is running over the tunnel.

Why this answer

In a hub-and-spoke route-based VPN, the hub uses tunnel interfaces for each spoke. After a reboot, the hub's routing table is cleared, and without static routes pointing to the spoke networks via the respective tunnel interfaces, the hub cannot forward traffic between spokes. Even though each spoke can reach the hub, inter-spoke traffic requires the hub to have explicit routes to the remote spoke networks, as dynamic routing protocols are not mentioned in this scenario.

Exam trap

The trap here is that candidates often assume firewall policies are the only control for inter-spoke traffic, overlooking that route-based VPNs require explicit routing entries on the hub to forward traffic between spokes.

How to eliminate wrong answers

Option B is wrong because firewall policies on the hub control whether traffic is allowed, but the question states traffic fails after a reboot, and each spoke can reach the hub, indicating the issue is routing, not policy. Option C is wrong because mismatched IKE versions would prevent the IPsec tunnels from establishing at all, yet each spoke can reach the hub, proving the tunnels are up. Option D is wrong because DPD (Dead Peer Detection) is used to detect tunnel failures, not to cause inter-spoke routing failures after a reboot; DPD misconfiguration would not prevent the hub from forwarding traffic between spokes.

Practice this question →

35

Multi-Selectmedium

An organization uses LDAP authentication for firewall policies. Users complain that they are frequently prompted for credentials. Which TWO settings can reduce the frequency of authentication prompts?

Select 2 answers

A.Increase the authentication timeout on the firewall policy.

B.Increase the idle timeout on the LDAP server.

C.Enable single sign-on (SSO) authentication method.

D.Disable captive portal on the interface.

E.Use a longer password for LDAP accounts.

AnswersA, C

Increasing the authentication timeout on the firewall policy extends how long an LDAP-authenticated user's session remains valid before the FortiGate forces a re-authentication. After successful LDAP validation, the firewall caches the user's access rights for the duration of this timeout; once it expires, the user must re-enter credentials for that policy. A longer timeout reduces the frequency of prompts, but it also widens the security window in which a session could be hijacked or reused by an unauthorized user on a shared machine. This is the direct, policy-level control that governs prompt frequency.

Why this answer

Increasing the authentication timeout on the firewall policy (Option A) allows the firewall to cache the user's authentication state for a longer period, so users are not re-prompted for credentials as frequently when traffic matches that policy. Enabling single sign-on (SSO) authentication (Option C) leverages Kerberos or NTLM to automatically authenticate users based on their domain logon, eliminating repeated manual credential prompts.

Exam trap

The trap here is that candidates confuse the LDAP server's idle timeout (a connection keepalive) with the firewall's authentication timeout (a cached credential timer), leading them to incorrectly select Option B.

Practice this question →

36

MCQeasy

An administrator wants to allow remote users to access internal resources using a web browser without installing any client software. Which VPN type should be configured on the FortiGate?

A.ZTNA access proxy

B.IPsec VPN with dial-up mode

C.SSL VPN tunnel mode

D.SSL VPN web mode

AnswerD

SSL VPN web mode provides agentless, browser-based access to internal web applications through a reverse-proxy portal. The user only needs a supported web browser and credentials, then receives a resource-list portal to reach specific HTTP/HTTPS URLs. This matches the requirement of allowing remote users to access internal web resources without installing any software or VPN client.

Why this answer

SSL VPN web mode (option D) is correct because it provides clientless remote access to internal resources via a web browser, requiring no software installation. The FortiGate acts as a reverse proxy, translating HTTPS requests from the user's browser to internal HTTP/HTTPS servers, which matches the requirement for browser-only access without client software.

Exam trap

The trap here is confusing SSL VPN web mode (clientless) with SSL VPN tunnel mode (client-required), as both use SSL/TLS but differ fundamentally in whether a software client is needed for full network-layer access.

How to eliminate wrong answers

Option A is wrong because ZTNA access proxy is a zero-trust solution that typically requires a FortiClient or endpoint agent for identity verification and device posture checks, not a clientless browser-only approach. Option B is wrong because IPsec VPN with dial-up mode requires a dedicated VPN client (e.g., FortiClient or third-party IPsec software) to establish the tunnel, which violates the 'no client software' requirement. Option C is wrong because SSL VPN tunnel mode requires the FortiClient SSL VPN plugin or a full VPN client to create a virtual adapter and route traffic, whereas the question specifies web browser access without installation.

Practice this question →

37

Multi-Selecthard

A FortiGate administrator is troubleshooting an IPsec VPN that fails to establish. The Phase 1 status shows 'init' and then resets. The administrator runs 'diagnose debug application ike -1' and sees the message 'no acceptable proposal'. Which TWO parameters are MOST likely mismatched?

Select 2 answers

A.Pre-shared key

B.Phase 2 local and remote networks

C.IKE version (IKEv1 vs IKEv2)

D.Encryption algorithm (e.g., AES256 vs AES128)

E.Diffie-Hellman group (e.g., group 14 vs group 2)

AnswersD, E

'No acceptable proposal' means Phase 1 negotiation found no matching transform set. Mismatched encryption algorithms, such as AES256 on one peer and AES128 on the other, prevent any proposal from being accepted, so the tunnel resets.

Why this answer

The IKE debug message 'no acceptable proposal' means the two peers could not agree on the Phase 1 (IKE SA) proposal parameters, which are negotiated during IKE SA establishment. Option D (encryption algorithm, e.g., AES256 vs AES128) is correct because the encryption algorithm is a Phase 1 proposal attribute, and if the local and remote FortiGates offer different encryption algorithms, no matching proposal exists and negotiation fails. Option E (Diffie-Hellman group, e.g., group 14 vs group 2) is also correct because the DH group is another Phase 1 proposal attribute; mismatched DH groups (modp2048/group 14 vs modp1024/group 2) prevent the peers from agreeing on a proposal.

Option A (pre-shared key) is not the cause here because a PSK mismatch produces authentication failure messages (e.g., 'probable pre-shared key mismatch'), not 'no acceptable proposal'. Option B (Phase 2 local and remote networks) is a Phase 2 quick-mode/selector issue and would not generate a Phase 1 proposal rejection. Option C (IKE version) can cause negotiation problems, but a version mismatch typically shows different errors such as 'received IKEv2 packet on IKEv1 tunnel' or invalid version messages rather than the specific 'no acceptable proposal' text.

Exam trap

The trap here is that candidates often confuse Phase 1 proposal mismatches (encryption, DH group) with authentication failures (pre-shared key) or Phase 2 mismatches (networks), but the 'no acceptable proposal' error specifically points to cryptographic parameter negotiation failure in Phase 1.

Practice this question →

38

MCQmedium

A FortiGate admin configures a captive portal for guest users on a wireless network. Users can connect to the SSID but cannot access the internet. The admin verifies the firewall policy permits traffic from the captive portal interface to the internet. What is missing?

A.The firewall policy must have 'Enable Captive Portal' selected

B.A DNS server must be configured on the FortiGate

C.The users must be added to the local user database

D.The wireless controller must be configured with a RADIUS server

AnswerA

The captive portal is a firewall-policy-level feature: on the FortiGate, you must enable 'Captive Portal' on the specific policy controlling the guest traffic (CLI: set captive-portal enable). This instructs the FortiGate to intercept HTTP/HTTPS sessions from unauthenticated clients and redirect them to the portal login page. Without this enablement, the portal page is never presented, and the guest traffic is simply blocked or forwarded according to the policy's normal settings.

Why this answer

For a captive portal to redirect unauthenticated users to the authentication page, the firewall policy that permits traffic from the captive portal interface to the internet must have the 'Enable Captive Portal' option selected. Without this setting, the FortiGate will not intercept HTTP/HTTPS requests and redirect them to the captive portal login page, so users remain unauthenticated and cannot access the internet even though the policy allows traffic.

Exam trap

The trap here is that candidates assume captive portal is automatically enabled when a firewall policy allows traffic from the captive portal interface, but in FortiGate, the 'Enable Captive Portal' checkbox must be explicitly set on the policy to trigger the authentication redirect.

How to eliminate wrong answers

Option B is wrong because a DNS server is not required for captive portal functionality; the FortiGate can use its own DNS proxy or forward queries, and DNS resolution is separate from the captive portal redirection process. Option C is wrong because captive portal for guest users typically uses authentication via a local user database or external authentication, but the question states users can connect to the SSID but cannot access the internet, indicating the issue is the missing captive portal enforcement on the firewall policy, not the absence of user accounts. Option D is wrong because a RADIUS server is not mandatory for a captive portal; the FortiGate can authenticate users locally or via other methods, and the wireless controller configuration is unrelated to the firewall policy setting that enables captive portal redirection.

Practice this question →

39

MCQhard

An administrator configures a dial-up IPsec VPN using IKEv2 with certificates. Remote users can connect, but traffic is not routed through the tunnel. The Phase 1 status shows 'up', but Phase 2 shows 'down'. What is the most likely issue?

A.The firewall policy for the VPN traffic is missing.

B.The Phase 2 proposals do not match between the FortiGate and the client.

C.The pre-shared key for Phase 2 is incorrect.

D.The remote user's client does not support IKEv2.

AnswerB

In IKEv2, the CREATE_CHILD_SA exchange negotiates the IPsec SA parameters, including encryption, integrity, and DH group. If the FortiGate's configured Phase 2 proposal set does not include at least one transform that exactly matches what the client proposes, the negotiation fails and no Phase 2 SA is established. The Phase 1 IKE SA may still be up, but the tunnel remains down because the two peers cannot agree on a common traffic protection algorithm suite. This is the most direct cause of a failed Phase 2 while Phase 1 is successful.

Why this answer

In IKEv2 VPNs, Phase 1 establishes the secure control channel (ISAKMP SA) and shows 'up' even if Phase 2 fails. Phase 2 creates the IPsec SA for actual data traffic; if it remains 'down', the most common cause is a mismatch in Phase 2 proposals (encryption, authentication, or PFS settings) between the FortiGate and the remote client. Since the client can connect but traffic is not routed, the tunnel is not fully established for data, pointing directly to a Phase 2 proposal mismatch.

Exam trap

The trap here is that candidates assume a successful Phase 1 means the entire VPN is working, but NSE4 tests the understanding that Phase 2 must also be up for traffic to flow, and proposal mismatches are the primary cause of Phase 2 failures.

How to eliminate wrong answers

Option A is wrong because a missing firewall policy would block traffic even if both Phase 1 and Phase 2 were up, but here Phase 2 is down, indicating the issue is at the SA negotiation level, not policy. Option C is wrong because IKEv2 with certificates does not use a pre-shared key for Phase 2; Phase 2 authentication is derived from the IKE SA established in Phase 1, and certificates handle authentication. Option D is wrong because the remote users can connect (Phase 1 is up), so the client does support IKEv2; the problem is specifically with Phase 2 negotiation.

Practice this question →

40

Multi-Selectmedium

A FortiGate admin wants to implement ZTNA to secure access to an internal application. Which TWO components are required for a basic ZTNA configuration?

Select 2 answers

A.A FortiClient EMS server

B.An IPsec VPN tunnel to the client

C.A ZTNA rule (policy) that specifies access conditions

D.A ZTNA application gateway

E.A static route to the application server

AnswersC, D

The ZTNA rule defines the access conditions — source, user or device posture, and protected application — that the FortiGate evaluates before granting access. Without this policy, no enforcement decision occurs, so it is essential alongside the application gateway.

Why this answer

Option C is correct because a ZTNA rule (policy) is the enforcement point on the FortiGate that defines the access conditions—such as user/device identity, posture tags, and application—that must be met before traffic is allowed to the protected resource. Option D is correct because the ZTNA application gateway (configured as a ZTNA server with a virtual host, real server, and access proxy) is the component that publishes the internal application and brokers the client connection through the FortiGate. Options A, B, and E are not required for a basic ZTNA configuration: FortiClient EMS is only needed for advanced posture/tag-based checks, an IPsec VPN tunnel is a separate remote-access method rather than a ZTNA requirement, and a static route is ordinary routing that does not constitute a ZTNA component.

Exam trap

The trap here is that candidates often confuse ZTNA with traditional VPN solutions and incorrectly assume that an IPsec tunnel or a static route is required, when in fact ZTNA relies on application-layer gateways and policy rules without a full network tunnel.

Practice this question →

41

MCQmedium

A FortiGate is configured as an SSL VPN server with tunnel mode. Remote users authenticate successfully, but after connecting they cannot reach any internal subnet. The administrator verifies that the SSL VPN firewall policy allows the tunnel interface and that the internal routes exist. Which SSL VPN configuration setting must be checked next to ensure that the correct routes are pushed to the clients?

A.Configure the 'Routing Address' in the SSL VPN portal to include the internal subnets.

B.Enable 'client-certificate' authentication in the SSL VPN settings.

C.Set the SSL VPN to use 'web mode' instead of 'tunnel mode'.

D.Enable 'split-tunneling' in the SSL VPN portal settings.

AnswerA

In tunnel mode, the SSL VPN portal's 'Routing Address' setting defines the destination subnets that are pushed to the client and routed through the tunnel. If it is empty or incorrect, clients will not have routes for internal networks, causing the described failure. This setting is the primary method to control which subnets are reachable over the SSL VPN tunnel.

Why this answer

In SSL VPN tunnel mode, the FortiGate pushes routes to the client based on the 'Routing Address' defined in the SSL VPN portal. If this setting is empty or does not include the internal subnets, the client will not have routes for those networks, even though the tunnel is up and the firewall policy permits traffic. Verifying and correcting the Routing Address is the direct solution.

Exam trap

The trap here is assuming that enabling split tunneling automatically defines which subnets are routed through the tunnel, when in fact the Routing Address setting must be populated.

Practice this question →

42

MCQmedium

An administrator configures an LDAP user group for firewall authentication. Users are able to authenticate, but the FortiGate does not retrieve group membership information. What is likely misconfigured?

A.The LDAP server's IP address is incorrect

B.SSL is not enabled for LDAP

C.The LDAP bind account does not have permission to read group attributes

D.The FortiGate is not joined to the domain

AnswerC

When the FortiGate authenticates a user via LDAP, it also performs a directory search to resolve that user's group memberships, using the credentials of the configured bind account. If the bind account has permission to read the user object but lacks read access to the group objects or their membership attributes (e.g., memberOf, uniqueMember, member), the LDAP search returns an empty or partial result. Because the FortiGate builds its firewall user groups from these returned attributes, insufficient read privileges on group data directly cause the correct behavior that the administrator is seeing: authentication succeeds, but no matching LDAP group is found.

Why this answer

The LDAP bind account must have sufficient permissions to read the memberOf or group membership attributes from the directory. If the bind account can authenticate users but cannot query group membership, the FortiGate will not be able to enforce policies based on LDAP groups. This is the most common cause when authentication succeeds but group information is missing.

Exam trap

The trap here is that candidates assume authentication success means all LDAP functions work, but Fortinet specifically tests the distinction between authentication (bind) and attribute retrieval (search), which require different permissions.

How to eliminate wrong answers

Option A is wrong because if the LDAP server's IP address were incorrect, users would not be able to authenticate at all. Option B is wrong because SSL is not required for LDAP group membership retrieval; LDAP over TCP (port 389) works fine for reading attributes, and SSL/TLS only adds encryption. Option D is wrong because the FortiGate does not need to be joined to the domain; it acts as an LDAP client and only needs to communicate with the LDAP server using the configured bind credentials.

Practice this question →

43

MCQmedium

A FortiGate is configured as a hub in a hub-and-spoke IPsec VPN. The spokes are remote branches. The hub has a Phase 2 selector set to 0.0.0.0/0 for both local and remote subnets. What is the advantage of this configuration?

A.It reduces the number of IPsec SAs needed

B.It simplifies configuration by not needing specific subnet definitions per spoke

C.It allows direct spoke-to-spoke communication without passing through the hub

D.It enables dynamic routing protocols over the VPN

AnswerB

This is correct. Configuring the Phase 2 selector as 0.0.0.0/0 on the hub means the hub will accept any source and destination subnet from the spoke during Phase 2 negotiation, so there is no need to define each spoke's LAN subnets explicitly. When a spoke adds, removes, or changes a protected subnet behind it, the hub's Phase 2 configuration remains valid and no reconfiguration is required. This greatly simplifies hub management in a dynamic environment where spoke subnets are not stable or are unknown in advance.

Why this answer

Using 0.0.0.0/0 as the Phase 2 selector on the hub allows the hub to accept any remote subnet from any spoke without defining each spoke's specific subnet in the Phase 2 configuration. This dramatically simplifies hub configuration in a hub-and-spoke topology because new spokes can be added without modifying the hub's Phase 2 selectors.

Exam trap

NSE4 often tests the misconception that a 0.0.0.0/0 Phase 2 selector enables spoke-to-spoke direct communication or dynamic routing, when it actually only simplifies hub configuration.

How to eliminate wrong answers

Option A is wrong because the number of IPsec SAs is determined by the number of Phase 2 selectors and tunnels, not by using 0.0.0.0/0 — in fact, a wildcard selector can create more SAs, not fewer. Option C is wrong because spoke-to-spoke communication still traverses the hub unless the hub is configured to forward traffic between spokes; the wildcard selector does not enable direct spoke-to-spoke tunnels. Option D is wrong because dynamic routing protocols (like OSPF or BGP over IPsec) require separate configuration such as GRE or VTI interfaces; the Phase 2 selector alone does not enable dynamic routing.

Practice this question →

44

MCQeasy

What is the purpose of a 'realm' in FortiGate SSL VPN configuration?

A.To enable two-factor authentication.

B.To specify the authentication server for the VPN.

C.To create distinct portals with separate authentication and access policies.

D.To define the encryption algorithm for SSL VPN.

AnswerC

A realm in FortiGate SSL-VPN creates a separate URL-based virtual portal, each with its own authentication realm, user group mappings, portal preferences, and access privileges. This allows an administrator to present a tailored VPN login and resource set to different user groups without deploying extra FortiGate units. For example, /remote/employees and /remote/partners can be distinct realms sharing the same physical interface but enforcing independent security policies.

Why this answer

In FortiGate SSL VPN, a 'realm' allows the administrator to create distinct login portals, each with its own authentication requirements and access policies. This enables different user groups (e.g., employees vs. contractors) to have separate VPN experiences without requiring multiple FortiGate interfaces or IP pools. The realm is appended to the VPN URL (e.g., https://fortigate:10443/remote/portal) to direct users to the correct portal.

Exam trap

The trap here is confusing 'realm' with 'authentication server' or 'encryption settings', as candidates often assume a realm is tied to a specific backend authentication source rather than being a portal-level abstraction for access control.

How to eliminate wrong answers

Option A is wrong because two-factor authentication is configured via authentication policies or security realms, not by the realm itself; realms can enforce different authentication methods, but they do not inherently enable two-factor auth. Option B is wrong because the authentication server (e.g., LDAP, RADIUS) is specified in the user group or authentication rule, not in the realm definition; a realm references a portal, not an authentication source. Option D is wrong because encryption algorithms (e.g., AES, 3DES) are defined in the SSL VPN settings or the firewall policy, not in the realm configuration.

Practice this question →

45

MCQeasy

What is the primary purpose of configuring split tunneling on an SSL VPN?

A.To provide two-factor authentication for the VPN connection

B.To encrypt all traffic from the remote client, including Internet traffic

C.To enable the use of client certificates for authentication

D.To allow the remote client to access both the corporate network and the Internet simultaneously without routing all traffic through the VPN

AnswerD

Split tunneling is a VPN configuration that routes only traffic destined for the corporate network (e.g., private subnets or specific IP ranges) through the encrypted tunnel, while all other Internet-bound traffic exits directly from the client's local interface. This allows the remote user to simultaneously access corporate resources and general Internet services without forcing every packet through the VPN gateway, which reduces bandwidth consumption, lowers latency for unrelated web browsing, and prevents the VPN concentrator from becoming a bottleneck. The FortiGate implements this by adding specific routes for corporate CIDRs to be sent over the tunnel interface, leaving the default route on the physical adapter for direct Internet access.

Why this answer

Split tunneling on an SSL VPN allows the remote client to have simultaneous access to the corporate network (via the encrypted VPN tunnel) and the public Internet (directly, without going through the VPN). This reduces bandwidth load on the VPN gateway and improves user experience by not routing non-corporate traffic through the encrypted tunnel. Option D correctly describes this behavior.

Exam trap

The trap here is that candidates often confuse split tunneling with full tunneling, mistakenly thinking split tunneling encrypts all traffic, when in fact it selectively routes only corporate traffic through the VPN.

How to eliminate wrong answers

Option A is wrong because two-factor authentication is a separate security feature, not a function of split tunneling; it is typically implemented via mechanisms like FortiToken or RADIUS. Option B is wrong because encrypting all traffic (including Internet traffic) is the purpose of full tunnel mode, the opposite of split tunneling. Option C is wrong because client certificate authentication is a method of verifying user identity, unrelated to how traffic is routed or split between corporate and Internet destinations.

Practice this question →

46

MCQeasy

What is the purpose of a ZTNA (Zero Trust Network Access) tag on a FortiGate?

A.To enable SNMP monitoring on the device

B.To assign static IP addresses to clients

C.To mark devices or users with attributes used in security policies

D.To tag firewall policies for logging purposes

AnswerC

This is the core function of ZTNA tags in FortiGate. Administrators create tags that mark users/devices with attributes such as device posture (e.g., OS patch level, antivirus status), user group membership, location, or other endpoint intelligence. Security policies then reference these tags to enforce granular, context-aware access decisions, enabling zero-trust principles where trust is based on verified attributes rather than network location.

Why this answer

ZTNA tags are user- or device-specific attributes (e.g., 'OS=Windows', 'Compliant=true') that FortiGate applies to endpoints after posture assessment. These tags can then be referenced in firewall policies to enforce granular, identity-aware access control, which is the core of Zero Trust Network Access.

Exam trap

The trap here is that candidates often confuse ZTNA tags with simple firewall policy tags or logging labels, but ZTNA tags are specifically dynamic attributes applied to endpoints for identity- and posture-based policy enforcement, not for administrative labeling or logging.

How to eliminate wrong answers

Option A is wrong because SNMP monitoring is enabled via SNMP configuration under System > SNMP, not through ZTNA tags, which are used for access control decisions. Option B is wrong because static IP assignment is handled by DHCP reservations or manual configuration, not by ZTNA tags, which are dynamic attributes for policy matching. Option D is wrong because firewall policy logging is enabled via the 'Log' option within a policy, not by tagging policies with ZTNA tags; ZTNA tags mark endpoints, not policies.

Practice this question →

47

MCQeasy

Which mode of SSL VPN provides full network-layer access to the remote network, allowing any application to function as if the client is directly connected?

A.Tunnel mode

B.Web mode

C.Split tunneling mode

D.Clientless mode

AnswerA

Tunnel mode is the SSL VPN operating mode that creates a virtual network adapter on the client and assigns it an IP address from the internal network. This allows the client to participate at Layer 3, with routing entries directing traffic through the TLS-encrypted tunnel, thereby providing full network-layer access to any IP-based service, not just web applications.

Why this answer

Tunnel mode is correct because it creates a virtual network interface on the client that obtains an IP address from the FortiGate's SSL VPN address pool, encapsulating all IP traffic within SSL/TLS packets. This provides full network-layer (Layer 3) access, allowing any application—including those using non-HTTP protocols like SSH, RDP, or custom TCP/UDP services—to function as if the client were directly connected to the remote network.

Exam trap

The trap here is that candidates often confuse 'split tunneling' as a separate VPN mode when it is actually a routing configuration option within tunnel mode, leading them to incorrectly select Option C instead of recognizing that tunnel mode is the only mode providing full network-layer access.

How to eliminate wrong answers

Option B (Web mode) is wrong because it only provides application-layer access via a web portal, proxying HTTP/HTTPS traffic and cannot handle non-web protocols or raw IP packets. Option C (Split tunneling mode) is wrong because it is not a distinct SSL VPN mode; it is a routing policy that can be applied within tunnel mode to direct only specific subnets over the VPN, but it does not define the fundamental access method. Option D (Clientless mode) is wrong because it relies on a web browser and supports only limited applications (e.g., web-based, VNC, RDP via Java/ActiveX) without installing a client, thus lacking full network-layer access.

Practice this question →

48

MCQmedium

You are configuring a route-based IPsec VPN with BGP over the tunnel. After Phase 2 is up, the BGP session does not establish. You run 'diagnose debug ipsec' and see no errors. What should you check next?

A.Disable anti-replay on the tunnel

B.Enable NAT traversal

C.Ensure the tunnel interface is added to the BGP neighbor configuration

D.Check the Phase 1 proposal

AnswerC

In a route-based IPsec VPN, the tunnel interface is a logical interface that terminates the encrypted traffic and carries the BGP session. For BGP to establish, the neighbor command must reference the correct IP address of the remote peer on that tunnel interface, and the local tunnel interface must be set as the update source (or the source interface must be reachable). Without the tunnel interface being tied to the BGP neighbor configuration, BGP will attempt to use another interface as the source, so the TCP connection fails even though IPsec is up.

Why this answer

When Phase 2 is up and 'diagnose debug ipsec' shows no errors, the IPsec tunnel is functioning correctly at the encryption layer. The BGP session failing to establish typically indicates a routing or interface configuration issue. Option C is correct because the tunnel interface must be explicitly added to the BGP neighbor configuration (e.g., 'config router bgp -> config neighbor -> set interface <tunnel>') so that BGP knows to send its TCP packets (port 179) over that specific tunnel interface; without this, BGP may try to use the physical interface instead, causing the session to fail.

Exam trap

The trap here is that candidates assume a successful Phase 2 means the tunnel is fully operational for all traffic, overlooking that BGP requires explicit interface binding to the tunnel interface to establish the TCP session.

How to eliminate wrong answers

Option A is wrong because disabling anti-replay would not affect BGP session establishment; anti-replay is a security feature that prevents packet replay attacks and does not impact routing protocol connectivity. Option B is wrong because NAT traversal is only needed when a NAT device is present between the VPN peers, and the question does not indicate any NAT scenario; enabling it unnecessarily would not resolve a BGP peering issue. Option D is wrong because Phase 1 is already up (as Phase 2 is established), so checking Phase 1 proposals is irrelevant; the problem lies in the BGP configuration, not the IKE/ISAKMP settings.

Practice this question →

49

MCQmedium

An administrator runs 'diagnose debug application fnbamd -1' on a FortiGate to troubleshoot authentication issues. The output shows that the FortiGate successfully contacts the LDAP server but the user authentication fails. What does this indicate?

A.The user's password is incorrect or the user account is locked

B.The LDAP server is unreachable

C.The LDAP bind user password is incorrect

D.The LDAP schema does not match what FortiGate expects

AnswerA

In the fnbamd debug output, "successful contact" confirms that the FortiGate established a TCP session and communicated with the LDAP server; the failure happens during the final bind step where the end user's distinguished name (DN) and password are verified. An LDAP 'invalidCredentials' or 'accountDisabled' result at this stage is the server's definitive rejection of that specific user's password or account state, not a communication problem. Therefore, the correct interpretation is that the user's password is wrong or the user account is locked out, disabled, or expired.

Why this answer

The 'diagnose debug application fnbamd -1' output shows successful contact with the LDAP server, meaning network connectivity and server reachability are fine. Since the server is reachable but authentication fails, the most likely cause is that the user's credentials (password) are incorrect or the account is locked/disabled on the LDAP server. This is a standard LDAP bind failure scenario where the server returns an 'invalid credentials' or 'account locked' error.

Exam trap

The trap here is that candidates often confuse a successful TCP connection or LDAP server response with successful authentication, not realizing that the FortiGate must perform a separate bind with the user's credentials, which can fail independently.

How to eliminate wrong answers

Option B is wrong because the output explicitly indicates the FortiGate successfully contacts the LDAP server, ruling out unreachability. Option C is wrong because the LDAP bind user password is used for the initial bind to search the directory, not for user authentication; a bind user password issue would prevent the search from succeeding, but the output shows contact is successful. Option D is wrong because an LDAP schema mismatch would typically cause attribute retrieval failures (e.g., group membership), not a direct authentication failure during the user bind attempt.

Practice this question →

50

MCQmedium

The output of 'diagnose debug application ike -1' shows 'no proposal chosen' for a Phase1 negotiation. Which action should the administrator take to resolve this?

A.Increase the Phase1 lifetime on both sides

B.Verify the pre-shared key is correct

C.Check and align the Phase1 encryption, authentication, and DH group settings

D.Change the IKE version from v1 to v2

AnswerC

This is the correct action: 'no proposal chosen' is an IKE Phase1 notification sent by the responder when it cannot find any overlap between its configured Phase1 parameters and the initiator's proposed transforms. The encryption algorithm, authentication/integrity algorithm, and Diffie-Hellman (DH) group must all match on both peers, and if any one of them differs, the proposal is rejected. Checking and aligning these settings directly addresses the root cause and is the standard troubleshooting step for this error.

Why this answer

The 'no proposal chosen' error in Phase 1 IKE negotiation indicates that the two VPN peers cannot agree on a common set of security parameters (proposal). The administrator must check and align the Phase 1 settings, specifically the encryption algorithm, authentication method, and Diffie-Hellman group, because these are the mandatory parameters matched during the IKE SA negotiation. Option C directly addresses this by ensuring both sides use identical Phase 1 proposals.

Exam trap

The trap here is that candidates often confuse 'no proposal chosen' with authentication failures (pre-shared key mismatch) or version incompatibility, but the error specifically occurs during the proposal exchange before authentication or version negotiation takes place.

How to eliminate wrong answers

Option A is wrong because increasing the Phase 1 lifetime does not resolve a proposal mismatch; lifetime is a secondary parameter that is negotiated after the proposal is accepted, and a mismatch here would cause a different error or rekey issue. Option B is wrong because a pre-shared key mismatch typically results in an authentication failure (e.g., 'invalid cookie' or 'authentication failed'), not a 'no proposal chosen' error, which occurs before authentication. Option D is wrong because changing the IKE version from v1 to v2 does not fix a proposal mismatch; both versions require matching encryption, authentication, and DH group settings, and the error would persist if the proposals are still misaligned.

Practice this question →

51

MCQeasy

What is the primary difference between route-based and policy-based IPsec VPNs on a FortiGate?

A.Route-based requires a static route, policy-based uses dynamic routing.

B.Route-based encrypts all traffic, policy-based encrypts only specified services.

C.Route-based supports only IKEv2, policy-based supports both IKEv1 and IKEv2.

D.Route-based uses a tunnel interface, policy-based uses firewall policies to define traffic selectors.

AnswerD

Route-based IPsec binds the tunnel to a virtual tunnel interface, so firewall policies route traffic into it and support dynamic routing. Policy-based IPsec instead matches traffic through firewall policies acting as traffic selectors, without a tunnel interface.

Why this answer

The primary difference is that route-based IPsec VPNs use a tunnel interface (e.g., 'phase1-interface' and 'phase2-interface') which participates in routing, while policy-based IPsec VPNs rely on firewall policies with explicit traffic selectors (source/destination addresses and services) to trigger encryption. In route-based VPNs, the tunnel interface is assigned an IP address and routes are used to direct traffic into the tunnel, decoupling encryption from policy matching. In policy-based VPNs, the firewall policy itself defines what traffic is encrypted, making the traffic selector part of the policy configuration.

Exam trap

The trap here is that candidates often confuse 'route-based' with 'dynamic routing' and 'policy-based' with 'static routing', but in reality, route-based VPNs can use either static or dynamic routing, while policy-based VPNs are inherently static and cannot participate in dynamic routing protocols.

How to eliminate wrong answers

Option A is wrong because route-based VPNs can use static or dynamic routing (e.g., OSPF, BGP) over the tunnel interface, and policy-based VPNs do not support dynamic routing at all—they rely solely on static traffic selectors defined in firewall policies. Option B is wrong because both route-based and policy-based VPNs encrypt only the traffic that matches their respective routing/policy rules; neither encrypts 'all traffic' by default. Option C is wrong because both VPN types support IKEv1 and IKEv2 on FortiGate; the choice of IKE version is independent of whether the VPN is route-based or policy-based.

Practice this question →

52

Multi-Selecthard

A FortiGate administrator is designing an SSL VPN solution for 500 remote users. The users need full network access. Which two design considerations are most important?

Select 2 answers

A.Ensure the SSL VPN IP pool has enough addresses for concurrent users.

B.Create firewall policies that allow traffic from the SSL VPN interface to internal networks.

C.Configure split tunneling to reduce load on the FortiGate.

D.Use certificate-based authentication for all users.

E.Enable port forwarding for RDP and SSH.

AnswersA, B

In tunnel-mode SSL VPN, each remote user must be leased a unique virtual IPv4 address from the configured SSL VPN IP pool. If the pool is smaller than the peak number of concurrent authenticated users, the FortiGate cannot allocate an address for additional sessions, so those users will fail to establish the tunnel even though authentication succeeds. Sizing the pool to the maximum simultaneous connections (not just the total number of registered users) is therefore a hard prerequisite for scalability.

Why this answer

The SSL VPN IP pool must have enough addresses to assign to all concurrent users. Without a sufficient pool, users will fail to obtain an IP address and cannot access the network. Option B is correct because firewall policies are required to permit traffic from the SSL VPN interface (e.g., ssl.root) to internal networks; without them, traffic is dropped even if the tunnel is established.

Exam trap

The trap here is that candidates often confuse optional features (like split tunneling or certificate authentication) with mandatory design requirements, overlooking the fundamental need for IP pool sizing and firewall policies to enable basic connectivity.

Practice this question →

53

Multi-Selecthard

An organization is implementing two-factor authentication for SSL VPN access using FortiToken. Which THREE components are necessary for this setup?

Select 3 answers

A.An LDAP server for user synchronization

B.A firewall policy that requires authentication and references the user group

C.A FortiToken assigned to the user

D.A user group with two-factor authentication enabled

E.A RADIUS server for token validation

AnswersB, C, D

The firewall policy is the enforcement point that triggers the authentication process. When a user attempts to match a policy that requires authentication, the FortiGate prompts for credentials and validates them against the referenced user group. Because the policy references the user group with two-factor enabled, it forces the user to provide both the password and the FortiToken code, making this policy a necessary component.

Why this answer

A firewall policy must reference the user group that has two-factor authentication enabled. The policy enforces authentication for SSL VPN traffic, and without this reference, the FortiGate would not require the user to authenticate via FortiToken, defeating the purpose of two-factor authentication.

Exam trap

The trap here is that candidates often assume an external authentication server (LDAP or RADIUS) is mandatory for two-factor authentication, but FortiGate can validate FortiTokens locally without any external server.

Practice this question →

54

Multi-Selecteasy

An administrator is configuring a dialup IPsec VPN for remote users. Which two settings must be configured on the FortiGate to allow clients to connect?

Select 2 answers

A.Enable XAuth for user authentication.

B.Enable Dead Peer Detection.

C.Enable mode-cfg on the Phase 1 interface.

D.Enable NAT traversal.

E.Create an IP pool for the remote clients.

AnswersC, E

Enabling mode-cfg on the Phase 1 interface is the direct mechanism by which the FortiGate pushes the client configuration back to the dialup peer. This configuration includes the assigned IPv4 address, DNS server, WINS server, and sometimes split-tunnel settings. Without mode-cfg, a remote client has no tunnel IP and cannot route traffic through the VPN, so it is a mandatory component for dialup deployments. In FortiOS, mode-cfg references an IP pool to source the addresses.

Why this answer

Mode-config (mode-cfg) on the Phase 1 interface is required to push network configuration parameters (such as DNS, WINS, and the virtual IP address) to remote IPsec VPN clients. This setting enables the FortiGate to act as a server in a dialup VPN scenario, dynamically assigning IP addresses and other settings to clients without requiring static configuration on each client.

Exam trap

The trap here is that candidates often assume XAuth or NAT traversal are mandatory for dialup IPsec, but the FortiGate specifically requires mode-cfg and an IP pool to dynamically assign client addresses and complete the tunnel setup.

Practice this question →

55

MCQmedium

A FortiGate admin is configuring a hub-and-spoke IPsec VPN. The hub has multiple phase 2 configurations for each spoke. The spokes can communicate with the hub but not with each other. The admin wants to allow spoke-to-spoke traffic through the hub. Which configuration change is required on the hub?

A.Change the IPsec mode from policy-based to route-based

B.Modify the Phase 2 selectors on the hub to include both spoke subnets and add firewall policies allowing traffic between the spoke networks

C.Enable 'add-route' on the hub's Phase 1 settings

D.Configure a static route on each spoke pointing to the other spoke's subnet via the tunnel

AnswerB

The correct fix is to ensure the hub's Phase 2 selectors for each spoke tunnel define traffic selectors that include both hub-side and remote-spoke subnets, so the hub can decapsulate traffic from one spoke, match it against the phase2 selectors of the other spoke's tunnel, and re-encapsulate it for forwarding. Additionally, the hub must have firewall policies that explicitly allow traffic between the spoke networks—typically by placing each spoke interface in a zone and permitting the traffic between them or using address objects. Without both the expanded selectors and the inter-spoke firewall policy, packets arriving from one spoke for the other will be dropped, as the hub either lacks the matching phase2 selector or the policy permission to forward the traffic.

Why this answer

In a hub-and-spoke VPN with policy-based IPsec, the hub's Phase 2 selectors define which subnets can communicate through each tunnel. By default, each spoke's Phase 2 selector only includes the hub and that specific spoke's subnets, blocking spoke-to-spoke traffic. Adding both spoke subnets to the hub's Phase 2 selectors and creating firewall policies that permit traffic between those spoke networks allows the hub to route traffic between spokes, effectively enabling spoke-to-spoke communication through the hub.

Exam trap

The trap here is that candidates often assume route-based VPNs are always required for spoke-to-spoke communication, but the real issue is that Phase 2 selectors and firewall policies must be explicitly configured to allow inter-spoke traffic through the hub.

How to eliminate wrong answers

Option A is wrong because changing from policy-based to route-based IPsec is not required; the issue is with Phase 2 selectors and firewall policies, not the IPsec mode. Route-based VPNs use virtual interfaces and routing, but the same selector and policy adjustments would still be needed to allow spoke-to-spoke traffic. Option C is wrong because 'add-route' on Phase 1 settings automatically installs routes for remote networks based on Phase 2 selectors, but it does not modify the selectors themselves or create firewall policies to permit spoke-to-spoke traffic.

Option D is wrong because configuring static routes on each spoke for the other spoke's subnet via the tunnel would only work if the hub already had the correct Phase 2 selectors and firewall policies; without those, the traffic would be dropped at the hub.

Practice this question →

56

MCQeasy

What is the primary purpose of the captive portal feature on a FortiGate?

A.To monitor bandwidth usage per user

B.To block all traffic from unknown IP addresses

C.To enable SSL VPN connections

D.To provide a web-based authentication interface for users connecting through a firewall policy

AnswerD

The captive portal feature forces any client that matches a firewall policy with it enabled to authenticate through an HTTP/HTTPS page before its traffic is forwarded. It supports local users, LDAP, RADIUS, and other auth methods, and once the user authenticates, FortiGate adds a session entry that permits subsequent traffic. This enables network administrators to control guest or office internet access without deploying a full VPN or a separate authentication appliance.

Why this answer

The captive portal feature on a FortiGate provides a web-based authentication interface that intercepts HTTP/HTTPS traffic from unauthenticated users and redirects them to a login page. Once the user successfully authenticates (e.g., via local database, LDAP, or RADIUS), the FortiGate dynamically creates a firewall authentication entry, allowing the user's traffic to pass according to the configured firewall policy. This is the primary purpose: to enforce user-based access control through a browser-based authentication mechanism.

Exam trap

The trap here is that candidates often confuse the captive portal with SSL VPN portal or general firewall blocking, but the captive portal is specifically a web-based authentication gateway for local network access, not a VPN endpoint or a blanket traffic blocker.

How to eliminate wrong answers

Option A is wrong because bandwidth monitoring per user is handled by FortiGate's traffic shaping and logging features, not by the captive portal, which focuses on authentication and access control. Option B is wrong because blocking all traffic from unknown IP addresses is a function of firewall policies with default deny rules or IP reputation filtering, not the captive portal, which actually allows unknown users to reach the authentication page before granting access. Option C is wrong because SSL VPN connections are established via the FortiGate's SSL VPN portal (using port 443/tcp with specific VPN settings), not through the captive portal, which is used for local network access authentication.

Practice this question →

57

Multi-Selecteasy

An administrator needs to authenticate users on a FortiGate using RADIUS. Which TWO of the following are required to configure RADIUS authentication?

Select 2 answers

A.A PKI certificate for the RADIUS server

B.A RADIUS server object with IP address and shared secret

C.An FSSO connector

D.A user group that references the RADIUS server

E.A local user account for each RADIUS user

AnswersB, D

RADIUS authentication requires a server object defining the RADIUS host's IP address and the shared secret used to encrypt and authenticate the FortiGate-to-server exchange. Without this object, the FortiGate cannot reach or trust the RADIUS server, so authentication requests fail.

Why this answer

Option B is correct because configuring RADIUS authentication on a FortiGate requires creating a RADIUS server object under User & Authentication > RADIUS Servers, which must include the server's IP address and the shared secret used to encrypt the RADIUS exchange (typically over UDP ports 1812/1813). Option D is correct because the RADIUS server object alone does not enforce authentication; you must create a user group that references the RADIUS server so it can be applied in firewall identity-based policies or SSL-VPN/LDAP-style authentication rules. Option A is not required because PKI certificates are only needed for EAP/TLS-based RADIUS or LDAPS scenarios, not basic RADIUS shared-secret authentication.

Option C is not required because FSSO is a separate agent-based single sign-on mechanism, not a prerequisite for RADIUS. Option E is not required because RADIUS users are authenticated against the external RADIUS database, not against local FortiGate accounts.

Exam trap

The trap here is that candidates often think a local user account is required for each RADIUS user, but RADIUS offloads authentication to an external server, making local accounts unnecessary.

Practice this question →

58

MCQhard

A FortiGate in a hub-and-spoke VPN topology has multiple spoke sites connecting via IPsec. The hub administrator wants to enable direct spoke-to-spoke communication without routing traffic through the hub. What technology should be used?

A.ADVPN (Auto-Discovery VPN)

B.Site-to-site VPN between each spoke pair manually

C.Policy-based VPN with multiple Phase 2 selectors

D.SSL VPN tunnel mode

AnswerA

ADVPN (Auto-Discovery VPN) is the correct dynamic solution. It builds on a standard hub-and-spoke IPsec topology, where the hub acts as a route reflector and triggers short-cut negotiations between spokes via IKE informational exchanges when inter-spoke traffic is detected. This allows spokes to dynamically establish direct IPsec tunnels, eliminating the need for traffic to hairpin through the hub and providing optimal routing and reduced latency.

Why this answer

ADVPN (Auto-Discovery VPN) is the correct technology because it dynamically establishes direct IPsec tunnels between spoke sites in a hub-and-spoke topology, eliminating the need to route inter-spoke traffic through the hub. It uses IKEv2 with short-cut messages (via the hub as a signaling broker) to allow spokes to learn each other's public IP addresses and negotiate a direct tunnel, reducing latency and hub load.

Exam trap

The trap here is that candidates often confuse ADVPN with simply adding more Phase 2 selectors to an existing tunnel, thinking that will magically route traffic directly between spokes, when in fact Phase 2 selectors only control encryption policies, not tunnel establishment.

How to eliminate wrong answers

Option B is wrong because manually configuring site-to-site VPNs between every spoke pair is not scalable and defeats the purpose of a hub-and-spoke design—it requires N*(N-1)/2 tunnels and static configuration, whereas ADVPN automates this. Option C is wrong because policy-based VPNs with multiple Phase 2 selectors only define which traffic is encrypted over an existing tunnel; they do not create new tunnels or enable direct spoke-to-spoke communication without hub involvement. Option D is wrong because SSL VPN tunnel mode provides remote user access to the network, not site-to-site connectivity; it cannot dynamically establish tunnels between spoke sites.

Practice this question →

59

MCQeasy

An administrator wants to configure SSL VPN web mode to allow remote users to access a specific internal web application without installing any client software. Which authentication method is required?

A.Certificate-based authentication only

B.No authentication is required for web mode

C.Two-factor authentication with FortiToken is mandatory

D.Any supported authentication method (local, LDAP, RADIUS, certificates)

AnswerD

FortiGate SSL VPN web mode supports multiple authentication backends, including local users, LDAP, RADIUS, and certificate-based authentication. The administrator selects the appropriate method when configuring the SSL VPN portal and corresponding user group. This flexibility allows integration with existing identity sources while maintaining centralized access control, which is why this is the correct answer.

Why this answer

SSL VPN web mode on FortiGate allows remote users to access internal web applications through a browser without client software. FortiGate supports multiple authentication methods for web mode, including local users, LDAP, RADIUS, and certificate-based authentication, so any supported method can be used. There is no requirement for a specific authentication type, making option D correct.

Exam trap

The trap here is that candidates assume SSL VPN web mode requires a specific strong authentication method (like certificates or two-factor), but FortiGate allows any supported method, and the question explicitly asks which is 'required'—not recommended.

How to eliminate wrong answers

Option A is wrong because certificate-based authentication is not mandatory; FortiGate allows other methods like local, LDAP, or RADIUS for SSL VPN web mode. Option B is wrong because SSL VPN web mode always requires authentication to establish the VPN tunnel and access internal resources; no authentication is not supported. Option C is wrong because two-factor authentication with FortiToken is optional, not mandatory; administrators can choose simpler methods if security policies allow.

Practice this question →

60

MCQhard

A FortiGate administrator is configuring a route-based IPsec VPN between two FortiGate devices. After setting up the tunnel and firewall policies, traffic does not flow. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. 'get router info routing-table all' shows routes on both sides. However, pings from the local network to the remote network fail. What is the MOST likely cause?

A.The pre-shared key is incorrect

B.The firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed

C.The remote FortiGate's static route points to the wrong local subnet

D.The Phase 2 proposal uses different encryption algorithms on each side

AnswerB

In a route-based VPN, the policy must be configured with the VPN interface as the destination interface (if traffic flows from internal to VPN) or source interface (if from VPN to internal). Misconfiguration here causes traffic to be dropped.

Why this answer

The tunnel is up and routes are present, indicating Phase 1 and Phase 2 negotiations succeeded. The most likely cause is that the firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed. In a route-based VPN, the policy must have the incoming interface as the source (e.g., internal) and the outgoing interface as the destination (e.g., the VPN tunnel interface).

Reversing these prevents traffic from being matched, even though the tunnel is established.

Exam trap

The trap here is that candidates assume a tunnel being up and routes present guarantees traffic flow, overlooking that the firewall policy's interface direction must match the traffic flow, not the tunnel's logical direction.

How to eliminate wrong answers

Option A is wrong because an incorrect pre-shared key would prevent Phase 1 from completing, causing the tunnel to show as down, not up. Option C is wrong because the remote FortiGate's static route pointing to the wrong local subnet would cause asymmetric routing or unreachability, but the local side's routes are correct per the scenario; the issue is on the local firewall policy, not the remote route. Option D is wrong because mismatched Phase 2 proposals would cause the tunnel to fail to establish or show as up with no traffic, but 'diagnose vpn tunnel list' would typically show a down or error state, not 'up'.

Practice this question →

61

MCQeasy

A FortiGate administrator wants to authenticate VPN users against an existing Active Directory server. The administrator creates a user group referencing a remote LDAP server and configures the firewall policy to authenticate using that group. However, users report authentication failures. What is the FIRST step to troubleshoot?

A.Run 'diag test authserver ldap <server> <username> <password>'

B.Verify the user group configuration

C.Restart the FortiGate

D.Check the LDAP server's firewall rules

AnswerA

Running the diagnostic command `diag test authserver ldap <server> <username> <password>` forces the FortiGate to initiate a live LDAP bind operation against the configured server object using the exact credentials provided. This single command validates the LDAP server's network reachability (TCP and TLS if LDAPS is enabled) and the correctness of the bind password in one step. Because it bypasses the VPN tunnel and user-group mapping layers, any failure here pinpoints a core LDAP authentication issue, making it the most efficient first troubleshooting action for VPN user login failures.

Why this answer

The `diag test authserver ldap` command directly tests LDAP authentication against the specified server, username, and password, isolating whether the FortiGate can successfully bind and authenticate the user. This is the fastest way to determine if the issue lies with the LDAP server connectivity, credentials, or configuration, rather than with the user group or policy. Since the administrator has already created the group and policy, the first logical step is to verify the fundamental authentication path before examining higher-level configurations.

Exam trap

The trap here is that candidates often jump to checking the user group or policy configuration (Option B) because they assume the LDAP server is reachable, but the NSE4 exam emphasizes using diagnostic commands first to isolate the problem at the authentication source.

How to eliminate wrong answers

Option B is wrong because verifying the user group configuration assumes the authentication itself works, but the core issue may be that the FortiGate cannot reach or bind to the LDAP server at all. Option C is wrong because restarting the FortiGate is a blunt, non-diagnostic step that does not address the root cause and may temporarily mask the problem without providing insight. Option D is wrong because checking the LDAP server's firewall rules is a network-level check that should be performed only after confirming the FortiGate's own LDAP test fails, as the test command will reveal connectivity or authentication errors first.

Practice this question →

62

MCQmedium

A client connects to a FortiGate SSL VPN in web mode. The user can access internal web applications but cannot ping or RDP to servers. The administrator wants to allow these services. What must be changed?

A.Enable split tunneling on the SSL VPN portal

B.Change the SSL VPN type from web mode to tunnel mode

C.Add the server IP addresses to the portal's bookmarks

D.Configure a firewall policy allowing the client's IP to the servers

AnswerB

Web mode proxies only HTTP and HTTPS through the browser, so ICMP and RDP cannot traverse it. Tunnel mode installs a virtual adapter and routes arbitrary IP traffic, enabling ping and RDP to internal servers.

Why this answer

Web mode SSL VPN only provides application-layer access through a web portal, typically using HTTP/HTTPS. It does not create a virtual network interface on the client, so lower-layer protocols like ICMP (ping) and RDP (TCP/3389) cannot be routed through the VPN. To support these services, the VPN must operate in tunnel mode, which assigns a virtual IP to the client and creates a full Layer 3 tunnel, allowing all IP-based traffic to traverse the FortiGate.

Exam trap

The trap here is that candidates assume adding a firewall policy or enabling split tunneling will magically allow non-web traffic in web mode, not realizing that web mode fundamentally lacks the Layer 3 virtual interface required to route protocols other than HTTP/HTTPS.

How to eliminate wrong answers

Option A is wrong because split tunneling controls which destinations are routed through the VPN tunnel versus the internet, but it does not change the fundamental limitation of web mode—web mode cannot pass non-HTTP traffic regardless of split tunneling settings. Option C is wrong because bookmarks in the SSL VPN portal are only shortcuts for web-based applications; they do not enable protocol-level forwarding for ICMP or RDP. Option D is wrong because firewall policies are necessary for traffic to be permitted, but without tunnel mode, the client's traffic never reaches the FortiGate as routable IP packets—web mode only proxies HTTP/HTTPS requests, so a firewall policy alone cannot allow ping or RDP.

Practice this question →

63

MCQeasy

Which IPsec VPN mode is typically used for site-to-site VPNs and is more secure because it negotiates Phase 1 in six messages?

A.Quick mode

B.Aggressive mode

C.IKEv2

D.Main mode

AnswerD

Main Mode is the default IKEv1 Phase 1 mode for site-to-site VPNs because it uses six messages to negotiate the IKE SA while protecting each side's identity. It performs the Diffie-Hellman exchange before sending identities, and all identity information is encrypted once the SA is established, which mitigates packet sniffing on untrusted links. FortiGate's phase 1 settings allow selecting Main to enforce this more robust exchange, making it the recommended choice for fixed, site-to-site peers.

Why this answer

Main mode is the correct answer because it is the IPsec VPN mode typically used for site-to-site VPNs and is considered more secure due to its use of six messages during Phase 1 (IKE) negotiation. This mode protects the identities of both peers by encrypting the identity payloads after the Diffie-Hellman exchange, making it resistant to man-in-the-middle attacks and identity disclosure.

Exam trap

The trap here is that candidates often confuse Main mode with Aggressive mode, mistakenly thinking Aggressive mode is more secure because it is faster, but in reality, Aggressive mode sacrifices identity protection for speed, making it less secure for site-to-site VPNs.

How to eliminate wrong answers

Option A is wrong because Quick mode is a Phase 2 exchange that negotiates IPsec security associations (SAs) for data traffic, not a Phase 1 mode, and it uses only three messages, not six. Option B is wrong because Aggressive mode uses only three messages in Phase 1, which reduces security by transmitting identities in cleartext before the Diffie-Hellman exchange is completed, making it vulnerable to identity theft. Option C is wrong because IKEv2 is a separate protocol that uses a four-message exchange (two request/response pairs) for initial SA setup, not six messages, and while it is secure, it is not the mode described in the question.

Practice this question →

64

Multi-Selecthard

Which TWO are best practices for configuring IPsec VPN on FortiGate to ensure high availability and security?

Select 2 answers

A.Disable DPD on the phase1 interface to reduce overhead.

B.Enable perfect forward secrecy (PFS) for phase2 to ensure session keys are not compromised if a private key is stolen.

C.Use aggressive mode for faster IKE negotiation.

D.Configure a dead peer detection (DPD) interval to detect tunnel failures.

E.Disable PFS to reduce CPU load on the firewall.

AnswersB, D

Enabling PFS for phase2 is a best practice because it forces a new Diffie-Hellman exchange for each Quick Mode, generating fresh session keys independent of the IKE SA's shared secret. If the firewall's private key or pre-shared secret is later stolen, an attacker cannot use it to derive previous or subsequent phase2 keys, limiting data exposure to the current session. PFS adds a small computational cost but is strongly recommended for environments handling sensitive data.

Why this answer

Perfect Forward Secrecy (PFS) ensures that if an attacker compromises the private key used during IKE phase1, they cannot derive the session keys used in phase2. By requiring a new Diffie-Hellman exchange for each phase2 rekey, PFS isolates the compromise to only the current session, protecting past and future encrypted traffic. This is a critical security best practice for IPsec VPNs on FortiGate.

Exam trap

The trap here is that candidates often confuse DPD with a performance overhead feature and disable it, or they mistakenly believe aggressive mode is faster and therefore better, overlooking the severe security implications of sending identities in cleartext.

Practice this question →

65

MCQeasy

A FortiGate administrator is configuring a new SSL VPN portal for employees. The requirement is that employees must authenticate using their Active Directory credentials, and after authentication, they should only be able to access a specific internal web server via a bookmarked link. Which SSL VPN configuration should the administrator use to meet these requirements?

A.Configure the SSL VPN settings to use 'Web Mode' and add a bookmark to the portal for the internal web server.

B.Configure the SSL VPN settings to use 'Web Mode' and enable 'Client Certificate' authentication.

C.Configure the SSL VPN settings to use 'Tunnel Mode' with split tunneling and add a static route for the web server.

D.Configure the SSL VPN settings to use 'Tunnel Mode' and create a firewall policy allowing all internal subnets.

AnswerA

Web mode allows users to access specific web-based applications through a portal without a full tunnel. By adding a bookmark to the internal web server, users can click the link to access it. Authentication can be set to use Active Directory. This meets the requirements of AD authentication and limited access to a specific web server via a bookmark.

Why this answer

Web mode is designed for browser-based access to specific applications, and bookmarks provide easy links to internal web servers. Authentication can be configured to use Active Directory, satisfying the credential requirement. Tunnel mode would provide broader network access than needed and does not use bookmarks for specific applications.

Therefore, web mode with a bookmark and AD authentication is the correct solution.

Exam trap

The trap here is assuming that tunnel mode is always required for internal access, when web mode with bookmarks is sufficient and more secure for specific web applications.

Practice this question →

66

MCQeasy

A company uses Fortinet Single Sign-On (FSSO) to authenticate users for firewall policies. The FSSO collector agent is installed on a Windows server and configured with Active Directory polling. What does the collector agent do?

A.It acts as a RADIUS proxy between FortiGate and AD

B.It monitors AD logon events and sends user-IP mappings to the FortiGate

C.It polls the FortiGate for user information

D.It directly authenticates users to the FortiGate

AnswerB

The FSSO collector agent polls Active Directory domain controllers for logon events, then forwards the resulting user-to-IP mappings to the FortiGate. This lets firewall policies identify users by IP without requiring them to authenticate directly against the FortiGate.

Why this answer

The FSSO collector agent polls Active Directory for security event logs to detect user logon events. It then maps the logged-on user to their IP address and sends this user-IP mapping to the FortiGate via the FSSO protocol (port 8000). This allows the FortiGate to enforce firewall policies based on user identity without requiring the user to authenticate directly to the FortiGate.

Exam trap

The trap here is that candidates often confuse the collector agent's role with that of a RADIUS server or a direct authentication proxy, but FSSO is purely a passive monitoring mechanism that does not perform authentication itself.

How to eliminate wrong answers

Option A is wrong because the FSSO collector agent does not act as a RADIUS proxy; RADIUS-based authentication is handled by a separate FortiAuthenticator or RADIUS server, not by the collector agent. Option C is wrong because the collector agent does not poll the FortiGate for user information; instead, it pushes user-IP mappings to the FortiGate. Option D is wrong because the collector agent does not directly authenticate users to the FortiGate; it only monitors existing AD logon events and relays the mapping information.

Practice this question →

67

MCQhard

An administrator runs 'diagnose vpn ssl stat' and sees 'tun-num: 5, clients: 0'. Users are unable to connect to the SSL VPN. The SSL VPN settings are correct and the certificate is valid. What could be the cause?

A.The FortiGate has reached the maximum number of SSL VPN users allowed by the license

B.The SSL VPN is listening on a non-default port and users are connecting to the default port

C.The SSL VPN certificate is not trusted by the client browsers

D.The SSL VPN portal is configured with 'limit-scan' scanning

AnswerB

The FortiGate's SSL VPN listening port is configured under `config vpn ssl settings` and defaults to 443. If it has been changed to a non-standard port like 10443, client connections attempting to reach 443 will not be accepted by the SSL VPN service, resulting in no established sessions. Thus `diagnose vpn ssl stat` correctly displays zero active tunnels because the clients are connecting to the wrong port and never complete the handshake.

Why this answer

The 'tun-num: 5, clients: 0' output indicates that the SSL VPN tunnel interface is up but no clients are connected. If the SSL VPN settings and certificate are correct, the most likely cause is a port mismatch: the FortiGate is configured to listen on a non-default port (e.g., 10443), but users are attempting to connect to the default SSL VPN port (443). This prevents the SSL handshake from completing, resulting in zero active clients.

Exam trap

The trap here is that candidates assume 'tun-num: 5, clients: 0' indicates a licensing or certificate issue, but the key diagnostic clue is that the tunnel interface exists (meaning the service is running) yet no clients are connected, pointing to a connectivity or port mismatch rather than a resource or authentication problem.

How to eliminate wrong answers

Option A is wrong because if the license limit were reached, 'clients: 0' would not appear; instead, the output would show a count equal to the maximum allowed, and users would receive a license limit error. Option C is wrong because an untrusted certificate would still allow a connection attempt (with a browser warning), and the 'clients' count would increment as the SSL handshake begins; the issue here is zero clients, not a certificate trust problem. Option D is wrong because 'limit-scan' is a web filtering feature that controls scanning of web content, not a parameter that blocks SSL VPN connections; it has no effect on the SSL VPN tunnel establishment.

Practice this question →

68

Multi-Selectmedium

An administrator wants to implement ZTNA (Zero Trust Network Access) on a FortiGate to secure access to an internal application. Which TWO components are essential for a ZTNA configuration?

Select 2 answers

A.A firewall policy using IPsec VPN

B.A FortiGate in transparent mode

C.A policy-based IPsec tunnel

D.A proxy-based firewall policy

E.A ZTNA rule that verifies endpoint identity and posture

AnswersD, E

ZTNA on FortiGate requires a proxy-based firewall policy, because the FortiGate must terminate and inspect the session to enforce per-application access rather than forwarding packets at layer 3/4. This satisfies the scenario's need to secure access to a specific internal application.

Why this answer

Option D is correct because ZTNA on FortiGate requires a proxy-based firewall policy, which enables full inspection of the traffic and allows the FortiGate to enforce ZTNA access control for the internal application. Option E is correct because the ZTNA rule is the core enforcement component that verifies the endpoint's identity and posture (via FortiClient EMS tags) before granting access to the protected resource. Options A and C are incorrect because ZTNA does not rely on IPsec VPN or policy-based IPsec tunnels; it uses a client-based access proxy model instead of traditional tunnel-based remote access.

Option B is incorrect because transparent mode is not an essential requirement for ZTNA; ZTNA can be deployed on a FortiGate in NAT/route mode as well.

Exam trap

The trap here is confusing ZTNA's proxy-based architecture with VPN-based access, leading candidates to incorrectly select IPsec or policy-based tunnel options, when ZTNA actually requires a proxy firewall policy and a separate ZTNA rule for endpoint verification.

Practice this question →

69

MCQeasy

Which of the following best describes the purpose of a captive portal on a FortiGate?

A.To provide secure remote access to internal resources

B.To authenticate users before granting network access

C.To encrypt traffic between sites

D.To block malware from entering the network

AnswerB

A captive portal intercepts HTTP/HTTPS sessions and redirects unauthenticated clients to a login page, so credentials are verified before any traffic is permitted through the FortiGate. This enforces the pre-access authentication constraint in the stem rather than merely logging or filtering traffic.

Why this answer

A captive portal on a FortiGate intercepts HTTP/HTTPS traffic from unauthenticated users and redirects them to a web-based login page. Once the user provides valid credentials (e.g., via local database, LDAP, or RADIUS), the FortiGate creates an authenticated session, allowing network access. This is a core mechanism for guest Wi-Fi or BYOD onboarding, not for remote access or encryption.

Exam trap

The trap here is that candidates confuse captive portal with SSL VPN or IPsec VPN, thinking it provides remote access or encryption, when in fact it only performs local network access authentication and does not create a secure tunnel.

How to eliminate wrong answers

Option A is wrong because secure remote access to internal resources is provided by IPsec VPN or SSL VPN (e.g., FortiClient), not by a captive portal which only authenticates users at the network edge. Option C is wrong because encrypting traffic between sites is the function of IPsec VPN tunnels or ADVPN, not a captive portal which does not perform any encryption. Option D is wrong because blocking malware is handled by FortiGate's antivirus, IPS, and web filtering engines, not by a captive portal which focuses solely on user authentication before granting network access.

Practice this question →

70

MCQhard

You receive an alert that a user's FortiToken synchronization is off. You need to resynchronize the token. Which CLI command achieves this?

A.diagnose user fortitoken resync <token-serial>

B.config user fortitoken edit <token-serial> set status activate

C.execute fortitoken-update <token-serial>

D.execute fortitoken-resync <token-serial>

AnswerD

"execute fortitoken-resync <token-serial>" is the correct command to resynchronize a FortiToken's OTP sequence with the FortiGate. It re-aligns the token's counter value with the server's expected counter, which is necessary when the token has been pressed multiple times without authentication, causing drift. This command is executed from the "execute" CLI level and takes the token serial number as its only argument.

Why this answer

The correct command to resynchronize a FortiToken on a FortiGate is `execute fortitoken-resync <token-serial>`. This CLI command triggers the token to synchronize its time-based one-time password (TOTP) seed with the FortiGate, correcting drift caused by clock skew or battery depletion. Options A, B, and C either use incorrect syntax, perform a different function, or do not exist in the FortiOS CLI.

Exam trap

The trap here is that candidates confuse the `execute` level command for resynchronization with the `diagnose` level command used for viewing token status, or they mistakenly think that editing the token configuration (Option B) can fix synchronization issues.

How to eliminate wrong answers

Option A is wrong because `diagnose user fortitoken resync` is not a valid FortiOS command; the correct diagnose command for token troubleshooting is `diagnose user fortitoken list` or `diagnose user fortitoken info`, but resynchronization is an execute-level operation. Option B is wrong because `config user fortitoken` is used to edit token attributes (like status or activation), not to trigger a resynchronization; setting `status activate` only enables the token, it does not fix synchronization drift. Option C is wrong because `execute fortitoken-update` is not a valid FortiOS command; the correct command for updating token firmware or seed is `execute fortitoken-update` does not exist, and the actual update process uses `execute fortitoken-import` or `execute fortitoken-resync`.

Practice this question →

71

MCQeasy

When configuring a route-based IPsec VPN, which of the following must be created to allow traffic to flow through the tunnel?

A.A static route to the remote subnet via the IPsec interface

B.A firewall policy with the VPN interface as source

C.A NAT rule to translate the private IPs

D.A security profile for VPN traffic

AnswerA

The static route is the core requirement in route-based IPsec VPN because the IPsec tunnel is bound to a virtual interface (e.g., s2s_ike). Without a route directing the remote subnet's destination IPs to that interface, the FortiGate has no next-hop to forward traffic into the tunnel, so packets are dropped by the routing decision. While a firewall policy must also exist to permit the traffic, it is the route that actually enforces the "remote subnet via IPsec interface" path, and traffic that doesn't follow this route remains unencrypted and may be routed incorrectly.

Why this answer

In a route-based IPsec VPN, the tunnel is represented as a virtual IPsec interface. To route traffic from the local network to the remote subnet through this tunnel, a static route must be configured with the remote subnet as the destination and the IPsec interface as the next-hop or outgoing interface. Without this route, the FortiGate has no forwarding information to send traffic into the tunnel, even if the IPsec phase 1 and phase 2 settings are correctly established.

Exam trap

The trap here is that candidates often confuse route-based VPNs with policy-based VPNs, mistakenly thinking that a firewall policy alone is sufficient to direct traffic into the tunnel, when in fact the route is the critical component that enables the forwarding decision in a route-based design.

How to eliminate wrong answers

Option B is wrong because a firewall policy with the VPN interface as source is not required; the policy must have the VPN interface as the destination (or as both source and destination in a bidirectional policy) to allow traffic exiting the tunnel, but the question specifically asks what must be created to allow traffic to flow through the tunnel, and the fundamental requirement is the route. Option C is wrong because NAT is not mandatory for route-based IPsec VPNs; in fact, site-to-site VPNs typically avoid NAT to preserve the original source IP, and NAT rules are only added if address translation is explicitly needed. Option D is wrong because a security profile (such as antivirus or web filter) is optional and applied to firewall policies for inspection, but it is not a prerequisite for traffic to flow through the tunnel.

Practice this question →

72

MCQeasy

An administrator is troubleshooting an SSL VPN connection issue. Users can authenticate but receive 'No available tunnel' error. What is the most likely cause?

A.Split tunneling is misconfigured.

B.The firewall policy does not allow traffic from the SSL VPN interface.

C.The SSL VPN port is blocked on the firewall.

D.The SSL VPN IP pool has run out of addresses.

AnswerD

When the SSL VPN IP pool is exhausted, the FortiGate cannot assign an IP address to the connecting client after successful authentication, so the tunnel cannot be completed. This often manifests as the client connecting and authenticating but then being unable to establish the tunnel or receive a virtual IP. In FortiOS, this condition can be verified with 'get vpn ssl monitor' or by checking the configured IP pool's usage.

Why this answer

The 'No available tunnel' error after successful authentication indicates that the SSL VPN daemon cannot assign an IP address to the client. The most likely cause is that the SSL VPN IP pool has exhausted its available addresses, preventing the creation of a virtual tunnel interface. This is a common issue when the pool size is smaller than the number of concurrent users.

Exam trap

The trap here is that candidates often confuse post-authentication issues (like IP pool exhaustion) with pre-authentication issues (like port blocking) or traffic-routing issues (like split tunneling or firewall policies), leading them to select options that would prevent authentication entirely rather than the specific error message given.

How to eliminate wrong answers

Option A is wrong because split tunneling controls which subnets are routed through the VPN tunnel versus the client's local network; it does not affect the ability to establish the tunnel itself. Option B is wrong because the firewall policy on the SSL VPN interface controls traffic forwarding after the tunnel is established, not the tunnel creation process. Option C is wrong because if the SSL VPN port were blocked, users would not be able to authenticate at all; the error occurs after successful authentication.

Practice this question →

73

MCQmedium

An administrator receives a report that some users cannot authenticate via captive portal on a FortiGate. The captive portal is configured for firewall authentication. The administrator checks the authentication logs and sees 'Authentication failed: invalid credentials'. However, the users confirm they are entering the correct username and password. What is the MOST likely cause?

A.The captive portal interface is not configured with a valid certificate

B.The users are not including the domain name in the username field

C.The FortiGate's clock is out of sync with the LDAP server

D.The LDAP server is not reachable from the FortiGate

AnswerB

When authenticating against an AD or LDAP server, FortiGate often requires the username in a fully qualified format such as DOMAIN\\username or as a User Principal Name (user@domain.com). If users type only their sAMAccountName, the FortiGate constructs a bind DN that does not match any directory entry, so the LDAP server returns error code 49 (invalidCredentials). The passwords may be correct, but the omitted domain prefix makes the bind fail exactly as if the password were wrong.

Why this answer

When FortiGate performs firewall authentication (captive portal) against an LDAP server, the username format must match what the LDAP server expects. If the LDAP server requires a domain-qualified username (e.g., DOMAIN\user or user@domain.com) and users enter only their short username, the bind attempt fails with 'invalid credentials' even though the password is correct. This is the most likely cause given that users confirm their credentials are correct and the logs show authentication failure rather than a connectivity error.

Exam trap

NSE4 often tests the difference between authentication failures caused by wrong username format versus connectivity or certificate issues, and candidates may overlook the domain-qualification requirement for LDAP binds.

How to eliminate wrong answers

Option A is wrong because a missing or invalid certificate on the captive portal interface would cause browser certificate warnings or portal access issues, not an 'invalid credentials' error in the authentication logs. Option C is wrong because clock skew with the LDAP server would typically cause Kerberos authentication failures, not simple LDAP bind failures; LDAP binds do not rely on time synchronization. Option D is wrong because if the LDAP server were unreachable, the logs would show a timeout or connection error, not 'invalid credentials'.

Practice this question →

74

Multi-Selectmedium

An administrator is configuring a FortiGate for ZTNA (Zero Trust Network Access). Which TWO components are essential for ZTNA to function? (Choose two.)

Select 2 answers

A.A firewall policy with ZTNA tags

B.A captive portal

C.FortiClient EMS for endpoint compliance

D.An IPsec VPN tunnel

E.An identity provider (IdP) for user authentication

AnswersC, E

FortiClient EMS for endpoint compliance is indeed a correct and required component of ZTNA. EMS continuously collects telemetry from FortiClient agents—such as OS patching, antivirus status, disk encryption, and overall device posture—and shares this real-time data with the FortiGate. The FortiGate uses this posture information to make per-session access decisions, enforcing that only compliant, healthy devices can reach a ZTNA-protected application. Without EMS, the FortiGate would have no way to verify the trustworthiness of the endpoint, which is central to a zero-trust architecture.

Why this answer

FortiClient EMS is essential for ZTNA because it enforces endpoint compliance by collecting device posture data (e.g., OS version, antivirus status, disk encryption) and communicating this to FortiGate via the FortiTelemetry protocol. Without EMS, the FortiGate cannot verify that endpoints meet security requirements before granting ZTNA access, which is a core principle of Zero Trust.

Exam trap

The trap here is that candidates often confuse ZTNA with VPN technologies (option D) or assume a captive portal (option B) is needed for user authentication, when in fact ZTNA requires an external IdP and EMS for its zero-trust model.

Practice this question →

75

Multi-Selecthard

A FortiGate administrator is troubleshooting an IPsec VPN between two FortiGates. The tunnel is established, but traffic is not passing. The administrator runs 'diagnose vpn ike log' and sees the following output: IKE: phase 2 negotiation completed IKE: IPsec SA up What THREE possible causes should the administrator investigate?

Select 3 answers

A.Firewall policies on either FortiGate are not allowing traffic between the local and remote subnets

B.The pre-shared key is incorrect

C.Routing tables on both FortiGates do not have routes pointing to the remote subnets via the VPN interface

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

E.NAT is being applied to the VPN traffic before it enters the tunnel, causing IP address mismatch

AnswersA, C, E

Even after an IPsec tunnel reaches Phase 2, traffic is still subject to the firewall policy database on each FortiGate. If no policy with action ACCEPT exists that matches the source/destination subnets and the incoming/outgoing interface (e.g., the IPsec virtual interface), the firewall silently drops the packets. A common misconfiguration is creating a policy for the WAN interface instead of the tunnel interface, or setting the wrong local/remote addresses in the policy.

Why this answer

Even though the IPsec SA is up (phase 2 completed), traffic will not pass unless firewall policies explicitly permit traffic between the local and remote subnets. FortiGate requires a policy that allows the traffic and references the VPN tunnel interface as the outgoing interface.

Exam trap

The trap here is that candidates assume a successful IPsec SA (phase 2 up) guarantees traffic flow, but FortiGate requires separate firewall policies and routing configuration for traffic to traverse the tunnel.

Practice this question →

Page 1 of 2 · 148 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Authentication and VPN questions.

Start 20-question session