3.1 Firewall Policies

Why Firewall Policies Matter

The firewall policy is the single most important object on a FortiGate. Every packet that crosses the device is checked against the policy table, and the policy decides whether the traffic is allowed, denied, inspected, or sent into a VPN tunnel. NSE 4 expects you to predict exactly which policy a given session will hit — and what happens to traffic that hits nothing.

A firewall policy in FortiOS 7.6 is a rule that matches a session against a set of attributes and then applies an action plus optional security inspection. The attributes a policy matches on include:

• Incoming interface and outgoing interface (or zones)
• Source — address, address group, user, or user group
• Destination — address, address group, or Internet Service
• Service — protocol and port (or Internet Service Database entry)
• Schedule — when the policy is active

Top-Down Policy Matching

FortiGate processes the policy list from top to bottom and applies the first policy that matches every attribute of the session. Once a match is found, evaluation stops — policies below it are never checked for that session.

This ordering rule has a direct consequence: more specific policies must sit above more general ones. If a broad allow-all policy sits above a narrow block policy, the broad policy matches first and the block policy becomes dead — it can never be reached.

When a new session's first packet arrives, FortiGate also performs route lookup and other checks, but for policy selection the model to remember is: walk the list, stop at the first full match, apply that policy.

The Implicit Deny Policy

Every FortiGate has a built-in implicit deny policy at the very bottom of each interface-pair (or global) policy list. It carries policy ID 0, cannot be deleted, and matches any traffic that no explicit policy accepted.

Key facts for the exam:

• The implicit deny drops traffic silently — no reset or rejection is sent back to the source.
• By default the implicit deny does not log dropped traffic. To see what it is dropping, enable logging of denied/violation traffic in the policy settings.
• Because of the implicit deny, FortiGate is deny-by-default: if you create no policies, nothing passes.

The practical takeaway: traffic is allowed only when it explicitly matches an ACCEPT policy. Anything else falls through to ID 0 and is dropped.

Policy ID vs. Sequence Number

These two numbers are easy to confuse and the exam tests the difference directly.

A policy created early may have policy ID 5 but be moved to the top of the list, giving it sequence position 1. FortiGate matches by sequence (list order), not by ID. When you reorder policies in the GUI or with move in the CLI, only the sequence changes; the ID stays fixed.

Firewall Objects

Firewall policies reference reusable firewall objects instead of raw values. This keeps configuration consistent and lets one change propagate everywhere the object is used.

Address Objects

An address object represents a source or destination. FortiOS 7.6 supports several address types:

• Subnet — an IP address and netmask, e.g. 192.168.1.0/24
• IP range — a start and end address
• FQDN — a fully qualified domain name FortiGate resolves via DNS
• Geography — all IP ranges belonging to a country
• Dynamic — addresses learned from connectors such as FSSO or SDN integrations

Address Groups

An address group bundles multiple address objects under one name so a single policy can reference many networks at once.

Service Objects

A service object defines a protocol and port — for example HTTPS is TCP/443. FortiGate ships with many predefined services, and you can create custom services and service groups.

Schedule Objects

A schedule controls when a policy is active. Two types exist:

• Recurring — repeats on chosen days/times, e.g. business hours Monday–Friday
• One-time — active during a single date/time window, then the policy stops matching

A policy whose schedule is not currently active is simply skipped during matching, exactly as if it did not exist.

The Action Field

Every firewall policy has an action that decides the fate of matched traffic:

Only ACCEPT policies expose the security profile section (antivirus, web filter, IPS, application control, SSL inspection) and the NAT settings. A DENY policy has no security profiles because the traffic is never allowed through to be inspected.

Logging Options

Each ACCEPT policy offers a Log Allowed Traffic setting with two levels:

• Security Events — logs only when a security profile records an event (e.g. a virus or blocked URL)
• All Sessions — logs every session the policy accepts

DENY policies have a Log Violation Traffic option. For the implicit deny, enabling violation logging is the only way to record what it is dropping. Logging "All Sessions" everywhere generates large volumes of data, so production designs usually log security events plus selectively log full sessions where visibility is needed.

Policy Best Practices

• Place specific policies above general ones so they are reachable.
• Use descriptive names and reusable objects rather than inline values.
• Avoid overly broad all-to-all ACCEPT policies; scope source, destination, and service.
• Enable logging where you need visibility, including violation logging on the implicit deny during troubleshooting.
• Periodically review for shadowed (unreachable) and unused policies.

Policy Evaluation Order — Step by Step

When the first packet of a new session arrives, FortiGate evaluates it in this order:

1. Start at the top of the relevant policy list (per interface-pair, or the flat list with policy-based ordering).
2. Compare the session against the current policy's incoming interface, outgoing interface, source, destination, service, and schedule.
3. If any attribute fails to match, move down to the next policy and repeat.
4. On the first policy that matches all attributes, stop searching and apply that policy's action.
5. If the action is ACCEPT, apply NAT, security profiles, and logging, then create the session entry.
6. If no explicit policy matches, the session falls through to the implicit deny policy (ID 0) and is dropped.

Because matching stops at the first hit, the order of the list is the policy logic. Two correct-looking policies in the wrong order produce wrong behavior — the most common firewall misconfiguration on the exam.