Configuring route propagation for VPN gateways

VPN gateway modes and route propagation

Understand how route propagation works across VPN gateways:

• Policy-based VPN - In a policy-based VPN, the routes are manually defined by using address prefixes and route propagation must be explicitly configured in the routing table. This mode supports manual route advertisement with Transit Gateway. See setting up transit gateway with policy-based VPN.

• Route-based VPN - Route-based VPN supports two connection types.

  • In a static route-based connection, the routes are defined by the VPN tunnel interface and route propagation must be configured in the routing table. This connection type doesn't support route advertisement with Transit Gateway.

  • In a dynamic route-based connection, the routes are automatically learned and propagated by using BGP. This connection type doesn't require manual route configuration in the routing table but it supports automatic route advertisement with Transit Gateway. See planning considerations for dynamic route-based VPN connection.

Setting up a transit gateway with policy-based VPN for VPC

This configuration is applicable only for a policy-based VPN. Dynamic route-based VPN automatically propagates routes and doesn't require manual configuration with Transit Gateway.

Follow the steps to set up a transit gateway with policy-based VPN for VPC:

1. When you create a transit gateway to connect VPCs, create an ingress routing table in the VPC where the VPN gateway exists.
2. Select VPN gateway if you want VPN gateway routes to be propagated to the routing table.
3. Turn the Advertise to switch to On when you select Transit gateway so that the on-premises routes learned from the VPN gateway are advertised to the Transit Gateway.

After the connection with the transit gateway is established, the route displays On in the Advertise column of the routing table. The on-premises routes are automatically advertised through the transit gateway after the ingress routing table accepts routes from the VPN gateway.

Both VPN gateway subnet and the virtual server instance subnet are set as remote CIDRs if they are configured as local CIDRs.

For troubleshooting purposes, you can select or deselect VPN gateway to check routes that were added by the VPN gateway.

Migrating to advertised routes in policy-based VPN for VPC

For a policy-based VPN, you can migrate from manually defined routes (address prefixes) to automatically advertised routes. With Transit Gateway route advertisement support beginning 3 May 2024, existing policy-based VPN gateway customers who use address prefixes can choose from the following options:

• Keep using address prefixes in your VPC. If you continue using address prefixes, no further action is needed.

• Migrate to advertise routes by following these steps:

  1. Go to the ingress routing table in VPC where the policy-based VPN gateway exists.
  2. In the Traffic source section, switch Advertise to to On.
  3. Wait for the route's Advertise status to indicate On in the table.
  4. Delete the address prefix in the VPC.

  A brief traffic disruption is expected during the migration process. To minimize interruptions, plan the migration with a designated maintenance window.

Related links

• Use case 4: Integrating with a site-to-site VPN gateway
• Why did the advertised route creation fail in my VPN gateway?
• Why isn't route advertisement to ingress sources working?
• Why can't I privately access my classic virtual server instance?