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:

Before you begin

The following information is necessary to set up an IPSec connection between a VDC and on-premises VDC:

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.

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.

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:

openssl rand -base64 48 

head -c 32 /dev/urandom | base64

$b = New-Object byte[] 32; (New-Object System.Security.Cryptography.RNGCryptoServiceProvider).GetBytes($b); [System.Convert]::ToBase64String($b) | 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 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.

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

3. 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:

Properties

VPN Tier

Protocol

LAN Connections

Maintenance Window

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

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.

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

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

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

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.

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.

Properties

Authentication

Initial Exchange (IKE_SA_INIT) Settings

Child SA/IPSec SA Settings (ESP)

Network CIDRs

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

Set the PSK as shown:

Components

Description

Example

Pre-Shared Key

Enter a strong key that is at least 32 characters long.

vPabcdefg123435hij565k7lmno8pq=

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

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

Configure the subnets in CIDR format, which are permitted to connect to the tunnel.

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.

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

2. 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, 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.

apt-get update
apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins libtss2-tcti-tabrmd0 -y

sysctl -w net.ipv4.ip_forward=1

203.0.113.10 203.0.113.20 : PSK "vPabcdefg123435hij565k7lmno8pq="

config setup
    charondebug=all
    uniqueids=yes
 
conn ionos-cloud-de-txl-demo
    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

systemctl enable ipsec
systemctl start ipsec

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

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 routing for IONOS Cloud LAN hosts ionos-cloud-txl

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:~#

ip route add 192.168.2.0/24 via 192.168.1.5

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.

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

6.3 Configure routing for on-premises LAN hosts user-on-prem-lhr

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:~#

ip route add 192.168.1.0/24 via 192.168.2.5

Verify connectivity

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.

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:~# 

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:~#

Summary

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.