NSE4 Authentication and VPN Practice Test 6 — 15 Questions

Question 1

A FortiGate admin is troubleshooting an IPsec VPN tunnel that fails to establish. The remote site uses aggressive mode. The local FortiGate is configured for main mode. The admin sees 'no proposal chosen' in the IKE debug. What is the MOST likely cause?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The IKE mode (main vs aggressive) does not match between peers. The 'no proposal chosen' error in IKE debug indicates a mismatch in the IKE parameters proposed by the peers. Since the remote site uses aggressive mode and the local FortiGate is configured for main mode, the IKE mode mismatch prevents the peers from agreeing on a proposal. IKE main mode and aggressive mode use different packet formats and exchange sequences, so they cannot negotiate a common proposal even if all other parameters match.

Answer

The pre-shared key is incorrect

Answer

The local firewall is blocking UDP port 500

Answer

The Phase 2 encryption algorithm is not supported

Question 2

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?

Accepted Answer

The ZTNA rule requires a specific client posture tag that the users' devices do not have. 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.

Answer

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

Answer

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

Answer

The ZTNA access proxy does not have a valid SSL certificate

Question 3

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?

Accepted Answer

The user's password is incorrect or the user account is locked. 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.

Answer

The LDAP server is unreachable

Answer

The LDAP bind user password is incorrect

Answer

The LDAP schema does not match what FortiGate expects

Question 4

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?

Accepted Answer

Modify the Phase 2 selectors on the hub to include both spoke subnets and add firewall policies allowing traffic between the spoke networks. 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.

Answer

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

Answer

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

Answer

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

Question 5

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

Accepted Answer

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

Answer

The pre-shared key is incorrect

Answer

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

Question 6

A FortiGate administrator is configuring FSSO to authenticate users transparently. The FSSO collector agent is installed on a Windows server in the domain. Which TWO requirements must be met for FSSO to work correctly?

Accepted Answer

The FortiGate must be able to reach the FSSO collector agent on TCP port 8000 (or the configured port). The FortiGate must communicate with the FSSO collector agent over TCP port 8000 (or a custom port) to receive real-time user login/logoff events. This connection is essential for the FortiGate to map IP addresses to authenticated domain users and enforce identity-based firewall policies. Without this reachability, the FortiGate cannot obtain the necessary user-to-IP mappings from the collector agent.

Answer

The FortiGate must be a member of the Active Directory domain

Answer

The users must authenticate via captive portal at least once

Answer

The firewall policies must use FSSO groups directly without any user objects

Question 7

You are troubleshooting an IPsec VPN between two FortiGates. The Phase 1 is up, but Phase 2 is not coming up. You check the Phase 2 configuration on both sides. What is a common cause of this issue?

Accepted Answer

Mismatch in Phase 2 settings such as encryption algorithm, authentication algorithm, or PFS group. When Phase 1 is up but Phase 2 fails, the most common cause is a mismatch in Phase 2 parameters. Phase 2 uses IPsec SA proposals that must match exactly on both sides, including encryption algorithm (e.g., AES256), authentication algorithm (e.g., SHA256), and Perfect Forward Secrecy (PFS) group (e.g., DH14). Even a single mismatch, such as one side using PFS and the other not, will prevent Phase 2 from establishing.

Answer

Firewall policy not allowing ESP traffic

Answer

Incorrect local or remote gateway IP

Answer

Mismatch in Phase 1 pre-shared key

Question 8

A FortiGate administrator wants to configure a captive portal to authenticate users before granting network access. Which authentication method is used by the captive portal?

Accepted Answer

Form-based authentication. FortiGate captive portals use form-based authentication by default, presenting a web page where users enter credentials (username/password) that are verified against a configured authentication server (e.g., LDAP, RADIUS, or local user database). This method is designed for HTTP/HTTPS interception and does not rely on network-layer or certificate-based mechanisms.

Answer

IPsec pre-shared key authentication

Answer

X.509 certificate authentication

Answer

NTLM authentication

Question 9

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?

Accepted Answer

The Phase 2 proposal includes a mismatched proxy ID. 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.

Answer

The remote gateway is using aggressive mode

Answer

The FortiGate has a static route pointing to the VPN interface

Answer

The VPN is configured in policy-based mode

Question 10

A FortiGate admin has configured FSSO (Fortinet Single Sign-On) using Active Directory polling. Users authenticate to the domain but when accessing the internet through the FortiGate, they are still prompted for credentials. What is the MOST likely cause?

Accepted Answer

The FortiGate is not polling the AD domain controllers. In FSSO with Active Directory polling, the FortiGate must be configured to poll the domain controllers to retrieve user logon events. If polling is not set up or fails, the FortiGate will not have the user-to-IP mapping, and thus cannot bypass authentication for domain users, causing them to be prompted for credentials when accessing the internet.

Answer

The users are using non-Windows machines

Answer

The firewall policy does not have FSSO authentication enabled

Answer

The FortiGate is not joined to the domain

Question 11

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

Accepted Answer

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

Answer

POP3

Answer

LDAP

Answer

TACACS+

Question 12

An admin is configuring a dial-up IPsec VPN for remote users. The users will connect from various public IP addresses. Which Phase 1 configuration is required for the FortiGate to accept connections from unknown remote gateways?

Accepted Answer

Set the remote gateway to 0.0.0.0. For a dial-up IPsec VPN where remote users connect from dynamic public IP addresses, the FortiGate must be configured to accept connections from any remote gateway. Setting the remote gateway to 0.0.0.0 (or 0.0.0.0/0) in Phase 1 tells the FortiGate to accept IKE negotiation from any source IP, which is essential for dial-up scenarios. This is the standard method to allow unknown remote gateways to initiate the VPN tunnel.

Answer

Enable aggressive mode

Answer

Configure a static route to the remote users' subnet

Answer

Set the remote gateway to a specific IP address

Question 13

You run 'diagnose debug application ike -1' and see the following output: 'Initiator: no acceptable proposal'. What is the MOST likely cause of this error?

Accepted Answer

The Phase 1 encryption or hash algorithm is mismatched. The error 'no acceptable proposal' indicates that the IKE Phase 1 negotiation failed because the two VPN peers could not agree on a common set of security parameters. This is most commonly caused by a mismatch in the encryption algorithm (e.g., AES128 vs AES256) or the hash algorithm (e.g., SHA1 vs SHA256) configured on the FortiGate versus the remote peer. The pre-shared key is not checked until after Phase 1 completes, so it would not cause this specific error.

Answer

The pre-shared key is incorrect

Answer

The remote gateway is not reachable

Answer

The firewall policy is blocking UDP port 500

Question 14

In Fortinet ZTNA, what is the primary purpose of the ZTNA access proxy component?

Accepted Answer

To proxy connections to internal applications after authentication and device verification. The ZTNA access proxy is the core component that mediates user access to internal applications. It intercepts client requests, enforces authentication and device posture checks (via FortiClient telemetry), and then proxies the connection to the protected application. This ensures no direct network access is granted; all traffic must pass through the proxy, which validates trust before forwarding.

Answer

To act as a forward proxy for web traffic

Answer

To provide load balancing for multiple FortiGates

Answer

To terminate IPsec VPN tunnels

Question 15

An admin needs to configure an SSL VPN for remote users that only provides access to specific internal applications, not full network access. What feature should be configured?

Accepted Answer

Split tunneling. Split tunneling (Option C) is the correct feature because it allows the SSL VPN to route only traffic destined for specific internal applications through the encrypted tunnel, while all other traffic goes directly to the internet. This meets the requirement of providing access to specific internal applications without granting full network access, as split tunneling uses routing policies to selectively forward traffic based on destination IP addresses or application ports.

Answer

Full tunneling

Answer

Client certificate authentication

Answer

Web mode portal