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 VeloCloud Orchestrator in the public cloud, and there must be a path to reach the cloud. The VeloCloud Gateway can selectively NAT certain traffic (such as the IP address of a VeloCloud Orchestrator, or the subnets used to reach a public DNS servers) even though it is operating in VLAN/VRF mode.


  • #1 - VCO 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 VeloCloud. For this use case, it is necessary to specify traffic by subnet on the Partner VeloCloud 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 VeloCloud Gateway is already configured with a 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. defined for Legacy Sites and marked for encryption. Traffic is transmitted between VeloCloud Edge and VeloCloud Gateway over the IPsec tunnel.
  • #2 - Remaining traffic is sent unencrypted to the VeloCloud Edge, and then to its final destination.