Skip links

Azure to AWS VPN with Dynamic Routing

Which cloud provider do you use?  Many companies today choose multiple providers due to the strengths they are after to meet either security requirements or ease of integration.  When it comes to basic networking, all cloud providers come with their own unique ways of addressing availability, whether it’s through availability zones with AWS, or geo-redundancy options for Azure.

So, when deploying to both of these cloud providers, linking the two together via a VPN is very easy to achieve and there are many tutorials on how to get setup in under 30 minutes.  This article aims to provide a quick way to connect point-to-site VPNs to Azure, then configure a site-to-site VPN to AWS and have all VNets and VPCs communicating successfully with BGP as the protocol used to advertise all network routes.

Due to the VPN configuration requirements of both platforms, we will be jumping back and forth between AWS and Azure to get each stage done as one step will feed into the next.  The architecture we will build is:

fig. 1, architecture diagram
fig. 1, architecture diagram

To start with the reference infrastructure, ensure all VPCs and subnets are created in AWS, VNets and subnets are setup in Azure and start with the AWS Transit Gateway creation.

fig. 2, AWS subnets
fig. 2, AWS subnets
fig. 3, Azure VNet setup
fig. 3, Azure VNet setup

Azure Virtual Network Gateway (VNG)

Now that the basic networking is in place, we need to configure the Azure Virtual Network Gateway.  As we are going to be using BGP we need at least the VpnGw1 SKU to be used.  Also, the VPN type must be route-based to allow for the BGP protocol.

When deploying the Azure VNG, make sure to enable the option to Configure BGP, set the Azure-side BGP ASN to 65413 (or another that you may want to use, but must be unique from the AWS ASN) and set the Custom Azure APIPA BGP IP address in the range allowed.  The custom IP address must be within the Azure APIPA ranges, which are 169.254.21.* and 169.254.22.*.  The AWS ‘inside IP’ has support for many more ranges.

For this, we will set it to 169.254.21.2, the AWS end will be configured with 169.254.21.0/30 and will consume the first available IP in this range.  Make a note of the public IP address assigned to the VNG for use later, in our case it is 51.140.250.225.

fig. 4, Azure VNG BGP configuration
fig. 4, Azure VNG BGP configuration

AWS Transit Gateway (TGW)

Next, we create the AWS Transit Gateway, ensuring we set the Amazon side ASN to the BGP ASN we need, in this case 65412, which is also the default.  If you want to set it to a different one, now is the time as a change to the ASN will require the Transit Gateway to be re-deployed.

fig. 5, AWS Transit Gateway configuration
fig. 5, AWS Transit Gateway configuration

AWS Customer Gateway (CGW)

As we have the Azure VNG public IP, we can configure the AWS Customer Gateway (CGW).  The routing option should be set to dynamic, the BGP ASN is that of the remote end ASN, in this case 65413 and the IP address assigned to the Azure VNG.

fig. 6, AWS Customer Gateway configuration
fig. 6, AWS Customer Gateway configuration

AWS Site-to-Site VPN

Next, we configure the AWS VPN endpoint, utilising the CGW and Transit Gateway.  In the AWS VPC console, under Site-to-Site VPN Connections, create a new connection specifying the Transit Gateway as the target type and select the already deployed TGW and use the existing AWS CGW, set the routing option to Dynamic.

fig. 7, AWS VPN connection
fig. 7, AWS VPN connection

The Tunnel Options are key for the BGP configuration, The Inside IPv4 CIDR for Tunnel 1 should be set to 169.254.21.0/30 to match the Azure APIPA address on the VNG.  Set a secure shared secret and if required, edit the tunnel options for phase 1 and 2 encryption, integrity algorithms and Diffie-Hellman group numbers.  The tunnel phase 1 and 2 configuration options can be changed later for a more secure setup.

fig. 8, AWS VPN tunnel options
fig. 8, AWS VPN tunnel options

Once the VPN configuration is started, the tunnel 1 outside IP address will be assigned and ready for the Azure Local Network Gateway (LNG) to be configured.  The outside IP address here is 52.30.50.45.

Azure Local Network Gateway (LNG)

In the Azure console, add a Local Network Gateway to your subscription, ticking the box for Configure BGP settings.  The LNG specifies the details of the AWS end of the tunnel, therefore the ASN to use is from AWS, 65412 and the BGP peer IP is the AWS end of the tunnel, 169.254.21.1.

fig. 9, Azure Local Network Gateway configuration
fig. 9, Azure Local Network Gateway configuration

Azure VPN Connection

Finally, the Site-to-Site connection can be set, under the Azure VNG object, select Connections and add a new one, specifying the connection type of IPsec, select the configured LNG, enter the pre-shared key used on the AWS end and tick the Enable BGP option.  Once deployed, as long as the VPN tunnel settings are the same, everything should connect.  If custom settings have been configured on the AWS end, first create the connection in Azure, once it is deployed, select the connection, go to Configuration and enable the Custom IPsec/IKE policy, entering the required settings to match up with the AWS end.

fig. 10, Azure VPN connection settings
fig. 10, Azure VPN connection settings

At present, if the VPN has successfully established, under the Azure VNG, select BGP peers to list any learned routes from the AWS end.  If you have followed this guide, there won’t be any routes from AWS learned yet as we haven’t attached the AWS VPC to the Transit Gateway.

fig. 11, Azure BGP peers and routes
fig. 11, Azure BGP peers and routes

AWS Transit Gateway attachment

In the AWS VPC console, go to Transit Gateway Attachments and create a new attachment.  Specify the existing Transit Gateway, attachment type of VPC, select the VPC and ensure the TGW subnet is selected.  Multiple subnets across all availability zones are recommended to ensure all deployed services are routable, however for the purposes of this tutorial, we only have the one set up.

fig. 12, AWS TGW attachment
fig. 12, AWS TGW attachment

The TGW attachment will automatically be associated to the default route table, this can be adjusted at any time.  The attachment will also be set for route propagation on the default route table, and it’s this propagation setting that ensures the routes are shared via BGP to the Azure end of the VPN.

fig. 13, AWS TGW route table propagation
fig. 13, AWS TGW route table propagation
fig. 14, AWS TGW route tables
fig. 14, AWS TGW route tables

To confirm that the routes have been shared successfully via BGP, go back to the Azure VNG BGP peers in the Azure portal.

fig. 15, Azure BGP routes and peers
fig. 15, Azure BGP routes and peers

Now all routing will work as-is from any resources deployed into this VNet.  This can now be extended and shared with other VNets via peering, making sure the Use this virtual network’s gateway or Route Server option is selected at this VNets end of the peering connection.

Azure Point-to-Site VPN

To create a Point-to-Site VPN configuration on the Azure VNG, select the VNG and go to Point-to-Site configuration, select Configure now.  Enter an IP address and configure the Tunnel type, I’m looking at an AlwaysON VPN setup for Windows 10 devices, so I need to choose IKEv2.  On the Authentication type, set Azure certificate and under the Root certificates enter a name for the public root certificate of the PKI infrastructure to be used, then open the public certificate from the root of the PKI and copy/paste the text between the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– into the Public certificate data.

fig. 16, Azure P2S configuration
fig. 16, Azure P2S configuration

Once the configuration is applied, the route will be added into the BGP configuration and will show up on the BGP peers in the Azure portal and the VPN connection in AWS will show an additional route is learned by BGP.

fig. 17, Azure BGP learned routes
fig. 17, Azure BGP learned routes
fig. 18, AWS learned BGP routes
fig. 18, AWS learned BGP routes

The only thing remaining is to setup the Windows 10 devices for connecting to the Point-to-Site VPN.  Download the configuration for the P2S setup and within the zipfile, there is a VpnSettings.xml file which contains the name of the VPN endpoint to be used.

fig. 19, Azure P2S VpnServer entry
fig. 19, Azure P2S VpnServer entry

Depending on how the configuration will be deployed, whether by Group Policy or Microsoft InTune/Endpoint Manager, the VPN server entry should be used for the connection.  All other settings then depend on security requirements and how you want to route the traffic across the Azure and AWS cloud environments, but all VPCs and VNets will be accessible.

Good luck with the VPN setup.

Leave a comment