Configuring route propagation for VPN gateways
Route propagation enables a VPC routing table to automatically learn routes from a site-to-site VPN gateway. Route advertisement enables those learned routes to be advertised to a transit gateway so they can be shared with other VPCs and connected networks.
Before you begin
Before you configure route propagation for VPN gateways, review the following considerations:
- Review planning considerations and known issues for VPN gateways.
- Review routing tables and routes.
- In the VPC ingress routing table, the Accepts routes from setting for policy-based VPN determines whether routes that are learned from a VPN gateway are added to the routing table.
- Additionally, you must select VPN gateway in the Accepts routes from setting in the following cases:
- The routing table is associated with a subnet that must route traffic through the VPN gateway.
- You are using a policy-based VPN and want VPN-learned routes to be propagated to the routing table.
- The VPN gateway route propagation for policy-based VPN is supported by both default and custom routing tables:
- For the default routing table, VPN gateway is selected by default in the Accepts routes from setting.
- For custom routing tables, you must manually select VPN gateway to enable route propagation.
- For ingress routing tables, the Advertise to setting advertises the propagated routes to a transit gateway, when the transit gateway is selected as the traffic source.
VPN gateway modes and route propagation
Route propagation and route advertisement behavior differ based on the VPN gateway mode and connection type.
| VPN type | Route behavior | Transit Gateway support |
|---|---|---|
| Policy-based VPN | No manual route configuration required. Traffic that matches the configured local and remote CIDR ranges and defined security policies pass through the VPN. | Supported. To configure a transit gateway with a policy-based VPN connection, see Setting up a transit gateway with policy-based VPN. |
| Static route-based VPN | You must configure routes manually in the routing table. Traffic is forwarded through the VPN tunnel based on routing table entries that point to the VPN connection. | Supported. To configure a transit gateway with a static route-based connection, see Setting up a transit gateway with static route-based VPN for VPC. |
| Dynamic route-based VPN | No manual route configuration required. BGP automatically learns and propagates routes. | Supported with automatic route advertisement. For more information, see planning considerations. |
Setting up a transit gateway with policy-based VPN for VPC
To set up this configuration, follow these steps:
-
Create a transit gateway to connect the VPCs.
-
Create a policy-based VPN gateway and select the VPC that is attached to the transit gateway.
-
Create an ingress routing table in the VPC where the VPN gateway exists.
- Enable the VPN gateway toggle in the Accepts routes from section to allow routes learned through the VPN gateway to be added to the routing table.
- Enable the Advertise to toggle for the transit gateway so that on-premises routes that are learned from the VPN gateway are advertised to other connected networks.
After the connection with the transit gateway is established, the route shows On in the Advertise column of the routing table. On-premises routes are automatically advertised through the transit gateway after the ingress routing table accepts routes from the VPN gateway.
For troubleshooting purposes, you can select or deselect VPN gateway to check routes that were added by the VPN gateway to the routing table.
Migrating to advertised routes in policy-based VPN for VPC
For a policy-based VPN, you can migrate from manually defined address prefixes to automatically advertised routes. Existing policy-based VPN customers who use address prefixes can choose from the following options:
-
Keep using address prefixes in your VPC. No further action is required.
-
To migrate to advertised routes, follow these steps:
- Go to the ingress routing table in the VPC where the policy-based VPN gateway exists.
- In the Traffic source section, set Advertise to to On.
- Wait for the route's Advertise status to change to On.
- Delete the address prefix from the VPC.
A brief traffic disruption is expected during the migration. To minimize interruptions, plan the migration during a maintenance window.
Setting up a transit gateway with static route-based VPN for VPC
This configuration applies only to static route-based VPN. A dynamic route-based VPN automatically propagates routes and doesn't require manual configuration with transit gateway.
To set up this configuration, follow these steps:
-
Create a transit gateway to connect the VPCs.
-
Create a route-based VPN, and select the VPC that is attached to the transit gateway.
-
Create an ingress routing table in the VPC where the VPN gateway exists.
- In the routing table, create a route and set the next hop to VPN connection, which enables direct routing to the VPN tunnel. For more information, see Creating a route.
- While creating a route, select the VPN gateway and VPN connection to define the next hop for traffic.
- Enable the Advertise toggle so that on-premises routes that are learned from the VPN gateway are advertised to the transit gateway.
After the connection with the transit gateway is established, the route shows On in the Advertise column of the routing table. On-premises routes are then automatically advertised through the transit gateway.
Use case: Static route-based VPN connection with transit gateway using ingress routing and VPN as the next hop
With a static route-based VPN, you can establish a VPN connection between your VPC and your on-premises private network using a transit gateway. You can route traffic based on its source by using the ingress routing table and configure routes that use the VPN connection as the next hop.
In this configuration, the enterprise network connects to a VPN gateway located in the transit VPC. The transit VPC is attached to a transit gateway, which provides connectivity to a spoke VPC. When route advertisement is enabled, incoming traffic from the VPN is forwarded to the transit gateway, which then routes traffic to the appropriate spoke VPC.
The ingress routing table in the transit VPC advertises on-premises CIDR ranges to the transit gateway and evaluates return traffic that is received from it. Return traffic follows the reverse path, flowing from the spoke VPC through the transit gateway, back to the transit VPC, then through the VPN gateway, and finally to the enterprise network.
