All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: Roman Mamedov <rm@romanrm.net>
Cc: Nico Schottelius <nico.schottelius@ungleich.ch>,
	wireguard@lists.zx2c4.com
Subject: Re: Multiple Keys per Peer
Date: Sun, 02 May 2021 14:06:53 +0200	[thread overview]
Message-ID: <87pmy9s5k2.fsf@ungleich.ch> (raw)
In-Reply-To: <20210502164344.039fe960@natsu>


Roman Mamedov <rm@romanrm.net> writes:

> On Sun, 02 May 2021 13:02:28 +0200
> Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
>
>> when running a lot of VPN connections using wireguard, there are some
>> questions we see quite often from users, two of which I'd like to
>> discuss here:
>>
>> Multiple keys per Peer
>> ----------------------
>>
>> Users often ask for sharing their connection with multiple
>> devices. The obvious solution is for users to setup their own VPN
>> endpoint with the first key and then reshare themselves. However, this
>> is not feasible in many end user situations.
>
> The prime and the most straightforward solution is to give each user multiple
> keys, and let them connect from each endpoint as an independent Peer.
>
> The rest of what you propose appears to be a set of bizarre hacks because
> you don't want to do the above, because "(reasons)". Maybe start with
> detailing those reasons first, or reconsidering if they are *really* that
> important and unsurmountable :)

Practically speaking our VPN are currently rather
"dumb" and only know about /48's (usually one VPN server is responsible
for a /40). And in practice, we are not so much interested in knowing
how people split their tunnels, so we considers this more of a
dynamic routing than a static configuration.

However, I see your point that we could update our systems for
pre-processing the routing logic and letting users split on a static
basis and with that keeping the wireguard protocol more simple.

I'd say fair enough and thanks for the pointer!

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

      reply	other threads:[~2021-05-02 12:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-02 11:02 Multiple Keys per Peer Nico Schottelius
2021-05-02 11:43 ` Roman Mamedov
2021-05-02 12:06   ` Nico Schottelius [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmy9s5k2.fsf@ungleich.ch \
    --to=nico.schottelius@ungleich.ch \
    --cc=rm@romanrm.net \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.