A VPN Gateway enables secure, encrypted communications between roaming users, on-premise networks, and cloud resources. This example demonstrates how users can configure the VPN Gateway product in IONOS Cloud to create an IPSec based site-to-site setup between two VDCs in different regions.
Overview
This tutorial demonstrates the use of the following:
Components
Description
Two VDCs
Provisioned in locations de/txl and gb/lhr respectively.
Managed gateways
We will use a managed IPSec instance to provide secure, encrypted connectivity between two VDCs in IONOS Cloud.
Before you begin
The following information is necessary to set up an IPSec connection between two VDCs:
VDC Left(de/txl)
VDC Right(gb/lhr)
Gateway Public Address
203.0.113.10
203.0.113.20
LAN ID
1
2
LAN Subnet
192.10.1.0/24
192.10.2.0/24
Gateway Lan Address
192.10.1.5
192.10.2.5
Pre-Shared Key
Remember to use the appropriate key.
Example:vPabcdefg123435hij565k7lmno8pq=
Reserve your IPs
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.
VDC Left(de/txl)
VDC Right(gb/lhr)
Gateway Public Adress
203.0.113.10
203.0.113.20
Configure LAN
This tutorial uses 10.10.1.0/24 and 10.10.2.0/24 for private LANs in the IONOS Cloud. 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.
VDC Left(de/txl)
VDC Right(gb/lhr)
LAN ID
1
2
LAN Subnet
192.10.1.0/24
192.10.2.0/24
Gateway Lan Address
192.10.1.5
192.10.2.5
Generate Pre-Shared Key (PSK)
Our current IPSec implementation supports PSK (which is expected to support certificates in the future). When provisioning gateways with DCD, 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
The execution process is divided into the following steps:
Setup VDCs
Provision the VPN Gateway
Configure the VPN tunnel
Configure routing on LAN hosts
1.Setup VDCs
Below are some screenshots from the DCD that contains the required VDCs.
1.1 VDC in de/txl
To begin with, two virtual servers are provisioned in the location de/txl and connected to each other via a private LAN. In this instance, LAN1 uses a custom subnet 192.10.1.0/24. We designate these two servers as 192.10.1.11 and 192.10.1.12, respectively.
1.2 VDC in gb/lhr
Similar to the de/txl VDC , two virtual servers are provisioned in gb/lhr and connected to each other via a private LAN. In this instance, LAN2 uses a custom subnet 192.10.2.0/24. We designate these two servers as 192.10.2.11 and 192.10.2.12, respectively.
2.Provision the VPN Gateways
This will need to be repeated for both sites, referring to the table of configuration parameters
In the DCD, go to Menu > Network > VPN Gateway under Connectivity.
Click Create VPN Gateway from the VPN Gateways window.
Enter the following details:
2.1 Properties
Complete the properties form before proceeding
Description
Example
Name
A descriptive name for the gateway instance, this does not need to be globally unique. Restricted to 255 characters.
vdc_to_vdc
Location
A dropdown of available locations for VPN Gateway.
de/txl
IP Address
A dropdown of available public IPv4 Addresses.
203.0.113.10
Description
More descriptive text for the gateway, limited to 1024 characters.
VPN Gateway for creating an IPSec Tunnel between a VDC and on-premises gateway.
2.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.
2.3 Protocol
The IPSec protocol is selected by default and no other configuration parameters are required.
2.4 LAN Connections
Attach a VPN Gateway to LANs in IONOS Cloud. Note that it is only possible to connect to LANs in the exact location where the VPN Gateway was provisioned. Let us look at the parameters required:
Components
Description
Example
Datacenter
Select a data center from the drop-down that lists VDCs in the same location as the gatweway.
de/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.10.1.5
IPv6 CIDR
The LAN IPv6 address assigned to the subnet's gateway in CIDR notation.
Not applicable
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.
Note: Repeat this process for the gb/lhr location to create a managed IPSec gateway there too using the parameters table to set the required properties correctly.
3.Configure the VPN Tunnels
Now that the VPN Gateway instance is provisioned, the 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 instances of the managed gateway.
Click Create Tunnels to begin configuring a new tunnel.
Configure the Tunnels for de\txl and gb\lhr, respectively.
3.1 de\txl Tunnel Configuration
Enter the following details to configure a tunnel:
Components
Description
Example
Tunnel Name
A name for the tunnel, this does not need to be globally unique and is limited to 255 characters.
ldn_tunnel
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.
203.0.113.20
Set the PSK as shown:
Components
Description
Example
Pre-Shared Key
A strong key, minimum of 32 characters
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 the purposes of the demonstration, the available options are aligned with BSI best practices. However, we will accept the default selections.
Item
Description
Example
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
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
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
Note: Both sites typically have the same ESP 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 ESP phase. For the purposes of the 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 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
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 cloud side that are permitted to connect to the tunnel.
192.10.2.0/24
3.2 gb\lhr Tunnel Configuration
Enter the following details to configure a tunnel:
Item
Description
Example
Tunnel Name
A name for the tunnel, this does not need to be globally unique and is limited to 255 characters.
txl_tunnel
Description
More descriptive text for the peer, limited to 1024 characters.
N/A
Remote Host
The Gateway Public IPv4 address of the remote VPN Gateway.
203.0.113.10
3.2 Authentication
This is where the Pre-shared key (PSK) is set.
Components
Description
Example
Pre-Shared Key
A strong key, minimum of 32 characters.
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 the purposes of the 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 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
Note: Both sites typically have the same ESP 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 ESP phase. For the purposes of the demonstration, the available options are aligned with BSI best practices. However, we will accept the default selections.
Components
Description
Example
Diffie-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
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.2.0/24
Peer Network CIDRs
Network addresses on the cloud side that are permitted to connect to the tunnel.
192.10.1.0/24
Click Save to save the tunnel configuration. This operation usually takes about one to two minutes to complete.
4.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.
4.1 Configure de/txl route
Step 1: Establish a console session to the LAN host(s)
To test connectivity for the LAN hosts without internet access, we will use the web console. 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/lhr 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/lhr 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/lhr.
4.2 Configure gb/lhr route
Step 1: Establish a console session to the LAN host(s)
To test connectivity for the LAN hosts without internet access, we will use the web console. Open a console session and ping the LAN address assigned to the VPN Gateway, 192.10.2.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 de/txl LAN subnet (192.10.1.0/24) via the gb/lhr gateway's LAN address (192.10.2.5):
ip route add 192.10.1.0/24 via 192.10.2.5
At this point, full connectivity between the two sites via the VPN Gateway is established.
Verify Connectivity
You should now be able to ping hosts in gb/lhr from hosts in de/txl.
Summary
You have successfully configured a site-to-site IPSec VPN between two IONOS Cloud VDCs using a Managed VPN Gateway .
Architecture depicts two IONOS Cloud VDCs connected over an IPSec tunnel
