In the dynamic landscape of cloud computing, seamless and secure connectivity is paramount for organizations managing private networks. As businesses harness the power of AWS (Amazon Web Services), establishing a robust and secure communication channel becomes essential to access resources in a private network from virtually anywhere. Enter AWS Client VPN, a versatile solution that bridges the gap between remote users and private networks, ensuring a streamlined and secure connection.

Scenario

Imagine a complex network landscape where the need for a seamless and secure solution is paramount. Picture a scenario where all traffic must flow seamlessly from a dedicated Network or Shared Services AWS account to various private networks or Virtual Private Cloud (VPC) residing in different AWS accounts, aptly named as workload accounts.

Each workload account boasts its own set of computing resources, necessitating strict isolation from one another. In this intricate web of connectivity, only the Network or Shared Services account should wield the power to communicate with each workload account. The catch? Workload accounts must remain oblivious to one another's existence, ensuring airtight segregation.

This connectivity conundrum doesn't stop there – these workload accounts might find themselves dispersed across different AWS regions, adding an extra layer of complexity to the puzzle.

The Architecture

Setup

Now that we've laid eyes on the architectural diagram, it's time to roll up our sleeves and dive into the nitty-gritty of setting up the AWS services. This section is your backstage pass to the configuration wizardry that makes the entire system click.

AWS Organizations (Optional)

Let's create an AWS Organization, Ideally, in this scenario you will need to create another account which is called Management Account on where you will create this AWS Organization.

Creating and Configuring an Organization

You can then invite the Shared Services or Network account and each of the workload account to these organization.

Inviting an Account To Your Organization

Transit Gateway

We need create a Transit Gateway in the Network or Shared Services Account.

Creating the Transit Gateway

Note: Make sure to disable the Auto accept shared attachments, this is for the best practice, and when we share this Transit Gateway later using Resource Access Manager to the other accounts, the account needs to accept the shared resource.

Resource Access Manager (RAM)

We will use Resource Access Manager to share the Transit Gateway to each workload accounts.

Transit Gateway Resource Sharing

Transit Gateway Attachments

Now that the Transit Gateway has been seamlessly shared with the workload accounts, the next step is to establish the vital connections through attachments. Attachments play a pivotal role in associating the Transit Gateway with specific subnets within each Virtual Private Cloud (VPC).

Create a Transit Gateway Attachment to a VPC

If your architecture spans multiple workload accounts, repeat the process for each one. This ensures a comprehensive and interconnected network across all relevant accounts.

Note: It is recommended to create a separate subnet on where you will place your attachment.

Once finished, all of the created attachments will be shown when you go back to Shared Services or Network account Transit Gateway Attachments Console.

VPC Route Tables

We now need to configure the routing of each VPC Route table in each involved Subnets in each AWS account. We need to point out the traffic that needs to be forwarded to the Transit Gateway.

We need to modify the VPC Route Table for each account involved.

Add or Remove Routes from a Route Table

For the sake of simplicity, we've used the 10.0.0.0/8 CIDR Block to cover the IP address ranges of all of the accounts.

In doubt that we will confuse the routing, we can still point the traffic later using the Transit Gateway Route Tables and the 10.0.0.0/8 CIDR Block is spread to all of the accounts without overlap.

Note: We need to modify the VPC Route Table for each account.

Transit Gateway Route Tables

Now that the traffic is pointing to the Transit Gateway, we now need to create the Transit Gateway Route Tables to manage the routing at the Transit Gateway level.

Go back to your Shared Services or Network Account, create Transit Gateway Route Table.

Create Transit Gateway Route Table

Note: We need to create a Transit Gateway Route Table for each of the account involved.

It should be like the below, where all of the Route Table are created inside the Shared Services or Network Account only.

Transit Gateway Route Table Associations

Once the Transit Gateway Route Tables are now created, we now need to associate them to the Transit Gateway Attachments we created in the previous step.

To put it simply, the Transit Gateway Route Table created for the Shared Services or Network account will be associated with the Transit Gateway Attachment we created for the account. This will be same for the workload account.

Associate a Transit Gateway Route Table

Transit Gateway Route Table Propagations

Now that we've associated the Transit Gateway Route Table to their respective attachments, we now need to create the Transit Gateway Route Table Propagations so the routes advertised in the Transit Gateway are dynamically added to the Transit Gateway Route Table Routes.

At least the dynamic propagation will be beneficial to the Shared Services or Network Account as it needs to learn the routes so it can communicate to each workload account.

Shared Services or Network Account

Select the Transit Gateway Route Table of the Shared Services or Network Account and go to the Propagations Tab then Create Propagation for each of the Workload accounts Transit Gateway Attachments. It will look like the below.

In the Routes Tab, it will then add the advertised routes which you can see as Propagated in the Route Type column.

Workload Account

We need to also create Propagations for each workload account but we only need to create propagations to the Shared Services or Network Account.

The routes will also be added dynamically but only the routes of the Shared Services or Network Account.

Client VPN

The Transit Gateway section is now finished, we now need to create the Client VPN.

For the sake of simplicity, we will use mutual authentication for the Client VPN.

During its creation, we need the below details:

• Client IPv4 CIDR
  This just needs to be a non-overlapping CIDR block from the CIDR blocks we’ve used earlier for the VPCs.

• Server Certificate ARN
  You can create this certificate using easyrsa, you can use this guide to generate a server certificate and upload this to the AWS Certificate Manager.

• VPC ID
  This needs to be the VPC ID to where you associated the Transit Gateway using the Transit Gateway Attachments.

• Security Group IDs
  The important is the Security Group that you associate with has an Outbound and is open to all traffic.

Once all the relevant configurations are filled, we can now create the Client VPN endpoint.

Client VPN Target Network Associations

In the creation of the Client VPN, we only specified the VPC where will be the Client VPN hosted. Using the Target network associations, you need to associate the same VPC and the subnets where you want the Client VPN endpoints created. We need to select the VPC Subnets we configured earlier that have been associated with the relevant VPC Route Tables.

You can only create one association per VPC subnet and it's okay to create an association per relevant VPC subnet.

Client VPN Authorization Rules

We need to create rules to grant clients access to networks. Here you can specify the CIDR block and you can granularly grant access to either Allow access to all users or Allow access to users in a specific access group.

For testing purposes, we’ve just added a 0.0.0.0/0 CIDR block to all networks.

Client VPN Route Table

We need create another Route Table in the Client VPN level to create routes for each CIDR block destination. Here you can specify the CIDR block and select the Subnet ID (this Subnet ID goes back to the selected VPC Subnet when we did the Target network associations) so if you created multiple Target network associates for multiple VPC Subnets, you will then need to create multiple Client VPN Route Table which is the best practice.

In this case, we’ve only created one Target network association and we use this to route to multiple VPC CIDRs

Finally, we’ve finished setting up the Client VPN and its network connectivity to all the accounts, we can now download and set up the AWS VPN Client on your machine.

Download AWS VPN Client Configuration

Configure AWS VPN Client Configuration

Follow for the next part of this article to learn on how to extend this solution to another AWS region

For any queries, you can reach me at:

Dev.to
Twitter
LinkedIn