AWS Client VPN Implementation for Private Networks
Tags: aws, networking, cloud, tutorial
Published: 2024-01-25 13:50:03

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

![The Architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wn46bv3pu1tna5s0hgcb.png)

## 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](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html)

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](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html)

### Transit Gateway

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

[Creating the Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html#step-create-tgw)

**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. 

![Transit Gateway](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q2666xu7n1q4u52ys08y.png)

### Resource Access Manager (RAM)

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

[Transit Gateway Resource Sharing](https://repost.aws/knowledge-center/transit-gateway-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](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#create-vpc-attachment)

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. 

![TGW Attachments](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/09719gfkupn2jmi7zhc0.png)

### 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](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)

![VPC RT](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vicgow4hjc0hzs68rorz.png)

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](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html#create-tgw-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. 

![TGW RT](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k150f7u2g6andu2nlj38.png)

#### 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](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html#associate-tgw-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.

![TGW Propagations - SS](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u3e4j8vb26wnwt8vnv7m.png)

In the _Routes_ Tab, it will then add the advertised routes which you can see as _Propagated_ in the _Route Type_ column.

![TGW Routes - SS](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3i70grt94wbv6akua4l3.png)

**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. 

![TGW Propagation - W](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jcgwlrxophjhxcjr0gj2.png)

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](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/mutual.html) 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. 

![CVPN - AR](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9e5ml785quyga8lvuwt8.png)

#### 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

![CVPN - RT](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5qnv5z4ttc7gip7j3kcs.png)

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](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-working-endpoint-export.html#export-client-config-file)

[Configure AWS VPN Client Configuration](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/connect-aws-client-vpn-connect.html)

<br/>
__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](https://dev.to/edwardmercado)
[Twitter](https://twitter.com/edwardmercado_)
[LinkedIn](https://www.linkedin.com/in/edwardallenmercado-677b69139/)