IPSec instance
An image with a pre-installed strongSwan solution for Linux and pre-configured routing and IP address translation rules. It can be used for secure connections between resources in a local data center and cloud resources through an IPSec tunnel. In this case, only one public IP address will be used: the one that will be assigned to the IPSec instance.
Before deployment, prepare the following:
- two separate VPC networks with subnets in the same availability zone: an external (
outside) network and an internal (inside) network; - a reserved public IPv4 address for the VM’s external interface;
- a route table in the
insidenetwork; - remote IPsec gateway parameters: its public IPv4 address, remote subnets, PSK, and IKE and ESP proposals.
Create a security group for the VM’s external interface. Allow inbound UDP traffic on ports 500 and 4500 from the public address of the remote IPsec gateway. If required, allow SSH on TCP port 22 from administrative addresses only. If you enable the HTTP health check, allow TCP port 8000 from the health check source.
Create a VM from the IPsec Instance image. Use at least 2 vCPUs, 512 MB of RAM, and a disk of at least 30 GB. Attach the network interfaces in the following strict order:
eth0: theoutsidesubnet, a static internal address, the reserved public IPv4 address, and the IPsec security group.eth1: theinsidesubnet, a static internal address, and no public IP address.
Add an ipsec key to the VM metadata with the following YAML value:
policy_name: yc-ipsec
remote_ip: <remote-gateway-public-ip>
preshared_key: <strong-preshared-key>
remote_subnets:
- 10.10.11.0/24
- 10.10.12.0/24
ike_proposal: aes128gcm16-prfsha256-ecp256
esp_proposal: aes128gcm16
r_timeout: 3.0
r_tries: 3
r_base: 1.0
web_hc: false
periodic_routes_update: true
The web_hc and periodic_routes_update parameters are optional and default to false:
web_hc: trueenables thehttp://<vm-address>:8000/healthendpoint;periodic_routes_update: truerefreshes routes fromremote_subnetsevery 15 minutes.
In the inside network route table, create routes for all remote_subnets. Use the internal address of the IPsec Instance eth1 interface as the next hop. Associate the route table with every subnet that requires access to the remote site.
No manual initialization command is required after the VM starts. The ipsec-host-init.service service automatically reads the metadata, renders the strongSwan configuration, and adds routes through the ipsec0 XFRM interface. strongSwan runs directly on the VM as a system service, without a Docker container.
Use the following commands to check the deployment:
sudo systemctl status ipsec-host-init.service strongswan.service ipsec-dev.service
sudo /usr/local/sbin/swanctl --list-sas
sudo /usr/local/sbin/swanctl --list-conns
sudo journalctl -u ipsec-host-init.service -u strongswan.service --no-pager
sudo tail -n 100 /var/log/strongswan.log
ip -d link show ipsec0
ip route show dev ipsec0
After changing IPsec metadata, apply the new configuration:
sudo systemctl restart ipsec-host-init.service
If only remote_subnets changed, you can refresh the routes immediately:
sudo /usr/local/bin/ipsec-update-routes.sh
The PSK, IKE and ESP proposals, and remote network parameters must match the remote IPsec gateway configuration.
- Creating a secure connection between resources in a local data center and cloud resources.
- Creating a secure connection between resources hosted in the clouds of different providers.
Yandex Cloud technical support is available 24/7 to respond to requests. The types of requests available and their response time depend on your pricing plan. You can activate paid support in the management console. Learn more about requesting technical support.