A Control Plane for WireGuard

Jordi Paillisse∗† , Alejandro Barcia∗ , Albert Lopez∗ , Alberto Rodriguez-Natal† , Fabio Maino† , Albert Cabellos∗
∗ Computer Architecture Department, UPC-BarcelonaTech, Barcelona, Spain
Email {jordip, alopez, acabello}@ac.upc.edu, [email protected]
† Cisco, San Jose, CA, USA. Email: {natal, fmaino}@cisco.com

Abstract—WireGuard is a VPN protocol that has gained WireGuard only supports one cipher suite, specifically -at the
significant interest recently. Its main advantages are: (i) simple time of this writing- ChaCha20 and Poly1305 (RFC 8439).
configuration (via pre-shared SSH-like public keys), (ii) mobility This greatly simplifies the architecture as well as the code,
support, (iii) reduced codebase to ease auditing, and (iv) Linux
kernel implementation that yields high performance. However, providing also important performance advantages.
WireGuard (intentionally) lacks a control plane. This means that In short, in WireGuard users only have to exchange the
each peer in a WireGuard network has to be manually configured public keys of the endpoints and the IP address of one of
with the other peers’ public key and IP addresses, or by other them to start exchanging data. In fact, the setup is very similar
means. to that of SSH. The underlying implementation takes care of
In this paper we present an architecture based on a centralized
server to automatically distribute this information. In a nutshell, the cryptography aspects of a typical VPN: key derivation,
first we manually establish a WireGuard tunnel to the centralized re-keying timers, anti-replay protection, etc. In addition, Wire-
server, and ask all the peers to store their public keys and IP Guard supports mobility and sends keepalives to maintain NAT
addresses in it. Then, WireGuard peers use this secure channel holes open.
to retrieve on-demand the information for the peers they want to With its ease of deployment, native mobility support and
communicate to. Our design strives to: (i) offer a key distribution
scheme simpler than PKI-based ones, (ii) limit the number of performance, WireGuard is gaining popularity and it is becom-
public keys sent to the peers, and (iii) reduce tunnel establishment ing the de facto VPN standard for certain Internet communi-
latency by means of an UDP-based protocol. We argue that ties. However, WireGuard lacks some critical features to enter
such automation can help the deployment in enterprise or ISP Internet professional scenarios, such as ISPs or Enterprise
scenarios. We also describe in detail our implementation and networks. On the other side, end users that would like to add
analyze several performance metrics. Finally, we discuss possible
improvements regarding several shortcomings we found during confidentiality to their connections usually have to rely on
implementation. deploying IPsec in the underlay, with its associated complexity.
Index Terms—dynamic VPN, wireguard, secure overlays, con- One of the main limitations is that WireGuard lacks a
trol plane control plane. Hence, users have to manually setup the public
keys and IP addresses in all of their endpoints, i.e. when we
I. I NTRODUCTION add a new device to the network we have configure its public
Virtual Private Networks (VPN) are one of the most per- key in all the existing devices. This process is time-consuming
vasive services offered in the Internet. As such, VPNs are and error-prone.
considered a mature technology with well-understood mech- Taking this into account, in this paper we aim to de-
anisms and widely deployed and accepted protocols. Notable sign, prototype and evaluate a control plane for WireGuard.
examples of current VPNs are OpenVPN [1], IKEv2 (RFC Specifically, we focus on three key points. First, automate
4306), or IPSec (RFC 4301). the distribution of WireGuard keys without relying on PKI-
Surprisingly, WireGuard (WG, [2]) is a recent VPN protocol based schemes or DNS-based schemes (e.g. IETF DANE
that has managed to disrupt this mature field [3]–[6]. One [7], [8]). These systems require complex configuration or
of the main reasons behind WireGuard’s success is that it additional infrastructure like a DNS server. On the other
tradeoffs flexibility for simplicity. As opposed to traditional hand, although there exist commercial systems that can offer
VPNs that support a large set of cipher suites and that nego- equivalent functionality, such as Dynamic Multipoint VPN [9],
tiate its capabilities before establishing the secure connection, or modern SD-WAN systems [10], their details are not public.
Second, reduce as much as possible the number of public
This work was partially supported by the Spanish MINECO under contract keys stored in the endpoints, in order to reduce communi-
TEC2017-90034-C2-1-R (ALLIANCE) and the Catalan Institution for cation overhead and avoid sharing unnecessary cryptographic
Research and Advanced Studies (ICREA).
information. Also, we want to be as fast as possible when
Cite as: J. Paillisse, A. Barcia, A. Lopez, A. Rodriguez-Natal, F. Maino, and creating new tunnels. And third, understand and pinpoint
A. Cabellos, “A control plane for wireguard,” in 2021 International Conference other potential limitations of the WireGuard protocol to be
on Computer Communications and Networks (ICCCN), 2021, pp. 1–8, doi:
10.1109/ICCCN52240.2021.9522315.
considered for Enterprise or ISP scenarios.
The proposed control plane works as follows: we store the
public keys of all peers in a central server, that sends them to
the WireGuard peers upon request (fig. 1). This way, users only

© 2021 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future
media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or
redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. http://dx.doi.org/10.1109/
ICCCN52240.2021.9522315
 Table I
C OMPARISON OF COMMON DATAPLANE ENCRYPTION PROTOCOLS
Device IP Public key Endpoint IP
Protocol NAT-trav. Mobility Overhead (Bytes)
Dev 1 Key 1 IP A
IPsec tunnel ESP × × 28
Dev 2 Key 2 IP B OpenVPN DTLS
√
× 38
√ √
Dev N Key 3 IP C WireGuard 38

Central
Server Encrypted data

UDP Crypto
Outer IP header Inner IP header Payload
header header
(0) (1) Device N
(2) Internet Mobility Internetworking Access Control
Authentication,
Confidentiality
(3) IP B
IP A Device 2
Device 1 Figure 2. WireGuard header structure

B. Secure Data Planes

Figure 1. Global design. Dashed lines represent data plane traffic flow, solid
lines control plane traffic. Table I compares several features of two of the most popular
L3 VPN protocols (IPsec and OpenVPN), and WireGuard,
along with the overhead of their headers. We can see that
have to setup a secure connection between the peer and the WireGuard supports both NAT traversal and mobility, with
central server on bootstrap (0); new peers store their public key the same overhead of OpenVPN with DTLS. OpenVPN does
and endpoint IP address in the server (1). Afterwards, peers not support mobility but can deal with NAT with additional
retrieve any information from the central server (2) and can configuration [15]. Finally, IPsec does not offer NAT traversal
establish WireGuard tunnels with this information (3). nor mobility but incurs in a smaller overhead. However, we
We must remark that the idea of storing public keys in a must note that IPsec can handle both NAT traversal and
centralized server is not new, but rather a well-know topic mobility with additional extensions: IPsec over UDP, and the
(sec. II-A). On the contrary, the contributions of this paper MOBIKE extension (RFC 4555), respectively.
lie on the practical implementation side, specifically: (i) the Regarding other data plane encapsulations, such as VXLAN
design caveats of a centralized key distribution control plane, (RFC 7348), VXLAN-GPE [16], GENEVE [17] or ILA [18],
(ii) the selection of a protocol to reduce the query latency when it is interesting to remark that they do not usually consider
requesting a public key, (iii) implementation details, and (iv) security or mobility (with the notable exception of ILA mo-
a performance evaluation. To the best of our knowledge, this bility), as opposed to the protocols in table I.
is the first control plane for WireGuard-based VPNs. Finally,
we plan to open-source this control plane implementation. III. BACKGROUND : W IRE G UARD
From a network architecture perspective, WireGuard adds
II. R ELATED W ORK two additional headers to a standard IP datagram (fig. 2). First,
A. Key Distribution an outer IP header, that contains the peer IP address. This
The problem of storing public key data in a centralized header supports mobility; its IP address can change arbitrarily
server, and distributing it to establish secure tunnels is a well- as the peer roams across different networks (e.g Wifi, LTE).
know topic and has been previously explored, such as in Ker- Afterwards, there is a UDP header plus a custom header that
beros [11], or the IETF DNS-Based Authentication of Named contains the message type, cryptography information, and the
Entities (DANE [7], [8]), that makes it possible to add different encrypted payload. Inside the payload we find the inner IP
types of public keys in DNS records like IPsec keys (RFC header, the one used by applications. This header is used on
4322). Furthermore, there is extensive research in dynamic the receiving end to perform access control, i.e. we can specify
VPN configuration and management [12]. More recently, a list of allowed IP prefixes.
SDN-inspired solutions propose to configure IPsec endpoints The key advantage of this architecture is that the three
in a centralized fashion [13], as well as the widespread usage headers are independent: we can modify any of them without
of Software-Defined WANs that automatically setup IPsec impacting the others. For example, in case that a peer changes
tunnels [10]. The most closely related work is a theoretical its IP address due to a mobility event, the crypto header
analysis to configure WireGuard with OpenFlow extensions and the encrypted data will be successfully decrypted in the
[14]. However, it does not provide an implementation or destination. In summary, each header performs a different task:
performance data, rather focusing on the design of control Outer IP header: mobility, can change freely
plane messages. Crypto header: authentication, confidentiality
 Table II IV. A RCHITECTURE
S AMPLE W IRE G UARD C RYPTOKEY ROUTING TABLE
A. Threat Model
Allowed Source IP Public key Internet Endpoint For this specific use-case, either for end users or enterprise
10.10.0.0/16, 10.11.0.0/16 Peer A key 80.80.80.80 networks, we assume we can trust both the endpoints and the
172.16.1.0/24, 172.16.2.2/32 Peer B key 100.128.128.128 centralized server, i.e. we consider legitimate any control plane
192.168.4.0/24 Peer C key 40.0.0.0 message they send. On the other hand, the underlying network
is not trustworthy.
In order to protect the signaling between clients and server,
we establish a WireGuard tunnel between them (sec. IV-C).
Original IP packet
To: 172.16.1.20
The keys for these tunnels are part of the configuration stage
WireGuard Cryptokey Routing Table
Payload
and are exchanged out of band. This way client and server have
Allowed Src. IP Public key Internet Endpoint
a way to authenticate each other. In addition, the centralized
10.10.0.0/16 Peer A key 80.80.80.80
Applications server stores only the endpoint location (Internet IP address),
172.16.1.0/24 Peer B key 100.128.128.128
and its corresponding public key. These assumptions raise a
(1)
(3) set of security concerns in both the centralized server and the
Application WireGuard
endpoints that we discuss below.
sockets Interface
1) Central server:
• Single point of failure: using a centralized server creates
Kernel Space

Kernel Routing Table (4)

a single point of failure, especially vulnerable to DDoS
Default route (2)
Physical attacks. We can mitigate this risk with: (i) replicating the
Route to WG iface
Interface central server, and (ii) since the centralized server uses
WireGuard tunnels, they include an anti-DDoS mecha-
To: 100.128.128.128 WG crypto Original IP packet
nism, detailed in sec. 5.3 of [2]. This mechanism is based
on a cookie from the server that the client has to re-send
Figure 3. WireGuard packet transmission when establishing a connection.
• Leak of peer locations and/or public keys: in this
situation, although an attacker can initiate connections
with the rest of the peers, it won’t be able to finalize the
Inner IP header: access control handshake because the peers won’t receive the attacker’s
public key from the central server (sec. IV-C). Moreover,
The key element of WireGuard’s operation is the cryptokey in case of compromise it is possible to remove the
routing table, that binds source IP addresses (usually IP affected key from the central server so the rest of the
addresses in the private range) to peer public keys (table II). In peers cannot establish communication.
other words, the source IP is used to determine the encryption • Leak of the private key of the central server: this is
key and the receiving peer. Additionally, it stores the Internet the worst scenario, since an attacker can impersonate the
IP address of the peer, that is used in the outer IP header. central server and mount a monkey-in-the-middle-attack.
Figure 3 presents the packet flow of an outgoing WireGuard The secrecy of the private key depends on the OS security
packet. First, users configure the cryptokey routing table with precautions.
the peers and adjust the Linux routing table to forward this 2) Endpoints:
packets to the WireGuard interface (2). This way, new packets
• Leak of peer locations and/or public keys: similarly
destined to the peers (1) are forwarded to the WireGuard
to the central server, this leak does not allow an attacker
interface (2, 3). The interface does a reverse IP lookup on
to connect to any peer, because it will not be able to
the cryptokey routing table to find the peer’s key and Internet
successfully authenticate in the central server. It may be
endpoint. Using this data, it encrypts, encapsulates and sends
able to take advantage of peers that that previously stored
the packet to the physical interface (4).
its public key in their cache, though.
Upon reception, the previous process is reversed. First • Leak of the private key of the peer: on the contrary,
packets are decrypted. WireGuard uses a local identifier here the attacker will be able to impersonate the peer
(equivalently to IPsec) to match incoming packets to the their when connecting to the central server, retrieve connection
security association. If decryption is successful, the WireGuard data and successfully establish connections to the rest of
interface performs access control. Specifically, it verifies that endpoints. Likewise, it is possible remove this key from
the source IP address of the packets is in the list of IP prefixes the central server to prevent future connections.
of the associated public key. This determines if packets are
accepted or dropped. Finally, they are forwarded back to B. Discussion
the kernel routing table, and in turn to the corresponding The key architecture decision we took was the state distribu-
application socket. tion model: send all the keys to all peers (push model) versus
each peer retrieving only the keys it needed (pull model). Table III
We chose the pull approach for two reasons. First, security, E QUIVALENCE OF SEC . IV MESSAGES AND LISP MESSAGES
because we avoid sharing all the public keys with all the peers.
Design message LISP message
Second, minimizing the amount of state in the data plane.
Store key Map Register
Since we only download the keys we need, the WireGuard
Request key Map Request
cryptokey routing table is less crowded. In turn, this reduces
Send key Map Notify
control plane signalling overhead and increases scalability. We
must remark that we are assuming that the traffic pattern
among the peers is not full mesh, i.e., peers do not need
all the existing keys, but just a bunch of them. On the other HTTP-based interfaces, like REST (RFC 7231), WebSocket
hand, the main drawback of a pull architecture is an increased (RFC 6455) or gRPC [20]. However, we chose to use LISP
connection establishment time. In order to minimize this delay, due to performance concerns: since LISP runs on UDP, it
we chose an UDP-based protocol to retrieve the keys. Section offers lower latency when compared to TCP and HTTP-based
VI-A quantifies this delay. protocols. We consider the control plane latency relevant for
our use case since it is in the critical path to establish new
C. Architecture Description connections (sec. VI-B compares such delay with gRPC).
In a nutshell, our architecture lays two elements on top On the other hand, we must remark that the aforementioned
of a WireGuard deployment (fig. 1). First, a centralized interfaces offer more extensibility than LISP.
database that contains, for each WireGuard peer, its associated Our prototype is based on an open-source LISP implementa-
public key and endpoint IP address. Second, a secure control tion, Open Overlay Router (OOR, [21]). OOR is implemented
channel between the centralized database and the WireGuard in C and works in Linux user space, which makes it easy
peers, that we use to retrieve the aforementioned WireGuard to implement new features [22]. In a nutshell, we modified
configuration (solid lines). The central database indexes peers OOR to: (i) detect flows that do not have an active WireGuard
by their inner IP address, i.e. the one used by applications and tunnel configuration, (ii) request its associated public key with
encrypted by WireGuard. the aforementioned control plane messages, and (iii) configure
The centralized database distributes the configuration data accordingly the WireGuard interface.
on demand (fig. 1): when a peer does not have the public key
for a particular destination IP (i.e. we don’t have an entry in
the WG crypto table), we request the public key and endpoint A. Endpoints
IP via the control channel, and configure WG appropriately
(step (2) in fig. 1 in order to communicate with Device 2). Fig. 4 presents a diagram of our implementation. First, we
The central server answers this request but also pushes Device configure a WireGuard interface to tunnel all control plane
1 public key and Endpoint IP to Device 2. This is due to the packets to the central server (i.e. server endpoint IP and pubic
fact that, in order to successfully establish a new WireGuard key). We use a statically defined IP prefix to identify and route
tunnel, both peers need to have each others’ public key. In such requests through this interface. We also create a TUN
other words, we use a pull-and-push approach: the node that interface and add a default route in the kernel routing table
initiates a connection pulls the key, while we push the key to pointing to it. The purpose of the TUN interface is allowing
the receiving node. Finally, once both peers have each other’s OOR to connect, capture packets and examine their destination
data, they can establish the WireGuard tunnel (3, dashed line). IP address. If the IP address is not in its local database, OOR
Taking this into account, we defined the following messages will send a LISP Map Request to the central server to retrieve
for the control channel to interact with the database: (i) Store the key. We must remark that the OOR database is a copy
a peer public key + endpoint IP, (ii) Request a peer public key, of the WireGuard Cryptokey Routing table. Once it receives
and (iii) Send a public key to a peer. this information, OOR configures the new peer in a second
WireGuard interface that handles only data plane traffic. Note
V. I MPLEMENTATION here that the prototype uses two WireGuard interfaces, one for
In order to implement the protocol for the control chan- data plane traffic, and another for control plane traffic. OOR
nel, we leveraged the control plane part of the Locator/ID also adds a more specific route in the kernel routing table
Separation Protocol (LISP, RFC 6833). LISP is a mature pointing to this second WireGuard Data Interface. New traffic
and standardized protocol, designed to dynamically create for this prefix will bypass the TUN interface and go directly
network overlays. This makes it an excellent candidate for this to the WireGuard Data interface. This is especially relevant
application, because LISP’s control messages present nearly a since it avoids copying packets from kernel to user space and
1:1 match to our requirements (table III). Moreover, the LISP viceversa, significantly improving performance.
architecture includes the Mapping System, a centralized server In case a peer does not want to tunnel all its traffic through
that stores pairs of overlay to underlay IP addresses. However, the dynamically-created WireGuard tunnels (split tunneling),
it is possible to adapt other SDN southbound protocols such it can bypass them by adding more specific routes in the kernel
as P4runtime or OpenFlow [19] for this use-case, or even use routing table pointing to an alternative destination.
User Space

Applications OOR Peer Data

Destination IP Endpoint Data
monitoring Requests
WG Config

Application TUN WireGuard WireGuard

sockets Interface Data Interface Control Interface
Kernel Space

Kernel Routing Table

Default route
Physical
Peer A src prefix Interface
Peer B src prefix

Figure 4. Simplified prototype operation diagram. Solid lines represent data plane traffic flow, dashed lines control plane traffic.

B. Central Server
1
We implemented the aforementioned centralized server as a 0.9
LISP Mapping System, more specifically a single Map Server. 0.8
In other words, all peers send their requests to the same Map 0.7
Server. This Map Server is running a modified version of the 0.6
CDF

OOR Map Server, in which incoming Map Requests trigger a 0.5

0.4
Map Notify to the destination WireGuard peer. This way, the
0.3
destination peer receives the sender key and the tunnel can be 0.2 OOR
established. In order to carry the peer public key in the LISP 0.1 WG+OOR
messages, we leveraged the LISP Canonical Address Format, 0
LCAF (RFC 8060), an extension of such protocol that allows 28 29 30 31 32 33 34 35 36 37 38
adding extra data in the Map Request/Map Reply messages End-to-end delay (ms)
(LCAF 11 - security key).
Finally, in case a peer wants to update its public key, we Figure 5. Tunnel Establishment end-to-end delay CDF
can easily update this information with a LISP Map Register
message.
the establishment of the WireGuard tunnels (for OOR+WG)
VI. E VALUATION or the LISP tunnels (for OOR). We repeated this experiment
We evaluated different metrics of our implementation in 100 times. We can see that WireGuard adds an extra delay of
order to quantify the overhead of adding security (i.e. the approximately 1 ms due to the cryptography. We consider this
WireGuard cryptography), as well as the delay of the pull delay acceptable, taking into account that we are comparing
architecture. Since OOR also implements the LISP data plane, an unencrypted connection (OOR) and an encrypted one
i.e. it can create unencrypted network overlays, we took OOR’s (OOR+WG). We must remark that OOR packets go through
performance (not modified) as a baseline. We carried out user space, while in OOR+WG they stay in kernel space. The
all tests in a lab setup with Gb Ethernet interfaces, and we former adds an extra delay because data packets are copied
considered the network delay negligible. The servers were from kernel to user space and vice-versa (fig. 6).
running Linux Ubuntu 16.04 on an Intel Xeon E5-2650 v4
@ 2.20 GHz. B. Control Channel Performance
We evaluated the performance of our control plane imple-
A. End-to-end Delay mentation and compared it to OOR with LISP data plane, and
Fig. 5 presents the CDF of the delay to establish a tunnel, a prototype that uses gRPC instead of LISP to retrieve the
i.e the time since we send a probe packet until we receive public key. The prototype is based on a C version of gRPC
the first response. The setup consisted of two instances of [23], and uses a WireGuard secure tunnel to communicate
our implementation in the same LAN, directly connected with with the central server, like the OOR+WG prototype. Figure
each other and also to the central server. We setup a data rate 7 presents the CDF of the end-to-end delay to add data for a
of 10000 pings/s to have an adequate time resolution. The new endpoint, or connection establishment time. We measured
measured time includes all the control plane signaling and the time it takes to retrieve the public key for a new endpoint
 Retrieve
Endpoint Data 125

Processing Delay (µs)

120
OOR 115
Application LISP Encapsulation 110
105 OOR+WG
Routing 100 OOR
User Space
Config 95
90
Application 85
TUN Interface 80
socket
10 100 1000 10000 100000

Kernel Space
Number of Entries
Physical
Linux Routing Figure 8. Central Server Response Delay
Interface
we artificially generated LISP messages towards the central
Figure 6. Out of the box OOR implementation diagram. Solid lines represent server using LIG, a tool that can create different kinds of LISP
data plane traffic flow, dashed lines control plane traffic. As opposed to the
OOR+WG implementation in fig. 4, data plane traffic is copied between kernel messages [25]. Note that we are measuring the performance of
and userspace, adding overhead. the central server, in other words, both OOR and OOR+WG
messages were unencrytped and there were no tunnels between
1 the central server and the machine sending the requests. We
0.9 repeated this experiment 50 times for each number of elements
0.8 in the server. We can appreciate that the delay does not depend
0.7 on the number of elements because the server implementation
0.6 uses a Patricia Trie [26]. In other words, the maximum number
CDF

0.5 of peers a single server can handle will be limited by its CPU,
0.4 not the database size. Additionally, this experiment quantifies
0.3 OOR the overhead of adding a public key in the central server
0.2 OOR+WG database. We can see that it increases the delay on average 40
0.1 gRPC+WG µs. Again, this modest increase is due to the aforementioned
0 extra 32 bytes.
0 1 2 3 4 5 6 7 8 9 10
Delay to add a new endpoint (ms) D. Handover Delay
Regarding mobility events, figure 9 presents the handover
Figure 7. Delay to request and configure a new endpoint delay for OOR and OOR+WireGuard. We modified the setup
of sec. VI-A by connecting one of the two peers via WiFi
from the central server. We repeated the experiment 150 times
through two possible access points (fig. 10), and we triggered
for the three scenarios. We can appreciate that OOR with
handovers by manually changing the access point of this peer.
WireGuard takes approximately 1.5 ms more than OOR to
We ran a ping of 10 requests/ms between the two machines and
complete this operation. This is due to the fact that we are
measured the amount time without ICMP replies. We repeated
retrieving more information (WireGuard needs the public key,
this experiment 20 times. This test shows that WireGuard
apart from the endpoint IP address) and the overhead of
presents a handover delay nearly one order of magnitude less
configuring the WireGuard interface (as opposed to OOR, in
than OOR. This is due to the fact that the WireGuard handover:
which we can start sending packets directly). Nevertheless,
(i) operates in kernel space, and (ii) it does not require control
since the WireGuard public keys are 32 bytes, the performance
plane signaling, as opposed to OOR, that issues a new Map
penalty of downloading this extra information is negligible
Request / Map Register in this situation.
compared to typical Internet latency [24]. On the other hand,
From an architecture point of view, we observe that adding
the gRPC prototype presents a delay double to OOR+WG, due
a security association simplifies mobility, because we can
to the overhead of its HTTP/2 transport.
learn new endpoints through the data plane with virtually no
signalling. In addition, if the endpoint IP address is spoofed,
C. Central Server Scalability
the payload is protected by the WG crypto header. On the
We also evaluated the scalability of the centralized server. other hand, this technique does not cover corner cases such
Figure 8 presents the delay to answer a request for endpoint as double jump. This is in line with the design philosophy of
data for both OOR and OOR with WireGuard, depending on WireGuard, that sacrifices flexibility for simplicity.
the number of elements in the central server. Specifically,
we measured the processing delay of the central server, i.e. E. Data Plane Performance
the time since it receives a data request until it generates Finally, we measured the data plane throughput. Fig. 11
the corresponding response. To perform this measurement, presents the input and output rate for our OOR+WireGuard
 10 1000
9
Handover Delay (s)
900
8 800
7

Output (Mbps)
6 700
OOR 600
5
4 WG 500
3 400
2 300
1 OOR+WG
0 200 OOR
0 2 4 6 8 10 12 14 16 18 20 100 IPsec
0
Test # 0 200 400 600 800 1000
Figure 9. Handover delay Input (Mbps)

Figure 11. Throughput comparison

Central that acts as identifier, e.g. VXLAN Network Identifier [27].

Server Since WireGuard packets do not include a Virtual Network
Identifier, it is not possible to make this distinction. However,
it can be accomplished by adding this field to the WireGuard
WiFi 1 header, or adding a VXLAN header before sending packets
LAN to the WireGuard interface, for instance. We believe this is a
Peer 1 Peer 2 relevant feature that could be considered among the WireGuard
community.
WiFi 2 B. Multihoming

Figure 10. Handover evaluation setup

Our implementation cannot send encrypted traffic from mul-
tiple Internet endpoints at the same time (i.e. multihoming).
implementation, IPsec, and out-of-the box OOR. In the same The main reason is that WireGuard only supports a single
setup as in sec. VI-A, we configured a tunnel between the endpoint IP at any moment in time. If the endpoint IP changes
two servers, and we used the nuttcp utility to determine it is interpreted as a mobility event, not traffic coming from
real throughput between them for several input rates, and different sources. A possible solution consists in leveraging
for each protocol. We sent UDP packets, and adjusted the the control plane channel to advertise the set of possible
lengths of the send/receive buffers taking into account the Internet endpoints to both peers. However, this means that the
size of the different headers of each protocol, in order to WireGuard data plane cannot update the Internet endpoint of a
fill in the packets but avoid L3 fragmentation. We configured peer when it receives a packet with a different IP, thus making
IPsec in tunnel mode with the same encryption algorithm as mobility more complex. This feature is especially interesting
WireGuard (ChaCha20 and Poly1305). We can see that both in the context of increased mobile device usage, e.g. WiFi
OOR+WG and IPsec offer similar performance, and start to and LTE interfaces in a smartphone, or ISPs that offer VPN
degrade gracefully around 900 Mbps. On the other hand, the solutions.
OOR version that uses the LISP data plane degrades abruptly
at 800 Mbps due to the overhead of copying form kernel to C. Mobility Double Jump
user space. In case two peers change their Internet endpoint at the same
time, it is not possible to re-establish connection only with data
VII. L ESSONS L EARNT plane mechanisms. However, thanks to our control plane we
During the implementation and evaluation of our proto- can account for this situation. When a peer detects it has not
type, we found a few shortcomings in WireGuard. Some are received packets after some time, it sends a new key request
especially relevant for enterprise (Virtual Networking) and to the control plane. Since the other peer will have updated its
ISP (mulithoming) scenarios. In this section we comment new endpoint in the control plane, the former peer will receive
on them and outline possible approaches. Some of them can the new endpoint IP and communication will resume.
be addressed with our proposed control plane, others require
modifying the WireGuard data plane. VIII. C ONCLUSION
In this paper we have presented a control plane for nodes
A. Virtual Networking using the WireGuard VPN. Such control plane stores the
It is common to support several instances of the same WireGuard public keys in a centralized server and distributes
addressing space, especially in enterprise environments. The them on-demand. The proposed architecture offers two main
most common solution is adding an extra field in the headers advantages: (i) automates the configuration of WireGuard
tunnels, and (ii) reduces state in the data plane by creating [18] (2020, May) Ila kernel documents. [Online]. Available: https:
security associations only if a particular tunnel is required. //www.kernel.org/doc/Documentation/networking/ila.txt
[19] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
This control plane can be used to automate deployment, J. Rexford, S. Shenker, and J. Turner, “Openflow: enabling innovation in
especially for enterprise or ISP scenarios with a large amount campus networks,” ACM SIGCOMM computer communication review,
of peers. We also took advantage of WireGuard to secure the vol. 38, no. 2, pp. 69–74, 2008.
[20] (2020, October) grpc - a high-performance, open source universal rpc
control plane channel between the nodes and the centralized framework. Google. [Online]. Available: https://grpc.io/
server. In addition, we have discussed the main challenges, [21] (2019, April) Open overlay router project. [Online]. Available:
such as pushing the sender’s public key to the destination, https://openoverlayrouter.org/
[22] A. Rodriguez-Natal, J. Paillisse, F. Coras, A. Lopez-Bresco, L. Jakab,
and possible additions like virtual networking or multihoming, M. Portoles-Comeras, P. Natarajan, V. Ermagan, D. Meyer, D. Farinacci
in order to support the aforementioned use cases. Finally, we et al., “Programmable overlays via openoverlayrouter,” IEEE Commu-
have presented the design of our implementation, an evaluation nications Magazine, vol. 55, no. 6, pp. 32–38, 2017.
[23] lixiangyun. (2021, March) C implementation of grpc layered of top of
of the overhead of such control plane, and performance core libgrpc. [Online]. Available: https://github.com/lixiangyun/grpc-c
measurements to validate that we retain the throughput and [24] R. Durairajan, S. K. Mani, J. Sommers, and P. Barford, “Time’s
mobility benefits of WireGuard. forgotten: Using ntp to understand internet latency,” in Proceedings of
the 14th ACM Workshop on Hot Topics in Networks, 2015, pp. 1–7.
[25] (2020, June) Lispmob lig-lispmob. LISPmob and D. Meyer. [Online].
R EFERENCES Available: https://github.com/LISPmob/lig-lispmob
[1] (2020, May) Openvpn project. [Online]. Available: https://openvpn.net/ [26] D. R. Morrison, “Patricia—practical algorithm to retrieve information
[2] J. A. Donenfeld, “Wireguard: Next generation kernel network tunnel.” coded in alphanumeric,” J. ACM, vol. 15, no. 4, p. 514–534, Oct. 1968.
in NDSS, 2017. [Online]. Available: https://doi.org/10.1145/321479.321481
[3] (2020, February) What is wireguard? why linux users going crazy over [27] M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar,
it? It’s FOSS. [Online]. Available: https://itsfoss.com/wireguard/ M. Bursell, and C. Wright, “Virtual eXtensible Local Area Network
[4] (2020, March) Linux’s wireguard vpn is here and ready to (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks
protect you. ZDNet. [Online]. Available: https://www.zdnet.com/article/ over Layer 3 Networks,” RFC 7348, Aug. 2014. [Online]. Available:
linuxs-wireguard-vpn-is-here-and-ready-to-protect-you/ https://rfc-editor.org/rfc/rfc7348.txt
[5] B. Lipp, B. Blanchet, and K. Bhargavan, “A mechanised cryptographic
proof of the wireguard virtual private network protocol,” in 2019 IEEE
European Symposium on Security and Privacy (EuroS P), 2019, pp.
231–246.
[6] A. Hülsing, K.-C. Ning, P. Schwabe, F. Weber, and P. R. Zimmermann,
“Post-quantum wireguard,” no. 2020/379, 2020. [Online]. Available:
https://eprint.iacr.org/2020/379.pdf
[7] P. E. Hoffman and J. Schlyter, “The DNS-Based Authentication of
Named Entities (DANE) Transport Layer Security (TLS) Protocol:
TLSA,” RFC 6698, Aug. 2012. [Online]. Available: https://rfc-editor.
org/rfc/rfc6698.txt
[8] P. Wouters, “DNS-Based Authentication of Named Entities (DANE)
Bindings for OpenPGP,” RFC 7929, Aug. 2016. [Online]. Available:
https://rfc-editor.org/rfc/rfc7929.txt
[9] (2020, February) Dynamic multipoint vpn configuration guide. Cisco.
[Online]. Available: https://www.cisco.com/c/en/us/td/docs/ios-xml/
ios/sec conn dmvpn/configuration/xe-16/sec-conn-dmvpn-xe-16-book/
sec-conn-dmvpn-dmvpn.html
[10] S. Gordeychik, D. Kolegov, and A. Nikolaev, “Sd-wan internet
census,” arXiv preprint 1808.09027, 2018. [Online]. Available:
http://arxiv.org/abs/1808.09027
[11] B. C. Neuman and T. Ts’o, “Kerberos: An authentication service for
computer networks,” IEEE Communications magazine, vol. 32, no. 9,
pp. 33–38, 1994.
[12] M. Rossberg and G. Schaefer, “A survey on automatic configuration
of virtual private networks,” Computer Networks, vol. 55, no. 8, pp.
1684 – 1699, 2011. [Online]. Available: http://www.sciencedirect.com/
science/article/pii/S1389128611000053
[13] D. Carrel and B. Weis, “IPsec Key Exchange using a Controller,” Internet
Engineering Task Force, Internet-Draft draft-carrel-ipsecme-controller-
ike-01, Mar. 2019, work in Progress. [Online]. Available: https:
//datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike-01
[14] A. S. Braadland, “Key management for data plane encryption in sdn
using wireguard,” Master’s thesis, NTNU, 2017. [Online]. Available:
http://hdl.handle.net/11250/2457832
[15] (2021, February) Openvpn reference manual. [Online]. Available: https:
//openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
[16] F. Maino, L. Kreeger, and U. Elzur, “Generic Protocol Extension for
VXLAN,” Internet Engineering Task Force, Internet-Draft draft-ietf-
nvo3-vxlan-gpe-09, Dec. 2019, work in Progress. [Online]. Available:
https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-09
[17] J. Gross, I. Ganga, and T. Sridhar, “Geneve: Generic Network Virtual-
ization Encapsulation,” Internet Engineering Task Force, Internet-Draft
draft-ietf-nvo3-geneve-16, Mar. 2020, work in Progress. [Online]. Avail-
able: https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-geneve-16