VMware NSX Integration

Versus treats VMware NSX the same way it treats any other firewall: NSX security policy — distributed-firewall (DFW) rules, gateway-firewall rules, NAT rules, and NSX Groups — is imported into the platform's normalized firewall model, where it is searchable, reportable, and auditable next to your Palo Alto, Cisco, Check Point, and Fortinet estates. Versus can also write rules into an NSX distributed firewall, both to enable/disable individual rules and as the target of a firewall-rule migration.

Two NSX device roles are supported, because NSX exposes two things worth managing:

Related NSX data-plane objects (nsx_edge, nsx_transport) are inventoried as managed devices under their controller. The AVI / NSX ALB Controller is a separate load-balancing integration — see F5 BIG-IP Integration for the ADC side of the estate.

---

How it connects

Versus talks to NSX over the NSX-T Policy API (https://<manager>/policy/api/v1), falling back to the Management Plane API (https://<manager>/api/v1) for node and cluster details that only live there. Authentication is HTTP Basic on every request, using a username/password credential stored in the Versus Vault — the credential is never held in the browser and, on self-hosted installs, can be resolved locally on a collector so it never leaves your network. All reads are paginated with the API's cursor scheme, so large rulebases come back completely rather than truncated at the first page.

Because NSX is reached like any other device, it inherits the platform's outbound-only edge model: a collector inside your environment does the reaching, and Versus never needs an inbound path to the NSX Manager. See Platform Architecture for the overall shape.

---

Importing NSX firewall policy

Add the NSX Manager as an nsx_firewall device with its API credential, then run an import. Import runs as a background job you can watch to completion; it walks the following, in order:

1. Manager info — hostname, software version, HA status, and license, from the Management Plane node and cluster endpoints.
2. Transport nodes — Edge VMs and host fabric nodes become managed devices under the controller, each tagged with the nsx cloud and its role (edge or firewall).
3. Distributed Firewall (DFW) rules — every security policy in every domain is pulled and stored as a rule set named DFW/<domain>/<policy>, with its rules normalized.
4. Gateway Firewall rules — T0/T1 edge policies, stored as GW/<policy> rule sets.
5. NAT rules — DNAT/SNAT/reflexive rules on each Tier-1 gateway, stored as NAT/<gateway> rule sets of type nat.
6. NSX Groups — imported as address-group firewall objects, carrying their tags and raw definition.

Each import is a full reconciliation: rules, NAT entries, objects, and rule sets that no longer exist in NSX are removed from Versus, so the imported view stays a faithful mirror of the source.

How NSX rules are normalized

NSX rules are mapped into the same shape every other vendor's importer produces, so cross-vendor search and reporting work uniformly. Notable mappings:

• Action — ALLOW → allow, DROP → drop, REJECT → deny. A JUMP_TO_APPLICATION rule is treated as allow.
• Groups — NSX source_groups / destination_groups become the rule's source/destination addresses.
• Services & profiles — NSX services map to the rule's services; L7 context profiles map to its applications.
• Zones — NSX DFW is micro-segmentation, so rules carry no zones; source/destination zones are empty by design.
• Logging, tags, notes — preserved as the rule's log setting, tags, and description.

NAT rules are normalized separately: DNAT/SNAT/NO_NAT/REFLEXIVE map to dnat/snat/no_nat/static, with translated networks and ports carried through.

---

Writing rules into NSX

Versus can push changes back to an NSX distributed firewall. The Policy API is declarative, so a rule write is a PATCH to the rule's own path — idempotent create-or-overwrite — and the change is realized immediately; there is no separate commit step to run afterward. Rule paths follow:

PATCH /policy/api/v1/infra/domains/{domain}/security-policies/{policy}/rules/{rule_id}

Two write paths use this:

• Toggle a rule. Enabling or disabling a single DFW rule from the firewall view issues a minimal PATCH that flips only the disabled flag, without rewriting the whole rule.
• Push a rule. Updating a rule's match or action sends the full rule payload — source_groups, destination_groups, services, action, logged, sequence_number, and so on — built from Versus's normalized rule.

Gateway-firewall rules are written the same way, under /infra/gateway-policies/{policy}/rules/{rule_id}.

---

NSX as a firewall-migration target

The larger use case is migrating firewall rules onto NSX. Under Workflows → Migrations → Firewall Rule Migration, a Firewall Migration Plan consolidates rules from one or more source firewalls (any supported vendor) and re-provisions them, rule-by-rule, onto a target. NSX DFW is one of the target platforms:

The plan runs as a state machine with distinct, resumable stages, each recorded on the plan:

discover → select_rules → translate → check_objects → deploy → validate → rollback

• discover reads the normalized rules from each source device.
• select_rules narrows the set to the rules you want to move.
• translate converts each source rule into an NSX Policy rule and each referenced address/service/application into its NSX equivalent, scoped to a target domain and security_policy.
• check_objects dedupes against the target, flagging rules and objects that already exist there.
• deploy provisions the translated rules through the NSX write driver.
• validate confirms what landed; rollback removes what was provisioned.

What translation handles

Because NSX's model differs from a zone-based firewall, translation is more than a field rename:

• Zones → applied-to / groups. NSX has no security zones; source/destination zones are translated to applied-to scope and groups, and the plan notes the mapping for you to review.
• Addresses → NSX Groups, and services → NSX services, created or verified on the target as part of the plan's object checklist.
• Applications → L7 context profiles. App-ID-style applications map to NSX L7 context profiles; the plan flags each one to verify it resolves to an available profile.
• Action — normalized allow/deny map to NSX ALLOW/DROP; any source, destination, or service collapses to NSX's ANY.

Each translated rule carries a per-rule checklist (create groups, create services, map zones, create the DFW rule) and migration notes highlighting anything that needs a human decision before deploy.

Deploy, verify, and roll back

At deploy time Versus resolves the NSX write driver against the target device's credential and provisions each rule with a PATCH. The driver implements the same contract as the PAN-OS and Panorama drivers, so the plan pipeline is identical regardless of target:

• provision PATCHes each DFW rule into the target security policy and returns its rule id.
• verify_realized re-reads the rule to confirm it exists on the box.
• rollback deletes a provisioned rule by id when you back the plan out.
• commit is a no-op — the Policy API realizes changes as they are written.

If the target NSX Manager is unreachable at deploy time, the plan does not fail: it falls back to a simulated dry run, logging what would be created on each rule so you can still review the full plan before a live attempt. You can also request a dry run explicitly.

---

Managing NSX-T Manager as a controller

Separately from firewall policy, you can register the NSX-T Manager as an nsx_manager controller on the Controllers page at /integrations/controllers. This surfaces:

• Node & version info and cluster peers, discovered from the Management Plane API.
• Tier-1 gateways, read from the Policy API (/infra/tier-1s) with a fallback to the Management Plane logical-routers endpoint on older NSX-T builds. Each gateway is returned by its full NSX-T path.

Tier-1 gateway discovery is what lets other migrations — for example moving load balancers onto NSX ALB / AVI — bind virtual services to the correct Tier-1. A Tier-1 lookup that returns nothing surfaces the reason inline (unreachable Policy API, bad credentials, or genuinely no gateways) rather than failing silently.

---

How it fits the platform

NSX policy is ordinary firewall inventory once imported, so everything the platform does with firewall data applies:

• Search and report across NSX and your other firewalls together — the normalized model doesn't care which vendor a rule came from.
• Audit NSX rulebases with the same PCI/segmentation checks used elsewhere.
• Automate rule changes and migrations through Workflows, with the same durable, auditable runs as any other change.

Everything writes through the credential in the vault and, on self-hosted deployments, through an outbound-only collector — so managing NSX never means opening an inbound path to your NSX Manager.

---

Related

• F5 BIG-IP Integration — the ADC counterpart, including NSX ALB / AVI.
• Workflow Builder — automate NSX rule changes and migrations.
• Secret Vault — where the NSX Manager API credential is stored.
• Collector Security — the outbound-only edge that reaches your NSX Manager.
• Platform Architecture — how devices, credentials, and workflows fit together.