Development discussion of WireGuard
 help / color / mirror / Atom feed
* Best strategy for multiple point-to-point tunnels
@ 2021-03-25 22:35 Karol Babioch
  2021-03-30 11:53 ` Chriztoffer Hansen
  0 siblings, 1 reply; 5+ messages in thread
From: Karol Babioch @ 2021-03-25 22:35 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Best strategy for multiple point-to-point tunnels
  2021-03-25 22:35 Best strategy for multiple point-to-point tunnels Karol Babioch
@ 2021-03-30 11:53 ` Chriztoffer Hansen
  2021-03-30 11:55   ` Chriztoffer Hansen
  0 siblings, 1 reply; 5+ messages in thread
From: Chriztoffer Hansen @ 2021-03-30 11:53 UTC (permalink / raw)
  To: Karol Babioch; +Cc: WireGuard List (wireguard@lists.zx2c4.com)

On Thu, 25 Mar 2021 at 23:35, Karol Babioch <karol@babioch.de> wrote:
> What is your recommendation on handling multiple peer-to-peer tunnels?
> Should I go for multiple interfaces or for one interface with multiple
> peers?

If you plan to do L3 routing over the P2P tunnels (e.g.
OSPF/BGP/EIGRP/Babel/etc.). A dedicated wg interface per remote
endpoint is generally recommended.

-- 
Chriztoffer


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Best strategy for multiple point-to-point tunnels
  2021-03-30 11:53 ` Chriztoffer Hansen
@ 2021-03-30 11:55   ` Chriztoffer Hansen
  2021-04-06 20:28     ` Allen Chen
  0 siblings, 1 reply; 5+ messages in thread
From: Chriztoffer Hansen @ 2021-03-30 11:55 UTC (permalink / raw)
  To: Karol Babioch; +Cc: WireGuard List (wireguard@lists.zx2c4.com)

On Tue, 30 Mar 2021 at 13:53, Chriztoffer Hansen wrote:
>
> On Thu, 25 Mar 2021 at 23:35, Karol Babioch wrote:
> > What is your recommendation on handling multiple peer-to-peer tunnels?
> > Should I go for multiple interfaces or for one interface with multiple
> > peers?
>
> If you plan to do L3 routing over the P2P tunnels (e.g.
> OSPF/BGP/EIGRP/Babel/etc.). A dedicated wg interface per remote
> endpoint is generally recommended.

If you are doing a road-warrior style set-up. One WG interface (e.g.
per subnet for road-warrior groups) at your aggregation point/server
will be enough.

-- 
Chriztoffer


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Best strategy for multiple point-to-point tunnels
  2021-03-30 11:55   ` Chriztoffer Hansen
@ 2021-04-06 20:28     ` Allen Chen
  2021-04-07 11:16       ` Karol Babioch
  0 siblings, 1 reply; 5+ messages in thread
From: Allen Chen @ 2021-04-06 20:28 UTC (permalink / raw)
  To: wireguard

The process of update is bugging me a lot. Does a update break the 1-n 
connection? There should be a way to check the version compatibility. 
But I don't know how.

Allen

On 3/30/2021 7:55 AM, Chriztoffer Hansen wrote:
> On Tue, 30 Mar 2021 at 13:53, Chriztoffer Hansen wrote:
>> On Thu, 25 Mar 2021 at 23:35, Karol Babioch wrote:
>>> What is your recommendation on handling multiple peer-to-peer tunnels?
>>> Should I go for multiple interfaces or for one interface with multiple
>>> peers?
>> If you plan to do L3 routing over the P2P tunnels (e.g.
>> OSPF/BGP/EIGRP/Babel/etc.). A dedicated wg interface per remote
>> endpoint is generally recommended.
> If you are doing a road-warrior style set-up. One WG interface (e.g.
> per subnet for road-warrior groups) at your aggregation point/server
> will be enough.
>
 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Best strategy for multiple point-to-point tunnels
  2021-04-06 20:28     ` Allen Chen
@ 2021-04-07 11:16       ` Karol Babioch
  0 siblings, 0 replies; 5+ messages in thread
From: Karol Babioch @ 2021-04-07 11:16 UTC (permalink / raw)
  To: wireguard

Hi,

Am 06.04.21 um 22:28 schrieb Allen Chen:
> The process of update is bugging me a lot. Does a update break the 1-n
> connection? There should be a way to check the version compatibility.
> But I don't know how.

right now there are no incompabilities (AFAIK). Not sure how this will
be handled in the future. I guess only time will tell.

I was hoping that some (core) developer could share his thoughts on what
it could look like, but maybe its also too theoretical and can only be
answered, once there is an issue and we know what is affected, etc.

Best regards,
Karol Babioch

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-04-07 11:16 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-25 22:35 Best strategy for multiple point-to-point tunnels Karol Babioch
2021-03-30 11:53 ` Chriztoffer Hansen
2021-03-30 11:55   ` Chriztoffer Hansen
2021-04-06 20:28     ` Allen Chen
2021-04-07 11:16       ` Karol Babioch

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ http://inbox.vuxu.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git