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 chart. To do this:
- Prepare your cloud.
- Set up a cloud site.
- Set up a remote site.
- 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:
- Go to the management console
and log in to Yandex Cloud or create an account if you do not have one yet. - On the Yandex Cloud Billing
page, make sure you have a billing account linked and it has theACTIVE
orTRIAL_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
Learn more about clouds and folders.
Required paid resources
The infrastructure deployment cost for this solution based on IPsec gateways includes:
- Fee for continuously running virtual machines (see Yandex Compute Cloud pricing).
- Fee for using a static external IP address (see Yandex Virtual Private Cloud pricing).
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:
-
Open the terminal.
-
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 namedid_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
-
Run
cmd.exe
orpowershell.exe
(make sure to update PowerShell before doing so). -
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 namedid_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:
-
Download
and install PuTTY. -
Make sure the directory where you installed PuTTY is included in
PATH
:- Right-click My computer. Click Properties.
- In the window that opens, select Additional system parameters, then Environment variables (located in the lower part of the window).
- Under System variables, find
PATH
and click Edit. - In the Variable value field, append the path to the directory where you installed PuTTY.
-
Launch the PuTTYgen app.
-
Select EdDSA as the pair type to generate. Click Generate and move the cursor in the field above it until key creation is complete.
-
In Key passphrase, enter a strong password. Enter it again in the field below.
-
Click Save private key and save the private key. Do not share its key phrase with anyone.
-
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 and create and set up an infrastructure for your site in Yandex Cloud: an IPsec gateway, two VMs, 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:
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 a network and subnets on the cloud site
-
Create a network named
cloud-net
. When creating your network, disable the Create subnets option. -
In the
cloud-net
network, manually create subnets with the following parameters:-
To connect the
cloud-gw
main IPsec gateway:- Name:
ipsec-subnet
. - Zone:
ru-central1-b
. - CIDR:
172.16.0.0/24
.
- Name:
-
To connect the
vm-d
VM:- Name:
subnet-d
. - Zone:
ru-central1-d
. - CIDR:
172.16.1.0/24
.
- Name:
-
To connect the
vm-b
VM:- Name:
subnet-b
. - Zone:
ru-central1-b
. - CIDR:
172.16.2.0/24
.
- Name:
-
Create and set up a security group for the main IPsec gateway
-
In
cloud-net
, create a security group namedcloud-net-sg
. -
In the
cloud-net-sg
security group, create rules based on the table below:Traffic
directionDescription Port range Protocol Source /
Destination nameCIDR 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-d
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
-
In the management console
, go to the folder where you created thecloud-net
network. -
Select Virtual Private Cloud.
-
Select the
cloud-net
network. -
Go to the Routing tables tab and click Create.
-
In the Name field, specify
cloud-net-rt
. -
Under Static routes, click Add a route.
- In the window that opens, specify
10.10.0.0/16
in the Destination prefix field. - In the IP address field, enter the private IP address of the main IPSec gateway:
172.16.0.10
. - Click Add.
- In the window that opens, specify
-
Click Create a routing table.
-
Link the
cloud-net-rt
route table tosubnet-d
andsubnet-b
:- Go to the Overview tab.
- In the
subnet-d
row, click and select Link routing table. - In the window that opens, select the
cloud-net-rt
route table and click Link. - Repeat the previous two steps for
subnet-b
to link thecloud-net-rt
route table.
Create and configure VMs on the cloud site
Create a VM with the main IPsec gateway on the cloud site
-
On the folder page in the management console
, click Create resource and selectVirtual machine instance
. -
Under Boot disk image, in the Product search field, enter
IPsec instance
and select a public IPsec instance image. -
Under Location, select the
ru-central1-b
availability zone hosting the subnet to connect the main IPsec gateway to. -
Under Network settings:
-
In the Subnet field, select
ipsec-subnet
. -
In the Public IP field, select
List
. -
In the IP address field that opens, select the
<x1.x1.x1.x1>
public IP address you previously reserved. -
In the Security groups field, select the previously created
cloud-net-sg
security group. -
Expand the Additional section:
- In the Internal IPv4 address field, select
Manual
. - In the input field that appeared, enter the address
172.16.0.10
.
- In the Internal IPv4 address field, select
-
-
Under Access, select SSH key and specify the data for access to the VM:
-
In the Login field, specify
ipsec
. -
In the SSH key field:
- Click Add key.
- Enter a name for the SSH key.
- Upload or paste the contents of the previously created public SSH key to access the VM.
- Click Add.
The SSH key will be added to your organization user profile.
If users cannot add SSH keys to their profiles in the organization, the added public SSH key will only be saved to the user profile of the VM being created.
-
-
Under General information, specify the VM name:
cloud-gw
. -
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.
-
Connect to the VM over SSH:
ssh ipsec@<x1.x1.x1.x1>
-
Set the date and time parameters for the VM:
sudo timedatectl set-timezone Europe/Moscow sudo timedatectl set-ntp True timedatectl
-
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
. -
Create a backup copy of the
swanctl.conf
file:sudo mv /etc/swanctl/swanctl.conf /etc/swanctl/swanctl.orig
-
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 (<x2.x2.x2.x2>
) of the remote IPsec gateway.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 for an IPsec connection.
Note
You can set additional parameters in the
swanctl.conf
configuration 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. -
Upload the configuration to strongSwan:
sudo swanctl --load-all
-
Restart strongSwan:
sudo systemctl restart strongswan
-
Check the strongSwan status:
sudo swanctl -L
-
(Optional) View the strongSwan logs:
sudo journalctl -u strongswan --no-pager sudo journalctl -u strongswan -n 20 sudo journalctl -u strongswan -f
-
Terminate the connection with
cloud-gw
:exit
Deploy test VMs on the cloud site
-
Create a test VM named
vm-d
with the following parameters:- Operating system: Ubuntu 22.04 LTS.
- Availability zone:
ru-central1-d
. - Subnet:
subnet-d
. - Public IP:
No address
. - Internal IPv4 address:
172.16.1.5
. - Login:
ipsec
. - SSH key: Public SSH key for VM access.
- Name:
vm-d
.
-
Create a test VM named
vm-b
with the following parameters:- Operating system:
Ubuntu 22.04 LTS
. - Availability zone:
ru-central1-b
. - Subnet:
subnet-b
. - Public IP:
No address
. - Internal IPv4 address:
172.16.2.5
. - Login:
ipsec
. - SSH key: Public SSH key for VM access.
- Name:
vm-b
.
- Operating system:
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
-
Create a network named
remote-net
. When creating your network, disable the Create subnets option. -
In the
remote-net
network, manually create a subnet to connect theremote-gw
remote IPsec gateway and a VM namedvm-1
with the following parameters:- Name:
subnet-1
. - Zone:
ru-central1-b
. - CIDR:
10.10.0.0/16
.
- Name:
Create and set up a security group for the remote IPsec gateway
-
In the
remote-net
network, create a security group namedremote-net-sg
. -
In the
remote-net-sg
security group, create rules based on the table below:Traffic
directionDescription Port range Protocol Source /
Destination nameCIDR 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
-
In the management console
, go to the folder where you created theremote-net
network. -
Select Virtual Private Cloud.
-
Select the
remote-net
network. -
Go to the Routing tables tab and click Create.
-
In the Name field, specify
remote-net-rt
. -
Under Static routes, click Add a route.
- In the window that opens, specify
172.16.1.0/24
in the Destination prefix field. - In the IP address field, enter the private IP address of the main IPSec gateway:
10.10.20.20
. - Click Add.
- In the window that opens, specify
-
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
.
- Destination prefix:
-
Click Create a routing table.
-
Link the
remote-net-rt
route table tosubnet-1
:- Go to the Overview tab.
- In the
subnet-1
row, click and select Link routing table. - 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.
-
On the folder page in the management console
, click Create resource and selectVirtual machine instance
. -
Under Boot disk image, in the Product search field, enter
IPsec instance
and select a public IPsec instance image. -
Under Location, select the
ru-central1-b
availability zone hosting the subnet to connect the remote IPsec gateway to. -
Under Network settings:
-
In the Subnet field, select
subnet-1
. -
In the Public IP field, select
List
. -
In the IP address field that opens, select the
<x2.x2.x2.x2>
public IP address you previously reserved. -
In the Security groups field, select the previously created
remote-net-sg
security group. -
Expand the Additional section:
- In the Internal IPv4 address field, select
Manual
. - In the input field that appeared, enter the address
10.10.20.20
.
- In the Internal IPv4 address field, select
-
-
Under Access, select SSH key and specify the data for access to the VM:
-
In the Login field, specify
ipsec
. -
In the SSH key field, select the SSH key saved in your organization user profile after 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.
- Enter a name for the SSH key.
- Upload or paste the contents of the previously created public SSH key to access the VM.
- Click Add.
The SSH key will be added to your organization user profile.
If users cannot add SSH keys to their profiles in the organization, the added public SSH key will only be saved to the user profile of the VM being created.
-
-
Under General information, specify the VM name:
remote-gw
. The naming requirements are as follows:- The name must be from 3 to 63 characters long.
- It may contain lowercase Latin letters, numbers, and hyphens.
- The first character must be a letter and the last character cannot be a hyphen.
-
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.
-
Connect to the VM over SSH:
ssh ipsec@<x2.x2.x2.x2>
-
Set the date and time parameters for the VM:
sudo timedatectl set-timezone Europe/Moscow sudo timedatectl set-ntp True timedatectl
-
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
. -
Create a backup copy of the
swanctl.conf
file:sudo mv /etc/swanctl/swanctl.conf /etc/swanctl/swanctl.orig
-
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 (<x1.x1.x1.x1>
) of the main IPsec gateway.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 for an IPsec connection.
Note
You can set additional parameters in the
swanctl.conf
configuration 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. -
Upload the configuration to strongSwan:
sudo swanctl --load-all
-
Restart strongSwan:
sudo systemctl restart strongswan
-
Check the strongSwan status:
sudo swanctl -L
-
(Optional) View the strongSwan logs:
sudo journalctl -u strongswan --no-pager sudo journalctl -u strongswan -n 20 sudo journalctl -u strongswan -f
-
Terminate the connection with
remote-gw
:exit
Deploy a test VM on the remote site
Create a test VM with the following parameters:
- Operating system:
Ubuntu 22.04 LTS
. - Availability zone:
ru-central1-b
. - Subnet:
subnet-1
. - Public IP:
No address
. - Internal IPv4 address:
10.10.10.10
. - Login:
ipsec
. - SSH key: Public SSH key for VM access.
- Name:
vm-1
.
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:
-
Send several ICMP packets from the remote site’s side, e.g., from
vm-1
tovm-d
, using theping
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
-
Activate an IPsec connection on the cloud site's side by sending ICMP packets from
vm-b
tovm-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
-
Connect to the
cloud-gw
main IPsec gateway:ssh ipsec@<x1.x1.x1.x1>
-
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
-
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. -
Terminate the connection with
cloud-gw
:exit
-
-
Connect to the
remote-gw
remote IPsec gateway:ssh ipsec@<x2.x2.x2.x2>
-
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
-
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. -
Terminate the connection with
remote-gw
:exit
-
-
Connect to
vm-d
:ssh -J ipsec@<x1.x1.x1.x1> ipsec@172.16.1.5
-
Set the date and time parameters for the VM:
sudo timedatectl set-timezone Europe/Moscow sudo timedatectl set-ntp True timedatectl
-
Test IP connectivity between
vm-d
andvm-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
-
Terminate the connection with
vm-d
:exit
-
-
Connect to
vm-b
:ssh -J ipsec@<x1.x1.x1.x1> ipsec@172.16.2.5
-
Set the date and time parameters for the VM:
sudo timedatectl set-timezone Europe/Moscow sudo timedatectl set-ntp True timedatectl
-
Test IP connectivity between
vm-b
andvm-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
-
Terminate the connection with
vm-b
:exit
-
-
Connect to
vm-1
:ssh -J ipsec@<x2.x2.x2.x2> ipsec@10.10.10.10
-
Set the date and time parameters for the VM:
sudo timedatectl set-timezone Europe/Moscow sudo timedatectl set-ntp True timedatectl
-
Test IP connectivity between
vm-1
andvm-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
-
Test IP connectivity between
vm-1
andvm-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
-
Terminate the connection with
vm-1
:exit
-
How to delete the resources you created
To stop paying for the resources you created: