DNAT Rule Applied to Route-Based IPSec VPN VTI Stays "Uninitialized".

Products

• VMware NSX

Issue/Introduction

1. When creating a Destination NAT (DNAT) rule and applying it specifically to the Virtual Tunnel Interface (VTI) of an active Route-Based IPSec VPN session, the NAT rule fails to realize and remains in an "Uninitialized" state in the NSX Manager UI.
   
   
2. The underlying Route-Based VPN session itself is fully established and shows a "Green/Up" status.
   
   
3. In the NSX Manager /var/log/proton/nsxapi.log, the NATRuleProviderNSXT is invoked but throws a PM500015 error when attempting to resolve the scope of the rule:
   

   INFO providerTaskExecutor-1-49 NATRuleProviderNSXT 6218 POLICY [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Handling PolicyChange on NAT rule with path map: {PolicyNATRule=[/orgs/default/projects/<uuid>/infra/tier-1s/<uuid>/nat/USER/nat-rules/DNAT]} and enforcement point: /infra/sites/default/enforcement-points/default

   ERROR providerTaskExecutor-1-49 ProviderInvocationTask 6218 POLICY [nsx@6876 comp="nsx-manager" errorCode="PM500015" level="ERROR" subcomp="manager"] ProviderInvocationTask: 249213742 - Failed to invoke provider NATRuleProviderNSXT
at com.vmware.nsx.management.policy.providers.nat.nsxt.NATRuleProviderNSXT.getScopeResourceReference(NATRuleProviderNSXT.java:1267) ~[?:?]
at com.vmware.nsx.management.policy.providers.nat.nsxt.NATRuleProviderNSXT.getAppliedTosForRule(NATRuleProviderNSXT.java:1062) ~[?:?]

Environment

VMware NSX

Cause

This issue occurs if a custom Display Name was applied to the VTI interface (either via API or during a custom provisioning script) when the Route-Based IPSec session was created.

When the NATRuleProvider attempts to realize a NAT rule scoped to a specific VPN session, the backend code explicitly searches for an associated tunnel interface with the hardcoded default display name of default-tunnel-interface. If the VTI's display name has been altered to match the session name (e.g., Custom_VPN_Name) or anything other than default-tunnel-interface, the scope dereference fails, an error is thrown, and the NAT rule remains unrealized.

The VTI display name is an internal parameter and is not exposed or editable via the NSX UI. It can only be viewed or modified via the NSX Policy API.

Resolution

To resolve this issue, you must use the NSX Policy API to rename the VTI's display name back to default-tunnel-interface.

1. Retrieve the Current Session Payload:
   1. Perform an API GET request to retrieve the configuration payload of the affected IPSec VPN session:
      1. GET https://<nsx-manager-ip>/policy/api/v1/infra/tier-1s/<tier-1-id>/ipsec-vpn-services/<service-id>/sessions/<session-id>
2. Modify the Payload:
   1. In the retrieved JSON payload, locate the VTI interface configuration block. Change the displayName field of the interface back to the required default:
      1. "displayName": "default-tunnel-interface"
3. Push the Corrected Payload:
   1. Perform an API PATCH (or PUT) request using the modified payload to the same endpoint:
      1. PATCH https://<nsx-manager-ip>/policy/api/v1/infra/tier-1s/<tier-1-id>/ipsec-vpn-services/<service-id>/sessions/<session-id>

Once the VTI display name is restored to default-tunnel-interface, the NATRuleProvider will successfully resolve the scope, and the DNAT rule will transition to a Realized/Success state.

Note: All policy APIs require the user to READ - MODIFY - PATCH with the entire payload. As an alternative, if the user wants to pass in just a part of the payload, then a feature called "partial patch" is supported. Once the partial patch is enabled, the user can provide part of the payload and the system will retain the remaining fields.