NSE7 Advanced VPN and Zero Trust Practice Question
A FortiGate administrator is troubleshooting a ZTNA problem where users are unable to connect to an internal application via FortiClient. FortiClient reports 'Connection refused'. The FortiGate ZTNA gateway is configured correctly. Which THREE steps should the administrator take to diagnose the issue?
⚠ Common exam trap
The trap is selecting generic steps like rebooting or checking antivirus, which are not relevant to ZTNA connectivity issues.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Verify that FortiClient can reach the ZTNA gateway's IP and port
Option B is correct because a 'Connection refused' error from FortiClient typically indicates a TCP-level reachability problem to the ZTNA gateway, so verifying that the client can reach the gateway's IP and port (for example, with telnet or Test-NetConnection on the configured access proxy port) confirms whether the failure is at the network path or at the gateway itself. Option C is correct because the ZTNA access proxy rule defines the application mapping (external FQDN/port to the real internal server and port), and an incorrect mapping would cause the gateway to reject or misroute the connection even when the gateway is otherwise configured correctly. Option E is correct because the FortiGate must be able to reach the backend application server; if the server is down, the port is closed, or a firewall/routing issue blocks the FortiGate-to-server path, the access proxy cannot complete the connection and the client sees a refused or failed connection. Option A is not relevant because antivirus update status does not affect ZTNA access proxy connectivity or TCP reachability. Option D is not a diagnostic step; rebooting the FortiClient computer does not isolate the cause and may only mask a transient issue.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Check the FortiGate's antivirus update status
Why it's wrong here
Antivirus signature freshness has no bearing on whether the ZTNA gateway accepts a TCP session; 'Connection refused' indicates the listener or policy rejected it. Scanning updates matter for malware inspection profiles, so this step would be valid when investigating detection gaps or content-scanning failures rather than connectivity.
- ✓
Verify that FortiClient can reach the ZTNA gateway's IP and port
Why this is correct
Reachability testing isolates transport-layer failures before deeper ZTNA inspection. Since FortiClient reports "Connection refused", the TCP handshake to the gateway's access port is likely failing — often due to routing, firewall policy, or an incorrect port. Confirming IP and port reachability satisfies the stem's requirement to diagnose connectivity before examining ZTNA tags or Microsoft Entra ID integration.
- ✓
Examine the ZTNA access proxy rule to ensure the application mapping is correct
Why this is correct
Examining the ZTNA access proxy rule verifies that the destination mapping, port, and real server match the internal application FortiClient is attempting to reach. A misconfigured mapping causes the access proxy to reject or misroute the connection, producing the 'Connection refused' error even though the gateway itself is configured correctly.
- ✗
Reboot the FortiClient computer
Why it's wrong here
Rebooting the endpoint clears no diagnostic evidence and cannot explain a server-side refusal; the gateway actively rejected the session, so the cause lies in FortiGate ZTNA policy, tags, or the application listener. Rebooting is legitimate for clearing a wedged FortiClient service or stale tunnel state, not a refused connection.
- ✓
Verify that the application server is reachable from the FortiGate (e.g., ping or telnet)
Why this is correct
A 'Connection refused' response indicates the TCP SYN reached a host that actively rejected it, so the FortiGate-to-server path and listening port must be confirmed. Pinging or telnetting from the FortiGate isolates whether the internal application server itself is reachable and accepting connections, ruling out a backend failure rather than a ZTNA policy fault.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 718 original NSE7 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Fortinet exam blueprint
This NSE7 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE7 exam.