Courseiva
Firewall Policies and NATmediumMultiple ChoiceObjective-mapped

NSE4 Firewall Policies and NAT Practice Question

A network admin runs 'diag sys session filter proto 6' and 'diag sys session list' and sees many sessions with state 'SYN_SENT' to a public web server. The firewall policy allows TCP/443. What is the MOST likely cause?

⚠ Common exam trap

It's easy for candidates to assume 'SYN_SENT' always indicates a server-side issue (like overload or firewall blocking), but in FortiGate diagnostics, it specifically points to a missing or misconfigured destination NAT when the destination is a public IP that must be translated to an internal server.

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

The destination NAT (VIP) for the web server is not configured

The 'diag sys session filter proto 6' command filters for TCP sessions (protocol 6). Seeing many sessions stuck in 'SYN_SENT' state indicates that the FortiGate is sending SYN packets to the destination but never receiving a SYN-ACK reply. Since the firewall policy allows TCP/443, the most likely cause is that the destination NAT (VIP) for the public web server is not configured. Without a VIP, the FortiGate forwards the packet with the original destination IP (the public IP), which may not be routable or may not exist on the internal network, causing the SYN to be sent into a black hole.

Answer analysis

Option-by-option breakdown

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

  • The web server is overloaded and dropping connections

    Why it's wrong here

    While an overloaded web server could theoretically cause dropped TCP SYNs, it is not the most likely issue in a FortiGate session-state context. When sessions remain in SYN_SENT, the firewall itself is often failing to forward the SYN because no destination NAT (VIP) exists to map the public destination IP to the internal server. The admin should first verify the VIP configuration before suspecting server load, as the session table will show the destination IP as a public address with no translation.

  • The policy is in proxy mode but should be flow mode

    Why it's wrong here

    Proxy mode and flow mode both process the TCP three-way handshake identically; the difference only appears after the session is established, affecting how packets are inspected. If a policy is configured for proxy mode, the FortiGate still creates a session and forwards the SYN, so the SYN_SENT state would not be caused by the inspection mode. Changing to flow mode would not solve a missing DNAT problem, because the packet would still lack a translated destination address to reach the internal server.

  • The destination NAT (VIP) for the web server is not configured

    Why this is correct

    The destination NAT (VIP) is the critical missing element in this scenario. When a client sends a TCP SYN to the web server's public IP, the FortiGate must use a matching VIP to translate that destination to the server's private IP address; without it, the firewall has no next hop or internal server to forward the packet to. As a result, the SYN is dropped or consumed by the firewall itself, the server never receives the request, and the client's session stays in SYN_SENT.

  • The firewall policy has session TTL set too low

    Why it's wrong here

    Session TTL settings in FortiGate control how long a session remains in the session table after it has been established, not whether the initial handshake completes. A very low TTL could terminate idle sessions, but it would not affect a session in SYN_SENT because that state exists during the setup phase before any established session is tracked. Additionally, the initial SYN packet is forwarded based on policy and NAT rules, so a low TTL would not influence the client receiving a SYN-ACK.

Visual reference

Inside (Private) PC-A 10.0.0.1 PC-B 10.0.0.2 NAT Router Outside (Public) 203.0.113.1 Inside Global Server PAT: many private IPs share one public IP via unique port numbers

About these practice questions

One of 282 original NSE4 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 →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This NSE4 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 NSE4 exam.