Azure Virtual Network Gateway Site-to-Site Connection to Amazon Web Services

Written by James McDonald

September 10, 2019

This is how I got a Site to Site (S2S) connection from an Azure Virtual Network to Amazon Web Services VPC running using a Ubuntu 18.04 LTS VM on AWS as a VPN Device

For the graphically inclined this is what we are doing except the on-premise bit is an AWS VPC

Firstly. I followed the information at this link =>

Now for the minutia

The SKU I chose for the Azure VNG was VpnGw1 although looking at the feature support this same setup could be done using the Basic SKU.

VM Types

For this setup I used

  • Azure testing instance: Standard B1ms (1 vcpus, 2 GiB memory)
  • Amazon EC2 Instance for VPN Device: t2.micro (1 vcpu, 1GiB ). You may have to increase this if you want to pump a lot of data through

What was the transfer performance with this setup?

Copying an 239M file between clouds took almost 10 seconds

IP Addressing

These are the IP ranges I used for the test Setup for Amazon and Azure. You just need to make sure the networks don’t overlap.

  • Azure V-Net Address Space:
  • Azure V-Net Subnet:
  • Azure Virtual Network Gateway Public IP:
  • Amazon VPC Address Space:
  • Amazon VPC Subnet:
  • Amazon VM Elastic IP: (this is the Azure Local Gateway IP)

I installed a Ubuntu 18.04 LTS image in the Amazon subnet as the VPN Device and it was auto assigned an Private IP address of

Note: I have used the VPC and V-Net address prefixes as the leftsubnet and rightsubnet values. This allows the tunnel to include any new subnets created in each of those supernet addresses. (you may want to be more explicit and specify the subnet only for greater control)

For the Azure Local Gateway configuration. You enter Elastic IP of the Amazon Ubuntu instance and the VPC Address Space

See the link for more instructions but the basic install is:

apt-get install strongswan

You also need to enable IP forwarding (check the link)

This was the working /etc/ipsec.conf file. Note the ike and esp proposal lines added

Note: Nothing worked until I added the ike= and esp= proposal values to /etc/ipsec.conf see below for the error message seen in /var/log/syslog

config setup
        # strictcrlpolicy=yes
        # uniqueids = no
conn azure

The only other change was to add authentication to the /etc/ipsec.secrets file

# 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. : PSK "caeb2d673de9e347ae68d68ac3515992"

Generate a Pre Shared Key

# this is just how I create a longish random string of letters and numbers
echo "You are the best person in the world charon" | md5sum
73e246ef03e75943bb99fece52209189  -

Problem – Will not connect

When I first finished configuring the connection the Azure portal connection status was stuck at “Connecting” instead of “Connected” as it should be as shown here

The Troubleshoots

When I first did ipsec start and the tunnel didn’t come up looking into /var/log/syslog I found the following. Note the received proposals inacceptable error message

Sep 10 02:53:36 ip-10-90-0-111 charon: 09[IKE] is initiating an IKE_SA
Sep 10 02:53:36 ip-10-90-0-111 charon: 09[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
Sep 10 02:53:36 ip-10-90-0-111 charon: 09[CFG] configured proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/AES_CMAC_96/HMAC_SHA1_96/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, IKE:AES_CCM_16_128/AES_CCM_16_192/AES_CCM_16_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/AES_CCM_12_128/AES_CCM_12_192/AES_CCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048
Sep 10 02:53:36 ip-10-90-0-111 charon: 09[IKE] local host is behind NAT, sending keep alives
Sep 10 02:53:36 ip-10-90-0-111 charon: 09[IKE] received proposals inacceptable
Sep 10 02:53:36 ip-10-90-0-111 charon: 09[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]

Basically everything Azure couldn’t agree strongswan about how they were going to encrypt things

However this site had a a mention of the correct ike= and esp= values to use. So I added them to the working configuration above.

How is the latency?

Ping times between the Azure and Amazon Virtual Networks ~4ms

Check to make sure that the ipsec service will start on boot

What does a successful connection look like?

This is what ipsec statusall looks like on a working connection

When connected and working the az-cli (Azure Command Line Interface) shows connectionStatus as “Connected” in it’s out put

If you turn off ipsec ( ipsec stop ) and wait a minute the Azure portal Status changes and az-cli reports “Connecting”

Once you stop the connection and try ipsec status and ipsec statusall nothing is returned. Start the connection again with ipsec start and run ipsec statusall to see the below output on a successful connection

How long for the connection to establish?

Once things are correct pretty much immediately but once you start the connection I found it takes a minute or so for the az-cli to report “Connected” again. You may need to navigate away and return to see the updated status in the portal.

What else?

Add Network Security Group rules to allow Echo Request ICMP to the VM NSG’s on both ends so you can test connectivity.

I didn’t need to change routing on the Azure side it all seems automatic.

AWS Gateway VPN Device Sending Spurious Redirects

My Gateway Device (Ubuntu VM) has been issuing ICMP redirects pointing clients back to the default gateway despite it having a tunnel to the Az network/s and not sure why. But connectivity still works. This is a fix of sorts

sysctl -w net.ipv4.conf.eth0.send_redirects=0


Submit a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.

You May Also Like…