Goal:
establish a VPN connection between an Azure VNET and an AWS VPC
Topology
AWS side:
- Virtual Private Cloud (VPC) / VPC Address Range : 172.31.0.0/16
- Virtual Private Gateway (VPG)
- Customer Gateway
- Site to Site VPN Connection
- EC2 Instance / Windows Server 2019
Azure side:
- Virtual Network (Vnet) / Vnet Address Space : 10.0.0.0/16
- Virtual Network Gateway
- Local Network Gateway
- Site to Site VPN Connection
- VM Instance / Windows Server 2019
Steps:
On Azure Side
- create you Virtual Network, choose an Address Space, a default Subnet and while you are there , also create a Subnet named “Gateway Subnet” which is necessary for the VPN Gateway.
- Next, create or make sure you have a Virtual Network Gateway in your Azure Subscription. This needs to be a Route-based VPN Gateway connected to your Virtual Network. It will take between 30 minutes and an hour, so you have time to look at the AWS side.
The same needs to be done on AWS side.
- Therefore, define a VPC and a address space of your choice. (“VPCs > Create VPC”)
- You don t need to define a Gateway Subnet in this case.
- Next create a Virtual Private Gateway (“Virtual Private Gateways > Create Virtual Private Gateway”). The creation process is almost instant.
- After creation, new VPG needs to be attached to your VPC ( “Virtual Private Gateways > Attach to VPC”). Again, the process is here very quick, as it takes just a couple of minutes for the gateway to show up as “attached”, therefore much quicker than the same steps on the Azure side.
- At this moment, you need the Azure Virtual Network Public IP information, so grab that from the Azure side once the Azure Gateway is available.
- You need it, because now you can create its corresponding element on the AWS side, meaning you need to create a Customer Gateway (“Customer Gateways > Create Customer Gateway”)
- Once this is created, we can configure the connection towards Azure from AWS side.
- Go to “Virtual Private Networks – Site to Site VPN Connections”, give the connection a name, select the Virtual Private Gateway as Gateway Type, check the AWS VPG and the newly created Customer Gateway, select “Static” under Routing Options and enter the Address Space of your Azure Vnet to which you want your AWS originating Traffic to be routed towards.
- As a next step, click on “Download Configuration”, leave the Vendor as “Generic” and click on “Download”.
- Look into the downloaded file and search for the “Pre-Shared Key” value . This is what will be used as a shared secret to encrypt the traffic between the Azure and AWS Gateways.
- Also check the “Outside IP Addresses -> Virtual Private Gateway” in the same file, as this will show the Public IP of your AWS Gateway.
- Now it is time to switch back to Azure and create a Local Network Gateway. This will represent the AWS Gateway on the Azure side.
- You need to provide the public IP Address mentined before and the internal Address Space of your AWS VPC.
- Now create the Azure S2S connection, select “Site-to-site” over IPSec, check the Azure GW and “local” Gateway and enter the pre-shared key you got from the AWS connection.
- The protocol used will be IKEv2 and not IKEv1, was a bit confusing at first as the configuration file on the AWS side was stating IKEv1, but my understanding is that the content of AWS configuration file needs to be updated regarding that part.
- in my experience in took around 10 minutes until the Azure Connection displayed the status as being “Connected”, so just wait and be confident.
During these minutes, you can go back on AWS and make sure the routes towards Azure are properly propagated to the AWS resource inside your VPC. ( “Route Tables – Edit Route Propagation”)
This means you do not need to manually edit any route table on your instances for example. More on these route tables later in the article.
You can check the status of the tunnel under Site-to-Site Connections. The recommended solution for a production environment is to have 2 tunnels connecting your VPG to the remote gateway. In this case the second tunnel is not configured, but the first one shows “UP” in the connection status.
Under “Virtual Private Cloud-Route Tables-Routes” the correct route table towards the Azure Vnet can be verified
The same verification can be done on Azure side, by checking the “Effective routes” on the NIC of the Azure VM connected to the Vnet.
- At this moment , we are ready to login on the VMs from both Clouds and verify the connection.
- Interestingly, both VMs do not show any routing entries when checking the local route table with route print
- This was a bit confusing for me in the beginning, as no machines could reach the other one and I was not sure if the routing was synchronized and everything was correctly setup.
- Verifying the Network Security Group on both sides makes perfect sense, but in my case, first making sure that the Windows Firewall was allowing traffic from the other Address Space was key in making sure the machines could ping themselves reciprocally.
Mission Completed 🙂
