Remote gateway unreachable for VMs using L2VPN tunnels between NSX data centers where NAT is configured.
Article ID: 431114
Updated On:
Products
Issue/Introduction
- L2VPN service has been created between two NSX environments within two separate software-defined data centers.
- Both sites stretch overlay (VNI) segments.
- DR downlink on either server or client side is configured as default gateway.
- While the VM's on the Client side of the tunnel will likely be able to communicate with VM's on the Server side and vice versa.
- VMs on one site can't ping the default gateway on the other site.
- VDR Mac address has been changed in at least one of the NSX environments
- Local subnets have NAT configuration applied where the destination field is not excluding the local subnet.
Environment
VMware NSX-T Datacenter
VMware NSX
Cause
When attempting to ping the IP of the remote gateway, the traffic is trying to reach Downlink Interface on the remote edge, the VDR IP. If there is a SNAT rule matching the reply , the packet will be subject to NAT.
Resolution
This is a condition that may occur in a VMware NSX environment.
Workaround:
If a SNAT rule is configured with the local subnets configured for VPN, consider creating a No-SNAT rule with a higher priority for the VPN subnet applied in both source and destination fields. Alternatively move the SNAT rule to the T0 if applicable.
If there SNAT rule configured where the local VPN subnet is included in the source range and the destination is not specific or does not exclude the local subnet specified in the source, the local VPN traffic may become subject to NAT. Specifying a No SNAT rule with the local VPN subnet as source and destination should exclude the L2VPN traffic from being subject to NAT.
Additional Information
Feedback
