Contact UsGet started
© 2024 Iron Hive LLC Belgrade

Setting up network connectivity with IPsec gateways on your own using Yandex Cloud

Written by
Updated at October 15, 2024

You can set up a secure connection between the cloud infrastructure and a corporate data center on your own by using IPsec gateways as described in the relevant subsection chart. To do this:

  1. Prepare your cloud.
  2. Set up a cloud site.
  3. Set up a remote site.
  4. Test an IPsec connection and connectivity between remote and cloud resources.

If you no longer need the resources you created, delete them.

Prepare your cloud

Sign up for Yandex Cloud and create a billing account:

  1. Go to the management console and log in to Yandex Cloud or create an account if you do not have one yet.
  2. On the Yandex Cloud Billing page, make sure you have a billing account linked and it has the ACTIVE or TRIAL_ACTIVE status. If you do not have a billing account, create one.

If you have an active billing account, you can go to the cloud page to create or select a folder for your infrastructure to operate in.

Learn more about clouds and folders.

The infrastructure deployment cost for this solution based on IPsec gateways includes:

Create an SSH key pair

To connect to a VM over SSH, you need a key pair: the public key resides on the VM, and the private one is kept by the user. This method is more secure than connecting with login and password.

Note

SSH connections using a login and password are disabled by default on public Linux images that are provided by Yandex Cloud.

To create a key pair:

  1. Open the terminal.

  2. Use the ssh-keygen command to create a new key:

    ssh-keygen -t ed25519 -C "<optional_comment>"

    You can specify an empty string in the -C parameter to avoid adding a comment, or you may not specify the -C parameter at all: in this case, a default comment will be added.

    After running this command, you will be prompted to specify the name and path to the key files, as well as enter the password for the private key. If you only specify the name, the key pair will be created in the current directory. The public key will be saved in a file with the .pub extension, while the private key, in a file without extension.

    By default, the command prompts you to save the key under the id_ed25519 name in the following directory: /home/<username>/.ssh. If there is already an SSH key named id_ed25519 in this directory, you may accidentally overwrite it and lose access to the resources it is used in. Therefore, you may want to use unique names for all SSH keys.

If you do not have OpenSSH installed yet, follow this guide to install it.

  1. Run cmd.exe or powershell.exe (make sure to update PowerShell before doing so).

  2. Use the ssh-keygen command to create a new key:

    ssh-keygen -t ed25519 -C "<optional_comment>"

    You can specify an empty string in the -C parameter to avoid adding a comment, or you may not specify the -C parameter at all: in this case, a default comment will be added.

    After running this command, you will be prompted to specify the name and path to the key files, as well as enter the password for the private key. If you only specify the name, the key pair will be created in the current directory. The public key will be saved in a file with the .pub extension, while the private key, in a file without extension.

    By default, the command prompts you to save the key under the id_ed25519 name in the following directory: C:\Users\<username>/.ssh. If there is already an SSH key named id_ed25519 in this directory, you may accidentally overwrite it and lose access to the resources it is used in. Therefore, you may want to use unique names for all SSH keys.

Create keys using the PuTTY app:

  1. Download and install PuTTY.

  2. Make sure the directory where you installed PuTTY is included in PATH:

    1. Right-click My computer. Click Properties.
    2. In the window that opens, select Additional system parameters, then Environment variables (located in the lower part of the window).
    3. Under System variables, find PATH and click Edit.
    4. In the Variable value field, append the path to the directory where you installed PuTTY.

  3. Launch the PuTTYgen app.

  4. Select EdDSA as the pair type to generate. Click Generate and move the cursor in the field above it until key creation is complete.

    ssh_generate_key

  5. In Key passphrase, enter a strong password. Enter it again in the field below.

  6. Click Save private key and save the private key. Do not share its key phrase with anyone.

  7. Click Save public key and save the public key in the following file: <key_name>.pub.

Set up a cloud site

At this stage, you will reserve two static IP addresses for IPsec gateways as well as create and set up an infrastructure for your cloud site in Yandex Cloud: an IPsec gateway, two virtual machines, and a network with two subnets.

Create and set up a cloud network

Reserve public IP addresses for gateways

Reserve two static public IP addresses in the ru-central1-b availability zone:

  • Further on, we will refer to the cloud-gw main IPsec gateway address as <x1.x1.x1.x1>.
  • Further on, we will refer to the remote-gw remote IPsec gateway address as <x2.x2.x2.x2>.

Create a network and subnets on the cloud site

  1. Create a network named cloud-net. When creating your network, disable the Create subnets option.

  2. In the cloud-net network, manually create subnets with the following parameters:

    1. To connect the cloud-gw main IPsec gateway:

      • Name: ipsec-subnet
      • Zone: ru-central1-b
      • CIDR: 172.16.0.0/24

    2. To connect the vm-a VM:

      • Name: subnet-a
      • Zone: ru-central1-a
      • CIDR: 172.16.1.0/24

    3. To connect the vm-b VM:

      • Name: subnet-b
      • Zone: ru-central1-b
      • CIDR: 172.16.2.0/24

Create and set up a security group for the main IPsec gateway

  1. In the cloud-net network, create a security group named cloud-net-sg.

  2. In the cloud-net-sg security group, create rules based on the table below:

    Traffic
    direction    		 Description Port range Protocol Source /
    Destination name    		 CIDR blocks
    Outgoing any All Any CIDR 0.0.0.0/0
    Incoming icmp All ICMP CIDR 0.0.0.0/0
    Incoming ssh 22 TCP CIDR 0.0.0.0/0
    Incoming ipsec-udp-500 500 UDP CIDR <x2.x2.x2.x2>/32
    Incoming ipsec-udp-4500 4500 UDP CIDR <x2.x2.x2.x2>/32
    Incoming subnet-a All Any CIDR 172.16.1.0/24
    Incoming subnet-b All Any CIDR 172.16.2.0/24

Set up static routing for the main IPsec gateway

  1. In the management console, go to the folder where you created the cloud-net network.

  2. Select Virtual Private Cloud.

  3. Select cloud-net.

  4. Go to the Routing tables tab and click Create.

  5. In the Name field, specify cloud-net-rt.

  6. Under Static routes, click Add a route.

    1. In the window that opens, set 10.10.0.0/16 in the Destination prefix field.
    2. In the IP address field, enter the internal IP address of the main IPSec gateway: 172.16.0.10.
    3. Click Add.

  7. Click Create a routing table.

  8. Link the cloud-net-rt route table to subnet-a and subnet-b:

    1. Go to the Overview tab.
    2. In the subnet-a line, click and select Link routing table.
    3. In the window that opens, select the cloud-net-rt route table and click Link.
    4. Repeat the previous two steps for subnet-b to link the cloud-net-rt route table to it.

Create and configure VMs on the cloud site

Create a VM with the main IPsec gateway on the cloud site

  1. In the management console, go to the folder where you need to create the main IPsec gateway.

  2. At the top right, click Create resource and select Virtual machine instance.

  3. In the Name field, specify cloud-gw.

  4. In the Availability zone field, select ru-central1-b hosting the subnet to connect the main IPsec gateway to.

  5. Under Boot disk image, go to the Marketplace tab, click Show all Marketplace products, and select the IPSec instance image.

  6. Under Network settings:

    1. In the Subnet field, select ipsec-subnet.

    2. In the Public IP field, select List.

    3. In the IP address field that opens, select the <x1.x1.x1.x1> public IP address you previously reserved.

      To ensure the IP address does not change after a restart, convert it to static.

    4. In the Internal IPv4 address field, select Manual and set 172.16.0.10 in the field that opens.

    5. In the Security groups field, select the previously created cloud-net-sg security group.

  7. Under Access:

    • In the Login field, specify ipsec.
    • In the SSH key field, enter the contents of the previously created public SSH key to access the VM.

  8. Click Create VM.

Wait for the VM status to change to Running.

Set up the main IPsec gateway

To set up the gateway, use the IP addresses, username, and SSH key that you specified when creating the cloud-gw VM.

  1. Connect to the VM over SSH:

    ssh ipsec@<x1.x1.x1.x1>

  2. Set the date and time parameters for the VM:

    sudo timedatectl set-timezone Europe/Moscow
sudo timedatectl set-ntp True
timedatectl

  3. To ensure optimal ICMP performance, disable the ICMP Redirects feature on the IPsec gateway:

    sudo su -c "echo 'net.ipv4.conf.eth0.send_redirects=0' >> /etc/sysctl.conf"
sudo su -c "echo 'net.ipv4.conf.default.send_redirects=0' >> /etc/sysctl.conf"

    For more information, see the strongSwan documentation.

  4. Create a backup of the swanctl.conf file:

    sudo mv /etc/swanctl/swanctl.conf /etc/swanctl/swanctl.orig

  5. Create a configuration for the main IPsec gateway in the /etc/swanctl/swanctl.conf file:

    sudo nano /etc/swanctl/swanctl.conf

    In the file that opens, specify:

    connections {
  cloud-ipsec {
    local_addrs = 172.16.0.10
    remote_addrs = <x2.x2.x2.x2>
    local {
      auth = psk
    }
    remote {
      auth = psk
    }
    version = 2 # IKEv2
    mobike = no
    proposals = aes128gcm16-prfsha256-ecp256, default
    dpd_delay = 10s
    children {
      cloud-ipsec {
        # List of local IPv4 subnets
        local_ts = 172.16.1.0/24, 172.16.2.0/24

        # List of remote IPv4 subnets
        remote_ts = 10.10.0.0/16

        start_action = trap
        esp_proposals = aes128gcm16
        dpd_action = clear
      }
    }
  }
}

# Pre-shared key (PSK) for IPsec connection
secrets {
  ike-cloud-ipsec {
    secret = <ipsec_password>
  }
}

    Where:

    • cloud-ipsec: IPsec connection name.
    • remote_addrs: Public IP address of the remote IPsec gateway (<x2.x2.x2.x2>).
    • proposals: Internet Key Exchange Version 2 (IKEv2). A list of ciphers that can be used for encrypting the IPsec connection control channel.
    • esp_proposals: Encapsulating Security Payload. A list of ciphers that can be used for encrypting the transmitted data.
    • secret: Pre-Shared Key. The <ipsec_password> key (password) to use to establish an IPsec connection.

    Note

    You can set additional parameters in the swanctl.conf file based on the strongSwan documentation.

    For example, to transfer data via an IPsec connection faster, use optimized encryption algorithms in IKEv2 mode. These algorithms should be supported on the remote IPsec gateway platform if it is different from strongSwan.

  6. Upload the configuration to strongSwan:

    sudo swanctl --load-all

  7. Restart strongSwan:

    sudo systemctl restart strongswan

  8. Check the strongSwan status:

    sudo swanctl -L

  9. (Optional) View the strongSwan logs:

    sudo journalctl -u strongswan --no-pager
sudo journalctl -u strongswan -n 20
sudo journalctl -u strongswan -f

  10. Terminate the cloud-gw connection:

    exit

Deploy test VMs on the cloud site

  1. Create a test VM named vm-a with the following parameters:

    • Name: vm-a
    • Availability zone: ru-central1-a
    • Operating system: Ubuntu 22.04 LTS
    • Subnet: subnet-a
    • Public IP: No address
    • Internal IPv4 address: 172.16.1.5
    • Login: ipsec
    • SSH key: Public SSH key for VM access

  2. Create a test VM named vm-b with the following parameters:

    • Name: vm-b
    • Availability zone: ru-central1-b
    • Operating system: Ubuntu 22.04 LTS
    • Subnet: subnet-b
    • Public IP: No address
    • Internal IPv4 address: 172.16.2.5
    • Login: ipsec
    • SSH key: Public SSH key for VM access

Set up a remote site

At this stage, you will create and set up an infrastructure for a remote site of a typical corporate data center. It will include an IPsec gateway, a VM, a network, and a subnet.

Create and set up a remote network

Create a network and subnet on the remote site

  1. Create a network named remote-net. When creating your network, disable the Create subnets option.

  2. In the remote-net network, manually create a subnet to connect the remote-gw remote IPsec gateway and a VM named vm-1 with the following parameters:

    • Name: subnet-1
    • Zone: ru-central1-b
    • CIDR: 10.10.0.0/16

Create and set up a security group for the remote IPsec gateway

  1. In the remote-net network, create a security group named remote-net-sg.

  2. In the remote-net-sg security group, create rules based on the table below:

    Traffic
    direction    		 Description Port range Protocol Source /
    Destination name    		 CIDR blocks
    Outgoing any All Any CIDR 0.0.0.0/0
    Incoming icmp All ICMP CIDR 0.0.0.0/0
    Incoming ssh 22 TCP CIDR 0.0.0.0/0
    Incoming ipsec-udp-500 500 UDP CIDR <x1.x1.x1.x1>/32
    Incoming ipsec-udp-4500 4500 UDP CIDR <x1.x1.x1.x1>/32
    Incoming subnet-1 All Any CIDR 10.10.0.0/16

Set up static routing for the remote IPsec gateway

  1. In the management console, go to the folder where you created the remote-net network.

  2. Select Virtual Private Cloud.

  3. Select remote-net.

  4. Go to the Routing tables tab and click Create.

  5. In the Name field, specify remote-net-rt.

  6. Under Static routes, click Add a route.

    1. In the window that opens, set 172.16.1.0/24 in the Destination prefix field.
    2. In the IP address field, enter the internal IP address of the main IPSec gateway: 10.10.20.20.
    3. Click Add.

  7. Repeat the previous step to add a second rule with the following parameters:

    • Destination prefix: 172.16.2.0/24
    • IP address: 10.10.20.20

  8. Click Create a routing table.

  9. Link the remote-net-rt route table to subnet-1:

    1. Go to the Overview tab.
    2. In the subnet-1 line, click and select Link routing table.
    3. In the window that opens, select the remote-net-rt table and click Link.

Create and configure VMs on the remote site

Create a VM with a remote IPsec gateway

Create a VM to act as a remote IPsec gateway.

  1. In the management console, go to the folder where you need to create a remote IPsec gateway.

  2. At the top right, click Create resource and select Virtual machine instance.

  3. In the Name field, specify remote-gw.

  4. In the Availability zone field, select the ru-central1-b zone hosting the subnet to connect the remote IPsec gateway to.

  5. Under Boot disk image, go to the Marketplace tab, click Show all Marketplace products, and select the IPSec instance image.

  6. Under Network settings:

    1. In the Subnet field, select subnet-1.

    2. In the Public IP field, select List.

    3. In the IP address field that opens, select the <x2.x2.x2.x2> public IP address that you previously reserved.

      To ensure the IP address does not change after a restart, convert it to static.

    4. In the Internal IPv4 address field, select Manual and set 10.10.20.20 in the field that opens.

    5. In the Security groups field, select the previously created remote-net-sg security group.

  7. Under Access:

    • In the Login field, specify ipsec.
    • In the SSH key field, enter the previously created public SSH key to access the VM.

  8. Click Create VM.

Wait for the VM status to change to Running.

Set up the remote IPsec gateway

To set up the gateway, use the IP addresses, username, and SSH key that you specified when creating the remote-gw VM.

  1. Connect to the VM over SSH:

    ssh ipsec@<x2.x2.x2.x2>

  2. Set the date and time parameters for the VM:

    sudo timedatectl set-timezone Europe/Moscow
sudo timedatectl set-ntp True
timedatectl

  3. To ensure optimal ICMP performance, disable the ICMP Redirects feature on the IPsec gateway:

      sudo su -c "echo 'net.ipv4.conf.eth0.send_redirects=0' >> /etc/sysctl.conf"
  sudo su -c "echo 'net.ipv4.conf.default.send_redirects=0' >> /etc/sysctl.conf"

    For more information, see the strongSwan documentation.

  4. Create a backup of the swanctl.conf file:

    sudo mv /etc/swanctl/swanctl.conf /etc/swanctl/swanctl.orig

  5. Create a configuration for the remote IPsec gateway in the /etc/swanctl/swanctl.conf file:

    sudo nano /etc/swanctl/swanctl.conf

    In the file that opens, specify:

    connections {
  cloud-ipsec {
    local_addrs = 10.10.20.20
    remote_addrs = <x1.x1.x1.x1>
    local {
      auth = psk
    }
    remote {
      auth = psk
    }
    version = 2 # IKEv2
    mobike = no
    proposals = aes128gcm16-prfsha256-ecp256, default
    dpd_delay = 10s
    children {
      cloud-ipsec {
        # List of local IPv4 subnets
        local_ts = 10.10.0.0/16

        # List of remote IPv4 subnets
        remote_ts = 172.16.1.0/24, 172.16.2.0/24

        start_action = trap
        esp_proposals = aes128gcm16
        dpd_action = clear
      }
    }
  }
}

# Pre-shared key (PSK) for IPsec connection
secrets {
  ike-cloud-ipsec {
    secret = <ipsec_password>
  }
}

    Where:

    • cloud-ipsec: IPsec connection name.
    • remote_addrs: Public IP address of the main IPsec gateway (<x1.x1.x1.x1> ).
    • proposals: Internet Key Exchange Version 2 (IKEv2). A list of ciphers that can be used for encrypting the IPsec connection control channel.
    • esp_proposals: Encapsulating Security Payload. A list of ciphers that can be used for encrypting the transmitted data.
    • secret: Pre-Shared Key. The <ipsec_password> key (password) to use to establish an IPsec connection.

    Note

    You can set additional parameters in the swanctl.conf file based on the strongSwan documentation.

    For example, to transfer data via an IPsec connection faster, use optimized encryption algorithms in IKEv2 mode. These algorithms should be supported on the remote IPsec gateway platform if it is different from strongSwan.

  6. Upload the configuration to strongSwan:

    sudo swanctl --load-all

  7. Restart strongSwan:

    sudo systemctl restart strongswan

  8. Check the strongSwan status:

    sudo swanctl -L

  9. (Optional) View the strongSwan logs:

    sudo journalctl -u strongswan --no-pager
sudo journalctl -u strongswan -n 20
sudo journalctl -u strongswan -f

  10. Terminate the remote-gw connection:

    exit

Deploy a test VM on the remote site

Create a test VM with the following parameters:

  • Name: vm-1
  • Availability zone: ru-central1-b
  • Operating system: Ubuntu 22.04 LTS
  • Subnet: subnet-1
  • Public IP: No address
  • Internal IPv4 address: 10.10.10.10
  • Login: ipsec
  • SSH key: Public SSH key for VM access

Test an IPsec connection and connectivity between remote and cloud resources

Establish an IPsec connection between the gateways and test it

The IPsec gateways on the main and remote sites are set up to establish an IPsec connection between each other when one of them receives traffic aimed for the subnet on the other side of the IPsec connection (behind the other gateway).

Note

Creating a tunnel between the gateways may take some time. If, when activating an IPsec connection, the ping command does not return the result you are looking for, try again in a few minutes.

To activate an IPsec connection between the gateways:

  1. Send a number of ICMP packets on the side of the remote site, e.g., from vm-1 to vm-a, using the ping command:

    ssh -J ipsec@<x2.x2.x2.x2> ipsec@10.10.10.10 ping -c4 172.16.1.5

    Result:

    PING 172.16.1.5 (172.16.1.5) 56(84) bytes of data.
64 bytes from 172.16.1.5: icmp_seq=1 ttl=58 time=4.92 ms
64 bytes from 172.16.1.5: icmp_seq=2 ttl=58 time=4.33 ms
64 bytes from 172.16.1.5: icmp_seq=3 ttl=58 time=4.31 ms
64 bytes from 172.16.1.5: icmp_seq=4 ttl=58 time=4.38 ms

--- 172.16.1.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.306/4.483/4.916/0.251 ms

  2. Activate an IPsec connection on the side of the cloud site by sending ICMP packets from vm-b to vm-1:

    ssh -J ipsec@<x1.x1.x1.x1> ipsec@172.16.2.5 ping -c4 10.10.10.10

    Result:

    PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
64 bytes from 10.10.10.10: icmp_seq=1 ttl=58 time=4.92 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=58 time=4.33 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=58 time=4.31 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=58 time=4.38 ms

--- 10.10.10.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.306/4.483/4.916/0.251 ms

Test connectivity between the VMs

  1. Connect to the cloud-gw main IPsec gateway:

    ssh ipsec@<x1.x1.x1.x1>

    1. Check the strongSwan status:

      sudo swanctl -L

      Result:

      cloud-to-remote-site: IKEv1/2, reauthentication every 3060s, no rekeying, dpd delay 30s
  local:  %any
  remote: <x2.x2.x2.x2>
  local pre-shared key authentication:
    id: <x1.x1.x1.x1>
  remote pre-shared key authentication:
    id: <x2.x2.x2.x2>
  cloud-to-remote-site: TUNNEL, rekeying every 28260s, dpd action is restart
    local:  172.16.1.0/24
    remote: 10.10.0.0/16
cloud-ipsec: IKEv2, no reauthentication, rekeying every 14400s, dpd delay 10s
  local:  172.16.0.10
  remote: <x2.x2.x2.x2>
  local pre-shared key authentication:
  remote pre-shared key authentication:
  cloud-ipsec: TUNNEL, rekeying every 3600s, dpd action is clear
    local:  172.16.1.0/24 172.16.2.0/24
    remote: 10.10.0.0/16

    2. Check active IPsec connections:

      sudo swanctl -l

      Result:

      cloud-ipsec: #6, ESTABLISHED, IKEv2, 80e6fa659b4f6307_i* 9f63a85191df1e48_r
  local  '172.16.0.10' @ 172.16.0.10[4500]
  remote '10.10.20.20' @ <x2.x2.x2.x2>[4500]
  AES_GCM_16-128/PRF_HMAC_SHA2_256/ECP_256
  established 9716s ago, rekeying in 4107s
  cloud-ipsec: #19, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_GCM_16-128
    installed 682s ago, rekeying in 2735s, expires in 3278s
    in  cf9668bb,      0 bytes,     0 packets
    out c3a00b2c,      0 bytes,     0 packets
    local  172.16.1.0/24 172.16.2.0/24
    remote 10.10.0.0/16

      If the connection status is ESTABLISHED, the IPsec connection is established and active.

    3. Terminate the cloud-gw connection:

      exit

  2. Connect to the remote-gw remote IPsec gateway:

    ssh ipsec@<x2.x2.x2.x2>

    1. Check the strongSwan status:

      sudo swanctl -L

      Result:

      remote-site-to-cloud: IKEv1/2, reauthentication every 3060s, no rekeying, dpd delay 30s
  local:  %any
  remote: <x1.x1.x1.x1>
  local pre-shared key authentication:
    id: <x2.x2.x2.x2>
  remote pre-shared key authentication:
    id: <x1.x1.x1.x1>
  remote-site-to-cloud: TUNNEL, rekeying every 28260s, dpd action is restart
    local:  10.10.0.0/16
    remote: 172.16.1.0/24
cloud-ipsec: IKEv2, no reauthentication, rekeying every 14400s, dpd delay 10s
  local:  10.10.20.20
  remote: <x1.x1.x1.x1>
  local pre-shared key authentication:
  remote pre-shared key authentication:
  cloud-ipsec: TUNNEL, rekeying every 3600s, dpd action is clear
    local:  10.10.0.0/16
    remote: 172.16.1.0/24 172.16.2.0/24

    2. Check active IPsec connections:

      sudo swanctl -l

      Result:

      cloud-ipsec: #6, ESTABLISHED, IKEv2, 80e6fa659b4f6307_i 9f63a85191df1e48_r*
  local  '10.10.20.20' @ 10.10.20.20[4500]
  remote '172.16.0.10' @ <x1.x1.x1.x1>[4500]
  AES_GCM_16-128/PRF_HMAC_SHA2_256/ECP_256
  established 9833s ago, rekeying in 3346s
  cloud-ipsec: #19, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_GCM_16-128
    installed 799s ago, rekeying in 2620s, expires in 3161s
    in  c3a00b2c,      0 bytes,     0 packets
    out cf9668bb,      0 bytes,     0 packets
    local  10.10.0.0/16
    remote 172.16.1.0/24 172.16.2.0/24

      If the connection status is ESTABLISHED, the IPsec connection is established and active.

    3. Terminate the remote-gw connection:

      exit

  3. Connect to vm-a:

    ssh -J ipsec@<x1.x1.x1.x1> ipsec@172.16.1.5

    1. Set the date and time parameters for the VM:

      sudo timedatectl set-timezone Europe/Moscow
sudo timedatectl set-ntp True
timedatectl

    2. Test IP connectivity between vm-a and vm-1:

      ping -c4 10.10.10.10

      Result:

      PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
64 bytes from 10.10.10.10: icmp_seq=1 ttl=58 time=4.92 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=58 time=4.33 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=58 time=4.31 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=58 time=4.38 ms

--- 10.10.10.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.306/4.483/4.916/0.251 ms

    3. Terminate the vm-a connection:

      exit

  4. Connect to vm-b:

    ssh -J ipsec@<x1.x1.x1.x1> ipsec@172.16.2.5

    1. Set the date and time parameters for the VM:

      sudo timedatectl set-timezone Europe/Moscow
sudo timedatectl set-ntp True
timedatectl

    2. Test IP connectivity between vm-b and vm-1:

      ping -c4 10.10.10.10

      Result:

      PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
64 bytes from 10.10.10.10: icmp_seq=1 ttl=58 time=4.92 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=58 time=4.33 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=58 time=4.31 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=58 time=4.38 ms

--- 10.10.10.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.306/4.483/4.916/0.251 ms

    3. Terminate the vm-b connection:

      exit

  5. Connect to vm-1:

    ssh -J ipsec@<x2.x2.x2.x2> ipsec@10.10.10.10

    1. Set the date and time parameters for the VM:

      sudo timedatectl set-timezone Europe/Moscow
sudo timedatectl set-ntp True
timedatectl

    2. Test IP connectivity between vm-1 and vm-a:

      ping -c4 172.16.1.5

      Result:

      PING 172.16.1.5 (172.16.1.5) 56(84) bytes of data.
64 bytes from 172.16.1.5: icmp_seq=1 ttl=58 time=4.92 ms
64 bytes from 172.16.1.5: icmp_seq=2 ttl=58 time=4.33 ms
64 bytes from 172.16.1.5: icmp_seq=3 ttl=58 time=4.31 ms
64 bytes from 172.16.1.5: icmp_seq=4 ttl=58 time=4.38 ms

--- 172.16.1.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.306/4.483/4.916/0.251 ms

    3. Test IP connectivity between vm-1 and vm-b:

      ping -c4 172.16.2.5

      Result:

      PING 172.16.2.5 (172.16.2.5) 56(84) bytes of data.
64 bytes from 172.16.2.5: icmp_seq=1 ttl=58 time=4.92 ms
64 bytes from 172.16.2.5: icmp_seq=2 ttl=58 time=4.33 ms
64 bytes from 172.16.2.5: icmp_seq=3 ttl=58 time=4.31 ms
64 bytes from 172.16.2.5: icmp_seq=4 ttl=58 time=4.38 ms

--- 172.16.2.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.306/4.483/4.916/0.251 ms

    4. Terminate the vm-1 connection:

      exit

How to delete the resources you created

To stop paying for the resources you created:

Previous
Solution diagram
Next
SGW solution by the Yandex Cloud architect team