Firewall Policies and NAT →easyMultiple Choice

NSE4 Firewall Policies and NAT Practice Question

An administrator wants to create a firewall policy that blocks all traffic from a specific IP address (10.0.0.99) to the internet, but allows all other traffic. Which policy configuration is correct?

⚠ Common exam trap

Watch out — candidates often think a deny policy alone is sufficient, forgetting that FortiGate requires an explicit allow policy for other traffic to pass, or they misorder policies, placing the allow before the deny, which causes the deny to be ineffective due to first-match logic.

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

✓

Create a deny policy for source 10.0.0.99 to destination 'all' on the WAN interface, then an allow policy for all other traffic

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.

Answer analysis

Option-by-option breakdown

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

✓
Create a deny policy for source 10.0.0.99 to destination 'all' on the WAN interface, then an allow policy for all other traffic
Why this is correct
FortiGate firewall policies are evaluated top-down, and the first match is applied. Placing a deny policy that matches source 10.0.0.99, destination 'all', on the WAN interface above a permissive allow policy ensures the host's internet traffic is blocked while all other traffic falls through to the allow rule. This is correct because the deny rule's specificity combined with its higher position makes it effective, and the allow policy remains broad for remaining sources.
✗
Create an allow policy for source 'all' and then a deny policy for 10.0.0.99
Why it's wrong here
Placing an allow policy for source 'all' before the deny policy is fatal because FortiGate uses first-match logic. The allow policy matches every source, including 10.0.0.99, so traffic from that host is permitted immediately and the deny policy for 10.0.0.99 is never evaluated. A deny rule must always be positioned above any allow rule that could otherwise match the same traffic to produce the intended block.
✗
Use a local-in policy to block the IP
Why it's wrong here
Local-in policies are designed for traffic destined to the FortiGate's own IP addresses, such as management sessions, not for traffic transiting through the firewall. Using a local-in policy to block 10.0.0.99 would only prevent that IP from reaching the FortiGate interfaces themselves, not from reaching internet destinations via the data plane. Forwarded traffic is controlled exclusively by regular firewall policies, so this approach is ineffective for the stated goal.
✗
Create a policy that denies all traffic from 10.0.0.99 to any destination
Why it's wrong here
Creating a deny policy that covers all traffic from 10.0.0.99 to any destination is overbroad because it blocks not only internet access but also internal LAN-to-LAN communications and other legitimate transit traffic. In FortiGate, a policy lacking a specific destination interface applies to all forwarded traffic, potentially breaking internal connectivity. The correct deny policy should specify destination 'all' on the WAN interface (or a specific WAN address) to limit the block to outbound internet traffic only.

Go deeper

NSE4 Firewall Policies and NAT Practice Question

Why each option matters

Option-by-option breakdown

Related to this question