Intro to Configure IPsec VPN (Gateway-to-Gateway ) using Strongswan

Strongswan supports Gateway-to-Gateway (site-to-site) and Road warrior  types of VPN. In first type, network traffic is encrypted/decrypted on the gateway (entrance/exit) of an organization. However in Road warrior case, traffic encrypted from the end client (machine) to remote end gateway. In this article, we will explain creation of  tunnel between two sites of an organization to secure the communication. Strongswan based VPN server/gateway placement is shown in the following figure. We want to secure communication between 10.1.0.0/16 and 11.1.0.0/16 networks of organization.

As shown in the above figure, we are interested to secure the communication from A to B and vice versa. It is important to make sure the routing ofStrongswan based VPN Gateways in the organization network. We assume that machine from  office A can ping a machine in the network of B office . This will ensure the connectivity of devices in the network.

In our previous we have installed the strongswan on the VM. However, in production environment, strongswan is installed on the hardware for the better performance.  In this article, we are using VM to show the tunnel creation between two sites.

By default, configuration of strongswan  are under /usr/local/etc/ directory which is shown in the following figure.

Gateway-to-Gateway tunnel (Pre shared key)

In this tunnel, we are using shared secret between two machine. This shared secrets used by Diffie-Hellman algorithm for mutual authentication before sharing key for symmetric encryption algorithm.

Configuration of Stronswan on Local (left) machine (A side)

ipsec.conf  is the main configuration file of strongswan. In this file, we define parameters of policy for tunnel such as encryption algorithms,hashing algorithm etc.

 config setup

charondebug="all"

uniqueids=yes

strictcrlpolicy=no

conn %default

conn tunnel #

left=192.168.1.10

leftsubnet=10.1.0.0/16

right=192.168.1.11

rightsubnet=11.1.0.0/16

ike=aes256-sha2_256-modp1024!

esp=aes256-sha2_256!

keyingtries=0

ikelifetime=1h

lifetime=8h

dpddelay=30

dpdtimeout=120

dpdaction=clear

authby=secret

auto=start

keyexchange=ikev2

type=tunnel

ipsec.secrets file contains the secret information such as shared key, smart cards pin and password of private key etc. In our case, pre shared key between A and B issharedsecret

192.168.1.10 192.168.1.11 : PSK 'sharedsecret'

 Configuration of Strongswan on Remote (Right) machine (B side)

config setup

charondebug="all"

uniqueids=yes

strictcrlpolicy=no

conn %default

conn tunnel #

left=192.168.1.11

leftsubnet=11.1.0.0/16

right=192.168.1.10

rightsubnet=10.1.0.0/16

ike=aes256-sha2_256-modp1024!

esp=aes256-sha2_256!

keyingtries=0

ikelifetime=1h

lifetime=8h

dpddelay=30

dpdtimeout=120

dpdaction=clear

authby=secret

auto=start

keyexchange=ikev2

type=tunnel

 

and the contents of ipsec.secrets of remote site are

192.168.1.11 192.168.1.10 : PSK 'sharedsecret'

After changes at both sides, run following command for tunnel creation.

# ipsec restart

To check the status of tunnel on both machines, run following command in the terminal. Output of the command for local and remote machine is shown below.

#ipsec statusall

Output of ipsec statusall on VM A

Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.13.0-24-generic, x86_64):

uptime: 8 minutes, since Jan 03 13:44:32 2015

malloc: sbrk 1351680, mmap 0, used 250048, free 1101632

worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5

loaded plugins: charon pkcs11 aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic

Listening IP addresses:

192.168.1.10

Connections:

     tunnel: 192.168.1.10...192.168.1.11 IKEv2, dpddelay=30s

      tunnel:   local: [192.168.1.10] uses pre-shared key authentication

     tunnel:   remote: [192.168.1.11] uses pre-shared key authentication

     tunnel:   child: 10.1.0.0/16 === 11.1.0.0/16 TUNNEL, dpdaction=clear

Security Associations (1 up, 0 connecting):

     tunnel[1]: ESTABLISHED 8 minutes ago, 192.168.1.10[192.168.1.10]...192.168.1.11[192.168.1.11]

     tunnel[1]: IKEv2 SPIs: cafdf24210e8e503_i* 7ee6557a1d297e35_r, pre-shared key reauthentication in 25 minutes

     tunnel[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024

     tunnel{1}: INSTALLED, TUNNEL, ESP SPIs: cbd51ed8_i c7243b49_o

     tunnel{1}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours

     tunnel{1}:   10.1.0.0/16 === 11.1.0.0/16

Output of ipsec statusall on VM B

Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.13.0-24-generic, x86_64):

uptime: 6 minutes, since Jan 03 13:44:21 2015

malloc: sbrk 1351680, mmap 0, used 250944, free 1100736

worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 8

loaded plugins: charon pkcs11 aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic

Listening IP addresses:

192.168.1.11

Connections:

     tunnel: 192.168.1.11...192.168.1.10 IKEv2, dpddelay=30s

     tunnel:   local: [192.168.1.11] uses pre-shared key authentication

     tunnel:   remote: [192.168.1.10] uses pre-shared key authentication

     tunnel:   child: 11.1.0.0/16 === 10.1.0.0/16 TUNNEL, dpdaction=clear

Security Associations (1 up, 0 connecting):

     tunnel[3]: ESTABLISHED 6 minutes ago, 192.168.1.11[192.168.1.11]...192.168.1.10[192.168.1.10]

     tunnel[3]: IKEv2 SPIs: cafdf24210e8e503_i 7ee6557a1d297e35_r*, pre-shared key reauthentication in 36 minutes

     tunnel[3]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024

     tunnel{3}: INSTALLED, TUNNEL, ESP SPIs: c7243b49_i cbd51ed8_o

     tunnel{3}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours

     tunnel{3}:   11.1.0.0/16 === 10.1.0.0/16

ip command with xfrm parameter can be used to see the policies and states of ipsec  tunnel on linux box. Output of  the command ip xfrm states on both devices is shown below.

Output of ip xfrm state command on VM A

src 192.168.1.10 dst 192.168.1.11

proto esp spi 0xc7243b49 reqid 1 mode tunnel

replay-window 32 flag af-unspec

auth-trunc hmac(sha256) 0x3077c888d622b899532a5f1b8e9399efe65684ffa694bf072ea4de8a44898b2f 128

enc cbc(aes) 0x8fafb23d824c1e898dc42f6d59b14c52e6a33b2183c0c9c762de8cacfd355a6f

src 192.168.1.11 dst 192.168.1.10

proto esp spi 0xcbd51ed8 reqid 1 mode tunnel

replay-window 32 flag af-unspec

auth-trunc hmac(sha256) 0x50b63121299e97339cf2a78bb86b958ae0c3e594b1c535a0a12ce0a165d4e0ef 128

enc cbc(aes) 0x41447fea3021a3b13838f076dbe72139389be93960a641664bb7e1e6fc34b01a

 

Output of ip xfrm state command on VM B

src 192.168.1.11 dst 192.168.1.10

proto esp spi 0xcbd51ed8 reqid 3 mode tunnel

replay-window 32 flag af-unspec

auth-trunc hmac(sha256) 0x50b63121299e97339cf2a78bb86b958ae0c3e594b1c535a0a12ce0a165d4e0ef 128

enc cbc(aes) 0x41447fea3021a3b13838f076dbe72139389be93960a641664bb7e1e6fc34b01a

src 192.168.1.10 dst 192.168.1.11

proto esp spi 0xc7243b49 reqid 3 mode tunnel

replay-window 32 flag af-unspec

auth-trunc hmac(sha256) 0x3077c888d622b899532a5f1b8e9399efe65684ffa694bf072ea4de8a44898b2f 128

enc cbc(aes) 0x8fafb23d824c1e898dc42f6d59b14c52e6a33b2183c0c9c762de8cacfd355a6f

 

As shown in the figure, XFRM command is showing sensitive information (keys). So please avoid such commands on the production strongswan server.