Strongswan IPSec (Including Cryptomap) to Microsoft Azure Virtual Network Gateway

We recently had to get a VPS Ubuntu server communicating through a Virtual Network Gateway (read IPSec concentrator) on Azure. We followed the documentation and examples we could find and lets just say they didn’t show the whole picture in a concise and clear way and it seemed to be slightly different than what we were seeing.

Azure IPSec Crypto Bit

For instance the documentation gave a specific set of crypto we could use for the IKE and Phase 2, but it wasn’t quite working as quickly as we wanted our tunnels to come up quickly with the absolute minimum of time based overhead.

From our logs we checked what the Virtual Network Gateway was reporting for IKE and this was the response (carriage returns added by me for clarity):

Mar 15 20:17:47 [ubuntu-webserver] charon: 08[CFG] received proposals: 
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, 
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024

Next we checked what we would use for the ESP (carriage returns added by me for clarity):

Mar 15 20:18:47 [ubuntu-webserver] charon: 13[CFG] received proposals: 
ESP:AES_GCM_16_256/NO_EXT_SEQ, 
ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, 
ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, 
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, 
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, 
ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ

Interesting Microsoft are allowing you to use the deprecated (but hugely interoperable) Triple-DES, we shan’t be using that one in production. But we did find an exciting mention of AES GCM!

From here we tried to align what we could do with Suite B and came up with the following as probably the best and most secure as we could do for both responder and initiator.

conn azure-policy-vpn
    # Azure Virtual Network Gateway IPsec crypto map
    # 3DES SHA1 is supported on Azure but is deprecated, not included in this config
    # https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices
    keyexchange=ikev1
    authby=psk
    ike=aes256-sha2_256-modp1024,aes256-sha1-modp1024,aes128-sha1-modp1024!
    ikelifetime=8h
    esp=aes256gcm16,aes256-sha2_256,aes256-sha1-modp2048,aes256-sha1,aes128-sha1!
    lifebytes=102400000000
    lifetime=1h

Strongswan to Azure IPSec.conf Bit

We had a setup like the following:

• Ubuntu Webserver – 1.1.1.1
• Azure Virtual Network Gateway – 2.2.2.2
• SQL Server on Azure Virtual Network – 172.16.202.4

We needed to get the Ubuntu webserver talking to the SQL backend and we didn’t want to open ports on the internet for this to happen, so IPSec was a perfect method to fix it!

Our whole ipsec.conf looks like this and please note the “conn vps-to-azure” section needs the code block above “azure-policy-vpn” but there’s no reason why you can’t copy and past the appropriate lines into this connection block.

conn vps-to-azure
    also=azure-policy-vpn
    auto=route
    left=1.1.1.1   #IP of the VPS
    right=2.2.2.2  #IP of the Azure Network Gateway
    rightsubnet=172.16.201.0/24 #IP range behind the gateway
    type=tunnel

For our ipsec.secrets file we had something like this:

# This file holds shared secrets or RSA private keys for authentication.
# RSA private key for this host, authenticating it to any other host
# which knows the public part.
1.1.1.1 2.2.2.2 : PSK "YourPSKHere!"

And up the tunnel came with some decent encryption:

root@ubuntu-webserver:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.15.0-46-generic, x86_64):
uptime: 28 minutes, since Mar 15 20:29:56 2019
malloc: sbrk 2568192, mmap 0, used 665648, free 1902544
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
[ubuntu-webserver-ip]
Connections:
vps-to-azure: [ubuntu-webserver-ip]...[azure-virtual-network-gateway-ip] IKEv2
vps-to-azure: local: [[ubuntu-webserver-ip]] uses pre-shared key authentication
vps-to-azure: remote: [[azure-virtual-network-gateway-ip]] uses pre-shared key authentication
vps-to-azure: child: dynamic === 172.16.201.0/24 TUNNEL
Routed Connections:
vps-to-azure{1}: ROUTED, TUNNEL, reqid 1
vps-to-azure{1}: [ubuntu-webserver-ip]/32 === 172.16.201.0/24
Security Associations (1 up, 0 connecting):
vps-to-azure[1]: ESTABLISHED 28 minutes ago, [ubuntu-webserver-ip][[ubuntu-webserver-ip]]...[azure-virtual-network-gateway-ip][[azure-virtual-network-gateway-ip]]
vps-to-azure[1]: IKEv2 SPIs: 61a48c61ae1dc398_i* 08fa3d4c8022e22e_r, pre-shared key reauthentication in 7 hours
vps-to-azure[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
vps-to-azure{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: ce143694_i fe440272_o
vps-to-azure{2}: AES_GCM_16_256, 14117 bytes_i (111 pkts, 4s ago), 9337 bytes_o (83 pkts, 4s ago), rekeying in 16 minutes
vps-to-azure{2}: [ubuntu-webserver-ip]/32 === 172.16.201.0/24

Our “Local Network Gateway” configured in Azure was literally the IP address of our VPS with the address space of the same IP as a slash 32.