Re: Interest in adding multicast support to Wireguard?

[Reid Rankin <reidrankin@gmail.com>]

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
>
>