A step-by-step guide for AWS EC2 provisioning using Terraform: VPN, VPC peering, tunnels, Site-to-site Connection, Subnets, Azure VPN Client & Gateway (multi-cloud) using Terraform — Part 12

Joel Wembo
26 min readJun 25, 2024

--

Terraform provisioning AWS VPN and Azure VPN Site to Site Connection with advanced network security. The proliferation of cloud computing has led to the rise of multi-cloud architectures, where businesses leverage the strengths of multiple cloud providers. However, this distributed approach necessitates secure communication channels between resources residing in different cloud environments. This article addresses this challenge by providing an in-depth exploration of various connectivity options. We’ll equip you with the knowledge to choose the most suitable method for your specific multi-cloud needs, ensuring the secure and seamless flow of data across your cloud infrastructure.

multi-cloud

Multi-Cloud VPN Planning

· Abstract
· Preface
· Introduction
· Use Cases for Multi-Cloud VPN with Examples
Building Blocks of Your Secure AWS Network
Azure’s Secure Networking Foundation
· Technical Guide: VPN between AWS and Azure Cloud
Step 1: Resource Group
Step 2: Virtual Network
Step 3: Add Subnet to this VPN-VN
Step 4: Virtual Network Gateway
Step 5: In the next step, let's jump to AWS
Step 6: Add subnets to vpc-azure
Step 7: VPN ( Customer gateway ) from AWS
Step 8: Create a Virtual Private Gateway
Step 9: Site-to-Site Connection
Step 10: Create a Local Network Gateway From Azure
Step 11: Create Route Table
Step 12: Add Route
· Conclusion
· About me
· References

Abstract

This article dives into the world of secure multi-cloud connectivity using Terraform, an infrastructure as code (IaC) tool. We’ll explore key concepts like Virtual Private Networks (VPNs), Virtual Private Cloud (VPC) peering, and Site-to-Site connections, all crucial for establishing secure communication channels between resources across different cloud providers. We’ll demystify the role of tunnels, the encrypted pathways that ensure secure data transmission. The focus then shifts to leveraging Terraform to manage the configuration and deployment of Azure VPN clients and Gateways. This enables seamless and secure connections between your on-premises network, other cloud environments, and your Azure Virtual Network, all automated through Terraform.

Preface

The growing adoption of multi-cloud strategies necessitates robust and automated solutions for secure inter-cloud communication. Terraform emerges as a powerful tool for managing this complexity. This article equips you with the knowledge to leverage Terraform for configuring Azure VPN solutions in your multi-cloud environment. We’ll guide you through the intricacies of VPNs, VPC peering, Site-to-Site connections, and tunnels, all within the context of Terraform automation. By the end, you’ll be empowered to establish secure and efficient multi-cloud connectivity using Terraform’s infrastructure as a code approach.

To enhance readability, this handbook is divided into chapters and split into parts. The first, part, “A step-by-step guide for AWS EC2 provisioning using Terraform: HA, ALB, VPC, and Route53 — Part 1”, and the second part “A step-by-step guide for AWS EC2 provisioning using Terraform: HA, CloudFront, WAF, and SSL Certificate — Part 2”, and “A step-by-step guide for AWS EC2 provisioning using Terraform: Cloud Cost Optimization, AWS EC2 Spot Instances — Part 3”, was covered in a separate article to keep the reading time manageable and ensure focused content. The next part or chapter will be published in the next post, upcoming in a few days, “A step-by-step guide for AWS EC2 provisioning using Terraform: VPN, VPC peering, Site-to-site Connection, tunnels, AWS VPN, Azure VPN client & Gateway (multi-cloud) using Terraform — Part 13“ and so much more !!

Introduction

There are several compelling reasons why organizations are increasingly adopting a multi-cloud strategy, using multiple cloud providers instead of just one. Here are some of the key benefits:

  • Flexibility and Choice: Multicloud lets you pick and choose the best services from various cloud providers. Need a powerful database solution? You can leverage one provider while using another for top-notch analytics tools. This flexibility ensures you’re not locked into a single vendor’s offerings.
  • Cost Optimization: With multiple cloud providers on the table, you can compare pricing and choose the most cost-effective option for each specific workload. This can lead to significant savings over being tied to a single provider’s pricing structure.
  • Vendor Lock-In Avoidance: By relying on just one cloud provider, you become dependent on their offerings and pricing. Multicloud eliminates vendor lock-in, giving you the freedom to switch providers or services if needed.
  • Improved Reliability and Security: A multi-cloud environment offers built-in redundancy. If one cloud provider experiences an outage, your critical applications can be seamlessly migrated to another cloud, minimizing downtime and ensuring business continuity. Additionally, spreading your data across multiple providers can enhance security by reducing the risk of a single point of failure.
  • Compliance Advantages: With data privacy regulations constantly evolving, some regulations might have specific requirements for the data storage location. A multi-cloud strategy allows you to distribute your data and applications across geographically diverse cloud regions to meet compliance needs.
  • Performance Optimization: Certain cloud providers might have data centers closer to your target audience, leading to faster loading times and better user experiences. Multicloud lets you leverage geographically distributed cloud resources to optimize performance for your specific needs.

Use Cases for Multi-Cloud VPN with Examples

A multi-cloud VPN creates a secure tunnel between your resources spread across different cloud providers like AWS and Azure. Here are some scenarios where a multi-cloud VPN proves beneficial:

1. Hybrid Cloud Integration:

  • Scenario: Your organization has on-premises infrastructure along with resources in multiple clouds. You need secure communication between them.
  • Example: A company maintains core financial systems on-premise while using a cloud provider for development and testing environments. A multi-cloud VPN enables secure data transfer between these environments.

2. Disaster Recovery and Business Continuity:

  • Scenario: You want to ensure your critical applications remain operational even if one cloud provider experiences an outage.
  • Example: An e-commerce platform replicates its core application across two different cloud providers. If one cloud goes down, the multi-cloud VPN facilitates a seamless switch to the other, minimizing downtime and revenue loss.

3. Resource Optimization and Cost Management:

  • Scenario: You leverage different cloud providers for specific workloads based on cost and service offerings.
  • Example: A company uses one cloud provider for high-performance computing tasks and another for data storage due to their respective pricing structures. A multi-cloud VPN allows secure communication and data transfer between these resources.

4. Data Residency and Compliance:

  • Scenario: Data privacy regulations mandate storing data within specific geographical regions.
  • Example: A healthcare company uses a cloud provider in a specific region to comply with data residency regulations. A multi-cloud VPN facilitates secure communication between this cloud environment and another cloud where non-sensitive data resides.

5. Application Development and Testing:

  • Scenario: You leverage different cloud providers for the development, testing, and production environments of an application.
  • Example: A software development team utilizes one cloud provider for development and testing, while another cloud hosts the production application. A multi-cloud VPN enables secure communication and data transfer during the development and deployment stages.

Building Blocks of Your Secure AWS Network

  • Virtual Private Cloud (VPC): Imagine a virtual network carved out of the AWS cloud, that’s your VPC. You control everything inside, from IP addresses to security.
  • Subnets: These are divisions within your VPC, like neighborhoods in a city. You can have public subnets accessible from the internet, and private subnets for internal resources.
  • Route Tables: Think of these as traffic signs. They direct data packets where to go within your VPC and to the outside world.
  • Security Groups: These act like bouncers at a club. They decide which traffic is allowed in and out of your resources based on your rules.
  • Highway to the Internet (Internet Gateway): This lets your resources in public subnets chat with the outside world.
  • Connecting VPCs (VPC Peering): Imagine building bridges between VPCs. This allows them to talk directly to each other, like neighboring towns.
  • Transit Gateway: This is like a central hub that simplifies connections between multiple VPCs and even your own on-premises network. No more managing a maze of point-to-point connections!
  • Private Connections with AWS PrivateLink: This keeps your data off the public internet altogether. It creates private pathways between your VPC, AWS services, and even your on-premises network.
  • Elastic Load Balancing (ELB): ELB is like a traffic manager for your applications. It distributes incoming requests across multiple resources, ensuring things run smoothly.
  • Network Address Translation (NAT) Gateway: This allows outbound traffic from private subnets to access the internet without exposing inbound traffic. Ideal for instances that only need to send data out.
  • Security Groups vs. Network Access Control Lists (ACLs): While similar, security groups are stateful firewalls that inspect traffic direction, while ACLs are stateless and only filter based on source and destination.
  • VPC Endpoints: These provide private connections between your VPC and specific AWS services, eliminating the need to route traffic over the internet.

Azure’s Secure Networking Foundation

  • Virtual Network (VNet): The cornerstone of Azure networking, your VNet is a private network carved out of the Azure cloud. You control all the resources within, including IP addresses, security, and connectivity.
  • Subnets: Similar to subnets in AWS, these are segments within your VNet. You can create public subnets for internet access and private subnets for internal resources, keeping things organized.
  • Route Tables: These act as traffic directors, guiding data packets within your VNet and to external destinations.
  • Network Security Groups (NSGs): Think of NSGs as security guards for your resources. They control inbound and outbound traffic flow based on the rules you define.
  • Internet Gateway: This acts as the on-ramp to the internet for resources in your public subnets. It’s essential for those resources to communicate with the outside world.
  • VNet Peering: Imagine creating secure tunnels between VNets. VNet peering allows direct communication between them, just like connected buildings on a campus.
  • Azure Virtual WAN: This centralizes connectivity for various VNets and even on-premises networks. It simplifies managing connections and reduces complexity compared to point-to-point configurations.
  • Azure Private Link: Similar to AWS PrivateLink, this keeps your data off the public internet. It establishes private connections between your VNet, Azure services, and your on-premises network.
  • Azure Load Balancer: This distributes incoming traffic across your resources for better performance and fault tolerance, ensuring a smooth user experience.

Technical Guide: VPN between AWS and Azure Cloud

Site-to-Site VPN Connection Azure and AWS using Tunnel

This technical guide will give you a walkthrough of Terraform provisioning AWS VPN and AWS VPN Site-to-Site Connection with advanced network security. From Resource Group, Virtual Network, Add Subnet to this VPN-VN, Virtual Network Gateway, add subnets to vpc-azure, VPN ( Customer Gateway ), Azure Virtual Private Gateway, to Site-to-Site Connection using terraform.

If you want to know how to set up your Azure account, Azure CLI with Terraform, please read the following article as we will skip this part here.

multi-cloud with Terraform

Step 1: Resource Group

Resource groups provide a way to organize, manage, secure, and track your cloud resources effectively. They offer a higher level of control, visibility, and maintainability for your infrastructure as code deployments in Terraform.

resource "azurerm_resource_group" "resource_group" {
name = "${var.resourcegroup}"
location = "${var.location}"
}

Step 2: Virtual Network

A VNet is a private network you create within the Azure cloud environment. It isolates your resources (virtual machines, storage accounts, etc.) from the public internet, providing a first layer of security. Traffic within the VNet can flow freely using private IP addresses. Think of a VNet as a gated community within Azure, offering a secure environment for your cloud resources.

You can create your virtual network from Azure portal

# Let's create a Microsoft Azure virtual network using Terraform

#primary azure virtual network
resource "azurerm_virtual_network" "prodxcloud-network" {
name = "prodxcloud-network"
address_space = ["10.0.0.0/22"]
location = var.location
resource_group_name = var.resourcegroup
depends_on = [ azurerm_resource_group.resource_group ]
}

# Second Virtual Network
resource "azurerm_virtual_network" "VPN-VN" {
name = "VPN-VN"
address_space = ["172.16.0.0/16"]
location = azurerm_resource_group.resource_group.location
resource_group_name = azurerm_resource_group.resource_group.name
}

Step 3: Add Subnet to this VPN-VN

Note we could have used prodxcloud-network just to make sure the space subnet ranges are different from the existing virtual networks

# Second subnet with attached address prefixed to VPN-Virtual network
resource "azurerm_subnet" "prodxcloud-vpn-network-subnet" {
name = "prodxcloud-vpn-network-subnet"
resource_group_name = var.resourcegroup
virtual_network_name = azurerm_virtual_network.VPN-VN.name
address_prefixes = ["10.0.2.0/24"]
}

Step 4: Virtual Network Gateway

Explanation:

  1. gateway_ip_configuration: This block is required and specifies the IP configuration settings for the Virtual Network Gateway.
  2. Sub-blocks within gateway_ip_configuration:
  • vpn_client_configuration: Optional. Specifies settings for VPN clients connecting to the gateway.
  • bgp_settings: Optional. Configures Border Gateway Protocol (BGP) settings for the gateway.

Common Issues and Troubleshooting:

  • Missing Sub-blocks: Ensure that you have provided at least one sub-block (vpn_client_configuration or bgp_settings) within the gateway_ip_configuration block.
  • Syntax Errors: Check for syntax errors such as missing curly braces {} or incorrect indentation.
  • Required Attributes: Verify that all required attributes within each sub-block are correctly specified according to Azure’s documentation for azurerm_virtual_network_gateway.

Adjustments:

  • Public IP Address: Ensure that public_ip_address_id refers to a valid Azure public IP address resource (azurerm_public_ip).
  • Subnet Configuration: Double-check that subnet_id points to a valid subnet where the Virtual Network Gateway's IP address will reside.

Terraform Version



# VPN Azure vpn gateway public ip
# resource "azurerm_public_ip" "vpn_gateway_public_ip" {
# name = "vpn_gateway_public_ip"
# location = azurerm_resource_group.resource_group.location
# resource_group_name = azurerm_resource_group.resource_group.name
# allocation_method = "Dynamic" # or "Static" depending on your requirement
# }

# # VPN Azure Virtual network Gateway
# resource "azurerm_virtual_network_gateway" "VPN-VNG" {
# name = "VPN-VNG"
# resource_group_name = azurerm_resource_group.resource_group.name
# location = azurerm_resource_group.resource_group.location
# type = "Vpn"
# vpn_type = "RouteBased"
# sku = "VpnGw1"

# ip_configuration {
# name = "gwconfig1"
# subnet_id = azurerm_subnet.prodxcloud-vpn-network-subnet.id
# public_ip_address_id = azurerm_public_ip.vpn_gateway_public_ip.id
# }

# vpn_client_configuration {
# address_space = ["172.16.0.0/27"]
# }

# bgp_settings {
# asn = 65515
# }

# depends_on = [ azurerm_subnet.prodxcloud-vpn-network-subnet ]

# }

Azure Virtual network with pre-defined subnet (network subnet ) for our VPN.

Step 5: In the next step, let's jump to AWS

To not confuse the ec2 configuration that we did earlier in Part 1 and Part 2, some of the resources like vpc and subnets will be recreated at this stage and then reattached later, to make the documentation reusable for other purposes.

First, create another vpc in AWS for the Azure connection

resource "aws_vpc" "VPC-Azure" {
cidr_block = "192.168.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
enable_network_address_usage_metrics = true
lifecycle {
create_before_destroy = true
}

tags = {
Name = "VPC-Azure"
}
}

Step 6: Add subnets to vpc-azure

# create a Subnet 1 for vpc-azure ( VPN related)
resource "aws_subnet" "prodxcloud-azure-subnet-1" {
vpc_id = aws_vpc.VPC-Azure.id
availability_zone = "us-east-1a"
cidr_block = "192.168.1.0/24"
map_public_ip_on_launch = true

tags = {
Name = "prodxcloud-azure-subnet-1"
}
}

Step 7: VPN ( Customer gateway ) from AWS

Using terraform

resource "aws_vpc" "VPC-Azure" {
cidr_block = "192.168.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
enable_network_address_usage_metrics = true
lifecycle {
create_before_destroy = true
}

tags = {
Name = "VPC-Azure"
}
}


# Create Subnet 1 for vpc-azure ( VPN related)
resource "aws_subnet" "prodxcloud-azure-subnet-1" {
vpc_id = aws_vpc.VPC-Azure.id
availability_zone = "us-east-1a"
cidr_block = "192.168.1.0/24"
map_public_ip_on_launch = true

tags = {
Name = "prodxcloud-azure-subnet-1"
}
}
# Create a reserved Subnet 2
# resource "aws_subnet" "prodxcloud-azure-subnet-2" {
# vpc_id = aws_vpc.VPC-Azure.id
# cidr_block = "10.0.0.0/16"
# availability_zone = "us-east-1b"
# map_public_ip_on_launch = true

# tags = {
# Name = "prodxcloud-azure-subnet-2"
# }
# }

# Create Customer Gatway ( VPN )

module "cgw" {
source = "terraform-aws-modules/customer-gateway/aws"
version = "~> 1.0"

name = "AWS-To-Azure"


customer_gateways = {
IP1 = {
bgp_asn = 65112
ip_address = "20.248.118.159"
}
}

tags = {
Test = "maybe"
}
}

Step 8: Create a Virtual Private Gateway

Using terraform

# Create Virtual Private Gateway
resource "aws_vpn_gateway" "prodxcloud_vpn_gateway" {
vpc_id = aws_vpc.VPC-Azure.id
tags = {
Name = "My VPC-Azure VPN Gateway"
}

depends_on = [aws_vpc.VPC-Azure]
}

Step 9: Site-to-Site Connection

Let's use the terraform to provision our site-to-site VPN connection

# aws vpn connection using terraform
resource "aws_vpn_connection" "prodxcloud_vpn_connection" {
vpn_gateway_id = aws_vpn_gateway.prodxcloud_vpn_gateway.id
customer_gateway_id = "cgw-0553fbf7795d03de4"
type = "ipsec.1"

# routes {
# destination_cidr_block = "172.16.0.0/24"
# # vpn_gateway_id = aws_vpn_gateway.prodxcloud_vpn_gateway.id
# }

tags = {
Name = "xcloud_vpn_connection"
}


depends_on = [aws_vpn_gateway.prodxcloud_vpn_gateway]
}

Download the configuration, we will need that file for our next configuration to Azure Network

Here is the template that was produced ( this is a demo/example only )

Amazon Web Services
Virtual Private Cloud

VPN Connection Configuration
================================================================================
AWS utilizes unique identifiers to manipulate the configuration of
a VPN Connection. Each VPN Connection is assigned a VPN Connection Identifier
and is associated with two other identifiers, namely the
Customer Gateway Identifier and the Virtual Private Gateway Identifier.

Your VPN Connection ID : vpn-06092e70a0657d5c9
Your Virtual Private Gateway ID : vgw-0daeba1ff99c68487
Your Customer Gateway ID : cgw-0553fbf7795d03de4

A VPN Connection consists of a pair of IPSec tunnel security associations (SAs).
It is important that both tunnel security associations be configured.


IPSec Tunnel #1
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows:
Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24.
NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels.

Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
The address of the external interface for your customer gateway must be a static address.
Your customer gateway may reside behind a device performing network address translation (NAT).
To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500.
If not behind NAT, and you are not using an Accelerated VPN, we recommend disabling NAT-T. If you are using an Accelerated VPN, make sure that NAT-T is enabled.
- IKE version : IKEv1
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : RbtJTUs_AQqJR9zdzLsQzLQ1cJwv0pgi
- Authentication Algorithm : sha1
- Encryption Algorithm : aes-128-cbc
- Lifetime : 28800 seconds
- Phase 1 Negotiation Mode : main
- Diffie-Hellman : Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24.
NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels.

Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
- Protocol : esp
- Authentication Algorithm : hmac-sha1-96
- Encryption Algorithm : aes-128-cbc
- Lifetime : 3600 seconds
- Mode : tunnel
- Perfect Forward Secrecy : Diffie-Hellman Group 2

IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
- DPD Interval : 10
- DPD Retries : 3

IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space,
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following
configuration on your Customer Gateway:
- TCP MSS Adjustment : 1379 bytes
- Clear Don't Fragment Bit : enabled
- Fragmentation : Before encryption

#3: Tunnel Interface Configuration

Your Customer Gateway must be configured with a tunnel interface that is
associated with the IPSec tunnel. All traffic transmitted to the tunnel
interface is encrypted and transmitted to the Virtual Private Gateway.



The Customer Gateway and Virtual Private Gateway each have two addresses that relate
to this IPSec tunnel. Each contains an outside address, upon which encrypted
traffic is exchanged. Each also contain an inside address associated with
the tunnel interface.

The Customer Gateway outside IP address was provided when the Customer Gateway
was created. Changing the IP address requires the creation of a new
Customer Gateway.

The Customer Gateway inside IP address should be configured on your tunnel
interface.

Outside IP Addresses:
- Customer Gateway : 20.248.118.159
- Virtual Private Gateway : 52.45.152.153

Inside IP Addresses
- Customer Gateway : 169.254.143.18/30
- Virtual Private Gateway : 169.254.143.17/30

Configure your tunnel to fragment at the optimal size:
- Tunnel interface MTU : 1436 bytes

#4: Border Gateway Protocol (BGP) Configuration:

The Border Gateway Protocol (BGPv4) is used within the tunnel, between the inside
IP addresses, to exchange routes from the VPC to your home network. Each
BGP router has an Autonomous System Number (ASN). Your ASN was provided
to AWS when the Customer Gateway was created.

BGP Configuration Options:
- Customer Gateway ASN : 65112
- Virtual Private Gateway ASN : 64512
- Neighbor IP Address : 169.254.143.17
- Neighbor Hold Time : 30

Configure BGP to announce routes to the Virtual Private Gateway. The gateway
will announce prefixes to your customer gateway based upon the prefix you
assigned to the VPC at creation time.


IPSec Tunnel #2
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows:
Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24.
NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels.

Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
The address of the external interface for your customer gateway must be a static address.
Your customer gateway may reside behind a device performing network address translation (NAT).
To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500.
If not behind NAT, and you are not using an Accelerated VPN, we recommend disabling NAT-T. If you are using an Accelerated VPN, make sure that NAT-T is enabled.
- IKE version : IKEv1
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : AXL18pPfeQKtzTth0JNiTesfvAFf9H6F
- Authentication Algorithm : sha1
- Encryption Algorithm : aes-128-cbc
- Lifetime : 28800 seconds
- Phase 1 Negotiation Mode : main
- Diffie-Hellman : Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24.
NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels.

Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
- Protocol : esp
- Authentication Algorithm : hmac-sha1-96
- Encryption Algorithm : aes-128-cbc
- Lifetime : 3600 seconds
- Mode : tunnel
- Perfect Forward Secrecy : Diffie-Hellman Group 2

IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
- DPD Interval : 10
- DPD Retries : 3

IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space,
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following
configuration on your Customer Gateway:
- TCP MSS Adjustment : 1379 bytes
- Clear Don't Fragment Bit : enabled
- Fragmentation : Before encryption

#3: Tunnel Interface Configuration

Your Customer Gateway must be configured with a tunnel interface that is
associated with the IPSec tunnel. All traffic transmitted to the tunnel
interface is encrypted and transmitted to the Virtual Private Gateway.



The Customer Gateway and Virtual Private Gateway each have two addresses that relate
to this IPSec tunnel. Each contains an outside address, upon which encrypted
traffic is exchanged. Each also contain an inside address associated with
the tunnel interface.

The Customer Gateway outside IP address was provided when the Customer Gateway
was created. Changing the IP address requires the creation of a new
Customer Gateway.

The Customer Gateway inside IP address should be configured on your tunnel
interface.

Outside IP Addresses:
- Customer Gateway : 20.248.118.159
- Virtual Private Gateway : 100.28.232.84

Inside IP Addresses
- Customer Gateway : 169.254.225.42/30
- Virtual Private Gateway : 169.254.225.41/30

Configure your tunnel to fragment at the optimal size:
- Tunnel interface MTU : 1436 bytes

#4: Border Gateway Protocol (BGP) Configuration:

The Border Gateway Protocol (BGPv4) is used within the tunnel, between the inside
IP addresses, to exchange routes from the VPC to your home network. Each
BGP router has an Autonomous System Number (ASN). Your ASN was provided
to AWS when the Customer Gateway was created.

BGP Configuration Options:
- Customer Gateway ASN : 65112
- Virtual Private Gateway ASN : 64512
- Neighbor IP Address : 169.254.225.41
- Neighbor Hold Time : 30

Configure BGP to announce routes to the Virtual Private Gateway. The gateway
will announce prefixes to your customer gateway based upon the prefix you
assigned to the VPC at creation time.



Additional Notes and Questions
================================================================================

- Amazon Virtual Private Cloud Getting Started Guide:
http://docs.amazonwebservices.com/AmazonVPC/latest/GettingStartedGuide
- Amazon Virtual Private Cloud Network Administrator Guide:
http://docs.amazonwebservices.com/AmazonVPC/latest/NetworkAdminGuide

Next, will need 2 information from this file to be able to connect to Microsoft Azure

First: Pre-shared Key

Second: Customer Gateway inside IP address for tunneling

Step 10: Create a Local Network Gateway From Azure

Add network address space

Validate your settings

Now you need to specify the public ip address from the AWS Virtual Private Gateway and the VPC CIDR prefix.

Please note that the public address from the AWS Virtual Private Gateway is described at the configuration file you have downloaded.

As mentioned earlier, AWS creates two IPSec tunnels to high availability purposes. I’ll use the public ip address from the IPSec Tunnel #1 for now.

Or Simply use terraform :

resource "azurerm_local_network_gateway" "example" {
name = "example-local-network-gateway"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location

gateway_address = "10.1.0.1"
address_space = ["10.2.0.0/16"]
}

Next, Go to Connections

Create a connection with Site-to-Site as a type

Next, click on the Connection Settings tab

Validate connection

Click on Create,

Terraform version : (do not confuse with azurerm_virtual_network_gateway)

resource "azurerm_virtual_network_gateway_connection" "example" {
name = "example-vnet-gateway-connection"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name

virtual_network_gateway_id = azurerm_virtual_network_gateway.example.id
local_network_gateway_id = azurerm_local_network_gateway.example.id
connection_type = "IPsec"
routing_weight = 10
shared_key = "AzureSharedKey" # Replace with your shared key
}

Configuration Breakdown

  • Virtual Network: Creates a virtual network with the address space 10.0.0.0/16.
  • Gateway Subnet: Creates a subnet named GatewaySubnet with the address prefix 10.0.1.0/24.
  • Public IP: Allocates a dynamic public IP address for the VPN Gateway.
  • Virtual Network Gateway: Creates a VPN Gateway with the type Vpn and VPN type RouteBased.
  • Local Network Gateway: Defines the local network gateway with the gateway address 10.1.0.1 and address space 10.2.0.0/16.
  • Virtual Network Gateway Connection: Establishes a Site-to-Site VPN connection between the Azure VPN Gateway and the on-premises Local Network Gateway using an IPsec connection type and a shared key.

VPN-AWS Connected from Azure to AWS Successfully

Tunnels created

Step 11: Create Route Table

Create a route table when you need to override Azure’s default routing. For example, you can route traffic to a network virtual appliance or to your on-premises network for inspection. A route table contains routes and is associated to one or more subjects.

Next, Associate a subnet where your VPN is located

Step 12: Add Route

Using terraform :

resource "azurerm_route_table" "example" {
name = "example-route-table"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
}

resource "azurerm_route" "example" {
name = "example-route"
resource_group_name = azurerm_resource_group.example.name
route_table_name = azurerm_route_table.example.name
address_prefix = "10.2.0.0/16"
next_hop_type = "VirtualNetworkGateway"
}

resource "azurerm_subnet_route_table_association" "example" {
subnet_id = azurerm_subnet.internal_subnet.id
route_table_id = azurerm_route_table.example.id
}

Next, navigate to the AWS VPC Route Table

Add Space addresses and target your virtual private gateway

Anyone joined to this network like 192.168.0.0/16 if the ec2 instance is attached to this network, azure VPN should be able to help establish the connection via this route table.

Update: Once you are done with this tutorial, you might check a follow-up tutorial in the next part in a few days, “A step-by-step guide for AWS EC2 provisioning using Terraform: Azure and AWS VPN Site-to-site Connection for EC2 (multi-cloud) using Terraform — Part 15”

🚀 A step-by-step guide for AWS EC2 provisioning using Terraform: Let’s Encrypt SSL Certificate in EC2 nginx server or Azure Virtual Machine ubuntu — Part 13 ( + Wildcard SSL )

🚀 A step-by-step guide for AWS EC2 provisioning using Terraform: Let’s Encrypt SSL on Apache2 servers in an Azure Virtual Machine using Ansible Playbook — Part 14

Conclusion

In conclusion, this article has explored various methods for establishing secure connections in a multi-cloud environment, highlighting the benefits of Terraform for streamlined automation. Here’s a recap with some key facts and figures:

  • Efficiency: Terraform automates infrastructure provisioning, potentially saving hours of manual configuration for VPNs, VPC peering, and Site-to-Site connections.
  • Reduced Errors: Terraform’s code-based approach minimizes human error compared to manual configuration, leading to a more reliable and secure infrastructure.
  • Scalability: Terraform excels at managing large-scale deployments, making it ideal for complex multi-cloud environments with numerous connections.
  • Security: Terraform enables you to define security best practices within your code, ensuring consistent security policies across your infrastructure.

By leveraging Terraform, you can significantly enhance the efficiency, security, and scalability of your multi-cloud network. With Terraform’s infrastructure as a code approach, you can manage and maintain your multi-cloud connectivity with greater control and flexibility. Remember, the specific figures regarding time savings and scalability will depend on the complexity of your environment, but Terraform delivers significant advantages for multi-cloud deployments.

To enhance readability, this handbook is divided into chapters and split into parts. The first, part, “A step-by-step guide for AWS EC2 provisioning using Terraform: HA, ALB, VPC, and Route53 — Part 1”, and the second part “A step-by-step guide for AWS EC2 provisioning using Terraform: HA, CloudFront, WAF, and SSL Certificate — Part 2”, and “A step-by-step guide for AWS EC2 provisioning using Terraform: Cloud Cost Optimization, AWS EC2 Spot Instances — Part 3”, was covered in a separate article to keep the reading time manageable and ensure focused content. The next part or chapter will be published in the next post, upcoming in a few days, A step-by-step guide for AWS EC2 provisioning using Terraform: Azure and AWS VPN Site-to-site Connection for EC2 (multi-cloud) using Terraform — Part 13 and so much more !!

Thank you for Reading !! 🙌🏻, don’t forget to subscribe and give it a CLAP 👏, and if you found this article useful contact me or feel free to sponsor me to produce more public content. see me in the next article.🤘

About me

I am Joel Wembo, AWS certified cloud Solutions architect, Back-end developer, and AWS Community Builder, I‘m based in the Philippines 🇵🇭; and currently working at prodxcloud as a DevOps & Cloud Architect. I bring a powerful combination of expertise in cloud architecture, DevOps practices, and a deep understanding of high availability (HA) principles. I leverage my knowledge to create robust, scalable cloud applications using open-source tools for efficient enterprise deployments.

I’m looking to collaborate on AWS CDK, AWS SAM, DevOps CI/CD, Serverless Framework, CloudFormation, Terraform, Kubernetes, TypeScript, GitHub Actions, PostgreSQL, and Django.”

For more information about the author ( Joel O. Wembo ) visit:

Links:

References

--

--

Joel Wembo

I am a Cloud Solutions Architect at prodxcloud. Expert in AWS, AWS CDK, EKS, Serverless Computing and Terraform. https://www.linkedin.com/in/joelotepawembo