Fortinet FortiManager
Group Export pushes a Group's members into a FortiManager ADOM as firewall address objects collected in an address group, kept in sync automatically. It works the same way as Panorama Group Export, with a FortiManager address group as the target instead of a Dynamic Address Group.
Each Connect Group targeting a FortiManager account becomes one address group per address family in the ADOM you choose: an IPv4 group, an IPv6 group, or both when the Group holds both. The group's members are address objects, one per address, CIDR or range in the Group. You reference the group from a firewall policy in a policy package and install that package once. From then on, every change to the Group updates the group in the ADOM. Objects reach a FortiGate only when the package is installed. If you turn it on for the account, the Connector runs that install for you after a change, behind a safety check; otherwise the change waits in the ADOM until you install.
Before you start
| Prerequisite | Why it's needed | Where to check |
|---|---|---|
| FortiManager 6.2 or later | The export has been run against FortiManager 6.2 and 7.4 with ADOMs on FortiOS 6.2 and 7.2, and handles the differences between releases itself | System Settings > Dashboard |
| An API administrator with JSON API Access set to Read-Write and an Admin Profile that can change policy objects in the ADOM | Every sync reads the address objects in the ADOM and writes the ones Connect manages. With installing turned on, the profile also needs the policy package install permission | System Settings > Administrators and System Settings > Admin Profiles |
| The ADOM the objects should live in | FortiManager keeps address objects per ADOM. The Connector writes into the ADOM named on the account, root by default | System Settings > All ADOMs |
| Outbound HTTPS from the Connector to FortiManager | The Connector opens every connection to FortiManager, on the JSON API port, 443 by default | Network Requirements |
If the ADOM runs in workspace mode, the Connector takes and releases its lock itself; see Workspace mode.
Set up a Fortinet FortiManager account
- In Connect, go to Integrations and click New Integration Account.
- Provider: Fortinet FortiManager. Give it a name and a project. The name is the label shown throughout Connect, so use something you and your team will recognize, such as the FortiManager hostname.
- Click Continue to Provisioning, then on the Provision page fill in:
- Connector: the Connector you paired earlier. (Required for FortiManager.)
- FortiManager Host: your FortiManager's hostname or IP address, with a port as
host:portif the JSON API is not on 443. If you paste the full URL, the Connector uses just the host and port. - Username / Password: the API administrator. Once saved, the password opens blank; leave it blank to keep it. See Passwords and tokens are write-only.
- Under Advanced, set ADOM if the objects should live somewhere other than
root, written as FortiManager lists it. Install policy packages after a sync is off by default; read Installing policy packages before turning it on. Allow Self-Signed Certificate is on by default, because FortiManager ships with a self-signed certificate; turn it off if you've installed a certificate from a publicly trusted CA.
- Click Provision Account, then press Test to confirm the Connector can reach FortiManager, sign in, and read the ADOM. A passing test names the versions and the ADOM: Connected to Fortinet FortiManager 7.4.8 at fortimanager.example.com and authenticated. ADOM 'root' (FortiOS 7.2, workspace mode on) found. An ADOM FortiManager does not know fails the test with the names the administrator can see; copy one of those into ADOM, save, and test again.
Export a Group
Same as Panorama: create or edit a Group under Groups in Connect, set Update to Automatic, and add your FortiManager account under Export To. A Group can target Panorama, NSX, FMC, and FortiManager accounts at the same time.
Update and Project are fixed when the Group is created and greyed out afterward, so set both correctly on the first save. See Creating a Group and Group size limits.
The Connector picks up the export job on its next poll. Watch it under Settings > Connectors > Jobs.
Verify it landed
An exported Group produces an address group named firemon- followed by the Group's internal id, under Policy & Objects > Object Configurations > Firewall Objects > Addresses in FortiManager, with the account's ADOM selected. A Group with IPv6 addresses also produces firemon-v6- followed by the id, in the IPv6 address group table. The Group's own name is in the group's comment, so search the page for the Group name to find it.
On that group, check:
| What | Where | What you should see |
|---|---|---|
| Name | The Name column | firemon-<group id>, and firemon-v6-<group id> for the IPv6 group. The name never changes, which is what keeps your policies valid when the Group is renamed |
| Comment | The Comments column | FireMon Connect: <your Group name> |
| Members | The Details column, or Edit | One address object per address in your Connect Group, named firemon-net- (firemon-net6- for IPv6) followed by the address: firemon-net-192.0.2.0_24 for 192.0.2.0/24, firemon-net-203.0.113.16_to_203.0.113.23 for a range |
| Where it is used | Where Used on the group | Your own policies; Connect creates none |
Each member is an ordinary address object of type Subnet, or IP Range for a range, with the comment Managed by FireMon Connect. The same object serves every Group that holds that address.
Use the group in your policy
Add the group as a Source or Destination of a policy in the package your FortiGate is installed from, under Policy & Objects > Policy Packages, then install the package once. That install puts the group and its members on the FortiGate. From then on, each change to the Group lands in the ADOM and reaches the FortiGate on the next install of the package: yours, or the Connector's when installing is on for the account.
The job that creates the group completes with the note No policy references this group's new FortiManager address group yet, so it has no effect on any FortiGate. Later jobs do not repeat it.
FortiManager refuses to delete an address object or group while a policy or another group references it. To delete one by hand, remove the reference first.
Installing policy packages
A FortiGate enforces what was last installed to it, not what the ADOM holds. With Install policy packages after a sync off, the default, the Connector keeps the ADOM current and the package shows Modified until someone installs it. With it on, after a sync changes a group the Connector:
- Finds every policy package that references the changed group, directly or through a group of yours that contains it, and every device and VDOM each of those packages is assigned to or has been installed on. A package assigned to a device group is installed to the devices in that group it has already been installed to at least once.
- For each device, runs an install preview of the package and reads what FortiManager would push.
- Installs the package to that device only when the preview carries nothing but the address objects and groups Connect manages. If the preview also carries another administrator's pending changes, such as an edited policy, the Connector leaves the install to you, and the job's summary says why:
Install skipped: <package> to <device> (<vdom>): preview carries changes this sync did not make: ...
A completed install appears in the summary as Installed: <package> to <device> (<vdom>) and in FortiManager's task monitor, with an ADOM revision named FireMon Connect group sync. An install that fails on the device is reported the same way and leaves the Group's job Complete. The group is correct in the ADOM, and the next install carries it, whether yours or the Connector's after the next change.
Turn this on only where an unattended install fits your change process. Nothing is installed until a Group actually changes, a package nothing references is never installed, and a package holding someone else's pending work is never installed.
Each preview is staged in the ADOM and discarded once it has been read. With workspace mode off, that discard also drops an install another administrator has staged in FortiManager and not yet confirmed. With workspace mode on, the Connector holds the ADOM lock for the whole sequence, so the two cannot overlap.
How changes are handled
| Action | Result |
|---|---|
| Edit the Group's filters | Membership recalculates on save and the group's members are brought in line on the next sync: new addresses get address objects and join the group, dropped ones leave it. The dropped address objects stay in the ADOM. |
| A resource gains/loses a matching tag | Automatic groups pick up the change on the next refresh and re-sync to FortiManager. |
| Rename the Group | The group's comment updates. Its name, and any policy referencing it, are unchanged. |
| Add/remove a target under Export To | Members sync to the new target. A dropped target's groups are left in place with their last members, the same as when the Group is deleted; delete them in FortiManager if no longer needed. |
| Edit the group's members or comment by hand | Undone on the next sync: the members always match the Connect Group. |
| Edit a member object's address by hand | Put back on the next sync. |
| The Group loses every address of one family | That family's group is kept and holds only FortiOS's built-in none object, which matches no traffic, so a policy referencing it stays valid and stops matching. The placeholder is used on every release, because FortiOS before 7.2 rejects an empty group. |
| Delete the Group | The groups and their member objects are left in place. Connect leaves FortiManager objects alone so live enforcement keeps working. Delete them in FortiManager once you're done with them, after removing them from any policy. |
| Delete the FortiManager account in Connect | The account is removed from every Group's Export To. Its groups stay in the ADOM with their last members; delete them there. All of them start with firemon-. |
| Change the account's ADOM | New syncs create the groups in the new ADOM. The old ADOM's objects stay in place; delete them there once nothing references them. |
| Restart the Connector | It runs a full sync on startup, bringing every exported Group's groups in line. Each sync diffs against what the ADOM holds, so the result is the same however often it runs. |
Details and edge cases
One group per address family. FortiOS keeps IPv4 and IPv6 address objects in separate tables, and an IPv4 group cannot hold IPv6 members, so a Group with both gets two groups: firemon-<id> and firemon-v6-<id>. Reference the one your policy needs; an IPv6 policy takes the IPv6 group.
A range stays a range. FortiOS has a native IP range object, so a Group member such as 203.0.113.16-203.0.113.23 becomes one address object of type IP Range rather than a set of CIDRs.
A bare address is a host. 203.0.113.5 is written as the subnet 203.0.113.5/32. A CIDR with host bits set, such as 192.0.2.77/24, is written as its network, 192.0.2.0/24.
Member objects are shared and kept. An address object is named after its address, so two Groups holding the same CIDR share one object, and a re-sync of an unchanged Group writes nothing. An object no Group uses any more stays in the ADOM. FortiManager refuses to delete an object that a group or policy still references, so deleting one by hand cannot break a policy.
Each family's group holds up to 5,000 members. That is FortiOS's limit on an address group. A Group whose IPv4 addresses, or whose IPv6 addresses, exceed it fails its export with a message saying so; split it into narrower Groups. The 10,000-item cap on a Group's membership still applies on top.
Workspace mode. When the ADOM, or FortiManager as a whole, runs in workspace mode, the Connector locks the ADOM for each batch of writes, commits, and unlocks. If the lock or the commit fails, the whole batch is discarded and retried. A single group FortiManager refuses fails only that Group's job; the objects it had already written stay, since each one is complete on its own. While another administrator holds the lock, the job retries for a while, then fails with the lock message, and runs again when the Group next changes or the Connector restarts. With installing on, the preview and the install run under a second lock after the objects have been committed.
Sessions. The Connector signs in once per sync and per Test and signs out afterwards. FortiManager caps concurrent sessions per administrator at 32 by default, so give the account its own administrator rather than one your team shares.
For common issues, see Troubleshooting.
Fortinet documentation
- FortiManager API Best Practices Guide: enabling JSON API access for an administrator, sessions, and workspace mode
- FortiManager documentation: the Administration Guide for your release, which covers ADOMs, workspace mode, policy packages and installs