Connect your on-premises Internet Data Center (IDC) to an Alibaba Cloud Virtual Private Cloud (VPC) using a Traditional VPN Gateway and open-source strongSwan software.
What you accomplish in this tutorial:
Create a Traditional VPN Gateway on Alibaba Cloud
Register your on-premises gateway as a customer gateway
Create an IPsec connection in dual-tunnel mode
Configure strongSwan on a Linux server as the on-premises gateway
Publish cloud routes and verify bidirectional connectivity
How it works
The VPN Gateway establishes a dual-tunnel IPsec connection to your on-premises strongSwan device. Traffic between the VPC and the IDC is encrypted and routed through these tunnels using destination-based routing (traffic selectors). One tunnel is active; the other is on standby for automatic failover.
Scenario
This tutorial uses the following setup:
A VPC in the China (Hangzhou) region with CIDR block
10.0.0.0/16An on-premises IDC with CIDR block
172.16.0.0/16and a single public egress IP
This tutorial covers a single-public-egress-IP scenario with static routing. For dual-public-egress-IP or BGP dynamic routing scenarios, see strongSwan configuration examples.
Resource plan
Cloud resources
| Resource | Value |
|---|---|
| VPC CIDR | 10.0.0.0/16 — China (Hangzhou) |
| vSwitch 1 | Availability zone I, CIDR 10.0.0.0/24 |
| vSwitch 2 | Availability zone J, CIDR 10.0.1.0/24 |
| ECS instance | IP 10.0.0.1, located in vSwitch 1 |
| VPN Gateway — active tunnel IP | XX.XX.1.1 (assigned after creation) |
| VPN Gateway — standby tunnel IP | XX.XX.2.2 (assigned after creation) |
On-premises resources
| Resource | Value |
|---|---|
| IDC CIDR | 172.16.0.0/16 |
| strongSwan device private IP | 172.16.0.1 |
| Public egress IP | XX.XX.3.3 |
Encryption configuration: The default console settings — AES-128 / SHA-1 / DH Group 2 (modp1024 in strongSwan notation). The encryption algorithm, authentication algorithm, and DH group must be identical on both ends.
Routing: Destination-based routing. The system uses the VPC and IDC CIDR blocks as traffic selectors and automatically routes matching traffic through the VPN tunnel.
Prerequisites
Before you begin, ensure that you have:
A VPC with two vSwitches in different availability zones, as specified in the resource plan above, with non-overlapping CIDR blocks between the VPC and the on-premises IDC
At least one Elastic Compute Service (ECS) instance in the VPC to test connectivity after setup
A Linux server with one public egress IP deployed in the on-premises IDC — this tutorial uses CentOS Stream 9 (64-bit) as an example; you will install strongSwan on this server to act as the on-premises gateway
Step 1: Create a Traditional VPN Gateway
Go to the VPN Gateway pageVPN Gateway page and click Create VPN Gateway.
Configure the following parameters:
Parameter Value Instance Name A descriptive name, such as vpn-gw-docdevRegion and zone The region where your VPC is located — China (Hangzhou) in this tutorial Gateway Type Standard Network Type Public VPC The VPC you want to connect vSwitch 1 The vSwitch in availability zone I vSwitch 2 The vSwitch in availability zone J (must be a different zone from vSwitch 1 to ensure cross-zone high availability) Bandwidth Based on your business requirements IPsec-VPN Enable SSL-VPN Close Billing Cycle Default Create Service-Linked Role Make sure this is created — the VPN Gateway uses this role to access resources in other cloud services Click Buy Now and complete the payment.
The VPN Gateway takes 1–5 minutes to initialize. After initialization, the system assigns two public IP addresses — one for the active tunnel and one for the standby tunnel.
Step 2: Create a customer gateway
A customer gateway stores the public IP address of your on-premises gateway device. Because this scenario has a single public egress IP, create one customer gateway.
In the left-side navigation pane of the VPN Gateway console, click Customer Gateways.
Click Create Customer Gateway and set the following:
Parameter Value Name A descriptive name, such as cgw-idc-docdevIP Address The public egress IP of your on-premises IDC ( XX.XX.3.3)
Step 3: Create an IPsec connection
In the left-side navigation pane, click IPsec Connections, then click Bind VPN Gateway.
Configure the basic parameters:
Parameter Value Name A descriptive name, such as ipsec-docdevRegion China (Hangzhou) Bind VPN Gateway The VPN Gateway created in Step 1 Routing Mode Destination Routing Mode — defines CIDR blocks at both ends; the system automatically routes matching traffic and generates routes Local Network 10.0.0.0/16(VPC CIDR block)Remote Network 172.16.0.0/16(IDC CIDR block)Effective Immediately Yes — Alibaba Cloud proactively initiates negotiation with the remote peer, so the connection comes up as soon as you configure the on-premises side Enable BGP Disabled (not used in this tutorial) Configure the tunnel parameters:
Tunnel 1 (Primary):
Parameter Value Customer Gateway The customer gateway created in Step 2 Pre-Shared Key A strong key with uppercase and lowercase letters, digits, and special characters. Record this value — you will need it for strongSwan. Encryption Configuration Keep the defaults: AES-128 / SHA-1 / DH Group 2 Tunnel 1 (Backup):
Parameter Value Customer Gateway The same customer gateway as the active tunnel (the IDC has only one public egress IP) Pre-Shared Key Use the same key as the active tunnel for this tutorial Encryption Configuration Keep the defaults, identical to the active tunnel Click OK. When prompted to publish the route, click Cancel for now — you will do this in Step 5.
The IPsec connection takes about 5 minutes to initialize. During this time, the status shows Preparing and route configuration is unavailable. Proceed to Step 4 to configure strongSwan while you wait.
Record the cloud tunnel IP addresses — you will need them in Step 4. Return to the IPsec-VPN connection list and find the connection you just created. In the Gateway IP Address column, record:
IPsec Address 1 (active tunnel):
XX.XX.1.1IPsec Address 2 (standby tunnel):
XX.XX.2.2
Step 4: Configure strongSwan
The following information about third-party products is for reference only. Alibaba Cloud does not make any warranties, express or implied, for the performance or reliability of third-party products, or for any impact from operations you perform on them.
The steps below apply to CentOS Stream 9 (64-bit). For other operating systems, see the official strongSwan documentation.
1. Configure firewall rules
On the strongSwan server, allow inbound traffic from the two Alibaba Cloud IPsec addresses on:
ESP protocol (IP protocol number 50)
UDP port 500
UDP port 4500
The following uses iptables as an example. Adjust the commands for your firewall tool:
iptables -I INPUT -s XX.XX.1.1,XX.XX.2.2 -p esp -j ACCEPT
iptables -I INPUT -s XX.XX.1.1,XX.XX.2.2 -p udp --dport 500 -j ACCEPT
iptables -I INPUT -s XX.XX.1.1,XX.XX.2.2 -p udp --dport 4500 -j ACCEPT2. Enable IP forwarding
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sudo sysctl -p3. Install strongSwan
dnf install epel-release -y
dnf install strongswan -y4. Create the strongSwan configuration
Back up the original configuration file:
mv /etc/strongswan/swanctl/swanctl.conf /etc/strongswan/swanctl/swanctl.conf.bakCreate a new configuration file:
vi /etc/strongswan/swanctl/swanctl.confAdd the following configuration. Replace all values marked
(Modify)with your actual values:# strongSwan dual-tunnel IPsec-VPN configuration for: # - Alibaba Cloud Traditional VPN Gateway # - On-premises single public egress IP # - Destination-based routing (traffic selector) # # You only need to modify parameters marked with "(Modify)". # Algorithm note: aes128-sha1-modp1024 corresponds to AES-128 / SHA-1 / DH Group 2 (console default). # High-availability logic: vco1 (priority=1) is the active tunnel, and vco2 (priority=2) is the standby tunnel. Failover is automatic. connections { # === Tunnel 1 (Active) === vco1 { version = 2 dpd_delay = 10 rekey_time = 84600 over_time = 1800 proposals = aes128-sha1-modp1024 encap = yes local_addrs = 172.16.0.1 # (Modify) Private IP of the strongSwan NIC. In a NAT environment, use the private IP. If the NIC is bound to the public IP, use the public IP. local { auth = psk id = XX.XX.3.3 # (Modify) On-premises public egress IP. } remote_addrs = XX.XX.1.1 # (Modify) Public IP of Tunnel 1 on Alibaba Cloud. remote { auth = psk id = XX.XX.1.1 # (Modify) Public IP of Tunnel 1 on Alibaba Cloud. Must match remote_addrs. } children { vco_child1 { local_ts = 172.16.0.0/16 # (Modify) On-premises traffic selector CIDR block. remote_ts = 10.0.0.0/16 # (Modify) Alibaba Cloud traffic selector CIDR block. mode = tunnel rekey_time = 85500 life_time = 86400 dpd_action = restart start_action = start close_action = start esp_proposals = aes128-sha1-modp1024 priority = 1 # Specifies the active tunnel. Do not modify. } } } # === Tunnel 2 (Standby) === vco2 { version = 2 dpd_delay = 10 rekey_time = 84600 over_time = 1800 proposals = aes128-sha1-modp1024 encap = yes local_addrs = 172.16.0.1 # (Modify) Private IP of the strongSwan NIC. Same as Tunnel 1. local { auth = psk id = XX.XX.3.3 # (Modify) On-premises public egress IP. Same as Tunnel 1. } remote_addrs = XX.XX.2.2 # (Modify) Public IP of Tunnel 2 on Alibaba Cloud. remote { auth = psk id = XX.XX.2.2 # (Modify) Public IP of Tunnel 2 on Alibaba Cloud. Must match remote_addrs. } children { vco_child2 { local_ts = 172.16.0.0/16 # (Modify) On-premises traffic selector CIDR block. Same as Tunnel 1. remote_ts = 10.0.0.0/16 # (Modify) Alibaba Cloud traffic selector CIDR block. Same as Tunnel 1. mode = tunnel rekey_time = 85500 life_time = 86400 dpd_action = restart start_action = start close_action = start esp_proposals = aes128-sha1-modp1024 priority = 2 # Specifies the standby tunnel. Do not modify. } } } } secrets { ike-vco1 { id = XX.XX.1.1 # (Modify) Public IP of Tunnel 1 on Alibaba Cloud. secret = your-psk-here # (Modify) Pre-shared key for Tunnel 1. Must match the key configured on Alibaba Cloud. } ike-vco2 { id = XX.XX.2.2 # (Modify) Public IP of Tunnel 2 on Alibaba Cloud. secret = your-psk-here # (Modify) Pre-shared key for Tunnel 2. Must match the key configured on Alibaba Cloud. } }
5. Start strongSwan and verify the tunnel status
sudo systemctl restart strongswan
swanctl --load-all
watch swanctl --list-sasBoth tunnels should show ESTABLISHED status with CHILD_SA status INSTALLED. This confirms the IPsec connection between strongSwan and the Alibaba Cloud VPN Gateway is up.
Step 5: Publish cloud routes
Because this tutorial uses destination-based routing, the system automatically generates a route entry in the VPN Gateway's Policy-based Route Table. Publish this route to the VPC route table so that ECS instances can reach the on-premises IDC.
Go to the VPN Gateway list and click the instance ID of the gateway you created in Step 1.
Click the Policy-based Route Table tab. The system has automatically generated a route entry with destination
172.16.0.0/16and next hop set to the IPsec connection.In the Actions column for that route entry, click Advertise.
After publishing, a new route entry appears in the VPC route table: destination 172.16.0.0/16, next hop is the VPN Gateway. Traffic from ECS instances to the IDC now flows through the VPN tunnel automatically.
Verify connectivity
Basic connectivity
Make sure the security group for the ECS instance allows inbound ICMP traffic. Then, from the strongSwan server, ping the ECS instance:
ping 10.0.0.1A successful reply confirms communication from the IDC to the VPC.
Make sure your on-premises firewall allows inbound ICMP traffic. Then, log in to the ECS instance (
10.0.0.1) and ping the strongSwan device:ping 172.16.0.1A successful reply confirms reverse connectivity from the VPC to the IDC.
Verify high availability
Start a long-running ping from the ECS instance to the on-premises server:
ping 172.16.0.1 -c 10000Interrupt the active tunnel: in the Alibaba Cloud console, change the pre-shared key of the active tunnel to create a mismatch.
Watch the ping output. After a brief interruption, communication resumes — traffic has failed over to the standby tunnel automatically.
Restore the active tunnel: change the pre-shared key back to the correct value. Traffic fails back after the tunnel recovers.
Troubleshooting
| Symptom | Possible cause | Solution |
|---|---|---|
| Console shows Negotiation Failed | Network connectivity issue | Verify that the strongSwan server can reach the VPN Gateway public IPs. Verify that the on-premises firewall allows UDP port 500 and port 4500. |
| Console shows Negotiation Failed | Pre-shared key mismatch | Verify the pre-shared keys are identical on both ends, including case and special characters. |
| Console shows Negotiation Failed | IKE parameter mismatch | Verify the IKE version, encryption algorithm, authentication algorithm, and DH group match on both ends. Traditional VPN Gateways do not support multiple algorithm suites — the parameters must be identical. |
| Tunnel is established, but ping fails | Route not published | Verify the VPN Gateway route has been published to the VPC route table (Step 5). |
| Tunnel is established, but ping fails | Security group restriction | Verify the ECS instance security group allows ICMP traffic from the IDC network (172.16.0.0/16). |
| Tunnel is established, but ping fails | On-premises firewall restriction | Verify the on-premises firewall allows traffic from the VPC (10.0.0.0/16). |
| Tunnel is established, but ping fails | Missing route on strongSwan device | Confirm IP forwarding is enabled. Confirm that other servers in the IDC have a route to the VPC network with the strongSwan device as the next hop. |
What's next
For more strongSwan configuration scenarios — including dual public egress IPs and BGP dynamic routing — see strongSwan configuration examples.