NSE5 Part 7: Policy and Objects

28 April 2026 FortinetNSE5FortiManagerPolicyFCPCertification

NSE5 Part 7: Policy and Objects

Part 7 of the NSE5 series. The policy package is what most people think of when they think of FortiManager — the ADOM-level firewall ruleset that gets installed onto one or many FortiGates. The exam tests the plumbing: how the package is constructed, how objects are scoped, what happens during install, and the dynamic object features that make a single package work across many devices.

What a policy package is

A policy package is the set of firewall rules, NAT rules, and object references for one or more devices in an ADOM. A single package can be installed onto many FortiGates simultaneously, which is the point — twenty branch firewalls with the same security posture install from one package.

config firewall security-policy        ; on the FortiGate after install
config firewall policy                  ; legacy rule type

The package itself lives under Policy & Objects → Policy Packages in the GUI. CLI access is via the pm package tree:

config pm package
    edit "branch-baseline"
        ...
    next
end

Package scope and installation targets

Each package has an installation target — the device or VDOM it gets installed onto. A single package can target many devices; a single device can have multiple packages (one per VDOM).

config pm package
    edit "branch-baseline"
        set scope-member <device-or-vdom-list>
        set type pkg
        set ngfw-mode profile-based
    next
end

The exam will hand you a package with three target devices and ask “if I install the package, what gets pushed to device 4?” — answer: nothing. Device 4 isn’t a target. Adding it to the scope is a separate operation.

NGFW mode — profile-based vs policy-based

Two policy modes that affect how rules are written:

Mode	Rule shape
Profile-based	One rule per source/dest/service plus security profiles (the classic FortiGate model)
Policy-based	Rules can match application or category directly without a profile reference

Profile-based is the default and what almost every production deployment uses. Policy-based was introduced for cleaner inspection chains and is the answer when the question asks about “central NAT, application-based policies, and one-pass scanning”.

A package commits to one mode at creation time. Switching mode requires creating a new package — the existing rules don’t translate cleanly between the two.

The object database

Objects (addresses, services, schedules, security profiles) are shared across packages within an ADOM. Edit an object once, and every package that references it gets the new value at the next install.

This shared model is the source of most operational mistakes. The exam will ask “you change address object branch-net from 10.0.0.0/24 to 10.0.0.0/16; what happens to the live policies referencing it?” — answer: nothing yet. Object changes don’t push automatically. They take effect on the next install of any package that references them.

That delay is the install-time cliff: if package A references the object and gets installed, while package B references the object but isn’t installed, the FortiGate-A and FortiGate-B versions of the object are now different. Confusing, but correct.

Dynamic objects

The single most-tested feature in this lesson. A dynamic (mapped) object has per-device values — the object name is the same on every FortiGate, but what it resolves to differs.

config firewall address
    edit "branch-lan"
        set type dynamic
        config dynamic_mapping
            edit "FGT-branch-1-vdom-root"
                set subnet 10.10.1.0 255.255.255.0
            next
            edit "FGT-branch-2-vdom-root"
                set subnet 10.10.2.0 255.255.255.0
            next
        end
    next
end

A single policy that references branch-lan installs onto branch 1 with 10.10.1.0/24, onto branch 2 with 10.10.2.0/24. One rule, twenty branches, twenty different LAN subnets.

The _default mapping (an unmapped device falling back to a generic value) is configurable; without it, the install fails when a target device has no mapping.

ADOM revisions and policy package revisions

Two distinct revision streams that the exam likes to confuse:

ADOM revision — a snapshot of the entire ADOM (objects, all packages, devices). Captured manually or on schedule. Used for “rebuild the ADOM the way it looked last Tuesday”.
Policy package revision — a snapshot of one package. Captured automatically before every install of that package.

Rolling back the ADOM rolls back everything. Rolling back a policy package rolls back just that package’s rules (objects revert with the ADOM).

Install previews

Every install begins with a preview — a CLI diff of what will be sent to the device. The preview reads in three colours in the GUI; in CLI form it’s a unified-diff-style block:

+ config firewall policy
+     edit 47
+         set name "permit-branch-to-hq"
+         set srcintf "branch-lan"
+         set dstintf "hq-vpn"
+         set srcaddr "branch-net"
+         set dstaddr "hq-net"
+         set service "ALL"
+         set action accept
+     next
+ end
- config firewall address
-     edit "deprecated-net"
-         purge
-     next
- end

The exam will show you a preview and ask what changes after install. Train yourself to read the diff line by line — adds, removes, modifies, purges. purge lines are most dangerous: they remove an object even if other rules still reference it (assuming all references were also being removed in the same install).

Install logs

After install, the Install Log records the per-device outcome:

Success — config diff applied cleanly.
Warning — config applied but with non-fatal messages (e.g., reference to a non-existent object that was already broken).
Error — install rolled back or partially applied.

diagnose dvm task list
diagnose dvm task del <id>

The install log lives in the FortiManager GUI under Device Manager → Install Wizard → Install Log and is retained per the global retention setting.

A common exam question: “install reports success on three of four devices; the fourth shows error. What’s the state of the failed device?” Answer: the FortiGate rejects the entire transaction by default, so the fourth device is unchanged — its config is still what it was before. (You can disable transactional install per device, but don’t.)

Header and footer policies

Inherited from Part 4 (ADOMs in advanced mode). A package gets:

Header policies prepended (from the Global Database in advanced mode).
The package’s own policies in the middle.
Footer policies appended.

Order matters because FortiOS evaluates rules top-to-bottom and stops on first match. A header policy that allows DNS hits before the package’s specific deny.

Sanity tools — Find Unused, Find Duplicates, Section Locking

Three GUI tools that turn into real exam questions:

Find Unused Objects — lists objects in the ADOM not referenced by any policy. Cleanup target.
Find Duplicate Objects — lists objects with the same value but different names. Common when admins copy-pasted across packages.
Section Locking — locks a specific package or object during edit so two admins can’t write the same thing at once. Less aggressive than full workspace mode (Part 8).

Diagnostics

diagnose dvm proc list
diagnose dvm task list
diagnose test deploymanager getcheckstatus <device-name>
diagnose test deploymanager fixflag set <device-name>

diagnose test deploymanager is the deep-diagnostic tree for install-time problems — checking the deploy queue, force-clearing stuck flags, and inspecting the per-device install state.

The most-used command after a confusing install:

diagnose dvm task list

This shows every recent install task, its outcome, and a task ID that opens the full install log on disk.

Common exam scenarios

“Edited an address object; live FortiGate still shows the old value.” Object changes don’t push automatically — install the package.
“Single package installed onto 5 devices; 4 succeed, 1 reports ‘object not found’.” Dynamic object missing a mapping for that device.
“Two admins edited the same package; one set of changes disappeared.” No section lock, no workspace mode — last write wins.
“Install succeeded but FortiView shows the old policy in use.” Wait for session table to age out, or run execute set system session-helper-info delete <id> on the FortiGate; install doesn’t kill existing sessions.

Part 8 covers workspace mode and the locking model that prevents the multi-admin overwrite scenario above.