NSE7 Advanced VPN and Zero Trust Practice Test 5 — 15 Questions

Question 1

A network administrator is configuring a hub-and-spoke ADVPN with FortiGates. The spokes are behind NAT and use dynamic IPs. The hub has a static IP. Which IKEv2 configuration is REQUIRED to allow the spokes to initiate the VPN and receive shortcut tunnels?

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

Accepted Answer

Set the phase1 remote-gateway to 0.0.0.0 and enable 'accept-any-remote-gateway' on the hub. In a hub-and-spoke ADVPN where spokes are behind NAT with dynamic IPs, the hub must accept IKEv2 connections from any remote gateway. Setting the phase1 remote-gateway to 0.0.0.0 and enabling accept-any-remote-gateway allows the hub to accept connections from spokes with unknown or changing public IPs, which is required for spokes to initiate the VPN and receive shortcut tunnels.

Answer

Set IKE version 2 to aggressive mode to allow rapid negotiation

Answer

Configure the hub with a static IP in the phase1 local-gateway interface

Answer

Use a preshared key and set the local ID to the spoke's public IP

Question 2

You run 'diagnose vpn ike gateway list' on a FortiGate hub and see the following output for a spoke connection: IKE SA state: ESTABLISHED, IPsec SA state: UP, but the spoke cannot route traffic to other spokes. The ADVPN shortcut tunnel is not being established. What is the MOST likely cause?

Accepted Answer

The hub has a static route for the spoke subnet pointing to the tunnel interface. ADVPN shortcut tunnels are established when a spoke receives a shortcut offer from the hub and the hub does not already have a route that forces inter-spoke traffic through itself. If the hub has a static route for the spoke subnet pointing to the tunnel interface, the hub advertises that route and the spoke never triggers a shortcut, so inter-spoke traffic keeps traversing the hub.

Answer

DPD is not configured on the hub

Answer

The spoke's phase2 proposal does not match the hub's proposal

Answer

The spoke is using a different IKE version than the hub

Question 3

A FortiGate is configured as a SAML service provider (SP) for SSO. Users authenticate via an external IdP. After successful authentication, the FortiGate should enforce a firewall policy based on the user's group membership. Which FortiGate setting must be enabled to receive group information from the IdP?

Accepted Answer

Configure the 'user-group' attribute in the SAML SP settings. For FortiGate acting as a SAML SP, the user-group attribute must be configured in the SAML SP settings so the FortiGate knows which SAML assertion attribute carries group membership from the IdP. Once mapped, the FortiGate can match firewall policies based on the user's group. This attribute configuration is what enables group-based policy enforcement after SSO.

Answer

Enable 'Require IdP Certificate Validation'

Answer

Create a separate firewall policy for each user

Answer

Enable 'Auto-Provision Users' on FortiGate

Question 4

A network administrator is troubleshooting an IPsec VPN between two FortiGates. The phase1 is up, but phase2 keeps failing to establish. The administrator runs 'diagnose vpn ike log' and sees: 'no proposal chosen'. Both sides have the same phase2 configuration: AES256-SHA256, DH group 14, 3600 seconds lifetime. What is the MOST likely cause?

Accepted Answer

The phase2 local and remote subnets do not match on both sides. Even if the encryption/authentication proposals match, a common issue is a mismatch in the local and remote subnets (selectors). The phase2 negotiation requires matching traffic selectors. If one side has 192.168.1.0/24 and the other has 10.0.0.0/8, the proposals will be rejected. Option C is correct.

Answer

The NAT traversal setting is inconsistent

Answer

The IKE version is different on each side

Answer

The pre-shared key is incorrect

Question 5

A FortiGate is configured with a ZTNA access proxy rule for a web application. The administrator wants to enforce that only devices with a specific FortiClient tag (e.g., 'Compliant') can access the application. Where is this tag-based access control configured?

Accepted Answer

In the ZTNA access proxy rule under the ZTNA gateway configuration. The FortiClient tag-based access control is configured within the ZTNA access proxy rule under the ZTNA gateway configuration on the FortiGate. This rule specifies which tags (e.g., 'Compliant') are required for access, and the FortiGate enforces this by checking the tags presented by FortiClient EMS during the ZTNA connection. This is the precise location where tag-based enforcement is defined.

Answer

In the FortiClient EMS policy

Answer

In the firewall policy that permits traffic from the ZTNA gateway to the application

Answer

In the SSL inspection profile

Question 6

A FortiGate is configured with two VPN tunnels to different remote sites. The administrator notices that traffic is not load-balanced across the tunnels; all traffic uses the first tunnel. The administrator wants to use ECMP (Equal Cost Multi-Path) routing. Which two actions are required? (Choose two.)

Accepted Answer

Set the same distance and priority for both static routes. Option A is correct because ECMP requires the competing routes to be equal-cost: the static routes pointing at the two VPN tunnels must have the same distance and the same priority, otherwise FortiGate installs only the best route and all traffic follows the first tunnel. Option D is correct because FortiGate only performs ECMP when the feature is enabled in the routing settings (config system settings, set ecmp enable), so without it the equal-cost routes are not used for multi-path forwarding. Option B is not required because the IKE version (IKEv1 vs IKEv2) is a tunnel negotiation parameter and does not affect route selection or ECMP eligibility. Option C is not required because matching phase2 lifetimes only influence IPsec SA rekeying, not whether the routes are treated as equal cost.

Answer

Configure both tunnels to use the same IKE version

Answer

Set the same phase2 lifetime for both tunnels

Question 7

A FortiGate administrator is configuring a multi-peer IPsec VPN where two remote sites connect to a central hub. The administrator wants to ensure that if one remote site loses connectivity, the other site can still reach the hub. Which configuration is essential?

Accepted Answer

Configure separate phase1 interfaces for each remote site. In a multi-peer IPsec VPN hub-and-spoke topology, each remote site must have its own phase1 interface to maintain independent security associations (SAs). If a single phase1 interface is shared, the loss of one remote peer can disrupt the SA state for all peers, potentially breaking connectivity for the other remote site. Configuring separate phase1 interfaces ensures that each remote site's VPN tunnel operates independently, so a failure at one site does not affect the other.

Answer

Use the same preshared key for both remote sites

Answer

Enable auto-negotiation on all phase1 interfaces

Answer

Configure a single phase1 interface with multiple remote IPs

Question 8

A network administrator is configuring a hub-and-spoke ADVPN with BGP over the VPN tunnels. Which TWO conditions are necessary for the spokes to establish direct shortcut tunnels between each other?

Accepted Answer

BGP must be configured on all FortiGates (hub and spokes) to exchange routing information. Option B is correct because ADVPN shortcut establishment relies on BGP: the hub and all spokes must run BGP so that the hub can propagate the routes (and the shortcut/ADVPN-related attributes) that let a spoke learn the remote spoke's network and trigger a direct tunnel. Option D is correct because, by default, the hub rewrites the BGP next-hop to itself when advertising spoke routes; configuring 'set next-hop-self disable' on the hub's BGP neighbor group preserves the originating spoke's next-hop, allowing the receiving spoke to resolve the route over a direct shortcut tunnel instead of sending traffic through the hub. Option A is not required because IKE phase2 proposals only need to match between the two peers negotiating a given tunnel, not across all spokes. Option C is not required because spokes can use different IKE versions as long as each individual spoke-to-spoke negotiation is compatible. Option E is not required because dynamic routing via BGP, not static routes on the hub, drives shortcut route resolution.

Answer

The spokes must have identical phase2 proposals

Answer

The spokes must use the same IKE version

Answer

The hub must have static routes for each spoke's LAN subnet

Question 9

A FortiGate is acting as a SAML Service Provider (SP) for user authentication. Which TWO of the following are required for successful SAML SSO?

Accepted Answer

The IdP's metadata must be imported to the FortiGate. Option B is correct because the FortiGate, acting as the SAML SP, must import the IdP's metadata (or manually configure the IdP entity ID, SSO URL, and signing certificate) so it can validate the IdP's assertions and know where to send authentication requests. Option E is correct because the SP requires a local certificate to sign SAML authentication requests and to decrypt/validate the encrypted assertions returned by the IdP, which is configured under the FortiGate's SAML SP settings. Option A is not required because the FortiGate does not need a static public IP; it only needs to be reachable by the IdP and users via its configured hostname/FQDN. Option C is not required because SAML federation is independent of Active Directory domain membership; the IdP handles directory authentication. Option D is not required because SAML SSO relies on X.509 certificates and metadata for trust, not a pre-shared key.

Answer

The FortiGate must have a static public IP address

Answer

The users must be in the same Active Directory domain as the FortiGate

Answer

A pre-shared key must be configured

Question 10

A network administrator is troubleshooting an ADVPN deployment. Spoke FortiGates can communicate with the hub, but shortcut tunnels between spokes are not being established. The administrator verifies that IKE and IPsec settings are correct on all devices. What is the MOST likely cause?

Accepted Answer

The hub's phase2 configuration has 'auto-negotiate' disabled. In ADVPN, the hub advertises shortcuts to spokes via IKEv2, and spokes initiate shortcut tunnels directly to each other. The hub's phase2 selector must have `auto-negotiate` enabled so the hub can dynamically negotiate the shortcut SA with the destination spoke when forwarding the first packet. If `auto-negotiate` is disabled on the hub's phase2, the hub will not bring up the shortcut tunnel on demand, so spokes never establish direct tunnels even though IKE/IPsec parameters are otherwise correct.

Answer

Dead Peer Detection (DPD) is disabled on the hub

Answer

The hub's phase1 configuration has 'auto-negotiate' disabled

Answer

The spokes have different IKE versions configured

Question 11

An administrator configures a ZTNA proxy rule to allow access to an internal application. Users can connect to the FortiGate ZTNA gateway but receive a '403 Forbidden' error. Which step should the administrator take to resolve the issue?

Accepted Answer

Check that the ZTNA proxy rule's action is set to 'accept' and the correct tags are specified. A '403 Forbidden' error in ZTNA typically indicates that the proxy rule is not configured to allow access. The administrator should verify that the ZTNA proxy rule's action is set to 'accept' and that the correct ZTNA tags are specified, as these determine whether the user is granted access based on endpoint posture. Without the correct action and tags, the request is denied.

Answer

Disable the 'require ZTNA tag' option on the proxy rule

Answer

Ensure the application is reachable from the FortiGate with a ping

Answer

Verify that the application's firewall policy has an SSL inspection profile applied

Question 12

A FortiGate administrator observes the following CLI output from 'diagnose vpn ike gateway list':
vd: root/0
name: VPN_TO_HUB
version: IKEv2
status: up
mode: main
DPD: on
...
Number of IPsec tunnels: 1
  name: phase2_tunnel
  status: up
  inbound: 0 bytes
  outbound: 0 bytes
The tunnel shows up but no traffic is passing. What is the MOST likely cause?

Accepted Answer

Firewall policies are not configured to permit traffic through the VPN tunnel. The output shows the IKE gateway is up but the IPsec tunnel has zero traffic. This often indicates a policy or routing misconfiguration. The most common cause is missing firewall policies to allow traffic through the tunnel.

Answer

Dead Peer Detection is disabled

Answer

The phase1 proposal is mismatched

Answer

The tunnel is in 'down' status

Question 13

An administrator wants to integrate FortiClient EMS with FortiGate for ZTNA. Which protocol must be allowed between FortiGate and FortiClient EMS?

Accepted Answer

HTTPS (TCP/443). For ZTNA integration, FortiGate communicates with FortiClient EMS over HTTPS (TCP/443) to exchange authentication and policy information. SNMP is not used for this purpose.

Answer

LDAP (TCP/389)

Answer

SNMP (UDP/161)

Answer

Syslog (UDP/514)

Question 14

An administrator configures OSPF over an IPsec VPN overlay between two FortiGates. The OSPF neighbors show a state of 'EXSTART/EXCHANGE' but never reach 'FULL'. The IPsec tunnel is up and passes ICMP traffic. What is the MOST likely cause?

Accepted Answer

The OSPF hello interval is mismatched. The EXSTART/EXCHANGE state indicates the routers are attempting to exchange OSPF database information. If the OSPF hello intervals are mismatched, the routers may not maintain a stable adjacency even after reaching EXSTART, preventing the transition to FULL. This is because each router expects hello packets at specific intervals; a mismatch can cause the neighbor to be declared dead and reset the adjacency, cycling through states but never reaching FULL.

Answer

The MTU on the tunnel interface is too large

Answer

OSPF is not enabled on the tunnel interface

Answer

The IPsec tunnel is using ESP with authentication

Question 15

An administrator configures a ZTNA gateway with inline CASB to monitor SaaS applications. Users report that access to Salesforce is blocked. The administrator reviews the ZTNA proxy rule and sees that inline CASB is enabled with a 'monitor-only' action. What is the MOST likely reason for the block?

Accepted Answer

A separate application control profile is blocking Salesforce. The inline CASB profile is set to 'monitor-only', which means it should not block traffic. Therefore, the block is most likely caused by another security profile, such as an application control profile, that is blocking Salesforce. The question states the ZTNA proxy rule has inline CASB enabled with monitor-only, so CASB is not the blocker.

Answer

The inline CASB profile is set to 'block' for Salesforce

Answer

The ZTNA proxy rule does not have SSL inspection enabled

Answer

FortiClient EMS is not assigning the required ZTNA tags