Configure IPsec VPN (Gateway to Gateway) with Strongswan
👨💻
Strongswan supports Gateway-to-Gateway (site-to-site) and road warrior types of VPN. In the first type, network traffic is encrypted/decrypted on the gateway (entry/exit) of the enterprise. However, in the case of a road warrior, encrypted traffic from the end client (the machine) to the far end gateway.
In this article, we will explain the construction of a tunnel between two sites of an organization to secure the connection. The position of the Strongswan-based VPN server/gateway is shown in the following figure. We want to secure the connection between the 10.1.0.0/16 and 11.1.0.0/16 regulation networks.
As shown in the above figure, we are concerned with securing the connection from A to B and vice versa. It is important to ensure that files are routed Strongswan-based VPN Gateways in the organization’s network. We assume that the device from office A can ping the device in the network of office B. This will ensure that the devices in the network are connected.
Previously, we installed strongswan on the VM. However, in a production environment, strongswan is installed on devices for better performance. In this article, we are using a VM to demonstrate tunnel creation between two sites.
By default, the strongswan configuration is under /usr/local/etc/ The guide is shown in the following figure.
Gateway-to-Gateway tunnel (pre-shared key)
In this tunnel, we use the shared secret between two devices. These are the shared secrets that the Diffie-Hellman algorithm uses for mutual authentication before sharing the key for the symmetric encryption algorithm.
Stronswan Configuration on Local Machine (Left) (Side)
Ipsec.conf is the main configuration file for strongswan. In this file, we define policy parameters for the tunnel such as encryption algorithms, hash 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 = 1 hour lifetime = 8 hours dpddelay = 30 dpdtimeout = 120 dpdaction = authentication clear = automatic secret = start key exchange = ikev2 type = tunnel
ipsec.secrets file contains confidential information such as shared key, smart card PIN, private key password, etc. In our case, the pre-shared key between A and B is Sharedsecret
192.168.1.10 192.168.1.11: PSK “sharedsecret”
Configure Strongswan on the 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 = 1 hour lifetime = 8 hours dpddelay = 30 dpdtimeout = 120 dpdaction = authentication clear = automatic secret = start key exchange = ikev2 type = tunnel
and the contents of ipsec.secrets of the remote site
192.168.1.11 192.168.1.10: PSK “sharedsecret”
After changes on both sides, run the following command to create the tunnel.
# Restart ipsec
To check the tunnel status on both devices, run the following command in the device. The command output for the local and remote machine is shown below.
#ipsec statusall
ipsec statusall output on VM A
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.13.0-24-generic, x86_64):
Uptime: 8 minutes, since January 13 13:44:32 2015
malloc: sbrk 1351680, mmap 0, user 250048, free 1101632
worker threads: 11 of 16 idle, 5/0/0/0 running, working queue: 0/0/0/0, scheduled: 5
Loaded plugins: charon pkcs11 aes des rc2 sha1 sha2 md5 random nonce x509 uninstall restrictions pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-genetlink update default socket x resolving
Listen to IP addresses:
192.168.1.10
links:
Tunnel: 192.168.1.10 … 192.168.1.11 IKEv2, dpddelay = 30 seconds
Tunnel: Local: [192.168.1.10] Uses preshared key authentication
tunnel: far [192.168.1.11] Uses preshared key authentication
Tunnel: Child: 10.1.0.0/16 === 11.1.0.0/16 TUNNEL, dpdaction = clear
Security associations (1 up, 0 connected):
Subway[1]: Founded 8 minutes ago, 192.168.1.10[192.168.1.10]… 192.168.1.11[192.168.1.11]
Subway[1]: IKEv2 SPIs: cafdf24210e8e503_i*7ee6557a1d297e35_r Pre-shared key re-authentication in 25 minutes
Subway[1]: IKE Suggestion: 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, redial within 7 hours
Tunnel 1: 10.1.0.0/16 === 11.1.0.0/16
ipsec statusall output on VM B
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.13.0-24-generic, x86_64):
Uptime: 6 minutes, since January 13 13:44:21 2015
malloc: sbrk 1351680, mmap 0, user 250944, free 1100736
worker threads: 11 of 16 idle, 5/0/0/0 running, working queue: 0/0/0/0, scheduled: 8
Loaded plugins: charon pkcs11 aes des rc2 sha1 sha2 md5 random nonce x509 uninstall restrictions pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-genetlink update default socket x resolving
Listen to IP addresses:
192.168.1.11
links:
Tunnel: 192.168.1.11 … 192.168.1.10 IKEv2, dpddelay = 30 seconds
Tunnel: Local: [192.168.1.11] Uses preshared key authentication
tunnel: far [192.168.1.10] Uses preshared key authentication
Tunnel: Child: 11.1.0.0/16 === 10.1.0.0/16 TUNNEL, dpdaction = clear
Security associations (1 up, 0 connected):
Subway[3]: founded 6 minutes ago, 192.168.1.11[192.168.1.11]… 192.168.1.10[192.168.1.10]
Subway[3]: IKEv2 SPIs: cafdf24210e8e503_i 7ee6557a1d297e35_r * Pre-shared key re-authentication in 36 minutes
Subway[3]: IKE Suggestion: 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, redial within 7 hours
Tunnel 3: 11.1.0.0/16 === 10.1.0.0/16
The ip command can be used with the xfrm parameter to see ipsec tunneling policies and states in a Linux box. command output IP xfrm الدول countries On both devices is shown below.
Output the command ip xfrm state on virtual machine A.
SRC 192.168.1.10 192.168.1.11 DST Proto Spain SPI 0xc7243b49 reqid 1 tunnel mode window re-flag 32 AF-unspec Almsadegh- TRUNC HMAC (SHA256) 0x3077c888d622b899532a5f1b8e9399efe65684ffa694bf072ea4de8a44898b2f 128 ENC CBC (AES) 0x8fafb23d824c1e898dc42f6d59b14c52e6a33b2183c0c9c762de8cacfd355a6f SRC 192.168.1.11 192.168.1.10 DST Proto Spain SPI re Tunnel operation 0xcbd51ed8 reqid 1-window 32 flag af-unspec auth-trunc hmac (SHA256) 0x50b63121299e97339cf2a78bb86b958ae0c3e594b1c535a0a12ce0a165d4e0ef 128 enc cbc (aes)
Output the command ip xfrm state on virtual machine B.
SRC 192.168.1.11 192.168.1.10 DST Proto Spain SPI 0xcbd51ed8 reqid 3 tunnel mode 32 re-flag window AF-unspec Almsadegh- TRUNC HMAC (SHA256) 0x50b63121299e97339cf2a78bb86b958ae0c3e594b1c535a0a12ce0a165d4e0ef 128 ENC CBC (AES) 0x41447fea3021a3b13838f076dbe72139389be93960a641664bb7e1e6fc34b01a SRC 192.168.1.10 192.168.1.11 DST Proto Spain SPI re Tunnel Operation 0xc7243b49 reqid 3-window 32 flag af-unspec auth-trunc hmac (sha256)
As shown in the figure, the XFRM command displays sensitive information (keys). So please avoid such commands on a strong production server.
[ad_1]
Don’t forget to share this post with friends !
