VPN - Setting up OpenVPN Server - Part 1
We’re all lazy, aren’t we? If you think about it for a
second, everything you do is more or less aimed at making your life easier,
simpler and less-time consuming. Think about your last project. What were you
more concerned about: polishing every little detail or maybe getting some stuff
done as soon as possible due to an incoming deadline?
We’ve all been there and we all know that feeling. Even if
you try to be perceived as your colleagues and clients as the most hardworking
admin around, at the end of the day you, after setting up 20 virtually
identical VMs, you’re probably thinking “How could I get this done faster next
time?”, less likely “Have I checked everything on #13 before pushing it into
production?”.
Well, we all do. We all look how to get even a smallest bit
of work off our back.
Do you remember your last trip to commsroom? Don’t you think
it would be so much easier to connect to some kind of relay that would transfer
the commands you’re typing in on your home laptop to the corporate network back
at work? If only such a relay would be possible…
Wait a second - it is possible. It’s a VPN server we need.
Before continuing, I highly recommend reading my previous post about setting up a vRouter on a Linux VM. The tutorial part of this article is going to be based around similar system.
Table of Contents
I. Virtual Private Network – Intro
II. Virtual Private Network – The Basics
III. Virtual Private Network – Technical Overview
IV. Setting up OpenVPN server on Linux vRouter
I. Virtual Private Network – Intro
Our story begins in 1996, when a Microsoft employee
developed PPTP (peer-to-peer tunnelling protocol). PPTP alone wasn’t what we
would consider a VPN-ish solution by today’s standard – it did not provide any
sort of encryption or user authentication whatsoever. Creating a secure network
link with PPTP required setting up additional security checks based on either
PAP or CHAP protocols.
However, if we look past PPTP flaws, it was indeed one of
the first network protocols capable of transferring data between two or more
remote private networks (inter-connected via the internet) as if they were all
a part of single LAN. At the time this protocol was revolutionary, letting
companies connect all of their internal networks into a single, centralized
intranet without investing in extremely expensive dedicated link provided by an
ISP.
As the years went by, PPTP users started to look for more
secure alternatives. While end-client security wasn’t a big concern back then
(people had waaaay more trust in their AV software at the time), network admins
were trying to find a way to secure traffic during the transfer itself
(sniffing, man-in-a-middle attacks etc.). Two technologies originating from
that period and still being used today are SSL and IPsec
The VPN flavour we are going to look into in this post is
OpenVPN – based mostly on SSL/TLS. Because of its custom security protocol born
from a mix both of these encryption standards, OpenVPN is considered one of the
most secure, if not the most secure VPN software on the market.
II. Virtual Private Network – The Basics
OpenVPN is an open source VPN implementation used mostly for
creating secure point-to-point or site-to-site connections. You can see the
difference between the two on the diagram below. To simplify the setup, we are going to assume the routers in both network have a VPN server functionality.
As you can see, in a
point-to-point (P2P) VPN setup, users connect to the main office - mostly using
dedicated clients – through a VPN gateway (office router), while the remote
site sends the return data as if it was regular traffic within LAN. The VPN
gateway (router) has been configured to “distinguish” traffic sent to the hosts
connected directly to LAN and traffic sent to hosts connected to VPN – the
latter receive appropriate packet tags before being put through to the
Internet. This setup ensures only the selected users can connect to the site
from the Internet – a double edged sword to be honest. Network admin doesn’t
have to worry about unauthorized users getting access to remote site resources
from outside the network, while on the other hand, users who are authorized to
do so, need to be trained in VPN client usage (at minimum).
Site-to-Site (S2S) setup is a little
bit more complicated – in this setup, we are connecting two (or more) sites
with each other, creating single virtual LAN (not to be confused with
vLANs/vNetworks VMware terms). The traffic is getting routed between the
gateways directly, meaning the end-users don’t even have to know they are being
a part of a VPN. That’s obviously, a huge advantage, but at the same time this
requires the network admin to secure restricted resources on a system level.
In this post we are going to have
an in-depth look on both of these situations (and deploy an OpenVPN VM for
each), but for the time being the summary above should suffice.
III. Virtual Private Network – Technical Overview
In a nutshell, VPN connection is
established between two or more parties - both connected to the Internet. On top
of user authentication, modern VPN setup usually includes a strong end-to-end encryption to
avoid data leaks “between” users.
As mentioned above, OpenVPN is
considered the best (or one of the best, depending on who you ask) VPN software
available. It’s main advantage over IPsec-based solutions is its security
(SSL/TLS mix) and flexibility – while IPsec uses specialized ports &
network protocols, OpenVPN relies only on common UDP/TCP ports. This is highly
desirable with restrictive ISPs or countries disallowing the use VPNs, as while
IPsec can be easily disabled without disturbing regular online activity, doing
same with OpenVPN would be highly difficult if not impossible.
The most basic OpenVPN setup between a client (remote) and a server (local) requires the
following:
- First and foremost, Internet access on both sides of the VPN link
- Individual (not shared between multiple sites, i.e. NATed) public IP or DDNS address on WAN-facing router interface in the local network
- Router with OpenVPN support or dedicated machine for VPN (VPN server) in the local network
- S2S only: Public IP (again, not NATed) or DDNS address on WAN-facing router interface in the remote network
- S2S only: OpenVPN-enabled router in the remote network or a dedicated machine for VPN (server)
- Certificate/secret key authentication for P2P remote users
- SSL authentication between the sites in S2S setup based on CA-level certificate ("HTTPS" certificate bought from ISP or provider such as GoDaddy, Let's Encrypt etc.)
- Secure VPN portal for easier rollout for new P2P remote users
- Service over VPN (DNS, Active Directory, SMB)
In the following tutorial we are going to look into the "basic" P2P OpenVPN setup. Advanced features and S2S are going to be described in another post (coming soon).
IV. Setting up OpenVPN server on Linux vRouter
1. Preparation
Before starting the actual setup of an OpenVPN server in our network, we need to plan things out a little bit. First major thing to consider is networking. Frankly speaking, VPN is just another network which your users are going to access. This means we need to plan how big we need it to be as well as where to "include" it in the subnet environment.
Let's say your local network in the office is operating on the most common B-level private subnet 172.18.x.0/24. In this case, it is recommended to setup the VPN on A-level 10.x.x.0 subnet or different 172.18.x.0 network. What you need to avoid is having your clients connect to the VPN from the same subnet as the one used in either your local network or VPN. Keep in mind you can safely assume most of the users are going to use their VPN clients from either home LAN or services such as open WiFi hotspots, which are probably based on 192.168.x.0/24.
2. Installation
Firstly, let's update our system:> sudo apt-get update
> sudo apt-get upgrade
Next, we'll need to download the OpenVPN & Easy-RSA (encryption):
> sudo apt-get install openvpn easy-rsa
And that's it - we have our base services installed. Now it's time to configure them.
3. Configuration
3.1. Server.conf
We are going to use the sample OpenVPN configuration file as template. We can get it extracted to /etc/openvpn/server.conf by running the following:
> gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf
Open it up with nano or other text editor of your choice:
> nano /etc/openvpn/server.conf
For a basic OpenVPN setup, we need to do the following changes (in red):
a) double RSA key length for stronger encryption - replace dh dh1024.pem with dh dh2048.pem
# Substitute 2048 for 1024 if you are using
# 2048 bit keys.
dh dh2048.pem
b) enable traffic redirection so the server passes clients web traffic to correct destination by uncommenting ;push "redirect-gateway def1 bypass-dhcp" (remove ';' character)
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
push "redirect-gateway def1 bypass-dhcp"
c) push OpenDNS servers' IP addresses as DNS settings for clients (to prevent leaks outside DNS connection) by uncommenting push "dhcp-option DNS 208.67.222.222" and push "dhcp-option DNS 208.67.222.220" (again, remove the ';' character)
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
# The addresses below refer to the public
# DNS servers provided by opendns.com.
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
d) set OpenVPN to run as unprivileged user by uncommenting user nobody and group nogroup (OpenVPN server runs by default as root - we don't need that)
# You can uncomment this out on
# non-Windows systems.
user nobody
group nogroup
e) enable TLS authentication by uncommenting tls-auth and adding key-direction 0
tls-auth ta.key 0
key-direction 0
f) select AES128 CBC cipher by uncommenting AES-128-CBS and adding auth SHA256
cipher AES-128-CBC
auth SHA256
Save your changes and exit the editor (if using nano - CTRL+X and double 'y')
The next step is not needed if you're using the vRouter VM from my previous post (skip to 3.3).
3.2. Port Forwarding
As VPN is based on forwarding packets from clients to the server (and vice-versa), we need to make sure our OpenVPN VM has that option enabled in the system. You can check that by running:
> cat /proc/sys/net/ipv4/ip_forward
Getting 1 as a result means the IP forwarding is enabled, while 0 indicates it's disabled. In case the later is true, run the following:
> echo 1 > /proc/sys/net/ipv4/ip_forward
Alternatively, edit /etc/sysctl.conf and and uncomment the line #net.ipv4.ip_forward=1 (remove #) to make the change permanent.
3.3. Firewall - opening ports required by OpenVPN
a) Advanced setup - applicable if your VM have IPtables configured with /etc/iptables.rules backup file (just like the one in this post)
Open up IPtables backup file:
> sudo nano /etc/iptables.rules
Add the following line to the filter (replace eth0 with your LAN-facing interface name):
*filter
(...)
-A INPUT -i eth0 -p udp -m udp --dport 1194 -j ACCEPT
(...)
-A INPUT -i eth0 -j DROP
Save and close the file (CTRL+X) and refresh the rules in the system:
> sudo iptables-restore < /etc/iptables.rules
b) Simple setup - UFW; applicable if you're setting up OpenVPN server on a new system
Install ufw package (simple firewall manager):
> sudo apt-get install ufw
Open the required ports by running:
> sudo ufw allow 1194/udp
Finally, apply the changes to the firewall by running:
> sudo ufw disable
> sudo ufw enable
3.4. Server & client RSA certificates
3.4.1 Setting up CA directory & basic variables
As OpenVPN is an TLS/SSL VPN, we need to setup an encryption for our traffic.
To begin, we can copy the easy-rsa template directory into our /home and move into it:
> sudo make-cadir ~/openvpn-ca
> cd ~/openvpn-ca
Now it's time to configure the CA (Certificate Authority) variables. Easy-RSA will use those values for identifying our server. We can set them in ~/openvpn-ca/vars
> sudo nano vars
We need to edit only the most basic variables for our OpenVPN server to work:
export KEY_COUNTRY="US"
Change US to your country ID (i.e. PL, IE, DE)
export KEY_PROVINCE="CA"
Change CA to your province (ND, SD, NY, WLKP etc.)
export KEY_CITY="SanFrancisco"
Change SanFrancisco to your city
export KEY_ORG="Fort-Funston"
Change Fort-Funston to your company/organization
export KEY_EMAIL="me@host.mydomain"
Change me@host.mydomain to your email address (optional; mostly needed while getting a Global SSL certificate from CA authorities such as LetsEncrypt, GoDaddy etc.)
export KEY_OU="MyOrganizationUnit"
Change MyOrganizationUnit to your department (i.e. IT, Accounts)
Remember you need to fill every single one of the values above. Do not leave them blank under any circumstances.
Once finished, press CTRL+X to save changes and close the editor.
3.4.2 Building the CA
Run the following command to source the vars file you just edited:
> sudo source vars
You should see the following if it was sourced correctly:
Output
NOTE: If you run ./clean-all, I will be doing a rm -rf on /home/(...)/openvpn-ca/keys
At this point we want to make sure we're operating in a clean system, so let's run:
> sudo ./clean-all
Now, we can build our root CA by typing:
> sudo ./build-ca
Since we already filled in all required info in the vars file, you can safely press ENTER through the prompts to confirm default selections.
3.4.3 Creating Server certificate & encryption files
Now we are going to generate all the certificates and encryption files needed for securing OpenVPN connections between our server & the client machines.
Start by generating the OpenVPN server certificate and key pair by running:
> sudo ./build-key-server server
You can safely press ENTER on all prompts as we filled the vars file before.
There are going to be two additional questions (regarding challenge passwords) at the end of this process. We are not going to go through them in this guide, so leave them blank for now by pressing ENTER twice.
Next, we are going to generate Diffie-Hellman keys (used during key exchange), by typing:
> sudo ./build-dh
Afterwards, we are going to generate an HMAC signature to strengthen the server's TLS integrity verification capabilities:
> openvpn --genkey --secret keys/ta.key
3.4.4 Client Certificate & key pair
For the sake of simplicity, we are going to generate the client certificate on the server side, however it is possible to the same on client's machine and then sign it. We are going to generate a single certificate/key pair, but if your setup includes more than one client, feel free to repeat the steps below as many times as needed (remember to replace client1 with a different name for each cert).
If you don't want the client to use additional password, use the build-key command in the next step. Otherwise, replace it with build-key-pass.
> cd ~/openvpn-ca
> source vars
> sudo ./build-key client1
Press ENTER for every question. Remember to leave challenge passwords blank.
3.5 Finishing up the configuration
To finish up the setup, copy all the files we created in the previous step to /etc/openvpn
> cd ~/openvpn-ca/keys
> sudo cp ca.crt ca.key server.crt server.key ta.key dh2048.pem /etc/openvpn
Now we can start the OpenVPN service by running:
> sudo systemctl start openvpn@server
Finally, make sure the OpenVPN service starts at boot:
> sudo systemctl enable openvpn@server
V. End Notes
Part 2
So that would be it then. I hope your OS won't crash today,
P.W.
