All Products
Search
Document Center

VPN Gateway:Configure routes for a VPN gateway

Last Updated:May 27, 2026

Configure static, policy-based, or BGP routes on a VPN gateway to connect your VPC to a data center through IPsec-VPN connections.

Choose a routing method

Static routes vs. BGP routes

Category

Static route

BGP route

Use cases

Networks with a small number of routes that change infrequently.

Networks with a large number of routes that change frequently.

Maintenance

Medium. Route changes must be configured manually.

Low. Routes are automatically advertised and learned.

Prerequisites

None.

Both the VPN gateway and the local gateway device must support BGP.

Static routes: Destination-based vs. policy-based

Choose between destination-based and policy-based routes.

Category

Destination-based route

Policy-based route

Matching criteria

Destination IP only

Source IP + Destination IP

Use cases

General use. Recommended for most users.

Traffic routing differentiated by source CIDR block.

Priority

Lower than policy-based routes.

Higher than destination-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.

Static route configuration

End-to-end overview

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

Traffic direction

VPC route table

VPN gateway route table

Local gateway device route table

Outbound (VPC to data center)

Choose one of the following methods:

  • Propagate routes from the VPN gateway (recommended):

    In the VPN gateway's route table, click Advertise to VPC in the Actions column of the route entry.

  • Manually add a route:

    Set the destination CIDR block to the data center's CIDR block and the next hop to the VPN gateway. Add and delete route entries.

Manually add one route:

  • The destination CIDR block is the data center's CIDR block, and the next hop is the IPsec-VPN connection.

  • You can configure either a destination-based route or a policy-based route.

Ensure the local gateway device has a route to the data center's internal network. If not, add one manually.

Inbound (data center to VPC)

No configuration is required.

No configuration is required.

Manually add two routes:

For both routes, set the destination CIDR block to the VPC's CIDR block and the next hop to the active and standby tunnels of the IPsec-VPN connection, respectively. Assign a higher weight to the active tunnel.

image

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.

Console

Add a destination-based route

Ensure you have created an IPsec-VPN connection associated with a VPN gateway.

  1. Go to the VPN Gateway page in the console. Click the ID of the target VPN gateway instance.

  2. Navigate to the Destination-based Route Table tab and click Add Route Entry.

    • Destination CIDR Block: Enter the CIDR block of your data center.

    • Next Hop: Select the target IPsec-VPN connection.

    • Advertise to VPC: Select Yes to automatically advertise the route to the VPC system route table. If you select No, you must manually add the route to the VPC route table.

    • Weight: Only legacy single-tunnel VPN gateways support weights. Active/standby route configuration.

Delete a destination-based route

Find the target route entry and click Delete in the Actions column.

API

API operation

Description

CreateVpnRouteEntry

Creates a destination-based route.

PublishVpnRouteEntry

Advertises or withdraws a VPN route.

DeleteVpnRouteEntry

Deletes a destination-based route.

ModifyVpnRouteEntryWeight

Modifies the weight (for legacy single-tunnel VPN gateways only).

DescribeVpnRouteEntries

Queries destination-based and BGP routes.

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.

Important
  • Matching order for same-priority routes is not guaranteed. Assign a unique priority to each policy-based route for deterministic routing.

  • For legacy single-tunnel VPN gateways, active/standby policy-based routes must share the same priority. Only active routes match. Active/standby route configuration.

Policy-based route matching example

Example:

VPC_1 (172.16.0.0/16) connects to IDC_1 (192.168.1.0/24, 192.168.2.0/24) through IPsec-VPN connection 1, and to IDC_2 (192.168.5.0/24) through connection 2.

Incorrect: Same priority + aggregate CIDR causes mismatch:

Priority

Destination CIDR block

Source CIDR block

Next hop

Problem

10

192.168.0.0/21

172.16.0.0/16

IPsec-VPN connection 1

Incorrectly matches traffic to IDC_2

10

192.168.5.0/24

172.16.0.0/16

IPsec-VPN connection 2

Correct: Assign different priorities. Give the more specific route a higher priority (lower value).

Priority

Destination CIDR block

Source CIDR block

Next hop

10

192.168.5.0/24

172.16.0.0/16

IPsec-VPN connection 2

20

192.168.0.0/21

172.16.0.0/16

IPsec-VPN connection 1

Note

Legacy VPN gateway: If your VPN gateway does not support policy priority configuration, policies are matched sequentially in the order they are configured, without priority. Use specific network segments (such as 192.168.1.0/24) instead of summary network segments (such as 192.168.0.0/21), or upgrade the VPN gateway to support policy priority.

Console

Add a policy-based route

Ensure you have created an IPsec-VPN connection associated with a VPN gateway.

  1. Go to the VPN Gateway page in the console. Click the ID of the target VPN gateway instance.

  2. Navigate to the Policy-based Route Table tab and click Add Route Entry.

    • Destination CIDR Block: Enter the CIDR block of your data center.

    • Source CIDR Block: Enter the CIDR block of the associated VPC.

    • Next Hop: Select the target IPsec-VPN connection.

    • Advertise to VPC: Select Yes to automatically advertise the route to the VPC system route table. If you select No, you must manually add the route to the VPC route table.

    • Policy Priority: Range: 1–100. Lower values = higher priority. Default: 10.

    • Weight: Only legacy single-tunnel VPN gateways support weight configuration. Active/standby route configuration.

Edit a policy-based route

Find the target route entry and click Edit in the Actions column to modify the Policy Priority or Weight. Only legacy single-tunnel VPN gateways support weight modification.

Delete a policy-based route

Find the target route entry and click Delete in the Actions column.

API

API operation

Description

CreateVpnPbrRouteEntry

Creates a policy-based route.

DeleteVpnPbrRouteEntry

Deletes a policy-based route.

ModifyVpnPbrRouteEntryWeight

Modifies the weight.

ModifyVpnPbrRouteEntryPriority

Modifies the policy priority.

ModifyVpnPbrRouteEntryAttribute

Modifies the weight and policy priority.

DescribeVpnPbrRouteEntries

Queries policy-based routes.

Advertise to a VPC route table

Advertise manually added routes to the VPC system route table without configuring them in the VPC console.

  • 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.

Console

  • When adding a destination-based or policy-based route, you can select to Advertise.

  • For existing route entries, you can click Advertise or Withdraw in the Actions column.

API

Call PublishVpnRouteEntry to advertise or withdraw a route.

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.

BGP route configuration

BGP (Border Gateway Protocol) lets a VPN gateway and data center peer automatically, learning and distributing routes without manual maintenance.

End-to-end overview

Traffic direction

VPC route table

VPN Gateway route table

Local gateway device route table

Outbound (VPC to data center)

No configuration required.

After you enable Automatic Route Propagation for the VPN gateway, the VPC route table automatically learns routes to the data center from the VPN gateway.

  1. You must enable Automatic Route Propagation on the VPN gateway.

    When enabled, the VPN gateway automatically learns system routes from the VPC system route table and advertises data center routes to the VPC system route table.

  2. You must enable BGP on the VPN gateway.

    When enabled, the gateway automatically advertises VPC CIDR blocks to the data center and learns data center CIDR blocks.

You must enable BGP on the local gateway device.

When enabled, the device automatically advertises the local network's CIDR blocks to the cloud and learns the VPC's CIDR blocks.

Inbound (data center to VPC)

No configuration is required.

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:

Console

  1. Specify the data center's ASN in the Customer Gateway

    Specify your data center's Autonomous System Number (ASN) when creating a Customer Gateway. If the existing one lacks an ASN, create a new one. Customer Gateway.

  2. Enable BGP in the IPsec-VPN connection

    • When creating or editing an IPsec-VPN connection, configure the Customer Gateway, Enable BGP, Local ASN, Tunnel CIDR Block, and Local BGP IP address. For parameter descriptions and procedures, see Enable or disable BGP.

    • The Local ASN for both tunnels must be the same. The peer BGP ASN must also be the same for both tunnels.

    • Set the Routing Mode of the IPsec-VPN connection to Destination Routing Mode.

  3. Enable route propagation

    Enable this feature in the Enable Automatic Route Advertisement column for the target VPN gateway instance. When enabled:

    • The VPN gateway automatically learns system routes from the VPC system route table.

    • The VPN gateway automatically propagates BGP routes from the data center to the VPC system route table.

      BGP routes are propagated only to the VPC system route table, not to custom route tables.
  4. Verify the BGP routes

    • VPN gateway BGP route table: On the VPN gateway instance details page, go to the BGP Route Table tab. The route source is marked as "CLOUD" (cloud-native routes) or "VPN_BGP" (routes learned via BGP).

    • VPC system route table: Check the VPC's system route table for entries of type "Dynamic Route".

API

  1. Specify the data center's ASN in the Customer Gateway

    Call the CreateCustomerGateway operation.

  2. Enable BGP in the IPsec-VPN connection

  3. Enable route propagation

    Call the ModifyVpnGatewayAttribute operation to enable it.

  4. Verify the BGP routes

    Call the DescribeVpnRouteEntries operation to query BGP route entries.

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 upgrading the IPsec-VPN connection to dual-tunnel mode.

Appendix

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

Active/standby route configuration

Important

This section applies only to existing VPN gateways that use single-tunnel mode.

  • To configure active/standby for a legacy single-tunnel VPN gateway, upgrade the 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 upgrading the 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)

Tutorials

strongSwan configuration example