Building Hybrid Global Networks with Cloud Enterprise Network (CEN) and VPN Gateway
By Oliver Arafat, Staff Solution Architect, and Fabien Locquet, Solution Architect
This document outlines the necessary steps and highlights the caveats when enabling Alibaba Cloud’s Cloud Enterprise Network (CEN) service to support VPN Gateways routes to either connect to an Internet data center (IDC) or another Virtual Private Cloud (VPC).
This document describes the following scenarios:
- CEN and VPCs all belong to a single billing account
- CEN and VPCs are spread across multiple billing accounts
Scenario 1: VPCs in a Single Billing Account
The following diagram illustrates the target architecture. VPC C in Figure 1 could also be an IDC network.
In this scenario, VPC A and B, CEN and VPN A all belong to the same Billing Account.
We will also discuss the necessary steps when attaching VPC from other accounts as depicted in Figure 1 in the second part of this paper.
Figure 1: Target Scenario for VPCs in a single Account
CEN doesn’t put constraint on the VPC CIDRs themselves. However, the VSwitch CIDRs of the different VPCs included in the CEN must be carefully chosen: Overlapping VSwitch CIDRs will be rejected by CEN.
Solution Implementation Steps
The following sub-sections will discuss how to setup and configure the CEN-service, VPCs, routing tables, and VPN-Gateway accordingly.
The provisioning and configuration of the CEN-Instance is straight forward and does not contain any special steps outside of the standard setup. It follows the standard approach:
- Create a CEN-Instance
- Attach the VPC A and VPC B to the CEN-Instance
- For inter-region communication make sure to buy an according bandwidth package and assign a bandwidth of at least 1 Mbps between the regions where VPC A and VPC B are located (note that for pure connectivity tests the built-in and free of charge bandwidth of 1 kbps might also be sufficient)
- For intra-region communication there is no need to buy a bandwidth package and assign bandwidths since it is free of charge.
Note that you do not need to add any routing table entries since CEN will automatically learn the routes to route data packets from VPC A to VPC B and vice-versa.
Connectivity between VPC A and VPC B can be tested by provisioning according ECS instances in both VPCs assigned to VSwitch which defines a subnet within the VPC.
Once this has been done a simple $ ping command can be used to verify correct packet routing through the private backbone network of Alibaba Cloud as depicted in below screenshots:
Pinging from VPC B to VPC A:
Pinging from VPC A to VPC B:
This is already very well explained in the Alibaba Cloud official documentation. For this reason, we will not elaborate much on this topic but rather refer to the two tutorials located at:
- Configure a site-to-site connection via IPsec (https://www.alibabacloud.com/help/doc-detail/65072.htm)
- Configure a VPC-to-VPC connection via IPsec (https://www.alibabacloud.com/help/doc-detail/65073.htm)
- VPN Gateway consumes 3 IP addresses of one of the VSwitch in the selected VPC. It seems that it chooses the VSwitch in the first AZ if multiple VSwitches exist. Given that, when trying to delete this VSwitch, it will fail because of the dependency on the VPN Gateway.
- This Dependency is not shown in the VSwitch dependency panel in the Alibaba Cloud Console, and the error thrown when trying to delete a VSwitch without removing first the associated VPN Gateway is not providing indications.
VPN-Routes Publishing to CEN
After the VPN has been setup and the IDC / VPC C has been interconnected with VPC B the VPN route in VPC B needs to be advertised to the CEN.
As depicted in Figure 1 the routing table of VPC B has been modified with the following entry:
DestinationNext Hop192.168.0.0/24VPN A
This route is, however, not visible to VPC A and not known to CEN. Thus, any request from VPC A to an IP address within the range 192.168.0.0/24 will not be routed anywhere.
In order to advertise this route to CEN it must be published to the CEN-Instance.
This can easily be done from the console. You need to navigate to the routing table of the particular VPC where you will find the according entry. Simply klick on the link “Publish” to advertise the route to all CEN-connected VPCs.
Under the hood this actually calls the OpenAPI PublishRouteEntries which is defined in the API documentation at https://www.alibabacloud.com/help/doc-detail/85470.htm
This allows you to also programmatically publish the route to CEN. There is a great online tool that allows to easily generate and execute according API calls (make sure to be logged in, otherwise you will be redirected to the Chinese portal):
You need to populate the fields similar to below screenshot:
Figure 2: Publishing CEN Route using the Open API Explorer
- CenId is the id of your CEN-Instance
- ChildInstanceId is the id of VPC where the routing table is located. In our example this would be VPC B.
- ChildInstance Type is the type of the network which is VPC in our scenario
- ChildInstanceRegionId is the region in where the VPC is located
- ChildInstanceRouteTableId is the ID of the routing table defined in VPC B (not the VRouter id, be careful!)
- DestinationCidrBlock is destination CIDR block of the route entry to publish.
Once this is submitted, the route will be published to the CEN-Instance and be visible in the routing entries. In our example this will be similar to
DestinationNext Hop192.168.0.0/24VPC B
Where this entry is actually automatically added by CEN to the routing table of VPC A as depicted in below screenshot:
So any request against the defined IP-range will be routed to VPC B and from there to the VPN-Gateway, and thus to the IDC network or (in our scenario) to VPC C.
Scenario 2: VPCs in Multiple Billing Accounts
This section describes another very interesting feature of CEN: A CEN-instance can include VPC belonging to other Billing Accounts.
In the following, we’re going to focus on the differences with the main scenario described in the previous section.
The target architecture is the following:
Figure 3: Target Scenario for VPC in multiple Accounts
In this specific example, there is one Account owning the CEN-instance and a VPC, and another one owning only one VPC.
Other scenarios can also be fulfilled with this approach: One account only owns the CEN-instance, and all VPCs are owned by other Accounts for example.
Solution Implementation Steps
CEN is created as described in the previous section, in Account 1.
Then CEN-instance in Account 1 then needs to be set as “trusted” in the VPC in Account 2. This is done by navigating to the VPC configuration page in the Console, and selecting ‘CEN Cross Account Authorization’, as shown below.
Figure 4: Cross Account CEN Authorization
Then enter the Account UId and the CEN id:
Figure 5: Entering Remote Account and CEN IDs
It then appears in the VPC trusted CEN list:
Figure 6: VPC Cross-Account Trusted CENs
Be aware that this only authorize the CEN in Account 1 to attach the VPC in Account 2.
Now the VPC actually has to be attached to the CEN, and this is done in the CEN management page in Account 1. Select “Attach Network”, and then select the tab “Different Account”:
Figure 7: Attach VPC from a different Account in CEN
VPN setup is the same as described in the previous section.
The last difference with single Account is how the route to the network served by the VPN is added to the CEN routing table.
In this case, publishing the route is not done in the Account owning the CEN, but instead in the Account owning the VPC containing the VPN Gateway.
In our scenario here, it means that the API PublishRouteEntries call shall be done in Account 2, instead of Account 1.
Once done, the connectivity can be tested by creating an instance in VPC A and one in VPC C and trying to make them ping each other, as described in the first part.
This document outlines the necessary steps to realize a VPN Gateway connectivity from on-premises networks to other VPCs that could be deployed in just about any region, including mainland China. Cloud Enterprise Network (CEN) will make sure that latency is consistently low and packet loss almost zero allowing for highly reliable and performant global hybrid network architectures which can be deployed in minutes.