> ## Content Index > Fetch the complete content index at: https://www.bagz.fr/llms.txt > Use this file to discover other available public pages before exploring further. # How to setup an IPSec tunnel with Strongswan with high-availability on Linux - URL: https://www.bagz.fr/how-to-setup-an-ipsec-tunnel-with-strongswan-with-high-availability-on-linux/ - Published: 2015-02-27T11:15:50.000Z - Updated: 2015-02-27T11:15:50.000Z - Author: bgazui - Tags: Linux, #Migrated-1790668826633, #wp, #wp-post, #Import 2026-09-29 08:00 It is possible to secure your communication between several sites (datacenters for example) by using an open-source VPN IPSec on your Linux System. We will see here how to: 1. Set-up a VPN IPSec on Linux with Strongswan () 2. Set-up a high availability mechanism on top of this VPN connection to ensure the link will always be up with KeepAlived () #### Architecture Here is the architecture example I will use in this post. - **\- - -** represents a local link - **\===** represents a VPN link 192.168.50.0/24 - - - 192.168.100.1 === 192.168.100.2 - - - 10.0.0.0/16 #### VPN Installation First of all, install the package **strongswan** using the package manager you used to, or by compiling it from sources. In the same time, install the **keepalived** package to be able to set it highly available at the end of this post.$apt-get install strongswan keepalivedThis will install the packages and the libraries needed to make them work. #### Certificates First thing to do will be to generate certificates used for the encryption of communication within the VPN. This can be done in two ways: - Using CLI with **StrongSwan's PKI Tool** () - Using a GUI tool to manage certificates like **XCA** () #### CA Certificate Once the packages are properly installed, we will have to create the different certificates that we will use to encrypt our connection between peers. For the example we will be using self-signed certificate here. The first certificate to generate wil be the CA certificate with which one we will sign any certificate we want to use in the VPN network. Generate a 2048 bit RSA private key (*caKey.der*) for the CA certificate (*caCert.der*) and self-sign it with this key: $ipsec pki --gen > caKey.der $ipsec pki --self --in caKey.der --dn "C=FR, O=myCompany, CN=myCompany CA" --ca > caCert.der #### End Entity Certificate For each peer (i.e. each gateway), a private key (**peerKey.der**) and a certificate (**peerCert.der**) will have to be generated using the CA previously created:$ipsec pki --gen > peerKey.der $ipsec pki --pub --in peerKey.der | ipsec pki --issue --cacert caCert.der --cakey caKey.der --dn "C=FR, O=myCompany, CN=vpn-peer1" > peerCert.der #### Install certificates On each peer, store the following certficates and private keys in **/etc/ipsec.d/** subdirectory as: - **/etc/ipsec.d/private/peerKey.der** for the private key of the peer - **/etc/ipsec.d/certs/peerCert.der** for the certificate of the peer - **/etc/ipsec.d/cacerts/caCert.der** for the CA certificate that signed the certificates The CA private key (**caKey.der**) should never be stored on a server directly reachable from the Internet and be kept safe. #### IPSec configuration To configure IPSec, you will have to configure two files: - **/etc/ipsec.conf** for the configuration of your tunnels - **/etc/ipsec.secrets** for the configuration of your keys and/or PSK (pre-shared keys) If you use certificate for your connection, here is what your configuration should look like:#/etc/ipsec.conf \# ipsec.conf - strongSwan IPsec configuration file config setup conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 keyexchange=ikev2 mobike=no conn peer1-peer2 left=192.168.100.1 leftcert=peerCert.der leftid="C=FR O=myOrganisation, CN=vpn-peer1" leftsubnet=192.168.50.0/24 leftfirewall=yes right=192.168.100.2 rightid="C=FR, O=myOrganisation, CN=vpn-peer2" rightsubnet=10.0.0.0/16 auto=start closeaction=restart #/etc/ipsec.secrets \# This file holds shared secrets or RSA private keys for authentication. : RSA peerKey.der If instead of using certificates you prefered to use Pre-Shared Key (as you will have to if you want to connect to AWS VPN Services), here are how should be configured both files: #/etc/ipsec.conf \# ipsec.conf - strongSwan IPsec configuration file config setup conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 authby=secret keyexchange=ikev2 mobike=no conn peer1-peer2 left=192.168.100.1 leftid=@vpn-peer-1 leftsubnet=192.168.50.0/24 leftfirewall=yes right=192.168.100.2 rightsubnet=10.0.0.0/16 auto=start#/etc/ipsec.secrets \# This file holds shared secrets or RSA private keys for authentication. @vpn-peer-1 @vpn-peer-2 : PSK "poiuYTREzaQSdfGhJKlmNbvCxw" #### IPsec commands and monitoring First of all, each time you are changing part of the configuration, it's strongly advised to reload configuration by doing:$ipsec restartOnce this done, you can easily up/down a configuration by using:$ipsec up peer1-peer2 $ipsec down peer1-peer2A last command very useful is "*statusall*" that allows you to check and monitor VPN links:$ipsec statusall Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-45-generic, x86\_64): uptime: 7 hours, since Feb 15 23:25:20 2015 malloc: sbrk 1486848, mmap 0, used 407360, free 1079488 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 6 loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity addrblock Listening IP addresses: 192.168.100.1 Connections: peer1-peer2: 192.168.100.1...192.168.100.2 IKEv2 peer1-peer2: local: \[C=FR, O=myOrganisation, CN=vpn-peer1\] uses public key authentication peer1-peer2: cert: "C=FR, O=myOrganisation, CN=vpn-peer1" peer1-peer2: remote: \[C=FR, O=myOrganisation, CN=vpn-peer2\] uses public key authentication peer1-peer2: child: 192.168.50.0/24 === 10.0.0.0/16 TUNNEL Security Associations (1 up, 0 connecting): peer1-peer2\[25\]: ESTABLISHED 2 minutes ago, 192.168.100.1\[C=FR, O=myOrganisation, CN=vpn-peer1\]...192.168.100.2\[C=FR, O=myOrganisation, CN=vpn-peer2\] peer1-peer2\[25\]: IKEv2 SPIs: 9f7e598d22e98081\_i 003d60cae30e9548\_r\*, public key reauthentication in 52 minutes peer1-peer2\[25\]: IKE proposal: AES\_CBC\_128/HMAC\_SHA1\_96/PRF\_HMAC\_SHA1/MODP\_2048 peer1-peer2{23}: INSTALLED, TUNNEL, ESP SPIs: cc8513e9\_i c729b4f7\_o peer1-peer2{23}: AES\_CBC\_128/HMAC\_SHA1\_96, 0 bytes\_i, 0 bytes\_o, rekeying in 12 minutes peer1-peer2{23}: 192.168.50.0/24 === 10.0.0.0/16 #### High availability configuration So that your VPN can be highly available, you will need to configure **keepalived** that you just installed at the beginning. You will have to configure it on both sides by using a virtual IP and a script to automate the restart on both nodes depending on the state of the cluster (option "notify"). Here is the configuration for the master server: ! Configuration File for keepalived vrrp\_instance VI\_1 { state MASTER interface eth0 virtual\_router\_id 51 priority 150 advert\_int 1 authentication { auth\_type PASS auth\_pass $ place secure password here. } virtual\_ipaddress { 192.168.100.1 } notify /opt/notifyipsec.sh } The configuration for the slave (backup) server is almost similar but *state* and *priority* are changing: ! Configuration File for keepalived vrrp\_instance VI\_1 { state BACKUP interface eth0 virtual\_router\_id 51 priority 100 advert\_int 1 authentication { auth\_type PASS auth\_pass $ place secure password here. } virtual\_ipaddress { 192.168.100.1 } notify /opt/notifyipsec.sh } And here is the script **notifyipsec.sh** for the "notify" option: #!/bin/bash TYPE=$1 NAME=$2 STATE=$3 case $STATE in "MASTER") ipsec restart exit 0 ;; "BACKUP") ipsec stop exit 0 ;; "FAULT") ipsec stop exit 0 ;; \*) echo "unknown state" exit 1 ;; esac Now you can restart both services and your IPSec VPN inter-site is ready with a high-availability mechanism enabled!! Obviously, you will have to do the same on the other node if you want your VPN to work properly, by reversing configuration.