Policy sets and the rule stack

Rule base, Policy packages shows every policy set (Fortinet: policy package), grouped by management domain (Fortinet: ADOM), with its policies in the order the firewalls evaluate them and hit counts from every firewall it is installed on. Everyone can see it.

The Policy packages page

Each management domain is a panel with its description (or Offline snapshot and read-only), the number of devices, and when it was synced or loaded. Each policy set row shows:

Column	Shows
Package	The name; click it to open the rule stack.
Installs to	The firewalls (installation scope), or No devices.
Policies	How many policies it holds.
Hit counts from	When hit counters were last collected, or Not collected.

Buttons at the top:

Audit all packages (implementers, Security, auditors and administrators) audits every policy set on live connections. Offline snapshots are audited when they're loaded.
A Sync button per live connection, named after it (implementers and administrators).

Banners show any connection whose last sync failed or had warnings.

Open a policy set

The page header shows the management domain, where the set installs to and when it was synced. Buttons:

Request a rule here (requesters) opens a new rule request.
Run audit (implementers, Security, auditors and administrators) audits this policy set now.

Figures across the top: the number of policies, how many never take effect (shadowed), how many are redundant, and how many are unused or inactive.

The rule stack

Evaluation order lists every policy, top to bottom, as the firewall evaluates them: the first match wins. Each row shows:

the policy ID, such as #12;
a coloured mark for the action (accept, deny or other);
the name (or Unnamed);
sources → destinations on services;
hits: a compact count, No hits, Disabled, or — when counters weren't collected;
up to two finding tags (not for never-hit or disabled policies, which show in the hits column).

Rows of policies that never take effect (shadowed or redundant) are dimmed; disabled policies are marked too.

Type in Filter by name, ID, object to show only matching policies. While filtering, the lines aren't drawn.

If the policy set hasn't been audited yet, the page says This package hasn't been audited yet, so overlaps aren't drawn. After an audit it shows Audited with the date.

The lines

Lines in the gutter on the left join a policy to the policy above it that affects it. An arrow points at the affected policy.

Line	Meaning
Red	Shadowed: the upper policy hides a policy with the opposite action. The lower policy never takes effect.
Grey	Redundant: the upper policy already does the same for all of the lower one's traffic. The lower policy is never reached.
Dashed orange	Crossing rules (shown as Partial overlap): the two policies share some traffic, neither contains the other, and they have opposite actions.

An allow above the final deny-all, or any narrow exception above a broader rule, is normal design. It is not flagged or drawn. Only rules that cross are.

Point at a line (or focus it with the keyboard) for a plain-language explanation and a Recommendation, for example #3 "Allow web" hides #9 "Block web". The two policies are highlighted. Click the line to open the affected policy.

When a policy is selected, lines that don't involve it fade.

Policy details

Click a policy (or press Enter on it) to open its details beside the stack:

Field	Shows
Action	accept, deny, and (disabled) if switched off
Interfaces	incoming → outgoing
Source and Destination	Address objects, IPv4 and IPv6
Service	Service objects
Schedule	The schedule
Logging	The log setting
Hits	Total hits across the firewalls, or not collected
Last hit	When, or never
Comment	If any

Below, Findings lists every finding about this policy, and those where it is the cause, each with a recommendation. Nothing to report for this policy. means none. Close hides the panel.

The address of a selected policy can be shared: it includes ?policy=<ID>.

How the audit works

FireSight resolves every address, group, range and service to real networks and port ranges, then compares each enabled policy with every enabled policy above it, the way the firewall evaluates them. Interfaces, schedules and installation targets are taken into account. A policy that is fully hidden is not used to judge policies below it, because it can never match.

Policies that use FQDN, geography, negation, identity or internet-service matching can't be resolved exactly. They are checked on a best-effort basis and never reported as hiding other policies, to avoid false alarms.

See Finding types for every finding and Audit findings for the list across all policy sets.