-
Notifications
You must be signed in to change notification settings - Fork 312
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.