* Interest in adding multicast support to Wireguard?
@ 2020-09-21 7:13 Derrick Lyndon Pallas
2020-09-21 9:57 ` Toke Høiland-Jørgensen
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: Derrick Lyndon Pallas @ 2020-09-21 7:13 UTC (permalink / raw)
To: WireGuard mailing list
I know this has come up a few times before, but if there was resolution,
I couldn't find it.
I am trying to set up a hub-and-spoke network with many clients
connected to a single concentrator. One application I need to support
relies on mDNS. Because Wireguard does not allow overlapping ranges (for
understandable reasons), this works on point-to-point links with two
peers but not on hub-and-spoke or other multi-peer setups. This would be
possible if every peer had its own hub interface, but that seems like an
inelegant, error-prone workaround.
Some have suggested running vxlan or another encapsulation method on top
of Wireguard, but that's not possible in this situation because I do not
control the software running on the peers. Typically, they'll just be
running the official Wireguard apps for MacOS or Windows.
Hacking Wireguard to understand the multicast range and to
clone-and-forward this traffic to all peers does work. If there is wider
interest in that specific feature, I'm happy to work what I have into
something that could be upstreamed. Currently the range is global and
hard-coded, but I could imagine wanting fine-grained control over which
peers were interested in specific multicast addresses, e.g., for a
user-space daemon managing IGMP subscriptions. However, before I spent
time on any of the above, I wanted to gauge whether there was interest
and whether that kind of feature might be accepted at all.
Thanks, ~Derrick
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-21 7:13 Interest in adding multicast support to Wireguard? Derrick Lyndon Pallas
@ 2020-09-21 9:57 ` Toke Høiland-Jørgensen
2020-09-21 15:16 ` Derrick Lyndon Pallas
2020-09-21 11:17 ` AW: " Florian Werner
` (2 subsequent siblings)
3 siblings, 1 reply; 13+ messages in thread
From: Toke Høiland-Jørgensen @ 2020-09-21 9:57 UTC (permalink / raw)
To: Derrick Lyndon Pallas, WireGuard mailing list
Derrick Lyndon Pallas <derrick@pallas.us> writes:
> I know this has come up a few times before, but if there was resolution,
> I couldn't find it.
>
> I am trying to set up a hub-and-spoke network with many clients
> connected to a single concentrator. One application I need to support
> relies on mDNS.
While I generally support adding multicast support to Wireguard, for
mDNS you may be able to solve your problem by using a 'hybrid proxy'
which makes it possible to do mDNS discovery over unicast DNS. See
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-10 for the standard,
and https://github.com/sbyx/ohybridproxy for an implementation. I'm
running the latter on my network, and while it does require a bit of
configuration, it works reasonably well for device discovery across
routed network segments... So depending on your setup it could likely be
made to work across wg links as well :)
-Toke
^ permalink raw reply [flat|nested] 13+ messages in thread
* AW: Interest in adding multicast support to Wireguard?
2020-09-21 7:13 Interest in adding multicast support to Wireguard? Derrick Lyndon Pallas
2020-09-21 9:57 ` Toke Høiland-Jørgensen
@ 2020-09-21 11:17 ` Florian Werner
2020-09-21 15:16 ` Derrick Lyndon Pallas
2020-09-21 11:24 ` Jason A. Donenfeld
2020-09-27 17:50 ` Derek Fawcus
3 siblings, 1 reply; 13+ messages in thread
From: Florian Werner @ 2020-09-21 11:17 UTC (permalink / raw)
To: 'Derrick Lyndon Pallas', 'WireGuard mailing list'
I would appreciate multicast support for Wireguard. My wish and use-case would be full support for in band dynamic address assignment, i.e. without any external protocol or other shared information except the public key.
At least for the IPv6 case (with I only consider here, but IPv4 can be added too), link-local scope multicast (FF02::/64) and the unspecified address (::) are enough to bootstrap any address assignment and to enable learning of self-assigned addresses (e.g. FE80::/64) of peers and eventually dynamic assignment (and learning) of global unicast addresses. This could all be accomplished only by standard protocols (IPv6 Neighbor Discovery, SLAAC, DHCPv6). The only modification would be for Wireguard to (optionally) send all packages with a multicast destination address to all peers and for Wireguard to receive packages with a (all or only some) multicast destination address from any peer. (if someone wants a detailed explanation of this, just ask)
There are multiple ways to implement multicast addresses:
(1) always make FF00::/8 and 224.0.0.0/4 special: send it to all peers and receive it from all
(2) like (1) but opt in for multicast per Wireguard interface
(3) like (1) but opt in for multicast per peer
(4) make FF00::/8 and 224.0.0.0/4 special, but only send/receive them if listed in AllowedIPs
(5) like (4) but allow smaller subnets (e.g. FF02::/64)
(6) make FF00::/8 and 224.0.0.0/4 special and allow for fine grained filtering for sending and receiving, i.e. AllowedIPs but separate between send and receive.
Regards,
Florian
> I know this has come up a few times before, but if there was resolution,
> I couldn't find it.
>
> I am trying to set up a hub-and-spoke network with many clients
> connected to a single concentrator. One application I need to support
> relies on mDNS. Because Wireguard does not allow overlapping ranges (for
> understandable reasons), this works on point-to-point links with two
> peers but not on hub-and-spoke or other multi-peer setups. This would be
> possible if every peer had its own hub interface, but that seems like an
> inelegant, error-prone workaround.
>
> Some have suggested running vxlan or another encapsulation method on top
> of Wireguard, but that's not possible in this situation because I do not
> control the software running on the peers. Typically, they'll just be
> running the official Wireguard apps for MacOS or Windows.
>
> Hacking Wireguard to understand the multicast range and to
> clone-and-forward this traffic to all peers does work. If there is wider
> interest in that specific feature, I'm happy to work what I have into
> something that could be upstreamed. Currently the range is global and
> hard-coded, but I could imagine wanting fine-grained control over which
> peers were interested in specific multicast addresses, e.g., for a
> user-space daemon managing IGMP subscriptions. However, before I spent
> time on any of the above, I wanted to gauge whether there was interest
> and whether that kind of feature might be accepted at all.
>
> Thanks, ~Derrick
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-21 7:13 Interest in adding multicast support to Wireguard? Derrick Lyndon Pallas
2020-09-21 9:57 ` Toke Høiland-Jørgensen
2020-09-21 11:17 ` AW: " Florian Werner
@ 2020-09-21 11:24 ` Jason A. Donenfeld
2020-09-21 15:04 ` Reid Rankin
2020-09-21 15:17 ` Derrick Lyndon Pallas
2020-09-27 17:50 ` Derek Fawcus
3 siblings, 2 replies; 13+ messages in thread
From: Jason A. Donenfeld @ 2020-09-21 11:24 UTC (permalink / raw)
To: Derrick Lyndon Pallas; +Cc: WireGuard mailing list
We've discussed this extensively and repeatedly. I made a few
proposals a few years ago that we discussed. It doesn't fit into
WireGuard's strong binding model.
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-21 11:24 ` Jason A. Donenfeld
@ 2020-09-21 15:04 ` Reid Rankin
2020-09-21 15:16 ` Derrick Lyndon Pallas
2020-09-21 15:17 ` Derrick Lyndon Pallas
1 sibling, 1 reply; 13+ messages in thread
From: Reid Rankin @ 2020-09-21 15:04 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: Derrick Lyndon Pallas, WireGuard mailing list
I looked at this a while back. As far as I could tell, there's nothing
fundamental about the protocol or the security model that prevents it
from happening; conceptually, it's as simple as overlapping AllowedIP
ranges. This is easy for incoming traffic, but outgoing traffic is
more difficult; each outgoing packet would need to be duplicated and
encrypted separately for each target peer. What's more, each of these
duplicate unicast packets would have to be queued separately because
each peer may be in a different handshake state.
None of this makes multicast over WireGuard impossible, however, just
difficult to fit into the existing implementation. I've toyed with the
idea of a one-interface-per-peer setup with bridging or some fancy
netfilter stuff to handle duplication and dispatch between them, but
it seems like it would be a PITA so I've never taken it farther.
As far as "special" multicast ranges, heck no. One of the fundamental
assurances of WG is that you'll only ever receive packets from a peer
which have a source address listed in that peer's AllowedIPs. If you
want to put ff00::/8 and 224.0.0.0/4 in a peer's AllowedIPs, by all
means, but I'm strongly against WG itself having any special notion of
what a "multicast address" is or any special handling -- or sneaky
emergent properties -- for them. DHCPv6, for example, requires only
ff02::1:2; if that's what you want, I probably wouldn't whitelist a
whole /8 to get it. YMMV, of course, but that should be the user's
choice and responsibility.
Another reason not to treat certain address ranges specially is that
there's more use cases for what would effectively be a "link-layer"
multicast than there are for IP multicast. You could have something
like port mirroring going on; say you've got a gateway with ::/0 as
well as an IDS with the same range. Both could receive the same
traffic, which could be useful in some applications. Obviously, you'd
need to realize the security implications -- both client-side (sending
copies of all your traffic) and IDS-side (trusting that you'll really
be sent copies of all the traffic) -- but flexibility is good, and I
can imagine some usecases (especially embedded systems) where that
would be a desirable property. (Sure beats sending the traffic in the
clear and having the IDS -- and whoever's hacked your switch -- get it
that way.)
--Reid
On Mon, Sep 21, 2020 at 7:27 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> We've discussed this extensively and repeatedly. I made a few
> proposals a few years ago that we discussed. It doesn't fit into
> WireGuard's strong binding model.
>
> Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-21 9:57 ` Toke Høiland-Jørgensen
@ 2020-09-21 15:16 ` Derrick Lyndon Pallas
0 siblings, 0 replies; 13+ messages in thread
From: Derrick Lyndon Pallas @ 2020-09-21 15:16 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, WireGuard mailing list
Toke, good to hear from you again!
Thanks for the pointer to ohybridproxy. Unicast conversion was on the
list of things to check out. Unfortunately, it appears to take manual
intervention on some platforms (e.g. MacOS) and does not work for
auto-discovery on others (e.g. iPhone). If I controlled the application
on both ends, I think this would have been a genuinely useful
alternative approach. Unfortunately, I do not control the application.
~Derrick
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: AW: Interest in adding multicast support to Wireguard?
2020-09-21 11:17 ` AW: " Florian Werner
@ 2020-09-21 15:16 ` Derrick Lyndon Pallas
0 siblings, 0 replies; 13+ messages in thread
From: Derrick Lyndon Pallas @ 2020-09-21 15:16 UTC (permalink / raw)
To: Florian Werner, 'WireGuard mailing list'
Thanks for the reply.
Since I can't control the peers (they're mostly just running the
official Wireguard apps), the way I've got it implemented is that
224.0.0.0/4 is explicitly in their lists of AllowedIPs. On the hub side,
I took approach (1) for the proof of concept.
If I were to extend the implementation, my gut says that it'd be better
to separate AllowedIPs and MulticastIPs logically, and to make the
ranges opt-in and per-peer. However, I haven't tried implementing that
yet so I don't know how hard/useful it would be.
~Derrick
On 9/21/20 4:17 AM, Florian Werner wrote:
> I would appreciate multicast support for Wireguard. My wish and use-case would be full support for in band dynamic address assignment, i.e. without any external protocol or other shared information except the public key.
>
> At least for the IPv6 case (with I only consider here, but IPv4 can be added too), link-local scope multicast (FF02::/64) and the unspecified address (::) are enough to bootstrap any address assignment and to enable learning of self-assigned addresses (e.g. FE80::/64) of peers and eventually dynamic assignment (and learning) of global unicast addresses. This could all be accomplished only by standard protocols (IPv6 Neighbor Discovery, SLAAC, DHCPv6). The only modification would be for Wireguard to (optionally) send all packages with a multicast destination address to all peers and for Wireguard to receive packages with a (all or only some) multicast destination address from any peer. (if someone wants a detailed explanation of this, just ask)
>
> There are multiple ways to implement multicast addresses:
> (1) always make FF00::/8 and 224.0.0.0/4 special: send it to all peers and receive it from all
> (2) like (1) but opt in for multicast per Wireguard interface
> (3) like (1) but opt in for multicast per peer
> (4) make FF00::/8 and 224.0.0.0/4 special, but only send/receive them if listed in AllowedIPs
> (5) like (4) but allow smaller subnets (e.g. FF02::/64)
> (6) make FF00::/8 and 224.0.0.0/4 special and allow for fine grained filtering for sending and receiving, i.e. AllowedIPs but separate between send and receive.
>
> Regards,
> Florian
>
>> I know this has come up a few times before, but if there was resolution,
>> I couldn't find it.
>>
>> I am trying to set up a hub-and-spoke network with many clients
>> connected to a single concentrator. One application I need to support
>> relies on mDNS. Because Wireguard does not allow overlapping ranges (for
>> understandable reasons), this works on point-to-point links with two
>> peers but not on hub-and-spoke or other multi-peer setups. This would be
>> possible if every peer had its own hub interface, but that seems like an
>> inelegant, error-prone workaround.
>>
>> Some have suggested running vxlan or another encapsulation method on top
>> of Wireguard, but that's not possible in this situation because I do not
>> control the software running on the peers. Typically, they'll just be
>> running the official Wireguard apps for MacOS or Windows.
>>
>> Hacking Wireguard to understand the multicast range and to
>> clone-and-forward this traffic to all peers does work. If there is wider
>> interest in that specific feature, I'm happy to work what I have into
>> something that could be upstreamed. Currently the range is global and
>> hard-coded, but I could imagine wanting fine-grained control over which
>> peers were interested in specific multicast addresses, e.g., for a
>> user-space daemon managing IGMP subscriptions. However, before I spent
>> time on any of the above, I wanted to gauge whether there was interest
>> and whether that kind of feature might be accepted at all.
>>
>> Thanks, ~Derrick
>>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-21 15:04 ` Reid Rankin
@ 2020-09-21 15:16 ` Derrick Lyndon Pallas
2020-09-22 18:54 ` Derrick Lyndon Pallas
0 siblings, 1 reply; 13+ messages in thread
From: Derrick Lyndon Pallas @ 2020-09-21 15:16 UTC (permalink / raw)
To: Reid Rankin, Jason A. Donenfeld; +Cc: WireGuard mailing list
Thanks for the reply. I definitely agree about not having magic, built
in ranges. If I were to more fully implement this, I'd likely separate
out MulticastIPs from AllowedIPs so that users do not unwittingly turn
an intended-unicast subnet into an accidentally-multicast subnet. It
would all, of course, be opt-in only. ~Derrick
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-21 11:24 ` Jason A. Donenfeld
2020-09-21 15:04 ` Reid Rankin
@ 2020-09-21 15:17 ` Derrick Lyndon Pallas
1 sibling, 0 replies; 13+ messages in thread
From: Derrick Lyndon Pallas @ 2020-09-21 15:17 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
On 9/21/20 4:24 AM, Jason A. Donenfeld wrote:
> We've discussed this extensively and repeatedly. I made a few
> proposals a few years ago that we discussed. It doesn't fit into
> WireGuard's strong binding model.
>
> Jason
As I mentioned, I looked through the archives before starting this
thread. Specifically, I looked for mentions of multicast and followed
the threads, but I didn't find a concrete resolution. Maybe I missed
something.
I understand the theoretical argument. However, the practical
implication is that a widely deployed discovery mechanism on at least
one very population hardware platform is hamstrung without jumping
through pretty significant accounting hoops.
Given the other responses to this thread, it sounds like there is
interest in an opt-in feature but that a pull request would likely not
be accepted. Have I misunderstood?
~Derrick
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-21 15:16 ` Derrick Lyndon Pallas
@ 2020-09-22 18:54 ` Derrick Lyndon Pallas
2020-09-22 19:38 ` Reid Rankin
0 siblings, 1 reply; 13+ messages in thread
From: Derrick Lyndon Pallas @ 2020-09-22 18:54 UTC (permalink / raw)
To: Reid Rankin, Jason A. Donenfeld; +Cc: WireGuard mailing list
On 9/21/20 8:16 AM, Derrick Lyndon Pallas wrote:
>
As an aside, it looks like at least one Wireguard (protocol)
implementation [1] actually does implement all-or-nothing
multicast/broadcast in their client: note the AllowMulticast option in
[2]. They also explicitly enable ICMPv6 Neighbor Solicitation.
[1] https://github.com/TunSafe/TunSafe/
[2] https://tunsafe.com/user-guide/config
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-22 18:54 ` Derrick Lyndon Pallas
@ 2020-09-22 19:38 ` Reid Rankin
2020-09-22 20:26 ` Derrick Lyndon Pallas
0 siblings, 1 reply; 13+ messages in thread
From: Reid Rankin @ 2020-09-22 19:38 UTC (permalink / raw)
To: Derrick Lyndon Pallas; +Cc: Jason A. Donenfeld, WireGuard mailing list
While I'm all for multicast support, I don't think this is it. TunSafe
only has that option to allow you to turn off an extra anti-multicast
filter that's on by default and drops anything incoming from ff00::/8
or 224.0.0./3, even if it's from a peer with those ranges in its
AllowedIPs. (Actually, 224.0.0.0/3 is technically the wrong range for
IPv4 multicast; that's 224.0.0.0/4. The upper half of that space,
240.0.0.0/4, has been "reserved for future addressing modes" since
1989.)
TunSafe was available long before the official WireGuard
implementation on Windows, largely because Jason insisted on
implementation of a proper Windows tunnel driver that operated at L3
(Wintun). TunSafe instead used the TAP-Windows driver from OpenVPN,
which shows up to Windows as an L2 device. It can do this because it
pretends that its peers have "MAC addresses" and uses a built-in
ARP/ND responder to fake the associated L2 traffic needed to bootstrap
L3 communication. I'm pretty sure this extra multicast filter was
added specifically because it prevents peers from interacting with
this internal ARP/ND machinery, either maliciously or through
misconfiguration.
--Reid
On Tue, Sep 22, 2020 at 2:54 PM Derrick Lyndon Pallas <derrick@pallas.us> wrote:
>
> On 9/21/20 8:16 AM, Derrick Lyndon Pallas wrote:
>
> >
> As an aside, it looks like at least one Wireguard (protocol)
> implementation [1] actually does implement all-or-nothing
> multicast/broadcast in their client: note the AllowMulticast option in
> [2]. They also explicitly enable ICMPv6 Neighbor Solicitation.
>
>
> [1] https://github.com/TunSafe/TunSafe/
>
> [2] https://tunsafe.com/user-guide/config
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-22 19:38 ` Reid Rankin
@ 2020-09-22 20:26 ` Derrick Lyndon Pallas
0 siblings, 0 replies; 13+ messages in thread
From: Derrick Lyndon Pallas @ 2020-09-22 20:26 UTC (permalink / raw)
To: Reid Rankin; +Cc: Jason A. Donenfeld, WireGuard mailing list
On 9/22/20 12:38 PM, Reid Rankin wrote:
> While I'm all for multicast support, I don't think this is it. TunSafe
> only has that option to allow you to turn off an extra anti-multicast
> filter that's on by default and drops anything incoming from ff00::/8
> or 224.0.0./3, even if it's from a peer with those ranges in its
> AllowedIPs. (Actually, 224.0.0.0/3 is technically the wrong range for
> IPv4 multicast; that's 224.0.0.0/4. The upper half of that space,
> 240.0.0.0/4, has been "reserved for future addressing modes" since
> 1989.)
Yes, I also agree that all-or-nothing is not the right answer. I'm only
pointing out that multicast has been implemented in at least one client.
~Derrick
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Interest in adding multicast support to Wireguard?
2020-09-21 7:13 Interest in adding multicast support to Wireguard? Derrick Lyndon Pallas
` (2 preceding siblings ...)
2020-09-21 11:24 ` Jason A. Donenfeld
@ 2020-09-27 17:50 ` Derek Fawcus
3 siblings, 0 replies; 13+ messages in thread
From: Derek Fawcus @ 2020-09-27 17:50 UTC (permalink / raw)
To: WireGuard mailing list
Various routers have support for running PIM (and IGMP/MLD)
in NBMA mode, whereby individual hosts and joins/leave for
such are tracked, rather than depend upon a shared broadcast
medium.
This is used for mcast over Frame Relay, ATM, etc
which are inherently NBMA.
ISTM that wg should also be modelled as NBMA, and as such
the same sorts of approaches should be taken.
DF
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-09-27 17:51 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-21 7:13 Interest in adding multicast support to Wireguard? Derrick Lyndon Pallas
2020-09-21 9:57 ` Toke Høiland-Jørgensen
2020-09-21 15:16 ` Derrick Lyndon Pallas
2020-09-21 11:17 ` AW: " Florian Werner
2020-09-21 15:16 ` Derrick Lyndon Pallas
2020-09-21 11:24 ` Jason A. Donenfeld
2020-09-21 15:04 ` Reid Rankin
2020-09-21 15:16 ` Derrick Lyndon Pallas
2020-09-22 18:54 ` Derrick Lyndon Pallas
2020-09-22 19:38 ` Reid Rankin
2020-09-22 20:26 ` Derrick Lyndon Pallas
2020-09-21 15:17 ` Derrick Lyndon Pallas
2020-09-27 17:50 ` Derek Fawcus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).