NSE4 Authentication and VPN Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

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

  Why this is correct

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

• ✓

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

  Why this is correct

  Assigning an IP address and completing TLS authentication only creates a secure tunnel endpoint; the FortiGate still evaluates traffic with its firewall rules. You must create policies whose incoming interface is the SSL VPN (ssl.root) virtual interface and whose outgoing interface is the destination internal network, specifying the allowed destination addresses and services. Without such a policy, the FortiGate silently drops the decrypted VPN traffic, so the tunnel appears established but users cannot reach any internal resources.

• ✗

  Configure split tunneling to reduce load on the FortiGate.

  Why it's wrong here

  Split tunneling is an optional routing strategy, not a deployment requirement: it directs only traffic destined for selected internal subnets into the VPN tunnel while other user traffic exits directly through the client's local Internet connection. Although this reduces the amount of traffic the FortiGate must encrypt and forward, it also means most of the client's traffic bypasses FortiGate inspection and can violate a full-network-access security policy. For this design, forcing all traffic through the tunnel is more appropriate, and load reduction alone does not justify enabling an option that weakens centralized security.

• ✗

  Use certificate-based authentication for all users.

  Why it's wrong here

  Certificate-based authentication, while stronger than passwords, is not a mandatory component of an SSL VPN deployment. FortiGate supports multiple authentication methods for SSL VPN portals: local database accounts, LDAP/Active Directory, RADIUS, and multi-factor authentication, and any of these can satisfy the security requirements depending on the environment. Requiring certificates for all users forces a PKI infrastructure and per-client certificate provisioning, which is operational overhead and is orthogonal to the core concern of enabling tunnel access and scalability.

• ✗

  Enable port forwarding for RDP and SSH.

  Why it's wrong here

  Port forwarding is a legacy or specialized SSL VPN mode used to publish individual TCP/UDP services, such as RDP or SSH, without creating a full virtual L3 tunnel. In a full tunnel-mode deployment, remote clients receive a virtual IP and can connect directly to internal server addresses through the firewall policy, so no port-forward mapping is needed. Enabling port forwarding could even restrict access to only the forwarded ports rather than providing the full internal network reachability that the administrator is designing for.

Go deeper

Related to this question