VPN Gateway:Get started: IPsec connection to a transit router

Resource planning

• Cloud: A Virtual Private Cloud (VPC) with the 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: Deployed in a vSwitch with the IP address 10.0.0.1 for connectivity testing.

  • CEN instance: Used to host the Transit Router.

  • Transit Router: Created in the China (Hangzhou) region, with a TR CIDR block of 10.10.10.0/24. This CIDR block cannot overlap with the VPC or on-premises IDC CIDR blocks.

• On-premises: An on-premises IDC with the 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. The encryption parameters must be identical on both ends of the tunnels.

• Routing method: destination-based routing. You will add a static route to the Transit Router's route table, directing traffic destined for the on-premises IDC to the IPsec connection.

Prerequisites

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

• A VPC is created, with two vSwitches in different availability zones. At least one ECS instance exists within the VPC to test connectivity.

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

  • The VPC is attached to the TR.

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

  • A CIDR block is configured for the TR.

• A Linux server is deployed in your on-premises IDC. This tutorial uses CentOS Stream 9 as an example. The server must have a public IP address. You will install strongSwan on this server to act as the on-premises gateway device.

1. Configure firewall rules

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

The following commands use iptables as an example. Adjust the commands based on the firewall tool you use.

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, you need to differentiate traffic between the tunnels. Create XFRM virtual interfaces to 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 to automatically bring down the corresponding XFRM interface when a tunnel is disconnected. This allows the Linux 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 ensure the XFRM interfaces and routes are persistent after a 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 and save the following configuration. Replace the 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 a status of ESTABLISHED and the CHILD_SA status is INSTALLED, the IPsec connection between the strongSwan device and Alibaba Cloud 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. First, ensure that the security group rules for the ECS instance allow ICMP traffic. Then, log on to the strongSwan device and run the following command to ping the ECS instance:

   ping 10.0.0.1

   If you receive a reply, the connection between the VPC and the on-premises IDC is established.

2. First, ensure that the strongSwan device or another on-premises server allows ICMP traffic. Then, log on to the ECS instance (10.0.0.1) in the VPC and ping the strongSwan device's private IP address:

   ping 172.16.0.1

   If you receive a reply, the reverse connection is also working correctly.

Test high availability

By default, an IPsec connection attached to a Transit Router uses both tunnels simultaneously for load balancing and high availability in an Equal-Cost Multi-Path (ECMP) configuration. 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 of the tunnels. For example, in the Alibaba Cloud console, modify the pre-shared key for Tunnel 1 to create a key mismatch. This will cause the tunnel to disconnect.

3. Observe the ping results. Pings should resume after a brief interruption, indicating that traffic has automatically failed over to Tunnel 2.

4. Restore the tunnel by changing the pre-shared key for Tunnel 1 back to the correct value. After the tunnel is re-established, traffic will again be load-balanced across both tunnels.