Courseiva

CCNA Authentication and VPN Questions

73 questions · Authentication and VPN · All types, answers revealed

Practice these questionsDomain overviewAll 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

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 →
3
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 →
4
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 →
5
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 →
6
Multi-Selectmedium

An administrator needs to configure a hub-and-spoke IPsec VPN topology. Which TWO settings must be configured on the hub FortiGate to allow spokes to communicate with each other through the hub?

Select 2 answers
A.Enable NAT on the hub's tunnel interface.
B.Set Phase 2 selectors to 0.0.0.0/0 on the hub's side.
C.Configure the hub as a DNS server for the spokes.
D.Configure IKEv2 instead of IKEv1 on all tunnels.
E.Create firewall policies on the hub that allow traffic between the spoke networks.
AnswersB, E

This allows traffic to any destination, including other spokes.

Why this answer

In a hub-and-spoke IPsec VPN topology, the hub must have Phase 2 selectors set to 0.0.0.0/0 (any-to-any) so that it can negotiate a single IPsec SA that covers all possible spoke-to-spoke traffic. This allows the hub to decrypt traffic from one spoke and re-encrypt it for another spoke without requiring separate Phase 2 selectors for each spoke pair. Additionally, firewall policies on the hub must explicitly permit traffic between the spoke networks, as the hub acts as a router forwarding inter-spoke traffic.

Exam trap

The trap here is that candidates often think NAT or IKE version changes are required for spoke-to-spoke communication, but the core requirements are simply the correct Phase 2 selectors (0.0.0.0/0) and proper firewall policies on the hub to allow forwarding.

Practice this question →
7
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 →
8
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

PFS group must match; if one peer has PFS disabled and the other has it enabled, Phase 2 will fail.

Why this answer

The 'no matching proposal' error in Phase 2 often indicates a mismatch in the Perfect Forward Secrecy (PFS) group. PFS ensures that if a private key is compromised, past session keys are not exposed; both ends must agree on the same Diffie-Hellman group (e.g., group 2, 5, 14) for Phase 2. If one side has PFS enabled with a specific group and the other does not, or uses a different group, the proposal fails.

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 →
9
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

After authentication, traffic must match a policy. If missing, traffic is dropped.

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 →
10
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 →
11
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 →
12
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 →
13
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 requires matching proxy IDs.

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 →
14
MCQhard

A FortiGate administrator notices that the IPsec VPN tunnel is established but traffic is not passing. The firewall policy allowing traffic from the remote subnet to the local subnet is in place. What is the MOST likely cause?

A.The VPN tunnel is a policy-based VPN and the policy is incorrectly configured
B.The Phase 2 proposal includes PFS, but the remote side does not
C.The local firewall is blocking ICMP
D.There is no static route on the FortiGate for the remote subnet pointing to the tunnel interface
AnswerD

Without a route, the FortiGate does not know how to forward traffic to the remote subnet even if the tunnel is up.

Why this answer

When an IPsec VPN tunnel is established but traffic fails to pass, the most common cause is the lack of a static route on the FortiGate for the remote subnet pointing to the tunnel interface. Even with a correct firewall policy, the FortiGate cannot forward traffic to the remote subnet without a route that directs packets into the VPN tunnel interface (e.g., 'tunnel.1'). This is a fundamental routing requirement for route-based VPNs, which are the default configuration on FortiGate.

Exam trap

The trap here is that candidates often assume a firewall policy alone is sufficient for VPN traffic, forgetting that route-based VPNs require a separate static route to direct traffic into the tunnel interface, which is a common oversight in NSE4 exams.

How to eliminate wrong answers

Option A is wrong because a policy-based VPN uses a firewall policy to define the traffic selector, and if the tunnel is established, the policy is likely correct; the issue is more commonly a missing route. Option B is wrong because PFS (Perfect Forward Secrecy) mismatch in Phase 2 would cause the tunnel to fail to establish or rekey, not allow the tunnel to be up while blocking traffic. Option C is wrong because blocking ICMP would only affect ping tests, not all traffic; the question states 'traffic is not passing,' implying a complete failure for all protocols, which points to a routing or policy issue.

Practice this question →
15
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 →
16
Multi-Selectmedium

An administrator is troubleshooting an IPsec VPN tunnel that is not establishing. The Phase 1 status shows 'down'. Which TWO commands can help diagnose the issue? (Choose TWO.)

Select 2 answers
A.diagnose npu np6 ipsec-sa list
B.diagnose sys session clear
C.diagnose debug application ike -1
D.diagnose vpn tunnel list
E.diagnose vpn ike log-filter
AnswersC, E

Enables IKE debugging at the highest level.

Why this answer

The 'diagnose debug application ike -1' command enables real-time IKE (Internet Key Exchange) debugging, which is essential for troubleshooting Phase 1 failures. This command captures IKEv1/v2 negotiation messages, including proposals, pre-shared key mismatches, and authentication errors, directly showing why the tunnel is down.

Exam trap

The trap here is that candidates often confuse 'diagnose vpn tunnel list' (which shows only the status) with a diagnostic tool that reveals the root cause, when in fact it provides no insight into the IKE negotiation process or error details.

Practice this question →
17
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

Mismatched encryption algorithms cause proposal mismatch.

Why this answer

The 'no acceptable proposal' error during IKE Phase 1 indicates a mismatch in the security proposal parameters that the two peers exchange to establish the SA. The encryption algorithm (e.g., AES256 vs AES128) and Diffie-Hellman group (e.g., group 14 vs group 2) are both part of the Phase 1 proposal; if either differs between peers, the negotiation fails and the status resets to 'init'.

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 →
18
MCQhard

You run 'diagnose sys session filter dport 443' and see the following output: proto=6 proto_state=01 duration=3600 expire=3599 What does this indicate?

A.The session is fully established and has been active for 3600 seconds.
B.The session is in SYN_SENT state and might be stuck due to no response from the server.
C.The session has been idle for 3599 seconds and will expire soon.
D.The session is in FIN_WAIT state and is being closed.
AnswerB

State 01 explicitly maps to TCP SYN_SENT, which means the firewall sent a SYN packet and is waiting for a SYN-ACK from the destination server. A duration of 3600 seconds with no state transition indicates the server has not responded, so the session is likely stuck in the initiation phase and will eventually time out unless the missing SYN-ACK appears.

Why this answer

The output shows `proto_state=01`, which in Fortinet's session table corresponds to the TCP SYN_SENT state (the session is waiting for a SYN-ACK from the server). The `duration=3600` indicates the session has existed for 3600 seconds, but the `expire=3599` shows it has not yet been confirmed as established. This combination indicates the session is stuck in the SYN_SENT state, likely because the server is not responding, making option B correct.

Exam trap

The trap here is that candidates confuse `duration` with idle time or assume `proto_state=01` means an established session, when in fact it specifically indicates the SYN_SENT phase of the TCP three-way handshake.

How to eliminate wrong answers

Option A is wrong because `proto_state=01` specifically indicates SYN_SENT, not an established session (which would show `proto_state=02` for ESTABLISHED). Option C is wrong because `expire=3599` is the remaining time before the session times out, not an idle time; the session has been active for 3600 seconds but is still in SYN_SENT, so it is not idle. Option D is wrong because FIN_WAIT states are represented by higher proto_state values (e.g., 04 or 05), not 01.

Practice this question →
19
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 →
20
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 rule defines who can access the application.

Why this answer

A ZTNA rule (policy) is essential to define the access conditions, such as user identity, device posture, and source IP, that must be met before granting access to the internal application. This policy enforces the zero-trust principle of 'never trust, always verify' by evaluating these conditions in real time.

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 →
21
MCQmedium

A FortiGate administrator is setting up a dial-up IPsec VPN for remote employees. Each employee uses a FortiClient. Which authentication method should be used to allow individual user identities?

A.Pre-shared key (PSK) for each user
B.Certificate-based authentication using local or CA-issued certificates
C.IKEv2 with EAP
D.Aggressive mode with PSK
AnswerB

Certificates provide unique identity per user and are scalable.

Why this answer

For dial-up IPsec VPNs where each remote user must be uniquely identified, certificate-based authentication (option B) is the correct method. Certificates bind a user's identity to a cryptographic key pair, allowing the FortiGate to authenticate each individual user independently, unlike a shared PSK which cannot distinguish between users.

Exam trap

The trap here is that candidates often confuse 'IKEv2 with EAP' (a transport for authentication) with a specific authentication method, but EAP itself is not a single method; the question asks for the method that provides individual identities, which is certificate-based authentication, not the protocol that carries it.

How to eliminate wrong answers

Option A is wrong because using a pre-shared key (PSK) for each user is not scalable and does not provide true individual identity verification; PSK authenticates the device or group, not the user, and managing many PSKs is impractical. Option C is wrong because IKEv2 with EAP is an authentication framework that can be used with various methods (e.g., EAP-MSCHAPv2, EAP-TLS), but the question asks for the method that allows individual user identities; certificate-based authentication is the specific mechanism that achieves this, while EAP itself is not a single authentication method. Option D is wrong because Aggressive mode with PSK is a legacy IKEv1 mode that is less secure (hashes identities in plaintext) and still uses a shared secret, not individual user identities.

Practice this question →
22
MCQeasy

Refer to the exhibit. A network administrator configured an IPsec VPN between the main office and a branch office. Remote users at the branch office report that they cannot access resources in the main office. The tunnel status shows up on both sides. What is the most likely cause of the connectivity issue?

A.The phase1 keylife is longer than the phase2 keylife, causing rekey issues.
B.The 'set net-device disable' prevents the tunnel from being used for routing.
C.The phase2 configuration does not specify the local and remote subnets to protect.
D.The phase2 proposal does not match the phase1 proposal.
AnswerC

Without 'set src-addr-type' and 'set dst-addr-type', the tunnel does not know which traffic to encrypt.

Why this answer

The phase2 configuration in an IPsec VPN must explicitly define the local and remote subnets (proxy IDs) that the tunnel is meant to protect. Without these subnets, the IPsec security associations (SAs) cannot be established for the actual traffic, even if the tunnel status shows as up (phase1 is complete). The tunnel status only indicates that IKE phase1 negotiation succeeded, but without phase2 proxy IDs, no traffic will be encrypted or routed through the tunnel, causing connectivity failures.

Exam trap

The trap here is that candidates assume a tunnel status of 'up' means the VPN is fully functional, but in reality, phase1 success alone does not guarantee that phase2 has been negotiated with the correct proxy IDs, and traffic will still fail without proper subnet definitions.

How to eliminate wrong answers

Option A is wrong because phase1 keylife being longer than phase2 keylife is not inherently problematic; phase2 keylife is typically shorter and rekey events are independent, so this does not prevent traffic flow. Option B is wrong because 'set net-device disable' is a FortiGate command that disables the virtual IPsec interface, which would prevent the tunnel from being used for routing, but the exhibit (not shown) does not indicate this command is present, and the tunnel status shows up, which would not be possible if net-device were disabled. Option D is wrong because phase2 proposals do not need to match phase1 proposals; phase1 and phase2 are separate negotiation phases with different parameters (encryption, authentication, DH groups) and mismatches between them do not cause phase2 to fail as long as each phase's proposals are consistent within themselves.

Practice this question →
23
Multi-Selectmedium

An administrator is configuring a dial-up IPsec VPN for remote users. Which TWO settings are required on the FortiGate for the dial-up server? (Choose two.)

Select 2 answers
A.Set 'mode-cfg' to enable on Phase 1
B.Set 'peer type' to 'any' on Phase 1
C.Set 'aggressive mode' on Phase 1
D.Set 'auto-negotiate' to enable on Phase 2
E.Set 'pfs' to enable on Phase 2
AnswersA, B

Mode-config is used to assign IP addresses to clients.

Why this answer

'mode-cfg' (Mode Config) enables the FortiGate to assign IP addresses and other network settings to remote VPN clients dynamically, which is essential for a dial-up IPsec VPN server. Option B is correct because setting 'peer type' to 'any' allows the FortiGate to accept connections from any remote peer without predefining a specific peer IP, which is required for a dial-up scenario where remote users have dynamic IP addresses.

Exam trap

The trap here is that candidates often confuse 'aggressive mode' as a requirement for dial-up VPNs because it is commonly used with pre-shared keys and dynamic peers, but FortiGate does not require it; the mandatory settings are mode-cfg and peer type any.

Practice this question →
24
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 →
25
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 →
26
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 →
27
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

Correct: route-based has a tunnel interface; policy-based defines selectors in Phase 2.

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 →
28
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 →
29
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

This defines the connection to the RADIUS server.

Why this answer

A RADIUS server object defines the IP address and shared secret that the FortiGate uses to communicate with the RADIUS server for authentication requests. Option D is correct because a user group must reference the RADIUS server to map authenticated users to policies; without this group, the FortiGate cannot apply firewall rules based on RADIUS authentication.

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 →
30
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 →
31
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

Tunnel mode supports all IP traffic, not just web, by creating a virtual network interface.

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 →
32
MCQhard

An administrator has configured an SSL VPN with tunnel mode and split tunneling enabled. However, remote users report that all internet traffic is going through the VPN tunnel. What is the MOST likely cause?

A.The firewall policy allows traffic to the internet
B.The SSL VPN portal has 'split tunneling' disabled
C.The client's routing table is set to route all traffic through the VPN
D.The user has installed a root certificate
AnswerC

Even with split tunneling enabled on the portal, if the client pushes a route for 0.0.0.0/0, all traffic goes through the tunnel.

Why this answer

When split tunneling is enabled on the FortiGate SSL VPN portal, the FortiClient VPN software should only route traffic destined for the corporate network through the tunnel. If remote users report that all internet traffic is going through the VPN tunnel, the most likely cause is that the client's routing table has been configured to route all traffic (0.0.0.0/0) through the virtual adapter, overriding the split-tunneling rules. This can happen if the client is set to 'Route all traffic through VPN' in its settings, which forces a default route into the VPN interface regardless of the portal configuration.

Exam trap

The trap here is that candidates often assume the portal's split-tunneling setting is the sole control, but the client-side configuration can override it, making option B seem correct when the real issue is the client's routing table.

How to eliminate wrong answers

Option A is wrong because a firewall policy allowing traffic to the internet is necessary for internet access, but it does not cause traffic to be forced through the VPN tunnel; it only permits the traffic once it reaches the FortiGate. Option B is wrong because the question states that split tunneling is enabled on the SSL VPN portal; if it were disabled, the behavior would be expected, but the scenario explicitly says it is enabled. Option D is wrong because installing a root certificate is used for certificate-based authentication or to trust the FortiGate's certificate, not to alter routing decisions for VPN traffic.

Practice this question →
33
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

This is the core function of the FSSO collector agent.

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 →
34
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 uses proxy-based inspection to apply access rules.

Why this answer

ZTNA on FortiGate requires a proxy-based firewall policy to intercept and inspect application-layer traffic. This policy type enables the FortiGate to act as a reverse proxy, terminating TLS connections and enforcing access control based on user identity and device posture before forwarding traffic to the internal application.

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 →
35
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

Captive portal intercepts HTTP traffic and redirects to a login page.

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 →
36
Multi-Selectmedium

A company requires two-factor authentication for SSL VPN access. They already have an LDAP server for user credentials. Which TWO components are necessary to implement this?

Select 2 answers
A.FortiAuthenticator
B.FortiToken hardware or mobile tokens
C.RADIUS server
D.Certificate Authority (CA)
E.LDAP server
AnswersB, E

FortiToken provides the one-time password (OTP) required for two-factor authentication.

Why this answer

FortiToken hardware or mobile tokens provide the second factor (something you have) required for two-factor authentication. The LDAP server supplies the first factor (something you know) via user credentials. Together, they satisfy the two-factor requirement for SSL VPN access on FortiGate.

Exam trap

The trap here is that candidates often assume a RADIUS server or FortiAuthenticator is mandatory for two-factor authentication, but FortiGate can directly integrate LDAP with FortiToken without intermediate servers.

Practice this question →
37
MCQmedium

A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. Phase 1 is up, but Phase 2 fails to establish. The debug command 'diagnose vpn ike log' shows: 'no suitable proposal found'. What is the most likely cause?

A.Phase 2 encryption or authentication algorithms do not match on both sides.
B.The firewall policy allowing IPsec traffic is missing.
C.The remote gateway IP address is unreachable.
D.The pre-shared key is incorrect.
AnswerA

Phase 2 (Quick Mode) negotiates the IPsec SA parameters, including the encryption algorithm (e.g., AES-256, 3DES) and authentication algorithm (e.g., SHA-1, SHA-256) for the ESP/AH protocol. If the local and remote firewalls do not offer a common proposal for these algorithms and the Diffie-Hellman group, the Phase 2 negotiation will fail with an error such as 'no proposal chosen.' Since Phase 1 has already formed a secure IKE SA, the problem isolates specifically to a Phase 2 proposal mismatch, preventing the tunnel from establishing even though both gateways are reachable and authenticated.

Why this answer

The 'no suitable proposal found' error in Phase 2 of an IPsec VPN tunnel indicates that the Phase 2 parameters (encryption algorithm, authentication algorithm, or PFS settings) do not match between the two FortiGate peers. Since Phase 1 is up, the IKE SA is established, meaning pre-shared keys, remote gateway reachability, and basic firewall policies for IKE traffic are correct. The mismatch specifically occurs in the Phase 2 proposal negotiation, where each side sends its supported transforms and the responder cannot find a common set.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 proposal errors, assuming any 'no suitable proposal found' message relates to Phase 1, but the context of Phase 1 being up explicitly isolates the issue to Phase 2 parameter mismatch.

How to eliminate wrong answers

Option B is wrong because a missing firewall policy for IPsec traffic would prevent Phase 1 from establishing, as IKE packets (UDP 500/4500) would be dropped; Phase 1 being up confirms the firewall policy is in place. Option C is wrong because if the remote gateway IP address were unreachable, Phase 1 would fail to initiate or complete, as IKE negotiation requires bidirectional reachability. Option D is wrong because an incorrect pre-shared key would cause Phase 1 authentication to fail, resulting in a 'no suitable proposal found' error at Phase 1, not Phase 2; Phase 1 being up confirms the pre-shared key is correct.

Practice this question →
38
MCQmedium

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

A.The IKE version is not compatible
B.The Phase 2 selectors (local and remote subnets) are misconfigured
C.The Phase 2 encryption and authentication algorithms do not match
D.The pre-shared keys do not match
AnswerC

The correct interpretation of the 'proposal mismatch' error is that the Phase 2 encryption and authentication algorithms, or other transform parameters like the PFS Diffie-Hellman group, differ between the two FortiGates. During IKE Phase 2, the initiator sends a list of SA proposals containing encryption algorithms (e.g., AES128/256), integrity algorithms (e.g., SHA1/256), and optionally DH groups for PFS. If none of the responder's configured Phase 2 proposals match any of the initiator's proposals, the responder sends the 'no proposal chosen' or 'proposal mismatch' notification. To resolve this, the Phase 2 transform sets (encryption, authentication, and PFS) must be aligned on both endpoints.

Why this answer

The error 'proposal mismatch' in the 'diagnose vpn ike log' output specifically indicates that the Phase 2 parameters (encryption, authentication, or DH group) do not match between the two FortiGate peers. Since Phase 1 completed successfully, the IKE version (IKEv2) and pre-shared keys are already validated, leaving only the Phase 2 proposal as the cause. Option C correctly identifies that the encryption and authentication algorithms are mismatched, which is the most common reason for this error.

Exam trap

The trap here is that candidates often confuse 'proposal mismatch' with Phase 1 issues or selector mismatches, but the error is specific to cryptographic algorithm negotiation in Phase 2, not to network-layer subnet definitions or authentication credentials.

How to eliminate wrong answers

Option A is wrong because Phase 1 completed successfully, which confirms that both peers are using a compatible IKE version (IKEv2 in this scenario). Option B is wrong because a 'proposal mismatch' error is related to cryptographic parameters, not to the local/remote subnet selectors; a misconfiguration of selectors would typically result in a 'no matching selector' or 'traffic selector mismatch' error, not 'proposal mismatch'. Option D is wrong because pre-shared keys are negotiated during Phase 1 authentication; since Phase 1 succeeded, the PSKs must match, so a PSK mismatch would have prevented Phase 1 from completing.

Practice this question →
39
MCQmedium

What is the primary advantage of using IKEv2 over IKEv1 for IPsec VPN?

A.IKEv2 has built-in support for NAT traversal and MOBIKE
B.IKEv2 supports only main mode
C.IKEv2 requires aggressive mode
D.IKEv2 is only for route-based VPN
AnswerA

IKEv2 includes NAT-T and MOBIKE as standard.

Why this answer

IKEv2 offers built-in NAT traversal (NAT-T) and MOBIKE (RFC 4555) as core features, not optional extensions. This eliminates the need for separate RFC 3947 NAT-T configuration and allows seamless IP address changes during a VPN session, making it far more robust for mobile users and dynamic environments compared to IKEv1.

Exam trap

The trap here is that candidates often confuse IKEv2's single exchange with 'main mode only' or think it requires aggressive mode, when in fact IKEv2 eliminates both modes and uses a more efficient, secure handshake.

How to eliminate wrong answers

Option B is wrong because IKEv2 does not support only main mode; it uses a single, streamlined exchange (two pairs of messages) that replaces both main and aggressive modes from IKEv1. Option C is wrong because IKEv2 does not require aggressive mode; aggressive mode is an IKEv1 concept that IKEv2 eliminates entirely for security reasons. Option D is wrong because IKEv2 is not limited to route-based VPNs; it supports both policy-based and route-based IPsec VPN configurations in FortiOS.

Practice this question →
40
MCQmedium

A network administrator configures an IPsec VPN between two FortiGates using IKEv1 main mode. The Phase 1 negotiation fails with the error 'no proposal chosen'. The administrator checks both sides and confirms the IKE version, encryption algorithm (AES256), authentication (SHA256), and Diffie-Hellman group (14) match. Which additional parameter is MOST likely mismatched?

A.Pre-shared key
B.IKE version (IKEv2)
C.Phase 2 encryption algorithm
D.Local and remote identifiers (local ID / remote ID)
AnswerD

In main mode, identifiers are exchanged. A mismatch of local or remote ID can cause 'no proposal chosen'.

Why this answer

In IKEv1 main mode, the Phase 1 negotiation includes an exchange of identity (ID) payloads after the Diffie-Hellman exchange. If the local or remote identifiers (local ID / remote ID) do not match what is expected on the peer, the FortiGate will reject the proposal with a 'no proposal chosen' error, even if all other Phase 1 parameters (encryption, authentication, DH group, IKE version) are identical. The pre-shared key is verified later in Phase 1 (during authentication), so a mismatch there would cause a different error (e.g., 'authentication failed'), not 'no proposal chosen'.

Exam trap

The trap here is that candidates assume 'no proposal chosen' always means a cryptographic parameter mismatch (encryption, hash, DH group), but FortiGate (and other vendors) can also return this error when the identity payload does not match the expected peer ID, especially in IKEv1 main mode where identity is exchanged after the proposal is accepted.

How to eliminate wrong answers

Option A is wrong because the pre-shared key is not checked during the proposal exchange; it is used in the authentication phase (Main Mode messages 5 and 6) and a mismatch would result in an 'authentication failed' error, not 'no proposal chosen'. Option B is wrong because the administrator confirmed both sides use IKEv1, and if one side were using IKEv2, the error would typically be 'no acceptable proposal' or a version mismatch, but the question explicitly states IKEv1 is used on both sides. Option C is wrong because Phase 2 parameters (encryption algorithm, etc.) are negotiated after Phase 1 completes; a Phase 2 mismatch would cause a Phase 2 failure (e.g., 'no proposal chosen' during Phase 2), not a Phase 1 failure.

Practice this question →
41
MCQmedium

An administrator configures a route-based IPsec VPN between two FortiGates. The Phase 1 and Phase 2 are up. The administrator adds a static route on each FortiGate pointing to the remote subnet via the virtual tunnel interface (e.g., 'to_remote'). Traffic between the subnets fails. What is the MOST likely missing configuration?

A.NAT must be disabled on the tunnel interface
B.The tunnel interface must be added to a zone
C.The Phase 2 proposal must include the correct local and remote subnets
D.A firewall policy is required to permit traffic between the interfaces
AnswerD

Route-based VPNs require explicit firewall policies to allow traffic through the tunnel.

Why this answer

In a route-based IPsec VPN, even when Phase 1 and Phase 2 are up and a static route exists via the virtual tunnel interface, traffic will still be dropped unless a firewall policy explicitly permits it. FortiGate uses a stateful firewall, so a policy must allow traffic from the local interface to the tunnel interface (or vice versa) to forward packets. Without this policy, the FortiGate will not forward traffic between the subnets, even though the tunnel is established.

Exam trap

The trap here is that candidates assume a static route and an established IPsec tunnel are sufficient for traffic flow, overlooking the mandatory firewall policy that FortiGate requires to permit inter-subnet traffic in a route-based VPN.

How to eliminate wrong answers

Option A is wrong because NAT is not required to be disabled on the tunnel interface for route-based VPNs; NAT is typically disabled automatically for IPsec traffic, and disabling it manually is not the missing configuration. Option B is wrong because adding the tunnel interface to a zone is optional and used for grouping interfaces for policy application, but it is not a prerequisite for traffic flow; a firewall policy can be applied directly to the interface without a zone. Option C is wrong because the Phase 2 proposal includes the correct local and remote subnets (0.0.0.0/0 for route-based VPNs), and the question states Phase 2 is up, indicating the proposal is correctly configured; the issue is not with Phase 2 parameters.

Practice this question →
42
Multi-Selectmedium

A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. The tunnel is established, but traffic is not passing. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. Which two additional diagnostics should the administrator run to isolate the issue?

Select 2 answers
A.diagnose sys session filter and diagnose sys session list
B.diagnose hardware sysinfo memory
C.diagnose debug application ike -1
D.diagnose netlink interface list
E.execute ping-options source and execute ping
AnswersA, C

This allows checking if sessions are being created and whether they match the expected policy.

Why this answer

'diagnose sys session filter' allows you to set filters (e.g., by source/destination IP or port) and 'diagnose sys session list' then displays the current session table entries matching those filters. Since the IPsec tunnel is up but traffic is not passing, the session table may show that traffic is being dropped or not matching the expected policies, helping isolate whether the issue is with policy routing, firewall rules, or session setup. Option C is also correct because 'diagnose debug application ike -1' enables detailed IKE debugging that can reveal post-establishment issues, such as rekey failures, phase 2 problems, or IPsec SA mismatches, which may not be apparent from the tunnel list alone.

Both diagnostics are appropriate: A checks the data plane (session table), and C checks the control plane (IKE negotiation details).

Exam trap

A common pitfall is to assume that 'diagnose debug application ike -1' is only useful during initial tunnel negotiation and not after the tunnel is up. In reality, this debug can be invaluable for troubleshooting issues like phase 2 rekey failures, SA mismatches, or traffic selector problems that occur after the tunnel is established. Another trap is to overlook the session table diagnostics (Option A), which directly show whether expected traffic is hitting the firewall policies and whether sessions are being created or dropped.

Both tools are needed for a complete analysis.

Practice this question →
43
MCQeasy

Which IPsec VPN mode is typically used when the VPN peer has a dynamic public IP address?

A.Quick mode
B.IKEv2
C.Aggressive mode
D.Main mode
AnswerC

Correct. Aggressive mode is used for peers with dynamic IPs because it can authenticate without prior IP knowledge.

Why this answer

Aggressive mode is used in IPsec IKE phase 1 when the VPN peer has a dynamic public IP address because it allows the initiator to send its identity and authentication data in the first packet, enabling the responder to identify the peer without requiring a reverse DNS lookup or static IP. This mode reduces the number of exchanges from six (Main mode) to three, which is essential when the peer's IP address is not known in advance, as in many remote-access or dynamic-IP site-to-site scenarios.

Exam trap

The trap here is that candidates confuse 'Aggressive mode' with 'IKEv2' or 'Quick mode,' thinking that IKEv2 inherently solves dynamic IP issues, but the exam specifically tests the phase 1 mode (Aggressive vs. Main) for dynamic IP scenarios, not the protocol version.

How to eliminate wrong answers

Option A is wrong because Quick mode is an IKE phase 2 exchange that negotiates IPsec security associations (SAs) for data traffic, not a phase 1 mode used to handle dynamic IP addresses. Option B is wrong because IKEv2 is a protocol version, not a mode; while IKEv2 can handle dynamic IPs through its built-in mechanisms (e.g., using cookies and initiator/responder cookies), the question specifically asks for a 'mode' used in IPsec VPN, and Aggressive mode is the correct phase 1 mode for dynamic IP peers. Option D is wrong because Main mode requires the IP address of the peer to be known beforehand, as it uses six exchanges and relies on the IP address for identity verification; it cannot be used when the peer has a dynamic public IP.

Practice this question →
44
MCQmedium

A network administrator has configured an IPsec VPN between two FortiGate devices. The Phase 1 proposal includes AES256-SHA256-DH14. The Phase 2 proposal includes AES128-SHA1. The VPN tunnel fails to establish. Which of the following is the MOST likely cause?

A.The Phase 1 proposal is too strong and the remote FortiGate does not support DH14
B.The Phase 2 proposal does not match between the two devices
C.The VPN policy has not been configured on the remote FortiGate
D.The pre-shared key is incorrect
AnswerB

Phase 2 parameters must be identical on both sides. One side may have AES256 or a different lifetime, causing mismatch.

Why this answer

The Phase 2 proposal must match exactly between both VPN endpoints for IPsec to establish. Here, the local device uses AES128-SHA1, but the remote device likely expects a different combination (e.g., AES256-SHA256 or another algorithm), causing the IKE negotiation to fail after Phase 1 completes. Even though Phase 1 succeeded with AES256-SHA256-DH14, the mismatch in Phase 2 prevents the IPsec SA from being created.

Exam trap

The trap here is that candidates assume Phase 1 and Phase 2 proposals must be identical in strength or that a strong Phase 1 automatically implies a strong Phase 2, but NSE4 tests that Phase 2 proposals are independently negotiated and must match exactly between peers.

How to eliminate wrong answers

Option A is wrong because DH14 is a widely supported Diffie-Hellman group, and if the remote FortiGate did not support it, Phase 1 would fail immediately—not Phase 2. Option C is wrong because a missing VPN policy would cause traffic to be dropped, but the IKE negotiation itself would still proceed and fail at a later stage, not specifically at Phase 2 proposal mismatch. Option D is wrong because an incorrect pre-shared key would cause Phase 1 authentication to fail, preventing any further negotiation, not a Phase 2 mismatch.

Practice this question →
45
MCQmedium

A FortiGate admin is configuring a dial-up IPsec VPN for remote users. The users have dynamic IP addresses. Which Phase 1 configuration is appropriate?

A.Set the remote gateway to 'Dialup User' and enable an IP pool
B.Disable XAuth authentication
C.Set the remote gateway to the user's IP address
D.Use aggressive mode with a group pre-shared key
AnswerA

This allows any remote user to connect and get an IP from the pool.

Why this answer

For dial-up IPsec VPNs where remote users have dynamic IP addresses, the FortiGate cannot know the remote gateway IP in advance. Setting the remote gateway to 'Dialup User' allows the FortiGate to accept connections from any IP, and enabling an IP pool assigns a static internal IP to the remote user for routing and policy enforcement.

Exam trap

The trap here is that candidates often confuse 'Dialup User' with a static remote gateway setting, or they mistakenly think aggressive mode is required for dynamic IPs, when in fact FortiGate dial-up VPNs use main mode by default and the 'Dialup User' option handles dynamic peers transparently.

How to eliminate wrong answers

Option B is wrong because disabling XAuth authentication would remove user-level authentication, which is typically required for dial-up VPNs to identify and authorize remote users. Option C is wrong because setting the remote gateway to the user's IP address is impossible when the user has a dynamic IP that changes each connection. Option D is wrong because aggressive mode with a group pre-shared key is less secure (sends identity in cleartext) and is not the appropriate Phase 1 configuration for dial-up users; FortiGate dial-up VPNs typically use main mode with certificates or EAP.

Practice this question →
46
MCQmedium

A FortiGate is configured with FSSO for firewall authentication. Users report they are prompted for credentials every time they access the internet, even though they are logged into the domain. What is the most likely cause?

A.The users are not members of the FSSO group.
B.The firewall policy uses 'All Users' instead of a specific group.
C.The FSSO collector agent service is not running.
D.The FortiGate's LDAP server is unreachable.
AnswerC

The FSSO collector agent is the critical component that gathers logon events from Active Directory (either through NetAPI polling or by reading Windows security event logs) and forwards them to the FortiGate. If the collector agent service is stopped or not running, the FortiGate has no source of domain user logon information, so it treats all traffic as unauthenticated and triggers local firewall authentication prompts. This is the most direct cause of the symptom described, because the entire FSSO identity pipeline is broken.

Why this answer

If the FSSO collector agent service is not running, the FortiGate cannot receive the logon events from the domain controllers. Without these events, the FortiGate has no way to know which users are authenticated, so it falls back to prompting for credentials on every new session, even though users are already logged into the domain.

Exam trap

The trap here is that candidates often confuse FSSO with LDAP authentication, assuming an LDAP connectivity issue is the cause, when in fact FSSO relies on a separate collector agent and domain controller event polling, not direct LDAP queries.

How to eliminate wrong answers

Option A is wrong because users not being members of the FSSO group would cause them to be denied access or not matched to the policy, not repeatedly prompted for credentials. Option B is wrong because using 'All Users' in the firewall policy would actually bypass FSSO authentication entirely, allowing traffic without any credential prompt. Option D is wrong because the FortiGate's LDAP server being unreachable affects LDAP-based authentication or directory lookups, not the FSSO polling mechanism which relies on the collector agent and domain controller events, not direct LDAP queries.

Practice this question →
47
MCQeasy

An administrator wants to use Active Directory credentials to authenticate firewall administrators. Which authentication server type should be configured on the FortiGate?

A.TACACS+
B.FSSO
C.LDAP
D.RADIUS
AnswerC

LDAP is the protocol used to query Active Directory for authentication and user attributes.

Why this answer

LDAP (Lightweight Directory Access Protocol) is the correct choice because it directly integrates with Microsoft Active Directory to authenticate firewall administrators using their existing AD credentials. FortiGate can bind to an LDAP server to verify username and password pairs, making it the native protocol for AD authentication without requiring additional services or translation layers.

Exam trap

The trap here is that candidates often confuse FSSO (used for transparent network authentication) with direct admin authentication, or assume RADIUS is the only way to integrate with AD, but FortiGate's native LDAP support is the simplest and most direct method for admin authentication against Active Directory.

How to eliminate wrong answers

Option A is wrong because TACACS+ is a Cisco-proprietary protocol that separates authentication, authorization, and accounting (AAA) and is not natively used by Active Directory; it requires a separate TACACS+ server to bridge to AD. Option B is wrong because FSSO (Fortinet Single Sign-On) is designed for transparent user identification on the network, not for authenticating firewall administrators; it polls AD for login events but does not perform direct password validation. Option D is wrong because RADIUS is a generic AAA protocol that can authenticate against AD only if a RADIUS server (like NPS) is configured as an intermediary; it is not a direct AD authentication method and adds unnecessary complexity for admin authentication.

Practice this question →
48
MCQhard

You run the command 'diagnose vpn ike log filter name vpn1' and then 'diagnose vpn ike log filter type phase1'. The log shows: 'IKEv1 exchange:f4470f07:00000000: responder: main mode: received IKE_SA_INIT (aggressive mode not allowed)'. What is the problem?

A.The initiator is using IKEv2 while the responder uses IKEv1
B.The responder is configured for main mode only, but the initiator is sending aggressive mode
C.The pre-shared key is wrong
D.The phase1 proposal is incompatible
AnswerB

In IKEv1, an aggressive-mode initiator sends its SA proposal, key-exchange material, nonce, and identity in a single packet, while a main-mode-only responder expects the two-round-trip Main Mode sequence (SA exchange first, then KE/nonce). When the responder's phase 1 configuration is set to 'main mode only,' it immediately discards the incoming aggressive-mode packet and logs a mode mismatch such as 'aggressive mode is not supported.' This rejection occurs before any proposal comparison or PSK authentication, so the log indicates a configuration mismatch rather than a cryptographic or proposal failure.

Why this answer

The log message 'aggressive mode not allowed' indicates the responder (FortiGate) is configured to accept only main mode IKE phase1 negotiations, but the initiator sent an aggressive mode request. This mismatch causes the responder to reject the IKE_SA_INIT message, as aggressive mode is disabled by default or explicitly set to main mode only in the phase1 configuration.

Exam trap

The trap here is that candidates may confuse the 'aggressive mode not allowed' message with a proposal mismatch or authentication failure, but the log explicitly states the mode is the issue, not the cryptographic parameters or keys.

How to eliminate wrong answers

Option A is wrong because the log explicitly shows 'IKEv1 exchange', so both sides are using IKEv1, not IKEv2. Option C is wrong because a pre-shared key mismatch would cause a different error, such as 'invalid payload' or 'authentication failed', not a mode rejection message. Option D is wrong because an incompatible phase1 proposal would generate a 'no acceptable proposal' or 'proposal mismatch' error, not a message about aggressive mode not being allowed.

Practice this question →
49
MCQhard

A FortiGate administrator runs 'diagnose vpn tunnel list' and sees the following output for an IPsec tunnel: 'status: up', 'incoming: 0 packets', 'outgoing: 100 packets'. Phase 1 and Phase 2 both show state 'up'. What is the MOST likely cause of zero incoming packets?

A.The remote gateway is using aggressive mode
B.The FortiGate has a static route pointing to the VPN interface
C.The VPN is configured in policy-based mode
D.The Phase 2 proposal includes a mismatched proxy ID
AnswerD

During Phase 2 negotiation, both peers exchange proxy IDs (traffic selectors) that define which source and destination subnets are encrypted. If the local proxy ID does not exactly match the remote peer's expected subnets, the IPsec SA is established with mismatched selectors. The remote gateway may then drop incoming packets that fall outside its configured selectors, or it may not respond at all, causing the tunnel to appear up but traffic to fail in one or both directions.

Why this answer

The output shows the VPN tunnel is up with outgoing packets but zero incoming packets. This indicates a Phase 2 mismatch, most commonly due to mismatched proxy IDs (local/remote subnets). When proxy IDs do not match between peers, the tunnel establishes but traffic is not correctly matched, causing the remote gateway to drop or not send traffic to the FortiGate, resulting in zero incoming packets.

Exam trap

The trap here is that candidates see 'status: up' and assume the tunnel is fully functional, overlooking that Phase 2 proxy ID mismatches can leave the tunnel up but unable to pass traffic in one direction.

How to eliminate wrong answers

Option A is wrong because aggressive mode affects Phase 1 authentication (using fewer exchanges and sending the ID in plaintext) but does not cause zero incoming packets once the tunnel is up; it would prevent Phase 1 from completing if mismatched. Option B is wrong because a static route pointing to the VPN interface is necessary for routing traffic into the tunnel; its presence would not cause zero incoming packets—it would actually help traffic flow. Option C is wrong because policy-based mode (vs. route-based) does not inherently cause zero incoming packets; both modes can work correctly if proxy IDs match.

The issue is specifically a Phase 2 proxy ID mismatch, which prevents the remote peer from associating incoming traffic with the correct SA.

Practice this question →
50
MCQhard

You run the CLI command 'diagnose vpn ike gateway list' and see that an IPsec VPN gateway is in 'up' state with 'initiator' mode, but no Phase 2 selectors are established. What is the most likely cause?

A.The Phase 2 proposal parameters (encryption, authentication) do not match between peers
B.The remote gateway is not responding to IKE packets
C.The local and remote Phase 2 selectors (proxy IDs) do not match
D.The IPsec interface is down
AnswerC

Mismatched proxy IDs prevent Phase 2 negotiation from completing successfully. The Phase 1 can be up but Phase 2 fails to establish.

Why this answer

When an IPsec VPN gateway is in 'up' state with 'initiator' mode but no Phase 2 selectors are established, it indicates that IKE Phase 1 (main mode or aggressive mode) has completed successfully, but Phase 2 (quick mode) negotiation has failed. The most common cause for Phase 2 failure is a mismatch in the Phase 2 selectors (proxy IDs), which define the local and remote subnets to be encrypted. FortiGate uses these selectors to match traffic and establish the IPsec SA; if they do not align between peers, the Phase 2 negotiation will not complete.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 failures, assuming an 'up' gateway means the entire VPN is working, but the 'initiator' mode and lack of Phase 2 selectors specifically point to a proxy ID mismatch rather than a proposal or connectivity issue.

How to eliminate wrong answers

Option A is wrong because Phase 2 proposal parameter mismatches (encryption, authentication) would typically cause a Phase 2 failure, but the question specifically states 'no Phase 2 selectors are established,' and the gateway is in 'up' state, meaning Phase 1 succeeded; Phase 2 proposal mismatches are a different issue that would still show Phase 2 negotiation attempts. Option B is wrong because if the remote gateway were not responding to IKE packets, the gateway would not reach an 'up' state in Phase 1; the 'up' state confirms that IKE Phase 1 completed, so the remote gateway is responding. Option D is wrong because the IPsec interface being down would prevent the gateway from reaching an 'up' state at all; the gateway status would show 'down' or the interface would be administratively down, not 'up' with no Phase 2 selectors.

Practice this question →
51
MCQeasy

A FortiGate administrator wants to authenticate VPN users against an existing LDAP server. The administrator creates an LDAP user group on the FortiGate. What additional configuration is REQUIRED to use this group for IPsec VPN authentication?

A.In the IPsec Phase 1 configuration, set the peer type to 'dialup' and specify the user group under authentication
B.Enable LDAP over TLS (LDAPS) on the FortiGate
C.Assign the LDAP user group to a firewall policy
D.Configure a RADIUS server as an intermediate proxy between FortiGate and LDAP
AnswerA

For dial-up IPsec VPN, the Phase 1 configuration must include the user group to authenticate users against LDAP.

Why this answer

For IPsec VPN authentication, the FortiGate must know which users are allowed to connect. Setting the peer type to 'dialup' in Phase 1 enables the FortiGate to accept connections from remote users rather than another gateway. Specifying the LDAP user group under authentication tells the FortiGate to validate the VPN user's credentials against that group's members, which are resolved via the LDAP server.

Without this configuration, the FortiGate has no way to associate the LDAP group with the VPN tunnel.

Exam trap

The trap here is that candidates often confuse the authentication configuration (Phase 1) with the authorization configuration (firewall policies), leading them to select Option C, thinking that assigning the group to a policy is sufficient for VPN authentication.

How to eliminate wrong answers

Option B is wrong because LDAPS (LDAP over TLS) is a transport security measure for the LDAP connection, but it is not required for IPsec VPN authentication; the FortiGate can authenticate using plain LDAP or LDAPS, and the question asks for what is required. Option C is wrong because firewall policies control traffic flow after authentication, not the authentication process itself; assigning the LDAP user group to a firewall policy is needed for authorization and access control, but it does not enable the VPN to authenticate users. Option D is wrong because a RADIUS server is not required; the FortiGate can directly query the LDAP server for authentication without an intermediate proxy, and using RADIUS would be an additional, optional configuration.

Practice this question →
52
MCQmedium

A network administrator wants to implement two-factor authentication for SSL VPN users using FortiToken. The users are already authenticated against an LDAP server. Which configuration step is required to enforce two-factor authentication?

A.Create a local user with the same username as the LDAP user and assign a FortiToken to that local user
B.Create a user group that uses LDAP as the authentication server and enable FortiToken two-factor authentication in the group settings
C.Configure the SSL VPN portal to require FortiToken and set the authentication server to LDAP
D.Set the SSL VPN authentication method to 'certificate' and use FortiToken as second factor
AnswerB

Correct. The user group authenticates against LDAP and then requires a FortiToken for two-factor.

Why this answer

FortiGate requires a user group to combine LDAP authentication with FortiToken two-factor authentication. By creating a user group that uses LDAP as the authentication server and enabling FortiToken in the group settings, the FortiGate will first authenticate the user against LDAP and then prompt for a FortiToken code as the second factor. This is the standard method to enforce two-factor authentication for SSL VPN users without creating duplicate local users.

Exam trap

The trap here is that candidates often think two-factor authentication can be enabled directly on the SSL VPN portal or by creating a local user with a token, but FortiGate requires the token to be associated with a user group that references the external authentication server.

How to eliminate wrong answers

Option A is wrong because creating a local user with the same username as the LDAP user and assigning a FortiToken to that local user would require the user to authenticate against the local database, not LDAP, which defeats the purpose of using LDAP as the primary authentication source. Option C is wrong because configuring the SSL VPN portal to require FortiToken and setting the authentication server to LDAP does not actually enable two-factor authentication; the portal settings only control the user experience, not the authentication method itself. Option D is wrong because setting the SSL VPN authentication method to 'certificate' changes the primary authentication to certificate-based, and FortiToken cannot be used as a second factor in that context; certificate authentication and FortiToken are separate mechanisms.

Practice this question →
53
MCQhard

An administrator configures FSSO (Fortinet Single Sign-On) with Active Directory polling. Users report that their web traffic is being blocked by the firewall even though they are logged into the domain. Which CLI command can the administrator use to verify the FSSO login status for a specific user?

A.diagnose user fsso poll user <username>
B.diagnose wad user list
C.diagnose debug authd fsso list
D.diagnose test authserver ldap <server> <username>
AnswerC

Correct. This command lists all FSSO users with their IP addresses and group memberships.

Why this answer

The command 'diagnose debug authd fsso list' displays the current FSSO login status for all users, including the Fortinet Single Sign-On (FSSO) session information such as username, IP address, and group membership. This command queries the authentication daemon (authd) which maintains the FSSO user database, allowing the administrator to verify if a specific user is authenticated and which firewall policies apply. It directly addresses the scenario where users are logged into the domain but web traffic is blocked, as it confirms whether the FSSO polling has successfully registered the user's login.

Exam trap

The trap here is that candidates confuse FSSO verification commands with LDAP authentication test commands or proxy user lists, leading them to choose options that test different authentication mechanisms (LDAP or WAD) rather than the FSSO-specific authd database.

How to eliminate wrong answers

Option A is wrong because 'diagnose user fsso poll user <username>' is not a valid CLI command; the correct syntax for polling a specific user is 'diagnose user fsso poll-user <username>' (with a hyphen), and even then it only triggers a one-time poll from the collector agent, not a verification of current login status. Option B is wrong because 'diagnose wad user list' displays users authenticated by the web application daemon (WAD) for explicit proxy or web cache, not FSSO domain users; it is irrelevant for verifying Active Directory polling-based FSSO. Option D is wrong because 'diagnose test authserver ldap <server> <username>' tests LDAP authentication against an LDAP server, which is used for direct LDAP authentication, not for FSSO polling; FSSO relies on domain controller event logs or polling, not LDAP binds.

Practice this question →
54
MCQeasy

An administrator wants to restrict SSL VPN access to only users who have a valid client certificate issued by the company's internal CA. Which setting should be configured?

A.Configure a firewall policy with identity-based authentication
B.Enable 'certificate-based authentication' in the user group
C.Enable 'require client certificate' in the SSL VPN settings
D.Import the users' public keys into the FortiGate
AnswerC

Setting 'Require Client Certificate' in the SSL VPN settings makes the FortiGate demand a client certificate during the SSL/TLS handshake, and only a certificate signed by a configured trusted CA will be accepted. This ensures that every SSL VPN session is cryptographically tied to a credential that is bound to a specific US user, so users without a valid certificate cannot even initiate the handshake. This is the direct control that physically enforces certificate-based access.

Why this answer

The 'require client certificate' setting in the SSL VPN portal or interface configuration enforces mutual TLS (mTLS), where the FortiGate requests and validates a client certificate against the configured CA. This ensures that only users presenting a valid certificate issued by the company's internal CA can establish the SSL VPN tunnel, regardless of their authentication credentials.

Exam trap

The trap here is that candidates confuse 'certificate-based authentication' with a user group setting, when in fact the enforcement point is the SSL VPN portal or interface configuration, not the user group definition.

How to eliminate wrong answers

Option A is wrong because identity-based firewall policies control access based on user/group authentication (e.g., LDAP or local users), not client certificate validation; they do not enforce certificate-based client identity at the SSL VPN tunnel level. Option B is wrong because 'certificate-based authentication' in a user group is not a valid FortiGate setting; user groups support authentication methods like LDAP, RADIUS, or PKI, but the group itself does not have a toggle for certificate-based authentication—this must be configured in the SSL VPN settings. Option D is wrong because importing users' public keys into the FortiGate is not a standard method for client certificate validation; the FortiGate validates client certificates by trusting the issuing CA's certificate, not by importing individual user public keys.

Practice this question →
55
MCQeasy

Which of the following FortiGate features allows users to authenticate using a one-time password generated by a mobile app?

A.FSSO
B.LDAP
C.FortiToken
D.Captive portal
AnswerC

FortiToken generates OTPs for two-factor authentication.

Why this answer

FortiToken is Fortinet's two-factor authentication solution that generates one-time passwords (OTPs) via a mobile app (FortiToken Mobile) or hardware token. When a user authenticates, they must provide both their regular password and the current OTP from the FortiToken app, which is validated by the FortiGate against the token's seed record. This directly matches the question's requirement for OTP generation by a mobile app.

Exam trap

The trap here is that candidates often confuse FortiToken with FSSO or LDAP because all three involve authentication, but only FortiToken specifically generates and validates one-time passwords via a mobile app.

How to eliminate wrong answers

Option A (FSSO) is wrong because FSSO (Fortinet Single Sign-On) collects user login events from domain controllers to map users to IP addresses for policy enforcement, but it does not generate or validate one-time passwords. Option B (LDAP) is wrong because LDAP is a directory service protocol used for storing and retrieving user credentials and attributes; it does not generate OTPs or provide two-factor authentication. Option D (Captive portal) is wrong because a captive portal is a web-based authentication interface that redirects users to a login page, but it does not generate OTPs; it can be used with external authentication methods but is not itself an OTP generator.

Practice this question →
56
MCQmedium

A network admin configures a site-to-site IPsec VPN between two FortiGates using IKEv1 main mode. The tunnel establishes successfully, but no traffic passes. What is the MOST likely cause?

A.Aggressive mode should be used instead of main mode
B.The pre-shared key is incorrect
C.There is no firewall policy allowing traffic through the VPN tunnel
D.The phase2 proposal does not match between peers
AnswerC

Even when the IPsec tunnel interface is up and phase 1/phase 2 SAs are active, FortiGate will not forward any user traffic through the tunnel unless an explicit firewall policy permits it. The policy must be configured with the source address, destination address, and service, and its outgoing interface must be set to the VPN tunnel interface (or the virtual IPsec interface). Without such a policy, packets are dropped at the firewall policy check even though the encrypted tunnel exists and is healthy. This is the classic root cause when the VPN shows connected but users cannot reach remote resources, and the fix is to create the appropriate ACCEPT policy from the local zone to the VPN zone.

Why this answer

The tunnel establishes successfully, meaning IKE phase 1 and phase 2 negotiations completed correctly, which rules out mismatched proposals or incorrect pre-shared keys. However, even with a functional IPsec tunnel, traffic cannot flow unless a firewall policy explicitly permits it between the source and destination zones using the VPN interface. In FortiGate, the VPN tunnel is treated as an interface, and without a policy allowing traffic from the internal network to the VPN interface (or vice versa), packets are dropped by the firewall engine.

Exam trap

The trap here is that candidates assume a successful IPsec tunnel automatically allows traffic, but FortiGate requires an explicit firewall policy to permit traffic through the VPN interface, unlike some other vendors where the tunnel itself implies a permit.

How to eliminate wrong answers

Option A is wrong because aggressive mode is used for faster negotiation with less security (e.g., when peer IP is dynamic), but main mode is fully valid and not the cause of traffic failure after tunnel establishment. Option B is wrong because if the pre-shared key were incorrect, IKE phase 1 authentication would fail and the tunnel would never establish. Option D is wrong because a phase 2 proposal mismatch would cause the IPsec SA negotiation to fail, preventing the tunnel from establishing; since the tunnel is up, the proposals must match.

Practice this question →
57
MCQhard

An administrator runs 'diagnose vpn ike gateway list' on a FortiGate and sees the following output for a dial-up IPsec VPN: gateway name: 'dialup' version: IKEv1 mode: aggressive local IP: 203.0.113.1 remote IP: 0.0.0.0 state: up peers: 0 What does 'peers: 0' indicate?

A.The remote IP should be set to a specific address
B.The gateway is in a down state
C.No IPsec clients are currently connected
D.The Phase 2 proposals are mismatched
AnswerC

Peers: 0 indicates zero active connections.

Why this answer

In the output of 'diagnose vpn ike gateway list', the 'peers' field shows the number of active IPsec tunnels (Phase 1 SAs) currently established through that gateway. A value of '0' means no remote clients have successfully completed IKE negotiation and are connected. Since the gateway state is 'up', it is ready to accept connections, but no clients are currently associated with it.

Exam trap

The trap here is that candidates see 'state: up' and assume the gateway has active connections, but 'up' only indicates the IKE process is running and listening, not that any peers are actually connected.

How to eliminate wrong answers

Option A is wrong because in a dial-up IPsec VPN, the remote IP is intentionally left as 0.0.0.0 to allow any remote client to initiate a connection; setting a specific address would defeat the purpose of a dial-up configuration. Option B is wrong because the output explicitly shows 'state: up', indicating the IKE gateway process is active and listening, not down. Option D is wrong because Phase 2 proposal mismatches would cause failures during IPsec SA establishment, not affect the Phase 1 peer count; the 'peers' counter specifically tracks Phase 1 SAs, not Phase 2.

Practice this question →
58
MCQmedium

A FortiGate administrator is configuring an SSL VPN web mode portal. The administrator wants users to access only a specific internal web application (https://internal-app.company.local) and nothing else. Which SSL VPN setting should be configured to achieve this?

A.In the SSL VPN portal, set the default bookmark to the application URL
B.Configure a firewall policy that allows traffic only to the application's IP address
C.Enable split tunneling under the SSL VPN settings
D.Under the SSL VPN portal, configure 'URL Access' to allow only https://internal-app.company.local
AnswerD

The URL Access feature under the SSL VPN portal provides a per-portal whitelist of web addresses that users are allowed to access through the reverse proxy. When you specify only https://internal-app.company.local, the FortiGate enforces that rule during proxy processing: any request to a URL that does not match the whitelist is denied with an error. This precisely meets the requirement because it is a proxy-level, application-aware access control, rather than a network-layer rule or a UI shortcut. It effectively prevents users from browsing to any other internal or external web host through the portal while allowing the specific internal application.

Why this answer

The 'URL Access' setting in the SSL VPN web mode portal allows the administrator to explicitly define which URLs users can access through the portal. By configuring an allow list with only https://internal-app.company.local, users are restricted to that specific internal web application, and all other URLs are blocked. This provides granular control over web-based resources in the SSL VPN portal without relying on network-layer restrictions.

Exam trap

The trap here is that candidates often confuse network-layer controls (firewall policies or split tunneling) with application-layer controls (URL Access), assuming that blocking traffic at the IP/port level is sufficient to restrict web-based access within an SSL VPN portal.

How to eliminate wrong answers

Option A is wrong because setting a default bookmark only pre-populates the user's portal with a link to the application; it does not restrict access to other URLs, so users could still navigate to other internal or external sites via the portal. Option B is wrong because a firewall policy controls traffic at the network layer (IP/port), not the application-layer URL access within the SSL VPN web mode portal; users could still access other web applications on the same IP or port if not explicitly blocked at the URL level. Option C is wrong because split tunneling controls whether client traffic goes through the VPN tunnel or directly to the internet for tunnel-mode VPNs, not for web mode portals; it does not restrict which URLs users can access within the portal.

Practice this question →
59
MCQmedium

A remote user connects via SSL VPN web mode but cannot access internal resources. The SSL VPN portal is configured with the default settings. What is the most likely reason?

A.The user must be authenticated via LDAP
B.The user has not installed the FortiClient VPN plugin
C.Web mode only allows access to specific bookmarks configured in the portal
D.The SSL VPN policy is missing a security profile
AnswerC

In SSL VPN web mode, the user's entire accessible domain is restricted to the bookmarks that the administrator has explicitly defined in the user's assigned portal. Without pre-configured bookmarks to internal URLs, the portal displays no resources, and the user cannot navigate to any internal application. This is exactly the symptom described: a remote user can connect and authenticate, but there are no portal bookmarks, so no access is granted.

Why this answer

In SSL VPN web mode, the FortiGate acts as a proxy, granting access only to pre-configured bookmarks (URLs or applications) defined in the SSL VPN portal. Default portal settings do not include any bookmarks, so even after successful authentication, the user sees an empty portal and cannot reach internal resources. This is by design, as web mode does not provide full network-layer access like tunnel mode does.

Exam trap

The trap here is that candidates often assume SSL VPN always provides full network access or that a missing security profile is the cause, but the NSE4 exam specifically tests the distinction between web mode (bookmark-based) and tunnel mode (full access).

How to eliminate wrong answers

Option A is wrong because authentication via LDAP is not a requirement for SSL VPN web mode; the user can be authenticated using any supported method (local, RADIUS, etc.) and the portal will still function. Option B is wrong because FortiClient VPN plugin is only required for tunnel mode (full network access) or for host-check features; web mode operates entirely through the browser without any client software. Option D is wrong because security profiles (AV, web filter, IPS) are applied to firewall policies, not directly to SSL VPN policies; the SSL VPN policy itself does not require a security profile to allow web-mode access.

Practice this question →
60
MCQhard

An administrator configures a dial-up IPsec VPN with IKEv2 to allow remote users to connect. The Phase 1 is set to use certificate-based authentication (PKI). Users can establish Phase 1, but Phase 2 fails with 'no proposal chosen'. The administrator checks the Phase 2 proposal: AES256-SHA256, and the remote network is 10.0.0.0/8 (the corporate LAN). What is the MOST likely cause?

A.The remote network in Phase 2 is set to 10.0.0.0/8
B.The remote network in Phase 2 is set to 0.0.0.0/0
C.The Phase 1 encryption algorithm is mismatched
D.The authentication type requires EAP instead of certificate
AnswerA

The remote network in Phase 2 should be 0.0.0.0/0 for dial-up, because the client's real IP is dynamic. Setting it to 10.0.0.0/8 means the FortiGate expects the client's IP to be in that range, which it is not.

Why this answer

The most likely cause is that the remote network (client subnet) in the Phase 2 configuration on the VPN gateway is set to 10.0.0.0/8 instead of the correct value (0.0.0.0/0) for dial-up clients. Since Phase 1 succeeds, authentication and encryption settings are correct. The 'no proposal chosen' error in Phase 2 indicates a traffic selector mismatch: the server expects the client's IP to be within the 10.0.0.0/8 range, but the client's actual IP typically falls outside that subnet.

Therefore, the Phase 2 negotiation fails.

Exam trap

The trap is that candidates often attribute Phase 2 failures to algorithm mismatches, but in IKEv2 dial-up VPNs, 'no proposal chosen' commonly results from an incorrect Phase 2 traffic selector. Specifically, the remote network (client subnet) on the server side must be set to 0.0.0.0/0 for dial-up clients, not the corporate LAN subnet.

How to eliminate wrong answers

Option B is wrong because setting the remote network to 0.0.0.0/0 would create a default route for all traffic, which is not the specific corporate LAN subnet and would still cause a Phase 2 mismatch if the gateway expects 10.0.0.0/8. Option C is wrong because Phase 1 is already established successfully, indicating that the encryption algorithms (including certificate-based authentication) are correctly matched; a Phase 1 mismatch would prevent Phase 1 from completing. Option D is wrong because certificate-based authentication (PKI) is explicitly configured and Phase 1 succeeds, so EAP is not required; EAP is typically used for extended authentication, not for basic IKEv2 Phase 1 with certificates.

Practice this question →
61
MCQmedium

A FortiGate administrator is configuring a hub-and-spoke IPsec VPN. The hub has multiple Phase 2 selectors for each spoke. What is the recommended way to simplify configuration on the hub when adding new spokes?

A.Use a single Phase 2 selector with 0.0.0.0/0.0.0.0 for both local and remote
B.Configure each spoke in a separate VDOM
C.Use aggressive mode for Phase 1
D.Use policy-based VPN instead of route-based
AnswerA

Setting both local and remote Phase 2 selectors to 0.0.0.0/0 creates an any-to-any proxy ID, so all traffic routed into the tunnel interface is encrypted without needing a separate selector per subnet or per spoke. In a route-based VPN, the tunnel interface decouples routing from IPsec proxy IDs, so a single Phase 2 definition can be reused across every spoke; new spokes simply reuse the same selector and rely on routing to direct traffic. This is the standard FortiGate recommendation for hub-and-spoke because it avoids negotiation failures caused by mismatched local/remote subnet definitions and eliminates per-spoke Phase 2 configuration at the hub.

Why this answer

Using a single Phase 2 selector with 0.0.0.0/0.0.0.0 for both local and remote simplifies hub configuration because it allows the hub to accept traffic for any subnet from any spoke without needing to define specific selectors per spoke. This is recommended in hub-and-spoke topologies to avoid manual updates when adding new spokes, as the hub's Phase 2 configuration becomes generic and automatically matches all spoke traffic.

Exam trap

The trap here is that candidates often think policy-based VPNs are simpler for hub-and-spoke, but they actually require explicit selector pairs per spoke, making the hub configuration more complex and less scalable.

How to eliminate wrong answers

Option B is wrong because configuring each spoke in a separate VDOM adds unnecessary administrative overhead and complexity, and does not simplify the Phase 2 selector configuration on the hub. Option C is wrong because aggressive mode for Phase 1 is less secure than main mode (it sends identities in plaintext) and is not related to simplifying Phase 2 selectors; it is typically used for remote access with dynamic IPs, not hub-and-spoke simplification. Option D is wrong because policy-based VPNs require explicit firewall policies for each subnet pair, which actually increases configuration effort when adding new spokes, whereas route-based VPNs with a single Phase 2 selector are simpler for hub-and-spoke designs.

Practice this question →
62
Multi-Selecthard

A FortiGate admin is troubleshooting an IPsec VPN that fails to establish. The output of 'diagnose debug application ike -1' shows: 'IKE: No proposal chosen from x.x.x.x'. The admin checks the Phase1 configuration. Which of the following mismatches could cause this error? (Choose three.)

Select 3 answers
A.Diffie-Hellman group mismatch (e.g., group 2 vs group 14)
B.Pre-shared key mismatch
C.Lifetime mismatch (e.g., 86400 vs 3600)
D.Authentication method mismatch (e.g., SHA1 vs SHA256)
E.Encryption algorithm mismatch (e.g., AES128 vs AES256)
AnswersA, D, E

DH group is also part of the proposal.

Why this answer

The 'No proposal chosen' error indicates that the IKE SA parameters proposed by the initiator do not match any configured proposal on the responder. Since the error occurs during Phase 1, mismatches in mandatory parameters like Diffie-Hellman group, authentication method (hash algorithm), and encryption algorithm will directly cause this failure, as these are negotiated as part of the SA payload.

Exam trap

The trap here is that candidates often confuse Phase 1 proposal mismatches (which cause 'No proposal chosen') with Phase 1 authentication failures (caused by PSK mismatch), leading them to incorrectly select the pre-shared key option.

Practice this question →
63
MCQhard

You are troubleshooting an SSL VPN connection. The user can reach the SSL VPN portal but cannot ping or access any internal resources. The portal shows the user as authenticated. Which configuration is MOST likely missing?

A.There is no firewall policy allowing traffic from ssl.root to the internal network
B.Client certificate authentication is required but not provided
C.Split tunneling is disabled
D.The SSL VPN realm is not configured correctly
AnswerA

In Fortinet's SSL VPN design, the SSL VPN interface (typically ssl.root) is just a virtual interface; after authentication, the tunnel is up but traffic is still subject to normal firewall policy checks. Without a policy that matches source ssl.root and destination internal network with the appropriate action (accept), the FortiGate silently drops the packets. Thus users can authenticate and establish the tunnel, but cannot reach internal resources until an explicit policy is created, often with NAT and security profiles as needed.

Why this answer

The user can authenticate and reach the SSL VPN portal, which indicates that the SSL VPN tunnel itself is established and authentication is successful. However, the inability to ping or access internal resources despite being authenticated points to a missing firewall policy that explicitly permits traffic from the SSL VPN interface (ssl.root) to the internal network. Without this policy, the FortiGate will drop all traffic from the SSL VPN tunnel, even though the user is logged in.

Exam trap

The trap here is that candidates assume authentication success implies full network access, but FortiGate requires an explicit firewall policy for SSL VPN traffic, separate from the authentication and tunnel setup.

How to eliminate wrong answers

Option B is wrong because client certificate authentication is an additional security layer for the authentication phase; if it were required but not provided, the user would not be able to authenticate or reach the portal at all. Option C is wrong because split tunneling controls whether traffic for internal networks is sent through the VPN tunnel or directly to the internet; disabling split tunneling would actually force all traffic through the tunnel, which would not prevent access to internal resources once the tunnel is up. Option D is wrong because the SSL VPN realm configuration affects the portal page and authentication settings; if the realm were misconfigured, the user would likely not see the correct portal or would fail authentication, but the user is already authenticated and on the portal.

Practice this question →
64
MCQeasy

An administrator wants to authenticate VPN users against an external LDAP server. Which authentication method should be configured in the user group for the SSL VPN portal?

A.RADIUS
B.FSSO
C.Local
D.LDAP
AnswerD

LDAP authentication enables the FortiGate to validate VPN users by performing a direct bind to the LDAP server (such as Active Directory or OpenLDAP) using the user's distinguished name and password. The FortiGate can also retrieve group memberships during the authentication process, allowing LDAP-based groups to be used in firewall policies. This is the most straightforward and correct method when the authentication source is an LDAP server, as it avoids an extra RADIUS or other proxy layer.

Why this answer

To authenticate VPN users against an external LDAP server, the user group for the SSL VPN portal must be configured with the LDAP authentication method. This directs FortiGate to bind directly to the LDAP server (e.g., Active Directory or OpenLDAP) using the configured LDAP server object, performing a simple bind or SASL bind to verify user credentials. Other methods like RADIUS, FSSO, or Local would not leverage the LDAP server directly.

Exam trap

The trap here is that candidates often confuse 'LDAP' as a protocol with 'RADIUS' as a protocol, assuming both are interchangeable for external authentication, but FortiGate requires the LDAP method specifically when the authentication source is an LDAP directory server, not a RADIUS server.

How to eliminate wrong answers

Option A is wrong because RADIUS is a separate authentication protocol that uses a RADIUS server (e.g., FreeRADIUS or NPS) to proxy authentication, not a direct LDAP bind; it adds an intermediary and does not authenticate directly against LDAP. Option B is wrong because FSSO (Fortinet Single Sign-On) is used for transparent authentication based on Windows domain logon events, not for direct credential validation against an LDAP server for VPN access. Option C is wrong because Local authentication uses locally stored user accounts on the FortiGate, which bypasses any external LDAP server entirely.

Practice this question →
65
MCQmedium

A FortiGate administrator wants to configure a dial-up IPsec VPN where remote users connect using VPN clients with pre-shared key authentication. The company has recently experienced a data breach where the PSK was compromised. What is the best method to improve security without changing all clients immediately?

A.Switch to aggressive mode with a complex PSK
B.Enable XAuth with a second authentication factor using FortiToken
C.Increase the PSK length to 64 characters
D.Migrate to certificate-based authentication for Phase 1
AnswerD

Certificate-based Phase 1 authentication replaces the shared PSK with a unique asymmetric key pair per dial-up peer, binding each client's identity to its certificate. During IKE main mode, certificates enable mutual authentication without ever transmitting a shared secret in the clear, and compromised certificates can be individually revoked via a CRL or OCSP without affecting other peers. This eliminates the single-point-of-failure shared secret and is the correct way to harden a dial-up IPsec VPN.

Why this answer

Migrating to certificate-based authentication eliminates reliance on a static pre-shared key (PSK), which is inherently vulnerable to compromise. Certificates provide asymmetric cryptographic proof of identity, ensuring that even if a PSK is leaked, the attacker cannot authenticate without a valid certificate. This is the most robust long-term fix for PSK compromise in IPsec VPNs.

Exam trap

The trap here is that candidates often confuse user authentication (XAuth) with Phase 1 authentication, mistakenly believing that adding a second factor like FortiToken fixes the compromised PSK, when in fact the PSK is still used and vulnerable in the initial IKE exchange.

How to eliminate wrong answers

Option A is wrong because aggressive mode actually reduces security by sending the PSK in cleartext during Phase 1 negotiation, making it easier to capture and exploit. Option B is wrong because XAuth with FortiToken adds a second authentication factor for user identity, but it does not replace or secure the compromised PSK used in Phase 1; the PSK remains the weak link. Option C is wrong because increasing the PSK length to 64 characters only increases brute-force resistance, but does not address the fact that the PSK has already been compromised and is known to an attacker.

Practice this question →
66
MCQmedium

A FortiGate administrator has configured a route-based IPsec VPN. After Phase 2 is up, traffic is not passing. The administrator verifies that the firewall policy allows traffic and the routes are correct. What should the administrator check next?

A.The static route uses the VPN interface as the outgoing interface
B.The remote gateway's IP address is reachable
C.The pre-shared key is correct
D.The Phase 2 proposal includes the correct local and remote subnets
AnswerA

In a route-based VPN, the virtual IPsec interface serves as the tunnel endpoint, and the static route must specify that interface as the outgoing interface for the remote subnet. Without this route, the FortiGate has no entry in its routing table to direct traffic into the IPsec tunnel, even if Phase 1 and Phase 2 SAs are fully established. The route triggers the actual forwarding decision, causing the kernel to encapsulate and encrypt matching traffic over the tunnel.

Why this answer

In a route-based IPsec VPN, traffic is routed to the VPN tunnel interface (e.g., 'to_remote'). Even if firewall policies and static routes exist, the static route must explicitly use the VPN interface as the outgoing interface. If the static route points to a different interface or a next-hop IP instead of the tunnel interface, the kernel will not forward traffic into the IPsec tunnel, causing Phase 2 to be up but no traffic to pass.

This is a common misconfiguration that breaks the route-based VPN model.

Exam trap

The trap here is that candidates assume Phase 2 being up guarantees traffic flow, overlooking that route-based VPNs require the static route to explicitly use the tunnel interface as the outgoing interface, not just any valid next-hop.

How to eliminate wrong answers

Option B is wrong because the remote gateway's IP address being reachable is a prerequisite for Phase 1 (IKE) to establish, not a cause for traffic failure after Phase 2 is up. Option C is wrong because an incorrect pre-shared key would prevent Phase 1 from completing, but the question states Phase 2 is up, meaning Phase 1 and authentication succeeded. Option D is wrong because if the Phase 2 proposal included incorrect local or remote subnets, Phase 2 would not come up; since Phase 2 is up, the proposal is correct, and the issue lies in how traffic is routed to the tunnel.

Practice this question →
67
MCQmedium

A FortiGate administrator configures a captive portal on a VDOM to authenticate users connecting to a guest SSID. The authentication method is set to LDAP. Users can reach the captive portal login page, but after entering valid credentials, they receive an authentication failure. The LDAP server is reachable from the FortiGate. What is the MOST likely cause?

A.The user is not a member of the configured user group
B.The captive portal is using HTTP instead of HTTPS
C.The captive portal interface is not in the same VDOM as the LDAP server
D.The LDAP server requires TLS and FortiGate is using plain LDAP
AnswerA

FortiGate uses LDAP for credential validation, but the firewall policy specifies a particular user group that must contain the authenticated account. After the LDAP bind succeeds, FortiGate performs a group lookup against the configured group; if the user is not a member, the captive portal rejects the login even though the password was correct. This is an authorization failure rather than an authentication failure, and it is the classic cause of a captive portal rejecting valid LDAP creds.

Why this answer

The most likely cause is that the user is not a member of the configured user group. In FortiGate, when LDAP authentication is used for a captive portal, the FortiGate first verifies the user's credentials against the LDAP server. Even if the credentials are valid, the FortiGate then checks whether the authenticated user belongs to a specific user group that is permitted to access the captive portal.

If the user is not a member of that group, the authentication fails, even though the LDAP server itself accepts the credentials.

Exam trap

The trap here is that candidates often assume LDAP authentication failure is always due to connectivity or protocol issues (like TLS or HTTP), but FortiGate's group membership enforcement is a distinct step that can cause failure even with valid credentials and a reachable server.

How to eliminate wrong answers

Option B is wrong because using HTTP instead of HTTPS for the captive portal would not cause an authentication failure after valid credentials are entered; it would only expose credentials in transit but not prevent successful authentication. Option C is wrong because the captive portal interface and the LDAP server do not need to be in the same VDOM; the LDAP server is reachable from the FortiGate, and VDOM separation does not affect LDAP authentication as long as routing permits. Option D is wrong because if the LDAP server required TLS and the FortiGate used plain LDAP, the connection would fail entirely, and the user would not even reach the captive portal login page or receive an authentication failure after entering credentials; instead, a timeout or connection error would occur.

Practice this question →
68
Multi-Selecthard

A company has multiple branch offices connected via IPsec VPN in a hub-and-spoke topology. They want to enable direct communication between branch offices without routing traffic through the hub. Which THREE configurations are required on the hub FortiGate? (Choose three.)

Select 3 answers
A.Enable 'forward traffic' in Phase 1 settings
B.Static routes for each branch's subnet pointing to the respective VPN interface
C.Phase 2 selectors that include both branch subnets in one proposal
D.Disable anti-replay on all tunnels
E.A firewall policy allowing traffic between the VPN interfaces
AnswersB, C, E

The hub needs routes to forward traffic between spokes.

Why this answer

Static routes for each branch's subnet pointing to the respective VPN interface are required on the hub FortiGate so that the hub knows how to forward traffic destined for one branch's subnet out the correct IPsec tunnel to the other branch. Without these routes, the hub would have no path to the remote branch subnets and would drop the traffic, preventing direct branch-to-branch communication.

Exam trap

The trap here is that candidates often think only firewall policies are needed, forgetting that without static routes and proper Phase 2 selectors, the hub cannot route or encrypt traffic between branches, even with permissive policies.

Practice this question →
69
MCQhard

A FortiGate administrator is troubleshooting a dial-up IPsec VPN where remote users can connect but traffic does not pass. The Phase 1 and Phase 2 status show 'up'. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. However, 'diagnose sys session list' shows no sessions for the remote user's IP. What is the MOST likely cause?

A.The Phase 2 proposal uses AES256 but the remote client only supports AES128
B.The FortiGate's routing table does not have a route to the remote user's subnet
C.There is no firewall policy permitting traffic from the dial-up interface to the destination network
D.The remote user's FortiClient is blocking split tunneling
AnswerC

The FortiGate's implicit deny rule silently discards any traffic that does not match an explicit firewall policy, including traffic arriving from a dial-up IPsec tunnel interface. Even if the Phase 1 and Phase 2 SAs are fully up, the FortiGate will not forward packets from the remote VPN user to the internal destination unless a policy exists allowing that traffic between the VPN interface (e.g., ssl.root or dialup) and the destination zone. Since the session table is empty, the packets are being dropped by the firewall policy lookup, making a missing policy the most direct and common cause.

Why this answer

Even when Phase 1 and Phase 2 are up and the tunnel is established, traffic will not pass through a dial-up IPsec VPN unless a firewall policy explicitly permits traffic from the dial-up interface (often the virtual IPsec interface) to the destination network. The 'diagnose sys session list' showing no sessions for the remote user's IP confirms that the FortiGate is not processing any traffic for that user, which points to a missing or misconfigured firewall policy rather than an encryption or routing issue.

Exam trap

The trap here is that candidates assume an 'up' Phase 1 and Phase 2 guarantee traffic flow, but FortiGate requires a separate firewall policy to permit traffic from the IPsec interface to the destination, and the absence of sessions in 'diagnose sys session list' is the key diagnostic clue for this missing policy.

How to eliminate wrong answers

Option A is wrong because if the Phase 2 proposal used AES256 but the remote client only supported AES128, the Phase 2 would not come up at all; the status would show 'down' or negotiation would fail. Option B is wrong because in a dial-up IPsec VPN, the remote user's IP is dynamically assigned and not a subnet that requires a static route; the FortiGate uses the IPsec interface itself to route traffic back to the remote user. Option D is wrong because split tunneling on FortiClient controls which traffic goes over the VPN versus the local internet, but it does not prevent the FortiGate from seeing sessions; if the tunnel is up and traffic is sent, sessions would appear in 'diagnose sys session list' regardless of split tunneling settings.

Practice this question →
70
MCQmedium

A FortiGate administrator is configuring IPsec VPN between two sites. The Phase 1 negotiation fails with the error 'no proposal chosen'. Which two settings must match on both VPN peers?

A.Pre-shared key and local ID
B.Dead peer detection interval and retry count
C.Remote gateway IP and Phase 2 selectors
D.Encryption algorithm and authentication algorithm
AnswerD

The "no proposal chosen" error is FortiGate's way of reporting that the IKE Phase 1 SA proposal could not be matched with the remote peer. The proposal is constructed from the encryption algorithm (e.g., AES256-GCM, AES256-CBC), the authentication/integrity algorithm (e.g., SHA-256, SHA-1), the Diffie-Hellman group, and in some cases the pseudo-random function (PRF). If any of these parameters differ between peers, the IKE SA negotiation fails with "no proposal chosen" during the SA payload exchange. Correcting the encryption and authentication algorithms so that both peers share at least one common proposal is the direct and expected remedy for this exact error.

Why this answer

The 'no proposal chosen' error during IPsec Phase 1 negotiation indicates that the two VPN peers cannot agree on a common set of security parameters for the IKE (Internet Key Exchange) SA. The encryption algorithm (e.g., AES-256, 3DES) and authentication algorithm (e.g., SHA-256, MD5) are mandatory components of the Phase 1 proposal; if they do not match on both peers, the IKE negotiation fails immediately.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 parameters, mistakenly thinking that mismatched Phase 2 selectors (option C) or pre-shared keys (option A) cause the 'no proposal chosen' error, when in fact it is specifically a Phase 1 proposal mismatch involving encryption and authentication algorithms.

How to eliminate wrong answers

Option A is wrong because the pre-shared key is used for authentication in Phase 1, but a mismatch would typically cause an authentication failure (e.g., 'invalid cookie' or 'authentication failed'), not a 'no proposal chosen' error; the local ID is optional and only matters when using aggressive mode or ID-based authentication. Option B is wrong because dead peer detection (DPD) interval and retry count are keepalive mechanisms that operate after the tunnel is established; they do not affect the initial proposal negotiation. Option C is wrong because the remote gateway IP is used to establish the connection endpoint, but a mismatch would prevent the peers from reaching each other, not cause a proposal mismatch; Phase 2 selectors (traffic selectors) are negotiated after Phase 1 is complete, so they are irrelevant to the Phase 1 'no proposal chosen' error.

Practice this question →
71
MCQmedium

A FortiGate administrator is troubleshooting an SSL VPN connection issue. Users can connect but cannot access internal resources. The administrator checks the SSL VPN policy and confirms it allows access to the internal subnet. What should the administrator check next?

A.Verify that the firewall policy between the SSL VPN interface and the internal network allows the traffic
B.Check the routing table on the FortiGate for the internal subnet
C.Ensure the users have the correct client software installed
D.Check the FortiGate's DNS settings
AnswerA

Correct. The firewall policy must explicitly permit traffic from the SSL VPN zone to the internal zone.

Why this answer

Even if the SSL VPN policy permits access to the internal subnet, traffic must still traverse a firewall policy from the SSL VPN interface (e.g., ssl.root) to the internal network interface. Without an explicit firewall policy allowing the traffic, the FortiGate will drop the packets, preventing resource access. This is a common oversight because the SSL VPN policy only controls tunnel establishment and route injection, not the actual forwarding of traffic between zones.

Exam trap

The trap here is that candidates assume the SSL VPN policy alone governs all access, overlooking the separate firewall policy requirement that actually enforces traffic flow between the SSL VPN interface and the internal network.

How to eliminate wrong answers

Option B is wrong because the routing table on the FortiGate is not the primary issue here; if users can connect to the SSL VPN, the FortiGate typically installs a route for the virtual IP pool, and the internal subnet route is usually present. Option C is wrong because the users are already connected, indicating the client software is functioning correctly for the tunnel; the problem is post-connection traffic forwarding. Option D is wrong because DNS settings affect name resolution, not direct IP-based access to internal resources; if users can connect but cannot access resources by IP, DNS is irrelevant.

Practice this question →
72
MCQmedium

An administrator has configured an SSL VPN. Remote users can connect and authenticate but cannot access internal resources. The SSL VPN policy allows all traffic from the SSL VPN interface to internal servers. What is the MOST likely missing configuration?

A.The remote user's client does not support split tunneling
B.The firewall policy allowing traffic from SSL VPN interface to internal network is missing
C.The authentication timeout is too short
D.The SSL VPN portal does not have the correct bookmark configured
AnswerB

Even with SSL VPN configured, traffic must be allowed by a firewall policy from the SSL VPN interface to the destination.

Why this answer

The most likely missing configuration is a firewall policy that explicitly permits traffic from the SSL VPN interface (e.g., ssl.root) to the internal network. Even with an SSL VPN policy allowing traffic, FortiGate requires a separate firewall policy to control and allow the decrypted traffic to reach internal resources. Without this policy, packets are dropped by the implicit deny rule.

Exam trap

The trap here is that candidates often confuse the SSL VPN policy (which controls authentication and portal access) with the firewall policy (which controls traffic forwarding), assuming the SSL VPN policy alone is sufficient to allow traffic to internal resources.

How to eliminate wrong answers

Option A is wrong because split tunneling controls whether client traffic goes through the VPN tunnel or directly to the internet; it does not affect the ability to access internal resources once connected. Option C is wrong because an authentication timeout that is too short would cause the user to be disconnected or re-authenticated, not prevent access to internal resources while still being connected. Option D is wrong because bookmarks are used in web-mode SSL VPN to provide easy links to specific web applications; they are not required for tunnel-mode access to internal resources.

Practice this question →
73
MCQeasy

What is the primary advantage of using route-based IPsec VPN over policy-based IPsec VPN?

A.Route-based VPN allows the use of dynamic routing protocols over the tunnel
B.Route-based VPN requires fewer firewall policies
C.Route-based VPN is easier to configure for hub-and-spoke
D.Route-based VPN supports higher encryption algorithms
AnswerA

Route-based IPsec VPN creates a virtual tunnel interface, allowing the underlying IPsec connection to participate in dynamic routing protocols such as OSPF, EIGRP, or BGP. This enables automatic route advertisement and convergence, eliminating the need for static proxy-IDs for each destination network, and making large-scale, redundant VPN topologies far more practical to deploy and maintain.

Why this answer

Route-based IPsec VPNs create a virtual tunnel interface (e.g., `tunnel` or `ipsec` interface) that acts as a logical routing endpoint. This allows the tunnel to participate in dynamic routing protocols like OSPF or BGP, enabling automatic route advertisement and failover across the VPN. Policy-based VPNs, in contrast, rely on static security policies that match traffic based on source/destination addresses and ports, which cannot be dynamically updated by routing protocols.

Exam trap

The trap here is that candidates often confuse 'fewer firewall policies' (Option B) as the primary advantage, but the NSE4 exam emphasizes that the key differentiator is the ability to use dynamic routing protocols over the tunnel, which is not possible with policy-based VPNs.

How to eliminate wrong answers

Option B is wrong because route-based VPNs typically require fewer firewall policies only in the sense that traffic is matched via routing rather than per-flow policies, but this is not the primary advantage; the core benefit is dynamic routing. Option C is wrong because while route-based VPNs can simplify hub-and-spoke topologies, this is a consequence of dynamic routing support, not the primary advantage; policy-based VPNs can also be used for hub-and-spoke with manual configuration. Option D is wrong because both route-based and policy-based VPNs support the same encryption algorithms (e.g., AES-256, SHA-256) as defined by the IPsec proposal; the choice of algorithm is independent of the VPN type.

Practice this question →

Ready to test yourself?

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

Start 20-question session