Partner SD-WAN Gateway can be configured with multiple subnets, each of which can be configured with a hand-off of NAT or VLAN. Each subnet can also be configured with a relative cost and whether the traffic should be encrypted or not.

The examples below illustrate two use cases for Partner SD-WAN Gateways configuration.

Gateway Configuration Use Case #1

In the following illustration, a SD-WAN Gateway is connected over VLAN/VRF mode to a VRF that has no access to the public Internet. However, the Partner SD-WAN Gateway must be able to contact the SD-WAN Orchestrator in the public cloud, and there must be a path to reach the cloud. The SD-WAN Gateway can selectively NAT certain traffic (such as the IP address of an SD-WAN Orchestrator, or the subnets used to reach public DNS servers) even though it is operating in VLAN/VRF mode.

  • #1 - SD-WAN Orchestrator traffic is routed using IP addresses to NAT.
  • #2 - Corporate Traffic is routed through subnets to VLAN/VRF.

SD-WAN Gateway Configuration Use Case #2

It is common for a Partner SD-WAN Gateway to tie into a corporate network, providing connectivity to legacy sites. This need can occur even when not all corporate sites have been converted to VMware network. For this use case, it is necessary to specify traffic by subnet on the Partner SD-WAN Gateway. Each subnet can also be configured to encrypt network traffic.

The following illustration shows an example where only the traffic to legacy sites is encrypted. If the SD-WAN Gateway is already configured with a 0.0.0.0/0 subnet to allow all traffic (which is a common configuration), all that would be required is to add the private subnet for your legacy sites and mark it as encrypted.

  • #1 - Subnet (e.g., 10.0.0.0/8) defined for Legacy Sites and marked for encryption. Traffic is transmitted between SD-WAN Edge and SD-WAN Gateway over the IPsec tunnel.
  • #2 - Remaining traffic is sent unencrypted to the SD-WAN Edge, and then to its final destination.
Note:
  • For an IPsec tunnel via Partner SD-WAN Gateway, the VCMP tunnel failure causes the existing flows to timeout. The expected behavior for existing flows is to remain on the current path. Any new flow will begin to go (direct) causing the tunnel to remain down.
  • Use application map flags mustUseGateway and dropIfPartnerGatewayDown to force or drop traffic through the SD-WAN Gateway until the path is restored. If these flags are not active, a flow flush is required once tunnel path is restored.