NSE4 Authentication and VPN Practice Test 9 — 15 Questions

Question 1

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

Accepted Answer

Route-based uses a tunnel interface, policy-based uses firewall policies to define traffic selectors.. 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.

Answer

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

Answer

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

Answer

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

Question 2

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?

Accepted Answer

The IPsec VPN is using the physical interface IP instead of a virtual IP (VIP) or floating IP.. 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.

Answer

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

Answer

The firewall policies for VPN traffic are not synchronized.

Answer

The HA heartbeat interface is down.

Question 3

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?

Accepted Answer

Set Phase 2 selectors to 0.0.0.0/0 on the hub's side.. 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.

Answer

Enable NAT on the hub's tunnel interface.

Answer

Configure the hub as a DNS server for the spokes.

Answer

Configure IKEv2 instead of IKEv1 on all tunnels.

Question 4

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?

Accepted Answer

The Phase 2 local and remote subnets do not match on both ends. 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.

Answer

The IKE version is mismatched (IKEv1 vs IKEv2)

Answer

The pre-shared key is incorrect

Answer

The firewall policies are blocking IKE traffic on UDP port 500

Question 5

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?

Accepted Answer

There is no firewall policy permitting traffic from the dial-up interface to the destination network. 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.

Answer

The Phase 2 proposal uses AES256 but the remote client only supports AES128

Answer

The FortiGate's routing table does not have a route to the remote user's subnet

Answer

The remote user's FortiClient is blocking split tunneling

Question 6

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?

Accepted Answer

In the IPsec Phase 1 configuration, set the peer type to 'dialup' and specify the user group under authentication. 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.

Answer

Enable LDAP over TLS (LDAPS) on the FortiGate

Answer

Assign the LDAP user group to a firewall policy

Answer

Configure a RADIUS server as an intermediate proxy between FortiGate and LDAP

Question 7

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?

Accepted Answer

Under the SSL VPN portal, configure 'URL Access' to allow only https://internal-app.company.local. 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.

Answer

In the SSL VPN portal, set the default bookmark to the application URL

Answer

Configure a firewall policy that allows traffic only to the application's IP address

Answer

Enable split tunneling under the SSL VPN settings

Question 8

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?

Accepted Answer

The firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed. 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.

Answer

The pre-shared key is incorrect

Answer

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

Answer

The Phase 2 proposal uses different encryption algorithms on each side

Question 9

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 10

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 11

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 12

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 13

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?

Accepted Answer

Enable 'add-route' on the hub Phase 2. 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.

Answer

Set the hub as the default gateway on each spoke

Answer

Use policy-based VPN instead of route-based

Answer

Configure NAT on the hub

Question 14

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?

Accepted Answer

Ensure the tunnel interface is added to the BGP neighbor configuration. 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.

Answer

Disable anti-replay on the tunnel

Answer

Enable NAT traversal

Answer

Check the Phase 1 proposal

Question 15

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?

Accepted Answer

There is no firewall policy allowing traffic through the VPN tunnel. 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.

Answer

Aggressive mode should be used instead of main mode

Answer

The pre-shared key is incorrect

Answer

The phase2 proposal does not match between peers