NSE5 Part 5: Device Registration and Provisioning

NSE5 Part 5: Device Registration and Provisioning

Part 5 of the NSE5 series. Registration is what brings a FortiGate under FortiManager’s control. The exam tests the mechanics — the FGFM tunnel, the discovery options, what’s pushed when, and the difference between a registered device and a managed device. This post walks through each.

FGFM — the tunnel under everything

FGFM (FortiGate-FortiManager protocol) runs over TLS on TCP/541 and is the only data plane between FortiManager and a managed FortiGate. Once established, every config retrieval, install, status poll, FortiGuard relay, and script execution rides over it.

Either side can initiate. By default the FortiGate dials the FortiManager — useful when the FortiGate is behind NAT, since FortiManager doesn’t need to reach the device directly. The FortiManager can also initiate a connection to a publicly reachable FortiGate, but most production deployments use FortiGate-initiated.

Manual registration — the FortiGate side

The FortiGate must be told who its FortiManager is:

config system central-management
    set type fortimanager
    set fmg "10.10.20.10"
    set serial-number "FMG-VM0000000000"
    set include-default-servers disable
    set vdom "root"
end
execute central-mgmt register-device <FMG-serial> <admin-pass> <FGT-IP> <FGT-pass>

Two settings that come up on the exam:

• include-default-servers — when enabled, the FortiGate falls back to Fortinet’s public FortiGuard servers if the FortiManager is unreachable. Disable it in production for stricter control over update sources.
• vdom — which VDOM the FGFM management traffic uses for its outbound socket. Defaults to root; change when management is in a non-root VDOM.

After this, the FortiGate appears on the FortiManager under Device Manager → Unauthorised Devices. It is not yet managed — only registered.

The authorisation step

Until you authorise the device, the FortiManager has its serial and IP but does not own its config. Authorisation happens in the GUI (Device Manager → Unauthorised Devices → right-click → Add) or via CLI:

diagnose dvm device add <FGT-serial>

When you authorise, FortiManager pulls the device’s running config and stores it as revision 1. From this point on, every install operation diffs against revision N and writes revision N+1.

The exam will ask “what does FortiManager have when a device is registered but not authorised?” — answer: nothing. A serial and a tunnel, that’s all.

FortiManager-initiated discovery

If the FortiGate is publicly reachable and you’d rather drive registration from the FortiManager side:

execute device add <name> <ip> <admin-user> <admin-pass>

Or in the GUI: Device Manager → Add Device → Discover. FortiManager initiates a TLS session, authenticates as an administrator on the FortiGate, and pulls the running config. This needs the FortiGate’s allowaccess to permit https (the API uses HTTPS, not FGFM) on whichever interface FortiManager reaches it on.

Model devices

A model device is a placeholder for a FortiGate that doesn’t exist yet — useful for templating new branches before the hardware ships. The model has a serial number, an ADOM, and a full config but no live tunnel. When the real device dials in for the first time and presents that serial, FortiManager promotes the model to a real device and installs the templated config.

diagnose dvm device add model <name> <serial> <adom> <platform>

Model devices are how zero-touch provisioning is implemented in FortiManager. A factory-fresh FortiGate with central-management configured at imaging time will phone home, match its serial against a model, and self-provision.

The exam will hand you “branch FortiGate ships with default config; what makes it auto-configure when plugged in?” — answer: a model device pre-built in FortiManager with that serial number, plus the FortiGate having a way to reach FortiManager (DHCP + DNS to a FortiGuard FOC redirector, or the older set fmg factory default).

Zero-touch provisioning (ZTP) flow

The full FortiZTP flow is:

1. Customer registers the FortiGate’s serial number on the Fortinet support portal and assigns it to the FortiZTP cloud service.
2. ZTP service is configured with a redirect to the customer’s FortiManager.
3. FortiGate boots, gets DHCP, calls home to FortiZTP, receives the FortiManager IP.
4. FortiGate dials FortiManager via FGFM.
5. FortiManager matches the inbound serial against a model device and installs the templated config.

The exam tests the order of these steps; remember the FortiGate calls FortiZTP first, then gets pointed at FortiManager.

Install operations

Installing a config means: take the FortiManager’s database for this device, diff it against what’s running, and push the difference. Three install variants:

Operation	What it does
Install Policy Package	Push only the policy package and its referenced objects
Install Device Settings	Push device-specific config (interfaces, routing, system settings)
Quick Install	Push both, in one operation

Each install starts with a preview — a CLI diff of what is about to change. Read the preview every time. The exam will hand you a preview output and ask whether a change will succeed; the trick is to watch for purge lines (which delete entries on the device) and for objects that exist on the FortiManager but not yet on the FortiGate (which appear as adds).

CLI equivalent for the install:

diagnose dvm task list
diagnose dvm task del <id>
execute install device-config <device-name>
execute install policy-package <package-name>

diagnose dvm task list shows every queued or running install task. diagnose dvm task del cancels one — useful when an install hangs and you need to retry.

Auto-update of the device database

When someone makes a change directly on the FortiGate (the dreaded “out-of-band” change), FortiManager has three options:

config dvmdb adom
    edit "branch-fw-74"
        set auto-push-cfg disable
        set check-out-mode reload
    next
end

• Auto-update enabled, conflict mode = reload — every detected change pulls the FortiGate config and overwrites the FortiManager database. Loses all unpushed FortiManager changes.
• Auto-update enabled, conflict mode = revert — every detected change is reverted on the FortiGate, restoring the FortiManager view.
• Manual — FortiManager flags the conflict and waits for an admin to choose.

Production deployments almost always run manual — neither auto-overwriting the FortiManager nor auto-reverting the FortiGate is what you want as a default. The exam tests the meaning of each mode.

Diagnostics

get system status
diagnose dvm device list
diagnose fgfm session list
diagnose debug application fgfmsd 255
diagnose debug enable

diagnose fgfm session list shows every active FGFM tunnel — local IP, remote IP, state, last keepalive. The fgfmsd debug is verbose and the right tool when “device shows offline but the FortiGate says it’s connected”.

On the FortiGate side:

diagnose fgfm sessions
diagnose debug application fgfmd 255

diagnose fgfm sessions from the FortiGate is the mirror image — same data, opposite endpoint. Run both sides simultaneously when troubleshooting tunnel flap.

Common exam scenarios

• “Device registered but stays unauthorised.” Authorisation is a separate step — manual approval needed.
• “FGFM tunnel up but installs fail.” Look at diagnose dvm task list first; usually a stuck previous task or a checked-out config.
• “Out-of-band change on FortiGate disappeared after FortiManager install.” Expected — installs overwrite. Use Retrieve Config before installing if you want to preserve.
• “Model device exists but real FortiGate doesn’t auto-provision.” Serial mismatch (typo in the model), or the FortiGate is reaching FortiManager from an interface FortiManager doesn’t expect.

Part 6 covers the device-level configuration objects — provisioning templates, CLI templates, SD-WAN, IPsec, and certificate templates — that turn registration into automation.