VPN Gateway:Configure policy-based routes

Prerequisites

An IPsec-VPN connection is created and associated with the VPN gateway. For more information, see Create and manage IPsec-VPN connections in single-tunnel mode or Create and manage an IPsec-VPN connection in dual-tunnel mode.

Limits

• Do not set the destination CIDR block of a policy-based route to 0.0.0.0/0.

• Do not set the destination CIDR block of a policy-based route to a subnet of 100.64.0.0/10 or 100.64.0.0/10, or a CIDR block that contains 100.64.0.0/10. If such a route is added, the status of the IPsec-VPN connection cannot be displayed in the console, or IPsec negotiations fail.

• Policy-based routes have a higher priority than destination-based routes and Border Gateway Protocol (BGP) routes.

Match rules for policy-based routes (including route priorities)

When a VPN gateway forwards traffic, the following match rules are applied:

1. Policy-based routes are matched against traffic in descending order of route priority. A smaller priority value indicates a higher priority. The VPN gateway forwards traffic based on the route that matches traffic.

   If your VPN gateway is configured with active/standby policy-based routes, the VPN gateway selects policy-based routes based on the IPsec-VPN connection negotiation and health check status.

   • If the active policy-based route passes both IPsec negotiations and health checks, the active policy-based route is used.

   • If the active policy-based route fails IPsec negotiations or health checks but the standby policy-based route passes IPsec negotiations and health checks, the standby policy-based route is used.

   • If both the active policy-based route and the standby policy-based route fail IPsec negotiations or health checks, the active policy-based route is used.

2. If multiple policy-based routes are assigned the same priority, traffic is matched against the policy-based routes based on their sequence numbers. The VPN gateway uses the first matched policy-based route to forward traffic.

   Each route is assigned a sequence number when it is applied to the system. In most cases, routes that are configured earlier are applied to the system first and therefore have smaller sequence numbers than routes that are configured later. However, there is no strict ordering on which routes are applied first, resulting in some cases where routes that are configured later are applied to the system first and have smaller sequence numbers than routes that are configured earlier.

Recommendations

To make sure that traffic can be forwarded as expected, we recommend that you configure a different priority for each policy-based route.

If you want to configure active/standby policy-based routes, we recommend that you configure the same priority for both the active and standby policy-based routes.

Examples

As shown in the preceding figure, Data Center_1 communicates with VPC_1 through IPsec-VPN Connection 1, and Data Center_2 communicates with VPC_1 through IPsec-VPN Connection 2. The CIDR blocks of Data Center_1 to be connected to VPC_1 are 192.168.1.0/24 and 192.168.2.0/24, the CIDR block of Data Center_2 to be connected to VPC_1 is 192.168.5.0/24, and the CIDR block of VPC_1 to be connected to the data centers is 172.16.0.0/16.

When you configure policy-based routes, you first configure a route from VPC_1 to Data Center_2, and then configure a route from VPC_1 to Data Center_1 and set the destination CIDR block of the route to 192.168.0.0/21. After the routes are configured, the routes are not applied to the system in the sequence in which they are configured. The following table describes the sequence numbers of the routes.

When the VPN gateway forwards traffic from VPC_1 to Data Center_2, network traffic is matched against the routes in sequence because both policy-based routes have the same priority. Traffic from VPC_1 to Data Center_2 matches the route whose sequence number is 1. As a result, traffic from VPC_1 to Data Center_2 is routed to Data Center_1 through IPsec-VPN Connection 1.

In the preceding scenario, you cannot control the time when policy-based routes are applied to the system. As a result, the policy-based routes are not sorted in the desired sequence and traffic is not forwarded by using the desired route. To prevent this issue, we recommend that you configure a different priority for each policy-based route. This way, traffic can match only one route without being affected by the sequence of policy-based routes.

In this example, we recommend that you configure routes as shown in the following table. The policy-based route with the sequence number 1 is first applied to the system, but has a lower priority. Therefore, when the VPN gateway forwards traffic from VPC_1 to Data Center_2, traffic matches the policy-based route with the sequence number 2 and traffic is forwarded to Data Center_2 as expected.

Match rules of policy-based routes (excluding route priorities)

When a VPN gateway forwards traffic, network traffic is matched against policy-based routes based on their sequence numbers instead of the longest prefix. If network traffic matches a policy-based route, the VPN gateway immediately uses the policy-based route to forward traffic.

• Each route is assigned a sequence number when it is applied to the system. In most cases, routes that are configured earlier are applied to the system first and therefore have smaller sequence numbers than routes that are configured later. However, there is no strict ordering on which routes are applied first, resulting in some cases where routes that are configured later are applied to the system first and have smaller sequence numbers than routes that are configured earlier.

• If your VPN gateway is configured with active/standby policy-based routes, the VPN gateway selects policy-based routes based on the IPsec-VPN connection negotiation and health check status.

  • If the active policy-based route passes both IPsec negotiations and health checks, the active policy-based route is used.

  • If the active policy-based route fails IPsec negotiations or health checks but the standby policy-based route passes IPsec negotiations and health checks, the standby policy-based route is used.

  • If both the active policy-based route and the standby policy-based route fail IPsec negotiations or health checks, the active policy-based route is used.

Recommendations

To ensure that traffic is forwarded by using the desired route, we recommend that you specify smaller CIDR blocks for policy-based routes and make sure that traffic can be matched only by one policy-based route.

Examples

As shown in the preceding figure, Data Center_1 communicates with VPC_1 through IPsec-VPN Connection 1, and Data Center_2 communicates with VPC_1 through IPsec-VPN Connection 2. The CIDR blocks of Data Center_1 to be connected to VPC_1 are 192.168.1.0/24 and 192.168.2.0/24, the CIDR block of Data Center_2 to be connected to VPC_1 is 192.168.5.0/24, and the CIDR block of VPC_1 to be connected to the data centers is 172.16.0.0/16.

When you configure policy-based routes, you first configure a route from VPC_1 to Data Center_2, and then configure a route from VPC_1 to Data Center_1 and set the destination CIDR block of the route to 192.168.0.0/21. After the routes are configured, the routes are not applied to the system in the sequence in which they are configured. The following table describes the sequence numbers of the routes.

When the VPN gateway forwards traffic from VPC_1 to Data Center_2, network traffic is matched against the routes based on their sequence numbers. Traffic from VPC_1 to Data Center_2 matches the route whose sequence number is 1. As a result, traffic from VPC_1 to Data Center_2 is routed to Data Center_1 through IPsec-VPN Connection 1.

In the preceding scenario, you cannot control the time when policy-based routes are applied to the system. As a result, the policy-based routes are not sorted in the desired sequence and traffic is not forwarded by using the desired route. To prevent this issue, we recommend that you specify smaller CIDR blocks for policy-based routes to ensure that traffic can match only one route. This way, traffic can be routed without being affected by the sequence of policy-based routes.

In this example, you can configure the policy-based routes as shown in the following table. When the VPN gateway forwards traffic from VPC_1 to Data Center_2, traffic matches only the policy-based route whose sequence number is 2, and traffic is forwarded to Data Center_2 by using the desired route.

Add a policy-based route

1. Log on to the VPN Gateway console.

2. In the top navigation bar, select the region of the VPN gateway.

3. On the VPN Gateways page, click the ID of the VPN gateway that you want to manage.

4. On the details page of the VPN gateway, click the Policy-based Route Table tab, and click Add Route Entry.

5. In the Add Route Entry panel, configure the parameters that are described in the following table, and click OK.

   Parameter	Description
   Destination CIDR Block	The private CIDR block of the data center that you want to access.
   Source CIDR Block	The private CIDR block on the virtual private cloud (VPC) side.
   Next Hop Type	The type of the next hop. Select IPsec-VPN connection.
   Next Hop	The next hop. Select the IPsec-VPN connection that you created.
   Advertise to VPC	Specifies whether to advertise the route to the VPC route table. Yes (recommended): advertises the route to the VPC route table. No: does not advertise the route to the VPC route table. If you select No, you must manually advertise the route to the VPC route table. For more information, see the Advertise a policy-based route section of this topic. Important If you create a route with the same destination CIDR block in both the policy-based route table and the destination-based route table, and advertise both routes to the same VPC route table, when you withdraw the route in the policy-based route table, the route in the destination-based route table is also withdrawn.
   Weight	The weight of the policy-based route. If you use the same VPN gateway to establish active/standby IPsec-VPN connections, you can configure route weights to specify which connection is active. A value of 100 specifies the active connection while a value of 0 specifies the standby connection. You can configure health checks to automatically check the connectivity of IPsec-VPN connections. If the active connection is down, the standby connection automatically takes over. For more information about health checks, see the Health checks section of the "Create and manage IPsec-VPN connections in single-tunnel mode" topic. 100(Active): The IPsec-VPN connection associated with the policy-based route is active. This is the default value. 0(Standby): The IPsec-VPN connection associated with the policy-based route is in standby. Important When you specify the active or standby connection, the active/standby policy-based routes must use the same source CIDR block and destination CIDR block.
   Policy Priority	The priority of the policy-based route. Valid values: 1 to 100. Default value: 10.

   If an error is reported because of route conflicts when you add a policy-based route, refer to the How do I troubleshoot the overlapping route error that is reported when I add a route to a VPN gateway? section of the "FAQ about VPN gateways" topic.

Advertise a policy-based route

When you create an IPsec-VPN connection, you must configure the Routing Mode parameter. If you set the Routing Mode parameter to Protected Data Flows, the system automatically creates a policy-based route that is in the Not Advertised state for the VPN gateway. To advertise the policy-based route to the VPC route table, perform the following steps:

1. Log on to the VPN Gateway console.

2. In the top navigation bar, select the region of the VPN gateway.

3. On the VPN Gateways page, click the ID of the VPN gateway that you want to manage.

4. On the details page of the VPN gateway, click the Policy-based Route Table tab, find the route that you want to manage, and then click Advertise in the Actions column.

5. In the Advertise Route message, click OK.

   If you want to withdraw the policy-based route, click Withdraw in the Actions column.

   Important

   If you create a route with the same destination CIDR block in both the policy-based route table and the destination-based route table, and advertise both routes to the same VPC route table, when you withdraw the route in the policy-based route table, the route in the destination-based route table is also withdrawn.

Modify a policy-based route

You can change the weight and priority of an existing policy-based route.

1. Log on to the VPN Gateway console.

2. In the top navigation bar, select the region of the VPN gateway.

3. On the VPN Gateways page, click the ID of the VPN gateway that you want to manage.

4. On the details page of the VPC gateway, click the Policy-based Route Table tab, find the route that you want to modify, and then click Edit in the Actions column.

5. In the Modify Route Entry panel, change the weight and priority of the route and click OK.

Delete a policy-based route

1. Log on to the VPN Gateway console.

2. In the top navigation bar, select the region of the VPN gateway.

3. On the VPN Gateways page, click the ID of the VPN gateway that you want to manage.

4. On the details page of the VPN gateway, click the Policy-based Route Table tab, find the route that you want to delete, and then click Delete in the Actions column.

5. In the Delete Route Entry message, click OK.

Call API operations to manage policy-based routes

You can use tools, such as Alibaba Cloud SDKs (recommended), Alibaba Cloud CLI, Terraform, and Resource Orchestration Service (ROS), to call API operations to manage policy-based routes. For more information about the related API operations, see the following topics:

• CreateVpnPbrRouteEntry: creates a policy-based route.

• DeleteVpnPbrRouteEntry: deletes a policy-based route.

• ModifyVpnPbrRouteEntryWeight: changes the weight of a policy-based route.

• ModifyVpnPbrRouteEntryPriority: changes the priority of a policy-based route.

• ModifyVpnPbrRouteEntryAttribute: changes the weight and priority of a policy-based route.

• DescribeVpnPbrRouteEntries: queries policy-based routes.