Scenario-based skill for connecting Linux servers to Alibaba Cloud VPC via IPsec VPN. Configure StrongSwan on the Linux server to establish dual-tunnel IPsec-VAN secure tunnels over the public network to access Alibaba Cloud VPC.
Triggers: "connect edge server to Alibaba Cloud VPC", "connect server to Alibaba Cloud VPC"
Connect Linux Server to Alibaba Cloud VPC via IPsec VPN (Guided)
Scenario Description
Configure IPsec on a Linux server to establish a secure tunnel over the public network connecting to an Alibaba Cloud VPC. Typical use cases: edge servers, lightweight servers, Wuying cloud desktops, and edge nodes establishing secure tunnels via public network to access Alibaba Cloud VPC internal resources.
Architecture: Linux Server (StrongSwan) ←IPsec Dual Tunnel→ VPN Gateway → VPC + VSwitch + Security Group
Preparation
Requirements:
Linux server with public IP (NAT supported) and SSH key authentication
Network: UDP 500/4500, ESP, TCP 22 allowed to this Linux server
Alibaba Cloud VPC
Resource provisioning is outside this skill's scope.
Pre-checks
1. Aliyun CLI version verification
Pre-check: Aliyun CLI >= 3.3.1 required
Run aliyun version to verify >= 3.3.1. If not installed or version too low, see references/cli-installation-guide.md for installation instructions.
Then run aliyun configure set --auto-plugin-install true to enable automatic plugin installation.
bash
aliyun version
2. Authentication credential verification
Pre-check: Alibaba Cloud Credentials Required
Security Rules:
NEVER read, echo, or print AK/SK values
ONLY use aliyun configure list to check credential status
bash
aliyun configure list
Check the output for a valid profile (AK, STS, or OAuth identity).
If no valid profile exists, STOP here and configure credentials outside of this session.
Phase 1: Permission Check
Before proceeding, verify that your Alibaba Cloud account has the necessary permissions.
IMPORTANT: Parameter Confirmation — Before executing any command or API call, ALL user-customizable parameters (e.g., RegionId, instance names, CIDR blocks, passwords, domain names, resource specifications, etc.) MUST be confirmed with the user. Do NOT assume or use default values without explicit user approval.
Phase 2: Guided Parameter Collection
Interaction Principles:
Guided & User-Friendly: Collect from basic to specific — start with foundational params (Region → VPC → VSwitch), use each to auto-query dependent options via API, then drill down to detailed configs
Interactive: All parameters MUST be explicitly confirmed by user. NO auto-selection
Immutable Once Confirmed: NEVER change a previously confirmed parameter without explicit user request
WAIT for user confirmation at each step before proceeding
Parameters to Collect
#
Parameter
Source
Depends On
1
RegionId
API query describe-regions
—
2
VpcId
API query describe-vpcs
RegionId
3
Bandwidth & Billing
User choice (recommend 10Mbps, 1yr)
—
4
VPN Gateway Name
Auto-suggest ipsec-vpn-{REGION}-{DATE}
RegionId
5
Primary VSwitchId
API query describe-vpn-gateway-available-zones + describe-vswitches
RegionId, VpcId, Bandwidth
6
Backup VSwitchId
Same as above (must be different AZ)
Same as above
7
Server Public IP
User input (validate IPv4, warn if RFC1918)
—
8
SSH Username
User input (default: root)
—
9
SSH Private Key
User input (path to key file, default: ~/.ssh/id_rsa)
—
10
LocalSubnet
Recommend full VPC CIDR from Step 2
VpcId
11
RemoteSubnet
User input (MUST be internal subnet, NOT public IP, NOT 0.0.0.0/0)
Recommend pairs spanning different AZs. Validate: primary and backup MUST be in different AZ.
Step 2.5: Server Information
Server Public IP: User input. Validate IPv4 format; warn if RFC1918 private range detected.
SSH Username: Default root. User can specify other admin user.
SSH Private Key: Path to private key file (e.g., ~/.ssh/id_rsa).
SSH IP: Default same as Server Public IP. User can override if SSH uses a different IP/port.
Step 2.6: Network Planning
LocalSubnet: Recommend full VPC CIDR {VPC_CIDR} from Step 2.2
RemoteSubnet: User input. Can SSH to server and run ip addr show to get internal subnet. ⚠️ MUST be internal subnet (e.g., 10.0.0.0/24), NOT public IP or 0.0.0.0/0
⚠️ Save PSK securely. NEVER echo in plain text. Offer: use generated / regenerate / enter custom (min 16 chars).
Phase 3: Server-side Pre-check
SSH to server and collect network info before creating cloud resources:
bash
ssh -o StrictHostKeyChecking=no -i {SSH_KEY_PATH} {SSH_USER}@{SSH_IP}
ip addr show && ip route show
Record: Server Internal IP, Local Subnet (e.g., 10.0.0.0/24), Default Gateway, Network Interface.
⚠️ RemoteSubnet in IPsec config must use server's internal subnet, NOT public IP or 0.0.0.0/0.
OS & Privileges: Check OS type, admin privileges, network connectivity, StrongSwan status (which strongswan swanctl). See references/server-precheck.md.
Phase 4: Confirm Configuration
Display collected parameters and ask user to confirm before proceeding. Explain the upcoming steps.
If you encounter InvalidVSwitchId.SecondVswitchNotSupport error when create vpn gateway, after double check the existance of this VSwitch, it means the availability zone of the backup VSwitch does not support VPN deployment.
Solution: Query VPN-supported availability zones and select a VSwitch in a suitable zone within the same VPC.
Note: Always use dual-tunnel mode. Do not fallback to single-tunnel mode.
Important: Current CLI version has limited support for --tunnel-options-specification parameter in plugin mode. Must use RPC style command with --method POST --force parameters.
Note: This command uses RPC API style (traditional format) because the current plugin mode create-vpn-connection command has compatibility issues when handling --tunnel-options-specification parameter for dual-tunnel mode. Recommend reporting to Alibaba Cloud CLI team to improve plugin mode support.
Record VpnConnectionId.
Phase 6: Add VPC Routes
⚠️ Important: Manual route addition may be required even with --auto-config-route=true.
MUST read and follow the referenced document before proceeding
Pre-configuration backup and validation steps
Installation commands (Ubuntu/Debian/CentOS)
/etc/swanctl/swanctl.conf template with dual-tunnel setup using VICI
/etc/strongswan.conf configuration with VICI plugin
Firewall rules (UDP 500/4500, ESP protocol)
Kernel parameter setup (net.ipv4.ip_forward)
Connection initiation and rollback procedures
Note: Must use the VICI (Versatile IKE Configuration Interface) method with swanctl.conf instead of the legacy ipsec.conf format. This allows both tunnels to be UP simultaneously using priority-based routing.
