VMware Cloud Infrastructure products, from VMware Cloud down to the core vSphere, contain a robust set of permissions that can be configured as part of the roles that users are assigned. These permissions allow granular access to capabilities inside the Google Cloud VMware Engine Private Cloud.
Virtual Private Network (VPN)
Google Cloud VPN functions provide an encrypted end-to-end path over untrusted networks using IPsec. It can be used for connections across the open Internet, but also across a Google Interconnect Security is always a tradeoff, and IPsec VPNs trade security for performance, limited by available CPU and network capacity inside the Private Cloud.
IPsec VPNs rely on Path MTU Discovery, which in turn may require relevant ICMP protocol messages (IPv4 type 3, IPv6 type 2) to be permitted. This is a general best practice for networks, as blocking all ICMP messages to disable ICMP echo (“ping”) causes the collateral loss of other important network messages like Fragmentation Needed, Time Exceeded, and more. Path MTU Discovery is important for automatic network optimization of most modern operating systems. Workarounds such as MSS Clamping add complexity and rigidity to an environment and may not be the best solution.
Deploying a VPN to connect to a Private Cloud involves other decisions about network topology and will depend on the network capabilities and topologies of the Private Cloud and other sites. Route-based VPNs use the BGP routing protocol to exchange information about networks between sites. This adds both complexity and flexibility, and the design of these networks is beyond the scope of this document. With simpler IP addressing schemes and network deployments the Policy-Based VPN options are possible. Layer 2 VPN connectivity allows for migrations into the cloud without re-addressing a workload, by extending an on-premises network, but requires the NSX Autonomous Edge appliance to be deployed in the local cloud.
VPNs between sites with dynamic addresses may require additional design considerations or operational process work. If the dynamic address changes then the VPN connection will not be functional until the SDDC is updated for the remote site’s new public IP address.
Ideas to consider:
Use IKEv2 with a GCM-based cipher with as high a bitrate as can support the required performance levels.
Use Diffie Hellman Elliptical Curve groups (19, 20 or 21), with the highest group number of those that can support the required performance (generally based on the total number of tunnels).
Enable Perfect Forward Secrecy where supported on both sides of the VPN connection. Enabling it on one side only may initially work, but will disconnect after a preset amount of time.
Use a long, randomly generated pre-shared key, or if available, certificate-based authentication.
If the BGP endpoint is on a different device from the IPSec VPN, or there is a possibility of access to the BGP network being used, then a BGP Secret should be configured on both endpoints to prevent route hijacking.
