To route management traffic between your VMware Cloud on AWS and on-premises SDDC infrastructure, you must establish a VPN connection to each on-premises region.
VMware Cloud on AWS offers two different types of VPNs for management traffic, route-based or policy-based.
-
A route-based VPN creates an IPsec tunnel interface and routes traffic through it as dictated by the routing table on the VMware Cloud on AWS SDDC. A route-based VPN provides resilient and secure access to multiple subnets. When you use a route-based VPN, new routes are added automatically when new networks are created.
Route-based VPNs in a VMware Cloud on AWS SDDC use the IPsec protocol to secure traffic and the Border Gateway Protocol (BGP) to discover and propagate routes when networks are created. To create a route-based VPN, you configure BGP information for the VMware Cloud on AWS SDDC and on-premises endpoints, and specify tunnel security parameters for the VMware Cloud on AWS SDDC end of the tunnel.
-
A policy-based VPN creates an IPsec tunnel and a policy that specifies how traffic uses it. When you use a policy-based VPN, you must update the routing tables on both ends of the network when new routes are added.
Policy-based VPNs in a VMware Cloud on AWS SDDC use the IPsec protocol to secure traffic. To create a policy-based VPN, you first configure the VMware Cloud on AWS SDDC endpoint, then you configure a matching remote on-premises endpoint. Because each policy-based VPN must create an IPsec security association for each network, a network administrator must update the routing information on-premises and in the VMware Cloud on AWS SDDC whenever a new policy-based VPN is created. A policy-based VPN can be an appropriate choice when you have only a few networks on either end of the VPN, or if your on-premises network hardware does not support BGP, which is required for route-based VPNs.
In this design, a VPN is required between the management cluster in each on-premises region (Region A and Region B) and the SDDC on VMware Cloud on AWS (Region C), however the on-premises termination locations are not enforced. Use NSX ESGs as the on-premises terminating devices, because you can place them in the on-premises SDDC infrastructure. This configuration provides a simple and secure location without complicating other parts of the enterprise network.
| Decision ID |
Design Decision |
Design Justification |
Design Implication |
|---|---|---|---|
| SDDC-VMC-NET-001 |
Create a policy-based management VPN between the Management Gateway on the VMware Cloud on AWS SDDC and the Region-A and Region-B management environments. |
BGP is not supported over NSX-IPsec VPN tunnels. |
In some environments, it might be preferable to terminate the VPNs outside the on-premises SDDC environments where BGP is available. |
| SDDC-VMC-NET-002 |
If using NSX for management VPN termination, configure a highly available pair of NSX Edge service gateways (ESGs) in each of the edge clusters. |
VPNs between the VMware Cloud on AWS and on-premises SDDC infrastructure must be able to exchange routing information. |
Adds resource overhead. |
| SDDC-VMC-NET-003 |
If using NSX for management VPN termination, configure the ESG HA heartbeat timeout to 5 seconds. |
Using a longer heartbeat timeout might result in a longer than desired outage of communication between on-premises and VMware Cloud on AWS workloads. |
Configuring a heartbeat timeout that is too short might result in a premature failover that can increase or extend an outage. |
Consider the difference in the property names in the VPN configuration of the VPN-enabled NSX ESGs and of the SDDC on VMware Cloud on AWS.
| NSX Property Name |
VMC Console Property Name |
|---|---|
| Name |
VPN Name |
| Peer ID |
On-prem Gateway IP |
| Peer Endpoint |
On-prem Gateway IP |
| Peer Subnets |
On-prem Network |
| Local ID |
Uplink SNAT (not a user-entered value) |
| Local Endpoint |
Uplink IP (not a user-entered value) |
| Local Subnets |
Local Network |
| Encryption Algorithm |
Encryption |
| Perfect Forward Secrecy |
Perfect Forward Secrecy |
| Authentication |
PSK (not configurable) |
| Diffie Hellman Group |
Diffie Hellman |
| Pre-Shared Key |
Pre-Shared Key |
| Enabled |
True (not configurable) |
To have traffic flowing between the VMware Cloud on AWS SDDC management networks and your on-premises management networks, you must populate the management VPN connections with the infrastructure subnet on the VMware Cloud on AWS SDDC, any custom network segments on the VMware Cloud on AWS SDDC, and the management on-premises networks. These networks are populated within the configuration of each side of the VPN tunnel as either local or remote networks. Also, adding the vSphere vMotion networks allows cold vSphere vMotions operations.
| VPN Source | VPN Destination | Remote Networks | Local Networks |
|---|---|---|---|
| VMware Cloud on AWS SDDC |
Region A |
|
|
| VMware Cloud on AWS SDDC | Region B |
|
|
| Region A |
VMware Cloud on AWS SDDC |
|
|
| Region B |
VMware Cloud on AWS SDDC |
|
|
| Decision ID |
Design Decision |
Design Justification |
Design Implication |
|---|---|---|---|
| SDDC-VMC-NET-004 |
Add all networks for management and vSphere vMotion in the on-premises and VMware Cloud on AWS SDDCs to each VPN endpoint configuration. |
To have operations running in both on-premises and VMware Cloud on AWS SDDC infrastructure, traffic between all management subnets must be routed. |
Having management networks routable over a VPN might bring in security considerations in some organizations. |
