I need remote access to the company's resources, now, now. The situation is what it is... Something needs to be done quickly!
What if I told you that you were going to DA! ONLY, NOW, using Amazon Web Services (AWS) cloud.
The idea was born to me because of the situation around us and all the confusion around the urgent need to send workers to work from home.
One of the challenges is, of course, the need for cooperation, although in Poland this word is associated not very positively, so maybe let it be efficient communication.
There are a lot of solutions available, such as MS Teams, Slack, Zoom and others. Some more GDPR friendly others willingly pick up our data and others giving different security options.
But one more topic is access to the company's internal systems, those that are not available directly from the Internet. In this case, we need to ensure secure connections to the still running DataCenter infrastructure and applications running there.
This case I just decided to take on the wallpaper. This is so important for those who do not have any solution and urgently need to do something.
AWS Cloud Remote Access
That's the idea that came to my mind? Let's take the cloud and try to provide remote access to resources in the local Data Center.
Because I don't have my own Data Center, I assimilated such an environment in the AWS cloud.
I have my “cloud” pretending to be the usual ON-PREMISES DC, in which some application is running.
The application, of course, is not available to the public from the Internet, but only from the company's private network.
So next year I prepared a piece of AWS infrastructure where I will host a remote access solution.
For this, I created a piece of space in the Virtual Private Cloud (VPC) service, which is such a “virtual” Data Center in the cloud.
About this and other AWS services you will learn from my ebook - 5 AMAZON WEB SERVICES, which is worth knowing.
IP address in my Data Center is 10.100.0.0/16, so in order not to have problems with routing for VPN I allocated network block 10.150.0.0/16.
I've set up a secure encrypted VPN connection that is available through VPC. This connection is between the edge router in DATA CENTER and my environment in AWS.
AWS connection to local DATA CENTER
Now comes the most important element of the puzzle, that is, our employee, who works at home and wants to connect to the APP server, which is located in DATA CENTER.
You need a solution that allows you to securely and control connect to the VPN_INFRA infrastructure and then through a VPN tunnel to APP applications.
Thinking for a while, it can be done in several ways.
One of them is probably putting up a virtual machine, installing OpenVPN. Of course, you need to instate everything and configure it from scratch. Plus there are issues of maintenance, high availability, etc.
The second option may be the installation of a ready-made solution, which are offered under AWS Marketplace. Here are solved companies Baracuda, Cisco and others (including even those based on OpenVPN).
The third option is to search for some solution based on AWS services.
How to get to APP?
AWS VPN Client
That's how we came to the candidate for remote access.
AWS Client VPN, is a remote access service to resources running in the AWS cloud, and those located in the on-premises Data Center.
The basic properties of services are:
Fully managed by AWS, the user side remains the configuration according to needs,
Secure TLS connection using OpenVPN client provided by AWS,
Authentication using Active Directory or certificates,
Granular control at both network and permissions level,
Integration with other services like AWS Active Directory or VPC.
Preconfiguration for AWS Client VPN
So let's move on to the configuration. For this purpose in VPC, I will create something called Client VPN Endpoint.
In my example, for simplicity, I will use the authentication method based on a certificate.
Therefore, first of all, I need to generate two certificates - for the server and for the client.
To do this, I will download a simple easy-rsa OpenVPN tool.
Then I go to the directory and one in turn, initialize the PKI environment and create CA - certificate authority.
. Easyrsa init-pki
. /easyrsa build-ca nopass
Then I create a server certificate:
. /easyrsa build-server-full server nopass
And also a certificate for the client:
. /easyrsa build-client-full client1.vpn.lukado.eu nopass
Then, for convenience, he will copy all the files to one folder to facilitate further configuration.
cp pki/ca.crt ~/Downloads/lukado_vpn/
cp pki/issued/server.crt ~/Downloads/lukado_vpn/
cp pki/private/server.key ~/Downloads/lukado_vpn/
cp pki/issued/client1.vpn.lukado.eu.crt ~/Downloads/lukado_vpn/
cp pki/private/client1.vpn.lukado.eu.key ~/Downloads/lukado_vpn/
Now I have everything ready to go to the configuration on the AWS side.
To begin with, you need to import the certificates you created before the moment. On the AWS platform, there is a dedicated service for managing and distributing certificates - AWS Certificate Manager (ACM).
AWS Client VPN and many other services integrate into a certificate manager and can use the certificates that are there.
To make it faster I use aws cli to import certificates into ACM.
aws acm import-certificate file: //server.crt —private-key file: //server.key —certificate-chain file: //ca.crt —eu-central-1 region
aws acm import-certificate —certificate fileb: //client1.vpn.lukado.eu.crt —private-key fileb: //client1.vpn.lukado.eu.key —certificate-chain fileb: //ca.crt —eu-central-1 region
aws acm list-certificates —eu-central-region 1
Cerfytikaty have been imported, so I can now move on to the basic configuration.
AWS Client VPN Configuration
Client VPN configuration is performed as part of the VPC service (I am operating in the Frankfurt region this time). On the left side at the bottom is the Client VPN Endpoints section where I will create a new endpoint.
The first part is, as usual, a name plus a description, and a circle of IP address that will be allocated to VPN clinets. Of course, this scope should not coincide (routing issues) neither with the VPC, to which we will join, nor with the IP address in the Data Center.
I chose 10.200.0.0/16
Next, in the Authentication Information section, I select “Use mutual authentication” and indicate the imported server and client certificates.
In addition, you can still enable the collection of logs to CloudWatch, and optionally specify such things as:
Transport protocol - here I do not change anything UDP in this case works better,
Enable split-tunnel - when there is a need to divide which traffic goes through the VPN tunnel and which one independently.
VPC ID - in addition, you can associate immediately with VPC, I will do it later.
VPN Port - I leave 443 by default.
Finally, my configuration looks like below (min. needed for operation):
When Endpoint is created, it's time to bind Endpoint to VPC and subnet. In the Association tab we add VPC and Subnet. When you click Associate, you sometimes have to wait a bit.
Further, in order for customers to use the resources you need to authorize them for this. For this purpose, in the Authorization tab I will create two configurations.
The first is access to VPC VPN_INFRA space, i.e. to 10.150.0.0/16 network.
If I used the authentication method “Use user-based authentication” then I could specify the group of users who can use this rule.
The second is access to Data Center resources - that is, to the network 10.100.0.0/16
To get to the Data Center resources, you still need to go to the Route Table tab and add an entry that the network 10.100.0.0/16 has to go to the subnet with VPC to which Endpoint is associated.
You should also remember the ditribution or appropriate entries in the routing table on the DATA CENTER side to direct traffic to the VPN client network (in this case 10.200.0.0/16) through the VPN tunnel to AWS.
That's all when it comes to configuration on the AWS side. It remains to download the configuration to the client and, of course, download and install the AWS Client VPN application itself.
Before I can connect to the execution, there are two more steps:
First, the VPN file and the client's certificate and key must be in the same directory. I moved the configuration file to my directory with certificates: ~/Downloads/lukado_vpn/
Secondly, you need to edit the configuration file and append the tool to the certificate and key. At me it:
cert ~/Downloads/lukado_vpn/client1.vpn.lukado.eu.crtkey ~/Downloads/lukado_vpn/client1.vpn.lukado.eu.key
Modify the endpoint address by adding something at the beginning. To do this, we are looking for something like this:
remote cvpn-endpoint-0d069d2a422b060c1.prod.clientvpn.eu-central-1.amazonaws.com 443
and I change it to something like:
remote lukado.cvpn-endpoint-0d069d2a422b060c1.prod.clientvpn.eu-central-1.amazonaws.com 443
Now it remains to save the file, launch the client, import the configuration and make the connection.
We managed to connect, so I'm checking to see if I can access the server at Data Center...
As you can see works 😎
As I mentioned, my Data Center is also in AWS 👍
AWS Client VPN - fast and not too complicated solution for remote access.
As you can see, you can easily and quickly configure a remote VPN connection using AWS Client VPN.
Which, certainly, in today's situation, can be quite interesting. No waiting, no installation of equipment and mass purchase of licenses.
Certainly, at a larger scale, integration for Active Directory should be considered for better access and user management.
In addition to Authorization Rules, Security Groups can be used to control and flow of connections.
And so far, that's it. Cheers 😎