VPN Gateway:Bind to a transit router

Resource planning

• Cloud: A VPC with CIDR block 10.0.0.0/16 in the China (Hangzhou) region.

  • vSwitch 1: In availability zone H, with the CIDR block 10.0.0.0/24.

  • vSwitch 2: In availability zone J, with the CIDR block 10.0.2.0/24.

  • ECS instance: IP address 10.0.0.1, used for connectivity testing.

  • CEN instance: Hosts the Transit Router.

  • Transit Router: In the China (Hangzhou) region, with a TR CIDR block of 10.10.10.0/24. Must not overlap with the VPC or IDC CIDR blocks.

• On-premises: IDC with CIDR block 172.16.0.0/16.

  • strongSwan device: Private IP address 172.16.0.1.

  • Public IP address: XX.XX.3.3.

• Encryption algorithm: IKEv2 / AES-128-CBC / SHA-1 / DH Group 2. Parameters must match on both tunnel endpoints.

• Routing method: Destination-based routing. You add a static route to the Transit Router's route table to direct IDC-bound traffic to the IPsec connection.

Prerequisites

• The VPC and on-premises IDC CIDR blocks do not overlap.

• A VPC is created with two vSwitches in different availability zones. At least one ECS instance exists in the VPC for connectivity testing.

• A CEN instance and a Transit Router (TR) are created with the following conditions met:

  • The VPC is attached to the TR.

  • Route propagation and route propagation are enabled between the VPC and the TR.

  • A CIDR block is configured for the TR.

• A Linux server with a public IP address is deployed in your on-premises IDC. This tutorial uses CentOS Stream 9. You install strongSwan on this server as the on-premises gateway device.

1. Configure firewall rules

On the strongSwan device, allow inbound ESP protocol (IP protocol number 50), UDP port 500, and UDP port 4500 from the two cloud-side IPsec addresses.

The following example uses iptables. Adjust 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 ACCEPT

2. Enable IP forwarding

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sudo sysctl -p

3. Install strongSwan

sudo dnf install epel-release -y
sudo dnf install strongswan -y

4. Create XFRM interfaces and an updown script

In a dual-tunnel scenario, create XFRM virtual interfaces to differentiate tunnel traffic and avoid kernel routing policy conflicts.

# Create XFRM interfaces for Tunnel 1 and Tunnel 2 respectively
sudo ip link add xfrm1 type xfrm dev eth0 if_id 1
sudo ip link add xfrm2 type xfrm dev eth0 if_id 2
sudo ip link set xfrm1 up
sudo ip link set xfrm2 up

# Add an ECMP route to load-balance traffic to the cloud CIDR block across both tunnels
sudo ip route add 10.0.0.0/16 nexthop dev xfrm1 weight 1 nexthop dev xfrm2 weight 1

Create an updown script that brings down the corresponding XFRM interface when a tunnel disconnects, allowing the kernel to redirect traffic to the active tunnel.

sudo tee /usr/local/bin/xfrm-updown.sh > /dev/null << 'EOF'
#!/bin/bash
XFRM_IF="xfrm${PLUTO_IF_ID_IN}"
case "${PLUTO_VERB}" in
    up-client)
        ip link set "${XFRM_IF}" up 2>/dev/null
        ;;
    down-client)
        ip link set "${XFRM_IF}" down 2>/dev/null
        ;;
esac
EOF
sudo chmod +x /usr/local/bin/xfrm-updown.sh

To persist XFRM interfaces and routes after reboot, add the commands to a startup script.

5. Configure strongSwan

1. Back up the original configuration file:

   mv /etc/strongswan/swanctl/swanctl.conf /etc/strongswan/swanctl/swanctl.conf.bak

2. Create a new configuration file:

   vi /etc/strongswan/swanctl/swanctl.conf

3. Add the following configuration. Replace example IP addresses and keys with your actual values.

   # strongSwan dual-tunnel IPsec-VPN configuration
   # For an IPsec connection attached to an Alibaba Cloud Transit Router
   # with a single on-premises public IP, using destination-based routing.
   #
   # Only modify parameters marked with "(Modify)". Keep default values for other parameters.
   # This configuration uses XFRM interfaces (if_id) to differentiate tunnel traffic and ECMP for load balancing.
   
   connections {
   
      # === Tunnel 1 ===
      tunnel1 {
         version = 2
         dpd_delay = 10s
         rekey_time = 86400s
         proposals = aes128-sha1-modp1024
   
         local_addrs  = 172.16.0.1               # (Modify) Private IP of the strongSwan server's NIC. In a NAT environment, use the private IP.
         local {
            auth = psk
            id = XX.XX.3.3                         # (Modify) The on-premises public IP address.
         }
   
         remote_addrs = XX.XX.1.1                  # (Modify) The public IP address of Tunnel 1 on Alibaba Cloud.
         remote {
            auth = psk
            id = XX.XX.1.1                         # (Modify) Same public IP as remote_addrs above.
         }
   
         children {
            tunnel1-child {
               local_ts  = 0.0.0.0/0
               remote_ts = 0.0.0.0/0
               mode = tunnel
               esp_proposals = aes128-sha1-modp1024
               dpd_action = restart
               start_action = start
               close_action = start
               updown = /usr/local/bin/xfrm-updown.sh
               if_id_in = 1                        # Corresponds to the xfrm1 interface.
               if_id_out = 1
            }
         }
   
         if_id_in = 1
         if_id_out = 1
      }
   
      # === Tunnel 2 ===
      tunnel2 {
         version = 2
         dpd_delay = 10s
         rekey_time = 86400s
         proposals = aes128-sha1-modp1024
   
         local_addrs  = 172.16.0.1               # (Modify) Same private IP as for Tunnel 1.
         local {
            auth = psk
            id = XX.XX.3.3                         # (Modify) Same on-premises public IP as for Tunnel 1.
         }
   
         remote_addrs = XX.XX.2.2                  # (Modify) The public IP address of Tunnel 2 on Alibaba Cloud.
         remote {
            auth = psk
            id = XX.XX.2.2                         # (Modify) Same public IP as remote_addrs above.
         }
   
         children {
            tunnel2-child {
               local_ts  = 0.0.0.0/0
               remote_ts = 0.0.0.0/0
               mode = tunnel
               esp_proposals = aes128-sha1-modp1024
               dpd_action = restart
               start_action = start
               close_action = start
               updown = /usr/local/bin/xfrm-updown.sh
               if_id_in = 2                        # Corresponds to the xfrm2 interface.
               if_id_out = 2
            }
         }
   
         if_id_in = 2
         if_id_out = 2
      }
   }
   
   secrets {
      ike-tunnel1 {
         id-1 = XX.XX.3.3                          # (Modify) The on-premises public IP address.
         id-2 = XX.XX.1.1                          # (Modify) The public IP address of Tunnel 1 on Alibaba Cloud.
         secret = "your-psk-here"                  # (Modify) The pre-shared key for Tunnel 1. Must match the key on Alibaba Cloud.
      }
      ike-tunnel2 {
         id-1 = XX.XX.3.3                          # (Modify) The on-premises public IP address.
         id-2 = XX.XX.2.2                          # (Modify) The public IP address of Tunnel 2 on Alibaba Cloud.
         secret = "your-psk-here"                  # (Modify) The pre-shared key for Tunnel 2. Must match the key on Alibaba Cloud.
      }
   }

   Important

   • The if_id_in and if_id_out parameters bind each tunnel to its corresponding XFRM interface (xfrm1 or xfrm2), ensuring that traffic from the two tunnels does not interfere.

   • The local_ts and remote_ts traffic selectors are set to 0.0.0.0/0. The routing table on the XFRM interface determines which traffic enters the tunnel. In destination-based routing, the cloud-side traffic selectors are also set to 0.0.0.0/0.

6. Start strongSwan and verify tunnel status

sudo systemctl enable strongswan
sudo systemctl restart strongswan
sudo swanctl --load-all
sudo swanctl --list-sas

If both tunnels show ESTABLISHED status and CHILD_SA shows INSTALLED, the IPsec connection is successfully established.

# Example of expected output (abbreviated)
tunnel1: #1, ESTABLISHED, IKEv2
  tunnel1-child: #1, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96
tunnel2: #2, ESTABLISHED, IKEv2
  tunnel2-child: #2, reqid 2, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96

Test connectivity

1. Ensure the security group rules for the ECS instance allow ICMP traffic. Log on to the strongSwan device and ping the ECS instance:

   ping 10.0.0.1

   A reply confirms connectivity between the VPC and the on-premises IDC.

2. Ensure the strongSwan device or another on-premises server allows ICMP traffic. Log on to the ECS instance (10.0.0.1) in the VPC and ping the strongSwan device:

   ping 172.16.0.1

   A reply confirms bidirectional connectivity.

Test high availability

By default, an IPsec connection attached to a Transit Router uses both tunnels simultaneously in an Equal-Cost Multi-Path (ECMP) configuration for load balancing and high availability. If one tunnel fails, traffic automatically fails over to the other active tunnel without manual intervention.

1. Start a continuous ping from the ECS instance to a server in the on-premises IDC:

   ping 172.16.0.1 -c 10000

2. Interrupt one tunnel. For example, modify the pre-shared key for Tunnel 1 in the console to cause a mismatch and disconnect the tunnel.

3. Observe the ping results. Pings resume after a brief interruption, confirming automatic failover to Tunnel 2.

4. Restore Tunnel 1 by reverting the pre-shared key to the correct value. After re-establishment, traffic is load-balanced across both tunnels again.