Advanced VPN configuration using WireGuard

Subject: Cyber Security I (KB I), Department of Telecommunications, Faculty of electrical engineering and computer science, VSB-TUO.

Name: Bc. Kryštof Šara (SAR0130)

Date of presentation: December 15, 2023

Task description: Application description, testbed creation, implementation of some of the most well-known scenarios for VPN - 1: 1 and N: 1, connection of PKI with VPN

introduction

In the modern era of digital nomadism, where one can roam virtually anywhere around the globe, while still having a connection to public Internet, it is crutial to ensure an additional layer of security for businesses as well as for individuals (public WiFi access points). [16]

virtual private networks

Virtual private networks (VPN) are a special subset of networks, which are to be interconnected using the existing public network infrastructure (the Internet backbone, public IP netoworks et cetera). Networks are meant as virtual, because all business resources are apparently available and everything acts like being interconnected like on a local network. The private property of a network means that the connection is secured and clients are to be authenticated and authorized. [16] [19]

Fig. 1: Generalized VPN connectivity scheme. [21]

Because VPN problematic is not built-in in TCP/IP itself, a combination of several technologies has to be implemented for a stable and secure VPN infrastructure — namely it is tunnelling, data encryption, authentication and authorization. IP VPN framework is described in RFC 2764. [16]

general types of VPN

• site-to-site (also as LAN-to-LAN) interconnects several business branches into one huge business intranet [16]
• remote access enables a mobile client (teleworker) to access business intranet; additional services like DHCP and DNS are required for this operation at the VPN gateway. [16]
• extranet — excluding a special network for clients extra the business intranet [16]

• 1:1 – site-to-site, adhoc tunnel between two LANs
• N:1 (road warrior) – multiple devices towards the VPN concentrator

infrastructure elements

• VPN gateways (concentrators) — vital border network devices to connect a site to VPN; [16]
• VPN clients — specialized software enabling the connection to VPN [16]
• authentication servers — identity ensuring identity of gateways and clients [16]
• VPN management servers — special server components for VPN state monitoring and managing [16]
• physical transport of IP datagrams over the public backbone [16]

symmetric vs. asymmetric encryption

The main purpose of an encryption is two ensure confidentiality of data. Also, the encryption can be used for authentication. [16] [18]

General types of encryption: [16] [18]

• symmetric using the shared private key — DES (3DES), AES, Kerberos
• asymmetric using the private-public key pair — Diffie-Hellman, RSA, digital signs and certificates

Asymmetric cryptography is an implementation of so-called trapdoor hash function, where the hashing procedure can be inverted using a secret key. [18]

Another key difference there is the computational speed of the encryption. While symmetric encryption is very fast, asymmetric encryption is way slower due to more complex algorithm used. This can by bypassed by using the symmetric type for the interchanged data encryption, while asymmetric type is used for secure symmetric key encryption and distribution. [16] [18]

message hashing, checksums

Hashing functions are one-way cryptographical functions, that produce a fingerprint from any amount of input data. They are mostly used for data integrity check of the received data, or to store user’s password in databases. [18] [19]

Message digest MDx (fingerprint, message checksum) is used to ensure integrity of sending data, that those are not being tempered during the transmission. Message hashing is one-way function, therefore one cannot decipher the message from the checksum. [16]

Modern algorithm is SHA (Secure Hash Algorithm). Hashing is used for message validation, ergo that the received message is identical to the transmitted message. [16]

public key infrastructure

One approach on how to ensure authentication feature being usuable, is by implementing ITU-T recommendation X.509 for public key infrastructure (PKI, hierarchical certification authority system), which introduces a third party that pairs a public key to its owner (the owner of the corresponding secret key). Another similar concept is based on decentralized “web of trust” idea and is being called Pretty Good Privacy (PGP). [16] [18]

To sum it up, it is a system of standards on how to deal with public keys, certificates, their management, emission and revocation. [18]

message authentication code

MAC is a mode of block cipher to generate a validation tag for data integrity check. The message code is created from the message with secret key (should be different from the key used to encrypt the data). A MAC send with data suits as authenticating service for data origin ensuring. [18]

Message authentication code (MAC) is a mechanism on how to authenticate the transported data. One-way hashing produces hash-based MAC (HMAC). Hashed message of any length is compressed into a static sized hash. The hash is then encrypted by private key of the same length. [16]

wireguard protocol

WireGuard is ISO/OSI Layer3 network tunnelling software, designed primarily as kernel module for GNU/Linux systems (introduced in 5.6 kernel). Compared to IPSec and still widely favourite OpenVPN technologies, WireGuard offers better performance, security, and simplicity to use. An implementation of fundamental secure tunnels deals with peer’s public key and source IP address. Data are authenticated and encrypted using ChaCha20Poly1305 (see more below), and encapsulated in UDP datagrams. The simplicity can be seen in a generic Linux implementation, which is possible to perform in less than 4000 lines of code (great advantage to OpenVPN implementation). [20]

WireGuard uses similar approach to exchange static public keys, as is done in OpenSSH. For a one round trip key exchange, Curve25519 for ECDH and HKDF for its results expansion, ChaCha20 and Poly1305 for authenticated encryption (AEAD), and BLAKE2s for hashing is implemented and used under the hood. [20]

Each peer is identified by its public key — 32-byte Curve25519 point.

Fig. 2: Performance of WireGuard tunnel compared to two IPSec variants, and to OpenVPN UDP variant. Tests were performed on 1-gigabit Ethernet cards. Results were averaged over 30 minutes. [20]

cryptography

WireGuard uses various modern protocols and primitives (fundamental building blocks). These are described in the following subsections below on. [4] [9]

Cryptografic methods used by WireGuard are not Post-quantum secure — can be partially hotfixed by pre-shared symmetric key. [1] [2]

1

wg genpsk

ChaCha20 + Poly1305 (AEAD)

ChaCha is a family of stream ciphers, more specifically ChaCha is a 256-bit stream cipher. Also known as Snuffle 2008. The implementation is very fast in any software. ChaCha20 is based on 20-round Salsa20/20 cipher. Other ciphers from the ChaCha family are reduced-round ciphers — those are based on Salsa20/12 and Salsa20/8 —, which are even faster when used in common cryptographic applications. WireGuard uses ChaCha20 for the symmetric encryption. [1] [4] [5]

The Salsa20 cipher has more conservative design than AES and it is being used by the community more and more these days. Salsa20/20 is also faster than AES (reduced-round ciphers are even faster). [5]

As mentioned before, ChaCha ciphers are derived from the Salsa20 ciphers. The key change there is the extra diffusion amount per round. A typical ChaCha round has 16 additions, 16 XORs, and 16 constant-distance rotations of 32-bit words (like Salsa20). Compared to Salsa20, ChaCha uses the double-speed update of bits. [5]

The implementation of ChaCha20 in WireGuard also uses Poly1305 authentication with AEAD construction. Poly1305 (or Poly1305-AES) is a secret-key message-authentication code (MAC) — one-time authenticator. Poly1305 can also use other cipher functions than AES, that are guaranteed to be secure. Poly1305 is also of a very high (consistent, not CPU-specific designed) speed MAC (three times faster than AES: on hardware not fully dedicated for AES). [4] [6] [8]

ChaCha20 and Poly1305 primitives are combined into an AEAD (authenticated encryption with associated data) construction as AEAD_CHACHA20_POLY1305. A standard AEAD construction, according to RFC 7539, consists of: [8]

• 256-bit key
• 96-bit nonce
• plaintext of any length
• additional authenticated data (AAD) of any length

At first, a one-time key is produced from the key and nonce using Poly1305. ChaCha20 cipher function then encrypts the plaintext using the key and nonce. And finally, the Poly1305 function is called again with the one-time key and a message constructed (mainly) of the padded AAD, padded ciphertext, and AAD and ciphertext lengths in octets. [8]

Message is authenticated only if the calculated tag (one output of the AEAD), and received tag are bitwise comparable — tags must match. [8]

Curve25519 (ECDH)

Curve25519 is the modern eliptic-curve Diffie-Hellman (ECDH) function. Its purpose is to generate a 32-byte public key from given 32-byte private/secret key. Next, the function takes peerA’s secret key and peerB’s public key, and generates a 32-byte secret shared between two peers. This shared secret is then used to authenticate and encrypt messages sent by the two sites communicating. [4] [10] [11]

Fig. 3: The data flow from secret keys to public keys for a shared secret generation. [11]

Moreover, a computation using the Curve25519 function is of very high speed. Curve25519 is also immune to timing attacks with the significant computational speed being preserved. Keys are relatively short — only 32-byte long using compression. [10] [11]

Eliptic curves use discrete logarithms under the hood. Generally, Curve25519 it is a short-key discrete-logarithm system. Also, it is not post-quantum secure. [11]

BLAKE2s (hashing and keyed hashing)

BLAKE2 is a simple and fast hash function (faster than MD5 and SHA-3), while still as secure as the modern SHA-3 standard. It is, simply put, way efficient alternative when compared to SHA and HMAC-SHA. The specification can be found in RFC 7693. There are two subtypes of BLAKE2 — BLAKE2b (for 64-bit systems, as well for specific ARM systems), and BLAKE2s (for 8- to 32-bit systems). For the backward compatibility, WireGuard uses BLAKE2s function. [4] [12] [13]

BLAKE2 has built-in keying mechanism. The hash function can used to authenticate digital signatures and messages, as well as in applications like Public Key Infrastructure (PKI), for secure communication protocols, version control systems, or cloud storages. [13]

Note: At the moment, there is even faster function available as BLAKE3. [12]

SipHash24 (hashable keys)

SipHash is a family of pseudorandom functions (PRFs, or keyed hash functions). When used with short messages, the overall performace and speed is very high. SipHash is relatively simple and fast when compared to MACs based on universal hashing. No cryptoanalytical project has been successful in breaking SipHash yet. A secret key should always be used with SipHash to ensure high security. [4] [14]

SipHash comes in various variants, where the default one is called SipHash-2-4. This variant takes 128-bit key on input, then comprosses it twice, finalizes it four times and returns a 64-bit tag. [14]

SipHash is designed to be used in (mainly) network traffic authentication. Most state-of-the-art MACs are optimized for long messages, while SipHash performs very well on short messages. [15]

HKDF (key derivation)

HKDF stands for HMAC-based key derivation function (KDF). The general goal of KDF is to take a source of keying material, and to derrive a secret key from it. Extraction of initial pseudorandom key and expansion into one or more cryptographic keys. [4] [17]

problems

Man in the middle attacker can relay packets and replace source addresses — locking the source IP address to a particular IP address should hotfix this. [1]

TCP sequence number guessing game — to direct WG direct packets to an uncontrolled IP address [1]

demonstration

In this section, the actual WireGuard installation, configuration, and testing is about to be described and shown. As far as the network topology is concerned, a very basic 1:1 (point-to-point) configuration, and more advanced N:1 (point-to-multipoint) configuration will be implemented.

Basic Linux shell knowledge is required. All commands shown below are to be run as root, or implicitly sudo prefixed. Terms “server” and “client” are used to follow the conservative server-client model henceforth (WireGuard defines any VPN client as a “peer”).

(point-to-site, site-to-point, site-to-site configurations) [2]

used technologies

• Debian GNU/Linux 12 bookworm
• wireguard, wireguard-tools v1.0.20210914-1
• iOS 17.1.1
• WireGuard for iOS v1.0.16

concentrator configuration

Having the fresh Linux system installed, we can proceed with wireguard-tools (via wireguard metapackage) installation. [2] [21]

1
2

apt update
apt install wireguard 

Next, we need to generate a (asymmetric) key pair for packets encryption/decryption: [21]

1
2

cd /etc/wireguard
wg genkey | tee priv.key | wg pubkey > pub.key

The private key has to be kept secret. Even if the public key is “less critical” in terms of security, it should be shared with other peers connecting to this very instance only. [21]

To set up a new concentration endpoint/interface, we need to create a configuration file. It’s name will be reflected in an interface name. Let us use, say, wg320 name for such file, which will be suffixed with “.conf”. [21]

1

vi wg320.conf

1
2
3
4

[Interface]
Address = 10.3.2.1/27
ListenPort = 51820
PrivateKey = WCzcoJZaxurBVM/wO1ogMZgg5O5W12ON94p38ci+zG4=

This settings will later create an interface with IP address 10.3.2.1 for the server, and will add a route to 10.3.2.0/27 network via the WireGuard interface. ListenPort is a UDP port on which will the WireGuard instance listen for incoming connection. [21]

Now, the interface configuration is ready to be brought up. For this purpose, we can use wg-quick tool, which has been installed with the kernel module too. The ip tool is used by wg-quick under the hood. [2] [21]

1

wg-quick up wg320

Alternatively, the interface can be brought up via a wg-quick.target systemd target/service. This target unit file is written generically to group systemd-managed WireGuard interfaces. The enable subcommand will ensure this service will start automatically after reboot. [3]

1
2

systemctl start wg-quick@wg320
systemctl enable wg-quick@wg320

testing the interface

The interface state can be observed/checked using ip, and wg tools. [21]

1

ip a

1
2
3
4

wg320: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.3.2.1/27 scope global wg320
       valid_lft forever preferred_lft forever

1

wg

1
2
3
4

interface: wg320
  public key: OdjaBKATqRCGwRo+AP44jHpv8mEVhZHY12ZZCyZ1ARk=
  private key: (hidden)
  listening port: 51820

IP forwarding and firewall setting

The concentrator instance (server) should now relay the traffic within the configured subnet (10.3.2.0/27). For this to work properly, IP packet forwarding has to be enabled in the running system. [2] [21]

1

sysctl -w net.ipv4.ip_forward=1

Packet forwarding also has to be explicitly set in the server’s firewall. Here, we presume that eth0 is an interface facing the Internet. If we wanted to reach the outer network, we could hide the source address coming from the VPN subnet and apply a masquerade to the packets — simple source NAT configuration. [2] [21]

1
2
3
4

iptables -A INPUT -p udp -m udp --dport 51820 -j ACCEPT
iptables -A FORWARD -i wg320 -j ACCEPT
iptables -A FORWARD -o wg320 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

With this configuration set, the server is often called a bounce server. Now, one connecting to the concentrator should be able to access the Internet — clients can safely visit public net even on unsecured public WiFi access points. [21]

client configuration

Next on, we will configure peers (and “server”) to establish the actual VPN tunnels.

generic peer’s setting

Let us assume that WireGuard is installed on the client’s machine, and key pair has been generated too. WireGuard configuration structure for the counterpart is a bit more verbose, but is still relatively simple to catch up. [21]

1
2

cd /etc/wireguard
vi wg320.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[Interface]
Address = 10.3.2.2/32
PostUp = wg set %i private-key /etc/wireguard/priv.key
DNS = 10.3.2.1, 1.1.1.1

[Peer]
PublicKey = CcZHeaO/x3FXdsSGZG32SvHlrwHnsWlGTs=
Endpoint = concentrator.example.com:51820
AllowedIPs = 10.3.2.0/27
# PersistentKeepalive = 25

concentrator changes

Now, we need to add the Peer section to the concentrator’s WireGuard configuration file too. [21]

1

vi /etc/wireguard/wg320.conf

1
2
3
4
5
6
7
8

[Interface]
Address = 10.3.2.1/27
ListenPort = 51820
PrivateKey = WCzcoJZaxurBVM/wO1ogMZgg5O5W12ON94p38ci+zG4=

[Peer]
PublicKey = lIINA9aXWqLzbkApDsg3cpQ3m4LnPS0OXogSasNW5RY=
AllowedIPs = 10.3.2.2/32

To apply changes, WireGuard service has to be restarted (or hot-reloaded). [21]

1
2
3
4

wg-quick down wg320 && wg-quick up wg320

# or using systemd service
systemctl restart [email protected]

The hot-reload approach allows the interface to be reloaded without any downtime. [21]

1

wg syncconf wg320 <(wg-quick strip wg320)

mobile clients

Fig. 4: Wireguard for iOS application version detail.

Mobile phone clients (WireGuard applications for Android and iOS systems) can import the configuration via a QR code. This code can be generated on the concentrator using qrencode tool. [1] [2]

1
2

apt install qrencode
qrencode -t ansiutf8 -r client.conf

Fig. 5: Generated QR code in command-line interface using the qrencode tool.

Fig. 6: Wireguard for iOS application, methods of configuration import.

establishing the tunnel (linux)

When the concentrator’s configuration is reloaded, defined peer can establish a tunnel. Having the client already configured, let us start it on a remote machine too.

1

wg-quick up wg320

The actual connection can be checked by the wg tool, but we need to send some traffic first, to initiate the link. Traffic can by of any type, so let us use ICMP echo packet flow (ICMP ingress has to be allowed in server’s firewall).

1

ping 10.3.2.1

Now, the peer-to-peer tunnel details should be seen using the wg command on server:

1

wg

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

interface: wg320
  public key: OdjaBKATqRCGwRo+AP44jHpv8mEVhZHY12ZZCyZ1ARk=
  private key: (hidden)
  listening port: 51820

peer: lIINA9aXWqLzbkApDsg3cpQ3m4LnPS0OXogSasNW5RY=
  endpoint: 193.1.1.39:56587
  allowed ips: 10.3.2.2/32
  latest handshake: 1 minute, 44 seconds ago
  transfer: 6.30 GiB received, 20.98 GiB sent
  persistent keepalive: every 25 seconds

Fig. 7: Wireguard for iOS application, connection details.

more advanced topology (backed up road warrior)

Using WireGuard, one could set up various topologies with multiple concentrator servers to ensure a backup route for traffic (see Fig. 8 below). Using this technique one is able to remotely connect to another concentrator when one (or its lines) goes down. Each server in the network is connected to both concetrators in N:1 mode.

Fig. 8: Advanced topology example interconnected using Wireguard. The topology includes two concentrators (frank and helix), two stand-alone peers for monitoring (talion and opsidian), and two hypervizors (squabbit and viking).

packet forwarding

1
2

iptables -I FORWARD -i wg192 -o wg128 -j ACCEPT
iptables -I FORWARD -i wg128 -o wg192 -j ACCEPT

concentrator to site

Below, the concentrator’s configuration file for primary WG interface is listed. The AllowedIPs directive ensures that the concentrator will be able to route/forward traffic to the remote site via such node/peer.

1
2
3
4
5
6
7
8
9

[...]

# viking from helix

[Peer]
PublicKey = s23slSPXccDSSl/nRTgMcBlMoEhco00bNLP3Y7=
AllowedIPs = 10.3.2.220/32, 10.3.5.32/27

[...]

routes

Using the ip command we can simply list all routes for both WG networks, and for two hypervizors’ networks (sites).

1
2
3
4
5
6

root@helix:~# ip r
default via 1.2.3.4 dev ens3 
10.3.2.128/26 dev wg128 proto kernel scope link src 10.3.2.150 
10.3.2.192/26 dev wg192 proto kernel scope link src 10.3.2.200 
10.3.5.0/27 dev wg192 scope link 
10.3.5.32/27 dev wg192 scope link

Fig. 9: Live diagram of two concentrators’ one-direction links, and two monitoring nodes connected to both concetrators. Grafana dashboard/panel is used for such diagram.

Wireguard and PKI

WireGuard itself does not provide support for certificates and the Public Key Infrastructure implementation. However, it is possible to imcorporate PKI and certificate exchange mechanism into the protocol itself due to its open-source philosophy and short code implementation. [22]

conclusion

Establishing the tunnel(s) is, by my opinion, easier and more straight-forward than with using OpenVPN. Even for mobile deviced there are client/peer applications available, so one can connect their phone to road-warrior type of topology for example. This could be used as another layer of security when connecting to public hotspots. The tunnel setting up there could be done via a QR code which makes it very easy to use too.

references