In this post, we will see how a virtual network in Azure connects to an AWS Virtual Private Cloud (VPC) with the help of a virtual network gateway. For a guide on how to connect AWS VPC to Azure using the dedicated VPN connection see this post.
AWS VPC allows for the option to use cloud resources in a logical isolated private network. It provides the same isolation that an Azure virtual network does. The logical network can be split into subnets where spun VMs can or cannot access the Internet or specific resources.
VMs from AWS private subnet should have access only to AWS VPC and to Azure virtual network. The link between VPC and Azure virtual network will use an IPsec tunnel created with the help of Strongswan Linux package on AWS side and the virtual network gateway on Azure side. The IPsec tunnel will be between Azure virtual network gateway and the VM from the AWS VPC public subnet.
Any traffic between the AWS VPC private subnet will go through the VM from the AWS VPC public subnet.
Fig1: sample environment setup
When a virtual network gateway is set up, a virtual network provides the network range that is reachable from the remote side and the public IP address is used by the remote side as IPsec tunnel endpoint. Additionally, the local network gateway provides the information about the public IP address to which the IPsec tunnel will be established and the remote network range reachable from VMs spun in the Azure virtual network. Basically, the local network gateway provides the on-premise network information.
Azure calls the IPsec tunnel a VPN connection and to bring it up, it uses the virtual network gateway and local network gateway information along with a pre-shared key (password).
1. Azure virtual network with the range of 10.1.0.0/16:
2. Virtual network gateway:
3. The VPN connection:
The screenshot was taken after the remote side had been set up. Once set up it will display the “Connected” status and the data transferred in and out will be visible.
4. The local network gateway with the details of the public IP and VPC range from AWS:
5. Finally, this is the VM in the virtual network from where it received 10.1.0.4 private IP address:
1. There are two subnets in VPC, one public and one private:
2. The route table of the public subnet has a default route(0.0.0.0/0) through the internet gateway:
3. The route table of the private subnet has a route to Azure virtual network through the EC2 instance spun in the public subnet:
4. The EC2 instances, one in each VPC subnet:
5. Source/destination check:
Because any EC2 instance from the private subnet will use the EC2 instance from the public subnet, the EC2 instance from the public subnet will act as a router, therefore will need to have source/destination check disabled(the EC2 instance from the public subnet will not be the source or the destination of the traffic between the Azure VM and the EC2 instance from the private subnet):
The EC2 instance acting as an IPsec peer for the Azure virtual network gateway runs strongswan to establish the IPsec tunnels.
The tunnel is up and there is connectivity between 172.16.0.0/16, on the AWS side, and 10.1.0.0/16, on the Azure side:
Traffic between 172.16.2.114 and 10.1.0.4 works just fine:
We have successfully connected an AWS VPC to an Azure virtual network using a virtual network gateway.
Azure Portal provides basic monitoring for Azure Virtual Network Gateway. Users that require advanced monitoring, auto-scaling or self-healing features, should learn more about Netreo. Along with advanced features designed to keep Azure Virtual Network Gateway stable, Netreo also provides powerful dashboards, historical reporting, various integrations to popular ITSM and other IT tools and much more.
[su_note note_color=”#eeeeee” text_color=”#151212″]Bonus Tip: see the detailed comparison of Netreo vs the native Azure monitoring features.[/su_note]
In the following example, we will see how to configure Azure Virtual Network Gateway monitoring in a few easy steps. Netreo comes with preconfigured metrics and alerts as seen below:
This alert fires when it if there is no connection for the defined period of time. Below is the alert configuration pane in the Netreo dashboard:
Sample alert case when the IPsec tunnel on AWS side was brought down:
Once the IPsec tunnel on AWS side is brought up, the alert is cleared off:
This alert monitors the traffic rate on either egress or ingress side of the VPN connection. Below is a sample configuration in the Netreo dashboard. By default, it monitors the level of 80% on 100Mbps connection. If the threshold is reached and sustained for more than two minutes, the alert fires.
In the example above the default threshold was set to 80% of a 10Mbps connection to trigger the alert quicker. Although the screenshot below monitors the entire throughput of the connection (ingress and egress), for this sample case only the Azure VM was sending traffic to the AWS VM and therefore the egress direction of the connection had around 19Mpbs. The sustained rate for more than two minutes triggered the alert:
The alert clears off after the throughput on egress direction falls below 8Mbps.
Further metrics and alerts can be configured for a virtual network gateway depending on the specific requirements for each particular case. However, one would always want to know whether the VPN connections are up.
[su_note note_color=”#eeeeee” text_color=”#151212″]Pro Tip: 5 Azure performance metrics every administrator should keep in mind[/su_note]