Best strategy for multiple point-to-point tunnels

[Karol Babioch]

Hi all,

first of all: Let me thank you for Wireguard, and all of the
discussion(s) and support here on this mailing list. It's super helpful
and getting started is actually quite easy!

I'm currently wondering what the best (TM) strategy for setting up
multiple point-to-point tunnels is. I'm actually not referring to "how
to manage this" (i.e. configuration management, etc.), but about whether
there is any recommendation on having multiple Wireguard instances (with
dedicated interfaces) vs. setting up a single Wireguard instances (with
multiple peers).

The reason I'm asking is that I'm coming from "OpenVPN world" and for
some reasons I'm actually used to setting up dedicated instances for
each tunnel. Essentially I have multiple OpenVPN instances running on
different ports - independent of each other.

Obviously this is no good for a typical "many clients, one server"
setup, but it has quite a few advantages for simple point-to-point tunnels:

a.) Better performance, since every instance has it's own process.
OpenVPN is notoriously CPU-bound and multi-threading has always been an
bottleneck.

b.) Easier to manage and understand firewall rules, as they can be based
on interface names (rather than IP addresses within a bigger subnet, etc.).

c.) Easier to manage TLS certificates. I'm used to generate "One-time
CAs" [2], i.e. there are only two certificates signed by a single CA. No
revocations and other complexities. This can be automated quite easily
and in case something is wrong, I can easily replace the certificate(s)
for this one tunnel without any effect on all of the other peers.

d.) Maybe the most important: Individual control for all settings (UDP
vs. TCP, MTU, cryptographic primitives, etc.). Sometimes it's hard to
find good, secure and modern settings for all clients, since not all of
them can be upgraded at once. For instance, some clients already support
TLS 1.3, while others do not, etc. OpenVPN allows for quite some
flexibility in that regard (e.g. peer-specific settings), but it was
always easier to have a configuration for every peer, rather than trying
to find the common denotator and/or deal with "client configuration
snippets", etc.

Now, looking at Wireguard, I'm wondering whether those thoughts are
still valid. I guess a.) and c.) are no longer valid concerns.

However b.) still is. For me it's still easier to write, understand and
manage firewall rules that are based on an interface name (i.e.
`wg-peername` vs. some seemingly "random" source IP from `wg0`).

The biggest concern on my end, though, currently is the "backwards
compability". So far Wireguard is the new kid in town and everything
works fine and is compability with each other, i.e. there are no
imcompatible versions / implementations, etc. That's great, of course.
Obviously, this is not a coincidence, but a design choice of the protocol.

However, the original whitepaper [1] also states:

> Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If
> holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing
> torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.

While I can understand (and agree with) this reasoning, I'm wondering
what this will mean in the future, when there will be either new
versions / features and/or some security vulnerability that will require
a breaking change on the protocol level.

What will happen to my tunnels, when I update the "server". Will only
compatible clients be able to connect? Will there be some switch to
still allow connections from some old peer(s). Will it make a difference
whether I have only one interface or multiple interfaces?

I'm basically trying to prevent a situation, where I update the server,
and some/most of my peers will no longer be able to connect, because of
some breaking change. Upgrading everything at once will always be a
challenge: Sometimes you don't have access and/or are not control over
some systems, sometimes there might be other restrictions and/or simply
no update available for some (older) appliance, etc.

I know that most of this is still hypothetical at the current time and
that no one has experience with such situation(s) yet. However, maybe
there are some recommendations on how to deal with this?

What are your thoughts about this? Are you taking any additional
measures to make sure to not be affected by a breaking change later on?
What is your recommendation on handling multiple peer-to-peer tunnels?
Should I go for multiple interfaces or for one interface with multiple
peers?

Thank you for your input, already appreciated in advance.

Best regards,
Karol Babioch

[1]: https://www.wireguard.com/papers/wireguard.pdf
[2]: https://github.com/kbabioch/otca