VPN Gateway:Configure strongSwan

Dual egress-BGP dynamic routing

For more information, see Connect a VPC to an on-premises data center in dual-tunnel mode and use BGP routing. Complete the Create a VPN gateway, Create customer gateways, Create an IPsec-VPN connection, and Enable BGP dynamic routing steps.

1. Because the strongSwan device has two public egress IP addresses, create two customer gateways.

2. When you create the IPsec-VPN connection, associate Tunnel 1 with public egress 1 and Tunnel 2 with public egress 2. This example uses Destination Routing Mode.

Dual egress-static routing

For more information, see Connect a VPC to an on-premises data center in dual-tunnel mode. Complete the Create a VPN gateway, Create a customer gateway, Create an IPsec connection, and Configure VPN Gateway routes steps.

1. Because the strongSwan device has two public egress IP addresses, create two customer gateways.

2. When you create the IPsec-VPN connection, associate Tunnel 1 with public egress 1 and Tunnel 2 with public egress 2. This example uses Destination Routing Mode.

Single egress-BGP dynamic routing

For more information, see Connect a VPC to an on-premises data center in dual-tunnel mode and use BGP routing. Complete the Create a VPN gateway, Create customer gateways, Create an IPsec-VPN connection, and Enable BGP dynamic routing steps.

1. The strongSwan device has one public egress IP address. Create one customer gateway.

2. When you create the IPsec-VPN connection, associate both tunnels with the same customer gateway. This example uses Destination Routing Mode.

Single egress-static routing

For more information, see Connect a VPC to an on-premises data center in dual-tunnel mode. Complete the Create a VPN gateway, Create a customer gateway, Create an IPsec connection, and Configure VPN Gateway routes steps. Note the following points:

1. The strongSwan device has one public egress IP address. Create one customer gateway.

2. When you create the IPsec-VPN connection, select Protected Data Flows mode and associate both tunnels with the same customer gateway. Configure the following parameters:

   • Set Local Network to the CIDR block of the VPC on the Alibaba Cloud side, which is 192.168.0.0/16.

   • Set Remote Network to the private CIDR block of the on-premises data center, which is 172.16.0.0/16.

If an IPsec-VPN connection is associated with a Transit Router, use BGP dynamic routing. Static routing is not recommended for this scenario.

Dual egress-static routing and BGP dynamic routing

1. Add routes so that traffic to IPsec address 1 goes through eth0 and traffic to IPsec address 2 goes through eth1.

   ip route add 47.XX.XX.151 via 172.16.20.253 dev eth0  # 172.16.20.253 is the private gateway address of eth0.
   ip route add 47.XX.XX.87 via 172.16.21.253 dev eth1   # 172.16.21.253 is the private gateway address of eth1.

   Verify connectivity to both IPsec addresses.

   ping 47.XX.XX.151 
   ping 47.XX.XX.87 

2. Create two virtual network interfaces to establish the IPsec-VPN tunnels.

   ip link add ipsec0 type xfrm dev eth0 if_id 42 # Create an XFRM virtual network interface for Tunnel 1. The interface ID is 42 and the underlying interface is the public interface eth0.
   ip link add ipsec1 type xfrm dev eth1 if_id 43 # Create an XFRM virtual network interface for Tunnel 2. The interface ID is 43 and the underlying interface is the public interface eth1.
   ip link set ipsec0 up # Start the XFRM virtual network interface for Tunnel 1.
   ip link set ipsec1 up # Start the XFRM virtual network interface for Tunnel 2.

   Important

   XFRM interfaces do not persist across reboots. You must configure the following startup script so that the interfaces are automatically re-created and strongSwan is reloaded on every boot.

   Click to view the startup script.

   1. Create a script file.

      vi xfrm.sh

   2. Add the following content and save the file.

      sudo ip link add ipsec0 type xfrm dev eth0 if_id 42 # Create an XFRM virtual network interface for Tunnel 1. The interface ID is 42 and the underlying interface is the public interface eth0.
      sudo ip link add ipsec1 type xfrm dev eth1 if_id 43 # Create an XFRM virtual network interface for Tunnel 2. The interface ID is 43 and the underlying interface is the public interface eth1.
      sudo ip link set ipsec0 up # Start the XFRM virtual network interface for Tunnel 1.
      sudo ip link set ipsec1 up # Start the XFRM virtual network interface for Tunnel 2.

   3. Find the absolute path of the script.

      sudo find / -name xfrm.sh

   4. Add the script path to /etc/rc.d/rc.local so it runs on startup. Replace /path/to/xfrm.sh with the actual path returned by the previous find command.

      echo '/path/to/xfrm.sh' | sudo tee -a /etc/rc.d/rc.local

   5. Grant executable permissions to the rc.local file and the xfrm.sh script.

      sudo chmod +x /etc/rc.d/rc.local
      sudo chmod +x /path/to/xfrm.sh

3. Modify the strongSwan configuration file.

   1. Back up the original strongSwan configuration file.

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

   2. Create a new strongSwan configuration file.

      vi /etc/strongswan/swanctl/swanctl.conf

   3. Add the following configuration. Each parameter value must match the corresponding Alibaba Cloud tunnel configuration.

      Important

      For static routing, uncomment the updown = /root/connect_1.sh and updown = /root/connect_2.sh lines in the configuration.

      connections {
         vco1 {                            # Add the VPN configuration for IPsec-VPN Tunnel 1.
            version = 2                    # Specify the IKE version. It must be the same as the IKE version of Tunnel 1 on the Alibaba Cloud side. 2 indicates IKEv2.
            local_addrs  = 172.16.20.80       # The IP address of the first on-premises network interface card.
            remote_addrs = 47.XX.XX.151       # Specify the peer IP address of Tunnel 1 as the gateway IP address of Tunnel 1 on the Alibaba Cloud side, which is IPsec address 1.
            dpd_delay = 10
            rekey_time = 84600             # Specify the SA lifetime for Tunnel 1. It must be the same as the SA lifetime in the IKE configurations of Tunnel 1 on the Alibaba Cloud side.
            over_time = 1800               
            proposals = aes128-sha1-modp1024  # Specify the encryption algorithm, authentication algorithm, and DH group for Tunnel 1. They must be the same as those in the IKE configurations of Tunnel 1 on the Alibaba Cloud side. group2 corresponds to modp1024.
            encap = yes
      
            local {
               auth = psk                  # Set the authentication method for the on-premises side to PSK, which is the pre-shared key method.
               id = 120.XX.XX.202             # The first on-premises public egress IP address. It must be the same as the RemoteId of Tunnel 1 on the Alibaba Cloud side.
            }
            remote {
               auth = psk                  # Set the authentication method for the peer to PSK. This means Alibaba Cloud uses the pre-shared key method.
               id = 47.XX.XX.151             # IPsec address 1 on the Alibaba Cloud side. It must be the same as the LocalId of Tunnel 1 on the Alibaba Cloud side.
            }
            children {
               vco_child1 {
                  local_ts  = 0.0.0.0/0    # The policy-based traffic selector for the destination-based routing mode on Alibaba Cloud is 0.0.0.0/0.
                  remote_ts = 0.0.0.0/0    # The policy-based traffic selector for the destination-based routing mode on Alibaba Cloud is 0.0.0.0/0.
                  mode = tunnel
                  rekey_time = 85500
                  life_time = 86400        # Specify the SA lifetime for Tunnel 1. It must be the same as the SA lifetime in the IPsec configurations of Tunnel 1 on the Alibaba Cloud side.
                  dpd_action = restart
                  start_action = start
                  close_action = start
                  esp_proposals = aes128-sha1-modp1024   # Specify the encryption algorithm, authentication algorithm, and DH group for Tunnel 1. They must be the same as those in the IPsec configurations of Tunnel 1 on the Alibaba Cloud side. group2 corresponds to modp1024.
      
                  if_id_out = 42           # Specify the egress and ingress interfaces for Tunnel 1 as the XFRM virtual network interface of Tunnel 1.
                  if_id_in = 42
                  #updown = /root/connect_1.sh         # Execute the /root/connect_1.sh script to configure routes based on the UP and DOWN status of Tunnel 1. This parameter is required only when you use static routing.
               }
            }
         }
        vco2 {                             # Add the VPN configuration for IPsec-VPN Tunnel 2.
            version = 2                    # Specify the IKE version. It must be the same as the IKE version of Tunnel 2 on the Alibaba Cloud side. 2 indicates IKEv2.
            local_addrs  = 172.16.21.248        # The IP address of the second on-premises network interface card.
            remote_addrs = 47.XX.XX.87       # IPsec address 2 on the Alibaba Cloud side.
            dpd_delay = 10
            rekey_time = 84600             # SA lifetime. Must match Tunnel 2 IKE configurations.
            over_time = 1800
            proposals = aes128-sha1-modp1024  # group2 = modp1024. Must match Tunnel 2 IKE configurations.
            encap = yes
      
            local {
               auth = psk                  # Pre-shared key authentication.
               id = 47.XX.XX.127              # Second on-premises public egress IP. Must match RemoteId of Tunnel 2.
            }
            remote {
               auth = psk                  # Set the authentication method for the peer to PSK. This means Alibaba Cloud uses the pre-shared key method.
               id = 47.XX.XX.87             # IPsec address 2 on the Alibaba Cloud side. It must be the same as the LocalId of Tunnel 2 on the Alibaba Cloud side.
            }
            children {
               vco_child2 {
                  local_ts  = 0.0.0.0/0    # The policy-based traffic selector for the destination-based routing mode on Alibaba Cloud is 0.0.0.0/0.
                  remote_ts = 0.0.0.0/0    # The policy-based traffic selector for the destination-based routing mode on Alibaba Cloud is 0.0.0.0/0.
                  mode = tunnel 
                  rekey_time = 85500
                  life_time = 86400        # Specify the SA lifetime for Tunnel 2. It must be the same as the SA lifetime in the IPsec configurations of Tunnel 2 on the Alibaba Cloud side.
                  dpd_action = restart
                  start_action = start
                  close_action = start
                  esp_proposals = aes128-sha1-modp1024     # Specify the encryption algorithm, authentication algorithm, and DH group for Tunnel 2. They must be the same as those in the IPsec configurations of Tunnel 2 on the Alibaba Cloud side. group2 corresponds to modp1024.
                  if_id_out = 43           # Specify the egress and ingress interfaces for Tunnel 2 as the XFRM virtual network interface of Tunnel 2.
                  if_id_in = 43
                  #updown = /root/connect_2.sh           # Execute the /root/connect_2.sh script to configure routes based on the UP and DOWN status of Tunnel 2. This parameter is required only when you use static routing.
               }
            }
         }
      }
      
      secrets {
         ike-vco1 {
            id = 47.XX.XX.151               # The public IP address of Tunnel 1 of the VPN gateway on the Alibaba Cloud side.
            secret = ChangeMe***            # Specify the pre-shared key for Tunnel 1. The key must be the same as the pre-shared key of Tunnel 1 on the Alibaba Cloud side.
         }
         ike-vco2 {
            id = 47.XX.XX.87                # The public IP address of Tunnel 2 of the VPN gateway on the Alibaba Cloud side.
            secret = ChangeMe***            # Specify the pre-shared key for Tunnel 2. The key must be the same as the pre-shared key of Tunnel 2 on the Alibaba Cloud side.
         }
      }

4. Restart the strongSwan process, reload the strongSwan configuration, and check the tunnel status.

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

   The following output confirms that the IPsec-VPN connection is established. However, network connectivity requires route configuration in the next step.

   

5. Configure routes.

   Refer to the section for the routing method that you plan to use.

   BGP dynamic routing

   The BGP IP addresses assigned to XFRM interfaces (ip address add) do not persist across reboots. Add these commands to the XFRM startup script described earlier. The FRR BGP configuration persists automatically after you run write memory in vtysh (see the last step below).

   1. Configure the BGP IP addresses on the XFRM interfaces.

      ip address add 169.254.10.2/30 dev ipsec0
      ip address add 169.254.20.2/30 dev ipsec1

   2. Install FRR (Free Range Routing) for BGP support.

      yum install -y frr

   3. Edit vi /etc/frr/daemons and set the bgpd parameter to yes to enable BGP.

      Edit the file, make the change, and save.

   4. Enable and start FRR.

      systemctl enable frr
      systemctl restart frr

   5. Add the BGP configuration. Replace the IP addresses and AS numbers with your actual values.

      1. Enter the FRR configuration interface.

         vtysh

      2. Enter configuration mode.

         config terminal

      3. Add the BGP configuration with the following commands.

         Replace the following values with your actual addresses:

         • Replace "169.254.10.1" and "169.254.20.1" with the actual BGP IP addresses of the tunnels on the Alibaba Cloud side.

         • Replace "65535" with the actual BGP AS number of the VPN Gateway.

         • Replace "172.16.20.0/24" and "172.16.21.0/24" with the actual CIDR blocks of your on-premises data center.

         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.20.0/24                  
           network 172.16.21.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
         

   6. Run exit to leave configuration mode, then run show ip bgp to view the BGP routes.

      The output confirms that the strongSwan device has learned VPC routes. The on-premises data center and VPC can now communicate.

   7. Save the BGP configuration so that it persists across FRR restarts.

      write memory

   Static routing

   Create two scripts that strongSwan calls to configure routes and control traffic flow.

   1. Create and edit the /root/connect_1.sh script.

      vi /root/connect_1.sh

   2. Add and save the following content.

      #!/usr/bin/env bash
      if [ x"$PLUTO_VERB" == "xup-client" ]; then
      	echo "ip route add 192.168.0.0/16 dev ipsec0" >> /root/vpn_route.log;ip route add 192.168.0.0/16 dev ipsec0 metric 100
      elif [ x"$PLUTO_VERB" == "xdown-client" ]; then
      	echo "ip route del 192.168.0.0/16 dev ipsec0" >> /root/vpn_route.log;ip route del 192.168.0.0/16 dev ipsec0 metric 100
      fi

      This script adds a route for traffic from the on-premises data center to the Alibaba Cloud VPC (192.168.0.0/16) through the XFRM virtual network interface of Tunnel 1 when the tunnel is up. The metric value of this route is set to 100, which gives it a higher priority than the route for Tunnel 2. If Tunnel 1 is down, the script revokes the route.

   3. Create and edit the /root/connect_2.sh script.

      vi /root/connect_2.sh

   4. Add and save the following content.

      #!/usr/bin/env bash
      if [ x"$PLUTO_VERB" == "xup-client" ]; then
      	echo "ip route add 192.168.0.0/16 dev ipsec1" >> /root/vpn_route.log;ip route add 192.168.0.0/16 dev ipsec1 metric 101
      elif [ x"$PLUTO_VERB" == "xdown-client" ]; then
      	echo "ip route del 192.168.0.0/16 dev ipsec1" >> /root/vpn_route.log;ip route del 192.168.0.0/16 dev ipsec1 metric 101
      fi

      This script adds a route for traffic from the on-premises data center to the Alibaba Cloud VPC (192.168.0.0/16) through the XFRM virtual network interface of Tunnel 2 when the tunnel is up. The metric value of this route is set to 101, which gives it a lower priority than the route for Tunnel 1. If Tunnel 2 is down, the script revokes the route.

   5. Grant executable permissions to the two scripts.

      sudo chmod +x /root/connect_1.sh
      sudo chmod +x /root/connect_2.sh

   6. Restart the strongSwan process.

      sudo systemctl restart strongswan

   7. Verify the routes.

      route -n

      

Single egress-BGP dynamic routing

1. Create two virtual network interfaces to establish the IPsec-VPN tunnels.

   ip link add ipsec0 type xfrm dev eth0 if_id 42 # Create an XFRM virtual network interface for Tunnel 1. The interface ID is 42 and the underlying interface is the public interface eth0.
   ip link add ipsec1 type xfrm dev eth0 if_id 43 # Create an XFRM virtual network interface for Tunnel 2. The interface ID is 43 and the underlying interface is the public interface eth0.
   ip link set ipsec0 up # Start the XFRM virtual network interface for Tunnel 1.
   ip link set ipsec1 up # Start the XFRM virtual network interface for Tunnel 2.

   Important

   XFRM interfaces do not persist across reboots. You must configure the following startup script so that the interfaces are automatically re-created and strongSwan is reloaded on every boot.

   Click to view the startup script.

   1. Create a script file.

      vi xfrm.sh

   2. Add and save the following configuration.

      sudo ip link add ipsec0 type xfrm dev eth0 if_id 42 # Create an XFRM virtual network interface for Tunnel 1. The interface ID is 42 and the underlying interface is the public interface eth0.
      sudo ip link add ipsec1 type xfrm dev eth0 if_id 43 # Create an XFRM virtual network interface for Tunnel 2. The interface ID is 43 and the underlying interface is the public interface eth0.
      sudo ip link set ipsec0 up # Start the XFRM virtual network interface for Tunnel 1.
      sudo ip link set ipsec1 up # Start the XFRM virtual network interface for Tunnel 2.

   3. Find the absolute path of the script.

      sudo find / -name xfrm.sh

   4. Add the script path to /etc/rc.d/rc.local so it runs on startup. Replace /path/to/xfrm.sh with the actual path returned by the previous find command.

      echo '/path/to/xfrm.sh' | sudo tee -a /etc/rc.d/rc.local

   5. Grant executable permissions to the rc.local file and the xfrm.sh script.

      sudo chmod +x /etc/rc.d/rc.local
      sudo chmod +x /path/to/xfrm.sh

2. Modify the strongSwan configuration file.

   1. Back up the original strongSwan configuration file.

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

   2. Create a new strongSwan configuration file.

      vi /etc/strongswan/swanctl/swanctl.conf

   3. The following configuration is similar to the dual-egress example. Only the differences are annotated. Add and save the following configuration.

      connections {
         vco1 {
            version = 2
            local_addrs  = 172.16.20.80    # Both tunnels use the same eth0 interface (single egress).
            remote_addrs = 47.XX.XX.151
            dpd_delay = 10
            rekey_time = 84600
            over_time = 1800
            proposals = aes128-sha1-modp1024
            encap = yes
      
            local {
               auth = psk
               id = 120.XX.XX.202
            }
            remote {
               auth = psk
               id = 47.XX.XX.151
            }
            children {
               vco_child1 {
                  local_ts  = 0.0.0.0/0
                  remote_ts = 0.0.0.0/0
                  mode = tunnel
                  rekey_time = 85500
                  life_time = 86400
                  dpd_action = restart
                  start_action = start
                  close_action = start
                  esp_proposals = aes128-sha1-modp1024
      
                  if_id_out = 42
                  if_id_in = 42
               }
            }
         }
        vco2 {
            version = 2
            local_addrs  = 172.16.20.80    # Same as vco1 (single egress).
            remote_addrs = 47.XX.XX.87
            dpd_delay = 10
            rekey_time = 84600
            over_time = 1800
            proposals = aes128-sha1-modp1024
            encap = yes
      
            local {
               auth = psk
               id = 120.XX.XX.202          # Same public egress IP as vco1 (single egress).
            }
            remote {
               auth = psk
               id = 47.XX.XX.87
            }
            children {
               vco_child2 {
                  local_ts  = 0.0.0.0/0
                  remote_ts = 0.0.0.0/0
                  mode = tunnel
                  rekey_time = 85500
                  life_time = 86400
                  dpd_action = restart
                  start_action = start
                  close_action = start
                  esp_proposals = aes128-sha1-modp1024
                  if_id_out = 43
                  if_id_in = 43
               }
            }
         }
      }
      
      secrets {
         ike-vco1 {
            id = 47.XX.XX.151
            secret = ChangeMe***
         }
         ike-vco2 {
            id = 47.XX.XX.87
            secret = ChangeMe***
         }
      }

3. Restart the strongSwan process, reload the strongSwan configuration, and check the tunnel status.

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

   The following output confirms that the IPsec-VPN connection is established. Configure routes in the next step to enable network connectivity.

   

4. Configure BGP dynamic routing.

   The BGP IP addresses assigned to XFRM interfaces (ip address add) do not persist across reboots. Add these commands to the XFRM startup script described earlier. The FRR BGP configuration persists automatically after you run write memory in vtysh (see the last step below).

   1. Configure the BGP IP addresses on the XFRM interfaces.

      ip address add 169.254.10.2/30 dev ipsec0
      ip address add 169.254.20.2/30 dev ipsec1

   2. Install FRR (Free Range Routing) for BGP support.

      yum install -y frr

   3. Edit vi /etc/frr/daemons and set the bgpd parameter to yes to enable BGP.

      Edit the file, make the change, and save.

   4. Enable and start FRR.

      systemctl enable frr
      systemctl restart frr

   5. Add the BGP configuration. Replace the IP addresses and AS numbers with your actual values.

      1. Enter the FRR configuration interface.

         vtysh

      2. Enter configuration mode.

         config terminal

      3. Add the BGP configuration with the following commands.

         Replace the following values with your actual addresses:

         • Replace "169.254.10.1" and "169.254.20.1" with the actual BGP IP addresses of the tunnels on the Alibaba Cloud side.

         • Replace "65535" with the actual BGP AS number of the VPN Gateway.

         • Replace "172.16.20.0/24" and "172.16.21.0/24" with the actual CIDR blocks of your on-premises data center.

         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.20.0/24                  
           network 172.16.21.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
         

   6. Run exit to leave configuration mode, then run show ip bgp to view the BGP routes.

      The output confirms that the strongSwan device has learned VPC routes. The on-premises data center and VPC can now communicate.

   7. Save the BGP configuration so that it persists across FRR restarts.

      write memory

Single egress-static routing

1. Back up the original strongSwan configuration file.

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

2. Create a new strongSwan configuration file.

   vi /etc/strongswan/swanctl/swanctl.conf

3. The following configuration is similar to the dual-egress example. Key differences: policy-based traffic selectors (local_ts/remote_ts) and priority for active/standby failover. Add and save the following configuration.

   connections {
      vco1 {
         version = 2
         local_addrs  = 172.16.20.80
         remote_addrs = 47.XX.XX.151
         dpd_delay = 10
         rekey_time = 84600
         over_time = 1800
         proposals = aes128-sha1-modp1024
         encap = yes
   
         local {
            auth = psk
            id = 120.XX.XX.202
         }
         remote {
            auth = psk
            id = 47.XX.XX.151
         }
         children {
            vco_child1 {
               local_ts  = 172.16.0.0/16   # Policy-based: on-premises private CIDR block.
               remote_ts = 192.168.0.0/16  # Policy-based: VPC 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                # Active tunnel (higher priority).
            }
         }
      }
     vco2 {
         version = 2
         local_addrs  = 172.16.20.80
         remote_addrs = 47.XX.XX.87
         dpd_delay = 10
         rekey_time = 84600
         over_time = 1800
         proposals = aes128-sha1-modp1024
         encap = yes
   
         local {
            auth = psk
            id = 120.XX.XX.202
         }
         remote {
            auth = psk
            id = 47.XX.XX.87
         }
         children {
            vco_child2 {
               local_ts  = 172.16.0.0/16   # Policy-based: on-premises private CIDR block.
               remote_ts = 192.168.0.0/16  # Policy-based: VPC 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 = 2                # Standby tunnel (lower priority).
            }
         }
      }
   }
   
   secrets {
      ike-vco1 {
         id = 47.XX.XX.151
         secret = ChangeMe***
      }
      ike-vco2 {
         id = 47.XX.XX.87
         secret = ChangeMe***
      }
   }

4. Restart the strongSwan process, reload the strongSwan configuration, and check the tunnel status.

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

   The following output confirms that the IPsec-VPN connection is established. The on-premises data center and VPC can now communicate.