Wireguard: multiple vs single peer per wg interface

Mysterium Network : Wireguard: multiple vs single wg interface for peers

Created by Antanas Masevicius on Oct 26, 2018

Common way for openvpn is to produce separate tunnel interface for each client. Wireguard lets you configure multiple peers and bind those peers to single interface.

Choosing option may mean difference in performance, management, policy management, usability etc. We try to establish pros and cons for both of these cases to help us decide how to proceed.

Since WG is L3 only, none of the L2 stuff, such as bridging will work with it. That limits single interface per peer usefulness a bit, but most L2 issues can be resolved with routing.

We could weight each point to make decision easier.

Table: Pros for different interfacing method

Interface per peer	One common interface	Group common interface
Routing policy per interface	Configure interface once	Single interface for a related peer group means easier setup and management
QoS policy per interface	Common routing rules can be setup just once	Required visibility of IP in the same subnet2 [1]
Security policy per interface
Easier peer statistics accounting from node
Individual finetune interface parameters (mtu,netns etc.)

Table: Cons for different interfacing method

Interface per peer	One common interface
Increased system resource usage	Harder security isolation
Need to track wg interface naming during addition / removal and relate it to session	Need to track statistics between sessions, since interface statistics cannot be reset [2]
Interface management is OS specific. Harder to implement.	Lack of network namespace may limit new functionality (eg. separate routing domains)
Harder maintenance of various policy rules
Need to handle multiple wg UDP ports - need to choose next free port

[1] We could have clients in different subnets and still forward traffic between them. Just need additional routes and provisional ping for each peer for traffic to flow (http://jrs-s.net/2018/08/05/routing-between-wg-interfaces-with-wireguard/)

[2] Due to static nature of peer WG keeps peer data until its removed by administrator. Mysterium node dialog exchanges auth information with a client generating new auth keys each time new session takes place. For this reason and for improved security there is no point to keep static peer auth data. Peer data should be recreated each time new session is established. Since WG does not have notion of session, we could emulate disconnect where client would send "DISCONNECT" request through our signalling channel and node provider would clear peer data. Otherwise we would keep session up and treat it as ongoing even if there is no traffic.