VMware NSX
Group Export pushes a Group's members to an NSX Group in VMware NSX, kept in sync automatically. It works the same way as Panorama Group Export, with an NSX Group as the target instead of a Dynamic Address Group.
Each Connect Group targeting an NSX account becomes one NSX Group, tagged so it's clearly identifiable as Connect-managed. Every sync fully replaces that NSX Group's membership with the Connect Group's current members, so the NSX Group always reflects exactly what Connect has. A Group that holds both IPv4 and IPv6 addresses becomes one NSX Group that nests two member groups, one per address family, because NSX keeps the two families in separate groups; the group your rules reference is still the one named after your Group.
Before you start
| Prerequisite | Why it's needed | Where to check |
|---|---|---|
| A reachable NSX Manager, or a Global Manager if you run NSX Federation | The Connector talks to the Manager's Policy API | The interface you log into |
| An NSX user that can create and update Groups in the default domain | Every sync creates or updates one Group there | System > User Management |
| Cookie-based API authentication left enabled on the Manager (the default) | The Connector signs in once per sync, as VMware recommends for repeated calls, rather than sending the password on every request | On unless an administrator turned it off; the session cookie guide under VMware documentation covers the setting |
| Outbound HTTPS from the Connector to the Manager | The Connector opens every connection to NSX | Network Requirements |
Confirm which kind of Manager you have before you provision. A Local Manager and a Federation Global Manager serve their APIs at different roots, so the wrong Manager Type makes every operation fail. If you're not sure, log in and check the top navigation bar: a Location drop-down listing the Global Manager and each Local Manager means you have a Global Manager. If you pick wrong, the Test button on the Provision page says so and names the type the Manager answers as.
The export authenticates and then creates or updates one Group per Connect Group in the default domain, and stops there. An account limited to Group management in the default domain is enough.
Set up a VMware NSX account
- In Connect, go to Integrations and click New Integration Account.
- Provider: VMware NSX. 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 NSX Manager hostname.
- Click Continue to Provisioning, then on the Provision page fill in:
- Connector: the Connector you paired earlier. (Required for NSX.)
- NSX Manager Host: your NSX Manager's hostname or IP address, with a port as
host:portif needed. If you paste the Manager's full URL, the Connector uses just the host and port. - Username / Password: an NSX user with permission to create and update Groups. Once saved, the password opens blank; leave it blank to keep it. See Passwords and tokens are write-only.
- Under Advanced, set Manager Type to Local Manager (the default, and the common case for a single NSX site) or Global Manager (Federation). Objects created on a Global Manager propagate to every federated site, so make sure this is what you intend. Allow Self-Signed Certificate is on by default, because NSX Managers ship 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 the Manager and sign in. A passing test names the type it reached: Reached VMware NSX Global Manager (Federation) at nsx.example.com and authenticated. With the wrong Manager Type, the test fails and names the type the Manager actually answers as; correct it under Advanced, 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 NSX account under Export To. A Group can target Panorama and NSX 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 NSX object, or three when the Group holds both IPv4 and IPv6 addresses: the group named after your Connect Group, plus a member group per family named <your Group name> (IPv4) and <your Group name> (IPv6). All of them sit under Inventory > Groups. To list everything Connect manages at once, filter on the tag firemon:connect.
On a Global Manager, switch to the Global Manager view first, using the Location drop-down in the top navigation bar. Global objects live at the Global Manager level, so that switch is what brings the group into view. A healthy export otherwise looks like a failed one.
On that group, check:
| What | Where | What you should see |
|---|---|---|
| Type | The Type column | Generic for the group named after your Connect Group; IP Addresses Only for each member group of a mixed Group |
| Members | View Members on the row | The CIDRs and IPs from your Connect Group. For a mixed Group, the group's own definition lists its two member groups, and View Members still resolves to the addresses |
| That it's Connect-managed | The Tags column | firemon:connect, which distinguishes Connect-managed groups from ones created manually |
| Description | Expand the group's row | FireMon Connect: <your Group name>, and FireMon Connect: <your Group name>, IPv4 members on a member group |
| That NSX has applied it | The Status column | Success. NSX accepts an update immediately and applies it in the background; the Connector waits up to 30 seconds for that after each update. A job that completed with a warning that NSX had not applied the group yet means it was still in progress then, so refresh to see where it is now |
| What's using it | Where Used on the row | Your own firewall rules. Connect creates none. On a member group, the group that nests it |
Use the group in your policy
Reference the group named after your Connect Group, not its member groups, as a source or destination in a rule under Security > Distributed Firewall, then click Publish. It starts affecting traffic once a rule references it, and a Group that later gains or loses an address family keeps working through that one reference. NSX does not support a group of plain IP addresses in a rule's Applied To field, so leave that at its default. Because the group keeps the same underlying ID in NSX, that reference survives renaming the Group in Connect.
NSX blocks deleting a group while a rule still references it. To delete one by hand, remove the rule and publish first.
How changes are handled
| Action | Result |
|---|---|
| Edit the Group's filters | Membership recalculates on save and the NSX Group's members are replaced on the next sync. |
| A resource gains/loses a matching tag | Automatic groups pick up the change on the next refresh and re-sync to NSX. |
| Rename the Group | The NSX Group's display name updates, and so do its member groups' names; their identities (and any policy referencing them) are preserved. |
| The Group gains its first address of the other family | The NSX Group switches in place from holding addresses itself to nesting one member group per family. Rules referencing it keep working. |
| The Group loses one address family | The NSX Group holds the remaining family's addresses itself again. Its member groups are emptied and left in place. |
| Add/remove a target under Export To | Members sync to the new target. A dropped target's NSX Group is left in place with its last membership, the same as when the Group is deleted; delete it in NSX Manager if no longer needed. |
| Edit the NSX Group's tags or description by hand | Overwritten on the next sync. Connect replaces both rather than merging your changes in. |
| Delete the Group | The NSX Group and its member groups are left in place. Connect leaves NSX objects alone so live enforcement keeps working. Delete them manually in NSX Manager once you're done with them, the group first. |
| Delete the NSX account in Connect | The account is removed from every Group's Export To. Its NSX Groups stay in place with their last membership; delete them in NSX Manager, where the tag firemon:connect finds them. |
| Restart the Connector | It runs a full sync on startup, re-pushing every exported Group's members. Each sync replaces the same NSX Group, so the result is one group however often it runs. |
Details and edge cases
Three objects is normal for a mixed Group. NSX keeps IPv4 and IPv6 addresses in separate groups and asks integrations to give each group one address list, so a Group holding both families becomes a group that nests one member group per family. Reference the nesting group in your policy; the member groups are its implementation, and NSX refuses to delete one while the nesting group references it. A Group of one family stays a single group holding its addresses directly.
If the group is empty, the Connect Group's filters currently match zero items. Reopen the Group and check the candidate preview under Group Candidates.
A large Group can hit two different limits. NSX's API accepts at most 25,000 addresses in a group, both families counted together, and the Connector refuses to sync a Group over that rather than truncate it; the job fails with the count in its error. Below that ceiling, your own environment has a practical limit on a group's effective members that depends on the NSX version and the Manager's form factor, and NSX raises a Group size exceeds limit alarm when a group crosses it. Exceeding it makes NSX accept the update and then fail to apply it, which the job reports.
The job checks that NSX applied the group. After each update the Connector watches the group's realization for up to 30 seconds. If NSX reports an error, the job fails with an error that starts NSX accepted and says NSX could not apply it, and splitting the Connect Group into narrower Groups is the usual fix. If NSX is still applying the group when the wait ends, the job completes with a warning saying so, and the group's Status column shows where it got to.
The group's tags and description belong to Connect. Every sync replaces them, so a tag or description you add to a Connect-managed group by hand disappears on the next sync. If you need your own labels, put them on an NSX object of your own.
For common issues, see Troubleshooting.
VMware documentation
- Add a Group: the Inventory > Groups screen, where groups are listed with options to view their members and where they're used, and the group types, including IP Addresses Only
- NSX API Authentication Using a Session Cookie: the sign-in the Connector uses, and the session timeout
- Alarm for Group size exceeds limit: what counts as an effective member in each NSX version
- NSX Tags: how object tags such as
firemon:connectwork - Overview of Group Membership Criteria: including why IP address members are expressed per address family
- Check Rule Realization Status: background on what the Status column reports as NSX applies a change