NSE4 Practice Test 8 — 10 Questions

Question 1

A network administrator notices that some users can access blocked web categories despite a web filter profile applied to the policy. The admin runs 'diagnose debug rating' and sees 'rating not allow' for the category. What is the MOST likely cause?

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

Accepted Answer

The web filter profile has an 'override' configured for those users. The 'rating not allow' message in the 'diagnose debug rating' output indicates that the FortiGate's rating engine correctly identified the category as blocked by the web filter profile. However, if an 'override' is configured for specific users or groups, it allows them to bypass the blocked category. This explains why some users can access the site despite the profile blocking it, as the override takes precedence over the profile's default action.

Answer

The policy is not using the correct web filter profile

Answer

DNS filter is allowing the domain

Answer

The FortiGuard web filter database is outdated

Question 2

A medium-sized enterprise has a FortiGate 100F in NAT/Route mode with three interfaces: port1 (WAN, 203.0.113.1/24, gateway 203.0.113.254), port2 (internal, 192.168.1.1/24), and port3 (DMZ, 10.0.0.1/24). The internal network hosts a web server at 192.168.1.10 and a mail server at 192.168.1.20. The DMZ hosts a public web server at 10.0.0.10 and a public DNS server at 10.0.0.20. The company has a single public IP 203.0.113.1. The administrator has configured the following:
- Port forwarding: external HTTP to DMZ web server (10.0.0.10:80) and external DNS to DMZ DNS server (10.0.0.20:53).
- Outbound NAT (IP Pool) for internal users to 203.0.113.1.
- Firewall policies allowing internal to external, DMZ to external, and external to DMZ (for forwarded services).

Users report that they can access the Internet but cannot reach the internal web server (192.168.1.10) via its public IP (203.0.113.1:80). The DMZ web server is accessible from the Internet. What is the most likely cause?

Accepted Answer

The port forwarding rule maps the public IP to the DMZ server, not the internal server. The port forwarding rule is configured to forward external HTTP requests (port 80) to the DMZ web server at 10.0.0.10. The internal web server at 192.168.1.10 is not covered by any port forwarding rule. Therefore, when internal users try to access the public IP 203.0.113.1:80, the traffic is not redirected to the internal server, and the request fails. This is the primary cause, not a missing hairpin NAT or misconfigured outbound NAT.

Answer

The firewall policy from internal to DMZ is blocking traffic

Answer

Hairpin NAT is not enabled on the FortiGate

Answer

The IP Pool for outbound NAT is misconfigured

Question 3

An administrator is troubleshooting a connectivity issue. A ping from the FortiGate to 8.8.8.8 succeeds, but traffic from internal hosts to the internet is failing. The firewall policy allows the traffic. What is the most likely cause?

Accepted Answer

The internal hosts have the wrong default gateway configured. Since the FortiGate can ping 8.8.8.8, its default route and internet connectivity are working. The issue is that internal hosts cannot reach the internet, which points to a Layer 3 forwarding problem at the host level. The most likely cause is that the internal hosts have the wrong default gateway configured, so their traffic is not being sent to the FortiGate for routing.

Answer

The default route on the FortiGate is missing

Answer

DNS resolution is failing

Answer

The FortiGate's interface to the internal network is down

Question 4

A FortiGate is configured with flow-based antivirus and an IPS profile on a policy. The administrator runs 'diagnose ips packet-list' and sees that packets are being forwarded without inspection. What is the most likely reason?

Accepted Answer

The session is offloaded to the NPU and is not being sent to the IPS engine. When a FortiGate offloads a session to the NPU (Network Processor Unit), the traffic bypasses the CPU and therefore does not reach the IPS engine for inspection. The 'diagnose ips packet-list' command shows packets forwarded without inspection because the NPU handles them directly, and flow-based inspection requires the session to be processed by the IPS engine on the CPU. This is the most likely reason when the administrator observes packets bypassing inspection despite having flow-based antivirus and IPS profiles applied.

Answer

The antivirus profile is set to proxy-based, conflicting with flow-based IPS

Answer

The IPS profile is configured with 'monitor' mode instead of 'protect'

Answer

The traffic is UDP and flow-based inspection does not inspect UDP

Question 5

A FortiGate administrator configures a captive portal on a VDOM to authenticate users connecting to a guest SSID. The authentication method is set to LDAP. Users can reach the captive portal login page, but after entering valid credentials, they receive an authentication failure. The LDAP server is reachable from the FortiGate. What is the MOST likely cause?

Accepted Answer

The user is not a member of the configured user group. The most likely cause is that the user is not a member of the configured user group. In FortiGate, when LDAP authentication is used for a captive portal, the FortiGate first verifies the user's credentials against the LDAP server. Even if the credentials are valid, the FortiGate then checks whether the authenticated user belongs to a specific user group that is permitted to access the captive portal. If the user is not a member of that group, the authentication fails, even though the LDAP server itself accepts the credentials.

Answer

The captive portal is using HTTP instead of HTTPS

Answer

The captive portal interface is not in the same VDOM as the LDAP server

Answer

The LDAP server requires TLS and FortiGate is using plain LDAP

Question 6

A FortiGate admin notices that HTTPS traffic to a web server is not being scanned by the antivirus profile applied to the firewall policy. The admin confirms the policy is correct and antivirus is enabled. What is the MOST likely reason the traffic is not being scanned?

Accepted Answer

SSL/TLS deep inspection is not enabled on the firewall policy. HTTPS traffic is encrypted with SSL/TLS, so an antivirus profile cannot inspect the payload unless the firewall can decrypt the traffic. Even with antivirus enabled in the policy, without SSL/TLS deep inspection (also called SSL inspection or HTTPS decryption), FortiGate only sees encrypted packets and cannot scan for malware. Therefore, the most likely reason is that SSL/TLS deep inspection is not enabled on the firewall policy.

Answer

The web server's certificate is self-signed and FortiGate is rejecting the connection

Answer

The antivirus profile is configured for flow-based inspection instead of proxy-based

Answer

The FortiGuard antivirus subscription has expired

Question 7

A FortiGate administrator is configuring a route-based IPsec VPN between two FortiGate devices. After setting up the tunnel and firewall policies, traffic does not flow. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. 'get router info routing-table all' shows routes on both sides. However, pings from the local network to the remote network fail. What is the MOST likely cause?

Accepted Answer

The firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed. The tunnel is up and routes are present, indicating Phase 1 and Phase 2 negotiations succeeded. The most likely cause is that the firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed. In a route-based VPN, the policy must have the incoming interface as the source (e.g., internal) and the outgoing interface as the destination (e.g., the VPN tunnel interface). Reversing these prevents traffic from being matched, even though the tunnel is established.

Answer

The pre-shared key is incorrect

Answer

The remote FortiGate's static route points to the wrong local subnet

Answer

The Phase 2 proposal uses different encryption algorithms on each side

Question 8

A FortiGate admin creates a new firewall policy with source address object 'Internal_Net' and destination 'All'. After saving, traffic from 'Internal_Net' is not matching the new policy but instead matches an older policy with a broader source. What is the MOST likely cause?

Accepted Answer

The new policy is placed below the older policy in the policy list. A FortiGate firewall evaluates policies sequentially from top to bottom, applying the first match. If the new policy is placed below an older policy with a broader source definition, traffic from 'Internal_Net' will match the older policy first and never reach the new policy. Therefore, option B is the correct answer.

Answer

The source address object 'Internal_Net' has an incorrect subnet mask

Answer

The new policy is disabled

Answer

Traffic shaping is applied to the new policy and is interfering

Question 9

An admin runs the command 'diagnose firewall iprope list 100000' and sees the following output:
id=2000000000 action=deny flag=0x0 src-interface=any dst-interface=any proto=0 src-addr=0.0.0.0-255.255.255.255 dst-addr=0.0.0.0-255.255.255.255
What does this entry represent?

Accepted Answer

The implicit deny policy at the end of the policy list. The output shows an entry with id=2000000000, action=deny, and source/destination addresses covering all possible IPs (0.0.0.0-255.255.255.255). In FortiGate, the implicit deny policy is automatically inserted at the end of the policy list with a high ID (typically 2000000000) and matches any traffic that hasn't been permitted by earlier policies. This is not a user-created policy but the built-in default deny rule.

Answer

A loopback interface policy

Answer

A user-created deny policy that blocks all traffic

Answer

A NAT policy that translates all addresses

Question 10

A FortiGate admin has configured a firewall policy allowing traffic from the internal network (10.0.1.0/24) to the internet (any). Users report that they cannot access a specific website (203.0.113.5). The admin runs 'diagnose firewall fqdn list' and sees that the FQDN object used in a policy above the allow policy resolves to an IP that includes 203.0.113.5. What is the MOST likely cause?

Accepted Answer

The FQDN object resolved to the IP after the policy was created, but the policy lookup uses the cached IP and matches before the allow policy. The FQDN object in a policy above the allow policy resolved to an IP that includes 203.0.113.5. FortiGate performs policy lookup based on cached IP addresses for FQDN objects. Since the FQDN object's cached IP now matches the destination IP of the website, traffic hits the higher-priority policy (which likely denies or otherwise blocks the traffic) before reaching the allow policy. This is why users cannot access the website despite the allow policy existing.

Answer

The destination NAT on the allow policy is misconfigured

Answer

The FortiGate's DNS server is not resolving the FQDN correctly

Answer

The antivirus profile on the allow policy is blocking the website