Create an IPSec Tunnel between a VDC and On-Premises Gateway

overview this tutorial demonstrates configuring an ipsec site to site vpn gateway for secure and encrypted communications, establishing a connection between an vdc and a simulated user managed on premises installation it utilizes a managed vpn gateway in the and a user managed on premises gateway this tutorial demonstrates the use of the following components description two vdcs ionos cloud txl as 's vdc user on prem lhr simulates a user managed on premises setup managed gateways we use a single managed gateway in ionos cloud txl for the cloud side for a user managed gateway, we use on premises simulation, install the components, and manually configure ipsec on a virtual server to complete the setup target audience this tutorial is intended to help both developers and technical decision makers what you will learn by the end of this tutorial, you will be able to establish secure site to site connectivity, provision and configure a managed ipsec vpn gateway in , simulate an on premises gateway, and set up the tunnel parameters, including pre shared keys, lan subnets, and routing rules this process creates the secure tunnel and allows you to verify successful traffic flow between the cloud and on premises hosts before you begin the following information is necessary to set up an ipsec connection between a vdc and on premises vdc the following information is necessary to set up an ipsec connection between a vdc and on premises vdc components ionos cloud (left) ionos cloud txl user on premises (right) user on prem lhr vdc name ionos cloud txl user on prem lhr gateway public address 203 0 113 10 203 0 113 20 lan id 1 not applicable 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 note ensure that the (left) and user on premises (right) lan subnets are unique and do not overlap using the same subnet cidr in the (left) or user on premises (right) does not work in such a scenario, we recommend either of the following options move one of them to a different subnet add an additional network connection to lan hosts on one side using a unique subnet, and then route the unique subnet via the vpn gateway 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 https //docs ionos com/cloud/network services/vdc networking/how tos/ip addresses (left) ionos cloud txl gateway public address 203 0 113 10 user on premises (right) user on prem lhr gateway public address 203 0 113 20 configure lan this tutorial uses 192 168 1 0/24 and 192 168 2 0/24 for private lans in (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 ip address must be outside the dhcp pool and range from 2 9 components ionos cloud (left) ionos cloud txl user on premises (right) user on prem lhr lan id 1 not applicable 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 ```bash openssl rand base64 48 ``` ```bash head c 32 /dev/urandom | base64 ``` ```bash $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 the execution process is divided into the following steps simulate ionos cloud txl below are some screenshots from the dcd that contains the required vdcs to begin with, two virtual servers on the 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 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 provision the vpn gateway in the dcd , go to menu > network services > vpn gateway click create vpn gateway from the vpn gateways window enter the following details | 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 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 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 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 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= 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 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 this tab displays the child sa/ipsec sa settings (esp) settings 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 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 https //docs ionos com/cloud/tutorials/network services/vpn gateway/ipsec vdc onprem#63 configure routing for on premises lan hosts user on prem lhr 5 1 install pre requisite software note this tutorial performs a basic install and setup of strongswan on ubuntu it is neither an in depth guide nor does it contain 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 this tutorial does not use an ipv6 address if you intend to use one, ensure net ipv6 config all forwarding=1 exists 5 3 configure ipsec this tutorial will walk you 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 1 populate secrets file currently, ipsec supports only pre shared keys (psk), so ensure the /etc/ipsec secrets file contains the key, so ipsec can read it from the file 203 0 113 10 203 0 113 20 psk "vpabcdefg123435hij565k7lmno8pq=" 2 populate ipsec config file next, populate the /etc/ipsec conf file this file contains a basic config setup section and a conn section that defines the configuration of the remote tunnel for more information, see download vpn gateway configuration https //docs ionos com/cloud/network services/vpn gateway/dcd how tos/download config config setup charondebug=all uniqueids=yes conn ionos cloud de txl 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 3 enable and start the ipsec service run the following commands to start ipsec and ensure it also starts on boot systemctl enable ipsec systemctl start ipsec 4 verify status of the tunnel connection run the ipsec status command to check if the tunnel connection is established 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 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 lan hosts ionos cloud txl 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\@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 # step 2 configure the vpn route the lan host(s) must know where to route the traffic to accomplish this, we will add a route for the user on prem 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 user on prem lhr region because those servers do not yet know how to route the traffic to resolve this issue, continue adding routes for lan hosts in user on prem lhr 6 2 set persistent routes in the 6 1 configure routing for 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 persistent routes first, add the configuration to your system's appropriate network or routing configuration files to set persistent routes the exact method depends on your operating system the following examples show how to make a route persistent across reboots for debian, ubuntu, centos, and rhel debian/ubuntu you can add the route to any of the following the /etc/network/interfaces file in a specific file under /etc/network/ example /etc/network/interfaces d/ use the ip route command in a startup script example /etc/rc local example of /etc/network/interfaces {{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}} centos/rhel you can add the route in /etc/sysconfig/network scripts/route eth0 and adjust it according to the relevant interface example 192 168 2 0/24 via 192 168 1 5 save the configuration file changes and restart the network service to apply the changes 6 3 configure routing for on premises lan hosts user on prem lhr note configure the host acting as a user managed gateway, as it can already route traffic based on the ipsec configuration this section focuses solely on the other on premises hosts connected to the same lan step 1 establish a console session to the lan hosts the user managed gateway user on prem lhr is connected to the internet and can be used as a jump host to reach the on premises lan hosts from the user managed gateway, establish an ssh connection to the first lan host 192 168 2 11 , alternatively you may use the web console to login to the lan hosts you can test the connectivity to the lan address assigned to the user managed gateway vpn gateway user on prem lhr using a console session in this case, the user managed gateway address is 192 168 2 5 let us begin by attempting to ping this ip address 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 # step 2 configure the vpn route the lan host(s) must know where to route return traffic hence, we will add a route for the ionos cloud txl lan subnet 192 168 1 0/24 via the user on prem lhr user managed gateway's lan address 192 168 2 5 ip route add 192 168 1 0/24 via 192 168 2 5 repeat this process for all on premises lan hosts that need to send or receive traffic over the tunnel at this point, the two sites can establish complete connectivity via the vpn gateway final result after completing all steps, you will have a fully operational ipsec site to site vpn tunnel between your vdc ionos cloud txl and your simulated on premises environment user on prem lhr 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 both cloud and on premises lan hosts can securely communicate across the tunnel, with routing configured to allow seamless traffic flow between the two networks you can verify connectivity by successfully pinging hosts on either side, confirming encrypted and secure communication is established conclusion you have successfully configured a site to site vpn between the 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 note ensure you remove the vpn gateway before attempting to delete vms, lans, or the vdc