Bering-uClibc 7.x - User Guide - Advanced Topics - Setting Up a Virtual Private Network

From bering-uClibc
Jump to: navigation, search
Advanced Topics - Setting Up a Virtual Private Network
Prev Bering-uClibc 7.x - User Guide Next


The whole topic of Virtual Private Networks can appear somewhat confusing at first sight since there are several different use case scenarios (e.g. mobile user remote access versus site-to-site VPNs), several different VPN tunnel encryption solutions (e.g. SSL/TLS versus IPsec) and several more authentication solutions (e.g. X.509 PKI certificates, Pre-Shared-Keys or EAP - much the same options as exist for WiFi networks). Furthermore, there are different open source implementations of some of the protocols (e.g. OpenSwan versus strongSwan versus LibreSwan).

In practice, things aren't as complex as they first appear because there are only really two underlying encryption solutions (SSL/TLS and IPsec) and - if the intention is to support a proprietary device such as a commercial smartphone as the VPN client - several constraints are imposed by the client-side VPN implementation which limit the options at the server-side.

Fundamentally, for Bering-uClibc 7.x, it comes down to choosing between:

  • Using the StrongSwan package strongswan.lrp to implement an IPsec-based VPN
  • Using the OpenVPN package openvpn.lrp to implement a TLS-based VPN
  • What about eoip.lrp which references - seems to be a MikroTik-specific Ethernet over IP protocol?

StrongSwan IPsec VPN

Use Case

The following assumes an IPsec VPN server is being configured to allow mobile 'road warrior' clients such as commercial smartphones to access network(s) protected by a Bering-uClibc 7.x firewall.


In order to configure StrongSwan, you will need:

  • An X.509 digital Certificate to identify the VPN server (known as the 'responder' in IPsec terminology), stored in the form of a .pem file
    • For the purposes of this document, assuming the VPN server is identified as, this file will be named
  • A corresponding private Key, stored in the form of a .pem file, together with the Passphrase for the private Key
    • For the purposes of this document, this file will be named
  • The public Key(s) for the Certification Authority chain used to issue the VPN server's digital Certificate
    • For the purposes of this document, this file will be named

There is nothing uniquely IPsec-specific about the generation of these Certificates and Keys so the exact procedure is not described here. Note however there are a few requirements:

  • The server Certificate must specify a Subject Alternative Name (SAN) which matches the way the client will identify the server (either a DNS name or an IP address)

Best practice is to have the VPN clients reference the VPN server by DNS name (rather than IP address) - not least because that allows the use of IPv6 where available - so IPv4 and / or IPv6 DNS records should be configured to reference the public Internet address(es) of the firewall and visible from the DNS server(s) used by the clients.

Package Installation

Install package strongswan.lrp in the usual way and add it to leaf.cfg so it gets loaded automatically on a reboot.

Package Configuration

Install Certificates and Keys

  1. Copy file into directory /etc/ipsec.d/certs/
  2. Copy file into directory /etc/ipsec.d/keys/
  3. Copy file into directory /etc/ipsec.d/cacerts/
    • Note that all files in this directory are automatically loaded when StrongSwan starts; they do not need to be specifically referenced in any configuration file
    • In the event that further Certification Authority configuration settings need to be specified (such as a Certificate Revocation List URL) this can be done in the 'ca' section of ipsec.conf - see
    • If the CA that signed the Certificate is not a Root CA, this directory needs to be populated with the Certificates for the Root CA, the Signer CA and any intermediate CAs

Configure Secrets

Edit file /etc/ipsec.secrets and add a line like the following:

: RSA "secret passphrase for private key"

Note that the colon (:) must be the first character on the line (no leading whitespace). See for full documentation of the RSA configuration entry format.

Configure Connections



TODO - Any volunteers?

Configuring Wireguard


This is a short introduction on how to configure the wireguard VPN on your LEAF system.


The software used build a VPN tunnel using wireguard is packaged in the wireguard.lrp LEAF package. You should be familiar on how to obtain LEAF packages from either a tarball in the LEAF file area or to download it using your internet connection. You should also be familiar on how to set up LEAF to automatically install packages.


As of LEAF 7.x wireguard.lrp depends on the following packages:

  • bash.lrp


The wireguard VPN software is configured using a text file /etc/wireguard/wg<tunnel ID>.conf, typically /etc/wireguard/wg0.conf. It is also controlled by the file /etc/default/wireguard where a few start parameters are defined. The wireguard.lrp package includes a copy of these two files for your reference.


The /etc/wireguard/wg0.conf file is used to tell hold the wireguard keys and information about the wireguard peer. The wireguard VPN is a peer network, however slight differences in the configurations exist, especially the initiator side uses the parameter Endpoint to address its peer. The example below shows the client or initiator side of the wireguard VPN.

# This is a dummy configuration file for the wireguard VPN server.
# It should reside in /etc/wireguard and is designed to be used
# by the wg-quick script viz:
# 'wg-quick up wg0' to start the VPN server and
# 'wg-quick down wg0' to stop it.
# Generate the private & public keys required thus:
# umask 077
# wg genkey | tee private_key | wg pubkey > public_key
# Dummy config:
Address =
ListenPort = 11194
PrivateKey = EKufmuT959jTCnFlK+jjhJvzPQWdEaEzNWsHIYnzTV8=
# Peer1
PublicKey = DJDe260WVX8Cm2gjf/0nmklHkO8N8XgSTpvB34zJzz0=
AllowedIPs =
Endpoint =
# Peer2
#PublicKey = <Peer 2 public key base64 string>
#AllowedIPs = <comma-separated address/cidr ranges allowed access from Peer 2>

To configure wireguard you need to edit the wg0.conf file and generate a private and public key pair for each of the tunnel endpoints.

For detailed information on how to set the up wireguard please refer to wireguard.


This file controls the wireguard daemon. It just defines if the daemon is started at all and the name of the wireguard interface used.

# Configuration for Wireguard init script
# Set to "yes" to start the VPN server at boot time
# Interface name. It must have a matching ${INTERFACE}.conf file in /etc/wireguard

Firewall settings

If you have to pass a firewall then you need to provide a way, possibly on both sides, for the tunnel and the tunneled packages to reach their respective destination. Shorewall provides a configuration file /etc/shorewall/tunnels which can be used to provide this access.


VPN Client Notes

iOS VPN Options

As of Apple iOS version 11, the options supported by the standard VPN client implementation are:

See also

Android VPN Options

As of Android version 6.0, the VPN options supported by the standard VPN client implementation are:

Other options such as IKEv2 can be supported by installing a custom VPN client - for example the StrongSwan VPN Client for Android

Prev Up Next