WireGuard Archive on lore.kernel.org
 help / color / Atom feed
* 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, back to index

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

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.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://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


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