Creating a Hybrid Data Centre with OpenVPN

Written on Mon, 19 December 2016

Setting up a hybrid data centre comprising of on-premise data centre and cloud data centre isn't a difficult task. You do, however, need some knowledge of networking before you proceed with this tutorial. In this tutorial, I'll be focusing on AWS as the cloud provider.

Having hybrid data centre is like having best of both worlds, but do take note that you will also have the worst of both worlds.

Advantages

Data compliance - If you have a compliance to meet, having data stored on-premise will certainly help. Especially if it's critical data and infrastructure.
Cost Savings On-premise - This is only true in certain use-cases. A typical server rack can cost USD10 000 and potentially beyond. But if properly virtualised and containerised, you could run more than 100 virtual machines. Let's take a m4.large instance from AWS running Ubuntu. It will take you 10 years to your Return On Investment (ROI) for having on-premise server. But if you're running 2 m4.large, that's going to be a 5 year ROI for having on-premise server. The math goes on. After all, a typical server rack last for 5 years.
Cost Savings Cloud - This is also only true in certain use-cases. Let's say you only need a server for a short period of time, you could just spin up an AWS instance for just that period of time and pay for that time. This is only good if you don't have enough on-premise resource and don't intend to procure servers for just 1 cause. This is a good strategy where you launch enough cloud resources until procurement of a physical server is justified. That way, you don't need to plan ahead, and just procure equipments whenever cost is justified.
Agility - Having a cloud provider gives you agility to have a server instance within seconds. Procurement of server racks take days, in some cases weeks and months, if you have multiple company management approvals to obtain.
Ease of Management - You don't need to have expertise to manage cloud data centre, apart from your on-premise data centre. Those are taken care of by the cloud provider.
Innovation Leverage - Whenever the cloud provider innovates their product, you can take advantage of the innovation as well. AWS is innovating at an average of 3 innovation per day in 2016. This rate of innovation is seriously unheard of.
Reliability - A data centre like AWS typically have more backup systems in place than a typical SME. For instance, they would have multiple backup generator that an ensure service continuity in the event of prolong blackouts while you would most likely have 1 backup battery that only last 20mins. AWS also have Availability Zones(AZ) which has independent internet connections and power supply. It's simply an isolated data centre per zone. If you build your application to run across multiple AZ, you will have greater reliability. Compared to your on-premise data centre, which is likely just a physical location, having multiple data centre will increase reliability.

Disadvantages

HR Cost - You still need manpower to manage your on-premise data centre. If you're managing many physical servers, then it would make financial sense. Otherwise, you are better off running the your applications in the cloud where the expertise are already in place to maintain the physical servers.
Configuration Nightmare - If the network is not properly set up, you are going to have a nightmare trying to get your applications to communicate. In some cases, this is going to cost your business.

Preparing AWS

Let's prepare the cloud data centre to a specific configuration. If you need a different configuration, you may deviate from this tutorial. But if you're just starting out, I recommend that you follow through this tutorial before setting up your own network configuration.

The network configuration is done in such a way that there is a public subnet and a private subnet per Availability Zone (AZ). I assume that you do not want some applications to have public address, therefore, a private subnet would be suitable for such applications. I'm using Northern Virginia Region with 4 AZ, so that means I will have a total of 8 subnets. I'm only entitled to Zone A/C/D/E, so my tutorial will feature these zones. The AZs available to you might be different, so adjust the commands accordingly as you follow through. You will also need different subnets if you are using AWS features like Aurora, which requires at least 3 different AZ for it to work.

Create the VPC

I've created a VPC named MyAwesomeVPC with the network of 10.0.0.0/16.

Create the Subnets

Let's create the 8 subnets to use. I usually name my subnets properly, such as [Name-Zone-PublicOrPrivate]. If you ever scale your data centre, a good name will help ease administration.

Here's my list of subnets created:

Subnet0-ZoneA-Public
- 10.0.0.0/24
Subnet1-ZoneA-Private
- 10.0.1.0/24
Subnet2-ZoneC-Public
- 10.0.2.0/24
Subnet3-ZoneC-Private
- 10.0.3.0/24
Subnet4-ZoneD-Public
- 10.0.4.0/24
Subnet5-ZoneD-Private
- 10.0.5.0/24
Subnet6-ZoneE-Public
- 10.0.6.0/24
Subnet7-ZoneE-Private
- 10.0.7.0/24

Now that we are done creating all the subnets in their respective AZ, so proceed.

Creating Internet Gateway

The internet gate allows instances created in the subnets to have internet access. Let's create an internet gateway and assign it to our VPC.

Creating Route Tables

Route tables allow proper network routing within the VPC. We will need 2 routing tables, one that has internet access and the other that doesn't.

In the first routing table, we make a public one named MyAwesomeVPC-Public and associate the subnets to it:

Subnet0-ZoneA-Public
Subnet2-ZoneC-Public
Subnet4-ZoneD-Public
Subnet6-ZoneE-Public

Now, under routes, let's add the internet gateway we created before. The destination is 0.0.0.0/0, which implies all IP. Internet Gateway ID starts with igw-.

The second routing table will be a private on named MyAwesomeVPC-Private. These are the subnets to associate it with:

Subnet1-ZoneA-Public
Subnet3-ZoneC-Public
Subnet5-ZoneD-Public
Subnet7-ZoneE-Public

We don't add the internet gateway because these subnets will not have internet.

We are done for now. We will be back here after we set up a VPN server.

Setting up OpenVPN server

We are going to set up an OpenVPN Server on Ubuntu 16.04. In most cases, a t2.nano server is enough. Upgrade the instance type if you experience hitting your credit limits regularly. You will also just be installing the server software. There is no storage of data for the traffic. The default 8GB HDD storage is more than sufficient.

The ports required for OpenVPN Server is only 22 for SSH, and TCP/UDP port 1194. If you are certain that your VPN clients will only use either TCP or UDP, you can specify only to allow one of it accordingly. For this tutorial, let's enable both. It's not a major security hole at this point in time anyway.

Don't forget to assign an Elastic IP to ensure your IP doesn't change for any reason.

All Linux/Ubuntu commands are running with root account. If you're not running root account, be sure to add sudo before every command.

sudo su

Update Ubuntu softwares to the latest version and reboot the instance.

apt-get update && apt-get -y dist-upgrade && reboot

Install OpenVPN server and it's related softwares.

apt-get install openvpn easy-rsa

Certificate Authority

Set up a Certificate Authority(CA) directory.

make-cadir ~/openvpn-ca

Configure the CA values

cd ~/openvpn-ca
nano vars

Search for the following and edit the values accordingly. You could leave it as default.

export KEY_COUNTRY="US"
export KEY_PROVINCE="CA"
export KEY_CITY="SanFrancisco"
export KEY_ORG="Fort-Funston"
export KEY_EMAIL="me@myhost.mydomain"
export KEY_OU="MyOrganizationalUnit"

Do not close this file yet. Search for the next configuration:

export KEY_NAME="EasyRSA"

Change it to:

export KEY_NAME="server"

Now save and close the file

Source the vars file:

source vars

You should see this once completed:

NOTE: If you run ./clean-all, I will be doing a rm -rf on /root/openvpn-ca/keys

Time to clean up:

./clean-all

Now build root CA:

./build-ca

Just hit enter as it prompts you for input. The values should be the same as what you typed in the configuration.

Now generate Server Certificates, Key, and Encryption files.

./build-key-server server

You can leave most of the input as default. When you are asked to sign the certificate and commit, choose y.

Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

Let's generate a strong Diffie-Hellman keys to use during key exchange by typing:

./build-dh

This may take some time, so grab a cup of tea.

Generate a HMAC signature.

openvpn --genkey --secret keys/ta.key

Generating Clients

Now let's generate client keys. You can repeat this step as many as you need for the number of clients you have. I recommend generating a few more than what you have. Each time you generate new clients, you need to restart OpenVPN server for the new clients to take effect, which can be disruptive to existing connections. If you are generating more than 1 client, be sure to use unique names.

cd ~/openvpn-ca
source vars
./build-key client1

You can leave the inputs as default. Password is not required so that you can have automated access. Sign the certificate and commit with 'y'.

Configuring OpenVPN

Now we configure OpenVPN with the files we have generated. Copy them to /etc/openvpn

cd ~/openvpn-ca/keys
cp ca.crt ca.key server.crt server.key ta.key dh2048.pem /etc/openvpn

Get the sample OpenVPN configuration file into configuration directory so that we can use it as a basis for our setup:

gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz | sudo tee /etc/openvpn/server.conf

Configure the openvpn server file we have just unzipped:

nano /etc/openvpn/server.conf

I personally prefer TCP instead of UDP, so find and set the following:

proto tcp

For administrative purposes, I prefer to keep OpenVPN client subnet number equal to host subnet +1. Since our VPC is running on 10.0.0.0/16, I want my clients to be on subnet 10.1.0.0/16. You can leave this as default if you prefer.

server 10.1.0.0 255.255.0.0

In my set up, I allow the clients to communicate with each other. If your set up disallows it, leave this configuration commented out.

client-to-client

Let's ensure all traffic can be routed to 10.0.0.0/8. Otherwise, a connection without ability to access other host in the VPC is not very productive in our use case.

push "route 10.0.0.0 255.0.0.0"

Uncomment the following, and add the additional configuration if it doesn't exists:

tls-auth ta.key 0 # This file is secret
key-direction 0

Uncomment the following encryption type:

cipher AES-128-CBC

Add the following just below the encryption you just uncommented:

auth SHA256

Now uncomment the following:

user nobody
group nogroup

You are done with OpenVPN configuration. Save the file and close it.

Networking Configuration

Let's adjust some networking configurations to ensure network traffic is properly forwarded.

nano /etc/sysctl.conf

Uncomment the following:

net.ipv4.ip_forward=1

Save the file and do the following command to read the new settings:

sysctl -p

Firewall and NAT configurations

I assume that your public network interface is eth0. You will need to edit your /etc/ufw/before.rules file to add in relevant configurations.

nano /etc/ufw/before.rules

Now add the follow codes at the top of the file. It is important that these codes are added before the rest of the existing rules.

# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.1.0.0/8 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES

Save the file and close. Now we edit /etc/default/ufw.

nano /etc/default/ufw

Find this code:

DEFAULT_FORWARD_POLICY="DROP"

Change it to:

DEFAULT_FORWARD_POLICY="ACCEPT"

Save the file and close. We enable the relevant ports open in the firewall.

ufw allow 1194/udp
ufw allow 1194/tcp
ufw allow OpenSSH

Let's restart the firewall.

ufw disable && ufw enable

Start OpenVPN Server

Let's start OpenVPN server.

systemctl start openvpn@server

You can check the status of the server with:

systemctl status openvpn@server

You can also check the IP of the tunnel server with:

ip addr show tun0

If you're satisfied with all the configuration you've done, proceed to enable OpenVPN to autostart during boot.

systemctl enable openvpn@server

Configure VPC Routing

Now that we have created the OpenVPN server, we must update VPC to route traffic to 10.1.0.0/16 properly. You must do this for MyAwesomeVPC-public and MyAwesomeVPC-private. You will need to get the Network ID of the EC2 hosts. Network ID starts with eni-.

Then under your VPC Route Table, set 10.1.0.0/16 to the Network ID on both tables, public and private.

Now, your VPC EC2 instances will be able to communicate with your clients.

Configure OpenVPN clients

So now that we have set up the server, let's make sure the client works too. First of all, we need to get the client files we generated from the server. If you have followed this tutorial closely, the files you need should be located at:

~/openvpn-ca/keys/client1.key
~/openvpn-ca/keys/ta.key
~/openvpn-ca/keys/client1.crt
~/openvpn-ca/keys/ca.crt

Download them with any softwares that allows you to download from the server. Personally I use filezilla to download via SFTP.

I'm using Windows, so if you're using other OS, adjust accordingly. There are guides for OSX, Ubuntu, Android, and iOS.

Download and install Windows Client

Download OpenVPN client. I recommend getting 64bit, because it's the future. And my tutorial will be based on 64bit. Use the latest stable version, unless you know what you're doing.

The installation will be very straight forward. Leave the installation folder as default, which is C:\Program Files\OpenVPN. Agree to the terms and conditions, which is just simply, if anything screws up, don't fault OpenVPN. But so far, OpenVPN is running smooth for me and many others on the planet. So you should be fine too.

Client Configurations

Your OpenVPN should be installed in C:\Program Files\OpenVPN. Go to C:\Program Files\OpenVPN\config and create a folder called keys. Remember the 4 files you downloaded from OpenVPN server? Move client1.key, ta.key, client1.crt, and ca.crt to C:\Program Files\OpenVPN\config\keys.

Now go back to C:\Program Files\OpenVPN\config and create a file called MyAwesomeVPN.ovpn. Paste the following, but replace the server IP address with yours:

client
resolv-retry 20
keepalive 10 60
nobind
mute-replay-warnings
ns-cert-type server
comp-lzo
max-routes 500
verb 1
persist-key
persist-tun
dev tun
proto tcp
port 1194
cipher AES-128-CBC
auth SHA256
key-direction 1
cert keys/client1.crt
key keys/client1.key
ca keys/ca.crt
tls-auth keys/ta.key
remote 12.34.56.78 1194 # This is your server IP address and port
#redirect-gateway def1 # Only enable this if you want to route all traffic through OpenVPN server

Now in your OpenVPN taskbar icon, when you right-click on it, you will see that you have MyAwesomeVPN to connect to. Connect and make sure it works.

That's it! Now you have a data centre on the cloud that works like your own data centre. You access your server instances like normal Local Area Network(LAN) IP address. But wait, didn't we talk about hybrid data centre where you connect your on-premise data centre to your cloud data centre? Fret on, the steps for setting that up is very similar to how you do on Windows Client. In most cases, you need an extra hardware. Proceed to further reading for more information.

Conclusion

OpenVPN is a very powerful tool you can use to establish remote connections to work virtually in the office. While setup may be a little complicated, it is usually a one time event. Add to the fact there there are applications like Untangle that drastically simplfies your setup, this is easily the best VPN solution around.

Creating a Classroom Suite with Moodle and BigBlueButton

Build yourself a Comprehensive Business Suite with Odoo