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 of Strongswan 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 is sharedsecret
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.
The post Intro to Configure IPsec VPN (Gateway-to-Gateway ) using Strongswan appeared first on LinOxide.