Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: wireguard@lists.zx2c4.com
Subject: Multiple Keys per Peer
Date: Sun, 02 May 2021 13:02:28 +0200
Message-ID: <87wnshs8jf.fsf@ungleich.ch> (raw)


Good morning,

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.

Conceptually I see it problematic to assign multiple keys per Peer as
the routing from outside ("where should this packet go to"?) might
become ambiguous. One counter option would be to allow a peer to signal
that it uses a certain part of the AllowedIPs. In comparison to layer 2
networks, I see two approaches: 1) a bit similar to ARP/NDP, client
addresses are learned 2) similar to dhcp-pd, clients "requesting" (in
this context more: announcing) that they use a certain sub-range.

Protocol wise I'd imagine this to be rather simple:

side a: I want to use 2001:db8:a:b::/64
side b:
     - checking your allowed IPs covers that prefix -> no ignore
     - checking whether the amount of sub routes is not exceeded
     - and/or checking whether the sub-prefix length is of minimum size
     (especially import for IPv6)
     - yes: adjust routing table, insert more specific route
     (with/without confirm probably should be modeld in tamarin)

What are your thoughts about an extension of wireguard with this?

If there are other suggestions to allow users to decide themselves how
to split a range, let's say a /48 IPv6 network, without setting up their
own redistribution node, I'd also be interested in hearing that.

Best regards,

Nico

p.s.: I have seen some old messages in the archive about this topic,
but did not a conclusion in it.

--
Sustainable and modern Infrastructures by ungleich.ch

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

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

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=87wnshs8jf.fsf@ungleich.ch \
    --to=nico.schottelius@ungleich.ch \
    --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

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://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/ https://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