[Yandex Cloud documentation](../../../index.md) > [Yandex Virtual Private Cloud](../../index.md) > [Tutorials](../index.md) > Setting up VPN connections > [Establishing network connectivity with the help of IPsec gateways](index.md) > Unaided implementation with Yandex Cloud

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


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](index.md) chart. For this, follow these steps:

1. [Get your cloud ready](#before-you-begin).
1. [Set up a cloud site](#cloud-setup).
1. [Set up a remote site](#remote-setup).
1. [Test an IPsec connection and connectivity between remote and cloud resources](#ipsec-test).

If you no longer need the resources you created, [delete them](#clear-out).

## Get your cloud ready {#before-you-begin}

Sign up for Yandex Cloud and create a [billing account](../../../billing/concepts/billing-account.md):
1. Navigate to the [management console](https://console.yandex.cloud) and log in to Yandex Cloud or create a new account.
1. On the **[Yandex Cloud Billing](https://center.yandex.cloud/billing/accounts)** page, make sure you have a billing account linked and it has the `ACTIVE` or `TRIAL_ACTIVE` [status](../../../billing/concepts/billing-account-statuses.md). If you do not have a billing account, [create one](../../../billing/quickstart/index.md) and [link](../../../billing/operations/pin-cloud.md) a cloud to it.

If you have an active billing account, you can create or select a [folder](../../../resource-manager/concepts/resources-hierarchy.md#folder) for your infrastructure on the [cloud page](https://console.yandex.cloud/cloud).

[Learn more about clouds and folders here](../../../resource-manager/concepts/resources-hierarchy.md).

### Required paid resources {#paid-resources}

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

* Fee for continuously running VMs (see [Yandex Compute Cloud pricing](../../../compute/pricing.md)).
* Fee for a static external IP address (see [Yandex Virtual Private Cloud pricing](../../pricing.md)).

### Create an SSH keypair {#create-ssh-keys}

To connect to a [VM](../../../compute/concepts/vm.md) over SSH, you will 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 login and password authentication.

{% note info %}

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

{% endnote %}

To create a key pair:

{% list tabs group=operating_system %}

- Linux/macOS {#linux-macos}

  1. Open the terminal.
  1. Use the `ssh-keygen` command to create a new key:
  
      ```bash
      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.

- Windows 10/11 {#windows}

  If you do not have [OpenSSH](https://en.wikipedia.org/wiki/OpenSSH) installed yet, follow this [guide](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse?tabs=gui) to install it.
  
  1. Run `cmd.exe` or `powershell.exe` (make sure to update PowerShell before doing so).
  1. Use the `ssh-keygen` command to create a new key:
  
      ```shell
      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.

- Windows 7/8 {#windows7-8}

  Create keys using the PuTTY app:
  
  1. [Download](https://www.putty.org) and install PuTTY.
  1. Add the folder with PuTTY to the `PATH` variable:
  
      1. Click **Start** and type **Change system environment variables** in the Windows search bar.
      1. Click **Environment Variables...** at the bottom right.
      1. In the window that opens, find the `PATH` parameter and click **Edit**.
      1. Add your folder path to the list.
      1. Click **OK**.
  
  1. Launch the PuTTYgen app.
  1. 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](../../../_assets/compute/ssh-putty/ssh_generate_key.png)
  
  1. In **Key passphrase**, enter a strong password. Enter it again in the field below.
  1. Click **Save private key** and save the private key. Do not share its key phrase with anyone.
  1. Click **Save public key** and save the public key to a file named `<key_name>.pub`.

{% endlist %}

## Set up your cloud site {#cloud-setup}

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

### Set up a cloud network {#setup-cloud-net}

#### Reserve public IP addresses for gateways {#reserve-public-ip}

[Reserve](../../operations/get-static-ip.md) two static [public IP addresses](../../concepts/address.md#public-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 {#cloud-net}

1. [Create a network](../../operations/network-create.md) named `cloud-net` with the **Create subnets** option disabled.
1. In the `cloud-net` network, manually [create subnets](../../operations/subnet-create.md) with the following parameters:

    1. The `cloud-gw` main IPsec gateway subnet:
        * **Name**: `ipsec-subnet`
        * **Availability zone**: `ru-central1-b`
        * **CIDR**: `172.16.0.0/24`

    1. The `vm-d` VM subnet:
        * **Name**: `subnet-d`
        * **Availability zone**: `ru-central1-d`
        * **CIDR**: `172.16.1.0/24`

    1. The `vm-b` VM subnet:
        * **Name**: `subnet-b`
        * **Availability zone**: `ru-central1-b`
        * **CIDR**: `172.16.2.0/24`

#### Set up the main IPsec gateway security group {#cloud-sg}

1. In `cloud-net`, create the `cloud-net-sg` [security group](../../operations/security-group-create.md).
1. In the `cloud-net-sg` security group, [create rules](../../operations/security-group-add-rule.md) based on the table below:

    | Traffic<br/>direction | Description | Port range | Protocol | Source /<br/>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 {#cloud-static}

1. In the [management console](https://console.yandex.cloud), navigate to the `cloud-net` network folder.
1. Navigate to **Virtual Private Cloud**.
1. Select `cloud-net`.
1. Navigate to the **Routing tables** tab and click **Create**.
1. In the **Name** field, specify `cloud-net-rt`.
1. Under **Static routes**, click **Add**.

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

1. Click **Create routing table**.
1. Link the `cloud-net-rt` route table to `subnet-d` and `subnet-b`:

    1. Navigate to the **Overview** tab.
    1. In the `subnet-d` row, click ![image](../../../_assets/console-icons/ellipsis.svg) and select **Link routing table**.
    1. In the window that opens, select the `cloud-net-rt` route table and click **Link**.
    1. Repeat the previous two steps for `subnet-b`.

### Create and configure your cloud VMs {#setup-cloud-vms}

#### Create the main IPsec gateway VM {#create-cloud-gw}

1. In the [management console](https://console.yandex.cloud), navigate to the [folder](../../../resource-manager/concepts/resources-hierarchy.md#folder) dashboard, click **Create resource**, and select `Virtual machine instance`.
1. Under **Boot disk image**, in the **Product search** field, type `IPsec instance` and select a public [IPsec instance](https://yandex.cloud/en/marketplace/products/yc/ipsec-instance-ubuntu) image.
1. Under **Location**, select the `ru-central1-b` [availability zone](../../../overview/concepts/geo-scope.md) where the main IPsec gateway will reside.
1. Under **Network settings**:

    1. In the **Subnet** field, select `ipsec-subnet`.
    1. In the **Public IP address** field, select `List`.
    1. In the **IP address** field that appears, select the previously [reserved](#reserve-public-ip) `<x1.x1.x1.x1>` public IP address.
    1. In the **Security groups** field, select the [previously created](#cloud-sg) `cloud-net-sg` security group.
    1. Expand the **Additional** section:

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

1. 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](#create-ssh-keys) public SSH key or paste its contents into the appropriate field.
        * Click **Add**.

        The system will add the SSH key to your organization user profile. If the organization has [disabled](../../../organization/operations/os-login-access.md) the ability for users to add SSH keys to their profiles, the added public SSH key will only be saved in the user profile inside the newly created resource.

1. Under **General information**, specify the VM name: `cloud-gw`.
1. Click **Create VM**.

Wait until the VM status changes to `Running`.

#### Set up the main IPsec gateway {#config-cloud-gw}

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:

    ```bash
    ssh ipsec@<x1.x1.x1.x1>
    ```

1. Change the VM date and time settings:

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

1. To optimize ICMP performance, disable `ICMP Redirects`:

    ```bash
	  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](https://docs.strongswan.org/docs/5.9/howtos/forwarding.html#_hosts_on_the_lan).

1. Create a backup copy of the `swanctl.conf` file:

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

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

    ```bash
    sudo nano /etc/swanctl/swanctl.conf
    ```

    In the file that opens, add the following code:

    ```bash
    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)](https://docs.strongswan.org/docs/5.9/howtos/ipsecProtocol.html#_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](https://docs.strongswan.org/docs/5.9/howtos/ipsecProtocol.html#_encapsulating_security_payload_esp). A list of ciphers the system can use to encrypt the transmitted data.
    * `secret`: [Pre-shared key](https://docs.strongswan.org/docs/5.9/howtos/ipsecProtocol.html#_psk_based_authentication). The `<ipsec_password>` the system will use for IPsec handshake.

    {% note info %}

    You can add more options in `swanctl.conf` based on these [strongSwan guides](https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html).

    For example, for faster data transfers, you can use [optimized encryption algorithms](https://docs.strongswan.org/docs/5.9/config/IKEv2CipherSuites.html#_authenticated_encryption_aead_algorithms) in [IKEv2](https://docs.strongswan.org/docs/5.9/features/ietf.html#_ikev2) mode. However, if you use a different software from strongSwan on the remote IPsec gateway, first make sure it supports these algorithms.

    {% endnote %}

1. Upload the configuration to strongSwan:

    ```bash
    sudo swanctl --load-all
    ```

1. Restart strongSwan:

    ```bash
    sudo systemctl restart strongswan
    ```

1. Check the strongSwan status:

    ```bash
    sudo swanctl -L
    ```

1. Optionally, check the strongSwan logs:

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

1. Terminate the `cloud-gw` connection:

    ```bash
    exit
    ```


#### Create your test cloud VMs {#cloud-test-vm}

1. [Create](../../../compute/operations/vm-create/create-linux-vm.md) the `vm-d` VM with the following settings:

    * **Operating system**: [Ubuntu 22.04 LTS](https://yandex.cloud/en/marketplace/products/yc/ipsec-instance-ubuntu)
    * **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`

1. [Create](../../../compute/operations/vm-create/create-linux-vm.md) 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 your remote site {#remote-setup}

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.

### Set up a remote network {#setup-remote-net}

#### Create a network with a subnet {#remote-net}

1. [Create a network](../../operations/network-create.md) named `remote-net`. with the **Create subnets** option disabled.
1. In the `remote-net` network, manually [create a subnet](../../operations/subnet-create.md) to connect the `remote-gw` remote IPsec gateway and a VM named `vm-1` with the following parameters:

    * **Name**: `subnet-1`
    * **Availability zone**: `ru-central1-b`
    * **CIDR**: `10.10.0.0/16`

#### Create the remote IPsec gateway security group {#remote-sg}

1. In the `remote-net` network, create the `remote-net-sg` [security group](../../operations/security-group-create.md).
1. In the `remote-net-sg` security group, [create rules](../../operations/security-group-add-rule.md) based on the table below:

    | Traffic<br/>direction | Description | Port range | Protocol | Source /<br/>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 {#remote-static}

1. In the [management console](https://console.yandex.cloud), navigate to the `remote-net` network folder.
1. Navigate to **Virtual Private Cloud**.
1. Select `remote-net`.
1. Navigate to the **Routing tables** tab and click **Create**.
1. In the **Name** field, specify `remote-net-rt`.
1. Under **Static routes**, click **Add**.

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

1. 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`

1. Click **Create routing table**.
1. Link the `remote-net-rt` route table to `subnet-1`:

    1. Navigate to the **Overview** tab.
    1. In the `subnet-1` row, click ![image](../../../_assets/console-icons/ellipsis.svg) and select **Link routing table**.
    1. In the window that opens, select the `remote-net-rt` table and click **Link**.

### Create and configure VMs on the remote site {#setup-remote-vms}

#### Create a remote IPsec gateway VM {#create-remote-gw}

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

1. In the [management console](https://console.yandex.cloud), navigate to the [folder](../../../resource-manager/concepts/resources-hierarchy.md#folder) dashboard, click **Create resource**, and select `Virtual machine instance`.
1. Under **Boot disk image**, in the **Product search** field, type `IPsec instance` and select a public [IPsec instance](https://yandex.cloud/en/marketplace/products/yc/ipsec-instance-ubuntu) image.
1. Under **Location**, select the `ru-central1-b` [availability zone](../../../overview/concepts/geo-scope.md) where the remote IPsec gateway will reside.
1. Under **Network settings**:

    1. In the **Subnet** field, select `subnet-1`.
    1. In the **Public IP address** field, select `List`.
    1. In the **IP address** field that appears, select the [previously reserved](#reserve-public-ip) `<x2.x2.x2.x2>` public IP address.
    1. In the **Security groups** field, select the [previously created](#cloud-sg) `remote-net-sg` security group.
    1. Expand the **Additional** section:

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

1. 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](../../../organization/concepts/membership.md) profile when [creating](#create-cloud-gw) 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](#create-ssh-keys) public SSH key or paste its contents into the appropriate field.
        * Click **Add**.

        The system will add the SSH key to your organization user profile. If the organization has [disabled](../../../organization/operations/os-login-access.md) the ability for users to add SSH keys to their profiles, the added public SSH key will only be saved in the user profile inside the newly created resource.

1. Under **General information**, specify the VM name: `remote-gw`. Follow these naming requirements:

    * Length: between 3 and 63 characters.
    * It can only contain lowercase Latin letters, numbers, and hyphens.
    * It must start with a letter and cannot end with a hyphen.

1. Click **Create VM**.

Wait until the VM status changes to `Running`.

#### Set up the remote IPsec gateway {#config-remote-gw}

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:

    ```bash
    ssh ipsec@<x2.x2.x2.x2>
    ```

1. Change the VM date and time settings:

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

1. To optimize ICMP performance, disable `ICMP Redirects`:

    ```bash
	  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](https://docs.strongswan.org/docs/5.9/howtos/forwarding.html#_hosts_on_the_lan).

1. Create a backup copy of the `swanctl.conf` file:

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

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

    ```bash
    sudo nano /etc/swanctl/swanctl.conf
    ```

    In the file that opens, add the following code:

    ```bash
    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)](https://docs.strongswan.org/docs/5.9/howtos/ipsecProtocol.html#_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](https://docs.strongswan.org/docs/5.9/howtos/ipsecProtocol.html#_encapsulating_security_payload_esp). A list of ciphers the system can use to encrypt the transmitted data.
    * `secret`: [Pre-shared key](https://docs.strongswan.org/docs/5.9/howtos/ipsecProtocol.html#_psk_based_authentication). The `<ipsec_password>` the system will use for IPsec handshake.

    {% note info %}

    You can add more options in `swanctl.conf` based on these [strongSwan guides](https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html).

    For example, for faster data transfers, you can use [optimized encryption algorithms](https://docs.strongswan.org/docs/5.9/config/IKEv2CipherSuites.html#_authenticated_encryption_aead_algorithms) in [IKEv2](https://docs.strongswan.org/docs/5.9/features/ietf.html#_ikev2) mode. However, if you use a different software from strongSwan on the remote IPsec gateway, first make sure it supports these algorithms.

    {% endnote %}

1. Upload the configuration to strongSwan:

    ```bash
    sudo swanctl --load-all
    ```

1. Restart strongSwan:

    ```bash
    sudo systemctl restart strongswan
    ```

1. Check the strongSwan status:

    ```bash
    sudo swanctl -L
    ```

1. Optionally, check the strongSwan logs:

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

1. Terminate the `remote-gw` connection:

    ```bash
    exit
    ```


#### Set up a test VM on the remote site {#remote-test-vm}

[Create a test VM](../../../compute/operations/vm-create/create-linux-vm.md) 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 {#ipsec-test}

### Establish an IPsec connection between the gateways and make sure it works correctly {#ipsec-bringup}

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

{% note info %}

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.

{% endnote %}

To activate an IPsec connection between the gateways:

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

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

    Result:

    ```bash
    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
    ```

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

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

    Result:

    ```bash
    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 {#ipsec-test-vm}

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

    ```bash
    ssh ipsec@<x1.x1.x1.x1>
    ```

    1. Check the strongSwan status:

        ```bash
        sudo swanctl -L
        ```

        Result:

        ```bash
        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
        ```

    1. Check active IPsec connections:

        ```bash
        sudo swanctl -l
        ```

        Result:

        ```bash
        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.

    1. Terminate the `cloud-gw` connection:

        ```bash
        exit
        ```

1. Connect to the `remote-gw` remote IPsec gateway:

    ```bash
    ssh ipsec@<x2.x2.x2.x2>
    ```

    1. Check the strongSwan status:

        ```bash
        sudo swanctl -L
        ```

        Result:

        ```bash
        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
        ```

    1. Check active IPsec connections:
    
        ```bash
        sudo swanctl -l
        ```

        Result:

        ```bash
        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.

    1. Terminate the `remote-gw` connection:

        ```bash
        exit
        ```

1. Connect to `vm-d`:

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

    1. Change the VM date and time settings:

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

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

        ```bash
        ping -c4 10.10.10.10
        ```

        Result:

        ```bash
        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
        ```

    1. Terminate the `vm-d` connection:

        ```bash
        exit
        ```

1. Connect to `vm-b`:

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

    1. Change the VM date and time settings:

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

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

        ```bash
        ping -c4 10.10.10.10
        ```

        Result:

        ```bash
        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
        ```

    1. Terminate the `vm-b` connection:

        ```bash
        exit
        ```

1. Connect to `vm-1`:

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

    1. Change the VM date and time settings:

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

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

        ```bash
        ping -c4 172.16.1.5
        ```

        Result:

        ```bash
        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
        ```

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

        ```bash
        ping -c4 172.16.2.5
        ```

        Result:

        ```bash
        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
        ```
    
    1. Terminate the `vm-1` connection:

        ```bash
        exit
        ```


## How to delete the resources you created {#clear-out}

To stop paying for the resources you created:

* [Delete the VM](../../../compute/operations/vm-control/vm-delete.md).
* [Delete the static public IP address](../../operations/address-delete.md).
* [Delete the subnet](../../operations/subnet-delete.md).
* [Delete the cloud network](../../operations/network-delete.md).