Create an IPSec Tunnel between two VDCs

this tutorial demonstrates how users can configure the vpn gateway product in to create an ipsec based site to site setup between two vdcs in different regions this tutorial demonstrates the use of the following components description two vdcs provisioned in locations berlin ionos cloud txl and london ionos cloud lhr respectively managed gateways we will use a managed ipsec instance to provide secure, encrypted connectivity between two vdcs in target audience this tutorial is intended to help both developers and technical decision makers what you will learn by following this tutorial, you will learn how to provision managed ipsec vpn gateways in across different regions configure site to site ipsec tunnels between two vdcs generate and use secure pre shared keys for authentication set up lan subnets and assign gateway addresses configure tunnel parameters including encryption, integrity, and network cidrs manually add routing rules to enable traffic between vdcs verify secure connectivity between hosts in separate vdcs before you begin the following information is necessary to set up an ipsec connection between two vdcs components berlin vpn ionos cloud txl london vpn ionos cloud lhr vdc name ionos cloud txl ionos cloud lhr gateway public address 203 0 113 10 203 0 113 20 lan id 1 2 lan subnet 192 168 1 0/24 192 168 2 0/24 gateway lan address 192 168 1 5 192 168 2 5 lan host 1 192 168 1 11 192 168 2 11 lan host 2 192 168 1 12 192 168 2 12 pre shared key remember to use the appropriate key example vpabcdefg123435hij565k7lmno8pq= this is a sample key used as an example in this document do not use this key for real world scenarios 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 https //docs ionos com/cloud/network services/vdc networking/how tos/ip addresses components berlin vpn ionos cloud txl london vpn ionos cloud lhr gateway public address 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 space vars 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 components berlin vpn ionos cloud txl london vpn ionos cloud lhr lan id 1 2 lan subnet 192 168 1 0/24 192 168 2 0/24 gateway lan address 192 168 1 5 192 168 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, ensure you generate a psk at least 32 characters long optionally, you can also generate a psk while creating an ipsec tunnel https //docs ionos com/cloud/network services/vpn gateway/dcd how tos/create peer tunnel the following commands explain how to generate psk for linux and windows, respectively execute either of these commands openssl rand base64 48 or 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 procedure setup vdcs below are some screenshots from the dcd that contains the required vdcs 1 vdc in ionos cloud txl to begin with, two virtual servers are provisioned in the location ionos cloud txl and connected to each other via a private lan in this instance, lan1 uses a custom subnet 192 168 1 0/24 we designate these two servers as 192 168 1 11 and 192 168 1 12 , respectively 2 vdc in ionos cloud lhr similar to the ionos cloud txl vdc, two virtual servers are provisioned in ionos cloud lhr and connected to each other via a private lan in this instance, lan2 uses a custom subnet 192 168 2 0/24 we designate these two servers as 192 168 2 11 and 192 168 2 12 , respectively provision the vpn gateways this will need to be repeated for both sites, referring to the table of configuration parameters 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 enter the following before proceeding components 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 list of available locations for vpn gateway configuration ionos cloud txl ip address a list 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 vdcs note you can only upgrade the tier or switch between high availability (ha) and non ha variants during editing 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 the ipsec protocol is selected by default and no other configuration parameters are required attach a vpn gateway to lans in space vars 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 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 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 ionos cloud lhr location to create a managed ipsec gateway there too using the parameters table to set the required properties correctly 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 1 click create tunnels to begin configuring a new tunnel 2 configure the tunnels for ionos cloud txl and ionos cloud lhr , respectively a ionos cloud 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 lhr 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= this tab displays the 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 the purposes of the demonstration, the available options are aligned with bsi best practices however, we will accept the default selections components 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 this tab displays the child sa/ipsec sa settings (esp) settings 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 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 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 168 1 0/24 peer network cidrs network addresses on the peer side that are permitted to connect to the tunnel 192 168 2 0/24 b ionos cloud lhr 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 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= this tab displays the 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 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 this tab displays the child sa/ipsec sa settings (esp) settings 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 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 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 168 2 0/24 peer network cidrs network addresses on the peer side that are permitted to connect to the tunnel 192 168 1 0/24 3 click save to save the tunnel configuration this operation usually takes about one to two minutes to complete 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 1 configure ionos cloud 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 168 1 5 begin by pinging the ip address root\@berlinlanhost1 # 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\@berlinlanhost1 # 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 ionos cloud lhr lan subnet 192 168 2 0/24 via the ionos cloud txl gateway's lan address 192 168 1 5 ip route add 192 168 2 0/24 via 192 168 1 5 we cannot ping hosts in the ionos cloud 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 ionos cloud lhr 2 configure ionos cloud lhr 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 that does not have an internet access open a console session and ping the lan address assigned to the vpn gateway, 192 168 2 5 begin by pinging the ip address root\@berlinlanhost1 # ping c 3 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=64 time=1 34 ms 64 bytes from 192 168 2 5 icmp seq=2 ttl=64 time=0 429 ms 64 bytes from 192 168 2 5 icmp seq=3 ttl=64 time=0 377 ms \ 192 168 2 5 ping statistics 3 packets transmitted, 3 received, 0% packet loss, time 2019ms rtt min/avg/max/mdev = 0 377/0 715/1 340/0 442 ms root\@berlinlanhost1 # 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 ionos cloud txl lan subnet 192 168 1 0/24 via the ionos cloud lhr gateway's lan address 192 168 2 5 ip route add 192 168 1 0/24 via 192 168 2 5 at this point, full connectivity between the two sites via the vpn gateway is established final result you should now be able to ping from hosts in ionos cloud txl to hosts in ionos cloud lhr conclusion you have successfully configured a site to site ipsec vpn between two vdcs using a managed vpn gateway