Portable Non SD-WAN Destination IP Address for Cloud Gateways: Caveats and Troubleshooting
search cancel

Portable Non SD-WAN Destination IP Address for Cloud Gateways: Caveats and Troubleshooting

book

Article ID: 376599

calendar_today

Updated On:

Products

VMware VeloCloud SD-WAN

Issue/Introduction

Portable NSD IP addresses allow an Operator to move NSD via Gateway configurations to different Gateways in the PoP without requiring the customer to reconfigure their tunnels. Portable NSD IP Address aids in the expansion, load balancing, and maintenance of the Gateway service with minimal impact to customer configurations.

This article covers caveats associated with this function and troubleshooting for issues that may occur.

Environment

VMware VeloCloud SD-WAN

Resolution

There are two important caveats with NSD IP Portability:

  • NSD peers must operate as an IKE responder. In the past, some configurations would permit an initiator-only setup, but that will no longer function.
  • Peers must allow NAT-T (NAT Traversal). The current implementation of NSD Portable IP uses NAT which is internal to the PoP.

On initial deployment of the Portable NSD IP feature, a single IP address is used for all NSDs initiated from a PoP. This has caused some tunnel configurations to fail:

  • Multiple NSD configurations from a single PoP, to a single destination IP, using the default or IPv4 IKE auth ID.
  • Multiple NSD configurations from a single PoP, to a single destination IP, using duplicate USER FQDN.
  • NSD configurations having the Redundant Tunnel in the same PoP.

For the majority of NSDs, reconfiguring the tunnels to use FQDN or User FQDN with unique IDs resolves connection failures:

On the Configure > Network Settings >  Non SD-WAN Destinations via Gateway > General settings of the tunnel, under Authentication, set Local Auth Id to FQDN or User FQDN. In the box that appears after changing Local Auth ID, add the auth id making sure each NSD via Gateway configuration has a unique value.

Note: A similar change must be made on the NSD via Gateway peer to expect this newly configured auth id.

Several NSD types do not currently allow setting FQDN or User FQDN as the IKE Local Auth ID type despite peer device support. These tunnels must be deleted and recreated using the generic NSD types.