All-in-one VPN with WireGuard, MikroTik and Keenetic
In this article, I will share my experience and configs for building a universal family VPN – both for end users and for organizing network interaction between a summer house and an apartment.
You will learn how:
configure on VPS server WireGuard
organize communication via WireGuard between two home networks without public IPs
organize access from client devices to the Internet without borders if your VPS is located on a foreign site
List of abbreviations
Of course, there are many different articles about WG – however, when I needed to solve a complex problem, those articles that I found did not help me. I would venture to guess that this was because most of the articles give the recipe without explaining the mechanics of what is happening, so stepping to the left or right makes the instructions useless. I want to close this gap and give the reader not only instructions, but also an understanding of how it works, so that he can implement something that is not described anywhere.
To begin with, I will describe the problem that I had and which was successfully solved. The initial starting point was the idea to connect two network segments – in the country house and in the apartment, so that you can administer one grid from the other and vice versa. It so happened that the environment turned out to be heterogeneous – there is a Keenetic Viva router at home, access to its admin panel is from the Internet thanks to Keenetic technologies, but MirkoTik RB3011 is installed in the country house, and the local provider does not have public IP services. The idea was in the air for a long time, but the implementation driver was the fact that the cool VPN Windscribe stopped working through my provider at all. I decided to rent a VPS abroad, set up a VPN for family members, and connect the two networks at the same time – like a cherry on top. The target architecture looks like this:
Rented a VPS server from a provider Fornexas a starting article for configuring WireGuard was used article on 1cloud. Next, we go in order – I used a root account, so commands without sudo.
apt install -y wireguard
Go to catalog /etc/wireguard and we do everything there. So far, everything is according to the instructions – we generate a key pair for the server:
wg genkey | tee /etc/wireguard/privatekey | wg pubkey | tee /etc/wireguard/publickey
As a result, we will have two keys – private and public, they will be used to connect to the WG server. Now it’s time to return to the study of materiel – how WG works, what entities it operates on and what it all leads to. Simplified, the WG workflow looks like this:
This scheme describes the following facts and considerations:
As a result of starting the WG server, a separate network interface on the host is raised
Server WG configuration applied to network interface
For each client connection on the server side, its own peer is configured, it is also a peer
A secure channel is established between two peers
The server does not configure client peers, it only configures its own peers
A peer, aka peer, as follows from the translation of the term, is an equal participant in data exchange, peers on the server do not differ in rights from peers on clients, and each peer has its own settings, and these settings determine what data will be sent to the secure channel , and this is a very important fact that will help you adjust the parameters to solve the problem.
First, let’s analyze the flow of packets from the apartment network to the dacha network and vice versa. Let’s assume we have the following options:
apartment subnet, Keenetic
dacha subnet, MikroTik
VPS IP address
Regarding the VPN subnet, you can set any subnet from among internal, non-public addresses. I have chosen one for myself, you can have any that meets the criterion of internal.
Let’s go step by step.
Configure the WG server to accept connections from client peers
Configure Keenetic to send packets to the VPN connection
Set up a WG client peer on Keenetic so that everything that comes to this peer is sent to the WG channel
Set up a WG server peer for Keenetic so that everything that comes from the 192.168.0.0/24 network to the WG channel is sent to the 192.168.88.0/24 network
Set up a WG client peer on MiroTik so that everything that comes to this peer is sent to the WG channel
Set up a WG Mikrotik server peer so that everything that comes from the 192.168.88.0/24 network to the WG channel is sent to the 192.168.0.0/24 network
Let’s start by setting up the WG server, for this we need the key generated earlier in /etc/wireguard With name privatekey.
First, let’s set up an interconnect between two networks – an apartment and a summer house. Before doing this, it is necessary to generate key pairs for apartment and dacha peers, i.e. for their routers:
wg genkey | tee /etc/wireguard/keenetic_privatekey | wg pubkey | tee /etc/wireguard/keenetic_publickey
wg genkey | tee /etc/wireguard/mikrotik_privatekey | wg pubkey | tee /etc/wireguard/mikrotik_publickey
Let’s create a file in the directory /etc/wireguard With name wg0.conf and the following content:
The AllowedIPs parameter just determines which packet source address will be transmitted to the encrypted channel. In the peer settings for each router, the subnet of another router is recorded – plus the IP address of the peer, which is formed as a result of its connection, so that the VPS server can reach hosts in internal networks. Those. when Keenetic connects, its peer has address 10.0.0.2, and packets from 192.168.0.0 and 10.0.0.2 will be sent to the encrypted channel. With MikroTik – mirror.
Now we need to set up the WG service on the VPS. On Ubuntu, this is done with the commands:
These commands start the WG service with the settings from the specified config file, i.e. wg0.conf. Next, you need to configure WG clients on routers. Let’s start with Keenetic.
I will not write here about how to add WG to Keenetic – this information is full. After adding, the WireGuard section will appear in the Internet -> Other connections section, where we will configure the necessary parameters. Click Add Connection and fill in the necessary parameters of the peer on the router:
name of the connection, fill in at your discretion
use for accessing internet
not covered, otherwise all traffic will go to the VPN, but we don’t need it
use data from keenetic_privatekey file
10.0.0.2/24 is the IP address of the Keenetic router in the VPN network
i used 22.214.171.124
data from the publickey file of the server itself
– use the VPS IP address and port set in wg0.conf
0.0.0.0/0 – everything that comes to the feast is sent to the VPN
15 – interface liveness polling interval in seconds
After that, the Keenetic router will connect to the VPN server. Next, you need to configure MikroTik. It should be noted here that WireGuard support in MikroTik appeared only from the seventh version of RouterOS, but the upgrade is still beyond the scope of this article and I assume that you were able to upgrade.
Open a tab in WebFig called WireGuard and fill in the parameters – these are the peer settings on the router:
any, I have 51380
mikrotik_privatekey file contents
Go to the Peers tab, then Add New, fill in the peer parameters:
Name from the previous step
server publickey content
xxxx – VPS server IP address
Listen Port from wg0.conf
So we set up a connection between the two networks.
Next on the list is setting up VPN connections for, say, phones to access the free Internet. I spent a lot of time and nerves, and the result was the following. Why so – it will become clear from the material further in the text. As a result, the conclusion was the following – it is impossible to configure on the same interface access to the Internet of client devices and communication between networks
Therefore, if someone from the family and I want to access the free Internet through a VPS server, new interfaces will have to be added to it. Why is it so?
Let’s assume that the WireGuard application is installed on the phone, the keys are configured, etc. We establish a connection with the server, and the phone sends a packet to a foreign Internet server, say, google.com. The packet is sent by the phone peer to the server peer, to the interface wg0. As a result of correct configuration, the packet from this interface is forwarded to the interface eth1, undergoes a masquerade and natirovanie, and goes into the big world. The google.com server will respond to our packet, it arrives at eth1 and forward to wg0, getting to the server’s peer, and here we stumble upon a problem. The server peer settings specify which packets from which IP addresses or networks should go to the channel. The google.com server is not there now, so the answer to the phone simply will not return and the connection will not be established. Okay, let’s add to the server peer settings for the phone 0.0.0.0/0, all packages will go to the phone – profit. After restarting the wg0 interface, we will be surprised to find that our VPS server is no longer available – it does not ping, does not connect via ssh, and the current terminal is completely frozen, because now all traffic goes to the peer, even the one that is not intended for it. That is why it is impossible to organize the desired scheme on one interface. Another rake that I stepped on – within the framework of one interface, it is impossible to make packets go to several peers – the packet goes to the peer for which there is a suitable Allowed IPs parameter.
But creating new interfaces is pretty easy. In the /etc/wireguard folder, copy wg0.conf to wg1.conf, and create a new key pair:
wg genkey | tee /etc/wireguard/user1_privatekey | wg pubkey | tee /etc/wireguard/user1_publickey
PrivateKey = <здесь тот же серверный private key> # Приватный ключ из файла privatekey.
Address = 10.0.1.1/24 #Адрес VPN-сервера в частной сети.
ListenPort = 51831 #Порт, который будет слушать VPN-сервер.
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE #Команды, который будут выполнять при поднятии сервера
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE #Команды, который будут выполнять при выключении сервера
PublicKey = <публичный ключ user1> #Публичный ключ user1
AllowedIPs = 10.0.1.0/24
In order for this configuration to work, you need to configure IP forwarding on the server – otherwise, packets from the wg1 interface will not be forwarded to eth0, i.e. to the Internet and vice versa:
So, what key changes has the config received compared to the exchange interface between networks?
Firstly, the Address has changed, there is now a different VPN subnet – 10.0.1.0/24. Accordingly, AllowedIPs has also changed – all packets from this subnet must be sent to the peer.
ListenPort changed – WG server will accept connections for this interface on a different port.
The PostUp and PostDown commands have changed – forwarding rules are not enough to access the Internet, you also need to raise NAT and masquerade, but this is a topic for a completely different article.
That’s all for now, the integration of the dacha and apartment network is set up, and VPN access to the Internet through the same VPS. For now, the generation of QR codes for setting up clients has remained behind the scenes – I think there should be no problems with this, note in the comments if there are problems at this stage, so that it is clear whether the manual needs to be updated.