Firewall Policies and NAT →mediumMultiple Choice

NSE4 Firewall Policies and NAT Practice Question

An administrator configures a firewall policy with source address 'internal_net' (10.0.0.0/16) and destination address 'server_farm' (10.10.10.0/24). The action is set to ACCEPT with NAT enabled. However, traffic from 10.0.1.100 to 10.10.10.50 is being denied. What is the most likely cause?

⚠ Common exam trap

Test-takers frequently assume the configured ACCEPT policy will apply because it matches the traffic, forgetting that FortiGate uses first-match logic and a higher-priority deny policy can override it.

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

✓

There is a deny policy above this policy that matches the traffic

The most likely cause is that a deny policy with a higher priority (lower sequence number) exists above the ACCEPT policy in the firewall policy list. FortiGate evaluates policies sequentially from top to bottom, and the first matching policy determines the action. If a deny policy matches the traffic (source 10.0.1.100, destination 10.10.10.50) before the ACCEPT policy is reached, the traffic will be denied regardless of the ACCEPT policy below it.

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 destination address 'server_farm' does not include 10.10.10.50
Why it's wrong here
The claim is factually incorrect if the address object server_farm is defined with the subnet 10.10.10.0/24, which includes all addresses from 10.10.10.0 to 10.10.10.255. Since 10.10.10.50 falls within that range, the destination object does contain the IP. The administrator should verify the object's actual definition, but given the subnet is a /24, this is not the reason traffic is dropped.
✓
There is a deny policy above this policy that matches the traffic
Why this is correct
FortiGate firewall policies are evaluated sequentially from top to bottom, and the first policy that matches source, destination, and service is executed. If there is a deny policy positioned above this allow policy and it matches the same traffic, the deny action takes precedence and the packet is blocked before ever reaching the allow rule. This is the most likely explanation for why traffic is not permitted, even though the allow policy appears correct.
✗
The NAT translation is causing the traffic to be dropped
Why it's wrong here
NAT (Network Address Translation) on FortiGate performs IP address translation and does not directly cause packet drops; the firewall policy's action determines whether traffic is allowed or denied. Even if NAT is misconfigured, it might lead to issues like asymmetric routing or session timeouts, but it would not silently drop packets during the policy matching phase. Therefore, blaming NAT for the traffic being dropped is technically inaccurate, as the policy would still need to deny the session explicitly.
✗
The source address 'internal_net' does not include 10.0.1.100
Why it's wrong here
The source address object internal_net, if defined as 10.0.0.0/16, encompasses the entire range from 10.0.0.0 to 10.0.255.255, and 10.0.1.100 is clearly within that range. A quick bitwise calculation confirms that the third octet (1) is within the valid host range for a /16 subnet. Thus, the assertion that the source is not covered is false, and a source address mismatch cannot be the reason for the traffic being blocked.

Visual reference

Go deeper

NSE4 Firewall Policies and NAT Practice Question

Why each option matters

Option-by-option breakdown

Related to this question