New VM Provisioning Fails with IP Conflict due to Misconfigured SNAT Rule on Tier-1 Gateway

Products

• VMware NSX

Issue/Introduction

• Attempts to provision or power on a new Virtual Machine (VM) with a specific static IP fail with an "IP Address Conflict" or "IP already in use" error.
• The IP address in question is not assigned to any other active VM, Segment, or Interface in the environment.
• ARP pings to the conflicting IP may resolve to the MAC address of an NSX Edge Transport Node.
• In the NSX-T Manager UI, the IP might show as "In Use" or "Allocated" despite no visible interface assignment.

Environment

VMware NSX 

Cause

The issue is caused by a misconfigured SNAT rule where the Internal IP (Source) and External IP (Translated) fields were swapped or incorrectly defined.

When a specific IP is entered into the External IP field of an SNAT rule, the NSX Edge node "claims" that IP to perform the translation. If an internal VM's IP address is accidentally placed in the External IP field:

1. The Edge node treats that IP as its own for translation purposes.
2. NSX prevents any other VM or service from being provisioned with that same IP to avoid a logical conflict.
3. Traffic intended for a VM with that IP is instead incorrectly routed to the Gateway's internal loopback or service stack.

Resolution

1. Identify the Rule:

   • Log in to NSX Manager.
   • Navigate to Networking > NAT.
   • Select the Tier-1 Gateway associated with the segment where the VM is being deployed.
   • Search for the conflicting IP address in the External IP column of the NAT rules.

2. Correct or Delete the Rule:

   • If the rule is needed but swapped: Edit the rule to place the correct Public/Transit IP in the External IP field and the VM's subnet/IP in the Internal IP field.
   • If the rule is redundant: Delete the SNAT rule entirely.

3. Clear the Conflict:

   • Once the rule is deleted/corrected, wait 30–60 seconds for the Edge realization to complete.
   • Retry the VM deployment or IP assignment.