* 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
* 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
* 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: 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 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 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 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 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 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).