When provisioning virtual machines via VMware Aria Automation 8.18.1 blueprints involving NSX-T NAT rules, a naming collision occurs in the NSX-T service entries.
If one deployment defines a NAT rule with a specific source port (e.g., TCP 22) and another defines a rule with the same destination port, Aria Automation generates an identical Service ID (e.g., Service-TCP_22) for both. Because NSX-T Policy API uses the service name as the unique identifier/ID, the second deployment's service entry overwrites the first. This results in functional corruption where SNAT rules may be inadvertently converted to DNAT behavior because they point to the overwritten service definition.
VMware Aria Automation 8.18.1
VMware NSX-T Data Center / NSX 4.x
The Aria Automation provisioning service uses a non-unique naming logic for internal NSX-T service objects that does not distinguish between source port definitions and destination port definitions, leading to ID collisions at the NSX-T endpoint.
This issue is scheduled to be resolved in VMware Aria Automation 8.18.1 Patch 6.
Workaround:
To prevent Aria Automation from generating the colliding Service-TCP_{Port} object, avoid using the "any" keyword in NAT rule port configurations. Explicitly define the port range 1-65535 instead.
Modify the blueprint natRules properties as follows:
For rules requiring "any" source port:
type: Cloud.NSX.Nat
properties:
name: "NAT"
natRules:
- translatedInstance: ${resource.VM.networks[0].id}
description: NAT-Rule
sourceIPs: any
translatedPorts: 2222
destinationPorts: 22
sourcePorts: 1-65535
index: 0
For rules requiring "any destination port:
type: Cloud.NSX.Nat
properties:
name: "NAT"
natRules:
- translatedInstance: ${resource.VM.networks[0].id}
description: NAT-Rule
sourceIPs: any
translatedPorts: 2222
destinationPorts: 1-65535
sourcePorts: 22
index: 1
By providing an explicit range, Aria Automation generates a unique service string that avoids the collision with the default single-port service naming convention.