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
