A VPN, or Virtual Private Network, creates an encrypted tunnel between your computer and a remote server. This has two major advantages. First, you mask your real location because you will have the IP address of the VPN server. Second, all the traffic between your computer and the server is encrypted. So, if you connect to a public WiFi, your data remains safe even if it intercepted by someone. Similarly, your Internet Service provider cannot read your data.
There are three ways to get a VPN service.
Configuration files for VPN servers located in the USA are provided by the private individuals on a voluntary basis. Stability, performance, and work of such server lies within the competency of aforementioned individuals.
This post is about the third option.
To get your own personal VPN, you need two computers:
A client computer, most likely it is your home computer or a laptop. You use it to connect to a VPN.
A private server, this where you install a VPN and use it as a VPN provider. This can be your own physical server or a virtual server.
There are several programs you can use to configure personal VPN. I will use OpenVPN. It is open-source, it is available in all Linux distro and I believe it is one of the most popular VPN programs.
You need to install OpenVPN and cURL programs:
cURL is needed to download the VPN installation script openvpn-install.sh.This script makes the installation very easy and error save.You can, of course, install everything manually, and there are good instructions on how to do that on Debian Wiki or Arch Linux Wiki. But I believe most of my readers prefer the simplest ways. This VPN installation script is a result of the work of 36 contributors, you can check what it does, and I personally trust it.
So, you need to download the script and make it executable:
Then run this script as a superuser to install and configure OpenVPN on your server:
You need to follow the assistant and answer a few questions. You can keep everything by default, just press Enter for every question. Only give a name to your VPN configuration and I also recommend to encrypt the configuration with a password:
When everything is done. You should see a file that ends with
.ovpn. This is a configuration file you will need to configure the client computer.
On a client computer, also install OpenVPN and OpenVPN extension for your network manager:
networkmanager-openvpn for Plasma 5 on Arch Linux. Search for these two packages in your distro. Their names may differ slightly. If you use Ubuntu GNOME, for example, you need to install
Next, download the VPN configuration file from your server:
The file will be downloaded to your local Downloads folder.
You can also use FileZilla if you prefer graphical programs. I explained how to use FileZilla and
scp command in my previous post.
First, I will show you the command line way to connect to a VPN. This way is more reliable and you make sure that your VPN works. Next, configure your graphical network manager.
So, copy the downloaded
*.ovpn configuration file to the client folder of your OpenVPN:
Test the connection:
You may need to enter the password if you set one and then you will see something like this:
If you do not see any error, your VPN works fine. To test it, open your internet browser and visit any website. You can also check your public IP address and it should be your server address.
Although I like the command line, it is much nice to be able to connect to the VPN with just with one click from your system tray:
So, to add your VPN configuration to the Network Manager, open the Network Manager settings. Click on Add new connection, and import the configuration file you have downloaded from the server:
Above screenshots are from Plasma 5 Network Manager. It is almost the same in GNOME and other desktops. Just find an option to import the connection.
After that, you should see a new connection in your connection list. Try to enable it. If you see that your Network Manager icon changed, this means your VPN works. You can go to your web browser and test it.
When you start your OpenVPN connection from the command line, you will see errors right on the screen if somethings does not work. Try to understand what it says. If you do not how to fix it, google that error message.
However, when you configure the graphical interface of the Network Manager, you do not see detailed error information if it happens. You need to check the errors in your logs with this command:
For example, I did not succeed to connect to my VPN in Plasma 5 the first time. I imported the configuration and I saw that the system tried to connect, but failed after some time:
Checking the log files revealed that TLS certificate was missing:
My Network Manager imported all certificated except the TLS one. From my experience, importing the connection configuration works flawlessly in the GNOME Network Manager. But other network managers may not recognize all settings during the importing. Probably, this is because the script is optimized for GNOME. So, you may need to correct some importing errors manually.
Open the configuration file
*.ovpn with a text editor and make sure you have the corresponding settings in your Network Manager.
If some certificates are missing in your Network Manager, copy it from the configuration file and save as a
*.crt file on your computer.Usually, all the Network Manager certificates are stored in
You can see the screenshots of my configuration after I corrected all errors:
You may also need to change the permissions of all the certificates.
This is how I was able to troubleshoot my Plasma 5 VPN connection. Obviously, I cannot guess all the possible problems that can arise during your installation and configuration of a personal VPN service.
When you run the scrip
openvpn-install.sh the first time, it creates a connection for one uses. However, if you run it again it, will offer you an option to add more users:
Select option 1. Add a new user and follow the instructions. The instructions are the same as above. Just provide a different Client name and you will see
newuser.ovpn configuration file. Use it to connect a new user to this VPN server.
As you can see from the screenshot, running
openvpn-install.sh again also gives you options to revoke a user, and remove OpenVPN from the server.
So, if you have ever thought about setting up a personal VPN, now you know how to do that. A personal VPN server is not only more secure in terms of privacy but it can also be cheaper. For example, if you connect your whole family to one VPN server, this option will be cheaper than subscribing your whole family to several VPN accounts by subscription.
This is the third post in my series on setting up a basic Always On VPN deployment. In this post I will be covering the configuration of the VPN server and the NPS server. I will also talk about the network and firewall configuration. Links to each individual post in this series can be found below.
Always On VPN – Basic Deployment Guide
Always On VPN – Certificates and Active Directory
Always On VPN – User Tunnel
Always On VPN – Device Tunnel
Always On VPN – Troubleshooting
In this deployment, the role of the VPN server will be filled by Windows Server 2019 running the Routing and Remote Access Server role. This post will provide instructions for both domain-joined and non-domain-joined VPN servers. For the best security, the recommendation is to not join the VPN server to the internal AD domain.
The server will be located in a perimeter network. If a perimeter network or DMZ is not available, the server could be placed on a separate VLAN where access to the rest of the corporate network is controlled by ACLs. The server could also be placed directly on the corporate network, but this is the least secure option.
The server will have 2 network adapters, 1 internet facing adapter and 1 intranet facing adapter.
If the VPN server is domain-joined, the server will need to be able to communicate with a domain controller. If there is not a read-only domain controller in the perimeter network, then these ports will need to be opened to domain controller on the internal network. Note that this is a potential security risk.
These steps will walk through the installation and configuration of the Routing and Remote Access Server role. These steps should be preformed on the VPN server.
This concludes the main setup of the Routing and Remote Access role. However, there are additional steps that can be done to improve security as well as add support for device tunnels.
The default security settings for an IKEv2 connection in the Routing and Remote Access configuration are not as good as they could be. The settings used for the IKEv2 connections can be set to a more secure level on the server. If these settings are set on the server, the same settings will need to be configured on the client side before the tunnel will connect.
This PowerShell command is sourced from this post.
It’s possible that the IKEv2 traffic can be split apart if the IP packets are too large. Windows 10 will support IKEv2 fragmentation by default, however this support needs to be manually enabled in Windows Server. Note that this feature only works in Windows Server 1803 and newer. To enable support for IKEv2 fragmentation, run this PowerShell command:
To read more about IKEv2 fragmentation, refer to this post.
The default configuration of the Routing and Remote Access server role does not allow machine certificate authentication. If device tunnels will be used, this needs to be enabled.
This PowerShell script is sourced from this page.
In this deployment, the role of the NPS server will be filled by Windows Server 2019 running the Network Policy Server role. This server should be domain-joined.
The server will be located behind the internal firewall on the internal network. The server should have a single network adapter with a static IP address or a DHCP reservation.
The following ports should be allowed through the internal firewall and the Windows firewall between the VPN server and the NPS server.
Windows Server 2019 has a bug where the Windows Firewall rules for the NPS role will appear as active but not actually be working. If communication on these ports does not seem to be making it through the Windows Firewall, open an administrative command prompt and run this command.
For more information about this bug and the solution, see this post.
These steps will walk through the installation and configuration of the Network Policy Server role. These steps should be preformed on the NPS server.
This completes the VPN and NPS server configuration portion of the deployment. The next post in the series is Always On VPN – User Tunnel.