Fortinet NSE 4 Network Security Professional NSE4 (NSE4) — Questions 901–975

To provide a floating management IP, the admin must set a dedicated management interface (which can be a physical interface or VLAN), assign an IP to that interface in the HA configuration, and ensure the interface is part of the HA managed interfaces so it synchronizes.

Option D is correct because in an active-passive HA cluster, the secondary unit must have a synchronized copy of the primary's configuration to take over traffic. If configuration synchronization is not enabled or fails, the secondary remains in standby but lacks the necessary policies and settings to handle traffic, so failover does not occur even though HA status appears normal.

Exemptions can be added in the SSL/SSH inspection profile to bypass inspection for specific destinations.

Application control relies on signatures to detect applications. If deep inspection is not enabled, encrypted traffic may not be identified correctly.

Flow-based inspection offloads traffic to the network processor (NPU) for forwarding without sending all packets to the CPU for inspection. The IPS diagnostic output showing packets forwarded without inspection indicates flow-based mode is skipping inspection for non-TCP traffic or when a session is offloaded.

In a FortiGate HA cluster, session synchronization is enabled by default for UDP sessions but not for TCP sessions (unless specifically configured). When the primary unit fails, the secondary unit takes over as primary and maintains all synchronized sessions, which includes UDP sessions. TCP sessions are not synchronized by default and will be dropped upon failover.

For a dial-up IPsec VPN, each spoke needs the hub's public IP or FQDN as the remote gateway. Authentication can be via pre-shared key or certificate. The spoke must also have a Phase 2 proposal that matches the hub's configuration.

Option C is correct because FortiGate firewall policies allow authentication to be enabled on a per-policy basis using the 'set auth-on-demand' or 'set auth-cert' options, which enforce user authentication before traffic is processed. This granular control enables administrators to apply authentication only to specific policies, such as those controlling access to sensitive resources, without affecting other traffic flows.

When SSL inspection is enabled and a specific HTTPS site is blocked despite not being in a blocked category, the issue often lies in the SSL/SSH inspection profile's certificate revocation check. If the FortiGate cannot verify the server's certificate revocation status (e.g., via OCSP or CRL), it may block the connection as a security precaution, even if the web filter category allows the URL. Option B directly addresses this by suggesting a review of the revocation check settings.

FortiGate log severities follow standard syslog: Emergency (0) is the highest severity, indicating system is unusable.

Option C is correct because DNS forwarding on FortiGate allows the device to act as a DNS relay, intercepting DNS queries from internal clients and forwarding them to a specified DNS server for security filtering. This is configured under Network > DNS by setting the system DNS to the desired server, which ensures all DNS traffic is redirected without requiring policy routing or firewall rule changes.

FQDN address objects can resolve to a list of IP addresses that change dynamically, making them suitable for frequently updated IP lists. Subnet objects are static.

Options A, B, and C are correct. Web filtering blocks malicious websites; antivirus blocks executable file downloads; IPS detects and blocks C2 traffic.

In active-active HA with session sync, sessions are synchronized periodically (every few seconds) or immediately depending on configuration. By default, sessions are synced every 200ms or when the session changes state.

Two-factor authentication is enabled by setting the authentication method to require both password and FortiToken. The 'Two-factor authentication' option must be enabled on the user group or user, not the policy itself.

The implicit deny policy is a built-in, unchangeable rule at the bottom of the FortiGate firewall policy list that drops all traffic not matching any explicit policy. It ensures that only explicitly permitted traffic is allowed, enforcing a default-deny security posture. This policy cannot be edited, removed, or reordered, and it applies to all traffic regardless of source.

Option D is correct. Even though the VPN tunnel is up, if there is no firewall policy allowing traffic from the dial-up interface to the internal network, the traffic will be dropped silently.

HTTPS (port 443) and SSH (port 22) are the only secure administrative access protocols that provide encrypted communication for remote management over the internet. HTTP and Telnet transmit credentials and data in plaintext, making them unsuitable for WAN-facing interfaces. FortiGate best practices mandate disabling all insecure protocols on external interfaces and enabling only HTTPS and SSH for administrative access.

In active-active HA, load balancing requires a load-balance method (like source IP hash or round-robin). Without a proper method, traffic may not distribute evenly.

The schedule object is configured to allow traffic only from Monday to Friday, 09:00-17:00. Since Saturday is outside this range, the firewall policy will deny or not match the traffic, even though the policy is enabled. This is the most direct and likely reason for the access failure.

Option B is correct because the 'admin-login-retry-lockout' setting (often referred to as 'admin-login-retry-limit' in older firmware) defines the number of consecutive failed administrative login attempts before the administrator account is locked out for a specified duration. This is a security feature to prevent brute-force attacks against the management interface.

FortiGate offers two modes for inspecting HTTPS: certificate inspection (which checks certificate validity but does not decrypt content) and deep inspection (which decrypts and inspects the content). Flow-based and proxy-based refer to the inspection mode for other security profiles, not specifically for HTTPS inspection type.

The proposal (encryption and authentication algorithms) and the Diffie-Hellman group must match between peers for Phase 1 to succeed. These are the key parameters negotiated during Phase 1.

Option A is correct because in active-active HA mode, the load-balance method must be set to 'load-balance' or 'weighted-load-balance' to ensure that session ownership is properly distributed and that session failover can occur. If the method is set to 'hub' or 'spoke', session synchronization and failover may not function as expected, as these modes are designed for different topologies.

Option C is correct because SSL VPN with FortiToken two-factor authentication meets the requirement for encrypted remote access with username/password plus a one-time passcode from a hardware token. SSL VPN provides encrypted tunnels over HTTPS, and FortiToken adds the required second factor, ensuring strong authentication even from untrusted networks.

Port Forwarding VIP (also called DNAT or destination NAT) is the correct choice because it translates a single internal server's IP and port (192.168.1.10:8080) to a specific public IP and port (203.0.113.10:80), allowing external HTTP users to reach the internal server. This is a one-to-one mapping of a public IP:port to a private IP:port, which is the exact definition of port forwarding in FortiGate.

Option C is correct because it specifies the internal network (10.0.0.0/8) as the source, the public DNS server (8.8.8.8) as the destination, and HTTPS (TCP/443) as the service, with an Accept action. This precisely matches the requirement to allow only HTTPS traffic from the internal network to that specific destination, blocking all other traffic by default via the implicit deny rule.

Option D is correct: SSL/SSH exemption list allows specific destinations to bypass deep inspection, while still applying other security profiles.

By default, hub-and-spoke only allows communication between spokes via the hub. To enable direct spoke-to-spoke, you need to add Phase 2 selectors with each other's subnets on the hub or configure dynamic routing (BGP/OSPF) to advertise routes between spokes. Another method is to use ADVPN (Auto Discovery VPN).

Central NAT must be disabled for policy-based NAT to work. When central NAT is enabled, it overrides the per-policy NAT settings.

A geography address object (also known as a geolocation object) allows the firewall to match traffic based on the source IP's registered country or region using GeoIP databases. This is the correct object type when the requirement is to block all traffic from a specific geographic region, as it evaluates the source IP against the FortiGate's built-in geolocation mapping.

FortiGate firewall policies control the establishment of new sessions based on the schedule. Once a session is established, it is tracked in the session table and continues to be forwarded even if the schedule ends, until the session naturally terminates or times out. This behavior ensures that ongoing traffic is not abruptly disrupted when a schedule expires.

The most likely missing configuration is a firewall policy to permit SNMP traffic from the NMS. Even though SNMP access is enabled on the interface, FortiGate uses firewall policies to control all traffic traversing between zones, including management traffic from an NMS. Without an explicit policy allowing UDP ports 161 (SNMP queries) and 162 (traps) from the NMS source to the FortiGate interface, the SNMP requests are dropped by the firewall.

Port scan detection is a type of anomaly detection in FortiGate's IPS profile that identifies reconnaissance attempts by monitoring for multiple connection attempts to different ports from a single source. This behavior deviates from normal traffic patterns and is flagged as anomalous, allowing the IPS to block potential scanning activity before an attack progresses.

Option B is correct because anomaly detection in IPS profiles uses a threshold-based mechanism; to block, the action must be set to 'block' (or 'reset' for TCP). Setting the action to 'pass' allows the traffic.

Option D (IP Pool type: Overload) is correct because it enables Port Address Translation (PAT), allowing 200 internal users to share a single public IP (203.0.113.1) by multiplexing sessions across the 2000 available ports. Option E (Set 'Fixed Port Range' on the IP Pool) is correct because it assigns a deterministic source port range to each user, which is required for logging and auditing applications that expect consistent port mappings.

Option A is correct. The administrator must verify that the relevant IPS signatures are enabled and set to an action like 'block' or 'reset'.

Option B is correct because configuring a secondary strategy (e.g., fallback to broadband) allows the SD-WAN rule to automatically steer voice traffic to the best available link when the primary MPLS link fails the SLA (latency > 50 ms). This ensures continuous SLA compliance without manual intervention, leveraging Fortinet's SD-WAN dynamic path selection based on real-time performance metrics.

FortiGate can log to multiple destinations simultaneously by configuring both local and remote logging.

'Initial contact' is a notification sent when a peer clears its Phase 1 and Phase 2 SAs. It typically indicates that the remote peer has restarted or its configuration has been reloaded. It is not an error but an informational message.

Checking the firewall policy list helps identify if an allow policy exists and its order. Running a packet capture helps see if traffic reaches the FortiGate and is being matched. Option A and D are correct.

Option C is correct because FortiGate HA heartbeat interfaces must be on the same subnet to allow the heartbeat packets (typically UDP port 496) to be exchanged directly between the primary and secondary units. This ensures Layer 2 adjacency is maintained for reliable failure detection and synchronization.

Restricting administrative access to trusted hosts (Option B) is a fundamental security best practice that limits the source IP addresses allowed to connect to the FortiGate management interface. By configuring a trusted host list, the FortiGate will only accept administrative sessions (e.g., HTTPS, SSH, or Telnet) from specified IP addresses or subnets, effectively blocking all unauthorized sources. This reduces the attack surface and prevents brute-force or credential-stuffing attacks from untrusted networks.

Option A is correct because FortiGate firewall policies are evaluated sequentially from top to bottom, and the first matching policy is applied. By placing a deny policy for source 10.0.0.99 to destination 'all' on the WAN interface first, traffic from that IP is blocked. Then a subsequent allow policy for all other traffic (source 'all') permits everything else, ensuring the specific IP is blocked while all other traffic is allowed.

When a packet arrives at a FortiGate interface, the firewall policy lookup begins by matching the incoming interface. This is because the interface is the first parameter evaluated in the policy-matching sequence, as defined by FortiGate's session-based architecture. Only after the interface match is successful does the FortiGate proceed to evaluate source address, destination address, service, and schedule.

Option D is correct because the output shows `proto=6`, which is the protocol number for TCP, and `dport=443` indicates the destination port is HTTPS. The `duration=3600` field means the session has been active for 3600 seconds (1 hour), and `expire=3599` shows the remaining lifetime in seconds. This confirms an active TCP session to port 443 that has been established for one hour.

Option D is correct: Protocol decoders parse application layer protocols to normalize traffic before signature matching, enabling detection of evasion techniques.

To allow internal users to access the server via private IP, a firewall policy must allow the traffic. To allow external users, a VIP is used to map the public IP to the private IP, and a corresponding policy is needed.

Overload NAT (PAT) allows multiple internal hosts to share a single public IP by translating source ports. To achieve this, you must create an IP pool with type 'Overload' that specifies the public IP address (203.0.113.1) and then enable NAT on the firewall policy, selecting that IP pool. This configuration ensures outbound HTTP/HTTPS traffic is translated to the single public IP with unique source ports.

Even if the SSL VPN policy is correct, the traffic must also be permitted by the firewall policies between the SSL VPN interface and the internal network. A common mistake is not having a firewall policy that allows traffic from the SSL VPN interface (e.g., ssl.root) to the internal network.

FortiGate firewall policies operate on a 'first-match' basis, and if no policy matches the traffic, the default action is to deny the traffic. This is a fundamental security principle to ensure that only explicitly permitted traffic is allowed through the firewall. The implicit deny rule is automatically applied at the end of the policy list and cannot be removed or modified.

ZTNA requires a ZTNA proxy to protect the application, a ZTNA rule (policy) to define access criteria, and an access proxy (or application) that listens for incoming connections. Option A, C, and D are correct.

For SSL VPN tunnel mode, split-tunneling settings determine which traffic goes through the tunnel. If split-tunneling is not configured, the remote user's traffic may not be routed to the FortiGate properly. However, more commonly, the firewall policy between the SSL VPN interface and the internal network is missing or incorrect.

Option A is correct because it configures a Virtual IP (VIP) that maps the public IP 203.0.113.10 on TCP port 25 (SMTP) to the internal mail server IP 10.0.0.5 on port 25. This allows inbound SMTP traffic from the internet to reach the mail server in the DMZ, performing both destination NAT (DNAT) and port forwarding for the specific SMTP service.

Central SNAT rules are evaluated in order of priority, and the first matching rule is applied. If a higher-priority Central SNAT rule matches the traffic before the intended rule with the specific public IP, the traffic will be translated to the IP defined in that higher-priority rule, causing the applications to fail. Since no policy-based NAT rules exist, the issue lies in the Central SNAT rule priority order.

HA configuration requires physical connection, mode selection, priority, and interface monitoring before reboot.

The 'diagnose sniffer packet' command captures packets in real-time on a specified interface.

Option B is correct because web filtering operates at the application layer and inspects HTTP/HTTPS URLs. If SSL inspection is not enabled, the FortiGate cannot decrypt the encrypted SMTP or IMAP/POP3 traffic to extract URLs from the body of emails. Without decryption, the web filter profile cannot see the phishing links inside encrypted email messages, so they bypass the filter regardless of the category being blocked.

SNMPv3 requires a security level to define whether authentication and encryption are used. The security level (authPriv or authNoPriv) determines the operational mode for the user, making it a mandatory configuration element. Without specifying the security level, the FortiGate cannot enforce the appropriate authentication and privacy policies for SNMPv3 communications.

Policy-based routing (PBR) on FortiGate overrides the routing table only when the traffic matches all configured criteria, including the source address. If the source address in the PBR rule does not match 192.168.1.0/24 exactly (e.g., a typo, wrong subnet mask, or missing entry), the traffic falls through to the default route via ISP2. This is the most likely cause because PBR rules are evaluated before the routing table, but only for matching traffic.

ZTNA (Zero Trust Network Access) enables agentless access to applications based on identity and context.

Option B is correct because specifying exact services (e.g., TCP/443, TCP/22) enforces least privilege by allowing only the necessary protocols and ports, reducing the attack surface. In FortiGate firewall policies, this is configured under the 'Service' field, where you can select predefined services or create custom ones to match specific TCP/UDP port numbers. This prevents overly permissive rules that could expose services like SMB (TCP/445) or RDP (TCP/3389) unintentionally.

The 'implicit deny' policy on a FortiGate is a default, last-resort rule that denies all traffic not matching any explicit firewall policy. It ensures that any packet that does not meet the source, destination, service, or schedule criteria of a configured policy is dropped, enforcing a default-deny security posture. This behavior is fundamental to stateful firewall operation and prevents unauthorized traffic from traversing the device.

'no matching policy' in debug flow indicates that the traffic did not match any firewall policy. Even if a policy exists, it may not match due to incorrect source/destination interfaces, addresses, or other criteria. A common cause is that the traffic is coming from an interface that is not covered by the policy or the policy is disabled.

The 'diagnose firewall iprope list' command confirms the allow policy exists in the FortiGate's kernel policy list, meaning it is present and enabled. However, FortiGate evaluates policies in sequential order based on policy ID (lowest first), so a deny policy with a lower ID that matches the same traffic (e.g., from internal to DMZ) will be hit first, blocking the HTTP request before the allow policy can be evaluated. This is the most likely cause because the policy is present but not being matched due to ordering.

The fourth parameter in the diagnose sniffer packet command specifies the number of packets to capture.

The URL filter is applied before FortiGuard categories and can override the category rating. A static URL filter entry blocking the specific website would cause the block even if the category is allowed.

FortiGate supports geography-based address objects that use IP geolocation databases to match traffic by country.

Flow-based inspection uses the FortiASIC for accelerated scanning and has lower latency, while proxy-based inspection reassembles the entire content before scanning, allowing for more thorough detection but with higher resource usage.

Option B is correct because source NAT (SNAT) on a FortiGate is configured at the firewall policy level, not on the interface or via a static route. By enabling NAT on the firewall policy from the internal network to the internet, the FortiGate automatically translates the source IP of traffic egressing port1 to the interface's primary IP address (the public IP). This is the standard method for implementing source NAT in FortiOS, as defined in the FortiGate Administration Guide.