# Create an IPSec Tunnel between a VDC and On-Premises Gateway
## Overview
This tutorial demonstrates configuring an IPSec site-to-site VPN Gateway for secure and encrypted communications, establishing a connection between an IONOS Cloud VDC and a simulated user-managed on-premises installation. It utilizes a managed VPN Gateway in the IONOS Cloud and a user-managed on-premises gateway.
This tutorial demonstrates the use of the following:
| **Components** | **Description** |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Two VDCs | - ionos-cloud-txl as IONOS Cloud's VDC.
- user-on-prem-lhr simulates a user-managed on-premises setup.
|
| Managed gateways | We use a single managed gateway in ionos-cloud-txl for the cloud side.
For a user-managed gateway, we use on-premises simulation, install the components, and manually configure IPSec on a virtual server to complete the setup.
|
## Target audience
This tutorial is intended to help both developers and technical decision-makers.
## What you will learn
By the end of this tutorial, you will be able to establish secure site-to-site connectivity, provision and configure a managed IPSec VPN Gateway in IONOS Cloud, simulate an on-premises gateway, and set up the tunnel parameters, including pre-shared keys, LAN subnets, and routing rules. This process creates the secure tunnel and allows you to verify successful traffic flow between the cloud and on-premises hosts.
## Before you begin
The following information is necessary to set up an IPSec connection between a VDC and on-premises VDC:
| **Components** | **IONOS Cloud (Left)** `ionos-cloud-txl` | **User On-Premises (Right)** `user-on-prem-lhr` |
| -------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **VDC Name** | `ionos-cloud-txl` | `user-on-prem-lhr` |
| **Gateway Public Address** | `203.0.113.10` | `203.0.113.20` |
| **LAN ID** | `1` | `Not applicable` |
| **LAN Subnet** | `192.168.1.0/24` | `192.168.2.0/24` |
| **Gateway LAN Address** | `192.168.1.5` | `192.168.2.5` |
| **LAN Host 1** | `192.168.1.11` | `192.168.2.11` |
| **LAN Host 2** | `192.168.1.12` | `192.168.2.12` |
| **Pre-Shared Key** | Remember to use the appropriate key. | **Example:** `vPabcdefg123435hij565k7lmno8pq=`. This is a sample key used as an example in this document. Do not use this key for real-world scenarios. |
{% hint style="info" %}
**Note:**
* Ensure that the **IONOS Cloud (Left)** and **User On-Premises (Right)** LAN subnets are unique and do not overlap.
* Using the same subnet CIDR in the **IONOS Cloud (Left)** or **User On-Premises (Right)** does not work. In such a scenario, we recommend either of the following options:
* Move one of them to a different subnet.
* Add an additional network connection to LAN hosts on one side using a unique subnet, and then route the unique subnet via the VPN Gateway.
{% endhint %}
### Reserve IP addresses
Before proceeding, ensure you have an IP block with at least one free IP address to assign to each gateway. For more information, see [Reserve an IPv4 Address](https://docs.ionos.com/cloud/network-services/vdc-networking/how-tos/ip-addresses).
| **IONOS Cloud (Left) `ionos-cloud-txl` Gateway Public Address** | **User On-Premises (Right) `user-on-prem-lhr` Gateway Public Address** |
| --------------------------------------------------------------- | ---------------------------------------------------------------------- |
| `203.0.113.10` | `203.0.113.20` |
### Configure LAN
This tutorial uses `192.168.1.0/24` and `192.168.2.0/24` for private LANs in **IONOS Cloud (Left)** `ionos-cloud-txl` and **User On-Premises (Right)** `user-on-prem-lhr` respectively. Remember to assign an IP address from the subnet to each gateway. The chosen IP address must be outside the DHCP pool and range from `.2 - .9`.
| **Components** | **IONOS Cloud (Left)** `ionos-cloud-txl` | **User On-Premises (Right)** `user-on-prem-lhr` |
| ------------------- | ---------------------------------------- | ----------------------------------------------- |
| LAN ID | `1` | `Not applicable` |
| LAN Subnet | `192.168.1.0/24` | `192.168.2.0/24` |
| Gateway LAN Address | `192.168.1.5` | `192.168.2.5` |
### Generate Pre-Shared Key (PSK)
Our current IPSec implementation supports PSK (which is expected to support certificates in the future). When provisioning gateways, ensure you generate a PSK at least 32 characters long. Optionally, you can also generate a PSK while [creating an IPSec tunnel](https://docs.ionos.com/cloud/network-services/vpn-gateway/dcd-how-tos/create-peer-tunnel). The following commands explain how to generate PSK for Linux and Windows, respectively:
{% tabs %}
{% tab title="Linux" %}
Execute either of these commands: \`\`\`bash openssl rand -base64 48 \`\`\` \`\`\`bash head -c 32 /dev/urandom | base64 \`\`\`
{% endtab %}
{% tab title="Windows" %}
\`\`\`bash $b = New-Object byte\[] 32; (New-Object System.Security.Cryptography.RNGCryptoServiceProvider).GetBytes($b); \[System.Convert]::ToBase64String($b) | Set-Content -Path .\psk.txt -Encoding ASCII \`\`\`
{% endtab %}
{% endtabs %}
## Procedure
The execution process is divided into the following steps:
{% stepper %}
{% step %}
#### Simulate IONOS Cloud `ionos-cloud-txl`
Below are some screenshots from the DCD that contains the required VDCs.
To begin with, two virtual servers on the IONOS Cloud are provisioned and connected to each other via a private LAN. In this instance, LAN1 uses a custom subnet of `192.168.1.0/24`. We designate these two servers as `192.168.1.11` and `192.168.1.12`, respectively.
{% endstep %}
{% step %}
#### Simulate on-premises `user-on-prem-lhr` setup
Imagine the `user-on-prem-lhr` VDC as a user-managed site where you provision three virtual servers. Here, we will use the LAN subnet `192.168.2.0/24`. The **Users VPN GW** has been configured with internet access IP address: `203.0.113.20` and a private LAN address of `192.168.2.5`, this will function as the on-premises host acting as a user-managed gateway. The two private LAN hosts are addressed as `192.168.2.11` and `192.168.2.12`, respectively.
{% endstep %}
{% step %}
#### Provision the VPN Gateway
1\. In the **DCD**, go to **Menu** > **Network Services** > **VPN Gateway**.
2\. Click **Create VPN Gateway** from the **VPN Gateways** window.
3\. Enter the following details:
{% tabs %}
{% tab title="Properties" %}
\| \*\*Components\*\* | \*\*Description\*\* | \*\*Example\*\* | | --- | --- | --- | |\*\*Name\*\* | Enter a descriptive name for the gateway instance. It is not required to be globally unique but must be limited to 255 characters. |\`site\_to\_site\`| |\*\*Description\*\* | Enter a descriptive text for the gateway. It is limited to 1024 characters. | \`VPN Gateway for creating an IPSec Tunnel between a VDC and on-premises gateway\`. | |\*\*Location\*\* | Select a location from the drop-down list of available locations for VPN Gateway. |\`de/txl\`| |\*\*IP Address\*\*| Select an IP address from the drop-down list of available public IPv4 addresses. |\`203.0.113.10\` |
{% endtab %}
{% tab title="VPN Tier" %}
The \*\*Enhanced VPN\*\* tier is selected by default. The number of LANs and tunnels or peers differ for each tier. You can also enable \*\*High Availability\*\* for a chosen tier, allowing VMs to operate in an active-passive mode. It minimizes downtime during a failover and ensures an uninterrupted connection.
{% hint style="info" %}
**Note:** You can only upgrade the tier or switch between High Availability (HA) and non-HA variants during editing.
{% endhint %}
!\[Select a tier]\(../../images/vpn-gateway/tutorial-ipsec-vdc-on-prem-dcd-tier.png)
{% endtab %}
{% tab title="Protocol" %}
The IPSec protocol is selected by default, and no additional configuration parameters are necessary.
{% endtab %}
{% tab title="LAN Connections" %}
Attach a VPN Gateway to LANs in \`ionos-cloud-txl\`. You can only connect to LANs in the exact location where the VPN Gateway was provisioned. Take a look at the following mandatory parameters:
| **Components** | **Description** | **Example** |
| --------------- | -------------------------------------------------------------------------------------------- | ----------------------------- |
| **Datacenter** | Select a data center from the drop-down that lists VDCs in the same location as the gateway. | `ionos-cloud-txl` |
| **Connections** | A list of connected LANs and the LAN addresses. | Refer to the following table. |
After selecting a data center, click **Add LAN Connection** to launch an additional pop-up window to set the following properties:
| **Components** | **Description** | **Example** |
| -------------- | ----------------------------------------------------------------------- | ---------------- |
| **LAN** | The ID of the LAN to connect to. | `1` |
| **IPv4 CIDR** | The LAN IPv4 address assigned to the subnet's gateway in CIDR notation. | `192.168.1.5` |
| **IPv6 CIDR** | The LAN IPv6 address assigned to the subnet's gateway in CIDR notation. | `Not applicable` |
{% endtab %}
{% tab title="Maintenance Window" %}
Define a maintenance window to begin at the specified start time (UTC) and continue for a duration of four hours. Specify the following:
| **Components** | **Description** | **Example** |
| -------------- | -------------------------------------------------------------------------------------- | ----------- |
| **Day** | Select a day from the drop-down list to set a day for maintenance. | `Sunday` |
| **Time** | Enter a time using the pre-defined format (hh:mm:ss) to schedule the maintenance task. | `01:40 AM` |
{% endtab %}
{% endtabs %}
4\. Click **Save** and wait for the gateway to complete provisioning. The process typically takes about 8-10 minutes, but further operations on the gateway will be instantaneous.
{% endstep %}
{% step %}
#### Configure the VPN tunnel
Now that the VPN Gateway instance is provisioned, the next step is to configure a tunnel to permit the two sides to talk to each other. We will need to configure a tunnel on both gateways, but the on-premises will be configured using IPSec configuration files.
1\. Click **Create Tunnels** to begin configuring a new tunnel.
{% tabs %}
{% tab title="Properties" %}
Enter the following details to configure a tunnel:
| **Components** | **Description** | **Example** |
| --------------- | ----------------------------------------------------------------------------------------------------------- | ---------------- |
| **Tunnel Name** | Specify a name for the tunnel. It does not need to be globally unique and can be up to 255 characters long. | `customer_site` |
| **Description** | Enter more descriptive text for the peer, not exceeding 1024 characters. | `Not applicable` |
| **Remote Host** | The public IPv4 address of the remote VPN Gateway. | `203.0.113.20` |
{% endtab %}
{% tab title="Authentication" %}
Set the PSK as shown:
| **Components** | **Description** | **Example** |
| ------------------ | ------------------------------------------------------- | --------------------------------- |
| **Pre-Shared Key** | Enter a strong key that is at least 32 characters long. | `vPabcdefg123435hij565k7lmno8pq=` |
{% endtab %}
{% tab title="Initial Exchange" %}
This tab displays the Initial Exchange (IKE\_SA\_INIT) Settings.
{% hint style="info" %}
**Note:** Both sites typically have the same exchange settings. If the configuration differs on both sides, the two gateways will negotiate to agree on the most secure settings.
{% endhint %}
Here, you can set the various encryption and integrity algorithms, Diffie-Hellman Group, and lifetimes for the IKE exchange phase. For demonstration, the available options are aligned with BSI best practices. However, we will accept the default selections.
| **Components** | **Description** | **Example** |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| **Diffe-Hellman** | The Diffie-Hellman (DH) key exchange algorithm makes a shared encryption key available to two entities without exchanging the key. The shared encryption key serves as a symmetric key for encrypting data. Only the two parties involved in the DH key exchange can derive the shared key, which is never transmitted over the network. | `15-MODP3072` |
| **Encryption Algorithm** | Encryption algorithms safeguard data to prevent third-party access during transmission. | `AES128-CTR` |
| **Integrity Algorithm** | Integrity algorithms verify messages and randomness, ensuring packets are authentic and not altered by a third party before arrival, and generate keying material for encryption. | `SHA256` |
| **Lifetime** | The duration (in seconds) for which a negotiated IKE SA key remains valid. Before the key lifetime expires, the SA must be re-keyed; otherwise, upon expiration, the SA must begin a new IKEv2 IKE SA re-key. | `86400` |
{% endtab %}
{% tab title="Child SA/IPSec" %}
This tab displays the Child SA/IPSec SA Settings (ESP) settings.
{% hint style="info" %}
**Note:** Both sites typically have the same Encapsulating Security Payload (ESP) settings. If the configuration differs, the two gateways will negotiate to agree on the most secure settings.
{% endhint %}
Here, you can set the various encryption and integrity algorithms, Diffie-Hellman Group, and lifetimes for the ESP phase. For demonstration, the available options are aligned with BSI best practices. However, we will accept the default selections.
| **Components** | **Description** | **Example** |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| **Diffe-Hellman** | The Diffie-Hellman (DH) key exchange algorithm is a method used to make a shared encryption key available to two entities without exchanging the key. The encryption key for the two devices is used as a symmetric key for encrypting data. Only the two parties involved in the DH key exchange can deduce the shared key, and the key is never sent over the wire. | `15-MODP3072` |
| **Encryption Algorithm** | Encryption algorithms safeguard data to prevent third-party access during transmission. | `AES128-CTR` |
| **Integrity Algorithm** | Integrity algorithms verify messages and randomness, ensuring packets are authentic and not altered by a third party before arrival, and generate keying material for encryption. | `SHA256` |
| **Lifetime** | The ESP SA specifies the duration for which keys generated during the IKE negotiation remain valid for encrypting and authenticating the data packets being transmitted. | `3600` |
{% endtab %}
{% tab title="Network CIDRs" %}
Configure the subnets in CIDR format, which are permitted to connect to the tunnel.
{% hint style="info" %}
**Note:** You may use `0.0.0.0/0` to permit any network; however, one site should explicitly define the network CIDRs permitted. Using `0.0.0.0/0` on both VPN gateways will result in broken routing.
{% endhint %}
\| \*\*Components\*\* | \*\*Description\*\* | \*\*Example\*\* | | ---| --- | --- | | \*\*Cloud Network CIDRs\*\* | Network addresses on the cloud side that are permitted to connect to the tunnel.| \`192.168.1.0/24\` | | \*\*Peer Network CIDRs\*\* | Network addresses on the peer or remote side that are permitted to connect to the tunnel. | \`192.168.2.0/24\` |
{% endtab %}
{% endtabs %}
2\. Click **Save** to save the tunnel configuration. This operation usually takes about one to two minutes to complete.
{% endstep %}
{% step %}
#### Deploy on-premises IPSec instance
In this tutorial, **Users VPN GW** in `user-on-prem-lhr` acts as a user-managed gateway. It has internet access, so SSH can be used instead of the web console. Start establishing an SSH connection to **Users VPN GW**'s public IPv4 address in London, remember to forward your ssh key when establishing this session. You will need this key while [establishing a console session to the LAN hosts](#63-configure-routing-for-on-premises-lan-hosts-user-on-prem-lhr).
5.1 Install pre-requisite software
{% hint style="info" %}
**Note:** This tutorial performs a basic install and setup of Strongswan on Ubuntu. It is neither an in-depth guide nor does it contain detailed information about the configuration files' content. It is an exercise for the reader to determine the correct installation procedure for a secure production environment.
{% endhint %}
Update the package lists and install the required packages:
```bash
apt-get update
apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins libtss2-tcti-tabrmd0 -y
```
5.2 Enable IP Forwarding
The VPN Gateway acts as a router and, therefore, is required to forward packets:
```bash
sysctl -w net.ipv4.ip_forward=1
```
This tutorial does not use an IPv6 address. If you intend to use one, ensure `net.ipv6.config.all.forwarding=1` exists.
5.3 Configure IPSec
This tutorial will walk you through specific options for configuring IPSec, but the rest of the configuration remains an exercise for the reader. This section contains the configuration files and content specific to this installation and peer setup.
**1. Populate secrets file**
Currently, IPSec supports only pre-shared Keys (PSK), so ensure the `/etc/ipsec.secrets` file contains the key, so IPSec can read it from the file:
```bash
203.0.113.10 203.0.113.20 : PSK "vPabcdefg123435hij565k7lmno8pq="
```
**2. Populate IPSec config file**
Next, populate the `/etc/ipsec.conf` file. This file contains a basic `config setup` section and a `conn` section that defines the configuration of the remote tunnel. For more information, see [Download VPN Gateway Configuration](https://docs.ionos.com/cloud/network-services/vpn-gateway/dcd-how-tos/download-config).
```bash
config setup
charondebug=all
uniqueids=yes
conn ionos-cloud-de-txl
type=tunnel
auto=start
keyexchange=ikev2
authby=secret
left=203.0.113.10
leftsubnet=192.168.1.0/24
right=203.0.113.20
rightsubnet=192.168.2.0/24
ike=aes128ctr-sha256-modp3072
esp=aes128ctr-sha256-modp3072
aggressive=no
keyingtries=%forever
ikelifetime=86400s
lifetime=3600s
dpddelay=30s
dpdtimeout=120s
dpdaction=restart
```
**3. Enable and start the IPSec service**
Run the following commands to start IPSec and ensure it also starts on boot:
```bash
systemctl enable ipsec
systemctl start ipsec
```
**4. Verify status of the tunnel connection**
Run the `ipsec status` command to check if the tunnel connection is established.
```bash
root@users-vpn-gw# ipsec status
Security Associations (1 up, 0 connecting):
d44-5c8-48-87-28f9[2]: ESTABLISHED 3 minutes ago, 203.0.113.20[203.0.113.20]...203.0.113.10[203.0.113.10]
d44-5c8-48-87-28f9{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c8f59a5e_i caa486ae_o
d44-5c8-48-87-28f9{2}: 192.168.2.0/24 === 192.168.1.0/24
```
{% endstep %}
{% step %}
#### Configure routing on LAN hosts
Currently, it is impossible to automate the addition of routes to LAN hosts to route the required subnets over the VPN Gateway. In this section, we will manually add the required routes. Remember to add them to the LAN hosts in both the VDCs.
**6.1 Configure routing for IONOS Cloud LAN hosts `ionos-cloud-txl`**
Step 1: Establish a console session to the LAN host(s)
We will use the web console to test connectivity for the LAN hosts without internet access. Open a console session and ping the LAN address assigned to the VPN Gateway, `192.168.1.5`. Begin by pinging the IP address:
```bash
root@lanhost1:~# ping -c 3 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5 icmp_seq=1 ttl=64 time=0.456 ms
64 bytes from 192.168.1.5 icmp_seq=2 ttl=64 time=0.352 ms
64 bytes from 192.168.1.5 icmp_seq=3 ttl=64 time=0.503 ms
--- 192.168.1.5 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2019ms
rtt min/avg/max/mdev = 0.352/0.437/0.503/0.063 ms
root@lanhost1:~#
```
Step 2: Configure the VPN route
The LAN host(s) must know where to route the traffic. To accomplish this, we will add a route for the `user-on-prem-lhr` LAN subnet `192.168.2.0/24` via the `ionos-cloud-txl` gateway's LAN address `192.168.1.5`:
```bash
ip route add 192.168.2.0/24 via 192.168.1.5
```
We cannot ping hosts in the `user-on-prem-lhr` region because those servers do not yet know how to route the traffic. To resolve this issue, continue adding routes for LAN hosts in `user-on-prem-lhr`.
**6.2 Set persistent routes**
In the **6.1 Configure routing for IONOS Cloud LAN hosts `ionos-cloud-txl`** section, we added routes that will not persist during a reboot. You must determine how to set persistent routes for your choice of operating system.
Persistent routes
First, add the configuration to your system's appropriate network or routing configuration files to set persistent routes. The exact method depends on your operating system. The following examples show how to make a route persistent across reboots for Debian, Ubuntu, CentOS, and RHEL.
**Debian/Ubuntu**
You can add the route to any of the following:
* the `/etc/network/interfaces` file.
* in a specific file under `/etc/network/`. Example: `/etc/network/interfaces.d/`.
* use the `ip route` command in a startup script. Example: `/etc/rc.local`.
**Example of `/etc/network/interfaces`:**
```bash
{{auto eth0
iface eth0 inet static
address 192.168.1.11
netmask 255.255.255.0
post-up ip route add 192.168.2.0/24 via 192.168.1.5}}
```
**CentOS/RHEL**
You can add the route in `/etc/sysconfig/network-scripts/route-eth0` and adjust it according to the relevant interface. Example: `192.168.2.0/24 via 192.168.1.5`.
Save the configuration file changes and restart the network service to apply the changes.
**6.3 Configure routing for on-premises LAN hosts `user-on-prem-lhr`**
{% hint style="info" %}
**Note:** Configure the host acting as a user-managed gateway, as it can already route traffic based on the IPSec configuration. This section focuses solely on the other on-premises hosts connected to the same LAN.
{% endhint %}
Step 1: Establish a console session to the LAN hosts
The user-managed gateway `user-on-prem-lhr` is connected to the internet and can be used as a jump-host to reach the on-premises LAN hosts. From the user-managed gateway, establish an SSH connection to the first LAN host `192.168.2.11`, alternatively you may use the web console to login to the LAN hosts.
You can test the connectivity to the LAN address assigned to the user-managed gateway VPN Gateway `user-on-prem-lhr` using a console session. In this case, the user-managed gateway address is `192.168.2.5`. Let us begin by attempting to ping this IP address.
```bash
root@users-vpn-gw# ssh 192.168.2.11
root@lanhost1# ping 192.168.2.5
PING 192.168.2.5 (192.168.2.5) 56(84) bytes of data.
64 bytes from 192.168.2.5 icmp_seq=1 ttl=62 time=0.239 ms
64 bytes from 192.168.2.5 icmp_seq=2 ttl=62 time=0.296 ms
64 bytes from 192.168.2.5 icmp_seq=3 ttl=62 time=0.268 ms
64 bytes from 192.168.2.5 icmp_seq=4 ttl=62 time=0.369 ms
--- 192.168.2.5 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2019ms
rtt min/avg/max/mdev = 0.352/0.437/0.503/0.063 ms
root@lanhost1:~#
```
Step 2: Configure the VPN route
The LAN host(s) must know where to route return traffic. Hence, we will add a route for the `ionos-cloud-txl` LAN subnet `192.168.1.0/24` via the `user-on-prem-lhr` user-managed gateway's LAN address `192.168.2.5`.
```bash
ip route add 192.168.1.0/24 via 192.168.2.5
```
Repeat this process for all on-premises LAN hosts that need to send or receive traffic over the tunnel. At this point, the two sites can establish complete connectivity via the VPN Gateway.
{% endstep %}
{% endstepper %}
### Final result
After completing all steps, you will have a fully operational IPSec site-to-site VPN tunnel between your IONOS Cloud VDC `ionos-cloud-txl` and your simulated on-premises environment `user-on-prem-lhr`. You should now be able to ping hosts in the simulated on-premises setup in `user-on-prem-lhr` from cloud hosts in `ionos-cloud-txl` and vice-versa. Both cloud and on-premises LAN hosts can securely communicate across the tunnel, with routing configured to allow seamless traffic flow between the two networks. You can verify connectivity by successfully pinging hosts on either side, confirming encrypted and secure communication is established.
{% tabs %}
{% tab title="Connected with ionos-cloud-txl VPN Gateway" %}
\`\`\`bash root\@lanhost1:\~# ping -c 5 192.168.2.12 PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data. 64 bytes from 192.168.2.12 icmp\_seq=1 ttl=62 time=18.8 ms 64 bytes from 192.168.2.12 icmp\_seq=2 ttl=62 time=19.3 ms 64 bytes from 192.168.2.12 icmp\_seq=3 ttl=62 time=19.0 ms 64 bytes from 192.168.2.12 icmp\_seq=4 ttl=62 time=18.8 ms 64 bytes from 192.168.2.12 icmp\_seq=5 ttl=62 time=19.1 ms
\--- 192.168.2.12 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 18.782/18.995/19.270/0.188 ms root\@lanhost1:\~#
````
```bash
root@lanhost1:~# ping -c 5 192.168.1.12
PING 192.168.1.12 (192.168.1.12) 56(84) bytes of data.
64 bytes from 192.168.1.12 icmp_seq=1 ttl=62 time=18.8 ms
64 bytes from 192.168.1.12 icmp_seq=2 ttl=62 time=19.3 ms
64 bytes from 192.168.1.12 icmp_seq=3 ttl=62 time=19.0 ms
64 bytes from 192.168.1.12 icmp_seq=4 ttl=62 time=18.8 ms
64 bytes from 192.168.1.12 icmp_seq=5 ttl=62 time=19.1 ms
--- 192.168.1.12 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 18.999/19.594/21.062/0.751 ms
root@lanhost1:~#
````
{% endtab %}
{% endtabs %}
## Conclusion
You have successfully configured a site-to-site VPN between the IONOS Cloud `ionos-cloud-txl` and a user-managed on-premises setup `user-on-prem-lhr` by utilizing a managed VPN Gateway in the cloud and a user-managed on-premises gateway.
{% hint style="info" %}
**Note:** Ensure you remove the VPN Gateway before attempting to delete VMs, LANs, or the VDC.
{% endhint %}