Cisco Firewall Management Center
Group Export pushes a Group's members to a dynamic object in Cisco Secure Firewall Management Center (FMC), kept in sync automatically. It works the same way as Panorama Group Export, with an FMC dynamic object as the target instead of a Dynamic Address Group.
Each Connect Group targeting an FMC account becomes one dynamic object in the FMC domain you choose, and the object's mappings are the Group's addresses. You reference the object from an access control rule and deploy that rule once. From then on, every change to the Group reaches each firewall the rule is deployed to on its own: FMC pushes dynamic object mappings to managed devices without a deployment, so Connect never deploys anything.
Before you start
| Prerequisite | Why it's needed | Where to check |
|---|---|---|
| FMC 7.0 or later | Dynamic objects and the API that manages them arrived in 7.0. The Test button on the Provision page fails on an older release and names the version it found | Help > About in FMC |
| A dedicated API user with the Object Manager > Modify Object Manager permission | Every sync reads the dynamic objects in the domain and creates or updates one per Group. Nothing needs the Devices or Deploy permissions. The user should be one nobody signs in to the web interface with: FMC logs a user out of the web interface, without warning, when the same user signs in through the API | System > Users and System > Users > User Roles |
| Access to the domain the objects should live in | A multi-domain FMC keeps objects per domain. The Connector creates the objects in the domain named on the account, which must be one the API user can see | System > Domains, or the domain switcher in the top bar |
| Outbound HTTPS from the Connector to FMC | The Connector opens every connection to FMC | Network Requirements |
The export signs in, lists the domain's dynamic objects, and creates or updates one per Connect Group, and stops there. A user limited to object management in that domain is enough.
Set up a Cisco Firewall Management Center account
- In Connect, go to Integrations and click New Integration Account.
- Provider: Cisco Firewall Management Center. 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 FMC hostname.
- Click Continue to Provisioning, then on the Provision page fill in:
- Connector: the Connector you paired earlier. (Required for FMC.)
- FMC Host: your FMC's hostname or IP address, with a port as
host:portif needed. If you paste FMC's full URL, the Connector uses just the host and port. - Username / Password: the API user. Once saved, the password opens blank; leave it blank to keep it. See Passwords and tokens are write-only.
- Under Advanced, set Domain if the objects should live somewhere other than Global. Write it as FMC shows it, as a full path:
Global/Branchfor a child domain named Branch. Leave it blank for Global. Allow Self-Signed Certificate is on by default, because FMC 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 FMC, sign in, and read the domain. A passing test names the version and the domain: Connected to Cisco Firewall Management Center 7.6.2 at fmc.example.com and authenticated. Domain 'Global' found. A domain FMC does not know fails the test with the names the user can see; copy one of those into Domain, 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 FMC 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 one dynamic object, named firemon_ followed by the Group's internal id and the account's id, under Objects > Object Management > External Attributes > Dynamic Objects in FMC. Switch to the account's domain first if it is not Global. The Group's own name is in the object's description, so search the page for the Group name to find it.
On that object, check:
| What | Where | What you should see |
|---|---|---|
| Name | The Name column | firemon_<group id>_<account id>. The name never changes, which is what keeps your rules valid when the Group is renamed |
| Description | The Description column | FireMon Connect: <your Group name> |
| Type | The Type column | IP |
| Mappings | The mapping count on the row, and Show Mapped IDs on the object | The IPs and CIDRs from your Connect Group. A hyphenated range in the Group appears as the CIDRs that cover it, because FMC maps hosts and CIDRs only |
| What's using it | Find Usage on the object | Your own access control rules; Connect creates none. The job that created the object notes that none references it yet |
Use the object in your policy
Add the object as a Source or Destination under the Dynamic Objects tab of an access control rule, under Policies > Access Control, then Save and Deploy that policy once. That deployment puts the rule on the firewalls; from then on, mapping changes made by Connect reach every firewall the rule is deployed to without another deployment. Because the object keeps its name in FMC, the rule survives renaming the Group in Connect.
The job that creates the object completes with the note No access control rule references this group's new FMC dynamic object, so it has no effect on any firewall yet. Later jobs do not repeat it. For a Group exported a while ago, use Find Usage instead.
FMC refuses to delete a dynamic object while a rule references it. To delete one by hand, remove it from the rule and deploy first.
How changes are handled
| Action | Result |
|---|---|
| Edit the Group's filters | Membership recalculates on save and the object's mappings are brought in line on the next sync: new addresses are added, dropped ones removed, the rest left alone. |
| A resource gains/loses a matching tag | Automatic groups pick up the change on the next refresh and re-sync to FMC. |
| Rename the Group | The object's description updates. Its name, and any rule referencing it, are unchanged. |
| Add/remove a target under Export To | Members sync to the new target. A dropped target's object is left in place with its last mappings, the same as when the Group is deleted; delete it in FMC if no longer needed. |
| Edit the object's description by hand | Overwritten on the next sync. |
| Add or remove a mapping on the object by hand | Undone on the next sync: the mappings always match the Connect Group. |
| Delete the Group | The object is left in place with its last mappings. Connect leaves FMC objects alone so live enforcement keeps working. Delete it in FMC once you're done with it, after removing it from any rule. |
| Delete the FMC account in Connect | The account is removed from every Group's Export To. Its objects stay in FMC with their last mappings; delete them there. All of them start with firemon_. |
| Change the account's Domain | New syncs create the objects in the new domain. The old domain's objects stay in place; delete them there once nothing references them. An object name is unique across all of FMC's domains, so an object the old domain still holds blocks the create in the new one until it is deleted; the job says which object. |
| Restart the Connector | It runs a full sync on startup, bringing every exported Group's object in line. Each sync diffs against what FMC holds, so the result is one object with the right mappings however often it runs. |
Details and edge cases
A hyphenated range becomes CIDRs. FMC maps single addresses and CIDRs, not ranges, so a Group member such as 10.0.0.1-10.0.0.5 is exported as the smallest set of CIDRs covering it: 10.0.0.1, 10.0.0.2/31, 10.0.0.4/31. The firewall matches the same addresses.
One object per Group and account. The object's name carries both ids, so a Group exported to two FMC accounts that point at the same FMC, in two domains, gets its own object in each domain.
If the object has no mappings, the Connect Group's filters currently match zero items. Reopen the Group and check the candidate preview under Group Candidates. The object stays, empty, so your rule keeps a valid reference.
There is no known cap on an object's mappings. FMC has accepted tens of thousands of mappings on one object. The Connector sends mapping changes in requests of at most 10,000, so a large Group takes a few requests rather than one.
Rules deployed once keep working. FMC sends mapping changes to every device a referencing rule is deployed to, so a Connect change takes effect within moments and nothing shows under Deploy as pending. A rule you add or change yourself still needs a deployment, as always.
On the firewall, the rule looks broader than it is. The firewall matches a dynamic object in its Snort engine, not in the LINA access list, so show running-config access-list lists the rule as an L7 rule with permit ip any any and its rule id, even for a Block rule, and none of the object's addresses. That is normal for dynamic objects. To see the addresses, use Show Mapped IDs in FMC.
The object's description belongs to Connect. Every sync replaces it with FireMon Connect: <Group name>, so a description you type in by hand disappears on the next sync. Put your own notes in the rule instead.
One API user, one session at a time. The Connector signs in once per sync and once per Test. A user who is also signed in to the FMC web interface is logged out of it when the Connector signs in, which is why the account should have its own API user.
Rate limits. FMC allows 120 API requests a minute from one address on releases before 7.6. The Connector spaces its requests to stay under that, so a first sync of many large Groups can take several minutes; a single Group change is a handful of requests.
For common issues, see Troubleshooting.
Cisco documentation
- Dynamic Objects, in the Device Configuration Guide: what a dynamic object is, why its mappings need no deployment, and that it takes hosts and CIDRs rather than ranges or FQDNs
- Connecting with a client, in the REST API Quick Start Guide: API sign-in, the token lifetime, and the recommendation to use a separate API user
- Objects in the REST API: request limits and the permissions object management needs
- Objects in the REST API, 7.0: the same for the oldest supported release