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

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

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

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

In the DCD, go to Menu > Network > VPN Gateway under Connectivity.
Click Create VPN Gateway from the VPN Gateways window.
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

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

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.

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

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

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

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

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

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:

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:

Configure de/txl Route

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.

Configure on-prem route

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.

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.

PreviousTutorials NextFAQs

Last updated 2 months ago

Was this helpful?

Introduction

Overview

Before you begin

Reserve your IPs

Configure LAN

Generate Pre-shared key (PSK)

Execution

1. Set Up IONOS Cloud

1.1 Simulate de/txl

2. Simulate on-prem setup

3. Provision the VPN Gateway

3.1 Properties

3.2 Protocol

3.3 LAN Connections

4. Configure the VPN Tunnel

4.1 Properties

4.2 Authentication

4.3 Initial Exchange (IKE_SA_INIT) Settings

4.4 Child SA/IPSec SA Settings (ESP)

4.5. Network CIDRs

5. Deploy on-prem IPSec Instance

6. Configure routing on LAN hosts

6.1 Configure de/txl Route

6.2 Configure on-prem route

Verify Connectivity

Summary

6.1 Configure `de/txl` Route