In this post, we will see how an AWS Virtual Private Cloud (VPC) connects to Azure infrastructure using the dedicated VPN connection. For a guide on how to connect Azure using VPN Gateway to AWS VPC see this post.
This is how the various AWS and Azure services mentioned throughout the post interact with each other:
The goal is that the VM from AWS VPC is able to reach the VM on Azure by configuring a VPN connection in AWS VPC.
An AWS VPC is a virtual network isolated from the other virtual networks in AWS. This allows a high level of customization by letting administrator to choose the subnets, the IP addresses, to configure the route tables, to specify which subnets are public and which are private.
A subnet is public if it has a default route pointing to an Internet Gateway. In this way, any EC2 instances from the public subnet can access the Internet.
Sometimes the VPC has to be reachable from other places in a secured way. This remote location can be the on-premise data center or other cloud vendors, like Azure.
AWS VPC allows customers to securely connect to these remote locations using VPN connections. This frees administrators from handling all the VPN configuration, operation and troubleshooting overhead.
To use this service, an administrator has to provide some critical information:
The VPN connection is established through two IPsec tunnels over which routes are exchanged. AWS provides the parameters that will bring up the two tunnels and it is the responsibility of the remote side to configure its device accordingly.
If there is any mismatch between the two sides, the IPsec tunnels will not come up and there will be no connectivity between the two locations.
The Virtual Private Gateway (VPG) service from AWS is similar to Virtual Network Gateway (VNG) from Azure. Both provide a possibility to connect remote locations (they can even be inside the same cloud vendor or on-premises or in another cloud vendor) to a VPC/virtual network. However, every time one of these two services is used, the peer has to fulfill the AWS/Azure requirements in order to bring up the IPsec tunnels and each of these two have different sets of requirements. This leads to the inability to connect an AWS VPC to an Azure virtual network using VPG on AWS side and VNG on Azure side.
One of these two sides will need to take a step back and accept the configuration requirements from its peer.
In this specific case, the Azure VM will be configured as IPsec endpoint by installing several packages and configuring IPsec using the parameters given by AWS. On top of this, BGP on Quagga will exchange routes with AWS Virtual Private gateway.
1. The VM in Azure:
2. The IP addresses from this VM:
As mentioned before, the focus in this post is not to show how to configure a VPC, but how to connect it to an on-premise network or, in this case, to Azure.
The VPC in AWS was created and the CIDR allocated is 192.168.0.0/16.
1. Define the Customer Gateway:
2. Create a new Customer Gateway and provide the public IP address from Azure VM. To advertise routes between VPC and Azure VM, dynamic routing will be used, in this case, BGP. The BGP Autonomous System Number will be 65001, but this is just a preference.
3. The Customer Gateway is available:
4. Create a Virtual Private Gateway:
5. The Virtual Private Gateway is detached by default:
6. We will attach it to the VPC:
7. Configure the VPN connections:
8. The VPN connection requires resources like Customer Gateway and Virtual Private Gateway and the type of routing:
9. This is the VPN connection that will connect the VPC to Azure VM:
10. At this moment, the Virtual Private Gateway waits for the remote side to initiate the IPsec connection. Because the Azure VM is not yet configured properly for IPsec, the two tunnels will be down:
11. AWS provides specific parameters for IPsec tunnels and BGP configuration that the remote side has to use.
In case the remote side uses an appliance tested by AWS (for instance a Cisco device), then AWS can provide the device configuration straight away. In case the remote side uses a device for which AWS cannot provide a configuration (like in this case, a Linux box), then the generic configuration file will contain all the parameters needed to bring up the VPN connection between the VPC and any given device:
12. Once the Azure is configured properly, the two IPsec tunnels come up and 3 BGP routes(due to dynamic routing) are received from the Azure VM.
Bringing-up the tunnels does not take long, but there were issues with the IPsec configuration on Azure VM side caused by a typo. If everything is correct, the IPsec tunnels should come up in seconds.
13. The VPN routes will not appear in the VPC routing table unless one of these happens:
Route propagation allows automatic VPN routes to be added in the routing table:
14. The routes are present in the VPC routing table. You can tell which routes are from the remote side by seeing that the target (next-hop) is the Virtual Private Gateway. In this case, the route in question is the 10.1.0.0/24 one, that is the internal range of the Azure VM:
Just to check this from both sides, on Azure VM, the VPC subnet (192.168.0.0/16) is tested via BGP:
If everything is correct, there should be connectivity between a VM in AWS VPC (192.168.0.0/16 subnet) and the Azure VM (10.1.0.0/24 subnet). For this, a VM was spawned in the AWS VPC with address 192.168.0.47:
And there is connectivity between the two VMs:
[su_note note_color=”#eeeeee” text_color=”#151212″][root@ip-192-168-0-47 ec2-user]# ping 10.1.0.4
PING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.
64 bytes from 10.1.0.4: icmp_seq=1 ttl=64 time=4.32 ms
64 bytes from 10.1.0.4: icmp_seq=2 ttl=64 time=4.35 ms
^C
— 10.1.0.4 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.326/4.341/4.357/0.067 ms
root@ip-192-168-0-47 ec2-user]#
[/su_note]
This means that the VPN connection between the AWS VPC and Azure VM is working correctly and traffic can pass through it.
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]
