> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/~/revisions/NfgM5VQuRjXRMfbR25yK/network-services/vpn-gateway/tutorials/ipsec-vdc-onprem.md).
# Establish an IPSec Tunnel between a VDC and an On-Prem
## Introduction
A VPN Gateway enables secure, encrypted communications between roaming users, on-premise networks, and cloud resources. This tutorial demonstrates how you can configure VPN Gateway in IONOS Cloud to create a site-to-site setup between an IONOS Cloud VDC and a simulated on-prem installation.
## Overview
The primary goal of this tutorial is to configure a site-to-site VPN between IONOS Cloud and your on-premise setup by utilising a Managed VPN Gateway in the IONOS Cloud and a user-managed on-prem gateway.
This tutorial demonstrates the use of two VDCs:
* `de/txl` as IONOS's VDC
* `gb/lhr` simulates your on-prem setup.
Instead of two managed gateways per the VDC to VDC use case, this demonstration uses:
* a single managed gateway in `de/txl`.
* For user-managed gateway, we use an on-prem simulation, install the components and manually configure IPSec on a virtual server to complete the setup.
## Before you begin
The following information is necessary to set up a connection between an IPSec VDC and an on-prem VDC:
| **Components** | **Left** `(de/txl)` | **Right** `(gb/lhr)` |
| -------------------------- | ------------------------- | --------------------------------------------------------- |
| **Gateway Public Address** | 212.132.124.163 | 194.164.123.149 |
| **LAN ID** | 1 | 2 (Not applicable in this use case) |
| **LAN Subnet** | 10.10.1.0/24 | 10.10.2.0/24 |
| **Gateway LAN Address** | 10.10.1.5 | 10.10.2.10 |
| **Pre-Shared Key** | Remember to use your key. | **Example:** vP7ypxAiVbmXv8mCwLMpYcsCCzZBwu/nbhxUImkb8ks= |
### Reserve your IPs
Each VPN Gateway must be assigned a public IP address. Ensure you have an IPBlock with at least one free IP to assign to each gateway before proceeding.
| **Left `(de/txl)` Gateway Public Address** | **Right `(gb/lhr)` Gateway Public Address** |
| ------------------------------------------ | ------------------------------------------- |
| 212.132.124.163 | 194.164.123.149 |
### Configure LAN
This tutorial uses 10.10.1.0/24 and 10.10.2.0/24 for private LANs in the IONOS Cloud. Each gateway must be assigned an IP Address from the subnet. We will use .5 as the VPN Gateway is not DHCP aware. You should assign an IP address outside of the DHCP Pool ranging from .2 to .9.
{% hint style="info" %}
**Note:** `gb/lhr` is a user-managed gateway and it uses its LAN host address of .10 instead. Hence the above statement does not apply to this data center.
{% endhint %}
| **Components** | **Left `(de/txl)`** | **Right `(gb/lhr)`** |
| ------------------- | ------------------- | --------------------------- |
| LAN ID | 1 | 2 (But not applicable here) |
| LAN Subnet | 10.10.1.0/24 | 10.10.2.0/24 |
| Gateway LAN Address | 10.10.1.5 | 10.10.2.10 |
### Generate Pre-shared key (PSK)
Our current IPSec implementation supports PSK (expected to support certificates in the future). When provisioning gateways with DCD, ensure to generate a PSK that is at least 32 characters long. The following explain how to generate your own PSK:
**Linux**
* `openssl rand -base64 48`
* `head -c 32 /dev/urandom | base64`
**Windows**
* `[System.Convert]::ToBase64String((New-Object byte[] 32))| Set-Content -Path .\psk.txt -Encoding ASCII`
## Execution
The execution process is divided into the following steps:
1. [Set Up IONOS Cloud](#1-set-up-ionos-cloud)
2. [Simulate on-prem setup](#2-simulate-on-prem-setup)
3. [Provision the VPN Gateway](#3-provision-the-vpn-gateway)
4. [Configure the VPN Tunnel](#4-configure-the-vpn-tunnel)
5. [Deploy on-prem IPSec Instance](#5-deploy-on-prem-ipsec-instance)
6. [Configure routing on LAN hosts](#6-configure-routing-on-lan-hosts)
### 1. Set Up IONOS Cloud
Below are some screenshots from the DCD that contains the required VDCs.
#### 1.1 Simulate de/txl
Two virtual servers are provisioned on IONOS Cloud connected to each other via a private LAN. In this instance, LAN1 uses a custom subnet of 10.10.1.0/24.
We address these two servers as .10 and .11 respectively.
### 2. Simulate on-prem setup
Imagine, the `gb/lhr` VDC as your site. Two virtual servers are provisioned, host 1 has been configured with internet access and will be the on-prem host acting as your managed gateway. We address these two servers as .10 and .11 respectively.
### 3. Provision the VPN Gateway
1. In the **DCD**, go to **Menu** > **Network** > **VPN Gateway** under **Connectivity**.
2. Click **Create VPN Gateway** from the **VPN Gateways** window.
3. Enter the following details:
#### 3.1 Properties
| **Components** | **Description** | **Example** |
| --------------- | --------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **Description** | A descriptive text for the gateway. It is limited to 1024 characters. | |
| **IP Address** | A drop-down list of available public IPv4 Addresses. | 212.132.124.163 |
| **Location** | A drop-down list of available locations for VPN Gateway. | `de/txl` |
| **Name** | A descriptive name for the gateway instance. This does not need to be globally unique, but is restricted to 255 characters. | site\_to\_site |
#### 3.2 Protocol
The IPSec protocol is selected by default and no other configuration parameters are required.
#### 3.3 LAN Connections
Attach a VPN Gateway to LANs in IONOS Cloud. Note that it is only possible to connect to LANs present in the same location that the VPN Gateway was provisioned. Let us look at the parameters required:
| **Components** | **Description** | **Example** |
| --------------- | ---------------------------------------------------------------- | ----------- |
| **Datacenter** | A drop-down that lists VDCs in the same location as the gatweway | `de/txl` |
| **Connections** | A list of connected LANs and the LAN addresses | See Below |
Once a Datacenter has been selected, 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 gateway for this subnet in CIDR notation | 10.10.1.5/24 |
| **IPv6 CIDR** | The LAN IPv6 address assigned to the gateway for this subnet in CIDR Notation | Not applicable |
4. Click **Save** and wait for the gateway to complete provisioning. This will typically take 10-15 minutes but further operations on the gateway will be instantaneous.
### 4. Configure the VPN Tunnel
Now that the VPN Gateway instance is provisioned, next step is to configure a tunnel to permit the two sides to talk with each other. We will need to configure a tunnel on both gateways but the on-prem will be configured using IPSec configuration files.
1. Click **Create Tunnels** to begin configuring a new tunnel.
#### 4.1 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 is limited to 255 characters. | customer\_site |
| **Description** | More descriptive text for the peer, limited to 1024 characters | Not applicable |
| **Remote Host** | The Gateway Public IPv4 address of the remote VPN Gateway | 194.164.123.149 |
#### 4.2 Authentication
Set the PSK as shown:
| **Components** | **Description** | **Example** |
| ------------------ | --------------------------------------------- | -------------------------------------------- |
| **Pre-Shared Key** | A strong key with a minimum of 32 characters. | vP7ypxAiVbmXv8mCwLMpYcsCCzZBwu/nbhxUImkb8ks= |
#### 4.3 Initial Exchange (IKE\_SA\_INIT) Settings
{% hint style="info" %}
**Note:** Typically, both sites will have the same exchange settings. If, however, 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. The available options here are aligned with BSI best practices, for the purposes of the demonstration. 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 an exchange of 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 protect the data so it cannot be read by a third-party while in transit. | AES128-CTR |
| **Integrity Algorithm** | Integrity algorithms provide authentication of messages and randomness, ensuring that packets are authentic and were not altered by a third party before arriving, and also for constructing keying material for encryption. | SHA256 |
| **Lifetime** | The length of time (in seconds) that a negotiated IKE SA key is effective. 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 |
#### 4.4 Child SA/IPSec SA Settings (ESP)
{% hint style="info" %}
**Note:** Typically, both sites will have the same ESP settings. If, however, 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 ESP phase. The available options here are aligned with BSI best practices, for the purposes of the demonstration. 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 an exchange of 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 protect the data so it cannot be read by a third-party while in transit. | AES128-CTR |
| **Integrity Algorithm** | Integrity algorithms provide authentication of messages and randomness, ensuring that packets are authentic and were not altered by a third party before arriving, and also for constructing keying material for encryption. | SHA256 |
| **Lifetime** | The ESP SA determines how long the keys generated during the IKE negotiation are valid for encrypting and authenticating the actual data packets being transmitted. | 3600 |
#### 4.5. Network CIDRs
Configure the appropriate subnets in CIDR format that are permitted to connect to the tunnel.
| **Components** | **Description** | **Example** |
| ----------------------- | ------------------------------------------------------------------------------- | ------------ |
| **Cloud Network CIDRs** | Network addresses on the cloud side that are permitted to connect to the tunnel | 10.10.1.0/24 |
| **Peer Network CIDRs** | Network addresses on the cloud side that are permitted to connect to the tunnel | 10.10.2.0/24 |
2. Click **Save** to save the tunnel configuration. This operation should typically be completed within a minute or two.
### 5. Deploy on-prem IPSec Instance
In this tutorial, Host 1 in `gb/lhr` acts as user-managed gateway. The host has internet access and thus SSH can be used instead of the web console. Start by establishing an SSH connection to the public IPv4 address of host 1 in London.
5.1 Install pre-requisite software
**Note:** This tutorial performs a basic install and setup of Strongswan on Ubunutu. It is not an in-depth guide or provide 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.
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
```
We are not using IPv6 here, but if you intend to, you should ensure `net.ipv6.config.all.forwarding=1` exists.
5.3 Configure IPSec
This tutorial intends to walk users 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.
**Populate Secrets File**
IPSec currently supports only pre-shared Keys (PSK), so the key must be written to the `/etc/ipsec/ipsec.secrets` file for IPSec to read. Ensure the file contains the following:
```bash
212.132.124.163 194.164.123.149 : PSK "vP7ypxAiVbmXv8mCwLMpYcsCCzZBwu/nbhxUImkb8ks="
```
**Populate IPSec Config File**
Next, populate the `/etc/ipsec/ipsec.conf` file. This file contains a basic `config setup` section along with a `conn` section that defines the configuration of the remote tunnel.
```bash
config setup
charondebug=all
uniqueids=yes
conn ionos-cloud-de-txl-demo
type=tunnel
auto=start
keyexchange=ikev2
authby=secret
left=194.164.123.149
leftsubnet=10.10.2.0/24
right=212.132.124.163
rightsubnet=10.10.1.0/24
ike=aes128ctr-sha256-modp3072
esp=aes128ctr-sha256-modp3072
aggressive=no
keyingtries=%forever
ikelifetime=86400s
lifetime=3600s
dpddelay=30s
dpdtimeout=120s
dpdaction=restart
```
**Enable and Start IPSec Service**
Run the following commands to start IPSec and ensure it also starts on boot:
```bash
systemctl enable ipsec
systemctl start ipsec
```
**Show status of the tunnel connection**
Now you should be able to run `ipsec status` and see that the tunnel has been established.
```bash
root@london-lan-host-1:/etc# ipsec status
Security Associations (1 up, 0 connecting):
d4274954-58c8-4718-8217-28f7deac67f9[2]: ESTABLISHED 3 minutes ago, 194.164.123.149[194.164.123.149]...212.132.124.163[212.132.124.163]
d4274954-58c8-4718-8217-28f7deac67f9{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c8f59a5e_i caa486ae_o
d4274954-58c8-4718-8217-28f7deac67f9{2}: 10.10.2.0/24 === 10.10.1.0/24
```
### 6. 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 VDCs.
{% hint style="info" %}
**Note:** In the above example, we added routes that will not persist during a reboot. You must determine how to set persistent routes for their choice of operating system.
{% endhint %}
#### 6.1 Configure `de/txl` Route
Step 1: Establish a console session to the LAN host(s)
Because we did not provide internet access for the LAN hosts, our only route is via the web console. Open up a console session and test connectivity to the LAN Address assigned to the VPN gateway; in our case, it is 10.10.1.5/24. Hence, let us first test if we can ping this IP address:
Step 2: Configure the VPN route
The LAN host(s) must know where to route the return traffic. To accomplish this, we will add a route for the \`\`gb/ldn\`\` LAN subnet (10.10.2.0/24) via the \`de/txl\` gateway's LAN address (10.10.1.5):
```bash
ip route add 10.10.2.0/24 via 10.10.1.5
```
Currently, we cannot ping hosts in the `gb/ldn` region because those servers do not yet know how to route the return traffic. Continue adding routes for LAN hosts in `gb/ldn` to resolve this issue.
#### 6.2 Configure on-prem route
Step 1: Establish a console session to the LAN hosts
**Note:** Perform the configuration on the host acting as the user-managed gateway, as it already knows how to route based on the IPSec configuration. This section relates only to the other on-prem hosts connected to the same LAN.
Our only route now is via the web console because we did not provide internet access for the second LAN host in our on-prem setup. Open a console session and test connectivity to the LAN Address assigned to the VPN Gateway. In our case, this is 10.10.2.10/24 (that is, LAN Host 1, which is the user-managed gateway). Hence, let us first check if we can ping the IP address.
Step 2: Configure the VPN route
The LAN host(s) must know where to route return traffic. To accomplish this, we will add a route for the \`\`gb/ldn\`\` LAN subnet (10.10.2.0/24) via the \`\`de/txl\`\` Gateway's LAN address (10.10.1.10).
```bash
ip route add 10.10.1.0/24 via 10.10.2.10
```
Repeat this process for all on-prem LAN hosts that need to send or receive traffic over the tunnel. At this point, we should have full connectivity between the two sites via the VPN Gateway.
## Verify Connectivity
You should now be able to ping hosts in the simulated on-prem setup in `gb/ldn` from cloud hosts in `de/txl` and vice-versa.
## Summary
You have successfully configured a site-to-site VPN between the IONOS Cloud and your on-premise setup by utilising a Managed VPN Gateway in the cloud and a user-managed on-prem gateway.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.ionos.com/cloud/~/revisions/NfgM5VQuRjXRMfbR25yK/network-services/vpn-gateway/tutorials/ipsec-vdc-onprem.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.