access cross-VPC resources from a client using SSL-VPN - VPN Gateway

Overview

The VPC interconnection method determines whether a client can access resources in other VPCs in the same region, across different regions, or under different accounts. Both CEN and VPC peering connection support these scenarios. After interconnecting the VPCs, add the CIDR blocks of all destination VPCs to the SSL server and add client-side routes in the relevant products. This enables the client to access resources in the interconnected VPCs through the SSL-VPN connection.

For more information about the differences between CEN and VPC peering connections, see VPC Interconnection.

CEN	VPC peering connection

Example

This topic provides an example based on the scenario in the following figure. A client has established an SSL-VPN connection to VPC1 and can access resources in VPC1. Remote employees also need to access resources in VPC2. To do this, first interconnect VPC1 and VPC2 by using CEN or a VPC peering connection. Then, you can add routes to the SSL server and to VPC1 or VPC2. This allows the client to access resources in VPC2 through the SSL-VPN connection.

Prerequisites

An SSL-VPN connection is established between the client and VPC1, allowing the client to access resources in VPC1. For more information, see Connect a PC or an Android client to a VPC by using an SSL-VPN connection.
On the details page of the SSL server, find the configured client CIDR block and the virtual IP address assigned to the client. You will need this information for subsequent configuration and connectivity tests.

In this example, the Client CIDR Block is 10.10.10.0/24. In the SSL Connections section, you can see that the virtual IP address assigned to the client is 10.10.10.6.

Important
Ensure that the client CIDR block does not overlap with the CIDR blocks of the resources that you want to connect in VPC1 and VPC2. Also, ensure that the CIDR blocks of VPC1 and VPC2 that you want to connect do not overlap with each other. If an overlap exists, you must modify the client CIDR block. This action interrupts the SSL-VPN connection, and the client must reconnect.

Procedure

This topic describes how to configure cross-VPC communication by using CEN or a VPC peering connection. You can choose either method.

Step 1: Interconnect the VPCs

CEN

Note

This topic describes how to use CEN to interconnect VPCs that are in different regions but belong to the same account. To use CEN for other scenarios, such as interconnecting VPCs that belong to different accounts, see CEN Quick Start.

Create a CEN instance.

When you create the CEN instance, select Create CEN Only, specify a name for the CEN instance, and keep the default values for the other parameters.
Create transit router instances.

Create one transit router (TR) instance in the China (Hangzhou) region and another in the China (Shanghai) region. Keep the default values for all other parameters.

Create VPC connections.

Connect VPC1 to the transit router in the China (Hangzhou) region and VPC2 to the transit router in the China (Shanghai) region.

Log on to the CEN console.
On the CEN Instance page, click the ID of the CEN instance that you want to manage.
On the Basic Settings > Transit Router tab, find a transit router instance and click Create Connection in the Actions column.

On the Connection with Peer Network Instance page, connect VPC1 and VPC2 to their respective transit routers based on the following configurations.

Parameter	Connect VPC1	Connect VPC2
Network Type	Select Virtual Private Cloud (VPC).	Select Virtual Private Cloud (VPC).
Region	Select China (Hangzhou).	Select China (Shanghai).
Account	Keep the default value: Your Account.
Attachment Name	Enter VPC1-Attachment.	Enter VPC2-Attachment.
Networks	Select VPC1.	Select VPC2.
vSwitch	Select vSwitch instances in zones supported by the transit router. In a region that supports multiple zones, you must select at least one vSwitch instance from each of two different zones. These two vSwitch instances provide zone-level disaster recovery for traffic between the VPC and the transit router. If you do not have enough vSwitches, you can create vSwitches.
Advanced Settings	Keep the default settings to enable all advanced options. Note If the route table of the VPC already contains a route entry whose destination CIDR block is 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16, the system cannot automatically add the route entry. You must manually add a route entry that points to the VPC connection in the VPC route table to enable communication between the VPC and the transit router. To the right of Networks, click Check Route to check whether such a route exists in the network instance.

Create an inter-region connection.

Since VPC1 and VPC2 are in different regions, you must create an inter-region connection between the transit routers in the China (Hangzhou) and China (Shanghai) regions to interconnect them.

On the Basic Settings > Transit Router tab, find a transit router instance and click Create Connection in the Actions column.

On the Connection with Peer Network Instance page, create the inter-region connection based on the following information.

Parameter	Description
Network Type	Select Inter-region Connection.
Region	Select China (Hangzhou).
Peer region	Select China (Shanghai).
Bandwidth Allocation Mode	Select Pay-By-Data-Transfer. Note If you select Pay-By-Data-Transfer, data transfer fees for the inter-region connection are billed by CDT.
Bandwidth	Enter a bandwidth value for the inter-region connection in Mbit/s.
Advanced Settings	Keep the default settings to enable all advanced options.

VPC peering connection

Note

This topic describes how to use a VPC peering connection to interconnect VPCs that are in different regions but belong to the same account. To use a VPC peering connection for other scenarios, such as interconnecting VPCs that belong to different accounts, see Use a VPC peering connection to enable private communication between VPCs.

Create a VPC peering connection.
1. Log on to the VPC Peering Connection console. In the top navigation bar, select the region of the requester VPC.
  
  In this example, VPC1 is the requester VPC. Select the China (Hangzhou) region.
2. If this is your first time using a VPC peering connection, on the VpcPeer page, click Activate CDT, and then click Activate in the dialog box that appears.
3. On the VpcPeer page, click Create VPC Peering Connection and configure the following parameters.
  
  Select the Requester VPC. For Accepter Account Type, select Your Account. For Accepter Region Type, select Cross-region. For Link Type, select Gold. For Accepter Region, select China (Shanghai). Select the Accepter VPC, and then click OK.
Configure routes for the VPC peering connection.
1. On the VpcPeer page, find the VPC peering connection that you created. In the Requester VPC column, click Configure route to add a route entry for VPC1 that points to VPC2. This allows the client to access VPC2 through VPC1. In the Configure Route Entries dialog box, set Name to to-SH, Destination CIDR Block to 172.16.0.0/16, and Next Hop to the peering connection instance. Then, click OK.
2. (Optional) In the Accepter VPC column, click Configure route to add a route entry for VPC2 that points to VPC1.
  
  After you complete this step, VPC1 and VPC2 can communicate with each other over a private connection. You can skip this step if you do not require private communication between VPC1 and VPC2.

Step 2: Add destination CIDR block

Add the CIDR block of VPC2 to the SSL server to allow the client to access resources in that CIDR block.

Note

If the client needs to access resources in multiple interconnected VPCs, you must add the CIDR blocks of all these VPCs to the SSL server.

Log on to the VPN Gateway console.
In the left-side navigation pane, choose Network Interconnection > VPN > SSL Servers.
In the top navigation bar, select the region of the SSL server.
On the SSL Servers page, find the SSL server that you want to manage and click Edit in the Actions column.
In the Modify SSL Server panel, click Add Local CIDR Block, enter the CIDR block of VPC2, and then click OK.

Step 3: Configure a route to the client

CEN

Advertise the client-bound route from VPC1 to CEN. This enables VPC2 to communicate with the client through CEN.

Log on to the VPC console.
In the top navigation bar, select the region of VPC1.
In the left-side navigation pane, click Route Tables.
On the Route Tables page, find the route table of VPC1 and click its ID.
On the Route Entry List > Custom Route tab, find the route entry with the destination CIDR block 10.10.10.0/24. In the Route Advertisement Status column for that route, click Advertise. Confirm that the status changes to Advertised to CEN. To cancel the advertisement, click Withdraw.

VPC peering connection

Log on to the VPC Peering Connection console. On the VpcPeer page, find the VPC peering connection that you created. In the Accepter VPC column, click Configure route to configure a route for VPC2 that points to the client.

Note

If the client needs to access resources in multiple interconnected VPCs, you must add a route to the client in the route table of each destination VPC.

In the Configure Route Entries dialog box that appears, set Name to to-SSL-VPN, set Destination CIDR Block to 10.10.10.0/24, select the peering connection instance as the Next Hop, and then click OK.

Step 4: Test the connectivity

After you complete the configuration, the client can access resources in VPC2, and resources in VPC2 can also access the client.

Open the command-line interface on your client.
Run the ifconfig command to view the network interface of the established SSL-VPN connection.

Run the ping <ECS IP address> -I <SSL-VPN tunnel interface> command to ping the ECS2 instance from the SSL-VPN tunnel interface. Receiving reply packets, as shown in the following output, confirms that the client can access resources in VPC2.

Note

Before you run the ping command, ensure that the security group rules of the ECS2 instance and the access control rules on the client allow ICMP traffic.

[root@iZ          Z ~]# ifconfig
eth0: flags=4163&lt;UP,BROADCAST,RUNNING,MULTICAST&gt;  mtu 1500
        inet 172.16.32.133  netmask 255.255.255.0  broadcast 172.16.32.255
        xxx
        xxx
        xxx
        xxx
        xxx
lo: flags=73&lt;UP,LOOPBACK,RUNNING&gt;  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        xxx
        xxx
        xxx
        xxx
tun0: flags=4305&lt;UP,POINTOPOINT,RUNNING,NOARP,MULTICAST&gt;  mtu 1500
        inet 10.10.10.6  netmask 255.255.255.255  destination 10.10.10.5
        xxx
        xxx
        xxx
        xxx
[root@iZ          Z ~]# ping 172.16.20.218 -I tun0
PING 172.16.20.218 (172.16.20.218) from 10.10.10.6 tun0: 56(84) bytes of data.
64 bytes from 172.16.20.218: icmp_seq=1 ttl=61 time=49.3 ms
64 bytes from 172.16.20.218: icmp_seq=2 ttl=61 time=9.72 ms
64 bytes from 172.16.20.218: icmp_seq=3 ttl=61 time=9.68 ms
64 bytes from 172.16.20.218: icmp_seq=4 ttl=61 time=9.73 ms
^Z
[1]+  Stopped                 ping 172.16.20.218 -I tun0
[root@iZb          Z ~]#

Log on to the ECS2 instance in VPC2 and run the ping <client virtual address> command to ping the client. If the ECS2 instance receives reply packets as shown in the following output, it indicates that the ECS2 instance can also access the client.

[root@iZuf		8c1Z ~]# ping 10.10.10.6
PING 10.10.10.6 (10.10.10.6) 56(84) bytes of data.
64 bytes from 10.10.10.6: icmp_seq=1 ttl=61 time=9.79 ms
64 bytes from 10.10.10.6: icmp_seq=2 ttl=61 time=9.47 ms
64 bytes from 10.10.10.6: icmp_seq=3 ttl=61 time=9.46 ms
64 bytes from 10.10.10.6: icmp_seq=4 ttl=61 time=9.45 ms
^C
[1]+  Stopped                 ping 10.10.10.6
[root@iZuf641 8c1Z ~]#

FAQ

Failed connectivity after advertising route to CEN

When you create VPC and inter-region connections with all Advanced Settings enabled, the transit router automatically propagates and learns routes. However, if you do not enable all Advanced Settings, add custom route entries, or have route conflicts in your environment, the transit router might fail to learn routes or create route entries. This can cause connection failures. Check the routes of each instance in your VPC interconnection scenario in the relevant product consoles. Ensure that each instance has routes to the interconnected VPCs and the client. If any routes are missing, add them manually. For more information, see Add a custom route entry to an Enterprise Edition transit router and Add a custom route entry.

Using the scenario in this topic as an example, click to view the descriptions of the route entries that are required for each instance to reach VPC2 and the client.

SSL server: Add the CIDR block of VPC2 to the Local CIDR Block of the SSL server.

Other instances:

Instance route table	Destination CIDR block	Next hop	Description
VPC1 system route table	172.16.0.0/12	VPC1-Attachment	A route to VPC2. If you enable the Auto-add transit router routes to all VPC route tables advanced setting when you create the VPC connection, the system automatically creates this route in the system route table of VPC1.
VPC1 system route table	10.10.10.0/24	VPN Gateway instance	A route to the client. After you create the SSL server, the system automatically creates this route in the system route table of VPC1.
China (Hangzhou) TR default route table	172.16.20.0/24	TR	A route to VPC2. If you enable the Automatically Advertise Routes to Peer Region advanced setting for the inter-region connection, the system automatically propagates this route to the default route table of the transit router in China (Hangzhou).
China (Hangzhou) TR default route table	10.10.10.0/24	VPC1-Attachment	A route to the client. After you advertise this route in VPC1, the system automatically propagates it to the default route table of the transit router in China (Hangzhou) based on the Automatically Advertise System Routes to Default Route Table of Transit Router advanced setting of VPC1-Attachment.
China (Shanghai) TR default route table	172.16.20.0/24	VPC2-Attachment	A route to VPC2. If you enable the Automatically Advertise System Routes to Default Route Table of Transit Router advanced setting when you create the VPC connection, the system automatically propagates the system routes of VPC2 to the default route table of the transit router in China (Shanghai).
China (Shanghai) TR default route table	10.10.10.0/24	TR	A route to the client. If you enable the Automatically Advertise Routes to Peer Region advanced setting for the inter-region connection, the system automatically propagates this route to the default route table of the transit router in China (Shanghai).
VPC2 system route table	10.0.0.0/8	VPC2-Attachment	A route to the client. If you enable the Auto-add transit router routes to all VPC route tables advanced setting when you create the VPC connection, the system automatically creates this route in the system route table of VPC2.