Configure routes for a VPN gateway

Static routes vs. BGP routes

Static routes: Destination-based vs. policy-based

Choose between destination-based and policy-based routes.

Route priority

The VPN gateway matches traffic against routes in this order:

1. The gateway first checks the Policy-based Route Table, matching routes by policy priority, not by the longest prefix match rule.

2. The gateway then checks the Destination-based Route Table, matching routes by the longest prefix match rule.

3. Finally, the gateway checks the BGP Route Table.

End-to-end overview

Connecting a VPC to a data center through a VPN gateway involves three route tables:

Destination-based route configuration

A destination-based route forwards traffic based on the destination IP address.

Matching rules:

• Longest prefix match: Traffic matches the route with the longest subnet mask. For example, if both 10.0.0.0/8 and 10.10.0.0/16 routes exist, traffic destined for 10.10.10.1 will match the 10.10.0.0/16 route.

• Active/standby routes (for legacy single-tunnel VPN gateways only): Only active routes match; standby routes are skipped. Active/standby route configuration.

Policy-based route configuration

A policy-based route matches traffic by both source IP address and destination IP address, and takes priority over destination-based and BGP routes.

Matching order:

1. Policy priority: Routes with the lowest priority value match first.

2. Routes with the same priority: Matched sequentially by creation time. The first match is used.

Advertise to a VPC route table

After policy routes and destination routes are created, they are in the state of Not published to the VPC route table by default. You can publish manually added routes directly to the VPC system route table without manually adding routes in the VPC route table.

• Routes are advertised only to the VPC system route table, not to custom route tables. To add a route to a custom route table, use Add and delete route entries.

• If routes with the same destination CIDR block exist in both the policy-based and destination-based route tables, withdrawing the route from one table also withdraws it from the other.

• If a route entry with the same destination CIDR block as the route to be published but a different next hop already exists in the VPC route table (for example, pointing to a peering connection or a NAT gateway), the system will prompt a route conflict (duplicate route) during publication. After evaluating your business requirements, delete the conflicting route or adjust the CIDR block plan, and then perform the publish operation again once the conflict is resolved. For more information, see Handle duplicate route errors.

Limitations

These limitations apply to both destination-based and policy-based routes:

• You cannot add a route with the destination CIDR block 0.0.0.0/0.

• Do not add a route to 100.64.0.0/10 (including subnets and supernets). This causes IPsec connection or negotiation failures.

• If the system reports a route conflict, see Handle duplicate route errors.

End-to-end overview

BGP route advertisement principles

• Inbound to cloud: Routes advertised by the data center via BGP → propagated to the VPN gateway → automatically propagated to the VPC system route table (requires route propagation enabled).

• Outbound from cloud: System route entries in the VPC system route table → automatically learned by the VPN gateway (requires route propagation enabled) → propagated to the data center via BGP.

Procedure

Before you begin, ensure:

• The VPN gateway supports BGP. Check whether a VPN gateway supports BGP.

• The gateway device in your data center supports BGP.

Limitations

• Each VPN gateway BGP route table supports up to 50 routes (expandable to 200; contact your account manager).

• The VPN gateway does not accept BGP routes where the destination CIDR block is 0.0.0.0/0.

• When BGP is enabled for multiple IPsec-VPN connections on the same VPN gateway, the Local ASN must be the same for all connections.

• Do not exchange routes between different IPsec-VPN connections.

• When a VPC is associated with multiple VPN gateways, the gateways do not support BGP peering with each other. Do not exchange routes between different VPN gateways.

• If a VPC is associated with multiple VPN gateways that all use BGP and connect to the same Customer Gateway, the Local ASN for the IPsec-VPN connections on each VPN gateway must be identical to prevent routing loops.

• If multiple dual-tunnel IPsec-VPN connections use BGP simultaneously, the destination CIDR blocks of the routes learned by each connection must not overlap.

• When using an Express Connect circuit and a VPN gateway for active/standby access to a VPC, the local ASN configured on the Border Router (VBR) and the VPN gateway must be the same.

• If the VPN gateway's VPC belongs to a Cloud Enterprise Network (CEN), enable route overlapping. This is enabled by default for CEN instances created after March 2019.

• If multiple VPCs in the same CEN connect to the same data center via BGP, dynamic routes may propagate through CEN to other VPCs, causing route flapping. Use static routes instead.

• VPN gateway in single-tunnel mode: Do not propagate routes for 100.64.0.0/10 (including its subnets and supernets). You can avoid this issue by Upgrade an IPsec-VPN connection to dual-tunnel mode.

Route configuration recommendations

• Use the same routing method for all IPsec-VPN connections on a VPN gateway. Do not mix destination-based, policy-based, and BGP routes.

• When configuring BGP routes, set the Routing Mode of the IPsec-VPN connection to Destination Routing Mode.

Check whether a VPN gateway supports BGP

• Newly created VPN gateways that support dual-tunnel IPsec-VPN connections support BGP by default.

• For existing VPN gateways: Call the DescribeVpnGateway operation and verify that the Tag field contains the VpnEnableBgp tag with a value of true.

• Upgrade options for unsupported gateways:

  - Dual-tunnel mode VPN gateway: Upgrade a VPN gateway (standard type only)

  - Single-tunnel mode VPN gateway: Upgrade to dual-tunnel mode

Active/standby route configuration

• To configure active/standby for a legacy single-tunnel VPN gateway, Upgrade an IPsec-VPN connection to dual-tunnel mode. Dual-tunnel connections provide active/standby by default without weight configuration.

• If you still need to configure an active/standby link in single-tunnel mode, follow these steps:

  1. The primary route has a weight of 100 and the standby route has a weight of 0. The destination CIDR blocks must be the same, but the next hops must be different. For policy-based routes, the source CIDR blocks must also be the same.

  2. Configure a health check for the IPsec-VPN connection to enable automatic failover. You can find this option in the tunnel configuration settings of the IPsec-VPN connection.

  3. To modify a route's weight, delete the standby route first, modify the active route's weight, then re-create the standby route. The same process applies when modifying the standby route's weight.

  For VPN Gateway instances that have not been upgraded since October 12, 2023, if you need to configure active/standby policy-based routes, ensure that an active/standby link is specified for each CIDR block. If a CIDR block has only one link configured, failover for other CIDR blocks may fail. You can avoid this issue by upgrading the VPN gateway or Upgrade an IPsec-VPN connection to dual-tunnel mode. This issue does not affect VPN Gateway instances that were created or upgraded after October 12, 2023.

• After configuration, the route takes effect based on the following rules:

  IPsec-VPN connection for active route	IPsec-VPN connection for standby route	Effective route
  Up (negotiation succeeded and health check is normal)	Any state	Active route
  Down	Up	Standby route
  Down	Down	Active route (default)

FAQ

Q: When an ECS accesses on-premises resources through a VPN gateway, how does traffic match the route table?

When an ECS communicates with on-premises resources through a VPN, traffic is forwarded in the following matching order:

1. VPC route table: The system first queries the VPC route table. If a route entry matching the destination IP exists (with the next hop being the VPN gateway), the traffic is forwarded to the VPN gateway.

2. VPN gateway route table: The VPN gateway then determines, based on its own route table (destination routing or policy-based routing), to which IPsec connection the traffic is forwarded.

Q: What should I do if the on-premises IDC cannot ping a cloud ECS or the SSH connection fails?

Troubleshoot in the following order:

1. Confirm that the VPN route configuration is correct (the VPC route table contains a route entry pointing to the VPN gateway, and the VPN gateway route table has the corresponding destination route or policy-based route configured).

2. Check the security group rules of the cloud ECS:

   • Ping test (ICMP): Confirm that the inbound direction of the security group allows the ICMP protocol from the on-premises IDC CIDR block.

   • SSH connection (TCP port 22): Confirm that the inbound direction of the security group allows TCP port 22 from the on-premises IDC CIDR block.

If the route configuration is normal but connectivity still fails, security group blocking is a common cause and should be checked first to avoid misdiagnosing it as a route issue.

Q: When a VPC NAT gateway is used together with IPsec-VPN, how do I configure the ECS routes?

In a scenario where a NAT gateway and a VPN gateway are combined, traffic sent by an ECS to on-premises services must first be translated by the NAT gateway and then transmitted through the VPN tunnel. The configuration steps are as follows:

1. Create a custom route table in the route table console and associate it with the vSwitch where the ECS resides.

2. Add a route entry to the custom route table: set the destination CIDR block to the on-premises internal service address and the next hop to the NAT gateway.

For more information, see Private network access via NAT and VPN Gateways.

Q: What is the impact of configuring the traffic selector as 0.0.0.0/0 or a large CIDR block (such as 10.0.0.0/8)?

The scope of the traffic selector determines the type of traffic that triggers IKE negotiation, but the traffic that actually enters the tunnel is controlled by route decisions:

• Configuring 0.0.0.0/0 does not directly affect on-premises network connectivity. However, if you point the 0.0.0.0/0 route to the VPN tunnel in the on-premises route table, all traffic (including Internet access) will attempt to enter the tunnel, which may cause Internet access to fail.

• You can configure the local CIDR block as a large range (such as 10.0.0.0/8), but make sure that the crypto ACL on the peer device is also modified to the corresponding aggregated CIDR block. If the peer CIDR block cannot be aggregated, you can use 0.0.0.0/0 and add specific route entries under the IPsec connection to achieve fine-grained traffic control and reduce the number of SA negotiations.

For more information, see Recommendations and FAQ for multi-CIDR interconnection configuration.

Tutorials

See Configure strongSwan.