Create an IPSec Tunnel between a VDC and On-Premises Gateway

Introduction

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.

Overview

This tutorial demonstrates the use of the following:

Components	Description
Two VDCs	- de/txl as IONOS's VDC. - gb/ldn simulates a user-managed on-premises setup.
Managed gateways	We use a single managed gateway in de/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.

Architecture depicts IONOS Cloud and on-premises simulation connected over an IPSec tunnel

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) (de/txl)	User On-Premises (Right) (gb/ldn)
Gateway Public Address	203.0.113.10	203.0.113.20
LAN ID	1	Not applicable
LAN Subnet	192.10.1.0/24	192.10.2.0/24
Gateway LAN Address	192.10.1.5	192.10.2.2
Pre-Shared Key	Remember to use the appropriate key.	Example: vPabcdefg123435hij565k7lmno8pq=

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.

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.

IONOS Cloud (Left) (de/txl) Gateway Public Address	User On-Premises (Right) (gb/ldn) Gateway Public Address
203.0.113.10	203.0.113.20

Configure LAN

This tutorial uses 192.10.1.0/24 and 192.10.2.0/24 for private LANs in IONOS Cloud (Left) and User On-Premises (Right) 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 to .9.

Components	IONOS Cloud (Left) (de/txl)	User On-Premises (Right) (gb/ldn)
LAN ID	1	Not applicable
LAN Subnet	192.10.1.0/24	192.10.2.0/24
Gateway LAN Address	192.10.1.5	192.10.2.2

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. The following commands explain how to generate PSK for Linux and Windows, respectively:

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. Simulate IONOS Cloud

2. Simulate on-premises setup

3. Provision the VPN Gateway

4. Configure the VPN tunnel

5. Deploy on-premises IPSec instance

6. Configure routing on LAN hosts

1. Simulate IONOS Cloud

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.10.1.0/24. We designate these two servers as 192.10.1.10 and 192.10.1.11, respectively.

Configuration on IONOS Cloud

2. Simulate on-premises setup

Imagine the gb/ldn VDC as a user-managed site where you provision two virtual servers. Here, we will use the subnet 192.10.2.0/24. Host 1 has been configured with internet access (IP address: 203.0.113.20) and will function as the on-premises host acting as a user-managed gateway. We address these two servers as 192.10.2.2 and 192.10.2.3, respectively.

Configuration on a user-managed on-premises setup

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	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.
IP Address	Select an IP address from the drop-down list of available public IPv4 addresses.	203.0.113.10
Location	Select a location from the drop-down list of available locations for VPN Gateway.	de/txl
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

Define properties

3.2 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.

Note: You can only upgrade the tier or switch between High Availability (HA) and non-HA variants during editing.

Select a tier

3.3 Protocol

The IPSec protocol is selected by default, and no additional configuration parameters are necessary.

Select a protocol

3.4 LAN Connections

Attach a VPN Gateway to LANs in IONOS Cloud. 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.	Berlin VPN
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.10.1.5
IPv6 CIDR	The LAN IPv6 address assigned to the subnet's gateway in CIDR notation.	Not applicable

LAN connections

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

4. 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.

Configure a 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 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

Configure tunnel properties

4.2 Authentication

Set the PSK as shown:

Components	Description	Example
Pre-Shared Key	Enter a strong key that is at least 32 characters long.	vPabcdefg123435hij565k7lmno8pq=

Configure PSK

4.3 Initial Exchange (IKE_SA_INIT) Settings

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.

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

Select a suitable algorithm

4.4 Child SA/IPSec SA Settings (ESP)

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.

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

Select a suitable algorithm

4.5. Network CIDRs

Configure the subnets in CIDR format, which 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.	192.10.1.0/24
Peer Network CIDRs	Network addresses on the peer or remote side that are permitted to connect to the tunnel.	192.10.2.0/24

Configure network CIDRs

1. Click Save to save the tunnel configuration. This operation usually takes about one to two minutes to complete.

5. Deploy on-premises IPSec instance

In this tutorial, Host 1 in gb/ldn acts as a user-managed gateway. The host has internet access, so SSH can be used instead of the web console. Start establishing an SSH connection to Host 1's public IPv4 address in London.

Deploy on-premises IPSec instance

5.1 Install pre-requisite software

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.

Update the package lists and install the required packages:

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:

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:

203.0.113.10 203.0.113.20 : PSK "vPabcdefg123435hij565k7lmno8pq="

2. Populate IPSec config file

Next, populate the /etc/ipsec/ipsec.conf file. This file contains a basic config setup section and a conn section that defines the configuration of the remote tunnel.

config setup
    charondebug=all
    uniqueids=yes
 
conn ionos-cloud-de-txl-demo
    type=tunnel
    auto=start
    keyexchange=ikev2
    authby=secret
    left=203.0.113.20
    leftsubnet=192.10.2.0/24
    right=203.0.113.10
    rightsubnet=192.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

3. Enable and start the IPSec service

Run the following commands to start IPSec and ensure it also starts on boot:

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.

root@london-lan-host-1:/etc# 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.10.2.0/24 === 192.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 the VDCs.

6.1 Configure de/txl route

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.10.1.5. Begin by pinging the 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 (192.10.2.0/24) via the de/txl gateway's LAN address (192.10.1.5):

ip route add 192.10.2.0/24 via 192.10.1.5

We cannot ping hosts in the gb/ldn region because those servers do not yet know how to route the return traffic. To resolve this issue, continue adding routes for LAN hosts in gb/ldn.

6.2 Set persistent routes

In the 6.1 Configure de/txl route 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:

 
{{auto eth0 

iface eth0 inet static 

address 10.10.1.10 

netmask 255.255.255.0 

post-up ip route add 10.10.2.0/24 via 10.10.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: 10.10.2.0/24 via 10.10.1.5.

Save the configuration file changes and restart the network service to apply the changes.

6.3 Configure on-premises route

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.

Step 1: Establish a console session to the LAN hosts

Currently, the only way to access the system is through the web console, as we did not provide internet access for the second LAN host in our on-premises setup. First, open a console session and test the connectivity to the LAN address assigned to the VPN Gateway. In this case, the address is 192.10.2.2 (which corresponds to LAN Host 1, the user-managed gateway). Let us begin by attempting to ping this IP address.

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 de/txl LAN subnet (192.10.1.0/24) via the gb/ldn user-managed gateway's LAN address (192.10.2.2).

ip route add 192.10.1.0/24 via 192.10.2.2

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 must establish complete connectivity via the VPN Gateway.

Verify connectivity

You should now be able to ping hosts in the simulated on-premises setup in gb/ldn from cloud hosts in de/txl and vice-versa.

Verify connectivity

Summary

You have successfully configured a site-to-site VPN between the IONOS Cloud and a user-managed on-premises setup by utilizing a Managed VPN Gateway in the cloud and a user-managed on-premises gateway.

Note: Ensure you remove the VPN Gateway before attempting to delete VMs, LANs, or the VDC.