Getting started with binding IPsec-VPN to 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: Created in the East China 1 (Hangzhou) region. TR address range: 10.10.10.0/24 (must not conflict with the VPC, IDC, or BGP 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 / SHA-1 / DH Group 2 / SA lifetime 86400 seconds. Both ends of the tunnel must be configured with the same encryption parameters.

• Routing mode: Use BGP dynamic routing. BGP CIDR block planning is as follows (the tunnel CIDR block must be a /30 within 169.254.0.0/16, and the two tunnels cannot be the same).

  Resource	Tunnel	tunnel subnet	BGP IP address	BGP AS number
  IPsec connection (cloud side)	Tunnel 1	169.254.10.0/30	169.254.10.1	65535
  	Tunnel 2	169.254.20.0/30	169.254.20.1	65535
  Local gateway device (IDC)	Tunnel 1	169.254.10.0/30	169.254.10.2	65530
  	Tunnel 2	169.254.20.0/30	169.254.20.2	65530

  The local autonomous system number of both tunnels must be the same; the remote (IDC) AS number is also recommended to be the same for both tunnels.

Prerequisites

• The VPC CIDR block, IDC CIDR block, and BGP tunnel subnet must not conflict with each other.

• A VPC has been created, and a vSwitch has been created in each of two different zones (the zones where the vSwitches reside must be included in List of zones supported by the Transit Router). At least one ECS instance exists in the VPC for verifying connectivity.

• 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 synchronization are enabled between the VPC and the TR.

  • A CIDR block is configured for the TR.

• A Linux server has been deployed in the local IDC (this article uses CentOS Stream 9 as an example) with one public egress. strongSwan (for the IPsec tunnel) and FRRouting (for BGP) will be installed on this server as the local gateway.

1. Configure firewall rules

On the strongSwan device, allow ESP protocol (IP protocol number 50), UDP port 500, and UDP port 4500 to permit access 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

Because the dual-tunnel scenario needs to distinguish the traffic of each tunnel, you must create XFRM virtual interfaces to avoid kernel routing policy conflicts. In BGP dynamic routing mode, you also need to configure BGP tunnel addresses on the XFRM interfaces.

# Create XFRM tunnel interfaces (corresponding to tunnel 1 and tunnel 2 respectively; with a single public egress, the underlying interface for both is eth0)
sudo ip link add ipsec0 type xfrm dev eth0 if_id 42
sudo ip link add ipsec1 type xfrm dev eth0 if_id 43
sudo ip link set ipsec0 up
sudo ip link set ipsec1 up

# Configure the local BGP tunnel addresses on the XFRM interfaces
sudo ip address add 169.254.10.2/30 dev ipsec0
sudo ip address add 169.254.20.2/30 dev ipsec1

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
   # Applicable to: Alibaba Cloud Transit Router-bound IPsec connection + local single public egress + BGP dynamic routing
   #
   #
   # Use XFRM interfaces (if_id) to distinguish the traffic of the two tunnels; routes are learned dynamically by BGP.
   
   connections {
   
      # === Tunnel 1 ===
      tunnel1 {
         version = 2
         dpd_delay = 10s
         rekey_time = 86400s
         proposals = aes-sha1-modp1024
         encap = yes
   
         local_addrs  = 172.16.0.1               # IP address of the strongSwan local NIC (modify as needed: in a NAT environment, use the private IP; if the NIC directly binds a public IP, use the public IP)
         local {
            auth = psk
            id = XX.XX.3.3                         # Local public egress IP (modify as needed)
         }
   
         remote_addrs = XX.XX.1.1                  # Public IP of tunnel 1 on the Alibaba Cloud side (modify as needed)
         remote {
            auth = psk
            id = XX.XX.1.1                         # Public IP of tunnel 1 on the Alibaba Cloud side, same as remote_addrs above (modify as needed)
         }
   
         children {
            tunnel1-child {
               local_ts  = 0.0.0.0/0
               remote_ts = 0.0.0.0/0
               mode = tunnel
               esp_proposals = aes-sha1-modp1024
               dpd_action = restart
               start_action = start
               close_action = start
               if_id_in = 42                       # Corresponds to the ipsec0 interface
               if_id_out = 42
            }
         }
   
         if_id_in = 42
         if_id_out = 42
      }
   
      # === Tunnel 2 ===
      tunnel2 {
         version = 2
         dpd_delay = 10s
         rekey_time = 86400s
         proposals = aes-sha1-modp1024
         encap = yes
   
         local_addrs  = 172.16.0.1               # IP address of the strongSwan local NIC, same as tunnel 1 (modify as needed)
         local {
            auth = psk
            id = XX.XX.3.3                         # Local public egress IP, same as tunnel 1 (modify as needed)
         }
   
         remote_addrs = XX.XX.2.2                  # Public IP of tunnel 2 on the Alibaba Cloud side (modify as needed)
         remote {
            auth = psk
            id = XX.XX.2.2                         # Public IP of tunnel 2 on the Alibaba Cloud side, same as remote_addrs above (modify as needed)
         }
   
         children {
            tunnel2-child {
               local_ts  = 0.0.0.0/0
               remote_ts = 0.0.0.0/0
               mode = tunnel
               esp_proposals = aes-sha1-modp1024
               dpd_action = restart
               start_action = start
               close_action = start
               if_id_in = 43                       # Corresponds to the ipsec1 interface
               if_id_out = 43
            }
         }
   
         if_id_in = 43
         if_id_out = 43
      }
   }
   
   secrets {
      ike-tunnel1 {
      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.
      }
      ike-tunnel2 {
      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.
      }
   }

   Important

   • if_id_in and if_id_out bind each tunnel to the corresponding XFRM interface (ipsec0 / ipsec1), ensuring that the traffic of the two tunnels does not interfere with each other.

   • local_ts and remote_ts are set to 0.0.0.0/0; the routes learned by BGP determine which traffic enters the tunnel. In destination route mode, the traffic selector on the cloud side is also 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

7. Configure BGP dynamic routing (FRRouting)

After the IPsec tunnel is established, the networks still cannot communicate. You need to configure BGP on the local gateway device to establish BGP neighbors with the Alibaba Cloud side, automatically advertise local CIDR blocks, and learn cloud-side CIDR blocks.

Note: After the strongSwan/FRR device restarts, you must re-add the XFRM interfaces, BGP tunnel addresses, and BGP configuration.

1. Install FRRouting:

   sudo dnf install frr -y

2. Enable the bgpd daemon:

   Edit /etc/frr/daemons, change bgpd=no to bgpd=yes, save, and then start FRR:

   sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
   sudo systemctl enable frr
   sudo systemctl restart frr

3. Add the BGP configuration:

   Enter the vtysh configuration interface and add the following configuration. When executing, replace the addresses with your actual values:

   • 169.254.10.1 and 169.254.20.1: Replace with the local BGP addresses of the two tunnels on the Alibaba Cloud side (that is, the remote BGP neighbors of the local device).

   • 65535: Replace with the local autonomous system number of the Alibaba Cloud IPsec connection.

   • 65530: Replace with the BGP AS number of the local IDC.

   • 172.16.0.0/24: Replace with the local IDC CIDR block that you need to advertise to the cloud side.

   sudo vtysh

   configure terminal
   route-map allow-all permit 1
   exit
   
   router bgp 65530
    bgp router-id 169.254.10.2
    neighbor 169.254.10.1 remote-as 65535
    neighbor 169.254.10.1 timers 10 30
    neighbor 169.254.20.1 remote-as 65535
    neighbor 169.254.20.1 timers 10 30
   
    address-family ipv4 unicast
     network 172.16.0.0/24
     neighbor 169.254.10.1 soft-reconfiguration inbound
     neighbor 169.254.10.1 route-map allow-all in
     neighbor 169.254.10.1 route-map allow-all out
     neighbor 169.254.20.1 soft-reconfiguration inbound
     neighbor 169.254.20.1 route-map allow-all in
     neighbor 169.254.20.1 route-map allow-all out
     maximum-paths 32
    exit-address-family
   exit
   exit
   write memory

4. Confirm BGP neighbors and routes:

   show ip bgp summary
   show ip bgp

   • The State/PfxRcd of the two neighbors (169.254.10.1 and 169.254.20.1) in show ip bgp summary should show the number of received prefixes (rather than Active/Idle), indicating that the BGP neighbors have been established.

   • In show ip bgp, you should be able to see the cloud-side VPC CIDR blocks learned through BGP (such as 10.0.0.0/24 and 10.0.2.0/24), and each CIDR block has two equivalent paths (via tunnel 1 and tunnel 2 respectively), forming ECMP.

   # show ip bgp summary expected output example (some content omitted)
   Neighbor        V         AS   ... State/PfxRcd
   169.254.10.1    4      65535   ...            2
   169.254.20.1    4      65535   ...            2
   
   # show ip bgp expected output example
   *> 10.0.0.0/24      169.254.10.1   ... 65535 i
   *=                  169.254.20.1   ... 65535 i
   *> 10.0.2.0/24      169.254.10.1   ... 65535 i
   *=                  169.254.20.1   ... 65535 i

5. Confirm that the ECMP routes have been installed in the kernel:

   ip route show 10.0.0.0/24
   # Expected: one route with two nexthops, via ipsec0 and ipsec1 respectively

Test connectivity

1. First ensure the ECS security group rules have allowed the ICMP protocol, then ping the cloud-side ECS from a client in the local IDC:

   ping 10.0.0.1

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

   Note: When pinging from the strongSwan device itself, specify the IDC internal IP as the source address (for example, ping -I 172.16.0.1 10.0.0.1) to prevent the kernel from selecting the BGP tunnel address (169.254.x.x) as the source address, which would cause the return path to fail.

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

An IPsec connection bound to a Transit Router and using BGP uses both tunnels simultaneously in ECMP (Equal-Cost Multi-Path) mode by default, with traffic load-balanced between the two tunnels. When one tunnel fails, BGP automatically withdraws the route of that tunnel, and traffic converges to the other tunnel without manual switchover.

1. Keep the ECS continuously pinging the IDC server:

   ping 172.16.0.1 -c 10000

2. Interrupt one of the tunnels: In the Alibaba Cloud console, modify the pre-shared key of tunnel 1 of the IPsec connection (so that the keys at both ends are inconsistent). The tunnel will be interrupted, and its BGP neighbor will be disconnected accordingly.

3. Observe the ping result: After a brief interruption, communication resumes, indicating that traffic has automatically converged to tunnel 2.

4. Restore the tunnel: Change the pre-shared key of tunnel 1 back to the correct value. After the tunnel and BGP neighbor are restored, traffic will be load-balanced between the two tunnels again.