Re: Multiple Keys per Peer
Roman Mamedov writes: > On Sun, 02 May 2021 13:02:28 +0200 > Nico Schottelius 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
Re: Multiple Keys per Peer
On Sun, 02 May 2021 13:02:28 +0200
Nico Schottelius 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 :)
> 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.
--
With respect,
Roman
Multiple Keys per Peer
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
