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 <[email protected]> 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 > >
