The purpose of an IPsec VPN is to advertise private networks from one site to another site:
VMware Cloud on AWS supports two types of VPN: Policy-Based VPN and Route-Based VPN.
With a Policy-Based VPN, you need to specify manually on both sides of the VPN which subnets will be exposed from site A to site B and from site B to site A.
On a standard Cisco router/firewall, you have to create an access-list (ACL) and specify in the ACL the subnets you are going to learn and advertise to the other side. This is used in the ‘crypto-map‘ section of the VPN configuration.
Everytime a new subnet is created (such as 10.3.20.0/24 on the VMC SDDC side), you would then need to update the VPN configuration, which is obviously not ideal.
In the case of VMware Cloud on AWS, it means that everytime a new logical network is created, we then have to update the VPN configuration across all VPNs and across all remote sites in order for that new subnet to be able to communicate with all the remote sites.
You would need to update the VPN configuration on the VPN on-premises and on the VMware Cloud on AWS side.
VMware Cloud on AWS recently introduced Route-based VPN. Route-Based VPN provides vast improvements from the traditional Policy-Based VPN.
It’s a simplification but in essence: route-based is dynamic whereas policy-based is static and route-based provides resilience whereas policy-based does not.
With a Route-Based VPN, we run a dynamic routing protocol (BGP) within the tunnel and routes are exchanged dynamically.
Once the route-based VPN tunnel is established, there is simply no need to update it; even after we create additional network segments in the Cloud or on remote sites.
Resilience with Route-Based VPN
The other advantage of route-based VPN is that we can now build multiple VPN tunnels, providing better resilience between the two sites.
You can easily create a second IPsec VPN session (and second BGP peering session) parallel to the first one and that would give you resilience in case one of the on-premises router fails.