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.

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

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.

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.

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

2. Simulate on-prem setup

3. Provision the VPN Gateway

4. Configure the VPN Tunnel

5. Deploy on-prem IPSec Instance

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.

Configuration on IONOS Cloud

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.

Configuration on your on-prem

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

Define Properties

3.2 Protocol

The IPSec protocol is selected by default and no other configuration parameters are required.

Select a Protocol

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

LAN Connections

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

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

Configure Tunnel Properties

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=

Configure PSK

4.3 Initial Exchange (IKE_SA_INIT) Settings

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.

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

Select a suitable algorithm

4.4 Child SA/IPSec SA Settings (ESP)

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.

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

Select a suitable algorithm

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

Configure network CIDRs

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

Deploy on-prem IPSec Instance

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:

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

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:

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.

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:

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.

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.

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.

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):

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

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.

Verify connectivity

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.