Contact UsGet started

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

Written by
Improved by
Updated at May 7, 2025

You can set up a secure connection between the cloud infrastructure and a corporate data center yourself using IPsec gateways according to the following chart:

  1. Get your cloud ready.
  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.

Get your cloud ready

Sign up in Yandex Cloud and create a billing account:

  1. Navigate to the management console and log in to Yandex Cloud or register a new account.
  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 and link a cloud to it.

If you have an active billing account, you can navigate 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 IPsec gateways-based solution includes:

Create an SSH keypair

To connect to a VM over SSH, you need a keypair with the public key located on the VM, and the private key kept by the user. This method is more secure than password authentication.

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 keypair:

  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 folder: 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. Add the folder with PuTTY to the PATH variable:

    1. Click Start and type Change system environment variables in the Windows search bar.
    2. Click Environment Variables... at the bottom right.
    3. In the window that opens, find the PATH parameter and click Edit.
    4. Add your folder path to the list.
    5. Click OK.

  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 to a file named <key_name>.pub.

Set up a cloud site

In this step, you will reserve two static IP addresses for IPsec gateways and set up your Yandex Cloud infrastructure, including IPsec gateways, two VMs, and a network with two subnets.

Set up a cloud network

Reserve public IP addresses for gateways

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

  • cloud-gw: Main IPsec gateway address, further referred to as <x1.x1.x1.x1>.
  • remote-gw: Remote IPsec gateway address, further referred to as <x2.x2.x2.x2>.

Create your cloud network with subnets

  1. Create the cloud-net network with the Create subnets option disabled.

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

    1. The cloud-gw main IPsec gateway subnet:

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

    2. The vm-d VM subnet:

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

    3. The vm-b VM subnet:

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

Set up the main IPsec gateway security group

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

  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
    Outbound any All Any CIDR 0.0.0.0/0
    Inbound icmp All ICMP CIDR 0.0.0.0/0
    Inbound ssh 22 TCP CIDR 0.0.0.0/0
    Inbound ipsec-udp-500 500 UDP CIDR <x2.x2.x2.x2>/32
    Inbound ipsec-udp-4500 4500 UDP CIDR <x2.x2.x2.x2>/32
    Inbound subnet-d All Any CIDR 172.16.1.0/24
    Inbound subnet-b All Any CIDR 172.16.2.0/24

Set up static routing for the main IPsec gateway

  1. In the management console, navigate to the cloud-net network folder.

  2. Select Virtual Private Cloud.

  3. Select the cloud-net network.

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

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

  6. Under Static routes, click Add.

    1. In the window that opens, specify 10.10.0.0/16 in the Destination prefix field.
    2. In the IP address field, specify the gateway private IP address: 172.16.0.10.
    3. Click Add.

  7. Click Create routing table.

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

    1. Navigate to the Overview tab.
    2. In the subnet-d row, 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.

Create and configure your cloud VMs

Create the main IPsec gateway VM

  1. On the folder page in the management console, click Create resource and select Virtual machine instance.

  2. Under Boot disk image, in the Product search field, type IPsec instance and select a public IPsec instance image.

  3. Under Location, select the ru-central1-b availability zone where the main IPsec gateway will reside.

  4. Under Network settings:

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

    2. In the Public IP address field, select List.

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

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

    5. Expand the Additional section:

      • In the Internal IPv4 address field, select Manual.
      • In the input field that appears, specify 172.16.0.10.

  5. Under Access, select SSH key and specify the VM access data:

    • In the Login field, specify ipsec.

    • In the SSH key field:

      • Click Add key.
      • Specify the SSH key name.
      • Upload the previously created public SSH key or paste its contents into the appropriate field.
      • Click Add.

      This will add the SSH key to your organization user profile.

      If, due to restrictions, you cannot add SSH keys to your profile, the system will save the key to the VM user profile.

  6. Under General information, specify the VM name: cloud-gw.

  7. Click Create VM.

Wait until the VM status changes to Running.

Set up the main IPsec gateway

To set up the gateway, use the IP addresses, username, and SSH key of the cloud-gw VM.

  1. Connect to the VM over SSH:

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

  2. Change the VM date and time settings:

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

  3. To optimize ICMP performance, disable ICMP Redirects:

      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 how-tos.

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

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

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

    sudo nano /etc/swanctl/swanctl.conf

    In the file that opens, add the following code:

    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: Remote IPsec gateway public IP address (<x2.x2.x2.x2>).
    • proposals: Internet Key Exchange Version 2 (IKEv2). A list of ciphers the system can use to encrypt the IPsec connection control channel.
    • esp_proposals: Encapsulating Security Payload. A list of ciphers the system can use to encrypt the transmitted data.
    • secret: Pre-shared key. The <ipsec_password> the system will use for IPsec handshake.

    Note

    You can add more options in swanctl.conf based on these strongSwan guides.

    For example, for faster data transfers, you can use optimized encryption algorithms in IKEv2 mode. However, if you use a different software from strongSwan on the remote IPsec gateway, first make sure it supports these algorithms.

  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. Optionally, check the strongSwan logs:

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

  10. Close the cloud-gw connection:

    exit

Create your test cloud VMs

  1. Create the vm-d VM with the following settings:

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

  2. Create the vm-b VM with the following settings:

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

Set up a remote site

In this step, you will set up a remote data center infrastructure,. including an IPsec gateway, a VM, a network, and a subnet.

Set up a remote network

Create a network with a subnet

  1. Create the remote-net network with the Create subnets option disabled.

  2. In the remote-net network, create a subnet for the remote-gw IPsec gateway and vm-1 VM with the following settings:

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

Create the remote IPsec gateway security group

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

  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
    Outbound any All Any CIDR 0.0.0.0/0
    Inbound icmp All ICMP CIDR 0.0.0.0/0
    Inbound ssh 22 TCP CIDR 0.0.0.0/0
    Inbound ipsec-udp-500 500 UDP CIDR <x1.x1.x1.x1>/32
    Inbound ipsec-udp-4500 4500 UDP CIDR <x1.x1.x1.x1>/32
    Inbound subnet-1 All Any CIDR 10.10.0.0/16

Set up remote IPsec gateway static routing

  1. In the management console, navigate to the remote-net network folder.

  2. Select Virtual Private Cloud.

  3. Select the remote-net network.

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

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

  6. Under Static routes, click Add.

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

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

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

  8. Click Create routing table.

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

    1. Navigate to the Overview tab.
    2. In the subnet-1 row, 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 remote IPsec gateway VM

Create a VM you will use as a remote IPsec gateway.

  1. On the folder page in the management console, click Create resource and select Virtual machine instance.

  2. Under Boot disk image, in the Product search field, type IPsec instance and select a public IPsec instance image.

  3. Under Location, select the ru-central1-b availability zone where the remote IPsec gateway will reside.

  4. Under Network settings:

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

    2. In the Public IP address field, select List.

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

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

    5. Expand the Additional section:

      • In the Internal IPv4 address field, select Manual.
      • In the input field that appears, specify 10.10.20.20.

  5. Under Access, select SSH key and specify the VM access data:

    • In the Login field, specify ipsec.

    • In the SSH key field, select the SSH key that you saved in your organization user profile when creating the main IPsec gateway VM.

      If there are no saved SSH keys in your profile, or you want to add a new key:

      • Click Add key.
      • Specify the SSH key name.
      • Upload the previously created public SSH key or paste its contents into the appropriate field.
      • Click Add.

      This will add the SSH key to your organization user profile.

      If, due to restrictions, you cannot add SSH keys to your profile, the system will save the key to the VM user profile.

  6. Under General information, specify the VM name: remote-gw. The name should meet the following requirements:

    • It must be from 2 to 63 characters long.
    • It may contain lowercase Latin letters, numbers, and hyphens.
    • It must start with a letter and cannot end with a hyphen.

  7. Click Create VM.

Wait until the VM status changes to Running.

Set up the remote IPsec gateway

To set up the gateway, use the IP addresses, username, and SSH key of the remote-gw VM.

  1. Connect to the VM over SSH:

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

  2. Change the VM date and time settings:

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

  3. To optimize ICMP performance, disable ICMP Redirects:

      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 how-tos.

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

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

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

    sudo nano /etc/swanctl/swanctl.conf

    In the file that opens, add the following code:

    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: Main IPsec gateway public IP address (<x1.x1.x1.x1>).
    • proposals: Internet Key Exchange Version 2 (IKEv2). A list of ciphers the system can use to encrypt the IPsec connection control channel.
    • esp_proposals: Encapsulating Security Payload. A list of ciphers the system can use to encrypt the transmitted data.
    • secret: Pre-shared key. The <ipsec_password> the system will use for IPsec handshake.

    Note

    You can add more options in swanctl.conf based on these strongSwan guides.

    For example, for faster data transfers, you can use optimized encryption algorithms in IKEv2 mode. However, if you use a different software from strongSwan on the remote IPsec gateway, first make sure it supports these algorithms.

  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. Optionally, check 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

Set up a test VM on the remote site

Create a test VM with the following settings:

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

Test an IPsec connection and connectivity between remote and cloud resources

Establish an IPsec connection between the gateways and make sure it works correctly

The main and remote gateways will establish an IPsec connection when one of them receives traffic directed to the other’s subnet.

Note

After you activated an IPsec connection, it may take a while for the gateways to establish a tunnel. If you test the connection with ping and it fails, try again in a few minutes.

To activate an IPsec connection between the gateways:

  1. Send ping ICMP packets from vm-1 on the remote site to vm-d:

    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 cloud side 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 active.

    3. Close 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 active.

    3. Terminate the remote-gw connection:

      exit

  3. Connect to vm-d:

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

    1. Change the VM date and time settings:

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

    2. Test IP connectivity between vm-d 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-d connection:

      exit

  4. Connect to vm-b:

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

    1. Change the VM date and time settings:

      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. Change the VM date and time settings:

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

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

      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 architecture
Next
SGW solution by the Yandex Cloud architect team