Partner Gateways 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 Gateways configuration.
Gateway Configuration Use Case #1
Consider the following figure, in which a Gateway is connected over VLAN/VRF mode to a VRF that has no access to the public Internet. However, the Partner 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 a SD-WAN Orchestrator, or the subnets used to reach a public DNS servers) even though it is operating in VLAN/VRF mode.
- #1 - SD-WAN Orchestrator traffic is routed via IP address(es) to NAT
- #2 - Corporate Traffic is routed via subnet(s) to VLAN/VRF
Gateway Configuration Use Case #2
Additionally, it is a common use case for a Partner 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 . For this use case, it is necessary to specify traffic by subnet on the Partner Gateway. Each subnet can also be configured to encrypt network traffic.
The diagram below shows an example in which 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 would be 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.
