An anomaly has been identified in the VTEP communication between NSX Edges. ARP requests originating from a specific source Edge have their source IP address modified in transit before reaching the destination Edge. This behavior is strictly unidirectional and has been verified via simultaneous packet captures.
Unidirectional Behavior: Reverse-path ARP requests (originating from 172.###.###.6 back to 172.###.###.7) are received normally without any modification. Simultaneous packet captures executed on both Edge nodes demonstrate the mutation:
Outbound capture on Source Edge shows the ARP request generated correctly with its assigned VTEP IP 172.###.###.7.
Inbound capture on Destination Edge shows the received ARP request with the Source IP 172.###.###.1 (changed to the subnet's default gateway IP.)
VMware NSX
A physical underlay network device is erroneously applying Source NAT (SNAT) to VTEP traffic exiting the Edge subnet, causing mid-transit modification of the source IP address.
NSX VTEP overlay tunnels require direct, UN-NATTED line-of-sight between Edge nodes. To resolve this issue:
Engage the physical network infrastructure team to audit the routing, NAT, and security policies on the upstream physical devices bridging the affected <REDACTED_IPS> subnets.
Isolate the specific physical gateway router modifying the packets. Check the device assigned to the modified source IP address, as this is the likely source of the mutation.
Remove or bypass the NAT/Proxy ARP configuration on the physical network for the VTEP subnets to ensure un-NATed, end-to-end layer 3 communication.
Verify bidirectional ARP resolution and successful tunnel initialization via NSX Edge packet captures.
For more information on Edge node underlay network requirements, refer to the VMware NSX Reference Design Guide - NSX Edge Networking Setup
For RTEP scenario kindly refer this KB article -- NSX Edge RTEP Tunnel Fails Due to Physical Underlay Source NAT Modifying Packets